Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Easier UI #19

Open
mjarkk opened this issue Apr 28, 2019 · 12 comments
Open

Easier UI #19

mjarkk opened this issue Apr 28, 2019 · 12 comments
Labels
enhancement New feature or request

Comments

@mjarkk
Copy link
Member

mjarkk commented Apr 28, 2019

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.

@mjarkk mjarkk added the enhancement New feature or request label Apr 28, 2019
@glvr182
Copy link
Member

glvr182 commented Apr 28, 2019

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
Copy link

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

@mjarkk
Copy link
Member Author

mjarkk commented Apr 29, 2019

@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
Copy link
Member Author

mjarkk commented May 9, 2019

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
Copy link

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

@mjarkk
Copy link
Member Author

mjarkk commented Jul 26, 2019

@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
Copy link

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
Copy link
Member Author

mjarkk commented Jul 26, 2019

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
Copy link
Member

glvr182 commented Jul 28, 2019

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
Copy link
Member Author

mjarkk commented Jul 28, 2019

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
Copy link

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
Copy link
Member

glvr182 commented Jul 28, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants