Simon McVittie <smcv@debian.org> (2021-05-17): > My biggest concern about cdebconf and GTK 3 is that it's relying on the > ability to call into GTK APIs from more than one thread. GTK 2 tried to > support this pattern, with gdk_threads_enter() and gdk_threads_leave() > providing locking, but it turned out not to be a good idea. GTK 3 > deprecates and strongly discourages these, and says: > > All GDK and GTK+ calls should be made from the main thread > > I think the good way to do it would be to have a debconf thread that > speaks the debconf protocol (which requires blocking in some places), > have a GTK thread that runs the GTK/X11 event loop (which requires not > blocking for extended periods), and pass messages between them with GLib's > GMainContext mechanism, which lets you schedule a function to be called > "a bit later" in the other thread. The GTK thread would run the default > GMainContext (as in g_main_context_default()), and behave like the main > thread from GTK's point of view. The debconf thread would *actually* > be the main thread, but have its own separate GMainContext, which it would > iterate when it's waiting for the GTK thread to do something. I'm familiar > with this model from writing non-GUI event-driven code using GLib. > > Philip Withnall wrote a really good introduction to GMainContext which > is now part of the GLib API reference: > https://developer.gnome.org/programming-guidelines/unstable/main-contexts.html.en > > The GTK 3 frontend for reportbug uses this model - reportbug is in the > same position as cdebconf, with an externally-imposed programming model > based on calling functions that must block until they have an answer, > but simultaneously needing to run a GUI that must not block. > > I spent a bit of time trying to annotate which cdebconf-gtk functions > are called from which thread, and I don't think it would be impossible to > disentangle. Ideally, for each function and 95% of the variables/struct > members, it should be obvious whether the function is called/the variable > is accessed from the debconf thread (only!) or from the GTK thread > (only!). This avoids needing explicit locking/mutexes/condvars/atomics > most of the time; the thread-safe operations are implicit in the > message-passing between one GMainContext and the other. > > Obviously this would require a lot of refactoring, which should be done > at the beginning, not the end, of a release cycle - but I don't think a > high-quality port to GTK 3 is going to be feasible as something that is > worked on during hard freeze anyway. Thanks for the details. Looks like a fun task for a few months from now! Given proper documentation (see introduction/guideline above), plus the directions you've already given us, that doesn't look like something that cannot be done. Looking under src/modules/frontend/gtk in cdebconf, it looks like < 8k lines total, sloccount'd at 3k. > I also think the beginning of Debian 12 would be a good time to > reconsider whether the graphical d-i mode is really the best way for > non-expert users to install Debian. The restricted capabilities of > udebs make d-i quite a "one hand tied behind your back" environment, > which was still a necessary evil a few years ago; but now that systems > with 512M RAM are literally given away with a magazine, perhaps that's > becoming less necessary than it once was? Maybe. Until now, I've been happy with maintaining (or at least trying to maintain) the status quo, which means an installer that works both in text and graphical modes, which can be preseed “as usual”, etc. It's definitely not getting many extra fancy features, but it seems to me it's been working rather reliably for a number of users, so… Of course it comes with a price regarding debuggability and you're unfortunately the one paying here, and I'm sorry for that. > For embedded and server uses, which have the tightest RAM restrictions, > or for many of the use-cases of preseeding, perhaps imaging the system > from a preprepared disk image is a better route? We have official cloud > images, and lots of ways to make your own, all of which start from > debootstrap or equivalent. The traditional TUI flavour of d-i also > seems good for this use: it's perhaps less crucial to have full support > for non-Latin character sets in an environment where your interactions > with the installed system will have more in common with 1980s Unix than > any particular natural language. > > For desktop- and laptop-class systems, I think Calamares from > a live-system environment has a lot of potential, perhaps combined with > gnome-initial-setup or a non-GNOME equivalent to do "first-run" setup > on the installed system. This is probably the place where a graphical > installer with many languages and a familiar UX is most important. I might be wrong, but I was under the impression the current status of live images wasn't exactly great… See [1] for example, towards the end. 1. https://lists.debian.org/debian-live/2021/04/msg00013.html If people want to propose alternative installers, and propose different choices on the website etc., I'm of course fine with that. I don't recall such a hard-to-fix regression similar to the Pango relayout thing (not saying I haven't put many hours into d-i, but that one feels *harder* than usual)… and I wouldn't mind trying to adjust the graphical version so that it stays as an option alongside the text version post Bullseye. > We're probably not ready for what EndlessOS does - their installer is > basically dd with a progress bar, and *all* customization is done > after rebooting into the installed system - but it's worth considering > how close we could get. The big advantages of doing that (and the > reasons why this is how phones and OEM installations of Windows/macOS > work) are that it's trivial to replicate the un-customized > installation across any number of machines either for yourself or to > be handed to others, and that all the GUI widgets, fonts, input > behaviours, design language etc. are automatically the same as in the > installed system, because it literally *is* the installed system. Again, I'm happy if others want to explore that and build an alternative (maybe default) installer that leans towards that; but I won't be the one leading such an effort. Again, that doesn't mean I want to prevent others from explore or maintaining alternatives! > > The installer seems to be working somewhat. I'm seeing strange > > things regarding layout, regarding widget expansion (basically we > > have some wasted vertical space). […] > > I'm also seeing a different behaviour regarding the expose (GTK 2) > > vs. draw (GTK 3) event handling, meaning the banner doesn't get > > repainted automatically […] Thanks again for your very detailed answers, that's definitely much appreciated. Cheers, -- Cyril Brulebois (kibi@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
Attachment:
signature.asc
Description: PGP signature