The rubber band is no equal replacement as it can select only items within a rectangular area. Beside that using the Control- and Shift-keys is a non discoverable feature it also requires that the user has to move his eyes from the display to the keyboard to hit the Control- or Shift-key (this even is valid for people that are familiar with touch typing).
Aaron came up with a nice idea some time ago, which allows selecting files with the mouse also in the single-click mode. I did not go that far yet, as I wanted a common solution that works in all view modes (even on view modes with very small icons). In Dolphin for KDE 4.1 a "select item" icon will fade-in when hovering an item:
When pressing this icon, the item will get selected and the icon changes to a "deselect item" icon:
I'm aware that this is no equal replacement to selecting files in the double-click mode, as the target area is a lot smaller. However, I still was surprised how comfortable it works especially in combination with the other view modes like details view and column view. I had some concerns that users will accidentally select an item instead of opening it, but it seems to work quite well. For sure this feature can be turned off too, as I'm aware that not everybody will like having such a fade-in icon above the items.
Anyhow I would be interested getting some feedback from people who actually worked with this feature by using the trunk version of KDE. Is the size of the icon sufficient? Are the used icons OK? Is the fade-in timeout too long or too short?
66 comments:
The first time I've seen this i said 'woa ... what a great idea!'.
So, yes, this works really well for me. It has always been a pain to select with single click mode.
Let's see how non geeky people deals with this.
What about
short (normal) click = select
long (half a second) click = exec
?
Or vice versa?
Or individual defaults (configurable)?
I think it's a great improvement. I've never liked single-click mode before but now I find myself drooling at the little select icon thingie! Personally I'd leave it as it is, simple and intuitive.
Overall I'm loving everything Dolphin. Thanks Peter!
Afterthought:
I'd prefer my first suggestion. Holding left mouse button long executes or opens.
But then I usually select via typing on keyboard.
What about using checkboxes instead of plus and minus signs?
Peter, this looks awesome!! :-D
manfred said...
> What about
> short (normal) click = select
> long (half a second) click = exec
Seams like a bad idea to me. It's not grandma compatible for instance.
People who have difficulty using a mouse hold the mouse button down a long time. People with rheumatism are not that fast with their finger anymore too.
A lot of people won't figure out why their computer responds differently to mouse clicks at some moments. It's magic, confusing and they'll hate it.
i think this is actually a great idea, but shoud be improved making the "+" icon bigger (with a smooth animation) when the mouse is over.
I use and like it very much, but since you're asking...
* I feel tick-and-cross icons (aka green slanted 'V' and red 'X') would be more intuitive... But that's my own feeling, can't back it up with facts.
* Either the icon is too slow to appear (I tend to wait until it's fully there before clicking), or it's too small. Bottom line : too hard to hit.
* I'm not affraid of acidentally selecting when I want to open : there's plenty of margin left, and the consequences are minimal.
* I want more such buttons ! Touchscreen users could have a button to "right-click" for the contextual menu. I'd love to have a "open in editor" button, when the normal (whole icon) action is "open in viewer".
* It'll need sane defaults and good configuration (per-mimetype ?). Tricky to get right, as it's all too easy to bloat this kind of feature (dolphin should be really simple to use).
Great, I much prefer single click mode on the whole but selecting files was a bit more difficult than it needed to be - until now :-)
Btw, I've just started experimenting with KDE 4.0.x on Fedora rawhide and I've got to say Dolphin is great. And I say that as a Konqueror fan - although I didn't object to Dolphin becoming default in KDE4 I didn't expect to use it myself, but I think I may be changing my mind...
What about an alternative way for the rubber band selection? It should not open up a rectangle but should only select entries that are directly crossed by the mouse path. This might be a good way for a list view instead of the icon view which has the bigger icons.
What about doing it like this:
Mockup
On mouseover an overlay which is splitted into 2 regions is displayed:
- one for (de-)selecting
- one for opening the file as usual
This would even work for listview, by splitting it into a left/right part.
Regards, Elias P.
Great! I love the idea, but I agree with stripe4 that the overlay icon should be a checkbox (preferrably a standard QT widget, for consistency).
Aside from that, I think it would be also useful to provide a more convinient way of checking/unchecking for advanced users. I'm thinking of something like a middle button click to toggle selection, where available. What about that?
I agree with the tick and cross remark. It is more intuitive. But on the other hand I also asssociate a red cross with "delete this".
Hmm......., needs more thought.
1.) Hovering on the left corner makes the icon appear without fading, on any other part it fades in (just a little bit too slow in my opinion)
2.) It's too small. It must be an easy-hit. For detailed view they are 'big' enough. Cause you have to be careful anyway in that mode
Oh, and I must also advice to stay clear from "timed" clicks (i.e 'long click' vs. 'short click'). I tried that in some Flash prototypes and decided against it after some usability testing. Heck, I even tend to drag my mouse clicks longer than needed when I'm running short of caffeine in the mornings!
[...]But on the other hand I also asssociate a red cross with "delete this". [...]
Yup, I'm afraid most novice users would be scared at the sole idea of "pushing that big, bright red button with an X on it which appears on top of your dearest files..."
Another paradigm, just off the top of my head:
- Single-clicking on the ICON opens the file/launches the app.
- Single-clicking on the icon TEXT selects the icon.
- Double-clicking on the ICON opens the file just as with 1-click.
- Double-clicking on the icon TEXT renames the text in-line.
Is that at all possible?
Thanks for so much feedback in such a short time frame... I've read all comments and will consider them for further decisions. Some short reply to specific points:
- Using a different icon (checkboxes, V or X): I've tried all of them already. Regarding V (= green OK/Apply) and X I got the feedback that especially the X looks like deleting. For the checkbox the problem is that in the unselected state it looks just like a plain rectangle and gives no indication that this is something that can be selected. Maybe the Oxygen team could come up with some cool ideas...
@Iván:
> I'm thinking of something like a
> middle button click to toggle
> selection, where available.
> What about that?
Good idea in my opinion!
@anonymous:
> What about an alternative way
> for the rubber band selection?
> It should not open up a rectangle
> but should only select entries
> that are directly crossed by
> the mouse path.
This is something I wanted to implement already 2 years ago, but never had time for it :-) I'm not sure how well this really might work...
@Moltonel:
> I want more such buttons !
Would be no problem technically, but it was important for me getting some feedback about this icon before extending this idea...
@bartotten:
> Hovering on the left corner
> makes the icon appear without
> fading, on any other part it
> fades in (just a little bit
> too slow in my opinion)
That's done on purpose: the icon is available immediately, so you don't have to wait until the fade-in is completed. I've played around with faster fade-ins, but this - from my personal point of view - felt quite "nervous" when moving the mouse above items.
> It's too small.
Maybe in the icon view it might be an option to adjust the size dependent from the current item size.
@Iván:
> Oh, and I must also advice to
> stay clear from "timed" clicks
I fully agree :-)
@Iván:
> Another paradigm, just off the
> top of my head:
> - Single-clicking on the ICON
> opens the file/launches the app.
> - Single-clicking on the icon
> TEXT selects the icon.
> - Double-clicking on the ICON
> opens the file just as with 1-click.
> - Double-clicking on the icon
> TEXT renames the text in-line.
>
> Is that at all possible?
Yes, this would be possible (although it would be not so straight forward to implement). One problem I have with this proposal is that it would not work well in the details view and column view: the icons there are too small to be the area of the most used action (= going into the directory/starting applications). But I'm convinced this proposal would work very well in the icons view with very large icons.
Well I have to admit at first I did not really know what these icons were supposed to be.
The reason for that is that I discovered these icons while I wanted to open a file. So I clicked them and "nothing" happened, but I still did not knew what they were supposed to do.
Even though I understood their meaning later on I think there should be some note if you press that icon for the first time or some other hint.
Especially older people don't experiment that much in my experience, fearing they could "destroy" something. So there needs to be a hint for them that tells them that no files etc. could be "harmed" using these icons.
About the "what does this button do ? delete my file ?" problem, displaying a tooltip on hover would help quite a bit. Sound obvious once you think about it :p
@mat69 and Moltonel: I've just committed a fix so that tooltips are shown when hovering the selection toggle :-)
The first thing I used to do when installing KDE was changing to double click. Now that I am compiling trunk regularly and playing with the settings, I have stopped to do this, simply because of the new feature you introduced. I works perfectly. This is a great improvement. Just leave it like that.
i agree that single-click mode is a pain when selecting things. from a user point of view, adding visual artefacts may help, but from a usability point of view, i'm not really convinced (i'm no expert, though).
in short : visual artefact is good for new users. advanced users may want to have something more productive (maybe with less clutter).
i have a few ideas/suggestion - but i don't know what they're worth :
- implement your method, as it can prove good and straightforward for general, new user
- let power users configure their own single click behaviour. from some of the previous posts, it can include :
- short click = select, long click = open
- use a checkbox
- other button combos, toggle behaviour
- click text = select, click icon = open (or the opposite…)
imho, the latter could be quite productive : text and icon are existing distinct areas, clicking them could(should) lead to different behaviour.
maye you should ask a usability expert, such as Celeste http://weblog.obso1337.org/.
Unfortunately I can't try it at the moment, but I bet it rocks. I wanted to have that since I first read about it.. years ago! :) But:
Maybe I missing something here, but what has it to do with single vs. double click? AFAICS this is "only" about replacing Control/Shift for selecting, well actually Control only?
The problem with single click compared to double click is, that you can't a) select _only_a_single_ (you can only add to an existing selection) icon, b) at the same time deselect all previously selected ones and c) do that with a single action. With single click you have to click on empty space to deselect. So you first need empty space for that (might be a problem in detailed view) and if the previously selected items are out of view, exactly nothing visibly happens ... So I sometimes click a few times, just to make really sure nothing else is selected :) With double click you click on the icon (e.g. the first of a new selection) and you know that everything else has been deselected now and you have feedback by the new icon being selected. So a solution for the real single click problem is still missing :)
But as I said I can't try it atm. So maybe I just writing nonsense, then feel free to ignore... And don't get me wrong, the feature itself is definitly a win! But IMHO more for replacing Control for selections (I always mix Control and Shift ...)
Greets Michael
I also like the new 'add to selection' button at the top left corner very much as it simplifies selecting several single files.
Additionally at least in my opinion we should not throw away the traditional method to select items using Ctrl+click or the rubber band every advanced user knows even if he or she is not a KDE user.
Compared to KDE3 I noticed a problem when selecting files using Ctrl (I tested KDE 4.0-4.0.2 and 4.0.66): When adding a group of files to an existing selection using Ctrl+rubber band the element(s) added before are unchecked again. E.g. 1) pick one file 2) pick another one using Ctrl+click 3) pick some others using Ctrl+rubber -> this will result in a selection containing the files only from 1) and 3).
Selecting files without mouse (e.g. Ctrl+Space, Arrowkeys, Ctrl-Space) is even hard (but works) in KDE4 because there isn't any hint which file will be selected. So you have to keep in mind your actual position. (I admit that I only tested this in KDE 4.0.2 and didn't have a look at any bugreports).
Regards, Robert
This is a great feature. I haven't personally used it yet, so take my feedback with "un par de pinzas".
I think it would be nice to allow a trail selection. This would mean that a user could click on a plus sign to select one file, and if he maintains the mouse button pressed and drags on top of other files these files get selected as well.
This could allow a bit more power than the rubber band selection since the files don't need to be in a rectangle for them all to be selected, the user could avoid files by passing between them.
I know this would be kind of like an easter egg for most users, but power user could appreciate it.
Dolphin is fantastic!!
Why not just have *one* icon/radiobutton in the Dolphin taskbar which when clicked enables the one-click selection mode for advanced users. That way each and every one of the icons is not cluttered with an even smaller icon and the clickable area for usual browsing remains the same?
Maybe I miss something here, but the current approach strikes me as overkill.
With the selection issue, it might be worth having a lateral glance at KolourPaint, which has three selector tools -- rectangular, elliptical, and free-form. I don't know how easy it would be to cannibalize the code, but it's an idea...
@anonymous:
> at least in my opinion we should
> not throw away the traditional
> method to select items using
> Ctrl+click or the rubber band
I never intended throwing away a traditional method...
> Compared to KDE3 I noticed a
> problem when selecting files
> using Ctrl
That was a Qt-issue that has been fixed in Qt 4.4.
> Selecting files without mouse
> (e.g. Ctrl+Space, Arrowkeys,
> Ctrl-Space) is even hard
> (but works) in KDE4
This has been fixed for KDE 4.1.
@Ricard
> I think it would be nice to
> allow a trail selection.
Wow, this would be an interesting feature. I fear it won't be easy to implement, but if I've fixed all Dolphin bugs until KDE 4.7... ;-) Seriously: really a good idea!
@anonymous:
> Why not just have *one*
> icon/radiobutton in the Dolphin
> taskbar which when clicked enables
> the one-click selection mode for
> advanced users.
Going into a mode for selecting and the need to disable the mode again after selecting does not sound comfortable for me. But I'm not sure and this reflects just my personal opinion :-)
I _love_ this feature. I find it incredibly useful, and now find 4.0.x (on my other computer) really annoying because it doesn't have it.
The only problem is that the button works before you can see it (because of the fade-in), so you can click it without realising it. Also, if you click on a folder (to enter it) before the button has faded in, you get an ugly white square.
@randomguy3:
> I _love_ this feature. I
> find it incredibly useful,
Thanks :-)
> The only problem is that the button
> works before you can see it
> (because of the fade-in), so you
> can click it without realising it.
If the mouse is above the toggle item it immediately gets visible -> the user should be able to see what he is clicking. And even in worst case the file gets only selected :-)
I played around with waiting until the fade-in has been finished, but this gets very annoying especially in the details view. With the current approach it is extremely easy to select multiple files in the details view. This would not be possible if the user has to wait until the fade-in has been finished...
> Also, if you click on a folder
> (to enter it) before the button has
> faded in, you get an ugly white
> square.
Currently it looks like this is a Qt-issue. It has improved with Qt4.4 in comparison to Qt4.3, but it still is not perfect. Maybe there are some tricks to bypass this white square...
It took an hour or two to adjust, but ohhh I love how this works in svn Dolphin!! It is soo effortless, soo comfortable. It is one of the truly excellent experiences in KDE4 so far.
Like I said, it may be a little uncomfortable at first. But it was primarily just mild retraining discomfort for me. For those who it might bother, I say work with it for a few days. Personally, I hope we never go back!
Regarding improvements, short of a delayed tooltip on the "+"/"-" icon hover describing what it does, I haven't heard anything that's better than the way it works in svn.
First of all: damn you Ricard for stealing my idea and glory! ;P
That's one of the issues I have with this new feature: I can't click on the icon and drag. I would expect the rubber band to show up, but after reading about the trail selection I've changed my mind; do I have to say that I love Ricard's suggestion?
Otherwise I don't have much to add, what I think about the feature has already been said.
+ Imo not too small, easy to hit
+ Works as expected (except when dragging the small icon)
+ I like how it fades
+ Not in the way
- I liked the look when all selections were equally selected... oh well.
- The icons, as others have mentioned.
Just something that popped into my mind when reading these comments. I haven't tried this feature, so this is a bit theoretical.
One of the topics of discussion was the delay in the icon fading in, and the issue of the icon appearing immediately if you moused over the top left button. I can imagine that tuning the delay is not easy, and if you mouse over the top left of icons you could get a strange flicker as icons appear and disappear.
So that gave me an idea. The problem right now is that as developers we only get mouse enter/leave events for our widgets. This is not enough information when thinking about a good UI that involves mouseover actions.
Dolphin uses a lot of these. For example, folders fade in and out as the mouse moves over them, now these icons fade, and appear when mousing over the right spot, etc..
The problem is that widgets can't distinguish between a mouse moving over them on the way to another target, and a mouse actually moving there and stopping. To get this difference, one would need to have more information, such as instantaneous speed and acceleration of the cursor.
For this example, if one had speed of the cursor, then the icon could ignore fast moving cursors and not appear when the mouse is over. Also, the delay problem would be almost solved. If a user moves their mouse over an icon and stops, the hover icon can appear immediately.
For this to work, there would have to be some toolkit level or X11 level support for it, but I think it could really enhance a lot of interfaces like dolphin.
My humble opinions after much time spent on it:
1) Yes, "v" could be prolly better than "+", but the red "-" is very confusing (will that delete my files?)
2) I'd enjoy a faster animation
3) Right now the tick is quite small
Of course i love this feature, it only needs some tweaking.
One issue I see in the screenshots, the status bar doesn't reflect that a (single) file has been selected.
"Great Wall.jpg (JPEG image, 302.0 KiB)" could be changed to something like "Selected Great Wall.jpg (JPEG image, 302.0 KiB)" for a single file and "Selected n files (n KiB)" for multiple files.
@Datschge:
> One issue I see in the screenshots,
> the status bar doesn't reflect that
> a (single) file has been selected.
The statusbar shows that
files has been selected, but only if no hovering is done (in the screenshot the selected item is hovered currently). But maybe I can improve this by checking whether the hovered file is equal to the selected file... I'm not sure.
@Felipe:
> 1) Yes, "v" could be prolly better
> than "+", but the red "-" is very
> confusing (will that delete my files?)
Is it only the color or the icon itself that indicates "delete" for you? I honestly have no good idea how a "deselect" icon looks like and fits into 16 x 16 pixels... ;-)
> 2) I'd enjoy a faster animation
Yes, it seems the general feedback is that the current animation is undoubtedly _not_ too fast :-) I'll play around a little bit...
> 3) Right now the tick is quite small
Could you please let me know which size your icons have? Do you use the largest possible size in Dolphin? Currently the selection toggle uses 16 x 16 pixels, the next step is 24 x 24...
A green V for selecting a file and the outline of a V (in black?) for deselecting it might work, but I am pretty happy with the + and - icons.
1. The mouseover highlight doesn't look right on OS X. I did file a bug report about this, which got fixed, and then broken again. Bug 157229 btw.
2. The icon takes too long to fade in.
3. The icons used aren't attractive. Someone suggested a tick (V) and cross (x) I agree that that would be better, but even improved (+) (-) icons would be better.
Another paradigm, just off the top of my head:
- Single-clicking on the ICON opens the file/launches the app.
- Single-clicking on the icon TEXT selects the icon.
- Double-clicking on the ICON opens the file just as with 1-click.
- Double-clicking on the icon TEXT renames the text in-line.
This was extacly same idea what i got when i readed this selection problem.
First, for them one-click and double-click are unknow functions, they dont know when to click twice and when just once, so they click always twice unless it's very clear it is a button what they are clickin, like clickin "New email" button on toolbar and it looks like a button. Links are hard, they click twice links what are on web pages if they has learned to double click for files. Context menu (right click) is own area so i dont mention it here ;-)
All my old age customers (over 50) who have not used computers much or customers who are using first time computer (daily, buyed own etc), clicks first file's name, not the icon. Somehow it is first idea to "select" something, like if i say "and now open file named dadada...." they click file name, not the icon because they search file by it's name, not by it's icon, even i would tell "and now open PDF file named dadada...." and they know that PDF file has own icon because it has just few minutes before told them in start, but they still first thinks it as name, not as file. Long term PC user knows to move searching to specifig file icons and then from those, a file name and click the icon, what is bigger and is "action" to do what mouse click does. Somehow this is just not so with old ageg users.
I would suggest this text and icon separation, it would solve one problem too with double click action, because old ageg (and new) users clicks file name, not the icon and they learn tho double click file to open it, they double click text, not icon. And then they are lost if/when renaming option comes up.
If this is made clear for them:
1. (Double) click file to open it
2. (double) click file name to rename it, it would be more clear.
KDE changed default renaming action so, that renaming by default double clickin dont rename file. but it's the way how many my customers likes to do, and they finds hard to rename files from context menu or by using a F2 etc...
That's why i have enabled the inline renaming option so they learn to click icon after few first time and they have much less problems with all views, including list views (text-only view is impossible then)
And i found this line renaming better after all.
That small icon on top left corner for selecting, i would suggest it so it would be shown all the time, not just over hover. Then it is much faster and easier to click it, even it is much smaller than a normal icon, because eyes can already see it when hand starts moving mouse cursor to other file.
If it comes up only on hover, there might be problems in selecting files. Because first they learn that when mouse cursor is top of icon, there comes up small icon what to click to get file selected. And it is not just that "i click this little one here and it is selected"
how about the same symbol in two versions: one colored and one grey to show whether the item is selected?
btw: a great feature
I have to add some things to what I posted before.
I really like the basic idea: Improving the situation for people with touchscreens etc. and those that don't want to, don't know how to ... use keys to select files. Imo it is not good to be constantly forced to switch between mouse and keyboard unless it is really necessary like when you rename the file.
Now to the "icon-problem" what about a square with a tick inside, like a normal checkbox?
Do you plan to incorporate this feature into gwenview, open-dialogs etc. (not sure if it'd make sense in the later)?
Do you plan to add some other "hover"-icons like renaming ...? If yes, do you have an idea how to avoid Icon-clutter? --> I don't think adding other icons would be a good idea unless they'd be only added in a special "one-click-mode", because as it's now nothing can happen to your files, despite to fears, while renaming etc. change things.
Could someone explain to me just what is the problem with double-click mode to begin with? What's so difficult about click once: select and click twice: execute? Except off course that the former is used by Windows (so automatically scary)?
The first thing I do after installing KDE is switching to double-click mode.
@Henk:
> Could someone explain to me just what
> is the problem with double-click mode
> to begin with?
Nothing is wrong with the double-click mode in general. You can discuss for weeks about single- vs. double-click and will not find an answer which of both is the "better" solution. For absolute computer beginners the learning curve for double-clicking is higher (it's tricky for them clicking 2 times within the specific timespan without moving the mouse). On the other hand selecting items in the single-click mode is really a problem too. So all in all it's a matter of personal preference.
@Mat69:
> Now to the "icon-problem" what
> about a square with a tick inside,
> like a normal checkbox?
Already tried that (see answer somewhere above).
> Do you plan to incorporate this
> feature into gwenview,
> open-dialogs etc.
No, this is not planned yet. Gwenview already supports its own hover actions.
> Do you plan to add some other
> "hover"-icons like renaming ...?
No plans yet. I don't think context menus are evil and I don't want to replace the context menu... But I'm also not strictly against such an idea (e. g. like you said for touchscreen users this might make sense).
I usually upper right corner for select, but lower left for open, so it is really great.
maybe rectangular or ark would be better:
here in menus zone I would anticipate select, in plus - open.
---++
-++++
+++++
The best of all could be, if it would be possible to fade out select area of icon,
so no need of icon upon icon, thet is more neat.
Regarding tick box, could it be used with text description?
Empty box: "Unselected"
Ticked box: "Selected"
Or would text cause problems with small icon sizes?
@Peter Penz:
> Is it only the color or the
> icon itself that indicates
> "delete" for you?
Both of them, maybe the tick should stay the same IMHO, be it a "+" or "v".
> Could you please let me
> know which size your icons
> have?
Sure man: http://img241.imageshack.us/img241/8073/snapshot1ad7.png
Thank you
@Nathan:
> Regarding tick box, could it be
> used with text description?
I've just added tooltips into the current SVN version :-)
@Felipe:
Thanks for your reply!
http://kde-look.org/content/show.php/Special+Stack+for+Selecting+Items?content=54232
Just add that kind function for Dolphin Kpart (for konqueror too!) when selecting images and there would not be any doupt what file is selected and what is not. Then just make selecting easy with one click but so it dont break intuitive working way how selection works on all other apps, on web pages, image editor's, music editors, text editos etc etc.
@Fri13
That's a different idea altogether (icon "stacks"). It has nothing to do with selecting objects, although it could work orthogonaly to regular selection.
That same concept of an object stack could be implemented in a much saner way with something as simple as a temporary folder: just shove your files into this temporary folder, or create symlinks into it.
Of course, the GUI could help, for instance displaying the contents of the stack folder into a split window, panel, or whatever, and ensuring that items tossed onto it are always saved as symlinks. It could even be built as a permanent plasmoid on the panel!
IMO, a neat idea, indeed, and a better way of moving items around than the very twisted "copy file" - "paste file" paradigm.
Dear Peter,
First of all thank you for your great work! Dolphin is a wonderful tool.
I have a probably quite silly question: I have no idea how to get back items deleted from the "Places" panel. I accidentally deleted the trash and miss it since.
Thanks in advance!
@Kde: please just enter "trash://" into the location bar of Dolphin, go to an empty area of the view, open a context menu and select "Add to Places..." :-) It seems quite a lot users accidentally removed the trash, we'll check whether it makes sense to disable the remove button in this case.
@Peter,
Thank you for your quick response. I am glad to have the trash back. I had actually tried before what you told me to do, but my intuition had told me to right-click the "Places" panel to add an entry. Instead, one has to right-click the breadcrumb or the file view panel. I simply did not try this... well, again, thank you!
Hi! Konqueror has a nice function that allows you to copy/move a/any files wherever you want, just right clicking and selecting "copy to..." or "move to...". I wish this beautiful feature will be implemented in Dolphin. This could allow Dolphin to be THE file manager, IMHO. I hope this will happen. :) Nice job
@Emanuele: this feature is already available in the SVN trunk version of Dolphin :-) Stay tuned for KDE 4.1...
@Peter
> this feature is already available in the SVN trunk version of Dolphin :-) Stay tuned for KDE 4.1...
Yeah! Thanks!
There is a bug concerning the selecting thingy that makes the selecting thingy appear misplaced.
Steps to reproduce:
Step 1. Activate a list view (probably works with other views as well) in a directory with larger ammount of items (so that the view is scrollable)
Step 2. Hover a file so that + appears
Step 3. Enter a letter to focus on a file that is not currently displayed so that autoscroll happens.
The selecting thingie will remain in the same place it was earlier... while the files are scrolled.
It is not difficult to achieve that + is in fact between two files.
@Ivan:
Thanks for the hint, I was not aware about this (I fixed it for the scroll wheel already, but not in combination with the keyboard). It is a Qt-issue (http://trolltech.com/developer/task-tracker/index_html?id=200665&method=entry), but I'll bypass this in Dolphin for 4.1 (currently the Qt-issue is targeted for 4.5.0).
"The icons used aren't attractive. Someone suggested a tick (V) and cross (x) I agree that that would be better"
Here we have the issues that different places have different customs. In Finland, the cross (x) it the typical way of selecting checkboxes and the like, whereas tick (v) is practically unused in this context.
I have also seen that elsewhere the tick is used to mark the correct answer, whereas the cross is used to mark the incorrect answer. Over here the usual way is to mark correct answer with a different symbol (that my keyboard does not support), while the tick is used to mark the incorrect answer. Well, it's not a tick as such, but a letter "v", which is short for "väärin" or "wrong".
Suggestion:
Instead of using a single tiny icon for adding/removing the current icon to selection, the entire blue "blop" around the icon could be clickable.
Already this blop is used to indicate if an icon is selected (dark blue blop) or not (no blop), so I find it intuitive that clicking the blop toggles selection.
For opening the icon, one would need to click on the icon itself or its text.
Open: click icon
Toggle selection: click blop
Does this make sense?
You know, these days, there are mice with as many as seven buttons (apart from the usual 5, there are those on the sides of the mice).
Why not enable selection on one of these extra buttons and still have the hover icon and the single click. This way, you can select many items with a single 'right-right' click and open all of them with a left click on the last item to be selected.
I've always felt that linux underutilizes these extra mouse buttons (including those of joysticks and lirc remote controls) and thus the adoption of such devices has slackened doe to lack of "content" from the UI?
What about a little border/frame around the icon in which you can put a number of icons for useful tasks?
First let me say that I really like Dolphin and really liked the promise of the KDE3 release. These comments are only because I like the program; I wouldn't bother otherwise! So please take this all as constructive (thx!)
A few comments about the way KDE4 Dolphin is going usability wise...
1. The mouse-cursor float-hilite thing I find very disconcerting. I've tried to get used to it, but find the old KDE3 dolphin (&Konq) mouse interaction to be much more intuitive. Besides, it also slows the GUI down no end, because it seems to be on all the time even when rubberbanding and such. Perhaps the hilite can appear after some period of hovering over an item, or perhaps the behaviour could be configured: as now | as above | off?
2. It would be nice if "type to locate" would work properly. At the moment, it works but you can't see that you've located anything (down-cursor confirms location). This is especially irritating in Detail view, the one I use a lot of the time for more power-user file ops.
3. Tab order when in filter mode could be more intelligent ie. tab from filter focuses directly to file list, then shift tab back to filter (or tab to toggle between the two?)
4. In combination with (1) above, rubberbanding is a nightmare, especially in detail view. The reason is that the whole column width is hilited, meaning that clicking way to the right of the filename (in whitespace) still actions it. In all views, it would be better to action the file only if the user has clicked on the icon or the text itself, and not some big bunch of whitespace around it. This makes it much easier to accidentally launch a file, and in 1-click KDE mode, this is defo not a desirable behaviour.
Keep up the good work!
effzee :)
@effze:
> 1. The mouse-cursor float-hilite thing
> I find very disconcerting.
We might think about making it less resource hungry or obtrusive, but we won't turn it off completely as it is necessary to give the user feedback whether clicking on the file will trigger it or not before he clicks.
> 2. It would be nice if
> "type to locate" would work properly.
This is fixed in KDE 4.1.
> 3. Tab order when in filter mode
> could be more intelligent
I agree; I just did not have the time yet fixing this.
> 4. In combination with (1) above,
> rubberbanding is a nightmare,
> especially in detail view.
> The reason is that the whole column
> width is hilited
In Qt 4 it is not possible anymore in an easy way making only parts of a column selectable... Before introducing hacks that might again have side effects I decided to leave it as it is in the meantime. I hope in Qt 4.5 there will be a way to adjust this.
> Keep up the good work!
Thanks :-)
I know this blog post is old, but it would be so much better if the automatic selecting on hover just worked.
In mouse settings you can enable that files are automatically selected upon hovering them for a short time (like Windows does since Windows 98!! and they got away from the single-click-idea why can't KDE do this in 2010?) and not having to look for a small icon.
Post a Comment