Re: [Usability] Launcher Dialogs



Am Sa, den 22.11.2003 schrieb Mark Finlay um 13:43:
> Hey all,
> 
> I'm trying to work out how to simplify/fix the launcher
> properties/creation dialog(s), and there are a few things that I would
> like opinions on.
Nice :).

> * The advanced tab should die. It only contains options that are useful
> to developers, who don't use this dialog anyway. I really don't think
> that users are creating launchers that are fully translated and with
> documentation and "Try this before using", whatever that is.
Exactly. Who changes translations using this interface? I bet nobody
does it.


> * It's not immediately obvious why one would want to "Comment" on a
> launcher. I don't know how users are going to work out that this if for
> the tooltip, or if they would ever even want to add a tooltip...
Inside the .desktop file, this really represents the comment.
"Tooltip" would be a bit confusing since tooltips on panel launchers
show "<Name>\n<Comment>". You may want to call it "Description" or
"Details".

> * "Generic Name" - I'm not sure what this is or where is shows up in the
> UI, which mean that it probably needs to be removed or rethought.
According to the freedesktop.org desktop entry spec [1], the generic
name in fact HAS a function although we (GNOME) currently don't use it.

> * "Type" - I can only make "Application" and "Link" do anything useful,
> and these two could conceivably be merged by using gnome-vfs-url-show.
> As such I think we can probably get rid of this. Links to devices and
> network shares should be created elswhere.
No, I don't think so. Right-click a GNOME menu item -> "entire menu" ->
"properties" - it will display "directory" as "Type". Refer to [1]
("There are 4 types of desktop entries: Application(1), Link(2),
FSDevice(3) and Directory(4)."). IMHO these should just be synced up
with GNOME's types.

> * "Command" - This input obviously has to stay, but if we use
> gnome-vfs-url-show that what do we label it as. In that case a launcher
> could be for a uri, application, file or folder[1]. This brings up the
> question of whether we want to throw all this together into one "object"
> - the launcher. Nautilus can already create shortcuts using symbolic
> links,but these can't be easily used on the panel atm.
We should stick to fd.org's specs (see above).

> * "Run in Terminal" - this is useful, but doesn't actually seem to work
This works - but only for terminal applications like links or dselect.

> Editing Launchers:
> 
> * Right now one can only edit a launcher on the panel, in the menus or
> in applications:// . Nautilus needs to  be able to edit launchers, but
> it should do it in the same way as the panels. Having an "Edit Launcher"
> context menu item in nautilus really sucks, so I'd vote for adding a
> "Properties" item to the panel's launcher context menu and removing the
> "Edit Launcher" item.
Uhm I don't know exactly what you mean. The panel's launcher context
menu HAS a "Properties" item.
I use stock GNOME and Nautilus indeed doesn't offer any way to edit
launchers. Unfortunately we can't simply remove the "Properties" item
since we need some place to display the file's properties. Instead, we
should IMHO add a tab to the property dialog called "Launcher"
containing the launcher's properties.
Maybe I got you wrong here.

Thanks for your efforts!

regs,
 Chris

[1]
http://freedesktop.org/Standards/desktop-entry-spec/desktop-entry-spec-0.9.4.html

> Anyway, there is a lot of stuff that needs fixing and rethinking, be we
> shouldn't put of fixing some of the easier fixed issues just because
> there are also some less easily fixed issues. Even removing superflous
> fields and "Types" that don't make any sense would be a big improvment
> for 2.5
> 
> 
> [1] Folders depend on http://bugzilla.gnome.org/show_bug.cgi?id=115726




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