Re: librsvg, where are you ?
http://git.gnome.org/cgit/librsvg/tree/MAINTAINERS http://git.gnome.org/cgit/librsvg/tree/ChangeLog http://librsvg.sourceforge.net/ irc://irc.gnome.org/#librsvg ... On Fri, Sep 11, 2009 at 8:27 AM, Andre Osku Schmidt andre.osku.schm...@osku.de wrote: Hello list, where could i communicate with the librsvg developers ? (and anyone who's interested in rsvg) cheers Andre Osku Schmidt ps. http://git.gnome.org/cgit/librsvg/tree/AUTHORS - 550 No such user ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- I like to pay taxes. With them, I buy civilization. -- Oliver Wendell Holmes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mutter with proprietary OpenGL/ES library ??
IANAL, but I think that this falls under the System Libraries and Standard Interface exceptions. It's why you can distribute GPL'd software on top of non-Free platforms (eg. Win32, .NET, Java until fairly recently, ...) On Wed, Jul 8, 2009 at 10:22 AM, Colin Walterswalt...@verbum.org wrote: On Tue, Jul 7, 2009 at 11:23 PM, Joone Hurjo...@kldp.org wrote: Hello All, Mutter(Metacity+Clutter) is very impressive technology. However, Mutter seems hard to be used on embedded devices. Because Metacity uses GPL license and most of HW accelerated OpenGL/ES library use a proprietary license. First, I'm not a lawyer. Now, a question - would the generic interface exception cover this? As I understand it, that's where it's not linking if A is using B through a mechanism that's not specific to B at all, and can be replaced with C and D. Now that Mutter is more of a library (in addition to an application) it would probably make sense for it to be LGPL to fit in with the rest of GNOME libraries, except that, well, relicensing is hell... If someone wants this to happen, they need to actively drive it (and have lots of patience), or find someone who will. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- I like to pay taxes. With them, I buy civilization. -- Oliver Wendell Holmes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moving spellcheckers into the Gtk+ stack
Hi Behdad, - Move Enchant into glib as a new module called gspell. Enchant is a small client-side library that loads modules that interface with spell-checking backends, like aspell, ispell, MySpell, etc. It's written by Dom, uses glib, and KDE recently forked it and called it kspell2 or something. So, I don't think it has a lot more opportunities as a fd.o project, and all its users are using the GNOME stack already. Other projects (OO.o, Mozilla), prefer to interface directly with backends or reinvent their own wrapper. So, by moving Enchant to glib, we bring spell-checking to the entire GNOME stack for free. This is quite in par with the gregex and gvfs efforts going on. Dom is pretty positive about this. For reference, here's Enchant's website: http://www.abisource.com/projects/enchant/ This is great, and I've been hoping for something like this for years now. For what glib version are we proposing to include this? There are some cleanups that I'd like to do before we move it up into a gspell library, but I had previously avoided in hopes of broader adoption by the KDE folks. That never happened, but I'm quite happy to have it included as part of the GNOME platform instead. I'd like to change the following when moving this up into gspell: *) Clean up the deprecated APIs *) Re-tool the library to use GErrors *) Translatable strings *) Rename functions to live in the gspell namespace *) Get some API review from ya'll *) Use XDG-DATADIRS when looking up dictionaries, plugins, and etc. *) Continue to provide an enchant library that wraps the new gspell component, for backward's compatibility? Or do we just leave Enchant 1.next as the last release of enchant proper? We'd want this to be optional built and have its own .pc file, like gregex. Other people's suggestions and critiques are of course welcomed. - Add properties and Gtk settings for turning on/off spell-checking globally, setting default languages, etc. Possibly adding context menu entries too. Yeah. We can probably do interesting things keying off of Pango's language property. - Develop a simple tool for control-center to adjust above settings. Is this strictly necessary? Or would it be better to have it default to g_getlocale()? Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. ___ 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: Resolution Independence in Gnome
using a precomputed raster version. Whether this is a performance problem remains to be seen, but cairo/svg is not performant yet. It is That's not quite true. In every test that I've done, librsvg + Cairo is between 2 and 10 times faster than librsvg + libart was. And librsvg + libart was faster loading many of these SVG icons than libpng was at loading the pre-rendered versions. Sure, it could be faster. But (afaik) no one was complaining that his/her 24px toolbar icons were taking too long to render. Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
librsvg has been branched
We branched a little while ago. Mundane 2.16 plans include: *) Working with Inkscape to support multiImage *) Supporting whatever SVG 1.2 features that Cairo 1.2's SVG backend requires, so that it doesn't need to do image fallbacks *) Translating the strings (something that's long overdue) *) Using GOption Best, Dom -- Counting bodies like sheep to the rhythm of the war drums. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module decisions for GNOME 2.14
Hi Vincent, I've been informed [1] (in a bugzilla comment, of all places) that Gnome 2.14 is going to use the 2.12 branch of librsvg in the upcoming release. I'd like confirmation on that, as my reference is only to a jhbuild module set, and I don't know how authoritative that is. Caleb Moore, Carl Worth, and I put in a lot of work getting everything ready for the Gnome 2.14 release, including ironing out countless bugs, adding dozens of new features, and applying layer upon layer of polish to the product. librsvg 2.12 is a vastly inferior product, and I don't (as yet) have plans to backport any of the patches that make librsvg 2.14 shine. Thanks, Dom [1] http://cvs.gnome.org/viewcvs/jhbuild/modulesets/gnome-2.14.modules?rev=1.41view=markup On 2/11/06, Vincent Untz [EMAIL PROTECTED] wrote: Hi all, The release team met yesterday to talk about all the current issues. Here are our conclusions. New modules: + gnome-power-manager: people like it, but some mor work is needed, and more integration should be done. It won't go in for 2.14, but we'd like to see a good integration work starting soon for 2.16. + libnotify/notification-daemon: it depends on libsexy. There was no consensus to include libsexy in our sets, and also some worries about the lack of HIG for notifications. Therefore it won't go in 2.14. Note that there was also strong support for it and, assuming those issues are resolved, it can absolutely be 2.16 material. We also believe that the nice libsexy widgets should be tested in a few apps and, if they work well, integrate them in our already existing libraries, like GTK+. + gnome-screensaver: there are some concerns about a possible slowness. People pointed out that it was most probably related to a fontconfig bug. Stay in for now, but we'll be watching closely to see if the issue has indeed been resolved or if the module may need to be pulled + for reference, other proposed modules that were previously accepted: pyorbit, deskbar-applet, fast-user-switch-applet, gnome-python-desktop, pessulus, sabayon Issues in other modules: + glib/pango: as previously announced, we'll ship the new versions (2.10/1.12) + gtk-engines: it's up to the maintainers to decide what to do. They'll look at the concerns that were sent on the lists and state what is their decision. (Looks like they recommend to use the 2.6.x versions for 2.14) + gnome-icon-theme: we fully support the adoption of the new icon naming spec. However the change happened too late for this cycle. We will ship with the 2.12 versions of gnome-icon-theme for GNOME 2.14 and encourage people to switch to the new version as soon as work for 2.16 happen. + GStreamer: current plan still is to go with 0.10. We all need to keep an eye on continued progress on this version. 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 -- Counting bodies like sheep to the rhythm of the war drums. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module decisions for GNOME 2.14
Hi Elijah, Crap. It sucks that this wasn't noticed so that those testing cvs could be testing the right thing. It looks like this was because you guys branched early last release, the 2.12 moduleset got copied for 2.14, and then no one caught this and updated it. Anyway, can you update that moduleset now to use HEAD? Yeah, we branched early so that we could focus on getting Cairo integration hammered out. I don't use jhbuild, so I would be more comfortable if someone who does use it made this change. I'd rather not make the change without being able to test it. (For the curious, it's worth nothing that http://live.gnome.org/TwoPointThirteen_2fDesktop is supposed to be the actual authoritative list (though I'm worried we may have sucked at keeping that up to date and correct) and it lists HEAD, we've been shipping 2.13.x tarballs during the 2.13.x releases and vendors are using it AFAICT, so I don't think lack of cvs testing should cause us to revert to 2.12 at this point. If you disagree, let us all know soon so we can debate it) 2.13 has gotten a lot of testing, and has come out a lot better than any previously released version. It has had a good number of bugs filed against it (and fixed), so it's gotten some testing by people other than Caleb and myself. I'm quite comfortable proposing it for inclusion in the 2.14 release and working with whomever to get any remaining issues ironed out. Best, Dom Thanks for pointing this out, Elijah -- Counting bodies like sheep to the rhythm of the war drums. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gtkspell (was Re: Announcing: Project Ridley)
On 1/19/06, Matthias Clasen [EMAIL PROTECTED] wrote: On 8/27/05, Chipzz [EMAIL PROTECTED] wrote: I'm not a Gtk+ developer, but I think one of the criteria for being considered is: doesn't introduce a new library dependency, or maybe it can, if it really makes sense. Gtk+ depending on a spell checking library hardly makes sense, however. I would envision a solution having two parts here: - some framework in GtkEntry/GtkTextView to support spellchecking - a module which makes use of the framework. The module could use Enchant, GtkSpell or any other spell-checking library - the module could be loaded desktop-wide, by using the gtk-modules setting that was introduced for this purpose a while ago. Enchant has been API/ABI stable for a while now, so I wouldn't mind proposing it for inclusion to the platform at some future point (or better still, free desktop). Chris Hammond's libsexy has a spell checking enabled GtkEntry subclass that depends on Enchant. It dlopen()'s the .so and looks up the functions by name rather than linking against it explicitly. If the module isn't found, spell checking is disabled. This might be something of a compromise solution, since it gives consumers a soft dependency on a spell checking lib rather than a hard dependency. Best, Dom ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
