minimized and stick windows
Alexander Preisinger
alexander.preisinger at gmail.com
Wed May 15 05:20:21 PDT 2013
Hello,
I thought a bit about it and like to present my ideas.
I mainly thought about it from the shell/compositor site when I like to
minimize, maximize surfaces from keybindings, like in some window managers.
For example the client can still request minimize, maximize, fullsrceen and
toplevel actions, but now the compositor responds with an state_update
event.
The compositor can also send this state_update when the compositor likes
change the window on it's own (like some task bar or compositor key
bindings).
The client can then save the state and act accordingly (like hiding same
menus if maximized or fullscreen).
diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index 3bce022..e0f2c4a 100644
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -811,6 +811,14 @@
<arg name="output" type="object" interface="wl_output"
allow-null="true"/>
</request>
+ <request name="set_minimized">
+ <description summary="minimize the surface">
+ Minimize the surface.
+
+ The compositor responds with state_update event.
+ </description>
+ </request>
+
<request name="set_title">
<description summary="set surface title">
Set a short title for the surface.
@@ -867,6 +875,30 @@
<arg name="height" type="int"/>
</event>
+ <enum name="state">
+ <description summary="different states for a surfaces">
+ </description>
+ <entry name="toplevel" value="1" summary="surface is neither
maximized, minizized or fullscreen"/>
+ <entry name="maximized" value="2" summary="surface is maximized"/>
+ <entry name="minimized" value="3" summary="surface is minizimed"/>
+ <entry name="fullscreen" value="4" summary="surface is fullscreen"/>
+ </enum>
+
+ <event name="state_update">
+ <description summary="update surface state">
+ Tells the surface which state is has on the output.
+
+ This event is sent in respons to set_maximized, set_minimized or
+ set_fullscreen request to acknowledge the request. The client can
update it
+ own state if it wants to keep track of it.
+
+ The also compositor sends this event if itt wants the surface
minimized or
+ maximized. For example by clicking on a task list item or compositor
key
+ bindings for fullscreen.
+ </description>
+ <arg name="state" type="uint" summary="new surface state"/>
+ </event>
+
<event name="popup_done">
<description summary="popup interaction is done">
The popup_done event is sent out when a popup grab is broken,
I don't know about multiple window applications and maybe missed some other
use cases, but I hope this isn't too wrong of an idea. At least this should
hopefully not break the protocol too much.
Best Regards,
Alexander Preisinger
2013/5/14 Kristian Høgsberg <krh at bitplanet.net>
> On Tue, May 14, 2013 at 2:30 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> > On Mon, 13 May 2013 17:26:28 -0500
> > Jason Ekstrand <jason at jlekstrand.net> wrote:
> >
> >> On Mon, May 13, 2013 at 4:14 PM, Rafael Antognolli <
> antognolli at gmail.com>wrote:
> >>
> >> > Hi Jason,
> >> >
> >> > On Wed, May 8, 2013 at 9:26 PM, Jason Ekstrand <jason at jlekstrand.net>
> >> > wrote:
> >> > > Hi Rafael,
> >> > >
> >> > >
> >> > > On Wed, May 8, 2013 at 6:04 PM, Rafael Antognolli <
> antognolli at gmail.com>
> >> > > wrote:
> >> > >>
> >> > >> Hello,
> >> > >>
> >> > >> I've been looking the Weston code relative to maximized windows,
> and
> >> > >> it seems that the respective code for minimized windows wouldn't be
> >> > >> hard to implement.
> >> > >>
> >> > >> The questions are: are there any plans to add it? Is there someone
> >> > >> already working on it? If not, would it be OK if I start submitting
> >> > >> patches to try to add support for this?
> >> > >
> >> > >
> >> > > A month or two ago, Scott Morreau was working on it. However, his
> work
> >> > > never made into weston for a variety of reasons. Personally, I'm
> glad to
> >> > > see someone interested in working on it again because it's
> something that
> >> > > wayland will need eventually.
> >> > >
> >> > > The place to start on it is probably with the following e-mail and
> the
> >> > long
> >> > > string of replies:
> >> > >
> >> > >
> >> >
> http://lists.freedesktop.org/archives/wayland-devel/2013-March/007814.html
> >> > >
> >> > > There was quite a bit of discussion about how to handle it from a
> >> > protocol
> >> > > level, but Scott never made an actual version 2. I'd suggest you
> start
> >> > by
> >> > > reading the chain of e-mails (it goes into April, not just March).
> There
> >> > > were quite a few suggestions in there that could be incorporated.
> >> > > Hopefully, you can pick through the e-mail discussion and figure
> out what
> >> > > the consensus was. It'd be good to have a pair of fresh eyes look
> at it.
> >> >
> >> > Thanks for pointing that out. I just went through the chain of
> >> > e-mails, but I don't think there was a consensus there.
> >> >
> >> > It also seems that the minimize implementation is a little more
> >> > complex than just hiding surfaces and marking some flags. Which makes
> >> > me not so comfortable doing an implementation without a consensus
> >> > about what should be implemented, and with some orientation.
> >> >
> >> > That said, I'm not sure I'm really going to take this task.
> >> >
> >>
> >> I didn't intend to scare you off. Honestly, I don't know for 100%
> certain
> >> how much weston machinery is needed to implement it. It would require
> some
> >> sort of set of flags to keep the compositor and shell plugin in sync.
> That
> >> said, I don't know if its quite as difficult as Scott made it sound.
> >>
> >> As far as direction goes, the first thing is to think through use-cases
> and
> >> settle on a protocol. Unfortunately, the discussion I linked you to
> seemed
> >> to go nowhere. However, a lot of that was Scott saying, "This is the
> way I
> >> want to do it and I'm not going to change." If you look at the other
> >> comments, I think there was some consensus in there (at least in a
> general
> >> direction). Feel free to throw some XML together and we can re-start
> the
> >> discussion. For that matter, if you can come up with a way to do it as
> a
> >> weston extension for now (with the hopes of putting it in wayland core
> >> later), things can be a lot more flexible and we can play around with
> >> protocol concepts as we go.
> >>
> >> Once a basic protocol is in place, then the client-side needs to be
> >> implemented in tinytk (window.c) and the server-side needs to be
> >> implemented in weston.
> >>
> >> I'm sorry "I want to add X feature" isn't simpler. Basically every new
> >> major protocol piece goes through a long mailing list discussion and a
> lot
> >> of revision.
> >
> > Also worth noting, that there are actually two different pieces of
> > protocol involved with minimized windows:
> >
> > - the public protocol, likely part of wl_shell_surface, which all
> > applications use to communicate with the server. This is the
> > important part that will go under strict review, but it is probably
> > also the simpler of the two. You could also check what DE
> > projects have done on this (Gnome/gtk, KDE/Qt, EFL, ...).
> >
> > - the private protocol between Weston and weston-desktop-shell
> > specifically. As we have chosen to let weston-desktop-shell client do
> > all the GUI drawing, and minimized windows will need some GUI (a task
> > bar button, a menu list of windows) to be able to get them back, we
> > need protocol to inform weston-desktop-shell about the windows so it
> > can draw the GUI.
> >
> > But these should not be complicated, once you understand how the basics
> > of a Wayland protocol work. And you don't need to have any complex
> > foreign surface passing protocol to get window thumbnails by hovering
> > the pointer over a taskbar button. Thumbnails can be added later, as it
> > does not concern the public protocol at all.
>
> We don't need even need to pull that complexity in in the first step.
> We can simply allow mod-tab to select minimized windows and unminiized
> if they're selected.
>
> Kristian
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130515/62c998bc/attachment-0001.html>
More information about the wayland-devel
mailing list