> On April 11, 2016, 5: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") > > 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. > > Anthony Fieroni wrote: > 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 :) > > Thomas Lübking wrote: > That patch only works around a bug in Qt (for KXMLGui windows, everything > is still affected) > That bug *might* be related to your problems with positioning - reverting > the patch rather won't help you here. > > What you want to know is whether the windows that fail to reposition > during session start have those WM_SIZE_HINTS set. For if not, it's no wonder > that the WM positions them and QWidget::move is simply broken for unmanaged > non-override-redirects. > > Anthony Fieroni wrote: > Can i set WM_SIZE_HINTS explicit? > > Thomas Lübking wrote: > Not w/o operating on X11 code, but one could try to cheat Qt into doing > it likewise (since i frankly doubt, there's any upstream interest in fixing > deprecated things like desktop functionality - rather on the contrary) > > Ftr: they're not set? > > Anthony Fieroni wrote: > How can i test it, easy, i don't get it. > > Martin Gräßlin wrote: > xprop the window - it will have a section like > WM_NORMAL_HINTS(WM_SIZE_HINTS): > program specified minimum size: 300 by 166 > program specified maximum size: 32767 by 32767 > window gravity: NorthWest > > Anthony Fieroni wrote: > [toni@toni-sony ~]$ xprop > _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 2, 2, 24, 4 > _NET_FRAME_EXTENTS(CARDINAL) = 2, 2, 24, 4 > _NET_WM_DESKTOP(CARDINAL) = 0 > WM_STATE(WM_STATE): > window state: Normal > icon window: 0x0 > _NET_WM_STATE(ATOM) = > _NET_WM_ICON_GEOMETRY(CARDINAL) = 502, 736, 256, 30 > _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, > _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_SHADE, > _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MAXIMIZE_HORZ, > _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE > _KDE_NET_WM_ACTIVITIES(STRING) = "153b4652-e23a-44c6-baf7-e7a0d812498a" > _NET_WM_USER_TIME(CARDINAL) = 372774774 > _NET_WM_ICON_NAME(UTF8_STRING) = > XdndAware(ATOM) = BITMAP > WM_NAME(STRING) = > _NET_WM_NAME(UTF8_STRING) = "Akregator" > _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0 > _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL > _XEMBED_INFO(_XEMBED_INFO) = 0x0, 0x1 > WM_CLIENT_LEADER(WINDOW): window id # 0x5000006 > WM_HINTS(WM_HINTS): > Client accepts input or input focus: True > Initial state is Normal State. > _NET_WM_PID(CARDINAL) = 3834 > _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 83886085 > WM_CLASS(STRING) = "akregator", "akregator" > WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, > _NET_WM_PING, _NET_WM_SYNC_REQUEST > WM_NORMAL_HINTS(WM_SIZE_HINTS): > user specified size: 980 by 602 > program specified minimum size: 325 by 237 > window gravity: Static > > Thomas Lübking wrote: > As predicted the client does not request some position, thus is > necessarily subject to positioning. QWidget/QWindow bug for sure. > No idea whether one can cheat QWidget into setting the flag or how many > years it will take to convince them that this is important :-( > > Anthony Fieroni wrote: > It must contribute to Qt to fix this issue, i'm not right person to do it. > So since this patch is unwanted i will discart reviview
If there is no or little regression potential, I don't think it will be hard to convince Qt maintainers to merge a simple patch. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/127631/#review94513 ----------------------------------------------------------- On April 10, 2016, 7: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, 7: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 > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
