I understand the spirit, but something is needed to reconcile these last two paragraphs: a "complete overhaul" isn't feasible, but no functionality should be lost. What will that mean in practice? A remaining compatibility layer, much like what is there now, for most of the dialogs? Maybe that could work, but at a minimum you'll probably have to rewire everything in the UI to use GTK3 style events, which is still a large undertaking.

I mean it would be some hybrid application, where the e.g. "Font Info" dialog could be shiny new, but when clicking "Add Lookup" button, the old GDraw subdialog would pop up.

Thankfully, a huge work was done on GDK which basically allows us to mix toolkits and events nearly seamlessly.

To be fair, in a lot of cases functionality is likely to be gained rather than lost in a fair few areas.

Some existing dialogue crash too often to be reliable, some technically should be rendering UI elements which they simply aren't, some functionality is awkwardly split across multiple dialogs and buried in unintuitive usage, etc.

For example, I have been prototyping combining the two 'Groups' dialogs into a unified interface (albeit in a separate repo not actually hooked into the actual program at all for now). The existing UI is prone to seg faults when encountering empty groups, it has no capacity to rearrange created groups, it gets itself into a 'race' between the user and an error popup on invalid input, and the code for actually keeping track of the list of groups is broken and loses track of itself if you delete a group rendering it dangerous to attempt to continue using until it reloads.

All of these issues, along with e.g. merging the create/edit dialog with that for actual filtering, separating out categorisation of glyphs by name or code point, improving the management and display of group contents, potentially managing (save/load) different group sets, allowing the dialog to maintain itself 'always on top', etc. are relatively easily addressed, imo massively improving that function of the program.

(Integrating into the labyrinth of undocumented structs and functions that store and work with the group data is somewhat more of a headache, of course, and something of another Titan that IMO ultimately needs slaying for Fontforge to become a truly maintainable piece of software.)

There's absolutely enormous scope for UI improvements if and when the main font view can be smoothly liberated from the old UI codebase, not to mention the stepping-off point this will provide for anyone wanting to try and contribute code, so this is very promising!

Haven't really had the time to do much tinkering or spelunking into the codebase lately unfortunately, but I hopefully will be able to have a good look at this progress after some January university work is out of the way.

My reference for the level of the conservatism of the project is #3638 .

@davelab6 (who is himself a FontForge board member) had worked with others to come up with a much more rational menu layout. I saw a partial PR for the changes in 2019 and finished the implementation. It turned out that the idea had been rejected in an email (not noted in the PR) because some existing users might not like the change. It was felt that until the menu layout was made fully configurable, so that users could choose between the old and new options, it shouldn't be accepted. I was pissed! But that was life.

At this particular moment, limiting the future of FontForge by tying it to some particular toolkit seems purely theoretical. Any future is better than zero commits in a year.

I agree that the hybrid approach effectively kills the consistency, theme customization and all the stuff around it. My opinion is that theme customization should have never been a concern at the first place. FontForge is a program for fonts, and it's functionality isn't affected by color of menu background. George Williams chose to write his own toolkit because he needed Unicode support, and back in 2000 no standard toolkit had any reasonable support for it.

On the other hand, the board has the last word, that's their right.

To add my own comments to what @iorsh has said here;

FontForge is already tied to a particular toolkit. The issue is that the toolkit it is tied to is bespoke and was written by, as far as I can tell, someone who does not now and has no future intention of ever again maintaining it. It is old. It is buggy (to the point it seg faults and crashes the whole program sometimes, doesn't display controls it is seemingly supposed to, etc.). I'm not sure there is anyone who knows how it works or what it is doing all the time. It is not commented or documented. It can only be used via a very low-level API, which adds to an already very verbose and Byzantine codebase.

IMHO any talk of consistency and theming is, frankly, laughable in the face of these more pressing concerns.

As the only serious contender as a font editor in the open source ecosystem, the current issues with the GUI code (as part of general issues with the aging of the codebase) are (or should be) a real concern to all who hold firm beliefs in the promise and importance of open source software.

The only options when it comes to making sure there continues to be a serious option for creating and editing fonts using open source software long into the future are to either create a new program from scratch written in modern and maintainable code (some have tried, and I'm sure you can find many aborted attempts around the internet), to fork it entirely independent of the main project (similar issues exist here; my own spare-time tinkerings which I can only very infrequently make time for time for are probably a good example of how that goes without a concerted effort), or to make serious attempts to modernise the existing codebase with a view to future maintainability.

The powers that be obviously have final say on what is or isn't merged into the mainline codebase, and it is quite right that this excludes any attempts at large scale changes like this which do not manage to gain the momentum to reach completion. Adding inconsistency and unfinished changes to a venerable codebase like this is the last thing it needs.

On the flipside, a serious effort to replace the entire GUI codebase with something that new developers stand a chance of contributing to, maintained and worked on as an aside to the mainline codebase (ideally as a branch of the main repo rather than any other random developers fork, though that is a whole separate discussion), is something that FontForge is ultimately going to need sooner or later.

The following worked for me (already in build, reconstructing from history, hopefully works) :

git remote add jtanx https://github.com/jtanx/fontforge
git fetch https://github.com/jtanx/fontforge
git checkout qt
sudo apt install qt6-base-dev
cmake -GNinja .. ; ninja

Cheers, I'll try doing exactly that when I'm next at my laptop.

My attempts to build on an arch-based box, after just temporarily installing the full qt6 metapackage (absolutely no idea what would or wouldn't be required specifically) result in a series of errors of the form:
/[..]/fontforge/po/fr.po:294: 'msgstr' is not a valid C format string, unlike 'msgid'. Reason: In the directive number 3, the argument size specifier is invalid.
...which ultimately ends in a failed build. This seems to be translations or somesuch, however, so perhaps there is a more minimal build I should attempt?

You'll either need to rebase or copy the po files from a more recent commit. This problem was fixed in #5330 and has to do with the pickiness of more recent toolchains.

I've rebased the qt branch to master fwiw

No issues at all building it on my box now.

This sounds reasonable to me, with a couple of comments.

1. It would be better to have this plan explicitly pre-vetted with the powers that be. The general idea and the technical direction seem to be clear as of now, and it would be counterproductive to proceed with bugfixes etc, if there is no consensus on the project substance.
2. After the initial release there should an agreed bug-free window of predetermined duration (with bux-fix releases if necessary), after which further transition to pure Qt will be acceptable.
3. I prefer to put the pure-Qt window in the release, active by default, with a preference (maybe config-only, without UI) to disable it in favor of the GDraw-based one. This would allow wider testing of pure-Qt path too, with a contingency plan in case of some major problem with that specific window. Does this sound ok?

It would be better to have this plan explicitly pre-vetted with the powers that be.

I don't disagree with this but that doesn't mean it will happen. It hasn't tended to happen in the past. There are some valid reasons for this and perhaps some not-so-great reasons.

Seems like this might be apples and oranges. In open source land "supported" means something like "will (probably) run". In the commercial software world it means "can pay the company to fix problems and get help". That first page above says "Supported platforms are actively maintained, subjected to testing, and bugs discovered in these platforms are prioritized for correction. Significant errors discovered in testing can impact release dates.", implying that there are other platforms it runs on.

Found some other info....
QT6.6 = poppler and qca2 appears to be having some relatively good success. That's a good sign.

I was reminded of this thread while just now reading https://betanews.com/2024/01/16/betterbird-the-email-client-thunderbird-could-have-been/ - the bit about profiles is intriguing. Perhaps fontforge with gdraw could be released as fontforge classic, and the qt version could be set up to run alongside it. That might free up the new effort so users who depend on classic features always have them

Adopting a new UI toolkit is a major change (perhaps one of the biggest ever), and I believe it's worth planning, followed by clear decisions by the people who have the authority to take such decisions. As part of this planning, the stakeholders can review the features which have the biggest chance to get broken by the change, consider the risks and the mitigation actions. Such actions can range between dropping the feature and keeping it and prototyping it in the new environment to reduce risks, as deemed appropriate.

Of course, anything on the scale between deep review and no review can be done, as long as decisions are made.

Honestly, I just took whatever @Omnikron13 started and continued from there. From my limited experience with documentation, GTK4 is richer, but sometimes more complicated. Besides that, there seem to be more code examples for GTK3, and it helps when copy-pasting stuff.

I already mentioned it above, gtk has pretty terrible cross platform support and it's only gotten worse in gtk4. There have been numerous times I have had to investigate quite deeply into the gdk/gtk source itself to figure out why it's been (mis)behaving.

They also deprecated a bunch of APIs with seemingly no viable replacement. It works ok enough as long as you stick to Linux and the gtk ecosystem, but as soon as you step outside of that you're in for a world of hurt

Why not port FontForge interface to GTK4 instead of GTK3? I don't have experience with GTK.

It has been some time since I first tinkered about with the notion, but in short, as I recall, because the Gdk version that FF will build on is quite specific and old and there's no chance of getting GTK4 to play nice with it.

Now, the alternative could be to dig into the guts of the UI and port it to some suitable version of Gdk. This, imo, would be quite a pain. Iirc there's quite a few bits of Gdraw you'd have to muck about with.

The problem there is that the codebase for Gdraw is not really commented or documented, and you will likely spend quite some time bouncing from file to data structure to file to data structure (none of which likely to be commented or formatted). The codebase and documentation for Gdk is marginally better, but in all honestly largely expected to be used via GTK, and so working out what you need to replace with what to port a (20 year old?) 3rd party minimalist UI toolkit (whose original author I think stopped working on the project some 10 years ago?) doesn't strike me a a very fun or productive pet project.

Possible, I'd expect? Worthwhile? It seems doubtful to me.

GTK3 however is basically already pulled in with the version of Gdk that FF can build on. A little, admittedly hacky, tinkering and you can have GTK3 components playing reasonably nicely alongside Gdraw ones, sharing an underlying Glib event loop.

Horribly broken and clunky to use UI dialogs can be, with a little more hacking about, replaced with GTK3 ones which are less buggy, much less likely to randomly segfault, provide better and less awkward (working) functionality, and be infinitely more maintainable given the number of people familiar with GTK Vs Gdraw.

it seems that GTK4 would be more future-proof and have more features because it is newer.

The lifecycle of GTK is, to put it bluntly, kinda screwy. The 'latest' major version is, as I'm lead to believe, considering by the Devs themselves to be considered unstable for some considerable time (I forget what versions they actually recommend it be considered stable). The upshot is that hanging back a while is generally for the best outside new projects. With talk of work on GTK5, I'd say we're past that sticking point tbh.

However, as I say it is likely much easier to replace components piece by piece while still having a fully functional piece of software, even if it is something of a ship of Theseus.

If and when the UI were to be fully onboard with GTK3, then porting up to GTK4 would likely be much less of a headache.

To those who tried to run this on Windows and unsurprisingly failed, please pick the fixed version at https://github.com/iorsh/fontforge/actions/runs/10801650837 (scroll to artifacts, I tested MINGW64). The branch should also compile fine in MSYS2.

Personally I still think going down gtk3 is a dead end/waste of time, but I'm also not working on this ATM so 🤷

Cause of the ancient codebase or just it's not worth the effort?

I'm doing my best to localize the GTK UI code as much as possible, so that if the impending doom arrives, the catastrophe would be less catastrophic. Meanwhile @skef made the code much more C++-friendly in #5750, and a lot of my effort goes into disentangling UI toolkit in a neutral manner.

Wow, that's a lot of work done, I am quite speechless, thank you.

It was mostly Claude, when it comes down to it.