Re: XPM support for NSImage
Hi everyone, Is there any interest in including my XPM NSImage support into GNUstep GUI? If so, I will sign the copyright form, and rework it as a patch against GNUstep GUI, rather than as a standalone class. If not, I'll probably get it into Etoile. Let me know. Thanks, Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: XPM support for NSImage
On Tue, 07 Nov 2006 17:28:09 -0500, Adrian Robert <[EMAIL PROTECTED]> said: >> It depends on libXpm, which is included in X11, or available from >> http://koala.ilog.fr/lehors/xpm.html. I'm not using any of the >> X11-specific functions from that library. > This may bother some people, especially those trying to deploy on > Windows. There is an alternative you might consider, which is to use > code included in GNU Emacs (image.c) for XPM support (originally > written for the Mac Carbon port by Yamamoto Mitsuharu). See http:// > lists.gnu.org/archive/html/emacs-devel/2004-04/msg00780.html Actually, libXpm has Windows support too, so it shouldn't be a problem on that platform. Honestly, though, the XPM format frightens me, and I'd rather use the library written by the people who created the format, and if necessary rip out the X11-specific bits. (No offense meant to YAMAMOTO Mitsuharu; I'm sure the patch that he wrote is good.) libXpm also provides functions for writing XPM files, if I ever want to add that as well. Thanks for the link, though. It's nice to see that someone was courageous enough to write an XPM parser. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: XPM support for NSImage
On Wed, 08 Nov 2006 00:47:53 +0100, Fred Kiefer <[EMAIL PROTECTED]> said: > Hubert Chan schrieb: >> >> Is there any interest in including my XPM NSImage support into >> GNUstep GUI? If so, I will sign the copyright form, and rework it as >> a patch against GNUstep GUI, rather than as a standalone class. If >> not, I'll probably get it into Etoile. > I would love to see support for XPM images and also many other format, > but not directly in gui. OK, that's fine. FWIW, I'm hoping to (eventually) also work on SVG support (using librsvg), PDF support (using PopplerKit, and implement Apple's NSPDFImageRep API), and DjVu support. (Roughly in that order.) > We rather should have it as an image filter service. Of course > somebody will have to write supporting code for that as well, but it > seems like the better solution. And it should not be to hard doing > this via the code already in NSPasteboard. But I don't have an idea on > the tasks involved in writing the filter service. Hmm... I'm not sure exactly what an image filter service is, or why it's needed. Right now, I'm just registering my class using NSImageRep's +registerImageRepClass:, so if you ask NSImage to load an XPM file, everything works fine. What else is needed? My current plan is to make it into a "user defined AppKit bundle", instead of making it a library as I'm currently doing it, so that every app can benefit from it. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: XPM support for NSImage
On Wed, 8 Nov 2006 06:30:11 +, Richard Frith-Macdonald <[EMAIL PROTECTED]> said: [...] > I think what Fred probably intended was to have a lot of filter > services available for different image file formats. Then in the gui > library have an NSImageRep subclass which would use any filter service > as required. That way, the only extra code in the gui library (and > hence linked in to apps) would be the little bit letting the > NSImageRep use filter services. The gui package could install a set > of image filters, but other packages/applications would also be able > to supply more or better filters. When the gui needs to convert from > format A to B it would just ask the NSImageRep to do it, and that > would automatically pick one of the available filters to perform the > actual conversion. Ah, OK. So the idea is to use the service to, say, convert an XPM to a PPM, and use the PNM loading code that is already in gui. Sounds a bit inefficient, but I guess it would allow us to reuse a lot of code from netpbm (or maybe even just create a wrapper around the netpbm programs). This would probably work for a simple bitmap format such as XPM, but it probably wouldn't work so well for, say, SVG, where we would want to keep all that vector goodness, or for PDF, where the Apple API includes extra methods like -setCurrentPage:. But if we could take advantage of netpbm (and ImageMagick), we would have free support for an insane number of file formats. Another thing is, does this also allow for writing files? -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Plans for change....
Hi Gregory, Congratulations on becoming chief maintainer. Thanks for your work so far, and thanks for your commitment to the project. And, of course, thanks to Adam for all of his work as chief maintainer as well. On Fri, 15 Dec 2006 20:10:01 -0800 (PST), Gregory John Casamento <[EMAIL PROTECTED]> said: [...] > 3) Eliminate the need for GNUstep.sh, either by making GNUstep place > it's binaries and libraries in more "standard" places, This is what we try to do for Debian, in order to satisfy the Debian Policy (which follows the FHS). Libraries get moved to /usr/lib, headers to /usr/include, architecture-independent files to /usr/share, and symlinks to make everything accessible from the normal *step hierarchy. And we have wrapper scripts in /usr/bin. It's not perfect, but it works, and we don't have any more complaints about policy violations. If you're interested, I can send you fuller details about the exact filesystem layout that we are using. If GNUstep does this sort of thing, I'd be more than happy to add my input wherever needed. > or by providing an installation procedure I'm not sure exactly what you're thinking of in terms of an installation procedure. But it should be fine as long as it can work well with GNU/Linux distributions. Again, I'd be more than happy to help out with this, with my Debian hat on. [...] > 5) Focus and concentrate on one and only one set of display > technologies per platform. We expend way too much time and energy on > maintaining mulitple backends (xlib, art and etc) when we really don't > have to. For Linux/BSD we have two functional backends and another on > the away for cairo. What's the point of this? In my opinion we should > complete the cairo backend and deprecate BOTH the xlib and art > backends. xlib is hopelessly outdated and libart isn't really > supported by anyone anymore. Yes please. ;) (We also need to get printing working properly. Fonts get messed up.) [...] > 7) Make GNUstep friendly with other environments like GNOME, KDE, > Windows and etc. Make sure that GNUstep functions sanely in these > environments. This might mean that we need to have behaviors for each > different environment. How to implement this is unclear, but it's > something that I believe would make the user experience better > overall. And I guess at least part of this would involve becoming involved in the freedesktop.org effort. (Unfortunately, probably not something that I can help out with much.) Although as a whole, this is probably a very tough problem. There are a few very big things that *step does differently. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Plans for change....
Gregory John Casamento wrote: [...] > I, personally, don't see much value in auto-layout, because > GNUstep/OPENSTEP provides the user with a way to have a GUI for each > locale, so that you can specifically tailor your GUI to each, but to > each his own. Well, it's not just about localization. If you change fonts, it may break the layout as well. But yes, as you say, to each his own. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test base library stable branch please
On Sat, 23 Dec 2006 15:38:16 +, Richard Frith-Macdonald <[EMAIL PROTECTED]> said: > Could people please make an effort to check out the stable branch > (http://svn.gna.org/viewcvs/gnustep/libs/base/branches/base-1_13_0/) > of the base library from subversion and check that none of the > backported bugfixes is faulty. Users of the Debian packages who don't want to compile it on their own can use my precompiled versions, available at: http://debian.uhoreg.ca/experimental/gnustep/gnustep-base/ You can also use the apt sources line: deb http://debian.uhoreg.ca/experimental/gnustep/ ./ It should be able to install straight on top of the regular Debian packages. Let me know if there are any problems with it. I'll try to keep the packages relatively up to date. Right now, the packages are based on an SVN checkout from last Saturday. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
On Thu, 28 Dec 2006 00:38:18 +0100, Guenther Noack <[EMAIL PROTECTED]> said: [...] > I could also imagine that a clear indication that xlib is deprecated > may help people outside the GNUstep project. For example when looking > at Etoile, there are at least the MultimediaKit and the > XWindowServerKit which directly talk to X11 (MMKit displays the > Mplayer window in a GNUstep window). For authors of projects like > these two, it may be very helpful to know that they won't have to > support xlib in the future. AFAIK, Etoile still needs to talk to X11 directly for those functions. They are mostly for things that the *Step API does not handle (e.g. switching desktops, embedding, etc.). -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test base library stable branch please
On Fri, 29 Dec 2006 21:23:25 +, "Paddy Smith" <[EMAIL PROTECTED]> said: [...] > I'd be happy to send/build you ppc binaries if it helps, but I imagine > you have buildds for that :-) Nope. I just have my i386 machine, and no buildd (it's a private build), so ppc binaries would be helpful. Thanks. (hmm. I may have to change the layout of my archive to handle different architectures...) Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Moving GNUstep applications to GPLv3
On Wed, 27 Jun 2007 10:09:37 +0200, Fred Kiefer <[EMAIL PROTECTED]> said: > I support this change as well. We already have the choice for the user > of the library in there: >This library is free software; you can redistribute it and/or >modify it under the terms of the GNU Library General Public License ^^^ Just to make sure this gets fixed: between versions 2 and 2.1 of the LGPL, the name was changed from the "Library" General Public License to the "Lesser" General Public License. Please make sure to change this when updating to version 3. Hubert >as published by the Free Software Foundation; either version 2 of >the License, or (at your option) any later version. > What I am not sure about is, whether we are able to change the license > for old code, where the contributor is no longer in contact with us. > Does anybody know about this case? > Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
On Wed, 22 Feb 2006 18:29:55 +, Richard Frith-Macdonald <[EMAIL PROTECTED]> said: > Maybe all we really need here is FHS support in the make package so > you can opt to install in FHS locations? And lots of publicity so > people know about it. FWIW, Debian is currently handling the FHS issue by using a script to move files around after they are installed by gnustep-make, and using lots of symlinks. (This is just for packages installed by dpkg, installed into the System domain. Packages that are manually installed just using gnustep-make are installed normally.) So under Debian, there is a /usr/lib/libgnustep-base.so.1.11, and other libraries can be found under /usr/lib too. But if gnustep-make had better support for FHS locations, that would be helpful too. -- Hubert Chan <[EMAIL PROTECTED]> - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: FHS compliance/Abstraction of NSBundle
On Mon, 8 May 2006 23:17:50 -0500, Andrew Ruder <[EMAIL PROTECTED]> said: [...] > P.S. I think this will also boost our adoption into distros > incredibly, GNUstep is not exactly the easiest thing to get into a > distro due to its non-conformity. Currently, in Debian, the GNUstep packages "fake" FHS compliance by using compatibility symlinks. For example, /usr/lib/GNUstep/System/Library/Headers is a symlink to /usr/include/GNUstep/Headers. This is just done for the System domain (i.e. packages installed by the Debian packaging system), and is done by using a script to move the files around after GNUstep Make has installed them. It doesn't change anything in the Local, Network, or user domains. It's not completely automated, though. There are some tricky cases -- e.g. sometimes Applications/Foo.app/Resources only includes only architecture-independent files (e.g. images), and should be moved to /usr/share. But sometimes Applications/Foo.app/Resources (I think I've seen one case) contains an executable or object code, so it has to be in /usr/lib. So some of that stuff has to be processed manually. (In reality, what usually happens is that the architecture-independent files are small enough, and they're just left in /usr/lib along with the rest of the Application bundle. And nobody has complained yet.) If anyone is interested in more of the details of what Debian does, let me know. Regarding needing to source GNUstep.sh and use openapp, Debian also provides wrapper scripts that take care of that. One problem with getting general FHS compliance that I can see is that the FHS doesn't have anything analogous to the Network or user domains. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: FHS compliance/Abstraction of NSBundle
On Wed, 10 May 2006 00:09:39 +0200, Helge Hess <[EMAIL PROTECTED]> said: > On 9. Mai 2006, at 23:06 Uhr, Hubert Chan wrote: >> One problem with getting general FHS compliance that I can see is >> that the FHS doesn't have anything analogous to the Network or user >> domains. > Well, Network is _roughly_ like /opt and user domains are basically in > ~ (~/bin, ~/lib if you wish to have that). Well, the FHS doesn't define things like ~/bin, ~/lib, ~/share, ~/include, or /opt/bin, /opt/lib, /opt/share, /opt/include. In fact, the FHS specifies that packages that get installed into /opt are installed into /opt/ or /opt/ directories. (And I think that /opt, as defined in the FHS, is more like Local than Network, but that's beside the point.) I suspect that what may end up happening is that, if GNUstep Make gets FHS compatibility bits put into it, it will have to install to FHS locations like /usr/lib, /usr/share, /usr/include for the System and Local domains, but stick with the traditional hierarchy for Network and User domains. Which is going to be really ugly. But that's just a guess. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: FHS compliance/Abstraction of NSBundle
On Wed, 10 May 2006 11:16:33 +0200, Helge Hess <[EMAIL PROTECTED]> said: > On May 10, 2006, at 6:11 AM, Hubert Chan wrote: >> the FHS doesn't define things > BTW: before this starts to go in the wrong direction again, we are not > talking about "just" FHS but integrating with the underlying operating > systems conventions. Which may not use FHS but some other FS > structure. > We are just using the FHS name because we have no better word for it > and because its the most common layout :-) OK. Well, I'm talking about the FHS specifically, as the Debian maintainer of the GNUstep libraries, because the FHS is what Debian cares about. Personally, I don't care much about what GNUstep does on Windows or other UNIX-like systems, although I do agree that it is a valuable discussion. I'm just not going to be able to provide much useful discussion on other systems, since it's not my area. > PS: FHS doesn't specify ~bin/~lib etc because FHS is concerned about > system packages, not on user customizations. And system packages never > install into ~. Well, at least thats how I understand it :-) True enough. My main concern, though, is that since the FHS doesn't define those directories, users might get upset if we start creating random directories in ~. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: FHS compliance/Abstraction of NSBundle
On Thu, 11 May 2006 00:15:51 +0200, Helge Hess <[EMAIL PROTECTED]> said: > On May 10, 2006, at 7:25 PM, Hubert Chan wrote: >> My main concern, though, is that since the FHS doesn't define those >> directories, users might get upset if we start creating random >> directories in ~. > OK, I see. Sure, we should not do this. But is anything put into > GNUSTEP_USER_ROOT except maybe defaults? I guess not unless this is > specifically requested by the user. No, I don't think anything gets put there automatically, unless the user does something like "make install GNUSTEP_INSTALLATION_DIR=...". > I think creating a ~/.gnustep directory containing per-user > configuration is reasonable and common practice. Yeah, one FHS issue with ~ is that the FHS says that configuration files are supposed to be in a dot-directory. Currently GNUstep configuration files are in ~/GNUstep/Defaults. But if we make GNUSTEP_USER_ROOT to be ~/.GNUstep, then user-installed applications, libraries, etc. get installed in a not-too-nice place, IHMO. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Need to make an unstable release for Debian by 8/26
On Sat, 19 Aug 2006 20:46:44 -0700 (PDT), Gregory John Casamento <[EMAIL PROTECTED]> said: > The Debian package maintainer will not be available from 9/1-9/17, so > it cuts that time out of the time we would have had to stabilize > things. :/ Just to clarify, things can be unstable (in terms of crashing/broken functionality). As long as programs that are compiled with the release that you make next week will be able to work with the next stable release without needing to be recompiled. (i.e. binary compatibility should not break between next week's release and the next stable release.) Thanks for your work, Greg. I hope I'm not rushing you too much. Hubert ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/Gorm code freeze
On Sat, 26 Aug 2006 19:01:39 +0200, Chris Vetter <[EMAIL PROTECTED]> said: [...] > However that brings me to another question that may look like > flame-bait... > Let's say there's a framework that implements one or more 'wanted' > classes but are licensed under, say, BSDL. Would it be permissible to > add those classes to GNUstep (since it's LGPL) or would those classes > have to be 'handed over' to FSF, changing the license in the process? > And what if the author doesn't want to change the original license but > adds a section that additionally puts the code under LGPL (that is, as > a dual license) provided / as long as the code is used in GNUstep? I think that the LGPL would prevent itself from being applied "as long as the code is used in GNUstep". (i.e. I believe that the LGPL essentially requires that you're able to rip it apart and distribute bits and pieces of it on their own, licensed under the LGPL.) But I don't think that in this case, licensing should be a problem, since the (3-clause) BSD license is, AIUI, compatible with the LGPL. The situation would be different for code licensed under a different license. The copyright assignment question, though, is a different matter, which I am not in any position to answer. There are ways around this, though, as long as the licensing is compatible, by wrapping the 'wanted' classes in an external library, and then having GNUstep call that library. Thus the library is not part of GNUstep (and hence wouldn't require copyright assignment), but GNUstep still gets to use the classes. Although this method is probably less desirable to actually having the classes in GNUstep. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Removing all remaining distinction between shared, debug, profile and static libs/executables
Sorry for the late reply, I was on vacation for the past couple weeks... On Thu, 7 Sep 2006 18:47:07 +0200 (CEST), "Nicola Pero" <[EMAIL PROTECTED]> said: > Adam has removed the '_d' library name suffix for debug libraries > ... a very welcome change which will make everything simpler and less > liable to break :-) > I think having done this, we lost the ability to have debug and > non-debug libs at the same time, so we can simplify everything a lot > ... without losing much more, since we have already done the big > sacrifice ;-) In Debian, with other libraries, what is usually done is the debug libs get installed in /usr/lib/debug, and the regular libs get installed in /usr/lib. Then, if you want to use the debug versions, you just set LD_LIBRARY_PATH. So you can do something similar here if you really want both versions installed. > 1. remove the difference between shared_obj, shared_debug_obj, > static_profile_obj, etc. too. Just use './obj' for everything (this > is kind of a no-brainer, now that there is no longer any difference in > the installed libraries, can't see any reason to keep a difference > while building!). Another advantage is we no longer need a symlink > here :-) I would prefer keeping the shared_obj and shared_debug_obj directories, since it makes compiling Debian packages easier (so that I can compile the regular and debug versions at the same time). But if you want to remove the distinction, this can probably be worked around. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
On Wed, 4 Oct 2006 21:28:49 +0200, Helge Hess <[EMAIL PROTECTED]> said: > On Oct 4, 2006, at 18:42, Richard Frith-Macdonald wrote: >>> Note: by 'unstable' I don't mean that the code itself is buggy but >>> that the ABI is unstable. >> Fair enough ... that's your definition ... but it's rather an unusual >> one. > Really? I think thats the term usually used by OpenSource > projects. But anyway ;-) > Stability is an inherent requirement for Linux distributions because > they can't change the ABI constantly. Which makes it a cycle of ~2 > years for all (serious) distributions. But at least 12 months. Yes, I agree. Having the ABI change frequently is a challenge for the Debian packaging team, since it means that every time a new GNUstep release is made, we have to recompile all our packages. Is there any reason we need to change the ABI all the time? (AFAIK, glib/gtk+ hasn't changed their ABI since glib/gtk+ 2.0 was released, so any old program that was compiled back then will still run on a newer system.) -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
On Wed, 4 Oct 2006 09:33:50 -0700 (PDT), Gregory John Casamento <[EMAIL PROTECTED]> said: > Since, you're the one making this assertion, I believe it's up to you > to prove that we have broken it in every release. I don't have the > same impression. IMHO, any time the SONAME is bumped, that counts as an ABI change, since you must recompile all your programs. The SONAMEs for GUI and for Base have been bumped for almost every release. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
Richard Frith-Macdonald said: > There is a tension between those who ask for more frequent releases > (because they want new features) and those who ask for less frequent > releases because they have some issue with keeping multiple releases > on disk I would prefer to have more frequent releases, but with a stable SONAME/ABI. > (you never need to recompile programs for a new release if you keep > the old libraries ... that's what library versioning is for). Actually, with the recent GNUstep 0.11.0/1.13.0 release, you are unable to run programs compiled against 0.10.3/1.12.0 because the old library could not communicate with ... I think it was gdnc (I assume due to a change in the communication protocol). On the other hand, if you take a program compiled against 0.10.3/1.12.0 and make libgnustep-base.so.1.12.0 a symlink to libgnustep-base.so.1.13.0, and libgnustep-gui.so.0.10.3 a symlink to libgnustep-gui.so.0.11.0, it seems to run perfectly fine. I just tried it on my system, with a few different programs, and they all ran fine, which suggests that we didn't need an SONAME bump. AFACT, the general rule that most other library developers follow is that if you add things to your libraary, you don't need to bump the SONAME. You only bump the SONAME if you remove things, or do other changes that remove library symbols (such as replace a function with a #define macro). So AFAICT, we don't really need to bump the SONAME for GNUstep at every release. > I think we are trying to make more frequent releases than we used to > ... eg once every six months, because (unscientific estimate) there > seem to be more complaints about there being too few releases than > about there being too many. > Actually, my sympathy with either complaint is limited ... People who > complain about too few releases always have the option of using SVN > trunk or snapshots with very little extra work required. Well, for the Debian packages, I'm a bit wary of packaging SVN snapshots, unless there's a very good reason for doing so. > People who complain about too many releases can always keep multiple > releases on their system or simply skip releases now and then, only > upgrading with bugfix releases for the main release they are using. Again, with my Debian packaging hat on (it would probably be less important to me just as a regular user), we're only supposed to have one version of each library in Debian, unless there's a very good reason for having multiple versions. So every time the SONAME is bumped, we need to recompile every GNUstep program, and every program has to be compiled before the new library can enter the testing distribution. > And as long as the complaints from both groups are roughly equal, > we've probably got the actual release rate about right. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
On Thu, 5 Oct 2006 01:42:15 +0200, Helge Hess <[EMAIL PROTECTED]> said: > On Oct 5, 2006, at 01:27, Jeremy Bettis wrote: >> I thought that to provide a "stable" ABI, you just can't do these >> things: > ... >> But these things should not cause instabilitity: >> >> Adding a class >> Adding a method > Thats wrong. A soname fixes one API, it can be neither extended nor > reduced (nor changed in the behaviour). I already gave the example of > adding a class. Sorry, I think we have different definitions of ABI stability. My understanding is the same as Jeremy Bettis. >From my understanding of what other (non-GNUstep) library developers do (e.g. GTK, QT, etc.), they don't consider adding functionality to be breaking the ABI. The only case that they tend to worry about is running previously-compiled programs with the new library: if that use case works, then they consider ABI compatibility to not be broken. They do not usually consider the case of a newly-compiled program (possibly depending on new functionality) running on an old library. Hence adding classes or methods are generally considered OK. (And I'm pretty sure that GTK has added some new classes and functions since their 2.0.) In fact, packaging systems generally take care of the second use case: a program compiled under the new library will depend on the new version of the library (in Debian, this is done using a dependency that looks like "libgnustep-gui0.10 (>= 0.10.2)", where "libgnustep-gui0.10" represents the SONAME, and "(>= 0.10.2)" represents the minimum version number required). > You are mixing up ABIs (or more exactly sonames) with backward > compatible APIs :-) ... Actually, I think that we (Jeremy and I) are talking about providing backward-compatible ABIs, whereas you are talking about ensuring backward- and forward-compatible ABIs. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On Thu, 12 Oct 2006 22:00:18 +0200 (CEST), "Nicola Pero" <[EMAIL PROTECTED]> said: [...] >> On a system where the traditional GNUstep filesystem layout is not >> used, the System domain should be /usr/local or /opt or whatever, >> unless the people managing a distribution want it to be /usr on that >> distribution of course. I imagine that on such systems the System >> and Local domains might be the same place. > I don't agree at all ... the System domain will of course be /usr, and > the Local domain will be /usr/local. Otherwise, why do we have > domains at all ? :-) Well, according to the FHS, if you download GNUstep and compile it on your own (not obtaining it from your distribution), then it should go under /usr/local, or /opt. In which case, Local and System are probably equivalent, since GNUstep itself is a "local" package, and there is no distribution involved. But if you obtain GNUstep from your distribution, then it should definitely go under /usr. So IMHO by default, the System and Local domains should be /usr/local, but the distributions will of course override that for their own packages. -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
On Fri, 13 Oct 2006 05:58:20 +0200 (CEST), "Nicola Pero" <[EMAIL PROTECTED]> said: >>> Things should be decoupled ... -make and -base don't really talk or >>> depend on each other. >> >> Not entirely true. Currently -base depends on -make for >> configuration. >> > Thanks, I see your point ... which is a very good one :-) > You're suggesting that, for example, in a binary distribution (say, > Debian) you could install gnustep-base without installing > gnustep-make. Well, since you mention Debian... ;) Debian currently splits off parts of gnustep-make into a package named gnustep-common. gnustep-common includes GNUstep.conf, openapp, GNUstep.sh, etc... all the stuff that a regular user might want for running GNUstep programs, without all the Makefiles. (It's nice to be on a mailing list where, when someone wants to use a binary distribution in an example, it's usually Debian. ;) ) [...] > I suppose the right way of addressing the issue is to create a > 'gnustep-common' package, that only installs GNUstep.conf. > Then, on top of that, you can install gnustep-make and/or > gnustep-base; you only install gnustep-make if you want to build. > We could make all this explicit by extracting the creation of > GNUstep.conf into a separate software ... to be installed before > gnustep-make. It sounds very clumsy though ;-) > At the moment, I'd leave everything as it is (a packager could still > install GNUstep.conf in a separate package to get the effect above). I agree. My personal recommendation would be that, in terms of source tarballs, you should keep GNUstep.conf inside gnustep-make. If someone downloads the sources, well, they'll need gnustep-make anyways. Then you can let the binary distributors do what they want, and split off a gnustep-common package if they want to. Of course, I'm biased, because that's how we're doing things in Debian. ;) -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
XPM support for NSImage
I have written a class to add XPM support to NSImageRep. I wrote it following the same style as the other bitmap format support in GNUstep, so it should be easy to integrate. Would there be any interest in including this in GNUstep? (I haven't signed the FSF copyright assignment for GNUstep (yet).) I have lightly tested it, but I still want to try it out with more XPM images to make sure that it does the right thing. There is also an unresolved issue related to named colours in the XPM format: XPM allows files to reference colour names from X11's rgb.txt, and I'm not sure what is the best way to do the lookup in GNUstep. It depends on libXpm, which is included in X11, or available from http://koala.ilog.fr/lehors/xpm.html. I'm not using any of the X11-specific functions from that library. Anyways, here is a tarball with the XPM class. XPMImage.tar.gz Description: Binary data -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
