| ID: | 4254 |
| From: | ge...@igor2.repo.hu |
| 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 ka...@aspodata.se |
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 pcb-rnd. 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 things. 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 allocation - 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, Igor2
Reply subtree:
4254 [pcb-rnd] librnd separation: lesstif and long term plans on X + UNIX from ge...@igor2.repo.hu
4255 Re: [pcb-rnd] librnd separation: lesstif and long term plans on X + UNIX from ka...@aspodata.se