Mailinglist Archive: yast-devel (177 mails)

< Previous Next >
Re: [yast-devel] WebYaST will help the openness
On Tuesday 15 February 2011 12:34:01 Johannes Meixner wrote:
Hello,

On Feb 15 09:03 Jiri Srain wrote (excerpt):
Actually, this leads to one requirement on the overal architecture,
which was mentioned couple of times already:
To have a back-end providing the business logic with a reasonable
high-level API, on top of which both YaST and WebYaST
can provide their UIs.

At least for me it is the topmost feature which YCP provides
what helps me to make a tool for my particular config task:

One language where I can describe the UI independent from the
various actual user-frontends (ncurses, Gtk, QT).


But even YCP does not provide sufficient high-level functions
to describe the UI really easily.

Too often I need to care about screen layout details and
screen space limitations.

I would like to have a language where I only need to describe
the logic of the UI but not which actual helper-widgets are used
to show a layout.

Well, you must make the decission: You can have three different back-ends and
describe the UI once (that's what we do for classical YaST) or you must
describe the UI three times.

Both approaches have their pros and cons. Currently you really need to do some
fine tuning so that the dialog can work with bots text-mode and graphical
interface, and it prevents you from using the full strength of the Qt/Gtk
libraries, but you can code each dialog only once. Given similar philosophies
behind all desktop environments, for the end user the same dialog fits in all
three environments.

For WebYaST we decided to implement the GUI from scratch. It may sound like an
overhead in the context of classical YaST (three or four UIs, what's the
difference?), but allows to create a real web application, use fully the
possibilities which web allows and match the expectations of web user.

Jiri



For example - as far as I know - YCP does not support to describe
how UI elements are "grouped" logically together.


Assume one particular sub-task of the whole config task
is to let the user enter two keywords with values.

Currently the code looks basically like this:
-------------------------------------------------------------------
InputField( "First keyword:", keyword1 )
InputField( "First value:", value1 )
InputField( "Second keyword:", keyword2 )
InputField( "Second value:", value2 )
PushButton( "Store keywords and values" )
-------------------------------------------------------------------

To get the layout, every module author decides on his own
which additional helper-widgets should make it look nicer.

E.g. one module author likes labeled frames with border lines
together with a strice vertical layout:
-------------------------------------------------------------------
Frame( "Keywords and values",
Frame( "First keyword and value",
Vbox( InputField( "keyword:", keyword1 ),
InputField( "value:", value1 )
)
)
Frame( "Second keyword and value",
Vbox( InputField( "keyword:", keyword2 ),
InputField( "value:", value2 )
)
)
PushButton( "Store keywords and values" )
)
-------------------------------------------------------------------

But another module author may perfer spacing plus separate labels
and a more horizontal layout:
-------------------------------------------------------------------
Vspace()
Label( "First keyword and value" )
Hbox( InputField( "keyword:", keyword1 ),
Hspace(),
InputField( "value:", value1 )
)
Vspace()
Label( "Second keyword and value" )
Hbox( InputField( "keyword:", keyword2 ),
Hspace(),
InputField( "value:", value2 )
)
Vspace()
PushButton( "Store keywords and values" )
Vspace()
-------------------------------------------------------------------

The result are YaST style guides which try to tell
all those module authors what the right way is in YaST.


I would like to describe only the logic of the UI elements
and leave the actual layout to an automatism like:
-------------------------------------------------------------------
Group( Label( "Keywords and values"),
Group( InputField( "First keyword:", keyword1 )
InputField( "First value:", value1 )
),
Group( InputField( "Second keyword:", keyword2 )
InputField( "Second value:", value2 )
),
PushButton( "Store keywords and values" )
)
-------------------------------------------------------------------
Looks very much like using "Frame" but the difference is that
"Group" is not a widget but describes only the logic
and is translated into whatever kind of widgets or layout style
which matches to a particular user-frontend.

If the particular user-frontend is narrow, the elemets could be
shown underneath each other with an optional vertical scroll bar
(like longer web-pages in a browser).

If the particular user-frontend is wide, certain elemets
could be also shown beneath each other (in particular
the keyword/value InputField pairs).

If the space on a particular user-frontend is very limited
so that not all elemets fit into one screen, it would be known
where the stuff could be automatically split without disrupting
the logic too much.


In the end I have something like the automatic layout of TeX in mind.

Of course I know that there is not the needed manpower...


Kind Regards
Johannes Meixner

--
Regards,

Jiri Srain
YaST Team Leader
---------------------------------------------------------------------
SUSE LINUX, s.r.o. e-mail: jsrain@xxxxxxx
Lihovarska 1060/12 tel: +420 284 084 659
190 00 Praha 9 fax: +420 284 084 001
Czech Republic http://www.suse.cz
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >