Re: [Development] Should QObject::event() be protected or public?
On 15/3/24 19:57, Jean-Michaël Celerier wrote: There's nothing more frustrating that instantiating a C++ type on the stack like MyType foo; and having to call a function with: static_cast(foo).someVirtualMethod(); Or: foo.Base::someVirtualMethod(); [..] -- Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[kwayland-integration] [Bug 447538] On Wayland, Kate doesn't prefer opening files in an instance on the current virtual desktop
https://bugs.kde.org/show_bug.cgi?id=447538 --- Comment #4 from Ahmad Samir --- I don't know much about Wayland; so here is an observation, assuming there is a kate instance on the current virtual desktop, and focus stealing prevention is set to none: - Ctrl+Clicking in konsole opens the file in that kate instance and activates the window - From that konsole window, using `kate /path/to/some/file`, the file is opened in kate, but the window isn't activated, and the task manager highlights the kate window as requesting attention -- You are receiving this mail because: You are watching all bug changes.
Re: [Development] Raising the minimum to C++20
On 9/2/24 16:45, Volker Hilsheimer via Development wrote: I haven’t heard any convincing argument for us raising the minimum to C++ 20 in the foreseeable future. Not for building Qt, and not for using Qt. At most we get some convenience constructs for ourselves. There’s value in that, of course. But unless I miss something huge, then that value is quite small. We have a working implementation of e.g. atomics that is sufficient for our own needs; we have our own implementation of . We now also have QSpan, which we practically don’t use anywhere in Qt so far. And that value is of practically no relevance to users of Qt - they can use C++20 in their application, together with Qt. The 3 big C++20 features people ask us about are modules, co-routines, and concepts. We have no compelling answers here. You can’t build Qt into a set of modules; we have no APIs using co-routines; none of our template constraints are expressed, or at least documented, as concepts, and there is no draft of a concept library for things that might be interesting for Qt users. Do we really want to go out and say that C++20 is now mandatory to build or use Qt, while we have no convincing story on any of that? Do we want to ask people to make a significant investment if they want to work with the latest Qt version, but even then they don’t get any support for any of the big three features? So, as much as I’d like for some of the things I’m working on to be able to benefit from C++ 20, I’d also say that we should rather slow down, and only require C++20 if we have something to show for it. We can perhaps still make improvements to better enable C++20 features, such as std::ranges, in application code; but that should neither require Qt to be built with C++20, nor require applications that don’t use std::ranges to use C++20. Volker The way KDE Frameworks and Plasma have raised the minimum required C++ version was asking distributions "do you have a problem if we require C++17?" and the answer was "we have recent enough gcc/clang, so go ahead if you want", so Plasma 5 and KF5 raised the minimum required to C++17 during the lifetime of KF5 (with the caveat, IIRC, of not using C++17-only headers unconditionally in public header files). Last time I checked, Plasma 6.0 now requires C++20, using the same process outlined above. I wonder if this can be done here too. Can you survey Linux distro developers/maintainers, your customers and other point-of-contacts? This way you will have a clearer picture of the situation, and can make an informed decision. For example I've started compiling with C++20 locally about 4-5 months ago, the CI still uses C++17, I have seen very few issues. My 2p's. Regards, Ahmad Samir On 9 Feb 2024, at 10:41, Vladimir Minenko via Development wrote: Just as a reminder, the "C++20 is mandatory for users of Qt (Phase III)” (https://bugreports.qt.io/browse/QTBUG-109362) says "The tentative plan is Qt 6.12+” and "C++20 is required for the development and buiding of Qt itself (Phase II)” (https://bugreports.qt.io/browse/QTBUG-109361) - "The tentative plan is Qt 6.9-6.11” With all the respect to the power of C++20 and enthusiasm to use it from Qt Project developers, what should we expect from all other users if we would make this change in 6.8, considering: a) just 4 months left to the Feature Freeze for 6.8 b) there is zero communication to users beyond the above issues on Qt But Reports and discussions on this mailing list (which is actually for Qt developers and not Qt users, BTW) c) there is no other communication about the done and ongoing works introducing C++20 in Qt and plans for future versions, beyond the talk from Mark at QtWS22 and careful reading of “What’s New” pages Qt crashed such a change on users with C++11 and with C++17 in the past. Each time after this, there were much more negative responses than “thank you”s. I still hope we find a way to do this better this time. And just “faster” is not “better" In the current shape, my vote is “no”. -- Vladimir On 3. Feb 2024, at 18:15, Thiago Macieira wrote: On Tuesday, 2 May 2023 17:39:01 PST Thiago Macieira wrote: I don't have access to QNX and INTEGRITY toolchain information, so I'd like to request that they simply match the feature list above, with minimal workarounds. What's the current state for those, for supporting Qt 6.8 or 6.9? We have VxWorks coming in and I'd like it to meet a higher minimum bar than "legacy". That is, I'd like VxWorks to require a C++20-compliant compiler before being enabled in our CI, but that's only fair if we have a line-of- sight to bringing everyone to C++20. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Development mailing list
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
On 30/11/23 12:49, Giuseppe D'Angelo via Development wrote: Hi, OpenSSL 1 has reached EOL last September: https://www.openssl.org/blog/blog/2023/09/11/eol-111/ Qt has supported OpenSSL 3 for a while, and so last week I pushed a patch to drop OpenSSL 1 support from Qt. "This has made a lot of people very angry and been widely regarded as a bad move." It turns out that not every platform officially supported by Qt ships OpenSSL 3 yet. Some of these platforms are promising to maintain OpenSSL 1 for a little while longer, for instance Ubuntu 20.04 LTS: https://canonical.com/blog/running-openssl-1-1-1-after-eol-with-ubuntu-pro See this thread started by Albert on the kde-distributions ML about the same issue https://mail.kde.org/pipermail/distributions/2023-November/001459.html Typically when you plan to support EOL software, you do the extra work on your own, that should include e.g. patching Qt to get that support back, and you maintain the patches to Qt code on your own too. That is my understanding of how corporate Linux support works, and it's confirmed by what Jan Grulich posted in a reply to the above KDE ML thread: https://mail.kde.org/pipermail/distributions/2023-December/thread.html (pipermail doesn't show links to the rest of the thread if it spans multiple months). How to move forward from here: "revert the patch", sure, but also not so fast: * First and foremost, I'd like a semi-formal insurance from Qt SSL maintainers that they're willing to maintain OpenSSL 1 code in Qt as long as needed. This should be done publicly, in docs + blog posts, because users are going to depend on this information. * For "how long" is that exactly? Also a very good question. Can we gather 1) which supported platforms are still offering only OpenSSL 1, and 2) for how long do they plan to support OpenSSL 1, and 3) for how long Qt would like to support these platforms? (Basically, assessing whether the "insurance" above is realistic) [...] * Then, a plain revert isn't a good idea either: the whole point of the original commit is that using OpenSSL 1 is outright dangerous if you don't know what you're doing. (Using unmaintained security-sensitive code is a terrible idea). Therefore, a revert must also include make OpenSSL 1 entirely opt-in (cmake switch), and not using any automatic detection whatsoever: users of Qt should never ever be enabling it "by accident". Just stating the obvious: I agree, must be opt-in with a clear disclaimer "You're on your own, if it breaks, you get to keep the pieces". [...] My 2p's worth. Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 11:06, Ivan Solovev via Development wrote: I would therefore propose to remove the file from qt5.git: +1 from my side. I believe I simply do not have the clang-format tool installed on my system, because it usually breaks the formatting of the patches, not improves them. One way to address these problems, especially for new devs or drive-by contributions, is stating clearly in the wiki page: "use clang-format, it should get you at least half way there, but you still should/must also override it to match the style of surrounding code, as much as possible, in the file(s) you're editing, that's kinder to reviewers". The problem is that we have a pre-commit (I believe) git-hook, which checks the formatting and nags if it does not match to what we have in the _clang-format file. This basically forces the new or drive-by contributors to submit the patch with an incorrect formatting, which then leads to a bunch of review comments about code-style. I think that it's better to give no hints, rather than misleading hints. [...] I think the best way to find out is indeed removing the file, then one of two things will happen: - we'll get less formatting issues in reviews (especially from new contributors) - or we'll still get formatting issues, just different ones than what clang-format currently does So 6-12 months, and we'll have a definite answer. :) Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 09:13, Paul Wicking wrote: On 12 Sep 2023, at 22:33, Ahmad Samir wrote: _clang-format isn't picked up by clang-format by default, you'd have to rename it to .clang-format. clang-format reads either of them [0]. It's unnecessary to rename the configuration file. [0] - https://clang.llvm.org/docs/ClangFormat.html#standalone-tool I didn't know that, thanks for the clarification (from other projects, it's always .clang-format, never prefixed with _). //! Paul Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 01:46, Marc Mutz via Development wrote: [I didn't get André's Email...] On 12.09.23 23:40, Ahmad Samir wrote: On 13/9/23 00:11, apoenitz wrote: On Tue, Sep 12, 2023 at 11:33:17PM +0300, Ahmad Samir wrote: A config file that is 80-90% correct is better than nothing. I disagree. The result of such a thing is that people submit patches matching the config 100%, deviating from the wanted style by 10-20%. Numbers are arbitrary here, but the effect is that in practice even long-term contributors start to submit "wrong" auto-formatted patches causing needless review roundtrips. The alternative is patches with arbitrary formatting; that's not better. Sorry, no. If you submit a patch, you should just use whatever style you find in the file. If there's a mix, use whatever is adjacent to where you're coding. It's that simple. That shouldn't be too much to ask, and I, for one, am fine going into the Gerrit editor and fixing things for the submitter if that's the only thing holding me back from a +2. It's when people insist on rewriting lines because that's how QtCreator or git-clang-format format it, that the discussions start. > And a clang-format file doesn't actually help here, because we have already introduced inconsistencies in qtbase and whatever we select in .clang-format will be wrong 50% of the time. Assuming, of course, that you can get it configured to be close enough to the prevailing style, which I have not seen proof of. If anyone thinks it's possible, there's a simple litmus test: apply your config to all of qt(base) and look at the diff: Is it just fixing some outliers, or is it rewriting the world? Without testing, I am sure it's the latter. :) On top of that repeatedly discussion are started about adjusting the style to the tool, because "the tool can't be adjusted". True, but style arguments arise on their own too, tool or no tool. It only arises because the tool cannot represent what we traditionally call the Qt style. If there are disagreements on what that means, it's easy to draw upon a majority vote of Qt 4 code to break the tie, disregarding clang-format-infected files. I should also point out that the discussions a few years ago were nitpicking about Qt coding style violations, and the expected response from the submitter was to fix them. These days, everything is called into question because clang-format does it differently, ie. wrongly. And I'm kinda getting tired commenting on all these clang-format idiosyncrasies. If the tool was truly configurable, e.g. with an example [...] (Are most of those idiosyncrasies about 'template <>' in qtbase reviews? if so, then that's because qtbase doesn't have its own .clang-format with that style, because that's actually something the tool can do). I _know_ there is no perfect solution, I've spent some time trying to tweak the clang-format config in Qt and other projects/repos, there is no way to get a dumb formatting tool to do exactly what you want in all cases, partly because it can't read minds, and partly because it can't know things like "breaking this line of code here is really stoopid". One way to address these problems, especially for new devs or drive-by contributions, is stating clearly in the wiki page: "use clang-format, it should get you at least half way there, but you still should/must also override it to match the style of surrounding code, as much as possible, in the file(s) you're editing, that's kinder to reviewers". Technically, that's what I personally do, it's the same as having bash scripts, even if I can get it to do 50% of what I want, just not having to repeat myself to run some chain of commands 10 times a day is good enough. file from which it would pick formatting, we wouldn't have this discussion, either. But what I read between the lines is that Google is happy that it can reproduce their style, and contributions to extend it are not welcome. One way to stop the recurring discussions would be to reach a majority consensus about a clang-format config file, format the whole code base of each module in one go, then apply the formatting for each new commit, less discussions. Is that ideal? no, because reaching a consensus about coding style is not easy. There _is_ consensus. It's in the wiki. And in older modules not infected by the _clang-format file. Discussions arise because of .clang-format, not despite it. Afaict, there never was a discussion about how faithful the _clang-format represents the Qt style before it was added. If there was _any_ attempt at the above-mentioned litmus test, the template<> issue and others would have been detected immediately. I could format it manually, probably two steps, or let the tool do it That assumes the tool can be configured to reproduce the style. Until proven, you have to do the work 50% of the time, anyway. Tool won't help. It can/is configured to reprodu
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 00:11, apoenitz wrote:
On Tue, Sep 12, 2023 at 11:33:17PM +0300, Ahmad Samir wrote:
A config file that is 80-90% correct is better than nothing.
I disagree.
The result of such a thing is that people submit patches matching the config
100%, deviating from the wanted style by 10-20%. Numbers are arbitrary
here, but the effect is that in practice even long-term contributors start
to submit "wrong" auto-formatted patches causing needless review roundtrips.
The alternative is patches with arbitrary formatting; that's not better.
On top of that repeatedly discussion are started about adjusting the style to
the tool, because "the tool can't be adjusted".
True, but style arguments arise on their own too, tool or no tool.
One way to stop the recurring discussions would be to reach a majority consensus
about a clang-format config file, format the whole code base of each module in one
go, then apply the formatting for each new commit, less discussions. Is that
ideal? no, because reaching a consensus about coding style is not easy.
For example I have copied that file to qtbase/.clang-format and changed that
`template <>` part, it's still useful for me to have the file there as I
could select some text and format only that part in e.g. KDE's Kate. I can
override the changes to conform to qtbase's coding style, but I don't have to
do it all manually.
It's not /that/ hard to follow the /one/ code style that's uses in one's main
project. I have some sympathy for cases where people submit occasional patches
in a side project with some odd style rules, but for the day-time project
typing code in its preferred style should become second nature - independent
of any possible quirks and oddities there.
Examples:
- typos (no space):
if (foo && bar){
//
}
- lengthy lines of code:
static QMetaObject::Connection connect(const QObject *sender,
PointerToMemberFunction signal, const QObject *receiver, PointerToMemberFunction
method, Qt::ConnectionType type = Qt::AutoConnection);
I could format it manually, probably two steps, or let the tool do it
- debating about where to break the line:
bool inSenderThread = currentThreadId ==
QObjectPrivate::get(sender)->threadData.loadRelaxed()->threadId.loadRelaxed();
after the assign =, or after == or ...etc; or just let a tool do it, I can
disagree and override it if it looks too bad.
Andre'
D
PS:
Drive-by suggestion: each module should also have a .git-blame-ignore-revs
file (name should be unified in all Qt repos), to put commit hashes that
git-blame should ignore. (See 'git blame --ignore-revs-file').
Why?
Useful when using git-blame, e.g.:
- the commit that moved inline keyword to fix MinGW warnings in qstring.h, seeing
any line from that commit in git blame isn't useful/informative
- Formatting a repo with clang-format, that commit isn't useful in git blame
context
Regards,
Ahmad Samir
OpenPGP_signature
Description: OpenPGP digital signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 12/9/23 20:29, Marc Mutz via Development wrote: Hi, TL;DR: - remove _clang-format in qt5.git - add it instead to submodules which conform to it The clang-format philosophy is that you pick a config and stick to it. If your personal preferences are different, you use a different configuration locally and re-format on check-in and check-out. This means that the source code in the VCS must always conform to the clang-format configuration in effect in that branch. It also means that when and if you make changes to the clang-format configuration, you need to re-run the tool over the whole code base and apply the changed configuration, otherwise the clang-format workflow doesn't work (produces unrelated white-space changes). We have for quite some time had a _clang-format config file in qt5.git. After many attempts by many people, it has become clear that a) it has completely wrong settings (e.g. template<> vs. template <>), This particular issue with template<> has been "fixed" recently thanks to Mårten https://codereview.qt-project.org/c/qt/qt5/+/433720. leading to a complete formatting mess in modules that predate the addition of the file and more discussions around formatting than before, because there appear to be two true styles, and b) we can't seem to hammer clang-format into reproducing what we traditionally understand as the Qt style. In addition, the position in qt5.git means that if you edit files in submodules of qt5.git, the config is in effect, if you just checkout qtbase, it is not. _clang-format isn't picked up by clang-format by default, you'd have to rename it to .clang-format. I would therefore propose to remove the file from qt5.git: https://codereview.qt-project.org/c/qt/qt5/+/503430 I propose leaving that _clang-format file as the default clang-format config file, but each repo should have a .clang-format committed in git where the module maintainers/powers-to-be can put the code style that they want in their module. Some repos in Qt already do that. One of them has the max line length set to way more than 100, with a comment (paraphrased): "most lines in this repo are long, we have to live with with, move on" which is perfectly fine, the tool will pick up the config file and act accordingly. You can even have a .clang-format per dir in each module. So, remove it if you want, but a precursor to that is copying it to each Qt module, new _and_ old. It's OK for each module to change its own copy to fit its own style, but there should be a .clang-format, because it's much easier to let it format a diff, e.g. `git clang-format`, and override the few places that the tool got "wrong". This is more important for new devs who aren't familiar with the current coding style (yes, there is a good wiki page about the Qt coding style, but no it's not enough, there so much code and too many quirks to cover in one wiki page). Modules that don't have a .clang-format in git are implying "use the default config file". With a .clang-format committed to git, you get it any which way you checkout a Qt repo, `init-reporistory` or `git clone`. A config file that is 80-90% correct is better than nothing. For example I have copied that file to qtbase/.clang-format and changed that `template <>` part, it's still useful for me to have the file there as I could select some text and format only that part in e.g. KDE's Kate. I can override the changes to conform to qtbase's coding style, but I don't have to do it all manually. Drive-by suggestion: each module should also have a .git-blame-ignore-revs file (name should be unified in all Qt repos), to put commit hashes that git-blame should ignore. (See 'git blame --ignore-revs-file'). Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CI failing due to ASan tst_selftest
On 27/8/23 05:36, Thiago Macieira wrote: See https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1698516419 [...] Looking at this log: ==19313==ERROR: LeakSanitizer: detected memory leaks agent:2023/08/26 21:36:18 build.go:405: 3: agent:2023/08/26 21:36:18 build.go:405: 3: Direct leak of 258 byte(s) in 1 object(s) allocated from: agent:2023/08/26 21:36:18 build.go:405: 3: #0 0x7ffa505c8e48 in __interceptor_malloc (/usr/lib64/libasan.so.5+0x109e48) agent:2023/08/26 21:36:18 build.go:405: 3: #1 0x7ffa4f2d7ff9 (/home/qt/work/install/lib/libQt6Core.so.6+0x896ff9) agent:2023/08/26 21:36:18 build.go:405: 3: #2 0x7ffa4f2d834d in QArrayData::allocate(QArrayData**, long long, long long, long long, QArrayData::AllocationOption) (/home/qt/work/install/lib/libQt6Core.so.6+0x89734d) agent:2023/08/26 21:36:18 build.go:405: 3: #3 0x7ffa4f23b700 (/home/qt/work/install/lib/libQt6Core.so.6+0x7fa700) agent:2023/08/26 21:36:18 build.go:405: 3: #4 0x7ffa4f1f6cc8 in QString::reallocData(long long, QArrayData::AllocationOption) (/home/qt/work/install/lib/libQt6Core.so.6+0x7b5cc8) agent:2023/08/26 21:36:18 build.go:405: 3: #5 0x7ffa4f1f68a7 in QString::resize(long long) (/home/qt/work/install/lib/libQt6Core.so.6+0x7b58a7) agent:2023/08/26 21:36:18 build.go:405: 3: #6 0x7ffa4f2092ff (/home/qt/work/install/lib/libQt6Core.so.6+0x7c82ff) agent:2023/08/26 21:36:18 build.go:405: 3: #7 0x7ffa4f209e09 in QString::vasprintf(char const*, __va_list_tag*) (/home/qt/work/install/lib/libQt6Core.so.6+0x7c8e09) agent:2023/08/26 21:36:18 build.go:405: 3: #8 0x7ffa4ed0d83d (/home/qt/work/install/lib/libQt6Core.so.6+0x2cc83d) agent:2023/08/26 21:36:18 build.go:405: 3: #9 0x7ffa4ed114a9 in QMessageLogger::fatal(char const*, ...) const (/home/qt/work/install/lib/libQt6Core.so.6+0x2d04a9) agent:2023/08/26 21:36:18 build.go:405: 3: #10 0x5641d2604c40 in tst_Silent::messages() /home/qt/work/qt/qtbase/tests/auto/testlib/selftests/silent/tst_silent.cpp:77 I see the same issue locally, so I used `git bisect`, which showed it's because in `checkErrorOutput(const QString , const QByteArray )` in tst_selftests.cpp, the code should return early for "silent" test, because the latter calls qFatal, that doesn't seem to happen on Linux any more. Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] On the use of the inline keyword
On 26/8/23 11:51, Volker Hilsheimer wrote:
On 25 Aug 2023, at 14:20, Ahmad Samir wrote:
On 25/8/23 14:11, Cristian Adam via Development wrote:
The other way of fixing this is by using ... macros. The article at c++ - Importing
inline functions in MinGW - Stack
Overflow<https://stackoverflow.com/questions/11546403/importing-inline-functions-in-mingw>
mentions using inline in the class declaration.
Their example works fine with both GCC MinGW and Clang MinGW. Visual C++ is
also fine:
#ifdef _WIN32
#define Q_EXPORT_INLINE inline
#else
#define Q_EXPORT_INLINE
#endif
class __declspec(dllimport) MyClass {
public:
Q_EXPORT_INLINE int myFunc2();
Q_EXPORT_INLINE int myFunc1();
};
inline int MyClass::myFunc2(void) {
return myFunc1();
}
inline int MyClass::myFunc1(void) {
return 0;
}
[...]
The main deterrent to not fix it like the qstring.h patch[1] is the churn
caused by changing many lines, in many files, right?
But if affected code is going to be changed anyway to fix it with macros, it
makes more sense to fix it like [1]; if you're changing those lines, may as
well adhere to more standard guidelines: inline keyword is only used on
function declaration and _not_ the definition.
My 2p's.
[1] https://codereview.qt-project.org/c/qt/qtbase/+/498739
Yes, if we have to change the code to fix the warnings, then the way Marc
proposes, and how it has now been done for qstring.h, seems to be the way to go.
But yes, my concern is the work (I expect this can be easily automated with
clazy, but still need to be reviewed), and the code churn that goes with it
(the impact on `git blame`, and the inevitable conflicts when cherry-picking).
Tentative clazy check: https://invent.kde.org/sdk/clazy/-/merge_requests/84
IIUC, the `git blame` issue can be mitigated by adding those commits to e.g. a
.git-blame-ignore-revs file in each repo, see `git blame --ignore-revs-file` [1].
I saw something like that in one of Qt's repos, but can't remember which one...
it's also used in almost all KDE's Frameworks repos.
Conflicts when cherry-picking could be a problem. But the changes can be limited
to the bare minimum, i.e. only add inline keyword to declaration of affected
methods (ignoring constexpr and function templates, both are implicitly inline IIUC).
(I'd rather the whole thing is done like qstring.h).
It seems to be a rare issue, triggered by specific circumstances. With the
knowledge that we have now, we can fix issues when they arise, and don’t have
to change all the problematic use right now.
That’s my understanding at least; I might be wrong, but we have been building
Qt for a few decades on MinGW without this constantly blocking us.
FWIW, that's my understanding too.
I've used that clazy check linked above (via clazy-standalone) on qtbase, it
doesn't look too bad... if you ignore src/opengl, that dir alone:
$ git show --stat
26 files changed, 14857 insertions(+), 14857 deletions(-)
I've no idea about OpenGL, but it looks like that is generated code, so maybe `git
blame` doesn't matter there that much.
[1] https://git-scm.com/docs/git-blame
Regards,
Ahmad Samir
OpenPGP_signature
Description: OpenPGP digital signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] On the use of the inline keyword
On 25/8/23 14:11, Cristian Adam via Development wrote:
The other way of fixing this is by using ... macros. The article at c++ - Importing
inline functions in MinGW - Stack
Overflow<https://stackoverflow.com/questions/11546403/importing-inline-functions-in-mingw>
mentions using inline in the class declaration.
Their example works fine with both GCC MinGW and Clang MinGW. Visual C++ is
also fine:
#ifdef _WIN32
#define Q_EXPORT_INLINE inline
#else
#define Q_EXPORT_INLINE
#endif
class __declspec(dllimport) MyClass {
public:
Q_EXPORT_INLINE int myFunc2();
Q_EXPORT_INLINE int myFunc1();
};
inline int MyClass::myFunc2(void) {
return myFunc1();
}
inline int MyClass::myFunc1(void) {
return 0;
}
[...]
The main deterrent to not fix it like the qstring.h patch[1] is the churn caused
by changing many lines, in many files, right?
But if affected code is going to be changed anyway to fix it with macros, it makes
more sense to fix it like [1]; if you're changing those lines, may as well adhere
to more standard guidelines: inline keyword is only used on function declaration
and _not_ the definition.
My 2p's.
[1] https://codereview.qt-project.org/c/qt/qtbase/+/498739
Regards,
Ahmad Samir
OpenPGP_signature
Description: OpenPGP digital signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[kate] [Bug 473425] LSP doesn't detect methods used in SIGNAL()/SLOT() macros when searching for references
https://bugs.kde.org/show_bug.cgi?id=473425
--- Comment #4 from Ahmad Samir ---
(In reply to Waqar Ahmed from comment #3)
> clangd provides AST in an xml like format which you can use to get more info
> about the current file and maybe do some extra operations on it. Maybe
> that's how qtcreator is able to achieve this. But afair, qtcreator has a
> third cplusplus backend based on a small c++ parser so maybe it's using that.
>
> For the issue itself, I generally use search plugin and it works nicely for
> finding refs even in SIGNAL()/SLOT() macros or
> QMetaObject::invokeMethod("stringMethod") stuff.
Yeah, same here I use the search plugin; but sometimes while refactoring code I
might forget, or the code supports multiple platforms with the help of #ifdefS,
so I want to only see the parts relevant to Linux ...etc.
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 473425] LSP doesn't detect methods used in SIGNAL()/SLOT() macros when searching for references
https://bugs.kde.org/show_bug.cgi?id=473425 --- Comment #2 from Ahmad Samir --- I see; I thought since Qt Creator has switched to clangd (instead of libclang backend) that this works with clangd too; perhaps they have another way of listing references to methods wrapped in SIGNAL/SLOT. Sorry for the noise. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 473425] New: LSP doesn't detect methods used in SIGNAL()/SLOT() macros when searching for references
https://bugs.kde.org/show_bug.cgi?id=473425 Bug ID: 473425 Summary: LSP doesn't detect methods used in SIGNAL()/SLOT() macros when searching for references Classification: Applications Product: kate Version: Git Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: a.samir...@gmail.com Target Milestone: --- When using "find references" with a method marked as a Qt signal, instances that are wrapped in the SIGNAL() macro in a QObject::connect() call aren't detected. It looks like Qt Creator special-cases SIGNAL/SLOT macros to find those references, see: https://codereview.qt-project.org/c/qt-creator/qt-creator/+/227189 (I am not familiar enough with the LSP plugin code in Kate, otherwise I would have tried to create a patch). -- You are receiving this mail because: You are watching all bug changes.
Re: [Development] Q_FOREACH, again
On 14/8/23 21:46, Thiago Macieira wrote: On Monday, 14 August 2023 10:32:36 PDT Marc Mutz via Development wrote: It does _not_ have any influence on user code. Except where accidentally the QT_NO_FOREACH gets copied to the library's CMake INTERFACE. Then it does. This happened for QT_NO_CONTEXTLESS_CONNECT when it was applied to Qt6UiPlugin. We don't understand why it happened there (didn't bother to investigate), so be aware that your claim may be incorrect and that user code may be affected regardless of your intention. See 93de403391b59acf90fbe7319a059382dfe458a6 in the qt-creator repository. Thanks to Giuseppe for poking the issue, Alexandru figured it out a while ago: https://codereview.qt-project.org/c/qt/qttools/+/491477/2/src/uiplugin/CMakeLists.txt#16 The issue seen in Qt Creator 93de403391b59acf90fbe7319a059382dfe458a6 (the QT_NO_CONTEXTLESS_CONNECT leaking to user code) was "fixed" by https://codereview.qt-project.org/c/qt/qttools/+/492556 The "gist" of it is, don't use qt_internal_add_module + HEADER_MODULE + DEFINES, because those DEFINES could be leaked into user code that links to the plugin in question. HEADER_MODULE isn't used that many times in Qt code, and typically where it's used there is no SOURCES arg passed to qt_internal_add_module, however it's a corner case to look out for when adding DEFINES to qt_internal_add_module. Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Failed to build Qt6 Documentation from qt/qtbase sources?
On 1/8/23 15:22, Haowei Hsu wrote:
Hello, Qt Development Team.
Recently, I tried to build the Qt6 Documentation from qt/qtbase
<https://github.com/qt/qtbase> sources. In order to
build Qt6 Documentation more conveniently, I prepared a
*CMakeUserPresets.json*
in the root directory with some required configurations introduced in:
- Building Qt Documentation - Qt Wiki
<https://wiki.qt.io/Building_Qt_Documentation#Building_Qt_6_Documentation>
- Qt Build System Glossary - Qt Wiki
<https://wiki.qt.io/Qt_Build_System_Glossary#Documentation-only_Build>
The following is the content of my *CMakeUserPresets.json*:
{
"version": 4,
"cmakeMinimumRequired": {
"major": 3,
"minor": 23,
"patch": 0
},
"configurePresets": [
{
"name": "win32",
"description": "Windows",
"binaryDir": "${sourceDir}/build/${presetName}",
"generator": "Ninja",
"toolset": {
"value": "v142,host=x64",
"strategy": "external"
},
"architecture": {
"value": "x64",
"strategy": "external"
},
"cacheVariables": {
"CMAKE_C_COMPILER": "cl.exe",
"CMAKE_CXX_COMPILER": "cl.exe",
"QT_HOST_PATH": "C:/Qt/6.3.2/msvc2019_64",
"QT_NO_PACKAGE_VERSION_CHECK": true
},
"environment": {
"LLVM_INSTALL_DIR": "C:\\Program Files\\LLVM"
}
}
]
}
The followings are the steps I used to build *docs_Core* target
1. Run: *git clone https://github.com/qt/qtbase.git
<https://github.com/qt/qtbase.git>*
2. Run: *cd qtbase*
3. Run: *git checkout 6.5*
4. Add the above custom *CMakeUserPresets.json*
5. Run: *vcvarsall.bat x64*
6. Run: *cmake --preset win32*
7. Run: *cmake --build build/win32 --target docs_Core*
However, it turns out that there is an error in the Step 7:
[image: image.png]
What happened? What did I miss? Can you help me to figure out this problem?
You can see the attachment with the full log: *log-build-qt6-docs.txt*
---
Haowei Hsu
From the build log:
D:/Repo/GitHub/testing/qtbase/src/corelib/doc/qtcore.qdocconf:1: (qdoc) error:
Cannot open file 'C:/Qt/Qt-6.5.3/./doc/global/qt-module-defaults.qdocconf':
???
Cannot open file 'C:/Qt/Qt-6.5.3/./doc/global/qt-module-defaults.qdocconf':
???
I don't use Windows so I am not sure how this can be fixed; it's looking for the
.qdocconf file in the installation path rather than the source dir (in the git
checkout).
Regards
Ahmad Samir
OpenPGP_signature
Description: OpenPGP digital signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype
On 9/3/23 10:14, Marc Mutz via Development wrote: On 08.03.23 15:30, Ahmad Samir wrote: So, named casts (static_cast) are better in such cases, as searching for them in source code is much easier than searching for: - int(foo) - (int)foo - (int)(foo) In which situation would you want to search for all casts in a piece of source code? Without the use of a semantic grep tool? The tool (in this case compiling with -Wshorten-64-to-32, then checking with clangd or the build log ...etc) would warn about implicit casts, but not explicit ones? now if there is a named cast, then I can search for that much easier than I would for the C-style cast (int)foo, or int(foo). (I haven't checked clang-tidy, but I am guessing it won't be that much different than clangd). I wouldn't like the extra noise of a static_cast when a constructor call would suffice. Obviously, C-style casts should be avoided (in headers, IIRC, they're caught by headerscheck). Good luck with avoiding C-style casts in a huge codebase, e.g. qtbase, there is code that's been there since the 90's, and any attempt to "fix" C-style casts in the whole codebase would be seen as "churn". Thanks, Marc Thanks, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype
On 1/9/22 12:15, Marc Mutz wrote: This should be non-issue for function parameters, because widening isn't an error. The value is less pronounced for return values, because widening those may cause narrowing in user code, but the hope is that once we've progressed somewhat, we can enlist compiler support by globally enabling warnings such as -Wshorten-64-to-32, even though, as the porting guide included in the https://bugreports.qt.io/browse/QTBUG-102461 epic describes, this will not catch manual casts, which is why, sadly, one needs to look at every int/uint manually. Sorry for bringing this thread back up from the archives. So, named casts (static_cast) are better in such cases, as searching for them in source code is much easier than searching for: - int(foo) - (int)foo - (int)(foo) multiplied by the number of other integral types in Qt (qint32, qint64, uint, qlonglong, qulonglong... etc). Thanks, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[kwin] [Bug 453197] When window maximized vertically it vertical size becomes not maximized after maximize and unmaximize
https://bugs.kde.org/show_bug.cgi?id=453197 --- Comment #8 from Ahmad Samir --- So, can KWin, instead of setting the maximize-vertically property (or whatever it's called in XCB/X11 land) on the window, calculate that height and "resize" the window instead? (I am not talking about the app-started-maximized-vertically use-case, rather the one in my previous comment). Of course, it could well be that would cause other issues, e.g. moving the window from one screen to another with a different size, if the maximized-vertically property isn't set, it's going go keep the height... window management is tough. :) -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 437692] Dolpin Version > 20.12.3 does not start in Firefox/Opera by clicking "open containing Folder"
https://bugs.kde.org/show_bug.cgi?id=437692 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com, ||k...@davidedmundson.co.uk --- Comment #2 from Ahmad Samir --- It could be systemd-related; could you please test this: mkdir -p ~/.local/share/dbus-1/services/ cp -v /usr/share/dbus-1/services/org.kde.dolphin.FileManager1.service ~/.local/share/dbus-1/services/ then edit ~/.local/share/dbus-1/services/org.kde.dolphin.FileManager1.service to be like this: [D-BUS Service] Name=org.freedesktop.FileManager1 Exec=/usr/bin/dolphin --daemon --select then try again. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 461520] Add a way to temporarily stop LSP server
https://bugs.kde.org/show_bug.cgi?id=461520 --- Comment #1 from Ahmad Samir --- Another data point, QtCreator has two config options: - "Files to keep open": "Minimum number of open documents that should be kept in memory. Increasing this number will lead to greater resource usage when not manually closing documents." - "Auto-suspend unmodified files": "Automatically free resources of old documents that are not visible and not modified. They stay visible in the list of open documents." -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 461520] New: Add a way to temporarily stop LSP server
https://bugs.kde.org/show_bug.cgi?id=461520 Bug ID: 461520 Summary: Add a way to temporarily stop LSP server Classification: Applications Product: kate Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: a.samir...@gmail.com Target Milestone: --- This is useful if you have multiple instances of Kate open, each on a different project; clangd takes 10% of my 16GiB of RAM per project (depending on project's codebase size). It would be nice if there is a way to "suspend" the LSP server, i.e. terminate it to free the memory, the one can resume/start it again when one wants to work on the project in that Kate instance. Closing the Kate instance is an option, yes, but quite annoying, you have documents open, edits in the undo stack ...etc. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461337] Right-click menu only appears after moving mouse pointer
https://bugs.kde.org/show_bug.cgi?id=461337 --- Comment #2 from Ahmad Samir --- X11, OpenSuse TumbleWeed. Right clicking anywhere, Kate, Dolphin, Konsole. It also seems to affect the menus in the menu bar. Setting the animation speed in the general behaviour KCM to a very low value seems to "fix it". -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461337] New: Right-click menu only appears after moving mouse pointer
https://bugs.kde.org/show_bug.cgi?id=461337 Bug ID: 461337 Summary: Right-click menu only appears after moving mouse pointer Classification: Plasma Product: kwin Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: a.samir...@gmail.com Target Milestone: --- Clicking the right mouse button, the context menu only appears after moving the mouse pointer; this seems to be an issue when the "fading popups" effect is disabled. -- You are receiving this mail because: You are watching all bug changes.
Re: Gitlab update, 2FA now mandatory
On 25/10/22 15:06, Christoph Cullmann (cullmann.io) wrote: On 2022-10-25 14:55, Ahmad Samir wrote: On 25/10/22 14:31, Christoph Cullmann (cullmann.io) wrote: On 2022-10-25 13:52, Ahmad Samir wrote: On 25/10/22 13:29, Harald Sitter wrote: On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir wrote: Can a first time contributor create a fork, create multiple/100 MR's and spin up CI jobs? if yes, then, first time contributors can disrupt the system. Weren't there some suspicious accounts that were using our gitlab instance for bitcoin mining (I could be wrong, I vaguely remember someone from Sysadmin team talking about something like that)? were these first time contributors or ones with developer accounts? I'm sure 2fa doesn't help with that (: I am not a cyber security expert, but isn't 2FA comparable to captcha stuff? it's not hard, but it takes some extra time. Which forum would a spammer target? the one with the "create account and login immediately" or the one with "create account, verify captcha hell, verify email address"? That is true, but did we have concrete issues with spam accounts? And if yes, a one time captcha solving is a lot lower barrier the to need to do 2fa auth for a trivial issue Comment or merge request. At least for any part I work on in KDE the issue is manpower. Any step to make it more easier to help is good. Any step to make it harder is bad. I see the point why we not work on GitHub, I don't like to be dependent on some random company that in worst case can randomly pull the plug. But I somehow don't understand why we need to enforce this now even for new accounts without rights. I must confess I would like it even more if 2fa would only be required on doing some action that Is problematic and not just on any issue or merge request comment. But I assume that is not feasible. Greetings Christoph FWIW, when I log in to GitHub, they email me a pin number that I have to put in the web page, for me it's exactly the same level of inconvenience: - "check email, find pin, copy, paste" - "check app on phone, type pin" A mail is a lot easier on many devices, at least for me. My Kindle Fire can read my mails, but per default has zero otp stuff I could use. Same for my different work computers. All can get mail, none had before any such application. Therefore, yes, GitHub or the Steam Store work for me Without any extra setup effort. A mail address was Required anyways. And no, not even per default KDE Plasma ships with any obviously well integrated otp client. In this thread Ivan said Plasma Pass has OTP support: https://mail.kde.org/pipermail/kde-community/2022q4/007309.html (I haven't tried it myself). Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
Re: Gitlab update, 2FA now mandatory
On 25/10/22 14:31, Christoph Cullmann (cullmann.io) wrote: On 2022-10-25 13:52, Ahmad Samir wrote: On 25/10/22 13:29, Harald Sitter wrote: On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir wrote: Can a first time contributor create a fork, create multiple/100 MR's and spin up CI jobs? if yes, then, first time contributors can disrupt the system. Weren't there some suspicious accounts that were using our gitlab instance for bitcoin mining (I could be wrong, I vaguely remember someone from Sysadmin team talking about something like that)? were these first time contributors or ones with developer accounts? I'm sure 2fa doesn't help with that (: I am not a cyber security expert, but isn't 2FA comparable to captcha stuff? it's not hard, but it takes some extra time. Which forum would a spammer target? the one with the "create account and login immediately" or the one with "create account, verify captcha hell, verify email address"? That is true, but did we have concrete issues with spam accounts? And if yes, a one time captcha solving is a lot lower barrier the to need to do 2fa auth for a trivial issue Comment or merge request. At least for any part I work on in KDE the issue is manpower. Any step to make it more easier to help is good. Any step to make it harder is bad. I see the point why we not work on GitHub, I don't like to be dependent on some random company that in worst case can randomly pull the plug. But I somehow don't understand why we need to enforce this now even for new accounts without rights. I must confess I would like it even more if 2fa would only be required on doing some action that Is problematic and not just on any issue or merge request comment. But I assume that is not feasible. Greetings Christoph FWIW, when I log in to GitHub, they email me a pin number that I have to put in the web page, for me it's exactly the same level of inconvenience: - "check email, find pin, copy, paste" - "check app on phone, type pin" Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
Re: Gitlab update, 2FA now mandatory
On 25/10/22 13:29, Harald Sitter wrote: On Tue, Oct 25, 2022 at 1:22 PM Ahmad Samir wrote: Can a first time contributor create a fork, create multiple/100 MR's and spin up CI jobs? if yes, then, first time contributors can disrupt the system. Weren't there some suspicious accounts that were using our gitlab instance for bitcoin mining (I could be wrong, I vaguely remember someone from Sysadmin team talking about something like that)? were these first time contributors or ones with developer accounts? I'm sure 2fa doesn't help with that (: I am not a cyber security expert, but isn't 2FA comparable to captcha stuff? it's not hard, but it takes some extra time. Which forum would a spammer target? the one with the "create account and login immediately" or the one with "create account, verify captcha hell, verify email address"? -- Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
Re: Gitlab update, 2FA now mandatory
On 25/10/22 12:11, Carl Schwan wrote: Le dimanche 23 octobre 2022 à 5:55 PM, Christoph Cullmann (cullmann.io) a écrit : On 2022-10-23 08:32, Ben Cooksley wrote: Hi all, This afternoon I updated invent.kde.org [1] to the latest version of Gitlab, 15.5. Release notes for this can be found at https://about.gitlab.com/releases/2022/10/22/gitlab-15-5-released/ There isn't much notable feature wise in this release, however there have been some bug fixes surrounding the "Rebase without Pipeline" functionality that was introduced in an earlier update. As part of securing Invent against recently detected suspicious activity I have also enabled Mandatory 2FA, which Gitlab will ask you to configure next time you access it. This can be done using either a Webauthn token (such as a Yubikey) or TOTP (using the app of choice on your phone) Should you lose access to your 2FA device you can obtain a recovery token to log back in via SSH, see https://docs.gitlab.com/ee/user/profile/account/two_factor_authentication.html#generate-new-recovery-codes-using-ssh for more details on this. Please let us know if there are any queries on the above. Hi, whereas I can see the security benefit, this raises the hurdle for one time contributors again a lot. Before you already had to register to get your merge request, now you need to setup this too (or at least soon it is mandatory). I am not sure this is such a good thing. I see a point that one wants to avoid that e.g. somebody steals my account that has enough rights to delete all branches in the Kate repository via the web frontend. Could the 2FA stuff perhaps be limited to people with developer role or such? Yes this would be ideal. We don't need to require 2fa for people who just started contributing or want to give some feedback on a MR/ticket. This should be possible with the following features: https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforce-2fa-for-all-users-in-a-group We can just require 2fa for developers because with great powers come great responsibilities. Cheers, Carl Can a first time contributor create a fork, create multiple/100 MR's and spin up CI jobs? if yes, then, first time contributors can disrupt the system. Weren't there some suspicious accounts that were using our gitlab instance for bitcoin mining (I could be wrong, I vaguely remember someone from Sysadmin team talking about something like that)? were these first time contributors or ones with developer accounts? -- Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
[frameworks-kio] [Bug 431351] For files that don't fit in the trash, the user isn't provided with the option to delete immediately
https://bugs.kde.org/show_bug.cgi?id=431351 Ahmad Samir changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version Fixed In||5.100 Latest Commit||https://invent.kde.org/fram ||eworks/kio/commit/3f922b72e ||5202b882c85a390926c905f8008 ||ca60 Resolution|--- |FIXED --- Comment #10 from Ahmad Samir --- Git commit 3f922b72e5202b882c85a390926c905f8008ca60 by Ahmad Samir. Committed on 19/10/2022 at 04:29. Pushed by ahmadsamir into branch 'master'. AskUserActionInterface: add DeleteInsteadOfTrash deletion type Typical use-case: - the user tries to Trash some file, which fails due to size constraints - we ask the user again about deleting the files instead of Trashing them FIXED-IN: 5.100 M +7-0src/core/askuseractioninterface.h M +8-1src/core/global.h M +3-0src/core/job_error.cpp M +2-2src/ioslaves/trash/trashimpl.cpp M +22 -2src/widgets/deleteortrashjob.cpp M +23 -1src/widgets/widgetsaskuseractionhandler.cpp https://invent.kde.org/frameworks/kio/commit/3f922b72e5202b882c85a390926c905f8008ca60 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 458525] Kate crash on save - every time
https://bugs.kde.org/show_bug.cgi?id=458525 Ahmad Samir changed: What|Removed |Added Status|REPORTED|NEEDSINFO CC||a.samir...@gmail.com Resolution|--- |WAITINGFORINFO --- Comment #7 from Ahmad Samir --- The backtrace isn't useful due to missing debug symbols; install the debug info packages from your distro and provide the backtrace again. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 458665] Kate crashes during the open file dialogue
https://bugs.kde.org/show_bug.cgi?id=458665 Ahmad Samir changed: What|Removed |Added Resolution|--- |WAITINGFORINFO CC||a.samir...@gmail.com Status|REPORTED|NEEDSINFO --- Comment #1 from Ahmad Samir --- The backtrace isn't complete, please install the debug symbols and post the backtrace again. -- You are receiving this mail because: You are watching all bug changes.
Re: Plasma-nm: passing on maintainership
On 4/10/22 14:06, Jan Grulich wrote: Hi, When I joined KDE as a developer, I started as a newbie working on NetworkManager and ModemManager integration and ended up writing one of the core Plasma components. Thanks to this I gained a lot of experience, attended a few Akademy conferences and met amazing people. I'm really grateful for the experience and I consider it as an important part of my life. Unfortunately, as life goes on and new projects appear, I found that I basically have zero time to dedicate to anything related to NetworkManager/ModemManager integration in KDE and all the bugs assigned to me for these components don't get enough attention from my side. For that reason I would like to ask to update bugzilla components for *kf5-networkmanager-qt*, *kf5-modemmanager-qt* and *plasma-nm* to have plasma-devel as default assignee and find someone who can be assigned by default to all code reviews to lead these projects. I will still happily help from time to time to explain some things around plasma-nm, but I will no longer be able to actively fix bugs and develop new features. I will still be around, mostly working on things around Flatpak, PipeWire, etc. Thank you. Best regards, Jan Grulich Thanks for all the work (features and bugs alike, as you know software is always a mixed bag :D), and yes, indeed a very core component of Plasma. As Jonathan said, don't be a stranger, KDE has very good memory :) Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
Re: libksane, KSaneCore and QT_NO_KEYWORDS
On 29/9/22 10:22, Tobias Leupold wrote: Hi all! I recently had to port Scandoc from libksane to KSaneCore, and now, I have questions ;-) Question 1: On Gentoo, we have libksane 22.04.3 (stable) and 22.08.1 (testing). On an Artix machine I run, there's only 22.08.1 (those guys are even more bleeding edge than Gentoo ...). I could not link against libksane 22.08.1 anymore there. I knew that there was effort going on to create a separate library only containing the SANE communication backend, without the QWidgets dependencies. This is of course a reasonable thing to do -- but if I get this correctly, libksane itself now depends on KSaneCore, and one can't link against it as before. So what's the rationale behind still releasing libksane, when it can't be used anymore, and one has to port one's code to KSaneCore anyway? Apart from that: The KSaneCore API docs say that one should use "target_link_libraries(yourapp KF5::SaneCore)" in CMakeLists.txt to link against it. That actually didn't work, I had to use "target_link_libraries(scandoc ... KSane::Core)" to make it work. Am I missing something, or should either the documentation be changed and/or the "KF5::SaneCore" target be added/defined? Question 2: KSaneCore depends on at least KF 5.90.0. After bumping this dependency in my CMakeLists.txt, I was deluged with compiler errors. It was a bit hard to figure out what was going on, but long story short, "-DQT_NO_KEYWORDS" is now set by default, which makes it necessary to use "Q_SIGNALS", "Q_SLOTS" and "Q_EMIT" instead of "signals", "slots" and "emit". I know that defining these keywords is argued about, as it "pollutes" the global namespace. But afaik, the only scenario where one has to define "- DQT_NO_KEYWORDS" is when a third-party signal/slot mechanism is used. Doing so seems to be reasonable when coding the frameworks (as Qt add-ons) to leave this up to the user. But what's the rationale or benefit of doing so by default for applications? Switching to Q_EMIT was done in KF because "emit" is going to be used by the STL in C++20 and later: https://lists.qt-project.org/pipermail/development/2020-February/038812.html https://en.cppreference.com/w/cpp/io/basic_osyncstream/emit Thanks for all clarification and/or explanation! Cheers, Tobias Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
[dolphin] [Bug 458709] [bug]: the closed file manager window crashes when copying
https://bugs.kde.org/show_bug.cgi?id=458709 --- Comment #9 from Ahmad Samir --- The backtrace in comment#6 looks slightly different than the one from comment#0, could be two separate issues... the problem is the backtrace from comment#0 is not complete due to missing debug symbols. I tried reproducing this issue, and it happened 1-2 times, but I failed to make crash again. This *might* be related: https://invent.kde.org/frameworks/kio/-/merge_requests/977 (it makes sense to parent the widgets to the dialog, not to its parent anyway). The question is, why is this happening only now when this code has been around for ages? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 458709] [bug]: the closed file manager window crashes when copying
https://bugs.kde.org/show_bug.cgi?id=458709 Ahmad Samir changed: What|Removed |Added CC||beedellrokejulianlockhart@g ||mail.com --- Comment #8 from Ahmad Samir --- *** Bug 458570 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 458570] Crash when exiting dolphin.
https://bugs.kde.org/show_bug.cgi?id=458570 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #2 from Ahmad Samir --- *** This bug has been marked as a duplicate of bug 458709 *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 454133] Crash on Copy Local Files to SMB1 Share
https://bugs.kde.org/show_bug.cgi?id=454133 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #2 from Ahmad Samir --- *** This bug has been marked as a duplicate of bug 458709 *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 458709] [bug]: the closed file manager window crashes when copying
https://bugs.kde.org/show_bug.cgi?id=458709 Ahmad Samir changed: What|Removed |Added CC||myccl...@outlook.com --- Comment #7 from Ahmad Samir --- *** Bug 454133 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 458709] [bug]: the closed file manager window crashes when copying
https://bugs.kde.org/show_bug.cgi?id=458709 --- Comment #6 from Ahmad Samir --- postix posted a complete backtrace at https://bugs.kde.org/show_bug.cgi?id=364039#c84 Operating System: openSUSE Tumbleweed 20220525 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.2 Kernel Version: 5.17.9-1-default (64-bit) Graphics Platform: Wayland ``` #0 0x7f0f092846ac in __pthread_kill_implementation () from /lib64/libc.so.6 #1 0x7f0f092316f6 in raise () from /lib64/libc.so.6 #2 0x7f0f0b2b9d7e in KCrash::defaultCrashHandler (sig=11) at /usr/src/debug/kcrash-5.94.0-1.1.x86_64/src/kcrash.cpp:633 #3 #4 QScopedPointer >::operator-> (this=0x8) at ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h:116 #5 qGetPtrHelper > > (ptr=...) at ../../include/QtCore/../../src/corelib/global/qglobal.h:1143 #6 QWidget::d_func (this=0x0) at kernel/qwidget.h:132 #7 QWidgetPrivate::createWinId (this=) at kernel/qwidget.cpp:2371 #8 0x7f0f0a5bdf79 in QWidget::createWinId (this=) at kernel/qwidget.cpp:2442 #9 0x7f0f0a5bbbd0 in QWidget::create (this=0x564ddc1b3f00, window=, initializeWindow=, destroyOldWindow=) at kernel/qwidget.cpp:1149 #10 0x7f0f0a5c899a in QWidgetPrivate::setVisible (this=0x564ddc020db0, visible=) at kernel/qwidget.cpp:8063 #11 0x7f0f0a5c8d92 in QWidget::setVisible (this=this@entry=0x564ddc1b3f00, visible=visible@entry=true) at kernel/qwidget.cpp:8044 #12 0x7f0f0a78fb95 in QDialog::setVisible (this=0x564ddc1b3f00, visible=) at dialogs/qdialog.cpp:787 #13 0x7f0f0b335dda in KIO::CopyJobPrivate::slotResultErrorCopyingFiles (this=, job=0x564dda63dd60) at /usr/src/debug/kio-5.94.0-1.1.x86_64/src/core/copyjob.cpp:1769 #14 0x7f0f09949def in QtPrivate::QSlotObjectBase::call (a=0x7ffd4c6f7b20, r=0x564ddc0c4920, this=0x564dda659950) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #15 doActivate (sender=0x564dda63dd60, signal_index=6, argv=0x7ffd4c6f7b20) at kernel/qobject.cpp:3886 #16 0x7f0f099430cf in QMetaObject::activate (sender=sender@entry=0x564dda63dd60, m=, local_signal_index=local_signal_index@entry=3, argv=argv@entry=0x7ffd4c6f7b20) at kernel/qobject.cpp:3946 #17 0x7f0f0ab97785 in KJob::result (this=this@entry=0x564dda63dd60, _t1=, _t1@entry=0x564dda63dd60, _t2=...) at /usr/src/debug/kcoreaddons-5.94.0-1.1.x86_64/build/src/lib/KF5CoreAddons_autogen/include/moc_kjob.cpp:633 #18 0x7f0f0ab9b8eb in KJob::finishJob (this=0x564dda63dd60, emitResult=) at /usr/src/debug/kcoreaddons-5.94.0-1.1.x86_64/src/lib/jobs/kjob.cpp:98 #19 0x7f0f09949def in QtPrivate::QSlotObjectBase::call (a=0x7ffd4c6f7c40, r=0x564dda63dd60, this=0x564ddb3e85a0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #20 doActivate (sender=0x564ddb3bd9a0, signal_index=6, argv=0x7ffd4c6f7c40) at kernel/qobject.cpp:3886 #21 0x7f0f099430cf in QMetaObject::activate (sender=sender@entry=0x564ddb3bd9a0, m=, local_signal_index=local_signal_index@entry=3, argv=argv@entry=0x7ffd4c6f7c40) at kernel/qobject.cpp:3946 #22 0x7f0f0ab97785 in KJob::result (this=this@entry=0x564ddb3bd9a0, _t1=, _t1@entry=0x564ddb3bd9a0, _t2=...) at /usr/src/debug/kcoreaddons-5.94.0-1.1.x86_64/build/src/lib/KF5CoreAddons_autogen/include/moc_kjob.cpp:633 #23 0x7f0f0ab9b8eb in KJob::finishJob (this=0x564ddb3bd9a0, emitResult=) at /usr/src/debug/kcoreaddons-5.94.0-1.1.x86_64/src/lib/jobs/kjob.cpp:98 #24 0x7f0f09949def in QtPrivate::QSlotObjectBase::call (a=0x7ffd4c6f7d60, r=0x564ddb3bd9a0, this=0x564ddc0b7f80) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #25 doActivate (sender=0x564ddc06c610, signal_index=5, argv=0x7ffd4c6f7d60) at kernel/qobject.cpp:3886 #26 0x7f0f099430cf in QMetaObject::activate (sender=sender@entry=0x564ddc06c610, m=, local_signal_index=local_signal_index@entry=2, argv=argv@entry=0x7ffd4c6f7d60) at kernel/qobject.cpp:3946 #27 0x7f0f0b34f056 in KIO::SlaveInterface::error (this=this@entry=0x564ddc06c610, _t1=, _t2=...) at /usr/src/debug/kio-5.94.0-1.1.x86_64/build/src/core/KF5KIOCore_autogen/include/moc_slaveinterface.cpp:452 #28 0x7f0f0b355f88 in KIO::SlaveInterface::dispatch (this=0x564ddc06c610, _cmd=102, rawdata=...) at /usr/src/debug/kio-5.94.0-1.1.x86_64/src/core/slaveinterface.cpp:181 #29 0x7f0f0b34ef06 in KIO::SlaveInterface::dispatch (this=0x564ddc06c610) at /usr/src/debug/kio-5.94.0-1.1.x86_64/src/core/slaveinterface.cpp:78 #30 0x7f0f0b3528b9 in KIO::Slave::gotInput (this=0x564ddc06c610) at /usr/src/debug/kio-5.94.0-1.1.x86_64/src/core/slave.cpp:336 #31 0x7f0f09949def in QtPrivate::QSlotObjectBase::call (a=0x7ffd4c6f7f70, r=0x564ddc06c610, this=0x564ddc0c59f0) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398 #32 doActivate (sender=0x564ddc09ab80, signal_index=3, argv=0x7ffd4c6f7f70) at kernel/qobject.cpp:3886 #33 0x7f0f0993e660 in QObject::event (this=0x564ddc09ab80, e=0x564ddbe54a90) at kernel/qobject.
[dolphin] [Bug 458709] [bug]: the closed file manager window crashes when copying
https://bugs.kde.org/show_bug.cgi?id=458709 Ahmad Samir changed: What|Removed |Added CC||midkiffjack...@gmail.com --- Comment #5 from Ahmad Samir --- *** Bug 456223 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 456223] Dolphin closes when copying files to SMB1 Share
https://bugs.kde.org/show_bug.cgi?id=456223 --- Comment #9 from Ahmad Samir --- *** This bug has been marked as a duplicate of bug 458709 *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 458709] [bug]: the closed file manager window crashes when copying
https://bugs.kde.org/show_bug.cgi?id=458709 Ahmad Samir changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- CC||a.samir...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 458709] [bug]: the closed file manager window crashes when copying
https://bugs.kde.org/show_bug.cgi?id=458709 Ahmad Samir changed: What|Removed |Added CC||damian.hoes...@gmail.com --- Comment #4 from Ahmad Samir --- *** Bug 458111 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 458111] Dolphin crash during transaction overwriting existing files from internal Btrfs RAID6 to USB HDD
https://bugs.kde.org/show_bug.cgi?id=458111 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #3 from Ahmad Samir --- Bug 458709 has a slightly better backtrace. *** This bug has been marked as a duplicate of bug 458709 *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 364039] Dolphin crashed on file transfer in KIO::WidgetsAskUserActionHandler::askUserRename()
https://bugs.kde.org/show_bug.cgi?id=364039 --- Comment #94 from Ahmad Samir --- All these reports can't be duplicates of the original report from 5.26, since KIO::WidgetsAskUserActionHandler was introduced in 5.78. -- You are receiving this mail because: You are watching all bug changes.
Re: New releases for bugfixes
On 8/9/22 13:51, Nicolas Fella wrote: Hi, I don't think Nate or anyone wants to propose a strict policy that when X then Y has to happen. That's just not how we operate in KDE. I do think it is valuable though to discuss and create some guidelines/shared understanding/soft policy that maintainers can use as a reference when making decisions. That would match very well how decisions and policies are made in KDE. Cheers Nico As I said somewhere else in this thread, any fixes should be backported to the stable branch/tag in git (that is most likely the current work flow for the release teams). From the git-archive manual page: «git archive behaves differently when given a tree ID versus when given a commit ID or tag ID. In the first case the current time is used as the modification time of each file in the archive. In the latter case the commit time as recorded in the referenced commit object is used instead. Additionally the commit ID is stored in a global extended pax header if the tar format is used; it can be extracted using git get-tar-commit-id. In ZIP files it is stored as a file comment.» so: - backport fix to the stable branch - packagers can look at that branch to find what extra commits their downstream packages don't have yet Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
[frameworks-ki18n] [Bug 444614] Potential Buffer overflow inside ki18n KCatalog
https://bugs.kde.org/show_bug.cgi?id=444614 --- Comment #5 from Ahmad Samir --- Git commit 241e0cfa96b1491721f361f1713b3514c58bde56 by Ahmad Samir. Committed on 05/09/2022 at 17:12. Pushed by ahmadsamir into branch 'master'. KCatalog: make setting LANGUAGE env var more robust - Use std::snprintf, since its docs state the resulting string will be null-terminated; also check the return value from that call to print warnings - Bump the size of the allocated char array to 64 Add rudimentary unittest adapted from kcountrytest.cpp. M +7-3autotests/CMakeLists.txt A +50 -0autotests/kcatalogtest.cpp [License: LGPL(v2.0+)] M +17 -6src/i18n/kcatalog.cpp https://invent.kde.org/frameworks/ki18n/commit/241e0cfa96b1491721f361f1713b3514c58bde56 -- You are receiving this mail because: You are watching all bug changes.
Re: Welcome* Ingo!
On 6/9/22 00:11, Aleix Pol wrote: Hi everyone, Last year during Akademy, we discussed different positions under the umbrella of Make a Living in KDE. Today I'm reaching out to announce that Ingo Klöcker (CC) will be taking on the role of App Stores Support Engineer. Ingo will be working with the different teams in KDE towards our infrastructure getting prepared to have their software delivered to the platforms they are targetting. With this, we hope to improve the reach of our products to end users and hopefully enable them also to make a living with their KDE products. * I know he's been around for a while, but still, please welcome Ingo in this new role! Best, Aleix Pol, KDE e.V. President Congratulations, and may all the KDE app stores flourish with your help. Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
Re: Notice of impending change to Gitlab CI
On 4/9/22 10:42, Ben Cooksley wrote: Hi all, Currently our Gitlab CI jobs for Linux (SUSE) and Android (Ubuntu) run their respective jobs as root within the Docker containers that Gitlab spawns for them. This is a restriction that was previously required by the simultaneous use of these same images by Jenkins, which following the shutdown of build.kde.org this weekend is no longer a problem. I will look into making this adjustment to our CI image(s) in the coming week for Linux (SUSE). Once implemented, tests which made use of root privileges may begin to fail (and those that were incompatible with it will begin to pass). Android Qt 5 builds still share the image with the Binary Factory and therefore will have to continue to run as root at this time until we are able to discontinue the BInary Factory (or at least, Android's use of it). Thanks, Ben Good work! This is especially good news for KIO (and possibly other frameworks with unittests that make heavy use of I/O operations). Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
Re: Voting for the new KDE Goals has started
On 30/8/22 14:25, Adam Szopa wrote: Hello! I'm happy to announce, that the voting for the new KDE Goals has started. If you have a developer account, you should be getting your email soon. You'll be selecting between 6 proposals, listed here: https://phabricator.kde.org/project/view/322/ If you have a developer account but didn't get your email within a day OR you don't have a developer account but feel that you're a contributing member of the community, please contact me privately. The winning proposals will be announced during Akademy 2022. - Adam Hello. It seems some members are arranging the tasks in the Phabricator workboard. Please note that you are not supposed to change the order of the tasks in the Phabricator link above, instead to cast your vote arrange the goals, according to your preferences, in the "survey" (a link to the that survey was sent in an email to each member individually). Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
[kactivitymanagerd] [Bug 458356] Plasma 5.25.x not launching on FreeBSD
https://bugs.kde.org/show_bug.cgi?id=458356 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #3 from Ahmad Samir --- Does moving ~/.local/share/kactivitymanagerd (before starting plasmashell), make any difference? -- You are receiving this mail because: You are watching all bug changes.
Re: KickOff bug report page
On 28/8/22 08:35, Enrico Bella wrote: Hello, I would like to report a strange behavior of Kickoff, but I can't find "KickOff" in the product list on https://bugs.kde.org/ Is KickOff listed with another name? Where can I report this? Thanks, Enrico Most likely it's part of the "plasmashell" product in bugzilla. Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
Re: Incubating app (Git Klient)
On 22/8/22 18:10, samuel ammonius wrote: Sorry. I was just trying to help. What would the right action be? That would be following the steps at https://community.kde.org/Incubator (Which what Hamed Masafi appears to be doing, first step is posting to this ML). Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
[frameworks-kwidgetsaddons] [Bug 451834] Calling app crashes trying to show a message box with KMessageBox::createKMessageBox()
https://bugs.kde.org/show_bug.cgi?id=451834 Ahmad Samir changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Version Fixed In||5.97 Latest Commit||https://invent.kde.org/fram ||eworks/kio/commit/5f7fe0501 ||725564d4c8247f74731bcee52cd ||711d --- Comment #6 from Ahmad Samir --- Git commit 5f7fe0501725564d4c8247f74731bcee52cd711d by Ahmad Samir. Committed on 21/08/2022 at 11:59. Pushed by ahmadsamir into branch 'master'. Use AskUserActionInterface (async) in UserNotificationHandler This avoids using QDialog::exec(), which uses a nested eventloop, with all the problems that come from such usage. FIXED-IN: 5.97 M +31 -23 src/core/usernotificationhandler.cpp M +1-0src/core/usernotificationhandler_p.h https://invent.kde.org/frameworks/kio/commit/5f7fe0501725564d4c8247f74731bcee52cd711d -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 447238] In tabs bar the icon associated to home folder is the template one.
https://bugs.kde.org/show_bug.cgi?id=447238 Ahmad Samir changed: What|Removed |Added Latest Commit||https://invent.kde.org/fram ||eworks/kio/commit/30d22d282 ||b0a9b1de359353f064b033ba2d3 ||0887 Version Fixed In||5.98 Resolution|NOT A BUG |FIXED --- Comment #5 from Ahmad Samir --- Git commit 30d22d282b0a9b1de359353f064b033ba2d30887 by Ahmad Samir. Committed on 21/08/2022 at 11:57. Pushed by ahmadsamir into branch 'master'. Ensure iconForStandardPath() returns user-home for QStandardPaths::HomeLocation FIXED-IN: 5.98 M +41 -24 src/core/kioglobal_p.cpp https://invent.kde.org/frameworks/kio/commit/30d22d282b0a9b1de359353f064b033ba2d30887 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 353883] "Invalid Protocol" when entering relative paths
https://bugs.kde.org/show_bug.cgi?id=353883 Ahmad Samir changed: What|Removed |Added Status|CONFIRMED |RESOLVED Latest Commit||https://invent.kde.org/fram ||eworks/kio/commit/d2d81ca6e ||d0653823b77b2cab3c404dd71bf ||8fef Resolution|--- |FIXED Version Fixed In||5.98 --- Comment #3 from Ahmad Samir --- Git commit d2d81ca6ed0653823b77b2cab3c404dd71bf8fef by Ahmad Samir. Committed on 20/08/2022 at 13:19. Pushed by ahmadsamir into branch 'master'. KUrlNavigator: check if typed text matches a relative dir first Test plan: - Open e.g. Dolphin at ~/, in the url bar replace all the text with ".config", Enter - it displays an error "Invalid protocol" - Apply patch and try again, it should open ~/.config as expected FIXED-IN: 5.98 M +17 -5src/filewidgets/kurlnavigator.cpp https://invent.kde.org/frameworks/kio/commit/d2d81ca6ed0653823b77b2cab3c404dd71bf8fef -- You are receiving this mail because: You are watching all bug changes.
Re: [Development] [Announce] Security advisory: Freetype in Qt
On 27/7/22 19:15, Thiago Macieira wrote: On Wednesday, 27 July 2022 09:43:32 PDT Albert Astals Cid wrote: 5.15: https://download.qt.io/official_releases/qt/5.15/CVE-2022-27404-27405-2740 6 -qtbase-5.15.diff This patch doesn't seem to apply over the v5.15.5-lts-lgpl tag for me, can someone please double check in case I'm doing something wrong? Looks like Freetype in the current 5.15 branch does not match what's in the patch. $ git show origin/5.15:src/3rdparty/freetype/docs/CHANGES | head -2 CHANGES BETWEEN 2.10.0 and 2.10.1 $ curl -sL https://download.qt.io/official_releases/qt/5.15/ CVE-2022-27404-27405-27406-qtbase-5.15.diff | \ grep -A3 b/src/3rdparty/freetype/docs/CHANGES diff --git a/src/3rdparty/freetype/docs/CHANGES b/src/3rdparty/freetype/docs/ CHANGES index 3bd5291ae1..3ad7ec4333 100644 --- a/src/3rdparty/freetype/docs/CHANGES +++ b/src/3rdparty/freetype/docs/CHANGES @@ -1,4 +1,235 @@ -CHANGES BETWEEN 2.10.3 and 2.10.4 +CHANGES BETWEEN 2.12.0 and 2.12.1 The patch was created on top of FreeType 2.10.3, while the branch has 2.10.1. I repeat :stop using the bundled third party content unless you're willing to update it yourself. In which case, you should simply update to 2.12.1 on your own. Ignore the patches in the CVE. Going forward, don't ship/bundle 3rd party libs, instead add scripts (shell or CMake (the latter has support to fetch remote stuff https://cmake.org/cmake/help/latest/module/FetchContent.html)) that download that source code from git (at a specific commit hash) or as tarballs and unpack them ...etc. This approach means you would only need to change one line in a script and users will get the latest stable source code of a 3rd party lib the next time they build. "Does the next version of lib A build?" that's a question Linux distributions will usually have an answer for; and you will have an answer for it too if you use those same scripts to fetch those sources in your e.g. Windows CI. If you keep bundling them, then the burden of pacthing CVE's in those bundles libs, falls on you (any which way you want to look at it, license-wise, morally, legally...). My 2p's. Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[frameworks-kio] [Bug 454226] Pointless 'Undo: Copy" option is available in 'Edit' menu after skipping all files in a file operation
https://bugs.kde.org/show_bug.cgi?id=454226 Ahmad Samir changed: What|Removed |Added Latest Commit||https://invent.kde.org/fram ||eworks/kio/commit/c34f934e5 ||8911b0ab64fa9cdbbb662f69ab8 ||dfda Resolution|--- |FIXED Status|REPORTED|RESOLVED Version Fixed In||5.98 --- Comment #2 from Ahmad Samir --- Git commit c34f934e58911b0ab64fa9cdbbb662f69ab8dfda by Ahmad Samir. Committed on 19/08/2022 at 15:35. Pushed by ahmadsamir into branch 'master'. FileUndoManager: for copyjob only add undo if it copied something Test plan, before applying this patch: - copy some files/dirs in dolphin, note the Edit menu now has an "undo copy" action - copy the same files/dirs to the same destination again, you should see the copy conflict dialog - enable "apply to all" and click "skip", nothing is copied; now check the Edit menu again, you should see the "undo copy" action still enabled, because another undo command was added even when nothing was copied - trigger "undo copy", nothing happens - trigger "undo copy" again, now it's asking if you want to delete /path/to/dest/files-you-copied-earlier from the destination Add a unittest. FIXED-IN: 5.98 M +57 -0autotests/fileundomanagertest.cpp M +1-1autotests/fileundomanagertest.h M +11 -0src/widgets/fileundomanager.cpp https://invent.kde.org/frameworks/kio/commit/c34f934e58911b0ab64fa9cdbbb662f69ab8dfda -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kservice] [Bug 442721] kf.service.services: KApplicationTrader: mimeType "x-scheme-handler/file" not found
https://bugs.kde.org/show_bug.cgi?id=442721
Ahmad Samir changed:
What|Removed |Added
Version Fixed In||5.96
Status|CONFIRMED |RESOLVED
Latest Commit||https://invent.kde.org/fram
||eworks/kio/commit/a4c404603
||bbf43fda2d60c82c814527bde0a
||8352
Resolution|--- |FIXED
--- Comment #15 from Ahmad Samir ---
Git commit a4c404603bbf43fda2d60c82c814527bde0a8352 by Ahmad Samir.
Committed on 19/08/2022 at 14:31.
Pushed by ahmadsamir into branch 'master'.
DesktopExecParser: don't kioexec if there is a handler for scheme
This fixes an issue where the code called
KApplicationTrader::queryByMimeType("x-scheme-handler/file"), which would
trigger a warning in KApplicationTrader, because there is no
x-scheme-handler/file mimtype.
FIXED-IN: 5.96
M +24 -12 src/core/desktopexecparser.cpp
https://invent.kde.org/frameworks/kio/commit/a4c404603bbf43fda2d60c82c814527bde0a8352
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 457953] New: Super/Win key always opens the Application menu, regardless of set shortcut
https://bugs.kde.org/show_bug.cgi?id=457953 Bug ID: 457953 Summary: Super/Win key always opens the Application menu, regardless of set shortcut Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: a.samir...@gmail.com CC: k...@davidedmundson.co.uk Target Milestone: 1.0 Open Application Menu's config dialog, the shortcut is Alt+F1 by default, if set to that it activated the menu when the Super/Win key is pressed. - set the shortcut to something else, press Super/Win the menu is still activated - unset the shortcut altogether, press Super/Win the menu is still activated Editing ~/.config/kwinrc and adding: [ModifierOnlyShortcuts] Meta= stops the Super/Win key from activating the menu. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 456819] Commenting out code in C++ source files adds // to the very beginning of the line
https://bugs.kde.org/show_bug.cgi?id=456819
--- Comment #6 from Ahmad Samir ---
Git commit fceb6fef10932a5b6aaf698c102f05bbed04e12a by Ahmad Samir.
Committed on 10/08/2022 at 18:20.
Pushed by cullmann into branch 'master'.
KateDocument: always add space after single line comment start marker
So that if you have code:
if (foo) {
do_something();
}
commenting out the second line, it would become (assuming the
position="afterwhitespace" option is set in c.xml):
if (foo) {
// do_something();
}
This works better with clang-format, which insists on reformatting this:
//do_something();
to
// do_something();
to the version with the space, "// ".
Fix unittests.
M +1-1autotests/src/katedocument_test.cpp
M +1-2src/document/katedocument.cpp
https://invent.kde.org/frameworks/ktexteditor/commit/fceb6fef10932a5b6aaf698c102f05bbed04e12a
--
You are receiving this mail because:
You are watching all bug changes.
5.97 respin request 2
Please include https://invent.kde.org/frameworks/kio/-/commit/a1fca0ad405f963e555142a22060a07919f31edf Thanks, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
5.97 respin request
Please include https://invent.kde.org/frameworks/kio/-/commit/ec8ea809b1125b6cede1a2351fc98b5b4c8ca96f Thanks, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature
[frameworks-ktexteditor] [Bug 456819] Commenting out code in C++ source files adds // to the very beginning of the line
https://bugs.kde.org/show_bug.cgi?id=456819 --- Comment #3 from Ahmad Samir --- Git commit 178c4dfbf4eb5ad7c5aef4838f190f717f97766f by Ahmad Samir. Committed on 08/08/2022 at 21:30. Pushed by ahmadsamir into branch 'master'. clang-format.cmake: don't change spaces after '//' in code comments For example, if you have: //This is a comment now clang-format won't change it to: // This is a comment We're mainly interested in formatting the code, not the comments, so that cuts down on some noise when running clang-format. M +5-0kde-modules/clang-format.cmake https://invent.kde.org/frameworks/extra-cmake-modules/commit/178c4dfbf4eb5ad7c5aef4838f190f717f97766f -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453197] When window maximized vertically it vertical size becomes not maximized after maximize and unmaximize
https://bugs.kde.org/show_bug.cgi?id=453197 Ahmad Samir changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #1 from Ahmad Samir --- This happens even without restarting the app: - open dolphin, note the window size, maximize it vertically - maximize it (which affects both vertical and horizontal size) - un-maximize it, it goes back to the initial window size from step 1 Repeat the above but instead of maximizing vertically using kwin shorctus (e.g. middle clicking the maximize button on the title bar), resize the window manually to the same size it would have been changed to; everything works as expected. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453197] When window maximized vertically it vertical size becomes not maximized after maximize and unmaximize
https://bugs.kde.org/show_bug.cgi?id=453197 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 456627] Reported tab name contains non-substituted %n in it
https://bugs.kde.org/show_bug.cgi?id=456627 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #7 from Ahmad Samir --- (In reply to Antonio Rojas from comment #6) > AFAICS this fix hasn't been backported to the 22.08 branch. The bug will > make it to the final release if it's not. The commit was reverted in release/22.08, https://invent.kde.org/utilities/konsole/-/commit/80f33b011f3cb2e0bcc76b01cb5de163e56ae2f5 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kholidays] [Bug 457176] No API documentation for HolidayRegion::rawHolidaysWithAstroSeasons()
https://bugs.kde.org/show_bug.cgi?id=457176 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com, ||spitz...@hotmail.com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kholidays] [Bug 457176] No API documentation for HolidayRegion::rawHolidaysWithAstroSeasons()
https://bugs.kde.org/show_bug.cgi?id=457176 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com, ||spitz...@hotmail.com -- You are receiving this mail because: You are the assignee for the bug.
[konsole] [Bug 456627] Reported tab name contains non-substituted %n in it
https://bugs.kde.org/show_bug.cgi?id=456627 Ahmad Samir changed: What|Removed |Added CC||kishor...@gmail.com --- Comment #5 from Ahmad Samir --- *** Bug 457201 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 457201] %n placeholder in konsole tab title no longer works
https://bugs.kde.org/show_bug.cgi?id=457201 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Ahmad Samir --- *** This bug has been marked as a duplicate of bug 456627 *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 437510] Notification says "Moving" during/after undoing mass renaming with Dolphin
https://bugs.kde.org/show_bug.cgi?id=437510 Ahmad Samir changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Version Fixed In||5.97 Latest Commit||https://invent.kde.org/fram ||eworks/kio/commit/0bf55cca0 ||4fd59f6dffd334d22a950d72092 ||13f7 --- Comment #3 from Ahmad Samir --- Git commit 0bf55cca04fd59f6dffd334d22a950d7209213f7 by Ahmad Samir. Committed on 25/07/2022 at 12:34. Pushed by ahmadsamir into branch 'master'. FileUndoManager: fix job description when undoing a batch-renaming It should be "Renaming", not "Moving". FIXED-IN: 5.97 M +28 -5src/widgets/fileundomanager.cpp https://invent.kde.org/frameworks/kio/commit/0bf55cca04fd59f6dffd334d22a950d7209213f7 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 456819] Commenting out code in C++ source files adds // to the very beginning of the line
https://bugs.kde.org/show_bug.cgi?id=456819
--- Comment #2 from Ahmad Samir ---
(In reply to Christoph Cullmann from comment #1)
> Does it behave better if you pass the singleLine tag the
> position="afterwhitespace" attribute in the XML highlighting file?
Yeah, that seems to have an effect:
if (!iconNo.isNull()) {
buttonNoGui.setIconName(iconNo);
}
becomes:
if (!iconNo.isNull()) {
//buttonNoGui.setIconName(iconNo);
}
but, of course, clang(pesky)-fromat still complains and changes it to:
// buttonNoGui.setIconName(iconNo);
so it would probably need another change in the indenter js code to add "// "
instead of just "//".
(I don't know javascript well enough to try hacking the indenter js code).
--
You are receiving this mail because:
You are watching all bug changes.
[kate] [Bug 456570] "Run current document" fails if path contains spaces
https://bugs.kde.org/show_bug.cgi?id=456570 --- Comment #6 from Ahmad Samir --- Git commit 8e45d772753fb8fc5a2bb2abb1875e9c891df10a by Ahmad Samir. Committed on 23/07/2022 at 13:43. Pushed by cullmann into branch 'master'. Konsole plugin: quote args before passing them to the shell An alternative fix for 456570 M +5-8addons/konsole/kateconsole.cpp https://invent.kde.org/utilities/kate/commit/8e45d772753fb8fc5a2bb2abb1875e9c891df10a -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 456570] "Run current document" fails if path contains spaces
https://bugs.kde.org/show_bug.cgi?id=456570 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #4 from Ahmad Samir --- There is KShell::quoteArg() https://api.kde.org/frameworks/kcoreaddons/html/namespaceKShell.html#a471161f0b7fb9b516932d2a9121c715b -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 456819] New: Commenting out code in C++ source files adds // to the very beginning of the line
https://bugs.kde.org/show_bug.cgi?id=456819
Bug ID: 456819
Summary: Commenting out code in C++ source files adds // to the
very beginning of the line
Product: frameworks-ktexteditor
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: indentation
Assignee: kwrite-bugs-n...@kde.org
Reporter: a.samir...@gmail.com
Target Milestone: ---
For example:
if (!iconNo.isNull()) {
buttonNoGui.setIconName(iconNo);
}
if I toggle comment on the middle line (or all of them), it becomes:
if (!iconNo.isNull()) {
// buttonNoGui.setIconName(iconNo);
}
the // characters are added to the very beginning of the line; which works, but
interferes with clang-format, which will then change that to:
if (!iconNo.isNull()) {
// buttonNoGui.setIconName(iconNo);
}
This can be avoided if the // characters are added like this to begin with:
if (!iconNo.isNull()) {
// buttonNoGui.setIconName(iconNo);
}
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-solid] [Bug 446834] Windows C drive is named "Basic data Partition"
https://bugs.kde.org/show_bug.cgi?id=446834 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #4 from Ahmad Samir --- As an aside: a filesystem label is tied to the filesystem not the OS, so you can change the label under Windows, and it'll be used in Linux. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kxmlgui] [Bug 444098] No entry in Global Shortcuts to configure KCommandBar
https://bugs.kde.org/show_bug.cgi?id=444098 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #2 from Ahmad Samir --- The KCommandBar action shortcut is added to the KActionCollection in KXmlGui, so for now you can configure that shortcut in each app's Settings -> Configure keyboard shortcuts (it's called "Find Action"). -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 438309] Built-in/hardcoded profile should not be named "Default [Read-only]"
https://bugs.kde.org/show_bug.cgi?id=438309 Ahmad Samir changed: What|Removed |Added CC||pilo...@gmail.com --- Comment #8 from Ahmad Samir --- *** Bug 456602 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 456602] No edit option for profiles
https://bugs.kde.org/show_bug.cgi?id=456602 Ahmad Samir changed: What|Removed |Added Resolution|--- |DUPLICATE Status|REPORTED|RESOLVED --- Comment #7 from Ahmad Samir --- This is sort of duplicate of bug 438309; so closing as such. *** This bug has been marked as a duplicate of bug 438309 *** -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 456602] No edit option for profiles
https://bugs.kde.org/show_bug.cgi?id=456602 --- Comment #5 from Ahmad Samir --- The default/built-in profile became read-only because otherwise it caused other issues. The "Root Shell" profile is read-only because the .profile file is owned by root, so your user account has no write-access to it. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 445044] LOTS of metadata access warnings on start-up, a few other ones, e.g. "null action"
https://bugs.kde.org/show_bug.cgi?id=445044 Ahmad Samir changed: What|Removed |Added Status|CONFIRMED |NEEDSINFO Resolution|--- |WAITINGFORINFO CC||a.samir...@gmail.com --- Comment #3 from Ahmad Samir --- If this still an issue? -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 456602] No edit option for profiles
https://bugs.kde.org/show_bug.cgi?id=456602 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #3 from Ahmad Samir --- If the profile you're trying to edit has "Read-only" in its name, then it can't be edited, you need to create a new profile. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ki18n] [Bug 438394] We need a software utility that will SOLVE the problem of one-off running KDE programs in a different language
https://bugs.kde.org/show_bug.cgi?id=438394 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #11 from Ahmad Samir --- Looking around it looks like setting LANGUAGE env var would work[1] e.g. from terminal: LANGUAGE=en dolphin [1]https://invent.kde.org/frameworks/kxmlgui/-/blob/master/src/kswitchlanguagedialog_p.cpp#L69 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 448859] KEmailClientLaucherJob can't lauch Thunderbird with env variable in Exec
https://bugs.kde.org/show_bug.cgi?id=448859 Ahmad Samir changed: What|Removed |Added Status|REOPENED|NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #8 from Ahmad Samir --- Ping. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 449600] kf.kio.slaves.file copy() QUrl mode= 420 Cannot copy file (Errno: 38)
https://bugs.kde.org/show_bug.cgi?id=449600 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #1 from Ahmad Samir --- Is this still an issue? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 454226] Pointless 'Undo: Copy" option is available in 'Edit' menu after skipping all files in a file operation
https://bugs.kde.org/show_bug.cgi?id=454226 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #1 from Ahmad Samir --- Good catch! https://invent.kde.org/frameworks/kio/-/merge_requests/908 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 453576] kioslave5 consumes massive resources slowing down Gimp file save 10 times
https://bugs.kde.org/show_bug.cgi?id=453576 Ahmad Samir changed: What|Removed |Added Status|REPORTED|NEEDSINFO CC||a.samir...@gmail.com Resolution|--- |WAITINGFORINFO --- Comment #1 from Ahmad Samir --- >From terminal enabled kio debug output, and start dolphin: export QT_LOGGING_RULES="*kio*=true" dolphin then save in gimp, and attach the terminal output here, hopefully it'll give a clue what's going on. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfigwidgets] [Bug 454061] KMail crashes in KCommandBar
https://bugs.kde.org/show_bug.cgi?id=454061
--- Comment #3 from Ahmad Samir ---
bool QIconEngine::isNull() const
{
bool isNull = false;
const_cast(this)->virtual_hook(QIconEngine::IsNullHook,
);
return isNull;
}
second backtrace, it's crashing on the const_cast line above, which makes no
sense to me...
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-kiconthemes] [Bug 452341] When an icon is not found from its specified absolute path, look for it in the active icon theme before giving up
https://bugs.kde.org/show_bug.cgi?id=452341 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #7 from Ahmad Samir --- Giving the code an absolute path, is restricting it to that exact path, if it's not found, the search should fail (as it does now). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kded] [Bug 452859] kded5 crashes with xrandr after reloading i2c_amd_mp2_plat.ko followed by xrandr
https://bugs.kde.org/show_bug.cgi?id=452859 Ahmad Samir changed: What|Removed |Added Resolution|--- |WAITINGFORINFO CC||a.samir...@gmail.com Status|REPORTED|NEEDSINFO --- Comment #1 from Ahmad Samir --- This backtrace is incomplete, please install the debuginfo packages, and provide another backtrace. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 452884] Selection text color is ignored
https://bugs.kde.org/show_bug.cgi?id=452884 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #11 from Ahmad Samir --- Could you try with a new/fresh user account? so that it's using the default color scheme, widget style...etc. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kactivities] [Bug 453570] activitymanagerd created database which took 80 GB in file system
https://bugs.kde.org/show_bug.cgi?id=453570 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #21 from Ahmad Samir --- (In reply to Tilman Vogel from comment #20) > > Are you all on Arch? > > No, I am on openSUSE Tumbleweed and had that problem. Also, > kactivitymanagerd ate 100% of one of my cores. I removed database and config > files. After that, it did not happen again yet. I had this same issue on Tumbleweed, and deleting the database files fixed the issue, I thought it was a fluke on my system, so never reported it. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfigwidgets] [Bug 454061] KMail crashes in KCommandBar
https://bugs.kde.org/show_bug.cgi?id=454061 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #1 from Ahmad Samir --- I couldn't reproduce this issue; do you still see it? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 455281] Folder selector mounts CIFS shares on opening
https://bugs.kde.org/show_bug.cgi?id=455281 --- Comment #3 from Ahmad Samir --- Could you try this? enable kio debug, `export QT_LOGGING_RULES="*kio*=true"`, then open the app, and recreate the bug, and post the log. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 455281] Folder selector mounts CIFS shares on opening
https://bugs.kde.org/show_bug.cgi?id=455281 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #1 from Ahmad Samir --- As a data point, does the same issue happen if you open the file dialog from e.g. kwrite or kate? (i.e. is it specific to the that KCM or a general issue). -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kxmlgui] [Bug 456208] KMainWindow saves auto settings too often: this can freeze applications
https://bugs.kde.org/show_bug.cgi?id=456208 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #1 from Ahmad Samir --- The link in your post is to a source file in kdelibs, which was split into multiple repos many years ago, kmainwindow.cpp is now in KXmlGui; do you see this problem with recent KF5 versions? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 456223] Dolphin closes when copying files to SMB1 Share
https://bugs.kde.org/show_bug.cgi?id=456223 Ahmad Samir changed: What|Removed |Added CC||a.samir...@gmail.com --- Comment #2 from Ahmad Samir --- The backtrace isn't complete, please install the necessary debuginfo packages and provide another backtrace. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 434912] File selector remembers last thumbnail previewed in last selected path
https://bugs.kde.org/show_bug.cgi?id=434912 Ahmad Samir changed: What|Removed |Added Version Fixed In||5.96 Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Latest Commit||https://invent.kde.org/fram ||eworks/kio/commit/a5b354b9c ||f350043e106ecd041de595d4fe7 ||ed27 --- Comment #4 from Ahmad Samir --- Git commit a5b354b9cf350043e106ecd041de595d4fe7ed27 by Ahmad Samir. Committed on 06/07/2022 at 00:21. Pushed by ahmadsamir into branch 'master'. KImageFilePreview: if no current preview, don't show last one on resize Test plan: - using e.g. the kfilewidgettest_gui app, show the preview panel, and select some image or text file, so that a preview is shown - unselect the file, the preview panel should be blank - resize the preview panel FIXED-IN: 5.96 M +5-0src/filewidgets/kimagefilepreview.cpp https://invent.kde.org/frameworks/kio/commit/a5b354b9cf350043e106ecd041de595d4fe7ed27 -- You are receiving this mail because: You are watching all bug changes.
