Re: Proposal to enable accessibility by default for GNOME development releases
OK - I'll answer my own question - this approach doesn't seem to do what we want. In testing and testing with this, the problem is that some assistive technologies depend upon the existence and value of the key itself: if it's not enabled, they let the user know and then enable it. I embarassingly know this now because that's what Orca does, and I'm pretty sure it's what Gnopernicus does. So It seems as though the right thing to do is enable accessibility in the default schema for development releases. Anyone have a clue for how to do this? Will On Fri, 2006-10-27 at 11:12 -0400, Willie Walker wrote: Hi All: This has festered for a little bit without further comment, so I'd like to poke it one more time to try to get this in for the GNOME 2.17.2 tarballs. Please speak up if you disagree and/or don't like the proposed patch (and you have a constructive alternative solution ;-)): http://bugzilla.gnome.org/show_bug.cgi?id=362457 Thanks! Will On Sat, 2006-10-14 at 19:18 -0400, Willie Walker wrote: Hi All: As part of the GNOME Boston 2006 Accessibility Summit, and as part of the larger GNOME testing discussions, we would like to propose that accessibility is enabled by default for GNOME development releases. That is, make the /desktop/gnome/interface/accessibility gconf setting be True by default for the odd (e.g., 2.17.x) releases. A couple of the reasons for doing this include the following: o The accessibility infrastructure will be used as part of the larger testing work. Having accessibility enabled by default will make it a little easier to set up and use the testing facilities. A lower barrier to entry means more people might be encouraged to test. ;-) o We need broader use and coverage of the accessibility infrastructure. Having accessibility enabled by default will help provide this. When we proposed this idea at the afternoon summary to all of the GNOME Boston 2006 attendees, the response seemed to be fairly positive. Jeff suggested posting a proposal to this list to see if we can get the ball rolling. Thoughts? Will ___ 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: Proposal to enable accessibility by default for GNOME development releases
On 11/1/06, Willie Walker [EMAIL PROTECTED] wrote: So It seems as though the right thing to do is enable accessibility in the default schema for development releases. Anyone have a clue for how to do this? We can use a autoconf variable on the schema file and expand it depending on minor version of libgnome (the packaging owning that schema). We would need to rename: schemas/desktop_gnome_interface.schemas.in to: schemas/desktop_gnome_interface.schemas.in.in and apply the attached patch to do the auto* magic voodoo and use the variable in the schema file. Salu2 Index: configure.in === RCS file: /cvs/gnome/libgnome/configure.in,v retrieving revision 1.246 diff -u -r1.246 configure.in --- configure.in 4 Sep 2006 14:30:45 - 1.246 +++ configure.in 1 Nov 2006 16:00:58 - @@ -191,6 +191,15 @@ AC_CHECK_LIB(popt, poptStrippedArgv,, AC_MSG_ERROR([popt 1.5 or newer is required to build libgnome. You can download the latest version from ftp://ftp.rpm.org/pub/rpm/dist/rpm-4.0.x/])) +LIBGNOME_MINOR_VERSION=libgnome_minor_version +if test $(( $(echo $LIBGNOME_MINOR_VERSION) %2)) == 1; then + A11Y_ENABLED=true +else + A11Y_ENABLED=false +fi + +AC_SUBST(A11Y_ENABLED) + AC_CONFIG_FILES([ Makefile libgnome-zip @@ -198,6 +207,7 @@ libgnome/Makefile monikers/Makefile schemas/Makefile +schemas/desktop_gnome_interface.schemas.in gnome-data/Makefile libgnome/libgnome-2.0.pc libgnome/libgnome-2.0-uninstalled.pc diff -u desktop_gnome_interface.schemas.in.in.orig desktop_gnome_interface.schemas.in.in --- schemas/desktop_gnome_interface.schemas.in.in.orig 31 Aug 2006 21:47:20 - +++ schemas/desktop_gnome_interface.schemas.in.in 1 Nov 2006 16:00:58 - @@ -6,7 +6,7 @@ applyto/desktop/gnome/interface/accessibility/applyto ownergnome/owner typebool/type - defaultfalse/default + default@A11Y_ENABLED@/default locale name=C shortEnable Accessibility/short longWhether Applications should have accessibility support/long ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal to enable accessibility by default for GNOME development releases
Willie Walker wrote: OK - I'll answer my own question - this approach doesn't seem to do what we want. In testing and testing with this, the problem is that some assistive technologies depend upon the existence and value of the key itself: if it's not enabled, they let the user know and then enable it. I embarassingly know this now because that's what Orca does, and I'm pretty sure it's what Gnopernicus does. GOK does it too :-P David So It seems as though the right thing to do is enable accessibility in the default schema for development releases. Anyone have a clue for how to do this? Will On Fri, 2006-10-27 at 11:12 -0400, Willie Walker wrote: Hi All: This has festered for a little bit without further comment, so I'd like to poke it one more time to try to get this in for the GNOME 2.17.2 tarballs. Please speak up if you disagree and/or don't like the proposed patch (and you have a constructive alternative solution ;-)): http://bugzilla.gnome.org/show_bug.cgi?id=362457 Thanks! Will On Sat, 2006-10-14 at 19:18 -0400, Willie Walker wrote: Hi All: As part of the GNOME Boston 2006 Accessibility Summit, and as part of the larger GNOME testing discussions, we would like to propose that accessibility is enabled by default for GNOME development releases. That is, make the /desktop/gnome/interface/accessibility gconf setting be True by default for the odd (e.g., 2.17.x) releases. A couple of the reasons for doing this include the following: o The accessibility infrastructure will be used as part of the larger testing work. Having accessibility enabled by default will make it a little easier to set up and use the testing facilities. A lower barrier to entry means more people might be encouraged to test. ;-) o We need broader use and coverage of the accessibility infrastructure. Having accessibility enabled by default will help provide this. When we proposed this idea at the afternoon summary to all of the GNOME Boston 2006 attendees, the response seemed to be fairly positive. Jeff suggested posting a proposal to this list to see if we can get the ball rolling. Thoughts? Will ___ 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
gnome-menus branched for 2.16
Hi, gnome-menus has branched - 2.16 stuff on the gnome-2-16 branch. Cheers, Mark. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Document font preference
In my font preferences I see a Document font option. It affects the gconf key /desktop/gnome/interface/document_font_name, which is documented as Name of the default font used for reading documents. However, changing this font seems to have no effect on any GNOME application. Two question: 1- why does this preference exist if not used? 2- Can I use it in my application, or is it deprecated? Thanks, -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Document font preference
On Qua, 2006-11-01 at 18:26 +, Gustavo J. A. M. Carneiro wrote: In my font preferences I see a Document font option. It affects the gconf key /desktop/gnome/interface/document_font_name, which is documented as Name of the default font used for reading documents. However, changing this font seems to have no effect on any GNOME application. Sorry, someone on IRC pointed out bug #160454; it appears that Yelp uses this (I forgot to check it). By the way, wouldn't it be nice if gtk+ GtkTextView widgets used this font by default? -- Gustavo J. A. M. Carneiro [EMAIL PROTECTED] [EMAIL PROTECTED] The universe is always one step beyond logic ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-menus branched for 2.16
On 11/1/06, Joachim Noreiko [EMAIL PROTECTED] wrote: Is there a list anywhere of what all these modules are and what they each do? Just searched for 'gnome-menus' on the wiki but I've not come out any more informed. gnome-menus is the library that powers the menu bar and alacarte. It's a GNOME implementation of the freedesktop.org menu specification. -- Travis Watkins http://www.realistanew.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Document font preference
On Wed, 2006-11-01 at 18:33 +, Gustavo J. A. M. Carneiro wrote: On Qua, 2006-11-01 at 18:26 +, Gustavo J. A. M. Carneiro wrote: In my font preferences I see a Document font option. It affects the gconf key /desktop/gnome/interface/document_font_name, which is documented as Name of the default font used for reading documents. However, changing this font seems to have no effect on any GNOME application. Sorry, someone on IRC pointed out bug #160454; it appears that Yelp uses this (I forgot to check it). Also gnome-dictionary uses it. By the way, wouldn't it be nice if gtk+ GtkTextView widgets used this font by default? It should be set using the XSettings bridge like the other properties. ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Document font preference
2006-11-01 klockan 19:26 skrev Gustavo J. A. M. Carneiro: In my font preferences I see a Document font option. It affects the gconf key /desktop/gnome/interface/document_font_name, which is documented as Name of the default font used for reading documents. However, changing this font seems to have no effect on any GNOME application. Two question: 1- why does this preference exist if not used? Gossip uses it, and Yelp as well. We need to get more apps to use it, eg. Evolution and RSS readers. mvrgr, Wouter -- :wq mail [EMAIL PROTECTED] web http://uwstopia.nl no more kill :: no more kill i'm in love -- black rebel motorcycle club signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Potential need for librsvg API breakage
Hi, So I'm currently faced with a dilemma that's hitting a lot of users, causing their applications to crash and otherwise behave badly. I'd appreciate if people might offer any insight they had on the issue. In the 2.16.x series, librsvg's fundamental type, the RsvgHandle, became a subclass of GObject, and is registered via g_type_register_static(). AFAIK, this relationship isn't exposed in any way that the public ABI is concerned (i.e. RsvgHandle is just a anonymous typedef in the header file). The problem is that librsvg is a library that gets used by a lot of plugins - I can think of at least 3 places: AbiWord's image loader, GdkPixbuf's loader architecture, and GTK+'s theme engine. Some of these (GTK+'s theme engine bits come to mind) make heavy use of what GObject calls dynamic types that get loaded/unloaded as necessary, and the GModule that ultimately called g_type_register_static(RSVG_TYPE_HANDLE, ...) may get unloaded. Since there is no way to signal that types need to be unregistered, this causes subsequent registration of the RsvgHandle type to fail, and lots of code to go belly-up. This is bad. Now, I don't intend to pass judgment on the type registration system. I just want to come up with the best way to fix the problem I'm encountering. I can think of a few solutions, but I welcome other ideas and suggestions for implementing my proposals. 1) Make helper-processes that do the heavy lifting. Have the plugins call those processes via a wire protocol (see also: The Gimp). The helper-process calls type registration. Problem goes away. Pros: No API breakage Cons: A decent amount of work. Performance penalties in at least 2 places (pixbuf loading, theme engine) where performance actually matters. 2) Break API. Involves changing documentation, removing type registration, etc. Probably need to tweak libtool bits to suggest interface breakage. Pros: No performance hit Cons: The obvious. Plus, Rsvg makes use of other GObject-based libraries (libgsf, gnome-vfs) that may still in-turn exhibit problems. 3) Whatever you all come up with Thanks for your help and understanding, Dom -- I believe in making the world safe for our children, but not our children's children, because I don't think children should be having sex. -Jack Handy ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Potential need for librsvg API breakage
On Wed, 1 Nov 2006, Dominic Lachowicz wrote: Hi, So I'm currently faced with a dilemma that's hitting a lot of users, causing their applications to crash and otherwise behave badly. I'd appreciate if people might offer any insight they had on the issue. In the 2.16.x series, librsvg's fundamental type, the RsvgHandle, became a subclass of GObject, and is registered via g_type_register_static(). AFAIK, this relationship isn't exposed in any way that the public ABI is concerned (i.e. RsvgHandle is just a anonymous typedef in the header file). The problem is that librsvg is a library that gets used by a lot of plugins - I can think of at least 3 places: AbiWord's image loader, GdkPixbuf's loader architecture, and GTK+'s theme engine. Some of these (GTK+'s theme engine bits come to mind) make heavy use of what GObject calls dynamic types that get loaded/unloaded as necessary, and the GModule that ultimately called g_type_register_static(RSVG_TYPE_HANDLE, ...) may get unloaded. this is already broken and has to be fixed. if you want to be able to unload a type implementaiton, you MUST use g_type_register_dynamic. using g_type_register_static and unloading its implementaiton is as good as dlopen(); atexit(dlsym()); dlclose(); the alternative is of course to make the module effectively unloadable by means of g_module_make_resident or dlopen(self) once loaded. Since there is no way to signal that types need to be unregistered, this causes subsequent registration of the RsvgHandle type to fail, and lots of code to go belly-up. This is bad. Now, I don't intend to pass judgment on the type registration system. I just want to come up with the best way to fix the problem I'm encountering. I can think of a few solutions, but I welcome other ideas and suggestions for implementing my proposals. 3) Whatever you all come up with i'm not sure what exactly your problem is here. if it's just the combo of g_type_register_static + unloading, simply prevent unloading or use g_type_register_dynamic. if it's something else, i didn't manage to grasp it from your email ;) Thanks for your help and understanding, Dom --- ciaoTJ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
