Is gnome 2 still available for v.12?

[Mjölnir]

[...] Or the OP just chill out... use the crap that is available and then just hope the next generation of Gnome developers are a little more competent when it comes to usability

+1. And/or the GTk developers to accept reality & fix their ignoring current modern display's DPI (fixed to 96 currently IIUC). Even Chris Moore, IIRC not a friend of bloated toolkits, choose Qt as the base toolkit for the Lumina Desktop. LxDE switched to Qt, too. How come?

 

[kpedersen]

+1. And/or the GTk developers to accept reality & fix their ignoring current modern display's DPI (fixed to 96 currently IIUC). Even Chris Moore, IIRC not a friend of bloated toolkits, choose Qt as the base toolkit for the Lumina Desktop. LxDE switched to Qt, too. How come?

It is annoyingly similar to the Gnome 2 vs KDE 3.5 thing. Gtk+ 2 in the past was considerably more lean than Qt4. And then when Gtk regressed into Gtk3, suddenly Qt4+ was competitive again. So rather than overtake Gtk+, Qt kinda undertook it instead XD

The truth is that neither are really acceptable. If I *had* to scrape up a winner from the bottom of the bucket, then yeah I would probably choose Qt5 over Gtk3 (even though I despise the idea of MOC). In practice I would likely choose Gtk+2 for future projects (it works better than both across a network)

 

[Mjölnir]

It is annoyingly similar to the Gnome 2 vs KDE 3.5 thing. Gtk+ 2 in the past was considerably more lean than Qt4. And then when Gtk regressed into Gtk3, suddenly Qt4+ was competitive again. So rather than overtake Gtk+, Qt kinda undertook it instead XD

IIRC KDE 4 got a major overhaul/redesign with focus on size & minimize the # of dependencies. I dunno if and to which degree these efforts affected Qt, too. The last comparison I read stated that KDE 5's memory footprint is near (slightly above) XfCE's, while offering (much) more features. Naturally, a software's functionality needs to be coded & data to work on, so that's reasonable. IMHO Qt itself was always lean; the bloat was added mainly through KDE libraries & apps by lazy programming, e.g. to subclass for only one feature, resulting in saving a few LOC for the feature while loading a library of 10x more LOC (plus it's dependencies).

The truth is that neither are really acceptable. [...] In practice I would likely choose Gtk+2 for future projects (it works better than both across a network)

The sad truth is that all existing DE/GUIs except Lumina suffer from Linuxisms and would be much more acceptable for BSDers w/o that bloat. Could you provide an example or two for your statement about network friendliness?

 

[ekvz]

KDE 5's memory footprint is near (slightly above) XfCE's

While i haven't checked myself i have little doubt about this. Xfce was never that lightweight and adopting GTK3 (which i pretty much assume they did by now) with all it's pointless bling surely didn't help.

IMHO Qt itself was always lean

It probably is. Maybe not as much as GTK2 was but in my opinion both toolkits have a vital flaw anyways: (L)GPL licensing. Qt fares a little better in that regard as it offers at least a paid opt-out but it still isn't what i'd call optimal. GTK2 also suffers (again in my opinion) from the rapidly shrinking adoption that has been going on for a couple of years now since part of what made it attractive to me (besides being lightweight and generally pretty bare) is the fact that it was possible to almost completely opt for applications based on a single toolkit (i obviously don't consider GTK3 to be the same toolkit). That's no longer the case and if i have to mix and match anyways i might as well look for alternatives with nicer licensing. Not that there is much viable options in regards to toolkits written in C but if the possibility arises GTK2 would have a way worse standing in my eyes than it had like maybe 5 years ago.

What would be pretty interesting would be a compatibility layer that maps GTK3 to GTK2 (or even better some non GPL toolkit) but i figure there is probably way to many differences that can't be mapped 1:1 making the end result a buggy mess at best. Let alone the amount of work such an effort would need.

 

[sidetone]

Licensing is a problem between gtk2 and gtk3. I believe they use incompatible versions of GPL. So now, for basic sounds, many programs need both libcanberra-gtk3 and libcanberra. I believe they use 1 source file, but the implementation is complicated. This may be due to incompatible licensing. If that's not bloat, then what is?

I may have gotten the wrong reason, but to have two implementations of libcanberra is inefficient.

 

[sidetone]

What would be pretty interesting would be a compatibility layer that maps GTK3 to GTK2 (or even better some non GPL toolkit) but i figure there is probably way to many differences that can't be mapped 1:1 making the end result a buggy mess at best. Let alone the amount of work such an effort would need.

They'll mess that up, the first chance they'll get. Maybe they keep it complicated to not break licensing reasons, as it seems with a purpose. but going direct to a feature that's non-GPL from both of them would work. They've done that when replacing many sound architectures with sndio, also with other programs that are in base or that are common among BSD's.

I want to learn how to do enough programming to do what's better.

 

[aht0]

There's Trinity DE (fork of KDE 3.5 like Mate is fork of Gnome2). It does not follow any new QT tho but has been maintaining their own fork of QT3 to avoid dependency problems.

https://en.m.wikipedia.org/wiki/Trinity_Desktop_Environment

I am kind of surprised nobody has shown interest in porting it to FreeBSD eventhough bunch of folks seem to recall KDE 3.5 with great fondness.

 

[kpedersen]

Could you provide an example or two for your statement about network friendliness?

For raster solutions (VNC), the many effects of modern toolkits such as pulsing, fading, etc, all generate large amounts of traffic as the image is always changing (just for pointless eye candy). Windows kind of gets away with this by being able to turn it off (interestingly for non-admin users, this is broken after re-logging in). Gnome 3 is probably the worst here. Just opening up the stupid menu is ~5MB of data .

For network protocol solutions (X11), the move from Gtk2 where at least some of the components could be drawn using instructions meant that with Gtk3 and Qt, it is all sending across raster images. This is much slower than a simple, "draw box here" instruction. Especially if you chuck in the slow interpolation effects mentioned above. Even for components that are entirely raster driven, there is usually ~3 image states. Normal, Hover, Down. It doesn't have that kerning in between.

Toolkits now are also looking at using acceleration (I don't know if they all do this yet) but sending over indirect GL commands is the likely future (if Wayland doesn't kill it completely). So what will this be just for the position, a Mat4x4 for every component drawn? Fun times.

 

[shkhln]

It's important not to conflate bandwidth with latency there, different use cases have vastly different constraints. X11 is designed with 80's / early 90's LANs in mind (low latency, low bandwidth), which is why it is so thoroughly obsolete.

Gtk2 where at least some of the components could be drawn using instructions

Which components?

Toolkits now are also looking at using acceleration (I don't know if they all do this yet) but sending over indirect GL commands is the likely future (if Wayland doesn't kill it completely).

I'm pretty sure indirect rendering has been dead for a decade already.

So what will this be just for the position, a Mat4x4 for every component drawn? Fun times.

You either get a raster image (ideally H.264 or H.265 or whatever from the video card onboard encoder) or an entire WebAssembly/WebGPU application.

 

[ekvz]

They'll mess that up, the first chance they'll get. Maybe they keep it complicated to not break licensing reasons, as it seems with a purpose.

Actually that's a very valid point. In any case it would be a serious cat and mouse game cleaning up the constant breakage.

Maybe they keep it complicated to not break licensing reasons, as it seems with a purpose. but going direct to a feature that's non-GPL from both of them would work. They've done that when replacing many sound architectures with sndio, also with other programs that are in base or that are common among BSD's.

The biggest problem is (from my perspective) that there is little to turn to. Sure there is a bunch of toolkits readily available but practically all of them are either C++, something that looks like it's from the 80s or stuff like Imgui. Nothing against Imgui but i just don't think that would be appropriate as a general solution and as far as C is concerned what really exists there? I've thought this through a couple times already with the result always being pretty much nothing and you don't just go write a toolkit from scratch. At least i wouldn't want to (try it again...). In my opinion there is about 2 options right now but 1 is rather unorthodox and the other depends on unfinished projects. At the moment it's simply not looking good in relation to replacing the big players i'd say.

effects of modern toolkits such as pulsing, fading, etc,

Jeez, yes the pointless bling bling... Don't get me started.

all generate large amounts of traffic

Now i somehow want to start a GTK3 application on my development server just to see how slow that would end up being over X forwarding but i think i'll control my urges

 

[sidetone]

Actually that's a very valid point. In any case it would be a serious cat and mouse game cleaning up the constant breakage.

It seems like it, as when it gets pointed out how to make things better, it goes right back to complicating things. Not if there's a drop in replacement, that goes straight to an implementation that is compatible with many BSD's. Using something that is common among similar projects would provide better ongoing maintenance.

I want to learn C. I'm reading on Rust programming, but won't learn it hands on for now. Then I'll read about C and get hands on that first, having what I will learn from reading on Rust in mind. I wanted to learn Rust first, but to do that first hands on, before getting hands on in C isn't practical for fixing things, when everything is in C.

The biggest problem is (from my perspective) that there is little to turn to. Sure there is a bunch of toolkits readily available but practically all of them are either C++, something that looks like it's from the 80s or stuff like Imgui

Could Tcl/Tk be used for desktop utilities that don't have a toolbar (or complex) interface, as a drop-in for GTK or QT? Such as that don't have a menu, nor need a visible interface for mouse clicks? Tcl/tk mouse interfaces may arguably be unappealing, but for desktop utilities that are of changing images, displays and very basic controls that the only interface is one needing one click and/or basic scroll over the application, tcl/tk may be overlooked. Such as for desktop meters, volume controls, desktop calendars... etc.

 

[kpedersen]

It's important not to conflate bandwidth with latency there, different use cases have vastly different constraints. X11 is designed with 80's / early 90's LANs in mind (low latency, low bandwidth), which is why it is so thoroughly obsolete.

The impossible bandwidth requirements of VNC completely overshadows latency issues making it a non-issue so I didn't feel a need to mention it. As it stands, many internet connections (certainly in England) are unable to yield a good result using VNC. Especially if we look at higher resolutions.

Sure, the "obsolete" X11 protocol may be "chatty" and have a lot of backwards and forwards of messages but it still works at a decent speed over a slow connection (which the internet generally is). I could probably have 1000 round trips by the time a single VNC frame is transferred.

With the sheer amount of bandwidth required for VNC, I am actually failing to see a use-case for it across the internet.

So my fairly simplistic (verging on trolling) results are:
X11 - LAN fast, Internet medium
VNC - LAN fast, Internet slow

Which components?

It is mostly dependent on theme engine to be fair. Raleigh in particular can be made up of primitives so if you resize a i.e plain button, it will send the X11 command to clear the area rather than an image (i.e with some fancy gradient effect). If you use ssh/x11 with that vs clearlooks, you will notice it is more responsive. Not quite on par with RDP and a win32 backend but still workable.

 

[ekvz]

Can tcl/tk be used for desktop utilities that don't have an interface, rather than GTK or QT? Such as that don't have a menu, nor need an interface for mouse clicks?

Funny you bring that up. Tk (or rather Ttk which is Tk in less ugly) would have been the unorthodox option and yes, of course you can build UIs with it. Thing is Tk doesn't have an API in the usual sense. If you want Tk you have to embed TCL. Now it wouldn't be overly hard to make the whole thing self contained but there would need to be some glue code to pass data/messages between TCL and the C code. TCL is actually easy to interconnect with C but once there is a lot of data or events it's facilities are likely not going to cut it. That would need some good design to be useful as a general solution and it would also need some tools to compile the UI scripts/assets into the application binary (well that's optional but saves the hassle dealing with paths and also just looks nicer). Oh and of course let's not forget that many people hate TCL (not entirely undeserved i have to admit) which could be somewhat worked around by forking Little but that's another story then. TL;DR: Could work but is not as trivial as it might seem and might not really work all that good in the end.

Tcl/tk mouse interfaces may arguably be unappealing, but for desktop utilities that are of changing images, tcl/tk may be overlooked.

I won't overlook TCL. Never! But you have a good point. It's pretty niche for being one of the oldest scripting languages and the origin of a toolkit that's even used by python (at least is was a couple years ago - i don't really follow python).

 

[user00]

The only editor that can still open 200+ MB files under Xorg is... tada! nedit. Vanilla XWindow interface. F k progress! I am for functional and working software. fvwm is still around and it is telling. Gnome 3 should have never been accepted in any distribution, but everyone just winked.

 

[ekvz]

The only editor that can still open 200+ MB files under Xorg is... tada! nedit. Vanilla XWindow interface. F k progress!

Which hasn't been the topic of this discussion so what's your point? Exactly.

I am for functional and working software.

What a relief. I am glad to hear that.

fvwm is still around and it is telling.

The only thing that's telling is how you either can't or don't want to comprehend was has been written here.

Gnome 3 should have never been accepted in any distribution, but everyone just winked.

Yeah and i should be rich, beautiful and omnipotent. Let's hope your logic works.

 

[sidetone]

I am for functional and working software.

There's nothing functional about Gnome. Gnome 2 is better than Gnome 3, but they still have excessive and unnecessary dependencies.

 

[kpedersen]

There's nothing functional about Gnome. Gnome 2 is better than Gnome 3, but they still have excessive and unnecessary dependencies.

Its true. And on FreeBSD particularly, Gnome 2 was actually pretty rough. Many of those dependencies caused a lot of issues. Some classic "features" from memory

• Core dumps left in home directory each session (usually nautilus.core and gnome-panel.core for me)
• No NetworkManager
• Most "System" category tools were broken. They looked great but did nothing.
• Using the add-user manager was dangerous
• gnome-power-settings were mostly defective
• Copying user settings to the gdm user (i.e screensaver timeout) was a mess
• So many missing icons. Some completely bizarre ones like the "Run" icon.
• Attempting to mount by clicking a volume would whine about bizarre hald/Polkit "things"
• Desktop icons would just appear on top of one another

Yes, all these things could have been fixed if Gnome 3 never happened and we had another 20 years. But lets be honest, given 50 years it would still be broken in so many ways. Most developers simply have more interesting projects to work on.
I am even starting to suspect that these user-friendly / consumer centric desktop environments are becoming less and less common. Now as a user, it is all about web sites. And for developers it is still all about the command line.

 

[Mjölnir]

The only editor that can still open 200+ MB files under Xorg is... tada! nedit. Vanilla XWindow interface. F k progress!

ls -lh /var/db/clamav/daily.cld:
-rw-r--r-- 1 clamav clamav 328M 27 Sep. 19:01 /var/db/clamav/daily.cld
user@t450s:~ % kate /var/db/clamav/daily.cld &

fsck(8) ignorance...

 

[user00]

• No NetworkManager

No NetworkManager is a blessing.