Display configuration

[Daniel van Vugt]

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,
>>
>>
>