Last week I decided to do a small evening and weekend project to improve my QML skills. As I had worked on quite some QML already for the new screen locker and the window switching layouts, I wanted to do something more complex, but still something to work on in the evenings.
Given also Marco’s post we slowly have to transit the Plasma Workspaces to Plasma Components, so it makes sense to look in the Plasma area for a widget which could use a rewrite.
I decided to try to rewrite our application launcher Kickoff in QML. There are various reasons for it. First of all I am somewhat familiar with the source base as I have in the past worked at least a little bit with it. The code is nicely separated in core and ui parts and makes strong use of Qt’s Model/View/Controller Framework, which means it’s very easy to add a QML based interface to it.
But most important I think that Kickoff is an applet which would benefit most from a QML port. As Kickoff uses the Model/View/Controller Framework it is QWidget based and embedded into Plasma’s Graphicsscene through a proxy widget. If you are familiar with the differences you can spot where Kickoff just does not fit with the rest of Plasma. E.g. the white background or the blue highlight which just does not look and feel like Plasma. Given that Kickoff is one of the first visual elements new users will see it is rather important to present the UI in a consistent and elegant way.
While it is still a work in progress and more a draft, you can get a feeling of the differences in this screenshot:
Thanks to the possibilities of QML all the data presented in the QML based Kickoff is currently just mock-data and not yet connected to the real C++ based Models. This gives the possibility to concentrate on the UI without caring about the required changes in the underlying Models.
My expectation is that after the QML port Kickoff should also perform much better. Removing those proxy widgets is clearly a plus and QML allows us to lazy load the data and view components much easier. E.g. in the mockup I presented all the data is loaded only when needed. That is if you only use the favorite tab there is no need to load e.g. the data for the applications. So overall a worthwhile project for learning QML.
Overall we still have plenty of Plasmoids which need a QML port, so get your hands dirty.
Before I close this part, I’d like to invite you all to Plasma Bug Days, which will be held this Friday and Saturday (December 2nd and 3rd), more info on Aaron’s blog. Come give us a hand if you want the 4.8 release to really rock!
With the inminent port of a lot of plasmoids to qml I think that a well defined plasma component HIG is urgent, Which would be the best channel to define some clear guidelines.
That gui mockup doesn’t look bad, but it could be a bit more like the shelf applet for example, which only highlights the current item (in the mockup desactivated items are half-highlighted), There are a lot of details like this that should be clearly written and respected unless there is a good reason not to.
I agree with this, the last thing we need is a bunch of willy-nilly looking widgets on the desktop. I always loved the balance of widgets and I hope they continue here.
completely right. defining a HIG before porting, and submitting all QML widgets to a open, shared, design review with the user in mind, is the way to take. mockups and mailing list.
for example, we need just one, 1, good, widget for file system management, incorporating and replacing folder view, stack folders, quick access, ..
widgets are poor as they are and KDE5 must be of class A.
I have enjoyed the KickOff menu style what Novell usability team made and I hope it does not get changed.
It means that the bottom tabs needs to be big ones, not just small ones like on the current mockup version with small tabs.
And same time the clarity when having a opaque background with all options instead transparent, but that is something what I hope is configurable, to have a opaque background and transparent way (like your mockup) what works when having a blur and text color being correct to background.
There are three things what I am worried about.
1) There will not be possibility to set own menu buttons (or just single menu button to desktop) for every KickOff tab (favorites, applications, computer, leave) and by that I mean person can set own buttons to panels or desktop and they open when clicking or hovering over them as panel. So no forced to have a huge menu open on desktop if placing widget to there.
2) The animation speed will suffer a lot with Plasma technologies. Now currently the KickOff is blazing fast and the selection and tabs switching follows mouse cursor very accurately. While widgets what use QML, are slow as….. You move cursor top of the list and the selection retancle follows much later. You move cursor up and down and the selection retancle lags clearly behind.
No, that is not what menu should be. The selection retancle should be stick to the mouse cursor, not being smootly animated as slow following dog after cursor.
3) The latest “improvement” of removing the “back” sidebutton in applications (good and bad thing) and replacing it with a very, very small breadcrumb menu on top right corner.
Please, make now the breadcrumb better with big button like the entries in menu are, the breadcrumb can be huge at always visible on top of the list so it would be easy just to swing mouse there and click, without aming to small letters. And start from left edge, as moving “Back” button location is bad. And to have even a constant look with dolphin and every other application what use breadcrumb by starting from left edge and adding current one to right of it.
I hope you really get the KickOff QML version really a fast, easy to configure and small and neat to be sticked to panels and desktop (just with button, not whole menu) with own widget buttons to tabs.
As currently the KickOff starts looking a littlebit old by the look of selection retancle.
I don’t get your number 1.
I only provided a screenshot. You cannot see how the selection rectangle moves. So be assured that in my current draft it is instant movement.
Yes I want to make them proper buttons.
Hello Martin!
While I’m not the author of the long comment above, I think I know what Fri13 meant to say with his #1.
There is this hidden functionality where you can pin single “tabs” of Kickoff (such as Apps, Computer, Leave, etc.) to the desktop as standalone widgets. That is, a button which opens a menu that looks exactly like Kickoff but contains only one tab.
So you can do this? I was looking for this feature for a long time. How to do this?
I was wondering about the back button – I’ve seen users who want it back, and if I were a heavy Kickoff user, I would too. The reason is that it’s very easy to hit when the application launcher is along the left edge of the screen (which it is by default). It’s much harder to navigate quickly with the breadcrumb. I thought the easily accessible back button was one of the key points of Kickoff.
Some have asked for an option, but I see little reason to not keep both the back button and breadcrumbs. How do you feel about this? I was going to try to create a patch, but seeing how you’re rewriting Kickoff, it doesn’t really make sense to do that now.
I think it’s very sad that Plasma looks so different from QWidget in the first place (Why does KDE’s workspace look so different from the applications developed by the same KDE project?), and I think “fixing” more plasmoids to pick up the unique Plasma look is the wrong solution. Plasma’s look shouldn’t be unique, it should be consistent with the rest of the environment, which includes the applications, not just the desktop workspace itself.
I’ve been complaining about the custom styling Plasma does to its QWidgets for a long time, and I think this situation where Plasma now invents its own components just makes things worse.
(I had to write “QWidget” resp. “plasmoid” instead of “widget” to make this post understandable at all. I’ve also been complaining about that ambiguous term for ages.)
Because it’s the workspace and not the applications.
“Why does KDE’s workspace look so different from the applications developed by the same KDE project?”
it was a conscious decision to make the workspace distinct from the application (though still look good together) so that it is clear where the application begins and ends. so when a popup is shown, it is instantly clear to the user whether this is part of their applications or it is “the computer”.
we found that this is an issue many people struggle with on other systems and having a nice delineation between the two helps quite a bit.
applications / documents are what you start and work with.
the rest is what the system provides for you.
But the difference is going to vanish soon with Plasma Active, isn’t it? So maybe it’s a good time to make even old QWidget based apps more consistent with Active apps and then help the transition to Plasma Components even for desktop versions to share as much code and design as possible between destkop and active (and no, I don’t want to merge it to one fit them all solution :).
“But the difference is going to vanish soon with Plasma Active, isn’t it?”
no. moving to QtQuick does not change the concept at all (it’s orthogonal: one is a design concept for multi-windows systems, and one is a software development tool). Plasma Active’s focus on devices does treat the application / shell separation slightly differently, and that’s because it’s a different usage style: one app visible at a time that is always full screen.
Classic menu in QML?! 🙂
it doesn’t need much porting. just an icon that can be clicked which shows the current popup menu.
it doesn’t require porting, really: just an icon in QML that triggers the current menu.
please feel free to contribute to that project if you use / love the old style menu.
“only loaded when needed” sounds nice at first but wouldn’t that cause a noticeable delay when Kickoff-QML is actually fed with lots of .desktop files, recent documents, etc.?
no more than there is currently, and in fact it will make the first show of the menu faster with each tab only needing to be loaded when shown. so its, at worst case, the same lag, but spread out over several different events. once all tabs are loaded, it would be instant switching.
and if the applications model is lazy-loading (not sure if it is; i seem to remember it isn’t) then it would all be a completely moot point.
I’ve always felt that Kickoff is out of place and doesn’t really match the polish of the rest of the desktop – the same goes for the side bar on Dolphin
I hope this rewrite helps unify the look of KDE in general
Nice work. Hope to see it in 4.8.
But could you please enlarge the bottom part (Favorites, Applications, etc) by default cause now it looks crappy if compared to the original one.
Sorry, 4.9 material – we are already in feature freeze.
As I wrote, it is currently just a draft 🙂
Well, it seems to be a good tradition:
all KDE users using 4.N are waiting impatiently for 4.N+2 🙂
Anyway, thanks again, Martin. I like very much the work you do and the posts you write.
As far as I know, the complete replacement of all Plasmoids for their QML counterparts is scheduled. The question is: is there any (relatively) easy way to test (say, a separate git repository, an QML replacement page in kde-look.org), or the only way to test the new plasmoids is to clone kde-workspace and hack the CMakeFiles to skip the version checks (that will surely require trunk releases of everything)
I’m interested in testing the QML Microblog plasmoid.
“the complete replacement of all Plasmoids for their QML counterparts is scheduled.”
small clarification: it’s not scheduled (as in: we know when it will be finished by) but it is a mid-term goal we have.
“The question is: is there any (relatively) easy way to test”
yes, grab 4.8beta1 (and the later 4.8 releases) and you already have one of them: the device notifier. you’ll also have all the bits and nobbles to test other qml widgets as they come out too 🙂
Great work, Martin! It looks so much better already, despite being a draft. It also makes me happy to see that the attempts to closely intertwine the KWin and Plasma efforts waaaay back was such a wise decision and is working out so well. You guys rock!
Nice to see improvements to Kickoff. I was fed up with the previous version (one of the things I don’t like is that you have to press 4 buttons to leave the Plasma Desktop: 1. the Kickoff button in the panel, 2. “Leave”, 3. one of the options in that tab, 4. the confirmation button in the dialog that appears after choosing one of those options; above all I hate the zigzag move that the mouse has to make to reach these 4 buttons) and Lancelot was too heavy for my needs (no blame intended, it is good that Lancelot exists in its current state, I only mean that for *me* it is too heavy).
So I decided to write my own launcher. As I wanted to learn QML too, it is a QML plasmoid: http://kde-look.org/content/show.php/AppMenu+QML?content=146098 It works already in KDE Plasma 4.7.x and I’m a happy user of my own work 😉 (as far as I ignore the bugs mentioned on the kde-look page). My plan is to move it to the PlasmaComponents and see how much bugs survive (I also hope that I will now get scrollbars for free on my ListViews as my current implementation for adding scrollbars to a ListView is ugly and buggy). Of course, any contributions are welcome.
You can disable the confirmation demand of logout/reboot/shutdown process. So you end up having only a two click system (it use to be single click as kickoff was possible configure to be opened when hovering on it).
Of course you can do as many clicks as you want, but you are not forced to do so many.
Great Job
Keep it forward 😀
I take advantage of the presence of Aron and Martin to ask something off topic, since now all have their most famous OS Market, App Store etc.. well do not think that his use of kde kde.look could improve in this respect with a polishing kde.look site in the future?
Anyway, congratulations on the work with Kickoff QML looks great, thanks for your efforts;)
Sorry for my bad English
kde-look.org and everything else from opendesktop.org is provided, hosted and developed by h i v e 01 gmbh and not by KDE. I’m sorry but we as the Plasma development team have no influence on the web site.
I suspected, but thanks for the KDE risposta.Comunque is true that with the ability to install directly from the various themes that takes advantage of its tools is better than other kde.look DE.
Anyway good job with Kickoff;)
Quick question. Are the individual UI widgets such as buttons and scroll bars configurable or even better theme-able?
For example i find the scroll bars to be about 25% to wide and i don’t like the way the grey of the buttons/tabs sit within the overall theme.
Also could i propose a small change to the bread crumb navigation. I think the bread crumb navigation works well with tree menus, although i think having it left aligned would improve usability.
I think it makes more sense to have the root of the tree not move across the screen as i drill down into the menu. Knowing that it’s always the very top left to get back to the beginning makes it more instinctive IMO.
Right… I’m off to install kde 4.8, keep up the good work
KickOff needs to be designed so it works as widget on desktop or panel. And that it can be located to panel a side of the screen or top or bottom.
That was one of the design flaws with the original menu “back” button what was on left side of the kickoff and was size of the height.
It really were easy just to swing a mouse to left and click, but it only worked if user had kickoff located to bottom or top left corner of the screen.
If user set it to middle or even little bit away from the left corners, it came impossible to swing mouse to side and click to get back.
I think I would take gladly just the “Back” button top of the list (being located bottom when having KickOff on top of the screen so menu is up-side down) what is permamentally located there and every menu entry goes under it.
As it might be better to have just single button to back, what needs +n clicks if browsed +n in the menu and is easier to click as back button would be size of the menu width, than having a breadcrumb what gives single click possibility to go any step back, but is harder to click to go one step back if deep in the menu hierarchic.
Example if the top of the list would have full width function to get back one step per click or breadcrumb.
1. [All applications][Menu entry 1][Menu entry 2]
2. [ BACK ]
(If formatting is not gone) You can see option 1. is easier by choices to go from 2 to all, but clicking back to 1 is harder than in option 2.
As now the kickoff looks like:
[All apps][Menu 1][Menu2]
[Entry 1 ]
[Entry 2 ]
[Entry 3 ]
[Entry n ]
So the clicking back is very hard, especially because it on right and small boxes.
[ BACK ]
[Entry 1 ]
[Entry 2 ]
[Entry 3 ]
[Entry n ]
Martin, this is just awesome! period!
Hey Martin,
I just want to say thanks for all the hard work that you are pouring into KDE, and also to congradulate you on sticking to your vision. I know that it’s not always easy when there are a million comments on why you’re a moron, or doing things wrong. But, ultimately, if you make decisions to keep everyone happy, you end up making no one happy.
There is one thing I would like to ask about though ((sorry about putting it here, but it’s a really simple question, and I understand it falls in your domain)):
Window Tiling. Back when it came out, I thought it was completely awesome! Having windows automatically resize so that everything fits onto the screen. But, unfortunately, it was a bit of a hassle to turn it on and off, and was a little too annoying to leave on full time. So I was wondering if there was a shortcut key. Press it too quickly snap everything into place, and then continue working as normal. And perhaps keeping the shortcut key pressed in if you want to drag things around like it does when tiling is enabled.
Anyway, thanks for all the hard work, hopefully you’ll be hearing more from me next year with the Summer of Code 🙂