Version: (using KDE Devel) Installed from: Compiled sources OS: Linux I just tried KDE4 alpha1 and of course dolphin as part of it. If you have used digikam recently, you might have noticed that even users that use "one click to open" can select an item by clicking within its frame and open it by clicking on the object itself. In dolphin there is no difference between those two areas. As a result the user is forced to use the keyboard in order to select a single item, instead of just clicking once. Having the frame-area not opening the object would even allow the user to select the item with one click and then click on the name displayed within the frame in order to be able to rename the file.
Thanks for the input, I'll try it within Digikam to check how it feels.
I just tried the "Details" view and there the "problem" is even worse. There are three columns, filename, date and size. Clicking on the whole filename column, even if the filename is just a tiny bit of it, opens the file. If I want to select that file I cannot even click on the date or size column since that does not do anything. So for people that have single-click enabled it would be useful, if they could click somewhere on the line without opening, but just selecting the file. Since one usually looks at the filename and to be consistent with the icons-view, it would be useful to be able to click within the "frame", i.e. in this case somwhere in the file-column but not on the object, i.e. filename itself. That way one would have "click on object opens it", "clicking next to it, selects it". BTW, how much feedback would you like to get? Some developers get annoyed if they get too much, since it means work for them. I can understand that and since I like dolphin I would not like to annoy its developer. :)
> BTW, how much feedback would you like to get? Some developers get > annoyed if they get too much, since it means work for them. > I can understand that and since I like dolphin I would not like > to annoy its developer. :) Having feedback is generally a good thing :-) It's just important to be aware that the current software is in alpha stage, so we are aware about many issues already. > There are three columns, filename, date and size. Clicking on > the whole filename column, even if the filename is just a tiny bit > of it, opens the file. Currently in Qt4.x there is no (easy) way to differ between clicking on the name or clicking on the name column. But the details view also has other weak points currently (e. g. no rubberband when selecting files), so we'll see what we can do in this area generally. > So for people that have single-click enabled it would be useful, > if they could click somewhere on the line without opening, but just > selecting the file. What about drag and drop? Should dragging a file X above the size column of directory Y drop it into the directory Y or inside the parent directory of Y (= viewport)? I'm just asking as I'm little bit concerned regarding a consistent behavior within the icons, details and columnview... > That way one would have "click on object opens it", > "clicking next to it, selects it". Sounds interesting. I hope I've time to play around with this until KDE 4.0 is out. Maybe we can give a visual feedback when hovering the item whether a selection will be done or a starting... Best regards, Peter
> Having feedback is generally a good thing :-) It's just important to be > aware that the current software is in alpha stage, so we are aware about > many issues already. Ok, I'll not post any bugs until beta and just look out for improvements. > > There are three columns, filename, date and size. Clicking on > > the whole filename column, even if the filename is just a tiny bit > > of it, opens the file. > > Currently in Qt4.x there is no (easy) way to differ between clicking on the > name or clicking on the name column. I just knew it from using konqueror, where it behaves that way, so I thought it would be the same for Qt 4. > > So for people that have single-click enabled it would be useful, > > if they could click somewhere on the line without opening, but just > > selecting the file. > > What about drag and drop? Should dragging a file X above the size column of > directory Y drop it into the directory Y or inside the parent directory of > Y (= viewport)? I'm just asking as I'm little bit concerned regarding a > consistent behavior within the icons, details and columnview... I think that if the user wants to drop a file into another object, e.g. a directory, one has to drop it on that object. Dropping it on the size or date-column would drop it into the parent-directory. If the object one drops it on is not something that accepts drops, such as a text-file, it should be dropped into the parent-dir. If dolphin ever introduces a tree-view this becomes more difficult, so I would suggest to never do so. :) With the above suggestion even in icon-view one would be able to drop something into the parent-dir. Icon view has the problem that the whole area is covered by objects (if their filename is long enough), so it is not always possible to find a blank spot without scrolling the view to the bottom. It does not work, if the whole visible area is covered by directory-objects though, since dropping it on any of those would move/copy it into that object.
*** Bug 149636 has been marked as a duplicate of this bug. ***
This is possible with Qt4! To quote Aaron: the delegate can certain draw extra UI on/around the icon and click on those items can be used to launch/perform other actions.
> This is possible with Qt4! Yes, it is possible but not in a very straight forward manner :-) The drawing part is easy to implement, but having a generic concept for the interaction part for all views is not something that Qt supports out of the box. > the delegate can certain draw extra UI on/around the icon and > click on those items can be used to launch/perform other actions. I've already a quite concrete idea how this can be solved for all views, but the solution is non-trivial and I'll have to postpone this to KDE 4.1. Generally I like your idea and will implement it!
Hello, > I've already a quite concrete idea how this can be solved for all views, but > the solution is non-trivial and I'll have to postpone this to KDE 4.1. > Generally I like your idea and will implement it! How is the current status with QT and Dolphin? I'am not the OP, but i also really miss that feature - mostly the clicking-not-on-the-name-to-select in the detailed/tree-view. BTW: How is that shared between Dolphin and Konq? If you/someone could implement that in Dolphin, would that also show up in Konqueror? Because in 3.5.x konq also showed that bevavior the OP described, but it got lost in 4.x (up to 4.2 as far as i can test) Thx, would be great to get some feedback, or someone who would invest some time to implement this. Daniel
> How is the current status with QT and Dolphin? I'am not the OP, > but i also really miss that feature - mostly the > clicking-not-on-the-name-to-select in the detailed/tree-view. Since 4.1 the (+) indicator allows to select items for all views. In 4.2 some adjustments to the details view have been made, so that it behaves more similar than the details view from KDE 3. However clicking on the right of the name to select a column has not been implemented yet. If it will be implemented, it will be an optional feature that can be turned on. The problem with this behavior - from my point of view - is that it is not possible to deselect items anymore in a simple way. In KDE 3 "Escape" fulfilled this task, but this was an undiscoverable feature... > BTW: How is that shared between Dolphin and Konq? Konqueror uses the Dolphin views, so implementing this in Dolphin automatically makes it available in Konqueror too.
> Since 4.1 the (+) indicator allows to select items for all views. In 4.2 some > adjustments to the details view have been made, so that it behaves more similar > than the details view from KDE 3. However clicking on the right of the name to > select a column has not been implemented yet. If it will be implemented, it > will be an optional feature that can be turned on. The problem with this > behavior - from my point of view - is that it is not possible to deselect items > anymore in a simple way. In KDE 3 "Escape" fulfilled this task, but this was an > undiscoverable feature... I don't understand this part. If this was implemented, clicking on the empty spacce next to the filename or somwehere on the empty space in the "frame" when icon-view is active would select that file. Doing the same with another one, would select only that file again, not like the "+" adding to the selection. In order to get the same behaviour as with the "+" the user would have to press CTRL while clicking on new files to (de-)select them. That's the same as it was in KDE3 and I think windows too. The benefit of the "+" is that the user does not need to know about the CTRL key, yet IMHO it only adds ease for a certain user-group, but should not replace the CTRL method. And ESC as aborting the current action, i.e. in this case selection, is not undiscoverable IMO, since all users I know, do know that ESC aborts. But even if it was undiscoverable, it does not mean that it should not be available, since it can only benefit those users that use it.
Hello, Nice to see feedback so fast, thx :) > If it will be implemented, it will be an optional feature that can be turned > on. The problem with this behavior - from my point of view - is that it is > not possible to deselect items anymore in a simple way. In KDE 3.5.x the clicking right of the name deselect all other files and just selects that one file. If you want (for what reason ever) deselect all files (ie. select no file) you could click between the icons (in Symbol-View) or in empty space (in Tree-View under the last line, for example). So I dont see any problem with that - and if it is optional it would also be great - as long as it is possible at all :) Daniel
*** Bug 195528 has been marked as a duplicate of this bug. ***
Created attachment 36623 [details] screenshot showing area where ability to place focus doesn't work Devs, How is progress on this bug coming? In 4.3.1 this problem still plagues konqueror. Additionally, this may need to be elevated in priority, due to the fact users lose all ability to place focus on a file without opening/executing the folder/file if the setting of "Show selection marker" is turned off in settings -> configure konqueror. No kidding, you have *no* ability to place the focus on a file with the mouse if that setting is turned off- that shouldn't be like that. The problem just underscores the flaw in konqueror that was created when the ability to place focus by clicking in the space between the filename and the size was lost. This lack of ability to manage focus in a reasonable way in kde4 konqueror is probably one of the top 3 annoyances of kde4. Please give this bug some attention. Thanks.
I have reported that bug at ubuntu papercuts. -> https://bugs.launchpad.net/hundredpapercuts/+bug/435090 Maybe someone with more programming experience than me will have the time to fix this. [David Rankin] > No kidding, you have *no* ability to place the > focus on a file with the mouse if that setting is turned off > that shouldn't be like that. Not completely true - not that i like that behavior, but i adopted to it: use the selection-rectangle to select only one file with the mouse. I click (as used from 3.x) in the empty space, next to the name. And than drag the rectangle only over the one file. Daniel
*** Bug 190722 has been marked as a duplicate of this bug. ***
*** Bug 168379 has been marked as a duplicate of this bug. ***
Screenshot from bug 168379 illustrating a proposed solution: http://bugsfiles.kde.org/attachment.cgi?id=26654 (In reply to comment #14) > > No kidding, you have *no* ability to place the > > focus on a file with the mouse if that setting is turned off > > that shouldn't be like that. > Not completely true - not that i like that behavior, but i adopted to it: use > the selection-rectangle to select only one file with the mouse. I click (as > used from 3.x) in the empty space, next to the name. And than drag the > rectangle only over the one file. You can also press the Control key while clicking a file's name.
The solution mentioned in comment 17 seems to be what KDE3 does. I don't see why KDE4 should be able to do the same. If KDE4 users have become too used to its new behavior, make a config setting. (personally I can't go from KDE3 to KDE4 before this annoying little thing and others like it are fixed, but that's just me)
This is not only about the details-view but also about icon-view as digikam and dolphin use it.
Resetting assignee to default as per bug #305719
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Closing as not relevant anymore IMO.