Digia Officially Releases Qt 5.2

[anda_skoa]

I hate gtk with a passion purely because FreeDesktop.org projects like to stuff glib anywhere and everywhere they can in core system tools/library's, and my Qt code ends up being Qt with Gtk parts running in the back end.

Do you have an example for that?
Usually software hosted on Freedesktop.org does not leak dependencies of that kind. E.g. service based infrastructure either uses a protocol on a socket or D-Bus interfaces, neither dragging library dependencies from service implementations into clients.
Libraries are usually very low level, using only standard C or C++ features.

Qt5 granted is a far better direction to go then Qt4 but they ripped my pure XLib backend out and replaced it with the undocumented donkey dung that is XCB which by the way doesn't support Hardware Accelerated GLX with Nvidia and Ati binary drivers and never will.

Are you sure? Usage of OpenGL in Qt, especially for the QtQuick2 scene graph, seems to be hardware accelerated on all platforms.

Then you have Dbus a piece of code that is 20,000+ lines of code, and everyone decides its a great piece of software that know one even use's or understands other than those who created it, when much simpler options are available http://unixbus.org/ubus/ or ZeroMQ with http://troydhanson.github.io/tpl/userguide.html

Those two technologies are similar but not quite replacements.
D-Bus, as a second generation of the ideas, principles and requirements proven by DCOP, might be used by application developers in ways it was not intended to be used, but it is more often used in ways it was specifically designed for.

Ubus seems to come close than ZeroMQ, so one would have to evaluate it on a case-by-case basis to determine where it currently falls short.

Cheers,
_

[zester]

Do you have an example for that?
Usually software hosted on Freedesktop.org does not leak dependencies of that kind. E.g. service based infrastructure either uses a protocol on a socket or D-Bus interfaces, neither dragging library dependencies from service implementations into clients.
Libraries are usually very low level, using only standard C or C++ features.

Pixman (Gtk is optional) but all distro compile support for it and it ends up in Qt and Webkit pulls in Glib(Required), GStreamer(Optional) for QtWebKit
XCB brings in Python(Required) UDisks brings in glib(Required). Polkit brings in glib(Required) UPower brings in glib(Required) MesaLib ends up pulling in glib and python
eventualy from its XCB dependence's I have a chart somewhere's

Are you sure? Usage of OpenGL in Qt, especially for the QtQuick2 scene graph, seems to be hardware accelerated on all platforms.

Lol no I am positive and I know for a fact that XCB doesn't handle GLX and hardware acceleration and instead offloads that back to Xlib. And I know this A. I have been a Gtk and Qt developer for 16 years now and have experience with every area of Linux including X, who do you think raised hell about Xlib support being removed in the first place and made not only phoronix news but global linux news.

Those two technologies are similar but not quite replacements.
D-Bus, as a second generation of the ideas, principles and requirements proven by DCOP, might be used by application developers in ways it was not intended to be used, but it is more often used in ways it was specifically designed for.

D-Bus is over complicated and bloated, for 99% of all use cases. I've contributed enough code to both to know what I am talking about.

Ubus seems to come close than ZeroMQ, so one would have to evaluate it on a case-by-case basis to determine where it currently falls short.

Ubus is designed for IPC and ZeroMQ with tpl or any Binary Serializer meets a more generic use case.



Oh by the way .... I highly doubt there is any part of Kde/Qt Gtk/Gnome
that I haven't contributed code to.

http://qt-project.org/member/2183

http://kde-look.org/usermanager/search.php?username=comtux

Cheers

[beevvy]

Qt5 granted is a far better direction to go then Qt4 but they ripped my pure XLib backend out and replaced it with the undocumented donkey dung that is XCB which by the way doesn't support Hardware Accelerated GLX with Nvidia and Ati binary drivers and never will.

Yeah and what's your problem with that? Why don't you just use Xlib for GLX and xcb for everything else? I get the impression that you are "raising the hell" just because you had (or still have) to rewrite your Xlib Qt4 code. The thing is, everyone had to.

[zester]

Yeah and what's your problem with that? Why don't you just use Xlib for GLX and xcb for everything else? I get the impression that you are "raising the hell" just because you had (or still have) to rewrite your Xlib Qt4 code. The thing is, everyone had to.

Hay buddy I can be pissed off about it for as long as I want to, and its my duty to bitch about this shit someone has to.
It keeps everyone on there toes. Just imagine if Linus never bitched or raised hell about what code went into the kernel or what it looked like,
we would have a Kernel that ran like WinMe instead.

Anyways .... what was I bitching about again?

[zester]

You people need to complain more often about whatever even if its nonsense and you really don't care. Its good for the community.
I learned that from all the new Windows users we gained. Currently I am entertained by all the complaining about there not being enough
AAA game titles for linux.

I can use there complaint to go bitch at the Ogre3D dev's for developing a API that is a nightmare to integrate scripting into due to
heavy templet usage.

[anda_skoa]

Pixman (Gtk is optional) but all distro compile support for it and it ends up in Qt and Webkit pulls in Glib(Required), GStreamer(Optional) for QtWebKit
XCB brings in Python(Required) UDisks brings in glib(Required). Polkit brings in glib(Required) UPower brings in glib(Required) MesaLib ends up pulling in glib and python
eventualy from its XCB dependence's I have a chart somewhere's

Ah, interesting. But Python for XCB is only a build time dependency, isn't it?
My understanding of UDisks, Polkit and UPower was that they are services with D-Bus interfaces. In which case their implementation requirements would be of no consequence for any of their clients.

Lol no I am positive and I know for a fact that XCB doesn't handle GLX and hardware acceleration and instead offloads that back to Xlib.

I am not sure I understand that. So the XCB QPA has hardware acceleration? Or does one need a different QPA for that?

And I know this A. I have been a Gtk and Qt developer for 16 years now and have experience with every area of Linux including X, who do you think raised hell about Xlib support being removed in the first place and made not only phoronix news but global linux news.

The main X11 QPA plugin seems to be called "XCB", which would allow a plugin "XLIB" to coexist and be runtime selectable (if I understand the QPA mechanism correctly).
So I guess there would be someone maintaining it if there were enough people needing it, no?

D-Bus is over complicated and bloated, for 99% of all use cases. I've contributed enough code to both to know what I am talking about.

Well, don't really know the internals, have only worked with bindings and a bit with libdbus myself. Didn't have any look at the daemon code.
Maybe newer developments have made things obsolete that were needed back when it was designed.

Ubus is designed for IPC and ZeroMQ with tpl or any Binary Serializer meets a more generic use case.

I only had a cursory glance at Ubus and I quite liked the concept of doing the addressing through file system paths. Since we have $XDG_RUNTIME_DIR we know a place that can contain unix sockets for sure, so that would allow a good base path. Also solves the "stale socket file" problem, at least with a reboot.

Service activation can probably be handled through systemd's socket activation, something that D-Bus had to implement itself due to systemd not existing back then.

Not sure how one would go find all processes with a certain signa. Probably traversing the file tree?

One important feature of D-Bus, which I am also unsure about regarding how Ubus would do that, is priviledge separation on the system bus.
With D-Bus the system bus daemon only needs write priviledges to the socket dir at startup and can then drop them. None of the services need elevated priviledges to be addressable for clients.

Probably by running system services with a special user group that has write access to the global Ubus socket dir?

Anyway, good thing people consider the requirements in the light of system improvements, e.g. like Ubus being able to delegate service activation to systemd.

Cheers,
_

[zester]

I am not sure I understand that. So the XCB QPA has hardware acceleration? Or does one need a different QPA for that?

The main X11 QPA plugin seems to be called "XCB", which would allow a plugin "XLIB" to coexist and be runtime selectable (if I understand the QPA mechanism correctly).
So I guess there would be someone maintaining it if there were enough people needing it, no?

Hardware Acceleration for Nvidia and Ati binary drivers are offloaded to Xlib, meaning regardless if your using XCB or not for those binary drivers Xlib will be involved in the backend for hardware acceleration.

This is why things like Wayland haven't fully replaced, Xlib or XCB. Nvidia and Ati can't opensource there code even if they wanted to, particularly Nvidia as Microsoft owns 10% of Nvidia stock. Ati and Nvidia cant incorporate there code into the kernel as its a GPL violation. Did you know Nvidia Optimus has been able to be supported for almost 2 years now but was blocked by the Kernel Development team and Nvidia had to write a new interface via Randr in order to get Optimus supported on linux?

Anyways XCB is a SHIM for Xlib and Xorg Server and existed 10 years prior to its acceptance.