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

[Max Horn]

Hi Vicent!

Am 02.09.2008 um 20:05 schrieb Vicent Marti:

> Greetings people, I'm back from my well deserved holidays.
>
> Let me start by saying that I'm extremely glad that my GSoC project is
> going to me merged into the trunk and that I'm ready to do everything
> possible to make the merge smooth as silk.

Glad to hear! :)

> I'm trying to get up to date with all the stuff going on after the
> release, so please bare with me and my slowness.

We'll even bear with you *ggg*.


> 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.


> 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. 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.

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).


> As far as I know, the XML parser was used in the project to parse
> HTML-like image maps, so changing the system to use a vectorially
> rendered keyboard may require quite a bit of extra work -- work which
> probably won't overweight the benefits of having a vector based
> keyboard (not having to embed more resources with the executable,
> allowing theme-based designs for the keyboard, etc).
>
> Either way, even if the keyboard is still rendered using bitmaps, I'd
> say it would be nice to have some better integration between the new
> GUI and the virtual keyboard (at the very least, packing the keyboard
> themes together with the GUI themes would be nice).

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.... ;)


Cheers,
Max