Qt5 QX11Info::display()?
-
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]
-
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