Instead of correcting the returned coordinate with "- 10" externally,
omit the white space inside the methods.
Note that Font::getTextWidth, which was used until recently, considers
an empty string to have width 1, so 3 + getTextWidth("") + 6 == 10.
There is a difference in how buttons that have neither a label nor an
icon are positioned in the new code, but that is a situation that
should not occur in practice. Plus I'd argue that the new behavior is
actually better in that case.
Previously, if a user installed a new version of an OPK with the same
name as one that had a link configuration file, GMenu2X could request
a file for an application whose new version required no files to
launch.
In practice, this transition would occur only once per OPK application,
when its developer decided to use a custom browser after having used
GMenu2X's file browser. This bug would then show GMenu2X's file browser
to request a file that would not even be passed to the application.
Thanks to Nebuleon for analyzing the problem and the above description.
0 is the default clock value, which doesn't get written to link files
if it's not changed. The clock was previously uninitialised before
reading link files, so it would get written with a random value if
there was none before.
There are a few exclusive operations for each type. Also we no longer
need the freeWhenDone flag since the class now determines whether the
surface should be freed or not.
Applications with this flag will not have their stdout/stderr
redirected to a log file when logging is enabled. That is a useful
feature also on platforms where we don't micromanage the console.
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.
Instead of reading the file line by line and then concatenating those
lines, just load the entire thing in one go. And pay more attention to
error conditions.
The constructors of those classes now accept a string to be wrapped, instead
of a vector to be modified with split lines inserted into its middle.
Along with this conversion, manuals for applications stored in OPK packages
are now transferred into a string without garbage at the end.
This does away with per-link selector directories in link files. It is assumed
that, if a user has access to write files to be launched by an application at
some location, he or she also has access to write files in the previews/
subdirectory under it.
This breaks one thing: the "params" option of the links must be
only one parameter (without spaces). The only way to actually
set this option being to edit the config files manually, it is
pretty safe to assume it will never contain two parameters.
The comment of this code indicates that it is needed for
SDL apps to work correctly.
However, I don't see any valid reason for the apps we
launch to be running in a different group.
Removing it didn't make any apparent difference, so unless
I'm proven wrong, it'll stay gone from now on.
LinkApp::drawRun() assumes the layers below are already painted when
it is called, but this was not the case. With single buffering, the
previous frame was still there so it still looked good, but with
double buffering the buffer typically contains an outdated screen.
Long term I think the launch should happen at the outermost scope,
so all destructors get a chance to run. This commit is a small step
in that direction, by exiting the main loop before launching.
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'.
