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?
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
