Re: Prototyping the next generation panel?
On 31 Oct 2008, at 17:56, William Jon McCann wrote: Very much agree with you. However, one of the things that strongly influenced the discussions at the GNOME UX Hackfest was the data released on the Windows 7 Shell blog: http://blogs.msdn.com/e7/archive/tags/Shell/default.aspx Yep, I didn't notice the references to that on l.g.o. until after I'd posted. While it certainly isn't a substitute for first hand data, I think it is extremely interesting. What do you make of it? I agree there's a lot of valuable commentary there, and I'm sure some of it applies to us as much as to Windows. Unfortunately we can't really tell what type of users those comments have come from, so it's hard to know exactly how skewed they are-- they're presuambly the type who are motivated to follow the development of Windows 7 via its engineering blog, though, which puts them fairly firmly at the 'advanced/technical user' end of the scale I would imagine. Of course their feedback is as valuable as anyone else's, but we obviously need to be careful not to over-emphasise it, too. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libunique external dependency for 2.25?
Hi, Le jeudi 02 octobre 2008, à 23:23 +0100, Emmanuele Bassi a écrit : while the ultimate goal *is* to have this functionality inside gtk+ I'm nowhere near having the time to integrate it myself - not in the way I want it integrated[1], at the very least. another issue is that libunique is pretty much a testing ground for API and requirements and while the basic functionality is obviously already implemented I still receive requests[2] that make sense to add *before* putting the whole shebang in gtk+. we do put stuff in libegg to have it ready for later integration with a reasonable set of API, right? So, it seems nautilus now depends on libunique. I understand the plan is to fix this in gtk+ (hopefully in 2.16), but it will not happen for 2.26 since we'll have gtk+ 2.14. Does it make sense to use libunique for this now, only for 2.26? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Le mardi 21 octobre 2008, à 10:30 -0400, Nathaniel McCallum a écrit : Hi, I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. Looking at the code, you don't listen for changes to the gconf keys. If I have an active connection through a proxy and I change my proxy settings, shouldn't libproxy tell the app the proxy settings have changed, so that it can restart the connection? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Vincent Untz wrote: Le mardi 21 octobre 2008, à 10:30 -0400, Nathaniel McCallum a écrit : Hi, I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. Looking at the code, you don't listen for changes to the gconf keys. If I have an active connection through a proxy and I change my proxy settings, shouldn't libproxy tell the app the proxy settings have changed, so that it can restart the connection? libproxy reads the configuration from gconf every time a new connection is established. IMHO, it is a bad practice to tear down a working connection so that you can try to establish a new connection which *might* work (or might fail). Best practice should be to keep all operational connections established and only use the new proxy settings for new connections. Nathaniel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Le jeudi 06 novembre 2008, à 07:59 -0500, Nathaniel McCallum a écrit : Vincent Untz wrote: Le mardi 21 octobre 2008, à 10:30 -0400, Nathaniel McCallum a écrit : Hi, I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. Looking at the code, you don't listen for changes to the gconf keys. If I have an active connection through a proxy and I change my proxy settings, shouldn't libproxy tell the app the proxy settings have changed, so that it can restart the connection? libproxy reads the configuration from gconf every time a new connection is established. IMHO, it is a bad practice to tear down a working connection so that you can try to establish a new connection which *might* work (or might fail). Best practice should be to keep all operational connections established and only use the new proxy settings for new connections. What if the connection works in both cases, but the results are different? I would guess it's up to the application to know if the connection should be restarted. An example for this (although this is a short-life connection) is that you can directly access PDF of the ACM library via a proxy while you end up on a webpage asking you to login if you don't use the proxy. I guess there could be similar examples -- but maybe it's not that important, don't know. Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Le jeudi 06 novembre 2008, à 14:32 +0100, Patryk Zawadzki a écrit : On Thu, Nov 6, 2008 at 2:23 PM, Vincent Untz [EMAIL PROTECTED] wrote: What if the connection works in both cases, but the results are different? I would guess it's up to the application to know if the connection should be restarted. An example for this (although this is a short-life connection) is that you can directly access PDF of the ACM library via a proxy while you end up on a webpage asking you to login if you don't use the proxy. I guess there could be similar examples -- but maybe it's not that important, don't know. But is it likely that the user remembers and manages to switch the proxy *during* the download to save one click? What if while trying to read that PDF you were 90% done downloading another large file (say a DVD iso) that is equally accessible with or without a proxy? Should it be restarted from scratch as there is no guarantee as to data integrity in case of (range GET) resuming with another proxy (a different cached copy comes to mind as a trivial example)? That's why I said it might be up to the application to know what to do :-) But it might be an issue that's not really solvable without user interaction anyway... Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
Le mardi 21 octobre 2008, à 10:30 -0400, Nathaniel McCallum a écrit : Hi, I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. The only argument I see against libproxy is yet another library while we're trying to reduce the number of libraries and people seemed to agree that this is actually not a real issue. So I guess we can accept it, unless someone else raises another issue? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
Le jeudi 23 octobre 2008, à 14:53 +0100, Bastien Nocera a écrit : Heya, I'd be interested in getting gnome-user-share into GNOME 2.26. Same comments as the ones I did for brasero :-) Please add gnome-user-share to the list at the top of http://live.gnome.org/TwoPointTwentyfive/Desktop and also add it to gnome-suites-2.26.modules (below the !-- Proposed Modules -- comment and in the meta-gnome-proposed metamodule). Thanks! Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Thu, Nov 6, 2008 at 2:23 PM, Vincent Untz [EMAIL PROTECTED] wrote: What if the connection works in both cases, but the results are different? I would guess it's up to the application to know if the connection should be restarted. An example for this (although this is a short-life connection) is that you can directly access PDF of the ACM library via a proxy while you end up on a webpage asking you to login if you don't use the proxy. I guess there could be similar examples -- but maybe it's not that important, don't know. But is it likely that the user remembers and manages to switch the proxy *during* the download to save one click? What if while trying to read that PDF you were 90% done downloading another large file (say a DVD iso) that is equally accessible with or without a proxy? Should it be restarted from scratch as there is no guarantee as to data integrity in case of (range GET) resuming with another proxy (a different cached copy comes to mind as a trivial example)? -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
Le samedi 01 novembre 2008, à 19:27 +0100, Philippe Rouquier a écrit : Hi, We'd be interested in having brasero integrated into the GNOME desktop. Please add brasero to the list at the top of http://live.gnome.org/TwoPointTwentyfive/Desktop and also add it to gnome-suites-2.26.modules (below the !-- Proposed Modules -- comment and in the meta-gnome-proposed metamodule). Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Thu, 2008-11-06 at 15:01 +0100, Vincent Untz wrote: Le mardi 21 octobre 2008, à 10:30 -0400, Nathaniel McCallum a écrit : Hi, I'd like to propose libproxy (LGPL 2.1+; http://code.google.com/p/libproxy/) as a blessed external dependency for GNOME 2.26. libproxy is currently used by vlc and neon and libsoup and webkit are considering adopting it. The only argument I see against libproxy is yet another library while we're trying to reduce the number of libraries and people seemed to agree that this is actually not a real issue. Personally, I'm less concerned with how many libraries we happen to depend on to build Gnome than I am with how many interfaces we're presenting to our third-party developers. Ideally, I'd love to see a GLib-level networking library. If that happened to use libproxy, wonderful. But since we don't have the single point of entry right now, exposing libproxy as a potential interface to our developers seems like the reasonable thing to do. That is to say, we should only reduce the number of libraries through unification, not through reduction of features. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.25.1 Released!
On Thu, Nov 6, 2008 at 7:02 PM, Vincent Untz [EMAIL PROTECTED] wrote: desktop - http://download.gnome.org/desktop/2.25/2.25.1/NEWS * bug-buddy: * Drop libgnome and libgnomeui dependencies. * cheese: - drop libgnome/libgnome-vfs dependencies, fixes bug #556580, courtesy of Cosimo Cecchi Should these be updated in jhbuild moduleset? The removed modules, however, are still pulled in via other dependencies. Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ Index: modulesets/gnome-suites-2.26.modules === --- modulesets/gnome-suites-2.26.modules(revision 2476) +++ modulesets/gnome-suites-2.26.modules(working copy) @@ -243,7 +243,6 @@ autotools id=bug-buddy branch/ dependencies - dep package=libgnomeui/ dep package=gnome-menus/ dep package=gnome-doc-utils/ dep package=evolution-data-server/ @@ -262,8 +261,6 @@ dep package=gstreamer/ dep package=gst-plugins-base/ dep package=gst-plugins-good/ - dep package=gnome-vfs/ - dep package=libgnomeui/ dep package=librsvg/ dep package=gnome-desktop/ /dependencies ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.25.1 Released!
Theppitak Karoonboonyanan wrote: Should these be updated in jhbuild moduleset? Yes (please file a bug report as I won't get over this just now); btw I started reviewing dependencies for all modules and already updated a few of them. Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.25.1 Released!
On Thu, Nov 6, 2008 at 10:32 PM, Frederic Peters [EMAIL PROTECTED] wrote: Theppitak Karoonboonyanan wrote: Should these be updated in jhbuild moduleset? Yes (please file a bug report as I won't get over this just now); btw OK. Bug #559610 filed. -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: notification-daemon+libnotify
On Thu, Oct 30, 2008 at 9:40 AM, Bastien Nocera [EMAIL PROTECTED] wrote: On Thu, 2008-10-30 at 10:24 -0400, Colin Walters wrote: Yes, I know what your initial reaction is - again?. Only maintainers can propose new modules, so unless we're talking external dependency, Christian would have to write that mail... I don't know how busy Christian is. But even if he is too busy to propose the module himself, I think it is time for us to be honest about the fact that it is pretty much impossible to use the desktop without notification-daemon nowadays. Many components rely on the ability to notify users in this way and are severely reduced in functionality if the notification service is not available. Sure, the implementation may not be ideal, and in an ideal world, it would not have its own little theming island and would maybe just be part of the desktop shell, but we don't live in that world (yet ?). Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: notification-daemon+libnotify
Le jeudi 06 novembre 2008, à 10:57 -0500, Matthias Clasen a écrit : I don't know how busy Christian is. But even if he is too busy to propose the module himself, I think it is time for us to be honest about the fact that it is pretty much impossible to use the desktop without notification-daemon nowadays. Many components rely on the ability to notify users in this way and are severely reduced in functionality if the notification service is not available. Sure, the implementation may not be ideal, and in an ideal world, it would not have its own little theming island and would maybe just be part of the desktop shell, but we don't live in that world (yet ?). I'm more worried about the fact that there has been no release since early 2007 (if I'm not mistaken), and so distro are currently shipping it with patches. Maybe we can just import the module in GNOME svn and fix stuff there? Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: notification-daemon+libnotify
On 6 Nov 2008, at 15:57, Matthias Clasen wrote: But even if he is too busy to propose the module himself, I think it is time for us to be honest about the fact that it is pretty much impossible to use the desktop without notification-daemon nowadays. Many components rely on the ability to notify users in this way and are severely reduced in functionality if the notification service is not available. Anything that *relies* on this kind of notification is kind of broken IMHO, usability-wise (and probably accessibility-wise, too). Notification messages are really just status bar messages for the desktop. As such, they should be there to provide useful extra information if you want them to, but equally you should be able to switch them off altogether without adversely affecting your ability to use any applications. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: notification-daemon+libnotify
On Thu, Nov 6, 2008 at 11:00 AM, Vincent Untz [EMAIL PROTECTED] wrote: Le jeudi 06 novembre 2008, à 10:57 -0500, Matthias Clasen a écrit : I don't know how busy Christian is. But even if he is too busy to propose the module himself, I think it is time for us to be honest about the fact that it is pretty much impossible to use the desktop without notification-daemon nowadays. Many components rely on the ability to notify users in this way and are severely reduced in functionality if the notification service is not available. Sure, the implementation may not be ideal, and in an ideal world, it would not have its own little theming island and would maybe just be part of the desktop shell, but we don't live in that world (yet ?). I'm more worried about the fact that there has been no release since early 2007 (if I'm not mistaken), and so distro are currently shipping it with patches. Maybe we can just import the module in GNOME svn and fix stuff there? There are other maintenance-related issues to bring up as well, like the duplicated functionality in having both notification-daemon+libnotify and libcanberra doing sound notifications (tiny amount of code we could drop from the n-d implementation, since it seems libcanberra is/will be better taken care of, at least for now). Either way, it would be nice to at least see the notification stuff imported into GNOME's tree, where more people are likely to put eyes on it and be able to do things such as roll releases, squash a couple of tiny leaks Ubuntu is shipping patches for, etc. It would be a big step forward just to get that far. -A. Walton Vincent -- Les gens heureux ne sont pas pressés. ___ 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: new module proposal: notification-daemon+libnotify
But even if he is too busy to propose the module himself, I think it is time for us to be honest about the fact that it is pretty much impossible to use the desktop without notification-daemon nowadays. I can only second that. Some while ago, I offered g-s-d to use notification for all kind of error that might happen (well, under normal circumstances g-s-d is 100% silent, but you know that far-from-perfect world...). But it could not be done without blessed dependency. g-s-d is complex enough to be completely bug-free - but usually in case of g-s-d misbehaves it is not easy to find out what exactly happened - partially, because we do not have desktop-wide logging facilities. At least, using libnotify could improve things a bit (keeping g-s-d independent from X at the same time). Cheers, Sergey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: WebKit/GTK+
Vincent Untz wrote: Homepage: http://webkit.org/ http://live.gnome.org/WebKitGtk Proposal on d-d-l: http://mail.gnome.org/archives/desktop-devel-list/2008-April/msg00134.html License: LGPLv2 or later (I believe) Short description: == WebKit/GTK+ is the new GTK+ port of the WebKit, an open-source web content engine that powers numerous applications such as web browsers, email clients, feed readers, web and text editors, and a whole lot more. Was there a conclusion on this at some point? I can't find anything in the archives. It would be great to be able to depend on it since I have some improvements in Devhelp trunk which needs WebKit. Cheers, Richard Summary so far: === + many +1 + should be API/ABI stable and follow the GNOME release cycle + integration with various other libraries of the GNOME stack + patches (and plans) exist for various GNOME applications to make them use WebKit + the 2.24 branch of epiphany has been created from the 2.22 one, so will likely still use Gecko + main concern is about the accessibility support. The accessibility team is waiting for an update from the WebKit/GTK+ team. -- Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: WebKit/GTK+
Richard Hult wrote: WebKit/GTK+ is the new GTK+ port of the WebKit, an open-source web content engine that powers numerous applications such as web browsers, email clients, feed readers, web and text editors, and a whole lot more. Was there a conclusion on this at some point? I can't find anything in the archives. It would be great to be able to depend on it since I have some improvements in Devhelp trunk which needs WebKit. http://mail.gnome.org/archives/devel-announce-list/2008-August/msg1.html + WebKit/GTK+ (external dependency): - lots of community support - accessibility support might not be good enough (no reply from WebKit/GTK+ people) - epiphany will still use Gecko for 2.24 - yelp is still using Gecko at the moment (there's a WebKit branch) - devhelp trunk is WebKit-only - evolution people intend to use WebKit in 2.26 - we'd prefer to avoid depending on both Gecko and WebKit at the same time = rejected for 2.24, but we'll propose a general switch for 2.26 Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: WebKit/GTK+
Le jeudi 06 novembre 2008, à 17:58 +0100, Richard Hult a écrit : Was there a conclusion on this at some point? I can't find anything in the archives. It would be great to be able to depend on it since I have some improvements in Devhelp trunk which needs WebKit. It was not ready for 2.24 (a11y support was not good enough). I know people are willing to push this for 2.26 again, but we don't know yet if it'll be ready in time :/ Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: WebKit/GTK+
Frederic Peters wrote: Richard Hult wrote: WebKit/GTK+ is the new GTK+ port of the WebKit, an open-source web content engine that powers numerous applications such as web browsers, email clients, feed readers, web and text editors, and a whole lot more. Was there a conclusion on this at some point? I can't find anything in the archives. It would be great to be able to depend on it since I have some improvements in Devhelp trunk which needs WebKit. http://mail.gnome.org/archives/devel-announce-list/2008-August/msg1.html + WebKit/GTK+ (external dependency): - lots of community support - accessibility support might not be good enough (no reply from WebKit/GTK+ people) - epiphany will still use Gecko for 2.24 - yelp is still using Gecko at the moment (there's a WebKit branch) - devhelp trunk is WebKit-only - evolution people intend to use WebKit in 2.26 - we'd prefer to avoid depending on both Gecko and WebKit at the same time = rejected for 2.24, but we'll propose a general switch for 2.26 Can someone remind me of the specific reasons to switch? cheers, David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: WebKit/GTK+
On Thu, Nov 6, 2008 at 6:10 PM, David Bolter [EMAIL PROTECTED] wrote:
Can someone remind me of the specific reasons to switch?
Better (GObject- and signal-oriented) API, smaller memory footprint,
easily embeddable in other apps, does not come with its own graphical
toolkit and a kitchen sink ;)
Would also be a welcomed replacement for gtkhtml{2,3}
--
Patryk Zawadzki
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: WebKit/GTK+
David Bolter wrote: + WebKit/GTK+ (external dependency): Can someone remind me of the specific reasons to switch? The Epiphany team explains its decision to change in this post: http://blogs.gnome.org/epiphany/2008/04/01/the-future-of-epiphany/ I'll be speaking for other projects and they will hopefully correct me where I am wrong. Here is my perspective: for other parts in the desktop, a blessed WebKit is seen as an opportunity for new features (Empathy and its Adium-theme branch), for much improved standards compliance/support (Evolution and switching off gtkhtml), or simpler code (switching off GtkMozEmbed), or a mix of those. Cheers, Frederic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: WebKit/GTK+
Frederic Peters wrote: http://mail.gnome.org/archives/devel-announce-list/2008-August/msg1.html + WebKit/GTK+ (external dependency): - lots of community support - accessibility support might not be good enough (no reply from WebKit/GTK+ people) - epiphany will still use Gecko for 2.24 - yelp is still using Gecko at the moment (there's a WebKit branch) - devhelp trunk is WebKit-only - evolution people intend to use WebKit in 2.26 - we'd prefer to avoid depending on both Gecko and WebKit at the same time = rejected for 2.24, but we'll propose a general switch for 2.26 Ah, thanks. I'll keep hacking away in trunk and hope we can ship that for 2.26 then (and fall back to the old branch again if not). /Richard -- Imendio AB - Expert solutions in GTK+ http://www.imendio.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: notification-daemon+libnotify
On Thu, 2008-11-06 at 17:00 +0100, Vincent Untz wrote: I'm more worried about the fact that there has been no release since early 2007 (if I'm not mistaken), and so distro are currently shipping it with patches. Maybe we can just import the module in GNOME svn and fix stuff there? Yes, this seems a good idea to me. If we want to do this and are lacking a volunteer for importing/reviewing patches and bugs you can count me in :) Cheers, Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: WebKit/GTK+
For me, one of the most important problems we face with WebKit is its lack of accessibility support right now. I have a great fear that Alp may have grossly underestimated the scope of the work. I have some confidence, however, that the WebKit folks who were at GNOME Boston should be able to do a decent analysis of what it will take to add it. I so wish I wrote down all the names of the WebKit folks that were at GNOME Boston. I'd like to follow up to see how their exploration is coming along. Will On Thu, 2008-11-06 at 18:48 +0100, Richard Hult wrote: Frederic Peters wrote: http://mail.gnome.org/archives/devel-announce-list/2008-August/msg1.html + WebKit/GTK+ (external dependency): - lots of community support - accessibility support might not be good enough (no reply from WebKit/GTK+ people) - epiphany will still use Gecko for 2.24 - yelp is still using Gecko at the moment (there's a WebKit branch) - devhelp trunk is WebKit-only - evolution people intend to use WebKit in 2.26 - we'd prefer to avoid depending on both Gecko and WebKit at the same time = rejected for 2.24, but we'll propose a general switch for 2.26 Ah, thanks. I'll keep hacking away in trunk and hope we can ship that for 2.26 then (and fall back to the old branch again if not). /Richard ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: notification-daemon+libnotify
I would *love* to see this bug get fixed: http://trac.galago-project.org/ticket/91 Will On Thu, 2008-11-06 at 19:43 +0100, Cosimo Cecchi wrote: On Thu, 2008-11-06 at 17:00 +0100, Vincent Untz wrote: I'm more worried about the fact that there has been no release since early 2007 (if I'm not mistaken), and so distro are currently shipping it with patches. Maybe we can just import the module in GNOME svn and fix stuff there? Yes, this seems a good idea to me. If we want to do this and are lacking a volunteer for importing/reviewing patches and bugs you can count me in :) Cheers, Cosimo ___ 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: Proposed external dependency: WebKit/GTK+
Well I think the elephant in the room here is WAI-ARIA support for accessible DHTML (i.e. accessible Web2.0 applications). Last I checked this work is being done for WebKit by Apple engineers, and a Google engineer. Although the Firefox accessibility hackers have trail blazed this work and even provided a helpful implementor's guide [1], it is still a significant effort indeed. Other that that, I think over the past year work was done to move some of Safari's (non-ARIA) accessibility into a platform agnostic architecture. I think Alp then put in the GNOME atk bindings. I know WebKit is fashionable these days, but I don't think we should be too hasty here. If we going to switch let's do it for the right reasons. [1] https://developer.mozilla.org/en/ARIA_User_Agent_Implementors_Guide cheers, David Willie Walker wrote: For me, one of the most important problems we face with WebKit is its lack of accessibility support right now. I have a great fear that Alp may have grossly underestimated the scope of the work. I have some confidence, however, that the WebKit folks who were at GNOME Boston should be able to do a decent analysis of what it will take to add it. I so wish I wrote down all the names of the WebKit folks that were at GNOME Boston. I'd like to follow up to see how their exploration is coming along. Will On Thu, 2008-11-06 at 18:48 +0100, Richard Hult wrote: Frederic Peters wrote: http://mail.gnome.org/archives/devel-announce-list/2008-August/msg1.html + WebKit/GTK+ (external dependency): - lots of community support - accessibility support might not be good enough (no reply from WebKit/GTK+ people) - epiphany will still use Gecko for 2.24 - yelp is still using Gecko at the moment (there's a WebKit branch) - devhelp trunk is WebKit-only - evolution people intend to use WebKit in 2.26 - we'd prefer to avoid depending on both Gecko and WebKit at the same time = rejected for 2.24, but we'll propose a general switch for 2.26 Ah, thanks. I'll keep hacking away in trunk and hope we can ship that for 2.26 then (and fall back to the old branch again if not). /Richard ___ 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: Proposed external dependency: WebKit/GTK+
David Bolter wrote: Well I think the elephant in the room here is WAI-ARIA support for accessible DHTML (i.e. accessible Web2.0 applications). Last I checked this work is being done for WebKit by Apple engineers, and a Google engineer. Although the Firefox accessibility hackers have trail blazed this work and even provided a helpful implementor's guide [1], it is still a significant effort indeed. I thought this was more about implementing ATK support in webkit? Or are the two the same? I can't imagine how we wouldn't need GNOME-specific code for a widget to be accessible. Or is that code already there? behdad Other that that, I think over the past year work was done to move some of Safari's (non-ARIA) accessibility into a platform agnostic architecture. I think Alp then put in the GNOME atk bindings. I know WebKit is fashionable these days, but I don't think we should be too hasty here. If we going to switch let's do it for the right reasons. [1] https://developer.mozilla.org/en/ARIA_User_Agent_Implementors_Guide cheers, David Willie Walker wrote: For me, one of the most important problems we face with WebKit is its lack of accessibility support right now. I have a great fear that Alp may have grossly underestimated the scope of the work. I have some confidence, however, that the WebKit folks who were at GNOME Boston should be able to do a decent analysis of what it will take to add it. I so wish I wrote down all the names of the WebKit folks that were at GNOME Boston. I'd like to follow up to see how their exploration is coming along. Will On Thu, 2008-11-06 at 18:48 +0100, Richard Hult wrote: Frederic Peters wrote: http://mail.gnome.org/archives/devel-announce-list/2008-August/msg1.html + WebKit/GTK+ (external dependency): - lots of community support - accessibility support might not be good enough (no reply from WebKit/GTK+ people) - epiphany will still use Gecko for 2.24 - yelp is still using Gecko at the moment (there's a WebKit branch) - devhelp trunk is WebKit-only - evolution people intend to use WebKit in 2.26 - we'd prefer to avoid depending on both Gecko and WebKit at the same time = rejected for 2.24, but we'll propose a general switch for 2.26 Ah, thanks. I'll keep hacking away in trunk and hope we can ship that for 2.26 then (and fall back to the old branch again if not). /Richard ___ 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: WebKit/GTK+
Hi Behdad, Yes, ATK support is separate. My point is that a Grade A browser should support Web2.0 accessibility. WebKit doesn't yet, so I'm raising that as an issue. cheers, David Behdad Esfahbod wrote: David Bolter wrote: Well I think the elephant in the room here is WAI-ARIA support for accessible DHTML (i.e. accessible Web2.0 applications). Last I checked this work is being done for WebKit by Apple engineers, and a Google engineer. Although the Firefox accessibility hackers have trail blazed this work and even provided a helpful implementor's guide [1], it is still a significant effort indeed. I thought this was more about implementing ATK support in webkit? Or are the two the same? I can't imagine how we wouldn't need GNOME-specific code for a widget to be accessible. Or is that code already there? behdad Other that that, I think over the past year work was done to move some of Safari's (non-ARIA) accessibility into a platform agnostic architecture. I think Alp then put in the GNOME atk bindings. I know WebKit is fashionable these days, but I don't think we should be too hasty here. If we going to switch let's do it for the right reasons. [1] https://developer.mozilla.org/en/ARIA_User_Agent_Implementors_Guide cheers, David Willie Walker wrote: For me, one of the most important problems we face with WebKit is its lack of accessibility support right now. I have a great fear that Alp may have grossly underestimated the scope of the work. I have some confidence, however, that the WebKit folks who were at GNOME Boston should be able to do a decent analysis of what it will take to add it. I so wish I wrote down all the names of the WebKit folks that were at GNOME Boston. I'd like to follow up to see how their exploration is coming along. Will On Thu, 2008-11-06 at 18:48 +0100, Richard Hult wrote: Frederic Peters wrote: http://mail.gnome.org/archives/devel-announce-list/2008-August/msg1.html + WebKit/GTK+ (external dependency): - lots of community support - accessibility support might not be good enough (no reply from WebKit/GTK+ people) - epiphany will still use Gecko for 2.24 - yelp is still using Gecko at the moment (there's a WebKit branch) - devhelp trunk is WebKit-only - evolution people intend to use WebKit in 2.26 - we'd prefer to avoid depending on both Gecko and WebKit at the same time = rejected for 2.24, but we'll propose a general switch for 2.26 Ah, thanks. I'll keep hacking away in trunk and hope we can ship that for 2.26 then (and fall back to the old branch again if not). /Richard ___ 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 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: notification-daemon+libnotify
Hi everyone. So, yes, I've been pretty busy as of late and haven't done a release in a while. I've been waiting on some work to be finished for a patch for notification-daemon these past couple of months and have decided it can wait. I'll be performing a release shortly. I actually meant to do this about two weeks ago, but have had some stuff going on in my life that's delayed this. Hopefully this weekend. As far as patches go, I've noticed that some distros are shipping patches that have never come across to me. If there are distros with patches that are not in notification-daemon SVN, please do send them my way so I can include them for the release. The tentative plan for notification-daemon and libnotify is to move them into SVN and switch over to Bugzilla. I'm then hoping to get someone to act as a co-maintainer for this. There will be a formal code review process for these modules, using a Review Board installation I'm setting up. All code will be expected to go through this before being committed in the code base (aside from translations). I would also like to formally propose notification-daemon and libnotify for inclusion into GNOME. To be quite honest, I've in the past lost interest in proposing this because it was rejected time and time again despite half the desktop depending on it nowadays, and I just left things up to the various distros to decide whether to provide the full functionality of these applications. However, I would like to get this into the GNOME desktop and as someone before said, I think we need to be realistic about the fact that this is pretty heavily used now and is in essence a dependency already. Christian -- Christian Hammond - [EMAIL PROTECTED] VMware, Inc. On Thu, Nov 6, 2008 at 10:43 AM, Cosimo Cecchi [EMAIL PROTECTED] wrote: On Thu, 2008-11-06 at 17:00 +0100, Vincent Untz wrote: I'm more worried about the fact that there has been no release since early 2007 (if I'm not mistaken), and so distro are currently shipping it with patches. Maybe we can just import the module in GNOME svn and fix stuff there? Yes, this seems a good idea to me. If we want to do this and are lacking a volunteer for importing/reviewing patches and bugs you can count me in :) Cheers, Cosimo ___ 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: new module proposal: notification-daemon+libnotify
I can assure you that this hasn't bit-rotted. It has been in development, but my work on Unity at VMware this past year basically took up all my free time. I would be happy to have people who want to contribute and fix bugs. I plan to keep the roll as maintainer, and have a couple people in mind for a co-maintainer. If people really want certain things in or fixed, by all means, submit patches. Nobody has done so in a while and nobody's really been complaining about anything to my knowledge, so I haven't felt that a release was that urgent. Still, there are some important fixes in SVN, some of which were waiting for additional patches that I never got and only recently had time to finish up. I should be in a good position to do a release soon. Christian -- Christian Hammond - [EMAIL PROTECTED] VMware, Inc. On Thu, Nov 6, 2008 at 8:46 AM, Patryk Zawadzki [EMAIL PROTECTED]wrote: On Thu, Nov 6, 2008 at 5:30 PM, A. Walton [EMAIL PROTECTED] wrote: There are other maintenance-related issues to bring up as well, like the duplicated functionality in having both notification-daemon+libnotify and libcanberra doing sound notifications (tiny amount of code we could drop from the n-d implementation, since it seems libcanberra is/will be better taken care of, at least for now). Either way, it would be nice to at least see the notification stuff imported into GNOME's tree, where more people are likely to put eyes on it and be able to do things such as roll releases, squash a couple of tiny leaks Ubuntu is shipping patches for, etc. It would be a big step forward just to get that far. Hell, I know almost nothing about its internals but still would be willing to become a maintainer if needed (maybe I wouldn't do much in terms of real programming time but I sure can review and commit patches). It's just too useful to let it bit-rot. Over time we can adjust the feature set and/or the API (should not be a huge problem as long as we update libnotify as well). -- Patryk Zawadzki ___ 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: Proposed external dependency: WebKit/GTK+
Heh - there are definitely two things: 1) How well WebKit exposes itself to assistive technologies. This is what the ATK support is about. 2) How well WebKit interprets ARIA. The take away from GNOME Boston is that WebKit doesn't do either very well, even *after* Joanie applied Alp's a11y patches. So, there is a fair amount of work to do. Will David Bolter wrote: Hi Behdad, Yes, ATK support is separate. My point is that a Grade A browser should support Web2.0 accessibility. WebKit doesn't yet, so I'm raising that as an issue. cheers, David Behdad Esfahbod wrote: David Bolter wrote: Well I think the elephant in the room here is WAI-ARIA support for accessible DHTML (i.e. accessible Web2.0 applications). Last I checked this work is being done for WebKit by Apple engineers, and a Google engineer. Although the Firefox accessibility hackers have trail blazed this work and even provided a helpful implementor's guide [1], it is still a significant effort indeed. I thought this was more about implementing ATK support in webkit? Or are the two the same? I can't imagine how we wouldn't need GNOME-specific code for a widget to be accessible. Or is that code already there? behdad Other that that, I think over the past year work was done to move some of Safari's (non-ARIA) accessibility into a platform agnostic architecture. I think Alp then put in the GNOME atk bindings. I know WebKit is fashionable these days, but I don't think we should be too hasty here. If we going to switch let's do it for the right reasons. [1] https://developer.mozilla.org/en/ARIA_User_Agent_Implementors_Guide cheers, David Willie Walker wrote: For me, one of the most important problems we face with WebKit is its lack of accessibility support right now. I have a great fear that Alp may have grossly underestimated the scope of the work. I have some confidence, however, that the WebKit folks who were at GNOME Boston should be able to do a decent analysis of what it will take to add it. I so wish I wrote down all the names of the WebKit folks that were at GNOME Boston. I'd like to follow up to see how their exploration is coming along. Will On Thu, 2008-11-06 at 18:48 +0100, Richard Hult wrote: Frederic Peters wrote: http://mail.gnome.org/archives/devel-announce-list/2008-August/msg1.html + WebKit/GTK+ (external dependency): - lots of community support - accessibility support might not be good enough (no reply from WebKit/GTK+ people) - epiphany will still use Gecko for 2.24 - yelp is still using Gecko at the moment (there's a WebKit branch) - devhelp trunk is WebKit-only - evolution people intend to use WebKit in 2.26 - we'd prefer to avoid depending on both Gecko and WebKit at the same time = rejected for 2.24, but we'll propose a general switch for 2.26 Ah, thanks. I'll keep hacking away in trunk and hope we can ship that for 2.26 then (and fall back to the old branch again if not). /Richard ___ 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 ___ 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: Proposed external dependency: WebKit/GTK+
On Thu, 2008-11-06 at 18:21 +0100, Frederic Peters wrote: I'll be speaking for other projects and they will hopefully correct me where I am wrong. Here is my perspective: for other parts in the desktop, a blessed WebKit is seen as an opportunity for new features (Empathy and its Adium-theme branch), for much improved standards compliance/support (Evolution and switching off gtkhtml), or simpler code (switching off GtkMozEmbed), or a mix of those. Anyone know the status of WebKit's GObject-based editing API? That's the main thing keeping Evolution from putting a bullet in GtkHtml. I'm hesitant to ship a release with both WebKit and GtkHtml dependencies (the former for rendering, the latter for editing). Matthew Barnes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
