Re: Move to LGPL3
Le samedi 15 mars 2008 à 21:43 +0100, Christian Persch a écrit : Hi Jean; Am Samstag, den 15.03.2008, 21:09 +0100 schrieb Jean Bréfort: Hmm, and what will happen to applications using at least one GPLv2-only libraries? This might indeed pose a problem, though I'm not sure how major it is. I have to admit that it is however not a theoretical problem, since we just found out that we do depend on one such library in Gnome: evince uses libpoppler which is a fork of Xpdf, and it is GPL version 2 only. Other affected projects are Goffice (GPL-v2 only) and all those which depend on it, namely Gnumeric, Abiword, Gnucash and GChemUtils (the last also use OpenBabel, another GPL-v2 only library). Seems that all the projects I'm involved in would be affected. Some can be relicensed, but probably not all, just because some previous contributors seem to have disappeared from the earth surface. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes: Foreign OSes BoF
I think that they're ready to go. Outside of the GTK+ tree, they won't get much testing. Do you think they cam unconditionally replace the traditional loaders that depend on external libraries for Win32, or should we add some --disable-gdiplus-loaders switch to the configury? --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
On Sat, 2008-03-15 at 21:48 +0100, Tim Janik wrote: On Sat, 15 Mar 2008, Andrew Cowie wrote: This topic was discussed recently on foundation-list. http://mail.gnome.org/archives/foundation-list/2008-March/msg00032.html In summary, attempting to relicence the library would be, in practise, impossible. No further benefit is gained by discussing this topic further. Updating the glib gtk+ headers to LGPLv3 is not relicensing. Our headers currently state: * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later version. So, everone is allowed to redistribute [...] under the terms of the GNU Lesser General Public License [...] version 2 [...] or [...] later, which LGPLv3 fullfills. Accepting LGPLv3 submissions in the future means that the library as a whole would effectively become LGPL = 3 licensed. So then, we might as well adapt our headers to reflect this. The LGPL also says: To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. Which means you can't add more restrictions to the license without effectively relicensing. I'm pretty sure it would also be a mess for applications that want to use proprietary GStreamer plugins. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
On Sun, 16 Mar 2008, Bastien Nocera wrote: On Sat, 2008-03-15 at 21:48 +0100, Tim Janik wrote: Our headers currently state: * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2 of the License, or (at your option) any later version. The LGPL also says: To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. Which means you can't add more restrictions to the license without effectively relicensing. We're not retro-changing the license of anything that has been released already, so we're not restricting rights anyone already has. We're talking about modifying redistributing future versions of GLib Gtk+ under LGPLv3, which the license clearly allows. --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes: Foreign OSes BoF
Hi Tor, On Sun, Mar 16, 2008 at 4:27 AM, Tor Lillqvist [EMAIL PROTECTED] wrote: I think that they're ready to go. Outside of the GTK+ tree, they won't get much testing. Do you think they cam unconditionally replace the traditional loaders that depend on external libraries for Win32, or should we add some --disable-gdiplus-loaders switch to the configury? I'd have them unconditionally replace the traditional loaders wherever the format is supported by the GDI+ plugin. I'd unconditionally add the formats supported by this plugin but not by GdkPixbuf (i.e. WMF and EMF). And I'd still build the traditional XPM, ANI, etc. plugins, as they don't have any external dependencies. Dom -- Counting bodies like sheep to the rhythm of the war drums. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Proposal] Helper functions in GTK+ for showing help and URIs
On Fri, Feb 29, 2008 at 10:19 PM, Jaap A. Haitsma [EMAIL PROTECTED] wrote: Hi, Can one of the maintainers decide what to do with the patch attached at http://bugzilla.gnome.org/show_bug.cgi?id=514396 Can I commit? Should I remove gtk_show_help? I removed gtk_show_help and attached the updated patch in the bugreport http://bugzilla.gnome.org/show_bug.cgi?id=514396 More comments or can I commit it? Thanks Jaap ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Gtk+ Automated Refactoring
Buenos dias, Tim Janik wrote: Hello Gtk+ Crowd. ... Further comments are of course welcome, we intend to keep the document updated as new issues are raised/solved. The proposed plan to migrate to Gtk+ 3.0 is going to remove public struct fields and introduce new accessors for these attributes. I've been looking into automating that. For instance: GTK_WIDGET (button)-style will be invalid when running against Gtk+ 3.0 and have to be refactored into: gtk_widget_get_style (GTK_WIDGET (button)) These kind of refactorings can easily be automated using simple regexs. by scanning for the macro syntax GTK_WIDGET and -style. I've written such a regex and generalized it into a python program which can do multiple field accesses to multiple types.[1] That program can successfully be run on the gtk+ tree for which it detects and refactors almost 500 field accesses. Some of them can be considered false positives as it's reasonable that the actual implementation of a widget should probably be allowed to access public fields. However, not all field accesses are done using macros, eg: widget-style Which is an example of a statement which cannot be converted using regexs, since the widget part can contain anything arbritary. To be able to refactor that statement a better understanding of the C language is required. Fortunately someone else has thought of that problem and there are tools available which can help in that process. Elsa[1], is a C/C++ parser which has the option to output a C syntax tree in XML form. I spent a some time during the hackfest building Elsa and running it on a source file in gtk+ (gtkbutton.c) which produced an XML output which seems to be suitable for our purposes. A generic tool which simplifies refactorings such as this one is a useful piece of software which will help not only our platform to migrate to 3.0, but more importantly, external applications. Quick howto for elsa, since I probably won't have too much time in the near future: * Download and build elsa * cpp -I. -I.. -I../gdk `pkg-config --cflags gio-2.0 glib-2.0 gobject-2.0 pango cairo atk` gtkbutton.c gtkbutton.c.preprocessed * ccparse -tr c_lang,xmlPrintAST gtkbutton.c.preprocessed Johan [1]: http://www.gnome.org/~johan/the-big-refactoring.py [2]: http://www.cs.berkeley.edu/~smcpeak/elsa/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Am Sonntag, den 16.03.2008, 07:49 +0100 schrieb Jean Bréfort: Le samedi 15 mars 2008 à 21:43 +0100, Christian Persch a écrit : Hi Jean; Am Samstag, den 15.03.2008, 21:09 +0100 schrieb Jean Bréfort: Hmm, and what will happen to applications using at least one GPLv2-only libraries? This might indeed pose a problem, though I'm not sure how major it is. I have to admit that it is however not a theoretical problem, since we just found out that we do depend on one such library in Gnome: evince uses libpoppler which is a fork of Xpdf, and it is GPL version 2 only. Other affected projects are Goffice (GPL-v2 only) and all those which depend on it, namely Gnumeric, Abiword, Gnucash and GChemUtils (the last also use OpenBabel, another GPL-v2 only library). Seems that all the projects I'm involved in would be affected. Some can be relicensed, but probably not all, just because some previous contributors seem to have disappeared from the earth surface. I am really wondering what's the reason for FSF claiming, that programs licenced GPL-2 only are not allowed to use LGPL-3 libraries. The LGPL-3 allows non-free, proprietary programs to use LGPL-3 libraries, but excludes free software, licensed GPL-2 only? This sounds absurd to me! Is the FSF spreading FUD with their license matrix? Why doesn't the matrix have footnotes explaining that absurd conflict? Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Am Samstag, den 15.03.2008, 21:48 +0100 schrieb Tim Janik: On Sat, 15 Mar 2008, Andrew Cowie wrote: This topic was discussed recently on foundation-list. http://mail.gnome.org/archives/foundation-list/2008-March/msg00032.html In summary, attempting to relicence the library would be, in practise, impossible. No further benefit is gained by discussing this topic further. Updating the glib gtk+ headers to LGPLv3 is not relicensing. Alternative interpretation: You fork under LGPLv3 or later, as permitted by LGPLv2.1 or later and keep LGPLv3 or later for the fork. Well, but I am no expert on legal stuff... Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes: Foreign OSes BoF
Am Sonntag, den 16.03.2008, 11:22 -0400 schrieb Dominic Lachowicz: Hi Tor, On Sun, Mar 16, 2008 at 4:27 AM, Tor Lillqvist [EMAIL PROTECTED] wrote: I think that they're ready to go. Outside of the GTK+ tree, they won't get much testing. Do you think they cam unconditionally replace the traditional loaders that depend on external libraries for Win32, or should we add some --disable-gdiplus-loaders switch to the configury? I'd have them unconditionally replace the traditional loaders wherever the format is supported by the GDI+ plugin. I'd unconditionally add the formats supported by this plugin but not by GdkPixbuf (i.e. WMF and EMF). And I'd still build the traditional XPM, ANI, etc. plugins, as they don't have any external dependencies. So what are your plans for PNG tEXt records? Does GDI+ support them? Unconditionally replacing the libpng loader, without supporting that records would be a regression. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Mathias Hasselmann wrote: Am Sonntag, den 16.03.2008, 07:49 +0100 schrieb Jean Bréfort: Le samedi 15 mars 2008 à 21:43 +0100, Christian Persch a écrit : Hi Jean; Am Samstag, den 15.03.2008, 21:09 +0100 schrieb Jean Bréfort: Hmm, and what will happen to applications using at least one GPLv2-only libraries? This might indeed pose a problem, though I'm not sure how major it is. I have to admit that it is however not a theoretical problem, since we just found out that we do depend on one such library in Gnome: evince uses libpoppler which is a fork of Xpdf, and it is GPL version 2 only. Other affected projects are Goffice (GPL-v2 only) and all those which depend on it, namely Gnumeric, Abiword, Gnucash and GChemUtils (the last also use OpenBabel, another GPL-v2 only library). Seems that all the projects I'm involved in would be affected. Some can be relicensed, but probably not all, just because some previous contributors seem to have disappeared from the earth surface. I am really wondering what's the reason for FSF claiming, that programs licenced GPL-2 only are not allowed to use LGPL-3 libraries. The LGPL-3 allows non-free, proprietary programs to use LGPL-3 libraries, but excludes free software, licensed GPL-2 only? This sounds absurd to me! It does say something about *GPL*, not about LGPL-3. You know, GPL-compatible license thing. Freedom or protection damn it. This Gtk relicensing thing is funny, by the way. Imagine this in a configure.ac PKG_CHECK_MODULES(GTK, gtk+-2.0 = 2.6) PKG_CHECK_MODULES(GTK_LEGAL, gtk+-2.0 2.16, [], [AC_MSG_ERROR([sorry but I won't do it, ask Gtk folks if you want to know why, I don't know why])]) Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
On Sat, 2008-03-15 at 21:43 +0100, Christian Persch wrote: Am Samstag, den 15.03.2008, 21:09 +0100 schrieb Jean Bréfort: Hmm, and what will happen to applications using at least one GPLv2-only libraries? This might indeed pose a problem, though I'm not sure how major it is. I have to admit that it is however not a theoretical problem, since we just found out that we do depend on one such library in Gnome: evince uses libpoppler which is a fork of Xpdf, and it is GPL version 2 only. Maybe it is good to start the relicensing process for (L)GPLv2-only to (L)GPLv2+. After all, that's the way the GPL is written. An please donc make the option of v3-only like KDE did. It is not practical. I totally agree about moving to v3, but don't put the cart before the horses :-) Hub ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
visibility-notify-event query
hi i asked the question in gtk +general but no response so i am asking it here i have a question regarding visibility-notify-event If i add widgets to a container than i get the signal visibility-notify-event, whenever visibility changes but if i add widgets to a scrolledwindow i donot get visibility-notify-event for the widgets that have scrolled up ie not visible nor i get unmap signal. What should i look for in order to get any of the two signals or anything else for the widgets in scrolled window that have either scrolled up or down which could tell me about there visibility. thanks and regards varun -- View this message in context: http://www.nabble.com/visibility-notify-event-query-tp16087944p16087944.html Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
