This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature

Alacarte: GNOME's long overdue menu editor

By Bruce Byfield on September 19, 2006 (8:00:00 AM)

Share    Print    Comments   

The Alacarte menu editor is one of the major additions in GNOME 2.16. Already previously available in Ubuntu and other distributions, Alacarte adds a degree of customization that has been generally lacking since GNOME dropped its previous menu editor more than five years ago during the early 2.x releases.

Running Alacarte through its paces using the Ubuntu 6.10 alpha release, I found it a welcome addition to the GNOME desktop, but it is weakened by inconsistent positioning of new menu items and several behavioral flaws.

Desktop menus are highly structured by definition. Because it mirrors them, so is Alacarte. On the left, the editing window displays a tree view of the Applications menu, and, in Ubuntu's case, the System menu of the GNOME panel. The Places menu, which is mostly for navigation, is not available for editing. Nor can users add top-level menus.

Within the Applications and System menus, though, users can add applications and menu separators, and nest menus however they wish. The middle of the editing window displays each item, with a check box beside to enable its display. From the right-click menu, you can edit the name and icon of each item, or, alternatively, delete it altogether or restore its default properties. For those who have been too rash with their customizations, the Revert button on the bottom restores all menus to their original state.

On the window's top right are tools for adding new items. Although everything else about Alacarte is simple enough that you can start using the application almost immediately, these tools are inconsistent in their behavior. New menus are added to the top of the middle pane, new items to the bottom, and separators below the currently highlighted item. Fortunately, new items can be dragged and dropped into other positions, or repositioned with the Move Up and Move Down buttons, but consistency is still needed; perhaps all new items could be added above or below the highlighted one, or at the top or bottom if none is currently selected.

Alacarte also shows a few other rough spots. At times, performance is sluggish enough that users can easily add two new items in their impatience for a response. Similarly, clicking the Revert button occasionally has no effect, or duplicates a highlighted item. More seriously, items that are hidden by default can be neither displayed nor deleted, although whether this is a fault of the application or a decision made by Ubuntu's developers is uncertain.

In addition, I am surprised that Alacarte has no provision for editing menus for all users. Not that controlling users' menus is needed for security -- that would only be useful for the discredited idea of security by obscurity. Rather, such a feature would be a relief to sysadmins who have to set up mass desktops.

However, that is probably too much to ask of an application that has just reached maturity. Despite its shortcomings, Alacarte is still vastly preferable to either of the two extremes of the last five years: A fully loaded menu like the Debian ones, which creates a labyrinth in which users can wander lost for days, or a minimalist one, which risks users never discovering most of the applications installed on their computer. With Alacarte, GNOME menus are finally back in the hands of the users, which is where they belong.

Bruce Byfield is a course designer and instructor, and a computer journalist who writes regularly for NewsForge, Linux.com and IT Manager's Journal.

Bruce Byfield is a computer journalist who writes regularly for Linux.com.

Share    Print    Comments   

Comments

on Alacarte: GNOME's long overdue menu editor

Note: Comments are owned by the poster. We are not responsible for their content.

Editing other users accounts

Posted by: Anonymous Coward on September 20, 2006 01:48 AM
There are other admin tools in gnome that allow editing the desktop and menus for other users. What's nice is that you use the same alacarte editor inside an embedded session.

Sabayon.
<a href="http://www.gnome.org/projects/sabayon/" title="gnome.org">http://www.gnome.org/projects/sabayon/</a gnome.org>

#

The Trouble With Editors

Posted by: Anonymous Coward on September 20, 2006 01:52 AM
The trouble with editors is that they must be learned, and their specifics must be remembered in order for them to be truly useful. Consequently, if they are non-intuitive in any way, they won't be used, and simply ignored by most end users. The previously observable fact that VCR's were perpetually blinking "12:00" in living rooms everywhere throughout the 1990's is proof of this fact. You didn't need a degree in VCR programming to set them, but you often times had to get the manual out to set them. Only typically people such as unlucky husbands who needed to keep peace at home by programming their VCR's to tape the wifes daily "soap opera's" actually committed their specifics to memory.

Ms Windows "Start" menus since Windows 95 required no special knowledge to manipulate them because their Start menus are just regular "folder/directories" in the Windows directory. Since the "Program launchers" in this folder are just sub folders and shortcuts (.lnk) to the executables, they can be cut-copy-and pasted, or dragged-and-dropped. All simple functions that are used daily by everyone in the course of normal computer use. A simple right-click on the start menu button--then left clicking explore--opens that folder. The start menu can then be customized to the end users liking, effortlessly. Far more user friendly than the idiosyncratic menu editors in KDE,Gnome, or other GNU/Linux GUI's.

Of course with Windows bigots in the GNU/Linux GUI development communities, we can't re-use, or copy anything from the Windows GUI, even if it is easier, cleaner, and more efficient, simply because it is from the Windows GUI.

In the specific case of Applications Menu editing, The Windows method is far easier for the normal end user to use. That makes it superior IMHO, and if GNU/Linux was truly a code meritocracy, and not just a collection of maniac Ego's, the Ms Windows method would be logically adopted globally, and as a consequence allow us to rid ourselves of some currently useless code bloat.

Flame-On...

#

Re:The Trouble With Editors

Posted by: Anonymous Coward on September 20, 2006 07:07 AM
[i]but you often times had to get the manual out to set them[/i]

How difficult. Actually, levels of literacy are considered a measure of a country's development for a reason.

[i]
Ms Windows "Start" menus since Windows 95 required no special knowledge to manipulate them[/i]

Yeah, because selecting "Start" to shutdown is like, SO intuitive.

[i]Of course with Windows bigots in the GNU/Linux GUI development communities, we can't re-use, or copy anything from the Windows GUI, even if it is easier, cleaner, and more efficient, simply because it is from the Windows GUI.[/i]

Actually the phrase "Windows bigot" refers to someone who can't see that Windows is a steaming pile of crap, and disses every other platform. As for not "reusing or copying anything from the Windows GUI", Windows bigots usually accuse KDE of doing just that.

#

Re:The Trouble With Editors

Posted by: Anonymous Coward on September 21, 2006 03:09 AM
Please, do us a favor and don't post such achievements any more. You should rather try to put some real answers to the questions, which includes:
1) not to point to the gramatical errors when you can't find anything else to argue (not to mention your faschist opinion that not mastering english has anything to do with literacy: there are other languages outhere, doh.)
2)not to focus on a nonperfect detail when the whole fits perfectly (start menus as folders)
Thanks

#

The trouble with the "Start menu"

Posted by: Anonymous Coward on September 21, 2006 02:49 PM
Ms Windows "Start" menus since Windows 95 required no special knowledge to manipulate them because their Start menus are just regular "folder/directories" in the Windows directory.

Except that a menu is a menu, not a directory of files. You must be the type of person that uses Excel to do the job of a database because databbases--even MSAccess--are "too complicated". In botch cases it can serve the basic purpose but even the most basic of special needs are not addressed without kludges.

Of course with Windows bigots in the GNU/Linux GUI development communities, we can't re-use, or copy anything from the Windows GUI, even if it is easier, cleaner, and more efficient, simply because it is from the Windows GUI.

Except the reason the GNOME community does not emulate this particualr Windows characteristic isn't because of being "bigoted"--it is because the start menu is basically a colossally stupid idea. The Free Software UI developers can and do emulate what does work in MacOS and Windows. You are just conveniently ignoring the blatant shortcomings of the start menu:

* Have you forgotten what Win95 was like to newbies, and how Windows still is to newbies?

      Expert: "No, don't hit the off button on your PC to shut down--you might damage files!

      Newbie: "So how am I supposed to turn this thing off?"

      Expert: "You click Start, then...."

      Newbie: "I press a button called START to STOP my machine? What kind of idiot came up with that?"

* The start menu is all about hiding things, and it frustrates beginners.

* Selecing an item nested several levels down is cumbersome and inefficient, and MS buried items way too far in--by default everything useful should be on the first and second levels.

* NOTHING is at a "hot spot" like the edge or corner of the screen.

* The "start menu as file folder" prooved to be insufficient. You neglect the fact that much of the start menu configuration is buried in the closed, hidden, monolithic, binary-encoded registry--making the start menu a rather IRRegular folder. Before XP what determined the ORDER in which menu items were displayed? What determined what items were hidden? THE REGISTRY. You have to edit the registry or....USE AN "EDITOR"... to determine such behaviour. Now there are TWO places to configure the start menu--the filesystem and the registry. At least if it is ALL in an editor then it's all in one place.

* The start menu is too dynamic in XP--what appears in front always changes and there doesn't seem to be much logic in what appears front-and-centre when you click the Start button. I presume it is supposed to be the most recently and/or most commonly used apps, but how it works is STILL a mystery to me. I use SQL Server Enterprise Manager all the time on one machine and it never seems to stay on the main start menu. I use some other app once or twice and it seems to make itself at home permanently. It doesn't stay in any particualr order (alphabetical or amount of usage or most recently used). If it makes a power user scratch his head it must really confuse beginners

* Windows provides the ability to "pin" items to the sart menu to address the above, but how to do this is completely unintuitive to a beginner--it is not "discoverable"

If anything GNOME should concentrate on making its application menu EVEN LESS like Windows. We have to be gradually but completely weaned off the flawed concept of a "start menu" and get people more used to a well designed "toolbox" or "dock". *Well designed* is the key--whether it was MacOS X or CDE or whatever there have been flaws. I cannot give all the answwers but threr are things to consider for such an app menu

* make it accessible--the F-keys were useful at one point, and a GUI could make them even more useful today. GUIs really put way too little emphasis on effective use of keyboards. Make it easier to use the mouse--make sure the dock stays on the edge of the screen or build "resistance" into the outside edges to make the target area larger. Resist eye-candy that can be disorienting like that "bulgy" effect thing that Apple put on the Mac's dock. Make sure it works well for alternative interfaces like those for the blind (audio or tactile)

* make configuration more integrated with the behaviour of the menu...avoid as much as possible a distinct and separate "editor" application and make maximal use of drag-and-drop and contextual menus

* DON'T try to make it "smart" and have the computer alter the configuration of the menu without user intervention or approval. That "feature" of the Windows Start menu is infuriating to most new users (and many seasoned users).

* Do a lot more user testing--get your grandma to use it, get Mac users to use it, get Windows experts to use it, get someone whose never used a modern GUI to try and figure it out...but be really careful not to fall into the trap of copying Windows or MacOSX simply becasue the test subjects have been habitualised to work with a counterintuitive aspect of the UI.

I think that the need for a discrete "menu editing" application indicates that more work has to be done to improve this aspect of GNOME. It is a good stopgap but we need some "bold innovation" to try out more radically different ideas...and we will know we've achieved success when "menu configurators" or other such editors are abandoned because users are so satisfied with how the menu itself works that they forget all about the editor.

#

Re:The trouble with the "Start menu"

Posted by: Anonymous Coward on September 21, 2006 10:33 PM
I will readily agree with your points regarding the specifics of Windows XP. I will add that it is apparent (at least to me) that the way XP's Start menu is arranged by default is far more a matter of "Monopoly Maintenance" than end user usability. An obvious attempt to steer all users to their preferred applications. Also, that their menu enhancements (and many others) are more hindrances that add to the confusion. Choosing the "Classic" mode and disabling all the misguided MS extras, while you lose the eye candy in the process, is far more navigable to most casual end users.

[Except that a menu is a menu, not a directory of files]
A menu can consist anything that you want. Why not leverage and end users prior knowledge (cut-copy-paste--drag-n-drop) when setting up a GUI? Even now, in GNU/Linux GUI's, KDE/QT has "Quick Browsers" that will turn any file folder into a menu (you can actually fashion a Windows style, drag-and-drop replacement Applications Menu in KDE using a quick browser . It's incomplete as such, because to properly implement it would require a hybrid config/directory similar to MS, but it demonstrates how easy KDE could move to that way of doing things if they so desired.

The basic code also exist for Gnome/GTK to implement these type of menus (named: file menu applet) contributed to the community by Benjamin Khann, and was used as an optional add-on applet in earlier versions of Gnome. It would assist Gnome developers also in implementing these type menus easily, with the side benefit of adding the general option of user selectable cascading file menus (Quick Browsers) to Gnome. I will also add that the File Menu Applet is a far better/more complete and mature implementation of this feature than the KDE Quick Browsers. KDE's Quick Browsers are incomplete lacking right-click-context menus, so drag-n-drop is the only option when using these menus directly.
[You must be the type of person...]
The type of person I am , is one that , as logic would dictate, caters to the needs of the most un-savvy end user when setting up a computer. Reasoning that the un-savvy can get their work done with little trouble that way, and the more computer literate users (being more literate) can make any changes to that default setup that they have a mind to. Also, these more literate users, having seen, and hence are now privy to the default layout, can easily help the un-savvy users over whatever rough spots they might be experiencing.

[* The start menu is all about hiding things, and it frustrates beginners.]
[* Selecting an item nested several levels down is cumbersome and inefficient, and MS buried items way too far in--by default everything useful should be on the first and second levels.]
I never suggested that these menus should be copied exactly or to use the MS defaults. And, you are correct on the usability point of having to look too-far-in. Even within Windows the Start menu can be easily customized to be exactly like any GNU/Linux Applications Menu. Simply by making new corresponding folders--then copying their favorite program shortcuts from the (catch-all) Programs folder to those (now top level) folders.

[* NOTHING is at a "hot spot" like the edge or corner of the screen.]
Nothing is so aggravating or more confusing to the un-savvy user than a bunch of applets floating around the desktop. "Clean is Kean" every extra/unnecessary item or additional design element/concept that exists on a GUI drags an un-savvy end user progressively deeper into a mind screwing (cognitive dissonance) that confuses them and even overwhelms them. I don't expect developers to understand this, because they don't deal with the profoundly computer illiterate on a daily basis. Those of us who see their clients as more than a wallet that needs to be lightened, and who truly care about their users computer using experience, must factor these issues into their end product.

I'm Skipping to the end because this is all the time I have to reply--Sorry..

[I think that the need for a discrete "menu editing" application indicates that more work has to be done to improve this aspect of GNOME. It is a good stopgap but we need some "bold innovation" to try out more radically different ideas...and we will know we've achieved success when "menu configurators" or other such editors are abandoned because users are so satisfied with how the menu itself works that they forget all about the editor. ]

Agreed. However, I think the "bold Innovation" you seek would be in the act of separating the Applications/Start menu from the Documents/Places in the form of an second Menu. Gnome (to their credit) has already done this to some degree, but the lack of the ability to cascade the "Places/entire computer" (file menu applet) in the same fashion as the Applications menu, makes it an incomplete implementation of a good idea.
Many people coming from MS Windows have previously made extensive use of "Tool-Bars" (functionally equivalent to file-menu-applets/Quick-Browsers) in Windows, and it's a tough give-up when moving to the GNU/Linux GUI's in their current states. They're not meant to replace the file browsers, they are simply a Quick way to get to-or see where things are. The best real-world analogy that I can think of is. "Cascading Menus are to File browsers, what Tool- Belts are to Tool-Boxes" They serve roughly the same function, just in a different way in their specifics. What's almost exciting about implementing them properly in a Linux GUI, is that with the linking capabilities inherent in the Linux/Unix kernels, the entire computer with all disks and drives, and even the Network can be cascaded. This can only be done properly (avoiding the too-deep problem you mentioned) in MS Windows by mounting the Desktop in a Tool-Bar and then mounting the users individual core Documents folders directly on the Desktop. i.e. My Pictures, My Text Documents, My Movies, My Music etc... I noticed that some people (Newsforge's Robin Roblimo Miller appears to like this style. Having seen how he sets up his desktop when he did a How-To on Open Office) like to do this anyway.

On a personal note:
I have been mounting the users My Documents folder in a tool bar by default for as long as I can remember. No complaints, but many who are now addicted to this method. Considering that the various GNU/Linux desktops refuse to implement these menus properly, I kind of screwed myself as far as moving them to GNU/Linux. Which is something I very much want to do, however, but it ain't going to happen without them. Not anytime soon anyway....

#

Hot Keys

Posted by: Anonymous Coward on September 20, 2006 02:49 AM
Does it support hot keys as easy as Windows? That's one of the things that I find very annoying. I want to be able to click on a menu item's properties and be able to setup a hotkey for it, not just some system defined hotkeys as it appears right now in Gnome.

#

hot keys rule!

Posted by: Anonymous Coward on September 21, 2006 02:56 PM
Agreed that hotkey support is lacking, though I'd say that even in Windows keyboard support is very badly implemented. In both environments it is unacceptably difficult to navigate by keyboard.

#

Be kind

Posted by: Anonymous Coward on September 20, 2006 07:18 AM
Alacarte is developed and maintained by a student, with no help from the Gnome project. Gnome leaders should be ashamed for ignoring such an important tool for so long- users have been asking for a menu editor ever since they removed it all those years ago.

Thank you for Alacarte, and I'm sure the developer wouldn't turn down a bit of skilled assistance.

#

Re:Be kind

Posted by: Anonymous Coward on September 21, 2006 03:17 PM
Alacarte is developed and maintained by a student, with no help from the Gnome project.

It is a laudable effort indeed...it is a testament to the spirit of Free software that it is even possible for a "mere student" to make such a contribution.

Gnome leaders should be ashamed for ignoring such an important tool for so long- users have been asking for a menu editor ever since they removed it all those years ago.

However, you could also say they should be proud of themselves for dedicating so much of their time and effort to keep GNOME moving forward and contributing soch a fine desktop to the Free software community. Obviously there are outside contributors who find so much merit in GNOME that they feel compelled to make their own contribution. Bless the GNOME team for fostering such devotion and inspiration.

Also, heep in mind that the culture of the GNOME team is very "far-sighted". You have to think from the mindset of the kind of people wo were on the original Mac design team for example. That is the approach I take. I'm not thinking a menu editor is an "important tool". Why do you say that? What makes it important?

I'd say if users are saying "we need a menu editor" and dedicated users feel the need so bad that they develop one on their own then there are flaws in the design of the menu itself. I think that is the reasoning behind removing the menu editor from GNOME in the first place. However perhaps the GNOME team is TOO farsighted. An ideal applications menu would NOT need a menu editor so they got rid of it in the interests of efficiency. However they did it too soon--before a proper redesign of the menu itself was in place.

As great as a-la-carte is I think it would be a mistake to incorporate it as a standard part of GNOME. What should be done is to examine what it does and how it might be done better, then incorporating such configurability RIGHT INTO THE MENU in the most intuitive way possible--perhaps using parts of the code itself if it proves useful. However GNOME has to resist the urge to throw "configurator" applicaitons at everything. The KDE project has long suffered from this in the interest of making power user tweak-fans happy and is the prime reason why I found myself moving to GNOME as my preferred desktop environment. Ultimately having too many in-your-face applications for setting up HOW to do things gets in the way of actually DOING things on your computer.

#

Re(1):Be kind

Posted by: Anonymous [ip: 12.169.163.241] on November 13, 2007 08:50 PM
Meanwhile, while you're over-thinking this, there is still no way to customize the freaking gnome menus. Except for Alacarte, thank you Alacarte developers, who went ahead and created something useful instead of sitting around thinking and waiting for the ideal moment to arrive.

And you wonder why people say gnome sux :P

#

How to Distribute Alacarte menus?

Posted by: Administrator on November 14, 2006 01:26 AM
I would like to distribute alacarte menus to several users on my system. How do I go about this?

Thanks,

Peter D'Souza

#

Re:How to Distribute Alacarte menus?

Posted by: Administrator on January 02, 2007 11:09 PM
Sabayon (The user profile editor) lets you create profiles for different users. It will set up a desktop and monitor all the changes you make within it (etc - menu edits with alacarte), then it will apply them to the users you specify.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya