Re: Gtk::Widget::is_mapped ()

[John Emmas]

On 03/03/2019 16:10, Paul Davis wrote:


John should really know that there's code to do this (to the best 
extent possible) within the Ardour source code at 
libs/gtkmm2ext/visibility_tracker.cc :)))




Hi Paul - that's in fact what I'm investigating

There's a new object called 'PluginDspLoadWindow' which is getting 
displayed by Ardour but not by Mixbus for some reason.  What's failing 
is those visibility_tracker calls to 'Gtk::Widget::is_mapped()' (and 
that's why I was asking what the call does...)


Anyway, this is off-topic now for the gtk-devel list.  If I make any 
progress with it, I'll either file a bug report or maybe join you on IRC 
sometime.  Best regards,


John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk::Widget::is_mapped ()

[Paul Davis]

On Sun, Mar 3, 2019 at 9:21 AM Emmanuele Bassi  wrote:

> No, it's not. The issue is not GTK: it's the windowing system.
>
> With the advent of compositing, all windows are "visible" all the time,
> from a toolkit perspective. The compositor is responsible for building
> what's presented to the user. For example: are windows fully visible when
> doing an "exposé"-like view? Are they not? If the compositor is ultimately
> responsible of creating the final result of what's on the screen, it could
> put each window on separate planets as far as the toolkit is concerned
> (assuming latency and coordinate space size aren't a problem).
>

seems to me like an extremely uninteresting question. "expose" means "while
you, the app, doesn't know why, it's time for you to redraw (some|all) of
the contents of this window right now". visibility or otherwise doesn't
seem relevant to that.


> On Wayland is even "worse", because each window surface is completely
> separate from every other window surface by design; each window has its own
> coordinate system, that has an origin in the top-left corner of the window.
> A window *cannot* be obscured by another window, as far as the toolkit is
> concerned.
>
> If you're targeting an X11 system from the late '90s/early '00s, then
> visibility notifications *may* be emitted (though they are never
> guaranteed). On anything more modern than that, or on
> Wayland/Windows/macOS, visibility notification events are either
> non-sensical, not emitted, or not possible by design.
>

macOS as of Sierra still causes GTK(2) to generate sensible visibility
notification events. AFAIK, we still get them on current Windows systems
too.

It seems to me somewhat insane that Wayland has broken this concept (I take
you at your word that it has). Part of the job of a window manager is not
just user-facing, but also app-facing, and that includes telling an
application about the state of its window(s). It doesn't seem even remotely
unreasonable to expect that this would include visibility changes.  It's a
bit like saying "some system component could make the window any size it
chooses too at all, so it has the app has no way to know how large its
windows are."

Oh well.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk::Widget::is_mapped ()

[Emmanuele Bassi via gtk-devel-list]

No, it's not. The issue is not GTK: it's the windowing system.

With the advent of compositing, all windows are "visible" all the time,
from a toolkit perspective. The compositor is responsible for building
what's presented to the user. For example: are windows fully visible when
doing an "exposé"-like view? Are they not? If the compositor is ultimately
responsible of creating the final result of what's on the screen, it could
put each window on separate planets as far as the toolkit is concerned
(assuming latency and coordinate space size aren't a problem).

On Wayland is even "worse", because each window surface is completely
separate from every other window surface by design; each window has its own
coordinate system, that has an origin in the top-left corner of the window.
A window *cannot* be obscured by another window, as far as the toolkit is
concerned.

If you're targeting an X11 system from the late '90s/early '00s, then
visibility notifications *may* be emitted (though they are never
guaranteed). On anything more modern than that, or on
Wayland/Windows/macOS, visibility notification events are either
non-sensical, not emitted, or not possible by design.

This is why I said: "there is no way to know".

Ciao,
 Emmanuele.

On Sun, 3 Mar 2019 at 16:10, Paul Davis  wrote:

>
>
>
> On Sun, Mar 3, 2019 at 6:26 AM Emmanuele Bassi via gtk-devel-list <
> gtk-devel-list@gnome.org> wrote:
>
>> On Sun, 3 Mar 2019 at 12:58, John Emmas  wrote:
>>
>>>
>> For example... let's say the widget is a top-level window.  If it's
>>> currently displayed on screen but there's some other window hiding it
>>> (maybe from a totally different app) would 'is_visible()' return true or
>>> false?
>>>
>>
>> That's entirely different, and you should have said so at the very
>> beginning of the thread. Yes, both "visible" and "mapped" would be set to
>> true because you called show() on the window, and a window has no parents,
>> so once it's visible and realized, it'll be mapped as well; there is no way
>> to know, from a toolkit perspective, if a top level is being partially, or
>> totally, covered by some other window, either in the same process or from a
>> different process. That information is only available to the window manager.
>>
>
> John should really know that there's code to do this (to the best extent
> possible) within the Ardour source code at
> libs/gtkmm2ext/visibility_tracker.cc :)))
>
> It works (to whatever extent it does work) by handling GtkEventVisibility
> notifications. Hopefully this is still possible in GTK3 ?
>
>

-- 
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::Widget::is_mapped ()

[Paul Davis]

On Sun, Mar 3, 2019 at 6:26 AM Emmanuele Bassi via gtk-devel-list <
gtk-devel-list@gnome.org> wrote:

> On Sun, 3 Mar 2019 at 12:58, John Emmas  wrote:
>
>>
> For example... let's say the widget is a top-level window.  If it's
>> currently displayed on screen but there's some other window hiding it
>> (maybe from a totally different app) would 'is_visible()' return true or
>> false?
>>
>
> That's entirely different, and you should have said so at the very
> beginning of the thread. Yes, both "visible" and "mapped" would be set to
> true because you called show() on the window, and a window has no parents,
> so once it's visible and realized, it'll be mapped as well; there is no way
> to know, from a toolkit perspective, if a top level is being partially, or
> totally, covered by some other window, either in the same process or from a
> different process. That information is only available to the window manager.
>

John should really know that there's code to do this (to the best extent
possible) within the Ardour source code at
libs/gtkmm2ext/visibility_tracker.cc :)))

It works (to whatever extent it does work) by handling GtkEventVisibility
notifications. Hopefully this is still possible in GTK3 ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk::Widget::is_mapped ()

[Emmanuele Bassi via gtk-devel-list]

On Sun, 3 Mar 2019 at 12:58, John Emmas  wrote:

> On 03/03/2019 11:22, Emmanuele Bassi wrote:
>
> On Sun, 3 Mar 2019 at 11:09, John Emmas  wrote:
>
>> Sorry to ask a dumb question...
>>
>> What does it mean if a widget is "mapped" ?
>>
>
> It means that:
>
>  - the widget is visible
>  - the widget is realized
>  - all its ancestors up to the top level window are mapped
>
> Thanks Emmanuele - can I just check 'is_visible()'?  Does it mean
> 'literally visible' or 'capable of being visible'?
>

If it were enough, why would we have two flags? :-)

The "visible" property means "you, or something else, called
gtk_widget_show()" on the widget. A widget can be visible and not have any
parent, for instance.

If you want to know that a widget is going to be drawn, and respond to
events, then you have to check the "mapped" state.

For example... let's say the widget is a top-level window.  If it's
> currently displayed on screen but there's some other window hiding it
> (maybe from a totally different app) would 'is_visible()' return true or
> false?
>

That's entirely different, and you should have said so at the very
beginning of the thread. Yes, both "visible" and "mapped" would be set to
true because you called show() on the window, and a window has no parents,
so once it's visible and realized, it'll be mapped as well; there is no way
to know, from a toolkit perspective, if a top level is being partially, or
totally, covered by some other window, either in the same process or from a
different process. That information is only available to the window manager.

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: Gtk::Widget::is_mapped ()

[John Emmas]

On 03/03/2019 11:22, Emmanuele Bassi wrote:
On Sun, 3 Mar 2019 at 11:09, John Emmas > wrote:


Sorry to ask a dumb question...

What does it mean if a widget is "mapped" ?


It means that:

 - the widget is visible
 - the widget is realized
 - all its ancestors up to the top level window are mapped

Thanks Emmanuele - can I just check 'is_visible()'?  Does it mean 
'literally visible' or 'capable of being visible'?


For example... let's say the widget is a top-level window.  If it's 
currently displayed on screen but there's some other window hiding it 
(maybe from a totally different app) would 'is_visible()' return true or 
false?


John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Gtk::Widget::is_mapped ()

[John Emmas]

Sorry to ask a dumb question...

What does it mean if a widget is "mapped" ?

Thanks, John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list