Re: Attention anyone uploading binaries to ftp.gnome.org/pub/binaries - understand the GPL
> Also, just to move things along, I plan to remove any binary which does > not have a corresponding SOURCES file in say one month from now. Fine with me, thanks for taking care of this! --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3 cleanup status update
> - what is the status of pygi (and introspection in general) with regard > to portability to Windows I did some hacking on getting gobject-introspection to build for Windows one weekend, and I did get it to build, and I think "make check" even passed mostly, but no idea whether it actually works that well. The code in there is quite convoluted, and I am not a Python person. The handling of libraries/shared object/libtool archives is of course quite different on Windows than on ELF-based systems, with the separation between DLL and import library concepts. I guess I should get back to that some day and submit a proper diff.. As for the Python conneciton, no idea at all. In general I have the feeling that the GTK+ stack on Windows is on a downward slope. Each new release introduces new stuff that never gets fully implemented/tested for Windows, like the client-side windows. Note that I am not blaming anybody, not even myself, just stating the obvious. It might well be that GTK+ 2.16 and GLib 2.20 was the most "usable" combination there will be, until somebody gets the inspiration / resources to dig into it. --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnomeweb-wml pushes not causing website updates. missing a hook?
Changes to gtk-web still don't seem to propagate to the web server? --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ORBit2 stopped calling g_thread_init(), and consequences
> Or just revert the change to ORBit2 Done. --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ORBit2 stopped calling g_thread_init(), and consequences
>> What should be the plan to fix them all ? Or just revert the change to ORBit2 and instead insert the g_thread_init(NULL) in programs as needed when/if they are ever ported to Windows or other odd platforms? Maybe at the same time update the documentation that says g_thread_init() should be the first GLib function called. Add something like: "But don't worry. Things usually work fine, especially on Linux, even if you call g_thread_init() (or some random library calls it) even after lots of other GLib functions have been called." --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Quotation marks: Using “” instead of ""
> utf-8 encoded litteral DO work in C, without glitch. Assuming the functions in any library (including the C library) you pass such UTF-8 encoded strings to expects them to be UTF-8... And UTF-8-encoded wide string literals hardly work correctly unless you explicitly tell the compiler that the codeset of the source file is UTF-8, so that it knows how to convert from UTF-8 in the file to the correct wchar_t sequence. --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Suggested even/odd convention for the micro version numbers (like cairo)
I humbly suggest that the versioning recommendation for the GTK+ stack and GNOME in general is amended for the third "micro" part of the version numbers to match the convention used in cairo. See http://cairographics.org/manual/cairo-Version-Information.html . In a nutshell, the idea is that released tarballs have an even micro version. The micro version is bumped both immediately before and after building the release tarball. The even micro number is never committed to SVN. In SVN the micro number is always odd. This has the advantage that there is never any confusion whether pre-release or post-release bump is used. Code from a SVN checkout can always be recognised by its odd micro number, and correspondingly code from a released tarball is recognised by its even micro number. One could imagine a module using a macro FOO_IS_DEVELOPMENT_VERSION() that would return true either if 1) the minor version is odd (as the convention already is in most (?) GNOME modules), or 2) the micro number is odd (a build from SVN, presumably thus intended for local hacking and not distribution). I guess one disadvantage of this is that it might take a time before people stop asking "what happened to version x.y.z". Also, one probably needs to script the bump-make dist-bump sequence in order not to forget it, at least initially. I think the use of this convention is regarded as a success by people working on cairo? --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Hide extensions [Was: Nautilus]
to 2005-12-22 klockan 08:24 + skrev Shane O'Connor: > IMHO if we want to get people to shift from Windoze then we're gonna > have to ensure the move is painless as possible. That doesn't > necessarily we have to mirror windoze behaviour but we should definitely > avoid making the default for gnome more cumbersome... Is there BTW any usability tests, polls, or whatever, that would report the usefulness of Windows Explorer's "Hide extensions for known file types" that by default is On? (Personally I find it an absolutely horrible default setting and invariably turn it off on all Windows boxes I use, but I am almost capable of seeing the reasoning behind it... and can certainly believe it if somebody tells me that it in fact has been shown to reduce confusion among novice users.) --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Thoughts on the future of gnome
On on, 2005-10-12 at 08:01 -0400, Larry W. Virden wrote: > The reason I would be interested in this is that Windows XP has this > component currently referred to as Interix/Services For Unix > > Having GNOME libraries, etc. supported on Windows would make it easier to > build and run an environment which supported GNOME compliant applications > in that environment. If I understand correctly Interix (the follow-up on the "POSIX subsystem?") really *is* Unix, from user code's point of view, so one cannot make Win32 calls from such code. I might be wrong, though. --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Thoughts on the future of gnome
On må, 2005-10-10 at 21:21 +0200, alan wrote: > Is it likly that a windows version of gnome (even a basic, light > version) will be available when vista is released? No. I don't really know what you mean by a "basic, light version of GNOME". But I am rather certain that it would make no sense whatsoever to run Nautilus, for instance, on Windows. If you want GNOME, run GNOME (on Unix). Some GNOME *applications*, like Evolution, and maybe Evince, make sense on Windows. Other free non-GNOME applications like OpenOffice, AbiWord, GIMP, InkScape already are available on Windows. Other applications like media players and various smaller "applets" already have lots of equivalents on Windows. They might not be free (as in Speech), but the end-users rarely care. If they do, they already run GNOME on Linux. --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing xrdb for 10% startup win?
> Why not grep for any preprocessor statements, and only run cpp if some > are present? What about preprocessor predefined identifiers (__linux, __SVR4, etc)? Some people might use them in resource files, although I can't think of an example where this would make sense except in #ifdefs, which would be caught anyway by such a grep. But to be perfect, gdm would need to know what identifiers are predefined in the cpp on each system... --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Removing xrdb for 10% startup win?
On sö, 2005-08-28 at 11:37 +0100, Gustavo J. A. M. Carneiro wrote: > It runs cpp once, and any time ~./Xresources changes, but otherwise > cpp is skipped altogether. My suggestion is pretty obvious, I guess, > but someone had to spell it out for the record :) It's flaw is also pretty obvious: What if .Xresources doesn't change, but it #includes other files, and one of the #included resource files changes? ;-) No, I have no idea how common it might be to use #include directives in resource files, but some people are bound to have used the feature. --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: tinderbox breakages in moz, soup, gnome-menus, libgnomeprint
I hope libgnomeprint is fixed now: 2005-08-14 Tor Lillqvist <[EMAIL PROTECTED]> * libgnomeprint/filters/Makefile.am (install-exec-hook): Hack to make "make install" work, especially in tinderbox-like situations. See http://mail.gnome.org/archives/desktop-devel-list/2005-August/msg00110.html The real fix would be to change the source code organization of libgnomeprint to avoid the need to cd back and forth and run sub-makes. A suggestion: put libgnomeprintfilter in a directory of its own, as a sibling to libgnomeprint. The plugin modules should also be in a sibling directory to libgnomeprint, not a subdirectory of it. The top-level Makefile.am would have them in SUBDIRS in the order: libgnomeprintfilter, libgnomeprint, filters. I think the libs would then naturally build in the correct dependency order? --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: tinderbox breakages in moz, soup, gnome-menus, libgnomeprint
> Tor: > http://cvs.gnome.org/viewcvs/libgnomeprint/libgnomeprint/Makefile.am?rev=1.115&view=markup > seems to have broken *make install* there, which I've never seen > before. Weird error: > > make[3]: Leaving directory > `/home/bb/microtinder/cvs/libgnomeprint/libgnomeprint/filters' > make[2]: Leaving directory > `/home/bb/microtinder/cvs/libgnomeprint/libgnomeprint/filters' > make[1]: Leaving directory > `/home/bb/microtinder/cvs/libgnomeprint/libgnomeprint' > /usr/bin/ld: cannot find -lgnomeprint-2-2 > collect2: ld returned 1 exit status > libtool: install: error: relink `libgnomeprint-zoom.la' with the above > command before installing it > make[3]: *** [install-pluginLTLIBRARIES] Error 1 Hmm. Yes. I think I understand this now. The inter-dependency of the shared libraries in libgnomeprint is quite complex. libgnomeprint/libgnomeprint-2-2.la depends on libgnomeprint/filters/libgnomeprintfilter.la (a "convenience" libtool library, I think they are called, i.e. one specified in noinst_LIBLTLIBRARIES, and for which only a static archive is built). So that has to exist before libgnomeprint-2-2.la is built if we use -no-undefined. On the other hand, the "plugin" libraries in libgnomeprint/filter, like libgnomeprint-zoom.la, since a time ago depend on libgnomeprint/libgnomeprint-2-2.la, so to be able to build them with -no-undefined we have to have libgnomeprint-2-2.la. My recent change was to add in libgnomeprint/filters ../libgnomeprint-2-2.la to the DEPENDENCIES of libgnomeprint-zoom.la (etc), and a rule to produce it by doing cd .. && $(MAKE) it. For plain "make" this works fine. But the libtool relink done by "make install" in filters apparently assumes that the libgnomeprint-2-2 shared object has already been installed in its final destination when it relinks libgnomeprint-zoom.la. Which it hasn't. On a "normal" Linux box with GNOME installed it apparently happens to work anyway as the relink then refers to the system libgnomeprint-2-2 (boo!)... But I guess tinderbox builds are built with -nostdlib or in a very bare chroot environment or something? I will figure out a fix and commit. If nothing else, I can just put the problematic stuff inside if HAVE_WIN32... --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: vfs, applets, keyring, libgtop broken [was Re: state of the tinder]
On Wed, 2005-07-27 at 12:25 -0400, Luis Villa wrote: > Also broken: > * gnome-vfs, since this commit: > http://cvs.gnome.org/viewcvs/gnome-vfs/ChangeLog?rev=1.2231&view=markup Should be fixed now. Sorry. --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
libgnomeui has been branched
A gnome-2-10 branch has been created for libgnomeui. The HEAD branch will get Win32 portability changes applied. I am bumping the version in HEAD to 2.11.0. --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
libgnome has been branched
A gnome-2-10 branch has been created for libgnome. The HEAD branch will soon get Win32 portability changes applied. (Unix functionality will not be changed.) I am bumping the version in HEAD to 2.11.0. --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
libbonoboui has been branched
A gnome-2-10 branch has been created for libbonoboui. The HEAD branch will soon get some Win32 love applied. (X11 functionality will not be touched, at least not now.) I am bumping the version in HEAD to 2.9.0. --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
libbonobo has been branched, sorry for late information
As has been pointed out to me, I should have announced on these lists that I was branching libbonobo. Sorry. (I guess I my subconscious thought was that some software automatically notices when a separate stable branch for the upcomong release appears, and starts doing its builds/string checks/whatever from there.) The gnome-2-10 branch of libbonobo was created a few days ago. (Presumably you already have been informed about ORBit2's branch, which was done about a month ago?) --tml ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
