GNOME Bugzilla – Bug 94618
No way to get contextmenu for current folder in list view
Last modified: 2016-12-01 22:05:55 UTC
See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=73679
*** Bug 96294 has been marked as a duplicate of this bug. ***
this is tricky...not quite sure what do here. Other ui people any ideas?
I think what can be done is making only right clicking the filename icon selects the file, other than that no file is selected, just like Konqueror.
Ok, so I had a look at how XP and OSX get around this. - Windows: the list view always leaves a blank row at the bottom that you can right-click in (although this may mean you have to scroll to get to it, of course). Also, in a Windows list view, only the first column is clickable anyway, so all the other columns are essentially the 'background'. - Mac: any white space in the list view is treated as the background. That is, to activate the context menu for a particular item in the list, you actually have to right-click within the bounds of an icon or a piece of text in that row. Otherwise you get the background context menu.
Isn't this bug more accurately described as "Now way to get context menu for current folder in list view"?
Yep, changing summary and adding a couple of keywords.
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
*** Bug 124423 has been marked as a duplicate of this bug. ***
Adding GNOMEVER2.4, GNOMEVER2.5 keywords.
I think many users try to right-click in the white space below the last file. Making the context menu appear when doing so would be a huge step forward.
*** Bug 127888 has been marked as a duplicate of this bug. ***
As a side effect, it is not possible to create a new folder in "View as List", as the only context menu that appears is related to the the selected file !!! This is very inconveniant.
*** Bug 110126 has been marked as a duplicate of this bug. ***
Created attachment 22623 [details] [review] Proposed patch. Makes List View behave like WinXP.
Thank you very much for your nice Nautilus patches Christian! Alexander Larsson is currently on vacation, but I hope that when he comes back he will look at your patches and apply as many as possible. Thanks once again for looking at these issues!
Ok, i commited that patch. However, that is not a full solution, as it only works if the window is larger than the list. We should probably go with the XP way of keeping an empty row at the bottom.
patch was committed, removing PATCH keyword.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
*** Bug 306413 has been marked as a duplicate of this bug. ***
Created attachment 49396 [details] [review] Proposed patch against HEAD This patch makes Nautilus treat clicks on other columns than the current sort column as clicks on the background. I'm also working on rubberband-ish selection but some GtkTreeView internals make this a bit tricky.
> This patch makes Nautilus treat clicks on other columns than the current > sort column as clicks on the background. That doesn't sound like a good thing to me, if I understand your description correctly. Since the whole row is highlighted to show selection, I'd expect clicking to behave the same regardless of the position in the row at which I clicked. (Note that in the MS Windows list view, only the filename column is ever highlighted to show selection, so having the rest of the row act as the background is a little more natural... but not having full row highlighting has always annoyed me more than the convenience of having the rest of the row behave the same as the background...)
Created attachment 49599 [details] mock up for making the "parent folders"-button behave like background i had this idea and build a mock up, i hope it is possible with gtk and you like it. What if we used the right click on a the small "parent folders"-button to show the folder-context-menu? To make this unique in browser and spacial mode, add the "parent folders"-button to the browser too - usefull anyway. another idea would be: making it possible to drop on the button - that would be consistent to the right-click as it behaves like the clean background then.
From comment 22: > i had this idea and build a mock up, i hope it is possible with gtk and you like it. You should really check out Nautilus 2.11. We have this :). > another idea would be: making it possible to drop on the button Works also in Nautilus 2.11. The context menu is stripped down, you won't be able to create folders for instance - but you can do some basic modifications (inter alia cut/copy/paste/properties)
OK, but remember that the main purpose of this bug is to get _programmatic_ access to the context menus, i.e. from API inside the application. This is needed for accessibility, so that onscreen keyboards etc. can find, enumerate, and activate all context menus that are available to a mouse user.
Bill: How are these registered in our usability framework? Maybe you could point us to some docs? The API for this is fm_directory_view_pop_up_background_context_menu btw.
Hi Christian - I don't understand your question, so perhaps you can point me to what you mean by 'our usability framework', and I'll try to reply. Basically we need: 1) to detect when/if a context menu is available, and what object it's associated with (i.e. what's its "parent"); 2) to be able to invoke that menu (which I think fm_directory_view_pop_up... does) 3) ideally, to be able to list the menu's items without actually popping it up. That's probably the harder task.
Sorry, I was actually referring to the accessibility framework. My question was more of: How do atk and friends know which menus are around and how they can be popped up? Do we have to advertize this somehow within Nautilus using the ATK API?
Hi Christian - I understand your question better now I think. Menus generally fall into two types: 'normal' menus that are visible to the user are detected by assistive technologies via ATK_ROLE_MENU. This role is set by the ATK implementation for the appropriate GtkWidget type, for instance GtkMenus items have ATK_ROLE_MENU, and their children have ATK_ROLE_MENU (for sub menus) or ATK_ROLE_MENU_ITEM. The second type of menus are 'context' or 'popup' menus. In some cases these menus don't even exist (i.e. their widgets don't exist) until/unless they are invoked, so ATK cannot detect them by their widget types and cannot advertise them as ATK_ROLE_MENU if they don't yet exist. In these cases, the fact that a particular item has a popup/context menu is something that the ATK/gail code needs to know from prior knowledge about the widgets - in other words, ATK needs some api like fm_directory_view_pop_up or similar, to let it know that there is a context menu available. Once ATK/gail is aware of the presence of a popup menu, it exposes this fact to ATs by making sure that the object which has a context menu implements AtkAction, and adding an AtkAction (usually called 'popup' or 'menu') to the list of available actions. So: 1) AT notices that an object implements AtkAction; 2) AT finds an action named 'menu' or 'popup'; 3) AT knows that there is a context menu available. From there, the AT needs the ability to either list the items in the menu and activate them (without actually popping up the menu), or it needs the ability to programmatically pop up the menu. Once the menu is popped up, it should appear as a ATK_ROLE_MENU item with ATK_ROLE_MENU_ITEM/ATK_ROLE_MENU children, either as a child of the object to which the popup 'belongs', or as a separate toplevel ATK_ROLE_FRAME with menus/items inside it, which has ATK_RELATION_POPUP_FOR pointing to the item that the context menu applies to.
To clarify the last part of my comment, when I say "AT" I am referring to assistive technologies that are clients of AT-SPI/ATK. So ATK needs to be able to detect the presence of an available context menu, and to be able to post it or at least query and activate it, in order to provide the interfaces that the AT needs.
As a point, even if we dont get the whole context menu, I beleive the following items shoudl be available from whatever you click on - New Folder - Paste Paste shoudl probably be called "Paste into current folder", along side "Paste into thsi folder" And new folder could be the same, these seem to be the most common operations that bite me in these cases.
Maybe we should add folder context menu to the pathbar element buttons.
Vidar: This is covered by bug 309844.
Updating bug information.
Created attachment 51911 [details] [review] Proposed patch #2 against HEAD OK, this one considers the first visible column instead of the sort column as file representation.
was this patch misplaced? Or has this bug just morphed into something entirely different from the summary?
Short summary: We discussed multiple ways of resolving the issue "No way to get contextmenu for current folder in list view". Treating clicks to other columns than the "Name" column as background clicks enables the user to do this and proves to be useful for other things (lasso selection, for instance). And there are some comments requesting random unrelated feaure additions as well; just ignore them for now :).
FWIW, I still don't like the idea of considering any one column as 'the file' and the others as 'the background'... like the Mac (and unlike Windows), our selection indicator correctly spans the whole width of the list, so I really believe we need to continue considering any part of the row that's highlighted to count as 'the file'.
Call me insane, but how about... The top folder in the list view is the current folder (as in .)! everything below is indented much like it is with the new tree view in Nautilus 2.12. **** This means we can rename, open properties and set permissions on the current folder with list view! **** (And, of course, you can drop files onto it to drop into the current folder!) I suddenly really like this idea, it may be a bit novel but it will solve all the problems... Alex
Mass changing Nautilus version for bugs that have GNOME 2.13 version info.
Agree with the approach laid out by Christian in comment #36. I understand the inherent logic in having the selection indicator span the entire row. But usability matters, too. I miss not being able to get the context menu or use lasso selection. It hurts the usefulness of the list view. Hey, if was a designing a car exterior, I'd want long, sleek, unbroken lines. But unfortunately, I have to put a couple doors in there someplace, know what I mean?
Well, in that case we should look into doing it how the Mac does it... treating any 'empty' part of a row, selected or otherwise, as the window background. Then if you want to select a row by clicking, you have to actually click on some text or an icon in that row... which users naturally do anyway.
*** Bug 336196 has been marked as a duplicate of this bug. ***
There is a patch for this issue! please commit! I'm really missing "Lasso Select" and "Open In Terminal" in List View! :) thanks!
Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.
Mentioned in https://launchpad.net/products/nautilus/+bug/51043 as well.
*** Bug 354763 has been marked as a duplicate of this bug. ***
Put the current folder's context menu into the window "File" menu. It makes perfect sense.
It's a 4 years old bug, there are better ideas in this discussion than moving the folders context menu into the "File" menu. btw, my bug was redirected here, because you can't lasso-select multiple files in list-view - which wouldn't be fixed if you just move the context menu. Fixing it (finally:) would increase usability of lisview vastly!
See a related proposal in http://bugzilla.gnome.org/show_bug.cgi?id=326171#c5 - it is to add some commands to the context menu for files, and to make it clear that those commands refer to the enclosing folder, not to the selected files.
Federico: IMHO your proposal is not as good as some others already made here. Additional entries would clutter the context menu and make cut/copy/paste operations more error prone. (Besides, this would not solve the lassoing problem.) Personally, I like the Win-Explorer behaviour the most (i.e. making the right columns behave like the background), as this solves both the context menu problem and the lassoing problem. But there seem to be some strong opinions against such a solution, so how about simply adding one empty (i.e. white) row to the end of the treeview and making it behave like the current folder?
Created attachment 88648 [details] [review] change the right click behavior to solve the bug The present right-click do the following things: choose the row and popup a menu. I change it to: donnot choose the row, the only way to choose the row is by left-click. if the row you right-clicked was just the row you choosed, the menu popuped will get the function of "open the folder" and the etc. But if the row you right-click was not the one you choosed, the menu popuped will get the function of "create folder" and the etc. I think it is the easyest way to solve the bug.
I've tested David's patch and it actually works very nicely. It's also harder to screw up your carefully-built selection by right-clicking in the wrong spot :)
David, can you please mail nautilus-list and request patch review for this bug?
*** Bug 314547 has been marked as a duplicate of this bug. ***
Still valid, modifying fields.
*** Bug 530332 has been marked as a duplicate of this bug. ***
We need better GtkTreeView selection interaction before this can be properly solved. I posted an email to gtk-devel-list about this issue around a month ago: http://mail.gnome.org/archives/gtk-devel-list/2008-April/msg00036.html
*** Bug 534588 has been marked as a duplicate of this bug. ***
*** Bug 535682 has been marked as a duplicate of this bug. ***
*** Bug 536593 has been marked as a duplicate of this bug. ***
Setting priority to high, as we get a lot of duplicates for this.
The solution in comment #51 comes from https://bugzilla.novell.com/show_bug.cgi?id=5322
Sorry if this was already brought up, but how about just adding a blank space at the left, where you can start a rubberband or right-click?
Created attachment 112192 [details] A quick mockup
The related patches in https://bugzilla.novell.com/show_bug.cgi?id=5322) change the current list view behaviors like these: It differents the file-name column with other columns: if the user right clicked on the file-name column, it will popup the original menu. if the user right clicked on another column, the popup menu will be the same with the one we right clicked on the blank ground space. I think it will solve the problem in an eazy way. We need not to add extra blank widget to either the button place or the left place. Moreover, we can implement the feature (select multi-files by mouse choose only) by differenting the file-name column with other columns: if the user left clicked on the file-name column and then drag the mouse, the selected file will be moved to the target directory (current behavior). if the user left clicked on another column (or the blanck space) then drag the mouse, the files dragged over by the mouse will be selected.
Yes, the way clicking on any other area as the file-name colum to show the folder context-menu is the way the most systems use and the most user knows. way develop a way the user don't know when there is a way everybody knows.
Created attachment 112197 [details] [review] patch can be applied in nautilus-2.22.2 change the src/file-manager/fm-list-view.c
i think this is the best solution to this problem. the only thing which would make it even nicer (imho) is if it would be possible to not only check for the file-name column, but actually for the file name itself, i.e. the characters of the name. so for example when you have files "a" and "bbbbbbbbbbb" and click right next to the "a" but still in the first column, the file wouldn't get selected which would make the behaviour more like icon view and the upcoming compact list view where you only select things by either clicking directly on the icon or the file name but not next to either of them. but i guess this would be a bit more difficult than the current patch.
Something else that I'd like to bring up that's directly related to this issue, but doesn't seem to be addressed: As a result of the whole surface of a list being a click target, there's no way to drag files to the folder itself if its display is filled with a list of folders. You have to scroll to find a file (since dropping on a line showing a file will make the containing folder the target), open the window larger to get some space (if possible), or navigate to the parent folder to use the folder as a target. None of these are really good in daily use. I think it's important to remember this when proposing solutions. It's not just "find a bit of extra space to click on". It's about creating a large, and obvious, target area for operations on the folder, not just its contents.
I'm not sure how to add an attachement, so I'm using mediafire.com to add imagery of what the file selection process looks like in Windows XP. http://download339.mediafire.com/kaxdojeddewg/nyzjynqni02/windows_xp-file_selection-details.png If someone can, please attach it via their post as I'm unsure how long this image will stay hosted.
Created attachment 114448 [details] Windows XP file selection when using 'show details' Here is the attachment. Apologizes for my ignorance.
After all those years this bug still isn't fixed. Could you please fix this bug?
*** Bug 566474 has been marked as a duplicate of this bug. ***
Created attachment 127991 [details] [review] patch from comment 67, updated This patch is the same as David's Liang's patch in comment #67, updated to the latest SVN (actually the git repo, which I'm assuming is kept up to date). Please, please, please consider applying this patch. It does not break anything, and this is a *huge* issue for many people migrating from windows. List view is seriously gimped in it's current state. This patch accomplishes the following: 1. right click brings up current folder's context menu unless it is on the filename column (as opposed to the current behavior of bringing up the context menu for the file in that row) 2. left clicking to select follows the same rules as right clicking, allowing us to drag the mouse for multiple file selection Not being able to get the context menu for the current folder or select multiple files with the mouse are huge usability problems IMHO, as well as the opinions of many people (see comments at http://brainstorm.ubuntu.com/idea/16535/). Let's get this fixed.
(In reply to comment #74) > Created an attachment (id=127991) [edit] > patch from comment 67, updated > > This patch is the same as David's Liang's patch in comment #67, updated to the > latest SVN (actually the git repo, which I'm assuming is kept up to date). Very cool, I too hope this can be included. As I mentioned in comment 69, there is the additional issue of drag target. Larry's patch would correct the mouse drag and right-click target, which is a great start. But there is still the issue of no space where the user can drop a file or folder in the case of a window full of folders in list view. Larry, someone else: are you up to tackling this too? :-)
I might be able to get to it eventually, but don't hold your breath... I'm working 50-60 hours a week right now :-/.
(In reply to comment #76) > I might be able to get to it eventually, but don't hold your breath... I'm > working 50-60 hours a week right now :-/. I've been there, I understand! In any case, thanks for the work so far. Crossing my fingers that it'll be reviewed and make it into 2.28 (since 2.26 is already in UI freeze).
(In reply to comment #74) > Created an attachment (id=127991) [edit] > patch from comment 67, updated > This is really a major improvement for people who use list view. It should definitely be part of Nautilus. Thanks Larry
Created attachment 131001 [details] nautilus context menu in list view windows way this is the windows way i think. just for illustration. to select a folder/file you have to select the icon or name (boxes), everything else would be like clicking into free space (which is not there if the list view covers the whole window). so you could also move/copy into a folder in list view (and not into a subfolder because it gets selected)
It's ridiculous List View never worked in Nautilus and no effort was taken to fix this misbehavior. Fortunately Larry fixed List View. Can you please implement Larry's patch in the upcoming release of Nautilus?
Any news? Will this ever be fixed?
Actually maintainers prefer having the patch to be sent to the nautilus mailing-list.
Can somebody do this? I don't know how to sent a patch to the Nautilus mailing list.
Quick pass over the latest patch says it still needs some work before we could accept it (though I'm not sure if behaviorally it's right). + +/* add the following members to realize the function of choosing files by mouse only action*/ + Be more to-the-point here or leave the comment out altogether. + if (view->details->start_path == NULL) + view->details->start_path = path; Nautilus' coding style puts brackets around the body of if statements. if (something) { do_something (); } Lots of those to fix. + /*leave the shift and control key press the default function*/ + gboolean is_filename_col_selected = TRUE; We don't declare variables in the middle of blocks, and we don't set them when we declare them. + view->details->start_y = event->y; Spacing should be: widget->details->variable = new_val; Don't add extra spaces to even out lines. Lots of these to fix too. We also have a large number of gbooleans in that struct, might be better to change them to a bitfield instead.
More than 7 years since this bug was first reported, and the only thing to do is make background clickable when Nautilus is in listview mode. Home users maybe don't feel affected by this problem, but enterprise users are! How can Gnome substitute Windows in enterprise environment if a single correction like that take such a long time to be implemented? Thank you!
*** Bug 599303 has been marked as a duplicate of this bug. ***
A possible solution for this problem could be create a new ListView component in GTK with a different behavior in relation to clicks. The only clickable column would be the first one, the rest would be transparent to mouse clicks. In addition, some small improvements could also be made, like turn the line height smaller, turn the icon image smaller and improve the column width resize.
No answers to posts, no new opinions, no discussions, nothing!! It seems that the Gnome team gave up on solving the nautilus bugs and this explains the status "new" in a 7 years old bug. Why?
(In reply to comment #88) > No answers to posts, no new opinions, no discussions, nothing!! > It seems that the Gnome team gave up on solving the nautilus bugs and this > explains the status "new" in a 7 years old bug. > Why? Because they don't care about fixing bugs. They only care about adding new features like Gnome Shell and Gnome Zeigeist.
I was debugging Nautilus code and my conclusion is that the problem is in GTK treeview widget, not in Nautilus itself. It would be needed modify "gtk_tree_view_get_path_at_pos" function to return FALSE when mouse rightclick is not over the first column, so Nautilus would understand that background was clicked. The problem is that change GTK Treeview Widget is infeasible, because it will affect many other programs. The only way I see is create another GTK widget component with a different behavior on right clicks and modify Nautilus to use it instead of Treeview. Unfortunately it is more than I can do. Can somebody help me?
bug 554229 comment 5 suggests new function gtk_tree_view_column_set_activatable(). That could help not only with my problem in this bug, but it will also make possible to implement behavior proposed here.
Your idea seems very good, avoid the need of a new widget and keeps compatibility with every program that uses Tree View. It doesn't seem to be complicated to implement.
*** Bug 601115 has been marked as a duplicate of this bug. ***
Yeah, another duplicate. That makes duplicate number 368. According to Wikipedia Nautilus was first released on March 13th 2001. I don't know if this version already had List View, but I think List View was introduced about 18 months later, because at that time the reports of this bug started to show up. Nautilus was only 18 months old when this bug was reported (that means: it's the oldest bug report of this bug I was could find). Now it's November 2009 and Nautilus is now 104 months olds. In this time span this bug has been reported at several places, like Gnome's Bugzilla, Red Hats Bugzilla, Novells Bugzilla, Ubuntu's Launchpad and at bug reporting systems of... well almost every other distribution or Linux related company or website that has a bug reporting system and to make it even worse: all those bug reports have several duplicates. It's insane how many times this bug has been reported and it's ridiculous this bug still hasn't been fixed, because it's one of those fundamental functions of a file manager. Hello developers of Nautilus!!! What's going on in your minds??? A bug showed up when Nautilus was only 18 months old, the bug has been reported an insane number of times and now, when Nautilus is ONE HUNDRED AND FOUR MONTHS OLD!!! this bug still isn't fixed, while it's a fundamental function of a file manager. You guys have lost your mind. Why do you think Linux has such low marketing share? How in the name of [The name of who? I don't care. Just insert a name.] can someone take you and Linux serious? Linux is free (Well, in most cases. I really don't understand those companies who are asking money for such bugged product!) and is developed by amateurs. There's no one above them telling them what to do. Well, it shows! What Linux needs is a big company with a lot of professional and payed employees and a person who's able to lead such company. Only then will Linux have a chance on the desktop. Only then will Linux be able to stand in line with Windows and Mac OS. But Linux isn't developed by a company like Microsoft or Apple, so we can only hope someday the developers of Linux (Yes, it's not only you, developers of Nautilus, I see the same behavior everywhere in Linux) will start to use their brains: Fix those 10 years old bugs, instead of developing one new feature after the other without ever reaching v1.0 status. All those applications in Linux: v0.2, v0.0.8, v0.4.2, v0.5.1, v0.3.1.2, v0.1, v0.2.3, v0.8, v0.3.2. When do those applications finally reach v1.0? In many cases they'll never reach v1.0, because its developers have started another project which is now at v0.0.8.
(In reply to comment #94) > > Hello developers of Nautilus!!! What's going on in your minds??? Hi Robert, Don't be shy and show us your code. You have time to write lenghty complains, so I guess you have also time to write code, and it would be more useful to fix the bug. Cheers.
robbertvandendoorn@hotmail.com: Robert, 6 comments of absolutely no technical value (and that's just in this bug). Consider this your last warning because your account gets blocked off.
Ok, returning to the subject... I think that a simple change in GTK Tree View Widget will solve our problem, maintaining 100% compatibility with every program that uses it. Summary of changes to be implemented (only 4 steps): 1. Create a gboolean array "transparent_to_rclicks[]" in gtk treeview widget The array elements are related to the columns in tree view. The default values for all of them are FALSE; 2. Create a method to change "transparent_to_rclicks[]" array values. Something like this: void function gtk_tree_view_column_set_rclicktransparent(int ncol, gboolean newval) {transparent_to_rclicks[ncol]=newval;} 3. Modify gtk_tree_view_get_path_at_pos method We need to return FALSE when mouse rightclick event occurs over a column "ncol" having transparent_to_rclicks[ncol]==TRUE. Something like this: if (transparent_to_rclicks[ncol]) { return FALSE; } else { //existing code ... } 4. Modify Nautilus to call gtk_tree_view_column_set_rclicktransparent(ncol, TRUE) on for each column > 0 in Tree View Widget. I really would appreciate suggestions, comments, criticism or something else. Thank you.
About 3: The current 'FALSE' value returned from gtk_tree_view_get_path_at_pos means there is no row exist at the coordinate. So, if the rclocks[ncol] was set to TRUE, it is fine when the user right click on the column, but how about left click on that? And I don't think we should add some 'rclick' logical codes to 'gtk_tree_view_get_path_at_pos'. It makes no sense.
About 1 & 2: If there would be a gtk_tree_view_column_set_rclicktransparent function, should gtk_tree_view_column_set_lclicktransparent or gtk_tree_view_column_set_mclicktransparent also be added accordingly? I think these maybe better to be implemented in the applications but not the gtk libs. What is your opinion, Walter?
David, Thank you very much for your reply. Yes, you're absolutely right, gtk_tree_view_get_path_at_pos function shall not be changed, I made a mistake. In the other hand, is difficult for the application know over which column or content type mouse pointer is, in order to decide if an item was clicked or the background. It should be too much easier if there were a method in treeview to return this additional information: what is effectively under mouse coords now? Analyzing Windows Explorer behavior, right clicks on blank areas, even in the first column, are treated different from right clicks over "texted" areas. If there were a method in treeview object that could answer this, it would be easy for the application take the decision of selecting item first or not. This method could be "gtk_tree_view_is_blank_at_pos" returning TRUE or FALSE. What is your opinion, David?
Agree. It will be too mush easier. To implement it, GtkCellRendererClass should add a method like 'is_blank_at_pos' and the sub-cellrenders like gtkcellrenderertext (for this bug, it is) should also implement this if needed.
Ok, we have a consensus until now! If the solution is technically feasible and it is the easiest method, I think we should follow this way. Any other suggestion? Could somebody divide the work into tasks?
David, I really can't gauge the breadth and depth of changes in the GTK libraries, I have a limited view of this project. Maybe you could present us a suggestion about the tasks that should be performed in order to create "is_blank_at_pos" method in treeview and listview classes. Is it possible? Well, the problem can be organized as follows: 1. Implement is_blank_at_pos method in treeview and listview classes (I thing that both classes should have the same features) => Please, David or somebody else divide it into single steps. 2. Modify fm-list-view.c source code => On button_press_callback function, call treeview "is_blank_at_pos" method to decide if r-click occurred over background or over an item. It shall be considered background only if a blank position of a non-selected item is r-clicked. 3. Debug everything 4. Assign "Solved" to bug status.
(In reply to comment #95) > (In reply to comment #94) > > > > Hello developers of Nautilus!!! What's going on in your minds??? > > Hi Robert, > > Don't be shy and show us your code. You have time to write lenghty complains, > so I guess you have also time to write code, and it would be more useful to fix > the bug. > > Cheers. There we go again. When does this "show us your code" stop? I'd really like to fix this problem, but I'm not a programmer. Why do people at Bugzilla (not only Gnomes, but also other Bugzilla-pages) always think everybody is a programmer? Not everyone knows how to program. I know how to build a computer. If I build a computer and it doesn't work and someone complains, do you really think I'm going to say: "Then show me how to build a computer." That person doesn't know how to build a computer, so he let me build his computer. If the computer I build for him doesn't work he has the right to come to me and complain. I'm the one who's responsible for fixing the computer. I can't expect he fixes the problem hisself. I can't expect he knows how to fix the errors I made. I can't expect he's able to build a computer. I'm the one who knows how to build a computer and I'm the one who is able to fix it. I'm not going to ask customers to show me how to fix my errors. Why do people at Bugzilla-pages always think everyone knows how to program? I don't know how to do it. If I knew how to do it, I'd join you all and I'd write the code to fix this and other bugs. Everytime I read "show us your code", but not everyone is a programmer. One person is good at writing code, another person knows how to build a computer and yet another person is able to repair a car. Not everyone knows how to program, not everyone knows how to build a computer and not everyone knows how to repair a car. I know how to build a computer, but I don't know how to program and I'm not able to repair a car. Lucky enough other people can do this for me, like I can build computers for people who don't know how to build a computer. But if these people haven't fixed their product after seven years, they still say I have to show them the code to fix the bug. Do you think someone is going to buy a computer from me if I still haven't fixed the computer I delivered seven years ago and eventually tell them they have to show me how to fix their computer? Let's repeat it again: I'd love to help you all with writing code to fix this bug and other bugs, but I'm not a programmer. I'm just not able to write code. And you're right, I've got time enough to write code. But I don't have the skills to write code.
(In reply to comment #104) > Let's repeat it again: I'd love to help you all robbertvandendoorn@hotmail.com : So far in this report you just wasted the time of may folks by whining and adding comments that have no value at all. You DO NOT help with this. Understand it. If you insist on "My bug report is the most important one and all developers must do this first and I cannot understand how they ever could have set different priorities because open source must have unlimited manpower because I believe in it", please get a support contract with a Linux distributor, pay for it, and ask them to write your code. For further unuseful comments the GNOME Bugsquad might disable your account without further warning. Thanks for your understanding.
Created attachment 147895 [details] Changes on fm-list-view.c, button_press_callback function, to correct the bug I think that this modification in fm-list-view.c may correct the bug, but it depends on gtk_tree_view_is_blank_at_pos function to work. The missing function must return TRUE if the position pointed by x, y coords is over a blank area in TreeView or FALSE if not. Can somebody help me writing gtk_tree_view_is_blank_at_pos function??
Created attachment 147896 [details] Small correction, same description of previous attachment Waiting for help!
(In reply to comment #105) > For further unuseful comments the GNOME Bugsquad might disable your account > without further warning. done Productive comments etc are welcome. But everyone understands every bug should be fixed.
I'm wondering why in this forum complaints are replied so quickly, as technical messages are sometimes ignored. I attached a new source code for fm-list-view.c, which may solve this bug, but depends on gtk_tree_view_is_blank_at_pos function to work. This function is a suggested new method for treeview GTK Widget, which should be implemented preferably by GTK team, for obvious reasons. I'll be grateful if someone can comment, criticize, praise or anything else about my suggestion, but contempt is the only thing that I was not expecting in this case. Thank you.
(In reply to comment #109) > I'm wondering why in this forum complaints are replied so quickly, as technical > messages are sometimes ignored. This isn't a forum, it's a bugzilla. Did you create a bug about your problem with your gtk_tree_view_is_blank_at_pos() problem? Did you make it block this bug? Seems like neither. Furthermore, did you discuss how this bug should be solved on the nautilus mailing-list? Are you sure that the effort you're putting into fixing this problem are actually getting this problem fixed in a way that would be accepted by the maintainers? This is the sort of questions you should ask yourself before making the sort of comments you made on this buzgilla. FWIW, I think that the drop-down menu at the bottom left of the nautilus windows should be made draggable as "the current folder" (and possibly an icon that would live in the title bar, but that's harder).
Create a bug about my problem with gtk_tree_view_is_blank_at_pos()? I'm a little confused about it, because this function even does not exist! please help me on understanding this point. I think that the way how bugs must be solved should be discussed in bugzilla, so I'm posting here my suggestion. Am I in the wrong place? I don't know if my suggestion will or will not be accepted by maintainers. But I'd like to know, so I submitted my source code. I often read here: "don't be shy, show us your code". Ok, here it is. Now I ask: guys, did you like it? Is it a good suggestion? Can it be accepted by gnome team? No?? please tell me the reasons! Let's discuss the problem technically! Can somebody say something? Please! Bastien, I never got involved in open source projects before and I'm just trying to solve a very inconvenient bug that persists in gnome for more than 8 years, and for what, I think, the maintainers are not motivated. I realized that I should make more than claim. I'm trying.
(In reply to comment #111) > Create a bug about my problem with gtk_tree_view_is_blank_at_pos()? > I'm a little confused about it, because this function even does not exist! > please help me on understanding this point. Yes, please file a bug against the gtk+ component requesting the addition of this function. Set that bug as blocking this one. Explain the reason the new function is needed, giving this as an example. > > I think that the way how bugs must be solved should be discussed in bugzilla, > so I'm posting here my suggestion. Am I in the wrong place? > > I don't know if my suggestion will or will not be accepted by maintainers. But > I'd like to know, so I submitted my source code. I often read here: "don't be > shy, show us your code". Ok, here it is. > Now I ask: guys, did you like it? Is it a good suggestion? Can it be accepted > by gnome team? No?? please tell me the reasons! Let's discuss the problem > technically! Can somebody say something? Please! While I can't speak for the maintainers, by your own admission you solution requires changes to Gtk+. Assuming your solution is the correct one, nothing can be done until these Gtk+ changes have been made.
*** Bug 616226 has been marked as a duplicate of this bug. ***
*** Bug 617400 has been marked as a duplicate of this bug. ***
*** Bug 622942 has been marked as a duplicate of this bug. ***
Depends on bug 350618
*** Bug 385763 has been marked as a duplicate of this bug. ***
Hey, guys! Good news! I think we already have all we need to solve this old and inconvenient bug. Function "gtk_tree_view_is_blank_at_pos()" was created in GTK+ TreeView component by Kristian Rietveld, after our suggestion. Thus, bug 350618, which one our bug was dependent, is supposed to be solved and we are about to be able to access context menu in current folder in Nautilus. Now we have to make small (I suppose) modifications in Nautilus source code to take advantage of this method in TreeView. Well, based on an old version of the source code, downloaded at a time when I had time to debug programs, I believe I have located one of the points that must be changed. The modified code is here: https://bugzilla.gnome.org/attachment.cgi?id=147896. Certainly we still need to manage the rubber banding, which was not handled. Can somebody help me?
Nautilus 3.1.4, which is present in Ubuntu 11.10, has a new interface that facilitates the implementation of this new functionality. The first column in treeview looks different from the others, which favors the new behavior enough.
*** Bug 410766 has been marked as a duplicate of this bug. ***
Created attachment 203262 [details] [review] Implement gtk_tree_view_blank_at_pos to show background folder menu on blank spaces Patch implementing the new treeview api to solve this bug, but attending to nested elements (those shown behind another folder) which do not show the folder background menu because it would confuse users as the menu shown is not of that folder but the folder of the current view. As a next step we could try to make those blank space clicks on nested folders to show the background menu for *that* folder.. what do you think about it?
(In reply to comment #121) > Created an attachment (id=203262) [details] [review] > Implement gtk_tree_view_blank_at_pos to show background folder menu on blank > spaces Thanks for the patch! Code review will follow in another comment. > Patch implementing the new treeview api to solve this bug, but attending to > nested elements (those shown behind another folder) which do not show the > folder background menu because it would confuse users as the menu shown is not > of that folder but the folder of the current view. > > As a next step we could try to make those blank space clicks on nested folders > to show the background menu for *that* folder.. what do you think about it? I tried your patch and I find the special case you did in your patch for nested folders confusing already. I think when a right click hits the blank space you should always display the context menu for the topmost folder, regardless of the depth.
Review of attachment 203262 [details] [review]: Just a little code style nitpick. ::: src/nautilus-list-view.c @@ +741,3 @@ + if (event->button == 3 && + (gtk_tree_selection_path_is_selected (selection, path) + || ((blank_click = gtk_tree_view_is_blank_at_pos (tree_view, event->x, event->y, NULL, NULL, NULL, NULL)) I don't like assignments inside nested if conditions, as they tend to get lost or unseen while refactoring code later; please move that before the if block (and remove the depth check).
Thanks Cosimo for the quick response! (In reply to comment #122) > (In reply to comment #121) > > Created an attachment (id=203262) [details] [review] [details] [review] > > Implement gtk_tree_view_blank_at_pos to show background folder menu on blank > > spaces > I tried your patch and I find the special case you did in your patch for nested > folders confusing already. > I think when a right click hits the blank space you should always display the > context menu for the topmost folder, regardless of the depth. Ok, that will simplify the patch, I didn't had an strong opinion on that, but my first impression was that people could try to "paste" into the nested folder by displaying context menu inside it.
(In reply to comment #123) > Review of attachment 203262 [details] [review]: > > Just a little code style nitpick. > > ::: src/nautilus-list-view.c > @@ +741,3 @@ > + if (event->button == 3 && > + (gtk_tree_selection_path_is_selected (selection, path) > + || ((blank_click = gtk_tree_view_is_blank_at_pos (tree_view, > event->x, event->y, NULL, NULL, NULL, NULL)) > > I don't like assignments inside nested if conditions, as they tend to get lost > or unseen while refactoring code later; please move that before the if block > (and remove the depth check). I made it so to not call blank_at_pos() twice or call it once but for every event->button.. I like to code with this performance nitpicking mind although as you said could make maintance harder.. I will make your changes tomorrow and repost a new patch.. thanks!
(In reply to comment #125) > I made it so to not call blank_at_pos() twice or call it once but for every > event->button.. I like to code with this performance nitpicking mind although > as you said could make maintance harder.. > > I will make your changes tomorrow and repost a new patch.. Yeah, even though this gets called only when there's a button event, so it's relatively uncommon (I could see it being a problem if we called this e.g. on each motion-event). Anyway, AFAICS this should be equivalent and more readable if (event->button == 3) { blank_click = gtk_tree_view_is_blank_at_pos (); } if (event->button == 3 && (blank_click || gtk_tree_selection_path_is_selected()) { /* do stuff */ }
(In reply to comment #126) > > Yeah, even though this gets called only when there's a button event, so it's > relatively uncommon (I could see it being a problem if we called this e.g. on > each motion-event). > Anyway, AFAICS this should be equivalent and more readable Indeed! :-)
Created attachment 203323 [details] [review] Patch to show context menu on list view blank spaces Here's a new version with review fixes. Thanks to Walter Ribeiro for noticing the new api needed to fix this.
Review of attachment 203323 [details] [review]: Thanks, looks good. Feel free to push to git master after fixing this little detail. ::: src/nautilus-list-view.c @@ +814,3 @@ if (event->button == 3) { + if (blank_click) { + gtk_tree_selection_unselect_all (gtk_tree_view_get_selection (tree_view)); You already have the GtkTreeSelection locally as a variable, so gtk_tree_view_get_selection() => selection here.
(In reply to comment #129) > Review of attachment 203323 [details] [review]: > > Thanks, looks good. > Feel free to push to git master after fixing this little detail. Committed. Marking as FIXED.
Although this problem is solved and the bug is fixed, there is another strange behavior in Nautilus that is very very similar to this one and should follow the same direction. When you drag and drop a file, the same method gtk_tree_view_is_blank_at_pos() should be called before deciding in which folder the file should be placed. I do not know if it's right to post this here, since the bug is fixed, but I could not find a more suitable place for it since there is a strong relationship between the two subjects. Thank you!
Maybe the bug should be reopend, this problem is present again in Nautilus 3.6.3
Please file a new report in that case.
Done: https://bugzilla.gnome.org/show_bug.cgi?id=689768