Isn’t that obvious with some rough calculation. If a programm is 10x slower it means it uses approximately 10 times more cpu instructions. That equates to a 10x power consumption increase.
Maybe I am missing something, but doesn’t power consumption scale linearly with execution speed.
Could I just build and run it without the system one’s being updated?
Yes, that’s its purpose. You can build and run normal apps like kdesrc-run dolphin. But that doesn’t quite work with the desktop itself. So after you build plasma-workspace and plasma-desktop, there should be a build/plasma-workspace/login-sessions/install-sessions.sh that install your custom-built KDE side-by-side with the system one. And you can choose it (“Session”) in your login screen.
I consider myself to be language agnostic developer and I have worked with many languages and tools during my career, like delphi/win32, C#/.NET, java, ruby, php, python etc. My only experience in C++ was through my (limited) contributions to KDE and I guess Qt made my life a lot of easier on that.
I guess (please correct me if I’m wrong, because that’s just my understanding) learning new tools/languages wouldn’t be an issue for the “core” kde developers. I also believe that many other “seasonal” contributors (me including) wouldn’t have a hard time in learning any tools based on the work done by the “core” devs. I’m saying that because it seems to me that the resources available on how to contribute to kde are really great and very helpful, so anyone who is able to catch up with the current tools/languages shouldn’t have issues on catching up with any tool/language. If you are a seasonal contributor like myself just think of you first contribution and your initial dive into the kde ecosystem. Seems like the fear/hesitation/whatever “learning new tools/languages” is more of a bias/prejudice than of a real issue.
The question to ask imho is if we could still rely on the underlying QT framework. Also the second important factor is the time and effort needed by the “core” kde devs to make a transition to new tools. If that can be done then I guess many contributors would just follow.
No, it’s not obvious because you can’t say for certain.
There’s not an inherent correlation between program speed and the number of CPU instructions used. Nor does that mean that it means it uses more power either. (Not that I’m saying this isn’t the usual case.) But it’s something hard to make blanket statements about without narrowing it down to a single program.
Thats not exactly how power consumption, executions speed, and instructions used correlate. CPUs and GPUs have a volt/frequency/power consumption curve and dont draw power linearly and thats whole can of worms that delves into things likely beyond the scope of this discussion with specialized hardware,etc.
That also doesnt even consider you can have code that basically does almost nothing and using few instructions but can peg a CPU/GPUs utilization so its doing no useful work but wasting power.
TLDR, none of those things directly correlate to each other in reality
Edit: trying to quote the right post… 
This is definitely the case for CPU-heavy work, but can be countered is business-logic style apps by the ease of using better data structures to solve stuff. I’ve seen code that uses lots of looping be put into python and use dict’s for lookups, and be 100x faster than the original C.
(Note that I haven’t used the Qt Python bindings, but I did skim through the Kirigami Python tutorial and I have done Python GUI development at a previous job using tkinter) My concern about encouraging Python for development is that it is much harder to develop a reliable GUI in Python than in a compiled language. The amount of potential runtime errors you have to avoid is extremely high, and in my experience as the program gets larger, the likelihood of a user hitting a runtime error grows exponentially. My rule of thumb now is that if a Python program grows larger than a single 500 line file, I rewrite it in something else before it becomes a liability. If you’re valuing reliability, stability, and ease of maintenance, I don’t think Python is the right option.
I will say that anyone who hasn’t done Qt development and is worried about how complicated C++ is should really give Qt a shot. It adds a TON of functionality to C++, and gives you a standard library similar to Java’s. Of course you still have to know about general low-level programming stuff (manual memory management, stack vs. heap, pass-by-reference vs. pass-by-value, etc) but it’s overall much nicer than vanilla C++.
Note that KDE has moved (and is moving) a large part of its UI to QML, which is based on js, not a compiled language.
JavaScript is used for simple interaction with the UI elements. For the actual business logic the application still rely on C++ (libraries).
QML is still compiled, but I doubt compiling is the problem for most people. I think what you mean is that it feels dynamic enough. It’s the additional complexity of older statically typed languages.
TBH, I dislike dynamic languages and don’t consider them fit for complex applications, but I do agree with bringing the down the barrier of entry.
This makes it worse no? Having another way of doing things when there are already 100000000 million ways of doing thing doesn’t make it less complicated. Now a new person who wants to contribute something entirely different which almost certainly will never be used anywhere else.
It honestly is a complete mess of software development and as someone who do coding as a hobby I have less than zero percent interest to even touch this part.
I am more than happy to even learn about these things but the worst thing is that there is no way to even learn C++. No matter who you ask you will get a different answer and it is not like physics chemistry where no matter what you learn at the end everything is same but in C++ every single thing is different.
C++ is a great language for proprietary projects where you need people to work on it for most of the time for open source projects where there are small contributers it is terrible.
And I have not even said anything about multiple compilers, no build system, no library management system… Just thinking about this make my headache…
Not at all.
It is one of Qt’s strengths that it provides a consistent API across multiple problem domains.
Very similar, as @ndiddy wrote, to the Java standard library.
It allows developers to easily transfer knowledge gained on one aspect to working on another.
For example moving between UI and non-UI code or between applications and services.
It also makes it much easier to learn C++ than most other frameworks because it adds a lot of convenience that other APIs are missing or even explicitly avoiding.
When I encountered Qt in around 1999/2000, I had plenty of experience with Pascal and Java but had failed at getting into C++ on several attempts.
Qt was a complete game changer, making not just easier but also fun to learn C++.
Just by reading a few replies on this thread I find plenty of basic, but common, misunderstandings:
The wrong language in the right context is the best language.
If you are using a library or framework, the language it uses is always the easiest language.
Most code readability doesn’t depend on the language, but on the programmer itself.
Qt heavily simplifies C++.
Knowing a programming language is the easiest part about programming.
The important part is problem solving. Figuring out the simplest solution, how to interact with other components, and how to architect things to fail in the best way possible.
To learn a language you don’t read a book. You start testing, little by little, if your code works.
Any code broken into the smallest parts is self obvious, independently if you are proficient in the language.
Wouldn’t Lua be better suited for this?