- devel - lists.apertis.org

Application Layout design proposal
by Simon McVittie 24 Nov '15

24 Nov '15

Here is a design proposal for altering the installed layout of application bundles to be suitable for upgrade/rollback, data-reset, containerization, and the theme installation use-cases raised by Ramya and Suma on <https://bugs.apertis.org/show_bug.cgi?id=575>: <https://wiki.apertis.org/Application_Layout> Please let me know if there are any requirements that are not covered, or areas that are unclear or unsuitable. There are some unresolved questions about the requirements, for which I would particularly appreciate feedback: <https://wiki.apertis.org/Application_Layout#Unresolved_design_questions> The part discussing icon themes should eventually be split out into a separate design document that specifically covers what has been said on <https://bugs.apertis.org/show_bug.cgi?id=575>, but for the moment it's just a subsection of Application_Layout. Thanks, S -- Simon McVittie Collabora Ltd. <http://www.collabora.com/>

2 4

SDK image available for AMD64 architecture
by Hector Oron 23 Nov '15

23 Nov '15

Hello, AMD64 SDK image has been recently added to the Apertis image set. Find them available in the daily builds directory: https://images.apertis.org/daily/15.12/latest/ Name: apertis-15.12-amd64-sdk-amd64-uefi Regards, -- Hector Oron Collabora Ltd Kett House, Station Road, Cambridge CB1 2JH, United Kingdom Telephone: +44 (0)1223 362967 Fax: +44 (0) 1223 351966 ------------------------------------ Visit Collabora on the Web at https://www.collabora.com/ Follow Collabora on Twitter https://twitter.com/collaboraltd ------------------------------------

1 0

New mailing list for testing-related discussion and results
by Ekaterina Gerasimova 18 Nov '15

18 Nov '15

Hi all, There is a new mailing list for testing (manual and automated) now at https://lists.apertis.org/listinfo/testing You should subscribe to it if you want to receive the automated LAVA test results and want to follow the weekly testing discussions. Thanks Kat

1 0

Re: [Devel] Updated geolocation and navigation design document - navi
by Barkowski Andre (CM-CI1/PRM1) 18 Nov '15

18 Nov '15

Hi Philip, let me focus on "navigation apps" in this answer (I will follow up on the other topics mentioned below in a separate email). " I was operating on the assumption that navigation apps would use the SDK (with the caveat that OEM-provided navigation apps may additionally use out-of-band data from OEM-specific APIs in the automotive domain). Is that not the case?" Let me try to explain, hope its possible to get the essential part from it. I said, let's look from an LBS-App point of view, which is not a navigation application (e.g. Hotel, Restaurants, Weather, etc). These Apps mainly use SDK-APIs from a _data consumer_ point of view, e.g. geoposition, route-info, map, reverse geocoding api, geofancing, etc similar like it also uses TTS-API etc. In contrast, the Navi App is special, because it fulfills the role as a "data producer", e g. providing map data for libchamplain, the route data for route-info API, or a geoposition with higher accuracy for geoclue, or even as a backend for "type-ahaed search and address completion" or "reverse geocoding". The build in functionality (the route calculation, the map rendering, the destination input, the street data, etc) is all "black box" internal stuff carried by the App itself. So if we for example ship our own BOSCH Navi as an App, or a TomTom one, or a NavIt one or whatever 3rd party Navi solution, it will bring its own binaries an data formats. We don’t care about it, its in the responsibility of the App-Developer. In addition, the Navi App requires a set of APIs to get functional at all, - mostly a subset of the ones needed by LBS Apps mentioned above (e.g. geoposition, TTS-API, may be some data from sensors and actuators design like vehicle speed, etc). If this APIs are not available, the Navi-App itself will not work well. Once this has been archived, there is an additional set of APIs, where a Navi App can decide (via manifest) if it interacts with. These are APIs, where the Navi-App itself fulfils the role as "data producer" - e.g. replacing other backends in use so far (or being the first producer at all). The data produced gets then shared via SDK-APIs to other Apps (samples mentioned above). That’s the usecases which we would like to cover. It is a non-usecase, that someones starts to create a navi solution from scratch fully based on the functionality exposed via SDP-API only (i.e. map rendering is based on libchamplain only, positioning is based on geoclue only, destination input is based on " type-ahaed search and address completion", route calculation is based on "route-info") etc. Do you see the difference ? Scope is - development of LBS-APPs - packaging and deployment of Navi App - Navi-App as data producer And independent of that - exchangeable Backends Rgds Andre -----Ursprüngliche Nachricht----- Von: Philip Withnall [mailto:philip.withnall@collabora.co.uk] Gesendet: Dienstag, 17. November 2015 11:46 An: Barkowski Andre (CM-CI1/PRM1) <Andre.Barkowski(a)de.bosch.com>; devel(a)lists.apertis.org Betreff: Re: AW: [Devel] Updated geolocation and navigation design document Hi Andre, On Mon, 2015-11-16 at 17:20 +0000, Barkowski Andre (CM-CI1/PRM1) wrote: > thx for the updated document. > After having read the document and before I start providing deeper > feedback, I was wondering about the UseCases covered in that > document. We have used the pattern (from Usecases to Requirements, > reflection of existing solutions and coming to a proposed approach) > already multiple times, but this time I was really wondering, when do > we pick up a use-case to be mentioned ? That’s a good question. Picking up use cases seems to be the hardest part of producing these design documents. Personally, the way I have been doing it is to make up what I think are reasonable use cases for such a system (based on my experience of using similar systems), and to add in use cases I have received from other parties. When the document undergoes review (either internally or externally), I add more use cases extracted from the feedback, and iterate until everyone seems to be happy. I am working on the assumption that if anybody spots a use case which is missing – or one which they think we should //not// design for – they will comment on that in their reviews. > One of my primary intentions is to define the SDK-API. So from that > point of view I reflect, what kind of use-case exists for a "non- > navigation app" to deal with location based information (e.g. > Weather, Hotels, etc). That’s an App-Developer point of view. I was operating on the assumption that navigation apps would use the SDK (with the caveat that OEM-provided navigation apps may additionally use out-of-band data from OEM-specific APIs in the automotive domain). Is that not the case? Certainly, using my phone as an example, I have a variety of navigation apps available to download, all of which use the Android geo-APIs. > Another set of use-cases comes from flexibility in system setups, > that’s influencing things behind the scene and is more a System > Integrator point of view. Agreed. > In contrast, I do _not_ take into account what an developer of a > navigation App would like to do. That’s all internal stuff, without > dependency to the SDK. > I do have the feeling, there are uses cases included only relevant > for Navigation internal implementation. Lets call them Navi-features. > But I am not sure. Things like "Deviating off a navigation route", > "Resuming a navigation route" or "cancelling a navigation route", > aren't they full App-Internal ? Its seems to me like we would discuss > that a phone call needs to have the capability to be canceled. That > for sure right, but I miss why its important for our context. These particular use cases were specifically aimed at navigation apps, yes. In this case I may have been too verbose, as those use cases did not translate into requirements for the routing API — they could be implemented entirely internally in a navigation app, as you say. Philip > Or the description is misleading, e.g. an App would like to subscribe > for a new route (for example caused by deviating off a navigation > route, but also caused by other reasons like a new (intermediate) > destination has been set). In that case the description / and the use > case would more focus on consuming the new-route information and to > generate some great service from it instead of "that the calculated > route must be radically different", and "recalculation should happen > within a short time period". > > Hope you get what I mean. > > Rgds > Andre > > > -----Ursprüngliche Nachricht----- > Von: Devel [mailto:devel-bounces@lists.apertis.org] Im Auftrag von > Philip Withnall > Gesendet: Donnerstag, 12. November 2015 17:40 > An: devel(a)lists.apertis.org > Betreff: [Devel] Updated geolocation and navigation design document > > Hi all, > > Please find attached version 0.2.1 of the geolocation and navigation > design document. This version incorporates feedback about swappable > backends and the ability to back any of the APIs by an implementation > in the automotive domain. > > I have uploaded this version to the wiki as a draft. Further feedback > is welcome and will be incorporated as normal. > > https://wiki.apertis.org/File:Apertis-geolocation-navigation-design-0 > .2 > .1.pdf > > Thanks, > Philip

1 0

Preview of new documentation tool output
by Philip Withnall 18 Nov '15

18 Nov '15

Hi Andre, I believe you were asking recently about the format of the output from the new documentation tool (hotdoc), which we’re building to replace gtk-doc. Mathieu has produced some example output of the documentation for libgrassmoor, and I’ve attached it if you would like to take a look. Currently, the output resembles gtk-doc’s quite faithfully — except for that it’s generated for C, Python and JavaScript bindings of the API. gtk-doc only supports C output. For the purposes of this demo, we have not significantly changed the wording of the documentation in libgrassmoor; but we have spent some effort adding GObject Introspection annotations to it so that its APIs can be used from Python and JavaScript. These are what hotdoc uses to generate the binding documentation. The other new feature you can see in the generated documentation is the ‘Edit’ link by each symbol. This is an early part of the implementation of an online editing system for allowing readers of the documentation to easily contribute fixes and improvements to the documentation. We believe this is a good way to encourage community contributions to the documentation by lowering the barrier to contribution. This feature is still in development, but should be available in beta form for 15.12. A third feature which hotdoc already has over gtk-doc is its support for incremental building, where it will only rebuild the output pages affected by the specific input files which have been changed, rather than rebuilding all output pages every time. This gives speed improvements over gtk-doc, which can take 5 minutes to build the documentation for a medium-to-large project. Mathieu is currently working on implementing an interface for tagging symbols by their stability, private/public, supported/unsupported, and whether they are specific to an OEM (for example). We aim to have that ready for 15.12 as well. However, it does not make an appearance in the attached example. In terms of our roadmap for after Christmas, we were thinking about the following additional features, which would be useful for Apertis and also highly desired by GNOME. If we can implement features useful to GNOME, that should increase the adoption of hotdoc there as a replacement for gtk-doc, and therefore increase its contributor base. Mathieu has spoken to various key people in the GNOME community about it (including the author of gtk-doc), and his ideas for hotdoc are well received. • Support for stand-alone Ducktype pages (rather than just Markdown pages), which would be useful for integration with prosaic developer guides (such as the GNOME developer guide, or the Apertis developer guide), to bridge the gap between API reference manuals and developer guides • Ensure linking to Mallard manuals/pages from API documentation work (another facet of the above; this allows API documentation to link to the user manuals for developer tools which are written in Mallard [which is a markup language for documentation; a more modern version of Docbook]) • Improving the Devhelp UI to improve searching, because its current search interface doesn’t return results in relevance order or support full-text search • Improving the Devhelp UI to integrate with the hotdoc online editing system to allow typos fixes to be submitted from within Devhelp • Promoting hotdoc within GNOME by applying it to some upstream modules as a test bed and to increase adoption The first two features would be useful for integrating API documentation and developer manuals and guides, such as an SDK development guide or the Apertis developer guidelines. The third feature would be good for use in the SDK to actually access the new documentation. Devhelp can do this already, but sub-optimally. Alternatively, it can be accessed via the web browser — Devhelp simply has some nice features like a side search bar and keyboard shortcuts. I’d appreciate your thoughts on these features, and how you would prioritise them in the roadmap. Philip

2 4

Apertis 15.12: release status
by Hector Oron 10 Nov '15

10 Nov '15

Hello, Apertis 15.12 is being currently prepared to be released by December 11th, 2015. The following activities are being carried out: * Rebase Apertis distribution has been synced against Ubuntu 15.10, codenamed "Wily Werewolf", a total of 507 packages conform target component, from which 80 packages have been merged, 165 have been synced from upstream. Development component has a total of 1161 packages, from which 66 packages have been merged and 428 have been synced with upstream. SDK component with a total of 527, 17 packages have been merged and 158 packages have been synced with upstream. There are still few activities on-going, as integrating latest Bluez5 stack and all its dependencies, however Apertis is fully functional and usable. * Full Rebuild Friday, November 13th, a full rebuild will be triggered just to test verify the complete set of Apertis packages are buildable. * Software freeze Apertis package set will be frozen on Wednesday, November 25th, 2015. After software freeze, only bug fixes will be accepted. * SDK release SDK beta image will be released Monday, November 30th, 2015. * Final release Target date is December 11th 2015. * Release Notes A template document for developers to document latest features will be placed at: https://wiki.apertis.org/15.12/ReleaseNotes Regards, -- Hector Oron Collabora Ltd Kett House, Station Road, Cambridge CB1 2JH, United Kingdom Telephone: +44 (0)1223 362967 Fax: +44 (0) 1223 351966 ------------------------------------ Visit Collabora on the Web at https://www.collabora.com/ Follow Collabora on Twitter https://twitter.com/collaboraltd ------------------------------------

1 0

libclapton API changes
by Guillaume Desmottes 06 Nov '15

06 Nov '15

Hey there, I recently did some API clean up to libclapton (T508). I ported all the modules on git.apertis.org already (T586) but if you have extra code using libclapton you'll have to port it as well. The change is pretty straightforward, see for example https://phabricator.apertis.org/D881 G.

1 0