Re: Wayland design principles (Re: wayland and gambas)
On Tuesday 2024-04-30 07:23, Carsten Haitzler wrote: >> >> Although gambas provides a Settings.Write(window_name) / >> Settings.Read(window_name) that saves/restores the window placement and >> size. It's bearable Wayland does not handle this. > >YOU should never be handling this. It's like saying "I'm used to having to >hand-crank my car's motor for it to start... why can't I keep doing that?". In keeping with the car analogy: one *can* handcrank the motor, one just needs a vehicle that implements *that*, so like youtu.be/4SZExEgLT_0 or, indeed, running gambas on an X11 interface (xorg-server, Xnest, Xwayland...) >If all you do is the above, you've barely scratched the surface of >"remembering my window". Things you don't handle above: > >1. Stacking remembering (relative to other things you may know nothing about >like someoene else's windows) I do not think anybody seriously uses overlaps, because searching in stacks (Alt-Tab or whatever method) is kinda inefficient. People either go big screen, workspaces/virtual desktops, or (say) temporarily exiting/suspending an editor to run the compiler.
Re: Wayland design principles (Re: wayland and gambas)
On Wed, 1 May 2024 09:35:30 +0200 (CEST) Jan Engelhardt said: > > On Tuesday 2024-04-30 07:23, Carsten Haitzler wrote: > >> > >> Although gambas provides a Settings.Write(window_name) / > >> Settings.Read(window_name) that saves/restores the window placement and > >> size. It's bearable Wayland does not handle this. > > > >YOU should never be handling this. It's like saying "I'm used to having to > >hand-crank my car's motor for it to start... why can't I keep doing that?". > > In keeping with the car analogy: one *can* handcrank the motor, one just > needs a vehicle that implements *that*, so like youtu.be/4SZExEgLT_0 or, > indeed, running gambas on an X11 interface (xorg-server, Xnest, > Xwayland...) > > >If all you do is the above, you've barely scratched the surface of > >"remembering my window". Things you don't handle above: > > > >1. Stacking remembering (relative to other things you may know nothing about > >like someoene else's windows) > > I do not think anybody seriously uses overlaps, because searching > in stacks (Alt-Tab or whatever method) is kinda inefficient. People > either go big screen, workspaces/virtual desktops, or (say) temporarily > exiting/suspending an editor to run the compiler. In the case mentioned here these "desktop gadgets" once you resize/scale the screen if you then scale the sizes/coords and deal with minimum surface sizes you may end up with overlaps between multiple process gadget windows (Each gadget is 1 window for 1 client/app) and the compositor can solve this by guessing they are aligned in a row and "line the up again". Apps can't do this - they don't know the other windows even exist. This also can happen with regular windows. I actually often tile my windows by hand (it's easy in E due to window resistance making it a doddle). If i e.g. switched from 3840x1440 to a 2560x144 monitor - I'd not rescale but I'd have to re-position and re-size as I had not adjusted scaling but adjusted screen aspect ratio. Each terminal of the set of 15 I have is a different window and process. Admittedly E doesn't quite realize it is a perfect grid. It's policy on such screen resizes is to remember window positions based on nearest screen anchor (top-left, top-middle, top-right, left-middle, center, right-middle, bottom-left, bottom-middle, bottom-right). This handles going up in size nicely. Down leaves some manual fiddling still but may lead to overlaps. Something I probably can fix for sure. :) -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: Wayland design principles (Re: wayland and gambas)
On Tue, 30 Apr 2024 17:21:41 -0700 Thiago Macieira said: > On Monday 29 April 2024 22:23:44 GMT-7 Carsten Haitzler wrote: > > > There is worry in our community that Wayland is going to take over and x11 > > > will become obsolete. > > > > It's inevitable. We're just arguing on timescales (I think Wayland will need > > more time to mature but it'll get there). > > I used to too, but I think we'll see X.org removed from non-LTS distros by > the end of the decade. At a minimum, I don't see it being offered as a > default for desktop distros; you'll need to install with Wayland and then > later switch to X11. We probably mostly agree here - X will be around for another 5-10y imho in distros but it'll become an optional extra install towards the end of that. At some point - maybe in 10-15 it might enter "Xwayland only" mode. But in braod strokes I think we agree. > > You might not be, but you may run some app you download from some random > > place on the internet you THINK is nice (some sodoku game trinket thing) > > but it's actually trying to steal your banking details... This is only > > getting worse in a world of snaps/flatpaks ... > > And even if most people on this list don't do that, there are people who do. > I refuse to run proprietary code as much as I can, and when I can't I want it > to run as a separate user (thus non-graphical) with very strong system > protections in the systemd .service file. 100%. I also avoid these like the plague wherever I can, but it does not remove the obligation for us to build a Wayland universe for the long term future than CAN be sandboxed and apps have limit ability to cause havoc/problems. > But I have several colleagues who download flatpaks and similars. Wayland has > to be designed with that in mind. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >Principal Engineer - Intel DCAI Cloud Engineering > > > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com
Re: How to use wl_object in wl_protocol_logger API?
I found a solution, but my offer to send a pull request adding wl_object_get_class() and wl_object_get_id() still stands. Let me know! To recap, my key question was: "The wl_protocol_logger API exposes a wl_object struct. How can I get the object class and ID from a wl_object?" To answer my own question: wl_object is actually declared here, behind an #ifndef: https://gitlab.freedesktop.org/wayland/wayland/-/blob/69633202180acce9d0d5ab4037d80291c71b2307/src/wayland-server.h#L58 The declaration is deprecated, though. I'm using it anyway for now, but I think accessor functions would be better so that I can treat wl_object as opaque. I'm happy to contribute if desired. Best regards, Chloe On Tue, Apr 16, 2024 at 10:56 AM Chloe Pelling wrote: > Hi, > > I'm attempting to use the wl_protocol_logger API to replicate the > functionality of WAYLAND_DEBUG=1 in my project, but logging to > https://perfetto.dev/ rather than stderr. I'm having some trouble > decoding message arguments of type object, since `wl_object` is an > opaque struct and there doesn't appear to be a "blessed" way to > interrogate it. In particular, there's no API to access > `wl_object::id`. > > Am I missing something? Would a patch adding wl_object_get_id() and > wl_object_get_class() functions be welcome? > > Here's what I've figured out so far: > > * Decoding the arguments requires inspecting the wl_argument unions in > `wl_protocol_logger_message::arguments`, according to the type > indications in `wl_protocol_logger_message::message->signature`. > > * Object arguments are denoted by "o" in the signature, indicating we > should examine `wl_argument::o` of type wl_object. > > * wl_object is an opaque struct, and there are no > wl_object_get_class() or wl_object_get_id() functions. > > * I can work around the lack of wl_object_get_class() by inspecting > wl_protocol_logger_message::message->types[i] for argument > wl_protocol_logger_message::arguments[i]. However, no such workaround > exists to retrieve the wl_object's id. > > * https://github.com/KDAB/GammaRay works around this problem by > casting wl_argument::o to wl_resource* and using > wl_resource_get_class() and wl_resource_get_id(). > > * This works because wl_resource's first member is wl_object, and > wl_resource_get_class() and wl_resource_get_id() are implemented only > by accessing that first member. > * While comments in wl_resource indicate that the struct layout > cannot be changed. It's unclear if that will be true forever. > * There is no guarantee that wl_resource_get_class() and > wl_resource_get_id() won't start accessing members of wl_resource > other than `object`. If they did, this technique could cause invalid > memory access due to overflowing the size of wl_object. > > I believe these are my current options: > > A) Cast wl_object* to wl_resource* like GammaRay does. I'm > uncomfortable with this, for the reasons above. > > B) Copy the definition of `struct wl_object` from wayland-private.h > into my project and access `id` directly. This might be safer than (A) > in practice, but I still don't like it. > > C) Submit a patch adding wl_object_get_class() and wl_object_get_id() > accessor functions. > > Have I missed something? Any advice would be helpful. > > Best regards, > Chloe >
