Replies: 15 comments 38 replies
-
@skef, I agree with your points. The links above are just some initial attempts to check the feasibility of the entire endeavor. @Omnikron13 introduced GTK File Chooser, and I expanded it to better match the functionality of the current GDraw chooser. In a separate effort I'm trying to convert the Font View to GTK (see https://github.com/iorsh/fontforge/tree/font_view). It's a very raw draft, but I could figure out the custom drawing of the character grid into a GTK widget,which seems to be one of the tougher pieces. My idea is to have all the main views ported (Font, Character, Bitmap, Metrics) together with File Chooser and maybe some more stuff. I don't think the complete overhaul is feasible at all, it's just a really huge pile of UI. The above list though can qualify IMO for a Beta status. One of (my personal) guidelines is losing NO functionality in the process. Nothing pisses people off more than stuff given to them and then taken away. |
Beta Was this translation helpful? Give feedback.
-
As of now, the Font View is bug-ridden (for example, the pop-up menu works fine, but the top menubar is still not operational). But the screenshot gives some impression of the overall direction. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
It would be good to reach some sort of consensus on this approach before we invest more work. For me, the main advantage here is that things can be done one piece at a time, instead of the all-or-nothing attempts which proved to be too laborious more than once. But there are probably other considerations which I may be not aware of. @skef, what do you think about this? Maybe we shall also seek some initial feedback from other contributors? |
Beta Was this translation helpful? Give feedback.
-
This has been my reasoning as well. Approaching it as something of a 'Ship of Theseus' means that solid, usable improvements (to both functionality and stability) can be made relatively quickly and painlessly, and even if that starts with nibbling at the edges with bringing improvements to minor dialogs it does actually result in small real benefits to user experience and even some small bonuses to the overall codebase maintainability as not only the old arcane UI code gets stripped out but some of the periphery code around them becomes a lot more accessible to tidy up.
Attempting to identify which areas are the least entangled into the codebase as good targets for relatively drop-in replacement is unfortunately something that seems pretty high on the priority list. I've done bits of digging about, though not much documenting of what I've found ultimately as it gets something of a labyrinth of chasing function calls and large mysterious structs about. Colour picking is certainly one worth untangled, as colours are currently handled rather... strangely, but i don't believe they are too widespread. Breaking up and documenting some of the mammoth functions in general would make things a lot easier for others to contribute too, to be honest. (As an example, the whole process of the program starting up, and reading command line arguments, etc. is paradoxically both composed of enormous dense functions, and tiny utility functions of a couple of lines in completely different files that seem to be called from just one or two places in the whole codebase. Dropping in a more standard solution for the arguments, integrating the tiny functions, commenting and a little refactoring, etc. would leave a much more streamlined entry point for anyone daring to try to get their bearings on the codebase.) Documenting/commenting the various data structures is unfortunately perhaps another area that would make actually working on the UI a hell of a lot easier and more palatable. Anyone attempting to make any real modifications to anything is very quickly going to find themselves bogged down trying to work out what data is where and what it is doing, which is just replicated wasted time for each person really at present. The trouble there is they are rather arcane, so it's a case of either somebody already properly familiar with them doing it, or a hell of a lot of meticulous work spelunking around mapping them out. |
Beta Was this translation helpful? Give feedback.
-
|
There are a lot of dimensions to these questions. The main medium-term UI/widget issue is the current dependence on a particular version of GDK, where newer versions of GDK work differently and the current one doesn't work with Wayland. @jtanx had much of a GTK port working but became frustrated with aspects of their model. I believe that is https://github.com/jtanx/fontforge/tree/gtk-works2 . He then switched to qt had felt he had better luck, but I don't think that work isn't finished either: https://github.com/jtanx/fontforge/tree/qt . Note that when I say "port" in this sense, I mean what @jtanx already did with GDK: Getting custom FontForge widgets to, in effect, work on top of some other "portable" graphics layer. Porting this or that window to "full GTK" without the others doesn't resolve that question. As for an incremental approach, a few years ago I suggested adding some code to allow "full GTK" windows to coexist with gdraw windows so that new additions to the UI, which might include plugins, could just use GTK. I did a proof-of-concept in https://github.com/skef/fontforge/tree/gtk-bridge . That idea was rejected, and at least one reason for the rejection was that it would tie the project to GTK and there was some preference for leaving that question open. (@jtanx already had reservations at that point.) Let's set that aside. In my personal view the main "customer-facing" issue raised by a partial GTK port is UI consistency. FontForge has an extensive UI customization system. GTK is also customizable, but in somewhat different ways and via different mechanisms. So any attempt at replacing, say, the font view with a GTK window raises the question of how the current customization system will interact with the window. E.g. will the overall look and functioning of the program be consistent between the two widget sets? However, even if that's my "line" I'm not going to make a unilateral decision about such a large change, and the other central members of the project tend to be more conservative than I am. Porting one window to the GTK puts the project on a certain trajectory that limits other future options. Some of "us" may object just on that basis. Other stuff: The discussion above mentions code stability. When it comes to the current system I'm mostly unmoved by those concerns. Yes, lots of FontForge code is bug-ridden. At this point the chance of hitting a crash is proportional to how much a given subsystem gets used. Most of the "mainstream" facilities work OK. I suppose the problem raised by the FontView is that it needs new functionality, including new widgets and existing widgets working in new ways, and that would be a pain to get working in gdraw. I don't disagree, but while that weighs on some of the things I've said above, it doesn't definitively change them. And, of course, bugs can be fixed. Meta: Note, as I have said in other contexts, that anyone who wants to can, of course, just fork the code and do exactly what they see fit without dealing with me or any other FontForge hoo-ha. That poses two challenges to the forker, one being the right kind of challenge and one being the wrong kind. The right kind of challenge is that to succeed the fork would have to be clearly better than the code in this repo, rather than just different in the way certain people felt it should be different, with everyone else dragged along by inertia. The wrong kind of challenge is the flip-side of that inertia: the fork could be better but maybe users wouldn't notice or wouldn't bother changing to it anyway. I say this to make it clear what this discussion is about, and will inevitably be about. It's not ultimately about code or direction, because you can write whatever code you want and take that code in whatever direction you want. The discussion is ultimately about a name and the inertia associated with that name. And the board of the foundation that has rights to the name, and thus this repository, has tended to be pretty conservative about the direction. In particular they tend to be much more focused on the needs and workflows of current users than on potential new users. That's how the cookie has crumbled and will probably how it will continue to crumble. |
Beta Was this translation helpful? Give feedback.
-
|
I haven't read the full thread but actually my qt branch more or less works. I'd definitely say that's the way forward if we ever need to move, especially as it has somewhat usable Wayland support |
Beta Was this translation helpful? Give feedback.
-
Probably "Add Encoding Slots" in the "Encoding" menu. Frequently used but mostly by people who have long ago stopped thinking about it. Also very simple. |
Beta Was this translation helpful? Give feedback.
-
|
So, just to clarify how this would probably work on a project level if it were to go forward: Assuming any remaining Qt issues (like the scaling above) are addressed, and the powers that be are amenable (which seems likely -- @jtanx's views on gdraw are generally trusted), there would probably need to be a release that only makes the Qt changes to gdraw (plus whatever other non-UI stuff has been merged), and that will need to be out in the world for quite a while before any Qt-only UI stuff is accepted into the master branch. That way we could be more assured that this path for the UI code, or if it won't we can back out to GDK for the time being. |
Beta Was this translation helpful? Give feedback.
-
|
Gonna throw in food-for-thought here: I do like KDE (3,4,5,6) as a Desktop, but it looks like it's narrowing-down to just the most popular desktop platforms, while GTK seems to still try and target what it can. |
Beta Was this translation helpful? Give feedback.
-
|
I just wanted to drop by to say, if anyone cares what I think, that I think this is a very good idea and I would like to see it happen, and support anything that helps expedite it. |
Beta Was this translation helpful? Give feedback.
-
|
GTK4 has been out for some time. Why not port FontForge interface to GTK4 instead of GTK3? I don't have experience with GTK, but it seems that GTK4 would be more future-proof and have more features because it is newer. |
Beta Was this translation helpful? Give feedback.
-
|
I made some proof-of-concept with Font View screen fully rewritten in GTK3. As mentioned earlier, it's based on @Omnikron13's major infrastructural breakthrough. You can check the code at https://github.com/iorsh/fontforge/tree/font_view or pick Linux AppImage at https://github.com/iorsh/fontforge/actions/runs/10101284086 (scroll to artifacts at the end of the page). The code is very unsightly, I don't think I bothered to release a single allocated byte of memory there. So the next step is probably cleaning and brushing it. It was tested in Linux (both X11 and Wayland); I still have to look how it behaves on Windows. @jtanx promised a lot of pain there, and I fully trust his experience. There are notes in the Wiki |
Beta Was this translation helpful? Give feedback.
-
|
Terribly sorry for reviving this but I don't want to start a new thread and I'd like to know if there is still work being done on this or maybe in the plans at least? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it was decided to proceed with porting UI to GTK3, and the latest release includes one GTK-based dialog for "Encoding --> Add Encoding Slots...". There is also a "Language List" dialog in #5648, and two pending PRs #5682, #5708. The pace is not quite fast, as you can see, but we do advance in the right direction. |
Beta Was this translation helpful? Give feedback.


Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Context: #5298
Beta Was this translation helpful? Give feedback.
All reactions