Issues in the Plasma-devel team

[René J.V. Bertin]

On Sunday March 5 2017 22:40:53 Valorie Zimmerman wrote:

Hello Valerie,


>Please tell us your thoughts and feelings about this, so that we can
>move forward.

Below, and CC'ing the KDE Mac community. Apologies that this is the sort of thing where my form of being concise is still quite longwinded...

My general thought here is that I cannot possibly catch every discussion that goes on on the different media, regardless of for how long I've been a contributor. Specifically the one concerning screensaving: that was apparently in 2011 and thus in fact before I even started getting involved, possibly before I started using KDE software frequently.

Concerning DrKonqi I do know that a number of KDE-Mac members have expressed concern about the fact it was being included in Plasma. At the time I was rather explicitly keeping away from KF5 because I my efforts were better used on polishing the KDE4/Mac experience while KF5 was taking shape and I felt I couldn't be constructive working on KF5 without knowing more about the underlying architectures AND how far is can be ported to the Mac OS. The only other thing I remember is that the decision to put DrKonqi in Plasma seemed not to be set in stone.

On another general note: as a scientist I've learned (been taught) long ago that the day one stops being able to accept that one's earlier decisions, opinions, points of view and approaches may need readjusting to new knowledge is the day one should start thinking of retiring or doing something else. That's not intended to be blunt but I know it'll probably come across as such...

>1. https://phabricator.kde.org/D4929

Exactly what is the issue there, support for lldb or the fact I unhappily used the term cross-platform?
If the latter then yes, that issue has been discussed before. I don't have links to the old discussion but I am convinced that there was at least support for the idea that DrKonqi is a utility with a usefulness that goes beyond Plasma desktops. It can and should be useful on every platform where the mechanisms on which it is based work (STOP and CONT signals, debugger attaching and remote control to obtain a backtrace). It is almost exactly in the same position as the KWalletManager. Or libksysguard which is used by KDevelop's debugger plugins for attaching to running applications (and ksysguard itself which could be used for remote monitoring).

I'll drop the issue if someone can point me to a definitive decision that I was explicitly made aware of that, basically, Plasma is too jealous of DrKonqi to allow it to be used elsewhere, which would include Gnome other non-Mac, non-KDE Unix platforms.

I don't know exactly how many active KDE-without-Plasma users there are who'd be bothering to use the bug reporting tool if it were more readily available because included with KCrash for instance. Maybe the Plasma team should hold a poll among all KDE developers to assess how important they find it to get useful bug reports from the field. After all Plasma devs will mostly see bug reports about Plasma stuff, which by definition can be made through DrKonqi. I can launch such a poll myself if needed.

How would it work out if bug reports from outside Plasma DEs simply had no backtrace or other useful information DrKonqi usually adds? 

Ultimately I don't care where DrKonqi's sources are to be found, anything beyond KCrash feels like an ad-hoc decision to me. I do care a bit more about how it's shipped

Can't we just leave the question about whom/what the tool belongs to in the middle? If DrKonqi is bundled as a standalone package, separate from plasma-workspace that question becomes moot, and anyone who wants to bundle it can do so without having to irk members of the Plasma team. 

There's a lot in the Plasma category that only makes sense in the context of a Plasma DE and which no one in his/her right mind would bother trying to port elsewhere. That doesn't mean that other parts which can make sense  on their own should be disallowed elsewhere and even less so that it's OK to take active steps to make that impossible. In my not so humble opinion that goes against any collaborative community spirit and would be more the kind of thing I'd expect from a religious sect.

>2. https://mail.kde.org/pipermail/plasma-devel/2017-March/067328.html (and
>follow ups)

As said above I was not part of the decision process concerning screensaving. Had I been I wouldn't have asked certain questions, but I would probably have voted against the decision that was taken, and I would reserve the right to mention that fact as should be acceptable within reason.
I realise that a certain amount of exchanges on the general ML were cross-posted to the plasma-devel ML but I'm not the sole responsible party for that oversight (nor, I think, the most verbose party).

@Valerie: you should have linked to a previous message in that thread as an example of the welcoming Plasma atmosphere, a message it took me a more than usual effort NOT to reply to in style and express my own hopes for its author. I didn't want to bother you at the time, but now that you did chose to get involved I trust you will know how to handle that incident.

>3. https://mail.kde.org/pipermail/plasma-devel/2017-February/066784.html (and
>follow ups)

What's the problem there? SDDM is not a KDE product as far as I can tell so admitting I don't like its looks shouldn't hurt anyone here. Asking if it'd be possible to *port* KDM doesn't mean I'm going to ask anyone to do it for me and then provide official support! That question was to know to what extent I could consider trying this for my own use. It was answered and that was that, no?

----
Well, those were my thoughts and feelings transcribed over the past 45 minutes or so...

R.