Re: [gimmie] Re: Proposing Gimmie applet for 2.22 -- check out 0.2.8
On Oct 31, 2007 5:18 PM, Alex Graveley [EMAIL PROTECTED] wrote: * There is an experimental standalone panel version of Gimmie. This can be branched into a sub-project, or simply not installed by default. I am *not* proposing to expose this panel alternative as part of GNOME. There are many other interesting panel alternatives which are seeing a lot of love. Left the standalone dock in for now, as no one weighed in either way on hiding/removing it. My two cents on this: a panel that treats people and documents as true top-level objects (like gimmie does) is an exciting and innovative future that GNOME should be actively pursuing. It would be a shame if this great experiment got dropped out of gimmie. [If I were GNOME BDFL, the question I would ask would not be 'should the gimmie applet be in GNOME', but rather 'how can GNOME replace the panel with the gimmie dock (and/or o-d?), and drop applets altogether in favor of widgets/gadgets/plasma-like technology.' And I'd be begging njp to make gimmie dock (and/or o-d?) as shiny as awn, but without the crack-y gnome-1.0-y prefs panel ;) ] Luis (pulling on the flame-proof suit) ___ 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 Tue, 2007-11-20 at 15:23 -0200, Pedro de Medeiros wrote: That's all very interesting, but what about a better integration of on-line applications in the desktop environment like regular applications? Have you seen, for instance, prism? http://labs.mozilla.com/2007/10/prism/ I think this is a very simple idea, and also a good match for a on-line desktop project. I agree, and blogged about this last month: http://cgwalters.livejournal.com/9706.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
System event sounds / audio feedback
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, With the recent release of PulseAudio 0.9.7, and discussions surrounding audio in GNOME, I thought I'd try and see if I could get some movement in the system event sounds area as well. The event sounds in GNOME, that have been in the gnome-audio package for ages now, are simply awesome. During my first days exploring Linux, I always had them enabled. As Linux became more and more my primary desktop environment, the clicking, crackling, latency and locking problems that ESounD produced led me to disable them for a long time. But now we have PulseAudio! Hooray! :D And things are good... well, a lot better... but: 1) Only libgnome-based applications seem to work? Besides non-GTK+ applications, another example close to GNOME is gcalctool. Libgnome also seems to be on the fast track towards deprecation. (?) 2) The number of configurable events is very limited. What about opening a folder, closing a window, switching tabs, browsing to a page, libnotify notifications, ...? 3) The event sounds are not bulk configurable, like a GTK+ theme for example. 4) I cannot control the volume of system events. *) (Anything else?) So instead of just wanting to come of as a ranting user here, I started looking around. Searching the archives, I found a thread about the bulk configurable part from 2005 [1]. But it doesn't look like anything came from it. There's also a quasy-relevant bug about auto-starting PulseAudio instead of ESounD in gnome-session. [2] This still leaves a lot of problems. I took a moment to think about possible solutions: 1) A replacement for the libgnome could be a GTK+ module, that simply hooks signals and plays sounds. Sounds are preloaded by settings-daemon; no difference from the current situation there. The GTK+ module can use PulseAudio's GLib mainloop integration. Playing sounds from the sample cache is asynchronous. 2) More events becomes a problem when thinking beyond just the fixed set for a GUI toolkit; about feedback from application specific functions. Opening a folder and browsing to a page are good examples of this. A possible solution would be to dedicate a GConf directory for sound events. Control-center iterates directory entries to find configurable sounds and their descriptions. (Short description in the listview, long in the tooltip for example.) Applications namespace their event names to avoid conflicts. 3) Theming is a matter of defining a format and implementing the configuration for it. This could be a dead simple archive containing wave or Ogg Vorbis files named after the GConf event names they play for. 4) This is slightly tricky. A volume can be specified when playing the sample. Along the lines of the previous solutions, this means the GTK+ module needs to access the configuration somehow to get the volume. I'm not sure if a GConf dependency in a generic GTK+ module is a good idea. PulseAudio also stores a default volume for samples in the cache, but there's nothing in the documentation on how to set this. Perhaps this is some extra work that needs to be done on the PulseAudio side. With that out of the way, I'd be very happy to hear about any other problems you are seeing (hearing), and comments on the solutions above. (GTK+ modules are a specific area I'm not familiar with. If there's anything special I need to know about how they are loaded, or limitations regarding functionality and library dependencies, do tell!) Regards, - -- Stéphan [1] http://mail.gnome.org/archives/desktop-devel-list/2005-May/msg00111.html [2] http://bugzilla.gnome.org/show_bug.cgi?id=398430 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHRItXcFUq0gzqDwQRAlR6AJ4qft9pDVfPSp0iA5OIdzHNAAZTkACdFAh8 ycuSkj43c/UXdd+vguuxBio= =PqLY -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing dependencies for gnome-games
Josef: gnome-games has for some time offered online gaming capabilities on top of the GGZ Gaming Zone platform. Three games are already working fine, a fourth one is currently being ported. As an upstream author of GGZ I'm very pleased to see this. However, gnome-games includes internal copies of all GGZ libraries in its SVN, with the justification of wanting to have GGZ support even if the distro in question doesn't have GGZ packages yet. Recently, a member of the Debian security team got very upset about this as this requires patching more packages. I share these concerns, especially since there are no major distros left that do not include recent GGZ packages. Sorry for the late response, but not quite true. Solaris is a major distro that doesn't include GGZ packages. Solaris has never included GGZ. Perhaps in the future we will include GGZ, but I am not aware of any specific plans to add it in the short-term. If gnome-games starts to depend on it, then we will need to consider adding it. Not sure how long that will take. I was pointed out that in order to let gnome-games' configure script fail when no external GGZ libraries are found, I would need to propose those libraries as external dependencies on this list. Why is it necessary for gnome-games configure to fail if GGZ is not found? If configure doesn't find GGZ, why not just disable building whatever games have hard dependencies on GGZ? Or do all the games now depend on GGZ? Brian ___ 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 Nov 22, 2007 6:40 AM, Alp Toker [EMAIL PROTECTED] wrote: Colin Walters wrote: On Tue, 2007-11-20 at 15:23 -0200, Pedro de Medeiros wrote: That's all very interesting, but what about a better integration of on-line applications in the desktop environment like regular applications? Have you seen, for instance, prism? http://labs.mozilla.com/2007/10/prism/ I think this is a very simple idea, and also a good match for a on-line desktop project. I agree, and blogged about this last month: http://cgwalters.livejournal.com/9706.html There's no need to look far and wide for this kind of functionality. We've already got a sleek and powerful browser component built around GLib and GTK+ whose sole purpose is integration with the desktop: http://live.gnome.org/WebKitGtk Just to broaden this discussion a little I recently tried Pagico [1] (which is a cross platform personal organiser). AFAICT (its closed source) Their approach to cross platform development seemed to involve writing the application in PHP and then starting apache to serve it. The app is then a thin-ish wrapper around firefox/gtkmozembed widget that connected to http://localhost:port My question is, do we want to encourage this sort of development in GNOME, and if so, how?. For example, the new shiny HTML5 client db stuff in webkit [2] will go some way to allowing desktop apps to be written in HTML/JS and then run inside a light webkit shell, but can we do better. What about * A simple way to start a webkit browser widget associated with a private, standalone httpserver? - might be necessary if someone wants to write apps in PHP/some other server side language * Some way to communicate gtk-isms/function calls from the html/js app to the desktop. For example, I have previoulsy acomplished this (in pygtkmozembed) by 1) encoding gtk function calls as javascript status messages 2) catching on_status_changed and then reecreating the call Can webkit facilitate some sort of Gtk/GNOME javascript binding? Anyway, somthing else to think about John [1] http://www.pagico.com/ [2] http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage/ http://live.gnome.org/WebKitGtk ___ 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
Re: Proposing dependencies for gnome-games
On Wed, 21 Nov 2007, Brian Cameron wrote: gnome-games has for some time offered online gaming capabilities on top of the GGZ Gaming Zone platform. Three games are already working fine, a fourth one is currently being ported. As an upstream author of GGZ I'm very pleased to see this. However, gnome-games includes internal copies of all GGZ libraries in its SVN, with the justification of wanting to have GGZ support even if the distro in question doesn't have GGZ packages yet. Recently, a member of the Debian security team got very upset about this as this requires patching more packages. I share these concerns, especially since there are no major distros left that do not include recent GGZ packages. Sorry for the late response, but not quite true. Solaris is a major distro that doesn't include GGZ packages. Solaris has never included GGZ. Perhaps in the future we will include GGZ, but I am not aware of any specific plans to add it in the short-term. If gnome-games starts to depend on it, then we will need to consider adding it. Not sure how long that will take. I was pointed out that in order to let gnome-games' configure script fail when no external GGZ libraries are found, I would need to propose those libraries as external dependencies on this list. Why is it necessary for gnome-games configure to fail if GGZ is not found? If configure doesn't find GGZ, why not just disable building whatever games have hard dependencies on GGZ? Or do all the games now depend on GGZ? GGZ has already been accepted as a external dependency. See: http://live.gnome.org/TwoPointTwentyone/ExternalDependencies - Andreas ___ 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 Nov 21, 2007 3:40 PM, Alp Toker [EMAIL PROTECTED] wrote: Colin Walters wrote: On Tue, 2007-11-20 at 15:23 -0200, Pedro de Medeiros wrote: That's all very interesting, but what about a better integration of on-line applications in the desktop environment like regular applications? Have you seen, for instance, prism? http://labs.mozilla.com/2007/10/prism/ I think this is a very simple idea, and also a good match for a on-line desktop project. I agree, and blogged about this last month: http://cgwalters.livejournal.com/9706.html Glad to know I am not the only one who thunk of that. :) There's no need to look far and wide for this kind of functionality. We've already got a sleek and powerful browser component built around GLib and GTK+ whose sole purpose is integration with the desktop: http://live.gnome.org/WebKitGtk Cool, will try it later. That's certainly something to look forward to. And I guess it would be nice and easy to improve Nautilus' Create Launcher... menu item behaviour by letting it create new links to RIAs directly onto the Desktop and GNOME Panel too... :) Pedro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Hard vs. soft deps (Was Re: Proposing dependencies for gnome-games)
On Wed, 2007-11-21 at 22:27 +0100, Andreas Røsdal wrote: Why is it necessary for gnome-games configure to fail if GGZ is not found? If configure doesn't find GGZ, why not just disable building whatever games have hard dependencies on GGZ? Or do all the games now depend on GGZ? GGZ has already been accepted as a external dependency. See: http://live.gnome.org/TwoPointTwentyone/ExternalDependencies Hardly a very constructive response. My take is that the list is not accurate; we really should make a distinction between hard and soft deps. Software in the GNOME desktop and platform releases should be able to build without having the soft deps available; yet it's fine for them to fail if it's missing a hard dep. Ideally, in the place where we enumerate the soft deps, an explanation of what value/features the soft dep adds is listed. For example, hal is AFAIK not a hard dep. On the other hand things like libXrender, a compliant C compiler, a POSIX-compliant libc etc. probably is. Notably these are missing from the list; maybe just because it's evident they are hard deps. Which is fine. No reason to state the perfectly obvious. Whether GGZ should be a hard or a soft dep, I don't know. But I know we need to make a distinction. Thoughts? Also, who is maintaining the dep list? I've proposed PolicyKit and PolicyKit-gnome as soft deps but received no response from the maintainers of that list. OTOH, lots of projects seem to want to use PolicyKit at least as a soft dep. Who am I supposed to track down? The release team? Thanks. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hard vs. soft deps (Was Re: Proposing dependencies for gnome-games)
On Wed, 2007-11-21 at 23:28 +0100, Olav Vitters wrote: On Wed, Nov 21, 2007 at 05:02:20PM -0500, David Zeuthen wrote: Also, who is maintaining the dep list? I've proposed PolicyKit and PolicyKit-gnome as soft deps but received no response from the maintainers of that list. OTOH, lots of projects seem to want to use PolicyKit at least as a soft dep. Who am I supposed to track down? The release team? Thanks. From the link: If you have proposed newer modules, there appears to be general consensus for your proposals, and the release team hasn't responded within a week, please send an email to release-team@ asking that we update this page. We tend to give people time to respond, but then unfortunately forget to update things. Oh, sorry. My bad for not reading the link. David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hard vs. soft deps (Was Re: Proposing dependencies for gnome-games)
On Wed, Nov 21, 2007 at 05:02:20PM -0500, David Zeuthen wrote: Also, who is maintaining the dep list? I've proposed PolicyKit and PolicyKit-gnome as soft deps but received no response from the maintainers of that list. OTOH, lots of projects seem to want to use PolicyKit at least as a soft dep. Who am I supposed to track down? The release team? Thanks. From the link: If you have proposed newer modules, there appears to be general consensus for your proposals, and the release team hasn't responded within a week, please send an email to release-team@ asking that we update this page. We tend to give people time to respond, but then unfortunately forget to update things. -- Regards, Olav ___ 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
On Wed, 2007-11-21 at 20:47 +0100, Stéphan Kochen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, With the recent release of PulseAudio 0.9.7, and discussions surrounding audio in GNOME, I thought I'd try and see if I could get some movement in the system event sounds area as well. The event sounds in GNOME, that have been in the gnome-audio package for ages now, are simply awesome. During my first days exploring Linux, I always had them enabled. As Linux became more and more my primary desktop environment, the clicking, crackling, latency and locking problems that ESounD produced led me to disable them for a long time. But now we have PulseAudio! Hooray! :D And things are good... well, a lot better... but: 1) Only libgnome-based applications seem to work? Besides non-GTK+ applications, another example close to GNOME is gcalctool. Libgnome also seems to be on the fast track towards deprecation. (?) See also: http://bugzilla.gnome.org/show_bug.cgi?id=368304 2) The number of configurable events is very limited. What about opening a folder, closing a window, switching tabs, browsing to a page, libnotify notifications, ...? This needs application support, and widget support. I think you're going overboard with your examples though. I think you should file bugs against specific applications that you'd want to support specific sounds. Implementing those with the gnome_sound_ API (or the esd API) would be alright as a stop-gap. 3) The event sounds are not bulk configurable, like a GTK+ theme for example. 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. 4) I cannot control the volume of system events. You can if you use PulseAudio. It's just only accessible with pavucontrol, not gnome-volume-control. snip 1) A replacement for the libgnome could be a GTK+ module, that simply hooks signals and plays sounds. Sounds are preloaded by settings-daemon; no difference from the current situation there. See bug above. snip 2) More events becomes a problem when thinking beyond just the fixed set for a GUI toolkit; about feedback from application specific functions. Opening a folder and browsing to a page are good examples of this. A possible solution would be to dedicate a GConf directory for sound events. Control-center iterates directory entries to find configurable sounds and their descriptions. (Short description in the listview, long in the tooltip for example.) Applications namespace their event names to avoid conflicts. This sounds like overkill to me, compared to other system sound APIs available. 3) Theming is a matter of defining a format and implementing the configuration for it. This could be a dead simple archive containing wave or Ogg Vorbis files named after the GConf event names they play for. Rodney was working on such a spec. But I'll give you £50 if you manage to create/gather up a sound theme of quality matching the current gnome-audio sounds, and that's actually shippable without copyright problems by distributions. 4) This is slightly tricky. snip PulseAudio should give you a separate track for the ESD connected applications. It's probably a matter of tagging those. Lennart would know better. Cheers ___ 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
John Stowers wrote: For example, the new shiny HTML5 client db stuff in webkit [2] will go some way to allowing desktop apps to be written in HTML/JS and then run inside a light webkit shell, but can we do better. What about * A simple way to start a webkit browser widget associated with a private, standalone httpserver? - might be necessary if someone wants to write apps in PHP/some other server side language Hey John! Your ideas are on the right track but we do it a little differently in WebKit, mostly to the same effect. Our strategy with WebKit is to discourage traditional gtkmozembed hacks like embedding a web server in the process, in favour of providing direct access to the resource request/response layer and Document Object Model via GObject. Of course, you can still ship a web server with your product as a migration path if you want to deploy PHP applications. One of the entry points you might use to access the DOM, just to give you an idea of what I mean here: DOMCSSStyleDeclaration* webkit_page_get_style (WebKitPage *page); * Some way to communicate gtk-isms/function calls from the html/js app to the desktop. For example, I have previoulsy acomplished this (in pygtkmozembed) by 1) encoding gtk function calls as javascript status messages 2) catching on_status_changed and then reecreating the call Can webkit facilitate some sort of Gtk/GNOME javascript binding? We're just about to enable a complete C API to access the JavaScript engine, allowing calls into JS as well as the creation of completely new dynamic JS objects complete with custom callback handlers, which can be accessed directly from WebKitFrame, for example: JSGlobalContextRef webkit_frame_get_global_context (WebKitFrame *frame); I've created a proof of concept JavaScript D-Bus bridge using only this new C API so it's already quite powerful and expressive. I hope that WebKit will encourage application developers to actually move away from some of the practices you describe and back towards real GTK+ applications that use Web technologies as a complement, not a replacement, for our existing platform. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Hard vs. soft deps (Was Re: Proposing dependencies for gnome-games)
2007/11/22, David Zeuthen [EMAIL PROTECTED]: Hardly a very constructive response. My take is that the list is not accurate; we really should make a distinction between hard and soft deps. Software in the GNOME desktop and platform releases should be able to build without having the soft deps available; yet it's fine for them to fail if it's missing a hard dep. I don't think it's a meaningful distinction. If a software can build and operate without the dependancy, it's more like recommended software than a real dependancy. Blessed dependancies should IMO be always considered hard, there shouldn't be a need to bless them if they're not... Ideally, in the place where we enumerate the soft deps, an explanation of what value/features the soft dep adds is listed. As said, I'd call that list recommended software and keep it totally separate from the dependancy list. These are of course, just my two small units of currency. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
