Re: Has there ever been ...

[René J . V . Bertin]

Nate Graham wrote:

> That version is over two years old and is not maintained. Can you maybe

On an unrelated note: does the feature to raise and activate a window by 
scrolling the mousewheel (or doing a 2-finger scroll) still only work on 
inactive 
windows - and thus nothing if you use focus-follows-mouse?

In xfwm4 it works indiscriminately and is thus a great way to raise a window 
without need for clicking (or hitting a keyboard shortcut). I miss it in other 
window managers. Something I'd like to bring up in an issue on BKO if it's 
still 
relevant.

R.

Re: Has there ever been ...

[René J . V . Bertin]

René J. V. Bertin wrote:

> René J. V. Bertin wrote:
> 
> The scrollbar arrows are also not drawn correctly,
> the bottom one seems clipped.

This particular symptom was due to the Oxygen win-deco theme setting to add a 
resize handle to borderless windows. I hadn't noticed the handle due to my 
colour palette. Let's see if the update glitch is gone now that I deactivated 
that setting (and I switched to XRender compositing too).

Re: Has there ever been ...

[René J . V . Bertin]

Nate Graham wrote:

> That version is over two years old and is not maintained. Can you maybe
> build the latest version from source?

As I said, not easily: too many dependencies that need to be updated, including 
Qt. Too much work (not to mention, time) for a result I'm just not certain 
about. I mean, if there was a blaring bug related to window content scrolling 
updating that has been fixed in those past 2 years someone would remember, no?
I could try with an AppImage though.

Or check if any distribution that's still at a close version ships their own 
interesting patches.

Re: Has there ever been ...

[René J . V . Bertin]

Nate Graham wrote:

> What version?

5.15.5 . As mentioned before, I cannot update to a more recent version easily 
on 
this system.

Re: Has there ever been ...

[René J . V . Bertin]

René J. V. Bertin wrote:

> Update: using OpenGL 2 seems to have cured the glitching I have been
> experiencing, apart from the occasional lack of immediate updating of a region
> (like just now when I opened the KWin prefs dialog via the titlebar context
> menu, which remained partly visible).
> 
> I guess shouldn't be surprised that an older OpenGL standard is less
> problematic on my hardware, and wonder why I never thought of trying that
> before. Will have to do for now, thanks for the feedback.

I think I spoke a little too soon :-/

After a while (possibly after using the Tigervnc x0vncserver) I get an updating 
issue in one of my Konsole windows. It's maximised vertically (doesn't matter 
if 
via the corresponding wm function or actually resized manually), and the bottom 
line tends to remain at the last entered command until I move the cursor out 
and 
back in (or some other exposure event occurs; I use focus-follows-mouse). The 
scrollbar arrows are also not drawn correctly, the bottom one seems clipped.

This happens only with KWin5.

R

Re: Has there ever been ...

[René J . V . Bertin]

René J. V. Bertin wrote:

> Marco Martin wrote:
> 
>> It doesn't and it never has. (transparecies and shadows without compositing)
> 
...
> I see that KWin5 also has XRender support; I'll check if that or "lowly"
> OpenGL 2.0 are suitable workarounds for me.

Update: using OpenGL 2 seems to have cured the glitching I have been 
experiencing, apart from the occasional lack of immediate updating of a region 
(like just now when I opened the KWin prefs dialog via the titlebar context 
menu, which remained partly visible).

I guess shouldn't be surprised that an older OpenGL standard is less 
problematic 
on my hardware, and wonder why I never thought of trying that before. Will have 
to do for now, thanks for the feedback.

R.

Re: Has there ever been ...

[René J . V . Bertin]

Marco Martin wrote:

> It doesn't and it never has. (transparecies and shadows without compositing)

OK, I made a shortcut, sorry for that. Transparency and shadows do work with 
XRender compositing so I suppose I should have talked about "OpenGL 
compositing".
I see that KWin5 also has XRender support; I'll check if that or "lowly" OpenGL 
2.0 are suitable workarounds for me.

I said I had no intention to make this into a thread but others here seem to 
want just that, so:

Does keeping up with my time also mean I have to succumb to fashionable 
susceptibility?!'m sorry (NOT!) but the latest kwin5 version I can currently 
run 
is 5.15.5 and it's the worst glitching WM on my system. Even if I could update 
I 
don't feel very inclined to because kwin has been becoming more and more 
bloated 
over the versions leading up to 5.15, and filled with functionality I don't 
need. 
I may evolve with my times (somewhat at least), but my computers don't.
I also happen not to like most of the themes included with KWin5 (in part 
because they don't render text properly = with the high quality of 
freetype+fontconfig with the Infinality patches) and because it's so tricky to 
get 
the window borders the way I want them. Is that seen as an insult too?

So no, I'm not going to be reporting bugs (unless you want them, for my 
"ancient" version) let alone try to fix things.
I'm a firm believer in not fixing things that ain't broke (there's a good 
chance 
I'd be using the Trinity DE had I come aboard in KDE3 days; also note the 
application I'm using to post here). KWin4 just happens to work (except for 1 
thing). I wouldn't have asked on here if it were less cumbersome to install 
without distro packages ... and less imposing a project to just do my thing 
during the few lost hours I have (like I did with kdm).

But fck it... shall we just say that I asked my question out of historic 
interest and personal education on things like best approaches to port KDE4 
applications to Qt5/KF5? I'm not going to conclude (yet) that nobody has an 
actual answer to my question (now THAT I'd consider an insult!)

R.

Re: Has there ever been ...

[René J . V . Bertin]

Jonathan Riddell wrote:

> This is pretty insulting, it would be better not to continue with this
> thread.
> 

Hah, well, I suppose the truth can hurt but I didn't think I I was writing 
anything that anyone would take personally. I didn't and don't lay any blame - 
but I do know I'm not the 1st, only nor probably the last person to use the 
terms KWin and glitch in the same sentence.

Anyway, there's no need to make this into a thread, a simple no or yes will do 
(with pointer to where I'd find the sources) - and that can be via private 
email 
too as far as I'm concerned.

R

Has there ever been ...

[René J . V . Bertin]

Hi,

Has there ever been a KWin version that was just (or predominatly) a straight 
port of the latest KWin4 to Qt5 and KF5?

Lately I find myself using KWin4 again because
1) it doesn't cause any glitching even with (OpenGL 2.0) compositing activated
2) it supports the few effects I find crucial (transparency during move/resize; 
*shadows*) even without compositing
3) I can use my QtCurve window decoration theme

Point 1) was why I use xfwm4 when KWin4 is not available, but that WM is also 
requires regular restarts to get rid of glitching ... but it won't do 
transparent move/resize with compositing turned off.

I could of course try to isolate the latest KWin4 and then do the porting 
myself but that's bound to be harder than it seems and repeating an effort that 
must have been done already...

Thanks,
R.

KWin refuses to start with compositor enabled?!

[René J . V . Bertin]

Hi,

I updated my home-built KWin 5.13.3, first to 5.13.3, then to 5.15.5 in hopes 
of experiencing less compositing glitches (that required me to restart KWin 
several times a day, ultimately forcing my back to xfwm4).

The jury is still out if there are less frequent glitches (and if those that 
remain aren't more severe), but now it requires me to activate compositing by 
hand after each restart, regardless of the corresponding startup setting. Kwin 
4 worked fine without compositing, even supported translucency during window 
moves (and compositor support in apps shouldn't depend on the window manager, 
right?!) but Kwin 5 can apparently no longer render window shadows without the 
compositor.And that's a deal breaker.

Below is the output I'm getting after a restart through krunner. The OpenGL 
output appears when I hit Shift-Alt-F12 to activate compositing:

org.kde.kwindowsystem: Loaded plugin 
"/opt/local/share/qt5/plugins/kf5/org.kde.kwindowsystem.platforms/KF5WindowSystemX11Plugin.so"
 for platform "xcb"
kwin_core: XCB error: 147 (BadOutput), sequence: 549, resource id: 2713715, 
major code: 140 (RANDR), minor code: 9 (GetOutputInfo)
kwin_core: XCB error: 147 (BadOutput), sequence: 550, resource id: 172, major 
code: 140 (RANDR), minor code: 9 (GetOutputInfo)
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 3728, resource 
id: 146800811, major code: 3 (GetWindowAttributes), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 3729, 
resource id: 146800811, major code: 14 (GetGeometry), minor code: 0
OpenGL vendor string:   Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 400 
(Braswell) 
OpenGL version string:  4.5 (Core Profile) Mesa 18.3.3
OpenGL shading language version string: 4.50
Driver: Intel
GPU class:  Unknown
OpenGL version: 4.5
GLSL version:   4.50
Mesa version:   18.3.3
X server version:   1.18.3
Linux kernel version:   4.14.23
Requires strict binding:yes
GLSL shaders:   yes
Texture NPOT support:   yes
Virtual Machine:no
libkwinglutils: Skipping self test as it is reported to return false positive 
results on Mesa drivers
kwin_core: XCB error: 10 (BadAccess), sequence: 3803, resource id: 246, major 
code: 142 (Composite), minor code: 2 (RedirectSubwindows)
qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 3806, 
resource id: 0, major code: 14 (GetGeometry), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 3816, 
resource id: 0, major code: 14 (GetGeometry), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 3826, 
resource id: 0, major code: 14 (GetGeometry), minor code: 0
qt.qpa.xcb: QXcbConnection: XCB error: 9 (BadDrawable), sequence: 3836, 
resource id: 0, major code: 14 (GetGeometry), minor code: 0

Qt/XCB drawing on the root window

[René J . V . Bertin]

Hi,

I have some old Qt4 code I'm porting to Qt5 that includes this

```
void
MyApplication::renderDone()
{
QPalette palette = desktop()->palette();
palette.setBrush(desktop()->backgroundRole(), QBrush(renderer->pixmap()));
desktop()->setPalette(palette);
//QApplication::setPalette(palette);
if (dpy) {
   //XSynchronize(dpy, true);
XClearWindow(dpy, desktop()->winId());
}

renderer->saveCacheFile();
renderer->cleanup();
// ...
QTimer::singleShot(1000, this, ::quit);
// quit();
}

main()
{
//
// Keep color resources after termination
XSetCloseDownMode(app.display(), RetainTemporary);
//
}
```

Some of you may recognise this as part of KDM, and that'd be correct :)

Displayed in a window, `renderer->pixmap()` is identical in Qt4 and Qt5, but 
only Qt4 gives me an actual image on the X11 root window (tested with the 
Xephyr nested window server). QDesktopWidget::winID() returns the correct X11 
Window so the differences can only be in what the QWidget::setPalette() does 
behind the scenes and how that trickles down to the underlying Window atom. Or 
in what it does in addition, like only actually applying the setting before 
doing some actual painting via the QPA, and then restoring the initial 
configuration?

I've tried to achieve what I want via Qt calls but have gotten nowhere with 
that either.

How does one do this sort of thing in Qt5? Clearly some part of the KF5 Plasma 
code manages to do what I'm trying to do, but which? 

Thanks,
R.

black screen with mouse cursor under kernel 5.7.14 with i915 driver on Cherrytrail & Baytrail CPUs

[René J . V . Bertin]

Hi,

Not a KDE issue in itself (I think) but one that certainly does affect Plasma; 
I'm posting it here to see if someone has seen this too and found a fix.

After installing a home-built 5.7.14 kernel I'm getting an all-black screen 
with just the mouse cursor visible on my Cherrytrail (N3150) and Baytrail (some 
Atom CPU in a Chuwi hybrid PC) PCs.  The SDDM greeter screen is fine (as long 
as I don't invoke the DE switcher) and the VTYs work fine too. Hitting 
Shift-Alt-F12 gives me a somewhat wonky view on the Konsole kpart (but not any 
window decoration or panel).

This happens with an old KUbuntu 14.04 but also on a fresh Devuan Beowulf 
install. The latter sits on a removable drive; if I boot an HP laptop with a 
somewhat recent i3 the desktop appears just fine.

It looks thus as if there's a regression in the OpenGL and/or direct rendering 
parts of the i915 driver for lower-end Celeron and Atom CPUs. Googling turned 
up all kinds of black screen issues (evidently...) but only 1 with the same 
symptoms but in an older 5.x kernel series (and no solution other than 
installing an older kernel IIRC).

Does all this ring a bell? Can anyone confirm that Plasma works OK with the 
latest 5.6 kernel (stock or else with the Con Kolivas patch)?

Thanks,
R.

Re: dipping a toe in waywater? :)

[René J . V . Bertin]

René J. V. Bertin wrote:

> And applications that I start with `-platform wayland` aren't decorated, as if
> kwin is either a WM or else a wayland compositor, but not the former inside
> the latter... Which is actually what I was hoping to get!

OK, belay that, apparently was because my Mesa install was lacking Wayland 
support (because I had built it against an older Wayland install).

Curiously, most KDE apps are decorated with a WM theme that doesn't look like 
any I have installed, while Firefox gets that titlebar that I configured (and 
that everyone gets in normal X11 operation; breeze).

Also see
https://bugs.kde.org/show_bug.cgi?id=423862

Finally, trying to start kwin_wayland from a virtual tty gives me a permissions 
error about /dev/drm/card0, even when there is no X11 server running. In itself 
this is correct given the permissions on that device file, but I hesitate to 
change them for fear the X11 will refuse to restart afterwards.

R.

Re: dipping a toe in waywater? :)

[René J . V . Bertin]

Kai Uwe Broulik wrote:

> Is it Mac OS?

No, nor a bird, nor a tree ;)

Even I wouldn't dream of testing KWin/Wayland on Mac. Just yet - I do dream of 
Wayland supporting Darwin but there a few too many dependencies on the Linux 
kernel for that (in KWin too, IIRC) that should be resolved first. A different 
topic that should probably be discussed elsewhere (including why you'd want to 
do this - there is at least 1 good reason).

No, this is just my personal take on a by-now venerable install that I've 
turned 
into something like a rolling release. FWIW, support for different DEs through 
the login manager was always flaky on this install, IIRC it only ever worked 
correctly with the fallback option that isn't really a DE - and that was never 
an issue for me.

Aleix's blog post did help; I must never have tried to start kwin_wayland 
without any arguments, or with a command to execute. That said, `kwin_wayland --
exit-with-session konsole` gives me ... an X11 konsole.

And applications that I start with `-platform wayland` aren't decorated, as if 
kwin is either a WM or else a wayland compositor, but not the former inside the 
latter... Which is actually what I was hoping to get!

R

Re: dipping a toe in waywater? :)

[René J . V . Bertin]

David Redondo wrote:

> Hello René,
> 
> maybe this blog post from Aleix can help you. It explains how to started a
> nested session or wayland session.
> https://www.proli.net/2020/04/03/developing-kwin-wayland/

Thanks David. That does look like things I already tried (and didn't work; 
starting kwin_wayland from a virtual terminal gives me a drm error about 
/dev/card0, for instance) but I'll just try again.

Other David: as I said, this is not a standard set-up, so just selecting 
wayland 
as a login option on the login manager screen isn't an option.

R.

Re: K'fusion, or descending Fusion from KStyle

[René J . V . Bertin]

In reply to underwhelming request:

github.com/RJVB/qtstyleplugins contains a clone of Qt's 5.12 built-in Fusion 
style that inherits KStyle, rebaptised KFusion and with a few minor other 
tweaks.

R.

dipping a toe in waywater? :)

[René J . V . Bertin]

Hi,

I hope this is the best place to ask:

I understand that KWin is its own wayland server/compositor/whatever-you-call 
it, so it might be possible to use kwin_wayland to get an impression of running 
a desktop under Wayland instead of X11?

If so, is there a succinct tutorial somewhere showing the steps to get a simple 
test environment up and running without interfering with my regular X11 
session? This is not on a standard distro with a standard full Plasma5 DE so I 
cannot simply ask to use Wayland while logging in, so I presume I'd either 
start a session manually from a virtual terminal so it runs parallel to my X11 
session, or I'd start a session that runs in an X11 window under my regular 
session (in that case: how representative and not limited by X11 can it be?).

Thanks,
R.

D13881: oxygen-demo : add KMessage preview

[René J . V . Bertin]

This revision was not accepted when it landed; it landed in state "Needs 
Revision".
This revision was automatically updated to reflect the committed changes.
Closed by commit R113:ad3cddb5954e: Fix the KDE4 build of the oxygen-demo 
(authored by rjvbb).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D13881?vs=67309=67381#toc

REPOSITORY
  R113 Oxygen Theme

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13881?vs=67309=67381

REVISION DETAIL
  https://phabricator.kde.org/D13881

AFFECTED FILES
  kstyle/demo/oxygenframedemowidget.cpp

To: rjvbb, #vdg, plasma-devel, lbeltrame
Cc: lbeltrame, GB_2, broulik, plasma-devel, LeGast00n, The-Feren-OS-Dev, 
jraleigh, fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[René J . V . Bertin]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R113:d299d6ebc195: add KMessage preview to the demo (authored 
by rjvbb).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D13881?vs=37155=67309#toc

REPOSITORY
  R113 Oxygen Theme

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13881?vs=37155=67309

REVISION DETAIL
  https://phabricator.kde.org/D13881

AFFECTED FILES
  kstyle/demo/oxygenframedemowidget.cpp
  kstyle/demo/oxygenframedemowidget.h
  kstyle/demo/ui/oxygenframedemowidget.ui

To: rjvbb, #vdg, plasma-devel
Cc: GB_2, broulik, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, 
fbampaloukas, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

KFusion style

[René J . V . Bertin]

Hi,

A while back I asked for some guidance in getting the Fusion style to inherit 
KStyle. Apparently there was no real interest in doing such a thing so in the 
end I rolled my own implementation, using a private, adapted copy of the KStyle 
class.

Contrary to that I thought, you cannot override the built-in Fusion style so I 
had to name my "new" style "KFusion", a pun on "KDE Fusion" and "confusion" 
(though the style will load as "Fusion" too, when Qt was built without the 
internal style).
 
github:RJVB/KFusion

Visible differences:
- better KDE integration through (optional) use of KStyle
- respects the ButtonsHaveIcons setting
- no double document-modified indicators on Mac
- no hardcoded highlight colour on Mac (the highlight/selection colour is about 
the only configurable colour there)

Feel free to use and/or bundle with binaries that use the Fusion style in order 
to have an acceptable, consistent cross-platform look and feel.

R. 

K'fusion, or descending Fusion from KStyle

[René J . V . Bertin]

Hi,

I had a recent run-in with a style hint that should actually be a 
platform-specific property (à la AA_DontUseNativeMenuBar; see QTBUG-77928) and 
then realised it could be useful to have a Fusion override style that inherits 
KStyle, given that more and more applications seem to adopt this style in order 
to have a consistent look (that just works) everywhere. Experience with the 
"native" Mac style suggests that Qt will give precedence to styles provided by 
plugins over styles provided in libQt5Widgets, so overriding a built-in style 
should indeed be possible.

We introduced KStyle inheritance In QtCurve with a simple `using` construct: 
when built with KDE support the style class will inherit KStyle, else it will 
inherit QCommonStyle.

It turns out that the Fusion style class invokes a protected QCommonStyle ctor 
that takes a newly allocated instance of the associated private class; KStyle 
itself inherits QCommonStyle but not this method. What are the options here, 
short of extending KStyle and using a "hand-written" d-pointer in the Fusion 
style class? I tried `d_ptr.reset(new PrivateFoo)` but that leads to a runtime 
error about reparenting an instance with a parent from a different thread 
followed by a crash.

Thanks,
R.

D22460: DrKonqi: improved lldb integration

[René J . V . Bertin]

rjvbb created this revision.
rjvbb added reviewers: kde-frameworks-devel, Plasma.
Herald added a project: Plasma.
Herald added a subscriber: plasma-devel.
rjvbb requested review of this revision.

REVISION SUMMARY
  Since a few versions lldb has had a tendency to remain stuck after the 
initial connection to the crashed application (on Mac). On Linux it would often 
exit cleanly and quickly in a way not foreseen by my previous code, causing 
DrKonqi to report an unexpected debugger termination.
  
  This patch addresses both issues:
  
  - recent lldb versions have no more problems with reading commands from a 
batchfile
  - this make it possible to add an explicit exit command
  - `slotProcessExited()` is called explicitly when lldb has confirmed the exit 
command
  - errors caused by terminating or killing the debugger process are now 
ignored.

TEST PLAN
  Getting a crash backtrace now works as expected on Mac and Linux. No 
regressions are introduced when using the gdb backend on Linux.

REPOSITORY
  R871 DrKonqi

REVISION DETAIL
  https://phabricator.kde.org/D22460

AFFECTED FILES
  src/backtracegenerator.cpp
  src/backtracegenerator.h
  src/data/debuggers/internal/lldbrc

To: rjvbb, kde-frameworks-devel, #plasma
Cc: plasma-devel, kde-mac, LeGast00n, jraleigh, fbampaloukas, GB_2, ragreen, 
Pitel, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, 
sebas, apol, mart

KDE file dialog column resize no longer possible?

[René J . V . Bertin]

Hi,

Sorry for cross-posting (initially), I'm not certain which list is the most 
appropriate.

It's often been tricky to trigger column resize mode in the KDE file dialog 
(when in one of the detailed view modes) but I realise I haven't been able to 
do this at all for a little while now. I just checked a Qt example, this is not 
a regression in the Qt version I'm using.

Has resizing support been turned off in KF5 maybe, and if so, where and why?

Thanks,
René

freedesktop.notifications daemon - crossplatform alternatives?

[René J . V . Bertin]

Hi,

Sorry for a somewhat off-topic question.

As far as I can tell the KF5/Plasma5 freedesktop notifications implementation 
is really not easily isolated even if it probably would be cross-platform. (I 
can run the systray widget in plasma-windowed, but that isn't really 
satisfactory.)

Why the cross-platform interest? Much KF5 software uses freedestop 
notifications that run over DBus, also when running on Mac or MS Windows, and 
evidently it would make sense to show them there too. Esp. if that could 
somehow be done via the native notification interface, with or without a 
control widget in the "systray" (menuextras on Mac).

Qt does allow that (possibly with a little extra code) so the question here is 
whether a (simple), pure-Qt implementation of a notification daemon already 
exists. Does anyone know?
The closest thing I have found to date is the lxqt notifyd, but that depends on 
liblxqt which requires X11.

Thanks,
R

D4929: DrKonqi : lldb and Mac support

[René J . V . Bertin]

rjvbb added a comment.


  > This revision was not accepted when it landed; it landed in state "Needs 
Review".
  
  Because I asked David if he'd seen the very last (=just committed) revision 
when he accepted this. He'd have infirmed that by now if our posts had crossed 
so I felt I could push this.

REPOSITORY
  R871 DrKonqi

REVISION DETAIL
  https://phabricator.kde.org/D4929

To: rjvbb, #plasma_workspaces, kfunk, davidedmundson
Cc: plasma-devel, #kde_applications, patrickelectric, kfunk, mart, broulik, 
kde-mac, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol

D4929: DrKonqi : lldb and Mac support

[René J . V . Bertin]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit R871:13121f4a303b: lldb and Mac support (authored by rjvbb).

REPOSITORY
  R871 DrKonqi

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D4929?vs=46309=46944

REVISION DETAIL
  https://phabricator.kde.org/D4929

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/backtracegenerator.cpp
  src/backtracewidget.cpp
  src/data/debuggers/external.mac/lldbrc
  src/data/debuggers/external/lldbrc
  src/data/debuggers/internal/lldbrc
  src/debugger.cpp
  src/debugger.h
  src/drkonqibackends.cpp
  src/main.cpp
  src/parser/CMakeLists.txt
  src/parser/backtraceparser.cpp
  src/parser/backtraceparserlldb.cpp
  src/parser/backtraceparserlldb.h
  src/tests/CMakeLists.txt

To: rjvbb, #plasma_workspaces, kfunk, davidedmundson
Cc: plasma-devel, #kde_applications, patrickelectric, kfunk, mart, broulik, 
kde-mac, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol

D4929: DrKonqi : lldb and Mac support

[René J . V . Bertin]

rjvbb marked an inline comment as done.
rjvbb added a comment.


  David, it seems our posts crossed, or did you actually see the new version I 
just uploaded?

REPOSITORY
  R871 DrKonqi

REVISION DETAIL
  https://phabricator.kde.org/D4929

To: rjvbb, #plasma_workspaces, kfunk, davidedmundson
Cc: plasma-devel, #kde_applications, patrickelectric, kfunk, mart, broulik, 
kde-mac, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol

D4929: DrKonqi : lldb and Mac support

[René J . V . Bertin]

rjvbb updated this revision to Diff 46309.
rjvbb marked 2 inline comments as done.
rjvbb added a comment.


  Fixed the AppleTerminal oversight in the non-Apple lldbrc.
  
  Also, I've removed the m_lldbDetached backend-specific member var. Instead, I 
now use the `m_proc` variable itself, and which will be nulled when we simulate 
the debugger exit.
  Or when the debugger actuall exits when we ask it to. Sometimes it does, 
which is why m_proc is tested before being used when detach output has been 
detected.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D4929?vs=46044=46309

REVISION DETAIL
  https://phabricator.kde.org/D4929

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/backtracegenerator.cpp
  src/backtracewidget.cpp
  src/data/debuggers/external.mac/lldbrc
  src/data/debuggers/external/lldbrc
  src/data/debuggers/internal/lldbrc
  src/debugger.cpp
  src/debugger.h
  src/drkonqibackends.cpp
  src/main.cpp
  src/parser/CMakeLists.txt
  src/parser/backtraceparser.cpp
  src/parser/backtraceparserlldb.cpp
  src/parser/backtraceparserlldb.h
  src/tests/CMakeLists.txt

To: rjvbb, #plasma_workspaces, kfunk, davidedmundson
Cc: plasma-devel, #kde_applications, patrickelectric, kfunk, mart, broulik, 
kde-mac, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol

D4929: DrKonqi : lldb and Mac support

[René J . V . Bertin]

rjvbb marked 3 inline comments as done.
rjvbb added inline comments.

INLINE COMMENTS

> davidedmundson wrote in lldbrc:7
> Linux has lldb too
> 
> I assumed that's why you also had a  "src/data/debuggers/external.mac/lldbrc" 
> as well as this file.

Ah, oops, good catch! Evidently the non-Mac version of lldbrc should not have 
AppleTerminal...

I haven't tried to understand how a debugger is chosen, I've never seen DrKonqi 
pick lldb over gdb on Linux. But there's FreeBSD too.

REPOSITORY
  R871 DrKonqi

REVISION DETAIL
  https://phabricator.kde.org/D4929

To: rjvbb, #plasma_workspaces, kfunk, davidedmundson
Cc: plasma-devel, #kde_applications, patrickelectric, kfunk, mart, broulik, 
kde-mac, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps

[René J . V . Bertin]

This revision was automatically updated to reflect the committed changes.
Closed by commit R858:1e02355c1786: Support for QGuiApplication-based apps 
(authored by rjvbb).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D14000?vs=44083=46108#toc

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D14000?vs=44083=46108

REVISION DETAIL
  https://phabricator.kde.org/D14000

AFFECTED FILES
  plugin/kquickstyleitem.cpp
  plugin/kquickstyleitem_p.h

To: rjvbb, #frameworks, mart
Cc: alexeymin, davidedmundson, mart, broulik, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol

D4929: DrKonqi : lldb and Mac support

[René J . V . Bertin]

rjvbb added inline comments.

INLINE COMMENTS

> davidedmundson wrote in backtracegenerator.cpp:140
> Yes
> 
> Also is it worth adding a "break;" there?

A break instead of or in addition to the return? I think I'd prefer the return, 
unless you think that maybe someday there will be some extra steps to be taken 
after the while loop?

> davidedmundson wrote in lldbrc:7
> Is this AppleTerminal line meant to be here?

Yes, that file is used when the user asks to attach a debugger to the crashed 
process. We shouldn't presume that s/he has Konsole installed, nor that it is 
installed with a wrapper script on the path. So we install a script that starts 
Apple's standard terminal emulator with the proper arguments, and call that.

REPOSITORY
  R871 DrKonqi

REVISION DETAIL
  https://phabricator.kde.org/D4929

To: rjvbb, #plasma_workspaces, kfunk, davidedmundson
Cc: plasma-devel, #kde_applications, patrickelectric, kfunk, mart, broulik, 
kde-mac, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol

D4929: DrKonqi : lldb and Mac support

[René J . V . Bertin]

rjvbb added a comment.


  > That'll probably be when we move to Qt6.
  
  Which is something I hope will be as far in the future as possible :)
  
  but
  
  > I doubt it really would make anyone's lives easier.
  
  Moving something outside of what I secretly call the Plasma jealousy universe 
should make life a bit easier for those who now have to argue why they'd want 
to use it. I can (kind of) understand why certain Plasma code would want to use 
the latest Qt5 version and almost why that version would be standardised across 
all Plasma members even though not necessary at all. So there's that too.
  
  > Can you explain why you detach?  Work to just call quit in the script to 
solve the hanging issue?
  
  In a nutshell, detaching before quitting makes the chance of hanging a lot 
smaller and speeds up the quitting too in my experience.
  
  As I said, I can make the variable backend-agnostic if you think that's 
preferable. But maybe it could be a nice junior job or GSoC project to redesign 
the backend so that DrKonqi doesn't have to wait for the debugger to quit. With 
both gdb and lldb it should be possible to obtain a reloaded backtrace from the 
same debugger instance, and that refreh should be a lot faster if you don't 
have to wait for a new debugger instance to start and churn through all loaded 
libraries - and I'm guessing that there will be no hanging issues when you quit 
lldb at DrKonqi's exit.
  And if so, keeping the backend-specific variable where it is could serve as a 
nice little reminder.

INLINE COMMENTS

> davidedmundson wrote in aboutbugreportingdialog.cpp:39
>   icon = QIcon::fromTheme
>   if (icon.isValid()) {
>  setWindowIcon(...)
>   }
> 
> is more standard..
> 
> Though from the docs:
> 
> > Note: On macOS, the window title bar icon is meant for windows representing 
> > documents, and will only show up if a file path is also set.
> 
> We don't set this, is this an issue?

Hmmm, this may have changed after I developed the brunt of this patch (in KDE4 
days). To answer your question, no, it's not a problem.
I'll have to look at this again, to see if this and similar changes still make 
sense.

> davidedmundson wrote in backtracegenerator.cpp:140
> this seems dangerous for the other clients.
> 
> It's not unfeasible for a process to have a load of data still in the buffer 
> when it quits.
> 
> I don't know lldb, but it seems you can probably move this to ~149

You mean move the check on QProcess::Running into the `if 
(line.startsWith(QLatin1String("Process ")) && line.endsWith(QLatin1String(" 
detached")))` ?

REPOSITORY
  R871 DrKonqi

REVISION DETAIL
  https://phabricator.kde.org/D4929

To: rjvbb, #plasma_workspaces, kfunk, davidedmundson
Cc: plasma-devel, #kde_applications, patrickelectric, kfunk, mart, broulik, 
kde-mac, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol

D4929: DrKonqi : lldb and Mac support

[René J . V . Bertin]

rjvbb updated this revision to Diff 46044.
rjvbb added a comment.


  includes the root cmake file changes.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D4929?vs=46025=46044

REVISION DETAIL
  https://phabricator.kde.org/D4929

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/aboutbugreportingdialog.cpp
  src/backtracegenerator.cpp
  src/backtracegenerator.h
  src/backtracewidget.cpp
  src/bugzillaintegration/reportassistantdialog.cpp
  src/data/debuggers/external.mac/lldbrc
  src/data/debuggers/external/lldbrc
  src/data/debuggers/internal/lldbrc
  src/debugger.cpp
  src/debugger.h
  src/drkonqibackends.cpp
  src/drkonqidialog.cpp
  src/main.cpp
  src/parser/CMakeLists.txt
  src/parser/backtraceparser.cpp
  src/parser/backtraceparserlldb.cpp
  src/parser/backtraceparserlldb.h
  src/tests/CMakeLists.txt

To: rjvbb, #plasma_workspaces, kfunk, davidedmundson
Cc: plasma-devel, #kde_applications, patrickelectric, kfunk, mart, broulik, 
kde-mac, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol

D4929: DrKonqi : lldb and Mac support

[René J . V . Bertin]

rjvbb added a comment.


  >   a find_packge for `KF5::WindowSystem` is missing in the root CMakeLists 
file.
  
  Ah, thanks. I have that in my own cmake file of course, but also an unrelated 
change I thought I could safely keep out by just taking a diff of the `src` 
directory.
  
  I test DrKonqi by starting an application like kate and then doing a `killall 
-SEGV kate`.
  Note that I do use a patched Qt5 on Mac where QStandardPaths can be made to 
behave like it does on any other Unix variant. Without that DrKonqi might well 
be unable to find the lldbrc (or equivalent) file it needs.
  
  The easiest way to make this platform independent would be to put those files 
in the Qt resource. That's a separate change though.

REPOSITORY
  R871 DrKonqi

REVISION DETAIL
  https://phabricator.kde.org/D4929

To: rjvbb, #plasma_workspaces, kfunk, davidedmundson
Cc: plasma-devel, #kde_applications, patrickelectric, kfunk, mart, broulik, 
kde-mac, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol

D4929: DrKonqi : lldb and Mac support

[René J . V . Bertin]

rjvbb added a comment.


  >   Can you rebase it over the last master branch ?
  
  I did that hours ago, or at least I thought I did?! Is there a commit later 
than 62c33ba3a885106f31706cbfecc75190ca00c70c 
 
which I somehow do not see yet?

REPOSITORY
  R871 DrKonqi

REVISION DETAIL
  https://phabricator.kde.org/D4929

To: rjvbb, #plasma_workspaces, kfunk
Cc: plasma-devel, #kde_applications, patrickelectric, kfunk, mart, broulik, 
kde-mac, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol

D4929: DrKonqi : lldb support

[René J . V . Bertin]

rjvbb updated this revision to Diff 46025.
rjvbb added a comment.


  Refactored for the standalone DrKonqi repo and disabled the integration 
testing on Mac.
  
  Making DrKonqi standalone is a good step, I'd strongly suggest to move it to 
KF5 Applications at the first possible occasion. The utility doesn't even 
depend on a single Plasma library and provides a service that has nothing 
Plasma-desktop specific.
  
  Instead, ask yourself if automatic crash reports are welcome only from Plasma 
desktop users or if as many users as possible should be able to submit crash 
reports (i.e. from any platform where DrKonqi is functional). Better, don't ask 
yourself, ask the entire family of KDE developers.
  
  On a related note: DrKonqi's dependencies have been bumped along with the 
other Plasma dependencies. That's overkill: it has no business requiring Qt 
5.11, 5.9LTS provides all required APIs. Similarly, it builds just fine against 
KF5 Frameworks 5.47.0, possibly even earlier versions.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D4929?vs=12368=46025

REVISION DETAIL
  https://phabricator.kde.org/D4929

AFFECTED FILES
  src/CMakeLists.txt
  src/aboutbugreportingdialog.cpp
  src/backtracegenerator.cpp
  src/backtracegenerator.h
  src/backtracewidget.cpp
  src/bugzillaintegration/reportassistantdialog.cpp
  src/data/AppleTerminal
  src/data/CMakeLists.txt
  src/data/debuggers/external.mac/gdbrc
  src/data/debuggers/external.mac/kdbgrc
  src/data/debuggers/external.mac/lldbrc
  src/data/debuggers/external/lldbrc
  src/data/debuggers/internal/lldbrc
  src/debugger.cpp
  src/debugger.h
  src/drkonqibackends.cpp
  src/drkonqidialog.cpp
  src/main.cpp
  src/parser/CMakeLists.txt
  src/parser/backtraceparser.cpp
  src/parser/backtraceparserlldb.cpp
  src/parser/backtraceparserlldb.h
  src/tests/CMakeLists.txt

To: rjvbb, #plasma_workspaces, kfunk
Cc: patrickelectric, kfunk, mart, broulik, kde-mac, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol

D4929: DrKonqi : lldb support

[René J . V . Bertin]

rjvbb marked an inline comment as done.
rjvbb added a comment.


  Sorry, I had updating this on my list but it drifted to the bottom...
  
  I think I've addressed all feedback apart from the `m_lldbDetached` variable 
Kevin objected to. I'm open to suggestions how to make that aspect less 
eyebrow-raising. Give it a more generic name and add a comment that it's only 
set/used for lldb (or else set it in every backend)?

REVISION DETAIL
  https://phabricator.kde.org/D4929

To: rjvbb, #plasma_workspaces, kfunk
Cc: patrickelectric, kfunk, mart, broulik, kde-mac, plasma-devel, ragreen, 
Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps (WIP/PoC)

[René J . V . Bertin]

rjvbb updated this revision to Diff 44083.
rjvbb added a comment.


  updated for the current git/head.
  
  David: did you perhaps forget to accept the revision (aka, should I have 
committed this)?

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D14000?vs=37897=44083

REVISION DETAIL
  https://phabricator.kde.org/D14000

AFFECTED FILES
  plugin/kquickstyleitem.cpp
  plugin/kquickstyleitem_p.h

To: rjvbb, #frameworks
Cc: alexeymin, davidedmundson, mart, broulik, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps (WIP/PoC)

[René J . V . Bertin]

rjvbb updated this revision to Diff 37897.
rjvbb added a comment.


  Using QApplication::style()

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D14000?vs=37568=37897

REVISION DETAIL
  https://phabricator.kde.org/D14000

AFFECTED FILES
  plugin/kquickstyleitem.cpp
  plugin/kquickstyleitem_p.h

To: rjvbb, #frameworks
Cc: alexeymin, davidedmundson, mart, broulik, plasma-devel, ragreen, Pitel, 
ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps (WIP/PoC)

[René J . V . Bertin]

rjvbb updated this revision to Diff 37568.
rjvbb added a comment.


  build on Mac too

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D14000?vs=37439=37568

REVISION DETAIL
  https://phabricator.kde.org/D14000

AFFECTED FILES
  plugin/kquickstyleitem.cpp
  plugin/kquickstyleitem_p.h

To: rjvbb, #frameworks
Cc: mart, broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol

D13881: oxygen-demo : add KMessage preview

[René J . V . Bertin]

rjvbb marked 3 inline comments as done.
rjvbb added a comment.


  Ping?

REPOSITORY
  R113 Oxygen Theme

REVISION DETAIL
  https://phabricator.kde.org/D13881

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps (WIP/PoC)

[René J . V . Bertin]

rjvbb updated this revision to Diff 37439.
rjvbb edited the summary of this revision.
rjvbb edited the test plan for this revision.
rjvbb added a comment.


  Getting the user's desktop style was easier than I thought.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D14000?vs=37437=37439

REVISION DETAIL
  https://phabricator.kde.org/D14000

AFFECTED FILES
  plugin/kquickstyleitem.cpp
  plugin/kquickstyleitem_p.h

To: rjvbb, #framework_syntax_highlighting
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D14000: qqc2-desktop-style: basic support for QGuiApplication-based apps (WIP/PoC)

[René J . V . Bertin]

rjvbb created this revision.
rjvbb added a reviewer: Framework: Syntax Highlighting.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
rjvbb requested review of this revision.

REVISION SUMMARY
  See https://bugs.kde.org/show_bug.cgi?id=396287
  
  Setting `QT_QUICK_CONTROLS_STYLE=org.kde.desktop` used to be safe but has 
started the cause applications to crash. Or I just never ran into what seem to 
be random (from a Joe User experience) but in fact are QGuiApplication-based 
applications.
  
  This patch presents a proof-of-concept fix that makes it safe to set 
`QT_QUICK_CONTROLS_STYLE` or whatever other options there are to use the QQC2 
desktop style in all applications that use QuickControls2.
  The current implementation creates a local instance of Qt's built-in Fusion 
style, and probably doesn't need to create a new instance for each new 
KQuickStyleItem instance. Being a Tier3 framework it should be possible to 
fetch the current desktop style through KConfig, in which case creating a new 
QStyle instance would be (more) justified. There's probably some optimisation 
to be done here though I'm not convinced it will make any difference in 
practice, in the general context of using QtQuick.
  
  An alternative approach would be to do the programmatic equivalent of the 
command-line override (e.g. `quickcontrols2/gallery/gallery -style Default`) 
but I have not yet been able to figure out if it is possible to change the 
QQuickStyle at this point.

TEST PLAN
  Tested with
  
> env QT_QUICK_CONTROLS_STYLE=org.kde.desktop 
/path/to/qt5-examples/quickcontrols2/gallery/gallery
  
  before: immediate crash because the plugin dereferences a NULL qApp->style() 
without flinching
  after: practically normal behaviour that is certainly preferable to crashing 
due to a potential security exploit.

REPOSITORY
  R858 Qt Quick Controls 2: Desktop Style

REVISION DETAIL
  https://phabricator.kde.org/D14000

AFFECTED FILES
  plugin/kquickstyleitem.cpp
  plugin/kquickstyleitem_p.h

To: rjvbb, #framework_syntax_highlighting
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[René J . V . Bertin]

rjvbb added a comment.


  A couple of snapshot (with my current KMessageWidget facelift; styles and 
themes switched "on-the-fly"):
  
  Oxygen with the Oxygen theme:
  F6014853: image.png 
  
  Breeze with Breeze-Dark:
  F6014872: image.png 
  
  QtCurve with my Mac OS X Graphite theme:
  F6014843: image.png 

REPOSITORY
  R113 Oxygen Theme

REVISION DETAIL
  https://phabricator.kde.org/D13881

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[René J . V . Bertin]

rjvbb updated this revision to Diff 37155.
rjvbb added a comment.


  Updated as (hopefully) requested.
  
  I've left the property change event filter, for builds against older than 
5.48.0 (or whatever version D13884  will 
appear in).
  
  There is one side-effect that will exist with older frameworks and not with 
D13884  in place: messages are recreated so 
will reappear if you've closed them. The easy way to prevent that would be to 
disable the close button, should I do that or do we not care about this? I 
can't say I'll lay awake about the detail...

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D13881?vs=37137=37155

REVISION DETAIL
  https://phabricator.kde.org/D13881

AFFECTED FILES
  kstyle/demo/oxygenframedemowidget.cpp
  kstyle/demo/oxygenframedemowidget.h
  kstyle/demo/ui/oxygenframedemowidget.ui

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[René J . V . Bertin]

rjvbb added inline comments.

INLINE COMMENTS

> broulik wrote in oxygenframedemowidget.cpp:90
> What do you need this for?

That's to catch the event sent to the qApp instance when the theme is changed 
(to be exact: after KColorSchemeManager sets or changes the 
`KDE_COLOR_SCHEME_PATH` property.

Without this, the messages don't adapt to reflect the new colours (even the 
current implementation mixes the window background into its background colour).

REPOSITORY
  R113 Oxygen Theme

REVISION DETAIL
  https://phabricator.kde.org/D13881

To: rjvbb, hpereiradacosta
Cc: broulik, plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D13881: oxygen-demo : add KMessage preview

[René J . V . Bertin]

rjvbb created this revision.
rjvbb added a reviewer: hpereiradacosta.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.
rjvbb requested review of this revision.

REVISION SUMMARY
  A recent change to the `KMessageWidget` look has caught my interest and made 
me start to experiment with ways to make them integrate better, in particular 
concerning the use of colour (see D13777  
and recent posts on the frameworks-devel ML).
  
  This patch adds a preview of the 4 different KMessageWidget types to what I 
think is the most appropriate existing widget, plus the magic required for 
detecting and reacting to colour theme changes.
  
  This change makes testing a new look across all installed colour themes and 
widget styles much easier. Idem for assessing just how well the current design 
really works, of course.

TEST PLAN
  Works as intended.
  
  Possible improvements:
  
  - add a dedicated frame/tab that could show other, comparable widgets (but 
which?)
  - add a signal to `ColorSchemeChooser` (but is that better than handling the 
QEvent it already triggers?)

REPOSITORY
  R113 Oxygen Theme

REVISION DETAIL
  https://phabricator.kde.org/D13881

AFFECTED FILES
  kstyle/demo/oxygenframedemowidget.cpp
  kstyle/demo/oxygenframedemowidget.h

To: rjvbb, hpereiradacosta
Cc: plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb added a comment.


  David,
  
  Could you please push it for me? I probably won't be able to do so for at 
least a week and it'd be a pity if the change just misses a release because of 
that.
  
  Thanks.

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb, #frameworks, davidedmundson, graesslin, cfeck, dfaure
Cc: ahmadsamir, rdieter, abetts, anthonyfieroni, ngraham, cfeck, fvogt, 
plasma-devel, ragreen, Pitel, ZrenBot, lesliezhai, ali-mohamed, jensreuterberg, 
sebas, apol, mart

gtk3 integration?

[René J . V . Bertin]

Hi,

I recently came across something called qt-gtk-engine (a bit of LXDE 
abandonware) which reminded me that I never found a satisfactory way to 
integrate GTk3 apps with my preferred look and feel, esp. not with more recent 
GTk3 versions. Oxygen-gtk3 comes closest but that project hasn't seen any 
activity for severals years now, too.

Much as I'd like to avoid Gnome and GTk apps that's just not feasible. Even 
Google Chrome seems to use the selected GTk3 theme.

How was the Breeze theme for GTk3 created? Is there a piece of software that 
automates the process by rendering all widgets of interest using the widget 
style and colour palette of choice into images and then bundles them as a 
theme? As far as that is technically possible?

Thanks,
R.

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb added a comment.


  >   In the code shown by this patch ;) Line 80.
  
  Right. Doh. The line that causes other side-effects when you comment it out :)
  
  >   But the test you suggested that I do above is further proof anyhow.
  
  
  
  >   
  >   But even without setStyleName call (i.e. with your patch) I get the bug, 
due to call to QFont::fromString.
  
  That's the problem with the styleName: once you caught one it's almost 
impossible to get rid of in code. You can set an empty styleName, but that 
doesn't restore the pre-styleName state completely. The only safe way I know of 
is to convert to string, remove the stylename and recreate a QFont fromString, 
or write out the equivalent set of operations like I did for QtCurve.
  
  Still, not setting style names in the platform plugin, AND taking care not to 
set it in KFontRequester should improve the situation - but it will not take 
care of your tainted settings files for you, of course. :)

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb, #frameworks, davidedmundson, graesslin, cfeck, dfaure
Cc: rdieter, abetts, anthonyfieroni, ngraham, cfeck, fvogt, plasma-devel, 
ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb added a comment.


  >   Unfortunately, this patch doesn't fix it. The text still isn't bold.
  
  No, this patch is written to be as transparent as possible. It won't impose a 
stylename, but will not remove it either.
  
  What happens when you remove the `,Regular`, i.e.
  
[General]
font=Noto Sans,7,-1,5,50,0,0,0,0,0
  
  Normally you should get a bold font again then?
  
  >   Workaround: enabling the line that calls 
QApplication::setDesktopSettingsAware(false).
  >   Proof that this code is guilty: commenting out the fromString line makes 
it work, too.
  
  Which line is that, where?
  
  >   What really confuses me is: why isn't it all set up so that this 
platform-plugin code provides *default* fonts, and so that what apps do 
overrides that?
  
  That is what used to be the case, and that's why I think the commit that 
added the setStyleName call to kfontsettingsdata.cpp ought to be reverted. (I 
haven't gone back to re-read the commit message, but IIRC it was mostly made to 
align with the way fonts are saved, without questioning whether they should 
always be saved like that.)
  
  I'd be happy to modify the patch so it strips the style names from the 
initial-defaults table as well as the call to setStyleName(). I could even go 
so far as to add code that strips the styleName if the font can be represented 
without it - but this also has a side-effect.

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb, #frameworks, davidedmundson, graesslin, cfeck, dfaure
Cc: abetts, anthonyfieroni, ngraham, cfeck, fvogt, plasma-devel, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb added a comment.


  >   Thanks for the info! So if/hen this goes in, what are the next steps?
  
  I'd say
  
  - decide whether this is an issue you want to solve only for plasma 
environments, or for all platforms where KF5 applications are supported.
  - draw up the conditions under which a stylename has to be set and whether to 
rely on Qt to do this in those cases.
  - how to avoid the effects of Qt setting a stylename in the conditions where 
this is not a necessity, how to get rid of it reliably etc.
  
  Optionally, when those things have become clear and have a well-tested 
implementation, try to work with the Qt team to merge any appropriate parts 
into Qt. From what I've seen in the exchanges with them it would be of no use 
to do this any earlier. Their stance seems to be "just don't rely on being able 
to setBold(true)" or any similar attribute change.
  
  Not that I see how that could be possible, but the observation I posted in my 
previous comment may indicate that there might be a central location after all 
where we could get rid of a stylename (in addition to KFontRequester).

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb, #frameworks, davidedmundson, graesslin, cfeck, dfaure
Cc: abetts, anthonyfieroni, ngraham, cfeck, fvogt, plasma-devel, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb added a comment.


  A diagonally related anecdote that shows this location is a more central 
point in the font selection process than I thought first:
  
  Applications like Qt's Assistant that call for Helvetica often end up using a 
font that looks pixelated - because it's actually an embedded bitmap version. I 
only saw that under X11 and always wrote that off to a missing font though the 
fact that scaling up the text solved the issue appeared strange.
  Then I noticed it too on Mac during my comparisons of the CoreText and 
Freetype font engines.
  
  One solution to this particular issue (itself unrelated to style names) is to 
use the ForceOutline style strategy when the Freetype engine is used. I 
implemented that in my Mac version of the platform integration plugin, right 
next to where this patch applies. That was mostly to be exhaustive (there is no 
way to set this as a global strategy applying to all current and future fonts). 
I was surprised to see that it apparently applies to the result of all font 
lookups.

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb, #frameworks, davidedmundson, graesslin, cfeck, dfaure
Cc: abetts, anthonyfieroni, ngraham, cfeck, fvogt, plasma-devel, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb added a comment.


  >   Is this change purely a conversation of what developers use in code to 
call up fonts in their applications?
  
  I think so.
  
  >   Or does this also include a discussion where regular users have 
interfaces that allow changes to font naming? Let's say, something like System 
Settings that would allow users to change the naming for system fonts?
  
  That already exists as you must have noticed: the Fonts settings panel.
  
  This suggested change removes one source of stylenames being set on fonts 
beyond the user's control. In the original/current code, the table with the 
default fonts (those used before the user makes any customisations) contains 
stylenames. Later on in the code those are set on the fonts being looked up.
  The modified version still does that, but only if looked-up font already has 
a stylename set.
  
  Concretely this means a better guarantee that the trick of removing the 
stylename part from the font descriptions in settings (rc) files will actually 
work.
  
  The modification should be transparent to anyone who does NOT remove 
stylenames and is thus the least invasive change. I still think the platform 
theme plugin should never have started calling setStyleName in the first place, 
and certainly not for default fonts that are perfectly described by the PANOSE 
system and thus don't need a stylename.

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb, #frameworks, davidedmundson, graesslin, cfeck, dfaure
Cc: abetts, anthonyfieroni, ngraham, cfeck, fvogt, plasma-devel, ZrenBot, 
progwolff, lesliezhai, ali-mohamed, jensreuterberg, sebas, apol, mart

D10092: [Examples] Fix build

[René J . V . Bertin]

rjvbb accepted this revision.
rjvbb added a comment.
This revision is now accepted and ready to land.


  LGTM.
  
  The examples seem to have a circular runtime dependency on (at least) 
plasma-desktop. Is that just an opportunistic dependency (= they'd work fine 
you'd only just installed plasma-framework)?

REPOSITORY
  R242 Plasma Framework (Library)

REVISION DETAIL
  https://phabricator.kde.org/D10092

To: broulik, #plasma, rjvbb
Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

[René J . V . Bertin]

David Edmundson wrote:

My previous reply to this seems to have gone missing.

> That plugin has it's own system tray handling that uses KNotification,
> instead of the platform DBus code you looked at in Qt.
> Combined with a getenv check in knotification will be the source of your
> issue.

I was right, the issue of KF5 systrays moving to the XFCE panel on Mac was due 
to Knotifications. The platform plugin just attempts to make every Qt 
application use the KNotifications wrapper around QSystemTrayIcon and is thus 
not the real culprit.
I've written a prototype fix (forcing legacy mode on platforms where that mode 
should be preferred) which I'll present in due time via the appropriate channel.

R.

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

[René J . V . Bertin]

David Edmundson wrote:

> You missed reading the code that calls this in
> src/widgets/util/qsystemtrayicon_x11.cpp which will make an X system tray
> if the platform doesn't.

I understand now why this doesn't happen in my case. Out of scope here.

> That plugin has it's own system tray handling that uses KNotification,
> instead of the platform DBus code you looked at in Qt.
> Combined with a getenv check in knotification will be the source of your
> issue.

Yes, I know the plugin modifies things in this domain. But it can only do that 
when it's actually installed and loaded and as already mentioned several times 
that doesn't matter here. I haven't yet had the time to look at what 
KNotification does. I doubt that it can see from a getenv check if a SNI host 
is 
present on the DBus. It may have to check the actual platform name in order to 
be really thorough (via QCoreApplication or KWindowSystem; last time I asked, 
Qt's official standpoint was "we support all QPA plugins that build on a given 
platform).

It could help me to know what env. variable KNotification looks for?
If you refer to KDE_FULL_SESSION or KDE_SESSION_VERSION, those aren't set in 
this particular case, and QT_QPA_PLATFORMTHEME=cocoa .

R

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

[René J . V . Bertin]

>>It's not plasma-specific
> 
> It is. Hence the name...

Just have a look at what it actually does; nothing requires a plasma 
environment 
to be present (with the possible exception of the look-and-feel feature but 
that's far from crucial). Its goal is to provide theming (visual and 
behavioural) for Qt5 applications so they follow a set of guidelines.

> and not surprisingly, you having issues when it
> integrates with Plasma.

Nope, that's not what is happening here. Please read again, there is no Plasma, 
the plugin is not implicated, and any issues I'm dealing with here exist 
whether 
or not the plugin is installed. I'm simply not looking for support with that 
plugin. Just forget I ever mentioned it.

>>I'll be looking into that too today.
> 
> Please do not waste your time or my time in trying to "fix" issues in an
> already broken setup.

Excuse me? Not only did I not ask you anything, the set-up in question (Mac 
with 
the official XQuartz environment installed, plus official MacPorts versions of 
XFCE, DBus etc.) is not broken but perfectly legitimate. A similar and 
similarly 
legitimate situation can exist on MSWin with Cygwin installed.
If my analysis is correct that is not an issue for this ML.

R

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

[René J . V . Bertin]

David Edmundson wrote:


> You missed reading the code that calls this in
> src/widgets/util/qsystemtrayicon_x11.cpp which will make an X system tray
> if the platform doesn't.

Indeed, but that's curious. I see what you mean, but I followed the flow in a 
debugger and AFAICT the qpa_sys==NULL path was never taken (which is why I 
missed it). I'll have to take another look at that.


> Please don't tell me you're using the Plasma platform integration plugin
> under XFCE?

Why wouldn't one do that? It's not plasma-specific in the sense that it doesn't 
depend on anything that the plasma environment provides. In fact you get close 
to the same functionality when you set the proper env. variables thanks to 
qgenericunixtheme.cpp .
FWIW, I'm only using XFCE on that machine because it's so much cheaper to build 
than a full Plasma environment. For the rest I want my Qt/KF5 apps to behave 
like they would under Plasma5 - not unlike running KF5 applications under a 
Plasma4 environment in fact.

I know that the integration plugin modifies the systray behaviour but it's not 
the only one responsible for KDE apps not getting a systray under XFCE. 
KNotifications also seems to have its part of responsibility, judging from the 
following:
- I use xfwm4 and xfce4-panel under XQuartz on my Mac and installed 
dbusmenu-gtk 
and the sni-plugin there too
- I maintain a fork of the plasma integration plugin for Mac (osx-integration)
- I added the SNI notifier widget to the XFCE panel
- Qt/Cocoa applications not using KNotifications still use the native Mac 
systray
- KDE4 and KF5 applications start using the XFCE systray as soon as I activate 
it and revert to the native systray when I unload the XFCE sni plugin.
- For KF5 applications this is independent of the integration plugin, i.e. it 
happens with or without that plugin.

This would happen if KNotifications tests for presence of a SNI host on the 
DBus 
and uses native systray functionality only as a fallback. I'll be looking into 
that too today.

R.

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

[René J . V . Bertin]

René J. V. Bertin wrote:

> PS: Ah, when I move the platform integration plugin aside I indeed get a
> systray icon. Hmmm...

Hmmm indeed. Pushing the plugin aside doesn't take down an already running host 
of course. When I do that too, the error message comes back that tells me that 
no systray feature is available.

R.

Re: DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

[René J . V . Bertin]

Hi,

> I think you've only half analysed this. If nothing is really listening on
> DBus it will fall back to legacy X which will work on XFCE.

Where did I miss this in the code? The createPlatformSystemTrayIcon() functions 
in qtbase/src/platformsupport/themes/genericunix/qgenericunixthemes.cpp are 
pretty clear: they return NULL unless isDBusTrayAvailable() returns true.

> You'll get into this situation if you have a StatusNotifierItemWatcher
> (typically a kded module from p-w) but no StatusNotifierItem host (sys tray
> support)

In fact, any Qt application that tries to put up a systray icon. At least when 
the plasma-integration plugin is installed.

I did find a solution though, ultimately:
https://github.com/equeim/snw-plugin

Which is just about exactly what I asked for :)

Hope this helps others,

R.

PS: Ah, when I move the platform integration plugin aside I indeed get a 
systray 
icon. Hmmm...

DBus statusnotifier (aka systray) daemon/bridge for GTk/XFCE environments?

[René J . V . Bertin]

Hi,

I'm running a simple XFCE environment on a Unix rig (not Linux) and thought 
some dependency was missing because the xfce4-panel notification area remained 
empty - until I noticed that it works just fine when GTk2 applications try to 
use it. Following the initialisation I now see that the Qt5 systray set-up 
fails because there's nothing listening on the DBus

Is there something like a daemon/server utility that acts as a Qt/KDE 
compatible StatusNotifierHost on the DBus and generally as an interface so Qt5 
and KF5 systrays work with the xfce4-panel application?

FWIW, I thought this was standard functionality...

Thanks,
R.

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb added a comment.


  >   So this this actually resolve 
https://bugs.kde.org/show_bug.cgi?id=378523, or just lay the groundwork for 
resolving it?
  
  No, it's more a change similar to proposed fix for that bug (don't set a 
stylename in KFontRequester).
  This patch implements the principle that you shouldn't set a style name if 
you cannot guarantee that the side-effects of that change are without 
consequence. The platform theme plugin loads the desktop fonts and if it 
imposes a style name on them no application can set them to bold or italic 
anymore.
  
  So you could say that this patch is necessary for the KFontRequester fix to 
work as intended (as far as the desktop fonts are concerned).

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb, #frameworks, davidedmundson, graesslin, cfeck, dfaure
Cc: anthonyfieroni, ngraham, cfeck, fvogt, plasma-devel, ZrenBot, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb added a comment.


  If you read 
https://bugreports.qt.io/browse/QTBUG-63792?focusedCommentId=381570 the 
take-home message seems to be that the platform theme plugin (and KDE in 
general) shouldn't be messing with setStyleName() at all UNLESS asking for a 
font with properties that cannot be represented in the old Panose system.
  
  Such fonts should probably be rare and a priori mostly encountered in very 
specific applications (Krita, Karbon and the like).

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb, #frameworks, davidedmundson, graesslin, cfeck
Cc: ngraham, cfeck, fvogt, plasma-devel, ZrenBot, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb added a comment.


  > On the other hand, calling setBold(true) on a font called 
"HandwriteCursive" _should_ select "HandwriteBoldCursive", even if the 
styleName was intended to enforce a specific face. If Qt cannot fix this issue, 
then we have to clear the styleName() at least for those fonts, where a perfect 
match is possible using the attributes alone (by comparing with the database 
again).
  
  Indeed - and I think there are limits to what any automated system can do 
here. There's a point where you have to accept that fonts may have a design 
issue in how they're named and what additional information is available in the 
font file (fortunately the font name isn't the only metadata). And at that 
point you indeed have to fall back to using databases (maybe FontConfig could 
help here)?
  
  > The patch also addresses the bug only for default fonts, but not 
per-application fonts that write their settings to the appnamerc file.
  
  True. Yet I only got bold syntax highlighting again after I applied this 
patch in addition to removing the stylename extension from kateschemarc. I 
don't yet have an explanation for that ...
  
  > All of those will also have a StyleName, so this here doesn't apply either.
  
  Hah, that depends with what Qt version they were generated, and on whether or 
not the user removed the parameter. I didn't invent that move myself, reading 
comments from others who did that to restore issues is what got me to write 
this patch in the end.
  
  > Nothing gets overridden here. It's just that the user didn't specify it.
  
  Which probably means he didn't want it, in this case... What if that short 
name is one of the fonts from Christoph's example (and thus includes an 
explicit weight specification), are you going to do heuristics on it?
  
  This kind of changing the default is fine for users who never use the 
configuration utilities and thus may not even have a kdeglobals file.
  It can get a bit tricky if s/he has a spec in the file that corresponds to an 
old default, but when in doubt I always assume the user is right in this sort 
of thing.

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb, #frameworks, davidedmundson, graesslin, cfeck
Cc: cfeck, fvogt, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb added a comment.


  >   IMO that's a feature though and is the expected behaviour. For instance, 
if we change the default window title to be bold, users with "windowTitle=Comic 
Sans" will also have a bold title.
  
  So how would you "change the default window title to be bold" and more 
importantly, how many people are going to have only a font family name in their 
configuration files? The vast majority will use the available GUI methods for 
selecting fonts and will end up with a complete specification.
  
  I'd go one step further: why would changes to defaults override choices 
already made by users? That's bad practice any way you look at it.
  
  >   So just specifying exactly 10 parameters as part of the config key should 
have the exact same effect.
  
  I don't know what Qfont method that comes from, but experience shows that 
just removing the stylename extension from the config key (a freshly generated 
one) doesn't do the trick. IOW, the stylename isn't cleared.

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb, #frameworks, davidedmundson, graesslin
Cc: fvogt, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb added a comment.


  It depends a little bit what kind of call you make. But yes, certain 
"conflicting" attributes can no longer be set. A particular example reported by 
many is setting bold. If you do `setStyleName("Regular")` on a Qfont, 
`setBold(true)` will no longer have the intended effect, or possibly not the 
same effect (apparently you can also end up with an emboldened version of the 
font, rather than with the actual bold version).
  
  Have you ever worked with professional typesetting, drawing of page-layout 
applications like InDesign or Illustrator? There you don't set a font to bold, 
you select another typeface from among the ones you have installed. This is of 
course how fonts are designed and implemented but most of expect that 
"old-fashioned inconvenience" to be hidden. IOW, flip a font to bold by hitting 
Ctrl-B and you get "Foo Bold" rather than "Foo Regular-or-Whatever-you-had 
turned into something looking bold". Calling `setStyleName()` brings back a bit 
of that old-fashioned "pedantic" nature.

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

To: rjvbb
Cc: fvogt, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart

D9070: KDE platform plugin: don't force default stylename on user-specified fonts

[René J . V . Bertin]

rjvbb created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Applying the default, hardwired QFont::styleName to one of the standard fonts 
which then gets changed to a user-selected font can break expectations because 
of the way Qt handles such canonical stylenames, letting them override the 
effects of other QFont methods invoked subsequently. It can for instance become 
impossible to make the font bold afterwards: see 
https://bugs.kde.org/show_bug.cgi?id=378523, 
https://bugreports.qt.io/browse/QTBUG-63792 or 
https://bugs.kde.org/show_bug.cgi?id=387467 .
  
  This may be a Qt "feature" that's here to stay, sadly.
  
  The change proposed here makes it possible (again) for users to prevent font 
weight rendering regressions by removing the stylename extension from 
configuration files manually as documented in several locations. This approach 
is useless when the KDE platform theme plugin then applies the default 
stylename, an issue that can be avoided by calling QFont::setStyleName() only 
when no user-specified font is available.
  
  Evidently the manual intervention could be replaced with a change in the way 
font settings are stored; this would also require the current change.

TEST PLAN
  Works as intended on Linux. An equivalent modification in my osx-integration 
fork of the platform theme plugin for Mac has the same effect (without it 
"Segoe UI Semi-bold" is no longer made bold where it should in dialogs).
  
  I don't think there are possible side-effects:
  
  - a stylename still gets set either if there is no user-selected font or if 
that selection includes a stylename extension
  - font specifications should still contain all the required information they 
always had; not applying a guessed stylename only means that no conflict can 
arise with the combined set of numeric style and weight attributes.

REPOSITORY
  R135 Integration for Qt applications in Plasma

REVISION DETAIL
  https://phabricator.kde.org/D9070

AFFECTED FILES
  src/platformtheme/kfontsettingsdata.cpp

To: rjvbb
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart

Re: KWin5 memory leak?

[René J . V . Bertin]

On Monday November 13 2017 17:20:56 Martin Flöser wrote:

Hi,

Is it possible that many if not most of the users who might report this kind of 
issue use (very) fast disks combined with lots of RAM (and possible tiny 
amounts of swap space) nowadays? (Meaning they never notice anything out of the 
ordinary.)

>Please note that KWin maps memory from other applications (window 
>content).

How is that even possible? Do you mean KWin allocates memory to cache or clone 
the window content generated by other applications?

>It might be wrongly attributed and might just go away when the 

I look at the VM usage as reported by htop. I'm fairly certain that it looks at 
actual swap memory usage. It's been a while that I looked at its sources, 
though.
What is certain is that the issue is real. I can almost feel the disk work when 
swap usage goes over 800-900Mb and I do desktop swaps and the like ... or when 
I restart KWin and over 1Gb of space is given back to the free pool.

>compositor is killed. I'm quite certain you look at the wrong offender 
>here.

All I can say is that the memory is released when I restart KWin. I don't know 
exactly what is going on, but unless there are helper applications that are 
also restarted when KWin is restarted I don't see any other explanation or 
other offender. The only other possible memory hog I can think of here is the X 
xerver itself, but that would suppose it needs globs of memory for the window 
decoration.

In fact, what surprises me most is how well so much VM is given back. It's true 
that I use a swap partition so there's no such situation as "can't unlink this 
swap file yet because a tiny portion of it is still in use" but I'm more 
accustomed to swap continuing to grow without ever going back to amount used 
after just logging in.

Cheers,
R.

KWin5 memory leak?

[René J . V . Bertin]

Hi,

This is something I also noticed with KWin4 but which seems to be worse with 
KWin5 (v5.11.1, FW 5.38.0, Qt 5.8.0 and the Breeze windowtheme):

After a big compile job (like building QtWebKit) performed in the background 
(output redirected to file) with Google Chrome and Kontact running (in addition 
to a few Konsoles and Plasma4 [sic] desktop) I often find myself with up to 2Gb 
swap used. That's clearly linked to KWin5 because the swap space is freed only 
after I quit that app. As far as I can tell it doesn't make a significant 
difference here if I do some light browsing or emailing or if I let the build 
complete without touching the computer.

In that case a Chrome extension ("The Great Suspender") will kill my browser 
tabs so the only active screen output comes from Kontact's sync progress bar 
and my screensaver (xscreensaver running the kclock screensaver module).

Why would KWin5 be needing to allocate memory in such scenarios, which 
apparently it never releases until exit?

This is on a laptop with an N3150 Celeron CPU ("Cherry" graphics, i915 driver) 
with kernel 4.9.30 with the ConKolivas extensions. That's an embedded GPU with 
shared video memory, could that have anything to do with what I'm observing 
(I'd hope "something" is clever enough never to swap out VRAM)?

Thanks,
R.

D8307: Make Qt5::X11Extras really optional

[René J . V . Bertin]

rjvbb added inline comments.

INLINE COMMENTS

> apol wrote in CMakeLists.txt:32
> Is this change needed?

I don't understand, since when has DrKonqi been split out of plasma-runtime?

Plasma-runtime had a different approach: search for X11Extras only when X11 was 
found. I think that's the better approach; keep it obligatory with X11 (if 
there's a reason for that), don't bother to look for it when building for 
another platform.

REPOSITORY
  R871 DrKonqi

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D8307

To: kfunk, rjvbb, sitter, davidedmundson
Cc: apol, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, mart

D8308: macOS: Don't create bundles for test executables

[René J . V . Bertin]

rjvbb accepted this revision.
rjvbb added inline comments.

INLINE COMMENTS

> apol wrote in CMakeLists.txt:7
> Maybe we could assume tests are non_gui by default?

For Mac there is only a theoretical difference in fact; nongui builds are 
non-bundled but you have to try really hard nowadays to find an application 
that doesn't work properly without being in an app bundle.

As long as you don't want to test integration with LaunchServices, that is.

REPOSITORY
  R871 DrKonqi

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D8308

To: kfunk, rjvbb, sitter, apol
Cc: apol, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, mart

Re: using KWin's wayland compositor under an X11 session?

[René J . V . Bertin]

Hi,

> ​You can run it nested; so you have a wayland session in a window. Like
> Xephyr.
> 
> But if you want to play with it, just choose it at the login manager, you
> don't need to uninstall X11.

Neither is really what I want, or can (my login manager doesn't know about 
wayland). I do have a VM that gives this choice, but that doesn't work. 
Something to do with OpenGL support in VirtualBox from what I understand.

What I'd like is something seamless, just like one can supposedly run X11 apps 
in a wayland session.

All this may be moot because it never takes long under KWin5/X11 before I start 
getting update glitches when pushing windows to the front or back of the stack 
with keyboard shortcuts, or switching virtual desktops the same way. Looks like 
something is trying to be too clever in determining which screen portions need 
redrawing. I'm not using animations for either operation, which maybe doesn't 
help.

using KWin's wayland compositor under an X11 session?

[René J . V . Bertin]

Hi,

Is it possible somehow to use KWin's wayland compositor when it's acting as the 
window server of an X11 session? I understand that the opposite is possible. I 
have little idea about the technical feasibility of what I'm asking but that 
aside it for anyone like me who feels wayland isn't yet ripe to replace X11 
completely (but who'd still like to start playing with it).

Thanks,
R.

D7640: QtCurve: reduce progressbar timer overhead

[René J . V . Bertin]

rjvbb added a comment.


  Implementing on-demand/JIT starting of the timer also allowed to kill the 
timer when all progressbars stopped animating, in the end. No more need for the 
idling frequency trick.

REPOSITORY
  R626 QtCurve

REVISION DETAIL
  https://phabricator.kde.org/D7640

To: rjvbb, yuyichao, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7640: QtCurve: reduce progressbar timer overhead

[René J . V . Bertin]

This revision was automatically updated to reflect the committed changes.
Closed by commit R626:d9d2bb0dcb01: reduce progressbar animation timer overhead 
(authored by rjvbb).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D7640?vs=19073=19096#toc

REPOSITORY
  R626 QtCurve

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7640?vs=19073=19096

REVISION DETAIL
  https://phabricator.kde.org/D7640

AFFECTED FILES
  qt4/style/qtcurve.cpp
  qt4/style/qtcurve.h
  qt5/style/qtcurve.h
  qt5/style/qtcurve_api.cpp

To: rjvbb, yuyichao, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7640: QtCurve: reduce progressbar timer overhead

[René J . V . Bertin]

rjvbb added a comment.


  Never too old to learn, thanks :)

REPOSITORY
  R626 QtCurve

REVISION DETAIL
  https://phabricator.kde.org/D7640

To: rjvbb, yuyichao, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7640: QtCurve: reduce progressbar timer overhead

[René J . V . Bertin]

rjvbb added a comment.


  >   This should not be necessary. You can add `mutable` or do const cast for 
certain members.
  
  Right. Never used that myself it wasn't my 1st reflex. But I don't see how 
could do either for startTimer()?

REPOSITORY
  R626 QtCurve

REVISION DETAIL
  https://phabricator.kde.org/D7640

To: rjvbb, yuyichao, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7640: QtCurve: reduce progressbar timer overhead

[René J . V . Bertin]

rjvbb set the repository for this revision to R626 QtCurve.

REPOSITORY
  R626 QtCurve

REVISION DETAIL
  https://phabricator.kde.org/D7640

To: rjvbb, yuyichao, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7640: QtCurve: reduce progressbar timer overhead

[René J . V . Bertin]

rjvbb updated this revision to Diff 19073.
rjvbb added a comment.


  Following Breeze's example, we can defer the creation of a timer for the 
busy/indeterminate state to when we encounter one, i.e. when 
`Style::drawControl()` is called with `CE_ProgressBarContents`.
  
  Determining if the timer can be killed is a bit trickier of course (without 
changing considerably more), so I could do this:
  
  1- start the timer if still necessary
  
A- when an animated PB is shown for the 1st time (= as usual), but not when 
a non animated PB is shown.
B- when an indeterminate PB is *drawn* for the 1st time
  
  2- return to the idle frequency when there are no more visible animated PBs 
(= current proposed change)
  3- kill the timer when all PBs are closed, destroyed or hidden
  
  Slight complication: Style::drawControl() is const, so one also has to move 
`m_timer`, `m_progressBarAnimateTimer` and `m_progressBarAnimateFps` to a 
private class, which in addition would have to have a `q` pointer and a 
startParentTimer() "proxy" so we can call Style::startTimer() from a const 
member function.
  
  For now I've only implemented this for Qt5, let me know if this is too much 
(complicated, or of a hack).

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7640?vs=19044=19073

REVISION DETAIL
  https://phabricator.kde.org/D7640

AFFECTED FILES
  qt4/style/qtcurve.cpp
  qt4/style/qtcurve.h
  qt5/style/qtcurve.cpp
  qt5/style/qtcurve.h
  qt5/style/qtcurve_api.cpp
  qt5/style/qtcurve_p.h

To: rjvbb, yuyichao, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7640: QtCurve: reduce progressbar timer overhead

[René J . V . Bertin]

rjvbb added a comment.


  Actually we do when the last progressbar is hidden, destroyed (or gets a 
QEvent::Close, testing that now).
  
  The reason we need to run a timer when progressbars are visible is how their 
busy mode is implemented. That does not have a separate state and there's no 
signal that's sent when the state changes. As far as I've seen the only option 
is polling. I'll have a look at how Breeze and/or Oxygen do this.

REPOSITORY
  R626 QtCurve

REVISION DETAIL
  https://phabricator.kde.org/D7640

To: rjvbb, yuyichao, #plasma
Cc: davidedmundson, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol, mart, lukas

D7640: QtCurve: reduce progressbar timer overhead

[René J . V . Bertin]

rjvbb set the repository for this revision to R626 QtCurve.

REPOSITORY
  R626 QtCurve

REVISION DETAIL
  https://phabricator.kde.org/D7640

To: rjvbb, yuyichao, #plasma
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart, lukas

D7640: QtCurve: reduce progressbar timer overhead

[René J . V . Bertin]

rjvbb updated this revision to Diff 19044.
rjvbb edited the summary of this revision.
rjvbb added a comment.


  cleaned up version that also switches the timer back to idling frequency

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D7640?vs=19042=19044

REVISION DETAIL
  https://phabricator.kde.org/D7640

AFFECTED FILES
  qt4/style/qtcurve.cpp
  qt4/style/qtcurve.h
  qt5/style/qtcurve.h
  qt5/style/qtcurve_api.cpp
  qt5/style/qtcurve_p.h

To: rjvbb, yuyichao, #plasma
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart, lukas

D7640: QtCurve: reduce progressbar timer overhead

[René J . V . Bertin]

rjvbb created this revision.
Restricted Application added a project: Plasma.
Restricted Application added a subscriber: plasma-devel.

REVISION SUMMARY
  Debugging an unrelated timer issue with GammaRay I noticed QtCurve can have 
multiple progressbar timers active in more complex applications like KDevelop 
even when progressbar aren't being animated (or are in fact not being 
shown/active). Progressbar timers run at 20Hz, which seems a bit fast for 
idling.
  
  This patch introduces a rather basic improvement. The progressbar timer is 
started at an idling frequency of 2Hz unless it's being started for a 
progressbar which requires animation. It will then be set to the working 
frequency in the timerEvent callback, if and only if there are progressbars to 
be animated.

TEST PLAN
  Works as expected. There's a small hickup when a progressbar is switched to 
animated (or "busy") mode, but one that ought to be hardly noticeable in real 
life.
  
  The current version of the patch has hysteresis: timers are never switched 
back to idling frequency. I'm looking how much more complex the code becomes 
when they're turned back down as soon as there are no more animated 
progressbars.
  
  NB: I'm not entirely certain why multiple timers would be active, it seems 
there ought only be a single one per process.

REPOSITORY
  R626 QtCurve

REVISION DETAIL
  https://phabricator.kde.org/D7640

AFFECTED FILES
  qt4/style/qtcurve.cpp
  qt4/style/qtcurve.h
  qt5/style/qtcurve.h
  qt5/style/qtcurve_api.cpp
  qt5/style/qtcurve_p.h

To: rjvbb, yuyichao, #plasma
Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, 
abetts, sebas, apol, mart, lukas

Re: start menu icon

[René J . V . Bertin]

On Wednesday August 30 2017 05:20:53 Duncan wrote:


Echoing this to the plasma-devel list so that at least they're aware of the 
use-case (with apologies for top-replying to those who take offense).

If indeed each launcher is a separate plasmoid and each plasmoid has its own 
settings one could expect those to be saved in an application (pardon, 
plasmoid) specific rc file. If that is not the case that probably means that 
plasmoids don't run as individual processes but as are instead run (as scripts) 
by a host application (the plasma shell), and settings are stored in that host 
application's settings file.

I don't think it'd be very difficult to store individual plasmoid settings in 
such a way that they don't overwrite each other, given how the config file APIs 
are designed. In this particular case though it may well be that the 
launcher/kicker settings are stored for/under the plasmoid category instead of 
name so that you can change launchers and find most of your settings in the new 
one.

Even so that would evidently also apply to the icon setting, so my guess is 
that this is not being stored as a plasmoid property, but as a setting for how 
(where, etc) individual plasmoids are displayed. That still doesn't mean that 
the icon *has* to be reset (the other properties like launcher location don't, 
right?) but it seems a bit less surprising that it would be the case.

In short, I don't think it'd be a huge change to implement a sticky custom icon 
feature, but do think like Duncan that it will probably not be considered worth 
the effort (besides, do as the VDG tells you and use Breeze already ;) )

Duncan proposed the approach I also thought of, but that may not be feasible 
because of how settings files are used (typically rewritten as soon as you 
change something, and rarely if ever monitored for external changes). 
Apparently you (Franklin) change your launcher often enough for the icon issue 
to become one, so maybe there's yet another workaround. Myself I use Lancelot 
on my Plasma4 desktop, but sometimes need the standard kicker to save an 
updated session configuration. If that happens I just add the standard kicker 
to my secondary panel, and do what I want to do. If I needed this frequently 
I'd leave the kicker there.
You could try the same thing: add 1 or 2 additional launchers and set them to 
kickoff and/or kickerdash. With luck the plasma shell will remember all 
settings you configure for each of those launchers - if it doesn't you could 
probably report that as a bug that ought to be considered more seriously than 
your original issue.

R.


>Franklin Weng posted on Tue, 29 Aug 2017 20:26:39 +0800 as excerpted:
>
>> In Plasma 5 we can right-click on the start menu and set our own icon.
>> However when I switch my menu from kicker to kickoff or kickerdash, the
>> menu icon changed to the default one and when I switch back to the
>> kicker, my own icon was gone and the default one is used.  Would anyone
>> please tell me how to keep my own icon in the kicker mode, or even when
>> switching to different menu mode?
>
>Good question.
>
>Unfortunately, as implemented it's not possible (except for source 
>patching[1]), and I'm not sure the plasma devs would consider it worth 
>the very likely rather large effort to make it possible.
>
>The problem is that each of the different types of "application launcher" 
>is its own separate "plasmoid", that is, component-widget, complete with 
>its own settings.
>
>For most plasmoids, switching from one to another is a process of 
>deleting the one, selecting add widget, and in the resulting plasmoid/
>widget-explorer dialog, dragging the one you want to replace the one you 
>just deleted to the appropriate location.  Then, depending on the 
>plasmoid, you may have to configure the new one to do what you want.
>
>Now it so happens that with the "launcher" plasmoids, they've created a 
>shortcut to all that, that lets you replace the one launcher with another 
>one without going thru the whole delete/add process manually.  But the 
>different types of launcher are still entirely different plasmoids, each 
>with their own settings and defaults, and replacing one with another 
>deletes the configuration for the replaced one and sets the configuration 
>of the new one to all defaults.
>
>So as I said, you can patch the sources to change those defaults and then 
>you'll get your patch-altered defaults every time you switch, but other 
>than that, there's no real way to do it.
>
>Wait... I actually just thought of another way, that I use sometimes 
>myself.
>
>You can backup the config file before you make your change.  Then make 
>your change, configure the new one as you like, and do a second backup, 
>keeping copies of both.  Then when you need to switch, you can simply 
>kill plasmashell so it doesn't overwrite your changes, restore the 
>appropriate backup with your desired settings, and restart plasmashell so 
>it sees the altered component, 

Re: querying current mouse state

[René J . V . Bertin]

On Thursday August 10 2017 17:15:20 Martin Flöser wrote:

> Point is: if the kernel could read the information from the device, it 
> would know it. I don't think that the kernel knows it, which means I 
> don't think that the device driver has that.

Hmm. That still might make sense for position information (even for a trackpad 
device which must have an internal knowledge where it's being pressed on, 
contrary to traditional mouses/trackballs). But buttons have only 2 states so 
instead of sending a state change signal when one is pressed or released the 
device could just as well send the actual state.


> no idea whether it uses libevdev, but it's of course evdev.

Whichever, it's Linux-specific (with a rather recent port to *BSD IIRC). I 
installed the latest version the other day and decided not to bother installing 
the XOrg libinput plugin/module too because it just seems to add a layer of 
complexity.

R.

Re: querying current mouse state

[René J . V . Bertin]

Martin Flöser wrote:

Hi

> of the buttons, but just sends the press events. I'm pretty sure that
> not even the kernel knows it, otherwise libinput would expose it.

It doesn't need to know it (and probably shouldn't because why would it). All 
it 
needs to know is how to read the information from the device when needed ;)

Libinput is based on libevdev just like good old X11, no?


> For Wayland you can use the KWayland Client library to low level listen
> to the button press/release events. Example code for how to do this is
> in breeze kstyle for manual moving of the window.

OK, I'll have a look, thanks.

R

Re: querying current mouse state

[René J . V . Bertin]

David Edmundson wrote:

> In wayland you never query anything, only track events.

There are applications for which this isn't good enough but I guess there must 
be other, low-level ways to query the current state of a given input device or 
sensor.

> What actually do you want to do?

I'm toying around with a click-and-hold-opens-the-contextmenu feature (ported 
from Mac where this makes a bit more sense), based on the TapAndHold gesture. 
It 
looks like that event is good demonstration why event tracking isn't 100% 
reliable. When I activate processing of that gesture on a QToolButton with a 
menu, it finishes (triggers) even when I am not holding any mouse button. The 
event filter in which I implement this feature also catches MouseRelease and 
MouseMove events (to turn off the gesture processing); I'm not getting those 
either when the QToolButton's menu is open.

IOW, when I click once on the button to open its menu, the contextmenu is 
opened 
too after the expected delay. The only reliable way I found to prevent this is 
to check if the mouse button is still pressed when the TapAndHold gesture 
claims 
to be finished.

R.

querying current mouse state

[René J . V . Bertin]

Hi,

Is there any class or function available in Qt or KF5 that allows to query the 
current state of the mouse on X11 and/or Wayland and that is not based on 
internal event handling? Alternatively, is such a function available in a 
library that is already used anyway by every application that puts up a GUI?

I know I can use XQueryPointer under X11 so if there's a Wayland equivalent for 
that function that'd be fine too.

Thanks,
René

Re: KTitleWidget and the native Mac style

[René J . V . Bertin]

On Wednesday July 05 2017 10:58:59 Hugo Pereira Da Costa wrote:

>No
>the default is false (no frame):
>
>breeze.kcfg:
>
>
>
>false
>
>

Curious, I've always seen Breeze display the frame, and never activated the 
option as far as I can remember. I did notice yesterday that breezerc doesn't 
contain the key at all if you deactivate the option, so it's a bit of a mystery 
how it got set on my end. Maybe the default hasn't always been off?

>> Do you have any idea why moving the QFrame shape and background role 
>> configuration from the KTitleWidget ctor to Style::polish() has this subtle 
>> effect, or why the frame outline is NOT drawn with rounded corners in the 
>> current code?
>nope. but no big deal if there is no frame drawn anyway, right ?

True, but that's assuming you'll get away with removing the feature to draw the 
frame completely. I don't particularly care for it myself I can see how one 
could get to appreciate it :)
Actually, the issue is more "why is the frame ever drawn without rounded 
corners in the current code".

R.

Re: KTitleWidget and the native Mac style

[René J . V . Bertin]

On Wednesday July 05 2017 09:55:27 Hugo Pereira Da Costa wrote:

(CC'ing the plasma-devel ML and thus keeping Hugo's full reply as context.)

>On 07/04/2017 11:13 PM, René J.V. Bertin wrote:
>> On Tuesday July 04 2017 20:16:55 Sebastian Kügler wrote:
>>
>> @Kevin: should we continue to CC you?
>>
>>> The frame in my understanding is old weight, and can go (do check with the 
>>> VDG
>>> though!)
>> Thing is that you cannot simply get rid of the QFrame, it would at least 
>> have to be replaced with something invisible that can take over its other 
>> role.
>>
>> What works (mostly) is something like this:
>>
>> KTitleWidget::KTitleWidget(QWidget *parent)
>>  : QWidget(parent),
>>d(new Private(this))
>> {
>>  QFrame *titleFrame = new QFrame(this);
>> // titleFrame->setAutoFillBackground(true);
>> // titleFrame->setFrameShape(QFrame::StyledPanel);
>>  titleFrame->setFrameShadow(QFrame::Plain);
>> // titleFrame->setBackgroundRole(QPalette::Base);
>>
>>  // default image / text part start
>>  d->headerLayout = new QGridLayout(titleFrame);
>>  d->headerLayout->setColumnStretch(0, 1);
>> // d->headerLayout->setMargin(6);
>>  d->headerLayout->setContentsMargins(0, 0, 0, 0);
>> //...
>> }
>>
>> and replace `d->textLabel->setStyleSheet(d->textStyleSheet())` with
>>
>> d->textLabel->setFont(QFontDatabase::systemFont(QFontDatabase::TitleFont));
>>
>> (that will use the window titlebar font, but also when no platform theme 
>> plugin -aka plasma-integration- is installed).
>>
>> in Breeze we can then do
>>
>>  } else if( qobject_cast( widget ) && widget->parent() && 
>> widget->parent()->inherits( "KTitleWidget" ) ) {
>>
>>  QFrame *frame = qobject_cast( widget );
>>  if( StyleConfigData::titleWidgetDrawFrame() ) {
>>  frame->setAutoFillBackground( true );
>>  frame->setFrameShape( QFrame::StyledPanel );
>>  frame->setBackgroundRole( QPalette::Base );
>>  // make the title frame a bit less luxuriously big, and centre 
>> the text vertically
>>  frame->layout()->setContentsMargins(3, 3, 3, 0);
>>  } else {
>>  frame->setAutoFillBackground( false );
>>  frame->setFrameShape( QFrame::NoFrame );
>>  frame->setBackgroundRole( QPalette::Window );
>>  // don't take extra space for a frame we're not showing at all
>>  frame->layout()->setContentsMargins(0, 0, 0, 0);
>>  }
>>
>>  }
>Concerning the change in breeze:
>1/ I would gladly get rid of the option to draw the frame at all (not 
>sure anyone uses this anyway)

Given that it's the default I have a hunch many people actually do (if you can 
call that "using" ;)). What you can do is start by not drawing the frame by 
default, possibly disable the option to enable drawing it in breeze-settings5 
and see what kind of feedback you get on that.
Do you have any idea why moving the QFrame shape and background role 
configuration from the KTitleWidget ctor to Style::polish() has this subtle 
effect, or why the frame outline is NOT drawn with rounded corners in the 
current code?

>2/ however, the default layout should not change with respect to what we 
>have now, unless blessed by the vdg and plasma team.
>That implies:
>- keep the current font size increment
>- don't change the margins.

Was the font increment blessed by either when Sebas introduced it, or maybe 
just the general idea of using a larger font?
I've CC'ed the plasma-devel ML, maybe you (Hugo) can loop in (someone from) the 
vdg team?

This also implies that appropriate display of the KTitleWidget on Mac (and MS 
Windows?) will require testing for the style in use in KWidgetsAddons.

R.

D5825: kcheckpass: Add support in for non-Linux platforms via kevent.

[René J . V . Bertin]

rjvbb added a comment.


  >   Nevertheless OS X is not supported by kscreenlocker and will never be.
  
  You got it all wrong, OS X doesn't support kscreenlocking, gna!
  
  (If I were still a fanboy I'd add that it's way too kool to support running 
most kinds of plasma O:^) )

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D5825

To: tcberner, #freebsd, graesslin, kde-mac, davidedmundson
Cc: rjvbb, adridg, davidedmundson, plasma-devel, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D5825: kcheckpass: Add support in for non-Linux platforms via kevent.

[René J . V . Bertin]

rjvbb added a comment.


  In https://phabricator.kde.org/D5825#112464, @davidedmundson wrote:
  
  > OS X is not a supported Plasma platform, BSD is.
  
  
  Just for future reference: OS X doesn't have sigwaitinfo() (or the cited 
alternative).

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D5825

To: tcberner, #freebsd, graesslin, kde-mac, davidedmundson
Cc: adridg, davidedmundson, plasma-devel, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D5825: kcheckpass: Add support in for non-Linux platforms via kevent.

[René J . V . Bertin]

rjvbb added a comment.


  Already getting updates through kde-mac, no need to receive everything twice.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D5825

To: tcberner, #freebsd, graesslin, kde-mac
Cc: adridg, davidedmundson, plasma-devel, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D5825: kcheckpass: Add support in for non-Linux platforms via kevent.

[René J . V . Bertin]

rjvbb added a comment.


  In https://phabricator.kde.org/D5825#112442, @tcberner wrote:
  
  > > Do you actually intend to test this on Mac?
  >
  > Nope, I don't have a Mac :) -- but I hoped, that there were some Mac users 
who could check it on their end too (as you also have kqueue/kevent) -- but I 
did not know that most of the stuff is not yet ported for Mac.
  
  
  You ought to be able to set up a VM (or build a dual-boot Hackintosh ;)) but 
there are several reasons why this endeavour is a bit futile on Mac. The most 
important of which are that Qt and KF5 code in general assume that X11 isn't 
available (or shouldn't be used) on Mac, and a prevalent apparent attitude 
among many (or just the most vocal) Plasma devs that Plasma is off-limits on 
Mac.
  
  But even without those obstacles, the XQuartz X11 environment runs as an 
"embedded server" inside a standard Aqua session and I don't know of any way to 
run any other kind of session. Of course you can run an X11 screensaver and/or 
screenlocker but what's the point if you already have the same functionality in 
the main session? In fact, the same *but full-featured* functionality; I 
strongly doubt that an X11 screenlocker will (nor should) provide features to 
suspend, shutdown/restart the system or login as another user.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D5825

To: tcberner, #freebsd, graesslin, kde-mac
Cc: rjvbb, adridg, davidedmundson, plasma-devel, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

D5825: kcheckpass: Add support in for non-Linux platforms via kevent.

[René J . V . Bertin]

rjvbb added a comment.


  In https://phabricator.kde.org/D5825#109698, @tcberner wrote:
  
  > I have not yet had time to test it at all :)
  
  
  Do you actually intend to test this on Mac? I laud and applaud the initiative 
but I see only one way that the package will ever get used on Mac - providing 
KWin as a standalone alternative *X11* window manager for use under XQuartz 
(knowing that XQuartz currently doesn't support compositing). And that's not 
possible with stock Qt (not until some of us team up to polish my PoC 
Qt/XCB-on-Mac patches and submit them for upstream incorporation; the Qt guys 
are likely to accept them as it'd fit with their policy and there might be a 
"market").
  
  FWIW, funny coincidence, I did manage to build kscreenlocker 5.9.3 on Mac 
last week, simply #ifdeffing-out parts of the code that where Linux specific or 
required an X11 KWindowSystem build (I just build the plugin). The screenlocker 
blacks out the screen but lacking keyboard event support it had to be killed. 
Or just quit via the native Mac menu item, which kind of defeats the purpose of 
a screenlocker ;)
  
  FWIW2: if you feel like starting a crusade against linuxisms, please do start 
with libwayland. It has a number of those (signalfd, epoll) which stand in the 
way of bringing Wayland to Mac, and there'd definitely be a market for that.

REPOSITORY
  R133 KScreenLocker

REVISION DETAIL
  https://phabricator.kde.org/D5825

To: tcberner, #freebsd, graesslin, kde-mac
Cc: rjvbb, adridg, davidedmundson, plasma-devel, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas

Re: Next Gen CI Will Be Moving to Production Shortly: Upcoming Changes

[René J . V . Bertin]

On Saturday May 06 2017 22:01:58 Ben Cooksley wrote:
>On Sat, May 6, 2017 at 9:58 PM, René J.V. Bertin  wrote:
>> On Saturday May 06 2017 21:37:51 Ben Cooksley wrote:
>>
>>>'Platforms' on which they build. At the moment we have three Platforms
>>>available: Ubuntu Xenial Qt 5.7, Windows Qt 5.7 and FreeBSD Qt 5.7.
>>>Adding additional Platforms to this mix is fairly easy, as long as the
>>>code can be built there. Qt will now be considered as part of the base
>>>system, and is something we will no longer build ourselves.
>>
>> One remark about this: Qt 5.7 is not the most issue-free version but I 
>> understand why the 5.6 LTS version was not preferred instead. However, there 
>> is 1 thing with using stock Qt that's potentially problematic on a CI. It 
>> lacks a QtDBus patch that Qt cannot at the moment incorporate but that 
>> everyone should be using because it prevents crashing on exit under certain 
>> conditions.
>
>It'll be up to the system distributor in that case to include the
>patch. We shouldn't be including patches the system distributor isn't
>in any case, as that will lead to a different environment compared to
>our users.

That works both ways. It's Qt's intention that distributions and "home 
builders" include the patch, so you can also adopt the position that a CI 
intended to find issues with KDE software shouldn't be vulnerable to issues in 
KDE dependencies that are not supposed to be present on user systems.
Note that I myself wouldn't really know which position to adopt... but I would 
probably avoid ambiguity and provide the dependencies with all known issues 
either explicitly fixed or explicitly NOT fixed (the latter being the easy 
solution). Depending on the decisions of a single "system distributor" chosen 
among the myriad of distributors (for Linux at least) seems ... problematic in 
this aspect.

>Note that for Windows and Mac we shouldn't be doing D-Bus anyway as
>they're alien to that platform

This is not exactly true and IMHO not a decision to be imposed by something 
like a CI. The DBus daemon includes support for both platforms and should be 
seen as a cross-platform desktop IPC solution which is also the only IPC 
interface Qt provides to my knowledge. Interdicting DBus use on Mac and MS 
Windows would make those platforms inaccessible to projects like KDEPIM. I 
don't think they'd appreciate that.
In fact, any application using KWallet will probably run into issues.

>(and the CI Tooling won't launch D-Bus
>as part of it's test environment setup there as a result)

The QtDBus issue itself does *not* depend on whether a DBus daemon is running 
or not, it's purely internal to Qt.

R.

Re: Next Gen CI Will Be Moving to Production Shortly: Upcoming Changes

[René J . V . Bertin]

On Saturday May 06 2017 21:37:51 Ben Cooksley wrote:

>'Platforms' on which they build. At the moment we have three Platforms
>available: Ubuntu Xenial Qt 5.7, Windows Qt 5.7 and FreeBSD Qt 5.7.
>Adding additional Platforms to this mix is fairly easy, as long as the
>code can be built there. Qt will now be considered as part of the base
>system, and is something we will no longer build ourselves.

One remark about this: Qt 5.7 is not the most issue-free version but I 
understand why the 5.6 LTS version was not preferred instead. However, there is 
1 thing with using stock Qt that's potentially problematic on a CI. It lacks a 
QtDBus patch that Qt cannot at the moment incorporate but that everyone should 
be using because it prevents crashing on exit under certain conditions.

R.

D5186: Add a widget style chooser to oxygen-demo

[René J . V . Bertin]

rjvbb abandoned this revision.
rjvbb added a comment.


  Closed with commit 
https://commits.kde.org/oxygen/3677f75e956e1946cd0ee775ff2969d0b2ecf1c7

REPOSITORY
  R113 Oxygen Theme

REVISION DETAIL
  https://phabricator.kde.org/D5186

To: rjvbb, hpereiradacosta
Cc: plasma-devel, #plasma, spstarr, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol

D5186: Add a widget style chooser to oxygen-demo

[René J . V . Bertin]

rjvbb set the repository for this revision to R113 Oxygen Theme.

REPOSITORY
  R113 Oxygen Theme

REVISION DETAIL
  https://phabricator.kde.org/D5186

To: rjvbb, hpereiradacosta
Cc: plasma-devel, #plasma, spstarr, progwolff, lesliezhai, ali-mohamed, 
jensreuterberg, abetts, sebas, apol