[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: misuse/abuse of popup windows - a real-life example
From:       Sébastien_Laoût "\[temporar\]" <les83plus () free ! fr>
Date:       2004-09-01 19:42:08
Message-ID: 1094067727.4510.73.camel () localhost ! localdomain
[Download RAW message or body]

Well.
I resend this message without the joined file.
The mockup is viewable at this address:
http://les83plus.free.fr/sebastien.laout/hangman-keyboard.png

Le mar 31/08/2004 à 22:30, Anne-Marie Mahfouf a écrit :
> > Perhapse the interface can be *completly* redesigned and just present a
> > virtual keyboard to the user (each keys are buttons)...
> like KTouch for example? But what about keyboard layouts for cyrillic for 
> example?

Yes, like KTouch, but with QButton to make clear they are clickable.

Yes, for intrnationalisation it's not easy.
But unfortunaly I don't know how Chines or Cyrillic (don't know this
language) do for entering text. I suppose they have keyboard ( ;-) ) but
don't know how.

> > Then, the user just have to click the buttons to enter letters and the
> > lineEdit issues are solved (if the letter is accepted by the game as
> > soon as it is pressed and then dissappear from the lineEdit, it could be
> > as confusing as needing to press Enter, IMHO).
> > In this case, those buttons could be checked in red for Missed, or
> > rounded in green for good chars: the feedback is immediate and at the
> > position where the cursor/eyes is/are.
> >
> > *PossibleImplementation: render the character in a pixmap, then apply an
> >  icon of round/check if needed)
> I don't understand what you mean.

Instead of making

    m_button[0]->setText("A");

use setPixmap() like that:

    QImage img;
    img.drawText("A", QPoint(0,0));
    QPixmap ok_ico = loadIcon("ok");
    QImage ok_img = ok_ico.toImage();
    KIconEffect::overlay(img, ok_img);
    m_button[0]->setPixmap(img.toPixmap());

Note: this code is "fantesist": I don't have courage to look in the docs
for compilable code ;-)
Or perhapse QButtons can have the loadIcon("ok") as a background.

> > *Question: Should the buttons disabled when clicked?
> >  If yes, a special QIconSet should be programmed to avoid the icons
> >  to be shaded when disabled
> Don't understand either.

When a button is clicked, it can't be clicked another time.
So, it could be good to write m_button[0]->setEnabled(false);
But the text and the icon would then be grayed.
Not beautiful.
I *think* create a QIconSet that do not gray disabled icons could solve
the problem...

> don't make it too easy by leaving only the possible letters for the user ;-)

Programatically, yes :-)
For the user, it solve the lineEdit problem.
Hum... he loss the ability to use keyboard.
Perhapse not so dramatic. A solution could be to accept keyboard inputs
in the SAME way kcalc accept them: ie. pressing key_num_8 simulate the
press of the QButton [8] (khangman would act consistently, but for
letters, of course).

> I would prefer NOT redesign everything at this stage (i.e. for 3.4). There's 
> too little time. A mock-up of your proposal would be nice so I could 
> understand it better.

OK.

I joined a mockup to make ideas clearer.
I put the image on left and the keyboard on right (instead of
top/bottom) so it make the thing easier for the eyes (more like "16/9"
screens). It make layout also better looking in full screen mode.
The blue background have to be replaced by the image, of course.
I added "Reminding trys: 7" because it was missing with the keyboard.

The difficulty and language is in the toolbar AND in the statusbar.
I removed it from the statusbar. But that's another subject!

Best regards,

Sébastien Laoût.


_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]