← Back to team overview

unity-design team mailing list archive

Re: Unity and Menus

 

Building on that, it was my understanding that every action should be
placed in the menu, but that frequently used actions should be echoed in a
button/toolbar.
On Jan 22, 2012 8:37 AM, "Christian Rupp" <christian@xxxxxxxx> wrote:

>  Am 21.01.2012 00:39, schrieb Jonathan Meek:
>
> In my spare time, I'm working on creating a traditional windowed
> application that will have a menubar. I find it important to integrate with
> Unity, leading me to an important question: What behavior is the best to
> adopt?
>
>  As I see it, there are three options:
>
>    1. I can have windows each have their own specific menubar as needed
>    and let Unity take it out and put it in the top as is usual now.
>    2. I can push the application to use only one window so that the
>    menubar becomes a non-issue.
>    3. I can work on an application-wide menu.
>
> And for the issues I see with these approaches:
>
>    1. This creates inconsistencies with the launcher being
>    per-application in its design. The launcher is based on the application,
>    not on its constituent windows.
>    2. Not all applications can force their system into a single window
>    interface with the limitations of current GTK technology. (At least to my
>    own satisfaction given the different models needed for different aspects of
>    the application.)
>    3. The way that Unity currently grabs the menubar from applications is
>    on a per-window basis. More or less literally ripping the menubar from the
>    application. This makes any application-wide menu feel like a hack
>    personally.
>
> I feel like it's obvious which approach I'd prefer, but I'm interested in
> feedback in which scenario is the one most in line with Ubuntu's future. I
> know that one of the ultimate goals stated my MPT was to be able to provide
> a default set of menus for every application. Then again, we have one of
> the default applications forgoing menus altogether (Ubuntu One Control
> Panel).
>
>  So which approach is condoned?
>
>  Additional question: What should the nomenclature of menus be? Are we to
> adopt the inherited behavior for classic GNOME applications where the first
> menu name should be relevant to the application? (I.E. Rhythmbox's first
> menu being named "Music", or Empathy's "Chat")
>
>  Or the adopt the newer GNOME behavior that will appear when using an
> application on OS X? (I.E. The name of the application being the first menu
> [in my opinion alleviating some of the global menu design issues] found in
> this link <http://developer.gnome.org/gtk3/3.3/GtkApplication.html> from
> another recent Ayatana posting.)
>
>  Thanks for your time.
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> pMore help   : https://help.launchpad.net/ListHelp
>
>  I think this is one of the main problems in the unity design. If you want
> to be shure you'll have to wait for the HIG for Ubuntu.
> Problem: They won't be finished or partly available in the next few months.
>
> What I would do:
> It depends on the app you are planning...
> But I would try to use one window and maybe some small windows for
> settings. If you want to be really great you can look up morphing windows,
> but I don't have any idea how thei are working, just like the idea behind
> them
> Also you have to reduce clutter.
> If I have understand the idea behind the design of ubuntu: Every action
> which is performed regullary should get a button, things like settings or
> very rarely used actions should be put in the menu, but as I said: it
> depends on the app and on its complexity
>
> Sorry was in a hurry
>
> Christian Rupp
>
> **
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

Follow ups

References