xdg shell status and gaps
matthias.clasen at gmail.com
Thu Sep 25 10:30:38 PDT 2014
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,
More information about the wayland-devel