Early this month I pushed the QML shutdown dialog implementation I did for basysKom:
OBS: I think QML does not support passing other variables as default value for properties between { } like in the line:
The looking is almost the same as the old one, but if you program in QML you can change it. I think you can also use Qt Creator to create new themes for ksmserver.
The default theme above resides in $(kde4-config --path data --locate ksmserver/themes/default/). There are four .qml files, one .js and one .desktop there. main.qml is the most important one. Basically main.qml is the dialog and the only requirement for it is emitting the signals to actually trigger actions:
signal logoutRequested()
signal haltRequested()
signal suspendRequested(int spdMethod)
signal rebootRequested()
signal rebootRequested2(int opt)
signal cancelRequested()
signal lockScreenRequested()
spdMethod is one of values of the enum Solid::PowerManagement::SleepState (StandbyState, SuspendState or HibernateState). StandbyState is rarely used nowadays but still supported.
The opt parameter in rebootRequested2 contains the index of the chosen boot option in the reboot menu (more on that later). The rebootRequested() reboots the system without changing grub's configuration. The other signals are self-explanatory.
Some important information are passed as QML properties from the C++ ksmserver to the dialog:
- bootManager: string identifying the boot manager installed on the computer. It can be "Grub", "Grub2", "Burg", etc.
- choose, sdtype, maysd: those are the same parameters (in the same order) used with "qdbus org.kde.ksmserver /KSMServer logout x y z" and KWorkSpace::requestShutDown(ShutdownConfirm, ShutdownType, ShutdownMode). Read /usr/include/kworkspace/kworkspace.h for the long explanation about them.
- rebootOptions is a hash (associative array). rebootOptions["options"] is string list containing the OSs configured in grub. It is used to create the boot menu in the screenshot above. rebootRequested2 passes the index (starts from zero) of this string list as parameter. rebootOptions["default"] is the index of the current selected option in rebootOptions["options"].
- ShutdownType and spdMethods are the Javascript versions of the enums KWorkSpace::ShutdownType (/usr/include/kworkspace/kworkspace.h) and Solid::PowerManagement::SleepState (/usr/include/solid/powermanagement.h). Added as convinience so that you do not need to use hardcoded integer values.
contextMenu.append({itemIndex: spdMethods.HibernateState, itemText: i18n("Suspend to &Disk")})
spdMethods.HibernateState is equal to 4 but itemIndex is 1 when I read it. I had to use hardcoded values in shutdown button's menu to avoid this problem.
20 comments:
Sweet jesus, does it mean we finally get shutdown menu that is free of 3 black corners without compositing?! It's been 4years people!
@Anonymous, no. I already answer that question a couple of months ago in my other post about this implemenation:
The black corners happens because compositing is disabled in your setup. Once it's enabled then kwin will be able to properly make the black rectangle behind the dialog fully transparent.
PS: I cannot force the shutdown dialog be a perfect rectangle. The borders used in the dialog is controlled by the plasma theme you are using.
Lamarque, I know you lot do not fit with what I'm saying, but really guys, kde is the best there is around, your work is fantastic, but please, find someone to care for the HIG KDE 5.
The only thing it lacks is the KDE look and consistency of the GUI, in this respect have much to learn from Ubuntu.
This is not intended as a message from trolls, I apologize if indeed not to blame.
I love kde and why I say this.
@Anonymous, like wrote a couple of weeks ago in the Brazilian KDE mailing list: boring things like usability and extreme high technical things like Solid (hardware abstraction layer) have no appeal on developers. Developers like doing new stuff and following guidelines is something people do not do by theirselves, usually that is pushed on to them by their employers, which is not the case for most KDE developers, that are not payed to do their work.
Ubuntu is a basically a company's product (from Canonical). Their developers must follow the guidelines Canonical creates. In KDE we are not forced to do that in any way.
I am just explaining why I think things are like they are. I agree with you that KDE should be more consistent in the look, but try to convince a developer that works for free that he/she should do a boring and time consuming work just because somebody else thinks his/her program is ugly.
@ Lamarque
It 's true, you're right, I apologize if they are off topic, but I just say that even small teams as well as Elementary OS but free as Gnome team, in this I managed to have a better organization, I say only because I love kde, and this is a shame!
I think that the time for KDE5 is on your side, and perhaps this is the time to talk about this, or never.
Maybe you should organize a team in kde that addresses this, I've seen people here on Planet KDE which is sensitive to this as Matthias Klumpp, but also others.
I really apologize for off topic, and thanks for your work, just love kde :)
Gnome has Redhat behind them since the begining. Why do you think most standards used in Gnome are in fact developed by Redhat's employees. Nowadays Gnome is almost a Redhat's product.
About black triangles: everything would be ok if there was 4 of them, but one corners is displayed properly so what the hell? Nobody cares because it's small "not cool" stuff to repair.
About HIG: this is really really good idea for KDE and was mentioned by many people before. I understand that you as a developer who doesn't get paid for it like to do only "cool" stuff and "new" features, but we as users are upset about "boring" stuff like bugs or fricking GUI inconsistency. You're right KDE is not driven by company but people should new that without good captain ship is doomed.
Let's thing for a second about this: there is developer who want to do application, he like kde so he join kde world, he make application but as a developer knows nothing about usability so we have buttons in shaped of pink rhino because he thinks that's cool and there is no GUI guidance to follow... that's how it works now
How it should be: it should be like in companies, people are focusing on delivering product (as open source is awesome software that will change the world), coders are coding, designers do the design - BUT ALL ARE FOLLOWING ONE MAIN DIRECTION. Coders don't code GUI as they think it'll be good but as design team decided - so all application will follow the same pattern and style. What comes from that? Happy users! You developer who use kde, john doe the designer who use kde, me who use kde. Everybody happy, the end.
How is it now? you are making code for network management, you need to think about how gui needs to work and implement it as you think will be good instead of focusing on code itself. AND THAT THING IS GOING ON FOR EVERY APPLICATION FOR EVERY DEVELOPER. What's good from that? Not much, layout is far from pixel perfect, applications have same options in different places, system settings is one big dumpster where finding something is like memo-game and so on...
about gnome: yeah is different but it clearly follow one vision and it's polished! what about kde? yeah it's awesome from wider view but not so much under the closer look - just because those little "boring" to fix stuff
disclaimer - don't want to sound disrespectful, we all love kde
@Anonymous The only thing you get is a dead project.
@Anonymous, I think "nobody cares" about this bug because it is way simpler just enable compositing. Why don't you do that? I guess an extremelly small percentage of KDE users currently do not use compositing. Also, when compositing is disabled in my notebook ksmserver paints the whole background in black. I guess it does that to workaround this problem. By the way, I am not a kwin developer, I do not know how to solve this problem without using compositing.
The HIG do exist (http://techbase.kde.org/Projects/Usability/HIG, http://techbase.kde.org/Projects/Usability) but as I said, most developers do not know about them or do not extrictly follow them. By the date on the first page (March of last year) you can also see that it is not oftenly updated. Maybe because writing HIG is boring and few people does that without a very good reason. The last update on the other page is even older.
I am one of those that do boring stuff from time to time. But I not a GUI guy, yet I try to fix GUI problems too, but some of them are impossible to fix and sometimes even workaround.
I prefer to fix bugs and make things correctly work. Most of the problems I have fixed in Plamsa NM are not related to the GUI. I cannot stop fixing those kind of bug just to invest on the GUI. I do not say for me to do both.
If you want HIG to be followed you should make the effort to make them available to the developers. Step up and try to find who write HIG in KDE and try to help him/her. kde-usability@kde.org is a good start. Complaining here will lead to nothing. I am already aware of them, I just do not have time to do my real life work, improve Plasma NM GUI, fix bugs and solve several other problems in Plasma NM that no KDE user probably know about but that needs fixing.
It's nice to see more and more of KDE Plasma Desktop being ported to QML. It would be cool if someday everything in KDE could be "themed" in just QML and SVGs.
Thanks for your work!
@Anonymous:
The default theme is optimized for compositing.
But no-one forces you to use it!
You have two choices, both very simple to do:
a) enable compositing
or
b) select another theme (in System Settings) which is better optimized for non-compositing
Where's the problem?
@Lamarque thanks for info, those black triangles are just example of those little things that are making kde feels more like a student work less like a awesome amazing blow your mind community (which most of the cases is ;)
about those little things - it's exactly my point, you as a developer should care about code and bugs, for gui you should have detailed cheet sheet and mockups from design team and not think about it just make gui as they want and care abut your favorite thing - code ;)
The last time I checked the buttons had no fade-in-effect on hovering them. But maybe this is a general Declarative Plasma Components issue.
@kuha, thanks. The idea is to port most things to QML when that means an advantage. The device notifier in 4.8.0 is already QML, the lock screen in 4.9.0 is going to be QML based too and several other things are going to be porte.
@Anonymous, I am pretty sure most users do not care about those triangles since they do not see them if they use compositing and most users use compositing.
@BajK, what do you mean by fadein effect?
You hover the button, in 4.8 the "hover effect" fades in. In the QML variant in 4.9 the button just switches to the hovered state with no nice transition.
@BajK, ahh that fadein effect. That's not bug, when I have more time I can think of implementing it.
Lamarque: you say that this theme uses some .qml, .js and .desktop files. Does it mean that new dialog basically obsoletes all plasma themes out there (dialogs/shutdowndialog file)?
Also, I disagree that you can't make people follow guidelines. Look at Debian - they have strict license policy, package policy, package workflow etc. Writing debian/copyright file is boring as hell (you must note each license that ever occurs in source code and associate each file with license). But all their package maintainers write that file and follow these guidelines, most (all?) of them volunteers.
I believe that rationale behind following HIG is so strong, that most people can be convinced to follow them. After all, they are not about making anyone's work harder - they are about providing better user experience.
Hi Lamarque ..
you might find this interesting topic.
check it out :
http://forum.kde.org/viewtopic.php?f=66&t=106981
Hi @Lamarque
check this out :
http://forum.kde.org/viewtopic.php?f=66&t=106981
@Mirosław Zalewski, the default QML theme uses the legacy Plasma shutdown themes, so everything should still work except for some themes that are broken (do not follow Plasma's specification). Broken themes usually lack the dialog's border.
Writing Copyright files is not like HIG. Usually who writes HIG are not the one that uses it, the developer are. Asking a developer to write a copyright file is boring but the developer can do it because the copyright file does not cause troubles to compile/run the software. The HIG on the other hand can cause conflicts between the one who writes it and the developers who should follow them because it affects how the software is implemented.
Does Debian has HIG for the desktop environments they ship?
Post a Comment