Didn't really do anything on Niepce in August, so no updates on that front. However I worked on a few other things.
A lot of work done on it. See my other wlog post. The short version is that I should look towards releasing 0.4.0 sometime soon.
Since that last post, I have added a long standing to-do item: code to generate test cases so I can run a non regression test suite on existing files. However I get hit with flaws in the various XML serde crates.
Did some work on AbiWord. Nothing ground breaking, but I have a goal to try to release the next 3.0.x with one or two bug fixes (UI), and then what I call 3.next (likely 3.2) that will focus on internal changes (stability) and UI fixes (anything back-portable to 3.0.x will get back-ported).
- Some code cleanup.
- Removed the use of
boostin many places where the standard C++ library would work.
- Use C++17 more.
- Making the build system less recursive. It's less complex and should be more parallel.
- Removed some Gtk3 construct that are deprecated in provision of a future Gtk4 port.
- More removal of the legacy containers.
- Rewrote the toolbars to use plain buttons and a
GtkToolItem. The look is slightly different.
- Fixing some Gtk3 bug: the table creation widget was not behaving properly. Will be on stable too (3.0.x)
- Fixing some bugs with styling. (also on 3.0.x)
I am introducing Gtkmm into the code base.. This can be done
progressively, but it will make Gtk work so much easier. The initial
bootstrap involve using it for the
GtkApplication object. This
ensure it's properly initialized and everything can trickle down from
Porting to Gtk4.
I try to anticipate some of the changes by trying to do some of the porting on Gtk3.
Porting the menus to
GMenu as the first step. It almost work, but
the main problem that the menu machinery doesn't poll the
nor the actions. Before that we created the
and connected to the
unmap signal to refresh the item. I
look into reproducing this with
GMenu based code. It not that
easy. The API lack: I can't get the action or the
GMenuItem from a
GtkMenuItem (or vice-versa) and I currently rely on the
structure. This will break on Gtk4 but it least it is more limited.
The goal is to have it work the same way for 3.next.
AbiWord uses libgoffice. I am working on fixing some bugs that happen
to hit both Gnumeric and AbiWord (Gtk3): in the
GOComboBox the popup
isn't set transient to the
GtkWindow which is a no-no on Wayland, so
it's never positioned right. But then fixing this cause a conflict
with tool-tip: if the user click on the control while the tool-tip is
showing, it will fail. And
GtkComboxBox just use some internal API
_gtk_tooltip_hide (GTK_WIDGET (combo_box))
So I haven't figured out yet how to hide the tool-tip.
See draft merge request 10.
Past 3.next, that will have the UI almost unchanged, I intend to think of a slight redesign. The challenge is to find the proper balance between improving the UI, not getting users lost, and how easy we can do it. It's a lot of work, but the current UI design is still stuck in the early 2000s as a "clone" of Microsoft Word™, and has become a bit messy over time.