API discussion

[mgord9518]

This is a place to discuss possible improvements and additions to the API, continued from #11

[mgord9518]

After a bit more experience with Zig and working with zfltk, I have found the separation of types within objects that do very similar things to be a little clunky. I originally pushed that change, but I believe it can be further improved.

The main issue stems with working with callbacks and other functionality which takes a specific widget type as a parameter.

Consider the following example:

groupCb(group: Group(.flex)) void {
}

// Vs

groupCb(group: Group) void {
}

To keep the best of both worlds, I can think of two decent solutions:

Solution 1:

Group.init(.flex, .{
    .x = 50,
    .y = 50,
    .w = 50,
    .h = 50,
}

Solution 2:

Group.init(.{
    .kind = .flex,

    .x = 50,
    .y = 50,
    .w = 50,
    .h = 50,
}

These both against the current syntax:

Group(.flex).init(.{
    .x = 50,
    .y = 50,
    .w = 50,
    .h = 50,
}

Advantages to solution 1:

• Similar to zfltk.Image init
• Very explicit

Disadvantages to solution 1:

• For normal groups, .normal must be used, which is a bit clunky. Maybe the name could be switched to something else? I'll investigate FLTK docs and see if the "default" group has an actual name

Advantages to solution 2:

• Simpler to tweak in the future without breaking code due to just being a struct field
• No need for .normal; to use default group just leave .kind unspecified

Disadvantages to solution 2:

• Too many init options may make code harder to read

Advantages to current solution:

• No code breakage

Disadvantages to current solution:

• Working with callbacks is very clunky
• While it isn't hard to read, I think the new 2 solutions offer even better readability
• Types that share tons of common functionality (such as groups) are treated as different types entirely. But it is hard to create a perfect 1:1 with C++ inheritance

I'd love to hear feedback on this, along with possible arguments to keep the current method

[mgord9518]

@MoAlyousef Yeah that's true too, although that would also require the biggest amount of changes from dropping the Type.kind setup.

The only widgets that break the current convention are Box, Tree and Widget. To fix the inconsistencies in solution 1, I think it would make sense for boxes to use BoxType as their Kind, allow Widget to be an exception as it's a bit special in being the parent to all other widget types and will rarely be instantiated. For Tree, I suppose normal would be the only current option, but it seems like it could potentially get more variations in the future

[MoAlyousef]

Another issue with solution 1 and 2 is: what would Group.fromRaw return?
For example, you pass a pack as the anyopaque pointer in a callback, then you would have to call Group.fromRaw on it. Unless Group.fromRaw also takes a kind argument.

[mgord9518]

@MoAlyousef Yeah that's a really valid point. Maybe as an initial switch to solution 4, wrapper types could be created around the current functions. Then, either incrementally refactor the code or leave it as is, as having functions to create the widget types is pretty flexible.

// Rename Group to GroupType
pub fn GroupType(kind: Kind) type {
...
}

pub const Group = GroupType(.normal);
pub const Flex = GroupType(.flex);
...

[MoAlyousef]

I think that would be reasonable. It’s also elegant.

[MoAlyousef]

I've added aliases as suggest in your last comment. I had to remove the exposed types in zfltk.zig and made them private as well.