[Scummvm-devel] Merging the vkeybdy and GUI branches

[Stephen Kennedy]

Hi Max,

> [...]
> I could look into this. But actually, with latest SVN (I just
> performed a merge on your module, BTW), I can not reproduce this. That
> is, I removed your extra graphics & common dirs, and it linked just
> fine, both on Mac OS X and Linux...
>
> Can you please confirm whether the issue still exists for you, and
> then tell me the exact error(s) ?

OK, I still have the issue on Linux. When I remove the extra graphics
and common from Makefile.common I get the following compile errors:

backends/libbackends.a(virtual-keyboard.o): In function
`Common::VirtualKeyboard::checkModeResolutions()':
/home/sk4425/scummvm/backends/vkeybd/virtual-keyboard.cpp:130:
undefined reference to `Common::XMLParser::parse()'
backends/libbackends.a(virtual-keyboard.o): In function
`Common::VirtualKeyboard::loadKeyboardPack(Common::String)':
/home/sk4425/scummvm/backends/vkeybd/virtual-keyboard.cpp:120:
undefined reference to `Common::XMLParser::parse()'
backends/libbackends.a(virtual-keyboard-gui.o): In function
`Common::VirtualKeyboardGUI::redraw()':
/home/sk4425/scummvm/backends/vkeybd/virtual-keyboard-gui.cpp:317:
undefined reference to
`Graphics::SurfaceKeyColored::blit(Graphics::Surface*, short, short,
short)'
/home/sk4425/scummvm/backends/vkeybd/virtual-keyboard-gui.cpp:320:
undefined reference to
`Graphics::SurfaceKeyColored::blit(Graphics::Surface*, short, short,
short)'
backends/libbackends.a(virtual-keyboard-parser.o): In function
`Common::VirtualKeyboardParser::parsePolygon(Common::Polygon*,
Common::String const&)':
/home/sk4425/scummvm/backends/vkeybd/virtual-keyboard-parser.cpp:342:
undefined reference to `Common::XMLParser::parserError(char const*,
...)'
/home/sk4425/scummvm/backends/vkeybd/virtual-keyboard-parser.cpp:345:
undefined reference to `Common::XMLParser::parserError(char const*,
...)'
/home/sk4425/scummvm/backends/vkeybd/virtual-keyboard-parser.cpp:349:
undefined reference to `Common::XMLParser::parserError(char const*,
...)'
backends/libbackends.a(virtual-keyboard-parser.o): In function
`Common::VirtualKeyboardParser::parseRect(Common::Rect*,
Common::String const&)':
/home/sk4425/scummvm/backends/vkeybd/virtual-keyboard-parser.cpp:330:
undefined reference to `Common::XMLParser::parserError(char const*,
...)'
/home/sk4425/scummvm/backends/vkeybd/virtual-keyboard-parser.cpp:333:
undefined reference to `Common::XMLParser::parserError(char const*,
...)'
backends/libbackends.a(virtual-keyboard-parser.o):/home/sk4425/scummvm/backends/vkeybd/virtual-keyboard-parser.cpp:67:
more undefined references to `Common::XMLParser::parserError(char
const*, ...)' follow
collect2: ld returned 1 exit status

Which shows that the vkeybd code still relies on stuff from Common and
Graphics. I've just realised that the reason you are not getting
errors is because I recently implemented compile time #define's to
enable including the vkeybd and keymapper in a build. To enable them
you need to run configure with '--enable-vkeybd' and/or
'--enable-keymapper'. (You might also want to glance at the additions
I made to the configure script to do this in r34706 to make sure I
have not broken anything).

> Actually, the default is not the green & black but rather the "modern"
> theme. :) Which is yellow & red. But ideally, we'd have keyboard maps
> for both -- possibly bundled with the theme files.
>
> Anyway, as long as we have at least *some* graphics pack, this is no
> blocker. After all, no regressions are introduced (compare this with
> the GUI branch, which modifies existing functionality, so we have to
> watch out for regressions).

OK, I'll make the documentation my priority at the moment. Then, when
I have the time, I'll get to work on some better graphics packs.

>>> * as with the GUI branch: did you recently perform a merge? If not,
>>> can you
>>> do one, please?
>>
>> I performed a merge earlier and resolved the conflicts. But, when
>> trying to compile I received the following error:
> [...]
>> I have no idea what is going on here!
>
> Hmm, I just performed a merge against trunk, and compiled afterwards,
> no problems. Has the Kyra issue been fixed since your original mail?
>

I did eventually resolve the merge problems, although I'm not sure how :-/

>
>> So to summarise, I guess the branch is not in the best state to be
>> merged at the moment, but I will try the get these issues sorted ASAP.
>> If you would prefer to go ahead and merge the GUI branch first then I
>> would not object to that - your call!
>
> Actually, yeah, we might merge GUI first, if it gets into a good shape
> soon.
>

>From reading the mails regarding the GUI branch's progress it looks
like it will be merged this week. So once it has been merged I will
re-merge my branch with the trunk and resolve the new conflicts -
shouldn't be too much to do.

Cheers,
Stephen