Mailing list archives : pcb-rnd

Date:Thu, 9 Jul 2020 10:53:48 +0200 (CEST)
Subject:[pcb-rnd] librnd separation: lesstif and long term plans on X + UNIX
replies: 4255 from
Hi all,
if you are not using motif/lesstif and you are generally not interested in 
getting rid of huge software stacks like gtk, you can safely skip this 
mail from point 2.
1. what's new on librnd
I've just finished the next step of librnd separation. Librnd is in a 
separate svn repository now, but other than the one-time extra steps (see 
previous mail) on the first svn up, you shouldn't notice any change on 
2. what's new on the lesstif hid
However, there are a lot of new things in the lesstif hid. First, I had to 
remove all pcb-rnd related parts of the code because librnd is independet 
of pcb-rnd. This includes removing any custom, hid-specific dialog boxes, 
like the old library dialog or the old attribute editor dialog.
The lesstif HID was always lagging behind the gtk HID on dialog boxes and 
most lesstif HID users did most operations by hand, using the CLI. The CLI 
ways didn't change. But instead of the custom dialog boxes, the lesstif 
HID now delivers all the same, centrally implemented dialog boxes that the 
gtk HID displays too.
This does include the "docked subdialogs" of the top window: the layer 
selector and the route style editor on the left, the toolbar and the 
readouts on the top. So the lesstif HID looks pretty much the same as the 
gtk HID now. This was the goal for a long time: all HIDs should have the 
same structure and present the same dialogs, the difference should be not 
how the GUI is structured but what stack we depend on for drawing the same 
Like the same dialogs, we have the same features on lesstif now: if you 
find too much screen space wasted on the top window docked subdialogs, 
just switch into the full screen mode (press the '\' key on US layout or 
use the fullscreen action).
3. known GUI bugs
Unfortunately motif is not very cooperative... The deeper I dig into it, 
the more it seems it's not really designed properly, for generic 
extensibility. I've sort of fixed up the major fillbox bugs so most 
dialogs will resize almost properly. However there are a few known bugs 
that I spent hours on and then decided to postpone them:
- we still don't have paned view so some dialogs will not allocate 
subsections properly and you won't be able to use a slide to change the 
- especially when a dialog has a tree/table view, it generally won't grow 
with the dialog
- there are tons of bugs in the tree/table widget implementation 
Please report such bugs only if you can allocate time on sitting down, 
debugging and fixing the bug, else I will either say "it's a known bug, be 
patient" or "won't fix", see below, in point 5.
4. motif/lesstif for ringdove!
Since the lesstif HID is now part of the hidlib, it means all other 
ringdove apps get it for free. I've tested it with camv-rnd and it sort of 
works. There are a few GUI handling bug in camv-rnd that got exposed with 
the second GUI HID. Once I get the time to fix those, we basically have a 
gerber/drill-file/etc. viewer that can be used without gtk, e.g. on small 
or old systems.
5. long term plan on motif/lesstif
After many many hours of hacking, I have to admit that motif is not 
something we want to rely on long term. It's very limited and inflexible, 
which would be kind of okay if it was very small and simple in return. But 
if you look at the internals and try to implement your own widgets, it 
turns out the API is really huge and overcomplicated. The implementation 
is still smaller than gtk, but almost as much complicated, just in a 
different way. I don't think it is really worth supporting motif on the 
long run, it's just a constant struggle and there's no much chance to 
recruit developers for it.
However, my strategy of supporting older UNIX systems, small systems, or 
just non-GNU systems where gtk is a real PITA, remains. Which means I have 
a plan for an alternative that will replace hid_lesstif some time in the 
far future. Until that we'll probably go on using hid_lesstif with a few 
known bugs.
The plan for the alternative goes like this: I started to write a very 
small and simple toolkit, using sdl. It's called miniboxtk. I will 
probably extend it so it can talk to either sdl or xlib directly. Once it 
speaks xlib, it will basically compile anywhere where you'd have motif. 
When this all start to work, it's just yet another hid, so it just works 
automatically for pcb-rnd, camv-rnd, sch-rnd without having to do anything 
extra in these apps. At that point I will remove hid_lesstif.
In a way this only means that instead of investin dozens of more 
hours fighting motif, I rather invest that time in finishing miniboxtk. At 
the end we will have a smaller, simpler, more flexible solution. The only 
loss is that within an environment where all your other apps are based on 
motif, pcb-rnd will look a bit different with miniboxtk.
Best regards,

Reply subtree:
4254 [pcb-rnd] librnd separation: lesstif and long term plans on X + UNIX from
  4255 Re: [pcb-rnd] librnd separation: lesstif and long term plans on X + UNIX from