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.
Each part of the code deals with either Links or IconButtons, but
not both: the base class is only used to share implementation and
not interface. Make this explicit by doing private inheritance.
Nowhere in the code do we actually mix IconButtons and Links (the other
Button subclass), so I'm thinking of breaking up this class hierarchy
or at least making the inheritance private.
Also switched to C++11 style loops.
Previously, the links would scroll when the cursor was about to move
out of screen. By scrolling earlier, the user gets a view of the next
row before it becomes the current row. This allows a longer reaction
time to switch from vertical to horizontal navigation when looking for
a particular link in the grid.
This reduces the number of required preprocessor directives, leading to
more readable code and more code being examined by the compiler (useful
to spot problems). Since the method is inlined, the compiler should be
able to eliminate the same amount of code that the preprocessor would,
only at a later stage of the compilation.
This fixes a bug with the captured background being wrong when using
double buffering. Also it ensures that for example the clock in the
status bar is updated when the context menu is open.
All of the entries in the context menu affect sections and links, so
the context menu should be considered part of the main menu, not of
the global / background context.
Writing hours and minutes separately while the string representation
is being constructed could lead to an incorrect result on an hour
boundary. Avoid this by using an atomic timestamp.
With GCC 4.8.1 on MIPS this atomic timestamp is lock free.
SDL does not guard against the final callback still executing when the
call to remove the timer returns. So we have to make sure the object
we access on the callback is not prematurely destructed. This commit
uses shared_ptr and weak_ptr to ensure that.
Note that we sort-of have a singleton again, only now it is private
and safely destructed.
Removed the suspend check: the best thing we can do after oversleeping
is the same as when we're woken right on time: fetch the time and
reschedule for the next minute boundary.
Don't create a new timer on every callback; instead return the next
interval to SDL.
Don't make Clock a singleton. While there should be no reason to
instantiate this class more than once, there is no problem with doing
that either. Removing the singleton makes it easier to control access
to the instance. It also avoids the rather nasty construct that was
used to delete it.
Make sure the timer callback function is a proper C function, since
SDL is a C library. This requires some trickery to be able to call
a private method from the callback, but I found a way using an
intermediate nested class. The compiler should be able to inline this
to eliminate any overhead.
Also some minor cleanups.
This method was never called.
And I cannot really think of a scenario in which it is useful to wait
for any button to be released: a particular button or all buttons I can
imagine, but not any button.
Instead of having a list and wrapping between beginning and end, always
put the current section in the middle and show the previous and next
sections using wrap-around.
Made sure it fills the space between the top and bottom bar. Use a one
pixel margin; I tried without margins but it didn't look nice.
Also cleaned up the paint code a bit.
Replaced Font constructor with factory method, so that if the TTF
cannot be loaded, the Font object is not constructed. The normal C++
way of handling this is with exceptions, but we're compiling with
-fno-exceptions.
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'.
This could be used to create platform-independent packages. It can
be useful for instance in the case where the executable is a script,
or when the package points to an executable that is present on all
systems on which OPKs are supposed to run.
The empty "" filter was previously matching all the files; since
a few commits it now matches the files without extensions. The
new "*" filter allows again to match all files.
tolower() will trigger an assertion failure in the case where the
string contains UTF-8 codes. This is not a problem as only the
file extension needs to be processed, and that one should contain
only ASCII.
These are not actual OPK files, but metadata (I assume) storage that
Mac OS X adds to vfat file systems. The current version of libopk has
extremely poor error handling, so ignoring these files avoids a crash.
But even when libopk is fixed, not trying to open these files as OPKs
will be useful since it saves time.
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.
The filename passed to it should contain the filename of the squashfs
image, the character '#', and the filename of the .png file contained
inside the package.
E.g.:
/tmp/package.opk#icon.png
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.
Use unsigned ints for width and height, like SDL does.
We're using the SDL typedefs there after all.
Include argument names in header when type name does tell everything.
Use whitespace in argument lists.
Fixes bug introduced in 57ad81e3df.
This bug would prevent applications from launching, so it's pretty serious.
I did test before committing, but apparently I didn't test the right binary.
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.
