Solved Gnome/GTK-free Desktop

Is it possible to have a Gnome-Free Desktop? Suppose you have a non-Gnome desktop (i3, KDE, etc). Is there any specific program in Gnome project that has no usable alternative in other projects e.g. KDE. What about GTK? For example is there enough Qt-based applications out there, to be able to ignore GTK-based/Gnome-related programs completely? Thanks.
PS. It's just a continuation of the my profile post. Thanks to Jose.
 
To recap the profile thread, Fltk and Wxwidgets both pull in glib and gtk.

Sidetone suggested TCL/Tk. However, he mentions that "Tcl/tk mouse interfaces may arguably be unappealing" in a different thread.

Vigole suggested Motif/Openmotif.

The motivation for me is the incessant churn of GTK versions, and trying to avoid the Gnome 3 disaster. I don't know much about KDE/QT, but I gather from reading Kpedersen's posts that it's in shape similar to Gnome 3. I also would like to avoid Freedesktop overhead like dbus, gconf, etc.

Edit: Added Kpedersen and Sidetone's interesting comments from a thread with an uninteresting topic.
 
For a nice appearance of anything with a clickable toolbar, gtk is the only way for now.

For desk utilities that don't have a tool bar interface (but can be minimally controlled with a mouse), tcl/tk could do. IE... desktop calendars, status displays, volume control. vigole brought up Motif, perhaps, that can be used this way too. Which ever these would work, or xaw or nextaw (Nextaw is for NextStep WM). Perhaps even something more basic for these. Jwm window manager can be used without gtk, and it has enough graphics needed for display and function. You wouldn't know now, because they later made gtk a dependency for it, as they already did for other window managers.


As for gtk's use for basic sounds, it would be nice to have a simplified drop in replacement for libcanberra that goes from the application to sndio. Sndio, because it's available for many BSD's: this would ease maintenance among these OS's. I want to learn if I can make that, which won't interfere with both GPL licenses, and call it libsplash. Pango is an interface for canberra which displays text with sound, text instead of sound, or text if the sound doesn't work.
 
Sidetone suggested TCL/Tk. However, he mentions that "Tcl/tk mouse interfaces may arguably be unappealing" in a different thread.

That's true for TK (https://web.archive.org/web/2003031...georgeps/Tk_Theme/Tk_Theme_With_Malephiso.png http://www.ucolick.org/~de/Tcl/pictures/misc/tkBio.png) but plain Tk is pretty much a legacy thing (at least in regards to TCL - pythons implementation is stuck with Tk i think). These days you would usually use Ttk (https://wiki.tcl-lang.org/page/Ttk) which is looking somewhat like this: https://wiki.tcl-lang.org/page/List+of+ttk+Themes.

Like i said Ttk really isn't that bad. It's rather the integration that makes it tricky (would need some extra code for syncing data / passing events if the application isn't simple enough to get away with using the raw C integration API of TCL) as you can't embed it directly but have to embed TCL instead. In general having TCL around isn't half bad as it can be used to do the GUI layout and/or implement more/improved widgets. The only real drawback is that TCL's variable system is somewhat "special". Which is why i would consider forking Little (a TCL hack with C style syntax: https://www.little-lang.org/).

Side note: Tk can use native widgets on windows and OSX (i think) so if you see nice looking Tk that's probably the reason.

Edit: I actually have some code lying around that adds a good part of that integration to TCL but it's not 100% finished and belongs to a larger project so even if i'd separate it it would come with quite some extra code (generic/cross os thread lib, event loops, memory organization, VFS, ...).
 
I have been looking a little further into Fltk for my own uses and came across this:
https://alf-p-steinbach.github.io/Install-FLTK-for-use-with-Visual-C-/

Not that Win32 is a particularly interesting target for me but if it can be compiled for this, surely it doesn't have any very tight dependencies on glib and friends. Potentially they are fairly superficial (i.e to implement some file locking or taskbar icon). When I get some time I am going to see if it can be cleaned up a bit.

The EDE desktop environment used to provide their own version of Fltk (efltk) and I wonder if it was for this reason.

Like i said Ttk really isn't that bad. It's rather the integration that makes it tricky

I have not really touched Tcl but I did spend some time with Perl/tk. I liked it. The (Tk rather than Ttk) components look terrible by default but with some tweaks, they can be made the spitting image of Microsoft's "modern" look. And people love that right?... right? ;)

As for a window manager to avoid the Gtk stuff, there are many to choose from. However there are relatively few that are considered "sane" enough for a desktop environment. OpenBox is close, perhaps the Gtk could be stripped out. Otherwise something simple like WindowLab (https://github.com/nickgravgaard/windowlab) could be adapted. Or even one written from scratch. Unlike wayland compositors, WMs are fairly easy (https://jichu4n.com/posts/how-x-window-managers-work-and-how-to-write-one-part-i/). I spent a while in the past adding multiple desktops into Mwm back in the OpenCDE days and it was impossible.

<ramble class="semi-rant">
All of this isn't hard stuff. It is just time consuming and something that *should* have been solved back in the late 80's. I can't believe that after 40 years we don't have better than what we currently have. In some ways it provides evidence that open-source development has a few underlying issues.
</ramble>
 
I actually managed to dig up a little example. Props to whoever manages to find out what the application does ;)

Code:
#include "lazy/common.h"
#include "lazy/main.h"
#include "lazy/io.h"
#include "lazy/log.h"
#include "lazy/tcl.h"

static tcl_t tcl = { 0 };
static index_t id = 0;
static io_vfs_t vfs = { 0 };

COM_BLOB_IMPORT( tk_vfs );

static status_t Init( void ) {
    if( !IO_Init() !TCL_Init() || !IO_VFSMount( &vfs, "",
            IO_MEM( COM_BLOB_PTR( tk_vfs ), COM_BLOB_SIZE( tk_vfs ) ),
            IO_VFSTYPE_ZIP
        ) ||
        !TCL_Setup( &tcl, &vfs,
            IO_FILE( NULL, "/main.tcl" ), MAIN_Handler(), TCL_FLAG_TK
        )
    ) {
        return STATUS_ERROR;
    }
    return STATUS_CONTINUE;
}

static status_t Frame( void ) {
    return STATUS_CONTINUE;
}

static status_t Event( void *source, uint_t type, void *data ) {
    if( source == &tcl ) {
        switch( type ) {
            case TCL_EVENT_SCRIPT: {
                mem_pack_t *args = data;
              
                if( !MEM_PACK_COUNT( args ) ) {
                    LOG_ERROR( "empty script event" );
                    return STATUS_ERROR;
                }
                if( STR_Match( MEM_PACK_PTRARG( args, 0 ), "exit" ) ) {
                    return STATUS_OK;
                } else if( STR_Match( MEM_PACK_PTRARG( args, 0 ), "input" ) ) {
                    uint32_t hash;

                    if( MEM_PACK_COUNT( args ) != 2 ) {
                        LOG_ERROR( "bad argument count for input" );
                        return STATUS_ERROR;
                    }
                    hash = CRYPT_DJBString( MEM_PACK_PTRARG( args, 1 ) );
                    TCL_EvalPack( &tcl,
                        MEM_PACKINFO(
                            MEM_PACKINFO_VALUE( "additem", MEM_TYPE_STRING ),
                            MEM_PACKINFO_VALUE( &id, MEM_TYPE_UINT32 ),
                            MEM_PACKINFO_VALUE(
                                MEM_PACK_PTRARG( args, 1 ), MEM_TYPE_STRING
                            ),
                            MEM_PACKINFO_VALUE( &hash, MEM_TYPE_UINT32 )
                        ), 0
                    );
                    ++id;
                    TCL_VarSet( &tcl, "count", &id, MEM_TYPE_GUESSINT( id ), 0 );
                }else {
                    LOG_ERROR( "bad script event" );
                    return STATUS_ERROR;
                }
                break; }
            default:
                LOG_ERROR( "bad event type" );
                return STATUS_ERROR;
        }
    } else {
        LOG_ERROR( "bad source" );
        return STATUS_ERROR;
    }
    return STATUS_CONTINUE;
}

MAIN_Loop( Init, Frame, 25, NULL, 0, Event, 0 );

Code:
proc additem { args } {
    itree .test.output.hashes {} end {*}$args
}

proc test {} {
    global input count
    set input {}
    set count 0

    window .test -title {UI Test} -scalex 1 -scaley 1
    onclose .test { sevent exit }
  
    grow .test.input
    entry .test.input.edit -textvariable input
    button .test.input.ok -text "OK" -width -1 -command {
        sevent input $input
        set input {}
    }
    gcol .test.input.edit -sticky nswe -weight 1
    gcol .test.input.ok

    grow .test.info
    label .test.info.label -text Count:
    label .test.info.count -textvariable count
    gcol .test.info.label
    gcol .test.info.count -sticky nswe -weight 1

    grow .test.output -weight 1
    tree .test.output.hashes -columns {id text hash} \
        -selectmode none -show headings -scrolly 1
    ctree .test.output.hashes id -text ID -cwidth 4
    ctree .test.output.hashes text -text Text
    ctree .test.output.hashes hash -text Hash -cwidth 16
    gcol .test.output.hashes -sticky nswe -weight 1
}

test

That Ttk wrapper is garbage with a capital G though. It would be way better to just use standard Ttk functionality than this abomination (i was trying stuff and never got around to build something solid or just scratch it in favor of default functions) so i wouldn't exactly expect the TCL code to look like that if this was actually finished some day.

I have been looking a little further into Fltk for my own uses and came across this:
https://alf-p-steinbach.github.io/Install-FLTK-for-use-with-Visual-C-/

Not that Win32 is a particularly interesting target for me but if it can be compiled for this, surely it doesn't have any very tight dependencies on glib and friends. Potentially they are fairly superficial (i.e to implement some file locking or taskbar icon). When I get some time I am going to see if it can be cleaned up a bit.

FLTK is rather nice. The only sad part is that it's C++. Otherwise i'd be pretty much sold.
 
  • Like
Reactions: a6h
What's the most minimal graphic library that is used for displaying images and application boxes/windows on the desktop that has a BSD-like license?

That should be the basis, and used for plain desk utilities that dont have a tool bar. Not glib. Something like xaw? Xlib?

libxcb? libx11?
 
Props to whoever manages to find out what the application does ;)

Prints out a simple message box saying "Hello World". The rest of the code is just boilerplate? ;)

hmm, just looking through the code.. it hashes things and puts them in a tree structure. Hmm, quick sort? Merkle Tree?

FLTK is rather nice. The only sad part is that it's C++. Otherwise i'd be pretty much sold.

If the API is nice, I would rather C but C++ is not too annoying these days. There is even some early smart pointer functionality in the API leading to some semblance of safety.

That said, Fltk comes with a tool called FLUID for building the UIs. Apparently it can do a lot more than that. You can build many applications without even writing a line of code. It uses a kind of flowchart like visual language. I tried to play with it but got completely lost XD
 
just looking through the code.. it hashes things and puts them in a tree structure. Hmm, quick sort? Spatial partition?
Beat me to it. Looks like takes a string and computes a DJB hash of it. Keeps a list of strings and their hash, maybe the list is displayed?

Edit:
That said, Fltk comes with a tool called FLUID for building the UIs. Apparently it can do a lot more than that. You can build many applications without even writing a line of code. It uses a kind of flowchart like visual language. I tried to play with it but got completely lost XD
I always find those UI builders much harder to use than writing out the code for the UI widgets I want. Then again, I'm mostly a back-end guy.
 
What's the most minimal graphic library that is used for displaying images and application boxes/windows on the desktop that has a BSD-like license?

That should be the basis, and used for plain desk utilities that dont have a tool bar. Not glib. Something like xaw? Xlib?

Yes, all the needed functions to get raw pixels on the screen and have windows should be somewhere in the X11 libraries. It's tempting to just go straight for the source and roll your own, i know. Writing a serious toolkit on nothing but a couple primitive draw functions and/or loading of images is not an easy task though but don't let that stop you. I had to try myself too before i came to the conclusion that i'd rather not do that ;)
 
just looking through the code.. it hashes things and puts them in a tree structure. Hmm, quick sort? Spatial partition?

Yes, that's pretty close. It's not doing anything fancy (like sorting or anything) though. It just hashes input strings and adds them as 3 items (string, hash, id) to a 3 column listbox (don't ask why it's called tree lol - it's been years and years since i wrote that) while incrementing the id and updating a label with it. It's really just pointless testcode and the interesting details are abstracted away anyways (like how TCL runs in another thread and communicates with the main part using FIFOs or how that "MEMPACK" thing makes sure that all the values are put directly into the FIFO buffer and not have to be copies around). Jeez, i had a lot of free time back then.

If the API is nice, I would rather C but C++ is not too annoying these days. There is even some early smart pointer functionality in the API leading to some semblance of safety.

Sure and with a bit of luck a wrapper is also possible. C++ is not very nice when it comes to distributing binaries though as you pretty much have to statically link libc++ if you want it to run on systems with even the slightest differences. C++ is sadly just not very flexible in certain situations that's why i'd prefer C a the base. Wrapping it in C++ for those who want that won't be a problem anyways but oh well, it's not like there is a real choice.

Beat me to it. Looks like takes a string and computes a DJB hash of it. Keeps a list of strings and their hash, maybe the list is displayed?

Also pretty close. It doesn't really keep a list in the stricter sense though. It just adds them to the listbox and does not care any further ;)
 
but oh well, it's not like there is a real choice.

Speaking of choice, I believe vigole posted this book a few days back.
https://www.amazon.co.uk/Programming-Principles-Practice-Using-C/dp/0321992784

Had a quick flick through. I was interested because this is written by Stroustrup and yet has some fairly large sections on GUI; something that C++ has never really committed to in the past. Understandably, it isn't really a programming language's place to dictate a GUI library, and instead that task is to be delegated out to the wider community...

So he chose Fltk... this kind of made me chuckle. I can honestly imagine Bjarne starting to sweat after realizing that the wider C++ community has done a pretty crap job and writing itself a UI system.

Qt - Not standard C++ (MOC).
Gtkmm - Pretty much Linux only (bindings ontop of a C API).
wxWidgets - Fairly ancient design. Copying off MFC in a number of areas.
VCL - Proprietary. Many Delphi-isms
Microsoft "Metro" - Not standard C++ (cx/clr extensions)
Fltk - Written by ~2 people. Most issues are closed stating "lack of man-power".

So in 2014 (when the book was released). The best choice that Stroustrup could find was the one supported by a number of developers you can count on one hand. That said, maybe that isn't such a bad idea. A lack of man power means that it wont exactly get "bloated" any time soon XD
 
One more option in general would be using some leightweight HTML render engine. Sure it needs a little customization but building widgets with it should be dead easy. Everyone knows HTML/CSS. From my perspective there is currently nothing perfect either though.
There is other projects too but usually they don't support much CSS which i feel is needed to get a nice visual result. Otherwise one could just rip the render code out of tkHtml and and enjoy the blockyness ;)
 
So he chose Fltk... this kind of made me chuckle. I can honestly imagine Bjarne starting to sweat after realizing that the wider C++ community has done a pretty crap job and writing itself a UI system.
There's something odd about C++ and OOP in general, but I can't quite put my finger on it! If I have to choose a language with higher level of abstraction, more than C, Frankly I prefer Go (lang/go).
In the context of non-GTK GUI/widget, does Golang has any future? I know a little about Golang, but I'm not a Golang programmer. There're lots of GUI binding for Go. On paper, everything sound good, but is it practical (language itself, supported libraries, etc), or we are all have to use C++ for good!
 
Athena, Motif or something like them would be better than Tk, because Tk requires the programming language Tcl.

There's a few diagrams that show Xaw (X Athena Widgets) and Motif pointing to Xt or x-toolkit, x11-toolkits/libxt. Xaw or Open Motif with libxt will already be perfect for deskutils that come without a toolbar.

* Correction: x11-toolkits/open-motif uses either an LGPL license or a customized license. According to ports, x11-toolkits/Xaw3d (Athena) uses an MIT license.

x11-toolkits/libxaw3dxft is associated with graphics/xpaint, so that's already an alternative to Gimp for designing.
 
  • Like
Reactions: a6h
For a nice appearance of anything with a clickable toolbar, gtk is the only way for now. [...]
??? Gtk is inherently (deliberately) broken by design... And Qt? It is fairly clean, mature, robust, etc.pp. If you don't like the moc precompiler, you can use many other modern languages than C++.
 
  • Like
Reactions: a6h
Motif or something like it would be better than Tk, because Tk requires the programming language Tcl.

I wouldn't say it's strictly better. TCL can be made to be fully self contained (even it's default library can be compiled into the resulting binary if one wants that - having the option of either hardcoding the UI scripts into the binary or shipping them alongside able to be customized is also a nice gimmick) and not having to do UI logic in C actually has it's upsides. Writing it in C is pretty boring, long winded and there is little to be gained from it as UI is usually not really performance critical. That's also why i'd consider using HTML/CSS (i think Steam shows that this can work fairly well - just their choice of embedding Chrome might be a "bit" heavy...). I don't have that much experience with C++ so the situation could be a bit different there but as far as C is concerned i kinda like the idea of moving out UI logic to something more suited for the task (if TCL fits that spot is of course another question - as i said even i would at least consider Little and i am one of those weird people who somewhat like TCL).

Semi related: Since when is SDL2 Zlib licensed? I was under the impression of it being LGPL? If SDL2 is actually not GPL infected that gives a really interesting spin to Tk/Ttk. Given Undrowish has been made to build non Android versions of Androwish TCL/Tk can literally target everything for which there is a SDL graphics driver. Beeing able to support such an amount graphics backends is a pretty impressive feature for a toolkit in my opinion.

Edit: You guys are horrible. Now i have this really strong urge to attempt building a library and a toolset based on this to see if it could work as nicely as imagine it might ;)
 
??? Gtk is inherently (deliberately) broken by design... And Qt? It is fairly clean, mature, robust, etc.pp.
I know gtk is messed up, and I suspected it was by design, because I know it's inefficient. I know QT5 is good, but it's usually for heavy weight applications. For basic applications, gtk2 did the job, despite it's flaws.

Appearance-wise, gtk2 was much better looking than many Motif/Xaw based applications.

If you don't like the moc precompiler, you can use many other modern languages than C++.
Does that include Rust for QT5?
 
The audio mixer audio/xmmix which uses Motif actually doesn't look bad, except for the cursor changing.

Now i have this really strong urge to attempt building a library and a toolset based on this to see if it could work as nicely as imagine it might

Motif/Xaw already have the libxt library. Go from those associated applications.

Edit * maybe you meant a toolkit for tcl/tk.
 
Motif/Xaw already have the libxt library. Go from those associated applications.

Uh what? I don't think we are speaking about the same thing here. I somewhat doubt Motif/Xaw has a C integration for TCL/T(t)k or tools to "compile" UI scripts ;)

I understand how this is confusing though. Without some demo code it's probably hard to get what i am thinking of. If i could i would just sit down right now and punch this in (OK, it would likely still take a couple of days to get something presentable) but time constraints... Well, maybe some day in the future :(
 
If you don't like the moc precompiler, you can use many other modern languages than C++.

For me personally, I don't dislike MOC because it is not pleasant to use. I dislike MOC because in the past I have seen it reduces the lifespan of the software and makes it a considerable maintenance nightmare.
Unfortunately using another language doesn't really solve that because the bindings underneath many layers still rely on MOC.

Something like this: https://github.com/woboq/verdigris would be more ideal (MOC-less C++) but it is currently a little too niche.
 
Why don't you guys dive into LxQt and/or Lumina and help there?

It's not attractive to me because of the licensing and being based on C++. As you might have noticed i am (for similar reasons) not sold on FLTK either but it actually comes out ahead from my perspective by having the "right" license.
 
Back
Top