Re: Alt-key mnemonics in menus
On 2011-09-05 at 21:35, Allin Cottrell wrote: Having built a minimal test program, showing a plain GTK window with a menu, I can confirm that the GTK default is (a). And I find this to be the case with all the gnome apps that I've tested. I infer that apps that support (c) -- e.g., Firefox, Thunderbird and LibreOffice -- must be making some special effort to achieve that effect. Maybe for compatibility with MS Windows? Firefox, Thunderbird and LibreOffice are not really gtk applications. in the case of Firefox and Thunderbird, at least, the chrome of the browser is written usign XUL — and only looks like gtk. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Can g_file_monitor_file () report events from before it was created?
On Tue, 06 Sep 2011 01:42:43 +0100 Peter Clifton pc...@cam.ac.uk wrote: I'm working on some code to monitor for file changes in our application, and ran into a bit of a problem today with the Save-As case. The order of operations is something like: 1. File monitor exists on the document file which was loaded last 2. User hits File-Save as.. (and enters a filename) 3. Core of app saves file into the new file name 4. File monitor does not fire, as the saved file is not the one being monitored 5. Core of app notifies the GUI (with the file monitor) that the document we should be watching is now in the new filename. 6. g_object_unref() the old file monitor 7. Create new file monitor on the new file. After this happens, I actually get a change event fire from the new file monitor - despite the changes having been saved by the app's core (fopen / fclose directly to the file in question), before I even created the file monitor. Is it possible that Glib / GIO is caching some state incorrectly, and spotting on-disk changes from _before_ I created the file monitor, or is it more likely that the file doesn't hit the disk until some time after I fclose() it - and that it spots the change at this point in time? Does it help if you call fsync() on the underlying file descriptor after calling fclose() (assuming you are using a unix-like OS)? That should at least force the write onto the hardware, so far as the kernel is concerned. From the man page of close(): A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hardware at this point.) Chris ___ 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.90
GLib 2.29.90 is ready. http://download.gnome.org/sources/glib/2.29/ 95af3f46a40ad1a3ecfe75db59b27956b256c4ad02f000be2aa13c7abd32fba3 glib-2.29.90.tar.xz I consider this to be (almost) a release candidate. There is probably a bug in GSettings that is causing lots of problems with gnome-settings-daemon that will need to be fixed before the next cycle. Other than that, we're more or less frozen -- it should mostly be docs and translations in the next release. There are two API breaks in this release with respect to the previous. One is a rename and the other is simple removal of a function that was only added in the last micro release. See below. Overview of changes from GLib 2.29.18 to 2.29.90 * API/ABI changes: - unix signal watches now match the API of all of the other sources - revert the addition of g_date_time_source_new () from last release * networking and other fixes for Solaris - we no longer support symbolic port names (ie: from /etc/services) - check if -lsocket is needed - fix g_socket_details_from_fd() - avoid getmntinfo - fix some harmless warnings * GDateTime improvements: - generally improved standards compliance (with C99) - support C99-specified format strings: %g, %G, %V, %c, %C, %w - consult the locale for the preferred 12-hour time format (%r) - drop support for non-standard %N and broken %W - better support for formatting non-POSIX (eg: Arabic) numerals - locale-related test case fixups, and fix some leaks * GTlsInteraction: add interaction method invocation guarantees * gdbus-codegen: post-process all interfaces when parsing 1 file * make GMainLoop, GMainContext and GSource boxed types * fix a race condition in the first use of g_get_monotonic_time() * lots gtk-doc cleanups * better intltool compatibility when generating pot file * avoid GCC-specific compiler options when not using GCC * Translation updates: Belarusian Brazilian Portuguese Canadian English Galician Indonesian Korean Lithuanian Norwegian bokmål Portuguese Spanish Swedish Thanks to everyone who helped: Alexandre Franke Andika Triwidada Aurimas Černius Changwoo Ryu Chun-wei Fan Dan Winship Daniel Nylander Duarte Loreto Fran Dieguez Ihar Hrachyshka Javier Jardón Jorge González Kjartan Maraas Matthias Clasen Og B. Maciel Patrick Welche Pavel Holejsovsky Stef Walter Tomas Bzatek Will Thompson Cheers ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Can g_file_monitor_file () report events from before it was created?
On Tue, 2011-09-06 at 01:42 +0100, Peter Clifton wrote: --=-1PQvPQuhjpa09GLvybFI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I'm working on some code to monitor for file changes in our application, and ran into a bit of a problem today with the Save-As case. The order of operations is something like: 1. File monitor exists on the document file which was loaded last 2. User hits File-Save as.. (and enters a filename) ^__ Just as an interesting (and probably critical note), I don't see this bug if I hard-code a Save-as filename. I only get unexpected file-monitor events if I use a gtk_file_chooser_dialog to select the new filename to save into. I'm presuming that this dialog (or some IO plugin) may use g_file_monitor, or threads, or SOMETHING - which is causing issues with my own usage of g_file_monitor. If anyone could help shed some light on this, it would be much apprecaited. 3. Core of app saves file into the new file name 4. File monitor does not fire, as the saved file is not the one being monit= ored 5. Core of app notifies the GUI (with the file monitor) that the document w= e should be watching is now in the new filename. 6. g_object_unref() the old file monitor 7. Create new file monitor on the new file. After this happens, I actually get a change event fire from the new file monitor - despite the changes having been saved by the app's core (fopen / fclose directly to the file in question), before I even created the file monitor. Is it possible that Glib / GIO is caching some state incorrectly, and spotting on-disk changes from _before_ I created the file monitor, or is it more likely that the file doesn't hit the disk until some time after I fclose() it - and that it spots the change at this point in time? Any ideas what I might be doing wrong here? (PS. I got the feeling GLib / GIO is using polling, not anything clever like inotify to spot changes - is this correct?) Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Alt and Command keys in the quartz backend
Hi all, Currently, the mapping of the Alt and Command keys on the mac is completely screwed: - The key labeled Command maps to GDK_MOD1_MASK (which is essentially interpreted as Alt by all existing code) - The key labeled Alt isn't mapped to any modifier at all Now there is a lot of discussion in these bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=607115 https://bugzilla.gnome.org/show_bug.cgi?id=605799 but at the bottom of all that is the above mentioned problem. After it's fixed we can fix whatever keymap issues in GTK on top. It seems pretty obvious to me that the key labeled Alt should produce GDK_MOD1_MASK because all existing code considers that being the Alt key. The only question is what to map Command to, and we are free to choose whatever, since the behavior will change away from the current one of producing GDK_MOD1_MASK anyway. I personally prefer GDK_META_MASK because it's what the Windows key is mapped to on PC keyboards, but that's not a strong reason (and it is, as saidm completely arbitrary anyway). Opinions? I volunteer to patch up all 3 branches once we come to an agreement. Regards, --Mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 1:27 AM, Michael Natterer wrote: Hi all, Currently, the mapping of the Alt and Command keys on the mac is completely screwed: - The key labeled Command maps to GDK_MOD1_MASK (which is essentially interpreted as Alt by all existing code) - The key labeled Alt isn't mapped to any modifier at all Now there is a lot of discussion in these bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=607115 https://bugzilla.gnome.org/show_bug.cgi?id=605799 but at the bottom of all that is the above mentioned problem. After it's fixed we can fix whatever keymap issues in GTK on top. It seems pretty obvious to me that the key labeled Alt should produce GDK_MOD1_MASK because all existing code considers that being the Alt key. The only question is what to map Command to, and we are free to choose whatever, since the behavior will change away from the current one of producing GDK_MOD1_MASK anyway. I personally prefer GDK_META_MASK because it's what the Windows key is mapped to on PC keyboards, but that's not a strong reason (and it is, as saidm completely arbitrary anyway). Opinions? I volunteer to patch up all 3 branches once we come to an agreement. How long have you been using a Mac as your primary computer? On what mac-native programs that you use daily is the alt/OPTION key used as a stand-alone modifier for shortcuts with default settings (any preference changes you've made don't count)? How does the code know what key produces the mod1 bit? Why would it care? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Tue, 2011-09-06 at 06:37 -0700, John Ralls wrote: On Sep 6, 2011, at 1:27 AM, Michael Natterer wrote: Hi all, Currently, the mapping of the Alt and Command keys on the mac is completely screwed: - The key labeled Command maps to GDK_MOD1_MASK (which is essentially interpreted as Alt by all existing code) - The key labeled Alt isn't mapped to any modifier at all Now there is a lot of discussion in these bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=607115 https://bugzilla.gnome.org/show_bug.cgi?id=605799 but at the bottom of all that is the above mentioned problem. After it's fixed we can fix whatever keymap issues in GTK on top. It seems pretty obvious to me that the key labeled Alt should produce GDK_MOD1_MASK because all existing code considers that being the Alt key. The only question is what to map Command to, and we are free to choose whatever, since the behavior will change away from the current one of producing GDK_MOD1_MASK anyway. I personally prefer GDK_META_MASK because it's what the Windows key is mapped to on PC keyboards, but that's not a strong reason (and it is, as saidm completely arbitrary anyway). Opinions? I volunteer to patch up all 3 branches once we come to an agreement. How long have you been using a Mac as your primary computer? On what mac-native programs that you use daily is the alt/OPTION key used as a stand-alone modifier for shortcuts with default settings (any preference changes you've made don't count)? I don't see how this is relevant, but i bow to your experience. How does the code know what key produces the mod1 bit? Why would it care? Code *knows* that MOD1 is Alt, and there is a key named Alt on the keyboard. Therefore it must produce MOD1. There is nothing to argue here. There is no reason to not use that consistency across 3 platforms when we can get it for free. --Mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for next cycle
On 09/06/11 10:05, Alexander Larsson wrote: On Thu, 2011-09-01 at 15:16 -0600, Ryan Lortie wrote: Another option is to use library load constructors to run the initialisation we need to do. That's certainly possible on Windows systems and anything using GCC. I'm not sure if it's possible to do it in a portable way from pure C, though. In my research for how to implement a resource system for glib I've been looking at this. I think its should be possible to do this for all the main platforms we're targeting (linux, elf unixes, win32, osx). There might be some ancient proprietary unix where it will not work (but probably not as this is a C++ requirement too). So, while the code would be kinda hacky to make this work with all weird setups required (like pragmas, ick) it should be quite possible to rely on. In HarfBuzz I'm using the C++ compiler without linking to libstdc++. I found it as very rewarding experience. You get library constructor/destructors for free there. I think this approach to library design has serious merit worth considering. b I have some notes somewhere on how it can be done for all platforms. Will write it up some day. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 4.0 and Clutter 2.0: rainbows and unicorns
Emmanuele Bassi ebassi at gmail.com writes: a) drop GTK+, move to Clutter and port the complex widges over; b) re-implement Clutter inside GTK+; c) use Clutter between GDK and GTK+; I would translate that as: a) tell GTK developers their code is crap b) tell Clutter developers their code is crap c) make Clutter and GTK developers work together on the best of both worlds I have a good idea what solution causes the least tension here... ;) the Clutter UI description format is JSON and not XML because I honestly don't like XML at all, and GtkBuilder/GtkBuildable was in the wrong position in the stack (GTK instead of GLib) and exposing the wrong API (GMarkup to create custom parsers); on the other hand, ClutterScript made JSON-GLib possible. I still maintain that the person that writes and maintains the parser and the UI for editing gets to decide what format we use. I can handcraft JSON and XML files that test GTK. I can even handcraft binary files to break things if I need to. And nobody else does care, because they'll all be using the editor anyway. (right? :)) Last but not least, I can also live with JSON existing in Clutter and XML existing in GTK. One of them will not work on the GTK level, so Clutter also has some cool concepts like Constraints, which are similar to SizeGroups/Alignments; Actions, which are objects that set up actors to provide high level concepts like click/long-click, gesture recognition, drag and drop; and Effects, which are post-processing filters that use GPU shaders or rendering to offscreen framebuffers. So, let's say we think these concepts are awesome and we want them in GTK. In particular, actions are something I'd want in GTK preferably right now so that when we do the switch in event bubbling, there's not that many event handlers left to fix. How do we do that? We don't want to introduce GTK API that is in effect identical to the Clutter API. And we don't want to depend on Clutter. Is there a solution that can work for this? obviously, we cannot shove Clutter as it is inside GTK and call it a day: both Clutter and GTK would require extensive API changes. there are a couple of different ways of incorporating Clutter inside GTK. one is going the CoreAnimation route, and have GtkWidget exposing a ClutterActor as part of its class; essentially, any GtkWidget would be able to embed a ClutterActor - and be embedded inside a ClutterActor. There is one thing I'd like to do, and that is providing state for the drawing operations we do in GTK. An entry would no longer need to do complex computations whenever it draws[1] (frame, text, progressbar and icons) and doesn't need to do complex border, margin and padding computations for each of them, but it would just have Frame, Text, Progressbar and Icon render objects, that took care of this job. They'd of course need to hook into the CSS theming infrastructure to get their rendering informations. And it seems to me it's a good idea to use ClutterActors for that. If in the end we make GtkWidget a ClutterActor or if we just delegate stuff, I don't think that matters a lot. In particular because changing from one to the other just requires changing 3 lines of code. ;) - drop containers and make the scene graph explicitly part of the ClutterActor API; The question of how to present containers in the public API is an interesting one. I poked you about this on IRC, so I won't go into the arguments here and don't want you to answer, but I'll point it out anyway so people reading this can think about it: There is 3 consumers of a container interface to an Actor/Widget: 1) someone implementing a subclass of the Actor/Widget 2) application developers using Actors/Widgets and reading API documentation 3) development tools like glade They all need to be able but not confused about what they are allowed to do and what they aren't allowed to do. So group 1 needs the ability to add child actors to any actor, but groups 2 and 3 should never do that unless the actor really is a container. Basically, you want to expose a protected add/remove() function and only make it public for real containers. Do we have a way how we support this in GObject? - drop Rectangle, Texture, and CairoTexture sub-classes and move towards a delegate approach for painting the contents of the actor; - fully retained painting model using primitives; Could you elaborate on the reasons for that a bit more? From looking at WebKit (who has a render object/html element split), GTK and Clutter (who don't, but apparently want to have) and talking to Tim about Rapicorn[2] (which has very few real widgets that render themselves and everything else is a container of those widgets) I've never managed to find the ideal split here. Because the render objects definitely need to be used for layout (their size is kinda important) and input (you need to know if you clicked on them after all). And at that point they are pretty
Re: GLib plans for next cycle
On Tue, 2011-09-06 at 10:14 -0400, Behdad Esfahbod wrote: In HarfBuzz I'm using the C++ compiler without linking to libstdc++. I found it as very rewarding experience. You get library constructor/destructors for free there. I think this approach to library design has serious merit worth considering. Ha! I was just writing an email along the lines of why don't we just compile a tiny bit of C++ code? before thinking oh... but then we'd have to link libstdc++ and closing the compose window. Good to hear :) Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.29.90
GLib 2.29.90 is ready. http://download.gnome.org/sources/glib/2.29/ 95af3f46a40ad1a3ecfe75db59b27956b256c4ad02f000be2aa13c7abd32fba3 glib-2.29.90.tar.xz I consider this to be (almost) a release candidate. There is probably a bug in GSettings that is causing lots of problems with gnome-settings-daemon that will need to be fixed before the next cycle. Other than that, we're more or less frozen -- it should mostly be docs and translations in the next release. There are two API breaks in this release with respect to the previous. One is a rename and the other is simple removal of a function that was only added in the last micro release. See below. Overview of changes from GLib 2.29.18 to 2.29.90 * API/ABI changes: - unix signal watches now match the API of all of the other sources - revert the addition of g_date_time_source_new () from last release * networking and other fixes for Solaris - we no longer support symbolic port names (ie: from /etc/services) - check if -lsocket is needed - fix g_socket_details_from_fd() - avoid getmntinfo - fix some harmless warnings * GDateTime improvements: - generally improved standards compliance (with C99) - support C99-specified format strings: %g, %G, %V, %c, %C, %w - consult the locale for the preferred 12-hour time format (%r) - drop support for non-standard %N and broken %W - better support for formatting non-POSIX (eg: Arabic) numerals - locale-related test case fixups, and fix some leaks * GTlsInteraction: add interaction method invocation guarantees * gdbus-codegen: post-process all interfaces when parsing 1 file * make GMainLoop, GMainContext and GSource boxed types * fix a race condition in the first use of g_get_monotonic_time() * lots gtk-doc cleanups * better intltool compatibility when generating pot file * avoid GCC-specific compiler options when not using GCC * Translation updates: Belarusian Brazilian Portuguese Canadian English Galician Indonesian Korean Lithuanian Norwegian bokmål Portuguese Spanish Swedish Thanks to everyone who helped: Alexandre Franke Andika Triwidada Aurimas Černius Changwoo Ryu Chun-wei Fan Dan Winship Daniel Nylander Duarte Loreto Fran Dieguez Ihar Hrachyshka Javier Jardón Jorge González Kjartan Maraas Matthias Clasen Og B. Maciel Patrick Welche Pavel Holejsovsky Stef Walter Tomas Bzatek Will Thompson Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.30 branch
hi,
GLib has branched for the stable release ('glib-2-30'). All translation
effort should be focused there (since this is what will appear in GNOME
3.2).
The branch is to be considered frozen for code changes, except by
approval.
Thanks
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for next cycle
On Tue, 2011-09-06 at 10:48 -0400, Behdad Esfahbod wrote: On 09/06/11 10:42, Ryan Lortie wrote: On Tue, 2011-09-06 at 10:14 -0400, Behdad Esfahbod wrote: In HarfBuzz I'm using the C++ compiler without linking to libstdc++. I found it as very rewarding experience. You get library constructor/destructors for free there. I think this approach to library design has serious merit worth considering. Ha! I was just writing an email along the lines of why don't we just compile a tiny bit of C++ code? before thinking oh... but then we'd have to link libstdc++ and closing the compose window. Yeah, the trick is to pass -fno-rtti -fno-exceptions to g++. In fact, libtool already has code to do this if your C compiler turns out to be a C++ compiler. It's the macro _LT_COMPILER_NO_RTTI. I've emailed libtool maintainers to ask to make this public. This is specific to gnu g++ though. If you want to target only that then you might as well just use the gnu c extensions to do library constructors in plain C. I have plain C ways to implement this for most systems, although we could use the C++ trick as a fallback. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 4.0 and Clutter 2.0: rainbows and unicorns
Exciting topic. Just a few comments scattered through the email... On Tue, 2011-09-06 at 14:26 +, Benjamin Otte wrote: Emmanuele Bassi ebassi at gmail.com writes: a) drop GTK+, move to Clutter and port the complex widges over; b) re-implement Clutter inside GTK+; c) use Clutter between GDK and GTK+; I would translate that as: a) tell GTK developers their code is crap b) tell Clutter developers their code is crap c) make Clutter and GTK developers work together on the best of both worlds I have a good idea what solution causes the least tension here... ;) the Clutter UI description format is JSON and not XML because I honestly don't like XML at all, and GtkBuilder/GtkBuildable was in the wrong position in the stack (GTK instead of GLib) and exposing the wrong API (GMarkup to create custom parsers); on the other hand, ClutterScript made JSON-GLib possible. I still maintain that the person that writes and maintains the parser and the UI for editing gets to decide what format we use. I can handcraft JSON and XML files that test GTK. I can even handcraft binary files to break things if I need to. And nobody else does care, because they'll all be using the editor anyway. (right? :)) Last but not least, I can also live with JSON existing in Clutter and XML existing in GTK. One of them will not work on the GTK level, so For the record, having a common serialization framework would make things much, much easier for the guys trying to generate this stuff. If, for instance GtkBuilder was indeed GBuilder, and would have been the obvious choice for ClutterScript... The result would have been: - Someone creates clutter-gtk widgets (already done) - Someone easily integrates the clutter widget into Glade catalog (some have done privately, quite easy to do as it stands) - The 'GtkClutter' widget could simply extend the definition of it's xml with the GBuildable interface, simply by creating ClutterActors from the embedded GBuilder xml. All ClutterActors, simply by nature of being GObjects, would be automatically supported by Glade, the only remaining work to be done to create clutter projects in Glade would be the UI. However unfortunately, things did not go down this road, and so we are that much further from editing ClutterScript, at least from Glade (and combined with GTK+ from Glade). Clutter also has some cool concepts like Constraints, which are similar to SizeGroups/Alignments; Actions, which are objects that set up actors to provide high level concepts like click/long-click, gesture recognition, drag and drop; and Effects, which are post-processing filters that use GPU shaders or rendering to offscreen framebuffers. So, let's say we think these concepts are awesome and we want them in GTK. In particular, actions are something I'd want in GTK preferably right now so that when we do the switch in event bubbling, there's not that many event handlers left to fix. How do we do that? We don't want to introduce GTK API that is in effect identical to the Clutter API. And we don't want to depend on Clutter. Is there a solution that can work for this? obviously, we cannot shove Clutter as it is inside GTK and call it a day: both Clutter and GTK would require extensive API changes. there are a couple of different ways of incorporating Clutter inside GTK. one is going the CoreAnimation route, and have GtkWidget exposing a ClutterActor as part of its class; essentially, any GtkWidget would be able to embed a ClutterActor - and be embedded inside a ClutterActor. There is one thing I'd like to do, and that is providing state for the drawing operations we do in GTK. An entry would no longer need to do complex computations whenever it draws[1] (frame, text, progressbar and icons) and doesn't need to do complex border, margin and padding computations for each of them, but it would just have Frame, Text, Progressbar and Icon render objects, that took care of this job. They'd of course need to hook into the CSS theming infrastructure to get their rendering informations. And it seems to me it's a good idea to use ClutterActors for that. If in the end we make GtkWidget a ClutterActor or if we just delegate stuff, I don't think that matters a lot. In particular because changing from one to the other just requires changing 3 lines of code. ;) - drop containers and make the scene graph explicitly part of the ClutterActor API; The question of how to present containers in the public API is an interesting one. I poked you about this on IRC, so I won't go into the arguments here and don't want you to answer, but I'll point it out anyway so people reading this can think about it: There is 3 consumers of a container interface to an Actor/Widget: 1) someone implementing a subclass of the Actor/Widget 2) application developers using Actors/Widgets and reading API documentation 3)
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 6:53 AM, Michael Natterer wrote: On Tue, 2011-09-06 at 06:37 -0700, John Ralls wrote: On Sep 6, 2011, at 1:27 AM, Michael Natterer wrote: Hi all, Currently, the mapping of the Alt and Command keys on the mac is completely screwed: - The key labeled Command maps to GDK_MOD1_MASK (which is essentially interpreted as Alt by all existing code) - The key labeled Alt isn't mapped to any modifier at all Now there is a lot of discussion in these bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=607115 https://bugzilla.gnome.org/show_bug.cgi?id=605799 but at the bottom of all that is the above mentioned problem. After it's fixed we can fix whatever keymap issues in GTK on top. It seems pretty obvious to me that the key labeled Alt should produce GDK_MOD1_MASK because all existing code considers that being the Alt key. The only question is what to map Command to, and we are free to choose whatever, since the behavior will change away from the current one of producing GDK_MOD1_MASK anyway. I personally prefer GDK_META_MASK because it's what the Windows key is mapped to on PC keyboards, but that's not a strong reason (and it is, as saidm completely arbitrary anyway). Opinions? I volunteer to patch up all 3 branches once we come to an agreement. How long have you been using a Mac as your primary computer? On what mac-native programs that you use daily is the alt/OPTION key used as a stand-alone modifier for shortcuts with default settings (any preference changes you've made don't count)? I don't see how this is relevant, but i bow to your experience. How does the code know what key produces the mod1 bit? Why would it care? Code *knows* that MOD1 is Alt, and there is a key named Alt on the keyboard. Therefore it must produce MOD1. There is nothing to argue here. There is no reason to not use that consistency across 3 platforms when we can get it for free. Really? Gtk+ is activating the camera in my Macbook and watching me push the alt/option key? Your argument is absurd on its face, as I said in the discussion on bug 607119. As for why using a Mac is relevant, the object of the exercise is to produce programs which are as well-integrated as possible into the Mac user experience. If mac users want to run programs that behave like X11, they run them under X11 (which is provided by Apple as part of the OS, and which initializes automatically when the machine receives an X11 connection request). Users of Gtk programs with the quartz backend want their programs to behave like native programs. Since you don't actually use a Mac, and apparently haven't surveyed mac users, why do you think that you should be able to dictate how they use their computers, or how the Quartz maintainers configure Gtk to work on a Mac? By the way, the key you claim is named Alt is in fact named option; it has a smaller label alt in the upper left corner of the key, just as the command key has a quatrefoil symbol in the upper left corner (older keyboards had an Apple logo on that key as well, and it was often referred to as the Apple key). It is sometimes referred to as the alt/option key, and while it's true that the enum name for it in Cocoa is NSAlternateKey, that's invisible to users. As I've also explained more than once in the long running discussion on 607119, the primary function of the option key is to extend the keyboard for i18n, a feature upon which many European users depend, and which conflicts with using option as a naked accelerator (i.e., without command or control as additional modifiers) in text context -- meaning at all in practice. In other words, you're right that there's nothing to argue, but you're wrong that option should be mapped to Mod1. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Bug 658098 - no way to specify optional domain field in gvfs password dialog
Hello,
The fix to this issue is quite trivial but requires patching all three
of glib, gvfs, gtk.
Also it is not quite obvious that replacing the old NEED_DOMAIN with
HAS_DOMAIN is the best thing.
Any opinions?
Thanks
Michal
Description: Upstream changes introduced in version 2.28.6-2dom1
This patch has been created by dpkg-source during the package build.
Here's the last changelog entry, hopefully it gives details on why
those changes were made:
.
glib2.0 (2.28.6-2dom1) experimental; urgency=low
.
* Add a separate option that specifies a domain is required.
.
The person named in the Author field signed this changelog entry.
Author: Michal Suchanek hramr...@centrum.cz hramr...@ipx7a-ion.ruk.cuni.cz
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
--- glib2.0-2.28.6.orig/gio/gioenums.h
+++ glib2.0-2.28.6/gio/gioenums.h
@@ -500,6 +500,7 @@ typedef enum {
* GAskPasswordFlags:
* @G_ASK_PASSWORD_NEED_PASSWORD: operation requires a password.
* @G_ASK_PASSWORD_NEED_USERNAME: operation requires a username.
+ * @G_ASK_PASSWORD_HAS_DOMAIN: operation may require a domain.
* @G_ASK_PASSWORD_NEED_DOMAIN: operation requires a domain.
* @G_ASK_PASSWORD_SAVING_SUPPORTED: operation supports saving settings.
* @G_ASK_PASSWORD_ANONYMOUS_SUPPORTED: operation supports anonymous users.
@@ -511,9 +512,10 @@ typedef enum {
typedef enum {
G_ASK_PASSWORD_NEED_PASSWORD = (1 0),
G_ASK_PASSWORD_NEED_USERNAME = (1 1),
- G_ASK_PASSWORD_NEED_DOMAIN = (1 2),
+ G_ASK_PASSWORD_HAS_DOMAIN = (1 2),
G_ASK_PASSWORD_SAVING_SUPPORTED= (1 3),
- G_ASK_PASSWORD_ANONYMOUS_SUPPORTED = (1 4)
+ G_ASK_PASSWORD_ANONYMOUS_SUPPORTED = (1 4),
+ G_ASK_PASSWORD_NEED_DOMAIN = (1 5)
} GAskPasswordFlags;
--- glib2.0-2.28.6.orig/gio/gioenumtypes.c
+++ glib2.0-2.28.6/gio/gioenumtypes.c
@@ -495,6 +495,7 @@ g_ask_password_flags_get_type (void)
{ G_ASK_PASSWORD_NEED_PASSWORD, G_ASK_PASSWORD_NEED_PASSWORD, need-password },
{ G_ASK_PASSWORD_NEED_USERNAME, G_ASK_PASSWORD_NEED_USERNAME, need-username },
{ G_ASK_PASSWORD_NEED_DOMAIN, G_ASK_PASSWORD_NEED_DOMAIN, need-domain },
+{ G_ASK_PASSWORD_HAS_DOMAIN, G_ASK_PASSWORD_HAS_DOMAIN, has-domain },
{ G_ASK_PASSWORD_SAVING_SUPPORTED, G_ASK_PASSWORD_SAVING_SUPPORTED, saving-supported },
{ G_ASK_PASSWORD_ANONYMOUS_SUPPORTED, G_ASK_PASSWORD_ANONYMOUS_SUPPORTED, anonymous-supported },
{ 0, NULL, NULL }
Description: Upstream changes introduced in version 1.8.2-1smbdom1
This patch has been created by dpkg-source during the package build.
Here's the last changelog entry, hopefully it gives details on why
those changes were made:
.
gvfs (1.8.2-1smbdom1) experimental; urgency=low
.
* Don't require domain when logging in to samba shares.
.
The person named in the Author field signed this changelog entry.
Author: Michal Suchanek hramr...@centrum.cz hramr...@ipx7a-ion.ruk.cuni.cz
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: http://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
Index: gvfs-1.8.2/daemon/gvfsbackendsmb.c
===
--- gvfs-1.8.2.orig/daemon/gvfsbackendsmb.c 2011-09-06 13:32:54.0 +0200
+++ gvfs-1.8.2/daemon/gvfsbackendsmb.c 2011-09-06 13:34:59.0 +0200
@@ -230,7 +230,7 @@
if (g_vfs_keyring_is_available ())
flags |= G_ASK_PASSWORD_SAVING_SUPPORTED;
if (backend-domain == NULL)
- flags |= G_ASK_PASSWORD_NEED_DOMAIN;
+ flags |= G_ASK_PASSWORD_HAS_DOMAIN;
if (backend-user == NULL)
flags |= G_ASK_PASSWORD_NEED_USERNAME;
Index: gvfs-1.8.2/daemon/gvfsbackendsmbbrowse.c
===
--- gvfs-1.8.2.orig/daemon/gvfsbackendsmbbrowse.c 2011-09-06 13:32:54.0 +0200
+++ gvfs-1.8.2/daemon/gvfsbackendsmbbrowse.c 2011-09-06 13:34:59.0 +0200
@@ -365,7 +365,7 @@
if (g_vfs_keyring_is_available ())
flags |= G_ASK_PASSWORD_SAVING_SUPPORTED;
if (backend-domain
Re: Alt and Command keys in the quartz backend
On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote: On Sep 6, 2011, at 6:53 AM, Michael Natterer wrote: On Tue, 2011-09-06 at 06:37 -0700, John Ralls wrote: On Sep 6, 2011, at 1:27 AM, Michael Natterer wrote: Hi all, Currently, the mapping of the Alt and Command keys on the mac is completely screwed: - The key labeled Command maps to GDK_MOD1_MASK (which is essentially interpreted as Alt by all existing code) - The key labeled Alt isn't mapped to any modifier at all Now there is a lot of discussion in these bug reports: https://bugzilla.gnome.org/show_bug.cgi?id=607115 https://bugzilla.gnome.org/show_bug.cgi?id=605799 but at the bottom of all that is the above mentioned problem. After it's fixed we can fix whatever keymap issues in GTK on top. It seems pretty obvious to me that the key labeled Alt should produce GDK_MOD1_MASK because all existing code considers that being the Alt key. The only question is what to map Command to, and we are free to choose whatever, since the behavior will change away from the current one of producing GDK_MOD1_MASK anyway. I personally prefer GDK_META_MASK because it's what the Windows key is mapped to on PC keyboards, but that's not a strong reason (and it is, as saidm completely arbitrary anyway). Opinions? I volunteer to patch up all 3 branches once we come to an agreement. How long have you been using a Mac as your primary computer? On what mac-native programs that you use daily is the alt/OPTION key used as a stand-alone modifier for shortcuts with default settings (any preference changes you've made don't count)? I don't see how this is relevant, but i bow to your experience. How does the code know what key produces the mod1 bit? Why would it care? Code *knows* that MOD1 is Alt, and there is a key named Alt on the keyboard. Therefore it must produce MOD1. There is nothing to argue here. There is no reason to not use that consistency across 3 platforms when we can get it for free. Really? Gtk+ is activating the camera in my Macbook and watching me push the alt/option key? Your argument is absurd on its face, as I said in the discussion on bug 607119. As for why using a Mac is relevant, the object of the exercise is to produce programs which are as well-integrated as possible into the Mac user experience. If mac users want to run programs that behave like X11, they run them under X11 (which is provided by Apple as part of the OS, and which initializes automatically when the machine receives an X11 connection request). Users of Gtk programs with the quartz backend want their programs to behave like native programs. Since you don't actually use a Mac, and apparently haven't surveyed mac users, why do you think that you should be able to dictate how they use their computers, or how the Quartz maintainers configure Gtk to work on a Mac? By the way, the key you claim is named Alt is in fact named option; it has a smaller label alt in the upper left corner of the key, just as the command key has a quatrefoil symbol in the upper left corner (older keyboards had an Apple logo on that key as well, and it was often referred to as the Apple key). It is sometimes referred to as the alt/option key, and while it's true that the enum name for it in Cocoa is NSAlternateKey, that's invisible to users. As I've also explained more than once in the long running discussion on 607119, the primary function of the option key is to extend the keyboard for i18n, a feature upon which many European users depend, and which conflicts with using option as a naked accelerator (i.e., without command or control as additional modifiers) in text context -- meaning at all in practice. In other words, you're right that there's nothing to argue, but you're wrong that option should be mapped to Mod1. I don't talk about *behavior* here, that is entirely GTK's business. I'm talking about what modifiers we should map the apple keys to, that's completely unrelated, and only a business of GDK. Can I please have an opinion from some other people, preferably somebody who is willing to discuss, instead of just rubbing their superior knowledge in my face? --Mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Tue, 2011-09-06 at 12:58 -0400, Paul Davis wrote: On Tue, Sep 6, 2011 at 12:49 PM, Michael Natterer mi...@gimp.org wrote: On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote: [ ... imminent turf war ... ] this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics the problem is that (2) includes GTK, not just applications, and GTK already makes this assumption. as a result, john changed the modifier that alt/option generates on OS X, because (2) is not true for OS X. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. That's not what I'm asking for. The only special meaning of Alt in GTK is to invoke mnemonics. Other than that, it's simply a modifier. Same on the Mac, it's just a modifier. Let's just disable the mnemonics on the Mac then. The fact that the OS uses it to generate special characters is not really relevant here. One X11 window manager steals key combo A from the app, the other one key combo B, there is nothing I can do about this. Turning Alt into Alt fixes more than it breaks. It fixes e.g. configuring GTK keybindings (you can easily make Alt-cursor do word navigation then, the config file says alt, it's all correctly mapped, the modifier says alt, and it just works). And it's not just key bindings. Alt-click should be alt-click, there is nothing wrong about that. If the OS decides to use it for its own purposes, then it's the job of higher-level code to be aware of that. If we need to change something in GTK as a consequence of that change, then so be it, but please let's not do strange stuff to the quartz' backend's modifier mapping just to accommodate some code in GTK that was never meant to handle the Mac, but can easily be changed to simply do it. --Mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 4.0 and Clutter 2.0: rainbows and unicorns
hi Benjamin; it's going to be a long email... :-) On 2011-09-06 at 14:26, Benjamin Otte wrote: Emmanuele Bassi ebassi at gmail.com writes: a) drop GTK+, move to Clutter and port the complex widges over; b) re-implement Clutter inside GTK+; c) use Clutter between GDK and GTK+; I would translate that as: a) tell GTK developers their code is crap b) tell Clutter developers their code is crap c) make Clutter and GTK developers work together on the best of both worlds I have a good idea what solution causes the least tension here... ;) I know you intended this for comedic effects, but (to be serious for a second) I don't think ditching either toolkit would be seen as a judgement on the quality of the code. I know that there are lots of places in both where the code is crap — but even if we reimplemented either toolkit on top of the other, a lot of the code would be salvageable. the issue is, as usual, is resources. we can pool the (small) resources we have or just start quasi-from-scratch and take (WARNING: number pulled out of my arse) five times as much. the Clutter UI description format is JSON and not XML because I honestly don't like XML at all, and GtkBuilder/GtkBuildable was in the wrong position in the stack (GTK instead of GLib) and exposing the wrong API (GMarkup to create custom parsers); on the other hand, ClutterScript made JSON-GLib possible. I still maintain that the person that writes and maintains the parser and the UI for editing gets to decide what format we use. I can handcraft JSON and XML files that test GTK. I can even handcraft binary files to break things if I need to. And nobody else does care, because they'll all be using the editor anyway. (right? :)) Last but not least, I can also live with JSON existing in Clutter and XML existing in GTK. One of them will not work on the GTK level, so I totally agree: we need a UI tool, and the UI tool can decided whatever to use — after all, libglade existed for years outside of GTK and everything was (almost) fine. the real issue is the format chosen when a widget (or an actor) want to intercept the deserialization or the serialization process, and intervene. ClutterState's description inside JSON is really ad hoc; same goes for GtkListStore in XML. you don't want to encode that inside the parsing code, because that would make third party objects impossible to define. the crux of the matter is that both the GtkBuildable and ClutterScriptable interfaces expose the parsing mechanism (and format) inside the API — GMarkupParser for the former, and JsonNode for the latter. nowadays we have a serialization/deserialization format in GVariant, but then again, you'd have to deserialize an on-disk format like JSON or XML into GVariant first. well, JSON-GLib already can... ;-) Clutter also has some cool concepts like Constraints, which are similar to SizeGroups/Alignments; Actions, which are objects that set up actors to provide high level concepts like click/long-click, gesture recognition, drag and drop; and Effects, which are post-processing filters that use GPU shaders or rendering to offscreen framebuffers. So, let's say we think these concepts are awesome and we want them in GTK. In particular, actions are something I'd want in GTK preferably right now so that when we do the switch in event bubbling, there's not that many event handlers left to fix. How do we do that? We don't want to introduce GTK API that is in effect identical to the Clutter API. And we don't want to depend on Clutter. Is there a solution that can work for this? no idea. if we don't want to depend on Clutter then we'll have to write that code somewhere — and the code is tightly coupled with the signals and with the event handling code. the Actions in Clutter, for instance, use captured-event on the stage, as well as other API like suspending the picking when dragging an actor around; or disabling the motion event throttling when doing gesture recognition; or detecting the actor underneath the pointer to check for a drop point. - drop containers and make the scene graph explicitly part of the ClutterActor API; The question of how to present containers in the public API is an interesting one. I poked you about this on IRC, so I won't go into the arguments here and don't want you to answer, but I'll point it out anyway so people reading this can think about it: There is 3 consumers of a container interface to an Actor/Widget: 1) someone implementing a subclass of the Actor/Widget 2) application developers using Actors/Widgets and reading API documentation 3) development tools like glade They all need to be able but not confused about what they are allowed to do and what they aren't allowed to do. So group 1 needs the ability to add child actors to any actor, but groups 2 and 3 should never do that unless the actor really is a container. Basically, you want to expose a
GTK and OSX: a call to sanity
okay, I've tried to get ahold of the gtk-osx project for a while, now, but since sf.net is just a joke and decided to reject my @gmail.com emails, let's try here. can we *please* stop this madness: 17:05 CIA-8 jralls quartz-integration * r7e37d94f2178 gtk+/ (10 files in 4 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * rf75a882670a8 gtk+/ (9 files in 4 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r8c288f0f890e gtk+/ (24 files in 7 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r41abe4a72f16 gtk+/ (4 files in 3 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r964b25d17b45 gtk+/ (35 files in 3 dirs): Merge branch 'master' into quartz-integration if there are patches for gtk-quartz, why are these inside at least three branches instead of being committed to corresponding main line one? why are these branch continuously being merged instead of being rebased, if they are personal branches? why are the tools to make bundles and modulesets hosted on github instead of being on gnome.org? why is gtk-osx a separate project, with mailing lists hosted on sourceforge, instead of being on gnome.org? every time that a project maintainer decides to use sourceforge, the Universe kills a puppy. can we please, *please*, for the love of all that's nice and pure in this Universe, stop killing puppies? ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 9:58 AM, Paul Davis wrote: On Tue, Sep 6, 2011 at 12:49 PM, Michael Natterer mi...@gimp.org wrote: On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote: [ ... imminent turf war ... ] this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics the problem is that (2) includes GTK, not just applications, and GTK already makes this assumption. as a result, john changed the modifier that alt/option generates on OS X, because (2) is not true for OS X. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. Actually, that was last changed by Richard Hult in 2008 [1], about 6 months before I got involved. I think I'd go further and require that the MODX masks be made private to GDK before I'd agree that it's moot. Even with the MOD1 hardcoding in Gtk removed there are still lots of other cases running around, and we'd still get complaints like Michael's that it's somehow broken. Regards, John Ralls [1] http://git.gnome.org/browse/gtk+/commit/gdk?id=31357d3cc7d37e5b0fe674835406c255a961a358 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Tue, Sep 6, 2011 at 2:12 PM, Emmanuele Bassi eba...@gmail.com wrote: okay, I've tried to get ahold of the gtk-osx project for a while, now, but since sf.net is just a joke and decided to reject my @gmail.com emails, let's try here. can we *please* stop this madness: 17:05 CIA-8 jralls quartz-integration * r7e37d94f2178 gtk+/ (10 files in 4 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * rf75a882670a8 gtk+/ (9 files in 4 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r8c288f0f890e gtk+/ (24 files in 7 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r41abe4a72f16 gtk+/ (4 files in 3 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r964b25d17b45 gtk+/ (35 files in 3 dirs): Merge branch 'master' into quartz-integration if there are patches for gtk-quartz, why are these inside at least three branches instead of being committed to corresponding main line one? i'm not the maintainer, but i'll just rapidly note that quartz-integration is not part of gtk-osx at this time. if and when GtkApplication takes on a palpably cross-platform feel, there may be some place for it within GTK, but right now it does stuff (e.g. management of the global menubar) that has no real slot within GTK. there are (at least) 3 modulesets because of the breakage that tends to happen with gtk-osx when parts of the gtk stack are modified by people who feel that its the role of the gtk-osx people to make the changes work on OS X. one is very old and stable (if broken) stuff; one is newer, with some patches and is generally OK; one corresponds to current git (or equivalent) for the whole GTK stack. the latter one tends to be unusable quite often; the first one is not bad but too old. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 10:42 AM, Michael Natterer wrote: On Tue, 2011-09-06 at 12:58 -0400, Paul Davis wrote: On Tue, Sep 6, 2011 at 12:49 PM, Michael Natterer mi...@gimp.org wrote: On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote: [ ... imminent turf war ... ] this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics the problem is that (2) includes GTK, not just applications, and GTK already makes this assumption. as a result, john changed the modifier that alt/option generates on OS X, because (2) is not true for OS X. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. That's not what I'm asking for. The only special meaning of Alt in GTK is to invoke mnemonics. Other than that, it's simply a modifier. Same on the Mac, it's just a modifier. Let's just disable the mnemonics on the Mac then. The fact that the OS uses it to generate special characters is not really relevant here. One X11 window manager steals key combo A from the app, the other one key combo B, there is nothing I can do about this. Turning Alt into Alt fixes more than it breaks. It fixes e.g. configuring GTK keybindings (you can easily make Alt-cursor do word navigation then, the config file says alt, it's all correctly mapped, the modifier says alt, and it just works). And it's not just key bindings. Alt-click should be alt-click, there is nothing wrong about that. If the OS decides to use it for its own purposes, then it's the job of higher-level code to be aware of that. If we need to change something in GTK as a consequence of that change, then so be it, but please let's not do strange stuff to the quartz' backend's modifier mapping just to accommodate some code in GTK that was never meant to handle the Mac, but can easily be changed to simply do it. It's not really different. Getting rid of the hard-coded association between alt in an accelerator map or key binding and GDK_MOD1_MASK is part of Paul's (2). I'd map it to GDK_META_MASK, but I'm open to super, hyper, or a new GDK_ALT_MASK (bit 25, perhaps). It *is* the right thing to do, I think, but it's not a quartz-only change and it probably would not be welcome in gtk+-2.24. This doesn't have anything to do with being able to map option-d to an accelerator map item altd and have it work. It won't. (At present in master altd will map to command-d, which works fine and presents only a documentation problem to the app developer.) Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib plans for next cycle
On Wed, 2011-08-31 at 12:17 -0700, David Zeuthen wrote: Hi, On Wed, Aug 31, 2011 at 1:06 PM, Ryan Lortie de...@desrt.ca wrote: - glib_get_worker_context() s/glib/g/ ? glib_* sounds like it's for glib-internal-only use, which I don't see any reason for. It's definitely useful outside of glib. My original intention is that it *would* be glib-private (like glib_gettext() for example). It's true that other libraries could find it useful, though -- dconf would certainly put itself on this list. I'm just slightly worried about this thread becoming contaminated (think: mainloop blocking) through use by poorly written libraries. That's my concern too. In fact, for reasons like this, I'm not happy about on having GDBus use it unless someone can demonstrate significant savings - and, honestly, in these days where the CPUs worth targeting with GLib are all multi-core, putting all of our crap in a single worker thread is probably a performance hit (but I doubt it's measurable). Maybe the time to discuss pulling in an api something like Grand Central Dispatch has arrived? :) Kevin David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 6:58 PM, Paul Davis wrote: this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics I have typically avoided the debate on modifiers/etc. since I am not very familiar with the X11 background of them either. The two things you set out indeed seem to make much sense to me. The big question to me is around (2), if MOD1 is passed by GDK, should GTK+ or an application still include cross-platform handling or should the cross-platform handling already been taken care of? I get the impression that given that keybindings still need cross-platform porting at the GTK+ level, the former is perhaps not a strange assumption. For the former, having modifiers bound to keys with similar labels is, I *think*, helpful for implementing the cross-platform handling in GTK+ and/or applications. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. My impression is that GTK+ has to be fixed first here before we can consider binding the key labeled with Alt to MOD1 like is done on other platforms. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Tue, 2011-09-06 at 21:51 +0200, Kristian Rietveld wrote: On Sep 6, 2011, at 6:58 PM, Paul Davis wrote: this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics I have typically avoided the debate on modifiers/etc. since I am not very familiar with the X11 background of them either. The two things you set out indeed seem to make much sense to me. The big question to me is around (2), if MOD1 is passed by GDK, should GTK+ or an application still include cross-platform handling or should the cross-platform handling already been taken care of? I get the impression that given that keybindings still need cross-platform porting at the GTK+ level, the former is perhaps not a strange assumption. For the former, having modifiers bound to keys with similar labels is, I *think*, helpful for implementing the cross-platform handling in GTK+ and/or applications. I agree, and I would argue like this about ALT/MOD1: - on GTK+, ALT/MOD1 are used for mnemonics, which are typically translatable, which means unforeseeable, so cannot really be used for apps. - on the Mac, ALT/Option is used for generating special chars, which are different per keyboard layout, which means unforeseeable, so cannot really be used for apps. So there is no conflict here, see below. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. My impression is that GTK+ has to be fixed first here before we can consider binding the key labeled with Alt to MOD1 like is done on other platforms. IMHO for the ALT/MOD1 mapping to work nicely, we simply need to hardcode gtk-enable-mnemonics to FALSE and we're done. Apps are used to have Alt-foo being taken by the system in an unpredictable way, and Alt-mouse interaction will just start working on the Mac too, so will keybindings that use Alt. Note that key bindings don't have above being taken problem, since they will typically modify a widget's key binding to do exactly what the respective Mac control does, so there should be no conflict. Did I miss anything here? --Mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Sep 6, 2011, at 11:12 AM, Emmanuele Bassi wrote: okay, I've tried to get ahold of the gtk-osx project for a while, now, but since sf.net is just a joke and decided to reject my @gmail.com emails, let's try here. can we *please* stop this madness: 17:05 CIA-8 jralls quartz-integration * r7e37d94f2178 gtk+/ (10 files in 4 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * rf75a882670a8 gtk+/ (9 files in 4 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r8c288f0f890e gtk+/ (24 files in 7 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r41abe4a72f16 gtk+/ (4 files in 3 dirs): Merge branch 'master' into quartz-integration 17:05 CIA-8 jralls quartz-integration * r964b25d17b45 gtk+/ (35 files in 3 dirs): Merge branch 'master' into quartz-integration if there are patches for gtk-quartz, why are these inside at least three branches instead of being committed to corresponding main line one? why are these branch continuously being merged instead of being rebased, if they are personal branches? why are the tools to make bundles and modulesets hosted on github instead of being on gnome.org? why is gtk-osx a separate project, with mailing lists hosted on sourceforge, instead of being on gnome.org? every time that a project maintainer decides to use sourceforge, the Universe kills a puppy. can we please, *please*, for the love of all that's nice and pure in this Universe, stop killing puppies? Emmanuele, You could have written me directly: my email address is in the git repositories, attached to the commits that you're complaining about. The tools and modulesets are on GitHub because that's where Richard Hult put them when he started 5 or 6 years ago and I haven't had time to change that since getting commit privs on git.gnome.org last year. What bothers you about it? Gtk-OSX is a separate project hosted on Sourceforge because Richard was using the facilities of his company, Imendio, which he had just dissolved. Those resources weren't available to me. The barriers to setting up a full project on Gnome including mailing lists, a bugtracker, web fora, source repositories, web pages, and ftp downloads seem daunting and time consuming -- while I (or anyone else) can have it set up on Sourceforge in a few hours with a single request. Sourceforge is working well hosting all of that stuff and no puppies are being killed -- nor is anything else bad happening. I'm sorry that you're irritated by the noise of the daily merges between master and quartz-integration, and between gtk-2.24 and gtk-2.24-quartz. Those tracking branches exist because I want to make it easy for application developers to use my changes to quartz, synchronized with the latest changes on the masters of each branch. Kris Reitveld asked me to wait until he reviews the patches to commit them to the mainline branches, and since his review is very valuable (he has a much deeper knowledge of the codebase than I do) I am complying with his request. If the noise from the merges is really that annoying I can easily move the quartz branches to Github and delete them from git.gnome.org. Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 12:10 PM, Michael Natterer wrote: On Tue, 2011-09-06 at 11:57 -0700, John Ralls wrote: On Sep 6, 2011, at 10:42 AM, Michael Natterer wrote: On Tue, 2011-09-06 at 12:58 -0400, Paul Davis wrote: On Tue, Sep 6, 2011 at 12:49 PM, Michael Natterer mi...@gimp.org wrote: On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote: [ ... imminent turf war ... ] this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics the problem is that (2) includes GTK, not just applications, and GTK already makes this assumption. as a result, john changed the modifier that alt/option generates on OS X, because (2) is not true for OS X. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. That's not what I'm asking for. The only special meaning of Alt in GTK is to invoke mnemonics. Other than that, it's simply a modifier. Same on the Mac, it's just a modifier. Let's just disable the mnemonics on the Mac then. The fact that the OS uses it to generate special characters is not really relevant here. One X11 window manager steals key combo A from the app, the other one key combo B, there is nothing I can do about this. Turning Alt into Alt fixes more than it breaks. It fixes e.g. configuring GTK keybindings (you can easily make Alt-cursor do word navigation then, the config file says alt, it's all correctly mapped, the modifier says alt, and it just works). And it's not just key bindings. Alt-click should be alt-click, there is nothing wrong about that. If the OS decides to use it for its own purposes, then it's the job of higher-level code to be aware of that. If we need to change something in GTK as a consequence of that change, then so be it, but please let's not do strange stuff to the quartz' backend's modifier mapping just to accommodate some code in GTK that was never meant to handle the Mac, but can easily be changed to simply do it. It's not really different. Getting rid of the hard-coded association between alt in an accelerator map or key binding and GDK_MOD1_MASK is part of Paul's (2). I'd map it to GDK_META_MASK, but I'm open to super, hyper, or a new GDK_ALT_MASK (bit 25, perhaps). It *is* the right thing to do, I think, but it's not a quartz-only change and it probably would not be welcome in gtk+-2.24. It is not the right thing to do. Why do you insist on that, and what is wrong about the hard-coded association between ALT and MOD1_MASK? What is the problem about fixing GDK to map Alt to what is globally considered Alt, and then fix the platform-specific things in GTK+ afterwards? For one thing, the platform-specific stuff belongs in Gdk. That's why there's gdk/broadway, gdk/quartz, gdk/wayland, gdk/win32, and gdk/x11. Yes, there are gtkdnd-quartz, gtkclipboard-quartz, gtkstatusicon-quartz, and (in quartz-integration) gtkselection-quartz. That's an unfortunate side effect of the main implementations being so closely tied to the X11 model that they couldn't be integrated with quartz at the gdk level, and it breaks the multiple-backend feature of Gtk+-3. For another, key-mapping is done in gdk as the very first step in processing a native key-down/up event (well, OK, the second step, the first being to decide that it's a key-down/up event and to dispatch it to the key-mapping routine). That is, of course, in a virtualized gdk function call. You're proposing to then reinterpret those key-down/up events in gtk? That seems rather complicated. Nothing is wrong with alt being mapped to GDK_MOD1_MASK so long as NSCommandKey is also mapped to GDK_MOD1_MASK. Why do you object to that? Is it that the GIMP documenters don't want to write (Command-foo on Macs) next to every occurrence of The accelerator for Bar is Alt-foo? Regards, John Ralls ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Tue, Sep 6, 2011 at 5:30 PM, John Ralls jra...@ceridwen.us wrote: Nothing is wrong with alt being mapped to GDK_MOD1_MASK so long as NSCommandKey is also mapped to GDK_MOD1_MASK. Why do you object to that? Is it that the GIMP documenters don't want to write (Command-foo on Macs) next to every occurrence of The accelerator for Bar is Alt-foo? for several years, i've distributed binaries of Ardour built against a GTK stack that bound Alt/Option to MOD1 and Command to META. it worked fine, but that's partly because we have a codebase that attempts to never use any GDK_modifier_MASK values directly, and because our documentation is written to be pre-processed into OS X and X11 specific versions. i recently built versions against the current GTK stack in which the bindings are different, and this immediately breaks the existing bindings for all our users. its my responsibility because i patched the original GTK and i chose to use the current bindings that john put in place. the only thing worse than this debate is the possibility of flip-flopping several more times, thus invalidating the keybindings our users have in place each time. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 1:13 PM, Michael Natterer wrote: On Tue, 2011-09-06 at 21:51 +0200, Kristian Rietveld wrote: On Sep 6, 2011, at 6:58 PM, Paul Davis wrote: this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics I have typically avoided the debate on modifiers/etc. since I am not very familiar with the X11 background of them either. The two things you set out indeed seem to make much sense to me. The big question to me is around (2), if MOD1 is passed by GDK, should GTK+ or an application still include cross-platform handling or should the cross-platform handling already been taken care of? I get the impression that given that keybindings still need cross-platform porting at the GTK+ level, the former is perhaps not a strange assumption. For the former, having modifiers bound to keys with similar labels is, I *think*, helpful for implementing the cross-platform handling in GTK+ and/or applications. I agree, and I would argue like this about ALT/MOD1: - on GTK+, ALT/MOD1 are used for mnemonics, which are typically translatable, which means unforeseeable, so cannot really be used for apps. - on the Mac, ALT/Option is used for generating special chars, which are different per keyboard layout, which means unforeseeable, so cannot really be used for apps. So there is no conflict here, see below. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. My impression is that GTK+ has to be fixed first here before we can consider binding the key labeled with Alt to MOD1 like is done on other platforms. IMHO for the ALT/MOD1 mapping to work nicely, we simply need to hardcode gtk-enable-mnemonics to FALSE and we're done. Apps are used to have Alt-foo being taken by the system in an unpredictable way, and Alt-mouse interaction will just start working on the Mac too, so will keybindings that use Alt. Note that key bindings don't have above being taken problem, since they will typically modify a widget's key binding to do exactly what the respective Mac control does, so there should be no conflict. Did I miss anything here? Uh, won't hard coding gtk-enable-mnemonics=FALSE (I suppose you mean the GtkSettings property, and that you propose to do it inside of some sort of a runtime check for the quartz backend) mean that all keybindings, regardless of what modifier keys they use, *don't* work? Have you actually tried any of these things? On a Mac? With the deadkeys patch [1]? No? Why don't you, and when you get it working post your patch on Bug 607115 [2]? You might find the test program I posted there [3] helpful in understanding how the Apple keyboard differs from the Microsoft one. It should compile in a gtk-osx or macports-quartz environment with 'gcc -o keytest keytest.c `pkg-config --cflags --libs gtk+-3.0`' Regards, John Ralls [1] https://bugzilla.gnome.org/attachment.cgi?id=175439 [2] https://bugzilla.gnome.org/show_bug.cgi?id=607115 [3] https://bugzilla.gnome.org/attachment.cgi?id=175074 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Tue, Sep 6, 2011 at 5:51 PM, John Ralls jra...@ceridwen.us wrote: Uh, won't hard coding gtk-enable-mnemonics=FALSE (I suppose you mean the GtkSettings property, and that you propose to do it inside of some sort of a runtime check for the quartz backend) mean that all keybindings, regardless of what modifier keys they use, *don't* work? there are at least 3 key binding mechanisms in GTK. mnemonics are just one of them. ardour, for example, uses no mnemonics anywhere, but binds almost every single key (and every single key+modifer) combination. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On 2011-09-06 at 13:32, John Ralls wrote: if there are patches for gtk-quartz, why are these inside at least three branches instead of being committed to corresponding main line one? why are these branch continuously being merged instead of being rebased, if they are personal branches? why are the tools to make bundles and modulesets hosted on github instead of being on gnome.org? why is gtk-osx a separate project, with mailing lists hosted on sourceforge, instead of being on gnome.org? every time that a project maintainer decides to use sourceforge, the Universe kills a puppy. can we please, *please*, for the love of all that's nice and pure in this Universe, stop killing puppies? The tools and modulesets are on GitHub because that's where Richard Hult put them when he started 5 or 6 years ago and I haven't had time to change that since getting commit privs on git.gnome.org last year. What bothers you about it? that something that should be in a central location is not. in order to build gtk on OSX I have to hunt down various bits and blobs, and the barrier to contribution from me, a gtk developer, is higher. Gtk-OSX is a separate project hosted on Sourceforge because Richard was using the facilities of his company, Imendio, which he had just dissolved. Those resources weren't available to me. The barriers to setting up a full project on Gnome including mailing lists, a bugtracker, web fora, source repositories, web pages, and ftp downloads seem daunting and time consuming -- while I (or anyone else) can have it set up on Sourceforge in a few hours with a single request. Sourceforge is working well hosting all of that stuff and no puppies are being killed -- nor is anything else bad happening. sourceforge is working so well that it bounces and rejects my emails to the mailing lists for days. their bug tracking system is the scourge of the earth, and the mailing list archives are a joke. but those are moot points: the gtk resources *are* on gnome.org. why you need a separate mailing list and forum and bug tracker is beyond me: • once you have a Git account you can create repositories on git.gnome.org in 30 seconds; • the gtk bug tracking system in bugzilla.gnome.org; the Quartz backend specific bugs have a component under the gtk+ product; • the separate tools for OS X integration can get a separate product just by opening a bug on bugzilla.gnome.org; • the gtk website is hosted in git.gnome.org; the OS X integration should be part of that website; • downloads are available from download.gnome.org; • gtk has three mailing lists already: gtk-list, gtk-app-devel-list and gtk-devel-list; application and toolkit development on OS X is on topic on those three lists. there is no time consumption — just the willingness to cooperate in an open source project according to the rules of said open source project. I'm sorry that you're irritated by the noise of the daily merges between master and quartz-integration, I'm moderately irritated by the fact that the branch's history is immensely fucked up — but that's just because I'm OCD on the history in a revision control system. that is, however, *not* my issue. the issue is that those branches should *not* exist, unless they are personal development branches. if you plan on letting other users target them then you should get those commits merged into the main line and keep the patches in bugzilla, where the review for gtk fixes and enhancements happens. otherwise you're just forking gtk, and using the resources of the gtk project to give an aura of officiality to what is essentially your own personal project. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Tue, Sep 6, 2011 at 6:07 PM, Emmanuele Bassi eba...@gmail.com wrote: otherwise you're just forking gtk, and using the resources of the gtk project to give an aura of officiality to what is essentially your own personal project. I'd politely request that you stop using this tone in connection with this issue. There has always been a level of antagonism between developers working on GTK for OS X and the core development team. It rises and falls, and at present, things are generally in remarkably good shape, where most of what is required to get a fully functional GTK for OS X is right there in the tarball releases. But when you start ripping into one of the only people willing to actually step up and take any responsibility for the issues faced by those of us that actually want to use GTK+ as a cross-platform development toolkit where the platforms include OS X, its remarkably scary. Other people have walked away from the effort because of the perception of the core GTK guys just don't give a shit, and it doesn't help in any way that you take such an argumentative tone with john. I appreciate that you believe that using gnome.org's infrastructure is all incredibly easy. You've been using it for quite some time, and done most of the things that anyone might want to do with it. John hasn't, and his real goal is for all of the work that he or Kris (or occasionally even me) do to end up in GTK+ releases, without caring too much about how things get done *before* merging into the mainline. The attitude you're displaying here is just another reason for yet another person to walk away from that task, and its not as if there has ever been a queue of people waiting to take over what Richard and now John have done (similarly with Tor's work on the windows side of things). So please could you tone it down a bit, and rather than excoriate John for whatever you perceive his mistakes or whatever to be, focus on helpful suggestions. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Sharing the places sidebar between Nautilus and GTK+
Hi, everyone, There is a patch in [1], by Jon McCann, to make the shortcuts bar in GtkFileChooser be pretty much the same as the one in Nautilus. Rather than patch the wobbly edifice that is gtkfilechooserdefault.c, this sounds like the perfect time to actually pull out the shortcuts bar as a public class of its own, that is shared by both the file chooser and Nautilus. My plan is this: 1. Copy nautilus-places-sidebar.[ch] into the GTK+ sources. 2. s/nautilus/gtk 3. Remove obvious nautilus-isms like the use of nautilus_bookmark, which should be easy enough to replicate in GTK+ (or with things which already happen through the file chooser's code). 4. See what common, public interfaces we need. For example, nautilus_window_set_initiated_unmount (sidebar-window, TRUE); seems like it could be replaced with a signal on the GtkPlacesSidebar class, and then Nautilus can start a spinner or whatever when an unmount operation starts. Another common interface would be something like gtk_places_sidebar_select_path (sidebar, file:///foo/selected) to highlight a particular item. 5. See what nautilus-isms *should* be doable with plain GIO, and see if there is anything else that Nautilus needs to do about them via signals; maybe for something like nautilus_file_operations_mount_volume_full (NULL, volume, volume_mounted_cb, G_OBJECT (sidebar)); 6. See what things should be available or not in the file chooser... when dropping files on the shortcuts bar, Nautilus can do nautilus_file_operations_copy_move (uris, NULL, drop_uri, real_action, GTK_WIDGET (tree_view), NULL, NULL); Same thing for nautilus_file_operations_empty_trash (GTK_WIDGET (sidebar-window)); I'm starting a branch in GTK+, places-sidebar to do this. Comments are appreciated, especially from Nautilus hackers who may know dark places in this code well. One little caveat: that part of Nautilus is GPL, and GTK+ is LGPL, although it *seems* that the places sidebar code may initially have come from GTK+ and then reworked heavily. I haven't checked the history closely. What do we do about this? [1] https://bugzilla.gnome.org/show_bug.cgi?id=642712#c4 Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Alt and Command keys in the quartz backend
On Tue, 2011-09-06 at 14:30 -0700, John Ralls wrote: On Sep 6, 2011, at 12:10 PM, Michael Natterer wrote: On Tue, 2011-09-06 at 11:57 -0700, John Ralls wrote: On Sep 6, 2011, at 10:42 AM, Michael Natterer wrote: On Tue, 2011-09-06 at 12:58 -0400, Paul Davis wrote: On Tue, Sep 6, 2011 at 12:49 PM, Michael Natterer mi...@gimp.org wrote: On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote: [ ... imminent turf war ... ] this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics the problem is that (2) includes GTK, not just applications, and GTK already makes this assumption. as a result, john changed the modifier that alt/option generates on OS X, because (2) is not true for OS X. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. That's not what I'm asking for. The only special meaning of Alt in GTK is to invoke mnemonics. Other than that, it's simply a modifier. Same on the Mac, it's just a modifier. Let's just disable the mnemonics on the Mac then. The fact that the OS uses it to generate special characters is not really relevant here. One X11 window manager steals key combo A from the app, the other one key combo B, there is nothing I can do about this. Turning Alt into Alt fixes more than it breaks. It fixes e.g. configuring GTK keybindings (you can easily make Alt-cursor do word navigation then, the config file says alt, it's all correctly mapped, the modifier says alt, and it just works). And it's not just key bindings. Alt-click should be alt-click, there is nothing wrong about that. If the OS decides to use it for its own purposes, then it's the job of higher-level code to be aware of that. If we need to change something in GTK as a consequence of that change, then so be it, but please let's not do strange stuff to the quartz' backend's modifier mapping just to accommodate some code in GTK that was never meant to handle the Mac, but can easily be changed to simply do it. It's not really different. Getting rid of the hard-coded association between alt in an accelerator map or key binding and GDK_MOD1_MASK is part of Paul's (2). I'd map it to GDK_META_MASK, but I'm open to super, hyper, or a new GDK_ALT_MASK (bit 25, perhaps). It *is* the right thing to do, I think, but it's not a quartz-only change and it probably would not be welcome in gtk+-2.24. It is not the right thing to do. Why do you insist on that, and what is wrong about the hard-coded association between ALT and MOD1_MASK? What is the problem about fixing GDK to map Alt to what is globally considered Alt, and then fix the platform-specific things in GTK+ afterwards? For one thing, the platform-specific stuff belongs in Gdk. That's why there's gdk/broadway, gdk/quartz, gdk/wayland, gdk/win32, and gdk/x11. Yes, there are gtkdnd-quartz, gtkclipboard-quartz, gtkstatusicon-quartz, and (in quartz-integration) gtkselection-quartz. That's an unfortunate side effect of the main implementations being so closely tied to the X11 model that they couldn't be integrated with quartz at the gdk level, and it breaks the multiple-backend feature of Gtk+-3. For another, key-mapping is done in gdk as the very first step in processing a native key-down/up event (well, OK, the second step, the first being to decide that it's a key-down/up event and to dispatch it to the key-mapping routine). That is, of course, in a virtualized gdk function call. You're proposing to then reinterpret those key-down/up events in gtk? That seems rather complicated. I have no idea what you are talking about. Nothing is wrong with alt being mapped to GDK_MOD1_MASK so long as NSCommandKey is also mapped to GDK_MOD1_MASK. Why do you object to that? Is it that the GIMP documenters don't want to write (Command-foo on Macs) next to every occurrence of The accelerator for Bar is Alt-foo? Why on earth would you want to map both keys to the same modifier? Nobody uses Alt for accelerators, I don't think we are talking about the same things here, in GTK+: - Accelerator is the thing to invoke actions (menu shortcuts) - invoked by Command on the mac, and by Control on != Mac. - Mnemonic is the thing that invokes the
Re: Alt and Command keys in the quartz backend
On Tue, Sep 6, 2011 at 6:46 PM, Michael Natterer mi...@gimp.org wrote:
Nobody uses Alt for accelerators, I don't think we are talking
about the same things here, in GTK+:
http://viewcvs.ardour.org/index.cgi/ardour2/ardour2/branches/2.0-ongoing/gtk2_ardour/mnemonic-us.bindings.in?revision=9232view=markup
sorry :) we do *try* to avoid naked altkey modifiers, mostly
because of X11 WM conventions.
- Accelerator is the thing to invoke actions (menu shortcuts)
- invoked by Command on the mac, and by Control on != Mac.
- Mnemonic is the thing that invokes the underlined stuff
- invoked by Alt on != Mac, doesn't exist on the Mac
in any sane world (or toolkit),
actions AND items in menus == things invokable by the user via
{keyboard/mouse/touch/other}
its been acknowledged that in the real world, GTK will try to move
towards this. the distinction is arbitrary, more so when you consider
the number of ways of making a given key do something in GTK.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Sep 6, 2011, at 3:07 PM, Emmanuele Bassi wrote: On 2011-09-06 at 13:32, John Ralls wrote: if there are patches for gtk-quartz, why are these inside at least three branches instead of being committed to corresponding main line one? why are these branch continuously being merged instead of being rebased, if they are personal branches? why are the tools to make bundles and modulesets hosted on github instead of being on gnome.org? why is gtk-osx a separate project, with mailing lists hosted on sourceforge, instead of being on gnome.org? every time that a project maintainer decides to use sourceforge, the Universe kills a puppy. can we please, *please*, for the love of all that's nice and pure in this Universe, stop killing puppies? The tools and modulesets are on GitHub because that's where Richard Hult put them when he started 5 or 6 years ago and I haven't had time to change that since getting commit privs on git.gnome.org last year. What bothers you about it? that something that should be in a central location is not. in order to build gtk on OSX I have to hunt down various bits and blobs, and the barrier to contribution from me, a gtk developer, is higher. Gtk-OSX is a separate project hosted on Sourceforge because Richard was using the facilities of his company, Imendio, which he had just dissolved. Those resources weren't available to me. The barriers to setting up a full project on Gnome including mailing lists, a bugtracker, web fora, source repositories, web pages, and ftp downloads seem daunting and time consuming -- while I (or anyone else) can have it set up on Sourceforge in a few hours with a single request. Sourceforge is working well hosting all of that stuff and no puppies are being killed -- nor is anything else bad happening. sourceforge is working so well that it bounces and rejects my emails to the mailing lists for days. their bug tracking system is the scourge of the earth, and the mailing list archives are a joke. but those are moot points: the gtk resources *are* on gnome.org. why you need a separate mailing list and forum and bug tracker is beyond me: • once you have a Git account you can create repositories on git.gnome.org in 30 seconds; • the gtk bug tracking system in bugzilla.gnome.org; the Quartz backend specific bugs have a component under the gtk+ product; • the separate tools for OS X integration can get a separate product just by opening a bug on bugzilla.gnome.org; • the gtk website is hosted in git.gnome.org; the OS X integration should be part of that website; • downloads are available from download.gnome.org; • gtk has three mailing lists already: gtk-list, gtk-app-devel-list and gtk-devel-list; application and toolkit development on OS X is on topic on those three lists. there is no time consumption — just the willingness to cooperate in an open source project according to the rules of said open source project. I'm sorry that you're irritated by the noise of the daily merges between master and quartz-integration, I'm moderately irritated by the fact that the branch's history is immensely fucked up — but that's just because I'm OCD on the history in a revision control system. that is, however, *not* my issue. the issue is that those branches should *not* exist, unless they are personal development branches. if you plan on letting other users target them then you should get those commits merged into the main line and keep the patches in bugzilla, where the review for gtk fixes and enhancements happens. otherwise you're just forking gtk, and using the resources of the gtk project to give an aura of officiality to what is essentially your own personal project. I'm not going to respond to most of that. Suffice it to say that building gtk-osx is largely automated, and there are well-tested instructions at http://sourceforge.net/apps/trac/gtk-osx/wiki/Build I didn't get commit privs at Gnome.org until just under a year ago, 18 months after I took over from Richard. I still don't have privs on any of the other facilities except Bugzilla, and there only because I'm a Gnucash Dev. (That turns out to be sufficient for almost everything.) Gtk-OSX needs its own mailing list because it provides jhbuild modules for over 100 separate projects, not all of which are even Gnome. It's not feasible for me to monitor all of them for support, nor is it reasonable for users of my build scripts to have to figure out which one to use for any particular problem. It's not a fork of Gtk+ (yet, though on days like this one I get really tempted). I actually revived the gtk-osx project on SF; the previous version was an actual fork of Gtk1. As I explained earlier, the changes *are* patches, they *are* attached to bugs in Bugzilla, and Kris Reitveld *has* promised to review them. When he has had time to do so and they have been polished to his high standards, they
Re: Alt and Command keys in the quartz backend
On Sep 6, 2011, at 3:46 PM, Michael Natterer wrote: On Tue, 2011-09-06 at 14:30 -0700, John Ralls wrote: On Sep 6, 2011, at 12:10 PM, Michael Natterer wrote: On Tue, 2011-09-06 at 11:57 -0700, John Ralls wrote: On Sep 6, 2011, at 10:42 AM, Michael Natterer wrote: On Tue, 2011-09-06 at 12:58 -0400, Paul Davis wrote: On Tue, Sep 6, 2011 at 12:49 PM, Michael Natterer mi...@gimp.org wrote: On Tue, 2011-09-06 at 08:27 -0700, John Ralls wrote: [ ... imminent turf war ... ] this seems to be about two different things, neither of which are in conflict (and i think john actually agrees with this). 1) whether or not the Alt key should generate MOD1 as a modifier 2) whether or not code that wants to be cross-platform can assume that they can use MOD1 with its own chosen semantics the problem is that (2) includes GTK, not just applications, and GTK already makes this assumption. as a result, john changed the modifier that alt/option generates on OS X, because (2) is not true for OS X. if (2) was fixed so that GTK was not an example of code that assumes that MOD1 is free for any interpretation on any platform, then (1) is moot, and it really doesn't matter what the Alt key generates on OS X (hence, it could be MOD1). but as long as (2) remains an issue within GTK itself, its hard to argue that a key that has clearly different purposes for a large body of platform users of OS X should be handled by GTK as if it had some different meaning based on another platform. That's not what I'm asking for. The only special meaning of Alt in GTK is to invoke mnemonics. Other than that, it's simply a modifier. Same on the Mac, it's just a modifier. Let's just disable the mnemonics on the Mac then. The fact that the OS uses it to generate special characters is not really relevant here. One X11 window manager steals key combo A from the app, the other one key combo B, there is nothing I can do about this. Turning Alt into Alt fixes more than it breaks. It fixes e.g. configuring GTK keybindings (you can easily make Alt-cursor do word navigation then, the config file says alt, it's all correctly mapped, the modifier says alt, and it just works). And it's not just key bindings. Alt-click should be alt-click, there is nothing wrong about that. If the OS decides to use it for its own purposes, then it's the job of higher-level code to be aware of that. If we need to change something in GTK as a consequence of that change, then so be it, but please let's not do strange stuff to the quartz' backend's modifier mapping just to accommodate some code in GTK that was never meant to handle the Mac, but can easily be changed to simply do it. It's not really different. Getting rid of the hard-coded association between alt in an accelerator map or key binding and GDK_MOD1_MASK is part of Paul's (2). I'd map it to GDK_META_MASK, but I'm open to super, hyper, or a new GDK_ALT_MASK (bit 25, perhaps). It *is* the right thing to do, I think, but it's not a quartz-only change and it probably would not be welcome in gtk+-2.24. It is not the right thing to do. Why do you insist on that, and what is wrong about the hard-coded association between ALT and MOD1_MASK? What is the problem about fixing GDK to map Alt to what is globally considered Alt, and then fix the platform-specific things in GTK+ afterwards? For one thing, the platform-specific stuff belongs in Gdk. That's why there's gdk/broadway, gdk/quartz, gdk/wayland, gdk/win32, and gdk/x11. Yes, there are gtkdnd-quartz, gtkclipboard-quartz, gtkstatusicon-quartz, and (in quartz-integration) gtkselection-quartz. That's an unfortunate side effect of the main implementations being so closely tied to the X11 model that they couldn't be integrated with quartz at the gdk level, and it breaks the multiple-backend feature of Gtk+-3. For another, key-mapping is done in gdk as the very first step in processing a native key-down/up event (well, OK, the second step, the first being to decide that it's a key-down/up event and to dispatch it to the key-mapping routine). That is, of course, in a virtualized gdk function call. You're proposing to then reinterpret those key-down/up events in gtk? That seems rather complicated. I have no idea what you are talking about. Nothing is wrong with alt being mapped to GDK_MOD1_MASK so long as NSCommandKey is also mapped to GDK_MOD1_MASK. Why do you object to that? Is it that the GIMP documenters don't want to write (Command-foo on Macs) next to every occurrence of The accelerator for Bar is Alt-foo? Why on earth would you want to map both keys to the same modifier? Nobody uses Alt for accelerators, I don't think we are talking about the same things here, in GTK+: - Accelerator is the thing to invoke actions (menu shortcuts) - invoked by Command on the mac, and by Control on != Mac. - Mnemonic is the thing that invokes the
Re: Sharing the places sidebar between Nautilus and GTK+
On Tue, 06 Sep 2011 17:44:01 -0500
Federico Mena Quintero feder...@gnome.org wrote:
Hi, everyone,
There is a patch in [1], by Jon McCann, to make the shortcuts bar in
GtkFileChooser be pretty much the same as the one in Nautilus.
Rather than patch the wobbly edifice that is gtkfilechooserdefault.c,
this sounds like the perfect time to actually pull out the shortcuts
bar as a public class of its own, that is shared by both the file
chooser and Nautilus.
My plan is this:
1. Copy nautilus-places-sidebar.[ch] into the GTK+ sources.
To be honest, I think we can do better than this. The user experience
offered by the current places sidebar is far from ideal IMHO. In
Nautilus 3.x
* the sidebar has no mount/eject progress indicators,
* the eject buttons do not look/feel clickable, i.e., they don't
change their appearance on hover events,
* and the categories are a bit messed up (e.g. I have a few disks in
Computer, other in Devices; mounted archives pop up in
Network) and so on.
Of course, some of these missing features are due to cell renderer
limitations, e.g. last time I tried, I couldn't get hover-in/hover-out
events for individual cells to work good enough to implement a
fully-working button renderer. But still, the places sidebar has more
potential and the current implement feels somewhat half-baked.
For Thunar, I'm currently working on a widget to replace the
GtkTreeView in the sidebar:
http://mocha.xfce.org/~jannis/screenshots/xfce/thunar-shortcuts-pane-custom-20110604-1.png
This sidebar consists of four classes (ThunarShortcutsModel
and ThunarShortcut for modeling the data, the custom widgets
ThunarShortcutsView and ThunarShortcutRow for representing the view
with its rows). You can already check out the current state here:
http://git.xfce.org/xfce/thunar/log/?h=jannis/new-shortcuts-pane
I realize that, aside from the code still being somewhat rough and
imcomplete, this is nothing we'd want to stuff into GTK+. In
particular, faking the look of a tree view with custom widgets may seem
like a hack to most people (even though standard GTK+ drawing routines
are used). On the other hand it is fun to use and shows how the places
sidebar *could* work IMHO:
* progress indicators for async operations,
* real mount/eject/cancel buttons ('cuz spinners alone are not
enough),
* individual row/button highlighting on hover,
* keyboard navigation works (even switching between rows and
buttons is possible),
* a GtkTreeModel is used to model the data,
* all file information is resolved asynchronously, and
* categories are less cluttered and messed up (every location pops up
only once; archives and devices appear in Devices,
personal folders and bookmarks appear in Places, remote locations
and the Network button show up in Network).
I guess what I'm trying to say is... if you merge something like the
places sidebar into GTK+ (as part of the public API), don't just take
the existing sidebar as it is; please improve it to make really useful.
I'd be happy to drop our sidebar if there's a good one in GTK+ (and if
there's anything I can do to help with that, let me know).
- Jannis
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sharing the places sidebar between Nautilus and GTK+
On Wed, 7 Sep 2011 01:53:44 +0200 Jannis Pohlmann jan...@xfce.org wrote: (snip) On the other hand it is fun to use and shows how the places sidebar *could* work IMHO: (snip) BTW, here's a (possibly incomplete) list of features we're aiming at with the new Thunar sidebar. I think they are really worth working towards: http://wiki.xfce.org/design/thunar/shortcuts-pane#summarized_requirements_list_and_implementation_status - Jannis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
