When a app is launched with a file selected with the built-in file
selector, we memorize the directory on which the file was found,
so that a future launch of that application will directly open
that directory.
Console apps are always launched on tty1. However it can occur that
the console displayed on the framebuffer is another one, so we have
to explicitely activate tty1.
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.
This functionality was half-removed already: some code missing, other
essential parts commented out.
I don't see the point of this either: RGB graphics are created for a certain
gamma value; if that differs from the screen gamma it is up to the application
to do something about it: gamma correct the graphics and/or change the screen
gamma. It doesn't make sense to make this user configurable.
Working directory was only configurable in the ini files, not in the GUI.
Many GP2X/Dingoo applications break if the working directory is changed
because they use relative paths for locating their data files.
I don't see a reason to keep this feature, since I don't know of a realistic
scenario where it would be useful. In any case, the functionality can be
re-created by using a wrapper script to change the working directory based on
a parameter value.
The desired backlight level depends on the amount of light coming in from
the environment, not on the application that is run. Setting the brightness
when launching an application discards what is probably the right value
for this location (indoor/outdoor) and time of day. So we decided that this
is not a desirable feature and therefore removed it.
It is already constrained on editing and when actually applying the frequency.
The string value constrain is problematic because it happens in a class that
has no knowledge of the actual CPU limits, so it can only contrain to
hardcoded limits.
With this change you'll actually be able to run apps at 432 MHz.
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.
Instead of having the copy constructor convert to display format, the new
copy constructor preserves the pixel format and a separate method was
introduced to convert surfaces to display format.
The code was made more robust as well: it should no longer crash if the
wallpaper cannot be loaded.
I cheated a bit by declaring ASFont as friend, but all other outside
access now happens via methods.
I removed the "saveScreenshot" method since the code calling it is
commented out and I never heard anyone complain about missing this
feature.
If loading fails, the factory method returns NULL, while previously the
constructor would create a Surface object with a NULL "raw" field.
However, since most of the methods dereference "raw" without checking,
such a Surface would likely crash the application when used.
