[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ayatana] File menu



I agree the File menu is not needed for the Calculator example because
really all it would  would only contain Quit. But I have seen some
applications do that and think it is OK. But it would be a waste of
space on an app with such a small menu.

What I was really objecting to is overloading application menus (such
as Calculator) with things that have traditionally been on other menus
(such as quit / copy / paste). Now I see that both the File and Edit
functions have been combined nicely on a single Calculator menu, but
it is really a File-Edit menu (should this be called "System" since it
is functionality that interacts with the rest of the system rather
than only the application?).

And really the "Calculator" specific functionality is found on the
"Mode" menu, which could arguably be on a "View" menu. I already know
it is the Calculator and don't need a menu named that..

I guess what I fear is that getting rid of these conventions without a
suitable replacement will make it hard to find common functionality in
applications. Maybe "System" stuff should be moved out of the
application to a common place in the shell and a callback mechanism
provided to notify the application, but this would be really hard to
get right and give applications the proper control (and require lots
of refactoring of apps).

On Tue, Nov 9, 2010 at 4:16 AM, Arian van Gend <waggy@xxxxxxxx> wrote:
>
> The File menu should probably not be used on a lot of applications, since
> they don't do anything with files.
> The calculator can easily do without it, for example.
> Besides, the File menu has been overloaded with actions that have nothing to
> do with files anyway, and should therefore at least be cleaned up.
>
> As long as for example in the case of Rythmbox, 'Music' would not be an
> overloaded menu (doesn't practically everything it does have to do with
> music?), it would be an acceptable name for a menu. But that would mean that
> closing an app, printing, and whatever other non music-related actions
> should NOT be there.
>
> Saying that this has been a convention and changing it will be confusing
> might be a good argument, although it is easy to change that habit for
> something more logical, and who closes his app from that menu anyway? I only
> do that in Empathy, because it's the only way to really close the app
> (,which I prefer to having it linger and taking up limited resources). This
> behavior is already wrong itself and should also be fixed (Android app
> management anyone?)
>
> 2010/11/9 Walter Wittel <wittelw@xxxxxxxxx>
>>
>> Taking Calculator as an example, I personally prefer "File". Putting
>> Copy / Paste / etc. there means I can now no longer look to Edit menu
>> on any application to find this common functionality. Might as well
>> have Menu 1, Menu 2, etc. because I'll have to open it up to discover
>> the functions.
>>
>> I believe anything that is the same across applications should be on
>> the same named menu (with few or no exceptions). The Calculator menu
>> should be for things that are specific to the calculator application
>> and not likely to apply to other applications.
>>
>> On Mon, Nov 8, 2010 at 7:23 PM, frederik.nnaji@xxxxxxxxx
>> <frederik.nnaji@xxxxxxxxx> wrote:
>> > hello there,
>> > thinking about the File menu, it has become clear to me that the known
>> > approach is the best:
>> > replace "File" with either [Application Name] or alternatively, as
>> > Rhythmbox
>> > does it, a title that indicates the main purpose of the respective
>> > utility..
>> > i have checked and found Empathy, Simple Scan, Rhythmbox, Totem,
>> > Calculator
>> > and others implement this.
>> > Now what is the better menu title strategy?
>> > a) indicate the name of the application (Gwibber, Calculator)
>> > b) indicate the main purpose/function of the application ( Empathy:
>> > "Chat")
>> > c) indicate the content of the application is meant to handle
>> > (Rhythmbox:
>> > "Music")
>> >
>> > my personal preference is (b), if (b) is not available i'd suggest using
>> > (a).
>> > what do y'all think?
>> > _______________________________________________
>> > Mailing list: https://launchpad.net/~ayatana
>> > Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~ayatana
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>> >
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ayatana
>> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ayatana
>> More help   : https://help.launchpad.net/ListHelp
>
>
>
> --
> http://avond.schemering.nl
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>