Re: GTK+ meetup at Guadec
On Tue, 2012-07-31 at 00:20 +0200, Philip Chimento wrote: > On Sat, Jul 28, 2012 at 3:30 PM, Matthias Clasen > wrote: > > - We need to document how one extends GTK+ itself (eg how to create a > > new widget class), to make it easier for new people to get involved > > (I'll try to get this started) > > I wrote a tutorial on extending GtkContainer in C > (http://ptomato.name/advanced-gtk-techniques/html/custom-container.html). > It's even current for 3.0. I wrote it for the advanced developer > rather than the new one, but perhaps you can recycle some of it. I think Matthias' comment has more to do with: - Adding the C files and headers to the correct sections of the Makefile.am - Making sure all the functions are documented - Add the filenames and sections to the API docs - Adding the new symbols to be exported - Adding a test application or widget to gtk-demo - Adding the AVAILABLE_IN... macro to the public headers etc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: deprecating gdk threads
On 7/29/2012 12:09 PM, Matthias Clasen wrote: I've put patches for deprecating the gdk threading api at https://bugzilla.gnome.org/show_bug.cgi?id=680754 Review appreciated. I'd like to bring up the issue of how language bindings should cope with this. Basically, the consensus from previous discussions even in language bindings, it is up to application authors to handle callbacks coming in another threads by wrapping code which needs to manipulate GTK into function/closure and schedule its execution via GLib.idle_add(). While this works generally pretty well (except that it puts the burden of knowing that the callback might be invoked in non-main thread to the application developer), there is unresolved issue with regard to destructors/finalizers. Higher level languages typically use some form of garbage collection and thus the time when finalizers are invoked are not deterministic. AFAIK python invokes finalizer callbacks from separate thread, Lua uses the same thread which is currently executing the Lua context, I'm not sure about other languages but I guess that it is similar. In the end, this means that finalizers (which typically invoke g_object_unref()) can be invoked in the context of any thread and application/binding has generally little control over this. AFAICS, this does not play nice with gdk threads deprecation, because one way to solve the GC finalization problems was to gdk_threads_enter() before entering g_object_unref() call. One way to solve this would be to put the burden on the bindings implementation, and force the bindings to queue g_object_unref() calls using g_idle_add() to be executed in the main thread. This seems to be rather ineffective though. Another way to solve this problem might be inside GDK itself, which might check whether native window disposal function needs to be transferred to the main thread and if yes, do it internally and transparently. The advantages are: + it is done only when needed (eg only on Win32/Quartz/whatever, only when called from 'bad' thread, only when g_object_unref() actually results in window destruction) + much more error prone - the actual native window destroy function can be called 'asynchronously' from the POV of the caller. - someone has to implement this :-( Thanks for reading and for any and all comments. pavel ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
On Thu, 2012-08-02 at 08:52 -0400, Morten Welinder wrote: > GtkSwitch bugs me. It really should just have been a styling of the toggle > button since it performs the same function with a different look. But no, > it is currently a totally separate widget not even derived from GtkButton. I could not agree more. --mitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
Hey :), On jue, 2012-08-02 at 11:42 +0200, Simon Schampijer wrote: > Hi, > > there have been several discussions around GTK+ touch support during > GUADEC. To get a good touch experience we talked about the following > points. I ordered them by priority that we set in Sugar development for > them. If you come across something that we missed, please comment. > > === 1. Text selection === > A lot of work has been going into text selection and manipulation those > days from the design and implementation point of view. The current > design ideas can be seen at [1]. > > Carlos created universally usable handles (implemented using GtkWindows) Just a minor annotation, GDK_WINDOW_TEMP GdkWindows > to adjust the selection and wrote the code to use them in GtkEntry and > the GtkTreeView in this branch [2]. The idea is to make those available > as well for external widgets, e.g. in Abiword or WebKitGTK. I'll update that branch in the following days with opposite-sided handles and other minor improvements. > > We discussed as well how the Edit Palette should look like and agreed > loosely on using GtkWindows instead of an Overlay for this to handle > cases like resizing windows for example. > > Something to check is if we want to allow to adjust the selection in > moving the right handle over the left one. Both iOS and Android do block > that and snap to the minimum selection when releasing the finger which > seems a good interaction model and limits complexity and edge cases. Given the loose interaction between the GtkTextHandle helper object and the text widgets, that'd be per-widget implementation, hard to avoid though. > > Another thing to make sure is that we do not use fixed positions in > regards to Wayland. > > > === 2. OSK - Slide canvas vertically to keep insertion point visible === > Carlos has been working on this already. He will send a mail with more > info about it. To get more background about the issue itself a > whitepaper is available at [3]. I'll better advance the rationale here. The target of this work was to extend GtkIMContext to let onscreen keyboards announce the extents the keyboard is going to take, so for example (mostly?) GtkScrolledWindows can move the focus to a visible location if necessary. Likely the root question here is whether this should be entirely a compositor task or a toolkit-level task, if this is handled by the compositor (eg. moving the window altogether) there's probably some important context lost if the window scrolls upwards (toolbars, etc). If this is fully handled by the toolkit there are other corner cases as well, such as scrolled windows falling entirely within the keyboard extents. So probably a mixed approach would be best, although it's a bit unclear when applies what and how to best coordinate those. I've pushed wip/im-osk-position with the initial work about this, it's notably missing a GdkDisplay/Screen argument in the signaling, and this concept altogether is likely not quite friendly with wayland... > > > === 3. SpinButton === > We had several discussions around the SpinButton. One thing that came up > is why we do not want to reuse the existing one. One option is to put > the '<' on the left side (this could be done by a property for example). > When the SpinButton was redesigned they put the < and > close together > to not interfere with other widgets at the left side. Having something > like "[button] < | 3| >" might not be as clear. That at last was the > reasoning for putting the stepper buttons next to each other. In touch > the interaction gets a bit fiddly having the buttons next to each other > that is why we propose that configuration option. > > We would keep the entry widget, on touch you can use the OSK to set a > value, or you can set it to be non-editable. Furthermore you can accept > a vertical swipe to alter the value, implementing this would be a > perfect use case for EventControllers. It also could be a good use for captured events, so touch events only focus the entry on tap, and change-value-as-you-swipe works after a threshold. > > Another option is introducing a complete new widget targeted at touch > usage (similar to the one in iOS Garageband) [4] which Carlos > implemented already [5]. The issue is here the height, which at least in > a Sugar toolbar could be not as ideal and introducing a new widget. Another open question there is about the widget implementing GtkOrientable, so "buttons" (and the swipe gesture) can be aligned on both axes. The big plus of this widget though is the better behavior on touch devices, so it could maybe stand as less useful if GtkSpinButton gains a similar behavior. Cheers, Carlos > > > === 4. Which GTK+ widgets break with touch === > The SpinButton item from above is one example of those. Another one was > the Combobox which has been fixed by Carlos and landed in master [6]. I > will have a look if I come across more. Feel free to add i
Re: next steps for touch support in GTK+
>> Another option is introducing a complete new widget targeted at touch >> usage (similar to the one in iOS Garageband) [4] which Carlos implemented >> already [5]. The issue is here the height, which at least in a Sugar toolbar >> could be not as ideal and introducing a new widget. > > > votes++. The spin button in gtk3 has already been bastardized from its > original mouse/kbd/space-friendly form. add TouchSpinButton or something and > leave the old one alone. 'bastardized' is a rather unfriendly term for improved. Maybe explain how the old design was mouse friendly, or how the new one is not keyboard friendly ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: next steps for touch support in GTK+
On 12-08-03 09:21 PM, Matthias Clasen wrote: Another option is introducing a complete new widget targeted at touch usage (similar to the one in iOS Garageband) [4] which Carlos implemented already [5]. The issue is here the height, which at least in a Sugar toolbar could be not as ideal and introducing a new widget. votes++. The spin button in gtk3 has already been bastardized from its original mouse/kbd/space-friendly form. add TouchSpinButton or something and leave the old one alone. 'bastardized' is a rather unfriendly term for improved. Maybe explain how the old design was mouse friendly, or how the new one is not keyboard friendly ? This issue could be resolved by making a "mobile" UI toolkit in parallel to (and based on the same libraries as) the existing desktop toolkit (maybe gtk-mobile-3.0?). Why not have a separate set of mobile/touch widgets in a separate library? In terms of usability, desktop and mobile interfaces are completely different beasts and "bastardizing"[1] (not my word) one toolkit type into the other is bound to make everyone annoyed. Cheers, Matthew Brush (random GTK-app developer and armchair critic) [1] http://developer.gnome.org/gtk3/3.4/GtkColorChooserDialog.html ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
GtkIMContext popup for on-screen-keyboard
Hello, I've tried everything I could but could not find any solution to this: I use a GtkIMContext to pop up a button to active the on-screen-keyboard via dbus (without any intention to actually do any IM communication). However, if that GtkIMContext gets activated, it subsequently renders the entry unusable because (apparently I can't just create a "transparent" GtkIMContext). Any ideas how to solve that? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
