| ID: | 5846 |
| From: | rn...@igor2.repo.hu |
| Date: | Fri, 9 Sep 2022 08:52:04 +0200 (CEST) |
| Subject: | [pcb-rnd] project state update + nlnet and miniboxtk news |
Hi all, A quick project state update and roadmap. 1. Present I've just finished the sch-rnd scripting examples, which also completed the last milestone of the nlnet sponsored "initial sch-rnd implementation" project that was scheduled from February to end of October. We've reached our original goals: - we have a working sch-rnd in beta testing - it is capable of producing netlists for pcb-rnd in a multi-sheet flat project - pluse we have some more, some extras, beyond the original plan for the initial rush (e.g. project support, mostly working io_geda and io_tinycad) Sch-rnd already offers a lot of essential extra features over geda/gschem and lepton: - explicit abstract model with GUI access - it really understands nets, which makes full featured back annotation possible - portmap and devmap; the transistor problem is finally solved without a per user custom hack - it can load schematics from alien formats But there's still a long way to go. For now, to let sch-rnd become stable, I'm mainly doing bugfixes and try to resist adding new features (except for some remote parts of the code, like alien file format support that won't affect code involved in dialy use). The plan is that concentrating on the bugfixes during the beta test phase we can ensure sch-rnd 1.0.0 would be really stable. I expect 1.0.0 to be released next spring. The exact timing depends on how much testing and bugreports the code gets. Until that we will have a series of beta test releases, 0.9.x. 2. Near future: miniboxtk As predicted on my last roadmap, my current main focus is miniboxtk, a GUI toolkit library. Miniboxtk is on the same level in the software stack as gtk or qt are. But miniboxtk tries to be small and simple, so it doesn't depend on glib or C++ and doesn't force its own build system on your application. Miniboxtk has a backend system, so it's not sdl2-only anymore, but can use different backends. There are multiple backends: - sdl2 (which itself has more than 22 backends so it shoudl run on pretty much anything) - glfw (runs on Linux, MacOSX and Windows, maybe on modern BSDs too and is a thin wrapper around opengl) - xlib (runs on anything with X11; this will allow us to target old UNIX systems, replacing hid_lesstif in librnd later on) The initial implementation of miniboxtk backend system and widget infra is sponsored by nlnet in September and October. Thanks to nlnet for the renewed support! The reason I decided to push hard on miniboxtk now: if I have a working prototype I can start writing a librnd HID using it, which would allow me to test the librnd HID API with one more toolkit. This may expose bugs and suboptimal API design. If this all happens before librnd 4.0.0, I can include these fixes in 4.0.0, so we won't need another big switchover, to 5.0.0 too soon. 3. Upcoming librnd 4.0.0 (nov-jan) From mid november I will switch my focus to librnd 4.0.0. This is a huge switchover that affects almost all ringdove apps. This means I will have to pause feature development and bugfixes in pcb-rnd, sch-rnd and camv-rnd. There will be a new release of the apps before the freeze for librnd 4.0.0. If everything goes right, librnd 4.0.0 would be released early next year (probably in January) then all other Ringdove apps would get a new release too, which would depend on librnd 4. The major version change means incompatible API, so pre-librnd-4 apps will require librnd3 and new versions will require librnd4. 4. long term plans (next year) Next spring, depending on the bugreports and fixes, sch-rnd 1.0.0 would be released. By then we'd also have librnd 4.0.0. This means a long period of development is closed: the period that introduced another core Ringdove application, sch-rnd, and cleaned up librnd APIs for it. After this period, there will be a few options to proceed, a few big, long planned tasks: - a set of librnd HIDs for miniboxtk, so that we won't need to rely on gtk long term - the polygon lib rewrite, so that self intersecting polygons become valid and maybe support for arcs in polygon contour - rubber band stretch based routing option in pcb-rnd (which is my idea for a reliable push & shove) I will decide about priorities later. Best regards, Igor2
Reply subtree:
5846 [pcb-rnd] project state update + nlnet and miniboxtk news from rn...@igor2.repo.hu