basic x windows applications

Funny how the old school retro look on a user interface seems amazing to the "young kids".
Kind of like vintage clothing.

The tradeoff between the old school and new toolkit is the amount of work the programmer needs to do.
Look at the tools used to create Mac native programs (at least the way it used to be): pretty much draw your interface, say "generate code" then fill in the backend with the specific functionality like save to the database or whatever.
Efforts that folk like cy@ and kpedersen are well worth it.

I know one can do "real work" with tools like tcl/tk and others, but the biggest part of a graphical application is getting buy in from people on "does this look right". Being able to quickly generate the shiny things is one of the best things about the tools. It gets old very quickly when people start to argue about the radius of corners on a button.
 
In my opinion all GUIs suck - the question is which GUI sucks less for your intended purpose.

The way to go and widely used GUI libraries though noawadays are either GTK or Qt, which are also both cross platform working on MacOS and Windows as well. All other libraries around today are just still there more or less because some ancient stuff which refuses to die still depends on it.

Of course there's other stuff as well, e.g. you could take Java (yikes!) or Electron (this derserves to die!), amongst others.
 
Can't stand flat UI... period. As my eyesight deteriorates with... uh, middle age... It's hard to distinguish borders between windows. Sure it's prettier, but functionally, ugh. I still like CDE and its cousins. These days, I guess XFCE is the city cousin.

Is CDE 64 bit? I was thinking it (and the motif stuff) was 32 bit for some reason.
 
eternal_noob said:
I agree. I use Qt at work and we have several applications based on it.

Qt is just perfect for nice looking, cross-platform apps.
Click to expand...
There seems to be a struggle between titans with QT and GTK+ that folks lean towards as the leaders in the UI market, with QT having a slight edge (maybe not in deployed applications, but with publicity). I'm just thinking about the last time I tried to install QT - it was humongous, had lots and lots of moving parts, had some weird 'why doesn't that work' stuff that was oh so convoluted to figure out, and when I did figure it out and get it running, left me with the 'will I ever be able to do that again and get it reinstalled properly' kinda feeling.

Before I go down the rabbit hole again, I'd be interested to hear how you and others experiences have been on the install, code, and deploy simplicity front?

The thread has a couple of examples with FLTK and TCL/TK - pkg install a single file, type up some code, compile and you have an executable that draws itself on the screen

Has doing this in QT/GTK+ gotten streamlined since I tried it last (years back, admittedly) or is it still the massive monstrosity of yesteryear?
 
This is a tk application i've written in Chicken-Scheme,
test.png
 
decuser said:
Before I go down the rabbit hole again, I'd be interested to hear how you and others experiences have been on the install, code, and deploy simplicity front?
Click to expand...
I never used Qt before i started to work at my current employer. I was always a GTK user.

I was thrown into cold waters but i must say the learning curve of Qt is very flat. Installation, programming, compiling and deploying is as easy as 1,2,3.
 
cy@ said:
Talking about retro desktop environments, I use CDE on my laptop. The last time I went to OpenHack here, a couple of GenZ people there remarked how they loved the look of CDE on my laptop. The 3-D effect of Motif widgets have a certain quality that you don't see on the flat looking toolkits that are the basis of today's desktop environments. OpenLook also had a 3-D look to it. It was style back then. It's no longer stylish to have that 3-D effect, probably because it takes a lot more effort to bake those effects into the toolkit.
Click to expand...
I hate the "everything is a Web page" look. I think it's being driven by things like React Native. Companies wanna do graphic design for a single UI toolkit that they can use across all platforms, and I admit it makes business sense, but frankly looks like crap.

I think I'm not alone. There's a reason why many Mac users pine for Snow Leopard.
 
Sorry I'm late to the party.

For anyone writing new code today for X11, I strongly encourage using XCB in place of XLIB. The main flaw of XLIB is every call blocks whereas in XCB, every call is asynchronous. You can push pixels to the framebuffer, do other work, and check later to see it completed. You can also create a shared memory segment to communicate a pixmap directly to the X server.
The only hassle is getting nice looking fonts rendered. That takes a little extra work.

XCB - in my opinion - solves 90+% of what Wayland is trying to accomplish.
 
eternal_noob said:
Here is a windowmanager written with XCB in only 159 lines of code.

github.com

tinywm-xcb/tinywm-xcb.c at master · stefanbidi/tinywm-xcb

Port of TinyWM to XCB library. Contribute to stefanbidi/tinywm-xcb development by creating an account on GitHub.
github.com github.com
Click to expand...
x11-wm/ittywm is in libxcb and based on tinywm. It has slightly more lines of code, at 171. https://github.com/marshallmason/ittywm/blob/master/ittywm.c

Some features don't work as well on it as on tinywm. It may have had some included unused headers and dependencies which were on libx11 though.
 
Kaminar said:
I also don't like the MOC preprocessor. I've never tried it, but Verdigris looks promising.
Click to expand...
Interesting. That's written by the author of moc, 'cause someone forked Qt to remove the moc dependency. I think it's an equivalent approach written to use only standard preprocessor macros. Frankly things like this "(t)he moc generated code is human readable for most part(sic)" give me the heebie-jeebies. Even human-written, and allegedly human-readable C++ code ain't exactly a joy to debug.
 
unitrunker said:
For anyone writing new code today for X11, I strongly encourage using XCB in place of XLIB. The main flaw of XLIB is every call blocks whereas in XCB, every call is asynchronous. You can push pixels to the framebuffer, do other work, and check later to see it completed. You can also create a shared memory segment to communicate a pixmap directly to the X server.
The only hassle is getting nice looking fonts rendered. That takes a little extra work.
Click to expand...
It seems that the programs based on different ones tend to conflict at times, where the libXCB based programs have problems functioning at times. Perhaps this has to do around upgrades.

One good thing is that a core part of libx11 was replaced with parts of libxcb by standard.
unitrunker said:
XCB - in my opinion - solves 90+% of what Wayland is trying to accomplish.
Click to expand...
Wayland is meant to be used with a graphical toolkit. libxcb is partial, and not a full graphical toolkit. The existing way is a shim for libxcb to work on Wayland, which for adaptability would be suitable. QT uses libxcb at its core. libcairo also can be optionally set to use libxcb rather than libx11; otherwise libcairo on FreeBSD is dependent on dependency hell. libxcb would be better than libx11, if used without a more graphical toolkit, for direct use to Wayland however.
 
decuser said:
There seems to be a struggle between titans with QT and GTK+ that folks lean towards as the leaders in the UI market, with QT having a slight edge (maybe not in deployed applications, but with publicity).
Click to expand...
Well when Qt started, it was back then a proprietary library by a Norway company called Trolltech. So it was also no opensource, they just allowed hobbyist use in the beginnings. Despite that, enough projects took it as their GUI.

GNOME was only founded in the old day because of that after KDE was announced to have a desktop where the GUI library is under the GPL.

Later then Qt became real opensource under the GPL, and was owned over time by different companies, like e.g. Nokia.

So as a result the whole development process and basic design of Qt is vastly different from GTK, because Qt started as commercial product and was always backed by a company.

GTK on the other hand something where developers might get hired by companies like SuSE, RedHat and so on in the past, but there was never a company in the background which owned it and steered the development alone due to this.

So much likely Qt has solutions and tools around for problems where GTK might fall behind or better tools in some areas, it is a much bigger solution.

There are also some bigger projects around, which in the past switched from GTK to Qt and explained their reasons, like e.g. Rosegarden, Wireshark or LXDE. I don't know much about the other way around, projects which moved from Qt to GTK.

There are also videos like this around - keep on mind 9 years old by now - where people explained why they made that switch. And Dirk Hohndel for sure knows his way around OSS as X.org guy.

View: https://www.youtube.com/watch?v=ON0A1dsQOV0
 
I thought GTK was done to support the development of GIMP?

I once wrote things with GTK. It's definitely OK and doesn't have too much programming overhead. It also has a graphical GUI builder. These days I would feel more attracted to fltw, but I didn't have to do native code GUI apps in a long, long time.
 
Yes, GTK started indeed its life to be the GIMP ToolKit after they wanted to get rid of Motif. But it started as GPL library, so... Qt was still proprietary, Motif as well.

So 10 months after KDE was announced, Miguel de Icaza formed the GNOME project (https://mail.gnome.org/archives/gtk-list/1997-August/msg00123.html).

Parts of the original announcement were:

Why don't you just use/contribute to KDE?

KDE is a nice project; they have good hackers working on it and
they have done a very good job. Unfortunately, they selected the
non-free Qt toolkit as the foundation for the project, which poses
legal problems for those desiring to redistribute the software.

Why not write a free Qt replacement instead?

The KDE project -in its current form- has about 89,000 lines of
code, on the other hand, the source code for the Qt library has
about 91,000 lines.

Qt also forces the programmer to write his code in C++ or Python.
Gtk can be used in C, Scheme, Python, C++, Objective-C and Perl.

Also, we believe that KDE has some design problems (they have lots
of good ideas though) that we plan to fix.
 
Alain De Vos said:
gtk has more bindings also due to introspection,
Click to expand...

Well, GTK as a C-based solution is a lot more friendly to other languages than anything C++ based. You can easily embed a GTK written program within a interpreter for a different language and use part of the GTK part from the other language. You can generally forgot about that with C++, unless you write another layer going through, well, C.

On the other hand it can be said that C is really not the most suitable language for GUI programming. In fact GUIs seem to be one of those rare occasions where object-oriented programming makes sense.
 
cracauer@ said:
On the other hand it can be said that C is really not the most suitable language for GUI programming. In fact GUIs seem to be one of those rare occasions where object-oriented programming makes sense.
Click to expand...
Well said. I teach C# and the students are constantly amazed that I don't just fawn over the object oriented capabilities. I try to explain to them that tasks, in the real world, rarely lend themselves to object oriented solutions - with the the notable exceptions of reusable libraries and guis :).
 
To be honest, i gave up on using GTK due to its ugly C API. I am a C++ guy and for me, Qt's C++ API is just beautiful.

And no, i don't like using wrappers. They seldomly are usable but are rather limited.
 
eternal_noob said:
To be honest, i gave up on using GTK due to its ugly C API. I am a C++ guy and for me, Qt's C++ API is just beautiful.

And no, i don't like using wrappers. They seldomly are usable but are rather limited.
Click to expand...
C++ and beautiful, in the same sentence, whew! Well you did say Qt's C++ API, so maybe that's beautiful, I'll have to take a look. As for C++, I can't stand C++ in its current incarnation. Maybe once upon a time, but these days, it's uh overbuilt, overcomplicated, overthunk... maybe just over... as in over the top. I did pro C++ for a decade, now that I have my own spare time, I prefer the clarity of straight c over C++, but to each their own.
 
You must log in or register to reply here.
Back
Top