Review Request 127631: [ksmserver] We must be sure that kwin process is ended

Thomas Lübking thomas.luebking at gmail.com
Mon Apr 11 15:19:29 UTC 2016 


> On April 11, 2016, 5:45 vorm., Martin Gräßlin wrote:
> > > otherwise kwindowsystem::self() is nullptr
> > 
> > how can KWindowSystem::self() be null? And why should that have anything to do with KWin? KWindowSystem does not depend on a window manager running.
> 
> Thomas Lübking wrote:
>     The entire thing sounds as if the problem would be that the session restorage in kwin overrides the placement for restored windows (with the restored position)
>     
>     That's however not a bug (at least it's intended) and I've no idea why that's relevant to the weird geometry handling of SNI items (which looks *faaaar* too complex - the position of remapped windows is usually maintained by QWidget ...)
> 
> Anthony Fieroni wrote:
>     I saw the code, it looks like KWindowSystem not depend on Kwin, but Kwin *must* be started *before* use of kwindowsystem. Thomas may right, because setGeometry even not work on sessions restored app.
>     When session was finish if start apps with kmail --session session-id everything wors fine.
> 
> Anthony Fieroni wrote:
>     Now, after Thomas comment, i even think only widget->show() must works because widget has internal frameGeometry and position.
> 
> Martin Gräßlin wrote:
>     > but Kwin must be started before use of kwindowsystem
>     
>     no, really there is no reason for that. KWindowSystem doesn't depend on a window manager running.
> 
> Anthony Fieroni wrote:
>     Then, correct KWin to kwindowsystem to start working. If there is no bug this will works on all cases -> https://git.reviewboard.kde.org/r/127216/ but it's not.
> 
> Martin Gräßlin wrote:
>     I don't know why you have problems, but it's impossible that KWindowSystem::self() returns a nullptr. You can check the code to verify. Something is really broken on your side, but I don't know what. Maybe missing plugins installed?
> 
> Thomas Lübking wrote:
>     it's not a hard dependecy on the instace, the sni geometry handling is just plain broken.
>     the workaround operates on configure events on the mapped window which will go nowhere if there's no running wm.
>     
>     the client needs to handle the no-wm case, ie. configure the window correctly, but to repeat myself: such requirement implies that either sni or qwidget/qwindow is completely fucked up.
>     
>     qwindow/qwidget::setGeometry should justwork(tm)
> 
> Anthony Fieroni wrote:
>     setGeometry *not* works, i can confirm since i'm test it. Nothing works if Kwin is started *after* usage of kwindowsystem::self().
>     Martin yeah nullprt is impossible.
> 
> Martin Gräßlin wrote:
>     then this is a bug in Qt's xcb plugin and needs to be fixed there. Setting a geometry without a window manager must be possible.
> 
> Anthony Fieroni wrote:
>     Wait a little, the bug is not in xcb. I'm not clear or what. This *happend* only on session restored apps, when kwindowsystem::self() is before kwin statup, only in this case. If run a app after kwin is started *all* works fine setGeometry(), move() - no problems.
> 
> Anthony Fieroni wrote:
>     Thomas Lübking wrote:
>      The entire thing sounds as if the problem would be that the session restorage in kwin overrides the placement for restored windows (with the restored position)
>      
>     For me, this is best explanation. Adn give you the easiest, no pain, working solution - wait kwin to start completely.
> 
> Martin Gräßlin wrote:
>     > Adn give you the easiest, no pain, working solution - wait kwin to start completely.
>     
>     I disagree. Working around such problems in the session startup seems wrong. I would say excluse the sni windows from session restore, which can be done from Qt API.

Can we please get few things straight?

You say that ::setGeometry doesn't work, but https://git.reviewboard.kde.org/r/127216/diff/5#index_header makes use of it (uses the propsed internally saved position and restores it with QWidget::move what's basically a ::setGeometry special case)

    => Does this work (leaving aside session restorage), yes or no?

Assuming it *does* work (except for session restorage) the claims to require a WM for operative KWindowSystem invocation are gladfully, since you're not using KWindowSystem at all.


Now onto session restorage:
---------------------------
What exactly is the problem here?
a) the windows are *not* visible when the session restarts. Showing them show them in wrong position
b) the windows *are* visible when the session restarts, but in wrong position?

In either case, the session restored geometry and the SNI internal geometry should *not* differ.

If they do there're two possible problems:
1. The window gets stored with the session, but the stored position is wrong (check the kwin session file in ~/.config/session on whether it contains such window and what position is saved)
2. The window does not get saved with the session and picks its new position in a different way

(2) has alternative failure points:
a) the window isn't positioned at all
b) the window gets a QWidget::move call from the SNI code, but that's ineffective (ie. QWidget::move fails if there's no WM)


I agree with Martin that waiting for the WM is ridiculous and only stashes the actual bug.
Either the wrong geometry is stored (and thus falsely restored) => we need to fix that
Or QWidget::move requires a running WM, what's simply a bug in Qt and *must* be fixed there, despite I severely doubt it will, even if you bang them with tons of patches...


Last hint:
----------
if the affected SNI window(s) are modal (open a nested eventloop) the problems may be an outflow of https://bugreports.qt.io/browse/QTBUG-40584
(the patch likely won't apply anymore and there's obviously no interest in fixing Qt/Desktop, so cc.: please get used to use fullscreen QML apps and forget about things like "windows")


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127631/#review94513
-----------------------------------------------------------


On April 10, 2016, 7:46 nachm., Anthony Fieroni wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127631/
> -----------------------------------------------------------
> 
> (Updated April 10, 2016, 7:46 nachm.)
> 
> 
> Review request for kwin, Plasma, David Edmundson, Martin Gräßlin, and Thomas Lübking.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> -------
> 
> We must proceed with autoStart0 when kwin process is ended otherwise kwindowsystem::self() is nullptr. Every restored session app cannot use kwindowsystem. This depends of cpu speed, it can be faster enough to start wm before ksmserver restore apps and kwindowsystem will be usable.
> 
> 
> Diffs
> -----
> 
>   ksmserver/startup.cpp f118b55 
> 
> Diff: https://git.reviewboard.kde.org/r/127631/diff/
> 
> 
> Testing
> -------
> 
> It's needed to fix this bug -> https://git.reviewboard.kde.org/r/127216/
> I don't know how to proceed if kwin fails to start in every way, can we process - i think not?
> 
> 
> Thanks,
> 
> Anthony Fieroni
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20160411/f2476d53/attachment.html>

More information about the Plasma-devel mailing list