> On Април 11, 2016, 8:45 преди обяд, 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") > > Martin Gräßlin wrote: > 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. > > Anthony Fieroni wrote: > T: "=> Does this work (leaving aside session restorage), yes or no?" > A: setGeometry *NOT* work > T: "What exactly is the problem here?" > A: a) the windows are not visible when the session restarts. Showing them > show them in wrong position > Position is depend on "placement" -> https://i.imgur.com/tzwJ1Lk.png > "2. The window does not get saved with the session and picks its new > position in a different way" > First show() always depend on "placement" i.e. if widget was shown when > leave session it will shown on right place, if was hidden first show depend > on "placement". But if Kwin is not started *always* depend on "placement" > "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)" > > Thomas Lübking wrote: > > A: setGeometry NOT work > > In total? Ie. the other patch is *completely* dysfunctional? > > Anthony Fieroni wrote: > What you mean "in total"? setGeometry() and move() works when app is > started *after* kwin and not before it. I.e. i can't write in more clear > words, my english is till here, > Kwin is stared before apps: > 1. setGeometry(), move() always works > Kwin not stated before apps: > 1. setGeometry(), move() if new values are same as internal widget => > placement > 2. setGeometry(), move() differs internal widgets => works i.e. > move(geometry().topLeft()) causing the bug. > > Anthony Fieroni wrote: > I mean > i.e. move(frameGeometry().topLeft()) causing the bug. > move(geometry().topLeft()) => placement > > Thomas Lübking wrote: > > move() works when app is started after kwin and not before it > > Means that the no-WM path in QWidget/QWindow doesn't set > USPosition/PPosition > Is or is related to QTBUG-40584. > > You can check that by running xprop on such (placed) window, it should > have some > > user specified location: <x> <y> > or > program specified location: <x> <y> > > If not, then the window doesn't signal the WM that it was explicitly > positioned (and will be placed on map requests) > > Andreas Hartmetz wrote: > Possibly the whole thing is moot. Due to a new bug in Qt 5.6 which has > been recently fixed (b77ef8a7e6e4104067d52824e29eadc8c66f5929 / "QtDBus: > clean up signal hooks and object tree in closeConnection"), applications got > stuck when they were supposed to terminate. This made session exit act > strangely, essentially some applications didn't shut down cleanly and were > forcibly killed tens of seconds later. ksmserver stuck around, too, waiting > for them. I haven't done a real or mental trace through ksmserver but such a > situation *can* mess with session saving.
Andreas, i notice it, but this stays before Qt 5.5, it's works correct on Qt 5.4 or 5.3 i can't remember when exactly was broken. Thomas, if you mean this -> https://git.reviewboard.kde.org/r/120078/ i can test it without this patch, but bug is removed, i don't know it's fixed :) - Anthony ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127631/#review94513 ----------------------------------------------------------- On Април 10, 2016, 10:46 след обяд, Anthony Fieroni wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/127631/ > ----------------------------------------------------------- > > (Updated Април 10, 2016, 10:46 след обяд) > > > 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
