Unequal increments in GtkScale or Spin Button
Hi list. Is it possible to specify unequal increments or decrements in scale/range/spinbuttons or adjustments? By that I mean, for example, if the up-arrow of a spin button is pressed, instead of increasing the value by a fixed increment, I change it by arbitrary values - say the value changes from 10 to 16 to 18 to 32 to 60 and so on? Thanks in advance Pramathesh ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: I'm done with O_CLOEXEC
On 03/20/2015 01:43 PM, Ryan Lortie wrote: karaj, For those unfamiliar with the issue: when a process is created on UNIX via naive fork() and exec(), the default is that the process will inherit all of the file descriptors of the parent. This makes a lot of sense for stdin, stdout and stderr, but almost nothing else. This has been the cause of a lot of strange problems over the years. The typical example: a process will open a listener socket at some point and sometime later will call a library function that does a naive fork()/exec() of a helper process that hangs around past the lifetime of the original program. When you try to restart the first program, the socket is still being held open by the helper and the new instance can't bind it again. There are two fixes to this problem. [..snip..] This makes me happy. I don't think I've actually seen any of this stuff handled right. Not to mention that close() itself is basically broken in multi-threaded scenarios on Linux (Linus says to basically just not worry about it if you get EINTR, which may or may not have succeeded, and then the FD entry taken by another thread). 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). -- Christian ___ 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 7:29 PM, Christian Hergert christ...@hergert.me wrote: This makes me happy. I don't think I've actually seen any of this stuff handled right. Not to mention that close() itself is basically broken in multi-threaded scenarios on Linux (Linus says to basically just not worry about it if you get EINTR, which may or may not have succeeded, and then the FD entry taken by another thread). 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). no, it wouldn't. as a pango user, do i call pango_close_all_fds_before_exec() or does gtk? or gdk? or ... as a libfftw3 user, do i call fftw2_close_all_fds_before_exec() or does some other library that also uses it? (which i may know that i am using, or i may not (via loading some arbitrary module). call the close_before_exec() for all libraries that i know i explicitly call into and pray that the rest do the right things for other libraries that i don't explicitly use this is a much weaker proposition. what you want is close_all_fds_before_exec() that just gets the job done, in one place, in the application. ___ 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
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 ? On Fri, Mar 20, 2015 at 4:43 PM, Ryan Lortie de...@desrt.ca wrote: karaj, For those unfamiliar with the issue: when a process is created on UNIX via naive fork() and exec(), the default is that the process will inherit all of the file descriptors of the parent. This makes a lot of sense for stdin, stdout and stderr, but almost nothing else. This has been the cause of a lot of strange problems over the years. The typical example: a process will open a listener socket at some point and sometime later will call a library function that does a naive fork()/exec() of a helper process that hangs around past the lifetime of the original program. When you try to restart the first program, the socket is still being held open by the helper and the new instance can't bind it again. There are two fixes to this problem. The first one, which we have been pursuing during the past several years, is to try to mark every file descriptor that we create as O_CLOEXEC. This is particularly fun in multi-threaded programs because it means that we have a race between the creation of a file descriptor and marking it O_CLOEXEC vs. a fork() that may be happening in another thread. This has led to the creation of a whole bunch of new syscalls to allow creation of file descriptors that already have O_CLOEXEC set from the start, thus avoiding the race. We have tried to use these syscalls where possible, but they usually are not part of POSIX. Somethings they are completely unavailable, even in Linux, or when they are available, they have other annoying limitations. The other fix to the problem is one that we have had in place for a long time in the g_spawn_*() family of APIs, and also in the new GSubprocess API. The trick involves close()ing all fds (except stdin/out/err) each time we do a fork()/exec() pair. Assuming it is practised universally, only one of these fixes is necessary. Today I am suggesting that we completely abandon our attempts to follow the first approach. I'm done with O_CLOEXEC. What led me to this was the dup3() system call. This is a variant of dup2() that was added (as part of the efforts mentioned above) to avoid the O_CLOEXEC race: int dup3(int oldfd, int newfd, int flags); unfortunately: dup3(0, -1, 0) = -1 EBADF (Bad file descriptor) which means that using this as a stand-in for dup() is a no-go. I could probably work around that by creating a new eventfd() or unbound UNIX socket in order to get a new fd number (while being careful to mark it as O_CLOEXEC as well) before using dup3(). We could probably also get this fixed in Linux, but dup3() has already been widely copied and we would then have to go about detecting which implementations are working and which aren't, and include a fallback (which would have to be implemented using the same dirty hacks mentioned above). I've had enough with these games, and this isn't really about dup3() anyway. O_CLOEXEC is useless. Okay. O_CLOEXEC is useful for one thing: when spawning a new process using fork()/exec(), you may want to know if exec() worked. An old trick for this is to create a pipe and mark the writer end O_CLOEXEC. The reader end will read EOF (due to the close of the writer) once exec() has succeeded. Otherwise, you can indicate the error by sending some other data through the pipe and calling exit(). Aside from that, O_CLOEXEC is useless. So: starting today I'm going to stop worrying about O_CLOEXEC being set on every file descriptor that GLib creates. 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. I believe this is justified for a few reasons: - during the GSubprocess discussion, I originally held the opposite opinion, but eventually became convinced (by Colin) to see the inherit-by-default behaviour of exec() as nothing more than a questionable implementation detail of the underlying OS. Consequently, at the high level, GSubprocess provides an API that gives the caller direct control over what is inherited and what is not, and that's just the way that it should be. - this behaviour is not limited to GSubprocess. Closing all fds before calling exec() is a common practice in modern libraries and runtimes, and for good reason. - fixing the few places that we spawn other programs is massively preferable to fixing the hundreds or thousands of places that we create new file descriptors - in the world of D-Bus activation, direct spawning of long-lived helper processes is just not something that we do anymore anyway. fds are not the only thing we have to worry about here.
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
Sorry, I'm not overly familiar with this sort of stuff. 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 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? [0] https://git.gnome.org/browse/mutter/tree/src/wayland/meta-xwayland.c#n458 On Fri, Mar 20, 2015 at 10:10 PM, Ryan Lortie de...@desrt.ca wrote: 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 -- Jasper ___ 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: Gtk3 MacOS (OSX) context menu issues
On 15-03-20 10:07 AM, Roger Davis wrote: Hi Jim Konstantin, I can now add another data point on this topic. My boss bought me a nice new iMac 27 Retina which arrived a couple days ago (yayy boss!!), so I decided to do my first ever X11-free quartz-only gtk3 MacPorts install (agh gtk3-on-quartz!!). I am now seeing your menu insensitivity bug, another bug as well, and all my hard-won tweaks to get gtk3 looking nice re: font and theme issues under XQuartz have gone down the toilet and I'm back at square one. On to the details ... (1) I had a bit of installation difficulty with MacPorts. For my previous XQuartz gtk3 installs I always just did port install gtk3 but to do this quartz-only install I followed some other instructions and did port install cairo +quartz -x11 port install pango +quartz -x11 port install gtk3 +quartz -x11 The last command failed because it dragged in the gtk2 port which wanted a pango with X11, so I started over: port install cairo +quartz port install pango +quartz port install gtk3 +quartz -x11 That worked. (2) My gtk3 app runs basically OK (and is not starting X11), but now shows the message *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead. every time I start it. Naturally, my own code knows userSpaceScaleFactor from nothing, so it must be getting called somewhere within gtk3/whatever. There are other reports of this on the web (some of which state that it has led to fatal errors!!) but I have not yet seen any detailed explanation. Obviously it still afflicts gtk 3.14.9 and friends on quartz-only. (3) Now, the context menu issue ... I am basically seeing the same problem you are (although I have *never* seen it under my XQuartz installs), but have some additional observations to add. First, my popup menus (both those which I directly display within my own code as well as those displayed indirectly by GtkComboBoxText widgets) initially display with a transparent 6-ish-pixel-wide border the first time they are shown, but on subsequent displays show no border at all (but still suffer from the insensitivity bug). Weird. Second, I can avoid triggering the bug if I initiate the menu display with a quick click-and-release. If on the other hand I trigger the menu with a depress-only mouse event, I see the bug as you have described. On my own direct popups, the menu displays to the lower right of the mouse cursor position. If I depress-only and move the mouse directly to the lower right the items are sensitive until I move the mouse out of the menu, but if I first move the mouse to the upper left and then into the menu, the items are never sensitive. Jim, I don't see how this could have anything to do with X11 because (1) the latter is not running on my quartz-only install where the bug appears, and (2) the bug *never* appears on my XQuartz platforms. Hope this helps, Roger Jim Charlton wrote: I certainly should have mentioned that my observations were made under the MAC OS X 10.10 (Yosemite) operating system. I too have not been able to observe this problem under Linux (Ubuntu). As Konstantin has pointed out, it does not seem possible to add a margin to the popup menuitem box in Linux to test if the problem would arise. I will try to determine if the problem arises in the XQuartz X11 libraries or in the GTK3 libraries. But the incorrect motion event data seems to point to the X11 libraries on the MAC. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list Roger: I can confirm that I see exactly the same thing that you do. Holding down the right mouse button while moving the mouse gives the effect that you see. On checking which widget is under the cursor at each motion event... I find that not releasing the right button changes what is initially reported to be under the cursor (from GtkMenu to GtkMenuItem). I used rather loose language when I referred to the XQuartz server. I am also actually using the Gtk3 + quartz and so am using the MAC quartz graphics library not the Xserver. A colleague here has suggested that it probably is not an incorrect event being sent from quartz as I imagined. It may be linked to either the handling of enter events, or perhaps the setting of event masks for the various widgets. I will continue to work my way through the code (gtkmenu.c) to see if I can figure it out. jim... Jim Charlton ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-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
Re: Gtk3 MacOS (OSX) context menu issues
Hi Jim Konstantin, I can now add another data point on this topic. My boss bought me a nice new iMac 27 Retina which arrived a couple days ago (yayy boss!!), so I decided to do my first ever X11-free quartz-only gtk3 MacPorts install (agh gtk3-on-quartz!!). I am now seeing your menu insensitivity bug, another bug as well, and all my hard-won tweaks to get gtk3 looking nice re: font and theme issues under XQuartz have gone down the toilet and I'm back at square one. On to the details ... (1) I had a bit of installation difficulty with MacPorts. For my previous XQuartz gtk3 installs I always just did port install gtk3 but to do this quartz-only install I followed some other instructions and did port install cairo +quartz -x11 port install pango +quartz -x11 port install gtk3 +quartz -x11 The last command failed because it dragged in the gtk2 port which wanted a pango with X11, so I started over: port install cairo +quartz port install pango +quartz port install gtk3 +quartz -x11 That worked. (2) My gtk3 app runs basically OK (and is not starting X11), but now shows the message *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead. every time I start it. Naturally, my own code knows userSpaceScaleFactor from nothing, so it must be getting called somewhere within gtk3/whatever. There are other reports of this on the web (some of which state that it has led to fatal errors!!) but I have not yet seen any detailed explanation. Obviously it still afflicts gtk 3.14.9 and friends on quartz-only. (3) Now, the context menu issue ... I am basically seeing the same problem you are (although I have *never* seen it under my XQuartz installs), but have some additional observations to add. First, my popup menus (both those which I directly display within my own code as well as those displayed indirectly by GtkComboBoxText widgets) initially display with a transparent 6-ish-pixel-wide border the first time they are shown, but on subsequent displays show no border at all (but still suffer from the insensitivity bug). Weird. Second, I can avoid triggering the bug if I initiate the menu display with a quick click-and-release. If on the other hand I trigger the menu with a depress-only mouse event, I see the bug as you have described. On my own direct popups, the menu displays to the lower right of the mouse cursor position. If I depress-only and move the mouse directly to the lower right the items are sensitive until I move the mouse out of the menu, but if I first move the mouse to the upper left and then into the menu, the items are never sensitive. Jim, I don't see how this could have anything to do with X11 because (1) the latter is not running on my quartz-only install where the bug appears, and (2) the bug *never* appears on my XQuartz platforms. Hope this helps, Roger Jim Charlton wrote: I certainly should have mentioned that my observations were made under the MAC OS X 10.10 (Yosemite) operating system. I too have not been able to observe this problem under Linux (Ubuntu). As Konstantin has pointed out, it does not seem possible to add a margin to the popup menuitem box in Linux to test if the problem would arise. I will try to determine if the problem arises in the XQuartz X11 libraries or in the GTK3 libraries. But the incorrect motion event data seems to point to the X11 libraries on the MAC. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
