Qt5 QX11Info::display()?
-
I don't want it to transform into a flamewar, so let's just agree to end it here, ok? I mostly agree with you anyway, even if I focused on counterarguments in my first reply.
They have destroyed a great opportunity for Qt, that is absolutely right. I just wanted to point out that they were not all bad. Nokia did increase manpower behind Qt extensively, so a lot of things would not have "happened regardless". I understand your frustration, I guess we all had a tough past year+ of uncertainty. That is a past now, however. Open Governance is in place, Qt has a new home, and we are close to getting the Qt5 goodness (or badness, in case of your X11 APIs. I'm lucky enough that projects I work on are not affected negatively by Qt5's changes).
-
Anyways I was in the middle of writing a Desktop that was 100% qt and blazzing fast. I though hay why not start porting to Qt5 now being its my GL based will make integrating 3d graphics/game engines like Panda3D, Ogre3D, Irrlight, Horde3D, OpenSceneGraph and Gameplay easyer.
!https://lh3.googleusercontent.com/-NCvdirf8TYc/UFFZxVqH8tI/AAAAAAAAAZo/3jhJxtT3Bxc/s746/Screenshot+-+09122012+-+11:52:34+PM.png(Quantum Desktop)!
But Qt5 broke my Window Manager with the XCB changes and removing the QX11 classes. So now I am stuck unless I am missing something and I can build without XCB.
-
Cool stuff :) Again, try the mailing list, but I'm afraid writing a X11 QPA plugin is the way to go here. Might be that someone is doing that already, I don't know.
-
I think you might want to read up on XCB. Most current Linux distributions have libX11 implemented using XCB. Why should Qt5 use the compatibility wrapper?
In 1997 libX11 was the hot thing, but in the meantime all the cool kids have moved on;-)
-
[quote author="Tobias Hunger" date="1347650490"]I think you might want to read up on XCB. Most current Linux distributions have libX11 implemented using XCB. Why should Qt5 use the compatibility wrapper?
In 1997 libX11 was the hot thing, but in the meantime all the cool kids have moved on;-)[/quote]
Sigh :(
bq. XCB-GLX only communicates with the X server, it does not perform any hardware initialization or touch the OpenGL client-side state. Because of this XCB-GLX cannot be used as a replacement for the GLX API. To use OpenGL in the X Windowing system, one must use the GLX API, and the GLX API is closely coupled with Xlib. As a result, an OpenGL application on the X Windows must use Xlib and thus can’t be done using only XCB. http://xcb.freedesktop.org/opengl/
Actualy XCB is nothing more than an alternative to XLIB, and XLIB is not implamented with XCB.
If you want hardware accelerated graphics using your Ati/Nvidia cards you have to use XLIB this is a fact that is not going to change unless that is Ati/Nvidia implament what needs to be done to have full hardware acceleration in XCB or wayland in the binary drivers. It's been 11+ years and thay have shown no interest in XCB whatsoever, So I consider XCB a crippled low level wrapper for a higher level interface. -
Oh come on! When was documentation found on freedesktop.org ever up to date? ;-)
Yes, the GLX Api is closely coupled with the Xlib API, but that is no longer an issue.
.bq Actualy XCB is nothing more than an alternative to XLIB, and XLIB is not implamented with XCB.
You are mistaken.
Check the dependencies in "arch":http://www.archlinux.org/packages/extra/x86_64/libx11/ or -- if you want something older -- "debian/squeeze":http://packages.debian.org/squeeze/libx11-6 . If you don't trust the packaging information: Just check the strings in libx11, it is full of XCB stuff.
Even "wikipedia":https://en.wikipedia.org/wiki/Xcb says so.
bq. If you want hardware accelerated graphics using your Ati/Nvidia cards you have to use XLIB
If you want to use GLX, then you need xlib, since the GLX standard defines this dependency. There is nothing any graphic card vendor can do about that short of changing the standard. None of the free drivers can change that requirement either by the way.
bq. this is a fact that is not going to change unless that is Ati/Nvidia implament what needs to be done to have full hardware acceleration in XCB or wayland in the binary drivers.
XCB is a modern version of a library used to control an X server and completely unrelated to 3D graphics -- just as Xlib. ATI/Nvidia provide drivers that is used inside that server (and the kernel beneath it). There is nothing to support for them related to XCB.
Wayland uses GL, which is fully accelerated in both ATI and NVidia binary drivers. Wayland works well on both.
What is missing with both the Nvida and ATI binary drivers is a way to set up GL acceleration without GLX, which is indeed something you want for wayland.
-
The change I've started to add QX11Info back to Qt 5 is mentioned on the first page of the google results for "QX11Info qt5". It can be found here:
https://codereview.qt-project.org/#change,26714If you want to help finish it, then great.
-
bq.
You are mistaken.
Check the dependencies in arch [archlinux.org] or — if you want something older —
debian/squeeze [packages.debian.org] . If you don’t trust the packaging information: Just check
the strings in libx11, it is full of XCB stuff.
Even wikipedia [en.wikipedia.org] says so.See http://cblfs.cross-lfs.org/index.php/Xorg7/Libraries
Under libX11 you will notice its RECOMMENDED not REQUIRED.
The reason those distros have it is because they compiled support in for it.
The Xlib vs XCB is a religious debate that has been going on forever.
Personaly I dont want or need it. Ill stick with Qt4 and fork if I have to.
-
bq. Under libX11 you will notice its RECOMMENDED not REQUIRED.
... which is why I said "Most current Linux distributions have libX11 implemented using XCB." I am pretty sure there are strange distros out there not using it for whatever reasons.
So far I was not even aware that there was a debate around XCB. XCB fixes lots of bugs and does away with multi-threading issues that are impossible to fix within libX11. I have not run into anyone yet being sad at libX11 is going the way of the dodo.
-
Under libX11 you will notice its RECOMMENDED not REQUIRED.
That was the case for some versions, but every version of libX11 since 1.4.0 has required XCB. libX11-1.4.0 was released in November 2010. The commit that removed support for XCB was made in June 2010. See http://cgit.freedesktop.org/xorg/lib/libX11/commit/?id=15e5eaf62897b3179d1fbe457cb19f886f0449f8
Personaly I dont want or need it. Ill stick with Qt4 and fork if I have to.
And given your ranting behavior, I don't think anyone would mind.
-
[quote author="Tobias Hunger" date="1347779912"]bq. Under libX11 you will notice its RECOMMENDED not REQUIRED.
... which is why I said "Most current Linux distributions have libX11 implemented using XCB." I am pretty sure there are strange distros out there not using it for whatever reasons.
So far I was not even aware that there was a debate around XCB. XCB fixes lots of bugs and does away with multi-threading issues that are impossible to fix within libX11. I have not run into anyone yet being sad at libX11 is going the way of the dodo.[/quote]
XCB didnt fix the problem it only put a bandaid on it, hence why wayland was created. Listen I am not new. I have been around a looooooong time. What are my issues with XCB easy just look at the docs/tutorials look at the site it self look when it was last updated. I can fix xlib issues because I have a stack of books that date back to the 1990's and everything is still relavent in them. I dont have that for XCB.
My rant is legitimate. And yes its a rant I agree. Because I am irritated.
It took me long time just to get my project where it is and being excited about Qt5, my toys were broken and removing the QX11Info class and replaceing Xlib as primary with XCB is a big deal. That should have been on the front page of this site long before it was done. You dont get to make changes like that and not let people know and if you do I suggest it goes un-noticed. You have any idea how much code in the Qt KDE community you just broke.
I am not the only one mad about this I was just the only one that really doesnt give a sh%$ about raising hell about it.
I am mad about alot of things in regards to the Qt/Nokia issue. That was just what heppend to set me off.
The Nokia branding on qt-project.org needs to disapear and soon.
-
Xlib and GLX is deprecated, with XCB (and Wayland) and EGL beeing the replacement. It already was for a long time.
For the same reason Qt on Xlib is deprecated, with XCB (and Wayland) and EGL beeing the replacement. It already was for a long time.
Feel free to add a Xlib QPA support, implement QX11Info, fork Qt or whatever it neccessary to keep your application running, but expect to just hear 'Yes, this was expected for a long time.' when Xlib and GLX support is dropped on distribution level (it already more or less happened on vendor level) and your application stopped working again.
Alternatively just swallow the pill and do what everyone does (including KDE and Gnome), stop using a thirty year old library and port your code to XCB (and Wayland) and EGL, which is already there for a long time now.
-
"I have been around a long time" is not a convincing argument. Neither is what you did in the 1990s.
X11 has severe limitations, which XCB addresses.
That Qt5 will use XCB only is on the news for a long time: That X11 support would be done via XCB was in the "very first announcement of Qt5":http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ .
You seem to be missing some information that used to be in QX11Info, that much I get. Please "file a bug":http://bugreports.qt-project.org/ about that: I am sure that is just an oversight.
With regard to "Qt5 can't do GL on nvidia/ATI binary drivers": That statement is plain wrong. Give it a try on any major linux distribution you grab from the net and try for yourself. Yes, it does break stuff for distros from the 1990s. But XCB is the least of your problems when trying to run any modern framework in such an old environment.
Phoronix covers this thread: http://www.phoronix.com/scan.php?page=news_item&px=MTE4NTk
-
GLX is depreceated? What!!! man get out of here I am not talking
about using mesa here. You go tell the Ogre, Panda3D, Maratis3D, Gameplay, cocos2dx, Moai SDK, LOVE game engine, OSG, Irrlicht, Radium3D, Horde3D, GLFW, SFML teams. That GLX is depreceated and see what they say. Because everyone of them use Xlib,GLX and OpenGL for linux support.You might want to read this.
http://news.ycombinator.com/item?id=4526348bq.
exDM69 1 day ago | link
This article is (at least a little) wrong. By the way I wrote the
XCB-OpenGL doc that is cited in this article.
You can use XCB with OpenGL, but you won't be getting rid of
Xlib altogether because of GLX depends on Xlib. It does not mean
that you cannot use XCB or get any advantage out of it.
So you use Xlib+GLX for OpenGL initialization and XCB for events
and windowing stuff. Works like a charm.And now I will quote my self
bq.
I cant use any of those Wayland and DirectFB dont support Nvidia
Drivers “hardware acceleration”, XCB doesnt support GLX eather
not with Nvidia drivers. All XCB does is off load everything to
standard X/GLX and XCB is never going to have support for GLX
on Nvidia cards. Its been 11 years.You guys are totaly not getting what I am saying and what the problem is by removing xlib support and the QX11Info calss not to mention chances are the other QX11 classes.
And I stopped filing bug reports when they would be confirmed, assigned but never fixed then be assigned to some one else just to have that person ask me to expalin the problem, and I would just to be ask why I was using that class ummm because its a widget with a critical bug and should be fixed and then it gets passed on again, three years later still not fixed. So yahhh filing a bug really fixes thing here.
And Tobias Hunger as far as being around you have been on this site for what 3 months longer than me but I have been a a kde-look editor sence 2004 http://kde-look.org/usermanager/search.php?username=comtux and before that my nose was grinding kde code. I have been around for aslong as kde has existed and thats most of Qt's life.
Why do you think kdelibs exist because of this very same reason. We express a problem you ignore it. I dont do mailing lists I want every Qt user on here to see how there going to be treated when you remove a vital class that breaks there software.
-
I think there's a major misunderstanding going on here...
The facts are:
- Qt 5.0 will have a XCB backend, not a Xlib one (and AFAIK noone so far missed the Xlib backend).
- Qt 5.0 will not have a replacement for the QX11* , QWin* , QMac* , etc. platform-specific classes. It's likely that they will be added back in 5.x, provided that someone writes the code. Richard already has a prototype for QX11Info.
- Qt 5.0, with the XCB backend, works perfectly with OpenGL applications. QtQuick2 running on Linux/X11 is the primary example. I don't care if using GLX actually requires mixing calls to Xlib and XCB due to GLX design -- it's already implemented, and it works (I can use OpenGL apps with Qt 5 and a X11 server, using the NVIDIA binary driver). If it doesn't work with a particular combination of hardware/software, there's a bug somewhere to investigate. But this doesn't mean that XCB is "bad" and Xlib is "good" (for any definitions of bad and good).
Does this clarify things a bit?
-
bq.
Qt 5.0 will not have a replacement for the QX11* , QWin* , QMac*
, etc. platform-specific classes. It’s likely that they will be added
back in 5.x, provided that someone writes the code. Richard
already has a prototype for QX11Info.:) Well there is at least 6 Qt developers that do care based on the rating of this thread.
I allready politely asked the XCB devs for improved documentation
and the answer was they can't be bothered with it. So there for I am of no use to Richard. Because I invested all my time in the X api's because thats what Qt4 was using while I was waiting for XCB's docs to improve they didnt and apparently there not ever going to according to the XCB devs.This is the last time I am going to bring this topic up but before I close I would like to quote one other dev that commented on the matter.
bq. quanticle 1 day ago | link http://news.ycombinator.com/item?id=4526348
And this is why, my friends, we don't have a Linux desktop. At
some point, we need get some stability and backwards
compatibility in our GUI toolkits. Otherwise, we see this problem
over and over again - GUI API updates break application
developers, and those developers have to put time and effort into
restoring functionality rather than adding new features or
improving usability.
Windows will happily run 10 year old GUI code. OSX will still run
7 year old GUI code. But Linux? Depending on the which window
manager you're using, even 2-3 year old code can be horribly
broken by API updates. As a developer, this is one of the chief
reasons I'm considering abandoning Linux and moving to OSX.
It's just too bothersome to deal with the ever-increasing flux in
Linux GUI libraries. -
zester: A workaround to get a Xlib Display:
@
#include <qpa/qplatformnativeinterface.h>// ...
QWindow window = new QWindow(/ screen */);
Display *display = static_cast<Display *>(qGuiApp->platformNativeInterface()->nativeResourceForWindow("display", window->windowHandle()));
// ...
@Edit: Forgot to mention that you need to add gui-private to QT (like: QT += core gui gui-private)
or:
@
#include "PATH_TO_QT5DIR/qtbase/src/plugins/platforms/xcb/qxcbscreen.h"// ...
QList<QScreen *> screens = QGuiApplication::screens();
QXcbScreen *xcbscreen = static_cast<QXcbScreen *>(screens.at(0)->handle());
Display *display = static_cast<Display *>(xcbscreen->connection()->xlib_display());// ...
@ -
Thank you kindly :)
[quote author="flim" date="1347884378"]zester: A workaround to get a Xlib Display:
@
#include <qpa/qplatformnativeinterface.h>// ...
QWindow window = new QWindow(/ screen */);
Display *display = static_cast<Display *>(qGuiApp->platformNativeInterface()->nativeResourceForWindow("display", window->windowHandle()));
// ...
@Edit: Forgot to mention that you need to add gui-private to QT (like: QT += core gui gui-private)
or:
@
#include "PATH_TO_QT5DIR/qtbase/src/plugins/platforms/xcb/qxcbscreen.h"// ...
QList<QScreen *> screens = QGuiApplication::screens();
QXcbScreen *xcbscreen = static_cast<QXcbScreen *>(screens.at(0)->handle());
Display *display = static_cast<Display *>(xcbscreen->connection()->xlib_display());// ...
@[/quote] -
[quote author="zester" date="1347882957"]
And this is why, my friends, we don't have a Linux desktop. At
some point, we need get some stability and backwards
compatibility in our GUI toolkits. Otherwise, we see this problem
over and over again - GUI API updates break application
developers, and those developers have to put time and effort into
restoring functionality rather than adding new features or
improving usability.
Windows will happily run 10 year old GUI code. OSX will still run
7 year old GUI code. But Linux? Depending on the which window
manager you're using, even 2-3 year old code can be horribly
broken by API updates. As a developer, this is one of the chief
reasons I'm considering abandoning Linux and moving to OSX.
It's just too bothersome to deal with the ever-increasing flux in
Linux GUI libraries.[/quote]
I can't see how this could be true. Qt 5 tries to minimize source incompatibilites w.r.t. Qt 4. Qt 4 has been around for 7 years now and won't go away in the next few years. This means that your Qt 4 + XLib application will have ~10 years of supported, working lifespan.
-
Couldnt just let me go in piece could you peppe? He wasnt talking about Qt in particular but linux as a whole and it happens constantly. Example??? Try to compile the newest gimp from src some time and see if it needs a version of gtk or its libs that you dont have. But if you need a Qt example well what do you think this whole topic was about? And it might just be cultural differances but here in the usa if you break something its your responsability to eather fix or replace it. If I had a commercial licenses and digia was a us company you could have been witness to that in effect. It doesnt matter that Qt4 will be around I had an expectation of porting to Qt5 without huge amounts of diffaculte and Qt/Nokia promised an easy transition from Qt4 to Qt5 with minimal breakage but thats not what heppend because non-of my Qt4 apps compile in Qt5 out of the box, Its going to cost me huge amounts of time to get this stuff ported to Qt5. Because there are lots of missing pieces now.
[quote author="peppe" date="1347892099"]
[quote author="zester" date="1347882957"]
And this is why, my friends, we don't have a Linux desktop. At
some point, we need get some stability and backwards
compatibility in our GUI toolkits. Otherwise, we see this problem
over and over again - GUI API updates break application
developers, and those developers have to put time and effort into
restoring functionality rather than adding new features or
improving usability.
Windows will happily run 10 year old GUI code. OSX will still run
7 year old GUI code. But Linux? Depending on the which window
manager you're using, even 2-3 year old code can be horribly
broken by API updates. As a developer, this is one of the chief
reasons I'm considering abandoning Linux and moving to OSX.
It's just too bothersome to deal with the ever-increasing flux in
Linux GUI libraries.[/quote]
I can't see how this could be true. Qt 5 tries to minimize source incompatibilites w.r.t. Qt 4. Qt 4 has been around for 7 years now and won't go away in the next few years. This means that your Qt 4 + XLib application will have ~10 years of supported, working lifespan.[/quote]
