Mailinglist Archive: yast-devel (132 mails)

< Previous Next >
Re: [yast-devel] Handle GUI and text-mode differently - yast ncurses survey
  • From: Ricardo Cruz <rpmcruz@xxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 23 Oct 2007 20:47:58 +0100
  • Message-id: <1193168878.4408.77.camel@xxxxxxxxxxxx>
Hi there,

If possible, get someone from maemo.org to assiste you. Not sure if
their SDK allows for it, but I know they have at least give it some
thought.

For the most part, you could just have two interface constructors and
re-use the logic. YCP is already an appropriate language for this I
would think, so just have printer-ui-main-text.ycp and -graphical.ycp,
and you wrap it into a nice modular library.

As you want more complex interfaces, you want compound widgets. If you
want to use a Tab Pages in one interface, and List Items as pages in
another, have a wrapper widget that constructs the appropriate widgets
and hooks them. When processing events, you need to ping this code -- I
guess you could do it behind the scenes from the interpreter or call a
function directly from the YCP code.

As yast-core is becoming language independent, maybe a XML factory
would be in order?

Cheers,
Ricardo

Ter, 2007-10-23 às 11:32 +0200, Katarina Machalkova escreveu:
Dear brothers and sisters in YaST,

(some of you already discovered the wiki page on $subject, so here is a full
explanation on what is this all about)

One of discussion topics on our recent workshop was whether we should handle
graphical UI differently from the text-mode. However, we found out that we
don't know an exact answer to the question who are the users of the
text-mode UI, why do they decide to use it, and if we decide to drop it, can
we find any equivalent?

In order to find some answers to at least some of the above questions, I
decided to carry out a small, informal in-house survey among Czech openSUSE
developers. The group was rather small and well, yes, developers are not
exactly the representative sample of society, but they are human beings (most
of them ;-) ), they are openSUSE users, and their opinion counts as well

The detailed questionare can be found here:
http://en.opensuse.org/YaST_Workshop_Prague_2007_Day_1/YaST_ncurses_survey#YaST_text-mode_UI_usage_survey
Some of the q's were multiple-choice with one open-ended "Something else,
please specify..." item, the others were entirely open-ended.

What does this small survey reveal?
* Text-mode users do not miss eye-candy, but - surprise, surprise ;-) they
_do_ miss functionality, they miss more comfortable and intuitive navigation
in UI.

* They use text-mode because
- It is usable even without X
- It provides the same functionality as GUI
- It is better choice for using over the network
- It is faster and has lower memory requirements
- and many more, see here:
http://en.opensuse.org/YaST_Workshop_Prague_2007_Day_1/YaST_ncurses_survey#What_do_users_like_on_YaST_text-mode_UI.3F

The entire summary of this topic can be found on this page:
http://en.opensuse.org/YaST_Workshop_Prague_2007_Day_1/Handle_graphical_and_text_mode_separately
which is a joint work of Jirka Suchomel, Lukas Ocilka and me.

And there are 3 possible conclusions of our workshop discussion and this
survey:

* We should cater for needs of different types of users. We can make one UI
an
eye-candy for those users that want it, while keeping the other one
simplistic, because its users want it to stay so.

* While improving look&feel, we should keep in mind that users do need and do
appreciate functional equivalency of all UIs

* Having ncurses may limit us in certain aspects (no yellow-violet-pinkish
eye-candy, no icons in every single table cell, low resolution and mouseless
user,...), but there are other areas in which it gives us even more freedom
instead of restricting us (we're independent of functional X server, certain
web-browser, fast network connection, and we still can have well-usable and
functionally equivalent UI).

B.

--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >
Follow Ups
References