bidi_l2v() classified each character with ispunct((int)c), but c is
a decoded Unicode codepoint. ispunct() is only defined for values
that fit in an unsigned char (or EOF); a larger value is undefined
behaviour, and glibc then reads past the ctype table and reports
some codepoints as punctuation.
Hebrew final kaf (U+05DA) and gimel (U+05D2) land on such entries,
so a string ending in one had that letter trimmed off its RTL block
as if it were trailing punctuation and moved to the wrong end of
the line. Limit the punctuation test to ASCII so the result is
well-defined.
Change-Id: Ie6c3d8413f35ec3652e9228e3d5af05ef5bb811a
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
FONT_UI scans from MAXFONTS-1 to 0 to maximize the chances of getting a loaded
font but this may result in global_status.font_id being ignored even
if set through setuifont
this should take care of all the plugin woes dues to this
by setting the lcd font to the ui font before loading the plugin
and also making FONT_UI map to this font when font_get(FONT_UI) is called
if the desired font is not loaded then fallback to the previous behavior
Change-Id: I101d6f91910c17b08fca2b988a0a99c9e6899bee
GetNextProcess, GetProcessPID and GetProcessInformation are replaced by proc_listallpids() and proc_pidpath()
Co-authored-by: ChatGPT (GPT-5.3 Mini) <chatgpt@openai.com>
Change-Id: Ic4fe13c405e11b658b1a9540e49741d4e69069f3
- insertMulti() -> insert()
- QString::fromUtf16() with a parameter type other than char16_t*
- enterEvent() parameter type changed from QEvent to QEnterEvent
- QVariant -> QMetaType
Co-authored-by: ChatGPT (GPT-5.3 Mini) <chatgpt@openai.com>
Change-Id: Ia9c6c93e281475856e8355a8aa0e64c474eed80c
This removes usage of the deprecated macOS Gestalt() API (2/2)
Co-authored-by: ChatGPT (GPT-5.3 Mini) <chatgpt@openai.com>
Change-Id: Id10386285469c06f082a7dcdcc3284b97519b10a
This removes usage of the deprecated macOS Gestalt() API (1/2)
Co-authored-by: ChatGPT (GPT-5.3 Mini) <chatgpt@openai.com>
Change-Id: Ia3af510412a97258dcd9fc9134708900c04c62c4
FONT_UI is a placeholder when it gets assigned it isn't resolved
immediately
when its time to resolve the font it is processed with font_get(int font)
first it sets it to the last slot
and then decrements till it gets a valid font
Change-Id: I3c203d58ed2d813d206f5b435e6b55ed196cf213
add get_metadata_afmt function so we don't have to extra functions
remove unneeded bounds check on audio_format in rbcodec_format_is_atomic()
add bounds check on audio_format in get_metadata_afmt()
Change-Id: I76bd869100b000579c6546f0670ba4ba2c541f22
tagcache.c add_tagcache() and potentially
skin_tokens.c wps_playlist_percent_prepare()
make calls to probe_file_format() prior to calling get_metadata_ex
resulting in some small amout of duplicated work
especially in the case of add_tagcache this can add
up to a lot of duplicated work
breaks out audio_fmt so these can supply the afmt other callers just
supply probe_file_format(trackname) in the function call
Change-Id: I8084213b8ee7e04d76dce0986beb83d443ac804b
%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
Was missing:
* Arabic Supplement
* Arabic Extended B
* Arabic Extended A
* Rumi Numerals
* Arabic Extended C
* Indic Isqaq Numerals
* Ottoman Siyaq Numerals
* Arabic Mathematical Alphabet Symbols
Worth noting that most of these are vanishingly unlikely to ever show up
in the context of Rockbox. (The exceptions are "Arabic Supplement" and
possibly the Mathematical Symbols)
Also corrected "Arabic Presentation" into two distint blocks, as
the characters between them (fe00-fe6f) are NOT indicative of RTL.
Change-Id: I0c5c547921c789d32425682c8c75edb21428f549
Commit d1be73c ("keyboard.c Use viewports, move text box pos")
moved the picker and edit line into dedicated viewports. Under an
RTL UI language these viewports get VP_FLAG_ALIGN_RIGHT, so
lcd_putsxy mirrors every call; with the per-character cell drawing
this reversed the picker grid and the edit line (Hebrew shown
reversed, Latin filenames backwards, wrong caret).
- Clear the alignment flag on the keyboard own viewports so the
picker grid and cell layout are no longer mirrored.
- Draw the edit line as a single string so the bidi engine reorders
mixed Hebrew/Latin correctly, and use the full line width.
- Compute the caret from the bidi (LTR-base) visual layout so it
lands at the insertion point, including mixed Hebrew+Latin text.
- Pick the edit-line direction and invert the left/right cursor
keys based on the text first strong character.
Change-Id: I79f1c444bc9121fd5018ad5f6f4148afe2c1a3e1
It can be used to choose which Apple Developer ID to use when signing the build of the Qt apps. By default, it uses ad-hoc signing, i.e. no Apple Developer ID is needed.
Change-Id: I5634e318f4949107eb954b729b2f8f1d60fad115
It is always enabled, except in the following situations:
* bootloaders
* warble or checkwps applications
* devices with less than 4MB of RAM
* imx233-based devices
imx233 is a special case; that will be backed out we figure out why
it fails to boot if the binary size exceeds 1MB.
Change-Id: If4a89e389f562bb5791a565fba99c830213473d3
