Are there any somewhat planned refactorings for owlkettle?

[PhilippMDoerner]

Heyho,
I was wondering what all the semi-planned-but-not-yet-caught-in-issues refactorings were that might or might not be planned.
I know I have one on my list, that being the one for playground nim to move towards unifying toFormField and toListFormField.

I also have 2 more modules where I'm not sure if they have a refactoring brewing on the horizon or not.

1. As I add more and more widgets to widgets.nim I wonder if it might make sense to think about splitting up widgets.nim into many smaller modules (one module per widget maybe ?) and using widgets.nim as a barrel file that imports and re-exports all of these modules.

Particularly given that widgets.nim is currently at 3600 lines of code and is only inching towards more this seems sensible to me, though that is of course heavily informed by my propensity to basically never let my modules grow beyond 500 lines of code. So please let me know if you have a very different idea of general structuring in this regard.

2. Another thing would be that adw.nim and widgets.nim handle wrapping both different. One separates the c-code bindings into its own module (gtk.nim and widgets.nim), the other combines both into the same module (adw.nim). I assume you tried out both approaches to see which worked better in your opinion. Is there any conclusion you've come to in that regard?

[can-lehmann]

1. Module size is generally personal preference and quite subjective. I tend to try to extract large & reusable software components into modules. However generally I am against splitting individual types/widgets into their own modules because of the following "philosophical" consideration: Modules are one layer of abstraction in a hierarchy (type < module < directory < package). When you add one module per type (widget), you kind of loose the separation between the two layers (i.e. they are now treated as one type = module; java does this for example). This is of course mostly a subjective perspective. If there are actually real/tangible benefits for one or the other, I may change my mind on this 😄 The other point is that dealing with a single large file is just much easier with my text editor, but I guess since I am not the only person working on the codebase anymore, that does not apply as much.
2. Initially I just put everything into one module for adw, since there wasn't a lot of code. I think that as the adw module grows, splitting it into two similar to widgets and gtk makes lots of sense. It also makes sense with the idea from above of modules being used for large & reusable software components (e.g. the bindings can be used independently of the owlkettle widgets). For names we could maybe use owlkettle/adw and owlkettle/bindings/adw (maybe also move owlkettle/gtk to owlkettle/bindings/gtk). From a philosophical standpoint, having a bindings folder would make sense, as it is a larger "sublibrary" that you could probably even use without using owlkettle itself (I don't see why you would want to though 😄).

Some additional upcoming refactors that come to mind

• Setters should be defined inside the viewable/renderable block
• The documentation system should generate machine readable docs instead of markdown to allow for a better documentation browsing experience (though this probably has to wait for 4.0.0)

[PhilippMDoerner]

Additional planned refactoring based on the PR comment from PasswordEntry:

Add an "Editable" Baseclass and let Entry Widgets inherit from it to not have to reimplement editing all the time.

Note though, it might make sense to discuss this a bit.
A widget always implements multiple interfaces. Do we maybe want to contemplate how we want to deal with the other interfaces a Widget may implement?

[PhilippMDoerner]

Actually question, what does this here mean:

The documentation system should generate machine readable docs instead of markdown to allow for a better documentation browsing experience (though this probably has to wait for 4.0.0)

What constitutes machine readable docs?

[PhilippMDoerner]

I would like to propose another refactoring in regards to enums:
Unify Enum handling.

In gtk.nim we currently have it so that you wrap the enum with identical wording from gtk, call it Gtk<EnumName> and then provide a second enum called <EnumName>' in widgets.nim with adjusted naming. Then we define a toGtkproc to convert between the two of them (And I usetoOwl` to convert back in some of the PRs where necessary).

Meanwhile in adw we save ourselves the hassle and just write one enum withour naming scheme and that's it.
I would propose a refactoring for gtk.nim and widgets.nim that we handle enums there the same way as in adw.nim.
That means getting rid of double-enums as well as toGtk procs, which I think would be quite nice.