On 11/02/2014 02:23, Bill Spitzak wrote:
May not have explained it correctly. It sounded like you were not
going to allow dialogs to be minimized except as a side-effect of
minimizing the parent.
I was, but I am not any more.
I certainly want to allow this! And I certainly want to support
sardemff7+wayl...@sardemff7.net wrote:
I was suggesting that one method of minimizing multiple surfaces
would be for the client to arrange them all as children of one of
them and then minimize the parent. The primary purpose is so the
compositor/taskbar knows all those windows are related, for
Hi Bill, hi Jasper, hi everybody again,
I just updated my taskbar code to make it work against Weston 1.4.0 :
https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar
And with regards to our former conversation, I added a logic that allows
the client to know when it has been minimized :
2014-02-10 17:25 GMT+02:00 Manuel Bachmann
manuel.bachm...@open.eurogiciel.org:
Hi Bill, hi Jasper, hi everybody again,
I just updated my taskbar code to make it work against Weston 1.4.0 :
https://github.com/Tarnyko/weston-taskbar/tree/1.4.0-taskbar
And with regards to our former
Oh, and I forgot to add, the taskbar has its own logic asking the
compositor to hide, so clicking on the taskbar will do this, too. Sorry for
the additional noise.
Regards,
Manuel
2014-02-10 16:43 GMT+01:00 Manuel Bachmann
manuel.bachm...@open.eurogiciel.org:
Hi Guilio,
In fact, the client
I need to read the rest of the responses, but this does *not* sound like
what I think is necessary. There should not be any need for an event
saying you have been minimized as this should never happen without the
client first requesting it.
As I see it, if the compositor decides to minimize
Okay this sounds like it is going in exactly the wrong direction.
What I am trying to do is restore the ability to use overlapping windows
which was broken in approximatly 1990 when everybody started doing
click raises (when even then it was *trivial* for a client to raise
it's own windows),
On 10/02/2014 21:57, Bill Spitzak wrote:
Okay this sounds like it is going in exactly the wrong direction.
And you sound like you do not understand the strong need here: the
compositor *must be in charge* of everything. But, please, do not start
to yell now, it can perfectly work well with
sardemff7+wayl...@sardemff7.net wrote:
First, a compositor may have no mechanism of “minimization”, so it must
not be forced to obey such a request with no meaning for it.
I agree the compositor does not have to obey the minimize request. I
think I am not explaining things clearly: *BOTH*
(Some parts are reordered to makes more sense in my answers. Agreed
parts are removed.)
On 10/02/2014 23:42, Bill Spitzak wrote:
sardemff7+wayl...@sardemff7.net wrote:
Based on Bill’s events and requests, here is what I think should
handle all cases the right way while keeping the global
sardemff7+wayl...@sardemff7.net wrote:
Not sure why you want to limit it like this. I certainly would like
the ability to minimized dialog windows.
If you want a dialog window to be minimized, then it makes even more
sense to allow minimizing multiple surfaces. The client could want to
Hi folks,
Where I work, we need to have some logic to manage surfaces from a client
point of view (application or toolkit). For example, we need to be able to :
- minimize (hide/show or more) surfaces, just like most desktop
environments allow ;
- manage layers, by arranging surfaces by z-orders
On Thu, Jan 30, 2014 at 6:31 PM, Bill Spitzak spit...@gmail.com wrote:
- When the compositor creates a shell_surface having the TOPLEVEL type,
it sets a numeral ID for it, and sends a map event to the desktop_shell
client ;
You must allow a toplevel to become a non-toplevel and
Hi Bill, and thanks a lot for sharing your thoughts,
You must allow a toplevel to become a non-toplevel and vice-versa
That's true ; the current implementation doesn't address this case.
My recommendation is that a surface has a parent that can be changed at
any time to any other surface or
Well, having read Jasper's comment, he has some valid points, the most
important being in my opinion :
it matches user expectations. If the user clicks minimize on a window,
they want it hidden
It the logic of what should *really* happen when a window is minimized is
implemented client-side,
Jasper St. Pierre wrote:
Hiding windows should not have any influence over the client, as many
desktop environments, including Weston, want to show live previews for
minimized or hidden windows in alt-tab or Expose-alikes.
Also, it matches user expectations. If the user clicks minimize on a
On Thu, Jan 30, 2014 at 8:48 PM, Bill Spitzak spit...@gmail.com wrote:
Jasper St. Pierre wrote:
Hiding windows should not have any influence over the client, as many
desktop environments, including Weston, want to show live previews for
minimized or hidden windows in alt-tab or
Manuel Bachmann wrote:
Hi Bill, and thanks a lot for sharing your thoughts,
GTK+ seems to have an impl, so I will check what it does.
I think it may be trying to use X window groups which is an example of
an excessively complex api to try to solve this. It has not worked and
Gimp is now
Jasper St. Pierre wrote:
A simple problem is a floating window shared by two main windows.
Can you give a concrete example of such a case? Not because I'm assuming
none exist, but because I want a specific example to evaluate and think
about.
A toolbox over a painting program that has
On Thu, Jan 30, 2014 at 9:03 PM, Bill Spitzak spit...@gmail.com wrote:
Jasper St. Pierre wrote:
A simple problem is a floating window shared by two main windows.
Can you give a concrete example of such a case? Not because I'm assuming
none exist, but because I want a specific example
Jasper St. Pierre wrote:
A toolbox over a painting program that has two documents open.
So, what is the expected behavior here exactly? There's a minimize
button on both of the content window's decorations, and clicking on one
should minimize all three windows?
Clicking minimize of
21 matches
Mail list logo
