Re: Window positions under wayland

2022-08-08 Thread JiDe Zhang
Hi:

Is it that more people think that not allowed the window to set their position 
is better? I think that Wayland is better than X11 In this regard. It is 
correct to not let the window be set position, But some people will have 
doubts, because their know that some windows need to set their own position. We 
should pay attention to these needs and analyze what is the real reason their 
need for this interface, I don't think most of the window do not care about 
their positions, such as Chrome or Firefox, and some other commonly used 
applications, such as terminals, vscode, QtCreator, can not set positions is 
without any effect on them. In addition, there are some special windows, such 
as taskbar, message notifications, etc, They need to control the position of 
the window in screen, and they also need to set the layer of the window, such 
as the desktop window is always at the bottom, the taskbar window has been at 
the top. In fact such applications are usually provided by the desktop 
environment, the Wayland compositor can provide support for them, different 
desktop environments can fully control all their windows, this is right, they 
do not need Wayland to provide the interface of setting window positions.

In addition to the above two examples, some windows are neither part of the 
desktop environment and and does need to control the position of the window 
(I'm using "control" instead of "set" here because I think they just need a way 
to control the position of the window, rather than having to use something like 
the X11 way of setting window coordinates). For a example, there have a window, 
when the user drags it to the edge of the screen and releases the mouse, which 
will to hidden, display only a small part of the window at the edge of the 
screen, and when the mouse hover in this part of the exposed area, the window 
will full display. I have used some applications like this, I'm sorry I 
couldn't find a GIF picture about it, I hope you understand what kind of 
feature I described. I think such demand is reasonable, the demand can be 
implemented in other ways instead of providing the interface of the set window 
position. In the case I give an example, we can provide it with a allowable 
window to set its anchor on the screen, such as:

void handle_shell_surface_move_finished(wl_surface *s)
{
QRegion visible_region = get_surface_visible_region_in_current_screen(s);
QRect rect = visible_region.boundingRect();

if (rect.y() > 0) {
 // Hidden the window to the top edge of the screen
 wl_shell_surface_anchors *screen_anchors = 
wl_shell_surface_get_screen_anchors(s);
 wl_shell_surface_anchors *window_anchors = 
wl_shell_surface_get_anchors(s);
 // Requires the bottom edge of the window to align with the top edge 
of the screen, and have 10px margins. You can only see the 10px height content 
at the bottom of the window on the screen.
 wl_shell_surface_request_anchors(window_anchors->bottom, 
screen_anchors->top, 10);
}
}

I think this interface that is not setting absolute coordinates will be more 
friendly for the application, most similar needs can be solved using this like 
interface. Do you think so and do you have any other examples to introduce?

--
JiDe Zhang -- linuxdeepin.

From: wayland-devel  on behalf of 
samuel ammonius 
Sent: Sunday, August 7, 2022 01:15
To: Igor Korot 
Cc: Thiago Macieira ; Daniel Stone ; 
wayland-devel@lists.freedesktop.org 
Subject: Re: Window positions under wayland

No one responded to my last email, so I'll just assume it was because everyone 
aggeed with it and not because it was so horribly structured that no one 
understood a thing I was saying :).

It would be possible to redesign Wayland following the principles you
have described. No-one is doing this, however.
If I added this feature through git, would it be accepted? It would just be 
"void wl_surface_request_position(wl_surface *surface, unsigned int x, unsigned 
int y);"

On Fri, Aug 5, 2022 at 8:14 PM samuel ammonius 
mailto:sfammon...@gmail.com>> wrote:
Sorry, I just read over my last email and realized that I didn't even state 
what I was trying
to say. I meant my last suggestion of letting the compositor handle the resize 
event. I was
just giving some reasons as to why it may be the best solution.

On Fri, Aug 5, 2022 at 6:32 PM samuel ammonius 
mailto:sfammon...@gmail.com>> wrote:
I don't understand why we're all asking if it should be up to the compositor or 
app to set a
window's position. The only correct answer is that it should be up to the user, 
so I don't
see what's wrong with my suggestion of a "set window size request" function. 
Waylands
idea of not letting apps set their window position because it thinks it knows 
better is very
similar to what's wrong with commercial operating systems nowadays, and it's 
probably
why many of us left Windows. For example, you could only disable "live 
s

Re: Window positions under wayland

2022-08-08 Thread Alan Griffiths

On 08/08/2022 09:05, JiDe Zhang wrote:

Hi:

Is it that more people think that not allowed the window to set their 
position is better? I think that Wayland is better than X11 In this 
regard. It is correct to not let the window be set position, But some 
people will have doubts, because their know that some windows need to 
set their own position. We should pay attention to these needs and 
analyze what is the real reason their need for this interface,



It is entirely understandable for the designers of applications and 
application toolkits to be surprised they don't have the control they 
have in other windowing systems (X11, Windows, whatever). For decades 
they've been used to deciding where their windows go. Trusting the 
compositor to do that is a surprise.



But in the real world, they have to conform to a small number idioms 
that users recognise, and supporting those is very possible without 
allowing "full control". We've done some work on classifying these 
idioms for Mir and there's a presentation of our findings here:



https://mir-server.io/docs/window-positions-under-wayland


The tl;dr is that most of the idioms (regular windows, dialogs, menus, 
popus, tooltips, hovers, satellites, toolboxes) are already supported 
and there's no fundamental problem extending the existing approach used 
by Wayland to cover others. (Most of the support needed can be cut & 
paste from other idioms.)


Use-case when positioning a window is necessary

2022-08-08 Thread Sébastien Wilmet
Hi,

I've seen the discussion this month about positioning windows.

The use-case is something concrete: the Devhelp [1] assistant window.

For some background, Devhelp (and libdevhelp) is implemented flexibly:
it can be used as a standalone app, it can be integrated into GTK IDEs,
the standalone app can be called to search or open a symbol.

And there is the Devhelp assistant window: it is typically used by a
text editor, to ask Devhelp to show a small window with the
documentation for the symbol under the cursor.

And that is where positioning is necessary: to not occlude the line of
text where the cursor is, and to show the documentation at a sensible
place (near the cursor position).

With Wayland, this should be implemented with a subsurface. I may be
wrong, but in this case it's not possible, because it's not the same
app (the same process).

(For example you open a terminal, then open Vim, then you press a key
and it opens the Devhelp assistant window).

So, what would be your suggestion in such a use-case? To still retain
the flexibility of Devhelp.

Thanks,
Sébastien

[1] https://wiki.gnome.org/Apps/Devhelp (an API browser)


Re: Use-case when positioning a window is necessary

2022-08-08 Thread Olivier Fourdan
Hi Sébastien,

On Mon, 8 Aug 2022 at 14:50, Sébastien Wilmet 
wrote:

> Hi,
>
> I've seen the discussion this month about positioning windows.
>
> The use-case is something concrete: the Devhelp [1] assistant window.
>
> For some background, Devhelp (and libdevhelp) is implemented flexibly:
> it can be used as a standalone app, it can be integrated into GTK IDEs,
> the standalone app can be called to search or open a symbol.
>
> And there is the Devhelp assistant window: it is typically used by a
> text editor, to ask Devhelp to show a small window with the
> documentation for the symbol under the cursor.
>
> And that is where positioning is necessary: to not occlude the line of
> text where the cursor is, and to show the documentation at a sensible
> place (near the cursor position).
>
> With Wayland, this should be implemented with a subsurface. I may be
> wrong, but in this case it's not possible, because it's not the same
> app (the same process).
>

See the xdg-foreign protocol [2].

Cheers
Olivier

[2]
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/unstable/xdg-foreign


Re: Use-case when positioning a window is necessary

2022-08-08 Thread Benoît Gschwind
Hello,

After a quick reading of your DevHelp case, I think the issue belong
devhelp and your app that using it. DevHelp have to provide an API to
be embeded in another application and Wayland protocol should not be
involved. Maybe d-bus can be used as pipe between DevHelp and others
applications.

Best Regards

Le lundi 08 août 2022 à 14:12 +0200, Sébastien Wilmet a écrit :
> Hi,
> 
> I've seen the discussion this month about positioning windows.
> 
> The use-case is something concrete: the Devhelp [1] assistant window.
> 
> For some background, Devhelp (and libdevhelp) is implemented
> flexibly:
> it can be used as a standalone app, it can be integrated into GTK
> IDEs,
> the standalone app can be called to search or open a symbol.
> 
> And there is the Devhelp assistant window: it is typically used by a
> text editor, to ask Devhelp to show a small window with the
> documentation for the symbol under the cursor.
> 
> And that is where positioning is necessary: to not occlude the line
> of
> text where the cursor is, and to show the documentation at a sensible
> place (near the cursor position).
> 
> With Wayland, this should be implemented with a subsurface. I may be
> wrong, but in this case it's not possible, because it's not the same
> app (the same process).
> 
> (For example you open a terminal, then open Vim, then you press a key
> and it opens the Devhelp assistant window).
> 
> So, what would be your suggestion in such a use-case? To still retain
> the flexibility of Devhelp.
> 
> Thanks,
> Sébastien
> 
> [1] https://wiki.gnome.org/Apps/Devhelp (an API browser)



Re: Use-case when positioning a window is necessary

2022-08-08 Thread Igor Korot
Hi,

On Mon, Aug 8, 2022, 8:38 AM Benoît Gschwind  wrote:

> Hello,
>
> After a quick reading of your DevHelp case, I think the issue belong
> devhelp and your app that using it. DevHelp have to provide an API to
> be embeded in another application and Wayland protocol should not be
> involved. Maybe d-bus can be used as pipe between DevHelp and others
> applications.
>

Problem is - DevHelp is like a plug-in- it can be used with a thousands of
applications, not just a specific one. And DevHelp don't have control over
them.

So you reading comprehension is too fast. :-)

Thank you


> Best Regards
>
> Le lundi 08 août 2022 à 14:12 +0200, Sébastien Wilmet a écrit :
> > Hi,
> >
> > I've seen the discussion this month about positioning windows.
> >
> > The use-case is something concrete: the Devhelp [1] assistant window.
> >
> > For some background, Devhelp (and libdevhelp) is implemented
> > flexibly:
> > it can be used as a standalone app, it can be integrated into GTK
> > IDEs,
> > the standalone app can be called to search or open a symbol.
> >
> > And there is the Devhelp assistant window: it is typically used by a
> > text editor, to ask Devhelp to show a small window with the
> > documentation for the symbol under the cursor.
> >
> > And that is where positioning is necessary: to not occlude the line
> > of
> > text where the cursor is, and to show the documentation at a sensible
> > place (near the cursor position).
> >
> > With Wayland, this should be implemented with a subsurface. I may be
> > wrong, but in this case it's not possible, because it's not the same
> > app (the same process).
> >
> > (For example you open a terminal, then open Vim, then you press a key
> > and it opens the Devhelp assistant window).
> >
> > So, what would be your suggestion in such a use-case? To still retain
> > the flexibility of Devhelp.
> >
> > Thanks,
> > Sébastien
> >
> > [1] https://wiki.gnome.org/Apps/Devhelp (an API browser)
>
>


Re: Use-case when positioning a window is necessary

2022-08-08 Thread Sébastien Wilmet
On Mon, 2022-08-08 at 15:11 +0200, Olivier Fourdan wrote:
> On Mon, 8 Aug 2022 at 14:50, Sébastien Wilmet
>  wrote:
> > 
> > With Wayland, this should be implemented with a subsurface. I may be
> > wrong, but in this case it's not possible, because it's not the same
> > app (the same process).
> > 
> 
> See the xdg-foreign protocol [2].
> 
> [2] 
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/unstable/xdg-foreign

Thanks! I didn't know this.


Position set/get prototype template

2022-08-08 Thread samuel ammonius
Hi,

I started a discussion a while ago about the possibility of adding position
set/get abilities to wayland, but since then I'd learned alot about how
wayland works. I had heard that wayland combines the WM and server into one
"compositor", but I thought wayland itself still managed some things. Since
then I've learned that the compositor manages every event that a wayland
client sends, and I think this makes the ability to set/get a position even
more necessary. The reasons are:

   1. Apps can send both the position they want for a window and and the
   type of window, and a compositor can choose which one to follow. (for
   example, a client can send (width/2, height/2) and "popup" for a popup
   surface, and compositors that prefer to follow the descriptive design will
   follow "popup" and ones that prefer prescriptive design will follow the
   coordinates).
   2. Waylands asynchronous event system means that a compositor can ask
   users if they would like to give an app permission to move itself and/or
   other windows, similar to how android asks before giving apps camera/GPS
   permissions.

I've looked at existing wayland protocols and used them to create a simple
one for position set/get.

--


  Copyright © 2022 Samuel
AmmoniusPermission is hereby granted, free of charge, to any
person obtaining acopy of this software and associated
documentation files (the "Software"),to deal in the Software
without restriction, including without limitationthe rights to
use, copy, modify, merge, publish, distribute, sublicense,and/or
sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice (including the
nextparagraph) shall be included in all copies or substantial
portions of theSoftware.THE SOFTWARE IS PROVIDED "AS IS",
WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY,FITNESS FOR A
PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALLTHE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
   LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISINGFROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE
OR OTHERDEALINGS IN THE SOFTWARE.  

  Used to set/get the
position of a surface. The ability to set the monitor that a surface
is on is not available yet.


  Warning! The protocol described in this file is experimental and
 backward incompatible changes may be made. Backward compatible
changes  may be added together with the corresponding interface
version bump.  Backward incompatible changes are done by bumping
the version number in  the protocol and interface names and
resetting the interface version.  Once the protocol is to be
declared stable, the 'z' prefix and the  version number in the
protocol and interface names are removed and the  interface
version number is reset.

  Set the position of a surface  

  

  

  

   Notification that a surface has been moved, either by
itself, another program, or the compositor.

WARNING: Do not use this event to force a surface to a certain
position. If multiple apps want the surface in a different position,
then the computer may freeze or glitch.

  

  

  





  

  







--

Should I just send it or is my reasoning (or XML syntax) wrong?


Re: Position set/get prototype template

2022-08-08 Thread Simon Ser
Hi,

As we already tried to explain numerous times in the previous thread:
no, we are not adding requests and events to set/get the window position.

If you are interested in fixing an app which doesn't work on Wayland
because of this omission, please explain your use-case, and we can
discuss solutions.

If you are not interested in explaining the use-cases, and are just
interested in blindly adding new features: sorry, but this isn't how we
want to approach things.

Thanks,

Simon


Re: Position set/get prototype template

2022-08-08 Thread Igor Korot
Hi, Simon,

On Mon, Aug 8, 2022, 9:37 AM Simon Ser  wrote:

> Hi,
>
> As we already tried to explain numerous times in the previous thread:
> no, we are not adding requests and events to set/get the window position.
>
> If you are interested in fixing an app which doesn't work on Wayland
> because of this omission, please explain your use-case, and we can
> discuss solutions.
>

My app that I'm still building will "not" work on Wayland reliably.
I tried at least 2 times to give very specific scenarios and was told to go
away.
No explanation, possible fixes or workarounds.
Just plain "we are not doing because it's by design".

I guess people (Software developers) will have to pray X11 will stay
forever.

Thank you.


> If you are not interested in explaining the use-cases, and are just
> interested in blindly adding new features: sorry, but this isn't how we
> want to approach things.
>
> Thanks,
>
> Simon
>


Re: Position set/get prototype template

2022-08-08 Thread Igor Korot
Hi,



On Mon, Aug 8, 2022, 9:27 AM samuel ammonius  wrote:

> Hi,
>
> I started a discussion a while ago about the possibility of adding
> position set/get abilities to wayland, but since then I'd learned alot
> about how wayland works. I had heard that wayland combines the WM and
> server into one "compositor", but I thought wayland itself still managed
> some things. Since then I've learned that the compositor manages every
> event that a wayland client sends, and I think this makes the ability to
> set/get a position even more necessary.
>

On top of that, the end user (a human sitting behind the monitor) can
reconfigure everything, because "we all know better and computers are dumb".


The reasons are:
>
>1. Apps can send both the position they want for a window and and the
>type of window, and a compositor can choose which one to follow. (for
>example, a client can send (width/2, height/2) and "popup" for a popup
>surface, and compositors that prefer to follow the descriptive design will
>follow "popup" and ones that prefer prescriptive design will follow the
>coordinates).
>2. Waylands asynchronous event system means that a compositor can ask
>users if they would like to give an app permission to move itself and/or
>other windows, similar to how android asks before giving apps camera/GPS
>permissions.
>
> I've looked at existing wayland protocols and used them to create a simple
> one for position set/get.
>
> --
>
>
>   
> Copyright © 2022 Samuel AmmoniusPermission is hereby 
> granted, free of charge, to any person obtaining acopy of this software 
> and associated documentation files (the "Software"),to deal in the 
> Software without restriction, including without limitationthe rights to 
> use, copy, modify, merge, publish, distribute, sublicense,and/or sell 
> copies of the Software, and to permit persons to whom theSoftware is 
> furnished to do so, subject to the following conditions:The above 
> copyright notice and this permission notice (including the nextparagraph) 
> shall be included in all copies or substantial portions of theSoftware.   
>  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR   
>  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS IN THE SOFTWARE.  
>
>   Used to set/get the position of a surface. The 
> ability to set the monitor that a surface is on is not available yet.
>
>
>   Warning! The protocol described in this file is experimental and  
> backward incompatible changes may be made. Backward compatible changes  
> may be added together with the corresponding interface version bump.  
> Backward incompatible changes are done by bumping the version number in  
> the protocol and interface names and resetting the interface version.  
> Once the protocol is to be declared stable, the 'z' prefix and the  
> version number in the protocol and interface names are removed and the  
> interface version number is reset.
>
>
> Set the position of a surface  
>
>summary="target surface"/>
>
>   
>
>   
>
>Notification that a surface has been moved, either by
> itself, another program, or the compositor.
>
> WARNING: Do not use this event to force a surface to a certain 
> position. If multiple apps want the surface in a different position, then the 
> computer may freeze or glitch.
>
>   
>
>   
>
>   
>
> 
>
> 
>
>   
>
>   
>
> 
>
> 
>
> 
>
> --
>
> Should I just send it or is my reasoning (or XML syntax) wrong?
>
>


Re: Position set/get prototype template

2022-08-08 Thread Igor Korot
Or even better - when one of you will need to quickly create a
"proof-of-concept" application that will jump all over the places on every
startup...

Thank you.


On Mon, Aug 8, 2022, 9:37 AM Simon Ser  wrote:

> Hi,
>
> As we already tried to explain numerous times in the previous thread:
> no, we are not adding requests and events to set/get the window position.
>
> If you are interested in fixing an app which doesn't work on Wayland
> because of this omission, please explain your use-case, and we can
> discuss solutions.
>
> If you are not interested in explaining the use-cases, and are just
> interested in blindly adding new features: sorry, but this isn't how we
> want to approach things.
>
> Thanks,
>
> Simon
>


Re: Position set/get prototype template

2022-08-08 Thread Daniel Stone
Igor,

On Mon, 8 Aug 2022 at 15:54, Igor Korot  wrote:
> Or even better - when one of you will need to quickly create a 
> "proof-of-concept" application that will jump all over the places on every 
> startup...

We've written applications for years. We know how to make it work.
We've explained to you how to make it work. It may not work in the
exact way you have in your head, but the real usecases can and do
work, even if you won't listen to patient explanations.

This discussion has more than run its course by now. Unfortunately as
you seem hellbent on continuing to repeat the same thing over and over
without listening to anything else being said, your posts will now be
moderated.

Cheers,
Daniel


Re: Position set/get prototype template

2022-08-08 Thread samuel ammonius
Hi,

On Mon, Aug 8, 2022 at 12:06 PM Simon Ser  wrote:

> If you are not interested in explaining the use-cases, and are just
> interested in blindly adding new features: sorry, but this isn't how we
> want to approach things.


Sorry for not giving a more specific answer to this earlier. The main
reason is regarding an app's location when it starts up. For example, a
large workspace application like VS-Studio or Blender may want to start
maximized, but not full screen. AFAIK, Wayland has a protocol for
fullscreen but not for maximizing/minimizing an app, so this can only be
done by setting the position to (0, 0) and setting the size to the viewport
size of the compositor. Other apps may want to start where they left off. I
know that this is something that the compositor should handle by default,
but many of them don't. The largest obstacle is that apps like screenshot
utilities may want to start in the top left, autoclickers start in the top
right, console applications start in the center when opened with ALT+T, and
many other small situations like. There are probably many other scenarios
like this, and it seems like an unnecessary amount of pain to add a new
protocol every time a new thing pops up.

Anyways, I don't see the harm in adding this feature. Who says that a
compositor is any smarter than an app? Many compositors don't support
remembering a window's location, while many apps do. Apps aren't users, so
taking power away from them isn't "making things simpler".

On Mon, Aug 8, 2022 at 1:13 PM Daniel Stone  wrote:

> Igor,
>
> On Mon, 8 Aug 2022 at 15:54, Igor Korot  wrote:
> > Or even better - when one of you will need to quickly create a
> "proof-of-concept" application that will jump all over the places on every
> startup...
>
> We've written applications for years. We know how to make it work.
> We've explained to you how to make it work. It may not work in the
> exact way you have in your head, but the real usecases can and do
> work, even if you won't listen to patient explanations.
>
> This discussion has more than run its course by now. Unfortunately as
> you seem hellbent on continuing to repeat the same thing over and over
> without listening to anything else being said, your posts will now be
> moderated.
>
> Cheers,
> Daniel
>


Re: Position set/get prototype template

2022-08-08 Thread Daniel Stone
Hi Samuel,

On Mon, 8 Aug 2022 at 17:04, samuel ammonius  wrote:
> On Mon, Aug 8, 2022 at 12:06 PM Simon Ser  wrote:
>> If you are not interested in explaining the use-cases, and are just
>> interested in blindly adding new features: sorry, but this isn't how we
>> want to approach things.
>
> Sorry for not giving a more specific answer to this earlier. The main reason 
> is regarding an app's location when it starts up. For example, a large 
> workspace application like VS-Studio or Blender may want to start maximized, 
> but not full screen. AFAIK, Wayland has a protocol for fullscreen but not for 
> maximizing/minimizing an app

Wayland does have a protocol for maximising apps. Without it, we
wouldn't have been able to ship as the default desktop for every
mainline distribution for several years now. I recommend you look into
the xdg-shell family of protocols. Introductory guides to Wayland will
also cover this.

> ... so this can only be done by setting the position to (0, 0) and setting 
> the size to the viewport size of the compositor. Other apps may want to start 
> where they left off. I know that this is something that the compositor should 
> handle by default, but many of them don't. The largest obstacle is that apps 
> like screenshot utilities may want to start in the top left, autoclickers 
> start in the top right, console applications start in the center when opened 
> with ALT+T, and many other small situations like. There are probably many 
> other scenarios like this, and it seems like an unnecessary amount of pain to 
> add a new protocol every time a new thing pops up.
>
> Anyways, I don't see the harm in adding this feature. Who says that a 
> compositor is any smarter than an app? Many compositors don't support 
> remembering a window's location, while many apps do. Apps aren't users, so 
> taking power away from them isn't "making things simpler".

It's not taking any power away from apps. It's giving the entire
ecosystem more power. It takes more work to achieve than just blindly
taking the shortest possible path, but conversely it also saves us
from being painted into the same corners that made X11 no longer
viable.

Cheers,
Daniel


Re: Position set/get prototype template

2022-08-08 Thread samuel ammonius
Hi Daniel,

I've just looked at the xdg-shell protocol as you said. I was really
surprised at the
amount of features it had, but one part in particular caught my eye:

The window geometry of a
surface is its "visible bounds" from theuser's perspective.
Client-side decorations often have invisibleportions like
drop-shadows which should be ignored for thepurposes of aligning,
placing and constraining windows.   The window geometry is double
buffered, and will be applied at thetime wl_surface.commit of the
corresponding wl_surface is called. Once the window geometry of the
surface is set, it is not possible to   unset it, and it will remain the
same until set_window_geometry is   called again, even if a new
subsurface or buffer is attached.   If never set, the value is the full
bounds of the surface,  including any subsurfaces. This updates
dynamically on everycommit. This unset is meant for extremely simple
clients.The arguments are given in the surface-local coordinate space
of  the wl_surface associated with this xdg_surface.The width and
height must be greater than zero. Setting an invalid size   will raise
an error. When applied, the effective window geometry will be   the set
window geometry clamped to the bounding rectangle of thecombined
geometry of the surface of the xdg_surface and the
associated  subsurfaces.  * <---
>  
> <---*   type="int"/>  
>
> Doesn't this mean that Wayland already supports this?


Re: Position set/get prototype template

2022-08-08 Thread samuel ammonius
(I forgot to mention in the above message that I was looking at the
unstable version)

On Mon, Aug 8, 2022 at 1:54 PM samuel ammonius  wrote:

> Hi Daniel,
>
> I've just looked at the xdg-shell protocol as you said. I was really
> surprised at the
> amount of features it had, but one part in particular caught my eye:
>
>The window geometry of a surface is its "visible 
> bounds" from the   user's perspective. Client-side decorations often have 
> invisibleportions like drop-shadows which should be ignored for the   
>purposes of aligning, placing and constraining windows. The window 
> geometry is double buffered, and will be applied at the  time 
> wl_surface.commit of the corresponding wl_surface is called.   Once the 
> window geometry of the surface is set, it is not possible to   unset it, and 
> it will remain the same until set_window_geometry is  called again, even 
> if a new subsurface or buffer is attached.   If never set, the value is the 
> full bounds of the surface,  including any subsurfaces. This updates 
> dynamically on everycommit. This unset is meant for extremely simple 
> clients.   The arguments are given in the surface-local coordinate space 
> ofthe wl_surface associated with this xdg_surface.The width 
> and height must be greater than zero. Setting an invalid size will raise an 
> error. When applied, the effective window geometry will bethe set 
> window geometry clamped to the bounding rectangle of thecombined 
> geometry of the surface of the xdg_surface and the associated  subsurfaces.   
>* 
> <---
>>  
>> <---*  > type="int"/>  
>>
>> Doesn't this mean that Wayland already supports this?
>


Re: Position set/get prototype template

2022-08-08 Thread Daniel Stone
On Mon, 8 Aug 2022 at 17:24, samuel ammonius  wrote:
> I've just looked at the xdg-shell protocol as you said. I was really 
> surprised at the
> amount of features it had, but one part in particular caught my eye:

Window geometry is relative to surface co-ordinates. As the first
paragraph describes, it is used to describe the region of the surface
which excludes external decor like drop shadows.

One thing you might note is that Wayland does not supply a global
co-ordinate space to clients. Everything is supplied in a surface
co-ordinate space. Again, this will become clear if you took the time
to work through an introductory guide to Wayland.

Think of it this way: the developers are giving you their time and
effort by explaining to you how Wayland works, and trying to guide you
through why your proposed designs are unworkable. It would be very
polite if you could repay the favour by investing some of your time
and effort to understand Wayland before proposing drastic changes to
it and demanding the developers justify why they won't be accepted.

Cheers,
Daniel


Re: Position set/get prototype template

2022-08-08 Thread Carsten Haitzler
On Mon, 8 Aug 2022 16:42:02 +0100 Daniel Stone  said:

> Igor,
> 
> On Mon, 8 Aug 2022 at 15:54, Igor Korot  wrote:
> > Or even better - when one of you will need to quickly create a
> > "proof-of-concept" application that will jump all over the places on every
> > startup...
> 
> We've written applications for years. We know how to make it work.
> We've explained to you how to make it work. It may not work in the
> exact way you have in your head, but the real usecases can and do
> work, even if you won't listen to patient explanations.
> 
> This discussion has more than run its course by now. Unfortunately as
> you seem hellbent on continuing to repeat the same thing over and over
> without listening to anything else being said, your posts will now be
> moderated.

What Daniel said. My mistake for putting fuel on the fire and explaining why
Wayland does not have explicit positioning. I hoped to provide some explaining
of the history of pain that led up to things being this way (and there are
decades of experience per experienced Wayland developer who supports this).
We've all done everything from display servers to window managers to
compositors, toolkits, applications and more for many decades.

Solve the corner cases not already solved. Don't do "give me a sledgehammer to
break the world with" with explicit positioning.

-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com



Re: Position set/get prototype template

2022-08-08 Thread samuel ammonius
Hi Igor,

I don't understand why you would want to be able to control where a
dialog goes. I'd normally agree that applications should be given the
option to do whatever they want, but a dialog is literally the worst
example possible second only to splash screens. Wayland allows
the user to control weather all dialogs should be centred in the screen
or in their parent application. Why is this a bad thing?

OR do what the
> user has explicitly configured it to do because the user wants something
> broken (and the compositor allows it),

This was only supposed to mean that users are able to configure their
compositor in strange ways and still have all apps behave the same.
Normally I'd argue that apps should still be given the option to ignore
these preferences (or at least a standard way to *ask* the compositor
if it can ignore them), but not with dialogs. I'm assuming you're talking
about Yes/No-type dialogs.


Re: Use-case when positioning a window is necessary

2022-08-08 Thread Sébastien Wilmet
On Mon, 2022-08-08 at 15:37 +0200, Benoît Gschwind wrote:
> 
> After a quick reading of your DevHelp case, I think the issue belong
> devhelp and your app that using it. DevHelp have to provide an API to
> be embeded in another application and Wayland protocol should not be
> involved. Maybe d-bus can be used as pipe between DevHelp and others
> applications.

The summary is as below:

> Le lundi 08 août 2022 à 14:12 +0200, Sébastien Wilmet a écrit :



> > With Wayland, this should be implemented with a subsurface. I may be
> > wrong, but in this case it's not possible, because it's not the same
> > app (the same process).
> > 
> > (For example you open a terminal, then open Vim, then you press a key
> > and it opens the Devhelp assistant window).



As Olivier suggested, the xdg-foreign protocol would be a solution. I
don't know if it's easy to implement, in a general way *from* any app
(terminal etc) *to* Devhelp.

But at least I know that it's feasible, and that Wayland supports it.

Your solution might work as well, I don't know.

Cheers,
Sébastien


Re: Window positions under wayland

2022-08-08 Thread JiDe Zhang
Thanks. I read https://mir-server.io/docs/window-positions-under-wayland, Is 
your standpoint by adding more shell protocols to support windows that behave 
differently rather than allowing the client to take full control window 
position to implement some special behavior? Agree, wayland should maintain its 
current design goals.

--JiDe Zhang -- linuxdeepin.