I did no scientific research about this, but I think first it was Microsoft with Windows Vista which started to put the menu bar into question for some applications:
- The ribbon replaced the traditional menu bar for their office suite.
- The menu bar is hidden per default in the Internet Explorer and the Windows Explorer. To still be able accessing all commands a kind of menu-button has been added to the toolbar.
Until I tried those applications I've been a strong opponent of those "menu bar violations". But after working a while with both approaches it seems that ribbons work very well for applications with a huge number of commands. I'm not sure whether the Internet Explorer or Google Chrome has been the first browser without menu bar, but as user of Chrome since around two years I was surprised that I never missed the menu bar and liked the well-arranged menu button.
I got the impression that the menu button as replacement works well for applications with quite less commands. In the meantime even Firefox 4 has switched to a default setup where no menu bar is shown; so I asked myself whether this might be an option for Dolphin and simply gave it a try. Since the release of Dolphin with 4.5 I try to strive for a cleaner and less cluttered default setup and now with having no menu bar I think the default setup is quite OK [1]:
It gets move obvious when comparing this with the default setup in 4.5:
Before the complaints "I want my menu bar back" start: Of course it is possible to enable the traditional menu bar :-)
Back to the new default setup of Dolphin. Beside the missing menu bar a lot of smaller updates have been done too:
- The Information Panel on the right is hidden.
- Toolbar items where the icon is sufficient for knowing the command don't have a text. By the way: In 4.7 this can be changed by a simple right-click.
- If the Places Panel is shown (like in both screenshots on the left) the "places selector" left from the Home > Pictures > Wallpapers path is hidden as it is duplicated functionality provided by the Places Panel.
- The Panels are "locked" per default like in Amarok and don't have a headline and two buttons.
- The search bar at the top right has been integrated into the view when executing the "Find" command.
Please note that those points just talk about default settings, no functionality has been taken away. For me it was - and still is - one of the main goals of Dolphin that it is easy and efficient to use without cutting too many features. I somehow like it that despite the added functionality during the last years this is not reflected in additional visual clutter. When looking back at the history of Dolphin screenshots it is somehow funny that for the upcoming 4.7 release Dolphin looks more similar to the old KDE 3 version than the 4.5 version :-)
[1] Please ignore the current look of the zoom-icons in the bottom-right of the screenshot. They will be replaced by a more decent version created by Nuno before 4.7.
82 comments:
What the...?
Great, so you too are blindly following the GNOME way of hiding "unneccessary" elements... at least you can re-enable it (for how long?), but I don't think this is a good default choice - have you ever thought about UI consistency between applications?
It would not be a problem if the global menubar would work, could be placed in an auto-hide-panel and would not take any space, but it would still be easily accessible. In my opinion this solution is far better than all the buttons.
Very cool, I have done away with thye menubar in konqueror, kmail and a few other kde apps supporting hiding it on the netbook, where simplified (read realestate economic) UIs is a must.
Personally I like that i can show the menubar and use the keyboard to navigate menus in applications with many commands - I wonder if menubar hiding could be impemented in kapplication, to make it globally available (even to users not using qtcurve).
Looks great! Nice work! But can we please find a different icon then the wrench?
Personally I'm indifferent about menu bars. What I'm not indifferent about is consistency. Maybe you guys should rather work on a global way to disable all menu bars by default.
I have tried the global menubar for some time. It functions quite good, but i can have drawbacks.
I use twinview with the global menubar as a button in a panel on screen 1. When accessing the menu from a program on screen 2 you have long distanve for your mouse.
It is working best for program/apps in always maximized environments like in the plasma-netbook.
(Nooo. I wrote a long reply, copied it (I thought) and then it failed to submit. Of course it wasn't copied properly...
So here it goes again:)
I hide the menubar in almost every application I use because I like the clean look and mostly rely on keyboard shortcuts. Having used Dolphin without a menubar for very long, here are some of my thoughts:
1. I'm not convinced yet that hiding the menubar by default is a good idea, since it hides some of Dolphin's functionality. Here are some examples of what I think first-time users would miss/not easily discover: tabs, show in groups, panels, filter bar and terminal.
Of course, this could be worked on.
2. The action I miss the most from the menubar is "Sort by". There is a toolbar action for it, but it is lacking in two respects:
a) It doesn't have a nice icon by default.
b) More importantly, the icon/text doesn't reflect its current state.
If not a better toolbar action, I would like to see it in the right-click context menu.
3. Talking about the context menu, I don't like seeing "Show Menubar" at the bottom when the menubar is hidden (I'm used to find "Properties" there). While I understand why it's there, I would prefer some other solution. My first thought was to show it in the toolbars' context menu instead, but this would lead to problems if the user hides the toolbars or if the application doesn't have any toolbars (like Konsole; this should of course be standarized across KDE applications).
Anyway, as said I don't like to have it in the top/bottom of the context menu. Somewhere in the middle would be much better in my opinion - it's not something I need often.
4. The wrench icon is for "Configure Dolphin..." I assume? How about having a menu icon (shows a menu when clicked) for the "Settings" menu instead? In that case you would also cover "Configure Toolbars/Shortcuts..." and also offer an easy way to show the menubar.
I think that was all, this time I'll make sure to copy everything before I hit "Preview". Keep up the great work with Dolphin!
@Boerny
How do you do it? Do you use Bespin or this Plasmoid? Are there any recent instructions?
Comparing those pictures the "new" obviously looks better, but (and that is a rather big but) it's not the missing menubar making the grate difference. It's all those other changes making the improvement. Using those pictures to get an opinion of removing the menubar or not is not right.
Trying out a version of the first wit and without menubar, I actually prefer with. It actually makes the interface more visually effective. As the menubar creates a visual "gap" making the eye focus on the primary are of the application, the file view.
Looks great, yet I think this kind of no-menu apps, should be standarized, with the same icon at the same place, and a new HIG should be made.
I would suggest adding the small down arrow in the menu button, like rekonq does.
Also, these “menu buttons” should be standard in every app, and put into the list of possible buttons when customizing the toolbar (no talking about defaults)
I personally think this should be the default for quite literally every app out there with exception of some productivity programs like Krita. It would be absolutely fabulous if both this and the hide menubar settings would be global, part of kdelibs or something.
This is simply the best way to deal with the menubar issue, if I may. So it goes without saying, this change is spectacular step foward.
@hans: I think that wrench button, is actually a "menu button", just like rekonq, that means it contains: File,edit,settings,etc,etc
So every feature is accesable through there.
Yet I think it should be redesigned, like firefox menu button, whichs offers the same in a different more "button menu" friendly layout.
For example putting most used features out of categories like file,edit,etc.
Hi, I have made an universal patch to hide the menu of every KDE apps when you press on ALT, it work very well to this day but was rejected upstream because of menu hiding haters. It's as good as it would have been if it was to be merged, but do the job anyway
http://forum.kde.org/viewtopic.php?f=17&t=76641
@Hans: thanks for your long reply, but I think you missed one important point: In opposite to the current approach when hiding the menu bar there will be a "menu button" at the right of the toolbar in 4.7 that allows to access all commands. This is the "wrench icon" you mention in point 4 and not meant for configuring Dolphin :-) Just check how Chrome does it to get an impression how it works.
@comments about a global menu bar or a more general approach: Personally I like the global menu bar a lot but it does not look like this will become default in the midterm for the KDE SC. But if more applications will use the approach of a menu-button (currently only Rekonq uses this too AFAIK) we should of course think about moving this functionality into kdelibs. But I'd say it is too early at the moment for this step.
I don't see a method of sorting files without a menu bar, and Dolphin has a toolbar button just for that. Also, can you review the keyboard interaction and reduce the space the "Places" toolbar takes for itself?
@Elv13: In my opinion your patch is no final solution as it still must be possible for users to access commands with the mouse that are not shown in the toolbar. It is also not enough to just hide the whole menu bar inside the "menu button" of the toolbar: Without going into too much details - the layout of the items in the "menu button"-menu are slightly different to the menu bar.
@ Alejandro Nova:
> I don't see a method of sorting
> files without a menu bar
This is still possible:
- Press the "wrench icon" on the right of the toolbar (-> a menu opens)
- Select "Sort by..." from the menu
All commands are still accessible from there.
IMHO, this feature should be globalwise, so it would be consistent with global desktop look and feel.
Probably, it would be nice to have per application exceptions, but there is should be a global list to view.
Menubar+toolbar is still much better than the Ribbon is. But the toolbar is alone much better than Ribbon is.
Ribbon has bad usability problem.
1. It changes when the window size gets changed
2. It has three different size icons
3. It has three different types of texts
4. It has far less space to use
5. The ribbon has different rows
The first problem is something what can not be avoided anywhere, but Ribbon needs more space than normal toolbars.
The icon problem exist only on Ribbon but not on normal toolbars where every icon stays by default as same size, but still can be configured to have different sized if wanted.
Third problem is that there are icons what has text under them, icons what has text a side of them, icons only and text only. For normal toolbars where there are no text or icon+text Ribbon is just flawed.
fourth is tied to first one, big ribbons takes much more space than what there would be needed by many people. Some defaults are good that most used are big but many wish all would stay at same size.
Fifth is that at one ribbon panel user can see 1-3 different icon sizes. One big icon with text under and next to it a group of icons in three columns.
Ribbon is just something what could be called "problem solver what brings as much other problems as it solves in first place".
I had used many years the KDE (and now KDE SC) where I have configured application UI's to be used without menubar. Configured the toolbars have only my chosen functions what I need mostly.
And for different people, it has been easy to configure GUI to meet their needs, were they senior users with shaking hands, bad vision and basic computer skills (= big icons + removed all un-needed functions) or younger people who just want computer to work (= default icons, customized functions and so on).
In the end the whole GUI is customized for the user so the user does not see un-needed menubar but can get it anytime back with Ctrl+M shortcut.
The Ctrl+M function really should be added to kdelibs so _EVERY_ KDE APPLICATION would use it. Not just some of the most used apps (like Dolphin, Konqueror, Gwenview, Kopete, digiKam, K3b, Amarok....).
Just disable by default the Ctrl+M shortcut so no one accidentally trigger it.
Then add a setting to system settings to enable it and set its default way (hide menubar by default).
This like is how my KMail looks http://i.imgur.com/5odNw.jpg
And how Dolphin and K3b looks
http://i.imgur.com/ozHLg.jpeg
Almost any other application follows same manner like kopete
http://i.imgur.com/bsOj3.jpeg
@ Hans
"3. Talking about the context menu, I don't like seeing "Show Menubar" at the bottom when the menubar is hidden (I'm used to find "Properties" there)."
Neither I like it there, but as well I dont want it to be top of the context menu as well. As 99.9% of times I have menubar hidden but I use context menu maybe 1-2% of the times, I want quick access to copy/cut/paste functions or so on. And the "Show menubar" at top (or bottom) is worse choise.
Please, someone add the Ctrl+M function to the kdelibs so every KDE application use it and people can use it when using Oxygen or any other style as well and not just QtCurve or Bespin! And possibility to hide the statusbar (what QtCurve allows!) would be needed as well!
@damipereira and Peter Penz:
Oooh, that makes a lot of sense. :D
I'm familiar with the concept (having used Chrome and the new Firefox), but my brain didn't make the connection "wrench icon = menu button". In that case I agree with what others have said - a better icon is needed and an arrow to indicate that it's a menu. (Yeah I know, details, details... :)
I still think that my point 3 stands, and partly point 2, i.e., it would be nice with a better way to sort than having to use the menu.
Another thing that I'm a bit concerned about is the placement of the "menu" icon - far to the right, directly below the close button. I can see how people could accidentally close the window, which would be very annoying especially if they use the menu icon a lot (optimally it shouldn't be the case though). Chrome puts it in the same place, but there seems to be slightly more room for mis-clicks because the close and menu button are farther apart in Chrome.
I can't claim to have done any studies on this, so maybe I'm overly pessimistic. Personally I don't think I would click on the wrong button, but I'm thinking about people who are less used to using a mouse and people with other, less accurate pointing devices, such as touchpads.
This looks much better, but the main concern I have is if the user will be able to discover that the wrench icon is actually the menu. I feel like some text saying menu or a drop down arrow would make it a little easier to discover.
Please see http://www.kdedevelopers.org/node/1617
I would prefer staying with the old default layout and just make sure, that Crtl+M works (I like the idea of putting that into libkde.).
When people are quite familiar with an application and know the most necessary shortcuts, they can just blend out the menu. Dead simple!
I think it would be clearer if it was the icon of the application instead of the icon used usually for configuration, or a button with its name.
KDE still is ugly as hell.
I think that what should be done is making a global hide menu bar, but at the same time automatically showing the menu button, even highlighting it when the menu is hidden.
The main complaint with global hide menu bar, is that people hide the menu bar and then don't know how to take it back, also making noise in bug trackers. But if after hiding the menu bar a menu button is shown and highlighted(it can have a glow that blinks a few times), then it's ok.
Also it seems to rapidly becoming common, so users will understand menu buttons more and more, buttons will be suspected as menus more often. Even chrome is good and only shows a wrench icon just like the screenshot(Yet I'd prefer a little arrow at the bottom of the wrench)
@Peter, reply to the hide menubar patch
Lets face it, the 80-20 rule apply here, most users use only 20% of the features or any given application. Not only do you use 20% of the features, but you use always the same, over and over again. KDE have a very nice power-solution to this, the ability to edit the toolbar content and keyboard shortcut to match those 20%, solving both mouse and keyboard aspect of accessing the feature. So why waste 30px*widt with a menu? Right, we dont, I think we can agree on this one.
It come down to the solution to this problem. The ribbon is one, it work, I use it in some of my apps. The menu button one have one big drawback. One of the pilar of KDE is consistency and reuse to elements. Every menu in KDE follow the same pattern, naming and order convention. Menu provide expected features in expected places. You know where to find configure or copy. The menu button can't provide that. While it solve the space problem (for those using toolbar only, and thats not everybody, I disabled it in dolphin because the bread navigation replace all the buttons anyway), it does not solve the consitency and accibility issue.
It make it hardter to find a feature because you cant use visual-muscular memory from other application to access the feature without thinking about it.
The universal menu higing, however, is not affected by this. Yes, it take longer to figure out that Alt with hide the menu and bring it back for a few second when you need it, but it keep the habit you already have in the application. It may be imperfect, but it is why I think it is better than a menu button.
The thing is, both are not incompatible. As long as you dont delete the menubar code from dolphin, one can disable the menubutton and enable back the menubar, I think this is a nice compromise between the two point of view.
The new screenshot has plenty of space in the "places" view, but for some reason the title of the area has been removed. Even with ridiculously low resolutions (800x480) you still have room for that title.
Furthermore you should not make drastic changes and set them as default. Feel free to make the changes but make them opt-in, at least until you've had your userbase try them on their own once or twice.
@The User: Yes, I think the Launchpad link you gave is the one being mentioned. I used that for a while on Arch (which required a rebuild of Qt and GTK in my case), and it worked well in terms of intended function. I agree with Boerny about the other problems, though.
@ppenz: Maybe I'm missing it, but how will one go about unlocking the panels? Is it just a menu toggle like Amarok? Also, if you're disabling the Information panel by default, are tooltips being used at all? I fully agree that it looks cleaner, but it does also hide a lot of useful features by default. Is there a middle-ground?
http://adishatz.1s.fr/~gnumdk/appmenu-qt.jpeg
Canonical appmenu is the way to go:
- Menu Bar like macosx
- Menu Button (current only for plasma but a kwin implementation is possible).
The Canonicals idea of menubar is terrible!
The XBar is much better than Canonicals idea what takes space, does not offer menubar better idea what is simple clear drop-down menu.
@ Anonymous
There is a already a global and standard icon for menu hiding. The wrench is wrong for that but I think it was just a example. As the default one is what is found in menubar and context menus.
You can see it from here http://i.imgur.com/RddE8.jpg
@ damipereira
There is no problem if the global menu hiding function gets implented correctly.
1. Disable menu hiding function (from menubar, context menu and shortcut) by default so user needs to enable it from System Settings first.
2. Show the (already used) information dialog when user trigger first time the menu hiding what tells what just happened and how to get menubar back. There is already a option as well a tick to not show the dialoge anymore
So there is no way the user could accidentally hide menubar and not get it back... unless user has bad memory problems and habit to click anything what sees on screen. And then any complain from such person is invalid.
Thank you for your hard working :)
I've hided the menu bar from Dolphin since kde 4.3.
Oh, and the ALT is not anyway best option to hide/show menubar.
It really need to be a combination. Alt is used for application own shortcuts and that is the problem in Windows as well, as pressing Alt+ combination brings menu up when not even needed.
Ctrl+M is such what is not possible press by mistake with left hand, while with right hand it is easy to press. Still when comparing to Ctrl+C, Ctrl+V and Ctrl+X shortcuts, a Ctrl+M is harder to use but as well it is used much less.
Alt alone is just something what should never be used for such thing.
As already the Alt is used to show drop-down menu shortcut underlines. And it should stay just as such passive visual thing or when used with shortcut combination.
Why don't you copy the behavior of Windows Explorer 7?
See url: http://www.pinnula.fr/wp-content/windows-explorer.png
I was a huge fan of KDE file explorer. But honestly the new Microsoft explorer is _really_ much better.
I really like the new approach and appreciate your work. This is because it really gets close to my config. I also hide the menubar by default. However, I have a button for it, just in case: http://img27.imageshack.us/i/dolphin46.jpg/
Some remarks to the other features:
"The Information Panel on the right is hidden" - Okay for me, but maybe there should be an indicator that it exists.
"Toolbar items where the icon is sufficient for knowing the command don't have a text. By the way: In 4.7 this can be changed by a simple right-click." - I can live with that.
"Places Panel ..." - As long as its there when Places and folders are in tabbed view it is fine for me.
"Locked panels, no buttons" - I can with the no buttons thing but I would like to have it unlocked by default. Nevertheless, this makes KDE applications more consistent in behaviour, thus it makes sense to implement it that way.
"search bar" - really nice, makes search in dolphin more consistent, I think.
After all, I would say assemble a live CD and let us users test it. Always give new Ideas a try.
I use all kde applications without menu bar.
It's integrated in the top panel (like OS X) and i use it only in some case, with advanced features, generally.
I would like more only integration with top panel when app windows maximize, for example: title (or only icon) and "min/max/close" buttons on right or left of global menu.
Ciao
Completely agree with your vision. Nice job :)
that's not kde way ;/ and there is a lot of more important issues than copying gnome/google/macOS shity designs!
stay KDE for christ's sake
@Jeffery
http://qt.gitorious.org/qt/agateau-qt/trees/appmenu-plugin
or
http://qt.gitorious.org/qt/agateau-qt/trees/appmenu
Which branch to use?
imho: the places selection looks rather "out of place" with the new layout. some of the navigation is on the top in the breadcrumb ... and some is on the left in the places bar. one is horiontal, the other is vertical. the first entries in each (sort of) line up. it's a little awkward.
i wonder if it wouldn't be better to make it more obvious in the first item of the breadcrumb that that is where you can get to different places?
this would probably rely on:
* the breadcrumb places list shows disk usage (useful / important)
* most users do not switch more often between places than they do between breadcrumb choices
* dragging to the places list in the breadcrumb expands the list and accept drops on it
that might also give room on the right for the information view which actually does expose some nice features and useful information.
just a thought :)
First of, I fully agree that traditional menu bars are ugly. BUT:
There is a solution for this problem already: a global menu bar ;)
You have clean application windows, and when you need menubar options it is still there (additionally you can put you systray in it and thus save space in the main panel).
Honestly, IMHO this button menu is a similar misguided concept as for instance vertical tab bars. Instead of inventing a new workaround, issues with the global menu should be fixed (if there are).
Really, I'm not convinced of this concept.
- A menu bar has clearly separated categories of items, which you already see before clicking anywhere. So a user normally already knows where to look for an option with out much navigation. In a button menu you have to orientate yourself only after opening it.
- All button menus will look different as there is no HIG.
- You will end up with a mixture of the two concepts (normal and button menus), as many menus are simply way too complex to cramp everything into a button menu.
- Personally I find navigating in a menubar easier than in a popup menu (especially with only a touchpad and no mouse)
- For me this button is unnecessary clutter by itself.
- If at all, this has to be globally solved. Otherwise, if this concept spreads, you'd have to disable it in each app individually.
So, please think about it ;)
About menus, I think we must build something new from scratch.
We need a successor for xmlgui to model a collection of actions that will be displayed in different views: menu bar (current default), global bar (Mac OS) , button menu (IE7, Chrome, Firefox4, Rekonq), ribbon (MS Office), right side panels (Photoshop, 3Dsmax, KOffice), full screen menu (Maemo), left side menu + full page (Meego tablet).
@megabigbug
Yea, my last year GSoC was about those kind of things, but I had to give up due to real life priorities. The fact is, it requier very little effort to write a new action view in XMLGui. It may be hard to start, but once your OK with how it work internally, its a matter of hours. I made a QDockWidget frontent to create "Toolbox" (equivalent of toolbars) and implemented some more features like the ability to place an action in the left side of a toolbar and display only icon for some actions in like 50 line of code. Those patches still work, if anybody can finish the work, it would be great, but I have no time for that anymore. The project also included aspect like actions/menu/toolbars over dbus to create custom actions view directly in the DE, but I never started that aspect of it.
But overall, I am agree, the single menu-button thing should be part of XMLgui, not custom code in every apps.
Hiding the menu is a great idea, but not in that way. It's not good place for menu and it looks bad. i really like a firefox solution. I'd be happy when I see this button like this in every KDE application. ;)
Just look: http://img858.imageshack.us/img858/1710/1234d.png
Doesn't this looks beautiful? After oxygenize, this would be really elegant.:)
I don't like removing the menu as default. I also don't like that in chrome/opera/.., perhaps because I don't use a widescreen (do so many people only watch films with their pcs? normal reading text always requires vertical scrolling..), and I do need file-detail browsing/managing extensivly for work.
A disadvantage of such a menu button is, that its submenu is even more complicated.
So I hope, that I will forever be able to switch the menu back on.
by the way: for me a "home"-button is essential in the toolbar (leftmost position), who about that as default?
There are 3 kind of apps with different needs.
1- Simple apps, like dragon player, bangarang,etc. These shouldn't have a menu, because in these apps it's just clutter.
2- Medium complexity apps, like dolphin, kwrite, etc. Normal users of these apps, will use 20% of features, mostly the 20% which ins in toolbar.
But the problem here are advanced users which use lots of features, you can't put everything in toolbar, so menu becomes a good choice too. These advanced users should be able to show menu to have fast access to features.
But I think this advanced users can also be contented with nicely organized menu button and smart gui design, like putting "new tab" button somewhere in the breadcumb(maybe not so good idea but you get the point)
3-advanced aplications like kate and kdevelop, in these apps there are more features, and they are used more, so the toolbar approach doesn't fit, in these cases maybe menu is the solution, maybe different menu buttons, very good design, and panels/ribbon would be good, but normal old menu is very good too.
A common gui for all these kind of apps is impossible, but there should be 2 higs defined, a simple one for 1 and 2 and a complex one for 3 and apps from 2 which can't make the design clean enough with hig 1.
Also hig 1 should be like dolphin/rekonq, and the menu layout should be standard (settings on the bottom, file related items first, etc)
In conclusion consistency is not only about following rules about hig, is more about how it feels, so these mostly different higs can actually be made consistent. It may be harder but it's the only way of having really good guis.
@Aaron that might be good but it's less discoverable, and windows users will have even more problems (where is My computer?) right now when people opne dolphin, they see their pendrives, their hdd, and everything.
Maybe making something like bookmark toolbar of browser for places?
Or making somethig more like My computer showing places as default instead of home.
@Aaron that might be good but it's less discoverable, and windows users will have even more problems (where is My computer?) right now when people opne dolphin, they see their pendrives, their hdd, and everything.
Maybe making something like bookmark toolbar of browser for places?
Or making somethig more like My computer showing places as default instead of home.
I agree with damipereira about the three kinds of apps. The problem with the current design of Dolphin however is that it is harder (or impossible) to use with the keyboard only. If the batteries in my wireless mouse fail (and I have no replacement at the moment), then I still want to be able to use Dolphin (and any KDE app of course) using only the keyboard (I also like to use the keyboard sometimes when my mouse isn't failing). So, the menu button should popup its menu using a keyboard shortcut specifiable by the user. In rekonq my patch for a keyboard shortcut for the menu was luckily accepted.
Great work. I especially like that the panels are finally locked by default. I always felt that the unlocked panels made Dolphin look very "unclean". In my opinion, you are just an awesome developer. You listen to users, strife to make your software better and at the same time keep the application configurable.
This is very nice! I appreciate your work :)
I'm currently using in QtCurve the option to add a menu button (M) into the window decorator to show/hide the menu bar. It is useful for apps that don't have the option to hide the menubar.
But a button like the one you added is better in general.
Why don't you enable both panels, the places and information in the same side at once? One on top and one on bottom.
Like in this screenshot (in the win-deco (M) is to hide/show the menubar):
http://img842.imageshack.us/i/dolphinwithplacesinform.png/
@ Aaron J.Seigo
"the places selection looks rather "out of place" with the new layout. some of the navigation is on the top in the breadcrumb ... and some is on the left in the places bar. one is horiontal, the other is vertical. the first entries in each (sort of) line up. it's a little awkward."
There is the mockup of dolphin breadcrumb what is possible to move like any other panel/dock.
That idea allows user to move breadcrumb top of the toolbar or even under the dolphin view.
As far I see, kdelibs needs some polishing and new features for the GUI customizing.
1. Like possibility to hide/show+move menubar and statusbar
2. hide/show+move their elements like zoom/size in statusbar (some apps like Dolphin) like in toolbars
And of course
3. Possibility have add own empty toolbars and name them. This would allow advanced users to even add more stuff to toolbars if wanted.
3. And then possibility to have toolbar buttons on the right side without making a tweak by adding a new toolbar after first and moving it to right side. This could be done simply by just having a same kind --separator-- function but --dynamic space-- or similar what would allow users to set toolbar buttons to left, middle and right side of the toolbar.
None of these of course very basic users itself could not use by default (as currently anything else currently) but it can be used by advanced user to tailor the whole GUI to them.
These would allow users to make easily really own GUI's like what could be like on Amarok where we have play/pause on left, position in middle and volume/mute on right, but without coding.
I like Aaron's idea of having a more promintent places button in the breadcrumb instead of the places panel. Perhaps you could make the Folder icon with the home symbol and the "home" text a visual union to make it more obvious.
Perhaps a button for the information panel could be in the toolbar now that there is so much space left.
Another idea would be a filter input box, which does not search, but filter the contents of the current folder. Perhaps this would also restore the visual "balance" of the bar, which imho weighs too much to the left in the screenshot.
About this proposal, I think you can go various steps further. This is a quick mockup I worked on.
http://www.megaupload.com/?d=04OAJCOJ
Don't agree with the removal of menu bar. What is the goal? "reduce clutter"? You are reducing functionality, making harder for the user to find the options/commands he wants.
Dolphin have to make me productive in files manipulation and search, not to be "less cluttered but harder to work with".
For instance, I find my self more productive with Dolphin 1.4 in kde 4.4.5 than the newer in 4.6.1 because:
a) I don't have anymore KFind fired when I press "Find", and having the nepomuck disabled (why waste so much resources and indexing so much data?) searching files by multiple criteria is now impossible
b) if copy a file over one with the same name, the older dolphin wrote "a older/newer item already exists" and the datetime was immediately shown of both, with the newer you have to enlarge the dialog window (for each file if you copy multiple existent files) and try to understand yourself, reading both dates, which one is newer.
Now you will remove the menu bar... what else???? Simply because M$Win7 explorer does and you think is "cooler"?
@markit: Those 2 issues you are mentioning should be bug reports, you are right complaining about that, but about the menu, most people don't use it, not even touch it, so having the menu in a button, makes the app less cluttered, and at least for me easier and better to work with, I can find the important stuff easier because there's less stuff that can be seen, while at the same time all the features remain.
Yet the menu button and toolbar should be optimized for this usecase.
You might be a user that likes the menubar, and uses it often, them you can press ctrl+M and bring it back, nobody told you, you can't.
But most users will feel better and do things more comfortably without menubar(when everything in the menu is ordered and some toolbar buttons are ordered.
@markit: Those 2 issues you are mentioning should be bug reports, you are right complaining about that, but about the menu, most people don't use it, not even touch it, so having the menu in a button, makes the app less cluttered, and at least for me easier and better to work with, I can find the important stuff easier because there's less stuff that can be seen, while at the same time all the features remain.
Yet the menu button and toolbar should be optimized for this usecase.
You might be a user that likes the menubar, and uses it often, them you can press ctrl+M and bring it back, nobody told you, you can't.
But most users will feel better and do things more comfortably without menubar(when everything in the menu is ordered and some toolbar buttons are ordered.
that is exactly how i want dolphin preconfigured.. i always hide the menubar (after initial configuration you don't need it anymore), i allways set the toolbar to "icons only" (it takes 1 minute to learn the meaning of all icons so no text is needed) and i already filed a request on brainstorm kde forum to lock the toolbars and remove the titles ...
please implement it right away! i love it!
thx!
http://forum.kde.org/brainstorm.php#idea85775_page1
How does it work with windows groups?
@damipereira
That are the point I find wrong.
a) "clutter" because of a simple, usual menu line vs a "multiclick or keypress" - hard to find, one button solution. Why? Why make my life/work harder?
b) "some like it that way" is not the correct way to develop user interaction.
"Less clutter" should mean that you can go directly to what you need faster and directly, not the opposite (hard to find "actions" in hidden menu).
I remember the old "slavery days" when I was under Windows and M$ introduced the new IE interface, with buttons that had no visual clue about being buttons and not just "background" and also nothing visual about their state, except when you pass over them with the mouse.
Aesthetically very pleasant, but a nightmare to use.
User interface design is for user interaction experts, not for programmers or, even worse, aesthetes.
One thing that always bugged me: Why isn't the free disk space bar showed by default?
Its one of the most important things for a filemanager to do imho, and it doesn't take much display space anyway.
@anonymous:
Removing options that are not so used, makes really used options easier to find, I feel comfortable without the menubar, because I don't use it, and when I'm looking at the toolbar, my brain thinks about the menubar too.
About additional menu clicks, they shouldn't be, unless for not common tasks, because the menu button, will be like firefox menu button (I hope) so important stuff is still there, while things like "help" and "go" don't clutter with options that aren't used or are available on the toolbar.
I'm not saying this solution work for everyone, as I don't feel comfortable with a menubar, some others won't feel comfortable with no menubar, we are all different, that's why it can be configured, but still, if done right, that "multi clicking" won't happen, even there will be less clicks, as you can't miss when looking the option it's all in one place.
OMG ! You DID it ! You hid text for some actions but not some others on the same toolbar. How did you do ? Is it a work-around for Dolphin ? A component in KDE ? Or can I do that on my Qt app ?
Just a suggestion : IMO, you should keep the search field near the "config" button.
"Those 2 issues you are mentioning should be bug reports, you are right complaining about that, but about the menu, most people don't use it, not even touch it, so having the menu in a button, makes the app less cluttered, and at least for me easier and better to work with, I can find the important stuff easier because there's less stuff that can be seen, while at the same time all the features remain."
So lets make the easy and already working thing and move Ctrl+M functionality to kdelibs where it has been wanted since KDE 3 times instead it being implented per application.
I dont use menubar than in actually one application and it is having changes for that, still keeping the menubars available!
Most used KDE applications what most even belongs to KDE SC, supports the Ctrl+M functionality. But not all and that is the problem what can be avoided by using a QtCurve or Bespin styles.
But reasoning to move application controls to window decoration is not wise at all. Window manager is a own program, it is not part of the application what people see. They have two totally different jobs and window manager is more important because it takes care of the window management for the user. If it crash, it can be restarted. If user does not like it, it can be changed. If user does not like a style, it can be changed. If user does not like decoration position, it can be moved.
Now there is a "great idea" that menubar is bad and it needs to be removed.
No, menubar is not bad at all. The problem is that it is on the way. The drop down list is one of the best ones. It is very fast to read and clear. (It needs little tweaking tough like for touch screens bigger fonts/entries but it is possible already do!).
Drop down menubar functionality is not broken, so dont fix that.
Window manager is not broken, dont fix that either.
What is broken, is that Ctrl+M functionality is not in kdelibs. It is not a global functionality to all KDE applications. It is not possible to change shortcut globally but only per app. That is broken.
Fixes for most problems (without cousing more than these ideas to join window manager and menubars) is:
1. Add Ctrl+M functionality to kdelibs so every KDE application use it
2. Disable the Ctrl+M shortcut and/or functionality by default so user need to enable it from system settings if there comes lots of problems by people hiding menu by accident and does not know how to get it back.
And thats it. We fixed the visual problem, while maintaining many other features like:
- Having a different window manager than KWin (there are those, not all use same KDE SC as default)
- Having a other window decoration than Oxygen but like BII, Nitrogen or even like Bespin where decoration can be in the side of the window!
- Having a different setup of window decoration buttons, like Mac OS style or like I do have, no buttons at all!
- Having a easy and big place to drag, resize and any other way control the window (close window, shade window, minimize window, maximize window, on all VD's etc etc! The "move from any empty space" does not help there, neither does Alt+Mouse button 1/2!
@Emmanuel Bourgerie
"OMG ! You DID it ! You hid text for some actions but not some others on the same toolbar. How did you do ? Is it a work-around for Dolphin ? A component in KDE ? Or can I do that on my Qt app ?"
Just go to configure toolbar buttons (right click toolbar) and then from right side of set buttons what are shown, select one and click "Change text". There you have a tick to hide text if it is configured to be a side of icon. This feature came at KDE SC 4.5 release. And I had mockups and bug reports for this features maybe since 4.1 that there would be a tick in the list side of the icons without need to go "Change text" button to select it.
There is 1 problem with the global "hide menubar" it can't be default, anywhere, if you want to give users default uncluttered dolphin, that can't do it, I think that if it's done right, it will be better than normal menues.
advantages:
1-Less clutter. So it is easier to find things.
2-Saves space (you notice on a netbook)
@Fri13:
Why not implement this ctrl-m feature like this:
you hit ctrl-m -> if the windowmanager supports this, show menu as menubutton in windeco, else hide it completely
if menubutton is already in windeco (because of prior ctrl-m) and you hit ctrl-m again -> hide menu completely
hit ctrl-m again and menubar is back!
______________________________
OR - provide an option in systemsettings
(*) ctrl-m hides menubar completely
(*) ctrl-m switches between menubar and menubutton
so everyone shoud be pleased
one quick question:
the "new" screenshot has this configured toolbar that looks very similar to my own configuration..
BUT i always add the "up" button beside "go back" and "go forward" and a "reload" button (which is often needed on networkfolders etc.)
what is the reason this buttons are not in the default config.. "go UP" is very essential i think when working with lots of "places" so "go back" is no replacement for "go up" because it leads to an other folder somewhere in the system...
thx anyway! dolphin is becoming a great alternative to konqueror
@xapient: I think up button is not included because you can click on the precious folder in the breadcrumb (the place where you have the current folder), So usually it isn't needed unless you're used to it.
I've always had it in my toolbar too, but I decided to start using the breadcrumb and found no problems.
I think this is definitely a move in the right direction. Still I believe that Martin Graesslin's idea of putting this button in the decoration is better because:
1. it would work with all applications that support d-bus menu (most apps) - no need to rewrite all the apps to ensure consistency.
2. It looks better (opinion).
3. Again, consistency! And economy. Everything that's needed is already in place, all is required is to modify the decorations.
Martin's idea:
http://blog.martin-graesslin.com/blog/2011/03/menu-button-inside-window-decorations/
But yeah your concept is spot on, and it's always good to see this kind of initiatives, so thank you for your work!
(P.S. I love the new search bar!)
because my primary work not includes IT tech I just love KDE, I don't know where to write my idea and I hope someone will read this and make it real,...
so I have 2 suggestions:
- put the buttons: icons, details columns in one icon (saved space). Preview as separate icon (or check box) so user will be able to preview the context of the: text doc, pictures even videos with possibility to play. Put option to chose where will be the preview window (left, right or bottom of the opened window)
- Navigation through the folders ??? similar as nautilus- elementary,... I like that.
USE WINDOW DECORATION (background of the folders),... white is boring.
Looks nice, congrats on taking such a brave decision. Should testdrive Dolphin again on my GNOME desktop.
Dolphin is absolutely the best file browser. Period. Dude, you rock! Did you ever think about making mouse forward and backward buttons work out of the box?
What is this obsession with saving screen space. Not everyone is working on 11" laptops...
It still looks messy and confused. e.g. Why do some icons have text associated and others not?
Also, you've committed the change already before getting feedback? Maybe a designer should look at it.
Nice simple interface! How about replacing the wrench icon with a gear... it is (or can be) nice and simple and stresses that it is a KDE program. And it strengthens the KDE brand :)
I don't miss the menu bar in chromium either but I like to keep it in other apps than the webbrowser. Dolphin looks too simplified as you show it - IMHO. A subjectively perfect dolphin window layout for me looks like this: http://secretpicdump.com/de/view/11766_2a30b_dolphin.jpg/
But it's a nice idea to give the user more control over the layout of the interface.
Returning to a previous folder, keeping into view the file or folder that was selected: This would be a great feature for Dolphin.
Who does not hate having to rescan a file or folder that had already been selected?
Awesome work, blazing fast performance and really great transitions. Love it! Hats off to you!!!
What is this obsession with saving screen space. Not everyone is working on 11" laptops...
And not everyone are using applications in fullscreen or having 100 icons all around window.
The idea of having single drop list to configure is terrible, now when it is been in use almost half a year.
The configuration button should be go away. It should not be placed to window manager either but it should not be forced to be on right side of toolbar. Now people can not hide toolbar as they dont have access to the menubar what is hidden as well.
And it takes space and looks bad on right side.
Really man,
after you gnomeyfied dolphin im not sad that you leave the project.
I think its better when someone takes it over which have a real passion for well integrated desktops for non-noobs
Post a Comment