Re: _wstat on Windows (actually stat stuff in general)
_wstat does not work with Windows Vista symbolic links. In these cases,
_wstat will always report a file size of 0. _stat does work correctly with
symbolic links.
Ugh, how weird and unexpected. (My expectation would have been that
neither supports symbolic links.) For which C runtime is this, btw,
the system msvcrt.dll, or some of the MSVC-version-specific ones?
Anyway, I think the only sensible thing to do is then to not use
either _wstat() or _stat(). We don't want to miss the full Unicode
support, and I guess this symbolic link stuff is useful, too.
Instead, we should just use the Win32 API to fill in the meaningful
fields of a struct stat. Yeah, following symbolic links manually might
be painful; I have no idea how to do that.
(Of course, when I say we, I actually mean you, as I don't really
take much part in GLib/GTK+ development currently... sorry. Just
noticed this thread when browsing the gtk-devel-list archove, and
*had* to follow-up...)
Anyway, isn't g_stat() kinda deprecated? Should it be? Partly exactly
because of this horrible potential for confusion with the several
struct stat variants on Windows (and also on some Unixes, I guess,
although there at least there is typically only one C
library). Doesn't GIO's APIs to get file
properties/attributes/whatever they are called supersede g_stat()?
Here's how I would define the GStatBuf data type:
typedef struct GStatBuf {
guint32 st_dev;
guint64 st_ino;
guint16 st_mode;
guint16 st_nlink;
guint32 st_uid;
guint32 st_gid;
guint32 st_rdev;
gint64 st_size;
gint32 st_atime;
gint32 st_mtime;
gint32 st_ctime;
} GStatBuf;
Er, no. NO.
This definitely is pointless, GIO supersedes g_stat() etc in much
cleaner fashion.
Why on earth would we want to use 32-bit timestamps in a new API? Or
just 16-bit st_nlink?
Why would we want the extremely Unix-specific st_mode to show up in a
portability layer at all? st_mode is on Windows always just a
best-effort (or not even that good an effort) fabrication. Many
POSIXes support ACLs in file systens and such might be common for some
file systems on some POSIX platforms. Any software supposed to be
generic and good should take that into consideration anyway when
figuring out the protection of some file. A single st_mode field is
basically useless in modern portable APIs.
st_uid and st_gid are also totally Unix-specifc, of course.
While in gstdio I'd also add the glaring-by-their-omission g_lseek,
g_fseek, and g_ftell all of which could take a gint32 as their argument or
return value.
That is a glaring omission only if you misunderstand the purpose of
gstdio.h. It is not supposed to be a wrapper for any file I/O related
functions. Its sole purpose (at least when it was created) is to take
care of the *file name* problems. It even says this in a comment:
/* Wrappers for C library functions that take pathname arguments. On
* Unix, the pathname is a file name as it literally is in the file
* system. On well-maintained systems with consistent users who know
* what they are doing and no exchange of files with others this would
* be a well-defined encoding, preferably UTF-8. On Windows, the
* pathname is always in UTF-8, even if that is not the on-disk
* encoding, and not the encoding accepted by the C library or Win32
* API.
*/
Beafing up gstdio.h now is too late. All newer file system portability
related stuff in GLib is in GIO, surely.
--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
Ugh, how weird and unexpected. (My expectation would have been that neither supports symbolic links.) For which C runtime is this, btw, the system msvcrt.dll, or some of the MSVC-version-specific ones? The MSDN documentation doesn't specify. I suspect its all of them TBH. Instead, we should just use the Win32 API to fill in the meaningful fields of a struct stat. Yeah, following symbolic links manually might be painful; I have no idea how to do that. Well I speak under correction but its my belief that The other API's follow them for you. I'm fairly certain GetFileAttributesEx() does. (Of course, when I say we, I actually mean you, as I don't really take much part in GLib/GTK+ development currently... sorry. Just noticed this thread when browsing the gtk-devel-list archove, and *had* to follow-up...) Glad you did :) That is a glaring omission only if you misunderstand the purpose of gstdio.h. It is not supposed to be a wrapper for any file I/O related functions. Its sole purpose (at least when it was created) is to take care of the *file name* problems. It even says this in a comment: Ah I had missed that bit. Beafing up gstdio.h now is too late. All newer file system portability related stuff in GLib is in GIO, surely. Sure but if all I want to know how big a file is, do I *really* want to link in all of that extra crud? GIO is huge. There are times when the low level functions are just plain appropriate. I've given up on the idea of a universal stat structure, but the g_stat() wrapper is still useful on Windows exactly because of the file name issue. People really do want to use stat rather than GIO. I do, and I've had private emails from others who do too. Right now though the biggest deficiency with it (aside from the symlinks and _wstat thing which needs to be addressed differently) is the actual stat structure you chose. It only supports 32-bit (well 31) file sizes and that's a real problem on Windows these days where ISO images are frequent and much larger than 2GB. I would dearly *love* to change that but that will mean breaking the ABI. Of course since everyone is off using GIO that shouldn't break too many people should it :) But that structure can be changed in a non-ABI breaking way and I hope to at least get that much past the powers that be. Kean ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
Ugh, how weird and unexpected. (My expectation would have been that neither supports symbolic links.) For which C runtime is this, btw, the system msvcrt.dll, or some of the MSVC-version-specific ones? The MSDN documentation doesn't specify. I suspect its all of them TBH. Actually, looking in the C library sources that come with MSVC2008, I see no sign of such a difference in _stat() vs. _wstat(). Both in stat.c and stat64.c (these are the files that contain the actual implementation of both the ANSI and wide-char versions of the stat family of functions) I see code that checks (findbuf.dwFileAttributes FILE_ATTRIBUTE_REPARSE_POINT) (findbuf.dwReserved0 == IO_REPARSE_TAG_SYMLINK) . But on the other hand, as far as I can see, this code is used to make stat() (etc) work as lstat(), not to actually follow the symlink! (But just if the symlink is the last component of the path; I assume symlinks in the middle of the pathname are followed transparently by the FindFirstFile(). So I wonder which is correct, the documentation, or what the code seems to imply. Experimentation would be useful... Of course, it might be that it is actually FindFirstFileA() vs. FindFirstFileW() that exhibits some difference. Sure but if all I want to know how big a file is, do I *really* want to link in all of that extra crud? GIO is huge. There are times when the low level functions are just plain appropriate. I would say, bah. Any actively maintained (or recently written) GLib-using code that doesn't use GIO by now is just being maintained or written in a misguided fashion. People really do want to use stat rather than GIO. I do, and I've had private emails from others who do too. Well, then you just will have to live with the various breakages;) I don't think you will be able to convince people it would be a good idea to add more bells and whistles in the form of stat() -style APIs when GLib already has a much cleaner and ABI/API stability/extendability safe (and other nice words) way to get information about files. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist t...@iki.fi wrote: Sure but if all I want to know how big a file is, do I *really* want to link in all of that extra crud? GIO is huge. There are times when the low level functions are just plain appropriate. I would say, bah. Any actively maintained (or recently written) GLib-using code that doesn't use GIO by now is just being maintained or written in a misguided fashion. Tor, did I understand your position right that any program written in the speed in minds and uses Glib is written in a misguided fashion? -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
hi; On 29 September 2011 09:57, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote: On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist t...@iki.fi wrote: I would say, bah. Any actively maintained (or recently written) GLib-using code that doesn't use GIO by now is just being maintained or written in a misguided fashion. Tor, did I understand your position right that any program written in the speed in minds and uses Glib is written in a misguided fashion? that's a fairly creative way of misinterpreting that sentence. if GIO is measurably slower at doing I/O than a stat(), please: file bugs along with profiling data. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
On Thu, Sep 29, 2011 at 10:05:57AM +0100, Emmanuele Bassi wrote: On 29 September 2011 09:57, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote: On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist t...@iki.fi wrote: I would say, bah. Any actively maintained (or recently written) GLib-using code that doesn't use GIO by now is just being maintained or written in a misguided fashion. Tor, did I understand your position right that any program written in the speed in minds and uses Glib is written in a misguided fashion? that's a fairly creative way of misinterpreting that sentence. if GIO is measurably slower at doing I/O than a stat(), please: file bugs along with profiling data. I wish GLib was the nice utility library it used to be. A utility library provides functionality people find useful; there is no agenda and consequently no need to tell people they are misguided if they just want to use the functionality they find useful and do not want use specific complex frameworks because they find them cumbersome. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
On Thu, Sep 29, 2011 at 12:05, Emmanuele Bassi eba...@gmail.com wrote: hi; On 29 September 2011 09:57, Andrew W. Nosenko andrew.w.nose...@gmail.com wrote: On Thu, Sep 29, 2011 at 11:35, Tor Lillqvist t...@iki.fi wrote: I would say, bah. Any actively maintained (or recently written) GLib-using code that doesn't use GIO by now is just being maintained or written in a misguided fashion. Tor, did I understand your position right that any program written in the speed in minds and uses Glib is written in a misguided fashion? that's a fairly creative way of misinterpreting that sentence. No, that is creative way to point author to avoid improper generalizations and be more precise in phrases. if GIO is measurably slower at doing I/O than a stat(), please: file bugs along with profiling data. GIO as layer is so comparable to stat() as apples comparable to grapes, and we both know it :-) But, unfortunatelly, all GMainLoop based stuffs (including GIO) are indeed slow when we come to high workload if compared to kqueue based (and I think epoll-based also) main loop implementations. Therefore, either you use GIO, and limited to the current GMainLoop speeds, or use something kqueue-based and have no way to GIO. Fill Bugzilla? No needs, it's already done both years ago and quite recently: https://bugzilla.gnome.org/show_bug.cgi?id=156048 (epoll support in gmain.c, 2004 year) https://bugzilla.gnome.org/show_bug.cgi?id=657729 (modernise GMainLoop, 2011 year) -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
if GIO is measurably slower at doing I/O than a stat(), please: file bugs along with profiling data. This is WAY off topic but still ... how can you possibly believe it is NOT slower? One system call versus: 1. Allocate arrays 2. Allocate hash tables 3. Do strdups 4. Calculate hashes 5. Involve at least 14 functions that I counted 6. Heap fragmentation How can you *POSSIBLY* expect that to be faster? The fact that you may not visually notice the speed difference because we all have the luxury of modern systems that are fast does NOT mean it is a superior solution. GIO adds 176000-odd lines of source code to an app. How is it even POSSIBLE you can question it is slower than 1 system call? If you really, honestly believe that, my faith in you (until now quite high) and in GLib and its future (until now also quite high) just plummeted through the floor. I really don't need accurate GPS measuring to know that a Bugati Veyron is faster than a Fiat Uno, any more than I need to provide you with profiling data to prove that GIO is slower than g_stat(). This over-engineering and relying on silicon to cover bad designs is what kills software in the long run. System calls in UNIX have survived 40 years for a reason. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
On 29 September 2011 10:53, Kean Johnston kean.johns...@gmail.com wrote: I really don't need accurate GPS measuring to know that a Bugati Veyron is faster than a Fiat Uno, any more than I need to provide you with profiling data to prove that GIO is slower than g_stat(). I can also tell you that for driving from my house to the supermarket, the Veyron won't be any faster because of other far larger sources of delays, such as the speed limit (or HDD latency). Of course GIO is slower when you look at the LoC count, the question is for the typical case is performance acceptable. If your application is opening a million files then maybe it's not typical. Ross ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
Of course GIO is slower when you look at the LoC count, the question is for the typical case is performance acceptable. If your application is opening a million files then maybe it's not typical. Maybe my application runs on a router and not on an 64-core Core i5000 with 16 petabytes of RAM. Just as Im not sure I'd drive a Bugati Veyron to the supermarket for a pint of milk, I'm not sure I'd use a Core i7 for a router than costs $150. If the general utility part of GLib extends to requiring massively more complex resources than alternatives, that pretty much seals GLib's fate as a general purpose anything and becomes instead a very specific to the GNOME desktop purpose library. No way you can convince me otherwise I'm afraid, and that's not because I'm being stubborn, it's because I (and I think you) know I'm right. GIO is appropriate for some applications, of that I have no doubt, but trying to convince me that it's a viable alternative to stat() when all I want it the damned file size? Never gonna happen. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
On 29 September 2011 11:13, Kean Johnston kean.johns...@gmail.com wrote: No way you can convince me otherwise I'm afraid, and that's not because I'm being stubborn, it's because I (and I think you) know I'm right. GIO is appropriate for some applications, of that I have no doubt, but trying to convince me that it's a viable alternative to stat() when all I want it the damned file size? Never gonna happen. If you are happy limiting yourself to a single platform and don't need some the magic that comes with GIO, feel free to use stat(). It's not like GIO is going to break that for you. Ross ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
If you are happy limiting yourself to a single platform and don't need some the magic that comes with GIO, feel free to use stat(). It's not UNIXWARE, SCO OpenServer, AIX, Solaris, MacOS X, Windows, Linux, FreeBSD, OpenBSD, NetBSD, Minix, HP-UX ... did I miss any platforms? I'll consider myself limited. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: _wstat on Windows (actually stat stuff in general)
Am 29.09.2011 12:24, schrieb Kean Johnston: If you are happy limiting yourself to a single platform and don't need some the magic that comes with GIO, feel free to use stat(). It's not UNIXWARE, SCO OpenServer, AIX, Solaris, MacOS X, Windows, Linux, FreeBSD, OpenBSD, NetBSD, Minix, HP-UX ... did I miss any platforms? I'll consider myself limited. How about a test case that first times stat recursively over a large folder and then the same with g_file_query_info. If you could run that on some typical hardware you're working with, I think that should be quite interesting. Personally I regularly talk to people who use my code on obscure systems I don't have, maybe never heard of. And I really need practical examples of what they are doing and how it's performing. It doesn't help to emphasize your point if there is no way for the other person to understand it. ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EXTERNAL: Re: _wstat on Windows (actually stat stuff in general)
On 9/29/2011 6:24 AM, Kean Johnston wrote: If you are happy limiting yourself to a single platform and don't need some the magic that comes with GIO, feel free to use stat(). It's not UNIXWARE, SCO OpenServer, AIX, Solaris, MacOS X, Windows, Linux, FreeBSD, OpenBSD, NetBSD, Minix, HP-UX ... did I miss any platforms? I'll consider myself limited. What about VAX/VMS :-) Damon Register ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Cleaning up owned dbus names on shutdown with glib
Hi, I'm battling a problem where imsettings, running as part of the desktop session, causes a delay between 5 and 20 seconds on every system shutdown, while it is trying to clean up dbus stuff. When shutting down, systemd quickly sends TERM signals to everything in the display manager cgroup, including the session bus dbus-daemon itself, and imsettings. Everything gets killed pretty quick but of course the exact order of signal reception and processing will vary. imsettings is a little daemon that deals with input methods. It hosts a dbus service on the session bus, claiming exactly one bus name with g_bus_own_name_on_connection(). The source code is: git://github.com/tagoh/imsettings.git imsettings-daemon/main.c is the main daemon in question, and imsettings-daemon/imsettings-server.c is the IMSettingsServer class implementation which is the GObject that claims the bus name and so on. I have made some minor changes to try and fix this in this patch: http://dev.laptop.org/~dsd/20110928/imsettings-shutdown.patch but none have worked right. Is imsettings doing something wrong, or have we come across a bug in glib? Here's whats happening during shutdown: 1. imsettings receives SIGTERM, which it has a handler for 2. The SIGTERM handler asks the glib main loop to quit 3. After the glib main loop ends, imsettings main() destroys its IMSettingsServer object, which is what was owning the bus name 4. imsettings_server_finalize() calls g_bus_unown_name() which then hangs for 5-20 seconds, then complains: [ 1317208397.833711]: GLib-GIO[2630]: WARNING **: Error releasing name com.redhat.imsettings: Timeout was reached [ 1317208397.834972]: GLib-GIO[2630]: CRITICAL **: Error while sending AddMatch() message: The connection is closed [ 1317208397.835505]: GLib-GIO[2630]: CRITICAL **: Error while sending AddMatch() message: The connection is closed Then exit completes. Note that the IMSettingsServer object never received its name_lost callback above. If it had done so, the code (with the very last bit of my patch) knows not to try and unown the name and I guess that would have avoided the long timeout. If I add a call to g_dbus_connection_close_sync() before trying to unown the name, shutdown completes instantaneously. It does complain: GLib-GIO[2630]: WARNING **: Error releasing name com.redhat.imsettings: The connection is closed but that's what I was expecting. However, that doesn't seem like the right fix. Ordinarily, outside of the shutdown path, if imsettings receives SIGTERM it should unown its bus name and exit cleanly, and it wouldn't be able to do this if the preceding code had just closed the connection. So I am wondering if I have found a bug in the dbus message sending internals of glib. I guess what is happening is that at the time when imsettings starts processing its SIGTERM signal, the session bus is still alive and kicking. Then, approximately at the same time as when it tries to unown the name, the session bus gets killed. This causes the unown call to hang for a long time. What should perhaps happen here is that if the session bus goes away at the same time as the unown call, glib internals should notice this and make the ongoing unown call return failure immediately, rather than waiting a long time for the timeout. Or is imsettings doing something wrong? Let me know how I can debug this further - I can reproduce it trivially. Thanks, Daniel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: circular dependency between glib and pkg-config
Thanks, Allin. Glib's ./configure --help mentions environment variables PKG_CONFIG path to pkg-config utility PKG_CONFIG_PATH directories to add to pkg-config's search path PKG_CONFIG_LIBDIR path overriding pkg-config's built-in search path ZLIB_CFLAGS C compiler flags for ZLIB, overriding pkg-config ZLIB_LIBS linker flags for ZLIB, overriding pkg-config CXXCPP C++ preprocessor PCRE_CFLAGS C compiler flags for PCRE, overriding pkg-config PCRE_LIBS linker flags for PCRE, overriding pkg-config DBUS1_CFLAGS C compiler flags for DBUS1, overriding pkg-config DBUS1_LIBS linker flags for DBUS1, overriding pkg-config which could lead one to believe that ZLIB isn't the only thing that could matter; and it doesn't say that pkg-config is not needed if these variables are present. It does say pkg-config is required. I think it should be possible for someone unfamiliar with either package to build glib from source after reading INSTALL, before installing pkg-config. Either that, or to install pkg-config before installing glib - whichever way the maintainers of the two packages can agree on. INSTALL doesn't give instructions on this, and I think it should. I don't think it should be necessary to search the web or read what's in configure, Makefile, etc. I'm not posting these messages to get glib or pkg-config built; I managed to do that some days ago. According to my notes and a couple of experiments just now, once I got the various pieces of software other than pkg-config that glib wanted, built and installed, and set PATH, CPATH, and LIBRARY_PATH to their locations (which weren't in the former PATH or the places the compiler or linker normally look), it was possible to build glib without pkg-config. I installed glib, too, into those non-standard locations, having used --prefix= for ./configure. Then, after setting GLIB_CFLAGS and GLIB_LIBS (the latter with -L and -l options for the linker), it was possible to build pkg-config. I didn't need to do anything special about zlib, which was already on the system. However I had to discover this by trial and error, not by reading INSTALL. I've learned a number of interesting and useful things from the journey, which I don't regret at all, but don't think people should be required to to more than read INSTALL just in order to build from source. Thanks again. On Tue, 27 Sep 2011, Stuart Ambler wrote: It seems that the pkg-config README in [Ryan Lortie's] message tried to address that, but sorry, I didn't see what zlib had to do with the dependency of glib on pkg-config. (To build pkg-config, you need glib installed already. Note that glib build-depends on pkg-config, but you can just set the corresponding environment variables (ZLIB_LIBS, ZLIB_CFLAGS are the only needed ones when this is written) to build it.) Presumably the point is that zlib is the only prerequisite library that is handled by pkg-config in the glib build (as in pkg-config --libs zlib, pkg-config --cflags zlib). The effect of the calls to pkg-config is to define ZLIB_LIBS and ZLIB_CFLAGS, but these could equally well be set manually. Allin Cottrell ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: circular dependency between glib and pkg-config
On Wed, Sep 28, 2011 at 11:52:26PM -0700, stu...@zulazon.com wrote: I think it should be possible for someone unfamiliar with either package to build glib from source after reading INSTALL, before installing pkg-config. Either that, or to install pkg-config before installing glib I guess you figured out all the steps now right? If so: patch welcome :-) -- Regards, Olav ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: circular dependency between glib and pkg-config
On Wed, 28 Sep 2011 at 23:52:26 -0700, stu...@zulazon.com wrote: CXXCPP C++ preprocessor There are many more like this (CC, LD, CXXFLAGS etc.), but they're standard for all Autotools packages, and none are mandatory. PCRE_CFLAGS C compiler flags for PCRE, overriding pkg-config PCRE_LIBS linker flags for PCRE, overriding pkg-config If you're building with the internal libpcre you don't need these; only distributions who want to link everything against a shared libpcre need them. DBUS1_CFLAGS C compiler flags for DBUS1, overriding pkg-config DBUS1_LIBS linker flags for DBUS1, overriding pkg-config I happen to know that these are only needed for full regression tests. However I had to discover this by trial and error, not by reading INSTALL. I've learned a number of interesting and useful things from the journey, which I don't regret at all, but don't think people should be required to to more than read INSTALL just in order to build from source. To be fair, you were bootstrapping it from source on a platform with neither GLib nor pkg-config, which is pretty unusual. You have to start somewhere; you also need a libc, a C compiler, a POSIX shell, a Make implementation etc., and INSTALL doesn't explain how to get those. The other way to start the process is to cross-compile GLib and/or pkg-config for your host platform, on a build platform that already has them (you can use your build architecture's pkg-config binary to configure GLib) - that's how you'd typically start off for embedded development, for instance. See http://wiki.debian.org/DebianBootstrap for some thoughts on how bootstrapping an architecture works in general (pkg-config is nowhere near the most difficult case). S ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkTable is deprecated
Hi! GtkGrid should be pretty much a drop-in replacement for GtkTable. Keep in mind that GtkGrid uses the align and expand flags of GtkWidget[2][3][4][5] instead of having expand and fill child properties. As always, should you have any questions, don't hesitate to ask. This is a massive change to existing GtkBuilder .ui files so I would suggest that somebody able to do xml and/or sed/grep magic would write a script that just replaces GtkTable with GtkGrid in existing .ui files. If that is included in gtk+ it would a lot of peoples lives easier. (Or of course, Javier could fix all modules in GNOME Git but I somehow doubt that he has the time...) Regards, Johannes ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkTable is deprecated
On Thu, Sep 29, 2011 at 12:30 PM, Johannes Schmid j...@jsschmid.de wrote: Hi! GtkGrid should be pretty much a drop-in replacement for GtkTable. Keep in mind that GtkGrid uses the align and expand flags of GtkWidget[2][3][4][5] instead of having expand and fill child properties. As always, should you have any questions, don't hesitate to ask. This is a massive change to existing GtkBuilder .ui files so I would suggest that somebody able to do xml and/or sed/grep magic would write a script that just replaces GtkTable with GtkGrid in existing .ui files. If that is included in gtk+ it would a lot of peoples lives easier. (Or of course, Javier could fix all modules in GNOME Git but I somehow doubt that he has the time...) deprecated != gone. There is no super-urgent need to rid the world of GtkTables - unless you want your module to compile with disabled deprecations. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkTable is deprecated
Hi! deprecated != gone. There is no super-urgent need to rid the world of GtkTables - unless you want your module to compile with disabled deprecations. Sure, but you know how picky some people are about deprecations... Regards, Johannes ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkTable is deprecated
On Thu, Sep 29, 2011 at 6:30 PM, Johannes Schmid j...@jsschmid.de wrote: This is a massive change to existing GtkBuilder .ui files so I would suggest that somebody able to do xml and/or sed/grep magic would write a script that just replaces GtkTable with GtkGrid in existing .ui files. If that is included in gtk+ it would a lot of peoples lives easier. I am not sure that a simple script - and it'd probably be easy enough to get a simple one going with some XSLT - because you need to fix the expand and align flags of your widgets, and that means setting flags on completely different widgets in the widget tree. That transition is a thing I'd love to have seen tackled more by app authors btw, but so far it wasn't necessary, so nobody bothered. GtkBox and GtkTable didn't lose these flags in the transition to GTK3 after all. Also, keep in mind that UI files won't cause deprecation warnings during compilation. So unless you have code that live-edits tables, your code will still continue to compile and run fine for the time being. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GDI+ animation frame delay bug patch
There exists a bug in the gdk-pixbuf's GDI+ animation handling that causes it to use the first frame's delay to be used for all frames. This is causing a much-lamented bug in Pidgin on Windows (http://developer.pidgin.im/ticket/11858). A couple of months ago I reported this bug (#655755) and provided a patch that fixes the issue. It would be great if this patch could be incorporated in an upcoming release. I realize that there is a large backlog of bugs and that patches can get lost in the sea of feature requests and bug reports without patches, so I'm just sending this email to point that this one has a patch and could be dis-positioned without a lot of work. If there is any more information I could provide on the bug or the fix, let me know. Also, I've never dealt with Gnome dev before, so if this email is a breach of etiquette, just say so and I'll happily step to the sidelines and wait my turn. Thanks, Keith Moyer ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkTable is deprecated
If GtkTable and GtkGrid were replaceable by a sed expression, I don't think we would have bothered breaking API. On Thu, Sep 29, 2011 at 1:11 PM, Johannes Schmid j...@jsschmid.de wrote: Hi! deprecated != gone. There is no super-urgent need to rid the world of GtkTables - unless you want your module to compile with disabled deprecations. Sure, but you know how picky some people are about deprecations... Regards, Johannes ___ desktop-devel-list mailing list desktop-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
