Re: GTK_MODULES removal and the future of existing modules
On Sun, Feb 25, 2018 at 4:11 AM, Philipp Emanuel Weidmann < p...@worldwidemann.com> wrote: > Greetings, > > I am the author of Plotinus[1], a GTK+ module that provides a > searchable command palette to GTK+ applications. Recently, it was > brought to my attention[2] that module loading has been removed[3] on > GTK+ master. > > It appears that this change could mean the end for Plotinus and other > modules like it. I would be interested to learn: > > 1. What is the rationale behind the removal of module loading? > > 2. What will be the first stable release of GTK+ that does not support >modules anymore? Is this GTK+ 4.0+ only, or will support also be >dropped in a 3.0 series release? > > 3. What, if any, alternatives are available/planned for software >like Plotinus that needs to inspect the widget hierarchy of running >applications in order to work? > > Any insight is appreciated! > > This may not be a popular opinion, but my view is that it is harmful to the eco system overall if useful features are hidden away in 3rd party modules instead of being properly integrated in the toolkit. Has the example you mention ever been suggested as a feature addition to GTK+ ? Was it rejected ? Or why was it implemented as a 3rd party module ? Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: No module anymore & perfect zoom feature
On 26 February 2018 at 17:49, Samuel Thibaultwrote: > Hello, > > So, I also saw the removal of generic modules. > > Unfortunately we currently need it for implementing perfect zoom feature > :) I don't know what a "perfect zoom feature" is — but zooming on a window should be part of the display server. Having said that, we do have a magnifier inside GTK, used by the Inspector. We could make that feature public, and improve it. We definitely do not want to let people inject code into running applications. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: No module anymore & perfect zoom feature
On Mon, Feb 26, 2018 at 5:49 AM, Samuel Thibault < samuel.thiba...@ens-lyon.org> wrote: > Hello, > > So, I also saw the removal of generic modules. > > Unfortunately we currently need it for implementing perfect zoom feature > :) > > The context is that visual-impaired users need magnification of the > desktop. Changing font sizes / dpi etc. have their limit, at some point > we need to just have a zoomed view of a piece of the screen. Currently > compiz' ezoom takes the piece of the screen, and magnify it to show it > on the screen, with obviously awful pixelization effects. > > Our idea was very similar to gtk-vector-screenshot : instead of taking > the output as it is displayed on the screen, get a module loaded within > the application, with which ezoom can discuss to make the application > produce a magnified rendering of its window, which ezoom can then show > in the magnification glass, thus getting perfect zoom. > > Without module loading, I don't know how to implement it :) Or perhaps > this could be added as an AT-SPI interface? > > If it is a toolkit-level feature that is needed desktop-wide, it needs to be implemented in the toolkit proper, not added through the backdoor via a module. I know that this will require some rearchitecting and may not be super-easy, but I still believe that this is the right way forward. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK_MODULES removal and the future of existing modules
On 26 February 2018 at 13:17, Philipp Emanuel Weidmannwrote: > Thank you for the quick response! > > I'm not sure anything short of direct access to the widget tree would > suffice for a GTK4 version of Plotinus to provide the functionality it > does today on GTK3. Which is kind of why we don't want people to write this kind of modules any more. ;-) Accessing the hierarchy from outside of the application is a great way to lead to crashes. See also why we removed theme engines. From our perspective, the only way to know about menus and actions should be through the GAction API, and the mechanisms that we already have in place to export the menus on the session bus. > Of course, I don't expect LibreOffice to move to GTK4 in the short or > even medium term. The major cross-platform applications like Firefox, > LibreOffice, GIMP, and Inkscape have been very reluctant in their > adoption of even GTK3, and likely don't fancy another bumpy upgrade > anytime soon. Still, eventually they might switch, and it makes sense > to anticipate that. If LibreOffice and Firefox will ever move to GTK4, we're going to strongly suggest they expose their menus on the session bus, either through the GMenu API directly, or by implementing the same DBus API exposed by GTK. Ciao, Emmanuele. > On Sun, 2018-02-25 at 09:54 +, Emmanuele Bassi wrote: >> Hi; >> >> On Sun, 25 Feb 2018 at 09:18, Philipp Emanuel Weidmann > mann.com> wrote: >> > Greetings, >> > >> > I am the author of Plotinus[1], a GTK+ module that provides a >> > searchable command palette to GTK+ applications. Recently, it was >> > brought to my attention[2] that module loading has been removed[3] >> > on >> > GTK+ master. >> > >> > It appears that this change could mean the end for Plotinus and >> > other >> > modules like it. I would be interested to learn: >> > >> > 1. What is the rationale behind the removal of module loading? >> > >> >> The module code was fairly ancient, and was hand rolling things for >> which we have better API down the stack, like GIO extension points, >> which support things like priorities and prerequisites. >> > 2. What will be the first stable release of GTK+ that does not >> > support >> >modules anymore? Is this GTK+ 4.0+ only, or will support also be >> >dropped in a 3.0 series release? >> > >> >> The GTK 3.x series is frozen, so it won’t be touched. This change is >> for 4.x only. >> >> > 3. What, if any, alternatives are available/planned for software >> >like Plotinus that needs to inspect the widget hierarchy of >> > running >> >applications in order to work? >> > >> >> We could be amenable to add an extension point for this, if you >> present a case for it, and explain what kind of requirements you need >> from the toolkit; granting blanket access to the internals of the >> toolkit is not something we’d be happy to provide, but if you have a >> specific domain it should be possible to accommodate your extension. >> >> Alternatively, we could ensure that all our menus and actions are >> introspectable from the outside, and give you a proper API for >> writing Plotinus in GTK 4.0. We’d probably prefer that. >> >> Ciao, >> Emmanuele. >> >> > Any insight is appreciated! >> > >> > Warm regards >> > Philipp >> > >> > >> > [1]: https://github.com/p-e-w/plotinus >> > [2]: https://github.com/p-e-w/plotinus/issues/35 >> > [3]: https://github.com/GNOME/gtk/commit/39d1537211501a8603f93a3196 >> > b910 >> > dce40e1617 >> > >> > ___ >> > gtk-devel-list mailing list >> > gtk-devel-list@gnome.org >> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list >> >> -- >> https://www.bassi.io >> [@] ebassi [@gmail.com] -- https://www.bassi.io [@] ebassi [@gmail.com] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Title on gnome-shell
Thank you for your explanation. I could get the title string in gnome-shell when I added the desktop files and changed GApplication to GtkApplication in my application. Maybe the specification could be defined in freedesktop.org On 02/28/18 02:45, Florian Müllner-san wrote: On Tue, Feb 27, 2018 at 1:59 PM, Takao Fujiwarawrote: How can I set the title name of GtkWindow on gnome-shell? gtk_window_set_title(), but that's probably not what you mean - there are few places where gnome-shell uses the window title, in general the application name is more prominent. For that it is important that gnome-shell finds the .desktop file that corresponds to the window. There are several options for making that work, most importantly: - use GtkApplication with an ID that corresponds to the .desktop file (for example "com.example.Foo" and com.example.Foo.desktop) - set the WM_CLASS property to the .desktop file name (e.g. g_setprgname("foo-bar"); and foo-bar.desktop) - set the StartupWMClass field in the .desktop file to the WM_CLASS of your program Refer to https://wiki.gnome.org/Projects/GnomeShell/ApplicationBased for more details. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list