Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 43

Thread: Digia Officially Releases Qt 5.2

  1. #31
    Join Date
    Nov 2013
    Posts
    68

    Default

    Quote Originally Posted by zester View Post
    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.

    Quote Originally Posted by zester View Post
    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.


    Quote Originally Posted by zester View Post
    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,
    _

  2. #32
    Join Date
    Jun 2011
    Posts
    267

    Default

    Quote Originally Posted by anda_skoa View Post
    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


    Quote Originally Posted by anda_skoa View Post
    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.


    Quote Originally Posted by anda_skoa View Post
    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.

    Quote Originally Posted by anda_skoa View Post
    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/sear...sername=comtux

    Cheers
    Last edited by zester; 12-12-2013 at 05:13 PM.

  3. #33
    Join Date
    Mar 2010
    Location
    Poland
    Posts
    11

    Default

    Quote Originally Posted by zester View Post
    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.

  4. #34
    Join Date
    Jun 2011
    Posts
    267

    Default

    Quote Originally Posted by beevvy View Post
    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?

  5. #35
    Join Date
    Jun 2011
    Posts
    267

    Default

    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.
    Last edited by zester; 12-12-2013 at 06:23 PM.

  6. #36
    Join Date
    Nov 2013
    Posts
    68

    Default

    Quote Originally Posted by zester View Post
    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.


    Quote Originally Posted by zester View Post
    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?

    Quote Originally Posted by zester View Post
    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?


    Quote Originally Posted by zester View Post
    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.

    Quote Originally Posted by zester View Post
    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,
    _

  7. #37
    Join Date
    Jun 2011
    Posts
    267

    Default

    Quote Originally Posted by anda_skoa View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •