<html> <head> <base href="https://bugzilla.gnome.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Wrong (ultra tiny/small) cursor size on HiDPI screen" href="https://bugzilla.gnome.org/show_bug.cgi?id=744932#c42">Comment # 42</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Wrong (ultra tiny/small) cursor size on HiDPI screen" href="https://bugzilla.gnome.org/show_bug.cgi?id=744932">bug 744932</a> from <a href="page.cgi?id=describeuser.html&login=otaylor%40redhat.com" title="Owen Taylor <otaylor@redhat.com>"> Owen Taylor</a> <pre>(In reply to Jonas Ådahl from <a href="show_bug.cgi?id=744932#c39">comment #39</a>) > > That all being said I have some specific concerns about MetaCursorSprite vs. > > MetaCursorSpriteWayland. > > > > MetaCursorSprite, as I understand it, is basically similar to > > MetaCursorReference - it's basically a union of different ways to specify > > the appearance of a cursor. A wayland-specific subclass of this might make > > sense so that it can store along with the appearance a pointer back to a > > Wayland object. But a Wayland specific subclass shouldn't gain entirely new > > capabilities like looking going out and looking at where it is relative to > > the monitors and reloading the theme image at a different size. > > > > I feel like the parent class is fur, and the subclass is a cat! > > That might be because when an X CM, the cat lives in the X server, but in > Wayland we are the cat. I don't want to push metaphors too hard, but if we think that in the "X CM" case, the cat is in the X server, then in that case, our object should still be a cat, even if it's a remote control cat-shaped toy. > > > > Things to think about for improving the design: > > > > - Do some pieces (like loading from the theme at a different size) work > > better in the generic code, even if they are only ever used in the Wayland > > case? > > This is why I put it in the Wayland object; it only ever makes sense do do > it there. My suggestion is the opposite - sometimes it makes sense to do things in the base class *even if they are only ever used in one subclass* - this can enhance encapsulation, avoid unnecessary virtualization, or just make things make more sense. [...] > Maybe we should have such a abstraction, not calling it Wayland but "display > server", and then hook wl_surface etc to it some other way and put it under > a "protocols/" directory. Not sure what to call that though; its neither > "winsys", "protocol" or "frontend". > > I.e. something like > > backends/ > x11/ > cm/ > nested/ > protocols/ > wayland/ > x11/ > xwayland/ (funky mix of the two above) > "running mode"/ > x11_cm/ > display_server/ > > ? > > MetaCursorSprite would go under "running mode"/ and under protocols we'd > have a MetaWaylandCursor which interacts with MetaCursorSprite. Hmm, I think the directory organization is getting ahead of the code organization. How do we replace the cases where we have meta_is_wayland_compositor() conditionals? How do we move x11 and wayland specific code out of common source files in core/ and compositor/? Having nice clean subdirectories doesn't make sense if we can't move the relevant code there.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are on the CC list for the bug.</li> </ul> </body> </html>