Text box can be used to set DPI

[sizzlesloth]

resolves #423

I've found clicking and dragging the sliders to set DPIs to be a bit finnicky, so I have added GtkEntry objects where the DPI labels would appear. This allows for setting the DPI via keyboard input.

Changes

• Text boxes show DPIs that have been previously set
• Text boxes and sliders affect each others' values
• Text box is set to nearest supported DPI if a random value is set
• Text boxes only allow numerical input
• ResolutionRow() init takes reference to ResolutionsPage as to call _on_row_activated() when the DPI text box is focused.

[staticssleever668]

Even a simple set_text call on Gtk.Entry when signal callbacks are present is enough to trigger those warnings. Seems to be a pygobject bug: https://gitlab.gnome.org/GNOME/pygobject/-/issues/12

Looks like Lutris has had same warnings at some point, and they fixed it by sub-classing Gtk.Entry: https://github.com/lutris/lutris/issues/394 Piper uses UI files for defining widgets, so in our case work-around would be more ugly

[sizzlesloth]

Even a simple set_text call on Gtk.Entry when signal callbacks are present is enough to trigger those warnings. Seems to be a pygobject bug: https://gitlab.gnome.org/GNOME/pygobject/-/issues/12

Looks like Lutris has had same warnings at some point, and they fixed it by sub-classing Gtk.Entry: lutris/lutris#394 Piper uses UI files for defining widgets, so in our case work-around would be more ugly

Following the advice from https://bugzilla.gnome.org/show_bug.cgi?id=708676 I have suppressed all warnings except for the one originating from Gio.py. I'll need to investigate this more, but the warning occurs before anything in the method to handle text input is run, so probably something to do with the signalling.

with warnings.catch_warnings():
    warnings.simplefilter("ignore")
    self.dpi_entry.set_text(str(value))

If we made a class to wrap around Gtk.Entry, would we not be able to use it in the UI files? I'm not familiar with GTK or UI files. What would make it uglier? While suppressing the warnings isn't too bad currently because we're not doing it much, I think it would be a good idea to do something like Lutris' solution in the future if Gtk Entry components end up being used more.

[sizzlesloth]

Seems like the issue occurs due to another instance of this same bug, where some parameters - like position, are invalid when handled using signals. The last assertion warning that I haven't suppressed yet is in Gio.py (when handling the insert-text signal). It seems like a solution is to make a class that inherits both Gtk.Entry and Gtk.Editable with a method inside for handling the insert-text signal. The position parameter is handled correctly by doing this, and inheriting Editable stops the warnings from occurring.

https://stackoverflow.com/questions/38815694/gtk-3-position-attribute-on-insert-text-signal-from-gtk-entry-is-always-0

A problem I see already is that the components are of a new Gtk.Template.Child(), so I'm not sure how to make this work with this custom class. Any advice is appreciated!

[sizzlesloth]

Using this new class as suggested in the StackOverflow link results in no warnings anymore. Feel free to test.