Re: I'm done with O_CLOEXEC
hi, On Tue, Mar 31, 2015, at 03:48, Alexander Larsson wrote: In general, setting O_CLOEXEC is a nice thing to do, but doing so does not change the fundamental fact that you can't rely on it being set. This is pretty much the entire point of this thread. I now consider O_CLOEXEC as a 'nice to have', but I will not consider it to be a bug if we fail to do it in some place. On the other side of things, it is expected that anyone doing fork()/exec() really -must- go through the close-the-fds song and dance. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I'm done with O_CLOEXEC
hi, On Sat, Mar 28, 2015, at 02:22, Jasper St. Pierre wrote: Thanks. I have refactored this code to use GSubprocess: https://git.gnome.org/browse/mutter/commit/?id=d4e8d97e58f9c931a14ea9b6484890d7a66e65e7 Glad to see this getting some more use. It looks like you leak the launcher, though. How about g_autoptr()? :) Not overly happy with the hardcoded fd assignments, but it's not the end of the world. It's really a lot better this way -- you get full control over it. I guess we could have an API that takes an fd and assigns the next available child fd (starting at 3), but what would be the point? You would just have to string-format the ints for the commandline... and the result would always be the same every time anyway. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I'm done with O_CLOEXEC
hi Chris, On Sun, Mar 22, 2015, at 09:12, Chris Vine wrote: The implementation borrows from g_spawn* which does not look quite right to me. I have submitted a bug ( https://bugzilla.gnome.org/show_bug.cgi?id=746604 ). I believe this bug report is based on a common misunderstanding. The code in question should definitely be safe. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I'm done with O_CLOEXEC
On Sat, Mar 21, 2015, at 12:04, Matthias Clasen wrote: 'Not part of POSIX' has never stopped us from using something in glib: atomics, futexes, inotify, pipe2, libelf, to name just a few... ...and in each of these cases, we pay the price with some sort of abstraction layer, #ifdef, fallback cases, etc. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I'm done with O_CLOEXEC
On Sat, Mar 21, 2015, at 12:09, Matthias Clasen wrote: Are you actually suggesting that we rip out all code that is currently doing the right thing, cloexec-wise ? from my original email: I'm not going to go and retroactively tear things out where they are already working, unless it would provide a substantial cleanup or fixes an actual bug. I'm not just going to go around looking for #ifdefs to remove. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I'm done with O_CLOEXEC
hi, On Sat, Mar 21, 2015, at 01:59, Jürg Billeter wrote: I would keep using O_CLOEXEC as it's as close as we can get to the behavior that should have been the default: don't implicitly inherit file descriptors on exec. Maybe there are applications out there that rely on correct file descriptor flags and directly call fork/exec. You could try to convince them to switch to GSubprocess (or work around the issue in their own fork/exec code). However, as I think we all agree that O_CLOEXEC is the best default behavior, I don't see why we should break these applications. This is probably the best counter-argument so far: since we all agree that the inherit-by-default behaviour is silly, we should try as much as possible to mitigate it. I agree with that point, but the main thrust of the argument that I was trying to make originally (and somewhat detracted from with my ranting) is: - there is often a high price to pay for doing the right thing; and - it's not actually necessary Sure, it's conceivable (and even likely) that there is code that isn't up to snuff, but that's sort of the point of this thread. I want to shift responsibility for getting this right from the innumerably many places that we create fds to the very few places that we launch subprocesses. And by the way: the high price that we pay is not just in cases where we need to implement one codepath for Linux and a fallback for other platforms inside of GLib. If you fully buy into the O_CLOEXEC mantra, then it means that every single person who casually calls open() (even in application code) needs to take care to get it right, for fear that some naive library is doing fork()/exec() in another thread. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I'm done with O_CLOEXEC
On Fri, Mar 20, 2015, at 20:29, Christian Hergert wrote: What I would welcome, is a function that says glib, close all FDs you know about or that you created. If all the libraries did that, at least it would be possible for applications to maybe, sorta, do the right thing. (That would push the synchronization responsibility during fork()/exec() to the application). I don't think this is the correct approach. The application should not have to be aware of what GLib is doing, or even that it is using GLib at all (if GLib is pulled in by some other intermediate library). Much less for any other libraries that it may be using. What the application should be aware of is simple: what does it want to pass to a process that it is spawning? Anything that it doesn't want to pass should be closed (after the fork, before the exec). There are many ways of accomplishing this. Some systems have an fdwalk() [read: foreach open fd] call designed to help you do this. On Linux the common idiom is to iterate /proc/self/fd/, closing as you go. On other systems which lack either of these, it's still possible to obtain the maximum possible file descriptor number and simply use a for loop to close them all (even if you call close() on some fds that are not really open). [[ As an aside: it would be great if we had a variant of execve() that took an array of fds. The new process image would end up with the fds in that array remapped as fd 0, fd 1, fd 2 (and so on) according to their array position. The truth is, however, with the walk and close all fds tricks that are already widely known and practised, this would only be a convenience. ]] Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I'm done with O_CLOEXEC
On Fri, Mar 20, 2015, at 23:33, Matthias Clasen wrote: So, you found that dup3 doesn't do what you want, and now you want to throw out the baby with the bathwater and just say I don't care anymore if we leak fds ? dup3() was a bit of a straw that broke the camel's back case. I could point at the existence of g_unix_open_pipe() as a similarly ridiculous case, or many others. I'm also not impressed by the inaccurate categorisation. I thought I explained fairly clearly why I believe that leaked fds will _not_ be the case, even without O_CLOEXEC. I was looking for some slightly more constructive arguments... Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I'm done with O_CLOEXEC
hi, On Sat, Mar 21, 2015, at 01:19, Jasper St. Pierre wrote: Right now, we use raw fork/exec in mutter where we need to do some tricky management and explicitly leak an FD into the correct place [0]. Does this mean that from now on, glib might leak an FD and we need to be prepared to handle that? Refactoring the code to use a child setup func and using g_spawn isn't quite really what I want to do (can I even leak an FD made with socketpair through in that case?), but I want to be aware of what might break in the future, and whose bug it should be. I recommend using GSubprocess. g_subprocess_launcher_take_fd() lets you give an fd (along with a target_fd number). This fd will appear in the newly-spawned process as the target number you gave. This is what I mean by code that spawns processes having explicit control over what they do. For example: int sv[2]; socketpair (..., sv); g_subprocess_launcher_take_fd (launcher, sv[1], 3); g_subprocess_launcher_spawn (launcher, NULL, /usr/bin/whatever); will put the sv[1] end of the socket pair into the launched process as fd 3. I know it's difficult to set a policy about this, but is there anything I can do to prevent too much damage in the future? If I file a patch against glib for where it might not set CLOEXEC with an easy flag the syscall, will you accept it, or are you going to reject it to stop me from relying on CLOEXEC? I'm not sure. It probably depends on the outcome of this thread. I'm leaning towards we won't do it if it complicates the code. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: I'm done with O_CLOEXEC
hi, On Sat, Mar 21, 2015, at 01:27, Jürg Billeter wrote: Doesn't the following standard POSIX functionality provide what you want? fcntl(fd, F_DUPFD_CLOEXEC, 0) Yes. It does. Thank you very much. It seems that this is a (slightly) recent addition. It's documented: F_DUPFD_CLOEXEC (int; since Linux 2.6.24) so I'm sure we'll probably still need to write an ifdef with a fallback... The wider question about the usefulness of O_CLOEXEC still stands. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib is branched
karaj, I just released GLib 2.43.92 and branched. 'glib-2-44' is what will become 2.44.0 and 'master' is what will become 2.46. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File monitor rewrite: Solaris (and other) help wanted
hi Aleksander, On Thu, Jan 15, 2015, at 06:28, Aleksander Morgado wrote: Currently GFileMonitor doesn't have a unique way to know whether a file got closed. There is the changes-done-hint event, but that covers IIRC 2 things: files getting closed and also a virtual emission which happens after some time even if the files were not closed (think of a log file which never gets closed). The main issue is that if you want to get notified of when a file was fully updated *and* closed, you need to fallback to raw inotify. The rationale for wanting to get notified only when the file got closed is e.g. Tracker monitoring the Downloads/ directory. We may not want to extract file info for an ongoing download, just for when the download is fully finished (and destination file closed). More background here: https://bugzilla.gnome.org/show_bug.cgi?id=635765 Short story: I want to add a flag to either disable or enable emission of virtual changes-done hints on monitor backends that can reliably handle it themselves. Even for fully-capable backends, I think virtual emissions are potentially important because, even if the file is not closed, someone watching it may want to update their opinion of its contents periodically. The question is only about what the default should be. Those who favour a nice clean API would say that virtual emissions should be off by default. Those who favour backwards compatibility would suggest that today's behaviour of virtual emissions should be kept as-is unless explicitly disabled. I'm not sure what we will do. Unfortunately, there's a longer story: None of the backends support reliable emission of non-virtual changes-done. Here's why: My plan is to make it a guarantee of the API that both CREATED and CHANGED events will always be followed by a CHANGES_DONE hint. That's already enforced in the state machine logic in GFileMonitorSource in the branch. My reason for that is that apps like Tracker should not want to response to CREATED events until the file content is complete. The idea (taking your download example) is that a file is created something like so: creat() write() write() close() which sends us IN_CREATE, IN_MODIFY, IN_MODIFY, IN_CLOSE_WRITE. As you mention, it doesn't make sense for the app to respond to the empty (or maybe very slightly populated) download just because it saw a CREATED event from GFileMonitor -- it should wait for the CHANGES_DONE. Consider this case: creat() close() in that case, we'd see IN_CREATE, IN_CLOSE_WRITE, with no IN_MODIFY. We still want to see a CHANGES_DONE event in that case, though so that the app knows that the empty file is the 'final result'. This is the basis of my opinion that CREATED should always get a CHANGES_DONE after it, even without actual CHANGED events. With the new support for move and rename events, a file created by the write to temp and mv into place method will be reported either as MOVED_IN or RENAMED with no CHANGES_DONE. That's okay, because you know that a file that was MOVED_IN or RENAMED into place is ready to be handled immediately. Unfortunately, there is another set of cases. IN_CREATE is sent both for the creat() case (in which case it will be followed by IN_CLOSE_WRITE) but also for cases like mknod(), bind() on a unix socket, mkdir(), etc.. In those cases, we will receive no IN_CLOSE_WRITE. We could detect that situation by looking at the filesystem and seeing that the newly-created file is of a special type, but link() also produces IN_CREATE without IN_CLOSE_WRITE. The only thing that saves us in this second case is that we get a virtual emission of CHANGES_DONE a couple of seconds later. At least link() is uncommon, although it stands to become a more common way of creating files, via O_TMPFILE. In short, I believe that we currently don't have any backend for which we could safely disable emission of virtual CHANGES_DONE events. Ideally, in the future, we will gain a mechanism in inotify to tell the difference between file created via open for writing, IN_CLOSE_WRITE coming soon and inode appeared in the file system in complete form. At that point we could expose a new event type in GFileMonitor (_APPEARED?) that doesn't need CHANGES_DONE to be emitted. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File monitor rewrite: Solaris (and other) help wanted
hi, On Thu, Jan 15, 2015, at 10:49, Morten Welinder wrote: Great plan, but you cannot get that in a meaningful way. Think creat write mmap close # Further writes by way of the mapped region I don't think you can detect the end of that write. Quoting inotify(7): The inotify API does not report file accesses and modifications that may occur because of mmap(2), msync(2), and munmap(2). so this is a completely lost cause anyway. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File monitor rewrite: Solaris (and other) help wanted
hi Martyn, On Thu, Jan 15, 2015, at 04:14, Martyn Russell wrote: Just to add to what you said, the Tracker project extensively uses this API and has quite some detailed unit tests which are ensuring the functionality is consistent between releases. It might be useful to anyone looking to test the new work? Thought I would mention it. Details are in tests/libtracker-miner/tracker-monitor-test Thanks for the information. I'll take a look, for sure. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File monitor rewrite: Solaris (and other) help wanted
hi, On Wed, Jan 14, 2015, at 19:13, Fan Chun-wei wrote: I think I can also take a look at the Windows backend for this as well, since we are actually using the same Windows API for monitoring file and directory changes, ReadDirectoryChangesW(), as I was trying to get file monitoring to work on Windows in bug 730116 a while ago (we only had directory monitoring for Windows-probably that bug would go obsolete as a result). Thanks very much for the offer. Please give me a poke on IRC if you need any help. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
File monitor rewrite: Solaris (and other) help wanted
hi, I'm making substantial modifications to the file monitoring system in GIO. I've gotten to the point where I feel comfortable pushing a branch that contains the main ideas: https://git.gnome.org/browse/glib/log/?h=wip/mount-watcher It's not even vaguely tested or stable and will probably crash under anything more than the most trivial of uses. Work will continue over the next days. The private API between GIO and the internal file monitor backends has changed substantially. See the commit message for details about that. This means that all of the backends will need non-trivial changes. I've already made the required modifications to the inotify backend. I plan to move next to the kqueue backend and I could probably even tackle the FAM and win32 backends myself. I have no means of testing changes to the 'fen' backend (Solaris). It would be awesome if someone with a Solaris box and some free time could port the fen backend to the new changes. If nobody comes forward, we will probably remove the backend. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File monitor rewrite: Solaris (and other) help wanted
hi, On Wed, Jan 14, 2015, at 18:14, Christian Hergert wrote: I quickly read over the relevant commit message. I didn't see anything alluding to the goal of the patch set. I'm sure there is a goal you have in mind? Overhead reduction, performance related I assume? Thread safety -- file and mount monitors are currently known to be crash-prone due to races. This has become particularly problematic since GDesktopAppInfo started using them from the GLib worker thread to watch for changes to desktop files. Due to the inotify-kernel changes on that branch, however, one measure of performance is definitely improved: file notifications will now arrive immediately, instead of after a hardwired delay. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: File monitor rewrite: Solaris (and other) help wanted
hi, On Wed, Jan 14, 2015, at 20:49, Christian Hergert wrote: Does anything rely on the delay that happens in the current system? For example, is it used to coalesce an open(O_CREAT)/rename() into a single signal emission? I know I've written some things in the past where I've been a bit worried about getting notified too often and though to myself well, it's OK -- GFileMonitor is slow anyway That's my biggest concern. As for functionality, the typical write-and-rename approach appears today as: create x.tmp change x.tmp changes-done x.tmp rename x.tmp - x and it will appear exactly that way in the future. On my TODO list is to add O_TMPFILE support to g_file_set_contents(), but I sort of want not to do it. I'm afraid that this is going to suck a little bit in terms of how notifications work because inotify reports link() the same as creat(). Normally with creat() we also see the close() event (changes-done) but with link() no such event will show up, so we'll end up generating one for ourselves two seconds later. It seems to be some sort of fail in the kernel that these two cases are considered equivalent. At least renames are their own event... Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Should We Start Dropping Windows XP Support?
hi Fan Chun-wei, On Tue, Dec 30, 2014, at 03:26, Fan Chun-wei wrote: -There are some things that required specialized implementations for XP, for example, SRWLock in GLib and networking items in GIO, which may or may not work well. (for example, by using inet_pton() directly in ginetaddress.c for Windows Vista and later enabled many of the network-address.c tests to pass) -We often needed to do GetProcAddress() to check the availability of system-level funtionalities, which would probably need a clean-up. -As people may know, Microsoft ended support for XP this past April, and it is found that maintaining support for XP is becoming a bigger and bigger maintenance burden. -There is likely the need to move forward to use newer system APIs and features, which were only available after XP (such as desktop/window composition) -Other reasons that people might bring up for this. Very well reasoned. Among the reason above I'd also include the fallback path that we have for monotonic time and secure random number generator seeding. It's my opinion that we should drop XP support early next cycle and take Vista with it. That would mean that our minimum requirement would become Windows 7. Wikipedia seems like as good of a source for information as any: http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm My reason for thinking that is based on the fact that Vista is also out of (mainstream) support and it's even less popular than XP. I also make a totally uninformed 'gut' guess that the people who are still running XP are probably not the kind of people (by and large) who are into installing new versions of software on their computers anyway (ie: they won't be using the new versions of GLib and Gtk or any software that packages them). The only thing I have doubts about are the server OSes (ie: Windows server 2003/2008). I have no idea how popular these are and I suspect that they would be unrepresented in any browser-based stats gathering (aside from terminal servers). I also expect that interest in running Gtk-based software on these machines is perhaps lower, but the same might not be true for GLib. We may fine-tune our requirements for Windows 7 at minimum to Windows Server 2008 at minimum depending on the availability details of the APIs we actually want to use. Let's make that decision when we get there. One thing worth noting is that Server 2003 is out of extended support before the release date of GLib 2.46.0. Windows 2008 will also be out of mainstream support. It seems less likely that a responsible admin would continue to use a server product past its end of life than a normal user with a client OS. If people are really interested in maintaining backwards compatibility of their software to old releases they can make installer packages based on older versions of GLib. I already almost axed XP this cycle. I think next cycle (released ~1.5 years after the end of super-extended-special support) is more than long enough. I also stress the fact that all already-released versions and their stable branches (including 2.44) will continue to work for those who want to package their software based on them for another couple of years. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib/goption.c (unknown symbol)
hi John, On Mon, Oct 20, 2014, at 06:28, John Emmas wrote: Hi - I just updated from git master (about half an hour ago) but MSVC gives me an 'undeclared identifier' error at line 368 of 'glib/goption.c'. Here's what the line looks like:- optind = 1; This is a known issue and will probably be fixed today. See https://bugzilla.gnome.org/show_bug.cgi?id=738659 https://bugzilla.gnome.org/show_bug.cgi?id=723160 Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [Help] Error when Glib cross compiled without the support of _POSIX_THREADS
hi, On Thu, Sep 25, 2014, at 02:29, Lele MA wrote: Does it mean the system doesn't define _POSIX_THREADS? If so, can I still use the glib in the Mini-OS without the support of _POSIX_THREADS? Without knowing too much about this MiniOS: GLib has a hard dependency on POSIX threads. It is not possible to build GLib without threading support. If MiniOS lacks threads, then you will not be able to use GLib there, without substantial modification. I hope this helps to clarify things. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Memory tracking in GJS
hi, On Thu, Feb 20, 2014, at 7:53, Giovanni Campagna wrote: It's worth pointing out that mozjs will *force* a garbage collect if you go over the malloc limit (a dynamic value between 30 and 90 MB), but will garbage collect a lot more often if you call MaybeGC. My preferred solution to the problem involves doing this, perhaps from a very low priority idle, once the mainloop has stopped spinning. I think any proposal that involves a sort of 'information API' where 'well behaved' classes are supposed to provide memory usage information is probably going to be very burdensome. Just to explore an example, a bit: let's say that we really strictly wanted to limit our scope and apply this logic *only* to pixbufs, because we identified those to be a problematic area. We now either need to do one of two things: - keep track of all pixbuf allocations in the program so that gjs can query a list and use this information to decide to do more GC - wire this interface through to the public API of any object that holds a pixbuf within itself, and through to the APIs of objects that hold those objects (etc.) in order to make this information visible on the actual objects held by gjs I consider the first alternative to be excessively evil. It's also unlikely to be able to give you the information you really need -- sure, we have 100MB of pixbufs allocated, but they might be in places that GC wouldn't help you. The second alternative is just entirely too much work to expect of every class that might stand between a pixbuf and a public API -- and we've only limited our scope to pixbufs already. It's also problematic from a (perhaps pedantic) accounting standpoint: if two objects reference a shared pixbuf (or intermediate object) then who gets to claim the memory use as their own? The other allocation-based alternatives sound like possibilities, but perhaps are very much too brittle. For what it's worth, I'm happy to try to find a way to make disabling the slice allocator and adding a memory vtable possible again... Is Giovanni's proposal workable? Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Fwd: glib thread create API
hi, On Tue, Nov 12, 2013, at 11:09, Jonathan S. Shapiro wrote: As an implementation matter, I understand that this is true. As an API matter, it's clearly false, because g_thread_self() is explicitly documented to silently return an invalid GThread* value if the calling thread was not allocated by g_thread_new(). Reconciling this would resolve every concern that I presently have. Here's some insight into what's going on here: When you call g_thread_new() you get a reference to a GThread* structure. When the thread is created, it stores a pointer to this thread structure into a thread-local variable. That's what is returned when you call g_thread_self(). If you call g_thread_self() and this thread-local variable is found to be empty, then you get a GThread structure whipped-up on the spot and returned to you. So each GThread object in existence is owned by: - the thread itself (via its thread-local variable) - the person who got a reference from g_thread_new() - anyone else who added a reference to it The GThread object that is created implicitly by access to g_thread_self() in a thread that was not created by GLib (including the main thread) is perfectly valid for most things -- you can pass it around, ref it, do comparisons on it, etc. The things that you should not do to this are the things that are limited to the lifecycle control of the thread itself -- things like joining it. It should be fairly obvious that since you did not use a GLib API to create a thread then you should not use our API to collect it, either. Other than that, there really are no GThread APIs left to speak of, so there is really no difference in what you can do (outside of the exceptions mentioned above). btw: I don't think that having the teardown APIs unsupported on these implicitly-created GThread is a weird thing. The person who wants to tear down the thread is probably the person who called _new() on it anyway -- and in this case nobody called _new()... By reconciling, I don't necessarily mean that the glib code base has to change. If I feel a need to mess with pthreads (or whatever) directly, the onus to make that work with glib should probably be on me. This could be purely a matter of documentation. In that case, it would be helpful if glib might export just enough API to let me manage the issue (and no more). Would it help if we documented something along the lines of On non-Windows systems, the threads created with this API are pthreads? The only issue I see - and I haven't looked at the internal GThread structure to see if this is addressed already - is that the thread teardown behavior would need a callback mechanism so that alien threads can be torn down properly. We don't want this, as mentioned above. Oh. And if g_thread_self() can return invalid answers without signaling, I think the API needs g_thread_is_gthread(), which returns true IFF the thread was allocated by g_thread_new(). The fact that this call even warrants consideration kinda illustrates why the current behavior of g_thread_self() isn't a good thing. As mentioned, the GThread returned from this API is completely legit. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib thread create API
hi, On Sat, Nov 9, 2013, at 10:38, Jonathan S. Shapiro wrote: but I'm kinda stuck, because GTK relies on GLIB mutexes, which seem to rely on GThread. This is not true. You can make your own threads and use them with our mutexes. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: non-Linux OSes
On Wed, Oct 23, 2013, at 6:26, Marc-André Lureau wrote: It would be nice if we can keep XP compatibility for a few more years (why would we need to drop it now?). XP support could be limited to mingw64, if it's complicated to keep MSVC support? The biggest gain here would be to kill the beast that is the SRWLock emulation. That said, this code has been working nicely for years now and nobody is touching it, so maybe it's not that big of a gain. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: non-Linux OSes
hi On Tue, Oct 22, 2013, at 6:11, Alexander Larsson wrote: By Darwin you mean OSX in general I assume? yes. I guess we need Cocoa here too in order to really be useful. I think the above list is a good start. But it is not good enough. We also need to specify which versions of the above OSes, and which versions of the compilers (especially important for e.g. msvc). For MSVC I agree. For the others, I don't think it's that big of a problem (although it could become a nice opportunity). As a result of our backcompat with world+dog, we've been pretty conservative about what we require. If we add a feature that appears in new versions of Linux, for example, we always add the back-compat case for both older Linux and other non-Linux systems. I expect we'd pretty much continue this way. What would be nice is in the case of things that have long been in POSIX, we could end of life old OSes and drop the backcompat hacks, relying on the new feature. What about android? It runs linux, but its sufficiently different than desktop linux to require its own testing. Also, what about iOS? As per e.g. http://stackoverflow.com/questions/5287960/compiling-glib-for-iphone: Yes it can be built, (see: http://stackoverflow.com/a/17733328/1856278) and there are several Apps in the Appstore that uses it. These were obvious omissions. Thanks. llvm? We've been mostly treating llvm as GCC for now and that's been working mostly OK for us. We occasionally see issues but they're almost always clang bugs (of course, doesn't mean that we don't have to work around these issues and that we shouldn't test...). It seems to me that it should be possible to have virtual instances of at least Linux (of various kinds), *Bsd, OpenSolaris, and Hurd running in some VM farm setup with just some work. But ideally we should be running copies of the non-free OSes too. This is more work than you think. Not every free software operating system has come the same distance that Linux distros have in terms of ease of installation and none of them are as familiar to us as any Linux system would be. I'm not the only one who has tried to do this piecemeal in the past and failed -- to even get the system up to the build deps installed point is not trivial. After that, keeping it up-to-date would be an ongoing challenge, multiplied by 10 (for the number of VMs we have, each totally different in its upgrade progress and schedule). I think we need outside help. Which these are virtualizable on x86? I know OSX is virtualizable, but there are licensing issues on non-apple hardware. New copyright law in Canada creates explicit exceptions for this sort of thing, so this is legal, in Canada at least. :) Solaris is availible on X86, maybe we can ask oracle for a few licenses for this (of course, ideally we should be testing on sparc hw too). I think there are a couple of old (but beefy) sparc machines floating around that some GNOME hackers received as gifts from Sun back in the day... Note: I just discovered that OpenSolaris lives on... Their homepage even talks about how they're GNOME-based: http://openindiana.org/ Probably there will be a growing delta here with time, though. HP-UX is itanium and pa-risc only i believe, AIX is PPC/s390 only. Maybe we could score a power machine that can run VMs from somewhere, but s390/pa-risc/itanium hardware sounds unlikely, maybe we can soft-emulate them?. Or we could exercise the other angle in this case and try to find some people who would give us access to their existing systems (or set up VMs for us, and maintain them). Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
non-Linux OSes
hi,
GLib aims to work on a wide range of operating systems, but we have no
good story for ensuring that this is the case. Mostly we do things for
Linux and, if they are the sort of thing that may cause problems, we
also check that they work on Windows. We read manpages and make sure
that the functions we are using are in the proper POSIX specs, but this
is not always a fool-proof process.
We want to improve this situation.
Dan recently started by doing some patches to pull out ancient support
for OSes like OS/2 and BeOS.
We have brainstormed a list of platforms that we think that we want to
support and it looks like so: Linux, {Free,Net,Open}BSD,
(Open?)Solaris, HP-UX, AIX, Hurd, Darwin, mingw(32/64), MSVC.
There is also the question of non-standard compilers (icc?).
What we don't have are the resources to setup routine testing of GLib
against these target operating systems. Some of these operating systems
are not Free Software.
What would be nice is if we could gain access to some machines (from
various projects) that we could use for testing GLib and/or if we could
get a VM farm setup on GNOME infra that various projects would help us
to setup (and maintain) their OSes on.
I don't have any concrete ideas here, but it seems like there are some
good options. If anyone has ideas or offers of help, they are greatly
appreciated.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Removal of icons in buttons/menus
hi, On Tue, Oct 15, 2013, at 15:14, Olivier Brunel wrote: I do not understand, however, why the entire GtkImageMenuItem widget was deprecated, and not just what relates to those options - since using icons in menus remain a very useful thing, and one used by many GTK apps out there. It makes better UI/user experience as it allows to accomplish certain tasks much easier/faster. The commit message mentions using a GIO API, but that's certainly not a valid replacement, since this is a completely different API and doesn't get us an actual widget/menuitem we can use in a menu. It looks like now every dev/app needs to re-implement this widget itself!? I can give a bit of a background to the reasons here. We make the distinction these days between noun icons and verb icons. Noun icons are icons that go alongside menu items that are nouns (things like bookmarks, applications in a list, disk devices, etc.). Verb icons are the old stock icons that we used to show beside verbs (Save, Quit, Print, etc.). Take a look at this page: https://wiki.ubuntu.com/MenuLayout and take particular note of these paragraphs: A menu item should have an icon before its text only where the item represents a dynamic object... and Any icon that comes before a menu item’s text should be laid out as if it is the beginning of the text... and In particular, icons of this sort should not go inside the margin... These dynamic object icons (that we call noun icons in GLib/Gtk) and are the sort of icons created by the GIO API. This is done in Gtk by creating a GtkBox and packing the icon and label into it so you get the effect mentioned in the spec above (laid out as if is is the beginning of the text, not inside the margin). GtkImageMenuItem puts its icon in the margin. We don't ever want noun icons to appear here. I nearly added gtk_menu_item_set_icon() that would add a noun icon in the proper place (ie: not in the margin) but implementing this proved to be sort of complicated -- mostly owing to the fact that GtkMenuItem is a container that can have arbitrary widgets added to it. Dealing with all of the possible combinations of things that could happen with icons, images, labels, boxes and other arbitrary widgets got complicated fast and I just gave up. It was much easier to implement for GtkModelMenuItem (which is how we get GMenu displayed in Gtk) because of the limited scope and my total control over the widget, so I only did it there. My thinking was that if you want noun icons, you can use GIO. If you want to continue using GtkImageMenuItem for verb icons (ie: things like Save, Quit, etc... the old stock icons) then you could do so. If someone else wanted to add gtk_menu_item_set_icon() and take care of the edge cases, we can still do that -- but this API should *only* be used for noun icons, not to have an icon beside Save and Quit. Moreover, what's the justification for not only deprecated the while widget, but breaking it - and therefore any all GTK apps using it - at the same time? I don't agree with this having happened. The deprecation is fine (and I think we should drop it completely in Gtk 4) but breaking its functionality during a stable cycle is not so cool. I did what I did (adding support for noun icons) because we wanted to use them from GNOME applications and applications written for Ubuntu and this is what I was working on. GNOME is also trying to move over to using GMenu so it made sense to add the support for the noun icons there. GNOME turns off verb icons by default these days and I think that makes sense for GNOME (and indeed, GMenu has no support for verb icons). That said, I still don't agree with (effectively) removing the ability to have verb icons for people who still want them. This is a widget that is only used when an icon should be present, since that's the whole purpose of the widget. With GTK 3.10 this behavior, the default/expected behavior since - again - that's the very reason to use this widget, is now broken. Note: this widget should only be used for verb icons. These are no longer of interest to GNOME developers, but I agree that others may find this desirable... Hope this provides some clarification. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Removal of icons in buttons/menus
hi, On Wed, Oct 9, 2013, at 10:45, Matthias Clasen wrote: You are right that the functionality of the gtk-button-images and gtk-menu-images settings was removed. They are only 'deprecated' insofar as programs that were using g_object_set to directly change these settings on the GtkSettings object will not fail to compile or run. In-so-far as it is possible to use g_object_set() to change these settings manually, we still need to have code in the widgets themselves to support programs that do this. That means that we really have gained no advantage in terms of reduced complexity anywhere. However, from looking at the commits in question: menus: https://git.gnome.org/browse/gtk+/commit/?id=e8147d15f74e62047c84eb95e393449722198d89 buttons: https://git.gnome.org/browse/gtk+/commit/?id=65c31629c38b3b1f49fb6f3327dc28819ffe0657 it seems that this is not the case. Those commits remove code from GtkButton and GtkImageMenuItem to talk to the GtkSettings object, requiring you to use the always-use-image property on the GtkButton and the always-show-image property on the GtkMenuItem. In a way I'm conflicted about this. The simplifications to these widgets (although not substantial) have at least provided an actual reason for us to have removed this feature. It would have been utterly ridiculous and useless for us to have removed the binding glue for these options between XSETTINGS and GtkSettings if we still had the GtkSettings-specific behaviour in the widgets themselves (which is not the case). On the other hand, this really sucks if you're an app author and you just want your images back. If I read the code correctly then you cannot merely set the option on GtkSettings as you just suggested -- you have to set a property on every single affected widget. In any case, I'm not sure what the harm was of having this setting. I can appreciate that this stuff will all die when we have Wayland (and I'm happy for that) but removing this now (for a gain of -98 and -86 lines respectively to gtkimagemenuitem.c and gtkbutton.c) seems highly destructive for very little reduction in complexity. As far as the functionality of those settings goes, we (the involved GTK+ developers) have decided that we don't want to support this functionality, which makes it impossible for designers or even developers to know if there will be an icon at any place in the UI or not. This kind of variability makes it much hard to design and develop user interfaces. For what it's worth, I agree that removing these icons in GNOME apps is a good idea, but I don't think the argument about predictability for designers and developers is a particularly good one. There's two reasons for that. The first is that, as far as GNOME goes, we do not expose a setting anywhere in our user interface for toggling this feature. If someone wants to mess around with XSETTINGS overrides or do something with the tweak tool, that's their business, and if they make their desktop ugly in doing so, then they get to own that. The second is that if an application author really really required no icons in their menus or buttons, even to the extent that they felt that they needed to override the user's settings, they could be the ones that manually override this at the GtkSettings level, forcing its value to FALSE. People keep raising this issue (both on list and on IRC) and I think there's a good reason for it. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Removal of icons in buttons/menus
hi On Wed, Oct 9, 2013, at 14:29, Jasper St. Pierre wrote: Perhaps we can revert the GtkMenu/GtkButton changes and just remove the XSettings hookup. Out of all of the available options, this would be the most pointless thing to do. If we're going to have the complexity in the widgets anyway, then we may as well actually have it exercised by something. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Spell checking in GIO
hi, On Wed, Oct 9, 2013, at 18:48, Jasper St. Pierre wrote: Of course, but do any of these need spell checking? I think it would be more helpful to solidify an API for spell checking to see if it's viable to do without UI concepts like cursor position or GTK+ concepts like GtkTextBuffer before deciding where to put it. This sums up my opinion on this topic quite well. I think we're going to get a better experience if we integrate this at the Gtk level than if we try to invent a bunch of generic interfaces that would be required to get this sort of level of integration. If we can design this as a feature for Gtk and discover that, actually, the API is not that tightly coupled with Gtk, then we could consider the possibility of moving it to GIO -- assuming we become convinced that there is a good non-GTK use for it there. There's a lot of we here. Is anyone actually interested in stepping up to work on this? Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Spell checking in GIO
hi, On Tue, Oct 8, 2013, at 9:49, Matthew Barnes wrote: Or perhaps follow the glib-networking pattern where GIO just defines a spell checking interface and an extension point and the meaty parts with the extra dependencies are supplied by 3rd party module(s). +1 from me. This is the only way that we could reasonably do it, in my opinion. The other option would be just to have it in Gtk. I'm not totally convinced yet that this belongs in GIO (although, seriously... someone added _menus_ to GIO, so why not?). Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.38 branched
hi all, I just branched off GLib 2.38 as glib-2-38. 'master' is now fully unfrozen and will become 2.40. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib 2.37.92/3
hi John, On Thu, Sep 19, 2013, at 4:06, John Emmas wrote: Slightly off topic but how do I find out when the upcoming stable version gets released? Although it's not strictly aligned with the GNOME schedule, GLib pretty much tends to follow it these days. You can see it here: https://wiki.gnome.org/ThreePointNine ie: the stable release of GLib will be out next Monday. Next cycle, you can expect a page to pop up here: https://wiki.gnome.org/ThreePointEleven ...and so on. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.37.92/3
hi, GLib 2.37.92 contained a couple of bugs in the new g_file_measure_disk_usage() so I did a 2.37.93 to fix them. This should be the one used in the upcoming release. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'glib/gio/glocalfile.c' no longer compiles with MSVC
hi, On Thu, Sep 12, 2013, at 5:17, John Emmas wrote: Before I add anything to Fan's bug report (and before visiting IRC) let me just create a record here of what I've found this morning - because it's definitely a bit baffling and I think it needs some lengthy consideration These are some interesting insights. This probably needs a bit of in-depth thought but I agree with Fan. It needs to be fixed with some urgency!! Depending on time zones I'd be happy to collaborate on IRC and I could help with testing if necessary. I have a new set of patches on the bug that are ready to be reviewed. https://bugzilla.gnome.org/show_bug.cgi?id=707787 If we can avoid having to use GDir entirely based on your analysis, then I am quite happy for that. In any case, can we please move discussion and analysis to the bug report? It makes it easier for people who try to trace down why we did what we did and may be helpful for freeze break requests, if it comes down to that. Thanks ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abuse of 'const' ?
hi John,
On 2013-04-08 04:44, John Emmas wrote:
// glib/gvariant.h
GLIB_AVAILABLE_IN_ALL
const gchar **g_variant_get_bytestring_array (GVariant *value, gsize
*length);
// glib/gvariant.c
static gpointer
g_variant_valist_get_nnp (const gchar **str, GVariant *value)
{
// some stuff
return g_variant_get_bytestring_array (value, NULL);
}
A 'const gchar **' is (in this case) an array of 'const gchar *' (ie:
const string pointers). It is the strings that are immutable. The
array itself is fully writable, and indeed you should free what
g_variant_get_bytestring_array() returns to you, using g_free().
By the same token it is therefore perfectly acceptable to pass it
through a gpointer.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [PATCH] icon-theme: fix leak in insert_theme()
hi list, On 12-12-02 05:59 PM, Alex Chiang wrote: diff --git a/gtk/gtkicontheme.c b/gtk/gtkicontheme.c index 0520686..cd2d765 100644 --- a/gtk/gtkicontheme.c +++ b/gtk/gtkicontheme.c @@ -1113,6 +1113,7 @@ insert_theme (GtkIconTheme *icon_theme, const char *theme_name) dir_mtime-mtime = 0; priv-dir_mtimes = g_list_prepend (priv-dir_mtimes, dir_mtime); + g_free (path); } priv-dir_mtimes = g_list_reverse (priv-dir_mtimes); We're discussing this issue offline, but it looks like this patch is not the right answer. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Adding .hidden support to the GTK File Chooser
hi, On 12-11-26 04:05 AM, Timothy Arceri wrote: I'm looking into adding support for .hidden to the GTK File Chooser see: https://bugzilla.gnome.org/show_bug.cgi?id=596234 however I'm not 100% sure where I should be making this change. I'm thinking the change should be made to Glib in gfileinfo.c g_file_info_set_is_hidden() that way the code can be shared with Nautilus (the same existing code could then be removed from Nautilus) and any other application that wishes to use it. Does this sound like the right place to be making the change? The bug you link is a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=587806 which already has a very old (2009) patch. The patch was rejected due to its dependency on the existence of a mainloop to clear the cache. GLib now has a helper main context inside of libglib that could be used instead. If you wanted to solve this problem, the patch on that bug would definitely be a good place to start. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
hi Morton, On 12-11-16 03:09 PM, Morten Welinder wrote: The breaking of mouse wheel support in gtk+ 3.4 also comes to mind. (Bug 675089 and others, I'm sure.) If I'm not mistaken, this was a different kind of breakage that we engage in a lot of lately: API-incompatible changes on the unstable branch. As much as those breaks are annoying a lot of people I do believe that we gain quite a bit of benefit from playing a little bit 'fast and loose' with regards to compatibility. Our old behaviour of nothing can change ever led to a substantially stagnated gtk2. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Guidelines for stable branch changes in GLib/Gtk
hi, It seems to me that we've been playing a little bit fast and loose with what goes into stable branches of GLib (and particularly) Gtk+ of late. From my point of view I think the only thing suitable for a stable branch is a bug fix. New features are completely out of the question and new API as well. Deep bug fixes (eg: requiring substantial changes to the iconview in order to workaround difficult issues) are probably also best avoided but it's more difficult to draw a firm line here. Those are my views. I'm not presupposing to enforce my views about what is appropriate in a stable series, but I think we should have a discussion about it and come up with an answer. Then we should stick to it. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
hi, On 12-11-11 03:03 PM, Matthias Clasen wrote: Hard to disagree in the abstract. But also not much of a discussion unless you cite the specific examples that made you write this mail. Which changes were problematic ? There are three specific cases that come to mind: 1) Recently Martin asked me for permission to backport his boxing of GPollFD to the stable branch of GLib and I said no new API on stable branches. I mention this only because of how small of a change it would have been compared to the following two: 2) The icon view changes that landed in the 3.4 cycle. 3) The file chooser recent folder changes that landed in 3.0 and also on 2.x. I consider the last case to be particularly egregious because nothing was broken to start with and the changes were highly visible from a UI standpoint. As I understand it, GNOME enters UI freeze at a particular point in time and never leaves it (on a given stable release). We can argue that Gtk is not GNOME, of course... My main reason for raising these concerns is that I want to see GLib and Gtk stable releases picked up by the distributions for the valuable bugfixes that they contain but distributions (Ubuntu, specifically) are getting annoyed with the non-bugfix changes that are often appearing in our stable series... Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Guidelines for stable branch changes in GLib/Gtk
hi, On 12-11-11 04:46 PM, Matthias Clasen wrote: Ah, ok. So, this is not about anything recent, but a 'multi-year accumulated frustration' mail. The thing that brought this up recently was a discussion at UDS. Ubuntu is nervous to take our stable releases because of what has happened in the past... And it is really just about GTK+, not GLib, as your initial mail seemed to indicate. I if we decide on a policy, it should apply equally to both. I don't think anybody disagrees that these examples would have been better off in devel branches. At the time, I (and others) got the impression that many people felt that what happened was OK and may well happen again in the future -- particularly on the file chooser changes. If this really is in the past and we agree that nothing like this should ever happen again then I do consider the issue to be entirely closed. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib status update and a warning
hi all, We ended up planning quite a lot of work for GLib during Boston Summit, a lot of which was considered to be potentially dangerous. Matthias wrote a good blog post that summarised most of it here: http://blogs.gnome.org/mclasen/2012/10/08/gnome-summit-sunday/ Point-by-point here's the status so far. I omit items that have no extra information to report since the summit (which is about half of them). == On the topic of Linux native thread operations, there is this branch which I haven't touched in a long time: http://git.gnome.org/browse/glib/log/?h=wip/linux I plan to pick that up soon. == The changes to the source API are almost done. See that here: https://bugzilla.gnome.org/show_bug.cgi?id=686853 == * READ HERE FOR WARNING: The removal of support for adding interfaces after class initialisation just landed. This is noteworthy in particular because it may cause some substantial short-term pain. pygobject and libsoup were both consumers of this functionality and they have had to remove their use of it. The upshot of this is that, as of a few moments ago, building glib from git without also building git versions of pygobject and libsoup has the potential to result in things being broken. There may be other users. Please keep an eye open for error messages that look like this: (process:30660): GLib-GObject-WARNING **: attempting to add an interface (TestIface1) to class (BaseObject) after class_init and give feedback here: https://bugzilla.gnome.org/show_bug.cgi?id=687659 In any case, following the normal G_DEFINE_TYPE_WITH_CODE() and G_IMPLEMENT_INTERFACE() pattern will always work. == I landed the ancient patch in bug 118536 to fix g_signal_connect_object() to automatically disconnect the handler when the target object was destroyed. This has caused some fallout. Most noticeably it has caused gedit to crash on exit. pbor and I are looking into this problem. Anyone who can produce a small testcase that demonstrates the issue has my undying gratitude. == g_type_init() is now deprecated. This caused a small amount of fallout which you can read about here: https://bugzilla.gnome.org/show_bug.cgi?id=686822 == GTask landed, as planned. == Unicode 6.2 support landed, as planned. == Not on Matthias' list, but another change: the -constructed() vcall on GObject is now called after *all* properties have been set (not just the G_PARAM_CONSTRUCT ones). This addresses a major complaint that (potentially) users of this API have had almost since it was introduced. There was no known fallout caused by this change. == Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
path= (or not) in GSettings schemas
hi, One of the big design mistakes I made with GSettings is that this is really weird: schema id=org.a11y.atspi path=/org/a11y/atspi/ The requirement to specify a separate path is confusing. It causes people to think that maybe the path should have a prefix like /apps/. If you manage to avoid this trap and do it properly then it is completely redundant. Of course, it is possible to omit the path to create a relocatable schema. schema id=org.a11y.atspi That's the crux of the mistake. Relocatable schemas are somewhat rare in their use. The non-relocatable case is the 'ordinary one'. Ideally, the syntax (immediately) above should have been reserved to that common case. Changing this now is a no-go, of course. There are existing applications that use the above syntax to define relocatable schemas. I propose that we could bail ourselves out of this mess with a two-step process, as follows: 1) Start looking for a relocatable='' attribute on schema. If a schema has no path and has not been marked as relocatable='yes' then emit a warning (similar to what we do for path='/apps/*' already). 2) After a year or so, assume that schemas without relocatable='yes' and with no path='' are schemas that wish to have a path automatically assigned using the expected '.' to '/' mapping. In this way we turn: schema id='a.b.c' path='/a/b/c/' !-- common case -- schema id='x.y.z' !-- uncommon case -- to: schema id='a.b.c' !-- common case -- schema id='x.y.z' relocatable='yes'!-- uncommon case -- Even if we don't do #2, I think doing #1 might be useful. I don't have any evidence (even anecdotal) to support the idea that the current situation is confusing but it seems that a helpful warning explaining to the user that schema id='a.b.c' doesn't mean what they think may be useful... Thoughts? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: path= (or not) in GSettings schemas
On 12-10-17 12:17 PM, Matthias Clasen wrote: to fixedschema id='a.b.c' relocatableschema id='x.y.z' Seb mentioned a variation on this theme focusing on attribute names instead: schema pathid=... !-- same as fixedschema above -- My problem with these proposals is that schema and id are the natural names to use here and that people will find a lot of online help instructing them about that. It's also problematic from the standpoint of not wanting the entire world to have to change over to the 'new way' and not wanting to have two separate element/attribute names around forever. From a purely aesthetic standpoint I guess I could accept schema name=''... Then we could have schema name='a.b.c'/ schema name='x.y.z' relocatable='yes'/ and throw warnings if we ever see id=''... We could keep the warnings forever (ie: never have an incompatible change). I could see a lot of people being annoyed about that, though. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: runtime accel changes
hi, Thanks for the feedback. On 12-09-12 05:15 PM, Paul Davis wrote: On Wed, Sep 12, 2012 at 5:07 PM, Michael Natterer mi...@gimp.org wrote: I object. Do you really want to disable shortcut editors in complex applications such as GIMP? I echo Mitch's objections. Ardour users find it very convenient to do runtime changes to key bindings. Is there a usecase for users who regularly switch keybindings as part of their normal workflow, or is this a sort of customise the app once, then use it forever type of situation? Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
runtime accel changes
hi, I recently wrote a patch[1] to re-enable accel labels in GtkMenu generated from GMenuModel. They got lost in the shuffle during some related recent changes. Essentially, the new approach means that the accel='' attribute of each menuitem directly determines what the accel label will be (instead of doing the lookup in the accelgroup). The most noteworthy impact of the patch (and the topic of this email) is the strong implication that we will no longer support runtime changing of accel keys. It's my personal opinion that runtime changes to accels have resulted in some rather complicated code in Gtk and we'd be better off without this feature. Additionally, the feature is disabled by default for quite some time because enabling it results in lots of bug reports from confused users. In the future we will likely gain some sort of action-database/factory functionality (to replace the other half of GtkAction -- creating proxies). I imagine accels will be registered with this database at application initialisation time. I could see a hook (like a keyfile in ~/.config/ somewhere) that allows advanced users to adjust their accels. An app restart would be required. [1] https://bugzilla.gnome.org/show_bug.cgi?id=683738 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.33.10
GLib 2.33.10 has been released. This is a point release on the way to what will become 2.34.0. API additions at this point should be considered unstable although things should be fairly well frozen by now. As usual, you can download from http://download.gnome.org/sources/glib/2.33 6caf18eb963aa2c3c7c0dc63201021bc29e7972c60d191f566e8971af77e9505 glib-2.33.10.tar.xz Overview of changes from GLib 2.33.8 to 2.33.10 === * New GTest API for testcases where log output is expected: g_test_expect_message() * GMenuItem now has 'get' accessors and a construct-from-GMenuModel API * GVariant now has a function to check a format-string for type compatibility * win32: We now use overlapped IO to support multiple asynchronous operations (ie: reading and writing) at the same time. * GMappedFile: Add g_mapped_file_get_bytes() * The problems with g_file_make_directory_with_parents() should be resolved. * The long-standing issues with placeholder generation of manpages are now resolved. * gtlscertificate: Add GBytes based certificate and private-key props * build: Switch back to using AS_IF for conditionals * test coverage improvements, documentation improvements, leak fixes * Bugs fixed 326931 Better docs for G_GNUC_* 550433 g_test_init doesn't recognize --help 600751 GCompletion should better document if and how items memory is managed 628193 Miscellaneous string fixes 637460 man glib-genmarshal is hard to use 674483 broken configure results when cross-compiling with gcc = 4.5 677065 GMappedFile: Add g_mapped_file_get_bytes() 679288 win32: use overlapped events for streams 679556 it's hard to use gtest when g_warning() is expected 680823 g_file_make_directory_with_parents: Fix error propagation 681319 gtlscertificate: Add certificate-bytes and private-key-bytes props 681336 man pages not built if --enable-gtk-doc not specified 681413 build: Switch back to using AS_IF for conditionals 681501 gmem: array only partially filled with memcpy 681854 Documentation fix for Howto compile a program with glib 682025 Documentation correction 682067 Fix problems with CLEANFILES and automake-1.11.1 * Translations updated: Lithuanian Spanish Galician Telugu Serbian Assamese Marathi Indonesian Traditional Chinese Contributors to this release = Aurimas Černius Chao-Hsiung Liao Chun-wei Fan Colin Walters Daniel Mustieles Dan Winship David King Dirgita Fran Diéguez Javier Jardón Krishnababu Krothapalli Lars Uebernickel Marc-André Lureau Matthias Clasen Nilamdyuti Goswami Owen W. Taylor Ryan Lortie Sandeep Sheshrao Shedmake Sebastian Geiger Stef Walter Thomas Hindoe Paaboel Andersen Мирослав Николић Cheers ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.33.10
GLib 2.33.10 has been released. This is a point release on the way to what will become 2.34.0. API additions at this point should be considered unstable although things should be fairly well frozen by now. As usual, you can download from http://download.gnome.org/sources/glib/2.33 6caf18eb963aa2c3c7c0dc63201021bc29e7972c60d191f566e8971af77e9505 glib-2.33.10.tar.xz Overview of changes from GLib 2.33.8 to 2.33.10 === * New GTest API for testcases where log output is expected: g_test_expect_message() * GMenuItem now has 'get' accessors and a construct-from-GMenuModel API * GVariant now has a function to check a format-string for type compatibility * win32: We now use overlapped IO to support multiple asynchronous operations (ie: reading and writing) at the same time. * GMappedFile: Add g_mapped_file_get_bytes() * The problems with g_file_make_directory_with_parents() should be resolved. * The long-standing issues with placeholder generation of manpages are now resolved. * gtlscertificate: Add GBytes based certificate and private-key props * build: Switch back to using AS_IF for conditionals * test coverage improvements, documentation improvements, leak fixes * Bugs fixed 326931 Better docs for G_GNUC_* 550433 g_test_init doesn't recognize --help 600751 GCompletion should better document if and how items memory is managed 628193 Miscellaneous string fixes 637460 man glib-genmarshal is hard to use 674483 broken configure results when cross-compiling with gcc = 4.5 677065 GMappedFile: Add g_mapped_file_get_bytes() 679288 win32: use overlapped events for streams 679556 it's hard to use gtest when g_warning() is expected 680823 g_file_make_directory_with_parents: Fix error propagation 681319 gtlscertificate: Add certificate-bytes and private-key-bytes props 681336 man pages not built if --enable-gtk-doc not specified 681413 build: Switch back to using AS_IF for conditionals 681501 gmem: array only partially filled with memcpy 681854 Documentation fix for Howto compile a program with glib 682025 Documentation correction 682067 Fix problems with CLEANFILES and automake-1.11.1 * Translations updated: Lithuanian Spanish Galician Telugu Serbian Assamese Marathi Indonesian Traditional Chinese Contributors to this release = Aurimas Černius Chao-Hsiung Liao Chun-wei Fan Colin Walters Daniel Mustieles Dan Winship David King Dirgita Fran Diéguez Javier Jardón Krishnababu Krothapalli Lars Uebernickel Marc-André Lureau Matthias Clasen Nilamdyuti Goswami Owen W. Taylor Ryan Lortie Sandeep Sheshrao Shedmake Sebastian Geiger Stef Walter Thomas Hindoe Paaboel Andersen Мирослав Николић Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.33.3
GLib 2.33.3 has been released. This is a point release on the way to what will become 2.34.0. API additions at this point should be considered unstable. As usual, you can download from http://download.gnome.org/sources/glib/2.33 4ae2695dff7f075e746c5dbcbed9e5f7afb7b11918201dc8e82609a610db0990 glib-2.33.3.tar.xz Overview of changes from GLib 2.33.2 to 2.33.3 == This release contains mostly bugfixes, cleanups and performance improvements (including many fixes contributed by Colin on the advice of Coverity). There are a few notable externally-visible changes: * Thumbnails are now in XDG_CACHE_HOME * new GDBus API: per-thread g_dbus_connection_get_last_serial() * GUnixOutputStream now has a can_poll() implementation * New deep copy APIs for G(S)List: g_(s)list_copy_deep * Bugs fixed: 518309 Incorrect data*dir path in glib-gettextize output 566994 Safer passing of -framework flag 672889 GLib.utf8_validate does segfault 673253 Not strict enough autconf test for libelf 675024 adds g_list_copy_deep() and g_slist_copy_deep 675168 prepare for thumbnails to move to XDG_CACHE_HOME 675966 gresolver: More robust parsing of DNS responses 676594 [Patch] fix g_reload_user_special_dirs_cache 676825 Implement g_dbus_connection_get_last_serial () 677235 Clarify the comment at the top of gmarshal.list 677527 OS X: gthread/spawn-async selftest failure 677718 GDBusProxy: treat org.freedesktop.systemd1.Masked error as non-fatal 60 GUnixOutputStream does not implement can_poll 677782 Install bash completion files in /usr/share 677817 g_key_file_to_data adds extra blank lines in some cases 677952 Missing annotation for GDBusConnection signal closed 678052 g_wakeup_acknowledge is called too often. 678273 unicode othercasing is wrong in gregex 678333 gdbus-codegen code causes warnings under -Wfloat-equal * Translations updated: Arabic Assamese Galecian Greek Spanish Telugu Contributors since 2.33.2: Benjamin Otte Christian Persch Chun-wei Fan Colin Walters Daniel Macks Daniel Mustieles Dan Winship David Zeuthen Emmanuele Bassi Fran Diéguez Jonh Wendell Khaled Hosny Lars Uebernickel Martin Jansa Martin Pitt Matthew Barnes Matthias Clasen Murray Cumming Nilamdyuti Goswami Paolo Borelli Phil Clayton Ryan Lortie Sasi Bhushan Boddepalli Stefan Sauer Stef Walter Taomas Bzatek Tom Tryfonidis William Jon McCann ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.33.2
GLib 2.33.2 has been released. This is a point release on the way to what will become 2.34.0. API additions at this point should be considered unstable. As usual, you can download from http://download.gnome.org/sources/glib/2.33 b7163e9f159775d13ecfb433d67c3f0883e0e518e85b2e970d4ad9773d7cd0b4 glib-2.33.2.tar.xz Overview of changes from GLib 2.33.1 to 2.33.2 == * GLIB_VERSION_MIN_REQUIRED now defaults to the current stable version * GIO input and output stream classes have grown GBytes-based methods * GApplication now has hooks to register D-Bus objects before the bus name is taken * Bugs fixed: 605976 add g_type_ensure(), to ensure that a type has... 660851 Breakage of code due to changes in the GThread... 666386 Empathy doesn't open Redirect URI with particu... 671139 need (transfer async) for io stream buffers 672329 memory leaks in gutils.c and glib tests 672548 g_utf8_validate: @str shouldn't end up annotat... 674111 Provide an accessor for MimeType desktop entry... 674483 broken configure results when cross-compiling ... 674634 Add g_clear_pointer() 674777 What's the (transfer) of g_variant_lookup()? 675309 gkeyfile: Fix annotations for g_key_file_load_... 675446 gfile: Plug memory leak in g_file_make_directo... 675509 add extra dbus hooks 675832 Incomplete gsettings bash auto-completion 676208 The tmpl parameter to g_file_new_tmp can be NULL 676265 GNetworkMonitor leaks a lot of memory 676277 Document that g_app_info_create_from_commandli... 676397 g_environ_* should work with NULL envp 676398 g_spawn_* should take PATH from the passed env... 676478 Broken gzip decoding 676594 [Patch] fix g_reload_user_special_dirs_cache 676816 Add more GLIB_AVAILABLE_IN_* 676937 Document notify signal deduplication with free... * Translation updates: Czech French German Greek Japanese Russian Slovenian Spanish Thanks to: Bruno Brouard Christian Kirbach Christian Persch Chun-wei Fan Colin Walters Dan Winship Daniel Mustieles Debarshi Ray Dimitris Spingos Emmanuele Bassi Giovanni Campagna Guillaume Desmottes Holger Berndt Jasper St. Pierre Jiro Matsuzawa Krzesimir Nowak Lars Uebernickel Marc-Antoine Perennou Marek Černocký Matej Urbančič Michael Olbrich Paolo Borelli Philip Withnall Ravi Sankar Guntur Xavier Claessens Yuri Kozlov and to Matthias Clasen for preparing the NEWS. Cheers ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.33.2
GLib 2.33.2 has been released. This is a point release on the way to what will become 2.34.0. API additions at this point should be considered unstable. As usual, you can download from http://download.gnome.org/sources/glib/2.33 b7163e9f159775d13ecfb433d67c3f0883e0e518e85b2e970d4ad9773d7cd0b4 glib-2.33.2.tar.xz Overview of changes from GLib 2.33.1 to 2.33.2 == * GLIB_VERSION_MIN_REQUIRED now defaults to the current stable version * GIO input and output stream classes have grown GBytes-based methods * GApplication now has hooks to register D-Bus objects before the bus name is taken * Bugs fixed: 605976 add g_type_ensure(), to ensure that a type has... 660851 Breakage of code due to changes in the GThread... 666386 Empathy doesn't open Redirect URI with particu... 671139 need (transfer async) for io stream buffers 672329 memory leaks in gutils.c and glib tests 672548 g_utf8_validate: @str shouldn't end up annotat... 674111 Provide an accessor for MimeType desktop entry... 674483 broken configure results when cross-compiling ... 674634 Add g_clear_pointer() 674777 What's the (transfer) of g_variant_lookup()? 675309 gkeyfile: Fix annotations for g_key_file_load_... 675446 gfile: Plug memory leak in g_file_make_directo... 675509 add extra dbus hooks 675832 Incomplete gsettings bash auto-completion 676208 The tmpl parameter to g_file_new_tmp can be NULL 676265 GNetworkMonitor leaks a lot of memory 676277 Document that g_app_info_create_from_commandli... 676397 g_environ_* should work with NULL envp 676398 g_spawn_* should take PATH from the passed env... 676478 Broken gzip decoding 676594 [Patch] fix g_reload_user_special_dirs_cache 676816 Add more GLIB_AVAILABLE_IN_* 676937 Document notify signal deduplication with free... * Translation updates: Czech French German Greek Japanese Russian Slovenian Spanish Thanks to: Bruno Brouard Christian Kirbach Christian Persch Chun-wei Fan Colin Walters Dan Winship Daniel Mustieles Debarshi Ray Dimitris Spingos Emmanuele Bassi Giovanni Campagna Guillaume Desmottes Holger Berndt Jasper St. Pierre Jiro Matsuzawa Krzesimir Nowak Lars Uebernickel Marc-Antoine Perennou Marek Černocký Matej Urbančič Michael Olbrich Paolo Borelli Philip Withnall Ravi Sankar Guntur Xavier Claessens Yuri Kozlov and to Matthias Clasen for preparing the NEWS. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.32.2 released
GLib 2.32.2 is now available for download at: http://download.gnome.org/sources/glib/2.32 b1764abf00bac96e0e93e29fb9715ce75f3583579acac40648e18771d43d6136 glib-2.32.2.tar.xz This is a stable point release for the 2.32 series and contains no new major features. There are some minor new features and a few bug fixes. See below. Overview of changes from GLib 2.32.1 to 2.32.2 == * GApplication: can now have a NULL application ID * g_clear_object: fix warnings when using it on C++ (due to lack of ability to implicitly cast void*) * GDBus: - add our own implementation of the message bus for use on Windows only - fix up a few bugs that use of this bus uncovered in GDBus - escape nonce files in dbus addressess (think 'c:\') - support initial underscores in dbus codegen namespace (for private) * Fix misdetection of GNUstep as Cocoa (for the MacOS GSettings backend) * make sure configure fails if AC_CHECK_ALIGNOF cannot detect the alignment * GAppInfo: overwrite the DISPLAY only if it is set in the launch context * glib/tests/date: force US locale running the GDateTime tests * GSocketControlMessage: Don't warn about unknown messages * Resources: - fix broken use of GVDB on big endian machines - set a 'display name' so that pretty file names appear in Gtk CSS warning messages * GMainContext: - block child sources when blocking the parent - introduce more testcases for child sources * Translations updates: Brazilian Portuguese French Galician Italian Lithuanian Polish Polish Serbian Simplified Chinese Spanish * Bug fixed: 619026 avoid warning in gutils.h when using gcc with -Wconversion 669260 Open/Save dialog hangs waiting for data with libsoup 671249 GApplication: Allow a null application_id? 672786 goa-daemon: action in notification doesn't work 673409 g_resource_lookup_data may return stale data pointer 674172 glib-2.32.1 misdetects GNUstep as Cocoa 674345 cssprovider: Make sure to print out file name in css warnings 674483 broken configure results when cross-compiling with gcc = 4.5 Thanks to those who contributed to this release Alexander Larsson Alexandre Rostovtsev Aurimas Černius Benjamin Otte Bruno Brouard Christian Persch Chun-wei Fan Colin Walters Cosimo Cecchi Dan Winship Daniel Mustieles David Zeuthen Debarshi Ray Fran Diéguez Hannes Mueller Jonh Wendell Kalev Lember Luca Ferretti Matthias Clasen Michael Olbrich Piotr Drąg William Hua Xavier Claessens Yinghua Wang Мирослав Николић Cheers ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.32.2 released
GLib 2.32.2 is now available for download at: http://download.gnome.org/sources/glib/2.32 b1764abf00bac96e0e93e29fb9715ce75f3583579acac40648e18771d43d6136 glib-2.32.2.tar.xz This is a stable point release for the 2.32 series and contains no new major features. There are some minor new features and a few bug fixes. See below. Overview of changes from GLib 2.32.1 to 2.32.2 == * GApplication: can now have a NULL application ID * g_clear_object: fix warnings when using it on C++ (due to lack of ability to implicitly cast void*) * GDBus: - add our own implementation of the message bus for use on Windows only - fix up a few bugs that use of this bus uncovered in GDBus - escape nonce files in dbus addressess (think 'c:\') - support initial underscores in dbus codegen namespace (for private) * Fix misdetection of GNUstep as Cocoa (for the MacOS GSettings backend) * make sure configure fails if AC_CHECK_ALIGNOF cannot detect the alignment * GAppInfo: overwrite the DISPLAY only if it is set in the launch context * glib/tests/date: force US locale running the GDateTime tests * GSocketControlMessage: Don't warn about unknown messages * Resources: - fix broken use of GVDB on big endian machines - set a 'display name' so that pretty file names appear in Gtk CSS warning messages * GMainContext: - block child sources when blocking the parent - introduce more testcases for child sources * Translations updates: Brazilian Portuguese French Galician Italian Lithuanian Polish Polish Serbian Simplified Chinese Spanish * Bug fixed: 619026 avoid warning in gutils.h when using gcc with -Wconversion 669260 Open/Save dialog hangs waiting for data with libsoup 671249 GApplication: Allow a null application_id? 672786 goa-daemon: action in notification doesn't work 673409 g_resource_lookup_data may return stale data pointer 674172 glib-2.32.1 misdetects GNUstep as Cocoa 674345 cssprovider: Make sure to print out file name in css warnings 674483 broken configure results when cross-compiling with gcc = 4.5 Thanks to those who contributed to this release Alexander Larsson Alexandre Rostovtsev Aurimas Černius Benjamin Otte Bruno Brouard Christian Persch Chun-wei Fan Colin Walters Cosimo Cecchi Dan Winship Daniel Mustieles David Zeuthen Debarshi Ray Fran Diéguez Hannes Mueller Jonh Wendell Kalev Lember Luca Ferretti Matthias Clasen Michael Olbrich Piotr Drąg William Hua Xavier Claessens Yinghua Wang Мирослав Николић Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk threads ...
hi Michael, On Mon, 2012-03-05 at 12:11 +, Michael Meeks wrote: Does that mean you're removing gdk_threads_enter and leave and the semantics around that ? is there some cunning new scheme proposed to intercept the mainloop and ensure that events / idle / timeout emissions hooked in by the toolkit can have applications add lock/unlock pairs ? We're not removing -- only deprecating. The removal will come in GTK4. There will be no replacement functionality -- you will just be expected to do all your interaction with the toolkit from the main thread (ie: dispatching results via idles). Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.31.18
Live from the Czech Republic, it's GLib 2.31.18! This release is an unstable release on the way to 2.32.0. http://download.gnome.org/sources/glib/2.31/ 1ce3d275189000e1c50e92efcdb6447bc260b1e5c41699b7a1959e3e1928fbaa glib-2.31.8.tar.xz This release is aimed at being used as part of GNOME 3.3.90. You will need this to build the just-released Gtk+ 3.3.16. Overview of changes from GLib 2.31.16 to 2.31.18 * GDBusProxy has now a flag, G_DBUS_PROXY_FLAGS_GET_INVALIDATED_PROPERTIES, which can be set to make GDBus automatically reload changed properties even if the propertychanged signal does not contain the new values. * GApplication puts non-unique applications on the bus * GApplication now has g_application_quit() * g_async_queue_timed_pop has been deprecated in favor of the new g_async_queue_timeout_pop, which uses relative delays in microseconds instead of a GTimeVal. * a huge number of API documentation fixes * Bugs fixed: 647986 put non-unique apps on D-Bus 658484 vpn connection vs NetworkSecretDialog 664237 GDateTime falls back to UTC if TZ is set 669329 gthread-win32: update for g_get_monotonic_time() changes 669330 glocalfile: fix error code when opening a directory on win32 669372 glib/tests memory leaks. 669412 mem leak in g_environ_unsetenv 669538 Fix compilation of glib-compile-resources.c on Windows 669544 gdbus-codegen example introspection XML is not complete 669595 glib-mkenums: fix handling of forward enum declarations 669670 gasyncqueue: don't use deprecated g_cond_timed_wait() 669671 gobject: use #pragmas to avoid deprecated function warnings 669689 Retrieve cwd and environ in local GApplicationCommandLine 669810 socket/win32: flush pending read before signaling HUP 669865 g_regex_fetch() 670085 memory leak in g_output_stream_write_async 670138 gbytes.h is missing the G_BEGIN/END_DECL guards 670485 Simplify session API (shared bug with gtk+) * Updated translations: Belarusian Danish Galician Serbian Telugu Hebrew Thanks to the contributors to this release: Ask H. Larsen Christian Persch Christophe Fergeau Chun-wei Fan Dan Winship Daniel Mustieles David King David Zeuthen Fran Diéguez Giovanni Campagna Javier Jardón Jesse van den Kieboom Kasia Bondarava Kjartan Maraas Luca Ferretti Marc-André Lureau Matthias Clasen Murray Cumming Peter Kjellerstedt Ravi Sankar Guntur Richard Hughes Swecha Localization Team Yaron Shahrabani Мирослав Николић Cheers ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.31.18
Live from the Czech Republic, it's GLib 2.31.18! This release is an unstable release on the way to 2.32.0. http://download.gnome.org/sources/glib/2.31/ 1ce3d275189000e1c50e92efcdb6447bc260b1e5c41699b7a1959e3e1928fbaa glib-2.31.8.tar.xz This release is aimed at being used as part of GNOME 3.3.90. You will need this to build the just-released Gtk+ 3.3.16. Overview of changes from GLib 2.31.16 to 2.31.18 * GDBusProxy has now a flag, G_DBUS_PROXY_FLAGS_GET_INVALIDATED_PROPERTIES, which can be set to make GDBus automatically reload changed properties even if the propertychanged signal does not contain the new values. * GApplication puts non-unique applications on the bus * GApplication now has g_application_quit() * g_async_queue_timed_pop has been deprecated in favor of the new g_async_queue_timeout_pop, which uses relative delays in microseconds instead of a GTimeVal. * a huge number of API documentation fixes * Bugs fixed: 647986 put non-unique apps on D-Bus 658484 vpn connection vs NetworkSecretDialog 664237 GDateTime falls back to UTC if TZ is set 669329 gthread-win32: update for g_get_monotonic_time() changes 669330 glocalfile: fix error code when opening a directory on win32 669372 glib/tests memory leaks. 669412 mem leak in g_environ_unsetenv 669538 Fix compilation of glib-compile-resources.c on Windows 669544 gdbus-codegen example introspection XML is not complete 669595 glib-mkenums: fix handling of forward enum declarations 669670 gasyncqueue: don't use deprecated g_cond_timed_wait() 669671 gobject: use #pragmas to avoid deprecated function warnings 669689 Retrieve cwd and environ in local GApplicationCommandLine 669810 socket/win32: flush pending read before signaling HUP 669865 g_regex_fetch() 670085 memory leak in g_output_stream_write_async 670138 gbytes.h is missing the G_BEGIN/END_DECL guards 670485 Simplify session API (shared bug with gtk+) * Updated translations: Belarusian Danish Galician Serbian Telugu Hebrew Thanks to the contributors to this release: Ask H. Larsen Christian Persch Christophe Fergeau Chun-wei Fan Dan Winship Daniel Mustieles David King David Zeuthen Fran Diéguez Giovanni Campagna Javier Jardón Jesse van den Kieboom Kasia Bondarava Kjartan Maraas Luca Ferretti Marc-André Lureau Matthias Clasen Murray Cumming Peter Kjellerstedt Ravi Sankar Guntur Richard Hughes Swecha Localization Team Yaron Shahrabani Мирослав Николић Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gir stability
It seems like we've been avoiding talking about this particular issue for a while, but I think it's time we got a bit more serious about it. https://bugzilla.gnome.org/show_bug.cgi?id=657385 This bug introduced a 'Rename to:' field on gtk_menu_popup_for_device(), which of course, is an API change of sorts. We've all made (or ACKed) changes like this in the past so there's not a lot of blame to assign here (other than to all of us). What makes this particular incident of note is that popup_for_device() existed in Gtk 3.2 and was bound as such. Python applications[1] started using it, and then, with this commit, it disappeared. We need to figure out what our story is with respect to annotations. 'Rename to:' is an extreme example (since an entire function, as named, disappears) but we can easily cause problems just as serious with changes that look a lot more innocent (like changing array length parameters or such). We can even break vala bindings with the introduction of an (allow none). On one extreme, do we say that we don't care about providing a stable API to users of our bindings at all? On the other hand, do we go as far as to guarantee bugs-compatible behaviour between our stable releases of introspection bindings? It's pretty clear that we can't continue along ignoring the issue as we have been so far... Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gir stability
On Tue, 2012-01-31 at 14:40 -0500, Ryan Lortie wrote: existed in Gtk 3.2 and was bound as such. Python applications[1] Sorry: [1] https://bugs.launchpad.net/bugs/923171 (Ubuntu software centre) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkBuilder GMenu changes
hi, I was quite fond of the XML format originally used by GMenu because it allowed for a relatively concise expression of the menus in your application. It turned out that this format didn't jive well with the rest of GtkBuilder and, particularly, the tools that we use to extract translations from our XML file formats. For this reason, the format has been changed to be brought more into line with how the rest of GtkBuilder works. In doing so, I also moved the code of the parser itself into Gtk and made it private (only to be called by GtkBuilder). The GLib API for parsing menus will soon disappear. When it does, you will have to ensure that you have the new version of GTK installed. I apologise for making this change after many people have probably already written their menus in the old format. To mitigate the inconvenience, I wrote a small XSLT program that should help with the process of converting to the new format. Commit: http://git.gnome.org/browse/gtk+/commit/?id=eed307713b8ef4da5e4edf0aa8d85aa5c32a6d4f Bug: https://bugzilla.gnome.org/show_bug.cgi?id=668696 XSLT program: http://bugzilla-attachments.gnome.org/attachment.cgi?id=206142 Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Bug 666728 - critical warning in libgee
hi Maciej, Thanks for bringing up this topic. I'm not exactly sure what the proper way forward is, but you raise some interesting possibilities. On Thu, 2012-01-05 at 01:32 +0100, Maciej Marcin Piechotka wrote: I don't think I can fix on libgee side without breaking API/ABI (at least I don't see it). I believe that because currently various GNOME applications depends on libgee it means that bug effectively breaks GNOME (by breaking for example gnome-shell or empathy). I talked to Jürg a bit about this problem and I think he decided that the appropriate thing to do would be to modify Vala to prevent Gee from doing this in the first place. - Treating g_object_interface_install_property as override property if interface have prerequisite I think this wouldn't help. The problem comes from the fact that two separate interfaces are defining a property with the same name and different types (so far so good) and then a class tries to implement both interfaces (one directly and one by inheritance). Boom. What we could do is to try to step up the intelligence in GObject about *which* property to override to pick the more-compatible type. I resist this because it's not simple and because in the event that you have two properties with the same name, why should we arbitrarily pick one over the other at all? Even if the types are compatible, we still have (admittedly small) questions about things like which description string we want to end up with. That might be a small practical concern, but it gives me a distinct feeling of this is icky I think we should possibly consider being *more* strict in this area: if there are two possible properties of the same name that you could be overriding then g_object_class_override_property() should probably fail. - Change Vala to use g_object_class_install_property(s) instead of g_object_class_override_property. I think this would be pretty reasonable. Vala has enough information to be able to pick the correct information to register the property with, from scratch. It could also give a meaningful compile time error if it's not possible to reconcile the types in a way that works with the access flags of each of the properties. - Change error into warning, remove it from libgee 0.7/0.8 and change back into error when the old software die. It's just a critical now, so nothing should die. I suppose we could downgrade that to a warning if you're worried about people running with fatal criticals. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.31.6
GLib 2.31.6 was just released. This release is an unstable release on the way to 2.32.0. It is intended for use with the GNOME 3.3.3 release and is needed to build Gtk+ 3.3.6, which will be released soon. You can grab it from the usual place: http://download.gnome.org/sources/glib/2.31/ 26f082d3dfa017c73049a7f09333dd2114abd32849fd601394e35f4f8b34e49a glib-2.31.6.tar.xz Overview of changes from GLib 2.31.4 to 2.31.6 == * GApplication no longer has APIs for setting menus. Those have been moved to GtkApplication. * the GActionGroup import/export functionality has been decoupled from GApplication by the introduction of a new interface for the purpose of handling platform data: GRemoteActionGroup. This allows Gtk to properly deal with platform data (and gdk threads) on window actions. * lots of documentation improvements * bug fixes and a huge number of memory leak fixes * the test suite now passes on ARM and some of the GDBus testcase hangs we've been seeing have been resolved (although others could remain) * g_bytes_get_data() API changed: now includes 'size' out parameter * new g_queue_free_full() API similar to g_[s]list_free_full() * desktop files: use standard Keywords now, not X-GNOME-Keywords * gsettings commandline tool now has --schemadir option for schemas not installed in the usual place (ie: as part of plugins) * Bugs fixed: 643736 GApplication doesn't emit dbus signals on action updates 657433 g_queue_free_full() missing 664699 glib: documentation fixes 665737 acquire/release gdk threads lock on incoming dbus 665879 GBytes: add a size argument to g_bytes_get_data 666113 various leaks in GLib, GIO are visible in the regression tests 666115 various tests leak memory, obscuring real leaks in the library 666145 Doc could be more explicite that g_thread_init calls can be droped 666173 Configure warning - linux/netlink.h usability... no 666296 Race condition in g_thread_xp_get_srwlock 666415 Settings tools should allow specifying a schema directory * Translations updated: French Spanish Thanks to those who helped: Alexandre Franke Chris Coulson Christophe Fergeau Chun-wei Fan Colin Walters Dan Winship Daniel Mustieles Florian Müllner Giovanni Campagna Matthias Clasen Ravi Sankar Guntur Simon McVittie Stef Walter Cheers ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.31.4
GLib 2.31.4 is out.
This is a point release on the way to what will become GLib 2.32.0.
http://download.gnome.org/sources/glib/2.31/
627fbffdb0c0a95709778e54ab32620d3e4ae9dfed939bb69ab4a50209ff43fb
glib-2.31.4.tar.xz
Overview of changes from GLib 2.31.2 to 2.31.4
==
* EXPERIMENTAL: Menu support has been added to GApplication. Menus
are exported on the bus, alongside the actions that are already there.
There have also been many related improvements to action group
functionality.
These new APIs are subject to changes in the coming releases. In
particular, it seems somewhat likely that the APIs for registering
menubars may change in order to accommodate windows with different
types of menubars.
* GDBusConnection previously directly dispatched destroy notifies when
unregistering objects if the current main context was the same context
the object was exported on. It now unconditionally dispatches these
through an idle on the context.
* Clean up Requires in pc files. Linking against GIO no
longer drags in gmodule. This may require dependency
fixes here and there.
* Introduce GBytes, a data type for immutable, fixed-size
byte sequences. This makes the pre-existing GBuffer
API available outside GLib
* GDBusInterfaceSkeleton can now be exported on multiple
connections
* Bugs fixed:
600161 Do not use static GTypeInfo and GInterfaceInfo
640077 GFileMonitor: Always send CHANGES_DONE_HINT after a move...
641720 Misleading definition for local_command_line() in GApplic...
648516 Little comment error and 2 useless lines of code
651997 Dummy backend for gapplication
652560 Test for g_ascii_strtod is failing
662208 failure to initialize a GInitable should be considered...
662718 GDBusInterfaceSkeleton should be able to export on multi...
663291 GBytes: Immutable, refcounted sequence of bytes
664406 Need context for a proper translation
664455 Build fixes for GLib GIT master (2.31.x)
664558 GDBusWorker.frozen has a value 1 in a gboolean
664559 sys/wait.h not available on windows
664617 gdbus segfault error 4 in libgio-2.0.so.0.3102.0
664635 GMemory{Out,In}putStream _async functions break sub-class...
664809 Add command line option to gtester to allow skipping tests
665067 cryptic assertion failure if nonsensical flag combinations...
665184 Check ref. count before reffing/unreffing
665298 Add 'Requires.private: libpcre' to glib-2.0.pc
665391 update documentation around mainloops
665607 ./configure is there for fiddling with cross-compile enviro...
665634 g_dbus_node_info_new_for_xml() errors on unknown attributes...
665685 Add a #define for the max length of a Unicode decomposition
665733 GDBusConnection holds lock while calling destroynotify
* Translation updates:
Hebrew
Korean
Norwegian bokmål
Spanish
Thanks to the contributors to this release:
Aleksander Morgado
Behdad Esfahbod
Benjamin Otte
Carlos Garcia Campos
Colin Walters
Cosimo Alfarano
Daniel Mustieles
Dan Winship
David Zeuthen
Kjartan Maraas
Matthias Clasen
Michael Vogt
Nicola Fontana
Philip Withnall
Piotr Drąg
Rico Tzschichholz
Sam Thursfield
Seong-ho, Cho
Simon McVittie
Stef Walter
Thomas Hindoe Paaboel Andersen
Tristan Van Berkom
Yaron Shahrabani
Cheers
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GMenuModel has landed
hi, On Fri, 2011-12-09 at 14:39 +0100, Nacho wrote: just one thing that I don't have quite clear... how will the extensibility be managed for the menus? i.e adding a new menuitem from a plugin. If the plugin can gain access to the GMenu then it can modify it (adding/removing items, etc). In some ways this could be easier because of how 'sections' work in GMenu -- any menu (including the menubar) can be composed of multiple sections that are merged together. If the plugin can gain access to the GApplication and/or GtkApplicationWindows then it can add its actions there, as well. No word on namespacing of actions or easy ability to remove all menuitems/actions that were added by a particular plugin, though. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
On Fri, 2011-12-09 at 09:50 +0100, Alexander Larsson wrote: Windows actually has an application menu thing. If you right-click on the application on the panel you can get app-specific operations in the menu. I'm not sure if the normal usecase for these match what the app menu is typically used for though. Is this the so-called jumplist? It sounds more likely that we'd treat this as a 3rd type of menu -- since the shell, unity and mac os all have this same concept these days as well... Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
hi Tristan, Thanks for the questions. On Fri, 2011-12-09 at 14:56 +0900, Tristan Van Berkom wrote: I think that the (twice) mentioned solution to this problem sounds elegant enough, i.e. if you have 2 windows with different menubars then they can easily be '2 applications' at least in terms of data sets. However, I'm curious as to how elegantly one can implement this. Not elegantly, presently. It's theoretically possible to have two GApplication instances in the same process, but 'running' them at the same time (so that the lifecycle of the process is tied to the lifecycle of either app) looks a bit weird and may actually be impossible. That's an API fix needed in GApplication, to be sure. There are also apparently some nasty races involved with trying to use two names for uniqueness on D-Bus related to how activation works. Add those to the normal hazards you have with holding two locks... Also, I'm still concerned about GApplication, I raised this point last year and I wonder if any progress has been made... what is the fallback ? Can g_application_run() please at the very minimum fall back on calling g_main_loop_run() when there is no D-Bus daemon ? Since last year, the situation has improved in two substantial ways: - we introduced the concept of non-unique applications that don't attempt to acquire D-Bus names - we made it so that if the D-Bus daemon isn't available, the application just continues along as a normal program without checking for uniqueness, exporting its actions, etc. In the future we hope to write better 'native' backends for Windows and Mac that do more than just ... nothing. If I write an application with this abstract GMenu model and then run it on a system that by no means has any need to run a D-Bus daemon, nor any need to run a window manager, or has a window manager that is not GMenu aware at all, what happens ? See above for the D-Bus thing, but as mentioned in my original email, we now have two booleans in GtkSettings that are manipulated by gnome-settings-daemon (ie: same delivery mechanism as the choice of theme) and control if the menu is shown in the local process. By default, the menu is shown, so it is only hidden if the desktop shell has explicitly indicated that it will show it. Can the menu bar automatically display using a basic GtkMenuBar in the main GtkApplicationWindow... when there is no D-Bus daemon running ? Yes. This is exactly what happens. Also... concerning MVC menus in general: Can this whole GMenuModel and GMenu thing be extendable without modifying GTK+ sources at all ? In my imagination, all I have to do is: - Implement menus to understand an extra property name i.e. implement the view, by deriving a GtkMenuItem with widgets to represent that data - Create the data model from my application and assign this extra property name a value, perhaps is-range = TRUE and range-value = 50 - Bingo, all of a sudden I'm using my new GtkScaleMenuItem with an embedded GtkHScale and it's value preset to 50 Indeed, Canonical has extensive plans to do this. They use menus for their indicators in the top-right of the screen and they have all manner of interesting widgetry up there (including a range widget for volume). One side note that your example brings up: it is not possible to modify a menu item after it has been created. For this reason, you would never see range-value='50'. Rather, you'd associate the range with a GAction that has a floating-point (or int) state, which would provide two-way synchronisation with the application. Back to the extendablity question: I've played with this before and come up with a semi-reasonable system to support it. There would be a type='' attribute added to menuitems. If this attribute was present on the item then Gtk would attempt to open a dynamic module of a given name from a particular directory. type='foo' might hit /usr/lib/gtk-3.0/modules/libgmenu-foo.so for example. That would be a module/extension-point/etc that implements a factory interface for creating menuitems of your required type. So that's the good news -- if you're a desktop environment. The bad news is this: I don't expect this to be supported on a per-application basis or to be possible to use at all from the menubars of an application. We need to make sure menus will continue to work on all platforms (including the mac and unity -- which will both display your menus in a different place, not even using Gtk in the case of the mac). This means that you will only be able to use a minimum baseline level of functionality (labels, checks, radios, accels, icons, etc.) in the normal menubar and application menu of your program. What this base level of functionality is has yet to be written down -- and is not entirely known. It's something that I hope to come to grips with as we proceed towards the stable release. Cheers
Re: GMenuModel has landed
hi Jannis, On Fri, 2011-12-09 at 15:34 +0100, Jannis Pohlmann wrote: I guess this is unrelated but I have a question regarding extensions as well. Will there be functionality similar to GtkUIManager-based merging with placeholders in the GTK part of GMenu? We use this heavily in Thunar to allow plugins to specify items for file/folder context menus (and also for the window's File menu). The way this works is with questions. Take this as an example that I've tossed around a lot: menu id='menubar' submenu label='_File' section item label='_New' action='app.new'/ item label='_Open' action='app.open'/ item label='_Save' action='win.save'/ item label='_Print' action='win.print'/ /section section id='recent-documents'/ section item label='_Close' action='win.close'/ item label='_Quit' action='app.quit'/ /section /submenu ... /menu Then you can feed that XML into a GtkBuilder. Later, you can do this: GMenu *menu = G_MENU (gtk_builder_get_object (builder, recent-documents)); and begin appending items to that menu. Note that Gtk automatically introduces separators between the sections at the toplevel (but not sections nested within sections). In a similar form, you could introduce empty 'plugin area' sections into your menus (or even the menubar -- but no separators there, of course) that the plugins could insert their items into, in section form. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
On Fri, 2011-12-09 at 09:56 -0500, Ryan Lortie wrote: The way this works is with questions. Uhm. *sections. Don't write email while trying to have a conversation at the same time, kids :) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
hi, On Fri, 2011-12-09 at 09:58 -0500, Shaun McCance wrote: I find it extremely unfortunate that GTK+ will be restricted to using the least common denominator. That's the kind of thing you get from wrapper libraries like wxWidgets. In particular, from what I can tell, it means the searchable help menu work I did will be entirely impossible to rebase on this. Although do note that Mac OS has had that exact functionality for years. On Fri, 2011-12-09 at 09:14 -0500, Ryan Lortie wrote: What this base level of functionality is has yet to be written down -- and is not entirely known. It's something that I hope to come to grips with as we proceed towards the stable release. I encourage you to investigate how it is possible to do this in a way that will work for everyone and request changes/improvements to GMenu. As far as I'm concerned, nothing is written in stone yet. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
hi, On Fri, 2011-12-09 at 11:12 -0500, Morten Welinder wrote: Will the new api allow one to write a gui that looks and feels like it was made with the old api? Yes. Simply provide a menubar and no application menu and use GtkApplicationWindow. You will get the menubar added for you automatically with the additional benefit that it works properly on the mac and unity (without the current menubar-stealing/hiding hacks). Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
hi, On Fri, 2011-12-09 at 16:07 +0100, Steve Frécinaux wrote: Do you plan on/Would the current Gmenu infrastructure allow something like the mockups in [1] ? Especially, menus like the Mega-menu mockup for EoG adding a dropdown menu in the title bar [2] would seem to be feasible server-site, but what about the rest ? We had a plan to introduce a GtkApplicationMenuButton as an alternative to the gnome-shell application menu in order to display that menu. The way GMenu is constructed is rather extremely generic: each item is just a list of attributes plus (optionally) links to other GMenus. You can imagine quite a lot of ways that this could be used to construct menus like those in the mockups. I expect that the sort of things we see in the mega-menu examples are things that might actually be appropriate for inclusion in the shell application menu as well. Unlike the menubars, I do expect that some 'more interesting' things will eventually want to go on there. I think what needs to happen before we commit to anything is that we have firm design mockups. At that point, we can ask ourselves okay. what do we need to do to support this? Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GMenuModel has landed
hi, Today I landed the GMenuModel work on glib master. A release will be following shortly. There is related work in the 'wip/gmenu' branch of Gtk+ that will hopefully be landing soon. There is a trivial example in gtk+/examples/bloatpad.c that demonstrates some of the ideas here. The main thing to understand about this work is that we are changing how menus work in Gtk+. The days of constructing a GtkMenuBar widget and packing it into a VBox at the top of your window are gone. GMenuModel is an interface to describe the content of a menu and GMenu is its obvious implementation (think GtkTreeView vs. GtkTreeStore). Your application will construct a series of interlinked GMenu instances to describe the content of your menus. Fortunately, there is an XML parser to do this automatically. It is integrated with GtkBuilder. Providing the menu in abstract form instead of GtkWidget form addresses a few long-standing issues in Gtk. The most notable one is that we will finally have proper support for the menubar on the mac. Menubars are no longer a per-window concept. They are now set for the entire application. This is done for two reasons: 1) every app already has the same menubar (content) in each window 2) this is how the mac universe operates The API to set the menubar for the application is, unsurprisingly: void g_application_set_menubar (GApplication *application, GMenuModel *menubar); A new type of menu has also been introduced: the application menu. This is the menu that gnome-shell currently only has a Quit item in. Your application can now control the contents of this menu by whipping up a GMenu and setting it: void g_application_set_app_menu (GApplication *application, GMenuModel *app_menu); We may add other types of menus in the future. A jumplist/dock menu comes to mind. GMenuModel is a strictly read-only API. It describes the structure of a menu, but has no support for invoking actions when items in the menu are clicked. This is handled through the already-existing (but now improved) GActionGroup API. When creating a menu item, you specify an action name. This looks like app.preferences or win.fullscreen. The part before the dot is the location of the action (in this case the hard-coded strings app and win refer to app-wide and window-specific actions, respectively). For example: item label='_Quit' action='app.quit'/ Clicking this menu item would result in the 'quit' action being invoked on your GApplication. There is a new GActionMap interface that GApplication now implements. It can be used to easily add actions to your GApplication. Gtk also has a new class called GtkApplicationWindow that implements GActionMap. That's where the win. actions go. Even though the menu is globally-specified at the level of the application, the actions are correctly routed to the appropriate window automatically. There are two new XSettings properties that have been added to gnome-settings-daemon that specify if the shell will show the application menu or the menubar. These values have hard-wired defaults on non-X platforms. shows-app-menu shows-menubar gnome-shell: yes no GNOME 2: no no unity:yes yes mac os: yes yes If a particular desktop environment doesn't show a menu then it will be displayed at the top of each GtkApplicationWindow associated with that application. For example, on gnome-shell, the menubar set with g_application_set_menubar() will be at the top of each window, but on the mac, it will be at the top of the screen. We're currently open to making changes to the APIs, so please check them out and give feedback, but remember that they may change. If you have questions about how to use something, please reply here and I'll answer it for the benefit of all. I hope to use the contents of this thread as the basis for writing some introductory material on the topic. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
hi, On Fri, 2011-12-09 at 01:34 +0100, Andrea Bolognani wrote: Does this mean different windows belonging to the same application will not be able to have different per–window menubars? I’m thinking about Empathy here, with its Buddy List and Conversation windows having different menubars, but it’s not an uncommon scenario. I guess a reasonable question to ask here is what empathy would look like if it were an application designed for mac os. If people ask for it, I'm open to adding the ability to override menus on a per-window basis, but it will be strongly recommended against. I think a possible way of dealing with this would be to treat the contact list and the chat windows as two separate applications -- it almost seems that way these days anyway, with the messaging integrated into the shell. I assume Windows will behave like GNOME 2 here. In the GNOME 2 case, is the app menu collapsed with the menubar somehow? Correct assumption. In the case that nobody is showing the application menu, an Application item is added to the left of whatever would have otherwise been the first item in the menubar. If there is no menubar, then you end up with a menubar with an Application menu and nothing else. We're trying to decide what the best name for this menu should be. Possibly it should be the same as the name of the application. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GMenuModel has landed
hi, On Thu, 2011-12-08 at 19:24 -0800, John Ralls wrote: I think that you misunderstand how mac os works. Yes, a single menu bar is displayed at the top of the screen. This is correct behavior according to Fit's Law, because you can bang the pointer to the top of the screen and it can't overshoot. No, applications are not limited to having a single menu bar. It's a one-liner to switch menubars when different window (or notebook tab, for that matter) gets focus. This is obviously true from the fact that an application can detect which window has focus and the fact that the items in a menu can be changed, but it has to be done manually and is exceedingly uncommon in native mac os applications. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GObjectClass.dispose and bringing objects back to life
On Thu, 2011-12-01 at 19:26 +, Simon McVittie wrote: Hi, I've been looking into the details of how GObjects are destroyed, hoping to solve https://bugzilla.gnome.org/show_bug.cgi?id=665211, in which disposing a global singleton GDBusConnection in one thread races with reffing and using it in another thread, causing resurrection and a crash if both happen. (Advice from GObject gurus on that bug would be very much appreciated.) See https://bugzilla.gnome.org/show_bug.cgi?id=548954 for pretty much the same issue. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.31.2
GLib 2.31.2 is out. This is a point release on the way to what will become GLib 2.32.0. http://download.gnome.org/sources/glib/2.31/ 19d7921671a487c3c5759a57df7b8508afdbadd7764d62a47a82fff7b399032b glib-2.31.2.tar.xz Overview of changes from GLib 2.31.0 to 2.31.2 == * Monotonic time is now properly supported on Windows * glib-mkenums: fix @ENUMPREFIX@ with /* underscore_name=... */ * EXPERIMENTAL: introduce new GSettingsSchema and GSettingsSchemaSource APIs for the convenience of plugin system authors and those who wish to introspect the contents of schemas. This API may change. * Improve the performance of GObject property notifies. * GDBus: - fix a race when unowning a name immediately after owning it - thread safety improvements on GDBusConnection - fixes for exit-on-close functionality * Deprecations: - add G_SIGNAL_DEPRECATED - don't use G_DISABLE_DEPRECATED masking for functions anymore * docs - tmpl/ is finally dead for glib * GIO: - GInetAddressMask: new type for internet address range matching - various GIO file and stream fixes - improvements to attribute and fileinfo handling Thanks to the contributors to this release: Aleksander Morgado Alexander Larsson Alexandre Rostovtsev Benjamin Otte Christian Persch Chun-wei Fan Cosimo Cecchi Damien Lespinau Daniel Mustieles Dan Winship David Zeuthen Fran Diéguez Giovanni Campagna Jasper St. Pierre Javier Jardón Jorge González Josselin Mouette Jürg Billeter Kjartan Maraas Kristian Rietveld Lucas De Marchi Marc-André Lureau Matej Urbančič Matthias Clasen Murray Cumming Nicolas Dufresne Piotr Drąg Rico Tzschichholz Robert Nagy Simon McVittie Sjoerd Simons Will Thompson Yaron Shahrabani Cheers ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.31.2
GLib 2.31.2 is out. This is a point release on the way to what will become GLib 2.32.0. http://download.gnome.org/sources/glib/2.31/ 19d7921671a487c3c5759a57df7b8508afdbadd7764d62a47a82fff7b399032b glib-2.31.2.tar.xz Overview of changes from GLib 2.31.0 to 2.31.2 == * Monotonic time is now properly supported on Windows * glib-mkenums: fix @ENUMPREFIX@ with /* underscore_name=... */ * EXPERIMENTAL: introduce new GSettingsSchema and GSettingsSchemaSource APIs for the convenience of plugin system authors and those who wish to introspect the contents of schemas. This API may change. * Improve the performance of GObject property notifies. * GDBus: - fix a race when unowning a name immediately after owning it - thread safety improvements on GDBusConnection - fixes for exit-on-close functionality * Deprecations: - add G_SIGNAL_DEPRECATED - don't use G_DISABLE_DEPRECATED masking for functions anymore * docs - tmpl/ is finally dead for glib * GIO: - GInetAddressMask: new type for internet address range matching - various GIO file and stream fixes - improvements to attribute and fileinfo handling Thanks to the contributors to this release: Aleksander Morgado Alexander Larsson Alexandre Rostovtsev Benjamin Otte Christian Persch Chun-wei Fan Cosimo Cecchi Damien Lespinau Daniel Mustieles Dan Winship David Zeuthen Fran Diéguez Giovanni Campagna Jasper St. Pierre Javier Jardón Jorge González Josselin Mouette Jürg Billeter Kjartan Maraas Kristian Rietveld Lucas De Marchi Marc-André Lureau Matej Urbančič Matthias Clasen Murray Cumming Nicolas Dufresne Piotr Drąg Rico Tzschichholz Robert Nagy Simon McVittie Sjoerd Simons Will Thompson Yaron Shahrabani Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
dconf 0.11.2
dconf 0.11.2 is released: http://download.gnome.org/sources/dconf/0.11/ 4625978257cd8c273a4d31ea7a8788326df63267fc0236b6d879e891cd48fad9 dconf-0.11.2.tar.xz This is a point release leading up to what will become 0.12.0. Changes in dconf 0.11.2 === - many bugfixes and improvements to the editor, most notably porting to GtkGrid to avoid the GtkTable layout bug that was causing size to be incorrectly allocated - fix a crasher due to invalid string index of -1 Thanks to those who contributed: Robert Ancell Matthias Clasen Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: A GTK+ hackfest opportunity
On Wed, 2011-11-02 at 14:15 -0400, Matthias Clasen wrote: E.g. Benjamin might be able to attend both... This is really the issue. Having the gtk and a11y developers in the same place is great -- but totally useless unless Benjamin can focus on a11y while he's there. For that reason, plus the reasons of less required synchronisation (and the fact that Benjamin doesn't seem to mind the extra trip) the a11y hackfest was separated out. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: experimental gtk+ 3.3.2 win32 build
hi Pedro, On Wed, 2011-10-26 at 16:14 -0300, Pedro Ignacio Guridi wrote: Hello everyone, I dont know if this list is the right place to post this information, my apologies if is not. I built Gtk+ 3.3.2, Glib 2.31, etc. under win32 (mingw32), I wanted to share the link if somebody is interested or finds it useful. In general, we are interested in improving the situation with respect to Windows builds. We'd like to do this in a more robust way (ie: done with every version and posted on gtk.org). Ideally, this would be automated. It's worth noting that it's already relatively easy for us to do mingw builds and indeed we have a full set of them in the Fedora archive. What we really lack is a good method of doing regular builds using Visual Studio (which is necessary to get the correct debugging symbols into the libraries). Do you have any ideas how we could possibly automate this process? Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
dconf 0.11.0
hi all, dconf 0.11.0 is released. This is the first unstable release going toward 0.12. http://download.gnome.org/sources/dconf/0.11/ cfe99f06f517e51e543266f2b27fd50a480565b2b59aa32996d4841887251b93 dconf-0.11.0.tar.xz There are some bugfixes: - don't install a system service file - dconf update no longer fails if the locks/ subdir is missing - port to the new GLib synchronisation APIs - stop using -Werror - get rid of maintainer mode - drop some dead code and no-longer-needed workarounds Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.31.0
At long last, GLib 2.31.0 has been released. http://download.gnome.org/sources/glib/2.31/ 46fcaec884be7ce1b780feffb0da987b55e23850a870d94ed84356870532fe8c glib-2.31.0.tar.xz Most people reading this announcement know that there have been a huge number of changes in this release. There were some breaks involved in that, but I've been running it on my system (in /usr) for the past few days now without detecting any issues. Special thanks to Rico Tzschichholz who has been doing the same and found two rather serious issues by doing so (both of which have been fixed). On to the NEWS... (ps: the 500 commits are a lie[1]) Overview of changes from GLib 2.29/2.30 to 2.31.0 = This release contains a huge number of changes (500 commits worth). The list below attempts to summarise, but not every change is listed. * Major changes to threading and synchronisation - threading is now always enabled in GLib - support for custom thread implementations (including our own internal support for errorcheck mutexes) has been removed - a whole lot of dead code (to deal with the non-threaded case) has been ripped out. This includes the racy path of GMainContext that caused deadlocks with respect to child process exits in single-threaded programs (such as gtester). - libgthread is now an empty shell and g_thread_init() is no longer required (and has been deprecated) - GMutex and GCond can now be statically allocated without explicit initialisation. Dynamic allocation for these types is deprecated. - new types GRecMutex and GRWLock can also be statically allocated without explicit initialisation. - GPrivate can now be statically allocated and has an improved API. Dynamic allocation of GPrivate is deprecated. - GStaticMutex, GStaticRecMutex, GStaticRwLock, GStaticPrivate are deprecated. - GCond now uses monotonic time internally and a new API takes monotonic time for timed waits, deprecating the wallclock API - removal of the insane macro indirection used in the previous implementation of threading and synchronisation APIs - use SRWLock and CONDITION_VARIABLE APIs when available on Windows (Vista and later) and emulate them on XP - leaks of G(Static)Private-allocated data on some cases of thread exit have been fixed - simplified new thread creation API with the old API deprecated. The concept of joinability has disappeared (all threads are joinable) as have priority levels, 'bound'ness (ie: kernel vs. userspace threads) and ability to manipulate the stack size. - GThread is now a refcounted type - other implementation details changed * Move headers for some deprecated functionality to a separate deprecated/ directory. * New support for attribute-based deprecations to issue compiler warnings instead of breaking the build and/or giving warnings about implicit declarations (and possibly miscompiling). * GCache has been deprecated (after its last use was removed from our platform over a year ago). * It is no longer possible to include individual headers (like ghash.h) -- you must #include glib.h. * The misguided experiment of allowing the program to stumble along with missing GSettings schemas is now over -- the abort is back. * Clarify that fork() is not valid while using GMainContext. This is because the internal resources of the GMainContext end up being shared by both processes. We had an assert here but it was breaking existing (valid) use cases as well, so it has been removed for now. * GApplication - add ::shutdown signal as logical dual to ::startup - don't use a GMainLoop: iterate the GMainContext directly (improves quit logic) * Several portability fixes for Windows, OpenBSD, Solaris * Add new GValue API to specifically deal in signed chars (in case the platform defines 'char' as unsigned) * some new API to mitigate the problems associated with calling setenv() in a multi-threaded program * Use CLOCK_MONOTONIC unconditionally if the libc has support at compile time (ie: stop checking for kernel support at runtime). * pkg-config files: - drop -uninstalled variants - remove gobject dependency on gthread * New macro G_ATOMIC_LOCK_FREE is defined if the atomic operations are implemented without use of a mutex. Cleaned up atomic-related compilation issues with mingw compilers on win32 systems. * SOCKS proxy and resolver improvements * Fix the spelling of G_IO_FLAG_IS_WRITABLE (was WRITEABLE) and introduce a macro for backwards compatibility. * GDBus: - many code generation updates and improvements - some race condition fixes, including testcase hangs * GVariant: - new g_variant_new_from_fixed_array() API - substantial docs improvements/clarifications * GKeyFile is now refcounted and boxed * mount monitoring is now based on /proc/mounts (where available) instead of mtab * new macros G_SOURCE_CONTINUE and G_SOURCE_REMOVE for
GLib 2.31.0
At long last, GLib 2.31.0 has been released. http://download.gnome.org/sources/glib/2.31/ 46fcaec884be7ce1b780feffb0da987b55e23850a870d94ed84356870532fe8c glib-2.31.0.tar.xz Most people reading this announcement know that there have been a huge number of changes in this release. There were some breaks involved in that, but I've been running it on my system (in /usr) for the past few days now without detecting any issues. Special thanks to Rico Tzschichholz who has been doing the same and found two rather serious issues by doing so (both of which have been fixed). On to the NEWS... (ps: the 500 commits are a lie[1]) Overview of changes from GLib 2.29/2.30 to 2.31.0 = This release contains a huge number of changes (500 commits worth). The list below attempts to summarise, but not every change is listed. * Major changes to threading and synchronisation - threading is now always enabled in GLib - support for custom thread implementations (including our own internal support for errorcheck mutexes) has been removed - a whole lot of dead code (to deal with the non-threaded case) has been ripped out. This includes the racy path of GMainContext that caused deadlocks with respect to child process exits in single-threaded programs (such as gtester). - libgthread is now an empty shell and g_thread_init() is no longer required (and has been deprecated) - GMutex and GCond can now be statically allocated without explicit initialisation. Dynamic allocation for these types is deprecated. - new types GRecMutex and GRWLock can also be statically allocated without explicit initialisation. - GPrivate can now be statically allocated and has an improved API. Dynamic allocation of GPrivate is deprecated. - GStaticMutex, GStaticRecMutex, GStaticRwLock, GStaticPrivate are deprecated. - GCond now uses monotonic time internally and a new API takes monotonic time for timed waits, deprecating the wallclock API - removal of the insane macro indirection used in the previous implementation of threading and synchronisation APIs - use SRWLock and CONDITION_VARIABLE APIs when available on Windows (Vista and later) and emulate them on XP - leaks of G(Static)Private-allocated data on some cases of thread exit have been fixed - simplified new thread creation API with the old API deprecated. The concept of joinability has disappeared (all threads are joinable) as have priority levels, 'bound'ness (ie: kernel vs. userspace threads) and ability to manipulate the stack size. - GThread is now a refcounted type - other implementation details changed * Move headers for some deprecated functionality to a separate deprecated/ directory. * New support for attribute-based deprecations to issue compiler warnings instead of breaking the build and/or giving warnings about implicit declarations (and possibly miscompiling). * GCache has been deprecated (after its last use was removed from our platform over a year ago). * It is no longer possible to include individual headers (like ghash.h) -- you must #include glib.h. * The misguided experiment of allowing the program to stumble along with missing GSettings schemas is now over -- the abort is back. * Clarify that fork() is not valid while using GMainContext. This is because the internal resources of the GMainContext end up being shared by both processes. We had an assert here but it was breaking existing (valid) use cases as well, so it has been removed for now. * GApplication - add ::shutdown signal as logical dual to ::startup - don't use a GMainLoop: iterate the GMainContext directly (improves quit logic) * Several portability fixes for Windows, OpenBSD, Solaris * Add new GValue API to specifically deal in signed chars (in case the platform defines 'char' as unsigned) * some new API to mitigate the problems associated with calling setenv() in a multi-threaded program * Use CLOCK_MONOTONIC unconditionally if the libc has support at compile time (ie: stop checking for kernel support at runtime). * pkg-config files: - drop -uninstalled variants - remove gobject dependency on gthread * New macro G_ATOMIC_LOCK_FREE is defined if the atomic operations are implemented without use of a mutex. Cleaned up atomic-related compilation issues with mingw compilers on win32 systems. * SOCKS proxy and resolver improvements * Fix the spelling of G_IO_FLAG_IS_WRITABLE (was WRITEABLE) and introduce a macro for backwards compatibility. * GDBus: - many code generation updates and improvements - some race condition fixes, including testcase hangs * GVariant: - new g_variant_new_from_fixed_array() API - substantial docs improvements/clarifications * GKeyFile is now refcounted and boxed * mount monitoring is now based on /proc/mounts (where available) instead of mtab * new macros G_SOURCE_CONTINUE and G_SOURCE_REMOVE for
Re: GThread struct now hidden
hi On Thu, 2011-10-13 at 13:26 +0200, Murray Cumming wrote: By the way, I also noticed that g_thread_init() is deprecated, presumably because you must now used g_thread_new(), so you don't need it, but I don't see a deprecation comment on g_thread_init(). g_thread_init() is deprecated because you simply do not need to call it. g_thread_new() is rather a replacement for g_thread_create(). Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GThread struct now hidden
hi Murray, On Thu, 2011-10-13 at 12:48 +0200, Murray Cumming wrote: This change in glib master does indeed break glibmm: http://git.gnome.org/browse/glib/commit/?id=d904612100120d12126f1a6623a106d8a5b02fa6 I had a feeling it might break something or other, and I didn't think about bindings. I'll back it out immediately. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
hi Markus,
On Tue, 2011-10-11 at 12:12 +0200, Markus Elfring wrote:
If you have a GVariant* variable, you should usually know what type it is
already,
but if not, g_variant_get_type() will tell you.
Is a direct use of a function like g_variant_type_is_maybe recommended?
Yes. It's there for exactly this reason.
I considered adding g_variant_is_array, g_variant_is_maybe,
g_variant_is_tuple, g_variant_is_variant, g_variant_is_int32,
g_variant_is_uint32, but you can see why I wanted to avoid that.
If you want to find out things about the type of a GVariant then of
course the GVariantType API is the correct and appropriate way to go
about it.
GVariants are immutable. Once a GVariant instance has been created, you
can't
change its value/contents - you can only throw it away and create a new
GVariant.
Thanks for your clarification.
I am still interested in an addition to the interface g_variant_new_maybe.
What addition?
You can reset a (GVariant *) variable to point to a variant representing
nothing the same way you'd make it point to anything else.
I imagine that this approach can be improved a bit.
How do you think about an interface like the following?
GVariant* g_variant_set_to_nothing(GVariant const * gv);
The name is a bit misleading because in our APIs _set_*() tends to mean
that you're modifying an object in some way (which is not what happens
here).
It's also worth noting that the new and the old object have absolutely
nothing in common except for their type -- which suggests that you
should just use the GVariantType interface to get what you want:
g_variant_new_maybe (g_variant_type_element (g_variant_get_type (gv), NULL);
(ie: create a new maybe-typed GVariant with no child value with the
element type equal to the element type of another GVariant 'gv').
If the passed instance is a maybe type already, its container will be
removed
while the contained type will be kept. (I would like to avoid the nesting of a
maybe type into another one.)
This is complicated. Your desire to avoid the nesting of maybe types is
understandable, but would introduce some inconsistency if we added it in
the API. If you want to do that in your own code then it is very easy:
{
GVariantType *type;
GVariant *new_val;
type = g_variant_get_type (gv);
/* if the type is already a maybe type, strip off
* the extra layer to avoid nested maybe types.
*/
if (g_variant_type_is_maybe (type))
type = g_variant_element (type);
/* create a new 'nothing' value of the correct type */
new_val = g_variant_new_maybe (type, NULL);
}
Note that you don't need to free 'type' anywhere here due to how
GVariantType works internally to avoid copies.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Function completion for GVariant maybe types?
On Tue, 2011-10-11 at 19:37 +0200, Markus Elfring wrote: I stumbled on the detail that the functions g_variant_is_of_type and g_variant_is_container are provided directly while some predicates can only be checked by the others. g_variant_is_of_type (gv, G_VARIANT_TYPE_MAYBE) will do what you expect. The name is a bit misleading because in our APIs _set_*() tends to mean that you're modifying an object in some way (which is not what happens here). Would you prefer a name like g_variant_create_maybe_from_source over my suggestion g_variant_set_to_nothing? ;-) I think I'd just prefer not to have such an API :) Why should it be easier to implement the special copy operation in my code? Do more GLib software developers need the suggested functionality? I'm not aware of anyone who does. GVariant is typically used in situations where there are strong expectations on the types of values in use and not much need for converting between different types. In fact, if we were to add any sort of 'additional flexibility' here, it would be in terms of introducing functions that are more flexible with respect to the different integer types... That issue has been raised a couple of times, but even in that case there doesn't seem to be a burning need. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Glib Atomic Operations
On Fri, 2011-10-07 at 09:24 -0400, Morten Welinder wrote: what is the purpose of '(void) (0 ? *(atomic) ^ *(atomic) : 0)'? Poor man's type check. That expression isn't valid for every possible atomic. Specifically, it ensures that the destination of the pointer is an integral type. You can't perform ^ (xor) on a pointer, struct, double, etc. Notice that this check is omitted for the _pointer_ variant -- which is (of course) expected to work on pointers. 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)
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
GLib 2.30.0
hello everyone. GLib 2.30.0 has been released. http://download.gnome.org/sources/glib/2.30/ d64c00b43409eabb89aad78501fcb1a992b002b314a4414a9bd069585cb7cdc1 glib-2.30.0.tar.xz This major release of GLib represents 1174 commits from 151 individual authors, including 35 contributors with 5 or more commits. Over a dozen companies have made a substantial contribution to this release. Countless others have contributed testing, bug reports, packaging, online support and other valuable work throughout the cycle. In addition to hundreds of bug fixes and enhancements made this cycle, the following major features were added: - GDBus has been improved by the addition of a high-level object manager and code generation facilities that make use of it. See http://davidz25.blogspot.com/2011/09/new-d-bus-features-in-glib-230.html for more information. - GLib has added an extensible TLS database where certificates and keys can be found and used, laying the foundation for integration with smart cards and other key stores. GLib now also supports HMAC hashes (which are used when implementing web technologies like OAuth). - The atomic operations have been expanded to include bit operations (and, or, xor) and so that all operations are supported on pointer-sized operands. The implementation has been made more correct and performant by way of GCC intrinsics and better use of the Interlocked API on Windows. Bitlocks now work on pointer-sized operands. - New API has been added to allow UNIX signals to be dispatched via the mainloop. Additionally, there is a new UNIX-specific API to allow race-free creation of close-on-exec pipes with a fallback on platforms where this is not possible. - GMainContext and GCancellable now use eventfd when available, instead of less efficient pipe pairs. - GApplication now supports non-single-instance applications. We had one small API break to an interface that wasn't used except from inside GLib itself: the name of the 'set_state' virtual function call on the interface of GAction changed to 'change_state' in order to avoid conflicts with the 'set_state' method on GSimpleAction. To avoid compatibility problems, those who will implement GAction going forward are suggested to assume that this feature appeared for the first time in this release of GLib. This release of GLib has had a fantastic amount of work put in by translators. Despite being one of the most difficult modules to translate, we have 100% coverage of 32 languages, including: Assamese, Basque, Brazilian Portuguese, British English, Bulgarian, Canadian English, Catalan (Valencian), Catalan, Chinese (China), Czech, Danish, French, Galician, German, Hungarian, Indonesian, Italian, Korean, Latvian, Lithuanian, Norwegian Bokmål, Polish, Portuguese, Punjabi, Russian, Serbian, Serbian Latin, Slovenian, Spanish and Swedish. Special mention goes to the translations of Tamil and Esperanto which were both at approximately 50% last cycle and made it to 100% this cycle. 12 other languages (Chinese (Hong Kong), Chinese (Taiwan), Belarusian, Hebrew, Uighur, Finnish, Greek, Romanian, Vietnamese, Armenian, Japanese, Gujarati) are above the 80% level. Finally, Chun-wei Fan has invested a substantial effort to ensure that it is once again possible to build GLib using Visual Studio on Windows. Release announcements (and more detailed change summaries) for the individual unstable point releases made during this cycle can be found here: 2.29.92: https://mail.gnome.org/archives/gtk-devel-list/2011-September/msg00153.html 2.29.90: https://mail.gnome.org/archives/gtk-devel-list/2011-September/msg00018.html 2.29.16: https://mail.gnome.org/archives/gtk-devel-list/2011-August/msg00034.html 2.29.14: https://mail.gnome.org/archives/gtk-devel-list/2011-July/msg00038.html 2.29.12: https://mail.gnome.org/archives/gtk-devel-list/2011-July/msg00034.html 2.29.10: https://mail.gnome.org/archives/gtk-devel-list/2011-July/msg3.html 2.29.8: https://mail.gnome.org/archives/gtk-devel-list/2011-June/msg00041.html 2.29.6: https://mail.gnome.org/archives/gtk-devel-list/2011-June/msg00011.html 2.29.4: https://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00012.html 2.29.2: https://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00071.html I won't try to list everyone who contributed to this release. You know who you are; a huge thank you to you all. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.30.0
hello everyone. GLib 2.30.0 has been released. http://download.gnome.org/sources/glib/2.30/ d64c00b43409eabb89aad78501fcb1a992b002b314a4414a9bd069585cb7cdc1 glib-2.30.0.tar.xz This major release of GLib represents 1174 commits from 151 individual authors, including 35 contributors with 5 or more commits. Over a dozen companies have made a substantial contribution to this release. Countless others have contributed testing, bug reports, packaging, online support and other valuable work throughout the cycle. In addition to hundreds of bug fixes and enhancements made this cycle, the following major features were added: - GDBus has been improved by the addition of a high-level object manager and code generation facilities that make use of it. See http://davidz25.blogspot.com/2011/09/new-d-bus-features-in-glib-230.html for more information. - GLib has added an extensible TLS database where certificates and keys can be found and used, laying the foundation for integration with smart cards and other key stores. GLib now also supports HMAC hashes (which are used when implementing web technologies like OAuth). - The atomic operations have been expanded to include bit operations (and, or, xor) and so that all operations are supported on pointer-sized operands. The implementation has been made more correct and performant by way of GCC intrinsics and better use of the Interlocked API on Windows. Bitlocks now work on pointer-sized operands. - New API has been added to allow UNIX signals to be dispatched via the mainloop. Additionally, there is a new UNIX-specific API to allow race-free creation of close-on-exec pipes with a fallback on platforms where this is not possible. - GMainContext and GCancellable now use eventfd when available, instead of less efficient pipe pairs. - GApplication now supports non-single-instance applications. We had one small API break to an interface that wasn't used except from inside GLib itself: the name of the 'set_state' virtual function call on the interface of GAction changed to 'change_state' in order to avoid conflicts with the 'set_state' method on GSimpleAction. To avoid compatibility problems, those who will implement GAction going forward are suggested to assume that this feature appeared for the first time in this release of GLib. This release of GLib has had a fantastic amount of work put in by translators. Despite being one of the most difficult modules to translate, we have 100% coverage of 32 languages, including: Assamese, Basque, Brazilian Portuguese, British English, Bulgarian, Canadian English, Catalan (Valencian), Catalan, Chinese (China), Czech, Danish, French, Galician, German, Hungarian, Indonesian, Italian, Korean, Latvian, Lithuanian, Norwegian Bokmål, Polish, Portuguese, Punjabi, Russian, Serbian, Serbian Latin, Slovenian, Spanish and Swedish. Special mention goes to the translations of Tamil and Esperanto which were both at approximately 50% last cycle and made it to 100% this cycle. 12 other languages (Chinese (Hong Kong), Chinese (Taiwan), Belarusian, Hebrew, Uighur, Finnish, Greek, Romanian, Vietnamese, Armenian, Japanese, Gujarati) are above the 80% level. Finally, Chun-wei Fan has invested a substantial effort to ensure that it is once again possible to build GLib using Visual Studio on Windows. Release announcements (and more detailed change summaries) for the individual unstable point releases made during this cycle can be found here: 2.29.92: https://mail.gnome.org/archives/gtk-devel-list/2011-September/msg00153.html 2.29.90: https://mail.gnome.org/archives/gtk-devel-list/2011-September/msg00018.html 2.29.16: https://mail.gnome.org/archives/gtk-devel-list/2011-August/msg00034.html 2.29.14: https://mail.gnome.org/archives/gtk-devel-list/2011-July/msg00038.html 2.29.12: https://mail.gnome.org/archives/gtk-devel-list/2011-July/msg00034.html 2.29.10: https://mail.gnome.org/archives/gtk-devel-list/2011-July/msg3.html 2.29.8: https://mail.gnome.org/archives/gtk-devel-list/2011-June/msg00041.html 2.29.6: https://mail.gnome.org/archives/gtk-devel-list/2011-June/msg00011.html 2.29.4: https://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00012.html 2.29.2: https://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00071.html I won't try to list everyone who contributed to this release. You know who you are; a huge thank you to you all. ___ 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
hi Stuart, On Sun, 2011-09-25 at 13:45 -0600, Stuart Ambler wrote: Apparently pkg-config used to contain within it an old version of glib, used mostly for strings, lists, hash tables, and a few other things, that the new version has removed and instead made itself depend on glib. glib documentation, on the other hand, says that glib is dependent on pkg-config. See the pkg-config README about this: http://cgit.freedesktop.org/pkg-config/tree/README#n33 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)
On Tue, 2011-09-27 at 11:36 +0200, Kean Johnston wrote:
On 9/27/2011 9:08 AM, Steve Frécinaux wrote:
Won't you break ABI if you're changing the layout of the struct on
linux/unixes? As I understand this is not an issue on Windows since
everyone ships the libraries with the binary, but it is on Linux.
I was just about to write a reply mentioning this -- glad someone else
brought it up. :)
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.
Nope. On linux there IS no ABI to break - everything is #define'd to its
libc name - so there is no real g_stat(). Any existing code out there will
just be calling stat(). If we make this change however we will be
introducing an ABI that will need to be maintained which is why its
important everyone agrees the data types are wide enough.
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.
If there is any API that takes a 'GStatBuf *' then that ABI will change
as a result of recompiling against the new GLib (ie: recompiling a
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.
A more practical concern, however, is the fact that GStatBuf was only
introduced somewhat recently:
http://git.gnome.org/browse/glib/commit/?id=1229281d95802c4c190284c7d331f67194a2553e
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.
Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Please consider for inclusion in glib 2.30
hi Kean, On Mon, 2011-09-26 at 06:57 +0200, Kean Johnston wrote: https://bugzilla.gnome.org/show_bug.cgi?id=660095 Its small, it doesn't affect anything except Windows and it fixes an actual build problem if your environment does have dirent.h. Thank you. We were hard code frozen at the time you sent this mail and only hours before the final release was rolled. We'll take a look at it for the .1 release. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
dconf 0.10.0
hi, dconf 0.10.0 was released with no changes at all. It should be packaged only as a matter of completeness. http://download.gnome.org/sources/dconf/0.10/ 9f744ccfb3da20163a4bb27916c960f6bf56048b3ec1112862c85414fc064ee2 dconf-0.10.0.tar.xz Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
dconf 0.9.1
hi dconf 0.9.1 was just released. I doubt there will be any changes before I release 0.10.0 in time for the GNOME 3.2 release, but please test this release in case changes do need to be made. Download http://download.gnome.org/sources/dconf/0.9/dconf-0.9.1.tar.xz (169K) sha256sum: fd2ea1ed3b7933cf3d6841f8fc8794a0351c30ef5d7b8eb0b56cc3171e9e354e Changes in dconf 0.9.1 == - give a g_warning() on failure to communicate with service - remove unworking 'set lock' call from dconf API and commandline tool - add code to exit gracefully on receipt of SIGINT, SIGHUP, SIGTERM - remove service function logic; always use the XDG runtime directory Thanks for the help from Marc-Antoine Perennou and Robert Schwebel. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.29.92
hi all, GLib 2.29.92 has been released. This release is intended to be included as part of GNOME 3.1.92. http://download.gnome.org/sources/glib/2.29/ 1f68d7990d03a52cf81284f039de94b041c3f5eb3d53663166b31e477557e8b1 glib-2.29.92.tar.xz 2.30.0 will be released on or slightly before September 26th. Overview of changes from GLib 2.29.90 to 2.29.92 This release contains only bugfixes, docs changes and translations updates. Translation will continue, but otherwise this should be considered a release candidate for 2.30.0. * GDBus bug fixes - fix segfault when remote property is invalidated (#659070) - take more care in connection teardown to avoid use-after-free (#651268) * GMappedFile: return an error when trying to map a device (#659212) * GSettings: always deliver signals to the correct thread (#657255) * some small documentation changes * Translation updates: Belarusian Brazilian Portuguese British English French Hindi Hungarian Italian Japanese Latvian Norwegian bokmål Persian Polish Punjabi Russian Simplified Chinese Spanish Swedish Tamil Thank you to the contributors to this release: A S Alam Alexandre Franke Antonio Fernandes C. Neto Arash Mousavi Aron Xu Bruce Cowan Daniel Mustieles Daniel Nylander David Zeuthen Gabor Kelemen I Felix Ihar Hrachyshka Jiro Matsuzawa Jorge González Josselin Mouette Kjartan Maraas Luca Ferretti Matthias Clasen Piotr Drąg Rajesh Ranjan Rudolfs Mazurs Simon McVittie Tomas Bzatek Yuri Myasoedov Cheers ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GLib 2.29.92
hi all, GLib 2.29.92 has been released. This release is intended to be included as part of GNOME 3.1.92. http://download.gnome.org/sources/glib/2.29/ 1f68d7990d03a52cf81284f039de94b041c3f5eb3d53663166b31e477557e8b1 glib-2.29.92.tar.xz 2.30.0 will be released on or slightly before September 26th. Overview of changes from GLib 2.29.90 to 2.29.92 This release contains only bugfixes, docs changes and translations updates. Translation will continue, but otherwise this should be considered a release candidate for 2.30.0. * GDBus bug fixes - fix segfault when remote property is invalidated (#659070) - take more care in connection teardown to avoid use-after-free (#651268) * GMappedFile: return an error when trying to map a device (#659212) * GSettings: always deliver signals to the correct thread (#657255) * some small documentation changes * Translation updates: Belarusian Brazilian Portuguese British English French Hindi Hungarian Italian Japanese Latvian Norwegian bokmål Persian Polish Punjabi Russian Simplified Chinese Spanish Swedish Tamil Thank you to the contributors to this release: A S Alam Alexandre Franke Antonio Fernandes C. Neto Arash Mousavi Aron Xu Bruce Cowan Daniel Mustieles Daniel Nylander David Zeuthen Gabor Kelemen I Felix Ihar Hrachyshka Jiro Matsuzawa Jorge González Josselin Mouette Kjartan Maraas Luca Ferretti Matthias Clasen Piotr Drąg Rajesh Ranjan Rudolfs Mazurs Simon McVittie Tomas Bzatek Yuri Myasoedov Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
glib-2-30 hard code frozen
hi everyone, I've been trying to follow the GNOME 3.1 release cycle fairly closely with GLib 2.29. For that reason, I now consider the glib-2-30 branch to be hard code frozen. Please do not commit anything without first asking for an exception. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
