On Wed, Aug 12, 2015 at 2:08 AM, Kevin Gunn
wrote:
I tend to agree, although i am curious to hear what others think.
My hope would be that we'd be balanced about adopting "new language
variants and dependencies" - if we have reasons to do so, then do
those outweigh stagnating for the sake of b
On Wed, Aug 12, 2015 at 12:03 PM, Daniel van Vugt
wrote:
I feel that is just making excuses to not aim higher. The whole
platform changes every six months and yes Linux developers are used
to the pain that comes with that. But would it hurt us to try and
make Mir one of the more stable parts o
On Wed, Aug 12, 2015 at 12:17 PM, Daniel van Vugt
wrote:
We did. C++14 was completely unnecessary and the reason why you can't
build Mir on our latest LTS today (without PPAs etc). The change to
the code was mostly cosmetic. Yes, that did make our lives slightly
easier in parts, but to what co
On Wed, Aug 12, 2015 at 2:02 PM, Daniel van Vugt
wrote:
My personal experience (and what I've observed in our users over
years of playing customer support) is that plenty of intelligent
people prefer LTS over the latest release. For stability and long
term support. I feel that's a reasonable
On Fri, Aug 14, 2015 at 1:59 PM, Daniel van Vugt
wrote:
OK, this is a bit messy. Mir still doesn't build on wily.
There is already a fix for the protobuf issue that was holding us up,
but I'm not sure if it's the permanent solution. The fix is to use
the new "v5" protobuf packages in wily-pro
On Tue, Aug 25, 2015 at 4:05 AM, Gerry Boland
wrote:
Hey folks,
chatting with the UITK guys, they need support for UI scaling (i.e.
grid
unit value) per display. I think adding a scale parameter to Mir would
make sense for this. I've written up a proposal here, please have a
look
and see wha
On Thu, Aug 27, 2015 at 12:05 PM, Daniel van Vugt
wrote:
That's true. If someone adds a field to a struct or changes the size
of a bool, symbol names don't change. Even worse; how do you
communicate that myprojectN uses libstdc++M? In a past life I
actually went to the trouble of putting out d
On Thu, Aug 27, 2015 at 1:30 PM, Daniel van Vugt
wrote:
That's the problem. We don't have abi-check automated yet. Although
we don't have to limit ourselves to that.
What we do have is regular ABI breaks landing and nobody noticing. So
I audit the code manually and propose the missing brea
On Sat, Aug 29, 2015 at 2:27 AM, Alexandros Frantzis
wrote:
On Fri, Aug 28, 2015 at 04:46:24PM +0100, Alan Griffiths wrote:
The current approach to naming stanzas in the symbol maps leads to a
potential for mistakes. For example, src/platform/symbols.map has
the
following stanzas:
MIRPLA
On Wed, Sep 2, 2015 at 1:26 PM, Daniel van Vugt
wrote:
Hypothetically the "9" could now go away. Internally that's fine:
MIR_PLATFORM_0.16
Right. I even suggested this upthread.
But externally if we started naming the files as such then it might
get confusing:
libmirplatform.so.0.17
Forked from review¹.
I think we're currently handling display configuration events
incorrectly, or at least in a way that will be surprising to clients.
When the hardware configuration changes we send the new configuration
to all clients. However, if a client has specified a different display
On Fri, Oct 2, 2015 at 7:00 AM, Gerry Boland
wrote:
On 01/10/15 17:55, Alan Griffiths wrote:
On 01/10/15 17:20, Gerry Boland wrote:
/me suspecting we'll need a doc.
We will, but at the moment we're still brainstorming requirements.
BTW IIRC at the pocket desktop sprint you were interest
On Thu, Sep 10, 2015 at 1:28 AM, Alan Griffiths
wrote:
After today's standup Stephen said that Chris will update the
doc/dso_versioning_guide.md to incorporate the ideas from this thread.
There's a proposal up at
https://code.launchpad.net/~raof/mir/new-dso-versioning-policy/+merge/273186
no
On Tue, Oct 6, 2015 at 2:33 AM, Alan Griffiths
wrote:
On 05/10/15 12:12, Alexandros Frantzis wrote:
but we should ensure
our built-in cursor images support all the predefined cursor types.
In
our client API we are exposing a set of predefined cursor names,
which
the BuiltinCursorImage im
On Tue, Oct 6, 2015 at 12:32 PM, Daniel van Vugt
wrote:
Named cursors were not my first choice. There was some arguing when
it was proposed. I personally prefer a set enums, which matches what
common toolkits use:
https://developer.gnome.org/gdk3/stable/gdk3-Cursors.html#GdkCursorType
tl;dr: Whenever you need to add a new symbol, add it to a
MIR_*_unreleased stanza (or create that stanza if it does not exist).
So,
https://code.launchpad.net/~raof/mir/new-dso-versioning-policy/+merge/273186
has just landed, with the new symbol versioning scheme documentation.
From a develo
On Mon, Oct 12, 2015 at 10:53 PM, Alexandros Frantzis
wrote:
On Wed, Sep 30, 2015 at 12:50:14PM +0300, Alexandros Frantzis wrote:
On Wed, Sep 30, 2015 at 02:04:00PM +1000, Christopher James Halse
Rogers wrote:
> Forked from review¹.
>
> I think we're currently ha
On Tue, Oct 13, 2015 at 12:36 PM, Darren Landoll
wrote:
…
$ sudo qtdeclarative5-examples-amd64.clocks
Bad system call
Loading module: 'libubuntu_application_api_desktop_mirclient.so.2.9.0'
[1444693723.318984] Loader: Loading modules from:
/apps/mir/snap1.1/debs/usr/lib/x86_64-linux-gnu/mir/
On Thu, Oct 22, 2015 at 5:15 AM, Thomas Voß
wrote:
On Wed, Oct 21, 2015 at 4:38 PM, Alan Griffiths
wrote:
On 21/10/15 11:38, Thomas Voß wrote:
Well, we always need to satisfy the case of handing configuration
up & down a
nested shell scene. If we don't add the respective functionality
Seems sensible; should this become necessary again we're very nearly in
a position to accommodate it as a no-core-changes-needed platform
anyway.
On Wed, Jul 6, 2016 at 11:40 PM, Kevin DuBois
wrote:
Sounds good to me, screencasting seems to have become the preferred
way that capturing output
On Thu, Sep 1, 2016 at 9:02 PM, Alan Griffiths
wrote:
When clients toolkits provide hints to place child surfaces using the
existing functions:
mir_surface_spec_attach_to_foreign_parent();
mir_connection_create_spec_for_tip();
mir_connection_create_spec_for_menu(); or the proposed,
mir_sur
On Tue, Sep 6, 2016 at 2:21 AM, Alan Griffiths
wrote:
On 02/09/16 15:44, Alan Griffiths wrote:
On 02/09/16 15:42, Thomas Voß wrote:
This only works in the fullscreen case and I
cannot think of a scenario where this impacts overall
user experience. The app already is the one "owning" the dis
On Thu, Sep 8, 2016 at 5:09 AM, Cemil Azizoglu
wrote:
Regardless of what EGL (or any other API) needs, there needs to be
a way for Mir platform to generically represent a unit of renderable
(hw or sw) with a distinct type. That's what MirRenderSurface
provides. "Generically" in the sense t
On Thu, Sep 8, 2016 at 9:36 PM, Kevin DuBois
wrote:
On Wed, Sep 7, 2016 at 8:01 PM, Christopher James Halse Rogers
wrote:
On Thu, Sep 8, 2016 at 5:09 AM, Cemil Azizoglu
wrote:
Regardless of what EGL (or any other API) needs, there needs to
be a way for Mir platform to generically
On Fri, Sep 9, 2016 at 4:18 AM, Cemil Azizoglu
wrote:
We quite literally cast MirRenderSurface* to EGLNativeWindowSurface
in the current WIP:
http://bazaar.launchpad.net/%7Ecemil-azizoglu/mir/mir-render-surface-v3/view/head:/playground/eglflash_render_surface.c#L112
Perhaps, I should point
Thinking about this further, I think we'll *have* to implement a shim
libEGL in the not-too-distant future. We can't propose or use
EGL_KHR_platform_mir unless we implement it on the Android stack. (And
we want to, because it's useful in certain cases).
So I therefore think we *should*:
#defin
damentally designed for it
- and because Android is fundamentally designed for it, it's no easier
to do in the client platform than in a libEGL.
IMHO, The decision to define our own windowing type is something that
will affect more than just the mir team (it has to do a bit with
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
;report" makes me think it is
ineffectual to server behavior.
On 15/09/16 10:01, Christopher James Halse Rogers wrote:
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'
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 wou
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'
On Fri, Nov 25, 2016 at 9:03 PM, 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 c
So, client-eventloop-driven MirConnection is getting really close to
working properly.
The latest problem I've run into is
mir_render_surface_get_buffer_stream - this purports to be a no-RPC
call and so doesn't take a callback/have a _sync version, but the
mcl::BufferStream constructor *does*
101 - 133 of 133 matches
Mail list logo
