GNOME Bugzilla – Bug 95331
Simplify new launcher dialog.
Last modified: 2006-11-13 19:01:09 UTC
Ok couple of ideas 1. get rid of the advance crack, users who create launchers are not going to set them up to use ten different languages. 2. divide this dialog up into two distinct dialogs add to panel => application launcher add to panel => link Reasoning: There is no reason users should have to be aware that links and application launcher use the same mechanism (.desktop files) this is an implementation detail (the fact that .desktop files are mentioned in the docs is a bug too). The other types of launchers are not meant to be used by users. We should create two distinct dialogs: add to panel => application launcher provides the user with a list of available apps that may be added to the panel like in the run dialog or the user may manually add a command. Also this design would allow us to remove add to panel => launcher from menu. add to panel => link just prompts the user to enter a url, name and lets them change an icon. Also for user created links and launchers there should only be one name entry (we can either use the generic name or name, either way choose one and go with it).
Ideally they shouldn't even have to worry about the distinction between links and launchers of course... what if they choose 'create link' and type in the URL of an executable? :) (I guess we don't have an easy solution to that right now, but it would be nice if we could think of one...)
see also bug #78902. Dave mentioned the idea of a druid.
Other things that worry me about the create launcher dialog (which have not been mentioned): 1. On the Basic tab, there are several labels that are less than illuminating. Take for example "Name" and "Generic Name". "Name" has a default value ("No name")-- "Generic Name" has nothing-- so I'm left with no clue about what sort of information belongs where, or what info I can ignore. A possible solution to this is to provide more default values for the entries on this tab. Another is to remove fields that have no practical use--I can't even seem to make the "Generic Name" data appear anywhere; what the heck is the point of this field? :) 2. There is no way to tell which fields are required, and which aren't. I know that right now, none of the fields seem to actually be required, because I can create a launcher without specifying any data at all, and a little, useless foot is added to my panel for me. This seems a bit odd to me. Can a launcher be useful if it doesn't do anything? (Will come back to this point shortly) Should some fields maybe be required? 3. The Type option menu should really be above the "Command" entry, since the value of the option menu determines what the label for that Command/URL entry is. It is a little weird to specify a command, then change the value of "Type", only to have the label above "Type" change. 4. Some of the options in the "Type" option menu are really hard to understand. What is an FSDevice? What about a ServiceType? Why is MimeType here? (What does it mean to launch a MimeType, anyway?) I'd like to see this list either a) trimmed down to include only useful options, or b) use more descriptive words. 5. Getting back to required/optional fields-- a possible way to clean up this dialog would be to group the fields as shown below: <frame name="Required Information> Name : ____________________________ Type: ____________________________ Command: ____________________________ </frame> <frame name="Optional Information"> Comment: _____________________________ Icon: _____________________________ [ ] Run this command in a teminal** </frame> **This one doesn't really work for me either; I tried making a launcher for the "ls" command, and while it does seem to execute an ls, the terminal which it is run in appears and disappears very very quickly (speed of lightishly, really). Anyway, just some food for thought about other potential issues with this tool. -Anna
Created attachment 12010 [details] I have been playing with glade, and made an initial try at this dialog with the suggestions Anna made, if you like it i can write the code needed
Taking the liberty of marking this high/enhancement, though it's probably something we can't really get to until 2.3. This is a bit of an abuse of 'high'; kids, don't do this at home. :)
*** Bug 102908 has been marked as a duplicate of this bug. ***
*** Bug 103219 has been marked as a duplicate of this bug. ***
*** Bug 89547 has been marked as a duplicate of this bug. ***
*** Bug 90462 has been marked as a duplicate of this bug. ***
*** Bug 78902 has been marked as a duplicate of this bug. ***
I'll try to work on this. What types should we keep? Application -> yes Link -> is it useful? Probably, but we should call it "File" or something like this FSDevice -> no (why is this in the spec?) Directory -> is it useful? What should it do? MimeType -> deprecated ServiceType -> KDE specific, so no Service -> KDE specific, so no
Mark, I've been working on this for a few hours. I made a dialog widget so we can remove some code in gnome-panel and gnome-desktop-item-edit (the idea is to just call gnome_ditem_edit_simple_dialog_run (uri) or something like that). I'm attaching a screenshot. There's more work to do, but I'd like to know if it's better to have a dialog widget or to keep something we can embed.
Created attachment 33770 [details] Screenshot
I know the frames are not HIG compliant. This will be fixed later :-)
This doesn't look bad. I'm also interested to see what the types are. (eg Applications, Samba, etc) It might be nice to be able to add network shares as well here. Once people know about about creating launchers it will seem natural to add as such. Morever, you need no longer have to get a nautilus window to create a network share as you do right now. Just a thought.
Created attachment 33780 [details] [review] Patch Here's a patch containing my current work. I must admit I'm using this bug as a backup :-) But you can comment on the patch too! There are some FIXME, but basically, it works. See the test in the patch. I should probably add a "closed" signal or something like this so we can know the desktop file was created (we want this to add it to the panel, for example). Mark: it'd be great to know if this is the right direction or not :-)
Sri: I agree it'd be nice to be able to create network connections from this dialog too. But it's not handled in the same way (network connections are not real files and are stored in gconf)...
Vincent: I'm not all too familiar with the inner workings of GNOME/Linux at all, so please excuse me if my question is a bit foolish: Why do we need a "Type"-setting at all? As far as I can see from the patch, there's only "Application", "File" and "Directory". Couldn't those be autodetected from file modes, or possibly some magic detection of mime-type?
Screenshot looks fairly good. Some comments on that: 1) Dave originally suggested two dialogs - one for editing links and one for editing launchers. I think that would be best too - just remove the Type field and don't worry about links for now. Also, .directory files either shouldn't be edited at all (they're in $datadir after all) or would be edited in a menu editor where you think you're editing a folder's name, icon, or whatever. 2) I can't say I like this "Required Information"/"Optional Information" 3) The "Run in terminal" checkbox seems oddly placed. On the patch: - go ahead and commit the g_get_language_names() stuff and bump the gnome-desktop glib required version. - I think it would make sense to use GKeyFile instead of GnomeDesktopItem - I'd like to think that if we can add launching support to libgnome-menu and add your launcher editor to gnome-menus, then we can deprecate libgnome-desktop altogether. DesktopEntryEditor ? - new_from_uri() should be the default: GtkWidget *desktop_entry_editor_new (GtkWindow *parent, const char *uri, const char *title, GError **error); thing. It feels like a registration webpage or something. - load_uri(), clear() and set_location() should be replaced by accessors for the "uri" property and allowing the uri to be NULL void desktop_entry_editor_set_uri (DesktopEntryEditor *editor, const char *uri); char *desktop_entry_editor_get_uri (DesktopEntryEditor *editor); actually implement the property as an object property too - GnomeDesktopItem usage is an implementation detail, it shouldn't be in the header. - I'm not sure I understand the use case for any of the signals. - Can we not replace set_editable() with just allowing gtk_widget_set_sensitive (GTK_WIDGET (editor), FALSE); - What's the use case for the name/command/comment/uri accessors? - I prefer to just use char instead of gchar - I'd much prefer if there was a lot less commenting and it was just more clear what the code is doing
> - I'd like to think that if we can add launching support to libgnome-menu > and add your launcher editor to gnome-menus, then we can deprecate > libgnome-desktop altogether. DesktopEntryEditor ? Ok. I can work on this. Btw, as libgnome-desktop is in Desktop and not developer, we could just remove it. Not sure if it's a good thing to do, though. > - I'm not sure I understand the use case for any of the signals. You want to update the launcher icon/tooltip/etc. in the panel without waiting the dialog to be closed. Or is there any other way to do this? > - I'd much prefer if there was a lot less commenting and it was just > more clear what the code is doing This is the first time I'm told to comment less :-) Yeah! I'll work on this ASAP (this will have to wait for a few days).
*** Bug 172893 has been marked as a duplicate of this bug. ***
The advanced tab is clearly crack but in the short term it really should be fixed to crack that uses GTK_STOCK_ADD and GTK_STOCK_REMOVE which would make it slightly prettier and one less thing for translators to worry about. (I made other comments in bug 172893 but this is on the only one that really remains relevant. Added the I18N keyword). >>> 3) The "Run in terminal" checkbox seems oddly placed. > 1. get rid of the advance crack, users who create launchers are not going ... I dont think a Desktop enviroment should be exposing users to the terminal, at least not in this situation. Those who want to use the terminal are far more likely to be in a position to use a list of aliases than to be using launchers. (if there is an easy way to reference a launcher from the terminal and use them as an easier way to setup aliases I might be willing to reconsider the need to remove this option) I cant help thinking of the old "Get Info" dialog from Mac OS which had an icon on the top left followed by the program or file name (and you could set custom icons for any file not just launchers, which I did frequently so the dialog is burned into my subconscious). http://www.lazilong.com/apple_II/adfs/graphics/info_gen.gif http://www.microfrontier.com/support_area/images/get_info.jpg http://mactips.info/tips/images/changeall.jpg http://www.interarchy.com/documentation/7/img/windows/getinfo.png I think the icon should be on the top left, followed by the name/title of the Launcher.
This is an enhancement (aka feature); features are *never* release showstoppers and should not be marked as such by the use of the GNOME Milestone field. If the gnome-desktop maintainers wish to make it a target for their product, they can use the target milestone field.
Created attachment 62068 [details] [review] New patch 15 months ago, I told I'd work on it a few days later. I'm not so late :-) Patch is much better/saner, but still needs some work. It still usr GnomeDesktopItem for now. We should probably write a thin layer above GKeyFile to provide the same functionnality. Anyway, here it is so it doesn't get lost.
Created attachment 62147 [details] [review] New patch A bit better. Still uses GnomeDesktopItem, but it's an implementation detail.
Created attachment 62148 [details] Editing an application launcher...
Created attachment 62149 [details] Editing an application launcher, but setting it to be launched in a terminal...
Created attachment 62150 [details] Editing a "link" launcher
Created attachment 62151 [details] Creating a new launcher
Small notes: + in the new launcher dialog, you can select from Application, Application in Terminal, File in the combo box + the dialog currently is resizable. Not sure if this should be the case...
gnome-panel 2.15.x now contains this. I'm not sure it makes sense to have the widget in gnome-desktop. Any comment on this?
I'm deprecating the desktop item editor in gnome-desktop, so we don't need to put the widget there.