[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic