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.
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.
There are various situations in which write() might write less than
the requested amount. In that case, if any progress was made (more
than 0 bytes written), try again, otherwise consider it an error.
Thanks to Nebuleon for reviewing.
The check I removed earlier today was redundant for readPackages() but
not so much for the Monitor: it starts a thread and it logs an error,
both of which are better avoided when possible.
Also cleaned up implementation of readPackages() a bit.
This is safer than the original code, which didn't use a temporary file
and could therefore leave partial files. Also it avoids a full sync(),
which can take a long time if for example a big file transfer is going
on or recently ended.
Since only non-default values are saved, it was quite likely settings
files were empty, especially since the clock saving was fixed. We now
remove a settings file on save if the contents are empty, so we have
to load fewer files on startup.
This avoids having to store the paths in an intermediate vector. Also
it allows us to do the writability check once per directory instead of
once per file.
Previously, it sorted before Link instances were created. Using
readLinks() ensures consistency and it might be more efficient if
a significant number of link files are rejected.
Also modernized the body of orderLinks() and removed unnecessary
special case for 1-link sections.
For zero keys, the OPK file itself would be parsed as a settings file.
For multiple keys, all first categories would be appended to the path,
leading to a much too deep directory.
Before this change, it was possible to delete for example a link that
is stored on a read-only file system and it would disappear after
deletion but reappear as soon as the menu restarts.
