Select Git revision
Search by author
- Any Author
- authors
-
Administrator root
-
Alaric Senat
asenat
-
Alexandre Janniaux alexandre-janniaux
-
Bart - The Review Bot
Bart
-
Benjamin Arnaud
bunjee
-
Christophe Massiot cmassiot
-
Claudio Cambra
claucambra
-
David dfuhrmann
-
Denis Charmet
typx
-
Fatih Uzunoğlu fuzun
-
Felix Paul Kühne
fkuehne
-
François Cartegnie
fcartegnie
-
Gabriel Lafond-Thenaille gabriel_lt
-
**** project_435_bot
-
**** project_435_bot_867220ea9cbb40f38051abad33491375
-
Ilkka Ollakka
ileoo
-
Jean-Baptiste Kempf
jbk
-
Jean-Paul Saman
jpsaman
-
Johannes Kauffmann
JohannesKauffmann
-
Konstantin Pavlov
thresh
- Jun 13, 2021
-
-
Fixes #25612
-
-
-
-
fixes #25737.
-
-
-
-
-
-
-
-
-
-
-
-
Modifications based on the design guidelines
-
-
- Jun 12, 2021
-
-
per suggestion in MR review.
-
...for es language attributes. while all iso-639 records in the table (iso-639_def.h) currently have a two char iso-639-1 code, with the exception of "Original audio", if/when MR 146 ([1]) is merged, there will be many records with no iso-639-1 code, which will cause empty strings to be captured in the language properties for such languages. all records, now and after MR 146, have an iso-639-2B code so switching to that will solve the problem. (all but one have iso-639-2T fwiw). [1]: !146
-
such that users have a hint of what the different available codes are.
-
under this algorithm codes are searched first, names second. (though of course codes are skipped if length is not 2 or 3). in short, this is partly because in cases where clashes between short names and codes occur (which can happen, as discussed shortly), i feel that it is best to prefer the code match, and partly because of the disadvantages of using names as identifiers, as discussed in a moment, that make codes perhaps more likely to be used for most languages. please note the note in the previous commit about how this is only of relevance to users specifying language preference for dvdnav and bluray, with `--sub-language`, `--audio-language` and `--menu-language` options. -- names as identifiers -- the disadvantages/problems of using names as identifiers: 1. first, note that since 236ca7ae introduced the possibility, the help text of the few relevant options has never actually informed users that it was possible. (in fact they also fail to clarify that the mentioned codes to be used are iso-639). so presumably any users of these options are more used to using codes already. 2. only English names are available, since only English names exist in the table, and the lookups have never involved translation. this makes the feature less useful than originally viewed in the commit log of the commit that introduced it. so for instance you can use "french" but not in fact "francais". 3. the names in the iso-639 table are primarily intended for display purposes rather than matching purposes. while many of the names are simple like "English" and "French", working just fine for the type of lookup performed, many are not so ideal like the following examples (some of which have been picked from the MR 146 update ([1])): - "Greek, Modern" (updated to "Greek, Modern (1453-)") - "Chichewa; Nyanja" - "Sotho, Southern" - "Tonga (Tonga Islands)" - "North Azerbaijani" - "Limburgan; Limburger; Limburgish" - "Gaelic; Scottish Gaelic" - "Interlingua (International Auxiliary Language Association)" - "Altaic (Other)" - "Apache languages" there are many such examples (especially after MR 146). (we would not want to rename them to be better identifiers, since this would make them less ideal for their primary display purpose, and it could make future updates from the glibc set much harder). 5. it is not even possible for users to easily discover the (English) language names (or rather labels?) that are available for use instead of codes. not all are easily guessable. 6. as shown by the MR 146 update, the names are far more prone to change than codes. this creates a backwards compatibility problem both for CLI use and saved settings. (we should not want to avoid such updates just for such backwards compatibility). so, aside from some cases like "english" and "french", which are ideal and reliable, for most languages codes are the better choice, putting more emphasis on codes being checked first. though of course the name/code clash issue discussed next is more significant. -- result differences -- the results given are identical with the current data set, since there are currently no records where the 3-char name of one matches (ignoring case) the iso-639-2 code of another. if/when MR 146 is merged, there are some such clashing records added, and considering the order of the records (preserved from glibc order to make updates easier if for no other reason), a different match would be returned by this algorithm than the previous one, preferring now the code-based match of the later record over the name-based match of the earlier. the clashing records of interest are: - "Kru" and "Kurukh", with the latter having an ISO-639-2 code of "kru". - "Mon" and "Mongolian", with the latter having a code of "mon". with "Kru" coming before "Kurukh" and "Mon" before "Mongolian", use of "kru" and "mon" with the previous algorithm would have matched "Kru" and "Mon" named records respectively, while the new algorithm will instead match "Kurukh" and "Mongolian" respectively, preferring the code-based match. (MR 146 with the old algorithm actually introduces a regression for "Mongolian" in that "mon" then matches the "Mon" record, whilst the new algorithm fixes that, restoring the "Mongolian" match). thus "Kurukh" and "Mongolian" could with the previous algorithm only be matched via their full names (or the "mn" iso-639-1 code in the Mongolian case), whilst with the new algorithm they can be reached via codes also, whilst "Kru" and "Mon" can only now be reached via codes ("kro" and "mnw" respectively). either way there's an unavoidable imperfection in doing a case-insensitive name-inclusive lookup, but i feel code-based being primary is best; we don't necessarily want to ditch the name-based lookup considering those languages that it does work well for, and i don't expect we would want to make the name search case-sensitive, requiring capitals. [1]: videolan/vlc!146
-
...with one that searches the names of all the records, then the codes, rather than all attributes of one record, then the next. (it is not necessarily the final form of this new algorithm, with a further tweak to come in the next commit). this alternate implementation, is just a simple extension of the "normal" (code-only) search algorithm, adding an extra conditional table attribute search, rather than having an entirely different algorithm for name-inclusive searches (which was copied from the old hack this replaced). also, under this new algorithm, ISO-639-1 codes are only compared when len==2, and similarly ISO-639-2 codes are only compared when len==3, saving wasted comparison effort in exchange for some possible more looping. note that name-inclusive searches are only performed by dvdnav, bluray, and esout, and only the first two are relevant with respect to considering any difference in results, since esout assumes 2/3 char language strings are iso-639 codes and thus does not perform a name-inclusive search for them (at the expense of not being able to reach the three letter name records by name). for dvdnav and bluray, this concerns recognising any user specified option values indicating "preferred language" per fc4005c1. -- result differences -- the results given happen to be identical to that of the previous algorithm, both with the current data set, and the updated one in MR 146 ([1]). noting that the table is updated from the data from glibc, maintaining the same order, it should be understood that the results would only be different to the previous algorithm if the table ever had an entry added with a three/two character name that matches (case insensitively) a code from an entry earlier in the table, in which case this new entry would be the match rather than the earlier entry. (name match now always wins rather than first matching record in the list). [1]: !146
-
if the code is 2 or 3 chars long it is assumed to be an iso-639 code and so a direct lookup is performed. otherwise: 1. a call was made to the `LanguageGetCode()` function, which performs a name-inclusive search and then returns the match's ISO-639-1 code, or "??" on no match. 2. a further lookup was then done with that ISO-639-1 code to simply get to the record pointer such that it can then get the attribute it actually wants here - the language name. we are in a position now to achieve the goal more efficiently and simply through `vlc_find_iso639()`. -
using the new functionality of the new `vlc_find_iso639()` function.
-
esout, dvdnav and bluray are currently using a very old hack of searching all fields of the raw language table for searches where they want to allow matches against the names, not just codes. this is a step towards getting rid of that ugly old hack by offering proper functionality for doing such a search. the implementation currently duplicates that used by the three previously mentioned use cases. i intend to rework the implementation in a subsequent commit; first though we need to just set things up for simply removing the hack. that new implementation will better justify this being done with a flag rather than a separate function.
-
just return NULL instead - much more simple and efficient.
-
...with a new function, which also replaces direct use of the three code-specific functions. all users of these three functions had a common pattern of using the iso-639-1 lookup for len==2 codes, and for len==3 doing a 2B lookup, falling back to a 2T lookup if that failed. this pattern is now implemented in the new `vlc_find_iso639()` function. the three individual functions are now made private, not being needed publicly anymore. they also now just do a straight `strcmp()` rather than `strncmp()` because they are only called for the right length of strings. the implementation will be tweaked slightly in the next commit.
-
this was introduced in b8774b3c as part of de-duplicating code, however the two blocks that used the relevant code were also merged in the same commit, making the function unnecessary. this is being done partly as cleanup before the next commit, which would remove it anyway, but doing it separately first makes the diffs more clear. this brings the use of the lookup functions back into line with use everywhere else in the codebase.
-
a handful of small mistakes were made in "simplifying" the iso-639 handling back in b8774b3c. this corrects those mistakes, and in doing so brings this back into line with all other use of the iso-639 lookup functions. the mistakes: 1. the english/native comments were added the wrong way around. 2. the 2T fallback lookup was made unreachable. after searching with the 2B code, we either have a match, or the 'unknown' record (which uses '?' characters). since every single entry in the table has a non-empty 2T code (ignoring the irrelevant end marker), and since the 'unknown' item also has a non-empty 2T code ("???"), the fallback path to search with 2T would never be triggered. 3. the avoidance of storing language code on failed lookup was broken. the `*code` condition would always be true, since matching records always have a 2T code, and for no match "???" is always returned from the 'unknown' record. this means that for failed matches, "???" would be unintentionally written into the entry. 4. the len==3 condition on iso-639-2 lookup was lost. the previous code conditionally only performed an iso-639-2 lookup if the string length is 3, just like all other cases of such lookups throughout the codebase. there was no specific reason for this to have been removed here. (this is going to get restored anyway momentarily when the code gets de-duplicated by a new function). 5. an incorrect comment was given to the newly introduced function. the new `GetIso639_2LangCode()` helper function it introduced always returns len==3 strings, never len==0.
-
-
fixes #25592
-
closes #25587
-
-
-
introduce widget 'CSDMouseStealer' which is used to disable mouse interactions in MainInterface::csdBorderSize around Main UI
-
-
-
And update MediaGroupList and VideoAll components.
-
-
