Subscribe to Planet KDE feed
Planet KDE - http://planetKDE.org/
Updated: 35 min 49 sec ago

AtCore: 100 Dowloads \o/

Wed, 2018/02/07 - 1:34am

First of all: Thank You! Last week we made the first release of AtCore.  But before that, we left AtCore on the beta version for more than a month until the 1.0 release. With the 3 months that AtCore is out for public use, we didn't receive any bug report, but a lot of congrats... Continue Reading →

Plasma 5.12 LTS is in KDE neon User Editions

Tue, 2018/02/06 - 11:43pm

Plasma 5.12 LTS was launched today after some months focusing on speed and stability of the original and best Linux desktop.

We’ve updated the packages in KDE neon User Edition and in KDE neon User LTS Edition.  The installable image is also updated.

Enjoy it!

 

The future of distros

Tue, 2018/02/06 - 9:11pm

Today KDE released Plasma 5.12 with Long Term Support–the culmination of more than a year of work. It’s really awesome, and we think you’ll love it!

But how do you get it!?

It all depends on your distro! Let’s look at Linux distros today.

What makes a distro a distro?

Today it’s mostly the choice of release model. “Stable release” distros like Ubuntu and Linux Mint lock everything to a specific version, only offering feature upgrades only when a new major version of the distro is released. “Rolling release” distros like Arch and openSUSE Tumbleweed give you everything as close to the developers’ schedules as possible.

Each model has drawbacks:

  • Stable release distros will often saddle users with ancient, years-old software. For example, users of Debian Stable might not get to experience KDE Plasma 5.12 for another 2 or 3 years–or even longer.
  • Rolling release distros expose users to the latest version of everything, turning them into QA. Breakage is often fixed quickly, but users are exposed to it in the first place.

Certain distros additionally try to go beyond mere packaging and releasing, and actually try to ensure some QA and polish in the final product. Distros like Ubuntu, Linux Mint, Manjaro, and Elementary that follow this model quickly rocket up to the top of the popularity pyramid. Users are desperate for distros with better QA and polish!

But it’s exhausting; if you package all the software, you’re responsible for it too. It’s a huge job, even for distros that base themselves on others, as they find themselves having to patch on top of patches, and manage two release cycles (their own, the the parent distro’s). Turnover and burnout are common.

Flatpak and Snap to the rescue

Flatpack or Snap provide the solution: 3rd party packaging. Instead of the distros doing the packaging, it comes either straight from the developers, or from a 3rd-party intermediary like Flathub.

For distros, the benefits are enormous: liberated from the grunt work chores of packaging and patching software, distros will be free to step wholeheartedly into their natural roles as arbiters of the final user experience, concentrating on impactful tasks like integrating diverse components, managing hardware support, performing QA, polishing the final product, and delivering it to users in an easy-to access manner. Fixes patches can be submitted upstream, instead of duplicated locally. This is KDE’s relationship to Qt, in fact. It works great.

Snap and Flatpak also improve things for users and developers:

  • Users get to choose whether they want each app to be stable, up-to-date, or cutting-edge according to their preferences, and they get a clear chain of responsibility when there’s a bug.
  • Developers get to package their apps only once to make them available to everyone, and get to determine for themselves their software’s presentation, branding, and release schedule–rather than hoping that packagers for 500 different Linux distros do it for them, and then having to deal with bug reports about versions of their software that are years old.

Ultimately, Flatpak or Snap liberate us from the tyranny of low-quality distros that make Linux software look bad because they don’t do QA, integration, or UX testing to make sure that the final product is of high quality. Many will rightly vanish because they’re not providing much value for users or generating enough developer interest to continue existing. Once this happens, developers and users will gather around the smaller number of remaining distros, increasing each of their levels of manpower and user bases.

So no, distros don’t go away. In fact, the distros that are worth keeping will be able to focus on tasks that offer more value to users than mere software packaging. Far from erasing diversity, this will empower real and meaningful diversity–where we have a handful of really good and strongly differentiated distros whose products embody different philosophies, instead of an overwhelming number of mediocre distros with often only minimal differences, none of which really work well once you dig deeply. We’ll all win, and all of these vastly superior distros will be far stronger contenders when compared to Windows, macOS, and ChromeOS.

How you can help

There are many ways for you to help enter this brave new world of actual QA and polished products.

Users: If your favorite app offers a Flatpak or Snap version, use it! Quite a lot do. If you find problems, file bugs! If you find an app listing in KDE Discover or GNOME Software that doesn’t look good, submit better information! If you find cases where duplicate apps appear when browsing, submit patches to fix it!

Software developers: Provide high-quality AppStream metadata and please submit your apps to Flathub! This goes for KDE developers, too. Krita and Kdenlive are already up, but I want to see Dolphin, Konsole, Kate, and all the rest!

Distro developers: don’t fight Flatpak or Snap; embrace them (and Flathub) and liberate yourself from packaging chores. Focus less on packaging software for your users, and more on performing the QA necessary to make sure that that software actually works well.

As always, consider becoming a KDE contributor if you like what you see! We can’t do this without you.

Plasma 5.12 arrives in backport PPA for Kubuntu 17.10 Artful Aardvark

Tue, 2018/02/06 - 3:46pm

Users of Kubuntu 17.10 Artful Aardvark can now update to the newly released Plasma 5.12.0 via our backports PPA.

See the Plasma 5.12 release announcement and the release video below for more about the new features available.

To upgrade:

Add the following repository to your software sources list:

ppa:kubuntu-ppa/backports

or if it is already added, the updates should become available via your preferred update method.

The PPA can be added manually in the Konsole terminal with the command:

sudo add-apt-repository ppa:kubuntu-ppa/backports

and packages then updated with

sudo apt update
sudo apt full-upgrade

 

IMPORTANT

Please note that more bugfix releases are scheduled by KDE for Plasma 5.12, so while we feel these backports will be beneficial to enthusiastic adopters, users wanting to use a Plasma release with more stabilisation/bugfixes ‘baked in’ may find it advisable to stay with Plasma 5.10.5 as included in the original 17.10 Artful release. Likewise, users who already have Plasma 5.11.5 via the backports PPA can disable the PPA temporarily and wait for more updates before upgrading. KDE will release bugfix updates to Plasma 5.12 following a Fibonacci sequence of weeks since the last release (i.e. 1, 1, 2, 3, 5 etc week gaps) detailed in the Plasma release schedule.

Other upgrade notes:

~ The Kubuntu backports PPA includes various other backported applications, and KDE Frameworks 5.42, so please be aware that enabling the backports PPA for the 1st time and doing a full upgrade will result in a substantial amount of upgraded packages in addition to Plasma 5.12.

~ The PPA will also continue to receive bugfix updates to Plasma 5.12 when they become available, and further updated KDE applications.

~ While we believe that these packages represent a beneficial and stable update, please bear in mind that they have not been tested as comprehensively as those in the main Ubuntu archive, and are supported only on a limited and informal basis. Should any issues occur, please provide feedback on our mailing list [1], IRC [2], and/or file a bug against our PPA packages [3].

1. Kubuntu-devel mailing list: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
2. Kubuntu IRC channels: #kubuntu & #kubuntu-devel on irc.freenode.net
3. Kubuntu ppa bugs: https://bugs.launchpad.net/kubuntu-ppa

WikiToLearn migration, why?

Tue, 2018/02/06 - 1:19pm

Well, currently WikiToLearn runs on MediaWiki, which is a good model for dealing with an encyclopedia but, when you are trying to build a more structured content, it doesn’t fit.

For the release 1.0 we have developed CourseEditor, which tries to make the unstructured content more structured, for example offering a drag-and-drop UI to manage a course structure.

However, this isn’t enough: the issue with the MediaWiki data structure is that the versioning is only at the single page level, which is a good design for something that has little to none requirement of unambiguous references between pages, but it is a very big deal if you are talking about a course.

This is the main reason why we had to think about something new.

Because we need something new we have the opportunity to build something that make easier to add features, functions and capabilities, try new things without too much worry about the whole stack.

Thanks to a big support from GARR, we have access to a lot of computing power, not only in terms of raw CPU/RAM/Storage/Network but also in terms of number of servers (or VMs) and this means that we can build something distributed, and therefore having full tolerance and resilience.

The first thing that comes to mind in this scenario is: microservices! Microservices everywhere!

With containers, containers all around the place!

Yes, microservices, not in the “put a LAMP stack in docker” way of doing it, but with a proper stratified design.

MediaWiki is not designed with micro-services in mind and we have already mediawiki inside docker, we need to design your platform from scratch.

The first step for this ambitious project is the storage: we have to store the user data in a safe way, and this service is the critical one, the one that we can’t do wrong – there isn’t a second chance for doing it.

Now we are testing using Eve to store everything in an object storage with RESTful API, the backend at this time is MongoDB (with replication).

Now the very big issue is: how do we transform the MediaWiki data-structure in something with rigid internal references and course-wide versioning?

For this we used mongodb as temporary storage to work on the data and process every page to find and resolve every reference.

Now the migration is working quite well, it’s not done yet but we are confident that we can do the magic trick very soon.

Bye!

Sharing Files on Android or iOS from or with your Qt App – Part 3

Tue, 2018/02/06 - 10:53am

Welcome to Part 3 of my Blog series about Sharing Files to and from mobile Qt Apps.

Part 1 was about sharing Files or Content from your Qt App with native Android or iOS Apps, Part 2 explained HowTo share Files with your Qt App from other native Android Apps – this part now does the same from other native iOS Apps.

01_blog_overview

Some preliminary notes
  • Try it out: all sources are available at ⦁ GitHub
  • Android Permissions not checked in Example App: enable WRITE_EXTERNAL_STORAGE manually
  • Current Android release is for Target SDK 23 ! (Android 7 requires ⦁ FileProvider – wait for Blog Part 4)
  • All Use-Cases are implemented to be used x-platform – currently Android and iOS

If you‘re looking for an Android-only solution please also take a look at AndroidNative project.

Prepare iOS Info.plist

Similar to Android intent-filter in AndroidManifest.xml we must add some informations to Info.plist. If you haven‘t already done copy the Info.plist from your build directory into your project:

02_info_plist_in_project

Then add this into your .pro:

ios { ... QMAKE_INFO_PLIST = ios/Info.plist ... }

Open the Info.plist and insert these lines:

<key>CFBundleDocumentTypes <array> <dict> <key>CFBundleTypeName</key> <string>Generic File</string> <key>CFBundleTypeRole</key> <string>Viewer</string> <key>LSHandlerRank</key> <string>Alternate</string> <key>LSItemContentTypes</key> <array> <string>public.data</string> </array> </dict> </array>

See all the details from Apple Documentation „Registering File Types“.
Here‘s a short overview how the Types are organized:

03_uniform_type_identifiers

public.data is similar to MimeType */* we are using to filter Android Intents in our Example App.

After adding the lines to Info.plist our App will appear as a target App if Files or Attachments should be shared from other iOS Apps.

Fortunately iOS doesn‘t provide our own App as target if we want to share Files from our Example App with other iOS Apps.
Remember: On Android we had to create a custom Chooser to filter out our own App as target.

Get the incoming URL

The Files from other iOS Apps will be passed to the Qt App via application:openURL:

- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation

see also Apple documentation.

From Part 2 (Android implementation) you know that we have to wait until the Qt App is ready to handle the incoming URL and be able to emit a SIGNAL to QML UI.

We don‘t need this for iOS, because there‘s a Qt method we can use out of the box and grab the passed file url by registering QDesktopServices::setUrlHandler:

QDesktopServices::setUrlHandler("file", this, "handleFileUrlReceived");

This is easy to implement. We already have the IosShareUtils.mm class where we handle sharing Files to other Apps. Adding some lines of code:

IosShareUtils::IosShareUtils(QObject *parent) : PlatformShareUtils(parent) { QDesktopServices::setUrlHandler("file", this, "handleFileUrlReceived"); } void IosShareUtils::handleFileUrlReceived(const QUrl &url) { QString myUrl = url.toString(); // … remove "file://" from Url // … then check if File exists QFileInfo fileInfo = QFileInfo(myUrl); if(fileInfo.exists()) { emit fileUrlReceived(myUrl); } else { emit shareError(0, tr("File does not exist: %1").arg(myUrl)); } }

That‘s it &#55357;&#56898;

Thank You @taskfabric

Seems this is the first time I can tell you that there‘s easy stuff to manage Filesharing from Qt,
but I never would have found it out by myself. Didn‘t expected to take a look at QDesktopServices for sharing File URLs on Qt Mobile Apps.

Thanks to Thomas K. Fischer from Taskfabric.com who offered help at Qt Blog Comment
This is the real value of a great Qt Developer Community: Thomas appreciated my work on this sending me some lines of Code and pointing me to QDesktopServices. As a result it was easy for me to implement and publish the updated Sharing Example at Github.

Overview

Here‘s a short Overview about the iOS implementation:

04_handle_url_from_ios_apps

Test it!

Now it‘s a good point to test it.

Open „ekkes Share Example“ and navigate to one of the Tabs.

Open per ex. Apple Keynote App to share a File.

Here‘s the workflow from Apple Keynote App.
Tap on the SHARE Button:

05_keynote_share_01

Select „SEND COPY“:

06_keynote_share_02

„ekkes Share Example“ appears as Target:

07_keynote_share_03

Select ‚ekkes SHARE Example‘ and iOS will open the App. The App was already opened, so the current selected Page will be displayed and include a message about the received File.

08_keynote_share_04

So it works &#55357;&#56898;

No Qt Support for iOS Share Extensions

Attention: Sharing with a File URL works for all Apps providing Files or Attachments, but to handle Text or embedded Images shared from other Apps needs to be implemented with a “share extension”. See the details here.

Share Extensions are easy created using Xcode, but …
This is quite tricky to use with Qt, as the extension needs to be registered in Xcode and qmake overwrites the Xcode file on each run.

So Share (and other) Extensions cannot be included automatically while building from QtCreator and breaks workflows. See discussions https://bugreports.qt.io/browse/QTBUG-40101.

Hopefully Qbs will support this in the near future, because iOS App Extensions are an essential feature of iOS Apps in the meantime.

Some issues from Sharing Files to other Android Apps

Android: Sharing from Microsoft Word (and other MS Office Apps)

There are differences between Android 6 and Android 7 versions of MS Office Apps.

In both cases the Qt App received a SEND Action and a Content Url

MS Word:

content://com.microsoft.office.word.fileprovider/94161e0b-e48a-4142-9785-d0602d801e95/test.docx

Using QSharePathResolver.java class this File Url could be constructed:

/data/user/10/com.microsoft.office.word/files/tempOffice/Share/ff3251b4-c475-48e2-a7cc-f1df02d69874/test.docx

On Android 6 Devices the File Url could be opened and read without any problems from QFile – on Android 7 Devices I got a „File does not exist“ Error.

Other Apps using SEND Actions and Content Urls are working same on Android 6 or Android 7 Devices, so it‘s something special with MS Office Apps.

Testing some other ways to handle the File Url I found out that on Android 7 Devices for MS Word I can use InputStream for the given FileUrl. So I added an extra check for situations like this:

public class QShareActivity extends QtActivity { // ... public static native boolean checkFileExits(String url); } bool AndroidShareUtils::checkFileExits(const QString &url) { QString myUrl; if(url.startsWith("file://")) { myUrl= url.right(url.length()-7); } else { myUrl= url; } QFileInfo fileInfo = QFileInfo(myUrl); return fileInfo.exists(); } JNIEXPORT bool JNICALL Java_org_ekkescorner_examples_sharex_QShareActivity_checkFileExits(JNIEnv *env, jobject obj, jstring url) { const char *urlStr = env->GetStringUTFChars(url, NULL); Q_UNUSED (obj) bool exists = AndroidShareUtils::getInstance()->checkFileExits(urlStr); env->ReleaseStringUTFChars(url, urlStr); return exists; }

Android: Sharing from Google Docs App fails if Qt App is open

In Android Manifest the Launch Mode is declared as

android:launchMode="singleInstance" android:taskAffinity=""

SingleInstance is the only launchMode where always the same instance of our one and only Activity will be opened. This enables workflows where User already logged into an App and navigated to a Page and if shared from another App exactly this Page will be displayed.

This works well and you can test it from „ekkes Share Example“ App: Open the App, select a specific Tab (Page), then open another App and share a File with the Example App. Our Example will be opened exactly on the selected Page.

If the App was open, onNewIntent() from our customized Activity should be called, but Google Docs always calls onCreate() – doesn‘t matter if the Target App is already running or not. Then a white screen comes up, the App hangs and must be closed. The Debug Log reports:

E Qt JAVA : Surface 2 not found!

I haven‘t found a way to workaround this yet – perhaps anyone else has an idea HowTo fix ?

Have Fun

Now it‘s time to download current Version from Github, build and run the Sharing Example App.

Stay tuned for the next part where FileProvider will be added to share Files on Android.

The post Sharing Files on Android or iOS from or with your Qt App – Part 3 appeared first on Qt Blog.

Interview with Owly Owlet

Mon, 2018/02/05 - 8:00am

 

Could you tell us something about yourself?

Hello. I’m Maria, more often I use my nickname: Owly Owlet. I have a youtube channel, where I make video tutorials (in Russian) about how to use art software, mostly Krita.

Do you paint professionally, as a hobby artist, or both?

Art is my hobby, but I wish I could become a professional artist someday. For now there is much to be learned.

What genre(s) do you work in?

My art usually is more cartoony-like. I like fantasy world, fairy tales with medieval clothes, castles and magical creatures.

Whose work inspires you most — who are your role models as an artist?

There are so many incredible artists, whose art makes me want to learn and practice drawing more and more, it’s immensely hard to pick just a single one. But for now I really found of Andreas Rocha’s work. I also love the art style of David Revoy.

How and when did you get to try digital painting for the first time?

I’ve been drawing digitally since March 2017, so almost a year now. My husband gave me a tablet as a present for my birthday. Before that I drew with vector tools and a mouse a bit.

What makes you choose digital over traditional painting?

The freedom you have with digital art. With traditional painting you have to learn not only the basics of how to draw: perspective, light, color… You also have to learn how to work with different tools: pencils, markers, watercolor, acrylic paint, oil paint and so on. And it’s harder to fix your mistakes when you are just learning. And when you draw digitally, you have the magic of “Ctrl+Z” and layers. And besides that you can change the color scheme, mirror your image which makes way easier to identify and fix your proportion and color mistakes. You just have to find the software you are comfortable to paint with and you are good to go.

How did you find out about Krita?

It was Age of Asparagus’ “Krita meets Bob Ross” tutorials. They are awesome and really helped me to learn how to use Krita and not to be afraid of it. (https://www.youtube.com/channel/UCkKFLSJjYtKNdFy3P7Q-CAA)

What was your first impression?

Before Krita I used FireAlpaca a bit, which is fine software too, especially for a beginner. So, switching to Krita after FireAlpaca was a bit scary, you know that “so many buttons” kind of thing.

What do you love about Krita?

My favourite is the Assistant Tool, vanishing point and perspective. And I also love the dynamic brush and the quality of mixing brushes.

What do you think needs improvement in Krita? Is there anything that really annoys you?

That would be nice if Krita had not only Brightness/Contrast curve, but also contrast sliders, like those in Photoshop.

What sets Krita apart from the other tools that you use?

It has so many cool features and tools, so flexible when it comes to brush settings and working with color, and yet it’s free. Isn’t that amazing?

If you had to pick one favourite of all your work done in Krita so far, what would it be, and why?


I think this was the first one decent enough. When I drew it, I thought that I was finally getting somewhere.

What techniques and brushes did you use in it?

Most of the time for cartoony characters I use basic Krita brushes, just edit settings a bit. Airbrush_pressure for sketching and shading, Fill_circle for colouring, ink_ballpen for lineart, Basic_wet_soft for blending.

Where can people see more of your work?

My drawings on Deviantart: https://owlyowlet.deviantart.com/
My Krita tutorials (in Russian): https://www.youtube.com/c/СтудияСовятня

Anything else you’d like to share?

I wanted to say that I admire people who created Krita, who work on it, the developers, artists, translators, test engineers and other good people who make it possible for everyone to learn digital art with Krita. Thank you for all your hard work.

MongoDB for WikiToLearn migration

Sun, 2018/02/04 - 8:20pm

Hi!

Today i want to talk about my experience with the WikiToLearn migration.

The problem of every migration is getting your hands on the data in a way such that you can work on it.

Starting from the mysql backend and trying to have everything into a versioned object storage (python eve is the one we are tring now) is not an option.

The solution is to use a temporary database to keep the data, process the data in this temporary storage and afterwards uploading everything in the destination.

After some tries we managed to have the pipeline that reads all the MediaWiki pages, parses the structure and uploads everything in eve, using mongodb as a temporary storage.

But why mongo?

There are tons of databases and, after all, why use a dbms as temporary storage?

Well, the first thing is that mongodb is an implicit-schema dbms (there isn’t such thing as schema-less) and this is useful because you can add and remove fields at will without a full restructuration of the data-scheme and this can speed up quick hacks to test.

The point I want to make is that a DBMS is fast, you can try to build an in-memory representation of the data, I’ve tried, but it’s quite hard and quite slow or it’s another DBMS, so why not use an existing DBMS?

The next point is about persistence: when you have to work with a non trivial dataset, it is quite nice to be able to re-run only a part of the migration, as this speeds up the development.

Mongodb has also mongdump and mongorestore, which lets you snapshot everything and restore from a “checkpoint”.

I hope I’ve given you some good points to think about the next time you have to migrate from an old datastore to a new one.

Bye!

This week in Usability & Productivity, part 4

Sun, 2018/02/04 - 5:50am

This was a big week for Usability & Productivity. Before I get to the list of improvements we landed, I’d like to make an exciting announcement: we’re scoping out the work to add FUSE support to KIO for remote locations like Samba shares. This should vastly improve the experience of interacting with files on Samba and FTP locations (among others) when using non-KDE software with KDE Plasma. No timelines or promises yet, but it’s now on our radar screens.

Anyway, let’s move onto the list of improvements this week. I think you’re going to like ’em!

  • The panel’s height is now shown in pixels when being changed, and can be minutely adjusted using the scroll wheel (KDE bug 372364)
  • Y axis labels for the network widget’s speed graph no longer overlap with the grid lines (KDE Phabricator revision D10183):
  • Spectacle’s Save button now remembers the most recently used save mode by default (KDE Phabricator revision D10153)
  • Spectacle’s Save button now defaults to showing “Save As” instead of “Save & Exit” (KDE bug 389614)
  • Spectacle now uses the correct icon for the “Export Image…” button, and now it also shows up properly when using the Breeze Dark theme (KDE bug 389775):
  • Dolphin no longer scrolls so quickly in icons mode when there are icons with really long/tall filenames (KDE Phabricator revision D10102)
  • A huge amount of work went into improving the speed of move and copy operations, especially for many small files (KDE bug 342056, KDE Phabricator revisions D10155, D10256, D10261, and D10282). More is still in the pipeline, too.
  • You can now put Dolphin’s Terminal pane on any part of the window, not just the top or bottom (KDE bug 362593):
  • Gwenview’s file rename dialog now excludes the filename extension from the initial selection (KDE Phabricator revision D9632)
  • When using Gwenview in Full Screen mode, showing the sidebar no longer moves part of the top toolbar (including the “exit Full Screen” button) out of view (KDE bug 387784)
  • Hitting the Escape key now exits Full Screen mode in Gwenview (KDE bug 305659)
  • When Gwenview is quit while in Full Screen mode, it no longer re-opens maximized (KDE Phabricator revision D10207)
  • Gwenview now lets you choose the ICC color rendering intent, rather than hardcoding “Perceptual” (KDE bug 359909):
  • Konsole gained the ability to blur the background when the window is transparent (KDE bugs 198175):
  • The standard KWin blur effect has been made blurrier by default (the blur strength is still user-configurable) to offer better out-of-the-box readability for things that use it, like the Application Dashboard (KDE phabricator revision D10180):
  • Text input in KRunner now always works on Wayland (KDE bug 385693)
  • The close button on Okular’s pop-up note annotation now uses the correct cursor (KDE bug 384381):
  • New Breeze icon for Emacs and better icon for Virtualbox (KDE Phabricator revision D10211 and KDE bug 384357):
  • Kate/KDevelop syntax highlighting now displays correctly for numeric literals with underscores in Python (KDE big 385422)
  • KSysGuard tabs now correctly show ampersand (&) characters (KDE bug 382512)
  • Many bug fixes for Discover

Yes folks, all of this happened in ONE WEEK! The volume of contributions is starting to accelerate, and we’re really firing on all cylinders these days. It’s the perfect time to get involved. You don’t need to be a programmer. We’ve got design tasks, bug triaging, promotion, the works! We’re aware that our wiki is a bit scattered and sparse, and we’re working on cleaning that up, too. Since it’s a wiki, please feel free to make improvements!

And there’s more coming, too. I wasn’t able to mention in this week’s status update quite a few exciting fixes that are still going through the review process.

This is an exciting time to be a KDE user or contributor. Feel the energy. Be part of something big. Cynicism and inactivity are easy, but ultimately not satisfying; this is the moment to rise above the pervasive malaise of our time. Climb aboard, and help us build something truly magnificent.

Kraft Moving to KDE Frameworks: Beta Release!

Sat, 2018/02/03 - 2:08pm

Kraft LogoKraft is KDE/Qt based desktop software to manage documents like quotes and invoices in the small business. It focuses on ease of use through an intuitive GUI, a well chosen feature set and ensures privacy by keeping data local.

Kraft is around for more than twelve years, but it has been a little quiet recently. However, Kraft is alive and kicking!

I am very happy to announce the first public beta version of Kraft V. 0.80, the first Kraft version that is based on KDE Frameworks 5 and Qt 5.x.

It did not only go through the process of being ported to Qt5/KF5, but I also took the opportunity to refactor and tackle a lot of issues that Kraft was suffering from in the past.

Here are a few examples, a full changelog will follow:

  • Akonadi dependency: Earlier Kraft versions had a hard dependency on Akonadi, because it uses the KDE Addressbook to manage customer addresses. Without having Akonadi up and running, Kraft was not functional. People who were testing Kraft without having Akonadi up were walking away with a bad impression of Kraft.

    Because Akonadi and the KDE contacts integration is perfect for this use case, it still the way to go for Kraft, and I am delighted to build on such strong shoulders. But Kraft now also works without Akonadi. Users get a warning, that the full address book integration is not available, but can enter addresses manually and continue to create documents with Kraft. It remains fully functional.

    Also, a better abstraction of the Akonadi-based functionality in Kraft eases porting to platforms where other system address books are available, such as MacOSX.

  • AppImage: The new Kraft is available as AppImage.

    There was a lot of feedback that people could not test Kraft, because it was hard to set up or compile, and dependency are missing. The major Linux distributions seem to be unable to keep up with current versions of leaf packages like Kraft, and I can not do that for the huge variety of distros. So AppImage as container format for GUI applications seems to be a perfect fit here.

  • A lot more was done. Kraft got simplifications in both the code base and the
    functionality, careful gui changes, and a decreased dependency stack. You should check it out!

Today (on FOSDEM weekend, which could be a better date?) the pre version 0.80 beta10 is announced to the public.

I would appreciate if people test and report bugs at Github: That is where the development is currently happening.

The future, the past and FOSDEM

Fri, 2018/02/02 - 10:30pm

Long time no see, something had happened for sure. So let’s begin with that.

The past

My last post was from 25th August 2017. It was about my GSoC project and how I was preparing the final patch set, that would then be posted to the xorg-devel mailing list.

That’s quite some time ago and I also didn’t follow up on what exactly happened now with the patch set.

Regarding the long pause in communication, it was because of my Master’s thesis in mathematics. I finished it in December and the title is “Vertex-edge graphs of hypersimplices: combinatorics and realizations”.

While the thesis was a lot of work, I’m very happy with the result. I found a relatively intuitive approach to hypersimplices describing them as geometric objects and in the context of graph theory. I even wrote a small application that calculates certain properties of arbitrary hypersimplices and depicts their spectral representations up to the fourth dimension with Qt3D.

I’m currently waiting for my grade, but besides that my somewhat long student career suddenly came to an end.

Regarding my patch set: It did not get merged directly, but I got some valuable feedback from experienced Xserver devs back then. Of course I didn’t want to give up on them, but I had to first work on my thesis and I planned to rework the patches once the thesis was handed in.

At this time I also watched some of the videos from XDC2017 and was happyily surprised that my mentor, Daniel Stone said that he wants my GSoC work in the next Xserver release. His trust in my work really motivated me. I had also some contact to Intel devs, who said that they look forward to my project being merged.

So after I handed in my thesis, I first was working on some other stuff and also needed some time off after the exhausting thesis end phase, but in the last two weeks I reworked my patches and posted a new patch set to the mailing list. I hope this patch set can be accepted in the upcoming Xserver 1.20 release.

The future

I already knew for a prolonged time, that after my master’s degree in mathematics I wanted to leave university and not go for a scientific career. The first reason for this was, that after 10 years of study, most of the time with very abstract topics, I just wanted to interact with some real world problems again. And in retrospective I always was most motivated in my studies when I could connect abstract theory with practical problems in social science or engineering.

Since computers were a passion of mine already at a young age, the currently most interesting techonological achievements happen in the digital field and it is somewhat near to the work of a mathematician, I decided to go into this direction.

I had participated in some programming courses through my studies - and in one semester break created a Pong clone in Java for mobile phones being operated by phone movement; it was fun but will forever remain in the depths of one of my old hard disks somewhere - but I had to learn much more if I wanted to work on interesting projects.

In order build up my own experience pretty exactly two years ago I picked a well-known open-source project, which I found interesting for several reasons, to work on. Of course first I did baby steps, but later on I could accelerate.

So while writing the last paragraph it became apparent to me, that indeed this all was still describing the past. But to know where you’re heading, you need to know where you’re coming from, bla, bla. Anyways finally looking forward I now have the great opportunity to work full-time on KDE technology thanks to Blue Systems.

This foremost means to me to help Martin with the remaining tasks for making Plasma Wayland the new default. I will also work on some ARM devices, what in particular means being more exposed to kernel development. That sounds interesting!

Finally with my GSoC project, I already have some experience working on an upstream freedesktop.org project. So another goal for me is to foster the relationship of the Plasma project with upstream graphics development by contributing code and feedback. In comparision to GNOME we were a bit underrepresented in this regard, most of all through financial constraints of course.

Another topic, more long-term, that I’m personally interested in, is KWin as a VR/AR platform. I imagine possible applications kind of like Google tried it with their Glass project. Just as a full desktop experience with multiple application windows floating in front of you. Basically like in every other science fiction movie up to date. But yeah, first our Wayland session, then the future.

The FOSDEM

Writing these lines I’m sitting in a train to Brussels. So if you want to meet up and talk about anything, you will presumably often find me the next two days at the KDE booth or on Saturday in the graphics devroom. But this is my first time at FOSDEM, so maybe I’ll just stand somewhere in between and am not able to orientate myself anymore. In this case please lead me back to the KDE booth. Thanks in advance and I look forward to meeting you and other interesting people in the next two days at FOSDEM.

Ceph Day Germany 2018 - Update

Fri, 2018/02/02 - 10:26pm
The German Ceph Day 2018 in Darmstadt is finally only a few days away (07. February 2018).
The agenda is now complete. There are 13 talks and a short Q&A session planed during the day. 
Already 150 attendees signed up and due to the support of our latest sponsor Intel we now are able to host for up to 175 interested members of the big Ceph community. There are only a limited number of tickets left, be quick to register for one while they are still available.

I would like to give already a big thanks to the Ceph community team, all sponsors (SUSE, Deutsche Telekom AG, Tallence AG, SAP, 42on.com, Red Hat, Starline), speakers and supporters which make this event possible. 

Some information if you attend: 

  • The location is at T-Online-Allee 1, 64295 Darmstadt. The entrance to the building is here. Please check this page for directions, traffic, parking and hotel information.
  • The registration will be open from 8:15am on. Please register at eventbrite so that we can be sure that you get a security badge to access the venue. In case the Ceph Day registration desk is closed, get you security badge from the front desk and refer to the Ceph Day in the Forum. You will get you name tag and goodies during the next break.
See you in Darmstadt! Enjoy the Ceph Day!

This week in Discover, part 4

Fri, 2018/02/02 - 9:55pm

In preparation for the impending release of Plasma 5.12, this was a big bug-squashing week in Discover thanks to lead Developer Aleix Pol, who knocked out a huge number of reliability and stability issues in Discover! We also got in a few UI polish and usability improvements, too.

  • The number of available updates is now always consistent (KDE bug 389108)
  • Update notifications are no longer shown twice in certain circumstances (KDE bug 389429)
  • Fixed a crash when opening Discover with the Flatpak backend installed, but without the system Flatpak libraries (KDE bug 380496)
  • Fixed a crash while searching (KDE bug 385679)
  • Fixed a regression where the screenshot overlay would lose keyboard focus (KDE bug 389510)
  • Fixed a memory leak when browsing the Plasma Addons category (KDE bug 387630)
  • Made the Reviews pop-up have less side padding for better readability and usability (KDE bug 389536)
  • The scrollbar on the settings page no longer overlaps interactive UI elements (KDE bug 389602)
  • Repo list items no longer expose redundant Filter buttons (KDE bug 389767)
  • Discover’s settings page displays repos in a much more usable and readable manner (KDE bugs 389714 and 389715):

 
“Xenial (Main)” being listed twice is a bug we’re working on; the second one is the source repository, but it doesn’t communicate that. Little by little!

It’s constant improvement like this that adds up over time to produce great software. We think you’re going to love Discover in Plasma 5.12, and we’re continuing to work on making it even better!

If you like what you see, please consider helping out! If we were pirates, we’d say, “yer money or yer time, yarr!”

Elisa 0.0.81 Released

Fri, 2018/02/02 - 5:32pm

The Elisa team is happy to announce the second alpha release of the Elisa music player.

When building this release we have worked on our vision for the Elisa music player:

  • Elisa is a music player developed by the KDE community that strives to be simple and nice to use. We also recognize that we need a flexible product to account for the different workflows and use-cases of our users.
  • We focus on a very good integration with the Plasma desktop of the KDE community without compromising the support for other platforms (other Linux desktop environments, Windows and Android).
  • We are creating a reliable product that is a joy to use and respects our
    users privacy. As such, we will prefer to support online services where
    users are in control of their data.

We also want to align with the KDE wide goals that have been chosen by the whole community. Since the last release we updated our community wiki page and cleaned some cruft accumulated from the very early time of the development to lower the barrier for new people willing to join the development.

The user interface was further tuned for a smooth experience. Several issues with dark themes were fixed and the appearance of the buttons and sliders were slightly altered to improve their readability.

Screenshot_20180202_172327Elisa with Breeze Dark color theme

We also worked on improving the performance with a focus on the Elisa files indexer. We still recommend to use baloo when possible because the experience is better.

We added the possibility to directly open a music track from a file browser in Elisa or by specifying files as command line options. This is the first step to add support for browsing your music directories directly from Elisa.

Support for reading and writing m3u playlist has been added. There is one know issue when opening playlist with track file names including non ascii characters.

Screenshot_20180202_172839

 

Finally, Elisa is know able to show you the metadata of your tracks and extending the set of supported metadata is an ongoing work.

Screenshot_20180202_173256

We hope you will enjoy this release as much as we enjoyed building it.

This version is available from KDE servers.

There are binary packages available from Neon, arch and Fedora Linux distributions. KDE provides automatic builds of flatpak packages for Elisa (it may not be always up to date). You can follow KDE wide documentation (the package name is org.kde.elisa) . A Windows setup is also provided from the Craft and binary-factory teams (binary-factory).

Pair programming with git

Fri, 2018/02/02 - 5:01pm
Git is great. It took the crown of version control systems in just a few years. Baked into the git model is that each commit has a committer and one author. Ofen this is the same person. What if there is more than one author for a commit? This is the case with pair programming or with mob programming or with any other way of collaboration where code is produced by more than one person. I talked about this at the git-merge conference last year. There are some workarounds but there is no native support in git yet.

It seems that the predominant convention to express multi-authorship in git commits is to add a Co-authored-by entry in the commit message as a so-called trailer. This adds more flexibility than trying to tweak the author and committer fields and is quite widely accepted, especially by the git community.

I'm happy that GitHub added support for the Co-authored-by convention now. It makes multi-authorship more visible. That's a good thing.

I did some work on adding native support for multiple authors in git. The direct approach of allowing more than one author field might be too intrusive due to the many possible side effects. But the Co-authored-by trailer is still a good solution. I have an unfinished patch to add some native support for that in git. It does need some more work, though.

Contributing to git is an interesting experience. The git mailing list is the central place. The contribution workflow is well-documented. It's good that Junio as maintainer has spelled out how he reviews patches and what that means for contributors. And it's definitely fun to work on a self-contained C project.

I'm looking forward to more multi-author support in git and GitHub. Pair-programming is a great model, and properly reflecting in the commit logs what happened when the code was written is the right thing to do.

Plasma Vault: Update on CryFS

Fri, 2018/02/02 - 12:41pm

Just a short update on the CryFS situation I mentioned a few days ago.

I was contacted by Sebastian (the maintainer of CryFS) and he said he has been actively working on the solution to the upgrading problem.

He has already implemented quite a few things that will be useful for Plasma Vault, and I will make the CryFS backend default again in Plasma 5.13 (after the LTS release) if these updates get released and packaged by the most popular distributions.

The main changes so far include automatic filesystem upgrades and error reporting through error codes. This will allow Plasma Vault to know exactly why opening a vault has failed to be able to properly communicate it through the UI.

It is awesome how the free/libre open source community sometimes works. :)


Read more...

How do I test Plasma Mobile? (part 2)

Fri, 2018/02/02 - 10:06am

The first part of this series focused on testing Plasma Mobile on virtual machine and/or on a PC/laptop. In this second part we will focus on testing Plasma Mobile on actual mobile devices.

Currently there are two possible ways of testing Plasma Mobile on an actual mobile device,

  • Using postmarketOS
  • Installing Halium and a KDE neon-based rootfs

I will explain both methods briefly in this blog post. Note that some of these steps may involve getting device-specific sources and building them manually, This may require a intermediate knowledge of how to unlock the bootloader, flashing and restoring devices and basic knowledge about various UNIX/Linux commands.

Using postmarketOS

postmarketOS is touch-optimized, pre-configured Alpine Linux-based distribution which offers Plasma Mobile as one choice of several available user interfaces.

There is a list of the devices that can run postmarketOS, and you can find instructions on installing postmarketOS on your device at their wiki page.

When you follow the instructions to install postmarketOS, remember to select “plasma-mobile” as the user interface when asked:

Available user interfaces (5): * none: No graphical environment * hildon: (X11) Lightweight GTK+2 UI (optimized for single-touch touchscreens) * luna: (Wayland) webOS UI, ported from the LuneOS project (Not working yet) * plasma-mobile: (Wayland) Mobile variant of KDE Plasma, optimized for touchscreen * weston: (Wayland) Reference compositor (demo, not a phone interface) * xfce4: (X11) Lightweight GTK+2 desktop (stylus recommended) User interface [weston]: plasma-mobile

An important thing to note about postmarketOS is that it also offers Plasma Mobile on devices running mainline kernel, for example on the Sony Xperia Z2 tablet, Google Nexus 7 (2013), and LG Nexus 5 (partially). More information about Plasma Mobile on postmarketOS project can be found at the Plasma Mobile wiki entry.

Video below shows Plasma Mobile running on the Sony Xperia Z2 Tablet, which is running on mainline kernel instead of the pre-installed older kernel version.

However note that the postmarketOS project is still at very early stages of development and is not suitable for most end users yet.

Installing Halium and a KDE neon-based rootfs

Various devices running Plasma Mobile

Halium provides the minimal android layer that allows a non-Android graphical environment to interact with the underlying Android kernel and access the hardware. The Plasma Mobile team provides a Neon-based rootfs which can be used along with the Halium builds. Currently Halium has been ported to multiple devices, however, binary builds are not provided because most of them include binary blobs which we cannot redistribute them legally. Instead we provide a link to the source manifest and you can use that to build your own images. Documentation on how to build and install Halium is available at the Halium website.

Plasma Mobile on Nexus 5 and Nexus 5X is using the Halium based images, binary images for those are distributed at Plasma Mobile image server as a reference for other porters and developers for easy testing. You can install on those devices using the flashtool available on Github.

AtCore 1.0.0 Release.

Thu, 2018/02/01 - 12:35pm

Today I would like to announce the release of AtCore 1.0.0. This is the first stable release for AtCore. Since its the first release and we have not written a “real” client for it yet we include our test GUI. If you own a 3D Printer you are encouraged to try AtCore for at least one print job.

GET IT!!

Source Code

Linux

Windows

OsX

Using AtCore Test GUI

Using the AtCore test gui is really easy for Linux you only need to make the AppImage executable then run it, On OsX you run the .app file and for Windows run AtCoreTest.exe. To do anything in the application you must first connect to a printer. Use the connection tab in the top area left area of the window. Select your Device and Baud then click connect. If for some reason your firmware is not able to be autodetected or you wish to speed the connection up you can select your firmware from the drop down list. If you don’t know what firmware you have try using repetier. You can find more information on the Test Gui if you view its User Guide. If you are intrested in hacking on/with AtCore you may want to check the Api Docsumentation.

Known Issues
  • The test gui’s log will show an extra set of I/O for each connect/ disconnect you have done while its running (fixed)
  • If your printer does not restart upon connection with AtCore then AtCore will not send the firmware request correctly. If this affects you just select your firmware plugin from the list, or send the command M115 from the command tab.

Be sure to Report Bugs that you might find.

 

Write-up for SoK Project – OpenQA Plasma Mobile

Thu, 2018/02/01 - 10:12am

KDE Goal: Usability and Productivity proposed by Nate Graham, is one of the three goals selected by KDE. This goal will focus on polishing our basic software so everyone will be delighted to use it. One of important aspect of Usability and Productivity is focus on quality assurance.

In this Season of KDE (SoK) 2018, I am working on “OpenQA Plasma Mobile” project. This project indirectly helps to achieve the goal of Usability and Productivity as it would work to get the higher quality version of the mobile by creating integration testing for it. It would make it easier to test the common operations of the mobile.

In these few weeks with the help of my mentor Bhushan Shah I have implemented the following:

  •  Test of checking wayland session.

    sddm-wayland-session

  • Test of checking initial phone session.

    Plasma-mobile-start

  • Test of opening dialer application.

    plasma-mobile-dialer

The work done can be found at : https://github.com/bdhruve/kde-os-autoinst/tree/openqa-plasma-mobile

In the upcoming weeks, I will add the tests for more features of Plasma Mobile shell as well as other applications in Plasma Mobile.

Calligra 3.1.0 released

Thu, 2018/02/01 - 7:54am

We are pleased to announce the release of Calligra 3.1.0 with the following apps included:
Words, Sheets, Karbon, Gemini, and Plan.

Note that Gemini, the KDE Office suite for 2-in-1 devices, is back after missing from the initial Calligra 3.0 release.

Also note that Kexi, the visual database applications creator is close to release 3.1.0.
See http://www.kexi-project.org.

The following is a list of new features and bug fixes since the last release (3.0.1).

Common:

  • Picture shape tool: Paint crop rectangle and its handles with 1px wide outline. (BUG: 388930)
    Due to the painter scaling the pen width (1 by default) was scaled too, which caused the outlines to cover the whole image.
  • Textlayout: Do not enter infinite loop when line rect is not valid.
  • Add RTF support to Okular. (BUG: 339835)

Sheets:

  • LaTeX export: Fix typo in UI string. (BUG: 380030)

Plan:

  •  Add dialog to be able to edit multiple tasks at once. (BUG: 310937)
  •  Provide expand all/collapse all in context menu. (BUG: 313606)
    Expands/collapses selected item(s) and all children.
    Retains the treeviews expanded rows across operations.
  •  Printing: Make changes to page layout persistent. (BUG: 385084)
  •  Open Document Text format report generator added.
    Adds the abillity to generate reports in odt format directly.
    Reports can be viewed using an odt viewer like Calligra Words or LibreOffice Writer. Report templates are also in odt format and can be designed using e.g Words or Writer.
  • Add support for sharing resources in multiple projects.
  • Improved context help and documentation.
  • Add support for automatic holidays generation.
  • Calendar view: Handle context menus with no calendar.
  • Replace the file centric startup page with page more suitable for projects.
  • Add editing and reloading of task modules.
  • Gantt view: Fix possible crash when deleting gantt view with large projects.
  • Gantt view: Fix issue with task dependencies not cleared in certain situations.
  • Fix undo/redo issue with modifying project target times.
  • Fix potential crash in Cost Breakdown View.
  • Fix potential crash when creating new project from current project.
  • Fix performance issue in chart view.
  • Note: Support for scripting is discontinued and reports using KReport is not supported in this release.

Gemini:

  • Port to KDE Frameworks 5
  • Port the welcome screen to Kirigami
  • Port to using the Qt Quick 2 based Calligra components (based on work done for Jolla Documents)
  • Port to using libgit2 directly for git support (as the Qt support library has become unmaintained)
  • Fix template support

Pages