Unfortunately there is no UI designer or editor for YaST dialogs. All dialogs are hand crafted in Ruby code. The idea of this project is to provide some way how to create or edit the existing dialogs in a user friendly way, without touching any code.
The advantage would be that even people with no programming skills could help us to design new dialogs or to improve the existing ones.
Also changing the existing dialogs would be easier because you could interactively fine tune the dialog layout. Currently you have to start the YaST module, check the UI, guess how to update the code, update it and start the module again to see the result.
The work for the designer team could be easier as well. The YaST UI is quite limited, the same dialog needs to work in text mode as well, and the limitations are usually not known to designers. That means the designers can easily propose a solution which we are unable to implement in the YaST UI.
With a designer tool they could try and see what is possible, they could easily see the results immediately.
YaST Dialog Spy
Actually the YaST UI implements some kind of UI inspector already, if you press the magic combination Ctrl+Shift+Alt+Y
you will see this Spy dialog:
You can see the structure of the currently displayed dialog and see the properties of the widgets. If you select a widget in the tree it will be highlighted in the dialog (using orange background color).
However, it works only in the read-only mode, you can see the widgets and their properties but you cannot change anything.
Proposal
This project is about implementing that missing editing functionality. The main idea is to reuse the already existing code and improve the spy dialog so it allows also changing the UI. There is a proof of concept code which adds a Delete
button for removing the selected widget from the dialog:
TODO
The UI "designer" should be able to
- Remove the existing widgets (already implemented in the preview)
- Edit properties of existing widgets (enable/disable, change the label,...)
- Add new widgets (the functionality depends on the context, only container widgets can contain child widgets)
- Move the widgets (initially probably only inside the parent container, if that's actually possible)
To permanently save the changes we will need add some kind of export. The idea is to dump the widget tree into a file and load it later.
- We could simply save a Ruby file with YaST code so you would just run the saved file.
- Alternatively we could save the dialog structure in a common data format (XML, YAML, ...) and implement a loader which would load the file and create the widgets accordingly.
The advantage of the latter solution is that we could move the UI definitions from the code to data files. On the other hand it would be difficult to define UI dependent content there.
This project is part of:
Hack Week 14
Activity
Comments
-
over 8 years ago by locilka | Reply
Your idea about the designer has basically three items:
- Use different source for views (XML, YAML, ...)
- Extend the Tree View into an Editor
- Add an Export functionality into the very same format as for views
This is a great idea, but you might need someone to help you with that :) Some kind of advert might help...
-
over 8 years ago by jreidinger | Reply
I have same idea few years ago and in the end I found that the easiest way is to have something like sass for yui and it result in https://github.com/libyui/ruby-ui/blob/master/examples/mvc/views/user/index.yui which is easy enough to be showed as mockup only without any functionality and also enough to be understand. So as source for views I suggest to use that format. BTW I have somewhere also working concept of its usage in yast itself.
Similar Projects
Design the new UI for storage configuration at Agama by ancorgs
Description
We are in the process of re-designing the web user interface to configure storage at Agama. We expected to have a clear idea of what we wanted before starting Hack Week. But the idea is still not that clear. So I will use use my Hack Week time to try several prototypes since I really want this to be done.
Goals
Have a prototype using Patternfly components and addressing all the use-cases we want to cover. Easy for the easy cases. Capable for the complex ones.
New openSUSE-welcome by lkocman
Project Description
Let's revisit our existing openSUSE welcome app.
My goal was to show Leap 16 in a new coat. Welcome app adds to the first time use experience. We've recently added donation button to our existing welcome.
Some things that I recently wanted to address were EOL and possibly upgrade notification.
I've already done some experiments with mint welcome app, but not sure if it's better than the existing one.
There is also a PR to rework existing app https://github.com/openSUSE/openSUSE-welcome/pull/36 (this should be considered as an option too)
Goal for this Hackweek
New welcome app, possibly with EOL notification for Leap.
1) Welcome application(s) with (rebrand changes) maintained under github.com/openSUSE
2) Application is submitted to openSUSE:Factory && openSUSE:Leap:16.0
3) Updated needles in openQA (probably post hackweek)
Resources
Reddit discussion about the best welcome app out there.
Github repo for the current welcome app.
Finish gfxprim application multiplexor (window manager) by metan
Project Description
I've implemented drivers for a few e-ink displays during the last hackweek and made sure that gfxprim widgets run nicely on e-ink as well. The missing piece to have a portable e-ink computer/reader/music player/... is a application that can switch between currently running applications and that can start new applications as well. Half of the solution is ready, there is a proxy gfxprim backend where applications render into a piece of a shared memory and input events (e.g. keyboard, mouse) can be multiplexed. What is missing is an interface (possibly touchscreen friendly as well) to make it user friendly.
Goal for this Hackweek
Make nekowm usable "window manager".
Resources