Hi,

It’s not the first Qt class that i’m making usable in QML and will certainly not be the last one. Even better would be singleton components because you really don’t want two of these components in one application, something that is possible in Qt5 if i’m correct.

Note: It has been suggested that i make this as a plasma service. I do wonder, what’s the benefit over a component? And how to even make a service? Making this wrapper class is really easy, is it even easier with services? Making this wrapper was really easy and only took a few hours.

Without further delay, here is the “Clipboard” QML component free for you to use however you like.
clipboard.h

And the clipboard.cpp file:

You obviously have to register the class in QML as well. Look in my other posts if you don’t know how to do that.

Now using this class needs a bit of documentation. First, you have to add it to QML which is as simple as adding:

Lets say you want to paste the content of the clipboard. For that i take my Shortcut element as example, look at the following code:

This happens to be an example for CTRL+V (pasting). clip.paste is where the magic happens. All you have to do is provide a location (with the protocol in front of it like “file://”). Then the files that are on the clipboard will be put on that location.

If you want to copy/cut files you have to go through some more trouble. This “trouble” is there because QML doesn’t properly allow arrays to be filled after they have been defined in “property variant someArray”. This has been resolved in Qt 5 where “property var someArray” works just as you would expect from a javascript array.

So, in the above Clipboard QML component you have one function to fill the url: clip.addUrl(file:///your/url/to/anything/). If you have multiple urls you have to add them all – one by one.
clip.addUrl(file:///your/url/to/anything/one)
clip.addUrl(file:///your/url/to/anything/two)
clip.addUrl(file:///your/url/to/anything/three)

Another function you have is clip.urlList() which just spits out your url list. There is no remove/clear/anything else for the url container.
Once you’re done adding url entries you call clip.cut() or clip.copy(), depending on what you want to do. After that point the files (urls actually) will have been placed on the clipboard and the url list will be cleared ready for the next job.

That’s about all there is to know for this wrapper.

Hi,

I wasn’t quite sure how to name this subject so sorry for the slightly vague title.

The case is as follows. I’m right now developing an application in QML for KDE (like the QML Calendar) and i’m finding myself in the position where i need to define application wide shortcuts for certain features/events. Hence the recent posts about application wide shortcuts in QML. Obviously defining the shortcuts inside the application would work (and is currently working just fine) but i was wondering if it can be done differently and perhaps better.

That’s when i got the following idea. Why don’t we – KDE – completely remove all shortcuts from the applications and instead let the applications register their features that could benefit from a shortcut in some global KDE wide “feature to shortcut” manager? In other terms: “apps don’t register shortcuts, but register the features where the user can assign a shortcut to”. Still vague? Here is a more practical example. In this case i’m taking Dolphin as the example since we all know that application.

Lets say that dolphin has no shortcuts in it’s application but rather registers the following features:

• reload
• back
• forward
• home

Then in KDE there has to be an app that does feature to shortcut translation like so (actually exists and is called Shortcut Manager):

• refresh
  • F5
• back
  • Mouse back button
  • backspace
  • alt + left arrow
• forward
  • Mouse forward button
  • alt + right arrow
• home
  • home button (some keyboards have that..)

This is how it would look in QML for an app to register the refresh feature and how to use it:

The syntax is roughly the same as my earlier Shortcut {…} component.

So you might think: “why not use a shortcut directly?” and perhaps you even wonder why i’m making this suggestion at all. There are a couple reasons for that.

1. If the shortcuts are managed from one single point then applications themselves don’t have to bother managing them thus less to worry about.
2. The most important point is unification. Right now the shortcuts in KDE applications are wildly different between apps. Just look at opening a tab in Konsole and in Dolphin for example. If the shortcuts are all managed from one central place (and  if apps actually obey that) then you will see a perfectly unified shortcut handling throughout KDE apps. CTRL+T will be a new tab in every app then.
3. It will become a lot easier for users to change default shortcuts since it’s all in one place! So if a user wants to have the refresh feature done by the F12 key rather then the F5 key then it’s just a simple matter of changing it once in the shortcut manager and all apps will obey to the new shortcut.

KDE, as one of the very few desktop environments, has a full featured shortcut manager. Shortcuts can already be managed through the existing KDE Shortcut Manager and the above idea might in fact already be possible to implement (not 100% sure yet).

One downside of all of this is when an application is not developed for KDE specifically but rather Qt only. In that case this suggestion won’t work so there it might be wise to have a fallback mechanism in the above qml that looks like this:

in which case the “FeatureRegistration” component would just be a Shortcut {} component.

What’s your opinion about this idea? Is it worth a try to get in KDE and get all current and future apps in line by using this mechanism? Note: if this is done then the FeatureRegistration will obviously also be a C++ class so that non QML apps can use it as well.

I kinda like this idea. Specially because it could finally tackle the very annoying issue of shortcuts not being unified between applications and it gives developers a very easy way to use shortcuts in a unified manner.

Cheers,
Mark

Update

It might be important to add a small update here. The CTRL+C shortcut is a very interesting one (among a bunch of others). Inside a application that CTRL+C might mean completely different things. For example in dolphin that will copy a file, but in konsole it will abort a running application. So lets think that the Shortcut Manager has this:

• copy
  • CTRL+C
• quit_running_app
  • CTRL+C

Now it’s not the shortcut manager that decides CTRL+C will quit your running application with CTRL+C or act as copy command. That’s up to you to decide. This is how it would look in QML for Konsole:

And for dolphin:

I hope that clears up a little confusion. Note that in this case i took strings as “feature” value. If one wants to add a custom shortcut that isn’t registered in the shortcut manager application then just defining the “fallbackShortcut” to whatever key combination the user wants should work as well.

Hi,

In my previous post i was using QShortcut to get application wide shortcuts. I didn’t like that route because it depends on QWidget, but i didn’t see any other option back then. After a little bit of discussion on how to get the same stuff working without QShortcut (thus no QWidget dependency) i started trying the same using Qt’s event filter system. That turned out to work rather nice! Because there is no more need for QWidget, the somewhat ugly trick to put the QWidget based mainwindow in a global class isn’t needed anymore. The C++ side looks as follows:

shortcut.cpp

And the header, shortcut.h:

Making it available in QML is done the same way as in the previous post:

The reason that this works is because of the re-implemented eventFilter function. That filter listens for key events and if it finds one (and if that one matches the one we registered) then a signal is emitted to indicate the application that the registered key has been pressed. It’s really that simple. The filter is registered in the class constructor through qApp->installEventFilter(this); That’s all i needed to do to get is working.

In QML it still looks as simple as this:

Right now this is not part of any KDE QML imports, but i do want to try and get this specific component in QML. It will help other applications as well if they happen to need this functionality.

Cheers,
Mark

Update
Updated the code to reflect all the suggestions from the comments. The QML side still works exactly the same, but has an additional signal that will let you know when the key has been changed. Changed! not triggered! That is still a separate signal. Also added a bool: m_keypressAlreadySend in an attempt to prevent double signals which was happening all the time.

If you know QML and have worked with it for some thime then you probably say: not possible. QShortcut requires a QWidget thus you cannot use it in QML.

The simple answer is indeed: not possible. The more complex answer is interesting. Yes, it is possible by using a nasty trick! However, it’s only possible if you expose your custom QML “QShortcut” through your main application since you need the widget of your main window. You cannot do the trick that follows in a plain C++ plugin to add some QML components.

So, how did i do this? We obviously need a QWidget in every QShortcut instance so to get that i made a global static singleton class in which i get/set my main window. I set it in the application context and get it in the “QSortcut for QML” context. It looks somewhat like this:

Util.h

That gives you the singleton. Now in the applications main context you have to set it’s main QWidget window. In the case that you are making a QML application you likely have a main that looks somewhat like this:

Note the line i added with: “Util::instance()->setMainWindow(&viewer);”. This works because the viewer object is (deep down the stack) inheriting from QWidget.

That’s all you need to add to your main for now (besides obviously the header for your Util class). Next up is creating the actual QShortcut component for QML. I’m using QShortcut here and not KShortcut. Please do note that KShortcut and QShortcut are completely different! A KShortcut just sets a primary and alternate shortcut which you can then set in a KAction. You can;y set a shortcut and listen for it which you can do in QShortcut. They are just two different beasts which you should not mix up.

QShortcut in QML. I named mine “Shortcut” and the code for it looks as follows (shortcut.h):

As you can see, a very simple clean component. Only a key can be set and a signal for when that key is activated (pressed).
And the source looks like this (shortcut.cpp, this is where the magic happens in one line):

Now the most important line here is the first line (m_shortcut ….). There i’m creating a QShortcut object in which i’m setting my main QWidget (the one i had set in the main file). Without that (little nasty) trick it doesn’t work. I really wish there was a nice way to add application shortcuts in QML, but apparently nobody has ever needed that before because there is just nothing out there that i can find. Yes, QML has the Keys{ … } stuff, but it’s not application wide.

Now all you need to do is expose this “Shortcut” class to QML so you can use it. Open you main.cpp again and simply add it as follows:

You obviously have to include “shortcut.h” in here as well. Now pay attention to the text: “Project” since that will be your import line. In QML to use this Shortcut it looks like this:

And that’s it. It’s that easy and clean! This does come with some notes you should be aware of. Since these shortcuts are application wide you should NOT add a shortcut inside a listview or so. Just make sure you only add them once for your own sake. Another limitation is that you can only set one key as shortcut. You can’t add a modifier or more keys. So a shortcut like CTRL + A isn’t possible in the current code. This however is just something you’d have to implement to make it available. It’s not difficult and the functionality is already there in QShortcut. You just have to make it available in QML. And that exact part is a bit tricky of you want multiple keys to act as one shortcut. Or you could just expose the string based shortcut and you’re done ^_-

That’s it for this hopefully helpful post about application wide shortcuts in QML applications. I hope this comes in handy for those that need it but don’t know how to get there.

Cheers,
Mark

Hi,

Today i read this post on the planet and it made me think: “can’t we use that already? It’s just a font..”.

It actually is quite easy to get it working. All you need is QML and the ttf font. This is what you need in QML:

And that’s it. That allows you to use the quite nice monochrome icons. You obviously need to change the location to wherever you downloaded fontawesome-webfont.ttf. Which you can be found in the download package from FontsAwesome.

There are a few things to know here. First, take a look at the available icons. You can’t use the names described in that page. But you can use their unicode key which you can find here. Now if you see an icon that you, for example the “icon-ok”, you type on this page (just using CTRL + F). There you will see that the unicode key for “icon-ok” is: “\f00c“. Putting exactly that in QML won’t work. Unicode keys have to be prefixed with “\u” so in this case you simply add a “u” after the slash and you’re done. The results is: ”\uf00c“.

That’s it. Easy right :)

Cheers,
Mark

Update

Somehow the “FontAwesome.ttf” in the root of the download package from their site isn’t working with the way i described above. You need to use the “fontsawesome-webfont.ttf” which you can find in the “font” folder of that same package.

Update 2

Since some people don’t like putting in unicode values in the text value, which i can perfectly understand, i made a translation array. Save the following as “fontawesome.js”

Now in QML you can use it as follows:

In my case i named the array “fontawesome.js” which i then include in QML as “FontAwesome”. Then in the text part you can use it with FontAresome.Icon.<the icon you want>.

When naming all the icons i went for camelcase with the first char as capital as well. I couldn’t do “icon-ok” because a “-” isn’t allowed in variable names in javascript. Good luck using it!

Hi,

Easy huh? Heh! Not really. It took me quite a lot of trial and error just to figure out that i can’t get it working without setContextProperty. Though i didn’t leave there. I opened a topic about this on the Qt interest mailing list. The example code is as follows:

pathmodel.h

class PathModel : public QStringListModel
{
public:
explicit PathModel(QObject *parent = 0);
};

Then i made a custom “utils” class where i just make some random functionality available. Like so:

util.h
class Util : public QObject
{
Q_OBJECT
public:
….
Q_INVOKABLE PathModel* pathModel();
Q_INVOKABLE QString testString() { return “some_test_text”; }
….
};

Then i have the main file where i create the QML context and load a QML file. Just the default stuff when you make a QML application through QtCreator. It looks like this:

Q_DECL_EXPORT int main(int argc, char *argv[])
{
QScopedPointer<QApplication> app(createApplication(argc, argv));

QmlApplicationViewer viewer;
viewer.setOrientation(QmlApplicationViewer::ScreenOrientationAuto);
viewer.setMainQmlFile(QLatin1String(“qml/Porpoise/main.qml”));
viewer.showExpanded();

return app->exec();
}

The above helps understanding the context. In the above you can already see that i want to send the Util class to QML. I do that like
so:

Util util;
viewer.rootContext()->setContextProperty(“Util”, &util);

Now in QML i call:
Util.testString()
Reply: “some_test_text”

That is es expected. Nothing wrong.

Now if i call:
Util.pathModel()
Reply: undefined

That surprised me. undefined wasn’t what i was expecting. The solution to get this example working was very kindly provided by Robert Voinea. His exact words:

For QObject-derived classes their properties are exposed to QML and used through the QObject interface.

Also with an example. All that was needed was adding (in util.h below Q_OBJECT):

Q_PROPERTY(QObject* pathModel READ pathModel CONSTANT)

And obviously removing Q_INVOKABLE from the pathModel function.
Then calling it in QML like so:

Util.pathModel <– no “()”
Reply: PathModel(….)

That works like a charm. Using it right now. I am really amazed that this kind of vital information is not easy to find in the Qt documentation.

Oh well, just posting this in here because it will probably save some other folks a lot of time figuring out the same.

Cheers,
Mark