No ECMAScript 6/7 in Frameworks, please
Hi everyone, just a quick heads up that KDE Frameworks minimum Qt version requirement policy [1] does not permit the use of ECMAScript 6/7 features in repositories such as KDeclarative and Plasma-Framework at this time. Current supported Frameworks minimum version is Qt 5.11 (I think? 5.13, 5.12, 5.11) but ECMAScript 6/7 features (like Arrow-functions, "let" keyword, for..of, etc) were only added in Qt 5.12. There's a few convenience methods (such as Array.find, Array.findIndex (very useful when dealing with ComboBoxes), String.startsWith and endsWith, String.includes, Number.isFinite, etc) that were added (partially by me \o/) in Qt 5.8 and Qt 5.9 and are safe to use, see [2] for a full list - most notably those with a "ECMAScript 6 added in Qt 5.x" comment. Thanks Kai Uwe [1] https://community.kde.org/Frameworks/Policies [2] https://doc-snapshots.qt.io/qt5-5.11/qtqml-javascript-functionlist.html
Re: How to prevent users from opening GitLab issues?
On Thu, Oct 10, 2019 at 3:26 PM Simon Redman wrote: > > You can add templates by following the directions here: > https://docs.gitlab.com/ee/user/project/description_templates.html#creating-issue-templates > > (Similar steps for pull requests, check out the kdeconnect-kde repo if you > want the templates I made) > > Unfortunately regular developers can't set the default. It has to be done by > an admin. At least I assume so because I have been looking for the repository > settings and I can't find them :) > > I wish we could make it required that a user pick *some* issue (and PR) > template. That way at least you could have a bug report "template" which says > "Don't report bugs here" Specifying a default issue template is an Enterprise Edition only feature i'm afraid. Please see https://docs.gitlab.com/ee/user/project/description_templates.html#setting-a-default-template-for-merge-requests-and-issues--starter for more information Regards, Ben > > On 10/9/19 11:30 AM, Alexander Saoutkin wrote: > > One should be able to add a issue template to issues (similar to how diffs > are prefilled in phab), which would make clear the purpose of issues. > > feverfew > > On Wed, 9 Oct 2019, 19:23 Nate Graham, wrote: >> >> GitLab Issues are intended to be the replacement for Phabricator tasks >> and are not intended to be used for user bug reports. We can't disable >> this feature or else we lose the project task tracking functionality >> entirely, which would be a major regression compared to Phabricator. >> >> Yes, it is very confusing to users, and yes, we are going to be dealing >> with users clogging it up with bug reports for the foreseeable future >> until we manage to rename Issues to "Project Tasks" or add a big banner >> directing users wanting to file bugs back to Bugzilla or something. >> >> Nate >> >> >> >> On 10/9/19 7:40 AM, Albert Vaca Cintora wrote: >> > As we transition to Gitlab, our users find two different ways of >> > reporting issues: in Bugzilla and in Gitlab. Since we don't have plans >> > to deprecate bugzilla, is there any way we can disable issues in Gitlab? >> > >> > Albert >> > >> >
Re: How to prevent users from opening GitLab issues?
On Thu, Oct 10, 2019 at 7:23 AM Nate Graham wrote: > > GitLab Issues are intended to be the replacement for Phabricator tasks > and are not intended to be used for user bug reports. We can't disable > this feature or else we lose the project task tracking functionality > entirely, which would be a major regression compared to Phabricator. > > Yes, it is very confusing to users, and yes, we are going to be dealing > with users clogging it up with bug reports for the foreseeable future > until we manage to rename Issues to "Project Tasks" or add a big banner > directing users wanting to file bugs back to Bugzilla or something. One possibility would be for us to enable Gitlab's Bugzilla integration, which would make Bugzilla more discoverable compared to Gitlab issues. https://docs.gitlab.com/ee/user/project/integrations/bugzilla.html We could also restrict Gitlab issues to those people who are members of the project. This would mean however that everyone who doesn't hold a Developer account (or given the Reporter role separately) is completely cut-off and unable to see our internal tasks. Changing the name of Issues would unfortunately require changes to the actual Gitlab source code in many places unfortunately (and would cause translation issues for those who had changed the language from English to something else) Introducing a custom banner would likely be less invasive, but would still require code changes i'm afraid. (Side note: in the past we have received complaints about Bugzilla making their email address public despite us having a warning in 100pt+ font that would happen as the first page in the registration process which is the first thing you saw - so people will miss a custom banner) > > Nate > Cheers, Ben > > > On 10/9/19 7:40 AM, Albert Vaca Cintora wrote: > > As we transition to Gitlab, our users find two different ways of > > reporting issues: in Bugzilla and in Gitlab. Since we don't have plans > > to deprecate bugzilla, is there any way we can disable issues in Gitlab? > > > > Albert > > >
Re: How to prevent users from opening GitLab issues?
On 10/10/19 3:28 AM, Ben Cooksley wrote: Specifying a default issue template is an Enterprise Edition only feature i'm afraid. Please see https://docs.gitlab.com/ee/user/project/description_templates.html#setting-a-default-template-for-merge-requests-and-issues--starter for more information I must admit feeling rather frustrated that so may of the features which make a GitHub/GitLab style of platform desirable are EE-only. Our crippled CE version is missing these features as well as some of the features that Phabricator currently has, such batching review comments, formal approvals, strong relationships between tasks, and a web-based notification system that doesn't send you ten thousand emails a day. Nate
Re: How to prevent users from opening GitLab issues?
On Fri, Oct 11, 2019 at 4:38 AM Nate Graham wrote: > > On 10/10/19 3:28 AM, Ben Cooksley wrote: > > Specifying a default issue template is an Enterprise Edition only > > feature i'm afraid. > > Please see > > https://docs.gitlab.com/ee/user/project/description_templates.html#setting-a-default-template-for-merge-requests-and-issues--starter > > for more information > > I must admit feeling rather frustrated that so may of the features which > make a GitHub/GitLab style of platform desirable are EE-only. Our > crippled CE version is missing these features as well as some of the > features that Phabricator currently has, such batching review comments, > formal approvals, strong relationships between tasks, and a web-based > notification system that doesn't send you ten thousand emails a day. > For the record, we currently have a request with them to move batching of review comments to CE. They've also already agreed to move approvals (not blocking) to CE. Once the batching is in I suspect your email problems will become less of an issue. (This isn't the first time i've mentioned the above two items either) Please note that an Enterprise Edition license would be available to us, if it weren't for Community Policy prohibiting the use of non-FOSS software. > Nate > Regards, Ben
[ANNOUNCE] CMake 3.16.0-rc1 is ready for testing
I am proud to announce the first CMake 3.16 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.16
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.16/release/3.16.html
Some of the more significant changes in CMake 3.16 are:
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
* The "target_precompile_headers()" command was added to specify a
list of headers to precompile for faster compilation times.
* The "UNITY_BUILD" target property was added to tell generators to
batch include source files for faster compilation times.
* The "find_file()", "find_library()", "find_path()",
"find_package()", and "find_program()" commands have learned to
check the following variables to control searching
* "CMAKE_FIND_USE_CMAKE_ENVIRONMENT_PATH" - Controls the searching
the cmake-specific environment variables.
* "CMAKE_FIND_USE_CMAKE_PATH" - Controls the searching the cmake-
specific cache variables.
* "CMAKE_FIND_USE_CMAKE_SYSTEM_PATH" - Controls the searching
cmake platform specific variables.
* "CMAKE_FIND_USE_PACKAGE_ROOT_PATH" - Controls the searching of
"_ROOT" variables.
* "CMAKE_FIND_USE_SYSTEM_ENVIRONMENT_PATH" - Controls the
searching the standard system environment variables.
* The "file()" command learned a new sub-command,
"GET_RUNTIME_DEPENDENCIES", which allows you to recursively get the
list of libraries linked by an executable or library. This sub-
command is intended as a replacement for "GetPrerequisites".
* "ctest(1)" now has the ability to serialize tests based on
hardware requirements for each test. See Hardware Allocation for
details.
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One may manually enable runtime linking for shared libraries
and/or loadable modules by adding "-Wl,-G" to their link flags (e.g.
in the "CMAKE_SHARED_LINKER_FLAGS" or "CMAKE_MODULE_LINKER_FLAGS"
variable). One may manually enable runtime linking for executables
by adding "-Wl,-brtl" to their link flags (e.g. in the
"CMAKE_EXE_LINKER_FLAGS" variable).
* "cmake(1)" "-E" now supports "true" and "false" commands, which do
nothing while returning exit codes of 0 and 1, respectively.
* "cmake(1)" gained a "--trace-redirect=" command line option
that can be used to redirect "--trace" output to a file instead of
"stderr".
* The "cmake(1)" "--loglevel" command line option has been renamed
to "--log-level" to make it consistent with the naming of other
command line options. The "--loglevel" option is still supported to
preserve backward compatibility.
* The "CMAKE_FIND_PACKAGE_NO_PACKAGE_REGISTRY" variable has been
deprecated. Use the "CMAKE_FIND_USE_PACKAGE_REGISTRY" variable
instead.
* The "GetPrerequisites" module has been deprecated, as it has been
superceded by "file(GET_RUNTIME_DEPENDENCIES)".
CMake 3.16 Release Notes
Changes made since CMake 3.15 include the following.
New Features
Languages
-
* CMake learned to support the Objective C ("OBJC") and Objective
C++ ("OBJCXX") languages. They may be enabled via the "project()"
and "enable_language()" commands. When "OBJC" or "OBJCXX" is
enabled, source files with the ".m" or ".mm", respectively, will be
compiled as Objective C or C++. Otherwise they will be treated as
plain C++ sources as they were before.
Compilers
-
* The "Clang" compiler is now supported on "Solaris".
Platforms
-
* On AIX, executables using the "ENABLE_EXPORTS" target property now
produce a linker import file with a ".imp" extension in addition to
the executable file. Plugins (created via "add_library()" with the
"MODULE" option) that use "target_link_libraries()" to link to the
executable for its symbols are now linked using the import file. The
"install(TARGETS)" command now installs the import file as an
"ARCHIVE" artifact.
* On AIX, runtime linking is no longer enabled by default. CMake
provides the linker enough information to resolve all symbols up
front. One m
