On large touchscreens the software keyboard can now run in "point mode". Keys are laid out finger-sized and tapped directly instead of being navigated with a cursor. Targets opt in with HAVE_KBD_POINT_MODE.
Key size is derived from LCD_DPI so a key is about 5mm across whatever the panel density, falling back to a fixed size where DPI is unknown.
A phone-style default layout in the UI font, across three flip pages of eight lines. Page two is page one shifted (i.e caps). Page three completes Latin-1 and adds additional accented letters common to the other European locales.
Space is drawn as an icon, since the UI font has no glyph for it.
Change-Id: Ibe2e305b3c22b1f9152358cf3864b9445b67b463
Co-Author: Claude Opus 4.8
When an SBS uses the new %QT tag (added in 96f42a5)
to retrieve the name of the top Quickscreen setting
(thus likely wants to draw its own QS UI), we disable
the built-in interface until a new SBS file is applied.
Fixes lag encountered in Themify 2 due to invisible
built-in Quickscreen UI that kept being re-drawn.
Change-Id: Id4f295f959c2d16d1650f6fc066c3ceca6685405
Decode the jack remote's play/pause and volume buttons via the
"Mikey" controller (I2C 0x72) and report them as multimedia keys so
they work on every screen, like the OF. Protocol reverse engineered
on-device, notes in mikey-6g.c.
Change-Id: If5f3d3abf043c0ce0d8ca7beb0f4b591e41c5c43
Allows any EQ band to be set to any of Low Shelf, Peak, or High Shelf, instead of hardcoding the types per band.
Change-Id: I470ab916359092ba465e7b6331baed3bf11b2fc9
As far as I can tell this was indtroduced during this commit
32ff4e93bd
basically they added a NOBREAK flag
to all the commands that had '\n'
where as
{ SKIN_TOKEN_VIEWPORT_FGCOLOUR, "Vf" , "S"},
{ SKIN_TOKEN_VIEWPORT_BGCOLOUR, "Vb" , "S"},
do not have \n yet they were changed to have the NOBREAK flag applied
{ SKIN_TOKEN_VIEWPORT_FGCOLOUR, "Vf" , "S", NOBREAK },
{ SKIN_TOKEN_VIEWPORT_BGCOLOUR, "Vb" , "S", NOBREAK },
this causes anything after the command to be ignored
-- Note added to manual this will be a won't fix
due to the possibility of breaking existing themes
Change-Id: I0135f04c344bf817c104f951a657e2690f2d36bb
%pP reports playlist progress by position index, which treats every
track as equally long. For playlists with tracks of unequal length --
audiobooks with chapters anywhere from two minutes to an hour are the
motivating case -- position is a poor proxy for listening progress.
%pX reports the played percentage of the whole playlist by time: the
summed length of all preceding tracks plus the elapsed time in the
current one, relative to the playlist's total duration. It can be
used as a value, in a conditional, with %if(), or as a bar tag like
%pb.
If a playlist contains more than 500 tracks or the scan is taking too
long and the user aborts the tag will fallback to the behavior of %pP
except the progress through the current track will be included in the
returned percentage
--------------------------------------
Computing this needs every track's length, and reading metadata for
every track is too slow and disk-heavy for a tag that refreshes on the
WPS. Instead each track's length is estimated from its file size: the
skin engine scans the playlist in the background, a batch of files each
skin refresh, opening each file only to read its size (directory
metadata, no header parse). Size is turned into time by calibrating one
file of each type -- the first file of each extension is parsed once
with get_metadata to learn its bytes-per-second, and every later file
of that type reuses it. A single-format playlist, the usual audiobook
case, parses exactly one file and stat's the rest.
The result is an estimate -- bitrate varies within a type, especially
for VBR -- but it is cheap and accurate enough for a progress
indicator, and the playing track always contributes its exact elapsed
time. Per-track lengths are stored as two bytes of minutes each in a
movable buffer sized to the track count and allocated only while the
tag is in use; the cache is keyed on the track count and a crc of the
first, middle and last filenames, so a playlist swap or reshuffle is
caught. If the buffer cannot be allocated (a very large playlist on a
low-memory target) the tag falls back to position-based progress.
The buffer is allocated when playback starts (and when the now-playing
screen is opened with playback already active) rather than lazily on the
first WPS refresh, so the one-time allocation happens at a playback
boundary instead of during steady-state playback; it falls back to
allocating on first use if that point is missed.
Until the scan finishes the tag does not blank: it returns an instant
equal-weight estimate -- (completed tracks + fraction through the
current one) / track count -- which sharpens into the size-based value
as the scan fills in. So a theme can just use %pX and it is correct
from the first frame, and %?pX is true whenever a playlist is loaded.
Tested on a Sansa Clip Zip and in the simulator. On a 216-track,
~745 MB single-format audiobook playlist the length scan dropped from
~4150 ms (get_metadata on every track) to ~174 ms (one parse plus 215
file-size stats), roughly 24x lighter.
Change-Id: I6e572e78a10444bd513ddc77e30da04aa5153ef2
Allow setting context menu items
reuses WPS hotkey items
Runs the item
displays the item
Open plugin shows the item name
Pitch shows the pitch speed amount
add 'Show In Files' hotkey item
devices without a hotkey get an extra item
added Manual entries
Change-Id: I427e70e1cad15364ac5d2a7114032e97cc9eee1a
-New countdown timer plugin with pause, overtime support
-Add full name to credits and manual entry
-Make status strings translatable
Change-Id: I1437b2e5ac5ede292bdab8d36e58b81326ea2ba3
Limit these (less commonly used) "file handling" operations
to the File Browser while making it quicker to reveal the
file that is currently playing from the WPS.
"Open With" and "Delete" remain available as WPS shortcuts.
Change-Id: I91e582a45998160f07a3f7e16d475d770e8c5212
ipod:
- To be more consistent with other plugins and
(Settings) menus, press Long Select, instead of Menu,
to reset, and press Menu, or Select, to exit screen
fiiom3k:
- Press Back, or Select, to exit screen
- Press Menu, instead of Select, to switch between modes
- Use repeat button events and adjust values by 1%, instead of
by 0.1%, when scrolling, to speed up setting changes
- Get rid of surprising actions for Back/Menu/Volume buttons
Change-Id: Ifd16958bf56c7e20fb182aa157b4cb4dd19ac9b9
All URLs into Sandisk's web site return 404 or 403 errors, so
point at our local mirror of Sansa firmware files instead.
Change-Id: Ib3efcb62b13431f6416a320483877ca162ea5990
(Sandisk no longer hosts any firwmare for these old devices, so point
users at our own mirror instead)
Change-Id: Ibdcddcd2560b2062e84c82c53049022a7f76b226
I added the setting keep_directory which automatically updates
the last directory visited and restores it on next boot
--added manual entry
Change-Id: I0ffe6531d591d693806ce0bf56fe22b99e3315e9
They haven't seen development activity for the better part
of two decades and apparently were never able to even boot
to Rockbox, although the Rockbox bootloader could load the
original firmware.
Change-Id: I5cfa5909c21feaf2825aa685a05e78044b893a13
Both targets were part of the (presumably dead) Lyre project
and no longer build. The Mini2440 was much more complete than
the Lyre and doesn't seem terribly difficult to fix up to the
point where it at least builds, if someone still cares -- but
given it is a dev board in a box, it's unlikely it ever saw
much use.
Change-Id: I09745379d28db69ea9aaf77f0a62b049884260e1
fixes:
- traverse_dir was called recursively using two
MAX_PATH local buffers => possible stack overflow
- The import function inserted additional, incorrect,
entries when the whole line buffer was filled
- "Dirs not found" message overlapped number
of folders when generating folder list
- Final number of scanned folders wasn't displayed
- Wouldn't stop inserting when maximum number
of files in playlist was already reached
- Prevent buffer overflow when importing
- Don't write to fd after opening failed
- Use whole buffer with read_line, instead
of subtracting 1. Remove hard coded sizes
- CRs don't need to be removed in import function
(already handled by read_line)
features:
- Use insert context for *much* faster insertion
of large # of folders, and nicer progress display
- Use UI viewport
- Add progress indicator when saving or loading
- Display number of folders in edit list title
- Go back to plugin's main menu from edit list
- Only ask to save changes if list is dirty
- Warn before erasing modified playlist
- Flag successfully created playlist as modified
- Make folder scan wait for dircache
- Shorten menu item names
- Put "Play Shuffled" menu item first
- Remember selection when returning from submenus
- Go to WPS after ACTION_TREE_WPS
- Exit menu when pressing Back
- Perform an initial scan, if no data file exists
yet, when "Play Shuffled" or "Edit" is selected
Change-Id: I7df76f8fb8387888ce491d8b74b01b481e9997d3
This new tag returns the position in the playlist as a percent. The main usecase for this is to use it as a bar tag, allowing themes to visually present playlist progress.
Change-Id: I0eb001e7458d97b8a0db39f3980d9c283bc8806b
This is necessary if you want to detect touches on the bar region
using %Tl conditionals. Suppressing the auto-created region and then
creating one manually using %T doesn't give exactly the same results
because user-defined touch regions can't yet specify padding.
Change-Id: I2f4bde8eb56ba89645c72f3cc9d4b2355b934abd
It's been possible to label touch areas since the v3.9 stable
release, but it was never documented in the manual, only the wiki.
Change-Id: I6b92ff1d19369c105dc3a90aa04f8763f18a4214
Cut off only happens in pdf output (fixed column width), not html.
Add \tabnlindent in favor of spaces in some places for consistent
display of multi-line-tag-parameters.
Change-Id: Ie2d4196da9fcd02af5e3ff72dcc9a97ae2d25303
High-frequency files increasingly use a block size of over 4608B, which
means we need larger buffers to decode them. However, larger buffers no
longer fit in IRAM on less-capable devices, hurting performance for
"normal" file playback.
On our slowest devices (M68K and PP-based devices), this is not worth
the tradeoff as they will likely not have enough CPU oomph to decode and
downmix these files in realtime.
S5L87xx-based devices have the raw performance to do this, so we decided
to err on the side of wider file compatibility at the cost of some
performance.
All other devices are unaffected.
Change-Id: I7344cf4c8c6b7b5c14f1ea67381160665d6ece5b
