Category Archives: BlaBla

New blog

BlaBla

After using for nearly a decade an old custom written little PHP hack (I loved that code since was my child and one of the first used-in-real-world pieces of software, but is time to wave goodbye ;), I finally moved my blog to WordPress, even tough the graphics still looks like it’s straight from the 80’s… I could never change that :p.

Any web link to old posts with the old urls will continue to work for the time being, I believe that we should try to make every Url we are responsible for on the interwebs as stable in time as possible.

A very nice thing about WordPress is that is dead easy to generate from any old legacy system a properly formatted file from which wordpress is able to import all posts and comments, I was quite positively surprised it was literally a 5 minutes thing 😉 (just adding a bit more data exported by the old rss feed as WordPress extended tags)

Hopefully, this means I’ll be able to blog more often now (Ah! the optimism :p)

Tokamak 6

BlaBla

Another Tokamak is over, and a very good one indeed

Many things have been done, many things have been decided this week. The main topic was prevalently about the architecture of our next workspace, and the frameworks needed to make such a vision coming to reality.

As you may already know, the new Plasma workspace we are now working on is based on Qt 5, QML2 and KDE Frameworks 5.
The platform will still run on X11, but down the road Wayland support will be added as well, work is ongoing in KWin for that.

First thing, when the new workspace based on that new technology will be released?

When is ready, where ready means there are no significant regressions left, so there will be a big technology change, but no significant disruption on the user interface.

There will be some small changes however, because the incremental improvement of the UI is a process that never stops. The login screen, the splash screen, the lock screen, the logout dialog and the fast user switching interface will look consistent all across the board, with a single, coherent QML theme for all those elements. As a side effect will make very easy to heavily customize the look and behavior of those components, either by users or vendors.

As the components mentioned before, also the shell itself will be defined by a single package.

This packae will define things such as the behavior of the desktop (icons? what plasmoids? what default wallpaper?), of the panels (how many? where?, what they do contain?), of the run command interface, and so on.

It will be possible to change this shell package at runtime, this means that user experiences such as Plasma Desktop, Plasma Active and Plasma Media Center can be loaded on the fly, on the same device and only when needed. You have a Plasma Active tablet that comes with a docking station? attach it and you’ll have Plasma Desktop on your screen. You attach your laptop to your 40 inch TV, and you get Plasma Media Center.

One interface does not fit any device, but one technology does, especially when it can give you an user interface always optimized for the device you are using in a particular moment.

A new show in town

BlaBla

For the next few weeks on mondays we’ll post an hangout-based mini podcast that will cover what to expect from the next iteration of Plasma workspaces, what’s happening in the development of KDE Frameworks 5 and the new Qt5 based goodness that is coming in KDE.

First episode here

It’s intended to be complimentary to shows like KDE teatime or Luminosity of Free Software, since this is a bit more oriented on low-level architecture, but yet still explained in an accessible, introductory way (don’t worry, the extra boring part, the API review is not there.)

Spoiler alert: it will explain why there will be no such thing called KDE5 😉

Active, images and devices

BlaBla

As I wrote before, we are trying to make PA4 as stable as possible, and as well as it was noted by some people, this involves also having images for a wide variety of devices.

What I’m doing, is kindof even another step: making the image creation as easy as possible, so that is possible for people to contribute easily in the creatoin process of those images, (especially images for previously unsupported devices).

In Mer, that is the base of Plasma Active the OS images are created from an instruction file called kickstart. you can find a source repository that creates kickstart files for plasma active here:

git clone git://anongit.kde.org/plasma-active-kickstart.git

Then, what you have to do is installing a Mer SDK, following the instructions here. This is very easy, is more or less uncompressing a tarball and running a shell script inside it, and should work on any distribution.

Then, from inside the SDK chroot environment, go where you downloaded the git repo (your home is accessible from there) and do:

mer-kickstarter -e . -c latest-devel/plasma-active-latest-devel.yaml -o plasma-active-latest-ks/

it will create a kickstart for each of the supported devices in the plasma-active-latest-ks/ subdirectory, then:

cd plasma-active-latest-ks/
sudo mic create livecd plasma-active-i586.ks -o . --pkgmgr=yum --arch=i686 --logfile=plasma-active-build.log

And an iso file with the same name as the kickstart file will be created. Different devices may need different image format, such as “raw” instead of “livecd”

Right now just a few devices are supported there, what I want to achieve is to support there all the device types Active has been successfully ran on.

One thing I must say, the code in that repo is derived from the Nemo project (another Qt based project built on top of Mer) so also a better sharing of bits and pieces for device adaptations with Nemo would be awesome as well.

Help make Plasma Active 4 shine

BlaBla

PA4

Plasma Active 3 was released on 15th October 2012, and since then, work on the next version has not stopped for a minute, now the work on Plasma Active 4 is well on the way.

Another important release at the horizon is the KDE Plasma Desktop shell 4.10, due in February.

We believe our desktop and mobile products are closely interrelated, both from a technology point of view and from a continuity of the user experience, therefore Plasma Active 4 will be based upon the KDE 4.10 release. This will mean that PA4 will automatically gain some of the features of 4.10, at least from the technology platform point of view, but means also another important thing: ease of setup.

PA4

We are planning to release it around the end of March, and since some hardware is approaching as well, this release is more important than ever.

Plasma Active 4 will have a number of important new features over PA3, there are countless small improvements, and few features that will be really visible, including:

  • Faster and more usable web browser
  • Improved usability of the on-screen keyboard
  • Numerous improvements in the File browser application: faster, more usable and scalable to very big amounts of data
  • Device-wide ownCloud integration
  • “Developer mode” on the device, to more easily work with it
  • More user friendly ui for setting alarms
  • Better notification
  • New applications
  • Community support for new devices

PA4

But I want to know more!

This is where you can make the difference: it’s very important that the new release will have an user experience as smooth as possible. The work for new features is coming to an end (even tough you are still in time to present a work plan if you want to work on a particular one). But is starting an even more important period: testing, stabilization, bugfix.

There are many ways to help in making the release shine: it may be just installing an image and testing, it may mean getting random people to test and register the issue they had with it, it may be participating in the discussions on IRC or the mailing list, it may be setting up a build environment, and start hacking.

PA4

Starting hacking on the components of Plasma Active is easier than ever, because as i said, PA4 will be based on KDE 4.10, that means everything specific of Plasma Active can be built on top of the development packages of KDE 4.10 from your distribution of choice, while having the active workspace and active applications running from git from your machine in matter of a minute.

From a packaging point of view, is ridiculously easy as well, as all you have to do is to install the Mer sdk, that is completely self contained, can be dropped on top of any distribution and doesn’t really “touch” your system

If you are interested, drop in in IRC, on the #active channel of Freenode, or join the malinglist active@kde.org

Plasma++ at Randa

BlaBla

Pretty busy days here at Randa. On the Plasma front some important decisions have been taken and a lot of work is now being done in this direction.

There is now a big traction in rewriting our current plasmoids in QML, such as the notifications I talked about some days ago, and many more that are coming.

The plan for the future is to have 100% QML-based workspaces, with as little changes as possible feature-wise compared to the current one, just with a smoother feeling 😉

This is only the first part of the road, and this is arriving already today, with each release of the Desktop workspace more complete, while Active is already 100% QML from day one.

What will happen next? Together with Qt5, there will also be the release of the next major revision of QML, that expands the language and changes the technology behind. Among the other things, everything will be on an opengl scene and the JavaScript bits will be managed by V8.

This comes at a price: only pieces of the user interface that are written in QML can be loaded in an environment based off QML2. hat means the old code based on QGraphicsView (and part of the old C++ API) has to go.

This wasn’t an easy decision, but it will make things dramatically easier in the future.

  • On QML2, we’ll have a lot more performance, guaranteeing a way smoother experience (with QML2 you can get 60fps in 1080p on an humble raspberry pi after all)
  • More stable, because most user facing code (especially most 3rd party) becomes scripted
  • Easier to write plasmoids: lowers the barrier for contributions and lowers the barrier in experimenting new innovative approaches for the UX
  • Also the internal library will be way easier to approach for new developers, because it will be way smaller and simpler
  • It will also be simpler to take and use the Plasma library for new things, like in application’s dashboards, or just using its QML components.

This is a long term plan: The work on the new Plasma library version started now, and we expect a working shell based on the new framewok and Qt5 in about 18 months or so.

I’ve just got a first preliminary version of libplasma building without QGraphicsView dependencies, and the binary is about two thirds of the size it had before, so this is an encouraging start 😉

It’s again an exciting time when we can design a new architecture, have crazy ideas, trying them out, and any input or help is very appreciated.

You can see the progress of the tasks that are added as the work proceeds here, and talk or claim some tasks for yourself at the usual channels of communication, plasma-devel@kde.org or the #plasma freenode IRC channel.

Note about QML plasmoids and dataengines

BlaBla

There is quite a lot of work going on in plasma land at the moment.

For PlasmaWorkspace 4.10 you may expect an overhauled visual appearance and an overhauled user interface on some plasmoids.

The two weather plasmoids and the pager were rewritten in QML by Luis as part of his gsoc, while others are in the works.

The Notifications and jobs plasmoid is in the works, solving many behavioural bugs that were a limit of the previous architecture (more on that later;)

A Kickoff replacement is on the works as well, and if everything goes allright another important one will arrive for 4.10.

This is made possible by the contribution of the people, I’m seeing a renewed interest in working on plasmoids, also due the new architecture that significantly decrease the learning curve.

But, there is always a but 😉

There is a small problem I seen in some converted QML plasmoids: sometimes the needed data arrives from a Plasma dataengine. there is a nice system to map that data directly to a model usable in a QML ListView, Repeater and so forth, DataModel from org.kde.plasma.core

This is a (strong) simplification of the device notifier plasmoid:

PlasmaCore.DataSource {
    id: sdSource
    engine: "soliddevice"
    //hpSource is a datasource connected to the hotplug engine
    connectedSources: hpSource.sources
}

ListView {
    id: notifierDialog

    model: PlasmaCore.DataModel {
            dataSource: sdSource
    }
    delegate: PlasmaComponents.Label {
        text: i18nc("@info:status Free disk space", "%1 free", model["Free Space Text"])
    }
}

The keys of the dataengine are directly mapped to the ListView model, so directly accessible to the delegates via the “model” variable, or directly as their own variables.

However, due to a limitation in QML, if the dataengine doesn’t immediately do a setData() of a particular key, or a key is not always available, it won’t be mapped as a role in the delegates, if you encounter this roadblock, feear not, you can still access the data with something that in the above example would map sdSource.data[“DataengineSource”][“Free Space Text”]

When possible tough use the model mechanism, since some nice optimizations are planned for it 😉

One of the things I wish for plasma2 is a formal specification of dataengine available data in a way that would avoid situations like that and most important nice documentation may be extracted from 😉

Click here to lend your support to: KDE Randa Meetings and make a donation at www.pledgie.com !

The Randa platform meeting

BlaBla

Last year, a bunch of KDE hackers gathered together in the little lovely swiss village of Randa in a meeting that was called Platform 11 (actually the third KDE meeting held in Randa).

That quite large meeting turned out to have been one of the most productive ever. Developers from all areas of KDE, from libraries and platforms targeted to other developers to applications (built with those libraries) targeted to end users.

A lot of design and development work happened on the KDE Frameworks 5 happened. This is crucial for the future of the KDE applications and workspaces, because besides porting to the soon to be released Qt5, it will make the KDE libraries much more modular, making easier for any application developer to just cherry pick between the features offered by the the KDE frameworks and use them on any platform without significant dependencies, being Linux, Windows, Mac, Android…

You can help this meeting to happen, as usual the development is done by volunteers, but there are some fixed expenses, like food and travel. There is a fundraising campaign for this on Pledgie, of which we are already at a good point, so yeas, you can make the diffeernce 🙂

Click here to lend your support to: KDE Randa Meetings and make a donation at www.pledgie.com !

Workspace sprint

BlaBla

Last week I was among many other KDE fellow hackers at the Workspace sprint in Pineda de Mar, It was a really awesome location (and company, of course;).

But is not all fun and play: what we have produced while there? What it’s a bit different from other times, is that it wasn’t a coding sprint, but rather was a very needed moment of taking a step back and reflect about the future.

We are in a transition period from a technological point of view: Qt5 is coming and the KDE frameworks effort is helping to redefine the whole developer story around our tecnology… but this is another story 🙂

This is the ideal moment to see where we are now in term of what we offer to the user, and how the whole workspace is perceievd as a whole. The first important thing is indeed exactly realizing and knowing where we are now, having a big picture from different sides.

At this point we can have a defined and realistic vision on where the workspace should head in the next years, and how to get there.

To get to this comprehension on where we are and were we want to go we are starting to use several classic tecniques of design, such as personas (hello Carla and Raj) and role games that help to identify problems (speed boat) and current or future features (Product tree), of which Sebastian and Kevin already explained it in length.

Looking at the problems of the boats and the Product tree, among the other things two stick out: Activities are a feature that really stands out of the pack: nobody else has it, but in order to be really a game changer has to be expanded a lot and be way more “natural” to use.

Also, workflows that spread across multiple devices are becoming more and more common (they are very important for Carla and Raj); our device spectrum effort is the right thing to do, but has to be more integrated in the core development process of everything we do as a community, and has to look more integrated (communication and marketing goals).

Other wiki pages and documentation on what has been going on those days will come up over the next few days: we’ll keep you posted.