Aseigo

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Wednesday, 31 October 2012

one code base, multiple form factors

Posted on 01:46 by Unknown
Yesterday we pushed a small but significant clean-up to a feature set we've been working on for a couple of years now which is perhaps one of the more interesting things we're doing in Plasma: the idea of "one code base, multiple form factors."

The idea is that whether your application is running as a widget on the desktop, docked in a panel, running full screen as part of a mediacenter, running in a touch based environment or as a regular ol' app-in-a-window, much of the code can be shared. We often put the non-graphical bits into shared libraries, and traditional we've built multiple front ends that are optimized for different form factors and input methods which use these libraries.

What would be even nicer would be, at least where possible, to raise the level of code sharing a bit and make it possible to also have the user interface adapt. Instead of having multiple user interfaces, you'd write one and it would be adapted depending on where it is running at the time.

One piece of the puzzle has been to communicate to the application this form factor information. In Plasma we let a component know when it is in horizontally or vertically constrainted presentation (usually a panel), when it has full run of a 2D surface, when it is full screen, etc. That's just the start, however.

For apps written with Qt Quick using a mix of QML, Javascript and perhaps some C++ bits behind the scenes, we ship the interface in a Package. Inside that package is a contents directory where all the individual QML, Javascript, image and other data files reside. There's also an optional "platformcontents" directory, and beneath that you can put platform customizations.

For example, if the interface should be laid out differently depending on whether it is on a tablet or a desktop, you can have a platformcontents/tablet/ directory. If you want to provide customizations for touch, platformcontents/touch/. Any files that are requested (be it QML, JS, images or whatever) that exist in those directories will be used instead of the version in contents/ when on that platform. In fact, on a tablet, anything in platformcontents/tablet will supersede platformcontents/touch.

Furthermore, the form factor also controls the QML components that are used to build the interface. For example, on touch we use thin scrollbars that fade out when not in use, as is typical on mobile devices, while on the desktop we use a much more traditional (and easier to use with a mouse) always-visible scrollbar.

How does this look in QML? Very boringly, it's transparent:


     import "plasmapackage:/code/Foo.js" as Foo

Will grab the correct Foo.js depending on the current form factor. Same for SVGs or other images requested or other QML files that are loaded.

This is controlled either by putting an the kdeglobals configuration file like this:


     [General]
     runtimePlatform=tablet,touch

Or by setting the PLASMA_PLATFORM environment variable:


    PLASMA_PLATFORM=desktop myApp
    export PLASMA_PLATFORM=tablet:touch

There is no limit as to how many form factors can be defined in the list, and it goes from most specific to least specific, finished up by the input style. The last entry controls which set of default components are used, and the other entries are used to define where in Packages to search for form factor specifics.


This actually works in Plasma Workspaces 4.9, but was a little harder to configure and get the expected results. Now there is just the one setting in either the configuration file or environment variable and any application can get at this information if needed via libkdeclarative. 

From here, we want to make it easier to switch to full window presentation (aka "traditional desktop app style"), continue to improve the individual QML components for different targets and hopefully also find a way to hook directly into QML's import statements to make this feature absolutely ubiquitous. We're already miles ahead of most of the competition here, though, and we know it works because, even if you didn't notice it, you've been using a system with these features for a while now. And if the user doesn't notice it, then we've succeeded, as that's the entire point. :)

More documentation here.
Read More
Posted in | No comments

Sunday, 28 October 2012

onwards to Four

Posted on 03:35 by Unknown
Not being the sort who rest much, we're already at work on Plasma Active Four. We met up on irc to firm up our plans. You can read the minutes here, thanks to Thomas who took the time to summarize the multi-hour session.

We are moving to a devel workflow in which we aim to have an "always-releasable" master branch. All development will happen in branches, something we essentially do already, but we will now also have an integration branch so we can bring the various branches together for testing before merging them when ready, branch by branch, into master. We have been working towards for some time, adjusting our habits one step at a time. This will only cover the plasma-mobile, share-like-connect and plasma-active-maliit repositories for now, but my hope is that as Frameworks 5 arrives we'll be able to broaden this to the bigger shared repositories such as kde-workspace.

We also set a release date target of March 26th, with betas and release candidates starting one month prior to that. So what do we plan on accomplishing between now and then?

Most of the core team's efforts are going to be focused on improving what was new in Plasma Active Three. We'll be focusing on one component at a time for review so we can document what needs improving, prioritize those items and then work on implementing the improvements in a time-boxed devel cycle, or sprint.  We are starting with Files for the first three week sprint, and then will move on to Share Like Connect. Not all sprints will be the same length. Some will be only one or two weeks, all depending on how much needs doing and how much time we have.

One of the Maliit input system developers joined us at the meeting as well, which was great as we have a lot of work to do on the on-screen keyboard still. We are very much looking forward to the improvements that Maliit 1.0 will bring, but that won't be Plasma Active Four material. We will be working on bringing multiple layouts and improving some of the current ergonomics. Already a few annoyances and bugs have been fixed, and we recently merged in some changes to the default layout.

There are also some new feature sets in the pipeline for Plasma Active Four. Work on syncing is already well on its way with ownCloud and akonadi integration (Sebas will probably blog more about this later) and screen rotation support (thanks to JP). More and more, though, we'll be looking to others to work on new applications and feature sets such as these.

... and now for something completely different: screenshot porn of a few things already in master for the Plasma Active Four release.





Read More
Posted in | No comments

Friday, 26 October 2012

KDE Manifesto in action: bodega server

Posted on 08:24 by Unknown
I wrote the other day about why the KDE Manifesto is important for the KDE community. Today I'd like to show how it can be used in practice with a real-world case study: the bodega server. Coherent Theory has been working on this content distribution system for a while and it does things rather differently in a variety of ways including:

  • Free software licensed :)
  • multiple owner-defined store fronts to the same (or different) bodies of hosted content thanks to a tag-based metadata system
  • able to federate external content (a feature set I expect will evolve significantly over time)
  • good for books, music, services, artwork, etc. as well as for applications; essentially any content or artifact that can be delivered over the network works just fine (which is why we don't call it an "app store")
  • built-in purchasing system using a points mechanism which can be tied to monetary purchases (swipe integration is included), gift cards or pretty much any other system you can think of (e.g. in a school environment students could earn points through their performance in class)
The implications of such a system being Free software are potentially significant. Both server and client code currently reside in KDE's review repository so that, if all goes well, we can move it into Extragear in two weeks time.

The client side currently consists of a C++ library (dependencies: QtCore, QtNetwork and QJSON), plugins to handle installation of downloaded assets (some of which use KDE technologies like Nepomuk) and a UI written in QML that uses Plasma Components and a variety of KDE libraries. It's easy to understand why the bodega-client repository can be called a KDE Project: it uses lots of KDE libraries,  integrates rather beautifully with the Plasma workspaces and the development community is well integrated with the larger KDE community.

But what about the server? It has no user interface; it doesn't use any KDE libraries, or even Qt for that matter. Instead it is built with node.js, PostgreSQL and Redis, none of which are particularly "KDE". Does this server-side code, in its own self-contained repository, make a good candidate to be a KDE Project?

We can start by looking at its relevance to KDE's goals. The bodega server was designed with devices running a KDE workspace, such as Plasma Active, in mind. Indeed, this is what powers the Add Ons application in Plasma Active 3. Since it is general purpose software, it can be used for all sorts of things, but integration with KDE software has been the development team's primary motivation. So the focus seems relevant to KDE, but is that enough to consider it for inclusion as a KDE Project?

The KDE Manifesto helps us here as we can use it to check if the foundational principles of KDE are found in this project. These principles are: Open Governance, Free Software, Inclusivity, Innovation, Common Ownership and End-user Focus. Without going into point-by-point details, bodega-server ticks all those boxes.

What about the commitments? There is no Contributor License Agreement to sign; the repository is open so all KDE contributor accounts are able to participate; the project already uses KDE infrastructure; trademarks and copyrights are in order; established KDE community principles are being followed (such as going through kdereview), etc.

With the Manifesto in hand, we can see that it is a reasonable candidate for becoming a KDE Project because it matches the focus, principles and the goals of KDE. Prior to the Manifesto, it was a lot harder to identify if something like Bodega ought to belong under the KDE umbrella. Other server-side projects struggled with this exact issue in the past, at times with rather unfortunate consequences.

Now it is quite straight-forward; we simply have to ask, "Does it push forward KDE's technical agenda, and does it meet KDE's documented principles and commitments?"
Read More
Posted in | No comments

Wednesday, 24 October 2012

KDE Manifesto

Posted on 03:23 by Unknown
Kevin Ottens recently blogged about the shiny new KDE Manifesto. He does a great job of explaining the motivations behind such a document. As he noted, I gave a keynote at Akademy six years ago on this very topic. Evidently it's something that has been on my mind for a while, and the reason has to do with sustainability of the KDE community.

By the time I wrote that keynote, KDE already had very clear social principles, agreements and mechanisms. They are reflected in the new Manifesto, so there is in one sense nothing really new there. What is new is that those principles are being stated openly and clearly. Not everyone felt they needed to be, and so I'd like to address the reasons why this is such an important step for KDE.

KDE as a community, a technology creator and the keeper of many assets with value (ranging from KDE e.V.'s bank account, IT infrastructure, trademarks, reputation, etc.) is something that many people and organizations want to be a part of. This is a sign of success that was built up over the 15+ years of history of KDE. As new projects and new people come together under the big tent of KDE, we are faced with three key tasks:


  1. Enabling external self-identification: Making it possible for those who are not yet affiliated with KDE to know whether they ought to be and what that would mean. This helps KDE remain relevant and full of energy. We've seen this happen with projects like Simon, Kdenlive and Necessitas.
  2. Enabling internal identification: As KDE has grown, it has become populated with more and more projects and products that do not fall cleanly into the original technical scope of "targets the desktop paradigm and uses Qt and KDE libraries fully." We even have multiple applications focusing on the same category or area of interest. Which of these applications is a part of the KDE system?
  3. Passing these capabilities on to those who come after us.
The Manifesto is an important tool in accomplishing the above. It helps avoid dissension due to a lack of agreed upon definitions. Interestingly, we collectively already knew what makes something KDE or not, what benefits come with that and what the commitments are ... we just hadn't put it down in writing yet. That act takes our collective wisdom and makes it available to all individuals at all times.

Prior to the Manifesto, when "grey area" issues arose, (well-intentioned) people would too often disagree over things they agreed on just days, even hours, before. Prior clear understanding of what it was to be a part of KDE would dissolve when we looked at it too hard or with too much on the line. That's just how people tend to work in group situations when it becomes necessary to turn implicit knowledge into explicit agreement, especially as stress is added. (Unresolved questions involving a common good is a source of stress in a group.)

Prior to the Manifesto, when KDE members would leave for one reason or another (the most common reason probably being lack of time due to changes in personal life), they would take their social knowledge with them. New generations of KDE members often were left to figure the pre-existing structures on their own, such as what a maintainer is in KDE. Now, we have a way to easily point new members to what our commitments are and what benefits come with them. This will help create continuity in the long term.

I'd like to stress that these are not theoretical problems. Well, they were six years ago when I gave that keynote: things were sailing along pretty smoothly then. However, upon examination, it was clear the the particular growth path KDE was on meant that this would not last without us taking action. The Manifesto was not the only thing needed, and we worked on other parts of the solution over the years, but the Manifesto is a keystone artifact. And yes, it took six years of effort. Turning an entity as big as KDE is like turning a large boat at sea: you can't do it quickly. This is important to keep in mind for future efforts ... though that is a topic for another blog entry entirely perhaps.

It is quite important for us to remember that the KDE Manifesto  is a living document, just as KDE itself is a living and evolving community. The Manifesto will see revision over time as we come to understand it better ourselves and improve our ability to communicate it clearly. It will be an iterative process which will see the Manifesto evolve with time. So having come this far down the road on a journey we should all be very proud of, we aren't finished.

And we never will be: maintaining a community's health is a journey, not a destination.

I'd like to thank Kevin Ottens and those who helped in the process of drafting and vetting the KDE Manifesto. It was a huge effort, both in terms of energy put into it and importance, and that deserves our appreciation.
Read More
Posted in | No comments

Monday, 15 October 2012

Plasma Active Three

Posted on 09:04 by Unknown



After several months of concerted team work, we have put the final wrapping on the next major release of Plasma Active. The last two weeks were spent testing on both ARM- and Intel-based devices to identify and fix show-stopper defects. It was time well spent, resulting in a polished release that shines as a successor to Plasma Active Two.

In keeping with our straight-forward naming scheme, this release is simply known as “Three”.

... or download the video in ogg format.

You can go read the official release announcement and news over on The Dot, but what follows is my tl;dr version of what we've been up to in making Plasma Active Three a reality.

A (Probably Not So) Quick Recap


Before I start writing about what's new in Three, let's recap what Plasma Active is in the first place. Plasma Active is a user experience for mobile and media devices built around the core design concepts of "simple beauty," or elegance, and something we call Activities.

You may have seen the word “Activities” in other user interfaces recently, but the word tends to get used as a rather hollow place-holder to mean “something that lets you do something.” Ye-e-e-ah. By contrast, Plasma has a concrete, useful definition for the term which Plasma Active's UI revolves around: activities are a holistic representation of your interests and topics of focus. What does that actually mean?

It means you communicate to the device (explicitly and implicitly) what you are interested in, experiencing and doing with that device; the device responds by keeping everything related to those various interests together for you. This allows the device to keep up as you move from one interest or topic to another.

A Plasma Active device can be your travel planning system one moment, your school textbook the next, your social media portal the next … all depending on what you are wanting to pay attention to right now. This verb-centric concept focuses on your information and the relationships within.

This design philosophy allows us to do several really cool things:

  1. Plasma Active can filter the information on your device to match what you are focusing on. This lets you put large amounts of information on the device without it becoming a data swamp that is difficult to move around in.
  2. The file system almost completely hidden. The focus is on meaning and relationships rather than hierarchical filing systems. (If you do need to root (excuse the pun) around in the file system, we do include a terminal application as well: the handy-dandy konsole.)
  3. Thirdly, it allows us to expose global concepts such as linking, sharing and tagging in a meaningful and easy-to-use way. I have found most systems that use concepts like tagging to require a large (and consistent) investment to get any real pay-off, while in Plasma Active I hardly even notice I'm doing anything.
As a result, we can deliver devices that work closer to the way our minds do; devices that are able to switch between concepts quickly, with a focus on one at any given time. The (often rather convincing) illusion of conscious multi-tasking generally arises from our ability to topic-flip efficiently; humans tend to be pretty poor true multi-taskers, however. Plasma Active is designed for how we're designed, and the benefits of this show up clearly when we put Plasma Active into the hands of people to use.

Around this core design we've pulled together a growing body of touch-optimized functionality based on KDE applications and frameworks so that a Plasma Active device is useful from the moment you turn it on: finding and reading books, opening up office documents, exploring your files, full groupware and a collection of fun games are just three things that compliment the typical applications of web browser. You don't need to open an app store or package manager: this is all there by default.

Best of all, it is all extremely easily to customize, change and advance. Developed completely in the open, sporting a very "normal" Linux userspace with no lock-down or lock-in and no royalties lurking in the background, Plasma Active is the perfect choice for building device experiences with. While other systems seem to go to great pains to weld the seams shut as tightly as possible, making it hard or even useless for bespoke applications, Plasma Active is built to be flexible, adaptable and accommodating of design requirements, whatever they might be.

What to Love About Plasma Active Three


Ok, tl;dr already, right? Let's get into what's up with this new release. After the release of Plasma Active Two, we decided to focus on a number of key areas, starting with the core set of applications. We began by building a file manager that reflects the Plasma Active design philosophy of “actively elegant”.

Managing files elegantly with Plasma Active Three's Files app

Unlike traditional file managers, Files doesn't directly expose the file system. We see that as an implementation detail like “which kernel drivers are loaded.” Yes, it's needed for the device to function, but the person using the device shouldn't have to care. Instead, Files promotes meaning and content. On starting Files, you select what you wish to view such as documents, images, music, videos, etc.. There are even stand-alone launchers for things like “Books” and “Images” which actually just launch Files in a content-optimized presentation. You may not even know you are looking at a file manager ... and if so we've succeeded.

Files lets you browse your information using a timeline, tags (including creating and removing tags with simple touch interaction) as well by activity. Oh, and it has a built-in search that doesn't only hit file names but also metadata and content.

The next thing we wanted was a way for people to add “stuff” to their devices easily. We had three primary objectives for this one: freedom, elegance and generality. The result is Add Ons, a system that can install books, wallpapers, applications, widgets .. actually anything that is packaged in a manner the system understands.



The content is accessed using a simple JSON interface. The server behind this is provided under a Free software license, and all the client and server side code is available from KDE's repositories. So not only are we able to provide a way to get at (e.g.) thousands of books really easily, we've also made it so that anyone who wishes could self-host their own system (or even have us host it for them). We believe this opens a whole new arena of possibilities for the use of devices in education, tourism, manufacturing, project-based office environments and more.

As if that wasn't enough, there's a new eBook reader (based on KDE's rather wonderful Okular), a news reader, an alarms application and numerous improvements to the applications we shipped previously.

Another extremely noticeable improvement is performance. Many applications in Plasma Active One and Two would take a rather long time to launch; you'd tap a launcher and then tap your fingers on the table as the little spinner spun and spun. With Three, things launch much faster. The file manager, for instance, launches in just over a second, as does the ebook reader, image viewer and others. We've hit upon a winning combination for how to get things launching quickly and their interfaces moving more smoothly. You'll see this in more and more of the applications we ship.

Part of our performance gains have come from moving to a new reference operating system base: Mer Core. This is the community continuation of MeeGo and a number of companies are actively working on and with it these days. The community itself has a potent mix of friendliness and competence that makes it a wonderful group to work with. It also has brought us into the modern age of Linux technologies. Faster boot times are nice (up-to-date kernels and systemd help here), but so is the ability to set up VPNs and have proper (read: high resolution) screen DPI. We integrated the Maliit input framework, giving Plasma Active Three a new keyboard that is faster, works with all applications you might install (including non-Qt ones) and gives us a really solid foundation for mobile input. As a bonus, the Maliit people have also proven to be an approachable, professional and enjoyable group of people to work with.

In between all these larger chunks of work, we also spent a good amount of time and effort improving the small things, such as where buttons appear in the sheet-style dialogs we use, how applications are listed and the visuals of certain animations to name a few.

As you can see, this is a big release and we hope you enjoy using it, tinkering with it, making new things with it and joining us in making it even better.

You can find out more about Plasma Active Three on the official website, including how to get it and get involved with the community behind and around it.
Read More
Posted in | No comments
Newer Posts Older Posts Home
Subscribe to: Comments (Atom)

Popular Posts

  • more plasma workspaces 4.8 news
    In my last blog entry on Plasma Workspaces 4.8 I talked about a number of things that we've worked on in the last six months. I promise...
  • what trains are for
    Today I had to go to Milan .. and back .. by train. That's a total of eight hours planted in a moving seat. I won't explain why I ha...
  • #merweek
    Make · Play · Live' s website is counting down to ... ? As Dario Freddi  noted in his G+ stream today, the week of the 25th is shaping u...
  • Improv and KDE
    When I announced the Improv ARM computer  on Monday, I did it on my blog which is also syndicated to Planet KDE. That's because there is...
  • a network
    Before I get to the positive strides we're making forward with Spark, I want to first apologize for not having the pre-order registratio...
  • an afternoon of small things
    I spent the afternoon working with some very small computers that we picked up today from a local shop that specializes in electronic parts ...
  • Call to authors
    For the last couple months I've been quietly working on a publishing deal for KDE books. I now have a contract in hand and we're mak...
  • bodega: partners, aggregating audiences and YOU
    I did a quick screencast today showing what "partners" are in Bodega and how they work. It's one of the many ways that Bodega ...
  • Break even weeks on bugs.kde.org!
    KDE developers around the world: we're currently just 14 closed bug reports away from a break even week! As of right now 475 bugs have b...
  • quick notes on using review board effectively
    The Plasma team has been using review board for quite a while. We were the pioneering project within KDE for its use, in fact, which leads t...

Blog Archive

  • ►  2013 (56)
    • ►  December (1)
    • ►  November (9)
    • ►  October (4)
    • ►  June (3)
    • ►  May (8)
    • ►  April (3)
    • ►  March (11)
    • ►  February (11)
    • ►  January (6)
  • ▼  2012 (49)
    • ►  December (1)
    • ►  November (8)
    • ▼  October (5)
      • one code base, multiple form factors
      • onwards to Four
      • KDE Manifesto in action: bodega server
      • KDE Manifesto
      • Plasma Active Three
    • ►  September (4)
    • ►  May (7)
    • ►  April (5)
    • ►  March (2)
    • ►  February (11)
    • ►  January (6)
  • ►  2011 (93)
    • ►  December (3)
    • ►  November (4)
    • ►  October (2)
    • ►  September (7)
    • ►  August (18)
    • ►  July (11)
    • ►  June (3)
    • ►  May (10)
    • ►  April (15)
    • ►  March (7)
    • ►  February (3)
    • ►  January (10)
  • ►  2010 (105)
    • ►  December (1)
    • ►  November (8)
    • ►  October (5)
    • ►  September (8)
    • ►  August (11)
    • ►  July (6)
    • ►  June (6)
    • ►  May (5)
    • ►  April (7)
    • ►  March (10)
    • ►  February (16)
    • ►  January (22)
  • ►  2009 (167)
    • ►  December (2)
    • ►  November (8)
    • ►  October (16)
    • ►  September (10)
    • ►  August (9)
    • ►  July (9)
    • ►  June (18)
    • ►  May (10)
    • ►  April (26)
    • ►  March (12)
    • ►  February (16)
    • ►  January (31)
  • ►  2008 (30)
    • ►  December (19)
    • ►  November (11)
Powered by Blogger.

About Me

Unknown
View my complete profile