> 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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
