[yast-devel] WebYaST will help the openness
Hi, I've just talked with Michal Svec, a product manager, about YaST and WebYaST. (Not knowing about our discussion, he wanted to know how hard it is to "copy" YaST features to WebYaST.) I noted that in the short term we instead want to work on opening the project, and he had these insights: Motivation: removing barriers to entry like I proposed is fine, but YaST already includes everything and the kitchen sink, so people have little motivation to contribute by adding new features. On the other hand, WebYaST is small feature-wise, so we could take advantage of that and of the current demand for the web stuff and make sure contributing to WebYaST is easy. YaST on other distributions: ZYpp is a community project thanks to libzypp and zypper being actually used by other distros. Can we do the same for YaST? It is much bigger so it is hard. How about porting a smaller part like WebYaST? -- Martin Vidner, YaST developer http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu
Dne pátek 11 Únor 2011 16:02:10 Martin Vidner napsal(a):
Motivation: removing barriers to entry like I proposed is fine, but YaST already includes everything and the kitchen sink, so people have little motivation to contribute by adding new features.
I agree. Why they should want to add new features, when all of them are already present.
On the other hand, WebYaST is small feature-wise, so we could take advantage of that and of the current demand for the web stuff and make sure contributing to WebYaST is easy.
I think we need to use non-YaST backend for webYaST. By this, I do not mean that old YaST should be obsoleted or completely replaced by webYaST. I just think that the goals and primary features (feature richness vs. speed and small size) of both projects are different. Jiri -- Jiri Suchomel SUSE LINUX, s.r.o. e-mail: jsuchome@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Praha 9, Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Monday 14 February 2011 10:45:42 Jiri Suchomel wrote:
Dne pátek 11 Únor 2011 16:02:10 Martin Vidner napsal(a):
Motivation: removing barriers to entry like I proposed is fine, but YaST already includes everything and the kitchen sink, so people have little motivation to contribute by adding new features.
I agree. Why they should want to add new features, when all of them are already present.
On the other hand, WebYaST is small feature-wise, so we could take advantage of that and of the current demand for the web stuff and make sure contributing to WebYaST is easy.
I think we need to use non-YaST backend for webYaST.
By this, I do not mean that old YaST should be obsoleted or completely replaced by webYaST. I just think that the goals and primary features (feature richness vs. speed and small size) of both projects are different.
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. Afterwards, porting a module form classical YaST to WebYaST will mean only creating the screen layout. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Jiri Srain <jsrain@suse.cz> [Feb 15. 2011 09:04]:
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.
Yes.
Afterwards, porting a module form classical YaST to WebYaST will mean only creating the screen layout.
Sounds like easy. But it isn't. Getting the UI design and usability right is *hard*. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Tuesday 15 February 2011 09:33:47 Klaus Kaempf wrote:
Afterwards, porting a module form classical YaST to WebYaST will mean only creating the screen layout.
Sounds like easy. But it isn't. Getting the UI design and usability right is *hard*.
Sure, it will always be hard. But with this kind of architecture, the module developer can concentrate on the business logic in the backend and the UI can be done completely independent by an usability expert/designer/... Ciao, Daniel -- J. Daniel Schmidt <jdsn@suse.de> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 15.2.2011 11:13, J. Daniel Schmidt napsal(a):
On Tuesday 15 February 2011 09:33:47 Klaus Kaempf wrote:
Afterwards, porting a module form classical YaST to WebYaST will mean only creating the screen layout.
Sounds like easy. But it isn't. Getting the UI design and usability right is *hard*.
Sure, it will always be hard. But with this kind of architecture, the module developer can concentrate on the business logic in the backend and the UI can be done completely independent by an usability expert/designer/...
In fact UI shouldn't be "completely" done independently by a usability expert/designer. IMO, it's better if designer(s) and developer(s) work on UI together, discussing pros & cons, different ideas, different points of view. No cents available Lukas - -- Lukas Ocilka, Appliances Department, Novell Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iD8DBQFNWlpRVSqMdRCqTiwRAvf3AJ4vG6fo0CwgVumPsOTzzm4xlUpK7ACgg+OS tI1oQaGaQtxVwILcJGWfHJI= =72NJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On Tuesday 15 February 2011 11:49:53 Lukas Ocilka wrote:
In fact UI shouldn't be "completely" done independently by a usability expert/designer.
s/can/could/g My point was, that it is easier when it is possible to work on both separately. Ciao, Daniel -- J. Daniel Schmidt <jdsn@suse.de> SUSE Linux Products GmbH Research & Development Maxfeldstr. 5 GF: Markus Rex, HRB 16746 (AG Nürnberg) D-90409 Nürnberg -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 15.2.2011 14:03, J. Daniel Schmidt napsal(a):
On Tuesday 15 February 2011 11:49:53 Lukas Ocilka wrote:
In fact UI shouldn't be "completely" done independently by a usability expert/designer.
s/can/could/g
My point was, that it is easier when it is possible to work on both separately.
Yes, it *that* was the point, it's absolutely valid from my POV :) sure. Lukas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iD8DBQFNWnxRVSqMdRCqTiwRAjlnAJ4q9flYUDAGdKRQahabJxJEuSWgtACfcHAa OjJVg4qg7NMuofaJNQw7JiI= =2pb3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
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. 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 -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 15.2.2011 12:34, Johannes Meixner napsal(a):
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.
... shortened a bit ...
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...
Let's get some fresh inspiration in other (similar projects), for instance Android :) This part describes all the Android layers in general: http://developer.android.com/guide/basics/what-is-android.html This part describes the Android application UI layout. It can be easily written in XML (or Java, but XML is preferred): http://developer.android.com/resources/tutorials/views/index.html UI written in XML is easy to understand, easy to write (e.g., in Eclipse with Android SDK plug-in), well documented. And it's similar to layout written in YCP (except, it's a well-known language). Bye Lukas - -- Lukas Ocilka, Appliances Department, Novell Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iD8DBQFNWnhBVSqMdRCqTiwRAp6dAJ0Xcnerwsv2zZKFL+AtWPAFWwUtTACeMUgM J/B8sJ8oAknqhl/l+wx+RCQ= =4ORE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
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@suse.cz 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@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 02/15/2011 12:34 PM, Johannes Meixner wrote:
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" ) )
We could call it HTML, and the styling/positioning part CSS. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 15.2.2011 17:19, Duncan Mac-Vicar P. napsal(a):
On 02/15/2011 12:34 PM, Johannes Meixner wrote:
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" ) )
We could call it HTML, and the styling/positioning part CSS.
Yes, we could :) Except "nobody wants to code HTML && CSS anymore"™. Certain level of abstraction is kind of a must nowadays. - -- Lukas Ocilka, Appliances Department, Novell Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iD4DBQFNW4zwVSqMdRCqTiwRAknYAKCaFShyBCYNUdwBsMVrm6mQXgBcXgCYvQk4 9X1XBBTi4QLINmnZJMTGpw== =nQT5 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Lukas Ocilka <lukas.ocilka@suse.cz> [Feb 16. 2011 09:38]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dne 15.2.2011 17:19, Duncan Mac-Vicar P. napsal(a):
On 02/15/2011 12:34 PM, Johannes Meixner wrote:
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" ) )
We could call it HTML, and the styling/positioning part CSS.
Yes, we could :) Except "nobody wants to code HTML && CSS anymore"™. Certain level of abstraction is kind of a must nowadays.
Moving away from well known and well documented technolgies brings another barrier in adoption. This is one of the lessons learned from YCP. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dne 16.2.2011 10:16, Klaus Kaempf napsal(a):
* Lukas Ocilka <lukas.ocilka@suse.cz> [Feb 16. 2011 09:38]:
Dne 15.2.2011 17:19, Duncan Mac-Vicar P. napsal(a): ...
We could call it HTML, and the styling/positioning part CSS.
Yes, we could :) Except "nobody wants to code HTML && CSS anymore"™. Certain level of abstraction is kind of a must nowadays.
Moving away from well known and well documented technolgies brings another barrier in adoption. This is one of the lessons learned from YCP.
Actually, YCP might fit 'well-known' and 'well-documented' criteria quite well if you ask here on yast-devel. On the other hand, if the target is to use something well-know beyond YaST team, YCP doesn't seem to be the best choice, as you say. One of the well-known, well-documented and heavily-used UI language is XUL: http://en.wikipedia.org/wiki/XUL -- XML User Interface Language. But there are definitely other similar ways too. - -- Lukas Ocilka, Appliances Department, Novell Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iD8DBQFNW5lnVSqMdRCqTiwRAjqZAJwPxm04Fl15HEGlShkPCJ0oxRrzWgCfYSnt ppHIAtsQYmWYh87BXKCV9+4= =fqwV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 02/16/2011 10:31 AM, Lukas Ocilka wrote:
One of the well-known, well-documented and heavily-used UI language is XUL: http://en.wikipedia.org/wiki/XUL -- XML User Interface Language.
BTW there is some code in svn research branches that added simple XUL support to libyui. http://svn.opensuse.org/svn/yast/branches/tmp/dmacvicar/yast-xmlui/libyui/ -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
On 02/16/2011 09:38 AM, Lukas Ocilka wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dne 15.2.2011 17:19, Duncan Mac-Vicar P. napsal(a):
On 02/15/2011 12:34 PM, Johannes Meixner wrote:
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" ) )
We could call it HTML, and the styling/positioning part CSS.
Yes, we could :) Except "nobody wants to code HTML&& CSS anymore"™. Certain level of abstraction is kind of a must nowadays.
a lightweight version of XUL (may be json-ized) may be a good thing. As libyui does not have event loop and you query widgets by id. Another thing to look is declarative user interfaces, has anyone given a look at Qt Quick? http://qt.nokia.com/products/qt-quick/ Also we should look more into model binding. Instead of manually maintaining data in the module for each widget, just say... this table is bound to this model and be done. -- Duncan Mac-Vicar P. - Novell® Making IT Work As One™ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
Hello, On Feb 15 17:19 Duncan Mac-Vicar P. wrote:
On 02/15/2011 12:34 PM, Johannes Meixner wrote:
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" ) )
We could call it HTML, and the styling/positioning part CSS.
This would be o.k. for me. I don't mind which language it is (even PostScript would be o.k. for me ;-) provided it works this way also for ncurses, Gtk, and QT. I only care that it is one single language for all user frontends. Out of curiosity: What would be the intersection set of possible UI functionality for ncurses, Gtk, QT, and web-frontend? In other words: Would a "common denominator UI functionality" for ncurses, Gtk, QT, and web-frontend be insufficiently small or would it be sufficient at least for a basic user interface? I think for a basic user interface one needs at least - Output (show arbitrary text to the user) - InputField (let the user enter arbitrary text) - SelectionList (show lines of text and let the user select a line) - CheckBox (show text and let the user select or unselect it) - Link (show text and proceed when the user clicks on it) Basically CheckBox is a single-line SelectionList or an OutputField which can be selected so that it seems CheckBox is somehow optional and could be omitted. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (8)
-
Duncan Mac-Vicar P. -
J. Daniel Schmidt -
Jiri Srain -
Jiri Suchomel -
Johannes Meixner -
Klaus Kaempf -
Lukas Ocilka -
Martin Vidner