If the application in question daemonizes, it will continue running
no matter whether we start it with system() or execlp(). So I don't
see a reason for this feature to exist and removing it means less
code paths to worry about.
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.
The code still has a lot of overlap with the other methods of Link and
LinkApp, but at least it is in the same place now.
Since this was the last outside use, setIconPath() could be declared
as 'protected'.
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.
The unnecessary alpha channel might harm performance but is not a big deal.
However, the fact that the alpha flag (bool) is somehow automatically
converted by C++ into a skin name (string) causes the entire screen to
stay black.
The black screen was fixed by removing the alpha flag.
For optimum blitting performance, the wallpaper surface is then converted
to the pixel format of the frame buffer.
Bug was introduced in 52c89d6005.
Although exposing a read/write reference to a private field is not much better than having a public field.
Well, at least we are explicit about the nasty stuff now.
