Currently the launched application is exec-ed from deep within the menu
code. This means a lot of destructors are never run and as a result
for example file descriptors from the menu remain open in the launched
process.
This is a first step to move the launch invocation from a deep call
stack to the top level.
It was only used to share implementation between IconButton and Link.
However, there was only one non-trivial method, handleTS(), and that
method used a different code path for each use case: doubleClick was
always false for IconButton and always true for Link. So the total
amount of code was actually reduced by eliminating this code sharing.
The main motivation for this split is that I can now freely refactor
Link without having to worry about IconButton.
This fixes a bug with the captured background being wrong when using
double buffering. Also it ensures that for example the clock in the
status bar is updated when the context menu is open.
Originally the font implementation was based on SFont, but it was
recently replaced by an SDL_ttf based implementation, so the name
no longer made sense.
LinkApp now calls its launch method via the delegate mechanism instead of
via an overridden virtual method. This should make it easier to move the
launch method out of LinkApp and into the GMenu2X main class.
There was a lot of gp2x-specific code which was built for
all platform. For instance, the code was compiled for all
the platforms with the constant "TARGET_GP2X" defined.
This obviously had to be fixed.
GMenu2X now uses tr1::unordered_map instead, which results in a much smaller binary.
The Google library might have its uses when high performance is required, but for us a smaller binary is more important since that reduces startup time.
No more poking into registers via /dev/mem.
If there is no cpufreq support in the kernel, when trying to change the frequency a message will be printed on stderr that the required sysfs file cannot be opened.
PXML is the metadata format for Pandora packages. It is not used on the
NanoNote or under Dingux.
Ideally it would be a compilation option, but without an active upstream it
would not receive any testing and therefore likely be broken. So in my
opinion it is more time efficient to remove it now and re-add if it is ever
wanted again.
