Plasma Mobile

Back around 2006, when the Plasma project was started by Aaron Seigo and a group of brave hackers (among which, yours truly) we wanted to create a user interface that is future-proof. We didn't want to create something that would only run on desktop devices (or laptops), but a code-base that grows with us into whatever the future would bring. Mobile devices were already getting more powerful, but would usually run entirely different software than desktop devices. We wondered why. The Linux kernel served as a wonderful example. Linux runs on a wide range of devices, from super computers to embedded systems, you would set it up for the target system and it would run largely without code changes. Linux architecture is in fact convergent. Could we do something similar at the user interface level?

Plasma Netbook

In 2007, Asus introduced the Eee PC, a small, inexpensive laptop. Netbooks proved to be all the rage at that point, so around 2009, we created Plasma Netbook, proving for the first time that we could actually serve different device user interfaces from the same code-base. There was a decent amount of code-sharing, but Plasma Netbook also helped us identifying areas in which we wanted to do better.

Plasma Mobile (I)

Come 2010, we got our hands on an N900 by Nokia, running Maemo, a mobile version of Linux. Within a week, during a sprint, we worked on a proof-of-concept mobile interface of Plasma:

Well, Nokia-as-we-knew-it is dead now, and Plasma never materialized on Nokia devices.

Plasma Active

Plasma Active was built as a successor to the early prototypes, and our first attempt at creating something for end-users. Conceived in 2011, the idea was not just to produce a simple Plasma user interface for a tablet device, but also deliver on a range of novel ideas for interaction with the device, closely related to the semantic desktop. Interlinked documents, contacts, sharing built right into the core, not just a "dumb" platform to run apps on, but a holistic system that allows users to manage their digital life on the fly. While Plasma Active had great promise and a lot of innovative potential, it never materialized for end-users in part due to lack of interest from both, the KDE community itself, but also from people on the outside. This doesn't mean that the work put into it was lost, but thanks to a convergent code-base, many improvements made primarily with Plasma Active in mind have improved Plasma for all its users and continue to do so today. In many ways, Active proved valuable as a playground, as a clean slate where we want to take the technology, and how we can improve our developemnt process. It's not a surprise that Plasma 5 today is developed in a process very similar to how we approached Plasma Active back then.

Plasma Mobile (II)

Learning from the Plasma Active project, in 2015 we regrouped and started to build a rather simple smartphone user interface, along with a reference software stack that would allow us not only to develop Plasma Mobile further, but to allow us to run on a growing number of devices. Plasma Mobile (II)'s goal wasn't to get the most innovative of interfaces out, but to create a bread-and-butter platform, a base to develop applications on. From a technology point of view, Plasma is actually very small. It shares approximately 95% of the code with its desktop companion, widgets, and increasingly applications are interchangeable between the two.

Plasma Mobile (in any shape or form) has never been this close to actually making it into the hands and pockets of end users. A collaboration project with Purism, a company bringing privacy and software freedom to end-users, we may create the first Plasma phone for end users and have it on the market as soon as januari 2019. If you want to support this project, the crowdfunding campaign has just passed the 40% mark, and you can be part of it - either by joining the development crew, or by pre-ordering a device and thereby funding the development.

22 Sep 2017 3:19pm GMT

So, back in Randa I was splitting my energies and attentions in many pieces. Some attention went to making pancakes and running the kitchen in the morning - which is stuff I take credit for, but it is really Grace, and Scarlett, and Thomas who did the heavy lifting, and Christian and Mario who make sure the whole thing can happen. And the attendees of the Randa meeting who pitch in for the dishes after lunch and dinner. The Randa meetings are more like a campground than a 5-star hotel, and we work together to make the experience enjoyable. So thanks to everyone who pitched in.

Part of a good sprint is keeping the attendees healthy and attentive - otherwise those 16-hour hacking days really get to you, in spite of the fresh Swiss air.

Frederik encouraged us to touch the floor and the ceiling with his acro-yoga sessions; it is good to get out of the hacking room and get into shape. These sessions also teach us all trust and cooperation. And between sessions, he fixed a Qt bug that probably affects Calamares accessibility.

Calamares had some more bugs squashed, its accessibility improved - although I need to test that again and again on different setups now that I'm home, since it needs time to re-build Qt and all. Even with this fix, the goal to reduce Calamares' root-needs remains.

You can read more of what the attendees in Randa achieved on planet KDE (e.g. kdenlive, snappy, kmymoney, marble, kube, Plasma mobile, kdepim, and kwin). I'd like to give a special shout out to Manuel, who taught me one gesture in Italian Sign Langauage - which is different from American or Dutch Sign Language, reminding me that there's localization everywhere.

For me, being back home means sitting back at my big FreeBSD box, hacking on Calamares and ARPA and CMake and stuff again, with a renewed sense of purpose and team thanks to having worked together in Randa. If you like what KDE achieves in Randa, consider still supporting the fundraiser so that we can return to the mountains next year.

22 Sep 2017 11:41am GMT

A lot happened recently regarding Kdenlive. Let's start with a some news from the swiss mountains:

Randa!

Last week, from wednesday to saturday I attended KDE's annual Randa sprint organized by wonderful people. This was an occasion to work fulltime on Kdenlive. Here is a resume of what happened during these days:

• I submitted Dušan Hanuš's color correction improvements (allow negative lift values in Lift/Gamm/Gain effect) in Movit and MLT. They have now been merged so we should soon have better color wheel correction.
• I made the first tests with Rafal Lalik's TypeWriter effect, that would bring back this much requested feature for our users.
• I merged my code for speed effect and committed a very preliminary qml builtin effect stack (that should in the future allow easy adjustment of basic video properties like contrast, color balance, etc).
• I fixed a problem preventing multithreaded rendering that we discovered with Manuel when comparing Shotcut and Kdenlive.
• I spend several hours trying to debug a performance issue and finally discovered that it was caused by a small qml animation (blinking rectangle) - a reminder that fancy effects can sometimes really get in the way of productivity!
• I briefly exchanged with Scarlett regarding AppImage and Snap packages
• And several small other fixes: display warning when adding images smaller than 8pixels (not fully supported by MLT), fixed import of image sequences, removed unnecessary warning on first start about missing DVD tools (stuff from another century as I was told :).

You can still donate to KDE's Randa fundraising to help. Kdenlive was also recently mentioned as the preferred video editor in a large survey of Ubuntu Desktop users, which makes us very proud!

First alpha testing version available

To share the result of these last months of work, I am happy to announce the first alpha version for Kdenlive 17.12, that contains the major code refactoring as well as the transition to Qml for the timeline display. This is an AppImage testing release. Just download the file, make it executable and run it. The x86_64 linux AppImage is available from the KDE servers: https://files.kde.org/kdenlive/unstable/kdenlive-alpha1-17.12.AppImage.mirrorlist
Beware: this is an experimental alpha version, allowing you to have a look at Kdenlive's future and should not be used for production. Projects created with this version cannot be opened by previous Kdenlive releases, and many issues still have to be solved before the official december release.

Windows version updated

Vincent Pinon worked on updating the Windows version to the last stable version (17.08.1) that can be downloaded here: https://files.kde.org/kdenlive/release/Kdenlive-17.08.1-w64.7z.mirrorlist

We hope to improve our packaging soon with the help of some great people in the KDE community, more news will follow on that.

Join us!

We are always welcoming people interested to contribute and exchange, so if you want to learn more and meet us, you are welcome to participate to our next Kdenlive café on IRC, channel #kdenlive, Monday, 2nd of October at 21pm (UTC+2) (CEST).

22 Sep 2017 9:46am GMT

One of the usual data visualization workflows supported by LabPlot involves the import of some external data into the application and the creation of plots. Once the data is imported, e.g. into a spreadsheet, there are basically the following steps to do in order to get the data visualized:

• create a worksheet (if not available yet)
• add a plot (if not available yet)
• add a xy-curve to the plot and select the spreadsheet columns as data sources for the curve

Despite the apparently small number of steps required here, this can result in a lot of tedious work if you need to plot many different imported data sets in one or several plots.

For the upcoming release we decided to improve here and to provide the user a more faster way to get the data plotted. The new "Plot Data" dialog, reachable via the context menu of the spreadsheet, helps the user to create all the intermediate steps mentioned above for many data sets in one single step:

In this dialog, the process of creation of all the required objects can be influenced via different options where the user can decide how many plots to create and where to add the generated curves. The dialog respects the selection in the worksheet and only the selected columns are plotted. In case nothing is selected in the spreadsheet, all data sets (columns) are considered:

When generating curves, LabPlot tries to automatically recognize the column that has to be used as the source for the x-data by evaluating the "plot designation" property attached to every column in the spreadsheet. This greatly helps if you need to plot a set of data series having the same x-values (usually an index or timestamp). In case there is no column with the plot designation "X", the first selected column is used as X.

Similar for data analysis: if you wanted to, let's say, smooth some data in a spreadsheet and to compare the result with the original data in a plot, you had previously to

• create a worksheet (if not available yet)
• add a plot (if not available yet)
• add a xy-curve to the plot and select the spreadsheet columns as data sources for the curve
• add a smoothing curve and select the spreadsheet columns as data sources for the smooth curve
• click on the "Recalculate" button to perform the calculation of the smoothed data

Also this kind of tasks can result in a lot of manual tedious work, which already was the reason for some user complains. We addressed this, too. With the recent improvements in LabPlot, you simply select the corresponding analysis function from the "Analyze and plot data" sub-menu in spreadsheet's context menu and let LabPlot do all the required steps

The procedure here is basically the same as described above with the only difference that the user has now the chance to additionally decide in the "Plot Data" dialog whether they want to plot the result of the analysis function together with the original data or to plot the result curve only.

With the analysis workflow sketched above, the analysis was initiated from the spreadsheet. For the use cases where you already have the data plotted and now want to smooth the already visualized data, to fit a certain model to the data, etc., you can initiate the analysis step via the context menu of the curve directly in the plot:

To further speed up the creation of data visualizations, we implemented the feature that allows the user to simply drag the columns in the project explorer and to drop them on the already existing plots - either by dropping in the Project Explorer or by dropping in the worksheet:

Until the next release, planned for December this year, we still have some time for fine-tuning and fixing the remaining issues in the new features and improvements briefly described here. All of them are already available in master and can be tried out.

21 Sep 2017 7:51pm GMT

Another successful Randa meeting! I spent most of my days working on snappy packaging for KDE core applications, and I have most of them done!

Snappy Builds on KDE Neon

We need testers! Please see Using snappy to get started.

In the evenings I worked on getting all my appimage work moved into the KDE infrastructure so that the community can take over.

I learned a great deal about accessibility and have been formulating ways to improve KDE neon in this area.

Randa meetings are crucial to the KDE community for developer interaction, brainstorming, and bringing great new things to KDE.
I encourage all of you to please consider a donation at https://www.kde.org/fundraisers/randameetings2017/

21 Sep 2017 12:54pm GMT

I am pleased to inform that Qt 5.6.3 has been released today. As always with a patch release Qt 5.6.3 does not bring any new features, just error corrections. For details of the bug fixes in Qt 5.6.3, please check the change logs for each module.

Qt 5.6 LTS is currently in the 'Strict' phase, and only receives fixes to security issues, crashes, regressions and similar. Since end of 2016 we have already reduced the number of fixes going into the 5.6 branch and after Qt 5.6 LTS enters the 'Very Strict' phase it will receive security fixes only. The reason for gradually reducing the amount of changes going into an LTS version of Qt is to avoid problems in stability. While each fix as such is beneficial, they are also possible risks for behavior changes and regressions, which we want to avoid in LTS releases.

As part of our LTS commitment, we continue to support the commercial Qt 5.6 LTS users throughout the three-year standard support period, after which it is possible to purchase extended support. For description of our support services, please check the recent blog post describing the Standard, Extended and Premium Support. In May 2017 we released Qt 5.9 LTS, which includes a wide range of new features, functionality and overall performance improvements. We expect to release Qt 5.9.2 patch release still during September, including all the bug fixes of Qt 5.6.3 and many more. To learn more about the improvements that come with Qt 5.9 LTS you can find all relevant blogs and on-demand webinars here.

If you are using the online installer, Qt 5.6.3 can be updated using the maintenance tool. Offline packages are available for commercial users in the Qt Account portal and at the qt.io Download page for open-source users.

The post Qt 5.6.3 Released appeared first on Qt Blog.

21 Sep 2017 10:08am GMT

21 Sep 2017 9:00am GMT

Less than a month after Krita 3.2.1, we're getting ready to release Krita 3.3.0. We're bumping the version because there are some important changes for Windows users in this version!

Alvin Wong has implemented support for the Windows 8 event API, which means that Krita now supports the n-trig pen in the Surface line of laptops (and similar laptops from Dell, HP and Acer) natively. This is still very new, so you have to enable this in the tablet settings:

And he also refactored Krita's hardware-accelerated display functionality to optionally use Angle on Windows instead of native OpenGL. That means that many problems with Intel display chips and broken driver versions are worked around because Krita now indirectly uses Direct3D.

There are more changes in this release, of course:

• Some visual glitches when using hi-dpi screens are fixed (remember: on Windows and Linux, you need to enable this in the settings dialog).
• If you create a new image from clipboard, the image will have a title
• Favorite blending modes and favorite brush presets are now loaded correctly on startup
• GMIC
  • the plugin has been updated to the latest version for Windows and Linux.
  • the configuration for setting the path to the plugin has been removed. Krita looks for the plugin in the folder where the krita executable is, and optionally inside a folder with a name that starts with 'gmic' next to the krita executable.
  • there are several fixes for handling layers and communication between Krita and the plugin
• Some websites save jpeg images with a .png extension: that used to confuse Krita, but Krita now first looks inside the file to see what kind of file it really is.
• PNG:
  • 16 and 32 bit floating point images are now converted to 16 bit integer when saving the images as PNG.
  • It's now possible to save the alpha channel to PNG images even if there are no (semi-) transparent pixels in the image
• When hardware accelerated display is disabled, the color picker mode of the brush tool showed a broken cursor; this has been fixed.
• The Reference Images docker now only starts loading images when it is visible, instead on Krita startup. Note: the reference images docker uses Qt's imageio plugins to load images. If you are running on Linux, remove all Deepin desktop components. Deepin comes with severely broken qimageio plugins that will crash any Qt application that tries to display images.
• File layers now correctly reload on change again
• Add several new commandline options:
  • -nosplash to start Krita without showing the splash screen
  • -canvasonly to start Krita in canvas-only mode
  • -fullscreen to start Krita full-screen
  • -workspace Workspace to start Krita with the given workspace
• Selections
  • The Select All action now first clears the selection before selecting the entire image
  • It is now possible to extend selections outside the canvas boundary
• Performance improvements: in several places superfluous reads from the settings were eliminated, which makes generating a layer thumbnail faster and improves painting if display acceleration is turned off.
• The smart number input boxes now use the current locale to follow desktop settings for numbers
• The system information dialog for bug reports is improved
• macOS/OSX specific changes:
  • Bernhard Liebl has improved the tablet/stylus accuracy. The problem with circles having straight line segments is much improved, though it's not perfect yet.
  • On macOS/OSX systems with and AMD gpu, support for hardware accelerated display is disabled because saving to PNG and JPG hangs Krita otherwise.

Download

Windows

Note for Windows users: if you encounter crashes, please follow these instructions to use the debug symbols so we can figure out where Krita crashes. There are no 32 bits packages at this point, but there will be for the final release.

• 64 bits Windows: krita-3.3.0-rc.1-x64-setup.exe
• Portable 64 bits Windows: krita-3.3.0-rc.1-x64.zip
• Debug symbols. (Unpack in the Krita installation folder)

• Explorer Shell extension: kritashellex-1.2.4.0-setup.exe

Linux

• 64 bits Linux: krita-3.3.0-rc1-x86_64.appimage

(If, for some reason, Firefox thinks it needs to load this as text: to download, right-click on the link.)

When it is updated, you can also use the Krita Lime PPA to install Krita 3.3.0-rc.1 on Ubuntu and derivatives.

OSX

• OSX disk image: krita-3.3.0-rc.1.dmg

Note: the gmic-qt and pdf plugins are not available on OSX.

Source code

• Source code: krita-3.3.0-rc.1.tar.gz

md5sums

For all downloads:

• md5sums.txt

Key

The Linux appimage and the source tarball are signed. You can retrieve the public key over https here:
0x58b9596c722ea3bd.asc. The signatures are here.

Support Krita

Krita is a free and open source project. Please consider supporting the project with donations or by buying training videos or the artbook! With your support, we can keep the core team working on Krita full-time.

21 Sep 2017 7:14am GMT

This week has been focused on finishing the development of persistent notifications at the top of the music views. They are intended to provide information about what happen with actions the user can take to improve things.

The following items have been pushed:

• Clean up of dependencies. Now all frameworks come with a description. Some have been downgraded to optional or recommended. Some have been upgraded to recommended ;
• A new version of persistent notifications.

The new persistent notifications

The player can be in four states:

• No notifications are active No notifications

• One notification is activeOne notification

• More than one notifications are active. Only one is shown such that vertical space is preserved

  Multiple notifications with the first visible

• The notifications area is expanded and several notifications are visible Show multiple notifications

If the user choose to act, the buttons are temporarily disabled to provide instant feedback and the notification disappear when the root cause is fixed (like in the example, if music tracks are discovered or Baloo configuration is modified or Baloo music indexer is disabled in Elisa.).

I have tried to provide smooth transitions between each of those states. Some may still be missing. Please do not hesitate to provide feedback on this feature.

I plan to add more notifications of this kind when the software wants to provide feedback to the user and asks him to choose what he prefers.

Next week, I should continue to improve integration with Baloo. I would also like to improve (in fact allow) the keyboard interaction.

20 Sep 2017 8:55pm GMT

Please read the following guest post from Łukasz who joined me last week in Randa to work on KMyMoney. Good things have happened in Randa and are going to happen to KMyMoney afterwards. During that time I've started to work on the appearance of the application in regard to colors. I think it's a …

Continue reading "KMyMoney's Łukasz Wojniłowicz in Randa"

20 Sep 2017 7:20pm GMT

20 Sep 2017 5:06pm GMT

Just came back home yesterday from Randa Meetings 2017. This year, even though my major motive for the sprint was to use Qt 5.8's Qt Speech module instead of custom Java for text-to-speech during navigation, that could not be achieved because of a bug which made the routes not appear in the app in the first place. And this bug is reproducible both by using latest code, and old-enough code, and is even there in the prod app in the Google Play Store itself. So, although most of my time had gone in deep-diving on the issue, unfortunately I was not able to find the root-cause to it eventually. I will need to pick up on that in the coming weeks again when I get time, to get it fixed. Apart from that, I managed to fix a few more bugs, and work on adding a splash screen to the Android app:

• Made the bookmarks dialog responsive to touch everywhere. When we tapped on the Search field in the app, if nothing was written in that field then the bookmarks dialog showed up there. If the number of bookmarks was <= 6, then the far-lower part of the dialog did nothing on being tapped. Made that portion choose the last item from the bookmarks list in that case.

• There was an issue where pressing the back-button always led to closing the app instead of handling that event depending on the various scenarios. On looking, it was found that the root-cause for the issue was lying in the code of Kirigami itself. Reported the same to Marco Martin, and fixed the issue in the Marble app via a workaround by using Kirigami.AbstractApplicationWindow instead of Kirigami.ApplicationWindow in the Qml. Also reported the issue that svg icons were not showing up in the app on Plasma Mobile because of svg icons not being enabled there.

• Worked on adding a splash screen to the Marble Maps app. The highest resolution of the Marble logo in png that we had at the moment was 192 x 192, which looked a bit blurry, as if it had been scaled up, so I just displayed it as 100×100 for the splash screen to make it look sharp. Later, Torsten created a 256×256 version of the png from an svg, which got rid of the blur in the previous png. So I added that in the splash screen later, and the icon there looks much bigger, sharper, and non-blurry now.
  

Apart from work, there was snow this year, did some interesting acro-yoga with Frederik, did a 3-hour hike to walk across the longest pedestrian suspension bridge in the world, went on a tour to Zermatt to catch a glimpse of the Matterhorn, and ended it all with having a delicious barbecue with Emmanuel and Tomaz somewhere up in the mountains on the final evening. Thanks to Mario for organizing the meetings and the cheese and chocolates, without which no work could have been done.

20 Sep 2017 2:41am GMT

Kubuntu 17.10 - code-named Artful Aardvark - will be released on October 19th, 2017. We need a new banner for the website, and invite artists and designers to submit designs to us based on the Plasma wallpaper and perhaps the mascot design.

The banner is 1500×385 SVG.

Please submit designs to the Kubuntu-devel mail list.

20 Sep 2017 2:25am GMT

I've spent the last few days with fellow KDE hackers in beautiful Randa in the Swiss Mountains.
It's an annual event that focuses on a specific topic every year, and this time accessibility was up, so Michael and me made our way up here to improve Kube in that direction (and to enjoy the scenic surroundings of course).

I have to admit we didn't spend all our time on accessibilty, since we've recently done a big push in that direction already with keyboard navigation and translation preparations. Anyhow, here's an overview on what we've worked on:

Query performance

While it might now be a showstopper, there is an annoyance in Kube that if you initially sync a lot of mail (my INBOX alone contains 40k) this not only uses a lot of CPU in the synchronizer process (which is expected), but also in the Kube client process, which seems odd at first.

The reason for this are the live queries, which update themselves whenever the resource signals that it has a new revision available (A new revision could be a new mail or a modification for instance). Usually, when we process an update we do so incrementally. If you just received a new mail or two, or something has been marked as read etc., that is also the sensible thing to do. It's a comparatively tiny amount of work, and we really want incremental changes in the result anyways, otherwise we'd mess up the client's UI state (selection, scroll position, …).

However, when we fetch 40k mails that also means we get 40k updates that we have to process and it's surprisingly hard to avoid that:

• We don't know in advance that there will be 40k updates, so we have to process the updates initially.
• We can't really skip any updates, because any update might affect what we have in the view. We just don't know until we've already processed it.
• We can't just fall back to redoing the full query because we need incremental changes, otherwise you'd see a blinking UI until the sync is done.
• We don't want to just stop updating until the sync is done, because in most cases you already have useful data to work with, so this is really a background task, and we don't want to block all updates.

If you end up processing the larger part of the data-set as incremental update it becomes naturally really expensive, because you can't leverage the indexes which made queries efficient in the first place. So this is not something that can just be optimized away.

This means some middleground has to be struck which allows for updates, but doesn't render the application maxed out because it's updating so fast.

A possible approach to fix this would be the following:

• Set some threshold when it becomes cheaper to redo the query instead of processing the updates.
• If the threshold is reached, redo the query from scratch.
• Diff the current results with the redone results so we can still update the UI incrementally.
• Apply some event compression to the revision updates, so we land in the optimized path quicker.

Given that this really isn't a huge problem right now, since the application does remain responsive (querying is done in a separate thread), and this will only ever happen if you sync a large folder for the first time, I won't spend a lot of time on that for now. The most important part was figuring out why this problem appeared in the first place, and understanding it's reasons and implications. This will allow us to attack it properly once we get to it.

HTML composer

Kube's composer is currently a simple text field where you can type plain text. This is obviously not the end goal.
To explore our options in providing a more advanced composer, we tried prototyping a simple HTML editor.
Unfortunately our experiments showed that QML isn't really up to that yet. The official example falls flat on it's face when trying it (it simply fails except for a few specific cases), and the "API" to do any sort of formatting is more a hack than anything else.

Granted, the API docs of the TextArea also state that you can't modify the internal document, or in other words, no HTML composer for us.

The options we have left are:

• Some custom text editing component (sounds like a lot of work, probably is).
• Try to hack around TextAreas deficiencies until we find some magic combination that works.
• Use a WebView and implement everything in javascript (now that's just sad).

For now the item is postponed.

GPG Support

We've scoped out what we want to reach for initial GPG support in Kube. While we already have read-only GPG support (we can decrypt mails and verify signatures), there is some more work to be done until we can also sign and encrypt messages we're sending. The focus will be on keeping things simple to get the job done, and not build the most advanced GPG interface ever.

Things that will happen are:

• Key selection for the account that will then be used for encryption.
• Key setup for new accounts that don't have a key yet (either by importing an existing key or creating a new one)
• Encryption option in the composer that depends on the availability of keys for all recipients.
• Key selection for users in the addressbook.

All of it can be found on Phabricator

Cross platform builds

Since we had some cross platform building experts on site, I explored some of our options:

• Cross compiling for Windows with MXE.
• Building on Windows and OSX using craft.
• Building with some custom scripts on Windows.
• Building with macports on OSX.
• Building with brew on OSX.

Although I had mixed feelings about craft back from the days when I used emerge (the craft predecessor) to build Kontact on Windows,
it at least looks like the most sensible option still.

Crosscompiling using MXE seems ok-ish for Windows; I had some success for parts of the stack and the rest will just be the grunt work of making tarballs and writing build definition files. At least that way you don't have to work on a Windows system. However I heard that the compiled end-result will just not be as good as using native compilers, so perhaps it's not worth it to trade some building convenience for a sub-par end result.
Also, writing the definition files is pretty exactly the same as for craft, and MXE would be for Windows only.

So, looks like I'll be doing another round with craft sometime soonish.

Plasma phone

It kinda works.

Bushan Sha quickly wipped up a package for the Plasma Phone and installed it, which allowed us to see Kube running for the first time on a mobile device, which felt surprisingly cool

There clearly are some rough edges, such as the UI being completely unsuitable for that form factor (who would have thought…), and a bug in one of the QML components which breaks folder selection using a touch screen. Still, it was nice to see =)

Input validation

To improve the UX with forms in Kube, or more specifically the configuration dialog, we wanted to provide some feedback to the user on what fields need to be filled out. Michael implemented a neat little visualization that that marks invalid input fields and gently fades away once the input becomes valid.

So far we only validate that fields are not empty, but that can be changed by assigning new validators that e.g. check that an email address field indeed contains a valid email address.

Recap

It was once again a very productive week, with lot's of good food and a couple of fun hikes in between to clear out the head.
Besides the usual work going on it's invaluable to have an exchange with other people that just might have solved the problem already that you're going to spend the next few weeks on. So in many ways this is not only about a concentrated work effort, but also about professional training and exchange, and that is only possible in when you're sitting together with those people.

I'd like to thank the whole team that organized the sprint, took care of us with great food and lot's of chocolate and generally just made our stay in Randa great once more.

If you made it all the way down here and skipped the fundraiser on top, please consider donating something, it's the only way we can keep doing meetings like this and they are invaluable for us as a community.

19 Sep 2017 10:15pm GMT

Last week I had a chance to attend the Randa meetings 2017, my plan was to work on the Plasma Mobile during the sprint, improve the state of current images. A few things changed over the course of the week:

New shiny wallpaper and packages

Starting from 8 Sept, we started using the packages from KDE Neon buildsystem instead of building them on the Plasma Mobile CI, this provides few benefits,

• No need to separately build the common things like Qt5, KDE Frameworks, Plasma
• Always up-to-date packages, no need to manually re-trigger builds for common things

We also upgraded to newer version of Qt, Qt 5.9 from the older version of Qt 5.7.1, this aligns our stack with whatever KDE Neon dev unstable edition is using.

Rootfs for non-nexus Qualcomm devices

Non-nexus Qualcomm devices use a modified version of the hwcomposer.h which is not ABI compatible with the generic version of the android API headers, so for them the libhybris and kwin need to be separately built. Previously our CI infrastructure didn't support this workflow, however now we are able to create the rootfs for such devices. Below is an image of Plasma Mobile running on Xiomi Mi device.

Marble maps

At Randa, we had a chance to test the newer version of the Marble maps, which has much more improved performance when zooming out-in. We were able to happily search locate Randa in the Marble maps.

QML based mobile friendly "konsole"

Previously we were using Konsole from the KDE Applications as a terminal emulator, however Konsole user interface was not mobile-friendly, and it was not possible to e.g, tab complete the command, go through history, etc. At Randa Emmanuel Lepage Vallee pointed us to qmltermwidget, which powers the terminal application in Ubuntu Touch and Cool-retro-term application. Marco Martin was able to write a simple QML application around qmltermwidget which can replace Konsole in Plasma Mobile.

Kirigami based koko

During GSoC 2017 lot of work has been put to port the normal QtQuick based image viewer application Koko to kirigami2, you can follow the work of Student developer Atul Sharma on his blog. At the Randa Sprint, we were able to test this work on Plasma Mobile and it shows great improvements compared to the older version.

Improved window switching experience

Due to a bug in the Plasma Mobile shell, shell windows such as task switcher and shell itself were also appearing in the task switcher, as a result of that user was able to close the shell window which ultimately ends up crashing the plasmashell. We were able to fix this bug in the plasma-workspace and plasma-phone-components so that Plasma Mobile shell windows would not appear in the task switcher.

Kube(!!!)

Yes, that is Kube in the first picture, we were able to run the Kube on the Plasma Mobile, it works in theory on Plasma Mobile, however the user interface is not mobile-friendly and needs various fixes to be usable on mobile. We will work with the Kube team to fix the issues and then test them on Plasma Mobile in the future.

Conclusion

That is all for now, I would like to thank the all the donors who donated for the Randa Meetings 2017, and made it possible for me to travel to Randa, Switzerland.

If you liked the work done on Plasma Mobile during the Randa Sprint, please support us on Randa 2017 fundraiser to make events like Randa possible in the future.

19 Sep 2017 12:00am GMT

Adventurous users and developers running the Artful development release can now also test the beta version of Plasma 5.11. This is experimental and can possibly kill kittens!

Bug reports on this beta go to https://bugs.kde.org, not to Launchpad.

The PPA comes with a WARNING: Artful will ship with Plasma 5.10.5, so please be prepared to use ppa-purge to revert changes. Plasma 5.11 will ship too late for inclusion in Kubuntu 17.10, but should be available via backports soon after release day, October 19th, 2017.

Read more about the beta release: https://www.kde.org/announcements/plasma-5.10.95.php

If you want to test on Artful: sudo add-apt-repository ppa:kubuntu-ppa/beta && sudo apt-get update && sudo apt full-upgrade -y

The purpose of this PPA is testing, and bug reports go to bugs.kde.org.

18 Sep 2017 11:12pm GMT