Input event reduction
Well, I think I have asked this already some years ago at gtk-list. (And I spent some hours experimenting with stuff like event_pending() and such, without success.) It is still the old problem: We have input events, for example keystrokes, and a function that can only process a few events per second. What we want: If there are more than one event of this type pending (in the queue) than discard all but the last one. That seems to be really hard in GTK3. One solution, which is used in the NEd Nim editor: Create a separate task, send the events though a channel to that task. That channel behaves like a queue, so the task can discard events easily and process always only the last one. Problem is, that GTK is not thread safe, so that task can not do GUI update itself, but has to use an Idle_Add function. All that works fine, but that is more than 10 lines of code for such a trivial problem. Currently I get the "changed" signal of a GTk Text Buffer -- when the user types fast, there may be up to ten function calls per second initiated. Processing these realtime is still possible on a fast CPU, but to save resources (battery power for example) it would be better to drop a few events when there are many, but always process the last one. (Task here is smart syntax check or syntax highlight, so the last input is always what matters most.) Timer events would be an option, but that would imply a permanent delay. What we want instead is immediate reaction when there are input events. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: SpinButton size
On Mon, 2017-03-27 at 14:23 +, Rúben Rodrigues wrote:
> hi guysm
>
> it's possible to change size of spinbuttons? In touchscreen mode
> spinbutton are still small.. We can change it's size with css
> provider?
>
>
That may be possible...
I found some example code in gedit C sources for changing widget sizes,
that code has changed from GTK version to GTK version. For 3.20 I have
working code like:
# from 3.20 gedit-documents-panel.c
let closeButton = button(newObject(typeButton, "relief", ReliefStyle.NONE,
"focus-on-click", false, nil))
let context = closeButton.getStyleContext
context.addClass("flat")
context.addClass("small-button")
let icon = newThemedIconWithDefaultFallbacks("window-close-symbolic")
let image: Image = newImage(icon, IconSize.MENU)
objectUnref(icon)
closeButton.add(image)
discard gSignalConnect(closeButton, "clicked", gCallback(closeTab), scrolled)
Well, that is not for spin button, but ordinary button. And again you
did not said if you want a solution for GTK2 or GTK4 on macosx.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: SpinButton size
Hi,
Thsnks.
I need for GTK3
On 29-03-2017 08:51, Stefan Salewski wrote:
> On Mon, 2017-03-27 at 14:23 +, Rúben Rodrigues wrote:
>> hi guysm
>>
>> it's possible to change size of spinbuttons? In touchscreen mode
>> spinbutton are still small.. We can change it's size with css
>> provider?
>>
>>
> That may be possible...
>
> I found some example code in gedit C sources for changing widget sizes,
> that code has changed from GTK version to GTK version. For 3.20 I have
> working code like:
>
># from 3.20 gedit-documents-panel.c
>let closeButton = button(newObject(typeButton, "relief", ReliefStyle.NONE,
> "focus-on-click", false, nil))
>let context = closeButton.getStyleContext
>context.addClass("flat")
>context.addClass("small-button")
>let icon = newThemedIconWithDefaultFallbacks("window-close-symbolic")
>let image: Image = newImage(icon, IconSize.MENU)
>objectUnref(icon)
>closeButton.add(image)
>discard gSignalConnect(closeButton, "clicked", gCallback(closeTab),
> scrolled)
>
> Well, that is not for spin button, but ordinary button. And again you
> did not said if you want a solution for GTK2 or GTK4 on macosx.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Wed, 2017-03-29 at 09:42 +0200, Stefan Salewski wrote: > It is still the old problem: Well, after some thinking I have the feeling that it may work with only an idle function, so no separate thread and message passing is necessary: The callback set a flag indicating that there is work to do, and calls the idle function unless the idle function is still working. That idle functions has an outer loop, which tests the flag and returns if unset. Otherwise it clears the flag and does the work. Will test soon... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Wed, 2017-03-29 at 16:47 +0200, Stefan Salewski wrote: > On Wed, 2017-03-29 at 09:42 +0200, Stefan Salewski wrote: > > > > It is still the old problem: > > Well, after some thinking I have the feeling that it may work with > only > an idle function, so no separate thread and message passing is > necessary: The callback set a flag indicating that there is work to > do, > and calls the idle function unless the idle function is still > working. > That idle functions has an outer loop, which tests the flag and > returns > if unset. Otherwise it clears the flag and does the work. Will test > soon... > Yes, basically that works fine. Problem is the idle function added with https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-idle-add I have the strong feeling, that the provided function is not running silently in the background, but it is just called at some point and then blocks user input until the function terminates. At least, when that function is added with g-idle-add on GtkTextBuffer changed signal and that functions does only a delay of 2000 ms, then for that time user input into text buffer is blocked. That was not what I expected. And it is bad, user input becomes a bit sluggish. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
Il Wed, 29 Mar 2017 21:27:48 +0200 Stefan Salewski scrisse: > ... > > Problem is the idle function added with > > https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-idle-add > > I have the strong feeling, that the provided function is not running > silently in the background, ... Hi Stefan, idle functions do *not* run in the background so if you don't release the CPU you will experience what you described. AFAIK all the GMainLoop code is single-threaded hence, as a consequence, you will block the UI whenever the CPU is busy running your code, being it inside a signal handler, a timeout function or (as in your case) an idle function. Just avoid loops when you know they are expensive. Instead leverage the cyclic nature of GMainLoop for iterating over your code, i.e. by respawning your idle function as much as needed. Ciao. -- Nicola ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
