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