GTK to remove X11 backend

[kpedersen]

I think that's very sound arguments against incredibly uninformed fantasies. I'm seeing LOTS of people fantasizing about writing their own OS, their own lib/toolkit, without realizing what that would even look like if they actually tried.

I'm pretty sure it was Linus himself who said, "Talk is cheap, show me the code!".

Heh, yeah. Back in my OpenCDE days, I also started a C++ GUI library called motifmm (some info at the bottom of this wayback page).
It was really just a c++ wrapper around Motif (so I could avoid wxMotif) and even that was a very large amount of work (too much!).

That said, for a DE specifically, I think distributing the workload could be quite easy if we can just decide on *any* GUI library.
If ~20 people currently on these forums who do any development work (or is interested in starting) has a bit of free time and writes a single "thing" for a FreeBSD desktop environment. We could certainly potentially have something workable in around a month.

 

[drs310]

There are people maintaining GTK2 and GTK3 forks:

GTK2: https://github.com/stefan11111/gtk2
GTK3 (CTK/Cafe Toolkit?): https://github.com/cafe-desktop/ctk

I think there are a few more, but those are the ones I know about.

 

[cracauer@]

There are people maintaining GTK2 and GTK3 forks:

GTK2: https://github.com/stefan11111/gtk2
GTK3 (CTK/Cafe Toolkit?): https://github.com/cafe-desktop/ctk

I think there are a few more, but those are the ones I know about.

Now I just need one for GTK+1

 

[drs310]

Now I just need one for GTK+1

GitHub - devinsmith/gtkretro: An ancient / retro version of GTK for fun

An ancient / retro version of GTK for fun. Contribute to devinsmith/gtkretro development by creating an account on GitHub.

github.com

However, you may not like this version because it's using CMake to build. The other thing about GTK+1 is that it doesn't have support for Xft (although maybe that's not hard to add?) so the fonts don't look to nice on high resolution displays.

 

[cracauer@]

GitHub - devinsmith/gtkretro: An ancient / retro version of GTK for fun

An ancient / retro version of GTK for fun. Contribute to devinsmith/gtkretro development by creating an account on GitHub.

github.com

However, you may not like this version because it's using CMake to build. The other thing about GTK+1 is that it doesn't have support for Xft (although maybe that's not hard to add?) so the fonts don't look to nice on high resolution displays.

Thanks for that.

I need it for my picture previewer/sorter, so the fonts don't matter.

 

[astyle]

When there's a will, there's a way.

 

[cracauer@]

When there's a will, there's a way.

Ugh. First attempts on macOS indicate a lot of will will be required.

 

[kpedersen]

Ugh. First attempts on macOS indicate a lot of will will be required.

https://www.xquartz.org/

Easy-peasy

Can even get Motif running without much issue.

That said, since macOS moved from GCC to Clang, perhaps there are some new issues introduced.

 

[cracauer@]

https://www.xquartz.org/

Easy-peasy

Can even get Motif running without much issue.

That said, since macOS moved from GCC to Clang, perhaps there are some new issues introduced.

Yeah current macOS clang chokes on some macros in glib-1.2. I'm past that with gcc-14 but now come the linker errors. And CMake disobeyes the set(CMAKE_VERBOSE_MAKEFILE TRUE) I have

 

[ThomasAdam]

https://www.xquartz.org/

Easy-peasy

Can even get Motif running without much issue.

That said, since macOS moved from GCC to Clang, perhaps there are some new issues introduced.

Indeed:

 

[cracauer@]

On

Indeed:

View attachment 21850

On my Mac I often use gcc for random programs. It is easy to get from homebrew or macports. LLVM behaves differently in quite a few details.

 

[ThomasAdam]

On my Mac I often use gcc for random programs. It is easy to get from homebrew or macports. LLVM behaves differently in quite a few details.

Do you have examples of this? It's not as if they're orders of magnitude different from one another...

 

[cracauer@]

Do you have examples of this? It's not as if they're orders of magnitude different from one another...

I didn't keep specifics. I remember that one C++ warning was turned into an error in clang++.

LLVM is also stricter about stack allocation and lexical scope. That lead to the discovery of a bug in pthreads code of mine.

 

[ThomasAdam]

Sure, but these are specifics rather than generalisations... I'm just trying to appreciate the issues you've run into, when many consider LLVM/GCC interchangable, and with good reason.

 

[cracauer@]

Sure, but these are specifics rather than generalisations... I'm just trying to appreciate the issues you've run into, when many consider LLVM/GCC interchangable, and with good reason.

For my own code I can use either, except for the stack bug I mentioned. I'm glad LLVM pointed it out of course.