[Wayland-bugs] [Bug 744932] Wrong (ultra tiny/small) cursor size on HiDPI screen

[mutter (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=744932

--- Comment #42 from Owen Taylor <otaylor at redhat.com> ---
(In reply to Jonas Ådahl from comment #39)
> > 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-bugs/attachments/20150706/52166df7/attachment.html>