Added my full name in git config.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Aug 13 2019
Can you try to build another kdeinit app (i.e. khelpcenter) to check if you get the same error?
Btw I think I spotted a regression:
Got the following errore while pushing:
Aug 12 2019
So now we wait for @elvisangelaccio :-)
In D23075#510896, @ndavis wrote:I think this is fine. It seems like I'm in the minority here with my opinion on the view mode buttons, so I'll just let that go.
In D23075#510697, @GB_2 wrote:
In D23075#510723, @felixernst wrote:I think this example is a very specific occurence for technical users. Most will imo be happy to just have the preview turned on without the need to change that because:
- Previews for text files are turned off by default
- File types have a lot of meaning for us whereas most don't care if they open an .odt or .doc file
- Browsing files where a preview is useless and the file type helps a lot in differentiating is (probably) a rare occurence (.h/.cpp). If there are a bunch of .odt and .doc files in a folder then the preview is more relevant than what type there is. So I think we should remove the preview button by default.
Update dolphinui.rc
In D23075#510738, @filipf wrote:In D23075#510697, @GB_2 wrote:I could be persuaded to have the Split button on the left, but either way this looks good.
In D23075#510697, @GB_2 wrote:
In D23075#510653, @ndavis wrote:In D23075#510484, @ngraham wrote:[Previews] are enabled by default.
Ok. If we're not going to have a button to enable/disable them by default, we should disable previews for documents under a certain size. Maybe =< 32px or =< 22px?
This is not very nice to look at
... compared to this
In D22727#505540, @dfaure wrote:The Qt documentation says "Warning: Because of differences in the platforms supported by Qt, the semantics of ReadUser, WriteUser and ExeUser are platform-dependent: On Unix, the rights of the owner of the file are returned and on Windows the rights of the current user are returned. "
In D23075#510680, @GB_2 wrote:In D23075#510675, @ndavis wrote:In D23075#510674, @GB_2 wrote:I think the view mode buttons should be replaced by the single View Mode menu button. Unlabelled icons are a bad idea unless the symbol is very common and very distinct. I don't think it's reasonable to expect people to understand the compact mode and icon mode icons without looking at the tooltip.
I think the Sort By button should also be on the left.
If a Create New button is also added after more discussion, I think it should also be on the left.
Did you read my comments about the view mode button?
In D7446#505870, @ngraham wrote:ut I am all ears for inputs.Right now by default we only show two: "today" and "last month". We should probably keep it at that, at most; my sense is that even these are very infrequently used. Sometimes I wonder if they should even be on the placed panel by default at all. Especially once your new recentlyused:/ ioslave is merged, it's so good that it will obviate the need for the "today" one, at the minimum.
In D23075#510675, @ndavis wrote:In D23075#510674, @GB_2 wrote:I think the view mode buttons should be replaced by the single View Mode menu button. Unlabelled icons are a bad idea unless the symbol is very common and very distinct. I don't think it's reasonable to expect people to understand the compact mode and icon mode icons without looking at the tooltip.
I think the Sort By button should also be on the left.
If a Create New button is also added after more discussion, I think it should also be on the left.
In D23075#510675, @ndavis wrote:In D23075#510674, @GB_2 wrote:I think the view mode buttons should be replace by the single View Mode menu button. Unlabelled icons are a bad idea unless the symbol is very common and very distinct.
In D23075#510674, @GB_2 wrote:
Is this better?
In D23075#510022, @felixernst wrote:In D23075#509940, @ndavis wrote:Make sure the default layout doesn't look lopsided when the application menu is enabled instead of the control button.
It does look kinda lopsided but I am not sure if it is worth it to change the default look because of that.
In D23075#510484, @ngraham wrote:They are enabled by default.
Aug 11 2019
CamelCase two variables, correct a getter
They are enabled by default.
We should probably keep the show preview button unless we want to enable previews by default.
In D22420#503573, @AndreyYashkin wrote:In D22420#503317, @elvisangelaccio wrote:I'd still like to understand what happend at the change in 4e40fe810d324.
@ngraham Any idea?
@elvisangelaccio, I read the description of change in 4e40fe810d324 and bug 298467, which was fixed in it more carefull and understood that the change was supposed to introduce the feature of setting the focus back to the active view. However, it seems that Ctrl-D or exit command cases were not tested good enough.
Can't test, but looks sane to me. I have a small comment, but can be left for later if time is of the essence.
Aug 10 2019
LGTM. Let's make sure Dolphin's maintainer @elvisangelaccio is good with it too!
In D23075#510022, @felixernst wrote:There wasn't much discussion about using the view mode button in the VDG:
<thavn> perhaps we should consider which buttons have labels and which are just the icon as well...
<noahdvs> I find it odd that we use icons with no labels for the different views
<noahdvs> Maybe we should switch them for the View Mode toolbutton?I think the biggest reason for it is that the label makes it clear that these buttons change the view mode. Clicking it also shows the names of the three different view modes so users can decide by the names and not just by the icons. It also teaches the user the shortcuts for them.
I think it looks better with the view mode button.In D23075#509940, @ndavis wrote:Make sure the default layout doesn't look lopsided when the application menu is enabled instead of the control button.
It does look kinda lopsided but I am not sure if it is worth it to change the default look because of that.
There wasn't much discussion about using the view mode button in the VDG:
Use three individual view mode buttons
In D23075#510015, @ngraham wrote:You don't necessarily have to, I just wanted to start a conversation about it. :) I do like the symmetry of the actions on the periphery being icons-only and the ones in the middle having icons.
You don't necessarily have to, I just wanted to start a conversation about it. :) I do like the symmetry of the actions on the periphery being icons-only and the ones in the middle having icons.
In D23075#509997, @ngraham wrote:This looks great to me now. Testing it out, the new layout feels much nicer:
However I have one hesitation regarding replacing the three individual view mode buttons with a drop-down menu button. It feels like an unnecessary change. I'm not against it, but I also don't see a particularly strong reason for it either. Can you explain your reasoning for this?
In the file dolphinmainwindow.cpp i changed m_controlButton->setToolTip(i18nc("@action", "Menu")); to m_controlButton->setToolTip(i18nc("@action", "Show menu"));
Don't forget about the other inline comment too. :) You can also mark the comments as done and then hit Submit to mark them as done.
Update the CMakeLists.txt File, i changed 5.61 to 5.61.0
Make sure the default layout doesn't look lopsided when the application menu is enabled instead of the control button.
+1, I love it. I would even add New Folder or Create New to the toolbar as well, but that's just me.
Aug 9 2019
Regarding qobject_cast this is the error I get:
Aug 8 2019
I'm good with the UI and functionality now. I'll let others take over for the rest of the code review and let Dolphin's maintainer @elvisangelaccio make the call regarding whether we should add the feature or not. Having used it now, I'm in favor because it has the potential to be an explosively powerful feature for power users and a major draw for the software among this crowd. But since it's hidden away on the Navigation page, I don't think it adds a lot of UI complexity for regular users.
change label text
There we go, now the action triggers instantly. Looking better!
I apologize for going dark on this. To be honest I feel a bit out of my technical depth here and I think you should either find someone else who knows the code better or proceed according to your own instincts. :)
I think I would prefer a mime type check over a endsWith(.flatpakref) but that would introduce some overhead, so I guess this is fine.
Hehe I was working on a patch for this too and your patch is almost identical. :)
check parent() against nullptr, use static_cast when getting the DolphinMainWindow
@ngraham - Hey Nate, if you have time I would like to pick this patch up again, what are your thoughts on how we progress this? Currently this patch depends on D20867 being merged and released and also a change to KWidgetAddons (F6773036), so one approach could be to focus the review effort on those changes first? We have previously discussed various ways to simplify this change, but no other suitable solutions has been found, but I am still open to simpler solutions :)
Aug 7 2019
Ping?
make requested changes and some cleanup
Use NOT VERSION_LESS instead to minimize the patch.
ping @elvisangelaccio
Aug 6 2019
Aug 5 2019
The actions in the current patch were a few I selected for showcase.
These are the actions I think are useful to have for the double click:
"file_new" "New &Window" "new_tab" "New Tab" "edit_paste" "Paste Clipboard Contents..." "edit_find" "&Find..." "edit_select_all" "Select &All" "split_view" "Split" "editable_location" "Editable Location" "replace_location" "Replace Location" "go_back" "&Back" "go_up" "&Up" "go_home" "&Home" "show_filter_bar" "Show Filter Bar" "open_terminal" "Open Terminal" "create_dir" "Create Folder..." "show_preview" "Preview" "show_in_groups" "Show in Groups" "show_hidden_files" "Hidden Files" "view_properties" "Adjust View Properties..." "show_terminal_panel" "Terminal"
Thoughts?
@ngraham Do you think it still fits better in the Navigation page?
Aug 4 2019
In D20532#506590, @fbg13 wrote:The alternatives I found are:
(DolphinMainWindow *)QApplication::activeWindow();
In D20532#506470, @ngraham wrote:Finally, it feels quite slow. When I double-click, there's a noticeable delay before the action gets executed. Maybe this is because of all the scanning widgets to find the main window? That doesn't feel like the correct approach, just browsing the diff.
For me there is no delay, but I also don't like the loop. The alternatives I found are: