That's because you emerged it before the pkgmove. As I said, this is a temporary bug, a fix is pending, let's hope it gets merged tomorrow._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

You don't have to copy the files into your own overlay, after all you miss out on any updates that may (or may not) happen there. You can bulk mask all of kde-sunset adding '*::kde-sunset' to package.mask._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

You don't have to copy the files into your own overlay, after all you miss out on any updates that may (or may not) happen there. You can bulk mask all of kde-sunset adding '*::kde-sunset' to package.mask.

True, but:

I do not expect to see updates any time soon, since kde-sunset has no maintainer

Many ebuilds are broken (old EAPIs etc.) and play havoc when I eupdate esearch.

Ah, indeed that is possible. Well, it is only unmaintained until someone steps up to do the work. So far, no one. Patches can be applied though if e.g. sent via bugzilla._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

I knew this day would come, but it is very frustrating none-the-less (ever-the-more?). My hacked together, duct taped KDE system needs to either (1) go all the way "forward" to Plasma 5 and friends or (2) using kde-sunset, go "backward" to a *sane* non-hacked Plasma 4 (or hell, go back to 3.5.10 and never worry about it again! - not realistic, joking ... mostly). Note, by hacked, I'm referring to all the steps we've had to do in this thread to keep Plasma 4 going.

I really only need the most minimal of minimal KDE installs. I use konsole, juk, clementine, and the current "kicker" (the old panel app) portion of the base KDE. I often make use of KDE's auto-mounting to simplify offloading data from USB devices.

My question is about steps 1 & 2. What is the best way to mask all plasma 5 and to unmask plasma 4? Secondary question: how to undo the masking of Plasma 4 that is currently in the main portage tree? (that might be taken care of by unmasking packages out of kde-sunset).

I assume for step 1, something close to this (from other KDE5 masking threads):

I really only need the most minimal of minimal KDE installs. I use konsole, juk, clementine, and the current "kicker" (the old panel app) portion of the base KDE. I often make use of KDE's auto-mounting to simplify offloading data from USB devices.

I find it strange that you won't upgrade if these are the reasons why you want to stay with 4.

I'm running plasma 5.9 and it's outstanding. By far the best DE I've ever used and I was really mad about being "forced" to upgrade but eventually decided to get on the wagon instead maintaining my KDE4 install.

...especially the big kdelibs-4 blob having been split up into tiny kde-frameworks/ packages would align well with those reasons..._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

KDE * 5 is full of regressions compared to KDE 4.
It got so bad that I have recently started documenting all new regressions as I find them. I am not happy by the way a whole suite of products that had not yet reached feature parity compared to the previous stable branch was pushed down our throat by removing support (both upstream and by the various distro packagers) to that otherwise very useable branch (KDE 4).

Another regression that I can't wait to fix is the ability to grab a maxized window by any of its border and resize it vertically or horizontally, exactly to the dimensions we want, very quickly and very efficiently. Right now, to achieve the same within KDE Plasma 5, it is a battle of wills between me and kwin. I usually win, but not without my ego bruised. I no longer feel in control.

As a Linux advocate and as a software usability advocate, I have started a serious crusade against regression and against the loss of user application settings (plenty of such occurrences during the KDE 4 => 5 application "ugrpades").

All this to say that those of you who want to stay with KDE 4.... you are probably making the right choice... at least for now.

Note that the regression that I just managed to fix on my system earlier today, had been reported many times since the early KDE Plasma 5 versions, and each report was set as "Won't fix". I was disgusted when I found out today that the fix was actually so easy.

I've had a very 'hacked' KDE installation for years, where I've removed lots of the dependencies manually, and things worked OK for me (a set-up very much unsupported by upstream, and as such, not very viable for Gentoo).

Now if I try the same with “KDEFP5”, things seem to have been knit together a lot more tight-like (even if it is, as a whole, modular).

I've recently started experimenting with other options, such as xfce4, lxqt, fvwm, openbox, e, i3, awesome... but all of them feel like they're lacking some more or less minor thing I've come to use a lot in KDE (some or most of them might be possible with a number of those listed, but I've not learned how, yet).

Right now I'm running lxqt with kwin:4. If I wanted to go kwin:5, I'm immediately presented with things such as 'sys-fs/udisks' and 'sys-auth/polkit', things I really don't need. If I went “OK” with those, I might just as well go all the way with KDE. :]

I'm sure upstream has their reasons for why the window manager requires an interface to work with storage devices, but I haven't researched, nor asked about it (yet). I did give a quick go at removing dependencies at the configure system level, but really didn't give it enough time, and will need to try it again at some point.

I guess one way out might be (haven't tried) removing unneeded stuff post-merge, but one would still build unnecessary packages, which somewhat defeats the purpose._________________Kind regards,
Chiitoo.

You might remember me from Gentoo projects such as Forums, LXQt, Qt, and Wine.

... that I have recently started documenting all new regressions as I find them.

That's great. How else do you think the process works? Different people find different bugs, those who just complain but never report, will remain unhappy for a very long time.

augustin wrote:

Today, thanks to some valuable help that I received, I at last managed to patch KDE plasma 5 to get rid of a regression that was a huge usability, daily nightmare for me.

No offense, but a lot of people (me included) never noticed. Of course everyone thinks of their bugs as the most important... So while I get that this may have been a very dramatic blow to your workflow, I'd consider it a papercut. And I'm glad a solution to it has apparently been found.

augustin wrote:

Another regression that I can't wait to fix is the ability to grab a maxized window by any of its border and resize it vertically or horizontally, exactly to the dimensions we want, very quickly and very efficiently. Right now, to achieve the same within KDE Plasma 5, it is a battle of wills between me and kwin. I usually win, but not without my ego bruised. I no longer feel in control.

Very dramatic words again, yet I can't even remember how (if) that worked in Plasma-4. So another papercut for some who painstakingly expect the same behaviour, but not important to a lot of people. Certainly not a big deal to me, though I can see the appeal. I just don't organize my windows like that - either they are maximised for a reason (I'm on mobile use with a small screen) or they are never maximised (I'm stationary with a big screen), and switching between maximised and regular state is easily done. Not only that, a maximised window can be instantly dragged to either half or quarter of the screen to be automatically positioned/sized to that._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

My question is about steps 1 & 2. What is the best way to mask all plasma 5 and to unmask plasma 4? Secondary question: how to undo the masking of Plasma 4 that is currently in the main portage tree? (that might be taken care of by unmasking packages out of kde-sunset).

I assume for step 1, something close to this (from other KDE5 masking threads):

I've had a very 'hacked' KDE installation for years, where I've removed lots of the dependencies manually, and things worked OK for me (a set-up very much unsupported by upstream, and as such, not very viable for Gentoo).

Now if I try the same with “KDEFP5”, things seem to have been knit together a lot more tight-like (even if it is, as a whole, modular).

I've recently started experimenting with other options, such as xfce4, lxqt, fvwm, openbox, e, i3, awesome... but all of them feel like they're lacking some more or less minor thing I've come to use a lot in KDE (some or most of them might be possible with a number of those listed, but I've not learned how, yet).

Right now I'm running lxqt with kwin:4. If I wanted to go kwin:5, I'm immediately presented with things such as 'sys-fs/udisks' and 'sys-auth/polkit', things I really don't need. If I went “OK” with those, I might just as well go all the way with KDE. :]

As a longtime KDE user I was always using *kit free KDE-setups. At the moment I've got three Gentoo systems running with a *kit free Plasma5/KF5.
It was only necessary to remove some dependencies in 3 ebuilds manually. (kde-frameworks/solid, kde-plasma/plasma-desktop, kde-plasma/powerdevil)

I do deserve to be mocked. I shouldn't have used such a dramatic tone. I do know how lucky I am. I have been very actively involved in humanitarian campaigns, and I do know what true human misery looks like, not from personal experience, but for having actively campaigned against it. I am extremely fortunate to have the luxury of having the problems I am having. I have access to many luxuries which includes access to the technologies which we're discussing here. So, I apologize for the tone of my rant and gladly accept some mild rebuff.

However, I don't think my main point was completely understood. I blame the tone of my post for that. Allow me to try to clarify...

asturm wrote:

augustin wrote:

... that I have recently started documenting all new regressions as I find them.

That's great. How else do you think the process works? Different people find different bugs, those who just complain but never report, will remain unhappy for a very long time.

I see what you are referring to, and I am clearly with you on that point.
I don't like the divide between "developers" and "users", and fight against it. We, as "users", are not entitled to anything. I see Linux as a very large community, and every user, even the most newbie who wouldn't know how to code two lines of HTML, has something to contribute... if only by filing bug reports, as you suggest.
I do what I can to contribute to the whole process and I welcome your invitation and reminder to do so.

I was talking about something else.
I was not complaining about the mere existence of such regressions.
I was complaining about:

1) the casual attitude many upstream developers have about such regressions. The one issue I was mentioning had been reported many times, and each report was set as a duplicate to a "WONTFIX" issue. I want to promote the idea that such regressions are not acceptable and should be considered as bona fide bugs! And such bug reports shouldn't be closed until they have been fixed. How else are we going to move forward, otherwise, if we do one step forward, one step back??

2) the casual way by which an inferior product was pushed down our throats (earlier version being "no longer maintained"), even though such earlier versions were perfectly stable, usable and fulfilled our needs. We are not asking developers to keep adding features to earlier branches (KDE4), nor even actively fix bugs. Simply allow us the freedom to continue to use it, and kindly apply bug-fixing-patches as may be provided by the wider community.
I made this point earlier here:
"No active EOL'ing of major software branches " http://linux.overshoot.tv/blogs/augustin/no_active_eoling_major_software_branches

I wish gentoo had kept KDE4 in the tree. As a gentoo newbie, at first I was not aware of the kde-sunset overlay. I wish I hadn't upgraded. Had I known, I would have waited a bit longer. I would have helped people like proteusx and others to provide patches to the part of the tree that's related to KDE4. I for one would have welcome the opportunity to help out with that, contributing by helping to keep a mature software in the repository.

astrum wrote:

augustin wrote:

Today, thanks to some valuable help that I received, I at last managed to patch KDE plasma 5 to get rid of a regression that was a huge usability, daily nightmare for me.

No offense, but a lot of people (me included) never noticed. Of course everyone thinks of their bugs as the most important... So while I get that this may have been a very dramatic blow to your workflow, I'd consider it a papercut. And I'm glad a solution to it has apparently been found.

You are right about your notion of papercut. See my starting note.

Having said that, the two usability regressions I mentioned easily affect me dozens of time every single day. That's many paper cuts.
One finally has a very easy fix that upstream developers still don't want to commit (I attached the patch to the bug report which is closed as wontfix).
The other one.... is my next priority to fix...

That's without mentioning the dozens of other regressions that, luckily, only affect me very occasionally, if at all.

astrum wrote:

augustin wrote:

Another regression that I can't wait to fix is the ability to grab a maxized window by any of its border and resize it vertically or horizontally, exactly to the dimensions we want, very quickly and very efficiently. Right now, to achieve the same within KDE Plasma 5, it is a battle of wills between me and kwin. I usually win, but not without my ego bruised. I no longer feel in control.

Very dramatic words again, yet I can't even remember how (if) that worked in Plasma-4. So another papercut for some who painstakingly expect the same behaviour, but not important to a lot of people. Certainly not a big deal to me, though I can see the appeal. I just don't organize my windows like that - either they are maximised for a reason (I'm on mobile use with a small screen) or they are never maximised (I'm stationary with a big screen), and switching between maximised and regular state is easily done. Not only that, a maximised window can be instantly dragged to either half or quarter of the screen to be automatically positioned/sized to that.

I jumped straight from KDE 4.6 to gentoo with one of the latest KDE 4 release before being quickly forced to upgrade to KDE5. I am not sure that feature was working in the latest KDE4 releases. The feature may have been removed in the later versions of KDE4. It's still a regression that affects me every single day.

Every one has a different workflow, and this one would depend on the hardware (screen size) each have. In KDE4.6, I really could very easily resize windows the way I wanted, and since I very often work with two windows side by side, this regression affects me a lot.

The main point is this: regression are not desirable. Apparently some need to be convinced of this.

I have just started a rough list of regressions, out of the top of my head:
http://linux.overshoot.tv/wiki/kde_plasma_5_regressions
I added your points to the list. Further details and links to bug reports are welcome. I 'll add all relevant information to the above list, as I become aware of them.

So, first of all, the way you present these is less than ideal. None of these probably even is Plasma related. Konqueror is a KDE Application, so any bugs related to it go there. And then it's important to point out the affected version - if you're using current stable, which is 16.08.3, this is still kdelibs-4 based, if you're using current latest release, which is 16.12.1, that is kf5-based. This is crucial to anyone trying to make sense of their/your issues.

krunner works as great as it has always done, an important thing to realise is its modularity - an application like konqueror or keditbookmarks can install its runner to make functions accessible from inside krunner. So if the bookmarks are not accessible to you, the first thing you check is if its runner is present and active, make sure the identify the place where it goes wrong (are your konqueror bookmarks even visible in keditbookmarks?), and then you can go on and blame the right thing - in either case, it is not Plasma.

The third item in your list is equally sparse on information - I'm not sure what to even look for, typing 'memory' e.g. gives me the link to a memory kcm, and I think 'fine, that's what I'm probably searching for'. Would I expect an embedded widget suddenly popping out of the krunner window? Probably not. If that is what you had in Plasma-4, I would file it under nice but minor gimmick that was not ported to Plasma-5.

augustin wrote:

1) the casual attitude many upstream developers have about such regressions. The one issue I was mentioning had been reported many times, and each report was set as a duplicate to a "WONTFIX" issue. I want to promote the idea that such regressions are not acceptable and should be considered as bona fide bugs! And such bug reports shouldn't be closed until they have been fixed. How else are we going to move forward, otherwise, if we do one step forward, one step back??

I've read the upstream dev's reason for closing the bug as wontfix, and I have to agree with them. The response is far from 'casual attitude', you being unhappy with it does not justify misrepresenting upstream. The bottom line to that: Sometimes developers have to make decisions, that's part of the job - unfortunately, there are always situations where you can not please 100% of the user base. Does that, then, qualify as a regression? Clearly not, it is behaviour that you can argue about one way or another, and previous versions' behaviour is only one argument of many, not a determining fact.

We discussed that matter already. No one removed any Plasma-4 sources to prevent work on it, they exist for anyone to pick them up. No one working on it effectively is making it EOL, don't you think?

augustin wrote:

I wish gentoo had kept KDE4 in the tree.

It has kept Plasma-4 for as long as possible, longer than most distributions. As it depends on a deprecated toolkit that does not receive any security updates as well for years and is falling apart with newer releases of toolchain deps like cmake and GCC, and no developer using Plasma-4, it is impossible to keep it in tree._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

Last edited by asturm on Sun Feb 05, 2017 11:11 am; edited 4 times in total

As a longtime KDE user I was always using *kit free KDE-setups. At the moment I've got three Gentoo systems running with a *kit free Plasma5/KF5.
It was only necessary to remove some dependencies in 3 ebuilds manually. (kde-frameworks/solid, kde-plasma/plasma-desktop, kde-plasma/powerdevil)

Oh! Last I tried, stuff really didn't like to configure if something was missing... but that was a while ago.

Will give it another shot soon. Thanks!_________________Kind regards,
Chiitoo.

You might remember me from Gentoo projects such as Forums, LXQt, Qt, and Wine.