- Jun 12, 2021
-
-
-
introduce widget 'CSDMouseStealer' which is used to disable mouse interactions in MainInterface::csdBorderSize around Main UI
-
-
-
And update MediaGroupList and VideoAll components.
-
-
-
- Jun 11, 2021
-
-
Fixes #6651
-
Fix #25810
-
-
the string type was unusual in having a special extra boolean parameter to select between an ordinary string type control and a password type one, rather than having a password specific type which derived from it, as everything else does. splitting out password controls into their own derived type simplifies things a little. it also achieves two other things: - it puts us into a position from which we can further customise password controls, as i have done in some later work to be submitted after this. - it makes it easier/cleaner to add further string derivative controls, as i also have done in at least one instance in other work. note that we are also removing a boolean param from the constructors of `IntegerListConfigControl`. this type only had this param because the string type did, in connection to the use of generic macros in the simple preferences code.
-
we have absolutely no need for such a dummy panel.
-
it makes it much easier to understand the makeup and contruction of each individual view and of the entire window this way, with the components and construction code for each view grouped more logically together. even more so when a new view is added in later work of mine. grouping by type of component and interweaving the creation of the views just make things unnecessarily harder to follow and work with.
-
with the adv tree and tree filter lazy creation condition blocks now merged, let's reorganise the construction code more logically.
-
the search filter for the advanced preferences tree should always be lazily created at the same time we lazily create the tree widget itself. there would never be a situation where this function would find one already created and not the other. we can thus merge the condition blocks here.
-
move methods such that types with multiple constructors have them adjacent to each other, rather than having other methods in between. the point of this was that it made the code much easier for me to work with.
-
no control uses the `vlc_object_t` object captured by the base class, so let's remove it, making things much tidier and more understandable.
-
-
-
-
-
1. the name suggests that it returns an item's type, yet in fact it returns the item's type class, so essentially it gives up false information, as named. (one exception is the hotkey group control which actually does give up its specific type, yet that is somewhat a lie also because the control does not represent a single config item). 2. any efficiency gain from returning a hard-coded value is dwarfed by the mess and fragility of having a collection of implementations cluttering the files, returning hard coded values. it is much more straight forward to just return the item's actual type value, and either let the caller use `CONFIG_CLASS()` on it where appropriate, (or do it for them with a more suitably named method). 3. this method is only used in one single place, the open-capture-advanced code, so is certainly not worth the mess. this reworks the method to a single implementation on the base class, which just returns an item's raw and actual type. to account for the special hotkey group control which has a null item pointer since it is not linked to a single config item unlike all other controls, it guardedly returns `-1` if the item pointer is null. the one user of this function, (which happens to have no interest in the hotkey control), now gets the raw type, asserts that it did not unexpectedly get `-1` to protect against any future mistake, reduces the type down to type class itself to get the info it actually wants, and proceeds from there as normal.
-
i have a use for `CONFIG_CLASS` now in the qt prefs code, and elsewhere in later work. the other test macros may be useful to have publicly for preference interface code so were moved also, and besides, having them all in one place makes finding them and maintaining them easier. there's no harm in exposing them to plugins.
-
the `getType()` call actually returns the type class, and all of these removed types inherit from the generic string control class, which returns `CONFIG_ITEM_STRING` when this method is called.
-
unused since e1c82853
-
unused since dda157b5
-
-
-
-
-
The android bug has been fixed since Android 5.0.
-
Co-authored-by:
Zhao Zhili <zhilizhao@tencent.com>
-
- Jun 10, 2021
-
-
On iOS and tvOS, dylibs must be wrapped into a framework and frameworks must be flattened into the frameworks/ application directory (or global to the system which is not possible in the general case), so dylibs can't be in the VLC_PKG_LIB_DIR/plugins folder. Redirect VLC_PKG_LIB_DIR/plugins toward VLC_PKG_LIB_DIR/ on those platforms.
-
Darwin platforms are using frameworks to embed libraries. Some of them like iOS and tvOS even forbid the use of dynamic libraries that are not wrapped into a framework. Since frameworks can contain various things (headers, resources, etc), we don't necessarily want to browse their whole tree if their structure is well-defined. In our case, since plugins are bundles and not dylibs, there's not linking and there's no point in supporting versionning so we can expect the plugin's dynamic library in the root of the framework, named like the framework without the .framework part. Since MacOSX can also make use of frameworks, this is enabled for all darwin platforms, though it might not use them.
-
-
Previous patches[1] added a warning regression by fixing the initializer of the max_align_t[] array used in vlc_list_entry_dummy, because a max_align_t array cannot be initialized with integers, typically where the max_align_t is implemented as an union of multiple types. [1]: c4f0f964 By providing an initializer for max_align_t, we can workaround this limitation and initialize the array without those warnings: ../../lib/media.c:264:5: warning: suggest braces around initialization of subobject [-Wmissing-braces] vlc_list_foreach( node, &list, node ) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../include/vlc_list.h:263:23: note: expanded from macro 'vlc_list_foreach' && ((pos) = vlc_list_entry_p((vlc_list_it__##pos).current, \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../include/vlc_list.h:243:44: note: expanded from macro 'vlc_list_entry_p' (0 ? (p) : (void *)(((char *)(node)) - vlc_list_offset_p(p, member))) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../../include/vlc_list.h:240:12: note: expanded from macro 'vlc_list_offset_p' ((p) = vlc_list_entry_dummy(p), (char *)(&(p)->member) - (char *)(p)) ^~~~~~~~~~~~~~~~~~~~~~~ ../../include/vlc_list.h:237:73: note: expanded from macro 'vlc_list_entry_dummy' (0 ? (p) : ((void *)(&(max_align_t[vlc_list_entry_aligned_size(p)]){0}))) ^
-
-
This makes sure that the window geometry is updated before the first new size buffer is attached.
-
-
- Jun 09, 2021
-
-
Refactor the boolean to int arithmetic so as to keep only boolean operation. Name the deadline so that the condition more easily reflects the comment above. No functional changes.
-