Version 0.1 Roadmap
thecodrr opened this issue · comments
Many features will need discussion so this thread acts as both a discussion & a task list for contributors/maintainers.
Notes:
- All these features won't necessarily make it into the v0.1 but they are planned nonetheless.
- Mentions after the each entry means that feature is being worked on by those persons.
- 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
- Declarative style (@thecodrr)
- Hot code reloading
- Proper eventing system using
eventbus(@thecodrr) - RTL support
- Themes
- Custom widgets on user level
- DataBinding to arrays & orm columns
- Widget customization using properties (color etc.)
Window API
- Drag & Drop
- Custom Scaling
- Resizing
Responsiveness
- Relative values for dimensions, margins etc. (percentage or px)
- Hover, focus feedback
- Animations & Transitions (@memeone)
- Tab support (focus)
Layout
Widgets
- Menus
- ScrollView (@thecodrr)
- ListBox
- ListView
- DataGrid
- Tab Control
- WebView
- Slider (@thecodrr)
- Dropdown (@thecodrr)
- Tooltips
- TreeView
TextBox
- Multiline textbox
- Text selection with a mouse (@thecodrr)
- TextBox Validation
- Format support
Accessibility
- Screen reader support
More items will be added as required
I feel like animations/transitions are pretty important in modern software as well. Add it to the list?
Proper eventing system using eventbus instead of the current struct Fn fields.
This might be solved automatically by implementing everything as generic streams.
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/
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?
- Render or Viewport Widget (aka direct access to the display memory to stream video or render frames from a game)
- Right-Left text editing direction (Arabic, Hebrew, Urdu...)
- Drag-and-drop (i.e. filename or whole path+filename)
- Tabbed widget
- Resizeable widget's borders
- Dockable widget or windows
- Inability to drag or put a widget/windows completely outside of screen view !!! Perhaps with a recenter event.
- Fullscreen command for widget
- Prefilling forms (perhaps this can be done with events)
- Zoom
- Color selector widget
Good job! Can you give an approximate completion time? I insterest in v lang and I want dev cnc controll software using vui.
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.
@thecodrr you can put me on animations, transitions are already merged
I’m also looking at implementing a scrollview but no guarantee that I’ll be able to pull it off
@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.
@thecodrr you can take it, maybe I’ll look at styling or hover feedback instead 🤔
@memeone okay awesome.
@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？
@origel I have already implemented 2 layouts: ColumnLayout & RowLayout. You should try it out.
- Tabs (mentioned above)
- Framebuffer (is canvas the same? )
- Map / Cartography / Webdata visualizer
- Dials, guages, windrose, clock...
- Charting widget
- Rich text
is the codebase of V in C? how can i write my own custom widgets and contribute?
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.
Will the lambda expression be added? Hope to be like kotlin anko's ui dsl
Add MDI (Multiple Document Interface)
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
A navigator widget could be nice
@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 :)
file dialogue probably
@leahlundqvist a widget to navigator to/for a page with twists!!
webview webview!!!
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.
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.
yes @vmcrash, I've added it to the roadmap
Maybe also having some documentation would be something needed no ?
Because I can't find any api doc, tutorial or something else...
@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 ;)
@serkonda7 Ok thanks. Tried the different examples, it seems pretty bleeding edge in deed :)
Context Menu
Maybe add support for different cursors?
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 .
What about file pick button?
Are native widgets going to come with this release?
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.
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 ?
There is no concrete movement in ui module. But there seems to be something about native ui in Alex's mind.
If you need GTK you can use https://github.com/vgtk/vgtk3
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?
Please also look at Java: SWT, the GUI library of Eclipse and other application is using native widgets on all platforms.
A great objective will be create docs of V UI
@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
@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).
Proved to be worse according to who?
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.
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.
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 😢).
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 😉.
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.
Also moving to a non *GPL license should be considered.
Some background :
- The GUI is a corner stone for the developper's experience. GO has failed in this section.
- 70% of the code we write at my company is App / UI side ...30% is server
- Those days we do programing for web and app, and there has been this challenge of beeing able to do both...
- We now have to take care of front and back dev to build something valuable....we usually end up with two ROUTINGS to organise the code : one for the API/server and one for the App. (I use meteor.js which solves some of those)
Questions :
1- How do we handel routing on the App side ? Is it part of a core package ? Is it correlated to UI ? Do we have a comon routing schem as with vweb ? (yes;) )
2 - Can we imagine compiling the UI library to wasm ? Can we have it interact with the DOM ? How ? Do we even need the DOM if we render opengl ?
- FileChooser
- ColorChooser
- Date 、Time and Number picker
- FlowLayout
- LazyListView
- LoadingView
- Tooltip
- Alert Box
- Dialog Box
- Animation API
- Touch, keyboard and mouse events API
- View shapes, shadows API
- Audio/Video Multimedia Operation API
- Background tasks API
- Print API
- Device access (Wifi, Bluetooth, USB, NFC...) API
- Log API
- Privacy and Security API
- Support character sets other than ASCII
- Examples and documentation
Also moving to a non *GPL license should be considered.
Why?
Because it's copyleft. Meaning it can only be used by open-source projects. So if I use V UI, my app also has to use GPL.
Or you have to pay for a license, which is the intent here, I believe. Finding ways to monetize V is really important for the sustainability and longevity of the project! Paying a bit in order to be able to create one graphical app in V + V UI and have it run everywhere would be an amazing deal.
Or you have to pay for a license, which is the intent here, I believe. Finding ways to monetize V is really important for the sustainability and longevity of the project! Paying a bit in order to be able to create one graphical app in V + V UI and have it run everywhere would be an amazing deal.
It would be the beginning of the end to start pulling that and trying to force licenses, because there is already highly developed open-source competition. Look at the many Go GUI projects, for example. It would also be against the spirit and perception of how V is viewed, thus sending people away. The rest of V is MIT, so people expect for V UI to go that direction too (and has promised to do so). Debatably better to stay open source and go the donation route.
The plan was to use MIT later. This current one is temporary.
There are many projects under V umbrella which is *GPL which is irksome.
I am assuming that many of these are temporary as well.
Or you have to pay for a license, which is the intent here, I believe. Finding ways to monetize V is really important for the sustainability and longevity of the project! Paying a bit in order to be able to create one graphical app in V + V UI and have it run everywhere would be an amazing deal.
It would be the beginning of the end to start pulling that and trying to force licenses, because there is already highly developed open-source competition. Look at the many Go GUI projects, for example. It would also be against the spirit and perception of how V is viewed, thus sending people away. The rest of V is MIT, so people expect for V UI to go that direction too (and has promised to do so). Debatably better to stay open source and go the donation route.
Maybe we want to create another issue or thread to discuss this topic. My personal feeling is that :
- If people working on this projet wants to get funded for their work, that makes perfect sens. It s their choice.
- The community is building itself on its own values, "sending people away" is inevitable. And its good to have many projects for many different minded people out there.
- Finally its open. I suppose there is no opposition from the V community for another GUI project that would fite your licensing needs. Innovation is kinda darwinian, lets see ;)
There are many projects under V umbrella which is *GPL which is irksome.
I agree that GPL is like Pandora's box. When going that direction, it looks to just as easily destroy or confuse, as it can also help and preserve. It's a matter of people knowing what they are doing, and the full consequences and ramifications that go along with it.
GPL isn't always bad, per se. For example in the case of V's Gitly, it's not likely anybody would be or want to be using it as a whole commercially or professionally. Rather, they use it to do tasks, not necessarily wanting to re-package it into anything. So there isn't as much concern that it's GPL, other than consistency with other V projects which are MIT (which how it looks is a concern). For example, a person may use a GPL project like NotePad++ to create files, but likely not need or want to use it directly for anything.
However, things like programming languages and UIs have a different usage. People would be very much incorporating them into their projects. People very much want to use them professionally or commercially. If TCC (which V uses) was GPL, it would create absolute havoc and confusion, thus they had enough sense to put it under at least LGPL.
A comparable project to V UI, would be one of Go's cluster of UI projects such as Fyne (github.com/fyne-io/fyne), which they smartly put under BSD, and not GPL. Most other open source programming language UI projects are under more permissive licenses such as LGPL, BSD, Apache, or MIT. Often in these days of open source competition, if they were or are commercial, they started that way (not switch up on their users). In various cases many commercial projects have ended up as free open source anyway, as were defeated by all the strong and free open source competitors that exist now.
Another aspect of this is the expectation of users. There is the perceived promise by V UI, "At some point in the future the library will be relicensed under MIT." So clearly people are going to feel some kind of way if that promise is broken.
Seems like better moves for projects which are and have started open source, would be to:
- Ask for donations (like make it apparent)
- Seek corporate sponsors (not be passive, and go ask)
- Write books/ebooks on using V UI and building GUI's the V way (advertises V/V UI and sponsors; stirs general interest)
- Make videos teaching V UI and put on places like Udemy
Quite sure supporters and interested people would buy a V UI ebook or training video. Very much liked "Getting Started with V Programming" from Packt.
Textbox adds copy-paste support for mouse or keyboard
For WebView, you might look into the C Bindings for webview
I don't know exactly how you will be able to embed it into the UI framework, but it's probably the right starting point. A weakness of this solution is that it adds a dependency to the build output, but you would likely have that for any implementation of webview unless you built your own HTML/JS/CSS engine.
An alternative that may be more difficult is Mozilla's Servo browser. This could potentially have rust libraries that could be exported as C Shared libraries and imported by V. I'm not loving that idea, but it might be an option.
Please update to show the completed features so we know what to focus on.
For WebView, maybe a V based https://tauri.app/ instead of Rust?
Any update for web views?
I’m a web developer and I don’t like using Electron and Tauri.
Is there a V project for cross platform web rendering?
I like how V UI is going (SwiftUI style) but I would like to use a WebAPP as rendered app and V to implement app core functions as native.
@Bellisario What do you think of Wailes ? I think it's fine, until vui is ready
Thanks @bashery! I definitely need to give it a try...
Hello all,
Thank you for your effort thus far. My question is this, is there ANY .... any way at all ...... to track this roadmap in some more detail? I'm faced with the decision whether it is feasible to choose V as the right platform for our stack, and I really really want to choose V.
Can we have this roadmap put in as Projects? I could help with that.
I know that I can make it go faster by contributing with code, and thats on my roadmap as well. :)
Databinding functionality and widget reactivity model.
I hope you will allow cursor blinking to be switched off application-wide (why). Qt and Gtk support this and Tk 9.0 will also.
I hope you will allow cursor blinking to be switched off application-wide (why). Qt and Gtk support this and Tk 9.0 will also.
Already done :)