Registered Member
|
Look at the menu button at the top right of your window. That one on the far left, just above the Back button. "File". Now click on it.
In Konqueror, you'll see: "New Window", "New Tab", "Open Location" (which, by the way, just highlights the location bar (huh? Why do we need a menu option for that? (Yay parentheses (OK, enough with the parentheses already)))), "Open File", "Sessions" and so on. Now, think about what a, "file" is. Usually something in a folder. A document, a spreadsheet, and in the computer world, sometimes an image or a music file, among many other things. So what, pray-tell, does opening a new tab have to do with files? What about a new window? Printing a web-page, anyone? All right, so some of these might apply better if your Konqueror window is actually pointed at a local file, but... it's a web-browser. That doesn't help justify the, "quit" option though. I'm sure that's nothing to do with a file, rather the application. Otherwise it would read, "close", as in, "close this file", no? It's not just Konqueror, either: check out Kopete. "File". Setting your status, anybody? Huh? OK, what about creating a new contact group? Exporting contacts, all right: that is appropriate, but adding a new contact? How about quitting the application? Choqok: A new quick post? Updating timelines? "Mark all as read"? Oh look, there's our trusty, "quit" option. In KMail, the first 5 options ("New", "Open", "Save as", "Import messages" and, "Print") COULD have something to do with files IF you treat E-mails as files. After that, it stops though: checking your Inbox? How about working offline? You get my point. "File" hardly represents the contents of that menu any more, but it's still all over the place, apparently not really giving any proper context to what you're actually going to do after you've clicked on it. There's two proposed solutions to this idea: the first is simply replace the menu's text with the application's name, such as, "Konqueror". This is already done in Amarok, and it is at least forgiving of the consistent, "Quit" option. The other is to change the menu's text depending on what you're doing in that application. In Konqueror, as a web browser, it might show, "Page". Since Konqueror is more than that, it might change depending on the KPart in use, but that might be a rather horrible experience. Kopete would show, "Contacts" (and probably move the, "Status" sub-menu to the bottom-right, where it already is), and Choqok would show, "Timeline". Amarok would show, "Track", GWenview would show, "Image" or, "Picture" and Dolphin would show, "Folder" or... well, all right, maybe, "File". MAYBE. The first option is simple and forgiving, the second one... not so much. Discuss!
Madman, proud to be a member of KDE forums since 2008-Oct.
|
Registered Member
|
I've got a great idea... how about we get rid of the whole top menu altogether because nothing is ever organized properly anyways, and we'll call it a ribbon!
On a more serious (and less catastrophic) note, I like this idea, but I would definitely stick with just the application name. The rest ends up being inconsistent from app to app, which is not good. But it may make sense to make a more sensible menu template now, and make a new set of guidelines for what goes where (eg: maybe "settings" goes under an edit menu, because you are editing them. This particular example is awful, but you get the point). |
Registered Member
|
Using file is legacy and really only used because that is what people are used to and we are creatures of habit. I remember first seeing it in old DOS text editors when you were editing an actual file.
I really like the idea of using the applications name. |
Registered Member
|
Thats just shocking 100% true. File menus are only for files.
|
KDE Developer
|
KDevelop-menubar ftw!!!
There is a “session”-menu for quitting etc. and a “file”-menu for file-management. But some of your points are really wrong. A website is a file, too. And when you want to print, open or close one, the file menu is just correct. I do not think that there is any important difference between “page” and “file”. PS: Sorry, I had problems with the Ajax-interface and posted three posts. |
Registered Member
|
Like already said it is just a habbit to have file menu. But I agree that it is more human-oriented to have menu called with app name, just like macos style. And as developer that familiar with qt and kde I think it is will be a top notch to have ability to make some parts of menu be standart from app to app, like help always contents about app and about kde actions and context help to application, and there are always first menu item called as app and have some standart tasks like close\quit.
So I think it can be more wide idea to have some framework addon, some class (KApplicationMainMenu or smth like that) |
KDE Developer
|
Fortunately many applications already replaced the “file” menu by the application name or any other action that is actually done there. Kopete for example has “Chat” as first menu
|
Registered Member
|
There has been discussion on this in the mailing list, but I don't think a decision was reached.
Man is the lowest-cost, 150-pound, nonlinear, all-purpose computer system which can be mass-produced by unskilled labor.
-NASA in 1965 |
Registered Member
|
I'm not sure that's an improvement. Because I seem to remember (don't use kopete myself anymore) quit is still under that menu even though it's called Chat. Quit has as little to do with "Chat" as it has to do with "File".
OpenSUSE 11.4, 64-bit with KDE 4.6.4
Proud to be a member of KDE forums since 2008-Oct. |
KDE Developer
|
I disagree. Quit has more to do with the actual “Chat” than with a “File” which you arenâ��t dealing with. You quit/close the chat not a file. |
Registered users: Bing [Bot], Evergrowing, Google [Bot]