Replies: 6 comments 8 replies
-
Proposal: Hierarchical ConfigThis is a proposal to achieve the best of both worlds, based on the following elements. Diff-based
|
Beta Was this translation helpful? Give feedback.
-
Improved semantic terminologyThe process of constructing the overall GUI is composed of two processes, analogous to how almost every other complex entity is made.
Keeping these two processes logically separate in your mind is key for understanding what goes where, including the critical point that the Plan can be continuously updated, but the actual built elements remain in place unless the plans for that element change. Customization can happen at both stages of the process: the Plan can be updated by additional |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
In most cases, it is best to design in terms of components that you Plan and Build separately, rather than having everything be part of one giant Plan that encompasses everything in the app. This allows flexibility in later redesigns, and simpler, more encapsulated elements that are then more robust and not so strongly interdependent on each other. Any necessary interdependency can hopefully be captured by layering |
Beta Was this translation helpful? Give feedback.
-
Proposal: structurally nested widget planningThe key limitation of the existing proposal is that you can not make automatically named children, since you have to specify the nesting using paths, which are not possible with automatic naming. My proposal addresses this by using a similar system to the existing tree nesting paradigm we use. In my proposal, you can write this: splits := core.Add(p, func(w *core.Splits) {})
core.Add(splits, func(w *core.Frame) {})Instead of: core.AddAt(p, "splits", func(w *core.Splits) {})
core.AddAt(p, "splits/nav", func(w *core.Frame) {})In my proposed code above, |
Beta Was this translation helpful? Give feedback.
-
|
Another option from Kai: core.Add(p, func(w *core.Splits) {
w.AddMaker(func(p *core.Plan) {
core.Add(p, func(w *core.Frame) {})
})
}) |
Beta Was this translation helpful? Give feedback.
-
|
This is actually two tabs per level of nesting, which is quite extreme: core.Add(p, func(w *core.Frame) { // 1
w.AddMaker(func(p *core.Plan) {
core.Add(p, func(w *core.Frame) { // 2
w.AddMaker(func(p *core.Plan) {
core.Add(p, func(w *core.Frame) { // 3
})
})
})
})
}) |
Beta Was this translation helpful? Give feedback.
-
|
See fc9ff65 for an example of the effects of this. |
Beta Was this translation helpful? Give feedback.
-
App-level declarative paradigm?Here are two possible ways to write the basic example, both seven lines of code: Existing way: package main
import "cogentcore.org/core/core"
func main() {
b := core.NewBody("Hello")
core.NewButton(b).SetText("Hello, World!")
b.RunMainWindow()
}Potential new declarative way: package main
import "cogentcore.org/core/core"
func main() { core.Run(NewApp()) }
type App struct { core.Frame }
func (a *App) Make(p *core.Plan) {
core.Add(p, func(w *Button) { w.SetText("Hello, World!") })
} |
Beta Was this translation helpful? Give feedback.
-
Making plans and building widgets, with dynamic updating(Note: This is provisional documentation for the current state of the new Plan / Build architecture.) Perhaps the most important challenge for an advanced GUI framework is providing an efficient, logical, and flexible way to construct and dynamically update the GUI contents. One popular "brute force" technique, the declarative approach, is to use exactly the same code for construction and updating, rebuilding the current state every time, and letting the framework figure out what has changed (using a diff-based algorithm). This is not very computationally or memory efficient, to say the least: our benchmark tests showed factors in the 100x to 1000x range of both computation and memory cost relative to our more optimized approach. It also typically makes it difficult or impossible to use standard programming logic during construction, because everything ends up being written in the form of a giant static literal expression. Furthermore, it introduces significant complexity regarding the status of the active state of the widgets when they are updated. Our "Plan & Build" alternative approach improves upon the standard declarative approach by using unique name identifiers as keys (like unique map keys) for determining the elements of a Plan for the GUI structure, and putting all the construction code inside a closure that is only executed when a new widget element is actually needed. Thus, all the logic is expressed using standard programming constructs ( A key general principle behind the
|
Beta Was this translation helpful? Give feedback.
-
|
Disclaimer: I have only spent about an hour investigating cogentcore, and all of my GUI experience is from the 90s, before more modern trends became popular. The whole project strikes me as an interesting and impressive achievement. In particular, it is a GUI library that comes with multiple non-trivial applications, which surely provides invaluable experience. My comments here are merely first impressions. Overall, I find the claims, made here and elsewhere in cogentcore documentation, against the declarative approach to be over-stated and under-substantiated. I read the claims and remain unconvinced. These concerns are closer to a matter of programmer taste and familiarity than a matter of being obvious or factual. Often declarative approaches are held up as being easier to maintain precisely because they are a more constrained, less expressive, DSL, and so easier to learn and use correctly. This is in large part why declarative approaches like HTML have succeeded. Personally, I usually find nested declarations easier to reason about than a set of tightly woven imperative APIs. That said, the efficiency arguments presented here hold obvious weight, in my opinion. I noticed that the pathed ID approach talked about here bears some resemblance to the one used by Xilem, I presume for similar reasons. See "Identity and id paths" at https://raphlinus.github.io/rust/gui/2022/05/07/ui-architecture.html. That architecture sets the lofty goal of being both declarative and fast. But, it is written in Rust, and no Go solution is likely to be able to touch it in terms of performance.
It isn't clear to me how these things are stacks. Stacks usually involve both push and pop operations, and often only the top element is accessed. Aren't these just lists? After reading all the above posts I remained confused about the distinction between Planning, Building, Rebuilding, Restyling, etc. I think the planning phase is effectively constructing bespoke "objects" of what amounts to a single type that behaves in a fixed way according to "the plan". The other phases are effectively methods on that object type (or "class"). The final |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your feedback! First, I would like to note that this was a WIP discussion of how to best structure things, and thus some of the examples and principles stated here are not what actually ended up being implemented. For an accurate representation of the current paradigms, you can look at the following sections of our docs:
Nevertheless, this discussion still does capture a good amount of the overall structure and principles of our current paradigm, and your concerns are legitimate. I will do my best to address them here, and I would be glad to here your thoughts after reading those documentation pages and my points here. I am not ruling out any possibilities such as a declarative approach, just making my case.
Let me first say that, relative to @rcoreilly, I was more in favor of a full declarative paradigm. I still agree with most of his arguments against a declarative paradigm, but I also recognize the merits of declarative paradigms to a further extent (having used them myself). I think that @rcoreilly's most adamant argument against declarative is the performance concerns, which I personally find to be somewhat overstated, so he would be better suited to make that case. My biggest argument against a declarative approach is, as @rcoreilly said:
As you can see in the code examples in the initial post above, all of the declarative paradigms use ternary expressions, As you noted, we have built several large applications using Cogent Core. In those apps, we find that the amount of actual basic GUI code that would be easy with a declarative approach is small, and most of the code is focused on business logic, such as simulating neural networks and manipulating SVG vector graphics. What Cogent Core allows you to do is easily plug that imperative Go business logic into a GUI without worrying about state concerns and ternaries and other declarative issues.
The problem is that people are not satisfied with HTML, as evident by the constant creation of new JavaScript frameworks. In my opinion, the reason that people are not satisfied with HTML is because it separates GUI logic from business logic too much. This is the key advantage of our closure-based approach: you can very easily integrate logic into your GUI using idiomatic Go embedded in closures.
Yes, stacks was a misnomer, @rcoreilly meant lists. Thank you for pointing that out.
If you are still confused about the distinction between all of those things after reading the documentation pages, please let me know and I will try to clarify it further (again, some concepts like Building do not exist in the current paradigm).
I guess I don't really understand what you mean by "regular Go interfaces" here, since we believe the advantage of our approach is that it is more like idiomatic Go than a declarative approach. For example, in my experience using go-app, I experienced an endless stream of hard-to-debug issues related to state management, component mounting, and control constructs. Thank you again for your feedback! |
Beta Was this translation helpful? Give feedback.
-
|
Ah, I had actually read through the docs and tutorials and thought this proposal was a modification the current release! Just goes to show how little I understood about both.
I don't really like things like
Yes, HTML is not good at expressing highly dynamic and interactive applications. I do notice that interactivity was initially added to HTML by attaching Javascript closures to DOM elements in a way that isn't all that different from the way Cogent Core wires up behavior using closures. People found the callback-heavy code hard to deal with, and so things like React came to be. I don't have any answers here. I think GUI is a hard problem, and for each of the myriad of ways a GUI can be expressed one can find examples where that way works best.
Oh, for that I was thinking something like the below, but now I don't think this would fit well with Core's design as I understand it. It actually makes me a bit sad, because I've been looking for a way I can express a GUI directly in idiomatic code, of some simple language like Go, for a long time. Core comes close, and while it is true that it doesn't invent new language constructs, it does introduce a kind of bespoke object system constructed from lists of closures. Perhaps this sort of thing is unavoidable in the problem space. |
Beta Was this translation helpful? Give feedback.
-
There are certainly some similarities, but a key feature of Cogent Core is that everything is in one cohesive language. One of the biggest issues with vanilla HTML/CSS/JS is that you have to constantly re-express how to get an element imperatively in different contexts, making it hard to track. For example, to make a red button that prints something when you click on it using separate (not inline) HTML/CSS/JS, you have to do something like this: <button id="my-button">Hello</button>#my-button {
background-color: red;
}document.querySelector("#my-button").addEventListener("click", function (e) {
console.log("Hello");
});Notice how bt := core.NewButton(b).SetText("Hello")
bt.Styler(func(s *styles.Style) {
s.Background = colors.Scheme.Error.Base
})
bt.OnClick(func(e events.Event) {
fmt.Println("Hello")
})Again, there are similarities between these approaches, but I would argue that one of the biggest advantages of React is that you don't have to separate HTML and JS; in fact, they even state so on their website:
Cogent Core provides you the same advantage by coupling everything together instead of having separate things like HTML/CSS/JS, which I would argue is the main disadvantage of that approach. Furthermore, the updaters and plans in Cogent Core provide a lot of the same functionality as declarative approaches, allowing you to avoid the deeply nested imperative callbacks that plague JS.
We actually used to have a system a lot more like that, but the fundamental problem with such an approach is it makes it extremely difficult to customize widgets. For example, if you wanted to make a red button, you would have to make a whole new widget type since the only way to style something is to implement interface methods. If you wanted to make a button that prints something, you would also need to make a new widget type since the only way to add an event handler is to implement interface methods. That kind of ultra-idiomatic approach sounds great in theory, but as soon as you actually have to customize anything, it becomes a nightmare. In fact, other Go GUI frameworks such as Fyne and Gio take more of that approach, but then it is impossible to customize anything without making new custom widget types and writing a bunch of code. The lists of closures allow you to have easily customizable widgets without some separate language like CSS. As you noted, this is a hard problem, and different approaches sacrifice different things. If you have any ideas on how we could ameliorate these problems without removing key functionality, we would be glad to consider them. Thank you again for all of your feedback! |
Beta Was this translation helpful? Give feedback.
-
The Declarative Paradigm
Many standard GUI frameworks use the declarative paradigm, where you construct a new composite object that represents the desired state of a widget, and the framework figures out from that what needs to be updated relative to the current state (i.e., basically performing a
diffand applying the resultingpatchto the current state). This is done every single time the state changes!The primary advantage of this paradigm is that the user doesn't need to worry about all the possible ways something might change : you can just create the desired state.
The primary disadvantage is that it ends up putting large chunks of GUI logic into single huge monolithic functions that are deeply nested and complex, with potentially significant amounts of embedded logic. In Go terms, it is basically writing your entire GUI logic within a struct literal expression, which are arguably the most unpleasant and unwieldy expressions in the language.
These declarative constructor expressions need to be massively nested because otherwise you would have to deal with complex logic of finding a particular place to insert a new element, and dealing with the state updating logic that you're trying to avoid in the first place. This means that you cannot use standard programming logic like
ifandforto flexibly build your GUI elements.For example, here is an example from the main Flutter sample app:
The code ends up being full of inline ternary logic expressions and other ways of replacing the standard procedural / imperative programming control flow constructs. The excessive boilerplate elements of the Dart language are not doing this code any favors, but even within Go, the equivalent declarative constructors end up being similarly horrible, here in the case of go-app:
Note the use of
app.Ifto implement conditional logic, and there are similarapp.Rangeconstructs.Fyne uses an imperative mode of updating, but ends up making large nested structures like the declarative paradigm for the initial configuration, as in this example from their tutorial, where the
container.NewVBoxfunction takes a list of widgets to add:Clearly, there is room for improvement here. There are ways of breaking these functions into smaller components, but the basic issues remain.
Another critical issue with the declarative paradigm is that the final resulting state can end up being a random mashup of old and new, updated elements, which can create problems with coordinating across the different parts of the overall state. This typically requires additional complexity and logic to distinguish between the "state" that might be overwritten by updates.
The Imperative Paradigm
In the imperative paradigm, one calls functions to directly construct the GUI structure, so that standard control flow logic can be used. For example, here's a sample from the Cogent Core demo:
The
NewXconstructor functions take a parentWidgetand automatically add themselves to the parent's list of children.This results in simple, logical code, but what happens if you want to update the configuration based on some kind of state change?
Simple updates to state, such as hover or changing text etc can all be managed by changing state of individual widgets, and are straightforward to handle. Typically, widgets handle these updates themselves. But what happens if you want to make changes across different levels of a set of nested widgets? This logic can become a bit complex, in terms of finding and updating the specific widgets in question. And this update logic ends up being physically separated from the original configuration code, so it is harder to keep the two synchronized.
Furthermore if you want to change the overall structure of a set of nested widgets, it can become even more complicated. Often you end up just resetting everything and rebuilding from scratch, which is obviously less efficient than a declarative mode "diff" update.
The Best of Both Worlds
To get the best of both worlds, we need the following:
Beta Was this translation helpful? Give feedback.
All reactions