Fwd: Re: [PATCH] 'sending unencrypted data' warning dialog regressions

[David Faure]

I think he hit the wrong key :)

----------  Forwarded Message  ----------

Subject: Re: [PATCH] 'sending unencrypted data' warning dialog regressions
Date: Wednesday 26 November 2003 13:59
From: Lubos Lunak <l.lunak at suse.cz>
To: David Faure <faure at kde.org>

On Tuesday 25 of November 2003 20:25, David Faure wrote:
> On Tuesday 25 November 2003 19:28, Lubos Lunak wrote:
> > On Tuesday 25 of November 2003 18:38, David Faure wrote:
> > > On Tuesday 25 November 2003 17:39, Lubos Lunak wrote:
> > > > Each keyboard input results in 3 separate key events: KeyDown,
> > > > followed by KeyPress, followed KeyUp. All platforms must generate
> > > > these events in this sequence for every keyboard input (except IME
> > > > events).
> > > >
> > > > Key repeat (automatic generation of keyevents when a key is held
> > > > down) results in a sequence of a KeyDown event, followed by multiple
> > > > keypress events, terminated by a KeyUp event. A keypress event should
> > > > be generated for each platform key repeat event recieved.
> > >
> > > Right.
> > >
> > > >  I'll take your mail as a proof that it's really broken.
> > >
> > > Well, only autorepeat was broken - it was worse before, trust me :)
> > >
> > > >  I suggest, besides fixing 2), and possibly also handling the one
> > > > more case in 1) which Dirk missed,
> >
> >  And how about this?
>
> Ah I couldn't see it in the patch, but that's because there's no patch for
> that one yet, right? I'm afraid I don't know.

 See attachment. It actually just reverts Dirk's commit in that file that was 
supposed to fix #64200. I don't understand why the commit was done, I cannot 
reproduce #64200 now, after reverting that patch (maybe something was 
different then). Dirk?

>
> Ah I can answer that one though:
> > Why is it written as te->keyVal() == ' ' instead of checking for
> > Qt::Key_Space BTW?
>
> Because events can be constructed via the DOM interface, in which case
> there's no access to any Qt event. The qKeyEvent accessor should be used as
> seldom as possible, being 0 when the event is DOM-constructed.
>
> Hmm, this means the activate() code can't get triggered by the DOM, but
> that's fine, since there's a DOM_ACTIVATE event for that purpose (I think).
> Ok, so ... where is it done twice? Once in click() and once in activate(),
> right?
>
> >  Doesn't khtml have some special rules, e.g. the ChangeLog?
>
> Yes. "C-x 4 a" for [x]emacs users :)

 As for the already committed patch, it's a bit broken WRT autorepeat and 
sending events to QScrollView. I already discussed it with David, I'll post a 
patch tomorrow (I have to leave now).

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/


-------------------------------------------------------



-- 
David FAURE, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: html_formimpl.cpp.patch
Type: text/x-diff
Size: 679 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20031126/b3bb6936/attachment.patch>