Tab bar

[ghost]

So far dvui is doing everything I want for building my gui framework. I'm very impressed. Especially with the slowed frame rates.

Below is my frame function for a tab-bar. (Its a callback and thats the reason for the anyopaque.)

There are 2 unsolved issues.

1. The tab-bar is inline but it should have a block layout.
2. The scroll area, which should a block layout below the tab-bar, end's up inline with the tab-bar. The tab's content area is correctly in the scroll area but again, the scroll area is inline.

Any help is greatly appreciated.

    fn frameFn(self_ptr: *anyopaque, arena: std.mem.Allocator) anyerror {
        var self: *Screen = @alignCast(@ptrCast(self_ptr));
        var tabbar = try dvui.menu(@src(), .horizontal, .{ .background = true, .expand = .horizontal });
        defer tabbar.deinit();

        if (try dvui.menuItemLabel(@src(), "Simple", .{}, .{}) != null) {
            self.selected = tabs.simple;
        }

        if (try dvui.menuItemLabel(@src(), "Hard", .{}, .{}) != null) {
            self.selected = tabs.hard;
        }

        if (try dvui.menuItemLabel(@src(), "Home Panel", .{}, .{}) != null) {
            self.selected = tabs.home_panel;
        }

        if (try dvui.menuItemLabel(@src(), "Other Panel", .{}, .{}) != null) {
            self.selected = tabs.other_panel;
        }

        var scroll = try dvui.scrollArea(@src(), .{}, .{ .expand = .both, .color_style = .window });
        defer scroll.deinit();

        switch (self.selected) {
            .simple => {
                var behavior: ?*_framers_.Behavior = self.all_screens.get("simple");
                if (behavior != null) {
                    var err = behavior.?.frameFn(behavior.?.self, arena);
                    if (err != error.Null) {
                        return err;
                    }
                }
            },
            .hard => {
                var behavior: ?*_framers_.Behavior = self.all_screens.get("hard");
                if (behavior != null) {
                    var err = behavior.?.frameFn(behavior.?.self, arena);
                    if (err != error.Null) {
                        return err;
                    }
                }
            },
            .home_panel => {
                try self.all_panels.home.?.frame(arena);
            },
            .other_panel => {
                try self.all_panels.other.?.frame(arena);
            },
            .none => {},
        }
        return error.Null;
    }

[david-vanderson]

This is awesome! Thanks for the questions!

I'm not sure I totally understand, but to start:

• I think you want to do the tabbar.deinit() before the scrollArea() - the way it's written now the scroll area is a child of the tabbar
• you might also want to wrap everything in a dvui.box(@src(), .vertical, .{.expand = .both}) so that the tabbar and the scrollbar are together the children of the box
• that might be the whole fix, but if not, can you provide the context where this function is called? What widget is the tabbar a child of?

[ghost]

Thanks, I didn't understand the reasons for the deinits until now. That fixed it.

I uploaded the changes to my one key piano project. For now, okp is where I am creating a working framework. After I create the working framework, I will create it's tool. I did this with go and wasm and I did this with go and fyne. I'm doing it now with zig and dvui because of issues with fyne that are still being worked on.

kickfyne is my previous tool like this that i made for go and fyne. Below is kickfyne's use command output. It should give you an idea of what this tool and framework is about. It should offer some context. I want this tool i'm creating now to be the similar to my kickfyne tool.

＄ kickfyne use

kickfyne v0.14.0

🗽 FRAMEWORK: GETTING STARTED WITH kickfyne.
  ＄ kickfyne framework      # creates the kickfyne application framework.
  ＄ kickfyne framework help # displays the framework commands
  ＄ kickfyne framework use  # displays how to create the framework.

kickfyne is a tool which helps build an application using the fyne toolkit.
The fyne toolkit has among other things a very nice GUI.
The fyne toolkit web site is located at https://fyne.io/.
This kickfyne project is not in any way associated with the fyne toolkit project.

To get started with kickfyne follow these 2 steps.

1. Create and initialize the app's folder.
  ＄ mkdir ~/projects/«name-of-my-app»
  ＄ cd ~/projects/«name-of-my-app»
  ＄ go mod init "example.com/«name-of-my-app»" or "github.com/«my-github-folder»/«name-of-my-app»"

2. Create the kickfyne framework in the app's folder. Inside the app's folder run the following command.
  ＄ kickfyne framework


The framework is contained in 4 folders.
  1. ./          which contains main.go and FyneApp.toml
  2. ./back-end/  which contains the back-end code.
  3. ./frontend/ which contains the front-end code.
  4. ./shared/   which contains shared code.

BUILDING AND RUNNING THE APP:
The application can be built anytime after running the command "＄ kickfyne framework".
The following build example is done in the application's folder.

  ＄ go mod tidy
  ＄ go build
  ＄ ./«name-of-executable»


📺 SCREENS:
  ＄ kickfyne screen add-apptabs «screen-name»   # adds an AppTabs screen.
  ＄ kickfyne screen add-doctabs «screen-name»   # adds a DocTabs screen.
  ＄ kickfyne screen add-accordion «screen-name» # adds an Accordion screen.
  ＄ kickfyne screen add-simple «screen-name»    # adds a simple screen.
  ＄ kickfyne screen remove «screen-name»        # removes a screen to the OS trash bin.
  ＄ kickfyne screen list                        # displays screens with their panels.
  ＄ kickfyne screen land-at «screen-name»       # sets the landing screen.
  ＄ kickfyne screen help                        # displays the screen commands.
  ＄ kickfyne screen use                         # displays how to use screens.
📊 PANELS
  ＄ kickfyne panel add «screen-name» «panel-name»    # adds a panel to a screen.
  ＄ kickfyne panel remove «screen-name» «panel-name» # removes a panel to the OS trash bin.
  ＄ kickfyne panel list «screen-name»                # displays the panels in a screen.
  ＄ kickfyne panel help                              # displays the panel commands.
  ＄ kickfyne panel use                               # displays how to use panels.

The front-end's user interface is built with screen packages.
A screen package is composed of panels and a messenger.
The panels are how the screen package interacts with the user, displaying content and accepting user input.
Only one panel is visible at a time.
The messenger is how the screen package communicates with the back-end, sending and receiving messages.

For example a screen might have a panel where the user selects a record to edit and then another panel for editing the record.
Meanwhile the messenger is communicating with the back-end getting records for selection, a record for editing, and sending the edited record to the back-end for storage and switching panels.

The screen commands complete their tasks by displaying a to do list for the developer.
The panel commands complete their tasks by displaying a to do list for the developer.


💬 MESSAGES:
  ＄ kickfyne message add «message-name»    # adds a shared message and its back-end handler.
  ＄ kickfyne message remove «message-name» # removes a shared message and its back-end handler.
  ＄ kickfyne message list                  # displays the messages.
  ＄ kickfyne message help                  # displays the message commands.
  ＄ kickfyne message use                   # displays how to use messages.

The front-end and back-end are separate go threads that communicate using messages.

MANAGING MESSAGES:

* Message definitions are at "shared/message/".
* The back-end messengers are at "back-end/txrx/"
* The front-end messengers are in each screen's messenger.go file and contain instructions for handling messages.
* A message name is upper camel case so a valid message name might be "AddContact".

The message commands complete their tasks by displaying a to do list for the developer.


🏪 STORES:
  ＄ kickfyne store add «store-name»    # adds a store.
  ＄ kickfyne store remove «store-name» # removes a store to the OS trash bin.
  ＄ kickfyne store list                # displays the stores.
  ＄ kickfyne store help                # displays the store commands.
  ＄ kickfyne store use                 # displays how to use stores.

The store commands complete their tasks by displaying a to do list for the developer.

A store is the operations of a remote or local data-store.

* Store interfaces are at back-end/store/storer/.
* Store implementations are at back-end/store/storing/.
* A store name is upper camel case so a valid store name might be "Contact".
* Local store files are at:
  * Darwin:  os.Getenv("HOME")/.<app-name>/<file-name>
  * Linux:   os.Getenv("HOME")/.<app-name>/<file-name>
  * Windows: os.Getenv("LOCALAPPDATA")/.<app-name>/<file-name>

[david-vanderson]

That looks really cool!

[david-vanderson]

Oh also you could try this debugging aid - call dvui.toggleDebugWindow() and play around with the debug under mouse stuff. It needs a lot of work but can help show which widgets are inside which other widgets. Let me know if it's helpful!

[ghost]

Thanks for pointing that out. I found fn demo in dvui.zig. I was wondering where that fn was.

[ghost]

OK.
So now I need to add and test my own additions to dvui. I need to do this to learn more about dvui and to attempt to create some widgets.

Is there are way that I can just have a dvui module in my app's libs/dvui folder? Can I do that and still have that "freetype" dependency still functioning? So far my attempts have failed.

Thanks again in advance.

[david-vanderson]

Sounds like you might want to "vendor" dvui so maybe a git submodule and copy the parts of build.zig and build.zig.zon into your own top level build.zig and build.zig.zon. That should work and you can test it without git by copying the whole dvui repo contents into libs/dvui. If that is not working can you post how far you got? Specifically what does your build.zig and build.zig.zon look like?

…

On Mon, Aug 21, 2023, at 5:07 PM, JosephABudd wrote: OK. So now I need to add and test my own additions to dvui. I need to do this to learn more about dvui and to attempt to create some widgets. Is there are way that I can just have a dvui module in my app's libs/dvui folder? Can I do that and still have that "freetype" dependency still functioning? So far my attempts have failed. Thanks again in advance. — Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZDO5EVSJ3QTPV7ZTP5LETXWPEYFANCNFSM6AAAAAA3WBSA4I>. You are receiving this because you commented.Message ID: ***@***.***>

[ghost]

This is exciting! I really want to do this! What the heck if "vendoring"?

My working source is at https://github.com/JosephABudd/okp. There, I implement your build protocols defined in dvui.

[david-vanderson]

"vendoring" is the fancy term for copying the whole source tree of a dependency into your own repo. Using git submodules can make that easier in some situations. Copying everything is a good plan if you want to have a lot of local changes.

For you I would recommend trying to use the zig package manager for now. Almost everything in dvui is public to allow widgets to be defined outside the project, so you should be able to do anything you need without modifying the dependency.

When I checkout that repo and run zig build it gives me a file not found error because the file src/frontend/lib/framers/api.zig is in build.zig but not in the repo?

[ghost]

My .gitignore is incorrect. I'll fix this but my internet is down. This will take all day.

[ghost]

I apologize for that. Thank you for your patience. I have fixed the mess I created at my okp repo. I just cloned it and it builds and runs correctly. Its still at https://github.com/JosephABudd/okp.

[david-vanderson]

No problem! I'm able to run zig build and run the example, click on the different tabs and stuff. Very cool! What does "one key piano" mean?

[ghost]

Its the name of my morse code trainer I want to re write in zig. It uses a metronome to assist in timing for keying as well as simple instructions for keying ("down, 2, 3 up") . Hence, "One Key Piano". I first wrote it in wasm using my kickwasm, then in go and fyne using my kickfyne. Now I want to do it with zig. My kick tools are just code generators to write most of my app code for me. My github okp site shows how the generated code will be layed out. My goal is to write my kickzig tool, and then recreate okp using kickzig.

[ghost]

BTW, each version of okp uses a straight key wired to the left button of a sacrificed mouse. Some morse code web sites do the same thing.

[ghost]

That was too easy. Thanks again.