Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LXQt 0.11 Released

lxqt.org

Post reply on HN
Print view View original

81–90 of 97 posts

Re: LXQt 0.11 Released

#81

Post by crudbug »

scrollaway wrote: post #2

So while this is on HN, I wanted to talk a bit about LXQt and desktop OSes in general. Context: I'm one of the original leads on LXQt, and I initiated the merge of Razor-qt and LXDE-Qt into LXQt. I've been using LXQt as my main desktop for several years now. I've kept up with what other desktops have been doing. I've been especially impressed by the efforts of the GNOME team, and especially disappointed with the clus…

I totally agree.

This might have been the main reason for Canonical to develop - Unity & Mir, for stable development cycles.

I think Linux Desktop environments need to decouple the user applications from core desktop functionalities - window manager, themes, settings; everybody is doing their own thing.

Currently, every DE comes with its own solution for these functionalities.

1. Toolkits - GTK+, QT, EFL

2. Desktop - Gnome, KDE, XFCE, Enlightenment

3. Desktop/Systems Settings Control - Network / Disk / Display etc.

4. Applications - File Manager, Web Browser, Email Manager etc.

Gnome 2 forks brought more chaos into this argument.

Re: LXQt 0.11 Released

#82

Post by [deleted] »

scrollaway wrote: post #2

So while this is on HN, I wanted to talk a bit about LXQt and desktop OSes in general. Context: I'm one of the original leads on LXQt, and I initiated the merge of Razor-qt and LXDE-Qt into LXQt. I've been using LXQt as my main desktop for several years now. I've kept up with what other desktops have been doing. I've been especially impressed by the efforts of the GNOME team, and especially disappointed with the clus…

[deleted]

Re: LXQt 0.11 Released

#83

Post by aq3cn »

scrollaway wrote: post #2

So while this is on HN, I wanted to talk a bit about LXQt and desktop OSes in general. Context: I'm one of the original leads on LXQt, and I initiated the merge of Razor-qt and LXDE-Qt into LXQt. I've been using LXQt as my main desktop for several years now. I've kept up with what other desktops have been doing. I've been especially impressed by the efforts of the GNOME team, and especially disappointed with the clus…

It seems like you don't watch Unix porn (http://imgur.com/r/unixporn).

Re: LXQt 0.11 Released

#84

Post by daurnimator »

rasterman wrote: post #79
daurnimator wrote: post #9

Earlier quoted context omitted.

> Not to mention the sad state of UI toolkits right now. This isn't about GTK vs. Qt or anything... but you can't pick up your favourite language (Python, JS, whatever) and easily write cross-platform apps that work well on Linux. This frustrates me to no end. - Qt is almost impossible to fully bind. The vague hacks we had all got tossed out the windows with the move from Qt4 to Qt5. I've given up putting my own effo…

We may have come up with an alternative for bindings - at least for EFL, where we now generate the C API from an IDL that expresses classes, inheritance, events (signals/slots), etc. so our C API is pushed out by code gen tools and we just fill in the functions, and right now we support automatically generating C++, JS and LuaJIT bindings out of the box whenever you type "make" on the toolkit. We're going for "full b…

> LuaJIT bindings

Well... somewhat. FWIW I was present at q66's talk at the lua workshop last year (https://www.youtube.com/watch?v=J_hlbjj_9-Q). From what I recall it was more of a full application framework rather than a library usable from existing processes.

I did try to give them a go at some point, but could never get things working.

Aside from this, the reliance on luajit makes this a no-go for me. (though perhaps you can use luaffi (https://github.com/facebook/luaffifb) to alleviate this?)

Re: LXQt 0.11 Released

#85

Post by rasterman »

daurnimator wrote: post #84
rasterman wrote: post #79

Earlier quoted context omitted.

We may have come up with an alternative for bindings - at least for EFL, where we now generate the C API from an IDL that expresses classes, inheritance, events (signals/slots), etc. so our C API is pushed out by code gen tools and we just fill in the functions, and right now we support automatically generating C++, JS and LuaJIT bindings out of the box whenever you type "make" on the toolkit. We're going for "full b…

> LuaJIT bindings Well... somewhat. FWIW I was present at q66's talk at the lua workshop last year ( https://www.youtube.com/watch?v=J_hlbjj_9-Q ). From what I recall it was more of a full application framework rather than a library usable from existing processes. I did try to give them a go at some point, but could never get things working. Aside from this, the reliance on luajit makes this a no-go for me. (though p…

well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be.

But yeah - we bound to LuaJIT because of performance and FFI. Technically bindings could generate C code for PUC Lua too. We generate C++ for v8 for JS, so it's possible but not done. My point was that we're making bindings a first class citizen part of development of the core. maybe this will fill in the gaps others have tried to fill before?

Re: LXQt 0.11 Released

#86

Post by toyg »

lj3 wrote: post #63
toyg wrote: post #14

Earlier quoted context omitted.

> it can't get more users without better drivers Drivers on Linux have always been like this, that's not the issue. The real issue is that modern line-of-business application development (which is where the money is) has left the desktop for good. Windows has the same problem. It's not the Linux desktop that is dying, it's "the desktop" as a concept. Desktop vendors are sandboxing everything to death, for security re…

> Drivers on Linux have always been like this, that's not the issue. What are you basing that on? Drivers on Linux have always been like this and Desktop Linux has always been DOA. OS X is a Linux based operating system that fixed this issue and linux users went to it in droves. You don't see the correlation? > The real issue is that modern line-of-business application development (which is where the money is) has le…

> OS X is a Linux based operating system that fixed this issue

OSX (which btw is based on BSD, not Linux) has been around for ages, but it wasn't that popular among developers until Apple moved to Intel, released the iPhone, and changed the laptop game with the MBA. That was the combo breaker, not the desktop.

> it's an issue that that's how people see it these days;

I agree, there is still good money in the desktop game; it's just that the margins on web are so eye-watering large, the market can't resist the temptation.

> go the apple route and make the Linux Distro specifically for a new laptop.

That would be nice, and it was sort-of tried by various entities at some point (Canonical + Dell, RedHat + IBM...), to be fair only with the commodity plasticky shit. Someone is trying it today with what are basically last year's MBPs (https://www.crowdsupply.com/purism/librem-15). The problem is that both Linux and hardware move so fast and so chaotically, long-term support is always an issue; today's graphic drivers might not be good enough for next year's chips, and tomorrow someone at RedHat might decide the audio stack should be rewritten for systemd, and so on and so forth.

And to be honest, the margins in the laptop game are clearly very thin. There is a reason Apple treats OSX as second fiddle to iOS and can't be bothered to refresh their MBPs as they used to.

Re: LXQt 0.11 Released

#87

Post by digi_owl »

toyg wrote: post #86
lj3 wrote: post #63

Earlier quoted context omitted.

> Drivers on Linux have always been like this, that's not the issue. What are you basing that on? Drivers on Linux have always been like this and Desktop Linux has always been DOA. OS X is a Linux based operating system that fixed this issue and linux users went to it in droves. You don't see the correlation? > The real issue is that modern line-of-business application development (which is where the money is) has le…

> OS X is a Linux based operating system that fixed this issue OSX (which btw is based on BSD, not Linux) has been around for ages, but it wasn't that popular among developers until Apple moved to Intel, released the iPhone, and changed the laptop game with the MBA. That was the combo breaker, not the desktop. > it's an issue that that's how people see it these days; I agree, there is still good money in the desktop…

> and tomorrow someone at RedHat might decide the audio stack should be rewritten for systemd

I can see it already, make pulseadio depend on logind under the banner of making audio device access "more secure".

Re: LXQt 0.11 Released

#88

Post by digi_owl »

ac29 wrote: post #68
qznc wrote: post #38

Earlier quoted context omitted.

I live in terminal and browser almost exclusively, but I still want a full desktop environment. I switched to Mate on my old laptop, because Unity and Gnome3 need to much resources. I tried others (XFCE, LXDE, ...) but they lacked little features like: * hibernate when closing lid * cpu/mem/network visualization in top/bottom bar * clean theme without much fiddling * mute/unmute via hardware button And the rest I for…

>(XFCE, LXDE, ...) but they lacked little features like: * hibernate when closing lid * cpu/mem/network visualization in top/bottom bar * clean theme without much fiddling * mute/unmute via hardware button All of those are possible with XFCE. Technically I think the mute/unmute thing comes through ACPI or something -- it works in any DE I've used.

On my desktop i have a mute key on the keyboard, and it shows up in X11 as a special key. From there i have set the XFCE keyboard manager to run some ALSA commands on pressing it to toggle the mute state of the master volume control.

Works fine, but then i do not have any transitory (USB) audio devices.

I suspect the lid close can be bound similarly (but these days you have the whole crapola of powerkit/powerd depending on systemd-logind handling the gruntwork, so who really knows).

Re: LXQt 0.11 Released

#89

Post by digi_owl »

wott wrote: post #80
a3n wrote: post #7

Earlier quoted context omitted.

> Most people who care about their desktop have migrated or are migrating to OSX I'm not among the most people. I don't care about my desktop, and I've migrated away from all the focus on appearance to tiling window managers, currently awesome. I almost never see my desktop, I just want my windows. I'm not a "the mouse is evil, twm's are efficient," I just got fed up with all the focus on the desktop. I don't care, I…

My personal conclusion is always the same: I always come back to Windowmaker. Every single time I use another DE, no matter how shiny it is (and they are truly beautiful when you open them for the first time), I face half-baked applications, many bugs, and basically half of the stuff is fucked up with each update. So I stick to Windowmaker. I don't even really use its DE part, I use it as a WM mostly. It gives me ter…

Been poking at Icewm for a similar reason.

And now i wonder about the state of Afterstep...

Re: LXQt 0.11 Released

#90

Post by daurnimator »

rasterman wrote: post #85
daurnimator wrote: post #84

Earlier quoted context omitted.

> LuaJIT bindings Well... somewhat. FWIW I was present at q66's talk at the lua workshop last year ( https://www.youtube.com/watch?v=J_hlbjj_9-Q ). From what I recall it was more of a full application framework rather than a library usable from existing processes. I did try to give them a go at some point, but could never get things working. Aside from this, the reliance on luajit makes this a no-go for me. (though p…

well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be. But yeah - we bound to LuaJIT because of performance and FFI. Technically bindings could generate C code for PUC Lua too. We generate C++ for v8 for JS, so it's possible but not done. My point was that we're making bindings a first class citizen par…

> well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be.

Languages want a something that can act as a library; not something that completely dictates the structure of your program. e.g. you must be able to specify your own main loop.

Glib does allow this, however the gobject introspection for it is completely broken. I haven't looked into it for Qt for a while

Post reply on HN