7GUIs and beyond #7
Comments
|
Looks good, will do. Hopefully the community can help out with some programs. |
|
Btw. I'd highly recommend making any information (both input and output) being treated by V UI as infinite streams of samples (similar to what e.g. Concur with it's Elevator Pitch and it's ==== Now here is the secret sauce ==== paragraphs does). You'll get live view of everything (i.e. complete interaction!) for free (even e.g. layout definition itself can be a stream allowing e.g. reacting to input stream samples saying the user is dragging a handle bar and the layout will just stream newly computed value to the drawing machinery which'll immediately accommodate). Making streams of samples (structs) a native feature of each smallest distinguishable part of UI (e.g. text, icon, position coordinates, width & height, etc. - but NOT of whole buttons/comboboxes/etc.) greatly simplifies all UI programming. This is btw. what Red VID dialect and Concur do. Others like immediate mode UIs and React at least move in that direction. See also Concur for ImGUI (i.e. how to use the streams concept with an immediate mode backend). I wrote this after seeing latest commits in this repository going rather in an old inflexible direction focusing on static views instead of fully live interactive stuff. |
|
It's all work in progress, I'll be moving it closer to Flutter/SwiftUI with its declarative style, state management, and hot reloading. And perhaps we can adopt this model as well. |
|
@dumblob I've added a task list. |
That's a bit pity as both state management and hot reloading wouldn't be needed at all if streams were used everywhere (you'll see it yourself when implementing e.g. the Cells task from 7GUIs - compare it then to 17 LOC solution in Red). Declarativeness is rather about syntax and not about architecture - thus declarativeness can be added to any architecture. |
|
You really think this code is something to wish for? |
|
But I'll do the research on streams, thanks. |
Well, not the density, but the expresiveness. Regarding density I thought you'll look at the original, i.e. formatted version mentioned in the article (I didn't want to change the title of the article in the link too much, so I wrote 17 LOC).
Thanks a lot. That makes me calmer as even if V UI would stay with the archaic approach, it'll be at least an educated and fully conscious choice 😉. |
|
Re: streams, if V implements Go-style channels then streams could just be infinite loops grabbing values from one source and throwing them into a channel 😃 . |
|
I currently raised similar request/question on "streams/reactiveness" at one of the devs behind the pure Go UI lib Fyne and got a prompt answer they're currently implementing it. It's worth looking at as they took the simplest approach, which is very performant, still more or less easy to use and solves the problem rather idiomatically. Fyne supports both "using functions" and "using structs" approaches to building interfaces (the latter being closer to declarative approach and the former being closer to immediate mode though still being retained state). See also my suggestions how to improve the programmer's experience which might not apply to Go (as Go is limited in different ways), but might apply to V as V has e.g. templates. Let's see whether Fyne's "reactiveness" will apply also to layouting (e.g. interactive drag & drop of new widgets from stash to the user interface as well as removing already placed widgets and putting them back to a stash). @andydotxyz thoughts? |
|
Thanks for the reference :). I'm not sure what you mean regarding layout - responsiveness has so many different meanings ;). |
True, sorry for not being clear. Let's just take the following example. You're assigned a task to create a GUI window using just Fyne abilities which supports full layout change during runtime. This app uses about 30 different kinds of widgets (buttons, lists, combo boxes, radio buttons, sliders, tabs, multiline text input, etc.) and has about 500 widget instances in total at the start. Each widget does something meaninful (either contains other widgets or does some computation or fetching from DB etc.). The widgets have different sizes (about half of them fixed, the other half stretchy) and some initial (e.g. random) layout and nesting of widgets. The goal is to ensure the user can toggle an "editing mode" and during this mode drag & drop any widget to any place and the layout must place the drag & dropped widget at the desired place and accommodate everything around to the new placement of the widget while obeying constraints of "swallow" widgets (e.g. tabbing widget - if the dragged widget shall overlap the boundaries, then the dragged widget will first be slightly repositioned to the nearest place where there is no overlap). During "editing mode" can the user also arbitrarily remove widget instances (not just hide them, but really remove) and add new ones (by drag & drop from a special list of widgets). There is also a requirement to use Now, does
Something else - see above. |
|
Wow, this is a really complex use-case and I cannot imagine a common one. Fyne is optimised for, as I would imagine most user interface toolkits are), running developer-defined interfaces across various devices. There is no reason that this could not be done - assuming a flexible enough layout algorithm. I don't think this is something that the dataapi would be designed to solve. The aim of it is to have a UI that is easy to bind to, and react from, data of some sort (backend, user input etc). I can't see the common use-case to have mouse cursor or other widgets be the data source for a binding. |
Understood. It's good to know in advance, that bigger GUI apps (like Office or email clients or CAD apps or Blender-like apps or...) rather shouldn't use Fayne, because e.g. dealing with "fully user-customized toolbars" is not supported out of the box (probably still possible, but difficult). All these apps support UI customization, so I consider it standard, but it's fine that Fyne won't support them (at least not for now) as Fyne isn't (yet 😉) meant for such huge GUIs. |
|
If you wish to consider customisable toolbars then yes, of course it could be in scope - though we will need drag and drop support first. The example you illustrated was, in my opinion, something quite different. |
I meant my example as a generalized concept of these specific use cases like adding/removing buttons from a toolbar (by drag & drop) and then adding/removing the toolbar (again by drag & drop). But if you see any difference in the concept, feel free to elaborate - I'd like to understand your view. I noticed you mentioned layout as an issue, so let me clarify the task and assume we already have a magic layouting function 😉, which'll get as input a list of all widget instances, the currently drag & dropped widget instance, and the absolute coordinates where the drop happened (assuming the widget instances contain all relations to other widgets - e.g. an Excel cell content depends on content of other two cells; or an Excel cell width is determined by the width of the header cell). This function will update offset and dimension in each of the given widget struct instances as well as the nesting information (it's a tree). What I was talking about is though all the stuff around this magic function. This stuff around is to actually (dis)connect everything (user inputs, inter-widget dependencies, instantiation, disposal, ...) in a live ("reactive") manner and maintain all the state of the app - the magic layouting function is just a negligible fraction of the whole machinery. |
|
I guess it's hard to know if this is going to be supported or not. Fyne is based on outcome based use cases (focused on cross platform) rather than generalised concepts. |
Based on how such generalization works e.g. in Red (as mentioned above), I'd hypothesize that using such "generalized streams" (similar to
Didn't know that. Thanks for clarification. I'll then look forward to see how Fyne (and others) will tackle the ever growing universe of concrete use cases (currently those are e.g. foldables which is in essence very close to the "task" I described above). Either way keep the good work! |
|
I updated my comment to be a little more focused (now "outcome based use cases - focused on cross platform"). If you want to discuss more the design of our toolkit we'd happily welcome the chat in the #fyne channel of gophers Slack - or on our own GitHub issue tracker. Let's take the discussion off vlang's project :). |
|
For those interested, these libs are somewhat close to what I envision under streams/flows/live_variables/reactiveness/signals of samples:
|
|
To demonstrate the urge of needing streams/flows/live_variables/reactiveness/signals, feel free to take a look at what the following tools produce. |
|
Technical blog post about "live" widgets and how to implement them to achieve effortless "composition in time": https://potocpav.github.io/programming/2020/05/01/designing-a-gui-framework.html . I highly recommend reading it as it shows yet another simple to implement in mainstream languages approach to liveness. Author of the blog post divides the problem of UI library architecture into two orthogonal concepts. "Composition in space" (i.e. layouting, theming, etc.) and "composition in time" (liveness of all kind: reaction to user input, I/O input, timers, etc.). Unfortunately currently V UI focuses almost exclusively on "composition in space" which is actually the easier concept of the two to tackle. So far V UI almost ignored the "composition in time" and as @kahsa said in #31 (comment) it's about time to open this painful topic. |
|
@rcqls you spend a lot of time with V UI lately, so I think this might be of interest to you. About year and a half ago few French guys got an idea how to tackle the complexity of GUIs in a very different way than any other existing UI lib (that's not an exaggeration). The idea was to apply pure ECS (a readable example in C) architecture to (G)UI. I myself find the results pretty amazing - read about it in the great Polyphony paper and see the code. It's very small code-size-wise, it's readable, it's performant, it's parallelizable, it's multiplatform incl. web (no obscure dependencies), it's declarative (even more than the current V UI architecture!), it fits the V philosophy, it's rendering backend agnostic (it shall also support retained native UI widgets if someone will invest the time to create corresponding proxy structs and methods). And now the main programmer of Polyphony sketched how the future would look like and the first thing he mentioned was rewrite it in a different language. To me V UI seems like the best candidate, but we'd need to accept the fact, that it'd involve research work (i.e. trial & error) and not just "pure programming". Could you @rcqls maybe take a look at the Polyphony paper and sum up your thoughts on the idea of changing V UI architecture to ECS GUI (i.e. Polyphony-like architecture)? |
|
@dumblob Thanks for the link. After a quick reading of the beginning of the paper, I can't see how entities could be technically defined in v since it would require some kind of map[string]Component{} with Component a sum type of all kind of components. But dealing with Component as a sum type could be cumbersome. V does seem to have "dictionary" container with values of any type, like hash in ruby,, named list in R, and Object in js, map of Any in julia. Generally the reason is also that these kinds of containers are not really efficient because of the Any type value. Sum type is a possibility (with the constraint to predefined the long list of all component types) but dynamic casting should be applied whenever you use (connect or update) the component to the entity. Of course, it is a quick thought and answer and I may be wrong. P.S.: btw, why don't you participate in the development of v ui or an alternatif GUI on v ? |
|
Interfaces seem like the natural fit here; every Component could have certain methods and/or fields that make it a Component. Then you can have a |
|
My concern is that the GUI ToolKit is not that simple to begin with. |
I don't think so. Component as an Interface would have a worse problem with dynamic casting. |
I actually don't think this is needed at all. Just look at how ECS is implemented in C here (here a unique instance of an Entity is nonexistent - what is considered as Entity is a number which has the property, that it's a valid index into every existing array of Components - and there is such array for every single existing Component; of course there is one more array of bool values of the same length saying whether the Component exists or not to manage their lifetime; and yes those are sparse arrays but there are solutions & alternatives to that as seen e.g. in Flecs) and in Flecs. The same is possible in V and even easier. Sure, this does not implement Polyphony, but because Polyphony is pure ECS, it can be mapped to C easily (the paper also explicitly says Polyphony tries to be fully language-independent, so the principles are valid also elsewhere despite there is some "sugar" in Polyphony to showcase how some boilerplate can be cut down by using neat language features).
Time, time, time. Family & jobs (I'm not programming for living) is my priority. But I don't have the heart to see V community investing mamoth effort in something which is already obsolete. And V UI might actually be exactly this case in the light of ECS GUI.
Despite not knowing what you're referring to with "GUI ToolKit", I can only agree with you that developing any (G)UI library is not simple. Actually I'm certain it's on par (if not more) with complexity and "size" of developing a programming language. I was (one of?) the first person(s) who strongly discouraged V community from even thinking of yet another UI library development and I still am - especially considering the scarce resources which must first flow into the language itself and first after a "release candidate" will be released we might focus on unrelated libraries (such as V UI). There was even a period IIRC when V community loudly protested against major V devs spending quite some time with V UI instead of developing V itself. But hey, here we are, there are hundreds/thousands SLOC in V UI repo and I can't just passively sit and look at the struggling V community without at least tossing my gathered knowledge into the issue tracker during the very few minutes of my spare time I have every day. I prefer doing something for V and the people around it instead of spending the short time with reading newspapers or hanging out with friends.
No. My intention with ECS GUI architecture is much more radical. The current V UI architecture is not only messy but much more "undirected" - there is no vision, no unified design philosophy as you said, no clear bounds. At least there is a (huge) list of use cases & desired functionality. But I digress. So my idea is to completely rewrite V UI using ECS GUI architecture. But despite ECS GUI being IMHO extremely promising as a hollistic approach to UI (and I'm saying this for the first time in my life about a GUI), it's very novel, so the development wouldn't be just plain "implementing an existing standard" but rather cooperating with ECS GUI authors and trying out new ideas (i.e. research) pushing ECS GUI further to achieve a complete system at some point. E.g. the ECS GUI paper completely deliberately omits any layouting or visual specification. This will need to be researched from zero. |
|
Are you sure that the c example is not too simple. In the article not all
the entities are sharing all the components as it is the case in the c
example. In my first understanding each entity has its own subset of
components.chosen in the whole set of components. Otherwise it is memory
consuming. So I misunderstand something.... Thanks for your feedback. If
you have free time it could be motivating that you propose the drawing
example of the paper in V code.
Le sam. 5 juin 2021 à 17:24, dumblob ***@***.***> a écrit :
… @rcqls <https://github.com/rcqls>
@dumblob <https://github.com/dumblob> Thanks for the link. After a quick
reading of the beginning of the paper, I can't see how entities could be
technically defined in v since it would require some kind of
map[string]Component{} with Component a sum type of all kind of components.
But dealing with Component as a sum type could be cumbersome. V does seem
to have "dictionary" container with values of any type, like hash in ruby,,
named list in R, and Object in js, map of Any in julia. Generally the
reason is also that these kinds of containers are not really efficient
because of the Any type value. Sum type is a possibility (with the
constraint to predefined the long list of all component types) but dynamic
casting should be applied whenever you use (connect or update) the
component to the entity. Of course, it is a quick thought and answer and I
may be wrong.
I actually don't think this is needed at all. Just look at how ECS is
implemented in C here <https://gamedev.stackexchange.com/a/45329> (here a
unique instance of an Entity is *nonexistent* - what is considered as
Entity is a number which has the property, that it's a valid index into
every existing array of Components - and there is such array for every
single existing Component; of course there is one more array of bool values
of the same length saying whether the Component exists or not to manage
their lifetime; and yes those are sparse arrays but there are solutions &
alternatives to that as seen e.g. in Flecs) and in Flecs
<https://github.com/SanderMertens/flecs>.
The same is possible in *V* and even easier. Sure, this does not
implement Polyphony, but because Polyphony is *pure* ECS, it can be
mapped to C easily (the paper also explicitly says Polyphony tries to be
fully language-independent, so the principles are valid also elsewhere
despite there is some "sugar" in Polyphony to showcase how some boilerplate
can be cut down by using neat language features).
P.S.: btw, why don't you participate in the development of v ui or an
alternatif GUI on v ?
Time, time, time. Family & jobs (I'm not programming for living) is my
priority. But I don't have the heart to see V community investing mamoth
effort in something which is already obsolete. And V UI might actually be
exactly this case in the light of ECS GUI.
@kahsa <https://github.com/kahsa>
My concern is that the GUI ToolKit is not that simple to begin with.
Despite not knowing what you're referring to with "GUI ToolKit", I can
only agree with you that developing any (G)UI library is not simple.
Actually I'm certain it's on par (if not more) with complexity and "size"
of developing a programming language. I was (one of?) the first person(s)
<vlang/v#2065 (comment)> who
strongly discouraged *V* community from even thinking of yet another UI
library development and I still am considering the scarce resources which
must first flow into the language and first after a "release candidate"
will be released we might focus on unrelated libraries (such as V UI).
There was even a period IIRC when *V* community loudly protested against
major *V* devs spending quite some time with V UI instead of developing
*V* itself.
But hey, here we are, there are hundreds/thousands SLOC in V UI repo and I
can't just passively sit and look at the struggling *V* community without
at least tossing my gathered knowledge into the issue tracker during the
very few minutes of my spare time I have every day. I prefer doing
something for *V* and the people around it instead of spending the short
time with reading newspapers or hanging out with friends.
So, if we keep extending it ad hoc without a unified design philosophy
that runs through the whole thing, it may end up being as complex as GTK.
No. My intention with ECS GUI architecture is much more radical. The
current V UI architecture is not only messy but much more "undirected" -
there is no vision, no unified design philosophy as you said, no clear
bounds. At least there is a (huge) list of use cases & desired
functionality. But I digress. So my idea is to completely rewrite V UI
using ECS GUI architecture.
But despite ECS GUI being IMHO extremely promising as a hollistic approach
to UI (and I'm saying this for the first time in my life about a GUI), it's
very novel, so the development wouldn't be just plain "implementing an
existing standard" but rather cooperating with ECS GUI authors and trying
out new ideas (i.e. research) pushing ECS GUI further to achieve a complete
system at some point. E.g. the ECS GUI paper completely deliberately omits
any layouting or visual specification. This will need to be researched from
zero.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAC7D7URRP5UXFIUJ6G2JALTRI6SBANCNFSM4KF2CD7Q>
.
|
I think you're understanding it correctly. Some observations though:
I'll think about it (might take weeks/months when it comes to finding time to write code - so do not wait for me and feel free to try it yourself any time sooner). |
I'm sorry for misleading you. I also think that easy extensibility of existing components is important for GUI development. |
Me neither 😢. That's why we're having this discussion 😉.
Well, this might be misunderstanding. Extending existing Components ("C" in ECS) in an ECS GUI is a no-go. The point is, that Components resemble 1st normal form (in database terms 😉) and extending them would almost for sure break this normalization. So in ECS one always "extends" by adding new Components and nearly never touches an existing Component. And even in cases when it would make sense to extend an existing component, it's better to introduce a new separate one. It's because existing Systems ("S" in ECS) closely depend on Components, their size, memory layout, etc. So making them bigger would certainly brake something at least subtly (e.g. invisibly like making the former performance worst case even worse).
Well, in case of ECS the problem doesn't even exist as demonstrated above 😉. So no need to worry about anything like that. ECS is really fully composable on its own already at the "model level" without relying on any "implementation level" technological/language features. A linguist would say, that despite natural languages are shaping our concept thinking (and thus the concepts are inherently dependent on the particular natural language features - this is the case of OOP), ECS wasn't shaped by any language, but objectively determined based on observation of patterns in game industry. So ECS is a pretty artificial concept, but it makes it also fully language independent 😉.
Hm, I actually don't think so. I think it's much more due to GUI libs being really hard and time consuming to develop. And both Go & Rust are too new to allow for a mature full-size GUI library - simply because there wasn't enough time for that 😉 (assuming non-ECS GUI libs because it seems to me ECS GUI libs might be quicker to develop once the "1st normal form" of most GUI features is found by researchers). Additionally ECS is much more language agnostic than majority of other GUI systems I know of.
That's an interesting idea. For ECS there is not much boilerplate even in lower-level languages like C (as Flecs demonstrates). Despite that authors of Polyphony actually recommend using language features to make ECS programming more friendly and less "strict". Still IMHO V is in a better position with regards to ECS than C/Go/Rust/Zig/... with its current set of features and quite minimal syntax, so I'd first start with using pure V and if there will be any point where repeating boilerplate would become apparent, we could think about a tiny DSL (like for SQL, etc.). |
|
@dumblob Thanks for this clarification about memory efficiency. However you need to multiply by the mean size of component. But the idea of matrix crossing entities and components (that can be sparse) is very informative. Also I have ended up a first quick reading of the article and ECS is very interesting. I'll try to propose a version of ecs in |
|
@dumblob flecs is huge and then not simple to translate in pure v since a lot of c tricks seem also to be used. My first attempt to define a world struct embedding entities and components failed in v because |
|
Editable data grid, like Excel or Access. |
|
@dumblob After some fight 😁, I managed to have a first version of vecs with world, entities and components. But it is of course very basic. import vecs
import gx
fn main() {
mut world := vecs.world()
world.new_component("comp1",vecs.comp1_map(world))
world.new_component("comp2",vecs.comp2_map(world))
world.new_entity("tutu")
world.new_entity("titi")
vecs.comp1(world).set("titi",vecs.Comp1{})
vecs.comp2(world).set("titi",vecs.Comp2{})
vecs.comp1(world).set("tutu",vecs.Comp1{gx.rgb(10,10,10)})
mut c1 := vecs.comp1(world).get("titi") ?
c1.color = gx.rgb(20,0,0)
vecs.comp1(world).set("titi",c1)
println(vecs.comp1(world).get("titi") ? )
}What was funny, I called |
|
Wow, you're quick! This V ECS lib looks promising to me! Today I got an email pointing me to this small list of features which are difficult to achieve in Unity (many have mentioned Unity to have one of the best - if not the best - UI toolkits to work with). It all boils down to the dynamicity & interaction (incl. advanced/free-form animations) as thoroughly discussed in this thread as well as in others. ECS is a viable answer IMHO. I'll see if I'll find some time after I return from abroad in about a month. |
|
Those advocating for Flutter-like functionality should definitely see this example. And those who don't (incl. me 😉) should take a look at these examples (this might be enormously interesting for V because VUI wanted to use native widgets which didn't happen yet - but these examples show it's possible to do and in a modern manner!). |
Please implement 7GUIs (and possibly the extended proposals) as soon as possible to get deeper understanding how complicated/easy the use of this UI library will be (before the API stabilizes) and to give others a good overview.
The text was updated successfully, but these errors were encountered: