Since not all links can be deleted, an action that deletes a section
and all the links it contains cannot be reliably implemented.
Therefore, the action will only be offered if all links have already
been deleted (or were never added in the first place).
This helps when testing on PC.
I didn't bother to implement the same functionality for all dialog
event loops, since that would be a lot of extra work and not necessary
for the scenario that I need it for: clean exit when running under
Valgrind.
This option is not compatible with section names being provided by
other sources than user-created links. Examples of other sources are
built-in action links, links installed by a distro in a read-only
directory and metadata from OPK files.
It didn't work anymore, at all. Touchscreen polling occurred only
*after* waiting for a button had completed. So the touchscreen events,
if any, would be ignored until the user had pressed a button, possibly
firing off another action with that button press and forwarding the
touchscreen event to the next interface that got brought up as a
result.
Reusing this code and fixing it would require far more work than
rewriting everything anew with touchscreen devices in mind from the
beginning.
MtH: Resolved conflicts, mainly from the GMenu2X pointer to reference
change I did on 2015-04-21.
This ensures the memory is freed when the pointers are removed. While
there was an explicit delete loop in the destructor, memory leaks could
occur when links were removed from the menu.
This avoids unnecessary copying.
Removed sectionName argument to addLink(), since its only caller didn't
provide a value for it, meaning it always defaulted.
Keeping it sorted when sections are inserted after startup improves the
user experience and if we have code for that already, we might as well
use it during startup too.
Previously, the built-in actions would only be added if their
respective sections already existed.
This also works around the fact that Menu::paint() crashes if there
are no sections present.
The code cannot deal with there being no sections. After startup,
there will always be sections for the built-in actions. But before
those are added the lack of sections could be fatal.
This check was copied from SDL 1.2.15's version of "sdl.m4".
This fixes a problem where "sdl.h" cannot be found on native compiles
because the output of the sdl-config script is ignored when compiling
the test program.
Previously 1 was written to the sysfs "blank" pseudo-file, but that
selects blanking state FB_BLANK_NORMAL, which does not power down the
display. Instead, we should write 4 for FB_BLANK_POWERDOWN.
Note that in the OpenDingux kernel, any non-zero blanking state would
power down the display, so we got the desired behavior in practice,
but this is not according to spec.
Remove fourth argument, which was never used and had a confusing name.
Change return type to void, since the returned value was never used.
Simplify the actual splitting code.
Add documentation comment.
The original code was incorrect: it used erase() on the end() iterator.
Also, it only checked for an initially empty page, but could not deal
with a page containing only empty lines, which will become an empty
page during the empty line removal.
The check for a line being empty is now done by searching the line for
non-whitespace characters instead of by trimming it. This avoids
creating new string objects that are only used to check whether they
are empty.
When compiling with musl, I got a warning that <fcntl.h> should be used
instead of <sys/fcntl.h>, but it seems neither is necessary.
The comment suggested the battery code needed the header, but the code
that was moved to battery.cpp only uses functions from <stdio.h>.
Under certain conditions, it was possible to get orderLinks() trigger a
segmentation fault or a SIGBUS; even if all the Link* and Linkapp*
pointers where correct, the compare_links() function would eventually
end up receiving an invalid pointer.
Apparently, the std::sort function *requires* that the assertion
compare_links(a, b) != compare_links(b, a) is always true, which was not
the case previously when a link was compared with itself.
It is possible for OPK links to refer to a missing icon or to an icon
that cannot be read as a PNG file, in which cases there is no fallback
to icons/generic.png and the icon is null.
Link::paint checks for this, but LinkApp::drawLaunch did not.
Obviously it is more desirable to properly fall back, but that would be
a very big change to many areas of the code, so this is a quick fix.
Instead, consider the installation location non-deletable and the home
directory deletable. This makes the "deletable" property follow the
purpose of the directory rather than its implementation details.
