Re: [g-a-devel] GnomeClient replacement?
James Henstridge wrote: On 26/07/06, Fernando Herrera [EMAIL PROTECTED] wrote: On 7/26/06, James Henstridge [EMAIL PROTECTED] wrote: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. So if we are moving to this solution we could also add a gnome_segvhandler module to this XSETTING in order to get gtk_init load this module installing the segv handler, right? That would probably also be possible. With all the recent work on bug-buddy, would it make sense to make it such a runtime loadable module as suggested in this thread months ago? I think the a11y toggle is already an xsetting, so this could be one of the last steps towards converting some apps to use gtk_init instead of gnome_program_init and getting rid of the spurious dependencies the latter imposes. thanks Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
Le lundi 24 juillet 2006 à 23:43 -0400, Luis Villa a écrit : Ubuntu does better than anyone has done it since... well, a long time, at any rate. And by Ubuntu I mostly mean *you*, which makes me worry about burnout, sustainability, etc., but that's a different discussion, probably. Right, different topic, I just want to point that Daniel Holbach is spending a good deal of efforts on forwarding bugs upstream too and we are trying the ubuntu-qa team to work on that too No, of course not. But most distros don't do either the filtering *or* the upstreaming, and given the choice between unfiltered traces or none at all, we must choose unfiltered. The issue is to know if there is enough people working on triaging bugs upstream to keep up with all those bugs that would be sent... takes place at the gnome level, the duplication can be reduced. Right, people triaging upstream are always welcome and that would be nice to have distributions contributing actively to that! Again, I'm sorry I offended- the different distros have different success levels here, and obviously over the past 12-24 months Ubuntu has been pretty much a model. I think there is still a lot to be done, though, especially in automation and filtering, for all parties. No offense, I was just trying to point that dumping load of bugs directly upstream might not be a better solution than what we have at the moment because of the workload it would put on the limit bugsquad man power. Anyway as you said there lot to be done so let's everybody work in that direction ;) Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
James Henstridge wrote: I think you'll agree that we want a11y enabled for all GTK applications, and the best way to do this is to make the initialisation happen in gtk_init(). The gtk-modules XSETTING makes this possible. The proposed method of getting things loaded is: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. 2. in gtk_init(), GTK sees that the gtk-modules XSETTING is enabled, and loads the listed modules. 3. in the libgnomeui specific gnome_program_init() code, check to see if the accessibility gconf key is set and load libgail-gnome. This setup should make sure that all GTK applications load the GTK accessibility modules, and all libgnomeui applications load the libgnomeui-specific accessibility modules. If this is agreed upon is it possible to make it for 2.16? Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
It's probably libbonoboui that needs to add libgail-gnome as an additional module. I am a little uneasy about making this change so late, but if someone volunteers to help test, I'd be OK with it. Bill On Tue, 2006-08-01 at 15:34, Jani Monoses wrote: James Henstridge wrote: I think you'll agree that we want a11y enabled for all GTK applications, and the best way to do this is to make the initialisation happen in gtk_init(). The gtk-modules XSETTING makes this possible. The proposed method of getting things loaded is: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. 2. in gtk_init(), GTK sees that the gtk-modules XSETTING is enabled, and loads the listed modules. 3. in the libgnomeui specific gnome_program_init() code, check to see if the accessibility gconf key is set and load libgail-gnome. This setup should make sure that all GTK applications load the GTK accessibility modules, and all libgnomeui applications load the libgnomeui-specific accessibility modules. If this is agreed upon is it possible to make it for 2.16? Jani ___ Gnome-accessibility-devel mailing list Gnome-accessibility-devel@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
On 26/07/06, Bill Haneman [EMAIL PROTECTED] wrote: On Tue, 2006-07-25 at 19:20, James Henstridge wrote: Havoc's summary at the bottom of his email says why the current gnome_program_init() code is a hack: In summary: - if every libgtk app should do something, get that code in gtk (in the olden days this was not acceptable to the gtk+ team, but I agree that it makes sense to put it there now) - if every libgnome-using app should do something, get that code in libgnome this is what the gnome_program_init code does now (and it was indeed in libgnome) - if only a particular app should do something, get that code in that app yes, that is what happens now for such apps. Assuming that we want accessibility turned on for all GTK programs, then performing that initialisation in a libgnome routine is suboptimal since not every app links to libgnome (e.g. metacity). The fact that the current initialisation code is in gnome_program_init() means that cut-n-paste is necessary. NO: comments like this are why the misunderstanding flared up. The libgnome code is NOT a hack (or at least it clearly was not a hack when it was written!) for several reasons including the one you give below. gnome_program_init() look to be exactly the right place for this code according to Havoc's second category above. Putting the initialisation in gnome_program_init() may have been the best solution at the time it was added, but it was still sub-optimal because it only fixed the problem for a subset of the applications. I think you'll agree that we want a11y enabled for all GTK applications, and the best way to do this is to make the initialisation happen in gtk_init(). The gtk-modules XSETTING makes this possible. The proposed method of getting things loaded is: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. 2. in gtk_init(), GTK sees that the gtk-modules XSETTING is enabled, and loads the listed modules. 3. in the libgnomeui specific gnome_program_init() code, check to see if the accessibility gconf key is set and load libgail-gnome. This setup should make sure that all GTK applications load the GTK accessibility modules, and all libgnomeui applications load the libgnomeui-specific accessibility modules. Cutting and pasting the libgnome a11y code into other modules is that part that's broken. Yes. And the cut-n-paste is necessary because of where the code is. If the initialisation code is put in the right place, it only needs to be done once (the suggested solution being to make gnome-settings-daemon set the gtk-modules XSETTING that libgtk now watches). The initialization code needs access to the xsetting; in the pre-XSETTING days, this meant GTK_MODULES for pure-gtk+ and gconf for 'gnome' progs. It makes sense for gtk+ apps to do this via the xsetting now, instead of the env variable, that would improve the situation. However this will not work for programs in the second category (libgnome using apps). That's why the gnome_program_init code in libgnome has a11y loading logic... libgnome/libgnomeui using programs _are_ GTK programs. The XSETTING should be sufficient to load the basic GTK accessibility modules. The idea is to only do the libgnomeui-specific module loading in gnome_program_init(). Why don't you think this would work? James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
On 7/26/06, James Henstridge [EMAIL PROTECTED] wrote: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. So if we are moving to this solution we could also add a gnome_segvhandler module to this XSETTING in order to get gtk_init load this module installing the segv handler, right? Salu2 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
On 26/07/06, Fernando Herrera [EMAIL PROTECTED] wrote: On 7/26/06, James Henstridge [EMAIL PROTECTED] wrote: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. So if we are moving to this solution we could also add a gnome_segvhandler module to this XSETTING in order to get gtk_init load this module installing the segv handler, right? That would probably also be possible. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: downstream bugs [was Re: GnomeClient replacement?]
Luis Villa wrote: On 7/19/06, Dan Winship [EMAIL PROTECTED] wrote: Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So now that we've got XML-RPC support in bugzilla, it would be insanely cool if someone could write interfaces and code to let you do cross-bugzilla refiling / mark as duplicate / mark as depending on or blocking. (Including cross-bugzilla notifications of relevant changes.) So like, someone files a bug against the panel on SLED, we figure out that it's an upstream bug, but we still want to track it, because it's still a bug against our product too, and it's affecting a customer. So we click a little refile this upstream and mark the local bug as depending on the upstream one button, which does just that. Then if we investigate further, we can add comments upstream, or if someone else fixes it and closes the bug upstream, we'd get a notification of that, and can apply the fix and close our bug. I strongly believe developing and maintaining such tools would be a very worthwhile investment for the various distros- it would reduce the duplication of QA by all parties (which is pretty brutal overhead right now), increase the speed that fixes get to users (again, a win for all parties), so on, so forth. I'd even be willing to argue that this is something a paid bugmaster should do, or at least help the distros' QA teams with. Obviously not going to be me at this point, but something I think the board and advisory board should keep in mind. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list I really like this idea. We (Sun) had a process for upstreaming bugs but when GNOME head moved away from the center of gravity of our user base we didn't find it very useful. Now that we're developing closer to head again, we're encouraging non-distro specific bugs to be manually upstreamed. This isn't an easy sell because most QA and customer support people are familiar with one tool and one process. If GNOME was the only component in our distribution I'd push to drop our internal bug tools entirely and use b.g.o but it isn't. So I'd like to push internally for improving our process for mapping QA bug content to and from bugzilla, tools and a good process for managing bugs generated by users of legacy GNOME releases would certainly help make the case. What, besides bugzilla's XML-RPC support, do we need in order to make this work well? Off the top of my head: A cross-platform automated crash logger: - gathers corefile and symbols when possible - modular so that lsof, dtrace and stacktrace fingerprinting can be enabled. (Would it be useful if, when an infrequent bug happened in a component the logger could automatically load some more detailed tracing modules so that if it happens again we get a better trace?) A crash/bug/rfe GUI which allows opt-in/opt-out to avoid privacy law violations. An I hate this/I love this key which brings up the GUI and passes it information about the currently focused widget (or just a screenshot?) A crash/bug/rfe fingerprinter. - Gathers gnome release version, component versions, distribution and whatever else makes this crash/bug/rfe unique. - When passed a crash/bug/rfe object attempts to match the stack trace or bug description with known b.g.o bugs. A patch-bug mapper - O.K. maybe this is blue-sky stuff, but one of my pet peeves is when bugs are marked as fixed without any indication in the bug as to where the patch is, what version the patch applies to... I'd like to see a two way mapping between every fixed bug and the source patch that fixed it. I understand that this is often impossible when one patch fixes many bugs or several patches fix one bug and some of the patches only apply to patched distribution specific code... but wouldn't it be cool to always tag the bits of code responsible for fixing each bug/rfe with something that can be linked to and viewed from within the bug report? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
Humm I'm seeing a problem here. What about GNOME/GTK+ applications launched outside a gnome-session? (for example people using KDE). They won't get the gtk-modules XSETTING and then they won't be accesible at all. I guess that the solution that Kristian pointed (gtk loading auto loading runtime modules provided by the platform) may solve this problem: - gtk_init -- load_init_modules: - gnome a11y module -- Check a11y gconf key -- load gail and friends - bug-buddy module -- install segv handler. the downside of this method is that if we have installed gnome a11y modules then we are adding a little bit of overhead to only-gtk applications (loading gnome-module because it is installed, loading gconf, checking a11y). Salu2 On 7/26/06, James Henstridge [EMAIL PROTECTED] wrote: On 26/07/06, Fernando Herrera [EMAIL PROTECTED] wrote: On 7/26/06, James Henstridge [EMAIL PROTECTED] wrote: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. So if we are moving to this solution we could also add a gnome_segvhandler module to this XSETTING in order to get gtk_init load this module installing the segv handler, right? That would probably also be possible. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
On 7/26/06, Fernando Herrera [EMAIL PROTECTED] wrote: Humm I'm seeing a problem here. What about GNOME/GTK+ applications launched outside a gnome-session? (for example people using KDE). They won't get the gtk-modules XSETTING and then they won't be accesible at all. I guess that the solution that Kristian pointed (gtk loading auto loading runtime modules provided by the platform) may solve this problem: - gtk_init -- load_init_modules: - gnome a11y module -- Check a11y gconf key -- load gail and friends - bug-buddy module -- install segv handler. the downside of this method is that if we have installed gnome a11y modules then we are adding a little bit of overhead to only-gtk applications (loading gnome-module because it is installed, loading gconf, checking a11y). GTK+ programs running outside a session can either fall back to the GTK_MODULES envvar or use an xsettings manager even if they are running under, say, KDE. That was the initial idea of xsettings anyway, and I believe there is a xsettings manager for KDE that some distributions use. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
Le mercredi 26 juillet 2006 à 09:05 -0400, Matthias Clasen a écrit : On 7/26/06, Fernando Herrera [EMAIL PROTECTED] wrote: Humm I'm seeing a problem here. What about GNOME/GTK+ applications launched outside a gnome-session? (for example people using KDE). They won't get the gtk-modules XSETTING and then they won't be accesible at all. I guess that the solution that Kristian pointed (gtk loading auto loading runtime modules provided by the platform) may solve this problem: - gtk_init -- load_init_modules: - gnome a11y module -- Check a11y gconf key -- load gail and friends - bug-buddy module -- install segv handler. the downside of this method is that if we have installed gnome a11y modules then we are adding a little bit of overhead to only-gtk applications (loading gnome-module because it is installed, loading gconf, checking a11y). GTK+ programs running outside a session can either fall back to the GTK_MODULES envvar or use an xsettings manager even if they are running under, say, KDE. That was the initial idea of xsettings anyway, and I believe there is a xsettings manager for KDE that some distributions use. xsettings-kde : ugly hack but it works not so bad.. I might add accessibility in it too but I need to check if KDE has some accessibility key. http://cvs.mandriva.com/cgi-bin/viewvc.cgi/soft/xsettings-kde/ -- 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: downstream bugs [was Re: GnomeClient replacement?]
On 7/26/06, Brian Nitz [EMAIL PROTECTED] wrote: Luis Villa wrote: On 7/19/06, Dan Winship [EMAIL PROTECTED] wrote: Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So now that we've got XML-RPC support in bugzilla, it would be insanely cool if someone could write interfaces and code to let you do cross-bugzilla refiling / mark as duplicate / mark as depending on or blocking. (Including cross-bugzilla notifications of relevant changes.) So like, someone files a bug against the panel on SLED, we figure out that it's an upstream bug, but we still want to track it, because it's still a bug against our product too, and it's affecting a customer. So we click a little refile this upstream and mark the local bug as depending on the upstream one button, which does just that. Then if we investigate further, we can add comments upstream, or if someone else fixes it and closes the bug upstream, we'd get a notification of that, and can apply the fix and close our bug. I strongly believe developing and maintaining such tools would be a very worthwhile investment for the various distros- it would reduce the duplication of QA by all parties (which is pretty brutal overhead right now), increase the speed that fixes get to users (again, a win for all parties), so on, so forth. I'd even be willing to argue that this is something a paid bugmaster should do, or at least help the distros' QA teams with. Obviously not going to be me at this point, but something I think the board and advisory board should keep in mind. I really like this idea. We (Sun) had a process for upstreaming bugs but when GNOME head moved away from the center of gravity of our user base we didn't find it very useful. Now that we're developing closer to head again, we're encouraging non-distro specific bugs to be manually upstreamed. This isn't an easy sell because most QA and customer support people are familiar with one tool and one process. Also because GNOME does not take the time to make the benefits clear. I believe part of the job of a distro-focused bugmaster would be to say 'you filed X bugs upstream this quarter; Y percentage of them were fixed by the community', or other such numbers that would clarify the value to the distro. If GNOME was the only component in our distribution I'd push to drop our internal bug tools entirely and use b.g.o but it isn't. So I'd like to push internally for improving our process for mapping QA bug content to and from bugzilla, tools and a good process for managing bugs generated by users of legacy GNOME releases would certainly help make the case. All distros should be pushing for this :) Would it perhaps be useful to have a QA summit at the Boston Summit, where the various distros could compare notes on upstreaming technique, and see if there are ways they could collaborate? What, besides bugzilla's XML-RPC support, do we need in order to make this work well? Off the top of my head: A cross-platform automated crash logger: - gathers corefile and symbols when possible - modular so that lsof, dtrace and stacktrace fingerprinting can be enabled. (Would it be useful if, when an infrequent bug happened in a component the logger could automatically load some more detailed tracing modules so that if it happens again we get a better trace?) bug-buddy is inching in this direction, but yeah, tied to gdb right now. Would be great to see some investment in this by the distros (who are, after all, the ones directly financially impacted by crashes.) A crash/bug/rfe GUI which allows opt-in/opt-out to avoid privacy law violations. I believe bug-buddy already does this, no? An I hate this/I love this key which brings up the GUI and passes it information about the currently focused widget (or just a screenshot?) I like this idea, but would consider it a secondary priority until we can better handle crashes. Baby steps :) A crash/bug/rfe fingerprinter. - Gathers gnome release version, component versions, distribution and whatever else makes this crash/bug/rfe unique. Latest bug-buddy does this now, I believe. - When passed a crash/bug/rfe object attempts to match the stack trace or bug description with known b.g.o bugs. We're getting there ;) A patch-bug mapper - O.K. maybe this is blue-sky stuff, but one of my pet peeves is when bugs are marked as fixed without any indication in the bug as to where the patch is, what version the patch applies to... I'd like to see a two way mapping between every fixed bug and the source patch that fixed it. I understand that this is often impossible when one patch fixes many bugs or several patches fix one bug and some of the patches only apply to patched distribution specific code... but wouldn't it be cool to always tag the bits of code responsible for fixing
Re: GnomeClient replacement?
Because of build issues I have not been able to test a11y with gnome-session HEAD. Are you telling me that a11y is regressed severely in HEAD, as it sounds? GTK_MODULES alone will NOT work for the gnome desktop as a whole, since libgail-gnome should be selectively included. Elijah, why didn't you take this to the accessibility-devel-list? Bill On Tue, 2006-07-25 at 05:08, Elijah Newren wrote: On 7/19/06, Havoc Pennington [EMAIL PROTECTED] wrote: Bill Haneman wrote: gnome_program_init also loads the accessibility support, calling gconf in the process. It's not clear to me that this could conveniently be put elsewhere without complicating the dependencies of other modules... This is a broken hack that should have been killed long ago, should never have been allowed into libgnome at all since it means that gtk-only apps need to either cut-and-paste the code or just not be accessible, despite having all the other a11y code already in gtk. It can be done with e.g. a GTK_MODULE instead, iirc. or perhaps an xsetting type of deal to get the gconf flag into gtk itself. I remember threatening long ago to kill the cut-and-paste from metacity after a release or two if nobody fixed this properly; Elijah, you should do that, I think it's been maybe two years or more! Fortunately Elijah is probably nicer than me and won't enforce the threat ;-) Nah, I'm just as nasty. In fact, I didn't give advance warning (at least, not outside of bugzilla) and committed it already over two months ago. And without being sure it was completely right as you can see in my ChangeLog entry (but no one commented on the bug when I asked for comment, so...). There's a metacity bug about it iirc. Yep, 123372 as shown in the ChangeLog: 2006-05-15 Elijah Newren newren gmail com Revert the accessibility module loading workaround from Gnome 2.6, since gtk+ has long since fixed this for us. #123372. * src/Makefile.am: remove METACITY_LIBDIR define * src/main.c (find_accessibility_module, accessibility_invoke_module, accessibility_invoke, main): remove the first three of these functions and all calls to them * src/tabpopup.c (meta_ui_tab_popup_new): not sure if this part of 120025 needed to be reverted -- but doing the reversion, if wrong, is the best way to get someone from the accessibility team to scream, er, I mean comment. ;-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On 7/25/06, Bill Haneman [EMAIL PROTECTED] wrote: Because of build issues I have not been able to test a11y with gnome-session HEAD. Are you telling me that a11y is regressed severely in HEAD, as it sounds? No, I'd have to know whether it was in order to say so. I just finally caught up on part of my email and since Havoc was bringing up a bug from a few months ago (and made it sound less safe than I thought it was at that time), so I thought I'd comment. GTK_MODULES alone will NOT work for the gnome desktop as a whole, since libgail-gnome should be selectively included. Elijah, why didn't you take this to the accessibility-devel-list? accessibility was cc'ed on the bug (okay, a different alias but probably close, right?), and my reading of the bug said that it should be closable as soon as the blocking gtk+ bug was closed. It was closed, and had been for a long time. So, I added a patch and waited for about two weeks for comment, then just went and committed. I really didn't think it'd cause any adverse affects, at least not until I read Havoc's email yesterday. After that I wasn't so sure anymore. *shrug* Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
Looks to me as though this has caused a major regression, if I understand correctly. Back in the ancient days when the AT support was initially being added, we were discouraged from relying on environment variables to control the loading of accessibility modules. The gconf and gnome_program_init stuff was written to address this problem. Why has the recommended solution suddenly become an 'ugly hack' ? The GTK_MODULES solution has some nasty issues - some theoretical, some real - for instance it tends to break gtk-1.2 stuff badly. It also means that we have to load gnome-specific code into gtk-only programs if we don't use gnome_program_init, since there's no way to tell whether libgail-gnome needs to be loaded or not; we just have to add it to the GTK_MODULES list. (If nothing else, we need to make this change in gnome-session, in order to reverse the regression). A better solution would be to use an XSETTING for a11y instead of just a gconf key, so that apps could detect it w/o a gconf dependency. This has been discussed in the past and seems to me it would have been better than ripping the gnome_program stuff out first. As part of this, gtk+ would need to load the appropriate modules at runtime _itself_; i.e. every app and/or toolkit would be responsible for reading the please turn on AT support key and loading the appropriate modules. In the case of gtk+ apps, the modules required are libgail and libatk-bridge; for gnome apps that use embedding and bonobo, libgail-gnome is also required. Some apps load their own specialized code as well, for instance firefox and openoffice. Bill On Tue, 2006-07-25 at 16:29, Elijah Newren wrote: On 7/25/06, Bill Haneman [EMAIL PROTECTED] wrote: Because of build issues I have not been able to test a11y with gnome-session HEAD. Are you telling me that a11y is regressed severely in HEAD, as it sounds? No, I'd have to know whether it was in order to say so. I just finally caught up on part of my email and since Havoc was bringing up a bug from a few months ago (and made it sound less safe than I thought it was at that time), so I thought I'd comment. GTK_MODULES alone will NOT work for the gnome desktop as a whole, since libgail-gnome should be selectively included. Elijah, why didn't you take this to the accessibility-devel-list? accessibility was cc'ed on the bug (okay, a different alias but probably close, right?), and my reading of the bug said that it should be closable as soon as the blocking gtk+ bug was closed. It was closed, and had been for a long time. So, I added a patch and waited for about two weeks for comment, then just went and committed. I really didn't think it'd cause any adverse affects, at least not until I read Havoc's email yesterday. After that I wasn't so sure anymore. *shrug* Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On 7/25/06, Bill Haneman [EMAIL PROTECTED] wrote: A better solution would be to use an XSETTING for a11y instead of just a gconf key, so that apps could detect it w/o a gconf dependency. This has been discussed in the past and seems to me it would have been better than ripping the gnome_program stuff out first. As part of this, gtk+ would need to load the appropriate modules at runtime _itself_; i.e. every app and/or toolkit would be responsible for reading the please turn on AT support key and loading the appropriate modules. In the case of gtk+ apps, the modules required are libgail and libatk-bridge; for gnome apps that use embedding and bonobo, libgail-gnome is also required. Some apps load their own specialized code as well, for instance firefox and openoffice. We added the gtk-modules setting a long time ago. IIRC, the main purpose was to replace the use of GTK_MODULES for a11y, but that never happened... ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
On Tue, 2006-07-25 at 17:12, Matthias Clasen wrote: ... We added the gtk-modules setting a long time ago. IIRC, the main purpose was to replace the use of GTK_MODULES for a11y, but that never happened... I guess I don't fully understand the gtk-modules xsetting or how it works. If not for 2.16, I think we should have a look at how to migrate/improve the situation. For 2.16 it may be OK to just append libgail-gnome to the GTK_MODULES environment... Bill ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
On Tue, 2006-07-25 at 17:57, Havoc Pennington wrote: ... It's just that people were too lazy to fix it generically, and instead went on a cut-and-paste spree. That the cut-and-paste spree included libgnome and thus got some subset of apps all at once hardly changes the basic situation. Nobody should really need to be told this is an unacceptable patch, but in any case people were told. There must be some disconnect here, I thought we were talking about the code in gnome_program_init that reads the gconf key and loads the modules appropriately. I am pretty sure I have misunderstood you, since your comments below don't make any sense to me in the context that I took them. I will have a closer look at the metacity code to see if I understand the changes. I agree with your summary points 100%. Bill I accepted it _anyway_ as emergency band-aid, but then the people doing the patch abused that lapse of judgment and did not go back and remove the band-aid and fix things properly despite being explicitly asked to do so and being given a multi-year grace period. Which is why no band-aids is usually a good policy on the part of maintainers. The GTK_MODULES solution has some nasty issues - some theoretical, some real - for instance it tends to break gtk-1.2 stuff badly. It also means that we have to load gnome-specific code into gtk-only programs if we don't use gnome_program_init, since there's no way to tell whether libgail-gnome needs to be loaded or not; we just have to add it to the GTK_MODULES list. (If nothing else, we need to make this change in gnome-session, in order to reverse the regression). Read the bugs involved here; GTK_MODULES is not involved, it's an xsetting with a module list, which GTK 1.2 will ignore. Loading libgail-gnome in gnome_program_init is fine, since only GNOME programs need it. The gtk module list on the display could presumably only include things that all gtk apps should load. A better solution would be to use an XSETTING for a11y instead of just a gconf key, so that apps could detect it w/o a gconf dependency. This is not related to the module loading fix. Having gnome-settings-daemon set an XSETTING based on the existing a11y gconf key would be our normal approach to this, and allow non-gconf apps to check the a11y enabled flag. The problem is not checking this flag in metacity though, it's having all the cut-and-paste code. The point of the metacity revert is that the same module loading / a11y setup code should not be in every single app, if every gtk app should do it, then get gtk to do it somehow, someway. Anything that involves cut-and-pasting all over every app is a broken hack. If there's a11y code in an app that is truly specific to that app, then that is NOT a hack and is just fine. And it's fine for apps to look at the global a11y setting in order to decide whether to run that code. In summary: - if every libgtk app should do something, get that code in gtk - if every libgnome-using app should do something, get that code in libgnome - if only a particular app should do something, get that code in that app Havoc ___ Gnome-accessibility-devel mailing list Gnome-accessibility-devel@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On Tue, 2006-07-25 at 16:29, Elijah Newren wrote: accessibility was cc'ed on the bug A bug alias was cc'd, but not one of the 'live' a11y lists. It happened during my sabbatical, so I didn't see it. However - when I saw the diff I was concerned to see the module-loading code removed; what I didn't see was that it was code pasted into metacity that was removed, not the actual gnome-program code. Bill ymore. *shrug* Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
On 26/07/06, Bill Haneman [EMAIL PROTECTED] wrote: On Tue, 2006-07-25 at 17:57, Havoc Pennington wrote: ... It's just that people were too lazy to fix it generically, and instead went on a cut-and-paste spree. That the cut-and-paste spree included libgnome and thus got some subset of apps all at once hardly changes the basic situation. Nobody should really need to be told this is an unacceptable patch, but in any case people were told. There must be some disconnect here, I thought we were talking about the code in gnome_program_init that reads the gconf key and loads the modules appropriately. I am pretty sure I have misunderstood you, since your comments below don't make any sense to me in the context that I took them. I will have a closer look at the metacity code to see if I understand the changes. I agree with your summary points 100%. Havoc's summary at the bottom of his email says why the current gnome_program_init() code is a hack: In summary: - if every libgtk app should do something, get that code in gtk - if every libgnome-using app should do something, get that code in libgnome - if only a particular app should do something, get that code in that app Assuming that we want accessibility turned on for all GTK programs, then performing that initialisation in a libgnome routine is suboptimal since not every app links to libgnome (e.g. metacity). The fact that the current initialisation code is in gnome_program_init() means that cut-n-paste is necessary. If the initialisation code is put in the right place, it only needs to be done once (the suggested solution being to make gnome-settings-daemon set the gtk-modules XSETTING that libgtk now watches). On the other hand, gnome_program_init() making sure that libgail-gnome is initialised if a11y probably is a good idea, since programs linking to libgnome probably need libgail-gnome. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: downstream bugs [was Re: GnomeClient replacement?]
On 7/19/06, Dan Winship [EMAIL PROTECTED] wrote: Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So now that we've got XML-RPC support in bugzilla, it would be insanely cool if someone could write interfaces and code to let you do cross-bugzilla refiling / mark as duplicate / mark as depending on or blocking. (Including cross-bugzilla notifications of relevant changes.) So like, someone files a bug against the panel on SLED, we figure out that it's an upstream bug, but we still want to track it, because it's still a bug against our product too, and it's affecting a customer. So we click a little refile this upstream and mark the local bug as depending on the upstream one button, which does just that. Then if we investigate further, we can add comments upstream, or if someone else fixes it and closes the bug upstream, we'd get a notification of that, and can apply the fix and close our bug. I strongly believe developing and maintaining such tools would be a very worthwhile investment for the various distros- it would reduce the duplication of QA by all parties (which is pretty brutal overhead right now), increase the speed that fixes get to users (again, a win for all parties), so on, so forth. I'd even be willing to argue that this is something a paid bugmaster should do, or at least help the distros' QA teams with. Obviously not going to be me at this point, but something I think the board and advisory board should keep in mind. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GnomeClient replacement?
Hello, the GnomeClient API is for some apps the single Gnome dependency that has no GTK equivalent and that keeps said apps tied to the 25 or so platform libraries. Other libgnome(ui) uses are gnome_program_init() and gnome_help_display() which can be replaced by gtk_init variants and directly spawning gnome-open or yelp. Could there be a per application analysis of whether GnomeClient is really needed and whether it can be discarded or replaced by using the simple X API directly? I see it's on the Ridley TODO list but with no alternative proposed. thank you Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
Hey, On Wed, 19 Jul 2006, Jani Monoses wrote: the GnomeClient API is for some apps the single Gnome dependency that has no GTK equivalent and that keeps said apps tied to the 25 or so platform libraries. Other libgnome(ui) uses are gnome_program_init() and Yes! Fixing this will be very good for GNOME, and greatly reduce the cost of some our daemons. gnome_help_display() which can be replaced by gtk_init variants and directly spawning gnome-open or yelp. Well, the other thing that the gnome_program_init provides (as I understand it) is the bug-buddy hooks. However, IMHO, this is more of a distro thing. Ubuntu's solution (https://wiki.ubuntu.com/AutomatedProblemReports) seems to be better here, as distro specific stuff can make great efforts to get symbols, etc. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On 7/19/06, Ben Maurer [EMAIL PROTECTED] wrote: Well, the other thing that the gnome_program_init provides (as I understand it) is the bug-buddy hooks. However, IMHO, this is more of a distro thing. Ubuntu's solution (https://wiki.ubuntu.com/AutomatedProblemReports) seems to be better here, as distro specific stuff can make great efforts to get symbols, etc. Bt. Wrong. A couple things we know right now: * without what bug-buddy gives us currently, GNOME would be nigh-unusable. * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So... stack traces going to distros instead of bugzilla ~= nigh-unusable GNOME. Now, many things could be done to improve this, of course- most concretely, I firmly believe the payoff on investment would be multiplied many times for the distros if they invested in a full-time bugmaster whose responsibility was coordination for getting bug information upstream and downstream. *If* they did that, or otherwise committed more thoroughly to getting their data upstream in a manner that was timely and useful, it might make sense for stack traces to go to the distros- as you point out it, it is easier for them to provide complete stack trace data. But in the current situation (distros don't have the tools to create the better stack traces, and don't have the tools to get bugs upstream, even if they did get better stack traces) this feature should be taken away over the dead bodies of the QA team. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On mer, 2006-07-19 at 03:28 -0400, Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) I though we were doing a pretty good job at forwarding Ubuntu bugs upstream, but apparently it looks like you don't appreciate the efforts, makes me wonder if we should bother keeping doing that then So... stack traces going to distros instead of bugzilla ~= nigh-unusable GNOME. There you assume than distros don't send back useful informations upstream and than distros are doing no QA. What we are trying to do with bugs about the Ubuntu desktop is to get something useful before forwarding them upstream. I would have no issue to just dump hundred of useless bugs and non-debug backtraces upstream and stop trying getting details for them if you think that would be better complete stack trace data. But in the current situation (distros don't have the tools to create the better stack traces, and don't have the Luis, have you read the Ubuntu spec pointed by Ben? A part of it is about getting better backtraces, Martin Pitt already did some good work on it and it's likely we will get automatic debug backtraces when something crash for Ubuntu edgy Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On Wed, 2006-07-19 at 10:21 +0200, Sebastien Bacher wrote: On mer, 2006-07-19 at 03:28 -0400, Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) I though we were doing a pretty good job at forwarding Ubuntu bugs upstream, but apparently it looks like you don't appreciate the efforts, makes me wonder if we should bother keeping doing that then I was in discussions with another maintainer of core GNOME modules (that shall remained anonymous), and we were not very impressed at the way Ubuntu forwarded bugs. Bugs caused by Ubuntu specific patches should not be able to make their way to the GNOME bugzilla, and patches that aren't brand or slight preferences fixing should have an upstream bugzilla. I have seen some patches showing up in b.g.o after having been in Ubuntu for months. Gathering backtraces should be done in launchpad before a bug is opened upstream, and it's not the case sometimes. So it's not perfect, but I'm sure you'll get there. Cheers -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
the GnomeClient API is for some apps the single Gnome dependency that has no GTK equivalent and that keeps said apps tied to the 25 or so platform libraries. Other libgnome(ui) uses are gnome_program_init() and gnome_help_display() which can be replaced by gtk_init variants and directly spawning gnome-open or yelp Well, the other thing that the gnome_program_init provides (as I understand it) is the bug-buddy hooks. However, IMHO, this is more of a distro thing. Ubuntu's solution (https://wiki.ubuntu.com/AutomatedProblemReports) seems to be better here, as distro specific stuff can make great efforts to get symbols, etc. -- Ben gnome_program_init also loads the accessibility support, calling gconf in the process. It's not clear to me that this could conveniently be put elsewhere without complicating the dependencies of other modules... Bill ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
downstream bugs [was Re: GnomeClient replacement?]
Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So now that we've got XML-RPC support in bugzilla, it would be insanely cool if someone could write interfaces and code to let you do cross-bugzilla refiling / mark as duplicate / mark as depending on or blocking. (Including cross-bugzilla notifications of relevant changes.) So like, someone files a bug against the panel on SLED, we figure out that it's an upstream bug, but we still want to track it, because it's still a bug against our product too, and it's affecting a customer. So we click a little refile this upstream and mark the local bug as depending on the upstream one button, which does just that. Then if we investigate further, we can add comments upstream, or if someone else fixes it and closes the bug upstream, we'd get a notification of that, and can apply the fix and close our bug. -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: downstream bugs [was Re: GnomeClient replacement?]
On Wed, 2006-07-19 at 09:09 -0400, Dan Winship wrote: Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So now that we've got XML-RPC support in bugzilla, it would be insanely cool if someone could write interfaces and code to let you do cross-bugzilla refiling / mark as duplicate / mark as depending on or blocking. (Including cross-bugzilla notifications of relevant changes.) So like, someone files a bug against the panel on SLED, we figure out that it's an upstream bug, but we still want to track it, because it's still a bug against our product too, and it's affecting a customer. So we click a little refile this upstream and mark the local bug as depending on the upstream one button, which does just that. Then if we investigate further, we can add comments upstream, or if someone else fixes it and closes the bug upstream, we'd get a notification of that, and can apply the fix and close our bug. Debian has something like this. It only does the syncing after the bug has been forwarded upstream, currently the bug has to be forwarded manually. http://lwn.net/Articles/182383/ has a summary. I presume launchpad.net does something similar. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On mer, 2006-07-19 at 09:52 +0100, Bastien Nocera wrote: I was in discussions with another maintainer of core GNOME modules (that shall remained anonymous), and we were not very impressed at the way Ubuntu forwarded bugs. Right, there is probably nothing to be impressed about but we try to get useful details (debug backtrace by example) and to forward as many upstream issues as possible, no doubt we could do better though. Anything special you would like to get changed from the bugs we forward? (saying that you are not very impressed doesn't give anything special to work on to make that better) Bugs caused by Ubuntu specific patches should not be able to make their way to the GNOME bugzilla I don't think Ubuntu maintainers are forwarding a lot of bugs due to Ubuntu patches upstream but maybe your experience is different? Users are a different issue. We try to push people to report bugs to Ubuntu when they are not sure of what they are doing so we can filter distribution specific ones before sending them upstream but we can't stop people using bug-buddy or bugzilla if they want and patches that aren't brand or slight preferences fixing should have an upstream bugzilla. I have seen some patches showing up in b.g.o after having been in Ubuntu for months. Agreed, that is an issue for pretty much every distribution around. I looked at some fedora, mandriva and suse packages for useful patches we could use for Ubuntu before dapper, and all of them have GNOME patches that would be welcome upstream and have not been forwarded, so nothing specific to Ubuntu on that, but right we should try to do better on that Gathering backtraces should be done in launchpad before a bug is opened upstream, and it's not the case sometimes. That's one of the things we are working one and what Luis was complaining about So it's not perfect, but I'm sure you'll get there. Right, it's far for being perfect at the moment but I think it's still better than sending everything directly upstream by bud-buddy (which was the point of my first mail). Note that the purpose of the mail was not to say Ubuntu does a particularly good job at it, but to point that the job done by distributions might not be perfect but is still something useful and there is no reason flooding directly upstream with distributions bug would be better for GNOME Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
Bill Haneman wrote: gnome_program_init also loads the accessibility support, calling gconf in the process. It's not clear to me that this could conveniently be put elsewhere without complicating the dependencies of other modules... This is a broken hack that should have been killed long ago, should never have been allowed into libgnome at all since it means that gtk-only apps need to either cut-and-paste the code or just not be accessible, despite having all the other a11y code already in gtk. It can be done with e.g. a GTK_MODULE instead, iirc. or perhaps an xsetting type of deal to get the gconf flag into gtk itself. I remember threatening long ago to kill the cut-and-paste from metacity after a release or two if nobody fixed this properly; Elijah, you should do that, I think it's been maybe two years or more! Fortunately Elijah is probably nicer than me and won't enforce the threat ;-) There's a metacity bug about it iirc. This has got to be a perfect poster child for why maintainers should reject broken half-measures on grounds that nobody will fix it properly once you accept a broken patch. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
I have to disagree. As I recall the history, it was the GTK_MODULES/gtk+ fix that caught most of the flak (and still does, relying as it does on an env variable). At the time that the gconf key for assistive technology support was first introduced, nobody called it a hack. Now that we have xsettings in gtk+ I agree though that an XSETTING makes more sense. Bill On Wed, 2006-07-19 at 18:34, Havoc Pennington wrote: Bill Haneman wrote: gnome_program_init also loads the accessibility support, calling gconf in the process. It's not clear to me that this could conveniently be put elsewhere without complicating the dependencies of other modules... This is a broken hack that should have been killed long ago, should never have been allowed into libgnome at all since it means that gtk-only apps need to either cut-and-paste the code or just not be accessible, despite having all the other a11y code already in gtk. It can be done with e.g. a GTK_MODULE instead, iirc. or perhaps an xsetting type of deal to get the gconf flag into gtk itself. I remember threatening long ago to kill the cut-and-paste from metacity after a release or two if nobody fixed this properly; Elijah, you should do that, I think it's been maybe two years or more! Fortunately Elijah is probably nicer than me and won't enforce the threat ;-) There's a metacity bug about it iirc. This has got to be a perfect poster child for why maintainers should reject broken half-measures on grounds that nobody will fix it properly once you accept a broken patch. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On Wed, 2006-07-19 at 17:01, Shaun McCance wrote: Hey Bill, As usual, I'm afraid most of us don't understand all the layers as well as we ought to. Could you clarify exactly which pieces of the accessibility stack wouldn't get activated? There are a lot of GTK-only applications, probably a couple inside Gnome. What are these applications missing out on? For now, as pure gtk+ apps are relying on gnome-session to set the GTK_MODULES environment variable to load the modules gail and atk-bridge. This is not really optimal but it works well enough for gtk+-only apps (some apps that use gtk+, such as mozilla/firefox, have to take measures to un-set this variable and do their own accessibility work based on the gconf key). What we really want is for all desktop apps to have a way of detecting the need for assistive technology support without having the environment tell them what modules they must load in order to get it - in this sense the GTK_MODULES solution makes the apps accessible as a side effect, rather than providing clear semantics as does gconf. A boolean XSETTING would probably be nicer since it would allow apps to make their own decisions on what modules should be loaded in order to enable assistive technologies. This would mean that gtk+ would incur a soft dependency on libgail and at-spi which it currently does not have, but at this stage in the history of ATK this would probably be acceptable. It has been proposed that gail be rolled into gtk+ at some point, which would be very helpful (as a separate module, it can be very awkward to poke into gtk+ widgets to the extent necessary in order to implement ATK on their behalf). The $GTK_MODULES approach also fails for embedded apps and things that use gtkplug/gtksocket, since for those apps an additional module (libgail-gnome) must be loaded - unless we don't mind pure gtk+ apps loading that module needlessly. regards Bill -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On Wed, Jul 19, 2006 at 11:36:28AM +0100, Bill Haneman wrote: Well, the other thing that the gnome_program_init provides (as I understand it) is the bug-buddy hooks. However, IMHO, this is more of a distro thing. Ubuntu's solution (https://wiki.ubuntu.com/AutomatedProblemReports) seems to be better here, as distro specific stuff can make great efforts to get symbols, etc. -- Ben gnome_program_init also loads the accessibility support, calling gconf in the process. It's not clear to me that this could conveniently be put elsewhere without complicating the dependencies of other modules... Another thing which needs to be done there is for example setting up the URI handler for GtkLinkButton. There'll always be some things which need to be initialized in a way depending on the platform. As for the URI handler, the handler will differ on UNIX, Win32, OS X, etc. During GUADEC Matthias and I talked about maybe having support for some kind of runtime modules with one for each backend/platform. The module would contain a function that initializes stuff specific to that platform and GTK+ will run that during initialization. Just like what happens with the file system modules right now, we could ship a default simple module for GTK+-only apps on Linux and have some other GNOME package provide a GNOME runtime module, which initializes a11y, sets the bugzilla hooks, etc. Just some thoughts, no real concrete ideas ... regards, -kris. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
