Re: The case for a "SceneGraph"

On 19/07/13 10:55, Michał Sawicz wrote: > I'm sure it was discussed before, but can you guys please give me a > summary why it's not possible to just keep the shell's scenegraph (in > our case the Qt/QML one) in play? Or if there maybe is another way for > shell's scenegraph to another process's su

Re: Proposal: Drop author fields from copyright headers

On 23/08/13 04:27, Robert Ancell wrote: > Hi all, > > I'd like to propose we drop the author fields from the copyright > headers in Mir - they're very hard to keep up to date and more > accurate information can be retrieved using 'bzr annotate'. Chances > are they either only list the initial autho

Re: Enhancements as opposed to bugs

On 15/10/13 14:01, Kevin Gunn wrote: > Something that I have not pushed very hard but is something I prefer > is to place features in relevant blueprints and keep bugs as bugs. In managing the backlog bugs vs features isn't the most useful distinction and is given far too much prominance in launch

Re: Component clarification

This came up again with my resent proposal to move Session related state to the "surfaces" component. On 25/10/13 15:22, Kevin Gunn wrote: > I'm ok with "state & implementation code" changing from "surface" to > "core". I'm sure others will weigh in. I'm not convinced that it says "semantic data

Re: Component clarification

On 19/11/13 14:18, Alan Griffiths wrote: > I think the natural domain name is "scene". > > It was the first suggestion and was only doubted because we've it > misinterpreted as implying that it /is a/ scenegraph (rather than /has > a/ scenegraph). we've *

Re: Component clarification

2 AM, Alexandros Frantzis > <mailto:alexandros.frant...@canonical.com>> wrote: > > On Mon, Nov 18, 2013 at 10:27:31AM +, Alan Griffiths wrote: > > This came up again with my resent proposal to move Session > related state > > to the "surfaces

Re: Nesting?

On 03/12/13 16:07, Daniel van Vugt wrote: > Hello? > > On 15/11/13 02:54, Daniel van Vugt wrote: >> I see there's some activity around nesting again. Does it work? Can we >> please have some docs on how to use it? :) >> >> - Daniel >> > mir_demo_server_basic -h ... --host-socket arg

Shell communication channel: simple, half-assed or fully-arsed?

I've sketched out in https://code.launchpad.net/~alan-griffiths/mir/message-passing-api/+merge/198422 Mir simply punts all concerns about protocol negotiation, versioning and structure to the shell and relies on the shell to provide all information that Mir will ever need. The advanta

Re: CI failures

On 11/12/13 16:01, Chris Gagnon wrote: > These tests pass when I ran CI on the current trunk of the > mir-development branch[1] and the tests passed, the test also passed > before enabling CI more than one time. It looks like the new code is > causing these tests to fail. > > We cannot disable t

Re: Shell communication channel: simple, half-assed or fully-arsed?

On 12/12/13 09:34, Thomas Voß wrote: > I don't see why we need a way to extend the protocol. We own every > part of the stack, top to bottom, and I don't see why the shell would > need a way to communicate to clients that is opaque to Mir. If it's an > issue of unaligned development pace, we should

Re: Shell communication channel: simple, half-assed or fully-arsed?

On 12/12/13 12:35, Thomas Voß wrote: > This could quite easily be implemented on top of: > > > https://developers.google.com/protocol-buffers/docs/reference/cpp/google.protobuf.dynamic_message Summarizing discussion from hangout... The use of a definition language and code generation isn't a s

Re: Shell communication channel: simple, half-assed or fully-arsed?

rior to migrating them into Mir. > > > On 13/12/13 19:33, Alan Griffiths wrote: >> On 12/12/13 12:35, Thomas Voß wrote: >>> This could quite easily be implemented on top of: >>> >>> >>> https://developers.google.com/protocol-buffers/docs/refer

Re: Mir in a virtual machine

Hi Rian, On 22/01/14 17:21, Rian Quinn wrote: > Daniel, > > I was able to update my system, and my sources and was able to get Mir > up and running. that's great news! > I am actually really impressed with the Mir source code. We were > considering writing a lot of this ourselves, but I think th

Re: Mir in a virtual machine

On 23/01/14 12:48, Rian Quinn wrote: > I would prefer to run the server as non-root, but if I attempt to do > that, it complains about not being able to open the DRM device. If I > run the fingerprint demo as non-root, and the server as root, the > client complains about not being able to make a co

What problem does mf::Shell::handle_surface_created() actually solve?

In my trawl through the data model I came across handle_surface_created() and wondered exactly what problem it solves. I suspect the "scene" rework will offer a better solution, but I'd like to understand what's going on before proposing anything. Firstly, note that *this function is not the subj

Re: Almost final freeze

On 02/04/14 04:03, Daniel van Vugt wrote: > We're almost at final freeze [1]. However Mir 0.1.8 requires one or > two more fixes before it gets tagged. In the mean time, please try to > avoid top-approving anything that's not a critical fix, until it's > tagged. We shouldn't ever be top-approving

Re: [Bug 1302689] Re: FocusController::set_focus_to() no longer seems to raise a session to the top

n if I've got the order right. (That is, I want to raise all of session > B's surfaces above session A's, but keep their respective session-internal > order.) I don't think there is currently, but it is a reasonable feature request. Anyone? -- Alan Griffith

Re: Packages don't cooperate

On 01/05/14 16:51, Cemil Azizoglu wrote: > The platform interface is not much different from mir server and > client ABI in terms of backward/forward compatibility. +1 -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinf

Modern C++ Programming with Test-Driven Development: Code Better, Sleep Better

Hi all, I've been reading another book: "Modern C++ Programming with Test-Driven Development: Code Better, Sleep Better"[*] which describes a lot of practices that are similar to what we are doing on Mir. But the differences are interesting too. There are some that I think would help address prob

Re: Modern C++ Programming with Test-Driven Development: Code Better, Sleep Better

On 12/05/14 16:52, Kevin DuBois wrote: > > My library had some copies, will check it out! Hopefully has some more > ideas for threaded tests... Excellent. BTW Any team members should ask kgunn about expensing a copy. -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubs

scene::Session => scene::Application

With the current review of "trust session" it is clear that "Session" is a bad name for what the scene::Session class represents. I suggest that we rename it to "Application" as that seems to better reflect its role. Clearly that has the potential to break some downstream projects - but that coul

Re: scene::Session => scene::Application

On 03/06/14 15:39, Gerry Boland wrote: > Your reasons for why Session is a bad name would help the discussion. Because it is the collection of surfaces owned by a MirConnection - and "session" doesn't convey *any* of that. > I've always thought that since Mir is a server, why not refer to clients

Re: Changelog quality

On 06/06/14 15:45, Cemil Azizoglu wrote: > There is a discussion going on on ubuntu-phone about this. Having gone > through the release process where I've had to make sure the changelog > is accurate, I think it's a good time to discuss this within the team. > > Currently, we seem to complete the c

Observers, collections and multiple threads

tion. (There's an example in MirEventDistributor::handle_event()). Thank you for listening! Alan https://code.launchpad.net/~albaguirre/mir/avoid-surf-observer-deadlocks/+merge/224733/comments/539885 https://code.launchpad.net/~andreas-pokorny/mir/synchronous-cancel-of-alarms https://code.launch

Re: CI device tests

On 18/07/14 05:46, Christopher James Halse Rogers wrote: > So, I think the cause of much of the heartache in the packaging in > https://code.launchpad.net/~mir-team/mir/libmircommon/+merge/226704 > is because the CI test is using our tools in a way that doesn't match > standard practice. > > The Br

Re: Clients reading their surface position on screen

On 14/08/14 00:31, Christopher James Halse Rogers wrote: > > > mir_debug_surface_coord_to_screen(MirSurface, int x, int y, int* outx, > int* outy) > > in libmirclient-debug and hooked it up to a --debug flag, who would > object, and what would those objections be? Returning a bool (or an enum?) t

Re: Thoughts on the limits of public headers

On 30/09/14 02:42, Daniel van Vugt wrote: > Noting that the hiding of headers in Mir 0.8, while causing some > teething problems, has been very successful in reducing ABI bumps. > Although we did bump ABIs in 0.8 it wasn't until late in the cycle > that changes were committed needing any bumps. So

private stuff "temporary" exposed

Some time ago we introduce a "temporary" facility to hook into the protobuf messaging protocol. This is exemplified by the DemoPrivateProtobuf acceptance tests. This support was intended to allow faster prototyping of some features that would eventually migrate into Mir. Once these features were s

Re: private stuff "temporary" exposed

On 03/10/14 13:28, Alexandros Frantzis wrote: >> > >> > However, things have not worked out as intended. These APIs are in use >> > for an (apparently stable) unity.protobuf.UnityService service copied >> > between platform-api, unity-mir and qtmir. > My understanding is that Unity is now using DB

Re: private stuff "temporary" exposed

On 03/10/14 14:13, Alan Griffiths wrote: > I guess my first step is to zap the platform-api code... Giving up for now. Zapping the code is easy. Understanding the surrounding code enough to be sure of not breaking things though... -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Mod

Re: Reworking our support for platform specific functions

Not only is it possible, it has been done. We're currently talking of withdrawing that feature: https://code.launchpad.net/~alan-griffiths/mir/privatize-PrivateProtobuf/+merge/237436 -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Reworking our support for platform specific functions

On 13/10/14 12:37, Alexandros Frantzis wrote: > Hi all, > > the need has arisen to add another platform-specific function, in order > to resolve bug LP: #1379266. This addition triggered some concerns about > the way we implement such functions. > > The problem > --- > > In our current impl

Re: Client API philosophy

On 10/11/14 03:31, Daniel van Vugt wrote: > > Sounds like a response to one of my merge proposals. So please put > arguments in the code reviews... There's a good reason to discuss this outside of a specific code review: we need to agree the "big picture". There is an apparent disagreement about

Re: Client API philosophy - minutes of meeting

To help resolve this discussion Thomas Voss called a meeting at 9:00UTC 11-11-2014 Those attending: Thomas Voss Christopher James Halse Rogers Alan Griffiths Alexandros Frantzis Andreas Pokorny Apologies: Daniel van Vugt 1. We started with a recap over some design goals: 1.1 The server should

Re: Artificial performance limitation

I've not looked through your evidence, but you seem to be overlooking an option: Push the response logic to the BasicConnector::io_service - that uses epoll() to farm work out to the IPC thread pool (which, despite its default size of 1, still exists). Yes, there's a bit of wiring things together

Re: Talk more

On 18/11/14 05:24, Daniel van Vugt wrote: > Hey all, > > In the interests of increasing face-to-face time with Europe, is there > an existing scheduled meeting I can be part of that's not too late > (say before 10am UTC)? Do we need a new slot? > > I'm sending this to the public list because it wou

Re: Talk more

On 18/11/14 10:04, Daniel van Vugt wrote: > I'd be happy with weekly (which I do already with the USA), but > spanning all timezones with one meeting isn't feasible... We have a daily "standup" with the USA, but whatever works for you. I'm just coming online at 9UTC - so allowing for delays, glit

Re: Talk more

On 18/11/14 17:25, Alexandros Frantzis wrote: > How about having it at 09:30 UTC on Tuesdays, which is the same day as > the US-Australia meeting? Works for me. -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-

DisplayChanger customization point

As part of the mir::Server API migration I'm looking at some acceptance tests that customize the [frontend]DisplayChanger. Now, with the phone we've not got any downstreams that use this customization so it is currently hidden. But I think it is needed for desktop and that the customization point

Re: DisplayChanger customization point

On 21/11/14 01:37, Daniel van Vugt wrote: > I'm not convinced *DisplayChanger are good abstractions. If you're > touching them then maybe we can think of a cleaner way to approach the > task of changing displays :) Yes, Alexandros made a similar point yesterday. I'm not yet clear on the right abst

Re: How to deal with client API precondition failures

On 26/11/14 12:09, Alexandros Frantzis wrote: > Hi all, > > in a recent review the subject of how to deal with precondition failures > in the client API came up again. In discussions we had yesterday the > consensus was that we should abort the process. This has the benefit of > catching the error

Re: [Canonical-ci-engineering] Online docs

On 02/12/14 23:33, Paul Larson wrote: > I think this should be fixed now. Check it in about 30 minutes. I thought it was fixed last week. -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: More automation

On 17/12/14 04:01, Daniel van Vugt wrote: > Thanks for Alberto and Francis for getting Jenkins back in full... > > If anyone knows how to do a quick test run of a demo server/shell or > two as part of CI, please get it in there... On several occasions > recently we've had merge proposals pass all t

Re: saving off display config

On 20/01/15 14:19, Kevin Gunn wrote: > hi all - > Just catching up on some bug house cleaning & found an open question > on this bug > > https://bugs.launchpad.net/mir/+bug/1401916 > > Is there an architectural preference for where to save off display > configs ? and reasons for the preference ?

Re: RFC: Move to C++14

On 17/02/15 12:37, Alexandros Frantzis wrote: > Let me know what you think. There are probably four important constituencies that need to build Mir and they may well be targeting different platforms. 1. Mir developers - they are clearly targeting vivid 2. Client-side "toolkit" developers - these

Re: RFC: Move to C++14

On 17/02/15 14:33, Oliver Ries wrote: > yeah, please keep the L(ong) in LTS in mind :) This isn't about supporting a mir branch for LTS but the ability to build the "cutting edge" development version on LTS. -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at:

Re: RFC: Move to C++14

On 22/02/15 11:26, Gauravdeep Singh wrote: > Can anyone please help me out to figure out an entry point to get > involved in the development process...!! > Any help is highly appreciable. Hi Gauravdeep, that depends an awful lot on what you're interested in doing, what time you have for it, and w

Re: Care and feeding of downstreams

On 06/03/15 09:57, Daniel van Vugt wrote: > "failing to build against lp:mir" I mean. Point taken. We should automate this check. > > > On 06/03/15 17:55, Daniel van Vugt wrote: >> Hi all, >> >> The following branches are failing to build right now. Could the owners >> of the respective changes

Is handle_surface_created() still needed?

Background: I've been looking at our legacy defaults for window management and came across the handle_surface_created() method. This is used to set the focus to a session after a surface has been supplied to the client but before that surface has had a frame posted. Hence, in a lot of cases we ar

RFC Evolving Mir support for writing shells

but keep them to support the legacy code in tests and playground? Opinions? Thanks in advance, Alan PS If you want to look at the spike it is here: https://code.launchpad.net/~alan-griffiths/mir/spike-using-camonical-window-manager/+merge/253653 NB I won't be MPing it in this form.

Re: Multiple personalities

On 20/03/15 07:40, Daniel van Vugt wrote: > Maybe as a temporary solution we should have the offending symbols > versioned as "MIR_COMMON_3.1" still from within libmirclient. At least > till the client ABI gets bumped. I don't think that would work - as (using your example) mir_demo_client_fingerp

Re: Multiple personalities

oposed in https://code.launchpad.net/~alan-griffiths/mir/fix-1415321/+merge/253077). FWIW We've had other silent ABI infelicities thanks to the the wildcards in MIR_CLIENT_8 accidentally publishing symbols in the wrong stanza. On 22/03/15 16:33, Cemil Azizoglu wrote: > Thanks Daniel for noticing this. I

Re: RFC Evolving Mir support for writing shells

On 23/03/15 02:11, Daniel van Vugt wrote: > For the benefit of all future shell developers; > I'd like to inherit from "SomethingShell" and get > something that works in a few lines without writing additional code. > Then I would like to be able to override functions to customise the > shell behavi

Re: RFC Evolving Mir support for writing shells

I've now proposed https://code.launchpad.net/~alan-griffiths/mir/default-to-canonical-window-manager/+merge/253950 Which assumes the following preferences: > 0. should we replace the legacy > DefaultShell/PlacementStrategy/SurfaceConfigurator with > CanonicalWindowM

Re: RFC Evolving Mir support for writing shells

On 24/03/15 12:50, Gerry Boland wrote: > On 23/03/15 13:12, Alan Griffiths wrote: >> 2. The shell writer can inherit from ShellWrapper override a few >> functions and "get something working". > AbstractShell/WindowManager more powerful than this, happy to le

Re: RFC Evolving Mir support for writing shells

On 24/03/15 16:03, Alan Griffiths wrote: >> >>> qtmir combines approaches 3 & 4 - it could migrate to 4 alone, but I >>> don't yet have a POC. >> I'm open to your ideas on the matter! > > It is on my list. Now available as a proof-of-concept:

Re: RFC Playground

". It's important and useful example code > that myself and others use every day to do our jobs. So if you want it > modernised, let's do it. > > > On 31/03/15 21:12, Alan Griffiths wrote: >> There's a bunch of code in the mir project that isn't needed for >

Re: Release breakage

Hi Robert, Is "release breakage" the same problem with landing Mir-0.13.x on wily that I was discussing with kgunn yesterday? AIUI the problem was an unexpected dependant of libmircommon. I believe clients should not be linking against libmircommon (only libmirclient), but we had some misplaced e

When should a nested server first post a buffer?

There's a comment in unity-system-compositor (src/window_manager.cpp) // We need to wait for the second frame before marking the session // as ready. The first frame posted from sessions is a blank frame. // TODO: Solve this issue at its root and remove this workaround that led me to

Re: When should a nested server first post a buffer?

On 29/05/15 04:26, Daniel van Vugt wrote: > Sorry for the confusion. Yes it's just a bug that needs fixing... > > If one frame has been posted then you need to take it because you can > never predict how long before a second one arrives, if at all. For clarity there are multiple bugs: /1/ We comp

Re: When should a nested server first post a buffer?

On 28/05/15 17:44, Gerry Boland wrote: > +1 on fixing this. > > Could mir clients exhibit this issue too? I have seen something similar with > Qt clients and qtmir. > -G Gerry, could you check in on this discussion

System compositors and surfaces created by nested servers

thod should be extended to also provide the surface that became > ready. > > What we actually have (c.f. the nested code and spinner) is one > fullscreen surface for each output for each system-compositor client. > https://code.launchpad.net/~alan-griffiths/mir/msh_SystemCompositorW

Re: System compositors and surfaces created by nested servers

On 15/06/15 15:38, Kevin Gunn wrote: > Hey Alan - > For #1, I would think it's easy to conceive of use cases where you > might have a system level arbiter that might want to have, for > instance, multiple user sessions in a spread potentially. > Maybe this means that the surfaces are still full sc

Re: [RFC] Performance test framework

On 19/06/15 11:22, Alexandros Frantzis wrote: > Hello all, > > there have recently been a few occasions where we wanted to experiment with > performance improvements, but lacked a way to easily measure their effect. > There have also been a few occasions where different implementations of the > (su

Re: [RFC] Performance test framework

On 19/06/15 11:52, Alan Griffiths wrote: > On 19/06/15 11:22, Alexandros Frantzis wrote: >> Hello all, >> >> there have recently been a few occasions where we wanted to experiment with >> performance improvements, but lacked a way to easily measure their effect. &g

The future of MirInputEvent

Hi All, In case anyone has missed it there's a debate about future direction started on two competing MPs: https://code.launchpad.net/~alan-griffiths/mir/event-timestamps/+merge/262879 <https://code.launchpad.net/%7Ealan-griffiths/mir/event-timestamps/+merge/262879&g

Re: [RFC] Release branches for unity-system-compositor

On 21/07/15 11:00, Alexandros Frantzis wrote: > I propose that we move to the same > scheme for unity-system-compositor too. +1 -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: [RFC] Release branches for unity-system-compositor

On 22/07/15 15:11, Cemil Azizoglu wrote: > > ​ > It's not true that if we don't have release branches, > ​release > is coupled > ​ with the development process​ > . > ​​ > > In theory. In practice we have USC feature branches that we're not landing on trunk until the 0.14 release is done. -- Mir

Re: QtMir branching strategy

On 07/08/15 16:37, Gerry Boland wrote: > Opposing argument is that the CI train system forces us to keep quality > high. I don't see any reason why changing our branching model would > cause quality of releases to degrade. One could argue that it means that > the quality of each intermediary code c

Re: Mir's building. And Mir's not building.

One further data point: The test failures are reproducible with -r2834 - which eliminates the changes we landed while CI was broken by the archive transition. On 18/08/15 10:15, Daniel van Vugt wrote: > The wily archive transition is now complete and you probably noticed > you can once again build

Re: Mir's building. And Mir's not building.

compile scripts don't work. > Solution: > https://code.launchpad.net/~vanvugt/mir/dual-cross-compile/+merge/268299 > > * New test case failures in CI - fd leaks? > alan_g is looking into it. Solutions: https://code.launchpad.net/~alan-griffiths/mir/fix-CI-test-failure/+me

Re: Mir's building. And Mir's not building.

On 18/08/15 13:09, Alan Griffiths wrote: > On 18/08/15 10:15, Daniel van Vugt wrote: >> The wily archive transition is now complete and you probably noticed >> you can once again build lp:mir on a fully updated wily system. >> >> However, the transition has left a few

Re: Mir's building. And Mir's not building.

On 18/08/15 14:35, Alan Griffiths wrote: > On 18/08/15 13:09, Alan Griffiths wrote: >> On 18/08/15 10:15, Daniel van Vugt wrote: >>> The wily archive transition is now complete and you probably noticed >>> you can once again build lp:mir on a fully updated wily system

Re: Redundant distro branches

On 24/08/15 08:45, Daniel van Vugt wrote: > We've been using this as our distro branch for a while, but actually > the distro does not use it: >https://code.launchpad.net/~mir-team/mir/ubuntu > > Why don't we just target future releases to the actual ubuntu > (proposed) branch instead? >htt

Re: Redundant distro branches

On 24/08/15 10:34, Stephen M. Webb wrote: > The problem is the dataflow. > > The ci-train assumes an "upstream" repo (here, it's lp:mir/ubuntu) > into which it merges the target branches. It builds source debs, > which then get uploaded to the -proposed pocket of the archive, which > then migrates

Re: Redundant distro branches

On 25/08/15 04:13, Alberto Aguirre wrote: > The CI train also requires a merge proposal. How does it handle projects that are hosted outside of launchpad? -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Redundant distro branches

On 25/08/15 15:17, Michał Sawicz wrote: > Not necessarily true, you can just build a source package locally and > upload it to the train PPA. It's just more manual labour this way. And > that's how it deals with projects outside of LP. That sounds like something that could easily be automated to t

symbols.map stanza names

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: MIRPLATFORM_9 { ... } MIRPLATFORM_9.1 { ... } MIRPLATFORM_9; It is far from obvious when adding a symbol whether it should be added to MIR

Re: symbols.map stanza names

On 31/08/15 04:25, Daniel van Vugt wrote: > I think there's another reason to not use the plural "symbols" in the > stanza name as has been suggested. Because we're actually talking > about the end result of how individual symbols are named: > > some_new_function@@MIR_PLATFORM_9.2 > some_new_fu

Re: [Canonical-ci-engineering] Online docs

Adding qa-t...@lists.canonical.com On 03/09/15 10:41, Daniel van Vugt wrote: > It appears that the Jenkins failure might have taken our online docs > down with it: > >http://unity.ubuntu.com/mir/ >(http://s-jenkins.ubuntu-ci:8080/job/mir-docs-upload/) > > Can anybody help please? > > The g

Re: symbols.map stanza names

After today's standup Stephen said that Chris will update the doc/dso_versioning_guide.md to incorporate the ideas from this thread. -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel

Re: Client display configuration notification

On 30/09/15 05:04, Christopher James Halse Rogers wrote: > 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. I totally agree that the existing behaviour is "surprising"; what isn't clear to

Re: Client display configuration notification

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 interested in additional information in the config (e.g. EDID for monitors). -- Mir-devel mailing list Mir-

Any fixes we want to land on Wily?

With Wily feature-frozen we should take a moment to consider whether there are any fixes we want to land into the 0.16 series before we head off into 0.17 land. I know none of this matters for phone/tablet development (as that remains on vivid+overlay) but folks are experimenting with Mir on X and

Should this be "core"?

In debugging our cursor code and getting it under tests I found something surprising (to me). Vis: std::shared_ptr mir::DefaultServerConfiguration::the_cursor_images() { return cursor_images( [this]() -> std::shared_ptr { auto xcursor_loader = std::make_shared();

Re: Should this be "core"?

On 05/10/15 12:12, Alexandros Frantzis wrote: > Otherwise, we could remove XCursor based theming, 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 implement

Re: Should this be "core"?

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 implementation doesn't currently support. To clarify, Buil

Re: Client display configuration notification

On 12/10/15 12:53, Alexandros Frantzis wrote: > So, my take is that the only config that clients need to be notified > about is the base one. Clients also need to be able to set the session > and base configs (subject to permission restrictions): I know the current scheme also has issues, but how

Re: Client display configuration notification

On 20/10/15 13:16, Gerry Boland wrote: > - Is it in Mir's scope as a display server to provide a client api for > configuring mir server settings like those for displays & input devices? Or > should Mir expose a mirserver API for these settings, and require the shell > to implement its own API v

Re: Client display configuration notification

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 to > the client api, we end up in > the situation of Unity8 being unable to speak to its parent Mir > instance. Wit

Re: Client display configuration notification

On 21/10/15 19:15, 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 w

Re: xenial-touch

On 18/12/15 03:12, Daniel van Vugt wrote: > Never mind. It appears someone has already flipped the switch recently > and made xenial-touch mandatory: I think Cemil did that already. -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/

Mir 0.20 release content

Hi, I'll be starting the 0.20 release process tomorrow AM with the aim to hit OTA10. I'm not aware of any MPs still in flight that are required for this release, if you know of any please speak up. Regards, Alan -- Mir-devel mailing list Mir-devel@lists.ubuntu.com Modify settings or unsubscrib

Re: Ideas for improving the release process

On 12/02/16 17:08, Cemil Azizoglu wrote: > Hi, > > We talked about the release process and how it could be improved. Here > are some ideas. Please add if you have others. > > (Jenkaas could be leveraged for some) > > 1. Minimizing the manual steps (like creation of the next target > branch on

Mir 0.20 Released

part of surface creation). o Track the displays plugged state to avoid reporting configurations in case they are unplugged (LP #1531503). o mouse pointer support on emulator is broken (LP: #1517597). o move an android-only test that ended up in tests/unit-tests/graphics. (LP: #154

QtMir and "devel-mir-next"

Guys, I had an interesting chat with Saviq today (on #ubuntu-unity) about his proposed approach to CI (focussed on QtMir). He's planning to introduce a branch that CI (including autolanding) can target so that MPs can land without being released. I'm not sure of the final terminology that will be

Use of LTO

Recently I encountered a problem (lp:1583536) with shipping an archive with objects compiled with -flto in our mirtest-dev package. My fix was: https://code.launchpad.net/~alan-griffiths/mir/fix-1583536/+merge/295227 and just suppressed -flto for that archive. But I've been thinking: shou

Re: scene::Surface - Shouldn't input_bounds be a bounding box of the input_region?

On 03/06/16 21:17, Daniel d'Andrada wrote: > Hi, > > I was working under the assumption that, in mir::scene::Surface, > input_bounds() was the bounding box of the input region [1]. But it > was always returning the full surface size no matter what. > > Then, checking implementation, I saw that it s

Re: Removal of offscreen display support (--offscreen)

On 07/07/16 05:45, Christopher James Halse Rogers wrote: > 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. +1 > > On Wed, Jul 6, 2016 at 11:40 PM, Kevin DuBois > wrote: >> Sounds good to me, scr

What we do and don't expose to window management

Inspired by a discussion with Chris I've been reading our code and spotted some inconsistencies: 1. In AbstractShell::modify_surface() we carefully consume the streams settings /and apply/ them before giving window management a chance to consider the modification request. Contrast this

  1   2   >