Review Request 127631: [ksmserver] We must be sure that kwin process is ended
Martin Gräßlin
mgraesslin at kde.org
Mon Apr 11 15:34:54 UTC 2016
> On April 11, 2016, 7:45 a.m., 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.
>
> Thomas Lübking wrote:
> 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")
To answer what Qt does:
const quint32 mask = XCB_CONFIG_WINDOW_X | XCB_CONFIG_WINDOW_Y | XCB_CONFIG_WINDOW_WIDTH | XCB_CONFIG_WINDOW_HEIGHT;
const qint32 values[] = {
qBound<qint32>(-XCOORD_MAX, wmGeometry.x(), XCOORD_MAX),
qBound<qint32>(-XCOORD_MAX, wmGeometry.y(), XCOORD_MAX),
qBound<qint32>(1, wmGeometry.width(), XCOORD_MAX),
qBound<qint32>(1, wmGeometry.height(), XCOORD_MAX),
};
Q_XCB_CALL(xcb_configure_window(xcb_connection(), m_window, mask, reinterpret_cast<const quint32*>(values)));
That code looks correct to me and even if or if not a WM is running should not matter.
- Martin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127631/#review94513
-----------------------------------------------------------
On April 10, 2016, 9:46 p.m., Anthony Fieroni wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127631/
> -----------------------------------------------------------
>
> (Updated April 10, 2016, 9:46 p.m.)
>
>
> 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/16ff20b0/attachment-0001.html>
More information about the Plasma-devel
mailing list