Should this be "core"?

Daniel van Vugt daniel.van.vugt at canonical.com
Tue Oct 6 01:27:29 UTC 2015


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:
> 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?
>
>



More information about the Mir-devel mailing list