search

vlang / ui

A cross-platform UI library written in V
MIT License
2.33k stars 153 forks source link

Version 0.1 Roadmap #31

Open thecodrr opened 4 years ago

thecodrr commented 4 years ago

Many features will need discussion so this thread acts as both a discussion & a task list for contributors/maintainers.

Notes:

  1. All these features won't necessarily make it into the v0.1 but they are planned nonetheless.
  2. Mentions after the each entry means that feature is being worked on by those persons.
  3. Please don't ask for ETAs. We are working on it as much as possible. Once it's done, you will know. You can follow the development on the Discord Channel.

API

Window API

Responsiveness

Layout

Widgets

TextBox

Accessibility

More items will be added as required

hex2f commented 4 years ago

I feel like animations/transitions are pretty important in modern software as well. Add it to the list?

dumblob commented 4 years ago

Proper eventing system using eventbus instead of the current struct Fn fields.

This might be solved automatically by implementing everything as generic streams.

ryandavs commented 4 years ago

For the lay out manager of components, please consider also looking at the imperative programming style of MigLayout API. It's small easy-to-read tutorial/manual is enough to give you an overview of its entire API. http://www.miglayout.com/

elimisteve commented 4 years ago

For the lay out manager of components, please consider also looking at the imperative programming style of MigLayout API.

Does this have advantages over just using flexbox?

lazalong commented 4 years ago
thecodrr commented 4 years ago

@lazalong

Render or Viewport Widget

We already have Canvas which does basically the same thing.

origel commented 4 years ago

Good job! Can you give an approximate completion time? I insterest in v lang and I want dev cnc controll software using vui.

thecodrr commented 4 years ago

Good job! Can you give an approximate completion time? I insterest in v lang and I want dev cnc controll software using vui.

@origel No ETAs please.

hex2f commented 4 years ago

@thecodrr you can put me on animations, transitions are already merged

hex2f commented 4 years ago

I’m also looking at implementing a scrollview but no guarantee that I’ll be able to pull it off

thecodrr commented 4 years ago

@memeone I will move on to ScrollView after the new API is merged. If you want to take it, I will look at something else.

hex2f commented 4 years ago

@thecodrr you can take it, maybe I’ll look at styling or hover feedback instead 🤔

thecodrr commented 4 years ago

@memeone okay awesome.

origel commented 4 years ago

@thecodrr I want implment some layout just like FillLayout，FormLayout, RowLayout and GridLayout in SWT, if vui is added layout function, vui can be used to develope actual software. But I have no idea if it is needed. and the layout description in 0.1 roadmap I don't know what does it mean, can you give me some suggestion？ What can I do to make this project move faster？

thecodrr commented 4 years ago

@origel I have already implemented 2 layouts: ColumnLayout & RowLayout. You should try it out.

naturalmechanics commented 4 years ago
  1. Tabs (mentioned above)
  2. Framebuffer (is canvas the same? )
  3. Map / Cartography / Webdata visualizer
  4. Dials, guages, windrose, clock...
  5. Charting widget
  6. Rich text

is the codebase of V in C? how can i write my own custom widgets and contribute?

hex2f commented 4 years ago

V is written in V, the main repo can be found at https://github.com/vlang/v

Creating new widgets is quite easy, you can look at rectangle.v and label.v in this repo for some simple reference implementations.

fxqy commented 4 years ago

Will the lambda expression be added? Hope to be like kotlin anko's ui dsl

Keyn1 commented 4 years ago

Add MDI (Multiple Document Interface)

smartiniOnGitHub commented 4 years ago

Years ago I implemented in a Java UI framework the ability to disable animations and transitions, sometimes (on old/poor hardware and some kind on users) they are not needed ... maybe you could add here even a similar feature, but of course by default enabled :-) . Bye

iampato commented 4 years ago

A navigator widget could be nice

hex2f commented 4 years ago

@lampato don’t really know what you mean by “navigator widget”. Do you have any examples? I’m gonna start trying to implement a few more widgets soon :)

medvednikov commented 4 years ago

file dialogue probably

iampato commented 4 years ago

@leahlundqvist a widget to navigator to/for a page with twists!!

xiusin commented 4 years ago

webview webview!!!

benstigsen commented 4 years ago

It would also be nice to have a font_path option. And since multiline_textbox is on the roadmap, it would make good sense to have a text.v file dedicated to the text calculation, width, wrapping, etc... functions.

ghost commented 4 years ago

Is tab-handling (in the meaning of navigation from control to control) already in the pipeline? When trying examples/users.v this was the first issue I was missing.

medvednikov commented 4 years ago

yes @vmcrash, I've added it to the roadmap

dedesite commented 4 years ago

Maybe also having some documentation would be something needed no ? Because I can't find any api doc, tutorial or something else...

serkonda7 commented 4 years ago

@dedesite currently you have to look at the examples or in the widget source codes directly. Currently the main focus is on stabilizing V. After that UI will get some love too and it will get some docs for sure ;)

dedesite commented 3 years ago

@serkonda7 Ok thanks. Tried the different examples, it seems pretty bleeding edge in deed :)

ghost commented 3 years ago

Context Menu

Polydynamical commented 3 years ago

Maybe add support for different cursors?

annymosse commented 3 years ago

as i noticed dartlang has no huge lovers until google team implement flutter which added a huge spot on dart language, and the success of flutter was related to it's widget system if we make everything above widget it will be easier to maintain and improve the framework even add more contributors form other communities .

Derad6709 commented 3 years ago

What about file pick button?

Nv7-GitHub commented 3 years ago

Are native widgets going to come with this release?

benstigsen commented 3 years ago

Are native widgets going to come with this release?

No, the point of UI was never to provide native widgets I think. If you mean widgets that look native, I don't think so since it requires some pretty advanced theming. By providing the same kind of UI on all platforms it simplifies VUI development a lot.

Nv7-GitHub commented 3 years ago

Will it ever support using native widgets? Like using Cocoa on mac, WinAPI on windows, GTK on Linux? Something like https://github.com/andlabs/ui ?

ghost commented 3 years ago

There is no concrete movement in ui module. But there seems to be something about native ui in Alex's mind.

ghost commented 3 years ago

If you need GTK you can use https://github.com/vgtk/vgtk3

Nv7-GitHub commented 3 years ago

GTK is only native to linux, not Mac or Windows. So far andlabs/ui and QT seem to be the only UI libraries that look and feel native, although andlabs/ui is missing some extremely basic and necessary UI elements and QT is really heavy and kind of convoluted. Will ui ever get native look and feel? Is it part of the roadmap at any step?

mklhmnn commented 3 years ago

Please also look at Java: SWT, the GUI library of Eclipse and other application is using native widgets on all platforms.

esquerbatua commented 3 years ago

A great objective will be create docs of V UI

elimisteve commented 3 years ago

@medvednikov Some version of auto-layout would be interesting so we can ditch CSS forever! Constraint CSS would let us specify constraints that a constraint solver would solve rather than doing the bullshit that CSS requires today.

Video about GSS, which takes the ideas of Constraint CSS and Apple's new-ish VFL (Visual Format Language): https://vimeo.com/91393694

A detailed version of these ideas from 1999: https://constraints.cs.washington.edu/web/ccss-uwtr.pdf

Apparently Apple lets, or at least let a few years ago, its developers do similar things using its Visual Format Language: https://developer.apple.com/library/archive/documentation/UserExperience/Conceptual/AutolayoutPG/VisualFormatLanguage.html

dumblob commented 3 years ago

@elimisteve this has been touched upon earlier but proved to be worse than hand written "dumb" CSS unfortunately. This problem seems to stem from the fact that the underlying linear constraint solver - mostly Cassowary - works best if used in a "global" context, but that's a lot of tedious work and thus most if not all Cassowary-based layouting engines chose to introduce scopes and subscopes forming a tree which on the other hand greatly diminishes the advantages Cassowary brings.

Probably the best implementation of Cassowary used in thousands of high-stake products nowadays is Python ENAML.

But IMHO all existing Cassowary solutions I know of are really wrong in two things. First they suppose widgets, widget groups, etc. will not come & go during runtime. Second there is no first class support for other transformations (rotation, skew, ..., and thus nothing high-level like easing, ...) and no support for 3D (despite the Cassowary algorithm on it's own does fully support 3D). And that's a no go in current times full of animations, user-buildable (not any more just user-adjustable) user interfaces, dynamic content widgets, apps auto-accommodation from a smartwatch/notification_widget to smartphone screen then to foldable smartphone screen then to tablet screen then to foldable netbook/notebook screen and finally to a desktop version (on big LCDs/TVs).

No Cassowary (or alike) library supports this. Extending such a lib seems easy on the first sight (just adding and removing new linear formulas into/from the solver formula list) but creating a usable high-level API for programmers (and at the same time designers who use e.g. Figma or alike) is hard and very tricky. Don't forget Cassowary itself deals only with size and dimensions but in practice one needs API seamlessly supporting "constraint solving" of at least all affine transformations needed for general use cases - e.g. rotation, skew, etc. Then you have to introduce the concept of time to Cassowary which is also very new. And suddenly you end up with huge constraint solver with unmanageable API.

Maybe that's the reason nobody tried that yet and everybody rather sticks with the mixture of imperative animations "spaghettied" together with declarative "checkpoints" and "easing/... in between" like Flutter and HTML5 do.

All in all I'm strictly against Constraint CSS, Apple's Visual Format Language, and all other existing constraint-based solutions as of today.

I'm though not against inventing a new solver offering all the capabilities mentioned above (worth reading but still far from enough: http://iamralpht.github.io/constraints/ ) and being efficient (actually Apple argumented that they don't push their Cassowary implementation any more because it's too slow/noninteractive & power_hungry).

elimisteve commented 3 years ago

Proved to be worse according to who?

dumblob commented 3 years ago

Proved to be worse according to who?

E.g. Apple.

But you don't need to seek only "proof by giants". I mean ask designers you have around and you'll find out yourself easily - they laugh at how low level constraints are and how much tedious work it is. It doesn't scale at all in the current state of being. That's why I said I'm not against inventing something new encompassing the whole thing and not just one tiny subset as current Cassowary solutions do.

elimisteve commented 3 years ago

I mean ask designers you have around and you'll find out yourself easily - they laugh at how low level constraints are and how much tedious work it is.

The exact opposite is true. Design tools like Figma let you set constraints, and those are a joy to work with; designers love that "auto-layout" feature. By contrast, trying to get CSS to do what you want is a gigantic pain every single day, as CSS is dramatically lower level than simply saying #thing[center] = #other[center], or specifying other such constraints.

The performance penalty of the constraint solvers I've seen so far is real indeed; hopefully more efficient ones exist and can be implemented, because CSS is the single worst-designed technology I have ever touched.

dumblob commented 3 years ago

I mean ask designers you have around and you'll find out yourself easily - they laugh at how low level constraints are and how much tedious work it is.

The exact opposite is true. Design tools like Figma let you set constraints, and those are a joy to work with; designers love that "auto-layout" feature.

Are we talking about the same thing? Designers love Figma (as I wrote above) because it doesn't do Cassowary-like constraints, but a negligible subset of similar functionality. If designers needed to use Cassowary-like constraints for most of their work, they'd go crazy (I meant it literally when I said go ask them - or at least read some blog posts about advanced layouting using constraints and everybody will tell you they need something much more high level otherwise they'll rather stick with the braindead CSS because despite all its enormous downsides it still comes as the winner from this match :cry:).

Let me paraphrase - if programmers were forced to use assembly nowadays for most of their work, they'd lough at me proposing this. They'll rather use PHP or Visual Basic or Delphi instead despite all the enormous downsides these languages have today.

Assembly has the maximum expresiveness our machines offer - same goes for the Cassowary technology (I'm deliberately not saying Cassowary implementations here because of them being rather "PHP"-like instead of "V"-like when it comes to usability and friendliness and overall usefulness). But there is no implementation with high level API which even approaches practical usefulness due to different shortcomings (find most of them outlined in my previous posts).

By contrast, trying to get CSS to do what you want is a gigantic pain every single day, as CSS is dramatically lower level than simply saying #thing[center] = #other[center], or specifying other such constraints.

The performance penalty of the constraint solvers I've seen so far is real indeed; hopefully more efficient ones exist and can be implemented, because CSS is the single worst-designed technology I have ever touched.

Here we univocally agree :wink:.

ghost commented 3 years ago

For 0.1, we need to review and complete the basics such as tab stops, event handling issues, and so on first. Then next step for widgets.