Announcement

Collapse
No announcement yet.

Lubuntu 18.10 Officially Switching From LXDE To LXQt

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Vistaus View Post

    Could you post a link to Nota? 'Cause I can't seem to find it on OpenDesktop.
    I'm very sorry. I confused Nota with the Nokta variant of the Adapta theme...

    GTK: https://github.com/adapta-project/adapta-gtk-theme
    Qt/Plasma: https://github.com/PapirusDevelopmentTeam/adapta-kde

    Comment


    • #22
      Originally posted by debianxfce View Post
      Gtk applications are installable always. Kdenlive does not install to Debian sid because of many mismatched Qt libraries. Qasmixer does have the same problem. It takes few weeks before Qt applications work again. When Qt applications work, they are good, but qt dependency hell is not good.
      You can install Kdenlive as a flatpak package from the Flathub repository. There are also OpenShot (Qt5), Shotcut (Qt5), VidCutter (Qt5) and Pitivi (Gtk+3).

      Comment


      • #23
        Originally posted by jpg44 View Post


        What triggered the move to Qt was the impeding switch to Gtk3. He found that Gtk3 would eat up far more RAM than Gtk2 that LXDE was based on. So instead of porting to Gtk3, he instead decided to port to Qt and by doing so memory would be saved. The move to Qt was a long term thing for the eventual possibility of Gtk2 discontinuation and the fact Gtk3 is a memory hog.

        PS I suspect what may be behind high memory usage numbers is memory graphics buffer management and the storing of graphics in RAM. Its hard to imagine how code can consume hundreds of MB, its probably graphics buffers. If you look at the memory usage, i wouldnt be surprised if the code itself has an insignificant impact on RAM usage no matter what toolkit you use, what does is the kinds of graphics buffering its doing. I would say the best thing to do is allow themes which are entirely based on vector graphics and use runtime vector commands to the window system and avoid rastering the UI graphics in the app itself. This should result in the vector graphics going directly to the front buffer (avoiding duplicated storage of rasterized data or storage of rasterized data that is not visible on screen), at least thats how things used to work.

        many people expect fancy graphics and UI effects like brushed steel look etc but that all consumes more RAM compared to vector graphics like Motif used. If you want to save RAM, motif type vector graphics can save big
        Fancy graphics and UI effects could be entirely done by GPUs. Did you know GPU these days are quite programmable? There's shaders and all kind of stuff. Vulkan even removes bloat and has SPIR-V too.

        Comment


        • #24
          Originally posted by debianxfce View Post
          Gtk applications are installable always. Kdenlive does not install to Debian sid because of many mismatched Qt libraries. Qasmixer does have the same problem. It takes few weeks before Qt applications work again. When Qt applications work, they are good, but qt dependency hell is not good.
          In what way packaging issues in the "unstable" branch of Debian have any relevance here?

          OpenSUSE Tumbleweed uses whatever newest Qt libs there are and there are no dependency issues ever, for example.

          Comment


          • #25
            Originally posted by jpg44 View Post
            PS I suspect what may be behind high memory usage numbers is memory graphics buffer management and the storing of graphics in RAM. Its hard to imagine how code can consume hundreds of MB, its probably graphics buffers.
            I can imagine how code can waste ram like crazy. What bloats stuff these days are levels of abstraction and "simplification" to make the job of downstream programmers easier. In many cases there are multiple layers of this.

            To do some jobs you (downstream developer) call a function that calls another that calls another and another and another and all that crap is run together at the same time, or is even loaded and idle in RAM with its own buffers and stuff. Or stuff isn't properly dumped (and RAM freed) at the end of a forked process because they rely on some garbage collector to kick in every now and then and do this job for them.

            I'm not saying that you can't abstract and "simplify" stuff for downstream programmers without giving up (a lot of) performance, but that's what usually happens, especially for crap written in java, but C++ isn't immune to this either, especially if you abuse the object-oriented features.

            many people expect fancy graphics and UI effects like brushed steel look etc but that all consumes more RAM compared to vector graphics like Motif used. If you want to save RAM, motif type vector graphics can save big
            That's wrong. Both Qt and Enlightenment (which are designed for embedded device usage, among other things) can pull off some pretty amazing graphics on total shit hardware while Gtk would need orders of magnitude more resources to do the same.
            Last edited by starshipeleven; 19 May 2018, 06:05 PM.

            Comment


            • #26
              The move to QT is a long term one. It is still lighter than XFCE, and it will be trimmed down further as more people will use it thus making bug reports etc... And it looks nicer than default LXDE even though that is up to taste.

              Comment

              Working...
              X