Qt5 QX11Info::display()?
-
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]
-
All my concerns and expectaions are or have been addressed thank you for that, I no longer have an issues with the Qt dev team or Digia.
My last remaining issue is with the devs of xcb it self, and I will be starting a campain and gathering support to force them to document there api's and at the least begin on some tutorials. Being that they appear to be a major player now in the linux community they have an oblagation to fullfill. 11 years ago they were rejected by the x team but they were able to gather enought support from the community to make the push, they set the tone and there were expecations for the support that got them were they are today.
-
Just a note for anyone looking at this thread in future. The Qt X11 extras module now exists and can be found at https://qt.gitorious.org/qt/qtx11extras