Review Request 125259: Support multiple X servers in the NETWM classes
Thomas Lübking
thomas.luebking at gmail.com
Thu Sep 17 07:00:41 UTC 2015
> On Sept. 16, 2015, 4:23 nachm., Thomas Lübking wrote:
> > would one want to use the occasion to get rid of the bazillion variables mapped to a struct array and have atom(Atom a) and atomString(Atom a) for an array of atoms a matching string - maybe including some namespaces so that instead of p->atom->net_wm_to_many_underscores one would have atom(NET::WM::NoUnderscores) and atom(WM::NoUnderscores) etc.?
> >
> > Ideally with a little preprocessor and include magic?
> > http://stackoverflow.com/questions/147267/easy-way-to-use-variables-of-enum-types-as-string-in-c
>
> Martin Gräßlin wrote:
> rather orthogonal to the change. I'm not sure whether a huge switch statemement will make it better. What might be more interesting is to get something like KWin's Xcb::Atom in to also only fetch the atoms which are actually used. Though the Atom class is of course considerable larger than just an xcb_atom_t.
The switch in the demo code is just a usage demo - I'd promise red overweight ;-)
Constantly using atom(Atom a) would of course allow a sparse array that mostly contains of "0" and is only filled on demand.
The reason why I thought it might be a good idea *now* is because this already requires a HUUUUUGE change that will block git blame.
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125259/#review85501
-----------------------------------------------------------
On Sept. 16, 2015, 1:42 nachm., Martin Gräßlin wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125259/
> -----------------------------------------------------------
>
> (Updated Sept. 16, 2015, 1:42 nachm.)
>
>
> Review request for KDE Frameworks and kwin.
>
>
> Repository: kwindowsystem
>
>
> Description
> -------
>
> So far on first creation of a NETRootInfo or NETWinInfo a static
> initialization of atoms was performed. This meant that the NET classes
> are only able to interact with the X server the first NET class is
> connected to.
>
> Normally applications don't need to interact with multiple X servers.
> An exception is kwin_wayland which needs a connection to its Xwayland
> server and on the x11 backend to the X server it renders to. So far
> KWin could not use the NET classes for it, causing the rendering window
> to e.g. not have a window title.
>
> This change removes the implicit constraint on one X server by
> creating a hash of connection and atoms. For each created NET class
> we check whether we have already resolved the atoms, if yes we reuse
> otherwise we create them.
>
> For the normal use case of one X11 connection the change should be
> rather minimal. Instead of performing the check whether the static
> atoms have been created, it now is a check whether the atoms for the
> connection have been created. The atoms are kept in a
> QSharedDataPointer ensuring that we don't needless copy the atoms into
> each class.
>
> CHANGELOG: Allow interacting with multiple X servers in the NETWM classes.
>
> [autotests] NETWM tests get a new X server per test
>
> Making use of new feature of allowing multiple X connections:
> start X server in init() instead of initTestCase().
>
>
> Diffs
> -----
>
> autotests/netrootinfotestwm.cpp e918873a5281f6ecbcc1769de3dadcf8f6222f6a
> autotests/netwininfotestclient.cpp a5b10376b943ea914a9521b5c07f9ef13a65d2f1
> autotests/netwininfotestwm.cpp a98e12fd690b0250337c7588e1525af1d0dda38c
> src/platforms/xcb/netwm.cpp d99a925ad2b99d5e60ab1dafcb01400b4a6a4c93
> src/platforms/xcb/netwm_p.h 917a86ed5b6c83f36e73bbc346360b943d457243
>
> Diff: https://git.reviewboard.kde.org/r/125259/diff/
>
>
> Testing
> -------
>
> see adjusted unit tests. Also tried it in kwin_wayland
>
>
> Thanks,
>
> Martin Gräßlin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150917/dd00eefa/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list