Easier UI

[mjarkk]

Describe the feature you'd like
A easier way to generate UI,
Currently everything needs to be set with fixed position but it's quite a bit of work to implement this in a new app when having a advanced UI.

I personally like the CSS grid layout for creating UIs and i think the underlying idea of grid layouts fits GoCui really well because the base concept is really easy and it's made for not nested widgets (Most ui managers have UI in UI in UI what is not used in gocui and in CSS grid).

Describe alternatives you've considered
/

Additional context
The origin repo also had in issue about this: jroimartin#183
Also as mentions in the original issue it might be a good idea to put this in a separate repo.

When #8 is merged i would like to work on this thought i want to hear first the thoughts of others.

[glvr182]

Interesting suggestion, how would the user create such a grid? Would they first 'cut' the ui in certain blocks, or is there a different mechanism?

[skanehira]

Like the tview grid?
https://github.com/rivo/tview/tree/master/demos/grid

[mjarkk]

@glvr182 I think a user would first need to define there views and init the grid.
After that they need to define where the components are, this can be always changed.

@skanehira Something like that but not the same.

I'm imagine something like this:

func makeUI() {
  g, _ := gocui.NewGui(gocui.Output256, true)
  grid := g.NewGrid() // Tell gocui we want a grid layout
  helloWorld := grid.NewView("hello") // Make a hello view, the helloWorld is a instance of gocui.View
  
  // Make a grid layout with a width of 3 and a height of 3
  grid.Screen("main", gocui.GridScreen{
    Columns: ["1","2","1"], // make 3 columns with the width of the array 
    Rows: ["1","100p","1"], // make 3 rows with the width of the items inside the array
    Views: gocui.GridViews[ // Tell the grid the views we have, we can always change this later
      helloWorld,
    ]
  })

  grid.ShowScreen <- "main" // Show the main screen
  _ = grid.Render("hello", gocui.GridPosition{
    Column: 2,
    Row: 3,
    // Or scratch the view over multiple columns / rows
    Columns: [2, 3],
    Rows: [2, 4],
    // There would be more options here for rendering
  })
}

[mjarkk]

I'm going to wait with making this because i'm not happy yet with my thoughts about the "grid layout".
I'll think about this a bit more and see if i can come up with something better.

[MichaelMure]

As the author of git-bug, which use gocui, I also struggled with this problem. I thought about a different solution: jroimartin#162

[mjarkk]

@MichaelMure i agree with the idea of child views, they could fix so much things so easily.

But should we extend that idea with "fake views" or "view groups" because there are some situations where you want to group views but they don't necessary have a parent view.

For example it would be great if it's possible to separate the popups from the main views with data, that way it's safer, "easier" and faster to show a popup and hide it behind the data views.

[MichaelMure]

I think that child views are the building block that make it fairly easy to implement more complex UI concept, be it grids, view groups, popup ..

You could start by implementing the child views and see how people use them. Once it become clearer what is actually useful, that can me merged into gocui.

[mjarkk]

Agree, that looks like good starting point for better view management.
@skanehira or @glvr182 do you also agree with adding support for child views?

[glvr182]

I like the idea, i'm just worried about making gocui too complex. The describtion of gocui says "minimalistic" but i fear by adding these features it will not be just that anymore. What do you guys think

[mjarkk]

That's a good point.
This indeed adds a lot of complexity to gocui what might make it simpler but breaks the minimalistic rule.

I think it comes down to what we see as minimalistic, a small code base or does the api needs to be minimalistic.

If we see it as a small code base then this would be a bad idea to add in gocui.
But if we look at the api (as in the amount of exposed functions etc) this doesn't look to complicated, this is for a end use probably only a few functions extra thus would still be minimalistic.

[MichaelMure]

A few things:

• first thing first, you are not limited by the current definition of the project, you can choose what you think make sense regardless
• the minimalism of gocui for me is the focus on providing the tools to build a UI, rather than providing every kind of widget possible. Child views very much fit in that definition
• I believe the changes needed to implement the child view would be fairly minimal, both in term of code size and API change. It can even be 100% compatible
• child views are something that is fairly difficult to implement from outside of gocui, thus it make much more sense to have it in gocui
• child views are a building block to build more complex widget/UI. Pretty much all UI framework include a similar concept

[glvr182]

Those are good points, count me in on this.

I would however like to see @jesseduffield 's code merged into this repo first. So i will first focus on that.

Would you like to do the initial if not full implementation of this?

Ofcourse if any other maintainer disagrees with the idea of child views we would have to solve that discussion first