Web links integration in applications: bugs, translations, help...
Hi, Distros, just like GNOME, have bug trackers, forums, support systems. GNOME and some distros have translation infrastructure. These are usually not integrated into the end-user applications. For example a new user wanting to report a bug against Gedit would: 1) fire his web browser to lookup where to report bugs 2) open the relevant bug reporting page, look for the Gedit component 3) file the actual bug description and details You can imagine the process is the same for translations fixes / new translations, help requests in forums, etc. Step 1) and 2) could very well be skipped would we integrate an URL link in each application Help menu (or a bug-buddy launcher). That is, selecting Help Report a bug would bring you to the relevant bug reporting page for this application, on your distributor's bug tracking system (or at GNOME's, freedesktop's, etc. depending on who the build comes from). Ubuntu has been doing such an integration with a system called LPI (Launchpad integration), and I think it's a generally useful concept which could be used by other distributors and by upstream apps. [1] I'm attaching a screenshot of Gedit's help menu on an Ubuntu system as an example. How do other people feel about such a system? Would it make sense to integrate this in GNOME? Where should it go? In the past, libgnomeui would have been a candidate for such stuff, but we try to drop this lib; I guess Gtk+ is where libgnomeui tends to move? Bye, [1] I don't think the implementation could be reused: it's a Python package implementing functions like getTranslateUrl() (hence directly accessible to Python apps) which is wrapped in a C lib starting a Python interpreter (for C apps); it basically transports the URL mappings and icons. -- Loïc Minier attachment: gedit-lpi.png___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
On Mon, 2007-11-26 at 10:05 -0500, Dan Winship wrote: Havoc Pennington wrote: I do think libsoup, gnome-vfs, neon, and curl are all bad answers long-term for apps that want to use web APIs or download an icon. The right answer will address among other things how to share cookies and proxy settings and cache with the browser. Can you check out http://live.gnome.org/LibSoup/DesktopWideHttp and see if there's anything missing? And IMO should just be HTTP, not SOAP or DAV. So this is a good problem for someone to try to solve. So, I'm not sure if you're being misled by libsoup's name (and heritage), but it IS just HTTP. (The SOAP support was ripped out for version 2.0, and while there was a little bit of soap stuff added back later, it's totally peripheral.) While I agree that no existing HTTP library does all of the integration you discuss (even using mozilla's HTTP layer is no good because it still can't *share* all the data with Firefox), it seems like it would make a lot more sense to take a working HTTP library and build on that, rather than writing a new one from scratch. (Unless you're thinking that the best solution is to proxy all HTTP calls to Firefox over D-Bus or something?) The ones we would care about for Totem and other media players would be passwords and cookies (and to a lesser extent certificates in a few cases). The problem is that we usually use gnome-vfs to access HTTP resources, and moving to gio/gvfs would either need an HTTP module there, or a library that offers similar features. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: System event sounds / audio feedback
Le lundi 26 novembre 2007 à 09:10 -0500, Matthias Clasen a écrit : On Nov 25, 2007 6:54 PM, Lennart Poettering [EMAIL PROTECTED] wrote: On Thu, 22.11.07 18:18, Stéphan Kochen ([EMAIL PROTECTED]) wrote: That's because we never had a whole slew of potential replacements. The current gnome-audio sounds suck (no offense to the original author), they sound dated, and badly finished. Compare this to the MacOS (even prior to OSX) or SGI sounds. True, there are not many. I know only of gnome-audio, Fedora's, Ubuntu's and less than a handful at gnome-look. I'm hoping PulseAudio will spur some creativity, or this is a chicken-egg problem. :) Hmm. I never hear or heard of the Ubuntu sounds. Are they any better than what we have now in gnome-audio? And are they licensed under a free license? If so, they should be merged into upstream gnome-audio, and at least be stolen for Fedora. Lennart, look here: http://packages.ubuntu.com/hardy/gnome/ubuntu-sounds May I also suggest Ia Ora sounds which were designed by our of our fellow Mandriva hackers, Helio Chissini de Castro http://svn.mandriva.com/cgi-bin/viewvc.cgi/soft/desktop-common-data/trunk/sounds/ Those are named ia_ora-* They are under CC BY-SA 2.5 license but this could be changed if needed. -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
Hi, Dan Winship wrote: Havoc Pennington wrote: I do think libsoup, gnome-vfs, neon, and curl are all bad answers long-term for apps that want to use web APIs or download an icon. To be clear, I wasn't trying to say here that none of these could be made a good answer, just that they aren't now due to the browser-state-sharing issue (or e.g. gnome-vfs deprecation, etc.). I would not say writing an http lib from scratch makes sense. The main other approach I was thinking of was to in some way use the Firefox http implementation, either via a dbus daemon or just via a shared library. Alex had some thoughts along those lines too. Can you check out http://live.gnome.org/LibSoup/DesktopWideHttp and see if there's anything missing? It looks pretty good to me though I am not an expert. I think from what you wrote it's pretty clear that modifying Firefox itself is a required part of a good solution. Some offhand thoughts that may suck: - making the codepath different depending on whether Firefox is running sounds like a direction that would have user-visible weird effects and also make app authors uncomfortable - it seems inevitable that both gnome-http-lib and Firefox would need to rely on some type of common repository of cookies, etc. and that this repo would be managed by some type of daemon that handled locking and change-notification; said daemon would need to be able to run sans Firefox, and would need to handle changes to the repo, not be read-only. - though it never pays to block on a committee, I would say key people to get sign off from (or at least keep informed) would be Alex so we know the solution works for gvfs, and the Mozilla team, so we know they will take the patches to Firefox and be OK with the way it's done - the Mozilla team might be interested in this problem on Windows also, since right now using the Windows HTTP stuff shares state with IE, but I'm guessing apps that rely on this get hosed when people use Firefox. So maybe Mozilla would like to provide an HTTP lib on Windows that shares state with Firefox, or something. No idea though. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Online Desktop and GNOME 2.22
- it seems inevitable that both gnome-http-lib and Firefox would need to rely on some type of common repository of cookies, etc. and that this repo would be managed by some type of daemon that handled locking and change-notification; said daemon would need to be able to run sans Firefox, and would need to handle changes to the repo, not be read-only. Isnt there some work been done on using gnome-keyring to store authentication information for firefox? (sorry I cant remember the link to the patch in FF bugzilla). Wouldnt it be a natural extension to this to use either use this, or upcoming GSettings (gnome-y) or dconf (more cross desktoppy) for the cookie store. Both of these implementations already deal with locking and change notification, so why do we need a new daemon? (especialy if dconf AIUI is daemonless) - though it never pays to block on a committee, I would say key people to get sign off from (or at least keep informed) would be Alex so we know the solution works for gvfs, and the Mozilla team, so we know they will take the patches to Firefox and be OK with the way it's done Yeah, and lets not forget webkit also. I think this is where something like dconf, which sounds a bit less GNOME-y has a greater chance of being signed off by on multiple projects with stakeholders outside GNOME. I guess it would then be a natural extension to make libsoup / gvfs et. al depend on dconf for authentication info and cookies. But does this then fall down or come back the the same debate about hard and soft deps and where (how low) something in the stack like dconf, gnome-keyring and gvfs (authentication) lies. John - the Mozilla team might be interested in this problem on Windows also, since right now using the Windows HTTP stuff shares state with IE, but I'm guessing apps that rely on this get hosed when people use Firefox. So maybe Mozilla would like to provide an HTTP lib on Windows that shares state with Firefox, or something. No idea though. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
