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.
Currently, inotify is used only to detect that OPKs have been
added / removed / modified, so it is not needed to enable inotify
support when support for OPKs is not compiled in.
Loading dynamically at startup is a very bad idea, as it
confuses the "load state before exiting" feature of GMenu2X:
the file selector will pass the file to a different program,
the cursor will move to select a different app, etc.
This reverts commit 5c631d610e.
This fixes a segmentation fault occuring on the wallpaper dialog
when trying to select a wallpaper located in the Default skin in
the user directory, when the current skin is not "Default".
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.
The scroll bar always spans the content area of the screen: the
position and height depend only on the theme and not on who is
drawing it.
Note that the coordinates passed were wrong in most cases, so this
commit fixes the scroll bar positioning for several dialogs.
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.
The labels were longer than the space before the RGBA controls and
the fact that these are colors is already clear from the context
(such as having an RGBA control after it ;).
I tried to update the translated versions of these labels as well.
However, since I don't speak most of these languages, it is possible
the result is grammatically incorrect. If this is the case, please
mail me a correction.
