Yea, also mind you it's only set in the X11 case. Under Wayland the viewports limits call is irrelevant. If std:: function is set to some function you can check easily as it's overloads the bool operator.
Like it does here: https://gitlab.com/kwinft/kwinft/-/blob/master/render/gl/scene.cpp#L725
Can you show me what you got until now or tell me what you're struggling with? Maybe I can help you with it.
two commits mostly backported things https://gitlab.com/tomenglund26/kwinft/-/commits/bugs , still have some investigation todo about tests failing, https://gitlab.com/tomenglund26/kwinft/-/commit/d25a443ded084814e7d7c9654af6093bbd9f3a5b#347d978fa03c64c4765ccf0b2b3189ab20165b81_625_628 but yeah mostly only the virtual_desktop_manager access left
Roman Gilg: cool kwin debug console has a decoration now, seems there was a bunch of dangling references to temporarys :p
still unmovable tho :(
also solves the decoration nullptr crash when exiting debug console ;)
hm kwin only lets you move kwin debug console on wayland. oh well
Roman Gilg: did make a draft that could use some help on either the space ref or integration struct, the rest i should be able to figure out
1 reply
Roman Gilg: oh dont worry, i left a wall of loud thinking :D , i did notice the kwin_debug console is movable in wayland if you press mod4/windows button and within milliseconds try to drag the window and release both, and keep repeating. and if you have done it once or twice so its moved. it wont crash when pressing quit console, otherwise it hits this
#0 0x00007f85d1a15765 in std::__uniq_ptr_impl<KWin::render::effects_window_impl, std::default_delete<KWin::render::effects_window_impl> >::_M_ptr (this=0x8)
at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/bits/unique_ptr.h:191
191 pointer _M_ptr() const noexcept { return std::get<0>(_M_t); }
[Current thread is 1 (Thread 0x7f85ca187c00 (LWP 553891))]
(gdb) bt
#0 0x00007f85d1a15765 in std::__uniq_ptr_impl<KWin::render::effects_window_impl, std::default_delete<KWin::render::effects_window_impl> >::_M_ptr() const (this=0x8)
at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/bits/unique_ptr.h:191
#1 0x00007f85d1a066e5 in std::unique_ptr<KWin::render::effects_window_impl, std::default_delete<KWin::render::effects_window_impl> >::get() const (this=0x8)
at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../include/c++/12.1.0/bits/unique_ptr.h:462
#2 0x00007f85d1a019b0 in KWin::render::effects_handler_impl::setupAbstractClientConnections(KWin::Toplevel*)::$_28::operator()() const (this=0x55a839fbc230)
at /home/tom/dev/aur/kwinft-git/src/kwin/render/effects.cpp:388
#3 0x00007f85d1a01946 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, KWin::render::effects_handler_impl::setupAbstractClientConnections(KWin::Toplevel*)::$_28>::call(KWin::render::effects_handler_impl::setupAbstractClientConnections(KWin::Toplevel*)::$_28&, void**) (f=..., arg=0x7fffa224aa70)
at /usr/include/qt/QtCore/qobjectdefs_impl.h:146
#4 0x00007f85d1a01911 in QtPrivate::Functor<KWin::render::effects_handler_impl::setupAbstractClientConnections(KWin::Toplevel*)::$_28, 0>::call<QtPrivate::List<>, void>(KWin::render::effects_handler_impl::setupAbstractClientConnections(KWin::Toplevel*)::$_28&, void*, void**) (f=..., arg=0x7fffa224aa70) at /usr/include/qt/QtCore/qobjectdefs_impl.h:256
#5 0x00007f85d1a018b1 in QtPrivate::QFunctorSlotObject<KWin::render::effects_handler_impl::setupAbstractClientConnections(KWin::Toplevel*)::$_28, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x55a839fbc220, r=0x55a83950f710, a=0x7fffa224aa70, ret=0x0) at /usr/include/qt/QtCore/qobjectdefs_impl.h:443
#6 0x00007f85d08bd341 in () at /usr/lib/libQt5Core.so.5
#7 0x00007f85d192d895 in KWin::Toplevel::visible_geometry_changed() (this=0x55a8396c50c0) at kwin_autogen/EWIEGA46WW/moc_toplevel.cpp:974
#8 0x00007f85d1b2826d in KWin::Toplevel::Toplevel(KWin::win::transient*, KWin::win::space&)::$_4::operator()<KWin::Toplevel*, QRect>(KWin::Toplevel*, QRect const&) const
(this=0x55a839f75c70, win=0x55a8396c50c0, old_geo=...) at /home/tom/dev/aur/kwinft-git/src/kwin/toplevel.cpp:66
window->render seems null so was currently checking kwinft/kwinft@783ab3e
1 reply
going to the second home today but il bring this laptop with me, but thought id mention it kwinft/kwinft!220 the last pic of the hamburger menu stacking wrong has something todo with https://gitlab.com/kwinft/kwinft/-/blob/master/win/wayland/subsurface.h#L32 fiddling around i removed the reference so it didnt change a thing and all of a sudden it stacked properly xD
Can't really explain that either. First I thought the local variable is destroyed later, but the
subsurface_stacker is only ever called in the same function call. But it's definitely fine to remove this reference.
1 reply
Pretty wild.
Have to look that up.
I expected it to be an invariant at the point the rendering of the window is executing.
https://i.imgur.com/KGuSKLF.jpg pretty much this, i wonder if the stacking order change made this hrm
tried changing to non references all over didnt make much difference
its there! only stacked below the mainwindow ;p
1 reply
time to bisect then i guess, because what i can recall it was working sometime ago
1 reply
Currently we put annexed children always on top of their lead. But Firefox sometimes put its subsurfaces below it.
We basically need a second list of children of a lead which are behind it.
that would explain that because ive bisected further then i think it should be possible
and it still occured! :P
also whats worth noting is that firefox adds two surfaces/windows on each uh "task" open kwin debug console, any window konsole/plasma or whatever adds one entry. open firefox? firefox adds one entry and one very weird unnamed one. https://gitlab.com/kwinft/kwinft/-/merge_requests/229/diffs?commit_id=64867a31456a5b72c9ffb45a818392ee6268c19f debug console needs this tho for that so it doesnt crash :p , open the hamburger menu? two entries appear etc.
https://i.imgur.com/WSX1UzD.jpg pretty much like this
oh well gotta hit the bed
Tom Englund: soon making a MR with a few changes to debug console, think i need this tool before i can proceed with both the firefox issue and the rules draft :p
eh Roman Gilg above. seems i highlighted myself :D
figured out why it got halfly decorated and placed outside screen geometry and crashing etc, was simply X11BypassWindowManagerHint , removed that on the wayland side and tada it gets positioned correctly, decorated etc
now just to figure out why window propertys just list "objectName" and im pushing :p
1 reply
Tom Englund: They are still a qobject, but the Q_PROPERTY macros have been moved from Toplevel class to the script::window class.
So that's why the runtime may not find the properties anymore.
good question i think ive read through the source 10 times and i dont quite get it
There is this console_model::propertyData function. maybe that's it.
2 replies
its like all its doing is checking for index, columns, rows and simply adds the window and it magically knows? :D
In get_client_property_data it does an implicit cast of the window to QObject* when calling propertyData
So maybe we could at this position cut the patient open and instead of doing a cast of the window a cast of the respective
script::window.
This should at least work for windows published to the scripts system (windows with control in general).
So here don't cast from the window, but from the window in script namespace.
That's this class with all the juicy Q_PROPERTYs: https://gitlab.com/kwinft/kwinft/-/blob/master/scripting/window.h
I assume (hope) it's somewhat composited into it. Or if not (yet) then we need to go via the global space instance.