Announcement

Collapse
No announcement yet.

Lubuntu 18.10 Officially Switching From LXDE To LXQt

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

  • makam
    replied
    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.

    Leave a comment:


  • starshipeleven
    replied
    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.

    Leave a comment:


  • starshipeleven
    replied
    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.

    Leave a comment:


  • timofonic
    replied
    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.

    Leave a comment:


  • the_scx
    replied
    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).

    Leave a comment:


  • CTown
    replied
    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

    Leave a comment:


  • STiAT
    replied
    I don't really care what my desktop and apps run as toolkit as long as they work and do their job. It's just sad that the desktop integration part still isn't as good as I'd wish it to be. Thanks to GTK by the way. We'll get there some day. Hopefully.

    Leave a comment:


  • Vistaus
    replied
    Originally posted by CTown View Post
    Since SVG and CSS are both scriptable, could not a program be made to convert a Kvantum theme to GTK theme or vice-versa? However, with amazing themes like Breeze, Nota, and Ark having versions for both toolkits, I don't think it's worth the effort. Still, that wouldn't solve the difference between the Gnome and KDE design styles (human interface guidelines). To add to that, even if both projects adopted the same style, there wouldn't be a guarantee that developers would follow that style.

    T.l.d.r.: So, it's probably never going to happen...
    Could you post a link to Nota? 'Cause I can't seem to find it on OpenDesktop.

    Leave a comment:


  • jpg44
    replied
    Originally posted by grok View Post

    I think that's a lot, does this include disk cache? Or simply the sum of having 64bit software, pulseaudio, network-manager, whatever is called Ubuntu's update manager, and maybe some background thing I'm missing.
    By the way I'm not doing an anti network-manager etc. diatribe, in fact Lubuntu is great if you need these things. Firefox forces our hand regarding pulseaudio, this is regrettable. But if the low-RAM system you need low footprint for has 2GB RAM, that's not a big problem, I do want pulseaudio and network manager anyhow, where a more raw system is clearly better is with 128-512MB RAM such as Raspberry Pi or some solid as rock desktop based on i440 BX.

    I'm partial to the GTK version of LXDE : for the looks, saving a couple tens MB RAM, and it's better bug fixed and maintained yet with minor new features sometimes.
    LXQt has the potential to support dpi other than 100% which is all that might matter with things like 1080p 13" laptops and the like! I think it's no better for now. But it may pay off by the time we're nearing Lubuntu 20.04, and there's a nice encouragement and exposure to end users in this decision.

    Pcmanfm is a great very fine piece of software, I wish to say that yet another time. Fast Nautilus clone with no dependencies (that also has an "application folder", which you won't need unless you don't have an application launcher or start menu). So you can use it with fluxbox or any raw window manager of your choice.

    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
    Last edited by jpg44; 19 May 2018, 10:06 AM.

    Leave a comment:


  • jpg44
    replied
    Originally posted by eydee View Post
    Well, the point of LXDE and Lubuntu is being lightweight. Qt is anything but lightweight.
    Actually, the reason he switched to Qt is that its memory usage was less than Gtk's and that Gtk3s memory usage was simply horrible. So instead of port to Gtk3, he found he would save memory by porting to Qt. So the Qt switch was in fact, to save RAM.

    Leave a comment:

Working...
X