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.
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.
