On Thu, 11 Mar 2021 14:27:07 +0100 Ancor Gonzalez Sosa <[email protected]> wrote:
> Disclaimer: I'm definitely not advocating to use Tk instead of libYUI or > Qt. I'm perfectly aware that Tk is not exactly "the future" (unless you > are somehow reading this from 1996). > > <snip> > > > 3) My experiment > > I just stole a calculator model from one of the Glimmer SWT/Opal demos > and wrote an UI for it using glimmer-dsl-tk. As you can see, the UI code > is really declarative and free of manual steps like populating values or > taking care of the event loop. There is also no boilerplate code like > the one we have in YaST to connect our object-oriented CWM widgets to > the underlying model (you know, defining #init, #store, etc.). > > https://github.com/ancorgs/glimmer-tk-calculator/blob/master/lib/views/glimmer/calculator.rb > > Data-binding works like a charm. This simple call you can find in the > code does all the connection magic, providing interactivity for free: > bind(presenter, :result) Hi, at first thanks for sharing it. Really interesting reading. I check your experiment and to be honest I still see similar issue we have with yast. UI is focused on programmers. You write code that produce some UI. And to be honest I do not like it. I prefer GUI designer that produce some description of UI like qt designer or java swing designer that allows to play with UI elements its organization. Testing how it will look when you resizing size, etc. And then connect UI elements to code like e.g. that bind call. This way it is much easier for designer to play with it. Now we get just screenshot with red circles what we should change and we need to do it ourself and wait again for designer to look at it and say his oppinion. > > It was also an opportunity to me to learn about Tk's grid layout system. > It's pretty neat. It's based in just a few simple concepts and it's > quite easy to understand, but it still gives the developer quite some > power. It's true that, used directly, it pollutes a bit the UI code (as > you can see in my code). But it should be easy to find a way to not need > to pass all those row/column values to every single widget. I am not sure, but how it will look like when you resize dialog? All those hard-coded padding a bit scary me. For me still the best layout is relative one which defines constrints like Spring Layout which for me works well and looks good. > > I though the whole Tk approach would work quite well for a TUI as > well... and I was not the first one. There are two implementations of Tk > for ncurses. The development of both was stopped a looong time ago and I > would be surprised if any of them is still useful in modern times, but > at least it looks like there is people who still try to keep them > compiling with relatively recent versions of Tk. > https://github.com/credil/ck > https://github.com/rkeene/CTk > > As final words, I'm not saying we should adopt Tk and/or Glimmer, but I > think we can take inspiration from both to whatever we do in the future > regarding the UI. There are quite some neat ideas in both. Writing an > interactive UI turned to be a quite pleasant experience with such tools > (as opposed to our not-so-nice experience in YaST). I like that binding approach to present raw data in UI. But still I think we should focus more on using some kind of GUI designer. My old idea was to use qt designer to produce UI file and then try to create ncurses UI from it, but I never move it forward. The approach that goes a bit further in this direction was experiment with shoes like definition in https://github.com/libyui/ruby-ui/blob/master/examples/wizard1.uit but still too far from GUI designer which anyone from UX/UI team can use. Josef > > Cheers.
