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

List:       kde-devel
Subject:    Re: Please check my IPv4LineEdit !
From:       tweakBSD () gmx ! net
Date:       2005-03-22 19:29:03
Message-ID: 200503222029.03410.tweakBSD () gmx ! net
[Download RAW message or body]

Am Dienstag 22 März 2005 19:44 schrieb Malte S. Stretz:
> On Monday 21 March 2005 23:11 CET tweakBSD@gmx.net wrote:
> > Am Montag 21 März 2005 22:50 schrieb Sandro Giessl:
> > [...]
> >
> > > I just tried the input mask "000.000.000.000;_" in designer and it
> > > appears that the user doesn't need to provide the dots and it behaves
> > > like you described, except that there is no 0-255 validation. The Qt
> > > doc says validators can be applied, tough, I will have a look at this.
> >
> > Ok, if you type 56 in the first field then we should go to the next 0-255
> > because the string "56" plus string "[0-9]" is bigger than will represent
> > a number greater 255.
>
> I think you should not put too much magic into those input fields.  Windows
> for example has stuff like this in many places and while it may sound
> useful on the first thought, they are often a usability nightmare.
>
> I haven't tried your solution, but some examples I had issues with before
> (in different variations):
>
> 1. Assume I've typed the octet 234 as the first one.  Now I notice that I
> wanted to type 134 so I set the cursor to the first number and remove it.
> That will give 34 as the first octet, how will your input thingy react?

That isn't bad 'cause everything can be returned as KIpAddress and I think 
KIpAddress chooses internally the next octet. I will test it.

> 34x isn't a valid octet, will it jump to the next one?  Or will it notice
> that the cursor is not at the end?
>
> 2. A variation:  I typed the octet 20.  Now I want to correct it to be 26.
> So I put the cursor between the 2 and the 0 and type a 6 because the next
> thing I wanto to do is to press Del to remove the 0.  But 260 isn't a valid
> octet, how does your filter react?

260 > 255, the input is ignored 'cause every LineEdit has a

>
> 3. To the user these input fields look like four separate line edits.
> Normally you can use tab to switch to the next one.  Ok, I have to type the
> IP 10.123.1.2 without looking at my screen.  10<tab>123<tab>1<tab>2 (or
> maby with dots instead of tabs, should behave the same).  How will it
> react?  I've seen solutions like this which produced 10.123.0.1*ding*
> (system bell).  Because after the 123 it automagically jumped to the next
> field.  But I pressed tab again (thought I was still in the first field)
> and it was filled up with a zero.  (Of course this example works the other
> way round, too.)


e.g. you type "25" then a "6" my event filter checks if "256" is greater than 
255 then go the next, if you are at the last position of one LineEdit focus 
on the next, the last one does not give any focus to the next one.
You can even use del to delete entirely all four LineEdit it automatically 
jumps to the next one and goes on with deleting, same for Backspace,
Key_Right, Key_Left are possible to use to switch between octets. if you type 
a point you come to the next LineEdit,...

Try it it behaves like ONE LineEdit not like FOUR as you thought, believe it.


>
> Oh, and does pasting (fractions of) IP addresses work?

Yes everything gets correctly validatet by the IntValidator and some other 
filters ;-)

>
> What I want to say is, that magic input fields (especially focus changing
> ones) are often more magic the user expects and instead of helping him they
> make his life harder because he always has to remember how that thingy
> worked on the OS he currently uses.

That thingy works not like anything special just like a LineEdit just with the 
purpose it's only for IPv4 addresses.

>
> A much more useful solution are IMO "silent" validating input fields.  Have
> a look at the Eclipse Class Wizard for example.  If something is fishy with
> the data the user entered (ie. he tries to derive a non-existing class)
> then a small light bulb appears behind (or in front? can't remember) the
> input fields.  The user can click on that icon and get an (understandable)
> explanation on what seems to be wrong.

Hmm, that's possible to indicate things like the "34" as the first octet as 
you mentioned, additionally could be very usefull. Thank you very much for 
this inspiration.

>
> Cheers,
> Malte

Cheers back,

Mario

>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> >> unsubscribe <<
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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