[Scummvm-devel] RTL branch to be merged (relevant for *all* developers)

[Stephen Kennedy]

Hi All

>> To start off, I don't
>> know much about the Virtual Keyboard project (except that it uses my
>> XML parser, hehe), but I take it uses some kind of rendering code to
>> draw the virtual keyboard on the screen and that this code is bitmap
>> based.
>
> Yup, I think so. But with an XML "imagemap" which defines polygon regions,
> and specifies what key those regions corresponds to.
>

Yeh the rendering code is bitmap-based with just simple key color transparency.

>> The thing is, would it be in order to change the VKeyboard rendering
>> API to use my Vector Renderer before merging it in? Or maybe change it
>> after my merge? Or maybe just leave it using bitmaps?
>
> I think it's definitely worth a thought whether we could implement a fast
> and good looking vector based keyboard. However, I'd worry about this after
> the merge. Just doing the merge is already quite a pile of work, no need to
> further complicate that.

I would agree that it is a definitely worth a thought but i do feel it
will be quite a different beast to a bitmap based keyboard. The main
reason it was decided to use bitmap/HTML imagemap based vkeybd was
that one can easily use GIMP or photoshop to create the keyboard
whereas a vector-based vkeybd would mean writing the whole keyboard
pack by hand, which might be quite a lengthy process given the number
of keys, different modes etc.

> And anyway, my hope is that the vkeybd code is
> modular enough to make it possible to change the way things are rendered
> independently from the rest.

Yep I made sure to abstract the rendering from the functionality :-)

> And we still have enough work with "the rest", far more important than the
> render bits. Like, getting the vkeybd into a shape that makes it actually
> usable by backends, and then getting a first console/phone backend to use
> it. I.e. we need one more port console/phone/small device porters to
> cooperate with us on this. And hopefully in the end, all backends can
> benefit from the virtual keyboard (well, some systems may already have their
> own good enough vkeybdy, those don't have to bother with our custom one, of
> course).
>

Yes this should definitely be the focus for the time being, and i look
forward to making this happen when I am back from holiday.

> Well, actually, I might want to pick themes and keyboard independently.
> Though of course our default theme & keyboard, the one 99% will use (at
> least initially?) should be coordinated and somehow "match" in the way they
> look.
>
> But I wouldn't force them to be packed into the same .zip file, though
> supporting that might be nice. This should in fact be quite easy once the
> Common::Archive code peres has recently commited starts to be used... but
> more on that in another mail I still have to write.... ;)
>

Sounds good :)

Cheers,
Kenny