GNOME Bugzilla – Bug 171872
leave tab and « open with ... » gui
Last modified: 2007-08-01 20:18:39 UTC
Hello, A great work is done for usability of the « open with ... » dialog and with the gnome-app-install program. I suggest a similar work with the gnome-default-applications-properties dialog. First of all, I suggest to leave the list box to use something similar to the « open with ... » dialog. With this improvement, the gnome-default-applications-properties dialog will be more integrated with the set of gnome app (especially nautilus and gnome-app-install), it will look better and easier than the Windows Default Apps chooser and it will also use icons from the theme which is a pretty usability improvement for newbies. Thanks for all, folks. Other information: I decided to not split this too improvement, but feel free to resolve them separatly.
Hi, I'm trying to rewrite gnome-default-applications-properties. I think it is a good exercise,regardless it will be accepted or not. The new applet will have one dialog instead of three tabs, it will use GtkComboBox instead of GtkCombo (which is deprecated) and will store applications information in an XML file, rather hard-coding them in source code (can be edited by ISVs). At the moment there is only the XML parser and it lacks all the gconf interaction.
Created attachment 53560 [details] Screenshot
oh, and the icons follow theme changes :)
Hey, That's quite amazing ! :) I'm just thinking about how it will look with around 6 applications to select. The window will be huge. I think that a tab-like view as done in disk-manager is a good idea. Thanks. Maybe this discussion should be in a mailing-list.
Thanks :) Of course this kind of layout suits well only with small number of application categories, not more than three/four. If more categories are needed the applet can switch to a tabbed layout. BTW, which other categories do you have in mind? I have read somewhere text editors, or media players (both audio and video), but all these kinds of applications can be selected via the "Open with" option in Nautilus, which deals with files MIME type. The applications presented in this applet doesn't interact directly with files, but with some sort of links (http://, mailto://...). Are other categories needed? I have seen also a post on g-d-l about a control-center restyling, maybe I'll post a commment to that thread.
Never mind, I have found your bug #171871, but the question is still valid. Are other categories needed?
Hello, Somes are listed at http://live.gnome.org/PreferencesRevisited#head-b20294aa501c2e2aa1080efd1126017c63fc1472 . Your work fit well in this goal. You're right, every choice regarding MIME type handling can be done in Nautilus. Nevertheless, there is a lake for related MIME type such as videos, pictures and office document and even source codes. All of this groups of MIME type should be binded to a prefered application. Perhaps the g-d-a should directly modify the MIME type database. perhaps ... Thanks.
Created attachment 53615 [details] default applications table In parallel with reworking the current capplet (web browsers, mail readers and terminals), I'm starting looking at other application types and how to integrate them in this capplet. A tabbed interface will be required, with a tab for each category. I also agree that it would be nice to have a central point to set a common application to handle a full category of files (like a default text editor for *all* text files, then, if I prefer emacs for .txt, it can be set via Nautilus "open with...", but is there a mime type for a full category of files?). The attachment contains a not exaustive table (other than usual apps I have added instant messengers).
maybe you could move this discussion on the gnome-cc list. This capplet needs some reworking. What is the preferred terminal emulator useful for? The current code has the text editor tab masked but the code for it is still here. There is also some bug than changing the preferred web browser make clicking on http:// or files opening differents softwares.
Terminal emulator should be used in case "run in a terminal" option is selected for web browser or mail reader. Anyway, I will make soon a post on gnomecc-list, thanks.
I've made a small hack that handles sip://, h323:// and callto:// URIs. My proposal is here : http://julien.quicheaters.org/ . I'd appreciate any comment on this. I've also sent an e-mail to the gnomecc ml on this.
Luca, how is it going ? Is your work available somewhere so that we can help, or, at least, know what will likely be broken or rewritten soon ?
Hi Julien, sorry for the delay commenting your posts here and on gnomecc-list, but I'm a bit busy at the moment. This is also the main reason of the delay releasing my work on the applet, but it is going well and I hope to release it soon (at least a preliminary version, so other people can work on it too). Now the applet uses a notebook widget, so it should be easy to add a tab for VoIP settings too, reflecting the applet you posted on youe web site, and I think we really should, since VoIP applications are getting a lot of attention lately (at least here in Italy).
No problem :-). It's kind of hard to push the information in the right place to be heard, this is why i tried several different ways to get some attention. If you can't commit your work in small chunks, either because you don't have CVS write access or because a complete rewrite can't be committed in small chunks, i can quickly setup a svn repository to host your rewrite. Then, i will be able to work on it with you to add the VoIP specific setup i described above. What do you think ?
Created attachment 54795 [details] gnome-default-applications-0.0.1.tar.gz Hi, I'm ready to release a first preliminary beta test version of the gnome-default-applications-properties. It is a total rewrite of the old capplet, and, at the moment, it is an independent application, but gnome-control-center integration should be very easy. It has a new gui, based on gtk_combo_boxes, which are not editable by the user, so less error prone than gtk_combo_box_entry. * default applications info inside an external xml file * improved gconf bi-directional connection. Not only when you choose an app from the gui gconf will reflect your choice, but if you write "galeon -w %s" in gconf editor then the capplet will choose Galeon Web Browser from combo box and the correct radio button will be selected (open link in new window). If no matches are found, then custom command will be used (current capplet doesn't do this). * url links can now be opened in new tabs, inside an existing browser instance, or in new windows. * tooltips notify the user about %s stuff in command entries. * added Opera web browser to the list installation is not needed, to test it you can run it with ./src/gnome-default-applications-properties (otherwise it will not find the .xml file). This is one of my first public gnome works, so some changes will be necessary. I will wait for you critics, comments and suggestions. Cheers
Created attachment 54796 [details] preferred_applications_screenshot.png
Hello, Nice work ! I just downloaded the source code attachment, compiled it (with no problem) and ran it. I would juste make one note : when i click on a combo, the UI gets _very slow_. It feels like i get stuck into the combo box. Sometimes, i manage to get back to a sane behavior, sometimes the program just crashes. I have to examine this a bit more. From the strace output, it seems that the program is always poll()ing, even when the mouse is not on the UI. I don't think it's the expected behavior. I did not check the UI for HIG compliance though. Is it possible to set up a repository somewhere (i can host this on a good server) so that we could work together ?
Hi, thanks for your bug report Julien. I have a strong suspect, I will try to fix it in the next few days. As for the public repository, well, I prefer to have something *working* before putting the source code somewhere :) Ciao
A public source code repository would help me to add the VoIP set of apps to your refactoring. Without it, i must hang on and stop my work. Waiting for something working completely leads, IMHO, to code and effort duplication, which is not good. On the other, i surely don't want to put pressure on your side, so feel free to do as you wish.
Created attachment 54871 [details] gnome-default-applications-0.0.2.tar.gz Hi, it seems that the hang up was due to Epiphany entry in default-applications.xml, which had the same string for <command> and <win-command>. This made web_radiobutton_toggled_cb enter an infinite loop. For the moment I have changed the xml file, but a source code fix should be far better and I will do as soon as possible. I have also cleaned up a bit the code in this 0.0.2 version. As for the SVN repository, you are right, but I prefer to wait for a control-center maintainer comment, in case they are interested in using it in gnome (as a side note, I don't know SVN and I have never used it :) In the meanwhile, maybe, you can post your patches here. Ciao
The hang-up problem i mentionned for the previous version has gone. Thank you very much ! I will make another note : the "custom" entry in the combo boxes would better pop-up a dialog similar to the "Open with" dialog, IMHO. I'll stay tuned :-). Keep up the good work.
From IRC/#bugs: 00:25:34 <bugsbot> loopback: Bug http://bugzilla.gnome.org/show_bug.cgi?id=171872 enh, Normal, ---, control-center-maint@gnome.bugs, NEW, leave tab and « open with ... » gui 00:26:12 <Manny> loopback, excellent! 00:26:13 <Manny> ! 00:26:13 <Manny> ! 00:26:15 <Manny> work on it:) 00:26:19 <Manny> I already had ideas on that 00:26:49 <Manny> problems to address: a) some people still want custom commands b) we need to be able to use .desktop files 00:27:17 <Manny> I suggest to use an additional flags in gconf, which toggles whether the given value should be interpreted as .desktop file, or as simple command 00:27:38 <Manny> if the matter is the case, you should use gnome_desktop_item_launch to get proper startup notification 00:28:11 <Manny> you could also get a list of all desktop files, and grep them for a matching "Exec" line, btw. 00:28:19 <loopback> My original idea was to extract needed info from the desktop file and put them in gconf, as the are stored now 00:28:32 <Manny> loopback, that won't work with startup notification, though. 00:29:08 <Manny> addning a new flag seems to be broken, considering that when you use a .desktop file, and you explicitly refer to it in gconf, distributors could add a "StartupNotify=true" flag, when the app supports it. It is just kind of redundant. Julien: > I'll stay tuned :-). Keep up the good work. I second that :).
I think that Christian's idea of having the default app .desktop file name stored in gconf is a good thing. He noted that there are two problems if we follow this approach. a) some people still want custom commands b) we need to be able to use .desktop files Problem a) can be probably solved by adding a .desktop file built on-the-fly with the NoDisplay property set, somewhere in the user's local menu directory with a common name like gnome-default-web-browser.desktop). Problem b)... Well, I don't really know which are the consumers of gconf stored info. I suspect that something will need a patch or two. Now I think that we have one more problem, lets call it problem c) c) which action to use from the .desktop file I will try to explain it. Reading freedesktop standard I have seen that one .desktop file can store multiple actions. See [1]. I think this can solve the problem of multiple commands, like open link in a new web browser tab, open link in a new web browser window... (if you look at my screenshot you can see some radio buttons to choose this option). The problem here is to tell which action have to be used to the application which will launch the browser. And, more important, is it possible to use dirrerent actions stored in .desktop files? So, my todo list now includes: 1. make a list of all menu entries with the custom option X-GNOME-ServiceType set to the category of interest (web-browser, mail-reader...) 2. in case of custom command, create e local menu entry with NoDisplay=true 3. put in gconf the .dekstop name of chosen app, plus some additional info (which action to use, if not the default one) [1] http://standards.freedesktop.org/desktop-entry-spec/latest/apa.html
Luca: For retaining backwards compatibility, it would be nice to have a new field called "desktop_id", which is used if set. Otherwise, or if no desktop file with the given desktop ID does exist, "exec", "needs_term" and friends would be interpreted. Upon setting "desktop-id", the relevant other fields would also be set. Also, I think a freedesktop.org spec about what service types an app should specify would be nice before hacking away, so that firefox, konqueror, kontact and whatever software is out there can be used as well with a minimum amount of GNOME branding :). What springs to mind: "browser", "email", "file-manager", "terminal", "music-player", "video-player", "audio-player", "cd-player" etc. You get the gist :). It might be quiet interesting to integrate this stuff with the "gnome-volume-manager" preferences in the mid- or long-term!
Luca, any news on that? The feature freeze is next week
Hi Sebastien, I returned in Italy this week, since I was working in Munich for some weeks (not too much holidays this year) so I'm a bit late with the development, sorry... Here is what we need to add: 1. Automatic applications discovering, but we need to extend .desktop files with a new custom key and we also need support for multiple actions in the same .desktop file (to have "open in a new window", "open in a new tab"...). Not too difficult if reusing the code/libs already in place for other gnome modules. 2. I have to add new gconf keys for storing .desktop file names. This is easy, but at the moment useless, since no one will use them. 3. I have to add .desktop files generation (with hidden=true) for custom commands (see point 2). This is easy too. Since we are a bit in a hurry due to feature freeze I propose to add just the new gui for this release and leave all the new functionalities for the next one. What do you think? Any comments on the applet as it is at the moment (mainly gnome-da-item.c)? I will have this weekend free (well, I hope :), so I will work on the applet.
I've just read your comment. I agree the desktop stuff need some discussion, work, etc so will be for next cycle. I would like to land the new UI to the CVS today or tomorrow (ie: before the freeze), we can fix bugs then. Do you have an updated patch or should I work on the previous tarball from that page?
I haven't a patch for CVS, since it is a total rewrite of the old applet. I think the safest way is to use the tarball. If you have some questions feel free to use my Bugzilla registration email address.
This is long since fixed, right?