| ID: | 2767 |
| From: | ge...@igor2.repo.hu |
| Date: | Thu, 14 Mar 2019 19:50:12 +0100 (CET) |
| Subject: | [pcb-rnd] GUI state update |
Hi all, 1. short update on the current GUI revamp state These days I am working on the new "spinbox entry widget". This is the widget that is used for numeric input on the GUI, including coord input. We currently have a gtk-only implementation that costs a lot of code and only partially doing what we need and absolutely no lesstif implementation. The new code is centralized, implemented in DAD; it will provide all we need, including proper unit setting, in all present and future HIDs. On the lesstif side, Bogdan is working on fixing the last few tree-table widget bugs. Once that's done, basically all new dialogs will automatically work on lesstif. After that, we have only a few dialogs left to rewrite in DAD (effort starting from the next development cycle): - the attributes dialog: will be removed in favor of the property editor that also edits attributes already - the library dialog: a new, DAD based dialog with very similar look and operation to the current gtk library window will replace the per HID implementations, once lesstif tree-table works - route style edit dialog: a new, DAD based dialog with slightly different functionality will replace the per HID implementations; the main change will be selecting a padstack prototype for via instead of diameter specification (this is how you will be able to choose exposed vs. tented or non-round-copper or different mounting hole padstacks). - the advanced search dialog: a new, DAD based dialog will replace the gtk-only implementation; because of the any-hid nature, it will need to have a different setup with the expressions than the current one has And yes, that's it, those 4 dialogs all that are left in per-HID domain by now! We started from a lot - we had 19 gtk-specific dialog implementations in version 1.2.6 back in late 2017. More info on why we are doing this: http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=hid_policy 2. mid term: main window upgrade plans We already have sub-dialogs in DAD. For example in the file selection code, that's how a the format combo box is injected by the caller. It's the same DAD API, but instead of creating a full dialog box in its own window, the caller creates only a small section (format selection) of a bigger dialog box (the file selector dialog, that is managed by some other code). The code for the sub-dialogs is suprisingly small. Now that we have this, I will start rewriting parts of the main window too: - the layer selector - the route style selector - the toolbar - the status printout Currently only the gtk hid has these, and they are all implemented in a gtk-specific way. After the rewrite they will be just DAD sub-dialogs provided by common code. And they will appear in the lesstif HID too. Don't worry, we have the full screen mode that hides all such widgets (you can test it in the gtk HID, it makes the gtk HID look like the lesstif HID, just one large drawing area, rather useful on small screen). Once this is done, it will be easier to maintain, fix, extend these parts of the UI plus this will drastically simplify implementation of new HIDs. 3. long term goals on the GUI And once we have our main window built up from sub-dialogs already, we pretty much have docking too: grabbing a subdialog and moving it out to a separate window, or grabbing the content of a separate window and stuffing it in a subdialog is not too complicated. And this reparenting is the only code that needs to be written. The best part is that docking will work with all GUI HIDs, and will work the same way in all HIDs. More on this and point 2: http://repo.hu/cgi-bin/pool.cgi?cmd=show&node=hid_topwin 4. HID plan: gtk, lesstif, sdl A major problem with the gtk lib is that it is huge and is changing a lot, in ways we don't really need. For a project like pcb-rnd, keeping up with new versions of gtk is rather expensive. We spend a year or more to be compatible with a new version (e.g. gtk3), but then in 5..8 years we have to start over (e.g. for gtk4). Not because we need any of the new features the newer gtk version offers, only because of the "trends" or because of the fear of the older version getting no support from distributions. In return: gtk is huge, slow, requires glib and C99 and is not easy to port. For example technically speaking gtk cross compilation breakage is the only reason we don't have a working windows port - of course our target audience is not on windows, so there's no much motivation either, but last time I cross compiled pcb-rnd, only gtk broke. TL;DR: I think gtk is generally an unsustainable technology. Up to this point, we were experimenting with gtk3. But in practice it didn't result in production quality HID and because of the above theoretical reasons plus that I do not want to loose too much time on features of minor importance (GUI eye candy), I finally made the following decisions today: - we keep maintaining the lesstif and gtk2 HIDs, idenepdently of whether/when popular linux distros stop supporting gtk2 and motif, to make sure pcb-rnd works on old systems - we keep gtk3+cairo HID as an experimental plugin, but it will not be officially advertised. It will not get configured automatically, it will not be listed in the documentation and we will recommend against using it. As long as it gets enough maintenance it will be possible to use it when explicitly configured. The main problem with gtk3+cairo is rendering speed, and that most probably won't improve (cairo is just too much overhead). - I finally pronounced the gtk3+gl effort dead, I will remove that plugin soon. It doesn't work, so don't worry, we are not losing features The policy on how we would proceed from here: - once I finish the HID API cleanup (see point 1..3 above), our HID API will be much simpler and implementing a new HID will become a much smaller task than ever before. In fact it is reduced to: a generic menu system engine (filled in by core), rendering (driven by core), input (pass over to core), DAD dialogs and nothing else. This means we can think about implementing new HIDs more easily. - I will definitely implement an SDL based HID. I wanted to do that since about 2010. I used SDL in a few projects already; compared to gtk it's very small, very fast, and very portable. Looking at the project history, it's also very stable: libsdl1.2, first released late 1990's, is still accessible in major Linux distributions. Which suggests if we write sdl2 code today, that has a good chance to run in 2035 without a rewrite for sdl3. - we are considering implementing other HIDs too, more on this later, when we get those project started - if a newer gtk version is very important for someone, he will need to volunteer to write a gtk4+gl HID. This requires serious dedication: the candidate really needs to be able to spend at least 8 hours a week on this and fully accept pcb-rnd's HID policy (which does include that we are not writing a GNOME application but just one more HID to a modular multi-HID pcb-rnd). I said gtk4 because I don't see the point in investing much time in a new gtk3 effort if then we will need to redo it for gtk4 a few years later. I said gl, because cairo already proved to be too slow (even on the scale of software renderings) and gtk versions from 3 don't seem to provide a simpler sw render, even a single pixel is drawn through cairo. - ... but I don't mind if a gtk4 HID (or gtk5 or gtkN HID) won't happen at all - I believe long term we should settle with more sustainable alternatives. - qt: not possible, as we won't support a C++-only lib - athena widgets, tk, fltk, native win32 and other toolkits: similar rules as for gtk4: if there is a developer with considerable dedication we can go for it. Please request them only if you have the time to code them. Regards, Igor2
Reply subtree:
2767 [pcb-rnd] GUI state update from ge...@igor2.repo.hu