Presentation of a new Khtml project (and Problems with mapToGlobal in LineEditWidget)

[Eduardo Robles Elvira]

On Thu, Nov 19, 2009 at 6:49 PM, Germain Garand
<germain at ebooksfrance.org> wrote:
> Le jeudi 19 novembre 2009, Eduardo Robles Elvira a écrit :
>> Hello everyone,
>>
>> I know I've been silent for a while but that doesn't mean I haven't
>> been busy working in konqi/khtml. As my final project I'm writing a
>> patch for khtml for adding support of GPG encryption in forms, so that
>> something like a GPG web client or a GPG web chat can be done (I'll
>> prepare a django chat demo too as part of that project). This project
>> is not intended to be merged in trunk (though I would love to do so
>> hehe). This is project is just a test of what can be done for
>> improving the security and functionality of web applications, allowing
>> end-to-end encryption so that you don't need to trust the server
>> meanwhile using it, so that the user can reclaim the control of the
>> data he lost when giving way to web services like Gmail o Gmail chat.
>> I'm using Libkleo for dealing with GPG stuff.
>
> that's a neat idea... nice and simple way of building back a polder of
> privacy.
>
> IIUC, you are using just a couple new attributes for this...
> do you intend to submit those as a proposal to w3c, once you have worked out
> things?

I've thought about that, and think I will do it =). It would be great
if something like this was included in HTML5, and I'm already
subscribed to w3c html5 public mailing list with that intention.
However I don't know that much about HTML5 yet and if those attributes
are compatible with HTML5 forms, although with a quick Google search
it seems that they could be.

What I'm envisioning is an easy and simple way to handle encryption
but OTOH it might be too simple for more complex things. Anyway it's
perfect for my purpose: as it is simple it's easy to implement, and it
can also be secure. My original idea was a bit more complex, see
http://edulix.wordpress.com/2009/01/22/web-encryption-framework/ .

>
> anyway, down to your practical problem:
>
> [...]
>> "drop-down widget". I'm trying to use mapToGlobal(QPoint(0, height()))
>> inside khtml::LineEditWidget (rendering/render_form.cpp) as a start
>> point to deal with this, but I'm getting (14, 24392), when as you can
>> see in [3] it should be more like.. ~ (15, 50). What can be happening
>> that is making mapToGlobal go crazy?
>
> most KHTML widgets are positioned off screen, they are painted at their
> visible position but they are not really there. This is how we control their
> stacking order among other rendering objects (cf. z-index CSS property).
>
> I'd love to be able to just overload mapToGlobal and friends, but those aren't
> virtual, so what you need to do instead is some variation of:
>
>    QPoint dest;
>    KHTMLView* v = m_kwp->rootViewPos(dest);
>
> within a KHTMLWidget.
>
> |dest| will then contain the widget position, on the canvas of the root
> KHTMLView |v|.
>
> Greetings,
> Germain

Thanks it worked! And you can even see the result in a screenshot ;-)
http://img17.imageshack.us/img17/2766/konqi7.png

Regards,
   Eduardo Robles Elvira.