Re: [Ubuntu-phone] LP: #1260712 post-mortem and improving our processes
On Saturday, 2013-12-14, 08:24:03, Thomas Voß wrote: On Sat, Dec 14, 2013 at 12:05 AM, Dimitri John Ledkov x...@ubuntu.com wrote: On 13 December 2013 22:25, Barry Warsaw ba...@ubuntu.com wrote: So, what steps can be taken to avoid such problems in the future, and what lessons were learned that might be of use across the project? dbus apis are hard, hence a few dbus apis are provided as shared-libraries (essentially generate client code and compile it into shared library). When looking at dbus api, as if it's a compiled generated shared library the ABI/API break is obvious and one typically renames the library package as per Debian policy. Seconded. Treating DBus as an implementation detail and not leaking it to customers of your service helps a lot in versioning access to your API/service. In addition, our tooling and packaging supports versioning on a library/symbol level quite nicely. While it is of course nice to delegate version handling to the linker, it also makes writing those interface libraries the difficult task. A client library like that needs to either hide the asynchronous nature of its D-Bus communication by providing a blocking interface or provide an asynchronous interface itself. The former means that developers either have the choice of risking blocking their main thread or use a secondardy thread. Also makes it necessary to wait for the full roundtrip. See Xlib. The second option splits into either using threads internally in the library, or providing hooks that the library user can call to drive the asynchronous IO. Both make it non-trivial to use the library. In the case of interal threads the developer needs to deal with getting callbacks in a different thread context. In the case of hooks they need to find a way to either call them regularily or attach them to their event loop system. libdbus is an example for the latter. A library that can be shared across different technology stacks but is also considered to complicated to be used by application developers directly. In contrast, a D-Bus API is fully technology stack agnostic, mainly because it is a well defined protocol over socket. Any client developer can use the most appropriate [1] integration technique for their chosen technology stack, e.g. event loop integrated (GDBus on GLib, QtDBus on Qt), threading (Java D-Bus bindings IIRC). I am not involved in the development efforts here but having done lots of D- Bus, application and bindings level, clients and services, my recommendation would be to discard the advantage of freedom of technology choice. It might not be necessary right now, but given Ubuntu's recent change in main technology from GLib to Qt you can most likely appreciate not having to build wrappers upon wrappers but using native integration capabilities instead. Cheers, Kevin [1] and usually most efficient, since data doesn't have to be transformed and copied that often. E.g. Mono and Java implement the wire protocol themselves to avoid coping into C types first and then again into their respective native types. -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] A video from the app purchase kickoff sprint
On Friday, 2013-12-06, 17:27:31, Martin Albisetti wrote: On Fri, Dec 6, 2013 at 4:10 PM, Зонов Роман roman2...@yandex.ru wrote: Firstly, I think, that we must stop use WebView when we buy an application. We must have fully native interface. I'm talking about desktop too. Very dynamic pieces of the system like payments and authentication are going to move over to be webviews, because there is going to be a lot of changes in currencies, payment methods, authentication layers (2 factor authentication, captchas, etc), and experience has shown us that shipping that UI in the client as native is always inadequate in the short term. Well, that would only be the case if the native UI was fixed at build time or needed to be installed. Assuming native UI here still means QML then there is no such restriction. The choice to go with an HTML based interface instead was most likely made to also allow purchase through normal web browsers. A valid reason, but has nothing to do with dynamic UI :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] QProcess, and a QML/JavaScript only alternative?
On Tuesday, 2013-11-26, 07:11:17, Israel wrote: On 11/26/2013 02:50 AM, Michael Zanetti wrote: On Monday 25 November 2013 18:58:45 Israel wrote: Is there work going on to integrate something like QProcess into QML/JavaScript. I'd really like to run some external programs (festival for one, and to make a few nice configuration programs for the in-process LXQt version of Lubuntu) as I'd rather the program be smaller, as both phone and Lubuntu generally want smaller programs, rather than full-on C++ code (if avoidable) I don't think that's true. Not sure what you mean with that? Are you saying you don't think QML/JavaScript is lighter? If so I understand, C++ probably compiles to be lighter, but my thinking is that JavaScript runs in a browser, so if I can make my code one line, instead of including main.cpp, qprocess.cpp qprocess.h it will be lighter (smaller?). I suppose this is not accurate, just seems like it would be slightly smaller. In neither case you would include qprocess.cpp in your program, it's code is already part of libQtCore. In both cases you have an application that links with Qt, perhaps loading parts of it as plugins. Naturally using QML, in this case for UI, will have additional overhead, at least memory wise. If the UI component technology used with QML is QtQuick2 then this is the only option [1] so also no difference. A package containing just QML and script code might be smaller in download/on- disk size though, assuming the runtime and all plugins are already present. Cheers, Kevin [1] QtQuick2 cannot be used without QML. Other UI component technologies, e.g. QtWidgets or BB10/Cascades, can be used with C++ or QML. -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Ebook reader?
On Monday, 2013-05-20, Stuart Langridge wrote: On Sat 18 May 2013 18:41:34 BST, Kevin Krammer wrote: On Friday, 2013-05-17, Stuart Langridge wrote: It is somewhere in between impossible and very nearly impossible to write a book reader in pure QML for Ubuntu Touch right now, sadly. Well, QtQuick (assuming you wanted to refer to that UI framework when you wrote QML) is a UI framework, not a data processing or application framework. Those pieces are supplied by C++ code just like QtQuick itself being implemented in C++. Speaking purely for myself here, I don't agree with this. I know that a lot of experienced long-time Qt programmers think that apps should be written in C++ with Qt Quick solely as a presentation layer, but I personally believe that the more it can be possible to write apps using QML and JavaScript alone, with no compilation step or C++ requires, the more it becomes possible to engage developers in building for the platform. I see your point but I was specifically addressing QtQuick which is solely a presentation layer, not QML generically. However, QtQuick as one of the available type sets for QML shows that certain things are best implemented in C++, exposed to the QML scene as ready-to-use building blocks. The more type sets you have available as part of the platform, the less often application developers will have to create their own. In this case my impression was that there are currently not components for rendering certain type of documents, neither into a QtQuick element nor into a buffer. One important thing to keep in mind is that the JavaScript parts of QML is not the same thing as JavaScript for Qt scripting, i.e. focused on the needs of QML. While it is currently using V8, a very capable and extensive engine, there are considerations to create a custom egine, codenamed V4, that is reduced to work for the QML use case but does not incur the problems V8 and other full engines have, e.g. not allowed on restricted platforms like iOS. I certainly acknowledge that that's not entirely possible right now, that there will always be a space for C++ plugins, and that the platform should probably not grow to encompass all things! However, I'd like to see Qt Quick, and the Ubuntu SDK, extend more capability than it currently does to JavaScript programmers. The web is working out the same way: using HTML and JavaScript as a presentation layer only certainly works, but more and more capability is extended to programmers in those environments without having to fall back on a more capable environment server-side. True, but in the case of HTML/JavaScript the browsers provide a closed system that is not really expandable by anyone than the browser vendor so they need to provide the option of adding functionality otherwise. Henvce their strive to provide better and better JS engines, even if that means not being able to provide the browser for certain locked down platforms. Qt, as a framework that others build upon cannot as easily afford to pass on those platforms but since it provides other means of extending the provided features set it can compromise in scripting capability and there have been hints that they are at least investigating into that direction. like that with Qt Quick; what's preventing that is not a large technical chasm between the two, but a few trivial items such as QML's XMLHttpRequest not supporting some of the XMLHttpRequest v2 API that deals with binary data. As Kevin says here, one way to do this is to put most of the logic of an ebook app in C++ and compile for each platform, and that's indeed what I suggested in my original mail... but I'd love to see the final few tweaks happen to allow an app such as an ebook reader to be writeable without compiling anything, in the same way that a good proportion of the already existing Ubuntu Touch apps are also pure Qt Quick. Sure, the very core concept of QML is to be agnostic of where the types developer can use come from. Whether the types are registered by the application startup code, by the application package or the platform doesn't matter. So if registered by the application startup code is undesired, i.e. the application should be started by a generic runner, then this still leaves the last two options. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] shared library packages and dependencies on mobile
On Tuesday, 2013-05-14, Ted Gould wrote: We expect that applications that need sophisticated dependency schemes will include those dependencies in their own packages. There will be a base image that everyone can depend on, but beyond that, you'll need to BYOD (bring your own dependency). Will there be any support for vendors with more than one application? E.g. vendors that have application suites and want to be able to share the components between the suites applications? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Some info regarding Akonadi
Hi folks! A friend pointed me to your recent discussion on Akonadi and I thought you would like to have some contact who you could ask any questions you might have. Since I have just subscribed I cannot direclty reply to the original mail. Client libraries: Currenly the only actively used client library for Akonadi is the one developed by the KDE PIM project developers. One of those developers, Stephen Kelly, has created a Pyton based implementation to demonstrate the technologies viability across software stacks: git://gitorious.org/python-twisted-akonadi/python-twisted-akonadi.git http://steveire.wordpress.com/2009/10/13/cross-platform-akonadi-video/ Basically the only requirement is to be able to handle a Unix domain socket. I have a proof of concept implementation in Vala lying around on my harddisk somewhere and recently for fun experimented doing it with NodeJS. The KDE based stack consists of several libraries, some of which contain low level code, some containing widgets or model/view classes, some for generic data, some for specialized data (such as contacts, calendar, email). Some protocol bits are shared with the server side implementation and have no dependency on any other library developed by KDE. KDE contact aggregation: similar to Folks the metacontact libs are primarily driven by people from the instant messaging community. The respective project is called KPeople.: http://www.mail-archive.com/kde-telepathy@kde.org/msg06970.html If you have any further questions just let me know. If I don't know the answers myself I will find people who do :) Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
