Will libX11-xcb.so still be included in XLibre?

[fredvs]

Describe the feature

Hello.
We're using libX11-xcb.so to transition our set of GUI widgets and toolkits from libX11.so to xcb.

Will this library still be included in XLibre?

Better yet, only one method is used: XGetXCBConnection(). Could I imagine this method being added to libxcb.so?

It should be implemented because

It would be wonderful.

What are the alternatives?

Crying.

Additional context

No response

Extra fields

• I have checked the existing issues
• I have read the Contributing Guidelines
• I'd like to work on this issue

[reaperx7]

The remainder of the X11 libraries, protocols, xcb, and other older and current subprojects is available from my personal archive here, but currently they lack active maintenance.

If anyone wants to refork the X11 extras, please feel free to do so.

[metux]

Right now, Xlib is still maintained by xorg, and they'll probably continue to do so. If this ever changes, we'll fork it, too.
Note that I really have no desire to add anything new to xlib - it's just for legacy applications that haven't been migrated to xcb.

[fredvs]

@metux I understand and respect your decision, but remember that a server without clients is sad.
And libX11.so is used by many programs and developers.

[metux]

@metux I understand and respect your decision, but remember that a server without clients is sad. And libX11.so is used by many programs and developers.

It seems we've got a communication problem.
Xlib is still there and still will be compatible - the protocol isn't changed, so any X11 clients will still work (that's actually the whole point of the project).

Right now, we don't have any need for actual development on Xlib - it's stable and the API is finished, and it's still maintained by xorg people.

Should that ever change, we'll consider forking that, too.

[fredvs]

Okay, okay, okay.

But you said in a previous post that XLibre could also fork libxcb.so.
I've migrated the MSEgui toolkit to xcb (with a looot of problems and white nights, mainly because on 64-bit Linux, libX11 uses 64-bit Atom while libxcb uses 32-bit Atom).
But for now, the working migration is partial, because it mixes libX11.so (mainly for events and drawing) and libxcb.so (for everything else). For this, libX11-xcb.so and its single method, XGetXCBConnection(), are required.

And libX11-xcb.so isn't always installed by default in many distributions.

So, if by chance you were to fork and maintain xcb, the suggestion would be to add a method, xcb_get_xcbconnection, that does exactly what XGetXCBConnection() does, but without adding any dependencies.

Amen.

[fredvs]

By the way, if anyone knows how to do exactly what XGetXCBConnection() does, using only the methods declared in libxcb.so, and can create a macro mimicking XGetXCBConnection(), that would be perfect too.

[reaperx7]

@metux we may have to eventually bring those in. While we may not have to work on them, per say, having them maintained would be beneficial.

[callmetango]

@reaperx7

@metux we may have to eventually bring those in. While we may not have to work on them, per say, having them maintained would be beneficial.

What should this “maintained” look like for you?

[fredvs]

Note that I really have no desire to add anything new to xlib - it's just for legacy applications that haven't been migrated to xcb.

As you know better than I do, for several years now, some libX11.so exported methods have been using those of libxcb.so.

The ideal (one can only dream) would be for libX11.so to make a complete transition and use only libxcb.so and its partners.

And thus, to offer developers using libX11.so an automatic transition to xcb.

[reaperx7]

@reaperx7

@metux we may have to eventually bring those in. While we may not have to work on them, per say, having them maintained would be beneficial.

What should this “maintained” look like for you?

Having them hosted at least would be a start. That way should anything be done to excise the rest of X out of FreeDesktops, they're available and safely stored and still available.

Plus upon the random chance some works needs to be done, per day adding yet another extension for, example, HDR10/10+ support, we have the sources at our disposal.

[callmetango]

This issue will be moved to X11Libre Q A · Discussions · GitHub since it is more of a discussion.

[fredvs]

Hello.
If I install XLibre on a blank operating system, without having previously installed Xorg, what happens to libX11.so and libxcb.so?
I don't see them in the XLibre repositories.
Will they be installed automatically or do I have to do it manually?
Will they be installed from:
https://gitlab.freedesktop.org/xorg/lib/libx11
https://gitlab.freedesktop.org/xorg/lib/libxcb
?

[callmetango]

Well, it depends on the way you install XLibre. If you use packages from a first- or third-party repository then all dependencies should get installed automatically. If you want to build XLibre from the source then you have to install or build all of its dependencies yourself.

[fredvs]

OK, so maybe it would be nice to have a "how to" to install without packages all the libraries needed to run XLibre for applications that only use it (I'm talking about applications that only use X11 via libX11.so or libxcb.so, not ones that use it as a dependency like gtk or qt.)

[fredvs]

And I'm still being annoyingly stubborn, but I'm voting for
https://gitlab.freedesktop.org/xorg/lib/libx11
https://gitlab.freedesktop.org/xorg/lib/libxcb
and their friends to be part of the XLIbre party.