Re: [Interest] Will TSAN_OPTIONS=detect_deadlocks=1 work when Qt is compiled with -sanitize thread?
Deadlocks usually occur across several threads. Do you have a stack trace for other threads, too? Alexey On Fri, 2024-07-19 at 12:12 +0100, Nuno Santos via Interest wrote: > Dennis, > > Thanks for the clarification. > > Maybe it is deviating a bit from Qt. It’s probably something I’m not > doing correctly from the Qt paradigm perspective but this is one of > those problems where I feeling lost. > > I’ve just had one of those rare deadlock and it happened like this: > > - This is a music making application. I have the audio processing and > the GUI. > - In the audio render thread, I call the processing of the sequencer > which is responsible for handling the music events. > - There are visual representations of this elements that contains the > notes that are being played > - During the processing of the musical steps, there is a signal that > is being called. It got stuck there. > > But invoking a method as a queue connection in another thread > shouldn’t be a problem, right? > > QMetaObject::invokeMethod(this, &DSClip::stepChanged, > Qt::QueuedConnection); > > This invoke will trigger a signal that will request the DSClip visual > instance to be updated on the QML side. > > Here is the place it got stuck in the audio render thread. It got > locked when invoking the method. > > Does this ring any bell? > > Thanks! > > Best, > > Nuno > > > > > On 19 Jul 2024, at 12:00, Dennis Luehring wrote: > > > > Am 19.07.2024 um 12:52 schrieb Nuno Santos: > > > Can data race cause deadlocks? > > > > > > Or should I explicitly look for deadlock: "lock-order-inversion > > > (potential deadlock)” > > > > > > data races can maybe get you into deadlocks someway... but you > > should > > look for lock-order-inversions and fix them (even if very hard to > > sometimes understand why they happening) > > > > > > btw: the discussion is drifting away from Qt itself :) > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Why does the QtLogging message not include type (e.g. WARNING)?
I'm actually grateful that the original message is so concise,
otherwise I wouldn't look for a way to customise it. I don't think it's
worth arguing what kind of information should or shouldn't be included
there - situations and even tastes differ. On my development machine, I
have the following defined:
QT_MESSAGE_PATTERN=%{time h:mm:ss.zzz}|%{category}|%{if-
debug}D%{endif}%{if-info}I%{endif}%{if-warning}W%{endi
f}%{if-critical}C%{endif}%{if-fatal}F%{endif}|%{message}
See https://doc.qt.io/qt-6/qtlogging.html#qSetMessagePattern for
details. Whatever format you apply in this way will be followed by Qt
and (unless it overrides, which is unlikely) QGIS as well.
Alexey
On Sun, 2023-12-10 at 14:03 +0100, Thomas Larsen Wessel wrote:
> The documentation (https://doc.qt.io/qt-6/qtlogging.html) states:
>
> The default pattern is %{if-category}%{category}:
> %{endif}%{message}
>
> 1) In my limited experience most or all logging architectures print
> the type (aka. severity or criticality, e.g. warning, debug, info,
> etc.) by default.
>
> 2) And in my personal opinion it should be default to print this,
> since the severity is often just as important as the message itself,
> when the goal is to leave the user / log reader informed.
>
> Is there a good reason why the severity is left out of the default
> format?
>
> My current situation and motivation for writing:
>
> I have a number of Python scripts that rely on PyQGIS, which relies
> on Qt. They are part of a small software package that is distributed
> to a number of machines. Each of these scripts occasionally produce
> log messages via QtLogging, and they are all printed without any
> context (unless I set them up differently). Its not my code that
> calls QtWarning, etc., they are called from either QGIS or Qt.
>
> Here is an example.
>
> QStandardPaths: wrong permissions on runtime directory
> /run/user/1000/, 0755 instead of 0700
>
> When someone sees this warning, they don't know if this is an error
> or warning. They don't know if its severe enough that they should do
> something or just ignore this. IMHO there is no doubt it should be
> prefixed with "Warning", "WARN" or similar.
>
> So now I set a custom format in each of my scripts. That works of
> course. But IMHO it would make a whole lot of sense if the default
> format was changed to include the severity :)
>
> Sincerely
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator Survey - Qt Group
On Wed, 2023-08-23 at 10:13 +, Pedro Bessa via Interest wrote: > > > Whether you are a Qt Creator user or not, the Qt Group would like to > hear your thoughts and experiences as an IDE user. > > Please take our survey to help us improve Qt Creator's user > experience: > https://www.surveymonkey.com/r/qtcreatorsurvey2023 I wonder if your survey is only for professional software developers or, e.g., open source enthusiasts like me as well? I struggle with the "Job title" question, to begin with - I could put my actual job title but it will be rather irrelevant to what I'm doing with Qt Creator. And it's pretty much the same struggle further down the road. I guess many KDE folks are in the same boat, so posting on-list. -- Alexey Rusakov ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Convert to QMetaMethod from QObject + const char *
Scott,
I guess the trick is to pass SIGNAL() as the second argument, rather
than a function or a function object. If you have the specific signal
passed to connect() (not a parameter passed from outside) then the
following might work for you (assuming C++17):
template
void func(..., ReceiverT* receiver, SlotT slot)
{
// logic
// The below assumes that `sender` points to an object of type
// `Sender` with a signal `void trigger()`; make sure to change
// it in both if constexpr branches
if constexpr (std::is_same_v) {
QObject::connect(sender, SIGNAL(trigger()), receiver, slot);
} else
QObject::connect(sender, &Sender::trigger, receiver, slot);
// more logic
}
(after playing around, looking at values in the debugger and studying
the relevant pieces of the Qt source code)
Actually, you can extract QMetaMethod out of whatever SIGNAL()/SLOT()
gives you if you're ok to rely on the undocumented format of the string
yielded by those macros, which is "NmethodName(Type1, Type2...)"
where N is a single digit encoding whether it's a signal or a slot. So
basically it could look like:
template
void func(..., ReceiverT* receiver, SlotT slot)
{
// logic
const auto signal = &Sender::trigger; // Put the signal pmf here
if constexpr (std::is_same_v) {
++slot; // skip the code - relies on the internal Qt logic
const auto& rmo = receiver->metaObject();
const int slotIndex = rmo->indexOfSlot(slot);
Q_ASSERT(slotIndex >= 0);
QObject::connect(..., QMetaMethod::fromSignal(signal),
receiver, rmo->method(slotIndex));
} else
QObject::connect(..., signal, receiver, slot);
// more logic
}
Alexey Rusakov
-Original Message-
From: Volker Hilsheimer
To: Scott Bloom
Cc: interest@qt-project.org
Subject: Re: [Interest] Convert to QMetaMethod from QObject + const
char *
Date: Wed, 17 Aug 2022 09:23:37 +
> On 16 Aug 2022, at 22:39, Scott Bloom wrote:
>
> I have a function that takes in a QObject and const char *
> signal/slot
>
> void func( …, QObject * target, const char * member )
> {
> …. logic
> QObject::connect( ….., target, member )
> … more logic
> {
>
>
> So I can call it via
>
> ….
> func( …., m_target, SLOT( )
> …
>
> it works fine
>
> I would like to modify the function so it can also take
>
> func( …., m_target, &TargetClass::
>
>
> however, I cant for the life of me figure out to convert, if its even
> possible
>
> Id prefer not to have to copy all the logic in func
>
> Is this possible?
>
> Yes, I know I can use std::enable_if, but that just copies the
> function logic
>
> Thanks
> Scott
Check QHostInfo::lookupHost for a Qt API that does that. It relies on
private Qt APIs though.
There might be C++17-ways to simplify some of that using `if
constexpr`, but the basics will probably be the same.
Volker
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] semi-modal dialog
I see quite a few applications adopting a popup instead that collapses into a toolbar icon showing a progress summary as a micro-pie-chart. And if you need to disable access to some components in the main window, you can disable/enable respective widgets depending on the progress. If the operation really blocks everything, maybe put the progress controls into an overlay widget parented by the main window, disabling actual main window controls. If you still need the ability to move the progress dialog independently of the main window, I'd suggest using a torn-off toolbar as a container of progress controls. Kind regards, Alexey On Fri, 30 Jul 2021 at 01:56, Scott Bloom wrote: > This is the current path we are going down. > > The problem is also the titlebar differences between windows and linux > > > > ~~Scott > > > > Original message > From: John Weeks > Date: 7/29/21 4:34 PM (GMT-08:00) > To: Giuseppe D'Angelo via Interest > Cc: Scott Bloom > Subject: Re: [Interest] semi-modal dialog > > We do something similar- we make it possible to put up a control panel (a > special type of window in our application) that allows the user to interact > in certain ways with one other window and no others. We do it with some > very hairy code that probably would make Thiago throw up. > > We fake the modal nature of this partially modal window by installing an > event filter on the application. Then we just block all the events that > shouldn't get through. Getting the choice of events right can be very > tricky! The ugliest bit is responding to window activation to force the > active window back to the one we want to be active. > > Hopefully, someone has a better solution to this problem! > > > On Jul 29, 2021, at 3:21 PM, Scott Bloom wrote: > > > > Here is my problem. > > > > I have a progress dialog, that I need to be able to use as a modal > dialog with respect to the main window (a QMainWindow class, which is also > its parent widget). > > > > But, I need to still be able to minimize the main application and even > move it. > > > > Any ideas on the best way to implement something like this? > > > > Scott > > ___ > > Interest mailing list > > Interest@qt-project.org > > https://lists.qt-project.org/listinfo/interest > > -John Weeks > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > -- Alexey Rusakov ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] L Word
why are you keeping the conflicts going? > > > > -- > > Best Regards, > > Bernhard Lindner > > > > ___ > > Interest mailing list > > Interest@qt-project.org > > https://lists.qt-project.org/listinfo/interest > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > -- Alexey Rusakov ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Guide me through the Qt offerings for GUIs
s using Scintilla or > the Electron JavaScript based things, or even GUI Emacs even on an i5-gen3 > and you are almost instantly taken to the line you were on with perfect > syntax highlighting. Because QPlainTextEdit has to do everything in the > main event loop and appears not to understand scope of visibility, it > starts at the top and works its way down. Bad enough with one file, but try > having three tabs open all with large files all using regular expressions > for highlighting in the main event loop. > > The underlying graphics API contributes to the single-thread-i-ness which > really drops the 6-bottom plow in behind the lawn mower. > > Integration isn't service. During the era of the 286 and OS/2 Integration > made sense. Today you need a stand alone service having a limited physical > communication API that can handle hundreds of different logical API versions. > This is how you do things in the world of large applications so you can > support things for 30+ years. > > Even economists know the story of the 486SX. > https://www.google.com/books/edition/The_American_Economic_Review/iP6yIAAJ?hl=en&gbpv=1&bsq=486sx+defective+fpu&dq=486sx+defective+fpu&printsec=frontcover > > Even Byte Magazine told the 486SX > story.https://www.google.com/books/edition/Byte/bTxVMAAJ?hl=en&gbpv=1&bsq=486sx+defective+fpu&dq=486sx+defective+fpu&printsec=frontcover > > You will find it is also one of the many case studies used by good management > schools about turning failure into profits. > > The other case studies they will cover are: > > the Sony Walkman. A shiny new VP combined a failed portable tape recorder > that couldn't record with an earbud/headphone set that had no market. Both > R&D failures that, when combined became a highly profitable niche market. > > 3M Post-It Notes: Engineers and scientists set out to create a glue so strong > it made Crazy glue look like Elmer's School Glue. They took the path of > exponentially increasing the length of time to dry. The end result was it > never really dries and bonds. It was a complete failure until someone used it > to glue little yellow pieces of paper together in the form of note pads. > People found you could stick them to anything and they would come right off. > > Gasoline: This was largely a byproduct of making heating and lamp oil. It was > dumped into rivers and burned off . . . Until Henry Ford came along. > > Vulcanization: Mr. Goodyear meeting investors in a shed that had a wood stove > for heat was raging that they wouldn't give him more money. Rubber tires were > so flimsy and blew out so often that "can I kick the tires" became a line in > American culture. Flinging his new hunk of rubber around while hollering and > gesturing with his arms, it landed on the hot wood stove. After scraping it > off the stove they found the result was still flexible and far more > impervious to cuts. He got his money. > > > > -- > Roland Hughes, President > Logikal Solutions > (630)-205-1593 > https://theminimumyouneedtoknow.comhttps://infiniteexposure.nethttps://lesedi.ushttps://johnsmith-book.comhttps://logikalblog.comhttps://interestingauthors.com/blog > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > -- Alexey Rusakov ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] CLion to replace QtCreator?
I don't know what I'm doing wrong but the new compile-time-checked syntax is auto-completed by my Qt Creator (that came with Qt 5.5.1) as well :) and you're a bit blunt on not recommending the older syntax. Apparently you haven't spent enough time with QML. On Mon, Apr 4, 2016 at 2:41 AM -0700, "Nikos Chantziaras" wrote: It only works with the old, Qt4 string/macro-based syntax (using the SLOT and SIGNAL macros.) Which is totally unsafe and I don't use it anymore (I wouldn't even recommend it to anyone.) The new syntax, which is statically checked (compile time) and thus type-safe, even though it's the recommended one by Qt, is not supported in Creator using the clang model. This does not auto-complete: connect(this, &MyWidget::mySignal, control, &MyControl::mySlot); This is not the end of the world, but still it's unpleasant to work with. The clang code model will get better in the future, I'm sure of it. But right now, it's pain all the way down. The lacking auto-completion might not even be the worst of it. In the end, that's "just" a productivity and convenience issue. The lack of reliable "find all uses" in the clang model is actually a more serious problem, since if you trust it you're left with the false sense of security that you caught all the places in your code where a symbol was used and made whatever changes you needed to make to fix an issue. But it doesn't find all uses. Which is *dangerous*. So I have to do a text-based, project-wide search for a string instead to actually get to all uses of the symbol and update my code. On 04/04/16 11:42, Alexey Rusakov wrote: > Not sure what I'm doing wrong but auto-completion for connect() does > work for me. Moreover, I don't expect CLion to be able to work with > SIGNAL() and SLOT() notation without Qt-aware plugin. > > I might expect CLion to rule them all in some indefinite future but very > hardly at the moment. Disclaimer: I am a switch-over from CLion to Qt > Creator, exactly because Qt Creator worked for me much better than CLion > for CMake-based Qt-using projects. > > > > On Mon, Apr 4, 2016 at 1:13 AM -0700, "Nikos Chantziaras" > > wrote: > > On 03/04/16 22:00, Thiago Macieira wrote: > > On domingo, 3 de abril de 2016 21:07:00 PDT Emre Besirik wrote: > >> Do you also find it a littlebit unpleasent to code in QtCreator like > me? > >> Does Qt plan to do something about this? > > > > It would be more constructive if you explained what your issues are and > what > > you findto be unpleasant. Without that, nothing is ever going to happen. > > I assume the same things as the rest of us, perhaps: > > * Lack of auto-completion for connect(). > * Very slow auto-completion. > * Generally auto-completion sometimes work, sometimes doesn't. > * "Find uses" doesn't work, so you have to grep to find uses. > * It gets very confused with smart pointers and templates in general. > * Sometimes doesn't highlight local uses. > > This is the clang code model, and these things are a major PITA. > > The Creator code model was excellent for C++98. The last few months, I > complete switched my projects to C++14, and that code model is now > useless, so clang is the only choice. And it's not very pleasant to work > with. In fact, I'd say it's very unpleasant. > > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] CLion to replace QtCreator?
Not sure what I'm doing wrong but auto-completion for connect() does work for me. Moreover, I don't expect CLion to be able to work with SIGNAL() and SLOT() notation without Qt-aware plugin. I might expect CLion to rule them all in some indefinite future but very hardly at the moment. Disclaimer: I am a switch-over from CLion to Qt Creator, exactly because Qt Creator worked for me much better than CLion for CMake-based Qt-using projects. On Mon, Apr 4, 2016 at 1:13 AM -0700, "Nikos Chantziaras" wrote: On 03/04/16 22:00, Thiago Macieira wrote: > On domingo, 3 de abril de 2016 21:07:00 PDT Emre Besirik wrote: >> Do you also find it a littlebit unpleasent to code in QtCreator like me? >> Does Qt plan to do something about this? > > It would be more constructive if you explained what your issues are and what > you findto be unpleasant. Without that, nothing is ever going to happen. I assume the same things as the rest of us, perhaps: * Lack of auto-completion for connect(). * Very slow auto-completion. * Generally auto-completion sometimes work, sometimes doesn't. * "Find uses" doesn't work, so you have to grep to find uses. * It gets very confused with smart pointers and templates in general. * Sometimes doesn't highlight local uses. This is the clang code model, and these things are a major PITA. The Creator code model was excellent for C++98. The last few months, I complete switched my projects to C++14, and that code model is now useless, so clang is the only choice. And it's not very pleasant to work with. In fact, I'd say it's very unpleasant. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] how can I call qRegisterMetaType?
On 17 May 2016 at 08:47, Hamish Moffatt wrote: > > And do I need to call Q_DECLARE_METATYPE(QList) or > not? It doesn't seem to be necessary in my test cases I don't think so. The documentation for Q_DECLARE_METATYPE says that if Type is registered then QList is automatically recognized by the metatype system as well. And as far as I understand the documentation, this applies to types declared as Q_ENUM as well. -- Alexey Rusakov ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
