On Fri, Sep 16, 2016 at 5:08 PM, Christopher James Halse Rogers
wrote:
On Fri, Sep 16, 2016 at 4:51 PM, Alan Griffiths
wrote:
On 16/09/16 02:51, Christopher James Halse Rogers wrote:
On Thu, Sep 15, 2016 at 12:11 PM, Daniel van Vugt
wrote:
So actually... I now think it's OK providing
On Fri, Sep 16, 2016 at 4:51 PM, Alan Griffiths
wrote:
On 16/09/16 02:51, Christopher James Halse Rogers wrote:
On Thu, Sep 15, 2016 at 12:11 PM, Daniel van Vugt
wrote:
So actually... I now think it's OK providing the base class is
named *Observer. And only some implementations would be ca
On 16/09/16 08:01, Daniel van Vugt wrote:
> However the more accurate naming of the interface being an "Observer"
I guess this is the root of the discussion: I think "Report" is the more
precise name.
--
Mir-devel mailing list
Mir-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https
Sure, renaming things isn't ever absolutely necessary. However the more
accurate naming of the interface being an "Observer" if some additional
implementations are to be non-reports, feels much cleaner. So we should
at least rename the one in question. Not all of them at once...
And if a metho
Hi,
On Thu, Sep 15, 2016 at 3:43 AM, wrote:
> [...]
>
> If we *are* going to treat Reports as something that shells can
> generically hook into to drive control flow we're going to need to be more
> careful about the environment we call them in. For example, currently if a
> shell hooks into new
On 16/09/16 02:51, Christopher James Halse Rogers wrote:
> On Thu, Sep 15, 2016 at 12:11 PM, Daniel van Vugt
> wrote:
>> So actually... I now think it's OK providing the base class is named
>> *Observer. And only some implementations would be called *Report.
>
> I would also be happy with this; va
On Thu, Sep 15, 2016 at 12:11 PM, Daniel van Vugt
wrote:
So actually... I now think it's OK providing the base class is named
*Observer. And only some implementations would be called *Report.
I would also be happy with this; various components take an Observer
(which provides a register-inter
So actually... I now think it's OK providing the base class is named
*Observer. And only some implementations would be called *Report.
On 15/09/16 10:10, Daniel van Vugt wrote:
That's a good point. We don't need to change all the reporting locations.
I still don't like the idea of having to d
That's a good point. We don't need to change all the reporting locations.
I still don't like the idea of having to delegate within reports, as
well as changing their construction methods.
Although I now realize my other concern that we'd have to change all
reports at once for consistency also
On Thu, Sep 15, 2016 at 11:57 AM, Daniel van Vugt
wrote:
Not impossible, but it feels too ugly. I would prefer to keep reports
for debugging/logging only where they don't affect the behavior of
the server. And programmers can assume this is true without knowing
the implementation details of an
It feels like a hack to me. In order to maintain the assumption that
switching reports should not affect the behavior of the system they
would need to be multiplexed, effectively additive. So you add a number
of active report implementations for any given report interface without
them canceling
On a recent merge proposal¹, Alan wrote:
>> Huh. I *guess* you could use the logging interface for detecting
display
>> configuration changes.
>
> You have that backwards. The reason we have the report interfaces is
that there are things
> that need reports from Mir that are not logging.
>
>
12 matches
Mail list logo
