Gtk::Widget::is_mapped ()

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Gtk::Widget::is_mapped ()

John Emmas-2
Sorry to ask a dumb question...

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

Thanks, John
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Widget::is_mapped ()

Gtk+ - Dev - General mailing list
On Sun, 3 Mar 2019 at 11:09, John Emmas <[hidden email]> 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

Only mapped widgets are drawn and can receive events.

Ciao,
 Emmanuele.

--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Widget::is_mapped ()

John Emmas-2
On 03/03/2019 11:22, Emmanuele Bassi wrote:
On Sun, 3 Mar 2019 at 11:09, John Emmas <[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Widget::is_mapped ()

Gtk+ - Dev - General mailing list
On Sun, 3 Mar 2019 at 12:58, John Emmas <[hidden email]> wrote:
On 03/03/2019 11:22, Emmanuele Bassi wrote:
On Sun, 3 Mar 2019 at 11:09, John Emmas <[hidden email]> 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.

--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Widget::is_mapped ()

Paul Davis



On Sun, Mar 3, 2019 at 6:26 AM Emmanuele Bassi via gtk-devel-list <[hidden email]> wrote:
On Sun, 3 Mar 2019 at 12:58, John Emmas <[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Widget::is_mapped ()

Gtk+ - Dev - General mailing 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 <[hidden email]> wrote:



On Sun, Mar 3, 2019 at 6:26 AM Emmanuele Bassi via gtk-devel-list <[hidden email]> wrote:
On Sun, 3 Mar 2019 at 12:58, John Emmas <[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Widget::is_mapped ()

Paul Davis


On Sun, Mar 3, 2019 at 9:21 AM Emmanuele Bassi <[hidden email]> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: Gtk::Widget::is_mapped ()

John Emmas-2
In reply to this post by Paul Davis
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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list