Actually there are more functions that need fixing. But essentially I
propose we just make the header file name, type name and function names
all consistent:
mir_display_config.h // currently "mir_display_configuration.h"
mir_display_config_*() // most of the new API uses this already
MirDisplayConfig // the new API uses this already
Roughly on the same topic I've just noticed we've got some function
names in the client API now that are around 60 characters long. That's
obviously not OK and we should be careful to avoid such verbose naming
in future.
On 28/11/16 09:33, Daniel van Vugt wrote:
Indeed this is something I'm trying to make progress on and have just
explained my plan in the comments here:
https://code.launchpad.net/~vanvugt/mir/mir-display-config-header/+merge/311246
It's disapproved right now but I think when people think about the
problem a bit more that will change.
Slightly related you may be interested in:
https://code.launchpad.net/~vanvugt/mir/mirout-basic-commands/+merge/311372
I don't have an opinion on moving things between libraries yet. But in
the interest of keeping things clear and simple with minimal breaks, I
think that can be discussed separately later.
- Daniel
On 25/11/16 18:03, Alan Griffiths wrote:
It could be that I'm confused, or it could be that we're confused. So
I'm starting with a quick email. If need be I'll create a doc for
discussion.
The current situation is that we have multiple incompatible
representations of the display configuration:
1. MirDisplayConfiguration and the mir_display_config_... functions.
2. MirDisplayConfig and the mir_display_configuration_... functions.
3. The mir::graphics::DisplayConfiguration interface and the various
platform implementations.
It looks as though we have started to replace 1 with 2 but haven't yet
finished.
Looking at the code it seems the various platform implementations of 3
"just" populate similar data structures to provide the same
functionality.
I think there is enough commonality that a single internal
implementation based on 2 could be used across server, platforms and
clients. I'd go so far as to say that DisplayConfiguration is a concept
that ought to be in libmircore (with a suitably ABI-stable API).
There would be advantages to having a single representation (DRY) and,
as servers, platforms and clients can operate in the same process, it is
easier to use,
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/mir-devel
