xdg shell status and gaps

[Matthias Clasen]

On Thu, Sep 25, 2014 at 10:32 AM, Jasper St. Pierre
<jstpierre at mecheye.net> wrote:


>> Anyway, here's the list:
>>
>> 1) Marking dialogs as modal (needed so we can implement the 'attached
>> modal' visuals of gnome-shell

What about this one ?

>> 2) Lowering windows (used e.g. by GtkInspector to get out of the way
>> when picking a window
>
> I'm not comfortable adding this. You can hide briefly the inspector by
> giving it a 1x1 blank surface and emptying the input region. Perhaps we
> should make this equivalent to what the "NULL surface" semantics are.

Might work - I chose lowering here instead of hiding since hiding
breaks the grabs we use under X.

>>
>> 4) Learning about output characteristics - is this display the
>> 'primary' / builtin / projector ? (needed e.g. when deciding which
>> output to show a presentation on)

>> 5) Finding out if there is desktop chrome that should be avoided (ie.
>> 'workarea') ? (Useful e.g. for window size heuristics)
>
>
> This will be handled by the probe extension, but I'm not really sure why you
> need this. You can't manually place your window with global coordinates.
> "Avoiding" anything doesn't make too much sense to me.

As I said, we currently use the workarea in
gtk_window_guess_default_size() when figuring out which size to give
the window initially. Thats somewhat useful, even if we have no
control of the placement.

>>
>> 7) Root window drop
>
>
> When is this useful?

One place where it is used is when dragging tabs out of a window to
create a new window. gnome-terminal, gedit, nautilus, all do this. But
looking closer, the way it is implemented is not actually as a root
window drop, specifically, but just any failed drop - if you don't
drop on a notebook in the same app that is hooked up to accept the
tab, we just treat any failed drop as a change to create a new window.
So, what we need is a signal that a drop failed. Not sure we get that,
currently ?