Is there anyone still developing applications with OpenMotif?

[DiTBho]

On Xterminal from the 90s and early 2000s (Tektronix's, NCD's, ...), { Motif, lessTif, OpenMotif, ... } seems like the only thing that makes sense, as GTK2, GTK3, KDE and QT dropped support for pseudo colors in 2010 as well as support for bitmap fonts and are massively using "too modern" approach, like xrender and xshm, if not also MESA stuff.

Anyway, even on a modern GNU/Linux SBC, applications based on OpenMotif are lighter by sever order of magnitude, and easy to develop.

So, why not? 

[Nominal Animal]

As far as I can tell, Motif/OpenMotif/lessTif on Linux is dead.

However, Athena 7 (libXaw7; Xorg home) and plain X Toolkit (libXt; Xorg home) are still very much used, just somewhat lower-level (very few widgets, must combine to make your own).  They tend to be part of base desktop Linux installs, still.

[DiTBho]

"Nirvana Edit" aka "nedit", and its fork "xnedit", are based on Motif.
But ... umm, they have "custom" widgets.

This is a problem for 90s and early 2000s Xterminals, because the source code is not clear in its intentions, and it seems it tries to "probe" for modern functionalities with tons of "polling requests" that saturate the Xterminal bandwidth, also because the Xterminal understands none of them.

Kind of ...

nedit: do you have Xrender?
Xterminal: What?
nedit: I said, do you have Xrender?
Xterminal: and I said, What?
nedit: I said, do you have Xrender?
Xterminal: What?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
nedit: I said, do you have Xrender?
Xterminal: What?
Xterminal: What?
Xterminal: What?
Xterminal: What?
Xterminal: What?
Xterminal: What?
Xterminal: What?
Xterminal: What?
Xterminal: What?
Xterminal: What?

timeout, connection reset

nedit: ummmm, after asking you this on loop for about 2000 times, I think that... maybe you don't support it.
nedit: Ok, next question ...
nedit: do you have XHM?
Xterminal: What?
....

All of this on a poor 10Mbps link

Crazy idea, in my opinion 


---

Anyway, I wrote a text editor based on Athena, but ... it seems limited.
For example, the "textarea" widget on Athena does not support multiple selections, while the Motif one does.

Anyway, Athena looks simpler.

[DiTBho]

I wrote a text editor from scratch for Motif, and one for Athena.

The Athena one is simple, but Athena does not have any file browsing widget (e.g. look ad "xedit", it's a good example), so I wrote a simple one myself.

I mean: with Athena, you have to write a lot of "basic" stuff (like the file broswer, or a text area with multi selection options) by youself.

[Nominal Animal]

I mean: with Athena, you have to write a lot of "basic" stuff (like the file broswer, or a text area with multi selection options) by youself.

Yes, exactly.

[SiliconWizard]

If you're looking for a lightweight alternative that can run on X11 (but also supports Wayland, OpenGL, Windows and macOS), and has a decent set of widgets, you can have a  look at FLTK:
https://www.fltk.org/

[DiTBho]

have a  look at FLTK

Code: [Select]

*  x11-libs/fltk
      Latest version available: 1.4.4-r1
      Latest version installed: [ Not Installed ]
      Size of files: 8268 KiB
      Homepage:      [url]https://www.fltk.org[/url]
      Description:   Fast Light GUI Toolkit
      License:       FLTK LGPL-2 MIT ZLIB

I don't know it, I've only heard about it as it's has a gentoo ebuild (which a few applications trigger when you emerge them), but it never surfaced nor have I ever written any applications with it.

Umm, it seems written in C++, which is a problem for me 

[DiTBho]

This is how my simple Motif-based text editor looks.
I hacked the file-browser widget callbacks and layout to have multi-filters.
It took me 60 hours to write the entire text editor:
+40 hours writing it using the default file browser
+20 hours figuring out how to implement multi-filters without rewriting the entire widget.

[DiTBho]

• body -> filter_set(*.c)
• head -> filter_set(*.h)
• incl -> filter_set(*.inc)
• text -> filter_set(*.txt)

[exe]

If performance is absolute objective, I'd try generating a library from scratch using AI and only functions that are relevant.
I'd also add round corners widgets...

[DiTBho]

If performance is absolute objective, I'd try generating a library from scratch using AI and only functions that are relevant.
I'd also add round corners widgets...

In my opinion, AI only produces GARBAGE, I don't use it.

[DiTBho]

If performance is absolute objective

Furthermore, performance itself isn't the issue: once started, nedit is fast and very responsive, even on a 40 MHz MIPS Xterminal from 1995.

The problem is that it takes a good 20 bloody seconds to start, during which time you can a frozen window because on the server side (a macmini) nedit stupidly sends thousands and thousands of polling requests to the poor Xterminal, on a 10 Mbps connection, just to "probe" what features it supports.

Analyzing what happens in the network link, between server and xterminal, I see an overload .... which is a bad by design 

Polling this way is bad, and, worse still, the code is difficult to understand or debug, which is exactly what AI produces: shoddy code, even worse than the original nedit source code!

If the nedit code prior to version 5 didn't even attempt polling, it must be said that everything prior to version 5.5 is written terribly! From "int" and "long" being written as if they were interchangeable (they are, only on 32bit machiens), pointers being cast without any care, .... with the result that if you try to compile on a 64-bit machine, what you get is a segmentation fault at startup.

That's a real pain, honestly, because working with its source is very frustrating.

Xnedit is significantly better written, but ... it's designed for modern things, so it doesn't even try to figure out if there aren't vector fonts on the other end but only bitmap fonts, and this makes everything, again, slow and frustrating, because to support vector fonts WHEN Xrender isn't available, you have to send hundreds of small images, which saturates the network bandwidth and keeps the xterminal CPU too busy.

After spending about 300 hours trying to understand/fix/debug/hack nedit, I got tired of it and wrote my own editor from scratch, without AI, because AI things just push you to "copy solutions like" nedit (I think that's how they ware trained).

In the end, my editor starts instantly, directly addresses fonts, supporting font zooming (buttons "+" and "-", in the above picture, are handled to specific callbacks, which directly map specific fonts), and all the features I need and use in nedit.

Which are very few.

And this proves, once again, that software design is considered "optional", while it should be "first priority, before implementing".

[SiliconWizard]

have a  look at FLTK

Code: [Select]

*  x11-libs/fltk
      Latest version available: 1.4.4-r1
      Latest version installed: [ Not Installed ]
      Size of files: 8268 KiB
      Homepage:      [url]https://www.fltk.org[/url]
      Description:   Fast Light GUI Toolkit
      License:       FLTK LGPL-2 MIT ZLIB

I don't know it, I've only heard about it as it's has a gentoo ebuild (which a few applications trigger when you emerge them), but it never surfaced nor have I ever written any applications with it.

Umm, it seems written in C++, which is a problem for me 

Yes, it's unfortunately C++.

[Nominal Animal]

In the end, my editor starts instantly, directly addresses fonts, supporting font zooming (buttons "+" and "-", in the above picture, are handled to specific callbacks, which directly map specific fonts), and all the features I need and use in nedit.

No color-based syntax highlighting?

It would be nice to reuse e.g. nano syntax highlighting rules (.nanorc, uses regular expressions for matching), as then you'd get tons of formats for "free".

[voltsandjolts]

Umm, it seems written in C++, which is a problem for me 

https://github.com/MoAlyousef/cfltk

[DiTBho]

Umm, it seems written in C++, which is a problem for me 

https://github.com/MoAlyousef/cfltk

wow, this is great! 

[DiTBho]

No color-based syntax highlighting?

Not yet.

Although things are much simpler with true-color (24-bit) hardware(1), pseudo-color (8-bit) is currently problematic for me, especially with pseudo-color hardware (2).

So, for portability, I don't support colors.

The Motif text area doesn't help here, it does not directly support multiple colors; "as is", without modification, you can set three elements: text color, background color, and text selection color, and since there is no color support, I would have to implement it myself, and that means dealing with the underlying theme layer: easy for TrueColor, but very complicated for psudocolor.

(This is why pseudocoloring was removed from GTK2 in 2012 and GTK3 never supported it.)

(1) e.g. NCD NC400, NC900 -> X terminals from the early 2000s
(2) e.g. Tektronix XP200, XP300, XP400 -> X terminals from the late 1990s

[DiTBho]

I also wrote a text editor in Java v1.1, which runs within the Netscape v4 browser on an NC900 xterminal.

In this case, Java (or rather, Java applet) should handle the colors, and the underlying hardware is "true color," and the operating system (NCDbridge v4, based on VxWorks + X11/R5) should handle the colors...

In theory, you have Java primitives that point to Motif primitives under the JavaVirtualMachine, so it should work ...  in practice, I haven't yet managed to do it cleanly.


Ummm 

[Nominal Animal]

The Motif text area doesn't help here, it does not directly support multiple colors; "as is", without modification, you can set three elements: text color, background color, and text selection color, and since there is no color support, I would have to implement it myself, and that means dealing with the underlying theme layer: easy for TrueColor, but very complicated for psudocolor.

Very true; I forgot that.

For an editor, it could be that at that point, dropping even libXt and going down to raw Xlib becomes easier.  That lets you treat the entire window contents similarly to SDL as a single "canvas", redrawing exposed contents using a single graphics context, filling backgrounds outside string areas XFillRectangle()/XFillRectangles() and rendering the text using XDrawImageString16() (which is similar to XDrawText16() except fills the background too).

I've done some raw Xlib and Xcb programming, and after you get the hang of it, for specific applications not requiring different types of widgets, they can be quite nice.  For an editor, I do believe the text rendering area itself is rather straightforward after you decide on the data structures — you may want to use linked lists or skip lists with both the canvas coordinates and size and metadata, and the single-color text hunk, for example —, but menu structures and any other widgets you might want can be more work to implement.  Thus, if you do experiment with this, I recommend you create a test case, a read-only viewer application, which does syntax highlighting, and splits each single-colored text hunk (also splitting at newlines and tabs) into a linked list item, with a skip list to the start of each new line (or perhaps a few lines) so you can find the first visible line faster without traversing through the data.

Note that this "raw" approach (relying only on libX11 or libXcb, whichever you prefer) is very similar to SDL, in that it forgoes "widgets" completely, and uses the displayed window as a canvas you draw onto as needed.  It is jarringly different to widget toolkits, yes; but still, quite usable in its own different way.  It does mean any styling processing you do need to do yourself (as they simply change the graphics context attributes when rendering the relevant text).

[Canis Dirus Leidy]

As far as I can tell, Motif/OpenMotif/lessTif on Linux is dead.

Not exactly. pcb-rnd still supports lesstif GUI, which (at least in Debian) is actually motif.

[ejeffrey]

*-Motif was never really popular on Linux due to it's initially commercial nature.  It was very popular for software (including shareware/freeware) targeting commercial UNIX systems since users were likely to already have a motif license, but in the Linux world that was much less common.  It was also used statically linked in commercial binary only software like Netscape and Staroffice for linux, but few people developing for Linux did that.  Lesstif was an option for running existing Motif software, but it wasn't fully compatible and I doubt many people at all developed specifically for lesstif.  By the time OpenMotif came along GTK and QT were already well established, and by the time Motif was actually open sourced it was long dead.