Re: _wstat on Windows (actually stat stuff in general)
I disagree that we don't have an ABI to maintain on Windows. I think
people on Windows are somewhat likely to download precompiled binary
versions of our DLLs for use with developing their software (since the
build process is so complicated). We can easily introduce extremely
difficult-to-debug situations for people who assumed that the DLL was
binary-compatible with the old one.
This is true. On Windows the code is actually fairly well insulated from
random size changes based on macros. The only problem is Tor chose the
wrong stat structure IMHO. These days, files 4GB are common. Since GLib
is a platform tool and you would rightfully expect to be able to write,
say, an archival tool that could compress big files, and this currently
isn't possible. Or you may want to write a backup tool and preserve
timestamps. Also not currently possible. Of course said applications could
just use other API's or specify their own stat structures and not use
g_stat() at all but in that case what is the purpose of having g_stat() at
all? Or any of the other gstdio.h wrappers. The purpose (I believe) is to
ensure that if you use those wrappers they will behave the same way on all
platforms GLib has been ported to. This is largely the case but it does
break down on the fringes.
While I mostly agree with this, it's only true in the case that both the
code calling g_stat() and the code inspecting its result are always in
the same codebase.
And therein lies the EXACT reason why having a well defined stat structure
with data types wide enough to cover all cases is such a requirement.
library with no code changes will change the ABI of the library). I'm
not sure there are any cases of this, but it's something to be aware of.
Certainly, and we could do some rather trivial things to insulate against
that. Call the structure something else (although as you mentioned GStatBuf
is sufficiently new that I don't think we'd have a problem). Or announce
the breakage prominently. We can work around the ABI change.
This means that there is an awful lot of valid existing code (including
within GLib itself) that looks like this:
{
struct stat buf;
g_stat (filename,buf);
}
which (if I understand your proposal correctly) would be badly broken.
That code would of course change to
{
GStatBuf buf;
g_stat (filename, buf);
}
The code wouldn't be broken at all. In fact it would be less broken. If,
for example, GLib wasn't compiled with _FILE_OFFSET_BITS=64 then
internally, all of its usage of g_stat() can only deal with 31-bit file
sizes. User code using GLib compiled WITH that set will support file sizes
with 63 bits.
Almost all of the functions currently wrapped in gstdio.h are problematic
with LFS. On Linux they are currently just macros. Changing those to
functions won't break any existing code on Linux because those symbols
aren't even in libglib-2.0.so. But in order to provide a consistent,
doesn't-change-with-macros interface that can *become* the GLib ABI is
useful. That code can be constructed inside GLib such that it is always
compiled with LFS in mind. For example, we can ensure that g_open() always
calls open64 or whatever it's called on the system in question. By rigidly
defining GStatBuf to use identically sized on all platforms fields, we make
g_stat() more useful. Heck, it even becomes possible to share binary dumps
of the thing on like-endian machines should you want to do that.
In a nutshell, if gstdio.[ch] were slightly tweaked to be actual functions
and not veneer macro wrappers, and they all took suitably sized arguments
then the code becomes that much more portable and easier to debug and less
surprising. I'd also add the various seek functions as they too are
problematic because they take a file offset but that also doesn't break any
ABI it just adds a new one. I think the *only* platform affected by the
changes I am proposing is Windows (or any UNIX system that defines
G_STDIO_NO_WRAP_ON_UNIX) and that only for g_stat() and that can be easily
worked around. But at the end of it we will have a completely consistent
API across all platforms. The *only* thorny question really, is what width
do we make the st_?time fields? 32-bit or 64-bit (or, as on MacOS, both).
And if we make them 64-bit what exactly does that represent? Nanoseconds
since the Epoch? I think the easiest way by far is to have those fields
defined thus in the structure:
gint32 st_atime, st_mtime, st_ctime;
gint64 st_atime64, st_mtime64, st_ctime64;
That supports the vast majority of the code out there that is UNIX-centric
and supports the notion of a 31-bit time field measured as seconds since
the epoch of Jan 1 1970. But code that wants higher precision can use the
64-bit variants on systems that provide it and simply multiply out the
32-bit ones to give usable values on those that don't.
Note that on Windows the 64-bit time fields are just more seconds since the
Epoch,
Re: _wstat on Windows (actually stat stuff in general)
On Mon, 2011-09-26 at 08:59 +0200, Kean Johnston wrote:
There is also a broader issue with stat. The size of struct stat can vary
according to what macros are defined when you include sys/stat.h. If you
have _FILE_OFFSET_BITS=64 defined your size fields are 64-bit, otherwise
they *can* be 64-bit but are most often 32-bit. Thus, if glib was compiled
without _FILE_OFFSET_BITS defined, and an application uses g_stat() but
DOES have it defined, you're in for trouble (and the inverse is true - if
glib was compiled with _FILE_OFFSET_BITS=64 and the app wasn't, the same
hilarity ensues).
I don't see how this would be any problem. Both the app and the library
will get the struct stat that matches what they were compiled with. The
only problem would be if you passed the struct stat between glib and the
app, but that doesn't happen as g_stat is a macro.
On almost all UNIX systems time_t is a signed 32-bit int thus capable of
representing time from the epoch through some time in 2038. Windows has
support for 64-bit time fields which is surprisingly forward thinking of them.
time_t is typically a signed long, which is 64bit on all 64bit linux
versions.
Since GLib is a platform library it would be extremely useful if
gstsdio.h defined a GLib version of the stat structures instead of just
doing typedef struct stat GStatBuf. That structure can be consistently
defined, with sufficiently large data types that it will work on all
systems. Despire the coolness of Windows supporting time fields 64-bits
wide for the least amount of pain it would probably be best if the time
fields were left at 32-bits (although it would be really cool and forward
thinking if we used 64-bits), but to use 64-bit fields for all size fields,
and 32-bit fields for all others. That way gstdio.[ch] can be compiled in a
very specific way to get the information needed and then smush it into that
portable structure. 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;
I don't see what advantages this gives you. It will break all existing
code that uses g_stat and struct stat, you can't share GStatBuf with
other struct stat using code, you can't access extensions like
nanosecond mtimes, it doesn't have things like blocksize and st_blocks
which means you can't calculate actual space used.
Also, we *do* have an abstraction that lets you write portable code. Its
called GFileInfo. g_stat is by its nature a lowlevel unix-like call, it
was added mainly as a quick way to port unix code to windows. So,
introducing our own copy of struct stat on windows might make sense
(with its c runtime library issues), but we don't want to change it on
unix.
___
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 Wed, 2011-09-28 at 10:00 +0200, Kean Johnston wrote:
This means that there is an awful lot of valid existing code (including
within GLib itself) that looks like this:
{
struct stat buf;
g_stat (filename,buf);
}
which (if I understand your proposal correctly) would be badly broken.
That code would of course change to
{
GStatBuf buf;
g_stat (filename, buf);
}
It would be a break in source-compat, which we can't just do. Glib is an
API stable library used by thousands of other libraries and apps.
The code wouldn't be broken at all. In fact it would be less broken. If,
for example, GLib wasn't compiled with _FILE_OFFSET_BITS=64 then
internally, all of its usage of g_stat() can only deal with 31-bit file
sizes. User code using GLib compiled WITH that set will support file sizes
with 63 bits.
I don't understand why you keep bringing this up. glib has
AC_SYS_LARGEFILE in configure.ac, so it will never be built with
anything but 64bits internally.
Almost all of the functions currently wrapped in gstdio.h are problematic
with LFS. On Linux they are currently just macros.
They are problematic due to LFS being problematic, but that is just how
unix works. If you want to work with other libraries etc on the lower
level you have to be aware of this. If you don't want that, use the
proper glib i/o abstractions in GIO that are not using anything like
struct stat.
That supports the vast majority of the code out there that is UNIX-centric
and supports the notion of a 31-bit time field measured as seconds since
the epoch of Jan 1 1970. But code that wants higher precision can use the
64-bit variants on systems that provide it and simply multiply out the
32-bit ones to give usable values on those that don't.
All 64bit linux arches uses 64bit signed time_t, and its in seconds.
Higher precision timestamps are done in linux by introducing separate
nanosecond fields in struct stat. This is all transparently handled by
GIO if you just use GFileInfo.
Note that on Windows the 64-bit time fields are just more seconds since the
Epoch, with an upper limit of Dec 31 23:59:59 3000. If we decide that the
64-bit time field is really nanoseconds since the Epoch (a much more usable
value IMHO) then it can represent dates up to some time in the year 2262. I
don't think it matters what it represents as long as we define it. If GLib
only breaks in the year 2262 I'm quite Ok with that :-)
Of course we can't just make time_t be nanoseconds, that would break a
lot of other functions that expect it to be in seconds.
___
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)
time_t is typically a signed long, which is 64bit on all 64bit linux versions. Even more good reason to standardize then. I don't see what advantages this gives you. It will break all existing code that uses g_stat and struct stat, you can't share GStatBuf with other struct stat using code, you can't access extensions like nanosecond mtimes, it doesn't have things like blocksize and st_blocks which means you can't calculate actual space used. So easily solved. Call the damned thing g_statfile() and have the structure be GFileStat. Something else. The Windows stat structure doesn't have block size and st_blocks anyway so again your code needs to become poluted with ifdefs. We can add the block size and number of blocks, and on Windows we can either find another API that gives us the same information of set the block size == file size and the number of blocks to 1 so that the code presents a uniform interface. It is *EXACTLY* because of all of these differences that having a wrapper is useful. Also, we *do* have an abstraction that lets you write portable code. Its called GFileInfo. g_stat is by its nature a lowlevel unix-like call, it was added mainly as a quick way to port unix code to windows. So, introducing our own copy of struct stat on windows might make sense (with its c runtime library issues), but we don't want to change it on unix. Only if you define UNIX as Linux. OSX has other fields Linux doesn't. Some UNIX variants have 16-bit uid_t's others have 32. Some have as low as 16-bit ino_t's others have 64. There are all KINDS of ways in which it differs. Offering a portable, no-ifdefs-required, suitably-large-sized-to-accomodate-everyone structure ... yes *STRUCTURE* that all code can use completely portably without having to worry about anything ... SURELY you can see the value in that? GFileInfo from GIO? You have GOT to be kidding me? As a replacement for stat()? When I want to look up a file attribute I have to go through hash table lookups for attributes and a completely open-ended size (GArray *attributes) and all that parent class and instance overhead - versus having a single structure I can sizeof() and write to a file? In what universe is that a better approach? GLib does plenty of abstractions of things that you could just use the native API for. Like g_malloc(). You could just use malloc(). But there are variances on how malloc() behaves so you wrap it to get consistent behaviour so that everywhere you use g_malloc(0) you know exactly what you are getting. You wrap printf because not all printf's are alike. stat() is just the same. It needs wrapping because not all stats are the same. It can be trivially done. It can be done in such a way that it doesn't break any ABIs or even API's. What's the problem? ___ 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)
Le mercredi 28 septembre 2011 à 11:03 +0200, Kean Johnston a écrit : Only if you define UNIX as Linux. OSX has other fields Linux doesn't. Some UNIX variants have 16-bit uid_t's others have 32. Some have as low as 16-bit ino_t's others have 64. There are all KINDS of ways in which it differs. Offering a portable, no-ifdefs-required, suitably-large-sized-to-accomodate-everyone structure ... yes *STRUCTURE* that all code can use completely portably without having to worry about anything ... SURELY you can see the value in that? GFileInfo from GIO? You have GOT to be kidding me? As a replacement for stat()? When I want to look up a file attribute I have to go through hash table lookups for attributes and a completely open-ended size (GArray *attributes) and all that parent class and instance overhead - versus having a single structure I can sizeof() and write to a file? In what universe is that a better approach? Do you have a use case where hash-table lookups would be a bottleneck? With dual-core CPUs we have nowadays, disk access is likely to be much slower than the hash-table work that GIO produces. And few programs would need to stat that many files anyway. Cheers ___ 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)
Do you have a use case where hash-table lookups would be a bottleneck? Small mobile devices. Devices with only 64MB of RAM to play with. Embedded devices. Just because GLib is used mainly in GNOME don't make the assumption its the ONLY place. Not every deployment of GLib applications is on a multi-core CPU system with multi-gigs of memory, or even with traditional hard disks. Or even hard disks at all. Places where you are using GLib becuase its relatively small, not using the massive overhead that is GIO and which serves a different purpose entirely. Just becuase GLib and GIO come in the same tar does NOT mean they are always deployed side by side. With dual-core CPUs we have nowadays, disk access is likely to be much slower than the hash-table work that GIO produces. And few programs would need to stat that many files anyway. Really? On what do you base that information? There are three applications I want to write that even brought me to the GLib / Gtk+ world and ALL of them use stat because they are dealing with files. The bottom line is, although stat may be a low level system call, applications deal with files. A LOT. A HELL of a lot. stat is a basic file operation. It can be made to be more portable. That's all I am trying to do. It can abstract 95% of all of the problem areas. If you have an application that needs very specific, tied-to-one-OS stat structures then by all means use stat. But when a *Platform* library isn't abstracting a basic *platform* call, that's a problem and I don't understand all the resistance to it. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Grip Size
On 26 September 2011 20:21, Matthew Bucknall matthew.buckn...@googlemail.com wrote: I'm working on a custom container class using GTK+ 3.0 which has some similarities with GtkPaned but supports more than two child widgets. I can install a style property to specify the size of the grips used for resizing child widgets, however it is not likely that any theme will ever support the property for my class. Is it possible for my container class to get at the handle-size property for GtkPaned without having to instantiate a GtkPaned object? I would appreciate an answer to this question. I'm sure someone on this list must known. ___ 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 Wed, Sep 28, 2011 at 10:27 AM, Kean Johnston kean.johns...@gmail.com wrote: Do you have a use case where hash-table lookups would be a bottleneck? Small mobile devices. Devices with only 64MB of RAM to play with. Embedded devices. Just because GLib is used mainly in GNOME don't make the assumption its the ONLY place. Not every deployment of GLib applications is on a multi-core CPU system with multi-gigs of memory, or even with traditional hard disks. Or even hard disks at all. Places where you are using GLib becuase its relatively small, not using the massive overhead that is GIO and which serves a different purpose entirely. Just becuase GLib and GIO come in the same tar does NOT mean they are always deployed side by side. Writing embedded code and writing code that is portable between three major desktop OSes are essentially orthogonal concerns. Scripting languages such as Python use hash tables for all their namespace lookups and as a common data structure - it's not a huge performance concern. With dual-core CPUs we have nowadays, disk access is likely to be much slower than the hash-table work that GIO produces. And few programs would need to stat that many files anyway. Really? On what do you base that information? There are three applications I want to write that even brought me to the GLib / Gtk+ world and ALL of them use stat because they are dealing with files. The bottom line is, although stat may be a low level system call, applications deal with files. A LOT. A HELL of a lot. stat is a basic file operation. It can be made to be more portable. That's all I am trying to do. It can abstract 95% of all of the problem areas. If you have an application that needs very specific, tied-to-one-OS stat structures then by all means use stat. But when a *Platform* library isn't abstracting a basic *platform* call, that's a problem and I don't understand all the resistance to it. The problem is that stat is API from the 1970's. None of us really want to prolong the life of code with such readable names as S_IFMT, S_IFREG, st_blksize and EBADF. One of GIO's design goals was to come up with a fully portable, modern abstraction on top of all this. I for one would much rather be working with G_FILE_ATTRIBUTE_STANDARD_IS_BACKUP, G_FILE_ATTRIBUTE_TIME_ACCESS etc. GLib is a 21st century platform library, not a pile of portability hacks. I admit that for convenience it's managed to acquire a bunch of portability hacks, but this isn't a design goal. If you would like to use GIO but find measurable performance problems or missing functionality, bug reports are welcome. Sam ___ 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)
The problem is that stat is API from the 1970's. None of us really So is malloc. So is chmod. They are wrapped. want to prolong the life of code with such readable names as S_IFMT, S_IFREG, st_blksize and EBADF. One of GIO's design goals was to come up with a fully portable, modern abstraction on top of all this. I for And if your application can benefit from that, please, by all means go ahead and USE it! But why should that be used as a precluder for someone who wants to USE the smaller, more efficient, working since the 1970's API? A USEFUL tool provides choices. That's what I want to do - provide a choice. I don't want to use GIO thank you very much. Pull in a library with 173762 lines of code (aside from GObject which it depends on)) so I can use G_FILE_ATTRIBUTE_TIME_ACCESS instead of buf.st_atime? No thanks. GLib is a 21st century platform library, not a pile of portability hacks. I admit that for convenience it's managed to acquire a bunch of portability hacks, but this isn't a design goal. If you would like to I want to add one more portability hack. It serves a need and doesn't impact anyone who isn't interested in using it. I am trying to improve Glib. Not GIO, but Glib. I want to use GLib. Not GObject and libFFI, not Gthread, not GIO. GLib. It has its own headers and its own library. There is one function I want to make more portable, and 2 I want to add because they are missing (seek and tell). If the way you develop software allows you to bring in hundreds of thousands of lines of code rather than using a single structure, then please, be my guest and do so. But please for the love of all that's holy stop trying to tell me that's how *I* should be doing things. use GIO but find measurable performance problems or missing 1,155,072 jx10-gio2.dll - 'nuff said. I hear people complaining about lack of maintainers all the time. I am trying very hard to participate in the community and add value. As all newcomers to a project do I pick something small that can benefit others as well as scratch a personal itch. That's how a development community grows. Whether you realize it or not you guys are being down-right contributor hostile. I have absolutely *NO* problem making my own changes to glib and maintaining them for my own purposes. I can use my time writing software instead of debating things with you. But if you want help, and you want fresh blood and you want a developer who is trying desperately to maintain the software on the worlds most common platform and offer precious cycles to your team, then please consider that not every single change has to appeal to one audience, that there are multiple uses of GLib far divorced from the GNOME community or UNIX and that not everyone thinks as you do or uses the software the way you do. ___ 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 Wed, 28 Sep 2011 at 11:03:00 +0200, Kean Johnston wrote: Offering a portable, no-ifdefs-required, suitably-large-sized-to-accomodate-everyone structure ... yes *STRUCTURE* that all code can use completely portably without having to worry about anything ... ... until GLib is ported to platform-of-the-week (Hurd? Plan 9? Windows 8?) which has interesting fields that weren't in the traditional struct stat; at which point it either becomes non-comprehensive on the new platforms (missing information that the new platform provides), or variable-size (#ifdefs), or an ABI break on existing platforms (GLib 4). Comprehensive, same layout on all platforms, fixed layout over time: pick any two. GFileInfo is opaque/extensible/indeterminate-size precisely so that the fact that its layout changes over time is not an ABI break. S ___ 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 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: GTK3 size negotiation
On Tue, 27 Sep 2011 12:06:06 -0400 Tristan Van Berkom t...@gnome.org wrote: On Tue, Sep 27, 2011 at 10:04 AM, Tony Houghton h...@realh.co.uk wrote: I found a bug in the GTK3 version of my X terminal application, roxterm http://roxterm.sourceforge.net: If you maximize a window with a single tab then unmaximize it, its width increases to more than it was before the window was maximized. Hi, Just a friendly reminder, in general this kind of query should probably go to gtk-app-devel-list (a list about developing with GTK+), we like to keep this list limited to discussion on the development of GTK+ itself. OK. But I thought it was on topic because there does seem to be a problem with GTK, but I don't know exactly what the bug is and what component(s) it's in so I wanted to discuss it before filing a bugrep. BTW, I posted about g-ir-scanner on the list because I was pointed to it by https://live.gnome.org/GObjectIntrospection. I thought it was a bit strange though. Would gtk-app-devel-list be more appropriate for that too? I'm surprised not to find lists especially for glib/gobject/introspection. Comments below... Unlike gnome-terminal, roxterm (optionally) always shows the tab bar. When there are multiple tabs the children are set to expand and fill and the tab bar spans the entire window. In this mode the window unmaximizes to its correct size. With a single tab expand is FALSE and I've written a custom label widget to try to make the tab approximately half the width of the window, which looks good. I realised why the size was changing: when the window is maximized, the tab is wider than the window's unmaximized width. When unmaximizing GTK prevents the window from becoing too small for that tab even though its size is renegotiated so it's approximately half the window's new width. During size negotiation the label has to request its mimimum_width to be the target width. If I try to use natural_width instead it ignores it and uses the minimum_width set by the base class, which is just enough to show the three dots when it's fully ellipsized, so that's no good. [1] That's a problem with the parent container, if it's modern and uses gtk_distribute_natural_allocation() for size allocations then you wont have this problem. (if your tab bar is a GtkBox or GtkGrid derived widget then it should allocate correctly, if it's a custom widget, it should be ported to use modern allocation logic). If we are taking about the tabs built-in to a GtkNotebook, then perhaps it's worthwhile to write a very short test case showing the bad behavour (I'm thinking a test case with just a window with a notebook and a broken ellipsized tab would be perfect) and file a bug against the notebook widget with that here: http://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B It is a GtkNotebook. I haven't checked yet whether it's specific to that or containers in general. I connected signal handlers for size-allocate and configure-event on the toplevel window, but the first time they get called during unmaximizing their data already contains the incorrect width based on the label's maxtimized size, so it seems it's already decided on its new size before any attempt to renegotiate the tab size can be performed. [2] That's normal, size requests are cached, widgets are only re-requested if their content changes (or say, the height might be re-requested in response to a window resize if the widget is height-for-width). On reflection, it's actually quite reasonable for GTK not to make the window smaller than the maximized size of the tab, seeing as I requested that size as a minimum. So the real problem is that the natural size is being ignored. Again, when writing a container, it might seem reasonable to use the minimum size when the expand flag is false, but it overlooks the issue of causing unwanted ellipsizing. And if the text size is small for other reasons (eg a roxterm tab label contains only '~') it can make visible/interactive containers like notebook tabs too small for convenience or aesthetics. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Cleaning up owned dbus names on shutdown with glib
On Wed, Sep 28, 2011 at 10:05 AM, Daniel Drake d...@laptop.org wrote: Let me know how I can debug this further - I can reproduce it trivially. Please use GLib bugzilla and the gdbus component for bug reports (it does sound like it's a GDBus bug) - otherwise it will just get lost. Thanks. David ___ 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 Wed, 2011-09-28 at 11:03 +0200, Kean Johnston wrote: So easily solved. Call the damned thing g_statfile() and have the structure be GFileStat. So then we would have 'struct stat' and 'GStatBuf' which would work with g_stat(), g_lstat() and fstat(). Additionally we would add a 'GFileStat' that only works with new calls 'g_statfile()', 'g_lstatfile()' and (presumably) 'g_fstatfile()' (for fstat() functionality applied to the new structure type). My head is spinning... Only if you define UNIX as Linux. OSX has other fields Linux doesn't. Some UNIX variants have 16-bit uid_t's others have 32. Some have as low as 16-bit ino_t's others have 64. There are all KINDS of ways in which it differs. Offering a portable, no-ifdefs-required, suitably-large-sized-to-accomodate-everyone structure ... yes *STRUCTURE* that all code can use completely portably without having to worry about anything ... SURELY you can see the value in that? GFileInfo from GIO? You have GOT to be kidding me? As a replacement for stat()? When I want to look up a file attribute I have to go through hash table lookups for attributes and a completely open-ended size (GArray *attributes) and all that parent class and instance overhead - versus having a single structure I can sizeof() and write to a file? In what universe is that a better approach? I don't find the ability to write 'struct stat' to a file to be a particularly compelling usecase... You propose to avoid indirection by moving people away from GFileInfo to GFileStat. At the same time, you'd be adding more indirection to the g_stat() users though -- a copy of all of the various fields of the system native structure to our shadow structure. Unless you actually propose that we keep both APIs around and undeprecated -- and my head is spinning again I don't really appreciate the problems that are caused by different sized inode, uid, etc. fields... It might be unsightly or aesthetically displeasing on some level, but the something like: if (buf.st_uid == getuid()) ... will obviously always work properly. I think, if anything, we cause ourselves more trouble by breaking with the system definition. The only benefit to your proposal (from a UNIX standpoint, at least) is that it helps avoid accidental portability problems where a non-portable field is used. I'm not sure that it's worth all the drawbacks. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkTable is deprecated
Hey everyone, So now with GNOME 3.2 out, it's time to make GTK break builds again. So I deprecated GtkTable in GTK master[1]. GtkTable is turned more and more problematic as GTK 3 evolves and the implementations of height-for-width improved, which GtkTable does not support. So we were ending up with more and more bugs about tables allocating way too much space for widgets (feel free to ask the Empathy guys about it ;)). 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. Happy hacking, Benjamin 1: http://git.gnome.org/browse/gtk+/commit/?id=08d578dfcbbbc4769d8c26de4ea0de4f76e1b2de 2: http://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-set-hexpand 3: http://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-set-vexpand 4: http://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-set-halign 5: http://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-set-valign ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
