The idea behind the PureOS design guidelines is to replace the concept of standalone, independent and feature-competing applications with a concept of small, single-purpose, cross-integrated applications—that would interact between each other to provide a unified experience across the device (and beyond). Those small applications can be seen as “features” of the system. 1 purpose = 1 feature.
The SMS was sent with a python script using the native oFono DBus API. First the kernel drivers for the modem had to be enabled followed by running ofonod which autodetects the modem.
In my understanding, the communication betweend every backend to a Feature (capital F as I’m talking about the Features described by François) and the GUI would be made through D-Bus. Do we have a bit more detail on how Purism will aggregate those backends? Will each backend expose a D-Bus service which will be consumed by the GUI? How would the GUI be aware of a new backend for a given Feature?
EDIT: mentioning @mdt and @Dwaff who are likely to be interested on the matter (see this post )
I love these Symbiotic Applications guidelines. It just makes sense. It reminds me of the fantasy GUIs I used to draw (on pencil and paper) as a child, except this time it could actually become reality.
It sounds similar in some respects to some of the things KDE does, with back-ends like Akonadi running behind the scenes and applications like Kontact that connect to them. Though, I hope it doesn’t take quite as long as some of those KDE features did to reach a stable, usable state!
Being more of a GNOME person I’m not very familiar with KDE related technologies, I must confess.
Still, I believe that with Purism team actully behind a product, it will drive much more quickly the backend work to a usable state.
I am a great supporter of democracy, and community driven project. Still, when discussing efficiency, both totalitarianism and enterprise-driven projects are more “efficient” at delivering the state/company vision. Whether it suits the public needs is another matter (although I must say I’m quite confident with Purism)
yes, i am. i did not notice Francois’s design report - thank you!
i read through it and while i like the idea it doesnt go far enough for me. back than when the openmoko showed up i designed a mobile software stack (but had to abondom it as the hardware wasnt good enough at that time). my idea was a complete separation from data structure and graphical representation plus a generic view on the data (which could to some degree answer the question on how to react on new backends). i thought of a single program showing communication with friend, be it sms, jabber, email, calls, matrix or whatsoever.
i know (from discussion with the matrix people) that such an abstractionn is quite difficult if not impossible. i know as well that other people think of the very same thing (see chat program DeltaChat which is in fact an email program).
in my oppinion the idea of apps is a marketing one (you cannot sell invisible services in the background well but you can sell bundles manifested by colorful icons). open source does not have this motivation (while there are movements into that direction which i consider a wrong way).
so i think a re-thinking of everything is really needed, far away from the idea having the desktop copied to a mobile.
I believe that’s what @francois-techene has in mind. If using D-Bus, there is no hardlinking between the data and the GUI. It would be feasible to have daemons running in background (well, you know… daemons) and populating D-Bus services.
Completely independent GUI could then consume thos D-Bus services to present it to the user. Several GUI could consume the same services, and services could be consumed by no GUI at all. Is that different from what you had in mind?
that’s only one part of my design idea. and it is common sense and usual habit. normally.
additionally i wanted to have abstract interfaces (in dbus speak) to describe services. so sms, matrix or email could just have the very same interface (or way to be used). a gui could just lookup all daemons providing an messaging interface and display data accordingly (telepathy tried a similar design for IM already).
you could even have different GUIs in different flavours for personal preferences.
The idea is similar to symbiotic applications: Our phones are multi-purpose communication devices used to exchange information and getting things done. On a typical phone we have a ton of apps to manage all our communication and coordination needs nowadays. Whether we do voice calls, video calls, text messages, etc. we do the same type of things across apps, and we potentially use the same contacts across some apps. This is ridiculous (and makes us navigate our phones half of the day instead of getting things done with the phone not being in our way).
It should be possible to have:
A generic API allowing external platforms to send and receive data (e.g. send voice or video stream, send and receive files, send and receive various types of messages)
Unified communication to the device users (a single front-end that allows unified access to information exchanged, e.g. text messages, IM chats protocols, voice and video call protocols, related files, images, contacts)
A user interface allowing to filter, group and sort all the information, empowering the user over the vast amount of data.
More details are described on Launchpad (see links above), but just to give you an idea:
You’d be able to build the regular telephony and messaging app just by (default) plugins (for voice, video, text, etc.)
You’d configure or plug-in any VoIP (SIP, XMPP) provider right into your phone app
We would integrate proprietary protocols via plugins that attach to data streams (messengers like Telegram, Hangouts, Ring, Skype, Slack, Viber, WhatsApp, etc.) and they’d show up in the default app
We may (as programmers or users) have the possibility to filter providers and style the app – thus creating virtually an “app” as we know it today (if we want or need it).
No complaining about a missing “WhatsApp” or “Skype” (or whatever) app anymore! You just write a plugin that handles low-level data management, or make it easy for those companies to implement that. For the UI, plugins that modify behavior could also be available one day.
Finally a single place where I get all my stuff done that has to do with communication! *phew!*
Your idea sounds exactly like the Blackberry Hub. Years ago I had a Blackberry Z10 with Blackberry OS10. In my opinion the Hub was one of the best features of that phone. I would love that feature.
Note that in François’ solution design drawing the “Contacts database” should really be a “Contacts app” to accommodate various - dynamic - data sources (such as contacts from social networks, LinkedIn, LDAP, etc.). And the “Compliant with many protocols” in the drawing should clearly be spanning across the “Contacts app” (that then may have a UI allowing filtering based on data sources), too.
It should be noted, though, that all this is not a specific “phone thing”. Personally, I really want all the GTD/PIM functionalities fully integrated into the tray area also on my desktop. It’s the vision that Canonical already tried to accomplish. There used to be a complete graphical overview of all “core apps” (integrated in the system tray) in the Ubuntu Wiki.
It reminds me of the fantasy GUIs I used to draw (on pencil and paper) as a child, except this time it could actually become reality.
yes, i am. i did not notice Francois’s design report - thank you!