Re: [Usability] Re: program binary names

On 13Oct2001 07:19PM (-0700), Seth Nickell wrote:
> I'm not sure the distinction is confusing, and I think we would be
> better off nixing "Gnome" from names wherever possible. 

I'm OK with that in most cases - but I imagine a future where many
GNOME and KDE apps will appear in the other desktop's menus by
default, when we iron out more of the integration issues. I'm also not
sure if naked generic terms are always good - having both "Calendar"
and "Evolution Calendar" in the menus is probably
confusing. Similarly, "GNOME Terminal" vs. "Xterm Terminal" may be
better than just "Terminal" vs. "Terminal".

> However, as I pointed out in the previous message, application
> developers don't necessarily need to be actively concerned about this.
> The functional description field in .desktop will be indepedent on the
> name and the two will be composed by the panel.

In Nautilus we took the approach of composing base view names with
"View as" and "Viewer" instead of including it in the string, and this
turned out to be a serious problem for translations. I think it may be
wiser to include the whole string somewhere in the .desktop file so it
can be localized, perhaps falling back to composition when the
pre-composed string is missing.

> > On an unrelated note, the section on MIME type integration should
> > probably mention that you should not install .keys or .mime files that
> > are already in the master gnome-vfs database, only for custom types
> > not yet in the database. In particular, gnome-vfs has an entry for
> > html already and an application should not install it's own.
> right, good point. Actually, this raises one technical issue, how do we
> deal with conflicts (or does it already?)? For example, as this database
> starts being used I can imagine multiple programs registering the same
> new type.

This is rather OT for usability (and most of this thread is somewhat
OT for g-h), but the current behavior is that program-installed .mime
and .keys files take precedence over the system one, in some arbitrary
order. It may be possible to do some kind of intelligent merging at
some point.

 - Maciej

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