Subject: Should this be "core"?

From: Alan Griffiths <[email-masked]>
Date: Mon, 5 Oct 2015 11:33:44 +0100

In debugging our cursor code and getting it under tests I found
something surprising (to me). Vis:

std::shared_ptr<mi::CursorImages>
mir::DefaultServerConfiguration::the_cursor_images()
{
    return cursor_images( [this]() -> std::shared_ptr<mi::CursorImages>
        {
            auto xcursor_loader = std::make_shared<mi::XCursorLoader>();
            if (has_default_cursor(*xcursor_loader))
                return xcursor_loader;
            else return std::make_shared<mi::BuiltinCursorImages>();
        });
}

Which translates to "see if X cursors images are available, if so use
them, otherwise use a builtin cursor". I don't think this is correct
behaviour for *core* libmirserver - I think that should always and
predictably use the builtin image. Something like the above makes
perfect sense in example code, but I don't think we should hard wire
this as the default.

Does anyone have an objection to changing the above to...

std::shared_ptr<mi::CursorImages>
mir::DefaultServerConfiguration::the_cursor_images()
{
    return cursor_images( [this]() -> std::shared_ptr<mi::CursorImages>
        {
 return std::make_shared<mi::BuiltinCursorImages>();
        });
}

...and moving the X cursor support to libexampleserverconfig.a?

---

From: Alexandros Frantzis <[email-masked]>
Date: Mon, 5 Oct 2015 14:12:34 +0300

> ...and moving the X cursor support to libexampleserverconfig.a?

We are using the X cursor support as a convenient way to theme the
cursors. If we consider cursor theming to be core functionality on the
server side, then leveraging existing infrastructure is a reasonably way
to achieve it, and the XCursor code should remain as the default
implementation.

Otherwise, we could remove XCursor based theming, but we should ensure
our built-in cursor images support all the predefined cursor types. In
our client API we are exposing a set of predefined cursor names, which
the BuiltinCursorImage implementation doesn't currently support.
Although we don't explicitly promise that these are always supported, it
would be surprising if our default implementation didn't provide them.

I think that the cursor buffer stream mechanism is enough to cover the
needs of clients by moving cursor theme support to the client/toolkit
side, but I don't feel I have enough information on the matter yet to
make a final decision.

-- 
Alexandros

---

From: Alan Griffiths <[email-masked]>
Date: Mon, 5 Oct 2015 12:19:53 +0100

> would be surprising if our default implementation didn't provide them.

FWIW *my* initial surprise came from finding that tests using the
predefined cursor names don't work on phone images. (Because X cursors
are not present and libmirserver falls back to BuiltinCursorImage.)

So the problem exists already.

---

From: Alan Griffiths <[email-masked]>
Date: Mon, 5 Oct 2015 16:33:12 +0100

On 05/10/15 12:12, Alexandros Frantzis wrote:
> but we should ensure

To clarify, BuiltinCursorImage does support retrieving a cursor image
for the predefined cursor names. It is just that it always returns one
based on "black_arrow".

Is that good enough default behaviour?

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Tue, 06 Oct 2015 10:17:37 +1100

> Is that good enough default behaviour?

Not really.

I think we should do one of two things:
1) Remove that cursor-names interface entirely and just rely on getting 
a BufferStream for the cursor, or,
2) If the *shell* wants to use the named-cursor support (I don't 
believe it does?) then we should install an xcursor theme on the phone 
and remove BuiltinCursorImage.

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 6 Oct 2015 09:27:29 +0800

I agree. In fact, I've always been bugged by the switching to X cursor 
themes, which only happens on some systems. Not only is it inconsistent 
but feels like we're leaning on legacy X too much.

It also became apparent those X cursors are unusably small on a 4K 
display. We do have bigger ones for Unity7 but I don't know where that 
cursor theme switching happens.

On 05/10/15 18:33, Alan Griffiths wrote:
>      return cursor_images( [this]() ->std::shared_ptr<mi::CursorImages>
>          {
>              auto xcursor_loader =std::make_shared<mi::XCursorLoader>();
>      return cursor_images( [this]() ->std::shared_ptr<mi::CursorImages>
>          {

---

From: Daniel van Vugt <[email-masked]>
Date: Tue, 6 Oct 2015 09:32:18 +0800

Named cursors were not my first choice. There was some arguing when it 
was proposed. I personally prefer a set enums, which matches what common 
toolkits use:

    https://developer.gnome.org/gdk3/stable/gdk3-Cursors.html#GdkCursorType
    http://qt-project.org/doc/qt-5/qt.html#CursorShape-enum
 
http://www.opengl.org/resources/libraries/glut/spec3/node28.html#SECTION000513000000000000000

But you can't kill named cursor support unless you replace it with 
equivalent enums.

BufferStream (or just plain bitmap) cursor support is also still 
required. I think that's what Xmir uses mostly.

On 06/10/15 07:17, Christopher James Halse Rogers wrote:
> 2) If the *shell* wants to use the named-cursor support (I don't believe
> it does?) then we should install an xcursor theme on the phone and
> remove BuiltinCursorImage.
>
>

---

From: Christopher James Halse Rogers <[email-masked]>
Date: Tue, 06 Oct 2015 12:56:55 +1100

On Tue, Oct 6, 2015 at 12:32 PM, Daniel van Vugt 
<[email-masked]> wrote:
> Named cursors were not my first choice. There was some arguing when 
> it was proposed. I personally prefer a set enums, which matches what 
> common toolkits use:
> 
>    

You absolutely can. An existence proof is Wayland, which has no such 
support.

We might *want* to support named cursors, because we think it'll make 
it more likely that clients will use the right cursor themes etc, but 
even here there doesn't need to be server support - it can be 
implemented in the client library.

---

From: Andreas Pokorny <[email-masked]>
Date: Tue, 6 Oct 2015 08:13:56 +0200

Hi,

On Tue, Oct 6, 2015 at 3:56 AM, Christopher James Halse Rogers <
[email-masked]> wrote:

>
>
> On Tue, Oct 6, 2015 at 12:32 PM, Daniel van Vugt <
> [email-masked]> wrote:
>
> We might *want* to support named cursors, because we think it'll make it
> more likely that clients will use the right cursor themes etc, but even
> here there doesn't need to be server support - it can be implemented in the
> client library.
>
>
For that purpose yes. But as soon as shells want to override that, and or
make decisions based on the selected cursor. However I am not sure how
useful that would be, given that the client might just provide a buffer for
the cursor.

regards
Andreas

---

From: Daniel d'Andrada <[email-masked]>
Date: Tue, 6 Oct 2015 13:37:23 -0300

> cursor theme switching happens. 

Cursors in dmz-cursor-theme (the one Unity 7&8 uses) come in 3 different 
sizes. The largest one is 48 pixels high and looks more than enough on 
my 2160p 28" monitor.

mir is hardcoded to use the default theme (/usr/share/icons/default, 
which points to /etc/alternatives/x-cursor-theme). dmz-cursor-theme 
installs itself as such. In this configuration, theme selection happens 
by changing the symlink /etc/alternatives/x-cursor-theme (ie, updating 
the alternative)

Naming is a bit wacky in xcursors. The "I" beam cursor for instance is 
called "x-term". So yeah, a lot of legacy in there.