Re: GTK_MODULES removal and the future of existing modules

2018-02-28 Thread Matthias Clasen 
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: GTK_MODULES removal and the future of existing modules

2018-02-28 Thread Emmanuele Bassi 
On 26 February 2018 at 13:17, Philipp Emanuel Weidmann
 wrote:
> 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: GTK_MODULES removal and the future of existing modules

2018-02-25 Thread Philipp Emanuel Weidmann 
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.

The problem is that in practice, some of the most important
applications use GTK in an "incomplete" manner. A good example is
LibreOffice: It doesn't use GtkApplication, nor does it have
GActionMaps, or GMenuModels from which actions can be extracted. There
is only a GtkMenuBar widget, which I'm guessing is constructed from
some backend-agnostic model inside the LibreOffice GUI stack.

Plotinus currently tries the obvious things first, looking for
application menus and their models, and falls back to raw widgets if it
doesn't find any. It is this fallback feature that allows Plotinus to
work with software like LibreOffice, and it is software like
LibreOffice where Plotinus is the most useful, since it has hundreds of
menu items.

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.

For Plotinus to continue supporting "semi-GTK" applications,
introspection APIs would need to cover the case where there is nothing
but a GtkWindow and a bunch of widgets. The existing D-Bus APIs, for
example, all seem to require at least a GApplication. I don't know
enough about GTK internals to say which alternatives might be feasible.
You mention GIO extension points, a feature I wasn't aware of until
now. How could such an extension point look for Plotinus' use case?
What information would it provide? And would it work with software that
doesn't use GApplication?

Thanks & best regards
Philipp




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]
___
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

2018-02-25 Thread Emmanuele Bassi 
Hi;

On Sun, 25 Feb 2018 at 09:18, 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?
>

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/39d1537211501a8603f93a3196b910
> 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]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list