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

Videos on Samba shares

Wed, 2018/01/17 - 5:06pm

A longstanding complaint about KDE Plasma is that it’s a pain in the butt to stream videos that are located on Samba shares. It’s a usability issue for sure. I’d like to talk a bit about the origins of the problem and how I helped drive a solution.

Background

For KDE Plasma and apps, the KIO framework is responsible for file access and I/O–including files on Samba shares. Software that uses KIO gets this for free; for other software, KIO can either download the file locally before giving it to the program, or else give the program a Samba URL (e.g. smb://share/path/to/file.avi) and let the program figure out what to do.

KDE does have a KIO-aware video player that could do the job: DragonPlayer. Unfortunately, it’s not actively developed, and a bug prevents this from working.

That leaves 3rd party software, like VLC and MPV. These two don’t use KIO, but they do have Samba clients built in, so they’re able to handle the Samba URLs that KIO gives them!

The problem

…Unless the share is password-protected. In this case, the password must be added to the URL, like this: smb://user:password@share/path/to/file.avi. KIO won’t do that because tossing around user passwords in plaintext is an obvious security problem. So it’s up to the video players to either ask the user for the password to the Samba share, or look it up in the user’s KWallet.

The solution

Ideally, KIO would mount remote locations like Samba shares to a local path using FUSE, and then provide that path to non-KDE apps, which is what GNOME’s GVFs does (and why it works without drama in most GTK-based desktop environments). This would let any video player work with with no modifications, but that’s a task I’m not qualified to tackle, so I decided to attack the problem from another angle: make the most popular video players integrate with KWallet so they can prompt for the password and store it in the user’s wallet.

Unfortunately (but understandably), the MPV developers denied the request. But the VLC developers didn’t, and actually implemented KWallet support in VLC 3.0! But when I tested it using nightly builds of VLC 3.0, I found that it didn’t work, and had even regressed from version 2.

Apparently I was the first person to test the feature in VLC 3.0 beta builds. The VLC developers were a joy to work with, and soon enough, both issues were resolved! I re-tested with later builds and verified the fixes.

Behold, the power of QA!

Once VLC 3.0 is out, KDE Plasma users should be able to play videos located on Samba shares accessed with Dolphin. The first time you do it, VLC will ask you for the Samba share’s password:

After that, VLC will look up the password in your KWallet and you’ll never need to think about it ever again.

Lessons learned

QA is important. If people don’t test features, apps could ship broken.

Users like us are the QA. Most Linux software is not developed and sold commercially, and even distros with commercial backing do not have the resources to test most pre-release software. If we don’t test beta versions of our favorite software, we’ll end up doing it after the release once users are disappointed by bugs and broken features.

The easier you make it to test pre-release builds, the more people will do it and the better your volunteer QA will be. All of this was made possible because the VLC developers provide an Ubuntu PPA with nightly builds, so testing pre-release versions was easy and painless. This is great for Ubuntu users like me, but what about users of Debian, Arch, openSUSE, Fedora, or distros based on them? Had I been one of those users, I probably would have given up on doing this kind of testing.

This is why our work in Discover to make it easy to switch app versions is so important for the future. When every app has beta builds available with only a few clicks in a centralized location with a consistent interface, any user can easily become a beta tester.

Like what you see? Please consider testing beta builds of your favorite software and filing high-quality bugs if you find any issues–even ones that seem so obvious that you can’t imagine that the developers could have missed them. They might only be obvious on your hardware or with your use case! We may not pay for most of our software with money, but that just means developers need our time instead. The price of freedom is eternal QA.

A Fistful of Ports Updates

Wed, 2018/01/17 - 9:14am

Here’s a list of KDE-related stuff (mostly official FreeBSD ports) the KDE-FreeBSD team handled recently. You could call it “a week in the life of some packagers”, packagers who are also otherwise busy with $work-work.

  • Updated otter-browser (a Qt webengine-based browser) to latest version 0.9.94
  • Added a GTK QPA
  • Updated latte-dock to latest released version 0.7.3
  • Clang6 fixes to older KDE and Qt software (out favorite #define nullptr NULL)
  • Reworked packaging of Qt 5.9 to fix a broken (generated) qconfig.h

And in area51, the unofficial ports tree where we do preparatory work (use the branch kde5-import, which supercedes the plasma5 branch; this one contains the current plan for adding Plasma5 to the ports tree and updating all the KDE Applications), we’ve also got:

  • Updated digikam to 5.8
  • Updated KDE Frameworks to 5.42 (this is waiting on an exp-run to move to official ports)
  • Improved powerdevil backend, thanks to Henry Hu
  • Added plasma5-browser-integration
  • Support Qt4 on aarch64, thanks to Fedora

As usual: you can run a full modern KDE desktop system with Plasma 5 and KDE Applications, from the area51 repository, from the kde5-import branch; official ports have the latest Qt and KDE Frameworks, but not the desktop.

CIP related work during the second half of 2017

Tue, 2018/01/16 - 10:00pm

As you probably know by now, I have been involved in the Civil Infrastructure Project (CIP), a Linux Foundation Initiative formed in 2016, representing Codethink, a founder Member and coordinating the engineering work in two areas within the project:

  • CIP Kernel maintenance
  • Testing strategy and kernel testing tooling.

In the first front, Ben Hutchings, the Debian Kernel maintainer, a colleague at Codehtink, has been labelled as CIP Kernel maintainer until August 2018. Ben has released in December the latest version of the CIP Kernel 4.4.105-cip15 Currently he is working on releasing a new version, including fixes for Meltdown.CIP Initiative logo

During 2017 until a little after ELCE, I have worked on defining the testing strategy for the CIP kernel and coordinating the efforts towards creating a tool to test it, based on kernelci.org. Robert Marshall has been leading the technical efforts the last few months. The tools was finally called Board at Desk (B@D). Some days before ELCE 2017 CIP released first version of the tool, which is nothing but an integration in a VM of the kernelci.org infrastructure that allow testers to test kernels locally in a board connected directly to their machines. There is no need for a remote centralised infrastructure to collect, process and visualise the results. You can read more about it in the B@D 1.0 Release announcement.

A lot of the work my colleagues and I did for CIP got its visualization at the Embedded Linux Conference Europe 2017, that took place in Prague during the third week of October. A couple of articles summarise the activity:

Codethink’s involvement the last few weeks of 2017 and the beginning of 2018 is reduced to the CIP kernel maintenance so in parallel, I have also reduced my involvement to focus more in customer’s work. I plan to attend to the Open Source Summit Japan 2018 to support again CIP activities.

If you are interested in following the work the CIP is doing to bring Linux based systems to Industrial Grade products, I recommend you join the cip-dev mailing list. You can read a previous post I wrote about my CIP related activity.

KWin/X11 is feature frozen

Tue, 2018/01/16 - 5:08pm

Yesterday the KDE Community released the Beta for Plasma 5.12 LTS. With that release the feature freeze for 5.12 is in place and also an eternal feature freeze for KWin/X11. To quote the release announcement: “5.12 is the last release which sees feature development in KWin on X11. With 5.13 onwards only new features relevant to Wayland are going to be added.” This raised quite some questions, concerns and misunderstandings in the social networks. With this blog post I try to address those question and explain why this change in policy is done.

Is KWin/X11 still maintained?

Yes! We are just in the process of releasing an LTS. Of course KWin is fully maintained in the LTS life time. While in 5.8 only X11 was maintained, now we are able to offer maintenance for both X11 and Wayland. For the maintenance we do not differentiate between windowing systems.

Will X11 bugs still be fixed?

As X11 is under maintenance, I expect bugs to still get fixed.

Does this mean that in 5.13 X11 will be unmaintained?

We are going to forward port bug fixes from the 5.12 branch to master. Thus any release after 5.12 will get all bug fixes from 5.12. Given that I would say 5.13 will also be maintained on X11.

Does this mean that in the next LTS X11 will be unmaintained?

We will decide when the time comes. Currently I do not expect that we would drop maintenance.

Does this mean Plasma 5.13 will default to Wayland?

This is about feature freeze for X11. Whether Wayland will be the default or not is completely unrelated to this.

Will X11 users not get any new features in KWin?

Of course there will be new features! Most functionality in KWin is independent of the windowing system. Any improvement to those areas benefit Wayland and X11 users. Currently we have a few improvements in the pipeline, for example tooltips on decoration buttons, improved blur effect, a rework of slide desktop effect, improvements to the cube effect and a few more. All of them will be available to both X11 and Wayland users.

How do you decide whether it’s an X11 only feature?

In the case of KWin this is very simple. There are areas in our code structure which are only get pulled in if run on X11, other areas are marked in an if (x11) section. If the new feature touches this code, it’s probably not going to be added.

Does this feature freeze also apply to other KDE software?

No, but personally I would recommend any maintainer to apply a similar feature freeze. I personally will not help developing any X11 specific feature any more and resigned as maintainer of various X11 specific frameworks this week.

What are you going to do if someone present a feature for X11?

It won’t be merged.

But why?

This requires a little bit more explanation. I had a look at the most prominent issues we had over the last years. Where are our stability problems, where are our quality problems, what costs most development time? I observed that it was always in new features specific to X11. Very often even for features we added to Wayland without causing problems.

So I started to look into why that’s so. The obvious answer that we don’t get bugs for Wayland because nobody uses is, is not the case. We get many bug reports for Wayland and many users are nowadays running Wayland. So the reason must be somewhere else.

On Wayland we are able to test the code. Let’s take an example: we get input events through libinput. For this we have unit tests through mocking. Thus we can automate the testing of the lowest layer. From libinput events are sent into KWin core through an internal API and that we can also use in the integration tests. So we can simulate everything from the point where libinput events would hit KWin core. We can test this properly, we know that we get all events (because KWin is the display manager) and we can test every aspect. We can lock the screen and verify how it works, we can make applications grab the pointer or keyboard and test this. We can invoke global shortcuts, etc. etc. It’s all just as if we get the events through libinput. The quality of these new areas in KWin feels really good.

A few weeks ago some commits I did hit the Linux media about KWin/Wayland without X11 starting too fast and due to that causing bugs. These issues were found through our test suite, before any user would ever be exposed to them.

What we did in the past was taking these new features and bring them to X11. But there we cannot test. There is no way on X11 to e.g. fake a touch screen. On X11 we cannot test how this behaves if we lock the screen or used Alt+Tab. We can write the code and manually test it. Hey it works, awesome! But that was mostly not the case. There were corner cases which caused trouble. And to this comes that the main devs run Wayland instead of X11. If features break they are not exposed to the bugs.

Could you give some examples of things that broke?

Sure! The first feature we backported to X11 was “modifier only shortcut”. We spent months fixing the fallout because of X11 weirdness. Another feature backported was panels on shared screen edges. It worked great for Wayland, but on X11 some corner cases were overseen and caused issues, which affected our users and required time to fix. We backported the touch screen swipe gesture on X11 which was a mess. On X11 touch screens are also mouse events, that made it difficult and created many corner cases.

The problem is not adding the feature. The problem is fixing the bugs created by the new features.

But if a new foo requires adjustments?

KWin won’t be adjusted to any new requirements in the XServer, Mesa, input stack, proprietary drivers, etc. If something breaks it’s the fault of those components which broke it.

Plasma 5.12 LTS beta available in PPA for testing on Artful & Bionic

Tue, 2018/01/16 - 4:21pm

Adventurous users, testers and developers running Artful 17.10 or our development release Bionic 18.04 can now test the beta version of Plasma 5.12 LTS.

An upgrade to the required Frameworks 5.42 is also provided.

As with previous betas, this is experimental and is only suggested for people who are prepared for possible bugs and breakages.

In addition, please be prepared to use ppa-purge to revert changes, should the need arise at some point.

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

If you want to test then:

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

and then update packages with

sudo apt update
sudo apt full-upgrade

A Wayland session can be made available at the SDDM login screen by installing the package plasma-workspace-wayland. Please note the information on Wayland sessions in the KDE announcement.

Note: Due to Launchpad builder downtime and maintenance due to Meltdown/Spectre fixes, limiting us to amd64/i386 architectures, these builds may be superseded with a rebuild once the builders are back to normal availability.

The primary purpose of this PPA is to assist testing for bugs and quality of the upcoming final Plasma 5.12 LTS release, due for release by KDE on 6th Febuary.

It is anticipated that Kubuntu Bionic Beaver 18.04 LTS will ship with Plasma 5.12.4, the latest point release of 5.12 LTS available at release date.

Bug reports on the beta itself should be reported to bugs.kde.org.

Packaging bugs can be reported as normal to: Kubuntu PPA bugs: https://bugs.launchpad.net/kubuntu-ppa

Should any issues occur, please provide feedback on our mailing lists [1] or IRC [2]

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

This week in Discover

Tue, 2018/01/16 - 2:09pm

I guess I’m becoming a Discover developer, since it’s where I seem to spend most of my time these days. It’s just so darn fun since the lead Developer Aleix Pol is super easy to work with, there’s a lot of low-hanging fruit, and with Kirigami, it’s very simple to make consequential changes even when you’re a notice programmer and not very familiar with the codebase. That said, Aleix is still making about 99% of the code changes, and I’m mostly doing UI tweaks, bug screening, promotion, strategy, and work with apps to get their houses in order.

Anyway, here’s are the user-facing highlights of what we’ve done in the last week or so. There was a lot of work on Snap and Flatpak in particular.

  • During installation of Snaps, the Install button changes so you can’t click it multiple times (KDE bug 388916)
  • Discover now shows the license for Snaps (KDE bug 388735)
  • Discover now shows the size for Snaps that aren’t installed (KDE bug 388734)
  • Discover no longer shows duplicate information in package changelogs for Debian-based distros (KDE bug 387041)
  • Discover now shows the version number for Flatpak apps that define information in their AppStream files (KDE Bug 388968)
  • Discover’s Home page now communicates that it’s a list of featured apps (KDE Phabricator revision D9868)

Let me share a video that shows a lot of the highlights:

We’ve got Kdenlive available from three sources. Version 17.08.3 is available from a distro, and version 17.12.1 is available straight from the developers via Flatpak. You can also get bleeding-edge development builds if you’d like to follow or participate in the development, or verify that a bug is fixed before the next release. You can install the one that suits you best, and change your selection as your needs and preferences evolve over time. It’s your choice.

You’re looking the future of software delivery, folks.

Do you want to help make this happen? Instead of my usual spiel about becoming a KDE contributor or donating, consider helping app developers correct and expand their AppStream metadata. The video you just saw isn’t possible without it. Let’s go build the future.

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

Tue, 2018/01/16 - 12:27pm

Please read Part 1 of this Blog series about sharing Files on Android and iOS where I wrote about my experiences how to share Files or Content from your Qt App with native Android or iOS Apps.

In the meantime I did some UI tuning and added more info to make it easier to understand and to manage some more use-cases, so expect some more parts of this series next weeks.

Also I found out that not all Android Apps are good citizens of ACTION_EDIT – Intents with ResultCode. After editing and save per ex. Google Fotos sends correct RESULT_OK where other Apps are giving you RESULT_CANCEL. For our workflows it‘s important to know if a File was modified, so as a workaround I store the last-modified-Timestamp before starting the Intent and compare with current Timestamp when Result was handled. All of this is done under the hood and you‘re always getting the correct result code back from EDIT Action.

Some preliminary notes
  • Try it out: all sources are available at GitHub
  • Permissions not checked in Example App: enable WRITE_EXTERNAL_STORAGE manually
  • Current release is for Target SDK 23 ! (Android 7 requires FileProvider – will add later)
  • 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.

Android / iOS

First part covers sharing Files from your App with other Apps on Android and iOS.

This Blog Post is about sharing Files with your Qt App on Android (iOS will follow soon):

  • Use your App as Share Target to receive Content or Files from other Android Apps
  • Impacts on „Sharing Files from your App with other Apps“ (see Part 1)
Intent Filter

To tell the Android OS what kind of Files our App can handle we must add an Intent Filter to AndroidManifest.xml:

<activity … > <!-- Handle shared incoming urls --> <intent-filter> <action android:name="android.intent.action.SEND"/> <category android:name="android.intent.category.DEFAULT"/> <data android:mimeType="*/*"/> </intent-filter> <intent-filter> <action android:name="android.intent.action.VIEW"/> <category android:name="android.intent.category.DEFAULT"/> <data android:mimeType="*/*"/> <data android:scheme="file"/> <data android:scheme="content"/> </intent-filter> </activity>

Now the App can receive Intents for all kind of MimeType using ACTION_VIEW or ACTION_SEND.

Custom Android Activity

To be able to get the Intent we must add some code to our main Activity, so extend the default QtActivity. To do so create a QShareActivity.java at this location:

<project>/android/src/org/ekkescorner/examples/sharex public class QShareActivity extends QtActivity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); } }

As next change the Name in AndroidManifest.xml:

<activity ... android:name="org.ekkescorner.examples.sharex.QShareActivity" ...> Get the incoming Intent

Now the interesting part:
Our App can be opened by other Apps – how do we get the Intent data and read or copy the ‚foreign‘ File ?

This depends from current ApplicationState:
if the App is already running, Android OS will call onNewIntent() – if not our App will be launched and the Intent comes in from onCreate(). The best way is to check the Intent from both methods and then call another method to process the Intent.

Attention: there are some traps to watch !

To inform the UI about an incoming File as usual we want to use a SIGNAL.

If the App is already running we want to open our App exactly on the current Page. Imagine a DropBox-like App where you navigate deep into your File hierarchy and now you want to upload a new Presentation File into the current Folder, but you must edit the Presentation before. So you open PowerPoint or something else, create/edit the presentation and then want to share that File with your App. Of course the User wants to be exactly where he was before without the need to do deep File navigation again.

If our App will be launched by the incoming Intent, onCreate() was called from Android OS to deliver the Intent. Unfortunately at this moment the Qt App isn‘t ready and the SIGNAL will be lost. To avoid this don‘t process the Intent from onCreate() but remember that there‘s a pending Intent.

Later when the Qt App is ready check for pending Intents. HowTo know if the App is ready to process Intents ?

In our Example App we‘re checking the ApplicationState and first time the State becomes Active we ask for pending Intents.

In a real-life business App probably you must at first Login to your Server or get some data from Server, so you‘ll do the check for pending Intents later.

LaunchMode ‚singleInstance‘ vs ‚singleTask‘

As next I found out that the last opened Page wasn‘t shown – instead a white Screen comes up and an error was logged: ‚Surface1 null‘.

Reason was the Launch Mode. Most Android Intent examples are using ‚singleTask‘ so I also did it. Changing the LaunchMode to ‚singleInstance‘ in combination with ‚taskAffinity‘ works better for Qt Apps: now the App opens correct the last opened Page.

Here are the changes to AndroidManifest.xml:

<activity ... android:launchMode="singleInstance" android:taskAffinity="">

Some code snippets:

QShareActivity.java:

public class QShareActivity extends QtActivity { public static boolean isIntentPending; public static boolean isInitialized; public static String workingDirPath; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); // now we're checking if the App was started from another Android App via Intent Intent theIntent = getIntent(); if (theIntent != null){ String theAction = theIntent.getAction(); if (theAction != null){ // delay processIntent(); isIntentPending = true; } } } // if we are opened from other apps: @Override public void onNewIntent(Intent intent) { super.onNewIntent(intent); setIntent(intent); // Intent will be processed, if all is initialized and Qt / QML can handle the event if(isInitialized) { processIntent(); } else { isIntentPending = true; } } public void checkPendingIntents(String workingDir) { isInitialized = true; workingDirPath = workingDir; if(isIntentPending) { isIntentPending = false; processIntent(); } } // process the Intent if Action is SEND or VIEW private void processIntent(){ Intent intent = getIntent(); // do something with the Intent } }

Check ApplicationState in ApplicationUI.cpp:

#if defined(Q_OS_ANDROID) void ApplicationUI::onApplicationStateChanged(Qt::ApplicationState applicationState) { if(applicationState == Qt::ApplicationState::ApplicationActive) { // if App was launched from VIEW or SEND Intent // there's a race collision: the event will be lost, // because App and UI wasn't completely initialized // workaround: QShareActivity remembers that an Intent is pending if(!mPendingIntentsChecked) { mPendingIntentsChecked = true; mShareUtils->checkPendingIntents(mAppDataFilesPath); } } } #endif Process the incoming Intent

Now let‘s take a look at processIntent() from QShareActivity.java to see how to read the File from the other Android App.

We‘re listening for VIEW and SEND Intent Actions. The ways to get the Uri are different:

Uri intentUri; String intentScheme; String intentAction; if (intent.getAction().equals("android.intent.action.VIEW")){ intentAction = "VIEW"; intentUri = intent.getData(); } else if (intent.getAction().equals("android.intent.action.SEND")){ intentAction = "SEND"; Bundle bundle = intent.getExtras(); intentUri = (Uri)bundle.get(Intent.EXTRA_STREAM); } else { return; }

As next we must check the Scheme to know if it‘s a ‚file‘ or ‚content‘ Scheme.

// content or file intentScheme = intentUri.getScheme(); if (intentScheme == null){ return; } if(intentScheme.equals("file")){ // URI as encoded string setFileUrlReceived(intentUri.toString()); // we are done Qt can deal with file scheme return; } if(!intentScheme.equals("content")){ return; }

To get the real FilePath from a Content Uri isn‘t so easy. Found many complicated examples and finally I got a great solution to extract the absolute FilePath from the Content Uri ��

Please take a look at QSharePathResolver.java:

<project>/android/src/org/ekkescorner/utils/ public class QSharePathResolver { public static String getRealPathFromURI(final Context context, final Uri uri) { // ... } }

QSharePathResolver.java checks if the content Uri comes from

  • ExternalStorageProvider
  • DownloadsProvider
  • MediaProvider: Images, Video, Audio
  • GoogleFotosUri

and tries to calculate the real path. Now it‘s easy to get the File from an Intent providing a Content Uri:

filePath = QSharePathResolver.getRealPathFromURI(this, intentUri); setFileUrlReceived(filePath); // we are done Qt can deal with file scheme return;

If the Uri couldn‘t be resolved from QSharePathResolver.java we try to read the InputStream. Please take a look at QShareUtils.java: createFile(ContentResolver cR, Uri uri, String fileLocation)

filePath = QShareUtils.createFile(cR, intentUri, workingDirPath); setFileReceivedAndSaved(filePath);

01_new_intent_from_other_app

Ok – we received the File from our custom Activity – how can we provide this to our QML UI where we‘re waiting for a SIGNAL from C++ ?

From Java (Activity) to C++ to emit the SIGNAL for QML

The methods setFileUrlReceived() and setFileReceivedAndSaved() are native methods:

public class QShareActivity extends QtActivity { // 'file' scheme or resolved from 'content' scheme: public static native void setFileUrlReceived(String url); // InputStream from 'content' scheme: public static native void setFileReceivedAndSaved(String url); }

Native Methods are implemented in C++ via JNICALL – see all details in AndroidShareUtils.cpp:

#ifdef __cplusplus extern "C" { #endif JNIEXPORT void JNICALL Java_org_ekkescorner_examples_sharex_QShareActivity_setFileUrlReceived(JNIEnv *env, jobject obj, jstring url) { const char *urlStr = env->GetStringUTFChars(url, NULL); Q_UNUSED (obj) AndroidShareUtils::getInstance()->setFileUrlReceived(urlStr); env->ReleaseStringUTFChars(url, urlStr); return; } JNIEXPORT void JNICALL Java_org_ekkescorner_examples_sharex_QShareActivity_setFileReceivedAndSaved(JNIEnv *env, jobject obj, jstring url) { const char *urlStr = env->GetStringUTFChars(url, NULL); Q_UNUSED (obj) AndroidShareUtils::getInstance()->setFileReceivedAndSaved(urlStr); env->ReleaseStringUTFChars(url, urlStr); return; } #ifdef __cplusplus } #endif

If you want to learn more about JNICALL and other ways to manage them, here‘s a great Blog Post from BogDan Vatra : qt-android-episode-5.

JNICALL is like a bridge from Java to C++:

void AndroidShareUtils::setFileUrlReceived(const QString &url) { QString myUrl; if(url.startsWith("file://")) { myUrl= url.right(url.length()-7); } else { myUrl= url; } // 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)); } }

This JNICALL enables us to emit the SIGNAL that we received an Intent from another Android App providing access to a File.

02_process_intent_from_other_app

Test it !

Now it‘s a good point to test it. Open Google Photos, select an Image and ShareWith shows ‚ekkes SHARE Example‘ App as target:

03_see_our_app_as_target

Select ‚ekkes SHARE Example‘ and Android will open our App. If the App already was opened, the current Page will be displayed and include the Image:

04_our_app_received_image_from_other_app

onActivityResult() (JAVA) vs QAndroidActivityResultReceiver (JNI)

While writing Part 1 of this Blog series I didn‘t found a way to get the Result back if Intent was started with Result from QShareUtils.java (Workflow ‚A‘ – the JAVA way)

QtNative.activity().startActivityForResult(Intent.createChooser(viewIntent, title), requestId);

@hamalaiv comment pointed me to the right direction: to get the Result back a Custom Activity must be used.

Ok – we‘re now using a custom Activity (QShareActivity.java) – let‘s test it.

To get the Result back, we must be implemented this JAVA code:

public class QShareActivity extends QtActivity { public static native void fireActivityResult(int requestCode, int resultCode); @Override protected void onActivityResult(int requestCode, int resultCode, Intent data) { fireActivityResult(requestCode, resultCode); } }

and this C / C++ Code:

JNIEXPORT void JNICALL Java_org_ekkescorner_examples_sharex_QShareActivity_fireActivityResult(JNIEnv *env, jobject obj, jint requestCode, jint resultCode) { Q_UNUSED (obj) Q_UNUSED (env) AndroidShareUtils::getInstance()->onActivityResult(requestCode, resultCode); return; } void AndroidShareUtils::onActivityResult(int requestCode, int resultCode) { processActivityResult(requestCode, resultCode); } void AndroidShareUtils::processActivityResult(int requestCode, int resultCode) { if(resultCode == RESULT_OK) { emit shareEditDone(requestCode); } else if(resultCode == RESULT_CANCELED) { if(mIsEditMode) { // check Timestamp and emit shareEditDone(requestCode); // or emit shareFinished(requestCode); return; } emit shareFinished(requestCode); } else { emit shareError(requestCode, tr("Share: an Error occured")); } }

05_overview_share_files_with_other_apps_v2

Testing the JAVA way sharing Files with other Android Apps now works as expected with or without ResultCode. I removed the workaround code from ApplicationUI.

But there‘s a Drawback: Testing the JNI way (Part 1, Workflow ‚B‘) using QAndroidActivityResultReceiver only works without ResultCode. If starting the Intent with ResultCode

QtAndroid::startActivity(jniIntent, requestId, this);

the QAndroidActivityResultReceiver wasn‘t called for the Result: instead the Result comes back via our custom Activity onActivityResult() method using a wrong RequestId.

Lesson learned: never use QAndroidActivityResultReceiver (C++, JNI) and onActivityResult() (JAVA Activity) together in one App.

To test this please comment or rename onActivityResult() and you‘ll see the JNI implementation alone works well.

There‘s another problem if we want to share one of our Files with other Apps, because now we‘re source and also target for same MimeTypes. This means: our own App will be listed as a target:

06_own_app_is_target

Tried some ways to workaround, but doesn‘t work well and selecting the own App as Target with Result crashed the App because there was a collision with LaunchMode ‚singleInstance‘.

Unfortunately there‘s no way to exclude targets using Intent Filter. So we have to create a custom Chooser without listing our own App as Target. Thanks to this thread at StackOverFlow I found a way to solve this. Please take a look at QShareUtils.java

public static boolean createCustomChooserAndStartActivity(Intent theIntent, String title, int requestId) { // ... }

Here‘s a short summary:

  • Create Intent as before and use as template
  • Context is QtNative.activity()
  • Get packageManager from context.getPackageManager()
  • Retrieve all Apps (List) for Template – Intent: packageManager.queryIntentActivities()
  • Sort Apps (List) by Label
  • From Apps (List) create List
    • Create Intent as Copy from Template – Intent
    • Add setPackage(targetPackageName)
    • Don‘t add Intent to list if Target PackageName equals own PackageName
    • If needed also watch a Blacklist

We created a List of Intents, where all Intents are based on our previously created Template – Intent with an extra PackageName added. This means each Intent will only detect one specific App as Target.

Now the tricky part:

We want to all collected Intents as EXTRA_INITIAL_INTENTS and we‘re using the last one from list of Intents as initializing Intent because the Chooser adds its initializing Intent to the end of EXTRA_INITIAL_INTENTS ��

Intent chooserIntent = Intent.createChooser(targetedIntents.remove(targetedIntents.size() - 1), title); if (targetedIntents.isEmpty()) { Log.d("ekkescorner", title+" only one Intent left for Chooser"); } else { chooserIntent.putExtra(Intent.EXTRA_INITIAL_INTENTS, targetedIntents.toArray(new Parcelable[] {})); } QtNative.activity().startActivityForResult(chooserIntent, requestId);

07_own_app_excluded_from_targets

Now it works as expected: our own App doesn‘t appear in list of target Apps.

Attention: onActivityResult() (JAVA) sometimes is too fast compared with QAndroidActivityResultReceiver (JNI)

While testing Action SEND I noticed that Files are not copied to other Apps or not printed, because ‚File does not exist‘. This happens only if going the JAVA way getting the Result back from onActivityResult(), but not if using JNI and QAndroidActivityResultReceiver.
When getting the Result back I‘m deleting the File from Documents Folder (see Part1) and it seems that onActivityResult() sends the Result before File was fully copied / printed.
As workaround I added a Timer with 500ms delay in QML before deleting the File.

From now on I‘ll use the JAVA way (Workflow ‚A‘ in Overview) as default to share Files with other Apps, because it‘s much easier to implement specific behaviour (as our Chooser Intent) using JAVA instead of JNI. The pure JNI way still remains in the code to get a feeling HowTo solve it without JAVA code.

Share from other iOS Apps with our Qt App

As next I want to implement the same functionality for iOS – so stay tuned for Part 3.

My goal is always to provide easy-to-use x-platform solutions for Android and iOS. That‘s why I‘m using Qt ��

Some years ago I developed mobile business Apps for BlackBerry10 (BB10) where the InvocationFramework makes it easy to share content or files between Apps.

BB10 Customers are now (and next years) in transition from BB10 to Android, iOS or both and of course I want to motivate them to use Qt as their new Framework. Last two years I implemented most of my patterns using Qt and QtQuickControls2 for Android and iOS. Having features only for one platform is like having no solution. Step-by-step I‘m reaching feature-parity with BB10.

I‘m also blogging about all of this to make it easy for mobile devs to start with Qt.

Back to Sharing Example.

Need Help – offer Bonus

As I understand it right, iOS Extensions should be used to share Files or Content from other iOS Apps to our Qt App and it seems that this isn‘t supported yet our of the box from QtCreator. If there are some manual steps needed I need a description HowTo do this.

Remember: I‘m a mobile Business App Developer, not a Xcode expert and not an Obj-C expert and I‘m doing all my work from QtCreator – not commandline.

I‘m open for all tips and any help HowTo …

  • Open Qt App from other iOS Apps sharing Text Content or Files
  • Reopen Qt App from other iOS Apps at current Page if Qt App is already running
  • Emit SIGNAL about received Files or Text and copy Files into AppData location
  • Development workflow to solve this from QtCreator / Xcode

Bonus: If someone can provide a small sample project before I found out all the steps and blogged about, the first one will get a Bonus of 500 € from me. Please be aware that I‘ll modify and include code into my Share Example as Open Source code.

Have Fun

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

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

Plasma on ARM: State of the Union

Tue, 2018/01/16 - 12:13am

For the past year at Blue Systems my colleagues and I have been working on getting Plasma 5 ready for ARMv8 systems such as the Pinebook. If you were at QtCon this year, you might have also seen our awesome team demo’ing these systems at the KDE booth along with Plasma on ARMv7 systems such as the ODROID C1.

A year ago, the state of Plasma on ARMv8 looked somewhat like this bench, covered in snow, not particularly inviting. Things worked, or at least appeared to, only to break as soon as you started digging deeper into the innards of the system. One of the biggest hurdles in the ARM space right now is getting graphics working on a Linux system. Working with the Pine64 and Pinebook was no exception.

While the X11 and DRM stacks are open source, the OpenGLES implementation is only provided as a proprietary blob. Better than nothing, but still not quite up to the quality that we were looking for.

Once we figured out where we could improve things, we started getting our hands dirty and improving things as best as we could and learning more about the graphics stack as a whole. This lead to improvements such as getting a working hwcursor (thanks David!) for the Pinebook, making sure we don’t have garbage on the screen when X11 gets started and a failed attempt to get Debian to rebuild Qt on ARM64 systems with GLES instead of OpenGL ( since there is no OpenGL on the Pinebook ).

We also bench marked important metrics that would affect our users such as time to login manager, time to desktop and the time it took to launch a file manager such as Dolphin. With these metrics in hand, the Plasma team at Blue Systems set out to improve these metrics by improving the various bits and pieces within the KDE product ecosystem. It’s important to note that all of the improvements that have been made will also benefit x86 users, though the impact will really be seen on ARM devices.

The future for Plasma on ARMv8 looks pretty bright from here on out to me. There’s still a lot of work to be done, but we’ve got a pretty good handle on it for now. There were massive improvements once we identified major pain points such as Qt using OpenGL instead of GLES and fixing issues within Qt itself.

I’d also like to take a moment and say a massive thanks to the Pine community as well. They’ve been an amazing group of people to work with. They even released a Wayland driver that could potentially become the building block to deliver a ARMv8 laptop that can run Plasma atop Wayland in the future! Thank you so much, it really is appreciated.

Three old Plasma Weather applet TODO items gone for Plasma 5.12

Mon, 2018/01/15 - 10:15pm

Just when I thought to have missed yet another Plasma feature freeze deadline with the one for Plasma 5.12 LTS and thus a good(?) excuse to re-decrease priority of some planned work on the Plasma Addons Weather applet (from the kdeplasma-addons repo, not to be mixed up with clearmartin’s one from github/store.kde.org) once more and thus delay things even further to a day that may never come, the Plasma team found they need to shift the deadline by some weeks to be after the KDE Frameworks 5.42.0 release.
So excuse gone, no other quickly found… time to do a git pull and open the editor.

It’s almost two years ago that the old Plasma Addons Weather applet got ported to Plasma 5 with an initial release in Plasma 5.6. That activity resulted in some plans for further work, which then though met a sad fate of plans… staying on paper to some degree. Let’s revisit the points of the plan and their state:

  • Breeze-style weather state icons: done -> hurra for hard-working Ken
  • Overhaul of look: only cosmetic changes applied, bigger redesign never turned into code -> FAIL
  • support for more weather data providers: a template for provider plugins has been done and added, but no-one ever contributed a plugin for a new provider -> FAIL so far
  • also temperature displayed in compact widget variant, like on panel: got lost in layouting code -> FAIL
  • privacy control which weather data providers are queried on finding weather stations: never worked on -> FAIL

Add to that a Plasma 5 Porting TODO item from the code:

  • Restore night-style icons for observation weather conditions at night: never worked on -> FAIL

Living in some slightly northern of the northern hemisphere, right now the days are short and the temperature is often around the freezing point. Which makes the weather applet look slightly broken and useless: not showing the temperature directly on the panel for a quick glance to check whether it is slippery outside, but showing the weather observation report with the sun symbol in the icon when it is dark outside… who needs or wants that. Still the applet is working too well for just proposing to wipe it from the repos in favour of one of the alternative ones out there. Of course there is also that tiny bit of pride in the porting work done, which begs for throwing more good time after it… &#55357;&#56841;

So motivation collected, some coding time shuffled free: the fight against the new Plasma 5.12 feature freeze deadline was picked up. And to make the already too long story short, I can now happily report that with the help of Kai Uwe and some further random Plasma developers the last three items can now be checked off as Done starting with Plasma 5.12 &#55357;&#56898;

Selecting which weather service providers to query for a location in the Plasma Weather applet. Spot also the optional temperature shown on both panels next to the weather state icon, as well as proper night-style weather state icon for England’s London during current CET night (sorry for German/English mix in UI, too sleepy for proper setup)

So some 2018 FLOSS contributions of mine done. Now I can slack off the rest of this year! &#55357;&#56859;
And watch you doing yours by implementing a plugin for your favorite weather data provider?

SoK Project – Week 1 & 2

Mon, 2018/01/15 - 2:07pm

With all the happiness after being selected for SoK 2018, I was looking forward to start working on my project with whole dedication. My project aims to complete port of a brain-boosting memory activity called “Railroad” (in which kids have to observe the given train and memorize it within given time and then try to rebuild it) from Gtk+ to Qt version. It is a part of project GCompris(a high-quality educational software suite, including a large number of activities for children aged 2 to 10). My mentors are Timothée Giet and Rudra Nil Basu, along with them I’d like to thank a lot to Johnny Jazeix and Divyam Madaan for helping me with my project. My SoK proposal can be found here –> SoK Proposal. And my progress can be tracked at –> Railroad branch.

I started with introducing myself to the GCompris community and discussing my implementation plans with the mentors. My mentors helped me to get my KDE developer account and setup git. First error which I encountered was during git clone, after googling about it and discussing with mentors I got to know that it was due to the firewall(thanks to my college).

My main task for first two weeks was to create a new layout for the activity, make the activity look better in small screen devices and remove horizontal scrolling. This activity was already started during previous SoK, so most of the code was already written. I compiled the activity and started understanding its code, my previous contributions on GCompris helped me to understand the code fastly. Previously it was hard-coded to have a fixed no. of wagons in fixed no. of rows which caused horizontal scrolling. I implemented a GridView based layout which helped to remove the need for horizontal scrolling and made UI look more beautiful.


1. For Horizontal Screens

2. For Vertical Screens

After working on UI, I created five levels based on increasing difficulty and fixed some issues in UI based on reviews from my mentors. Every error opened an opportunity for me to learn something new. I’ll be working on implementing keyboard navigations next week.

Some of the new things which I learned during this project so far
> Importance of Version Control System.
> Quality of code is more important than Quantity of code.
> Dividing a big task into small tasks and then proceeding.
> Using SSH keys.
> An image when opened with a text editor shows real mystery behind it.

In conclusion, SoK proves to be a great experience thus far, being a pleasure to work on a project focused mainly on Education. For further updates, stay tuned!

How you can help drive Flatpak adoption

Mon, 2018/01/15 - 4:46am

What happens in Discover in when an app is available from multiple sources–say, Flathub as well as your distro’s packages?

As long as both versions of the app provide the same AppStream ID, Discover will show a single entry and let you choose which one you want to install, like this:

But if any of the available versions use a different AppStream ID, they’ll show up separately:

Uuurgh, how awful. Which GIMP is the real GIMP? And why do they all have different names?! Flathub uses org.gimp.GIMP as the AppStream ID, while The GIMP developers provide gimp.desktop for distros to use as the AppStream ID. And the Snap version provides no AppStream ID, sadly.

So we need the GIMP developers to change their AppStream ID to the same one that Flathub uses (which actually follows the AppStream spec). I submitted a patch to fix it that was recently accepted, so this should be resolved with the next GIMP release. That will unify the first two, but the third–which comes from Snap–won’t get rolled up into it until Snap uses AppStream IDs. The Snap folks are on the case, but it’s still a work in progress.

But adopting AppStream only work as long as developers are populating their AppStream files with valid IDs! An AppStream ID is supposed to look like com.myurl.NameOfMyApp, not NameOfMyApp.desktop or com.myurl.NameOfMyApp.desktop. Flathub gets this right, but a lot of app developers themselves get it wrong, and it’s up to us to help them, and make sure the AppStream IDs in their files match those on Flathub.

I’ve started to submit patches for apps that unify their AppStream IDs:

What can I do to help?

See all those patches I submitted? You can do the same! If you use any apps that have AppStream IDs in their distro packaging that are incorrect and different from what’s in Flathub, then submit a patch to fix it! Keep in mind the following guidelines:

  1. Dashes/hyphens must be replaced with underscores: com.shutter-project.shutter is wrong and should be com.shutter_project.shutter
  2. Leading digits in the app name are not allowed: com.wildfiregames.0ad is wrong and should be com.wildfiregames._0ad
  3. If the AppStream ID used for Flathub is wrong, don’t replicate that wrongness with your patches; encourage developers to use correct AppStream IDs and file a bug for the app on Flathub, like this one.

For extra credit, you can also submit patches that add information, too. This will make the app’s version string show up in Discover:

And here’s the properly formatted information in HexChat’s AppStream file that provides it: https://github.com/hexchat/hexchat/blob/master/data/misc/io.github.Hexchat.appdata.xml.in#L29

I know this isn’t the most immediately rewarding work, but it’s super important to make Flatpak (and later Snap) work properly in a mixed environment where you also have distro packages available. If you want the world to be Snappier or more Flatpacked, this is probably the easiest way to make it happen if you’re not a programmer or a packager. If you need a hand, you can email flatpak@lists.freedesktop.org or check out the #flatpak IRC channel on freenode.org.

As always, if you find this work useful or valuable, please consider becoming a KDE contributor or donating to KDE! But do consider submitting patches for Apps that have sparse or incorrect AppStream data. You’ll be doing your part to pull Linux software distribution into the future.

Flatpak support in Discover

Sun, 2018/01/14 - 12:51am

People often ask about the state of Flatpak in Discover, so today I’m going to write about that. Thew good news is that Discover’s Flatpak support is very good and getting better all the time. It’s fully production ready and we encourage you to use it!

To download Flatpak apps in Discover, you need to have the Flatpak backend installed. In many distros, it’s a separate package that doesn’t come installed by default. In Ubuntu-based distros, you can install it by running sudo apt install plasma-discover-flatpak-backend. in Discover 5.12, you’ll even be able to install different backends from within Discover itself, by searching for “Flatpak” or “Snap”. If you want faster Flatpak adoption, please petition your distros to install the Flatpak backend by default!

Once the Flatpak backend is installed, you need to add at least one Flatpak repo. Distros can provision this with default entries, but most don’t. Bug your distro if you want a better experience here! Until then, you can go to Discover’s Settings page and click the “Add Flathub” button to add Flathub as a source. After that, you can access Flatpak apps by browsing or searching through the app lists as normal. You can also go to the settings page and click on the Flatpak entry, which will show you just the Flatpak apps from that repo:

You can add multiple Flatpak repos; to do so, go to the Settings page, click the Hamburger menu button next to the text “Flatpak”, and click “Add Source…” Then enter the URL of the Flatpak repo you want to add. Discover also handles this properly when you click on a repo URL in your web browser.

Multiple Flatpak repos enable users to effortlessly switch between stable and up-to-date versions of apps, each version provided by a different repo. Right now, we’re generally stuck with one or the other, according to our distro’s packaging policy: Arch and other rolling distros say that you always get the latest version; Debian and Ubuntu and other stable release distros say that you always get a specific version that’s frozen in time. Sometimes that’s not right for you, because maybe the latest version has a bad bug, or an old stable version is missing features you want that were implemented in a later version.

Flatpak liberates us from this. You could add Flathub (https://flathub.org/repo/flathub.flatpakrepo) and also KDE’s nightly testing repo (https://distribute.kde.org/kdeapps.flatpakrepo). Then when you go to install a KDE app that’s present in both, you can choose the source! Maybe you want to live on the bleeding edge, but if you run into an issue, you can easily revert your installation to the stable version. It’s pretty awesome.

I believe that Flatpak is the future of app distribution. It’s slick, it works, it’s becoming very widely adopted, and it makes life easier for both users and developers. Users get to have apps that are up-to-date or stable per their preference, and developers only have to package their apps once rather than hoping that packagers for 500 different Linux distros do it for them.

Ultimately, this liberates us from the tyranny of low-quality distros with no QA. When most software comes from the developers without needing distros to act as gatekeepers, the difference between the distros begins to recede, and many will rightly vanish because they’re not providing enough value and generating enough developer interest to continue existing. Once this happens, the small number of remaining distros will have much more manpower and more eyeballs on their offerings, resulting in better QA, more development, higher quality offerings for users, and fewer development targets for developers.

Far from erasing diversity, this will empower better real, meaningful diversity–where we have a handful of really good diverse distro options instead of an overwhelming number of mediocre ones with often only minimal differences. We’ll all win.

If any of this sounds exciting and desirable, please don’t hesitate to join our team or make a donation to KDE. My next post will share some specific things you can do to help push Flatpak adoption, even without being a programmer.

digiKam 5.8.0 is released

Sun, 2018/01/14 - 12:00am

Lac Mirroir, Le Melezet, Ceillac, French Alps

Following the release of 5.7.0 published in September 2017, the digiKam team is proud to announce the new release 5.8.0 of the digiKam Software Collection. In this version a lot of work has happened behind the scenes and in fixing bugs as usual, which does not mean there are no enhancements: a new tool to export collections to UPNP/DLNA compatible devices has been introduced.

Bugs Triage

Following the large update of bug categories processed before the previous release, we have been able to reassign entries to the right components. With the help of pre-release bundles computed each day, we have been able to provide a digiKam test version along with the fixes applied to close reports in bugzilla. The result with this release is a set of more than 200 entries officially closed.

Application Bundle Improvements

MacOS and Windows digiKam Installers in Action

For each platform supported by the digiKam project, we propose a bundle package ready to use, which embed all the needs to have a suitable application. The AppImage is the main Linux bundle which has been updated to last SDK available which now permits to run the bundle under Firejail sandboxing technology.

Showfoto Running Under Windows

The Windows installer is now built with the latest NSIS version to be compatible with Windows 10. The installer code has also been cleaned to remove obsolete packaging plugins and to prevent false virus detections while installing. Note that all digiKam Windows bundles are fully built under Linux with the MXE cross-compiler and there is no risk to inject Windows viruses in the application.

Showfoto Running Under MacOS

All bundles, including the MacOS package build with the latest Packages, now include more optional features available on digiKam and also Showfoto, as some new low level libraries have been ported to pure Qt5, such as digital scanner support and events file support with export to Calendar tool.

Mysql Support Improvements

Mysql Config Panel and Migration Tool

A lot of work has been done around the Mysql support with the help of end users testing step by step progress and the relevant fixes applied daily. For these hacking stages, the pre-release bundles have really helped a lot, by providing a ready to use beta version of digiKam including all debug statements necessary to investigate the dysfunctions, especially for the database schema update performed on older collections hosted on a Mysql or Mariadb server. The migration tools have also received many fixes, especially to move from Sqlite databases, when collections grow substantially and over time become more and more slow. Now, the migration tool can import and export better from/to Mysql or Sqlite without data-loss while databases are being converted.

Export to UPNP/DLNA devices

New Tool to Share Collections With DLNA Devices

In September 2017, the digiKam team has been invited to take part in the Randa Meetings. In this tiny town in the Swiss alps a lot of KDE developers work on improving their software. We have focused the reunion on including the new media server dedicated to sharing collection contents on local networks with compatible DLNA devices or applications, such as tablets, cellulars, TV, etc. This tool is now available in all digiKam views through the main Tools menu and also in Showfoto. There are plenty of DLNA applications available in digital stores like iTunes or GooglePlay. As the DLNA and UPNP protocols are standardized, we don’t need to develop dedicated applications for each client device that wants to access the digiKam/Showfoto contents.

Port DropBox Export Tools to OAuth2

digiKam DropBox Export Tool Running Under Windows

Concerning digiKam export tools to remote Internet services, the port to OAuth version 2 is advancing steadily with more work planned in the course of the year. After porting the Flickr and Imgur export tools with the 5.7.0 release, the DropBox export tool is now ported to the new authentication API, so after a short time of dysfunction the tool is back and ready for use in production. In the future other tools, such as Facebook and GPhoto export, will be ported to OAuth version 2. This will probably be a subject for the students working with us for the upcoming Google Summer of Code 2018.

Final Words

As always, but especially noteworthy this time, you can look at the list of 231 resolved issues for detailed information.

digiKam 5.8.0 Software collection source code tarball, Linux 32/64 bits AppImage bundles, MacOS package, and Windows 32/64 bits installers can be downloaded from this repository.

Happy new year 2018 and happy digiKaming!

Last Weeks Activity in Elisa

Fri, 2018/01/12 - 5:40pm

Elisa is a music player designed to be simple and nice to use. It allows to browse music by album, artist or all tracks. You can build and play your own playlist. We aim to build a fluid interface that is easy to use.

We are preparing for the next alpha release when the following features will be done. Alexander is working on a metadata view for tracks. I am working on cleaning the different grid views into a generic one.

Diego Gangl did several modifications of the interface as part of the interactions with KDE VDG.

All in all, Elisa now looks like that:

Screenshot_20180112_174013Snapshot of album view including the changed application menu

The following things have been integrated in Elisa git repository:

  • Fix modification of files with DatabaseInterface::modifyTracksList by Matthieu Gallien ;
  • This patch increases the blur in the headerbar background, increases contrast
    between background and text, and brings the labels closer together by Diego Gangl ;
  • Tune appearance of all albums and all artists views by Matthieu Gallien ;
  • Fix wrong id reference in FilterBar by Matthieu Gallien ;
  • In all models, calls base class roleNames before adding new role names by Matthieu Gallien ;
  • Simplify the definition of custom roles in all models by Matthieu Gallien ;
  • Allow MusicArtist to be stored in a QVariant by Matthieu Gallien ;
  • Allow to enqueue artist in MediaPlayList by using MusicArtist objects by Matthieu Gallien ;
  • Change height of delegate in GridView by Matthieu Gallien ;
  • Fix a typo in the imported tracks notification by Diego Gangl ;
  • Make shadows centered and slightly larger. Fits better with other shadows in the
    desktop (like dolphin and widgets), and it also aligns with the new shadows for
    breeze (D9549) by Diego Gangl ;
  • Fixes key arrow navigation in list and gridviews and implements enter and return key actions for delegates by Alexander Stippich ;
  • Allow elisa to open any external files, scan them and enqueue them by Matthieu Gallien ;
  • Syncs the windows theme file with the current main theme file. Removes bundled icons for windows which are not needed as proven by ViewSelector.qml, but also tested on windows by Alexander Stippich ;
  • Make the delegates more appealing when using a dark theme also add hover animations while keeping the loader component by Alexander Stippich ;
  • Fix keyboard navigation for album artist view too by Alexander Stippich ;
  • Move all icon and image definitions to theme file and make some consistency fixes. In anticipation of a colorized version of the artist image, there are two definitions which currently hold the same icon. Also enables the display of a default cover in context view by Alexander Stippich ;
  • qml profiler shows a few percent of cpu time spent just for the creation for simple buttons for the delegates. cut this by loading on demand by Alexander Stippich ;
  • Try to find png files for covers if jpegs do not exist can probably be made a lot smarter than this, but kept it simple for now by Alexander Stippich ;
  • Try to fix build (as seen on binary-factory.kde.org) by Matthieu Gallien ;
  • Re-order menu items to fit better with the order used in other KDE applications by Diego Gangl.

 

PackageKitQt 1.0.0 and 0.10.0 released!

Fri, 2018/01/12 - 2:07pm

Happy new year every one!

PackageKitQt is a Qt Library to interface with PackageKit

It’s been a while that I don’t do a proper PackageKitQt release, mostly because I’m focusing on other projects, but PackageKit API itself isn’t evolving as fast as it was, so updating stuff is quite easy.

It haven’t seems a proper release in a while, it got several patches from other contributors, including the Qt5 port, so 0.10.0 is for that, the 1.0.0 release is to match PackageKit 1.0.0 API, while 0.10.0 works with that some signals and methods where removed from PackageKit which where useless in PackageKitQt.

Add to 1.0.0 release the complete Offline updates interface some API cleanups, missing enums and a performance improvement on parsing package ids.

Due the complexity and effort used to roll a release, from now on releases will be done with tags on GitHub, so packagers stays tuned &#55357;&#56898;

https://github.com/hughsie/PackageKit-Qt/archive/v1.0.0.tar.gz

https://github.com/hughsie/PackageKit-Qt/archive/v0.10.0.tar.gz


Ceph Day Germany 2018

Fri, 2018/01/12 - 12:24pm


I'm glad to annouce that there will be a Ceph Day on the 7th of February 2018 in Darmstadt. Deutsche Telekom will host the event. The day will start at 08:30 with registration and end around 17:45 with an one hour networking reception. 
We have already several very interesting presentations from SUSE, SAP, CERN, 42.com, Deutsche Telekom AG and Red Hat on the agenda and more to come. If you have an interesting  15-45 min presentation about Ceph, please contact me to discuss if we can add it to the agenda. Presentation language should be German or English.

I would like to thank our current sponsors SUSE and Deutsche Telekom and the Ceph Community  for the support. We are still in  negotiation with potential sponsors and will hopefully announce them soon.

The agenda will be available here soon. You can register through this link. Stay tuned for updates! See you in Darmstadt!

New Stable Release: Krita 3.3.3

Fri, 2018/01/12 - 11:01am

Today we’re releasing Krita 3.3.3. This will probably be the last stable release in the Krita 3 series. This release contains several bug fixes and one very important change for Windows users:

  • The Direct3d/Angle renderer is now the default for Intel users. Recent updates to the Intel display drivers have broken Krita on many more systems than before, so it’s better that everyone gets this workaround by default. If you experience decreased performance, you can always try to enable OpenGL again.

Other fixes and improvements include:

  • Fix an issue where it would not be possible to select certain blending modes when the current layer is grayscale but the image is rgb.
  • Set the OS and platform when reporting a bug from within Krita on Windows.
  • Make it possible to enter color values as percentage in the specific color selector
  • Add OpenGL warnings and make ANGLE default on Intel GPUs
  • Add an Invert button to the levels filter
  • Implement loading and saving of styles for group layers to and from PSD
  • Fix the erase mode not showing correctly when returning to the brush tool
  • Save the visibility of individual assistants in .kra files
  • Add an option to draw ruler tips as a power of 2
  • Disable autoscroll on move and transform tools.
  • Improve handling of native mouse events when using a pen and the Windows Ink API
  • Fix the focal point for the pinch zoom gesture
  • Fix loading netpbm files with comment.
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.

Linux

(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.3 on Ubuntu and derivatives. We are working on an updated snap.

OSX

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

Source code md5sums

For all downloads:

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.

Seeding new ISOs the easy zsync way

Fri, 2018/01/12 - 7:26am

Kubuntu recently had to pull our 17.10 ISOs because of the so-called lenovo bug. Now that this bug is fixed, the ISOs have been respun, and so now it's time to begin to reseed the torrents.

To speed up the process, I wanted to zsync to the original ISOs before getting the new torrent files. Simon kindly told me the easy way to do this - cd to the directory where the ISOs live, which in my case is 

cd /media/valorie/Data/ISOs/

Next: 

cp kubuntu-17.10{,.1}-desktop-amd64.iso && zsync http://cdimage.ubuntu.com/kubuntu/releases/17.10.1/release/kubuntu-17.10.1-desktop-amd64.iso.zsync

Where did I get the link to zsync? At http://cdimage.ubuntu.com/kubuntu/releases/17.10.1/release/. All ISOs are found at cdimage, just as all torrents are found at http://torrent.ubuntu.com:6969/.

The final step is to download those torrent files (pro-tip: use control F) and tell Ktorrent to seed them all! I seed all the supported Ubuntu releases. The more people do this, the faster torrents are for everyone. If you have the bandwidth, go for it!

This week in Usability and Productivity

Fri, 2018/01/12 - 3:04am

I’d like to highlight some fixes and features that landed in the past week for our Usability and Productivity initiative:

  • Dragging a Firefox tab to the desktop now detaches it properly (KDE bug 337711)
  • Right-clicking on Discover’s icon exposes a new action that allows you to go straight to the Updates page (KDE Phabricator revision D9637)
  • You can now hide the “Comment” field in Dolphin’s Information Panel (KDE bug 365620)
  • Dolphin’s Properties window now has a tab that shows the same file metadata that the Information Panel does, for people who would prefer to access the information that way (KDE bug 384194)
  • Okular’s dialog box for when a PDF wants to be opened full screen is now presented more naturally (KDE bug 388511)
  • Okular can now Print .djvu files (KDE bug 388514)
  • Discover now de-duplicates categories from Flatpak (KDE bug 388313)
  • Discover no longer lets you scroll beyond the boundaries with the PageUp/PageDown keys (KDE bug 388745)
  • Discover app lists are now more compact (KDE Phabricator revision D9833)

These improvements were landed by KDE Developers Kai Uwe Broulik, Albert Astals Cid, Aleix Pol, Michael Heidelbach, and myself. And that’s not all; the entire KDE community has been busy landing many more bugfixes and features too–more than I can keep track of!

I want to especially focus on the last Discover change I mentioned above. After my last post about Discover, we got a lot of user feedback that people wanted greater density and to be able to see more apps at once. We’ve executed on a part of that, and this is now what Discover looks like if you make the window narrow:

I bring this up to highlight that we really do listen to users. Your feedback matters and we hear it! If you enjoy the results of our efforts, please consider becoming a contributor yourself or donating to KDE! In particular, we would love more contributors for our Usability and Productivity initiative. If you’re interested, please feel free to work on any of these bugs. Here are some that should be relatively easy. Happy coding!


KStars 2.9.1 is off to a fantastic start in 2018!

Thu, 2018/01/11 - 3:36pm
We're kicking off 2018 with a new fantastic release of KStars for Windows & MacOS. Linux users should wait a few more days to get the release in the official PPA due to Canonical's Launchpad downtime because of the Meltdown and Spectre CPU vulnerabilities discovered recently.

KStars 2.9.1 aka "Lancaster" release is primarily a bugfix release, but it brings with it as well several new features and improvements to existing technologies.

Over the holidays, Robert Lancaster made significant improvements to KStars and this release is named in his honor. Thank you Robert for your awesome contributions to KStars and Open Astronomy community!

MacOS users gained a few additional drivers with this release including Apogee, QHY, and Meade DSI support!
Set Park PositionSetting a custom parking position used to involve going to INDI Control Panel and tinkering with a few settings before it is saved and active. With KStars 2.9.1, it is now a very accessible action. Simply click anywhere on the sky map and select your desired custom parking position.

The mount shall slew normally to the desired location and save it as the parking position. It will NOT park the mount, it will just save that position as the desired position. To park the mount, use the parking/unparking controls from the toolbar or from the sky map as you normally would.

Additional PHD 2 Support

Robert Lancaster built upon his previous changes to PHD2 to add a PHD2 command request list so that KStars can keep track of what it has asked PHD2 to do. This allowed the addition of several additional commands that could be used to control PHD2. Now, users can use the Ekos Guide Module to change the PHD2 exposure time, change the DEC guide settings, and get information about the guiding pulses sent to the mount. Also, after changing the Connect/Disconnect code, the PHD2 connection seems to be more reliable.

Dither support was improved by using the timeout variable in the Guide options to control how long KStars will wait after issuing a dither command before continuing. And in a related fix, the Guide module will use the setting in the guide options “Dither Failure Aborts Autoguide” to control whether a dither issue will cause the entire sequence to abort. The last two changes were due to the fact that if PHD2 did not send back a response after dithering, KStars would not complete the sequence and if PHD2 reported a guide error, it would abort the entire sequence regardless of the setting in the guide options. This should all now be fixed. Also he added a PHD2 Lost Lock Timer so that if it loses track of the guide star but then regains it within 5 seconds, then it won’t abort guiding.

Drift Graphics Updates

Robert Lancaster made several improvements to the graphs in the Guide Module. These changes will work whether the user is using PHD2 or the internal guider. First, the mount corrections were added to the Drift Graphics plot so that the user could see not just the RA and DEC error, but also the corrections that the mount is making in each axis.

Since this graph naturally has a different scale than the guide errors, a separate axis was added along with a slider to control its scale independently of the other axis. A set of controls was added at the bottom left so that each component could be added or removed from the graph independently. A slider was added so that the user could scroll through the guide history, or click the “Max” checkbox to lock the graph onto the latest point so it will autoscroll.

Also buttons were added for autoscaling the graphs, or exporting the guide data to a CSV file, clearing all the guide data, and for scaling the target in the Drift Plot. Finally, a label was added to the guide graph every time that a dither occurred so the user knows guiding was not bad at those points.

New 3D Star Profile and Data Visualization Tool

Robert Lancaster created a new KStars tool based on some QT Examples that would plot the Pixel Data shown in any of the KStars Image Views so that the user can inspect the data in a new manner. This is particularly useful for astrophotographers who want to visualize the profile of a star they are considering focusing or guiding on, for scientists who want to examine a cross section of their data to understand the relative brightness of different objects in the image, and for imagers who want to visually see what is going on in their data collection in a new way.

Note that in order to use this feature, KStars must be built with the Data Visualization module installed. For the Mac OS X DMG, users can start using this function right away. We are working to get it into the Windows exe and Linux PPA very soon so that these users can also use this function right out of the box. But for now, Linux users would have to build from source with Data Visualizations installed to have these features.

To use the new feature, the user needs to select the View Star Profile Icon in one of the Ekos Module Views, or in the Fitsviewer. Then, the region selected in the green tracking box will show up in the 3D graph as shown above. The user will then have one of the following toolbars at the bottom.



At the far left, the sample size combo box will let the user select the size of the image crop shown in the graph. This option is only available in the Summary Screen, the Align Module, and the Fitsviewer. The second combo box lets the user control whether they are selecting an individual item, or a row, or a column of pixels.

The slice button will be enabled if the user selects “Row” or “Column.” It will put the graph in slice mode so that the user can see a cross section view of the image. Third, is a check box that will open up two sliders that will let the user drag the slider to change the selection.

This is extremely useful in the slide mode to change the selected point and to move the cross section around the graph. It is also useful in the normal view when in “Explore Mode” so that the user can zoom around the image examining the pixels. 


Then the user has the “Zoom To” combo box, which the user can use to zoom the graph to different preset locations. Next is the combo box that lets the user select the color scheme of the graph. Then are the HFR and the Peak checkboxes, which will both turn on the HFR and Peak labels on each found star in the image, but will also display one of them at the bottom of the screen. And finally comes the Scaling checkbox, which enables the Scaling Side Panel. In that panel are three sliders, one to control the minimum value displayed on the graph or “black point”, one to control the maximum value displayed in the graph or the “white point,” and a third that is disabled by default that lets the user control the cutoff value for data displayed on the graph.

This third slider is very useful to get really big peaks out of the way so you can study the finer details in the image. There is a checkbox at the top to enable/disable the cutoff slider.


And finally at the bottom of the sliders is the “Auto scale” button. This will auto scale the sliders as you sample different areas in the image. It will not only optimize the display of the data, but will also affect the minimum and maximum points of the slider.


If you disable auto scale, then as you sample different parts of the image, they will be displayed at the same scale. A particularly useful way to use this is to select an area of your image using auto scale, tweak the min, max, and cutoff sliders to your liking, and then turn off the auto scale feature to explore other areas of the graph.

Pages