Re: [Interest] QtCreator c++20 highlighting

[Konstantin Shegunov]

On Mon, Feb 19, 2024 at 2:22 PM Frank Mertens  wrote:

> Hi Konstantin,
>

Hi Frank,

I'm here with QtCreator 12.0.1 and C++20 syntax highlighting works just
> fine.
>

Okay, thank you!
I'm then going to assume that my version is simply too old.

Of course I had to enable it?! In CMakeLists.txt that is done with:
> set(CMAKE_CXX_STANDARD 20)
>

Yes, surely. I've done that.

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] QtCreator c++20 highlighting

[Konstantin Shegunov]

Hello,
Are c++20 features (operators/keywords) supported with the QtCreator
(10.0.2) highlighter?
I'm asking because what I observe is that keywords like concept, consteval,
requires are not recognised and have no highlighting. So I'm not sure if my
version is old, the feature isn't supported, or it's a bug.

Note that I'm not talking about the clangd (clang code model), which picks
up the features fine and hints appropriately in-editor, but only the source
editor highlighting.

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QApplication was not created in the main() thread.

[Konstantin Shegunov]

On Fri, Jun 30, 2023 at 11:12 AM Yauheni Pervenenka via Interest <
interest@qt-project.org> wrote:

> Hi community,
> I was faced with a warning QApplication was not created in the main()
> thread. on windows only, it is very rare happen,
>

Almost certainly you're creating a static `QObject` instance that sets the
"main" thread, and whenever the application constructor runs it reports
this as error.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML plugin with wasm not building

[Konstantin Shegunov]

On Sat, Feb 18, 2023 at 3:09 AM Sze Howe Koh  wrote:

> Does it work if you use STATIC instead of SHARED?
>

No, it makes no difference. I am assuming that `qt_add_library` changes it
in the post-processing stage to be the correct type.

Is the plugin built at the same time as the main application?
>

Yes. As I mentioned I don't really need a plugin as such, I always link to
the backing target (hence me trying to use  `PLUGIN_TARGET` with the lib
target).

>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML plugin with wasm not building

[Konstantin Shegunov]

Me again. If it matters, the exact diagnostics is as follows:

On Mon, Feb 13, 2023 at 10:22 AM Konstantin Shegunov 
wrote:

> `qt_register_pluginXXX` (or something of this sort).
>

Here's what emscripten reports:

error: undefined symbol: _Z31qt_static_plugin_XXX_UiPluginv (referenced by
top-level compiled C/C++ code)
warning: Link with `-sLLD_REPORT_UNDEFINED` to get more information on
undefined symbols
warning: To disable errors for undefined symbols use
`-sERROR_ON_UNDEFINED_SYMBOLS=0`
warning: __Z31qt_static_plugin_XXX_UiPluginv may need to be added to
EXPORTED_FUNCTIONS if it arrives from a system library
Error: Aborting compilation due to previous errors

If I don't use  `PLUGIN_TARGET xxx`, instead I get a cmake warning and the
runtime says the plugin can't be loaded:
---/qtbase/lib/cmake/Qt6Qml/Qt6QmlMacros.cmake:2821 (message):
  The qml plugin 'xxx-uiplugin' is a dependency of 'xxx', but the link
  target it defines (xxx-uiplugin) does not exist in the current scope.
  The plugin will not be linked.
Call Stack (most recent call first):
  ---/qtbase/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:640
(qt6_import_qml_plugins)
  ---/qtbase/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:640 (cmake_language)
  ---/qtbase/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:705
(_qt_internal_finalize_executable)
  ---/qtbase/lib/cmake/Qt6Core/Qt6CoreMacros.cmake:562:EVAL:1
(qt6_finalize_target)
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] QML plugin with wasm not building

[Konstantin Shegunov]

Hi,
I wanted to build a simple QML application with webassembly, to try things
out. However I've hit a strange problem I can't really figure out. The
application consists of an executable and a library. It builds and runs
fine for desktop, however switching to wasm - it fails with an unresolved
symbol:
`qt_register_pluginXXX` (or something of this sort). In the cmake I used
the qt_add_qml_module
with pointing the target to the actual library (I don't really need a
separate plugin). It goes something like this:

qt_add_library(xxx SHARED ... sources)
...
qt_add_qml_module(xxx
URI My.Module
PLUGIN_TARGET xxx
...
)

Now seeing the error I attempted to put the now outdated (apparently)
NO_PLUGIN which causes the application to build successfully, but then it
doesn't load - it can't find the QML-exposed classes (the .qml files are
found okay). So it appears that the binary is indeed correctly linked (as
the qml files are in a resource and can be loaded), but the type
registration isn't run.
What am I doing wrong here? Should I do some manual call to register the
types I'm not aware of?

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML notify dynamic property changes from C++

[Konstantin Shegunov]

On Mon, Mar 7, 2022 at 12:20 PM Konstantin Shegunov 
wrote:

> Sure, I'm going to try and prepare a testcase sometime later this week.
>

A bit later than I'd hoped for, but I tracked down the problem; posting for
anyone that may stumble onto this at a later time.

I didn't have an equality operator for my gadget type, and a bit
surprisingly (to me at least) QQmlPropertyMap::insert() does check against
the existing value. Since I didn't have the == operator what I assume was
happening (I hadn't the ability to check at the time) was that QVariant
coerced the type to bool (as I've an implicit cast operator) and hence it
always produced in the QQmlOpenMetaObject::checkedSetValue() the same
value-check result no matter the actual object, hence the value didn't
update for me.

Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML notify dynamic property changes from C++

[Konstantin Shegunov]

On Mon, Mar 7, 2022 at 12:05 PM Ulf Hermann  wrote:

> Sorry, it's called:
> void insert(const QString &key, const QVariant &value);
>

Just checked in the debugger, but calling it doesn't appear to update the
value C++-side even.

In order to further examine this we
> would need a minimal example to reproduce the problem.
>

Sure, I'm going to try and prepare a testcase sometime later this week.

On a related note, I'd suggest including an iterator/const_iterator for the
QQmlPropertyMap for convenience, and also it could possibly handle this
sort of value change in a more streamlined manner.

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML notify dynamic property changes from C++

[Konstantin Shegunov]

Hi,

On Mon, Mar 7, 2022 at 11:20 AM Ulf Hermann  wrote:

> QQmlPropertyMap::setValue(key, value) should trigger the change signal
> of the property.
>

Do you possibly mean QQmlPropertyMap::updateValue, because I don't see a
setValue method in the documentation. Either way it doesn't appear to work
for me, which made me muse a bit. Is it possible that it doesn't update
because my property is a gadget and the binding is through an implicit
QString conversion? Additional piece of information that may be relevant is
that the QObject which exposes the dynamic properties is a 'constant'
property of another object (I don't want to allow it get set from QML),
should this be a problem, I'd assumed not?

Mind that "QVariant &operator[](const QString &key)" is broken in that
> way. It cannot possibly notify if you change the value through the
> reference it returns.
>

Noted (also confirmed by my experiments).
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] [Qt6] QML notify dynamic property changes from C++

[Konstantin Shegunov]

Hello,
I have exposed some dynamic properties through QQmlPropertyMap to the QML
engine and that works well. However I need to change the values from C++
and want to notify the bindings about the property change from there. Is
there a way to do it?

I attempted to manually emit the valueChanged(), and I can capture the
signal from QML, but that works with the property name and obviously
doesn't update the bindings. Another thing I attempted was to use the
QMetaProperty::write hoping that it's going to bubble up through the QML
layer, which it doesn't, and there doesn't appear to be some specific event
that I could use to push onto the object to force the QML to reevaluate.

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [External]Re: How to get QtConcurrent to do what I want?

[Konstantin Shegunov]

On Mon, Jan 31, 2022 at 7:15 PM Murphy, Sean 
wrote:

>   1. Creating 60,000 QObjects in a single thread appears to be slow

[...]
>

Ehm, maybe I'm not understanding something, but why do you need objects to
begin with?


> The actual loop is this:
> // generate each tile with its assignment
> [snip]
>

What's the significance of the tiles? As far as I can tell from your
requirements, you don't care about
the "true geometry" of the data.

At least to me it seems you want something like (pseudo algorithm):

1) Start QThread::idealThreadCount threads (QThread::create<> / std::thread)
2) Each thread works on "total samples" / QThread::idealThreadCount buffers
that are completely independent.
2.1) Each thread goes through each sample from a partially mapped (from the
file) buffer, takes the min/max to get the dynamic range
2.2) Sync the threads to get the global min/max
2.3) Go through each of the buffers a second time to normalize the dynamic
range (again no tiles involved, just samples)
3) Done.

Note: As each thread works on its own piece of data in both cases there's
no sync required at any one point - you just read/write different parts of
the same thing. Which is true both for when you load/write from/to a file
and from/to memory.

What am I missing here?

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Inject a QML enum from C++ at runtime

[Konstantin Shegunov]

On Thu, Jan 20, 2022 at 5:13 PM Ulf Hermann  wrote:

> > Well, the number of names isn't fixed is the point - they're loaded at
> > runtime and will change (increase) from time to time.
>
> Then an enumerator won't really help you. The point of an enumerator is
> that each entry is a constant.
>

Each entry is still a constant either way. What I'd intended to provide is
a sort of a "remapping". I simply need stable names from the QML side, that
map to something (as "definitive" as this may sound), which "something" is
going to be mapped to vector indices on the C++ side. The latter (the
vector indices) I must assure are not changed from one version to the next.
While I do still need to provide some convenient API for QML to modify the
value(s). This in a nutshell is what I'm trying to do. Perhaps doing it
with an enum in QML is misguided, I was simply attempting to avoid defining
one such enum in C++ and needing to reship the compiled binary (to a
colleague). Perhaps my whole workflow idea is flawed, I guess.

If the names and values can change at runtime, you should use a
> QVariantMap or a JavaScript object.
>

Yes, I suppose. Perhaps that's what I'm going to do in the end. Thanks for
the input.

If for each version of the program the set of names is fixed, and only
> the values change, then properties on a singleton are the better choice.
>

Actually the other way around (as, described above).

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Inject a QML enum from C++ at runtime

[Konstantin Shegunov]

On Thu, Jan 20, 2022 at 4:55 PM Ulf Hermann  wrote:

> Why does it have to be an enumerator?


It doesn't, of course. Currently I'm simply using strings instead. However
it's 'nice' for the QML person/people to refer to a real name with an
integer behind instead of a free-floating string, albeit you could make the
argument that it's the same either way.


> The code accessing them needs to know a fixed set of names after all.
>

Well, the number of names isn't fixed is the point - they're loaded at
runtime and will change (increase) from time to time.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] [Qt6] Inject a QML enum from C++ at runtime

[Konstantin Shegunov]

Hello,
I imagine I'm not supposed to do such stuff, but is it at all possible to
provide a QML enumerator at runtime from C++?

I took a peek how the QML engine deals with enums, and it does appear it's
technically feasible, provided there's some API, which understandingly
isn't public.
What I'd want to do is to read some configuration file/resource from C++
and fill out a set of named constants in QML based on it.  In C++ I have no
problem indirectly referring to the data, but it'd be advantageous for me
for the QML part to refer to a set of scoped constants by name.
Perhaps I'm thinking in the wrong direction, so if anyone has a suggestion,
it is more than welcome.

Thanks,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Konstantin Shegunov]

On Wed, Jan 19, 2022 at 10:44 AM Alexandru Croitor 
wrote:

> I assume you mean you did target_sources(tsc_ui_target INTERFACE dummy.cpp)
> target_link_libraries(your_shared_lib PRIVATE tsc_ui_target)
>

Yes.

It does work if the direct consumer is a shared lib.
> That doesn't quite work if the consuming target is a static lib, that is
> then linked into an executable/shared lib.
>

Fair enough.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Konstantin Shegunov]

On Wed, Jan 19, 2022 at 9:56 AM Alexandru Croitor 
wrote:

> As far as I know, the referenced merge request only implements an
> abstraction for decorations, but does not implement the specific decoration
> of making sure a library is not discarded.
>

Yes, that's my understanding of the discussion as well. LINK_WHAT_YOU_USE
is supposed to do the right thing, however it's documented for ELF only,
and even then I wasn't able to make it work. That's why I started with the
g++ -u someSymbol  and /INCLUDE:someSymbol instead.

There are WIP changes that try to do that.
> See https://codereview.qt-project.org/c/qt/qtdeclarative/+/367149


Oh, I just took the easy (perhaps wrong) approach. I pushed from the
backing target to the consumer a cpp file, which is a dummy containing the
pointer thing. It just contains (Tsc.Ui is my module's URI):

extern TSCUI_API void qml_register_types_Tsc_Ui();

inline volatile auto tscUiTypeRegistration = &qml_register_types_Tsc_Ui;

I haven't tested it with static libraries, as generally I do avoid them,
but does work for for the shared one (as expected).
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Konstantin Shegunov]

On Fri, Jan 14, 2022 at 11:58 PM Ulf Hermann  wrote:

> The way we work around the issue in the generated plugin code is storing
> it in a volatile pointer. That's terrible and also not guaranteed to
> work, but it works in practice on all compilers we support. If you
> figure out a better way, please let me know.
>

I've had some "progress" with this, so I'm going to post some findings for
future reference.

It turned out that I observe this "surprising" (at least at first) behavior
as the g++ linker wrapper's  been patched upstream to implicitly pass
--as-needed, hence the library's not been marked with DT_NEEDED and
subsequently it isn't loaded.

Firstly, I've attempted to trick the linker by passing -u someSymbol, which
symbol is defined in the library to make it decide that the library was
indeed necessary, however with no success. Inspecting the symbols -
everything did appear correct, yet the linker still refused to mark it as
needed. Why that didn't work I don't know. For MSVC there's the
/INCLUDE:symbol which should work in the same way as gcc's -u according to
the documentation, but since I failed to make it work on linux I didn't
bother to test.

Secondly, I tried to set LINK_WHAT_YOU_USE in CMake, but for whatever
reason that also didn't work. Probably the reason is that I'm using ninja,
while it's supposed to be supported for Makefiles.

Thirdly, I passed --no-as-needed manually for the library, which did indeed
work correctly and marked the library for loading. Unfortunately it is
quite clumsy, especially if one wants to restore the default behavior, and
I imagine is somewhat error prone. On that note the CMake people have an
open ticket to provide decorating at link time which should cover such a
possible use case in the future[1]. Whether this gets in, remains to be
seen, but from a glance does seem somewhat advanced in the MR review.

Lastly, I provided my own dummy cpp file out of the library for the
consuming target(s) - where I do the pointer trick which Ulf mentioned.
This works, just okay, and the consumer doesn't need to care, which is the
whole point.
On that note, is there a specific reason I'm missing that qt_add_qml_module
doesn't do this, but instead requires the consuming target to ensure that a
symbol is accessed? Perhaps, provided there are no problems that I'd
missed, this could be an "improvement"; in the sense that it's not going to
be done manually anymore, and can be neatly integrated into the CMake
scripts.

Kind regards,
Konstantin.

[1]: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6769
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Konstantin Shegunov]

On Fri, Jan 14, 2022 at 1:58 PM Ulf Hermann  wrote:

> Indeed. And instead of the dummy symbol you can just use the existing
> type registration function for that. As you've found out, "just store
> it" is not enough. You have to "do" something with it. Sorry for being
> inaccurate there.
>

I must've not understood the documentation then. I was left with the
impression from the text that I'd put that whole store the pointer in a
volatile variable inside the library itself so to prevent the linker from
stripping the symbol. If that wasn't the intent then it's definitely a
misunderstanding on my part.


> The way we work around the issue in the generated plugin code is storing
> it in a volatile pointer. That's terrible and also not guaranteed to
> work, but it works in practice on all compilers we support. If you
> figure out a better way, please let me know.
>

Well, I'm by no means expert neither in QML nor in cmake, but what about
putting a target property for the QML module target and checking against it
from the cmake target that links against it, and if the property is set
generate a dummy c++ code to load a dummy symbol (I used a dummy version
tag for my experiments)? I'm not sure if that's even possible, but sounds
like some sort of a "solution".
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Konstantin Shegunov]

Well, I did find out what the problem is, and how to work around it. So I'm
posting for further reference to anyone that may stumble onto this.

On Fri, Jan 14, 2022 at 8:09 AM Ulf Hermann  wrote:

> No. You can store a pointer to the type registration function somewhere
> in order to prevent the linker from dropping the dependency.


Assuming I understood the documentation correctly - yes, but no, not
exactly anyway. After inspecting the symbols, they (in my case 'it') are
exported just fine, the library itself isn't stripped or anything.
The problem occurs because this object:

static const QQmlModuleRegistration registration("Tsc.Ui",
qml_register_types_Tsc_Ui);

isn't created at all. So this prompted me to dig a bit deeper, into the
application binary this time. It turns out that the linker in question
(msvc19) checks if you refer to symbols from external binaries explicitly,
and if you don't it silently drops the dependency on the library.
Thereafter the library isn't loaded at all, the static object isn't
initialized, hence the registration code isn't run at all. Which also
explains why calling it explicitly does work. In my case to make extra sure
I exported a dummy global symbol from the dll. If I don't do anything with
it - nothing works. If I print it with qDebug() in the application code,
the library is loaded and registration code and all works just as expected.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Konstantin Shegunov]

On Fri, Jan 14, 2022 at 8:09 AM Ulf Hermann  wrote:

> If you want the QML engine to find your module, you need to follow
> certain conventions around the paths.
>

My resistance to this is the self-containment of the given project/target.
I don't mind following the convention(s) for the paths inside the resource
file, this is perfectly fine. I'm taking an issue with supposing a specific
build directory structure is all. I don't even mind enforcing some
convention for the source directory, as this is something I can control
easily myself.


> You can create a separate CMake target just for your QML module if you
> like that better. Then you don't have to mess with the existing target's
> output path.
>

I don't want to mess with the output path at all. What I want is to have
some library that encapsulates the QML module (possibly with additional C++
code), which library I link directly already. I believe this is a perfectly
reasonable use case, I'm not attempting something very exotic, am I?

You should _not_ manually call the type registration. This is private
> API and it _will_ break.
>

Okay, noted, I'm not going to do it.

No. You can store a pointer to the type registration function somewhere
> in order to prevent the linker from dropping the dependency.
>
> I recommend the "custom directory layouts" section of
> https://www.qt.io/blog/qml-modules-in-qt-6.2


Thank you! I'd found your blog post but I must've skimmed through the
important content instead of taking the time I suppose. I will read it more
carefully this time and try to follow it.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Konstantin Shegunov]

On Fri, Jan 14, 2022 at 7:18 AM Ulf Hermann  wrote:

> Well, no, that doesn't work. If your module is called Tsc.Ui, then it
> needs to live in a directory called Tsc/Ui/, not TscUi/. That's the
> reason why the explicit file system import path doesn't work either.
>

Perhaps that's how it's supposed to work, but I'm not intending to mess
around with the target output paths in cmake. It simply makes no sense to
me.

I guess your linker ignored the linkage because you don't "use" any
> symbols from the linked library. You need to do the plugin linking trick
> with Q_IMPORT_QML_PLUGIN.
>

That doesn't work as it's not a static plugin. However this put me on the
right track (or at least I believe it is). Adding this to main():

extern void Q_DECL_IMPORT qml_register_types_Tsc_Ui();

qml_register_types_Tsc_Ui();

Did load the resources properly and I can see the QML module is loaded
(after also adding the import path to ":/")

So is this the "correct" way to do it with my setup with NO_PLUGIN,
then? I can live with the manual call, I'm just wondering if that's
the way.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML automatic type registration in a (shared) library

[Konstantin Shegunov]

On Fri, Jan 14, 2022 at 6:16 AM Ulf Hermann  wrote:

> Is the place where the module's qmldir ends up reachable via the QML
> import path?


I don't know. I have the generated qmldir in
the C:\Programming\tsc\build\debug\TscUi directory, which I think should be
correct. I haven't messed with the output paths at all.
The application goes to a neighboring directory
in C:\Programming\tsc\build\debug\TscApp

I can see that the .rcc contains a couple of cpp files corresponding to the
qml files I have: TscUi_Main_qml.cpp, TscUi_BottomBar_qml.cpp
and TscUi_qmlcache_loader.cpp, but the resource path doesn't include any of
this (perhaps correctly). In any case it does not include the qmldir either.


> If you're linking the library into the application, you may
> just add :/ to your import path so that it's loaded from the qrc file
> system right away.


Yes, that's the first thing I tried, however when it didn't work I
inspected the resource path:

QDir dir(":/Tsc");

const auto list = dir.entryInfoList();

for (const auto & entry : list)

qDebug() << entry;
Which produced only:
QFileInfo(:\Tsc\Core)


This is the other library, which exports C++ symbols into QML, and which as
mentioned works just fine. There's no path for this TscUi target, as I'd've
expected.

Be aware that some linkers just drop the linkage if
> they perceive it to be "unused", though.


Yes, perhaps this is the problem, but how do I fix this? What I currently
do in the application is to do nothing but link against:

qt_add_executable(TscApp

main.cpp

)


target_compile_definitions(...)


target_link_libraries(TscApp

PRIVATE Qt6::Core Qt6::Gui Qt6::Quick Qt6::Qml Tsc::Core Tsc::Ui

)


qt_add_resources(TscApp

"tsc_main"

PREFIX /

FILES

   main.qml

)

main.qml here I use just as an entry point that I load with:

QQuickView view;

view.setResizeMode(QQuickView::SizeRootObjectToView);

view.setSource(u"qrc:/main.qml"_qs);
The qml content is just a trivial instantiation:
import Tsc.Ui

Main {}


Otherwise, if the module ends
> up in C:/foo/bar/Tsc/Ui/, then you need to add C:/foo/bar/ to the import
> path.
>

Yes, that's where it ends up, at least that's where the qmldir resides.

The executable would be at the root of the application-specific import
> path if you were following the recommended directory layout.
>

I thought I was, but I'm not sure anymore. The application is placed in:
/TscApp
The library is in:
/TscUi

I've done nothing to change the default layout.

On Fri, Jan 14, 2022 at 6:42 AM Günter Schwann 
wrote:

> Hi,
>
> I did come across some similiar issue. And my solution was to add the
> resource as import path.
>

Hi,
I did try this, but this doesn't work as the resource file doesn't contain
the qmldir to begin with (see above).
I must've messed up something else.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] [Qt6] QML automatic type registration in a (shared) library

[Konstantin Shegunov]

Hi,
I've been continuing to experiment with the Qt6 QML capabilities and I hit
the following problem. I have a shared library with a couple of qml files,
but for some reason I don't get them installed and when I run the
application I get the module not installed error.

While trying to figure out what I did wrong I listed the resource and I
don't have a path for the library's module at all, so I imagine that'd be
the reason for the error. I do get a qmldir for a C++ piece of code (in
another shared library) fine, though, so I assume something's not correct
with my project, but for the life of me I can't seem to understand what.
Here's what I have for the problematic subproject:

add_library(TscUi SHARED

TscUi.h

TscUi.cpp # This is just a dummy, without it I don't get a .lib file at all

)

add_library(Tsc::Ui ALIAS TscUi)


set_target_properties(TscUi PROPERTIES

VERSION ${PROJECT_VERSION}

SOVERSION ${PROJECT_VERSION_MAJOR}

)

target_include_directories(...)

target_compile_definitions(...)


target_link_libraries(TscUi

PRIVATE Qt::Qml Tsc::Core

)


qt_add_qml_module(TscUi

URI Tsc.Ui

VERSION ${PROJECT_VERSION}

QML_FILES

Main.qml

BottomBar.qml

NO_PLUGIN

)


I've added the NO_PLUGIN, as I explicitly link against this, but for what
it's worth removing it doesn't seem to make any difference. In the
tscui_qmltyperegistrations.cpp I see the module being added, but no types
(in contrast to the code that exposes QML things from C++), is this correct:

Q_QMLTYPE_EXPORT void qml_register_types_Tsc_Ui()
{
qmlRegisterModule("Tsc.Ui", 0, 0);
qmlRegisterModule("Tsc.Ui", 0, 1);
}

Additionally when I configure I get the following warning:
CMake Warning at
C:/QtDesktop/6.2.2/msvc2019_64/lib/cmake/Qt6Qml/Qt6QmlMacros.cmake:694
(message):
  The TscUi target is a QML module with target path Tsc/Ui.  It uses an
  OUTPUT_DIRECTORY of C:/Programming/tsc/build/debug/TscUi, which should end
  in the same target path, but doesn't.  Tooling such as qmllint may not
work
  correctly.
Call Stack (most recent call first):
  C:/QtDesktop/6.2.2/msvc2019_64/lib/cmake/Qt6Qml/Qt6QmlMacros.cmake:1453
(_qt_internal_target_enable_qmllint)
  C:/QtDesktop/6.2.2/msvc2019_64/lib/cmake/Qt6Qml/Qt6QmlMacros.cmake:576
(qt6_target_qml_sources)
  C:/QtDesktop/6.2.2/msvc2019_64/lib/cmake/Qt6Qml/Qt6QmlMacros.cmake:627
(qt6_add_qml_module)
  TscUi/CMakeLists.txt:42 (qt_add_qml_module)

Manually forcing

qt_add_qml_module(TscUi

URI Tsc.Ui

...OUTPUT_DIRECTORY

Tsc/Ui

)disposes of it, but also doesn't seem to make any difference for my
registration problem.
If I load from the filesystem the files are parsed properly and
produce the expected result.

As you probably can tell from the paths, I'm using Qt 6.2.2 (from the
maintenance tool) on windows with msvc19.
Any ideas what I did wrong?

Thanks,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Gadgets in QML

[Konstantin Shegunov]

On Fri, Jan 7, 2022 at 10:46 AM Ulf Hermann  wrote:

> Sure, if you have something on gerrit let me see!
>

Not as of yet, but it can be arranged.


> However, value types with upper case names is something I probably won't
> allow.


Not up to me, but I have a licensing obligation to submit my changes to the
library, so consider it me fulfilling that.


> All our existing value types are lower case, and as they're so
> different from object types, this is a _really_ handy way to discern
> them already on a syntactical level.
>

Eh, personally, I'm not completely convinced, but that's way above my pay
grade.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Gadgets in QML

[Konstantin Shegunov]

On Thu, Jan 6, 2022 at 4:01 PM Konstantin Shegunov 
wrote:

> Yes, I'd intended to also provide:
>
> property var age: Age {}
>

Well, it does work, albeit I'm not convinced if it's better/efficient
enough.
In any case, if you're interested we can pick up on gerrit, just say so.

>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Gadgets in QML

[Konstantin Shegunov]

On Thu, Jan 6, 2022 at 12:54 PM Ulf Hermann  wrote:

> > Person is a `QObject`, the `Age` is a gadget I've exposed from C++.
>
> Then it's easy. If the "age" property is declared in C++, already today
> you can do the following (just like with font):
>
> property var person: Person {
>  age {
>  years: 12
>  months: 4
>  }
>
>  Simulation.onAdvanced: age.months++
> }
>

Yes, I'd intended to also provide:

property var age: Age {}


However, I just saw that my whole reasoning is moot, as gadgets appear to
be wrapped in a QObject anyway.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Gadgets in QML

[Konstantin Shegunov]

On Thu, Jan 6, 2022 at 12:46 PM Ulf Hermann  wrote:

> Well, yes, you need to declare the "person" property in C++ for now
> because you cannot have named value types. Once we get named value types
> (and some grammar fixes) you can do the following:


Person is a `QObject`, the `Age` is a gadget I've exposed from C++.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] Gadgets in QML

[Konstantin Shegunov]

Hi,
Thanks for the information.

On Thu, Jan 6, 2022 at 11:38 AM Ulf Hermann  wrote:

> It's not implemented yet, and there are some questions surrounding the
> desired syntax.
>

That's a given, no argument.


> We already have group properties. So, if you have a property font of
> some value type, you can already do this:
>

Yeah, but my beef with it is that I must derive from QObject for that,
don't I? I can live with not having notifications for the fields, is what I
mean.

I just have a stupid struct with 2-3 fields, that I'd love to initialize
within the document tree. I did some hacking around and did provide this
out of the parser (just ignoring the warning about registering value types
with capital letter), but I was wondering if I missed some subtle problem.
The whole idea of just having the god factory I find distastefulness and
somewhat harder to read/reason about. Currently this is what it looks like
for me:

property var person: Character {

name: qsTr("Person name")

age: Age {

years: 1

months: 0

}

Simulation.onAdvanced: {

age.months++

}

}
I'd've 'accepted' initializing from a plain JSON object as well, but
somehow I don't believe the QML parsing really works with these, plus
the quoting of the field names is a pain.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] [Qt6] Gadgets in QML

[Konstantin Shegunov]

Hello,
To be frank it's been an annoyance for me that gadgets can't be
instantiated the same way the QObject can within the QML document/tree. Is
there a good reason to disallow this or is it simply not implemented? Am I
missing some odd use/corner case why it's not a good idea?

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML_ATTACHED failing with ::QQmlPrivate not declared

[Konstantin Shegunov]

On Wed, Jan 5, 2022 at 11:54 AM Ulf Hermann  wrote:

>  would import a class called "QQmlRegistration". There
> is no such class in that header. It's a collection of macros. The
> correct form is .
>

Yes, I suppose, albeit you do ship .
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML_ATTACHED failing with ::QQmlPrivate not declared

[Konstantin Shegunov]

On Wed, Jan 5, 2022 at 11:23 AM Ulf Hermann  wrote:

> > On a side note, I was wondering, why these, contrary to other Qt
> > headers, don't provide cpp style naming?
>
> Where do you see the lack in cpp style naming? What name is wrong?
>

I didn't mean the name's wrong, simply that I read
 in the docs instead of  or
something akin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qthread from QFuture?

[Konstantin Shegunov]

On Wed, Jan 5, 2022 at 3:03 AM Scott Bloom  wrote:

> Its such a nice simple interface for launching a background thread and
> asynchronously being notified when it finishes 😊
>

The point is that it doesn't start a thread at all, not necessarily. The
threads are pooled and your job is queued for execution. When and on which
thread that happens is beyond your control, nor is it deterministic. It may
happen (almost) immediately or sometime later when the other pending jobs
have been processed. What you want is to kill a thread you don't own - you
haven't started, you don't manage and you don't know when or how it
finishes. Hence Thiago's advice - use QThread if you really *must* kill it.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] [Qt6] QML_ATTACHED failing with ::QQmlPrivate not declared

[Konstantin Shegunov]

On Mon, Jan 3, 2022 at 11:21 AM Ulf Hermann  wrote:

> > So, did I stumble on a bug?
>
> Including qqml.h instead of qqmlregistration.h should work.
>

Thanks!

Indeed, that does fix it cleanly for me.
Just noting: similarly I had 'undeclared qRegisterXXX' for the singleton if
I forward declare QQmlEngine and QJSEngine in the header and using
qqmlregistration.h. I imagine (haven't tested it) this is also going to be
fixed by including qqml.h.

On a side note, I was wondering, why these, contrary to other Qt headers,
don't provide cpp style naming?

https://codereview.qt-project.org/c/qt/qtdeclarative/+/383175 may have
> fixed this. It forward declares some of the types.
>

Possibly, my checkout was done from the root repository's dev
(init-repository), so the HEAD is a little bit behind this patch.

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] [Qt6] QML_ATTACHED failing with ::QQmlPrivate not declared

[Konstantin Shegunov]

Hello,
I've been doing some experimenting with Qt6's QML - C++ integration
(qtdeclarative @ 3d23912b0e, following the docs on providing attached
properties for a QML exposed class and I'd got the aforementioned compile
error.

I have the C++ class(es) in a dynamic library where in the CMakeLists.txt
I've added the absolute minimum:

qt_add_qml_module(TscCore

URI TscCore

VERSION ${TSC_VERSION}

)

The code which causes the error is very bare-bones; it basically
follows the documentation's examples. The classes are in a namespace,
but I don't believe that's the actual cause for the error.
Here's a very condensed snippet of the declarations:


#include 


TSC_BEGIN_NAMESPACE


class TSCCORE_API SimulationAttachedType : public QObject

{

Q_OBJECT

QML_ANONYMOUS

public:

... };

class TSCCORE_API Simulation : public QObject

{

Q_OBJECT

Q_DISABLE_COPY(Simulation)


QML_ATTACHED(SimulationAttachedType)

QML_UNCREATABLE("")

QML_NAMED_ELEMENT(Simulation)

... };

TSC_END_NAMESPACE

With a bit of sifting through the headers the error goes away if I include
QtQml/qqmlprivate.h. After that the integration part works just fine, the
objects are available and the attached properties accessible.

So, did I stumble on a bug?

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] (Q)Plugins and QML/Quick

[Konstantin Shegunov]

On Tue, Sep 14, 2021 at 9:02 PM Rui Oliveira  wrote:

> PS: For reference, I'm talking about what would be the QML/Quick
> equivalent of the Plug and Paint example:
>
>
> https://doc-snapshots.qt.io/qt6-dev/qtwidgets-tools-plugandpaint-app-example.html
>
> Where the plugins bring UI components with themselves.
>

Off the top of my head, if I were to do something akin, I'd push the
"container" quick item (e.g. the menu item in the 'plug and paint') through
the plugin interface, in which (plugin) I'd instantiate a QComponent and
then create the actual QQuickItem from it (QComponent::createObject). As
soon as the interactions get complicated this may be rather tedious and/or
error-prone though. You could attach "stuff" (e.g. signals and such) in the
plugin instantiated component (a.k.a. UI file) given that the correct
context's been provided. The actual plugin(s) you can expose through a
QObject adapter that bridges the QML world to the QPlugin/interfaces world.
I haven't tried it as such, but should work in theory.

Alternatively, it may be possible for you to derive from QQuickItem just
for the purpose of providing a QML context for runtime created items and
load your plugins/cast their interfaces, instantiate components/quick items
there; then expose the QQuickItem objects as  a property (or something),
possibly reparent them to your type's parent or even do the creation
directly with the correct parent.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Warning about QHash keys().toVector()

[Konstantin Shegunov]

On Sun, Jun 13, 2021 at 7:22 PM Kevin André  wrote:

> How can I avoid the warning in this case?
>

return QVector<..>(_actions.keyBegin(), _actions.keyEnd());

Should work, I believe.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QOpenGLWindow inside QSplitter horizontal layout ?

[Konstantin Shegunov]

On Fri, May 21, 2021 at 11:43 AM Benjamin TERRIER 
wrote:

> Regardless of QOpenGLWidget being better suited that QOpenGLWindow,
> shouldn't QWidget::createWindowContainer() work with any window?
>

Yes but typically you go to it when you integrate an external surface, say
one that you get from another library, some engine, or w/e.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Language and translator : Learning and questions

[Konstantin Shegunov]

On Sun, May 2, 2021 at 8:50 PM Nicholas Yue  wrote:

>   (2) I see some examples where a translator is removed before installing
> a new one, I comment that away and it still works, is there some issue
> lurking in the background that will cause a crash later ?
>

QCoreApplicaiton supports multiple translators and the translator is
deregistered automatically on destruction. The only problem here is
ideological: you not clearly declaring the QObject's lifetime. Keeping a
QObject in an external reference counted pointer wrapper can create
unintuitive and hard to diagnose dangling pointer crashes (i.e. losing the
reference while processing a slot on said reference), not to mention
wasteful. The QObject already supports weak pointer semantics internally
(a.k.a. the QPointer support). Much better is to revert to an owning
semantics - std::unique_ptr, QScopedPointer or the 'evil' raw pointer, or
simply to rely on the parent-child relationship.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] How to get QMainWindow derived window to show

[Konstantin Shegunov]

On Sat, May 1, 2021 at 1:22 AM Nicholas Yue  wrote:

>   but somehow, the MainWindow variety, I have not been able to
>
>
> https://github.com/nyue/QtQuestions/blob/main/Qt5/language_change/mainwindow/MainWindow.cpp
>

You're treating the main window that's instantiated as a `QWidget`.
Simply:
int main( ... )
{
   ...
   QUiLoader loader;
   QFile file(":/designer/mainwindow.ui");
   if (file.open(QFile::ReadOnly))
   {
  QMainWindow *mainWindow = qobject_cast(loader.load(&file));
  ...
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] L Word

[Konstantin Shegunov]

On Fri, Apr 30, 2021 at 6:48 PM Robert Hairgrove 
wrote:

> There IS the other forum at https://forum.qt.io/ ...
>
> It has lots of subforums which would seem adequate for off-topic content
> as long as it even remotely concerns Qt.
>
Yes, we are lenient, probably sometimes to a fault, but we have banned
overly disruptive people in the past, albeit not too often. The main
purpose of the forum is for users of Qt to help other users of Qt, much
like this list. We don't get a significant presence from the QtC employees,
however. We have "The lounge" though, you can vent there as much as you
want, as long as you're not actively insulting other people, obviously.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Language file resource loaded but UI not updating

[Konstantin Shegunov]

On Fri, Apr 30, 2021 at 9:42 AM Nicholas Yue  wrote:

> Hi,
>

Hi,

  What function do I need to call to tell the application that I have
> loaded a language file and to use it ?
>

You install the translator to the application. For newly initialized forms
- nothing more is to be done, however for forms that were already
initialized into a widget you need to call `retranslateUi()` (generated by
the designer) to have an observable effect.

Take a look here as well:
https://doc.qt.io/qt-6/qcoreapplication.html#installTranslator
https://doc.qt.io/qt-6/internationalization.html#dynamic-translation
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] L Word

[Konstantin Shegunov]

On Fri, Apr 30, 2021 at 1:56 PM Bernhard Lindner <
priv...@bernhard-lindner.de> wrote:

> Agreed. Why not configuring e-mail filters? This is what I would do. This
> is definitely
> better than leaving the list or getting angry and also better than waiting
> for the
> moderators taking actions for years.
>

Well, because ignoring a problem doesn't magically make it go away. Sure,
it's been done, many of us have ignored the mails/threads, but I'd say it
comes a point where you stand your ground. We did draft the CoC for a
reason, and I like that it's not enforced for arbitrarily minor
infractions, but then again, this is not a single instance or a slip, this
has been going on for a time. You could possibly argue that Peppe's
reaction is extreme, or passive-agressive, but the fact of the matter is
that it's also logical. If you push back but it ain't budging, you
typically look for a way around ... and in some sense avoiding a hostile
space (or one you perceive as hostile) is a very valid "way around".

Depends from the point of view. I have never felt insulted by Roland. And I
> can understand
> (and agree) his points many times.


Me neither, and so do I. But this isn't the issue here. The point is that
this isn't a society of two (you and me), but it's a larger group. I am not
into the SJW mentality, however you have to acknowledge the repeated use of
qualifications incompatible with the good tone and spirit of a civil
(technical) discussion. I will not bring in examples, of which there's
plenty, and you did acknowledge that.


> But it explains his frustration. And it explains why there a so few people
> who understand
> his (rudely presented) arguments.
>

I could have an explanation for any unacceptable behaviour without having
to validate it.
Hypothetical example: If, say, a person was abused by their parents, we
could argue it's perfectly understandable why they react violently and
abuse their spouse. This doesn't mean it's an acceptable (or lawful)
behaviour.

If you came from Mars I would surely tolerate much more misbehavior than if
> you came from
> Earth.
>

How much more? Sure, you can allow for some leeway in your decisions, but
sooner or later I'm going to have to face the music if I continue to act
the same way, right?
As always one draws the line somewhere, even if it may not be the same
place for everybody.


> This is a mailing list. People can be filtered and/or ignored on an
> individual basis.
>

You know this, and I know this, because we've been around long enough and
can make an informed decision. A person who just joins the list ordinarily
has little notion of how people are, and who's who. And that's in addition
to the obvious hijacking of the threads and arbitrary insults. When I come
with a question, I wouldn't want to be told that I'm stupid for not having
a "software engineering degree" (which seems rather important for Roland)
or read a book on how great VMS is, I'd rather be guided to a proper
solution for my problem. This is hardly unreasonable to ask, is it?

On Fri, Apr 30, 2021 at 2:15 PM Ulf Hermann  wrote:

> I would like a new mailing list that focuses on technical aspects, like
> "how do I use Qt in such and such way". Any question of licenses,
> general politics, the importance of functional safety, fruit baskets,
> etc can stay here on the old mailing list.


Agreed, although I acknowledge it's not always easy to disentangle the
questions of licenses and politics from the technical discussion, and these
topics do matter. But as it happens we all have our opinions, I just hope
we can share them as civilized people.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] L Word

[Konstantin Shegunov]

Ronald -> Roland

Sorry about the typo.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] L Word

[Konstantin Shegunov]

On Thu, Apr 29, 2021 at 11:27 AM Giuseppe D'Angelo via Interest <
interest@qt-project.org> wrote:

> I don't. And I don't send ultimatums or threats of libel lawsuits
> (seriously?) around, including to the moderators, in order to force them
> to make a move.


Well, us "script kiddies"* don't live under a rock, I'm rather convinced
Roland knows rather well how distasteful this statement is, not to mention
the probability of it being an empty threat ... which makes it even worse.
USA law is not directly applicable to EU citizens, and also general
compensation for law expenses don't apply as in the EU legal system. If he
had any intention of perusing such a lawsuit it'd need to be under the
jurisdiction of a court overseeing the place where the supposed offence had
happened. Also he would need to hire a layer who is versed in french law
and (probably) works on site. And to pile on, libel is a hard thing to
prove, as in many jurisdictions it requires proving malice and/or intent
(like in mine). All in all I'd consider this one very Ronald in character:
first have a speech, and another, then if that doesn't work (i.e. you get
ignored or challenged) insult somebody, if insulting somebody doesn't work
threaten something or someone. That's the very definition of how trolling
works and what it is, as you'd duly noted. So, as usual, if a troll
couldn't provoke someone then it escalates ...

* which Roland has used on multiple occasions to refer to people
frequenting this list, and in general to assert his "superior ways". I have
an email from the list sent by him dating back to 2016 where this
particular expression had been used.

Hence, I'll be removing myself from this list, effective immediately.
>

I do hope you reconsider, it's going to be a loss for you, but much bigger
loss for us.

You win. Audience claps. Curtains.
>

Yeah ... except that nobody claps ...

On Thu, Apr 29, 2021 at 1:05 PM Bernhard Lindner <
priv...@bernhard-lindner.de> wrote:

> The main problem isn't trolling.


Actually it is.

The main problem is: Roland comes from a completely
> different world. The world of functional safety.


If I came from Mars that still wouldn't give me the right to abuse, insult
or demean other people on this list.

On Thu, Apr 29, 2021 at 2:48 PM Tuukka Turunen  wrote:

>  Technically it is a trivial thing to remove someone from a mailing list.
> The challenging part is to decide when it is time to do that.
>

Well, my personal opinion is that the time had come some time ago.
Nonetheless, this issue festered over the years, and also not without some
fault of us (the users of said list). Many of just ignored the ramblings of
said person without a challenge to the turn of phrase or behaviour (the
"Ronald filters" is one such example). I must confess somewhat ashamedly, I
was relieved as he disappeared for some time, so I thought he'd finally
left. But apparently not ...

I second the request for Roland to be removed from the list, preferably
forever.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[Konstantin Shegunov]

On Sun, Apr 25, 2021 at 7:43 PM Ulf Hermann  wrote:

> For example named value types or (civilized) construction of value types
> in QML.


I have a question about that one. Is it feasible, in the technical sense at
least, that a value object be constructed from a JSON definition? Perhaps
supporting a QML-style constructor that maps the property names from the
QML side to the actual dynamic properties? Or do you have something more
streamlined in mind?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[Konstantin Shegunov]

On Sun, Apr 25, 2021 at 2:21 PM Giuseppe D'Angelo via Interest <
interest@qt-project.org> wrote:

> 22/04/21 20:38, Konstantin Shegunov:
> > Registering a struct/data class with the meta type system and/or
> > marshaling it over QVariant, just so it can be visible in QML isn't
> > that. Or things as natural (with C++) as having the UI raise some
> > encapsulated piece of data in a signal (say some struct, say QColor or
> > QVector3D) which the backend responds to isn't it either.
>
> I think I'm missing some context: when you say "isn't that" or "isn't
> it", what "that"/"it" are you referring to?
>

By that/it I specifically meant that I don't consider (re)wrapping already
encapsulated and self contained piece of data (e.g. one coming from the
backend to UI or vice versa) specifically for the purposes of it being used
only in the UI, a part of the business logic, a presentation layer or some
other sort of application design layer that's worth doing. This I consider
an adapter, so you tie two APIs/interfaces that are not compatible and
you're just stuck suffering with it ... which may be necessary sometimes,
no doubt, but in my opinion shouldn't be, if you're thinking about the Qt
codebase as a whole. Think of my statement like: "we are forcing the user
to write a middle man between the QAbstractItemView and QAbstractItemModel
just because we decided that's the right way ..."

"Controller" is an extremely overloaded word. Could you please clarify
> what design are you referring to?
>
> I don't understand some of your points, like "UI that's completely
> decoupled from the business logic". What does this mean -- shouldn't the
> business logic be the one decoupled from the UI? Are you talking about
> UI testing (via a mock business implementation)?
>

Right, I can see how this could've happened. No, I wasn't talking about
testing. I meant it in the sense of the MVC. I have UI, I have models
and/or possibly backend objects, so I have this entity whose main
responsibility is to possibly instantiate some objects, connect the two
mentioned layers, ideally keeping the coupling between them in one
manageable spot, and maybe implement at most some validation/simplistic
logic about the data transfer. Now, with QML you can't have this, because
the scene instantiation happens behind closed doors, so to speak, and you
don't have access to it after the fact (beside some nasty hacking with
findChildren<> and/or relying on the private API). This is my "technical"
beef with it, the idea I like. Currently, I have to expose said
"controller" object, or some other object I've designed specifically for
the purposes of routing the data to and fro without actually having to.
This obviously goes to the fact that the quick scene simply has no C++
interface, nor can you control the way it's instantiated. There's the
QComponent::createObject, sure but how do you "reach in" the scene to add
your newly created quick item?

Sure it is! I said it myself, it's typically not just one magic
> do-it-all layer, but multiple layers. In those layers you
>
> * adapt business logic datatypes into Qt datatypes;
>

My argument is that you adapt said datatypes even if they're very Qt-ish
and very much in line with what QML should eat easily. Instead we have this
superfluous re-wrapping just so it is possible to have them accessible.
Moreover, the UI couldn't possibly populate such a type directly, could it?
(going back to the factories for QVector3D, and the QColor being actually a
string in QML).


> * expose the relevant business logic in QObjects;
>

Yes, everything is QObject, even if it may not need to be necessarily,
which is one of my arguments. I mean, one could live with it, but in my
ideal world, I wouldn't want to.


> * write Qt models wrapping business logic datasets;

* create custom UI components;
>

This is perfectly fine and expected no matter if you're doing widgets, QML
or whatever else.


> * write state machines and what else is necessary to drive the UI based
> on the business logic state;
>

Most of the state machines that I'd seen in QML code were done in the UI
part, just sayin'. You could, obviously, do it from the C++ side, but many
people don't, as it's easier to define it in QML. Which is in conflict,
somewhat at least, with your comment that QML forces you to have the
separation between UI and business.


> The important message here is that such
> adaptation / UI logic layers do exist in any non trivial application,
> and the fact that from QML you just can't "just" reach into business
> logic, you need to jump through the languag

Re: [Interest] Guide me through the Qt offerings for GUIs

[Konstantin Shegunov]

On Sat, Apr 24, 2021 at 2:42 PM Rui Oliveira  wrote:

> Audio applications, like DAWs solve this by just allowing VST developers
> to bring their own UI at their will, on a separate window. But I have an
> app I want to create a space for the plugin/module to display it's
> controller for it's own hardware... How?
>
You can do that both with widgets and with QML, no one is saying you can't
return a Quick item from a plugin, which is after that exposed to the main
QML interface (by adding it to the scene as necessary). Should take
approximately the same effort as doing it with the widgets or thereabout.
It is also possible in a client-server architecture, however the "how" will
depend very much on the requirements you have. Servers come in different
flavours as well, it's not mandatory to stick to HTTP, but it may be
beneficial in some cases. Personally, I don't like the idea of streaming
the UI related stuff over the network (e.g. with WebGL), but again this'd
be a decision made based on the actual requirements of your project.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[Konstantin Shegunov]

On Thu, Apr 22, 2021 at 7:19 PM Giuseppe D'Angelo via Interest <
interest@qt-project.org> wrote:

> You should create a C++ layer (call it a "presentation" layer) that sits
> between your (possibly non-Qt) business logic and the UI. That layer
> contains stuff like item models, QObjects that expose the relevant
> business logic APIs, type wrappers, and so on.
>

Registering a struct/data class with the meta type system and/or marshaling
it over QVariant, just so it can be visible in QML isn't that. Or things as
natural (with C++) as having the UI raise some encapsulated piece of data
in a signal (say some struct, say QColor or QVector3D) which the backend
responds to isn't it either. As a matter of fact, how do you tie your
existing backend to QML? Say we have this nice encapsulated UI that's
completely decoupled from the business logic, how do I tie a specific
object from the Quick scene and connect the notifications back to C++? I
can't do it from the business logic (i.e. controller side), I have to
expose the backend to the QML engine and do it from there, am I wrong?
Basically you say it's fine that the UI drives the controller (incl. object
creation)?

We can agree on the principles, gladly, but this is really a gross
oversimplification of the problem.

While building this layering may be super tedious (YMMV), in the long
> run, it makes your application more robust, not less. The fact that QML
> _forces_ you to have this stuff becomes somehow a good thing.
>

Forces you? Do you mean, perhaps, that JS is somehow not supported, or
maybe that Component.createObject is somehow hidden and/or inaccessible?

On widgets, well, raise your hand if you didn't at least once connect a
> QPushButton to a slot declared in the widget that contains the button,
> and perform some business logic from there (yay business logic in the UI!).
>

Yes, it is done, and not without an honorable mention of the documentation,
where the view-controller idiom is used extensively.  But then, raise your
hand if you at least once didn't use an `if` (or some other JS piece of
code) in a QML file. I can pull out for you numerous cases of it being
done, probably too numerous to count even in the examples. Shooting
yourself in the foot is not restricted to one language or another, nor to
the technological solution in use is my point. You can make a holy mess of
any piece of code on any language you choose, and QML certainly doesn't
force you to do anything you don't *really want to*.

In other words, being "entirely" in C++ has also its downsides.
>

Most certainly. One of the major downsides is it being much more complex
and unforgiving, which doesn't necessarily mean it's better.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[Konstantin Shegunov]

On Thu, Apr 22, 2021 at 6:10 PM Rui Oliveira  wrote:

> Basically we're coupling the whole backend to the GUI framework.
>
You always have some coupling between the logic and the GUI, no matter what
you use, but I do get the gist.

> I'd prefer to write C++ than to learn Loaders and whatever else there
> is... But seems that people do love QML a lot (again, shouts out to KDE).
>
Funny that you mentione the `Loader`, which is sort of no-op item from the
C++/desktop dev perspective. What I mean by that is that the `Loader` is
the archetype of the 'QML engine is really a glorified object factory',
which I mentioned. The only reason it is there is to delay the creation of
a QtQuick item. This would've been rather trivial to do in a C++
environment, you just create and add the object to the scene whenever it's
needed, no need to wrap this in a `QObject`, but not so trivial to do if
you want to leverage it in a 'declarative' (or rather JS) context. Note
that the component doesn't go away too, because at some point you may want
to unload said scene item, which instead of just deleting, being the
obvious choice, you set the relevant property to the loader, which detaches
it from the scene.

> Opinions, I guess.
>
I don't see anything wrong with that, as long as we have a civil discussion
(not a troll fest) about it.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[Konstantin Shegunov]

On Thu, Apr 22, 2021 at 11:56 AM Volker Hilsheimer 
wrote:

> * declarative vs imperative APIs
>
> Many widget classes don’t have a declarative-friendly API. Plenty of
> widget properties have side effects on other properties, so the order in
> which properties are set matters. That doesn’t work well in a declarative
> world.
>

This is hard to agree to. The widget designer outputs XML, which is as
declarative as you can get. While QML's syntax is nicer you have the same
argument going for it (e.g. the dreaded circular bindings).


> * weight
>
> Widgets are heavy, often very complex objects. They often come with all
> bells and whistles. QPushButton always has the data structure to support
> QPushButton::setMenu, even if probably <1% of buttons out there ever use
> that feature. That’s ok on desktop machines, it’s not ok on embedded
> systems.
>

Eh! I agree for the imperative painting and not being able to batch and
render efficiently, but you really think that a QWidget window has more
objects than a QtQuick scene? I will be hard pressed to believe that.
Moreover with the widgets you don't need everything to be QObject (or in
some cases Q_GADGET), or wrap everything in QVariant, or introduce global
factories like `Qt.vector3d` just due to the fact that you're working on a
lower level and you don't have to battle with the JS engine. I will concede
that the widgets were conceived in another age so they have a lot of
shortcomings, but 'heavy, often very complex objects' doesn't seem to be
it, especially if you're drawing a parallel to QtQuick. Anyone can go and
see the internal implementations of the QtQuick items if he/she doesn't
believe this.

* complexity and hard to customize
>
> Inheritance and reimplementing are nice concepts on paper and works great
> if you build your own custom widget from a reasonably abstract base class.
> But if you have ever tried to subclass e.g. QTreeWidget to modify how
> certain interactions work, then you know how hard it can be to not break
> the complex states that the default implementations rely on.
>

Yes, somewhat true. But this does go to the time the widgets API was
designed. It could as well have been using more aggregation and more
flexibility then (not placing blame). For example it could've been possible
to designed the tree widget to accept delegates that are not directly
painting, but rather are issuing jobs for the (hypothetical) painting
engine. And there could've been an effort to aggregate complex controls
instead of deriving (QComboBox comes to mind) where customizing elements
could've been done through delegates, but it is what it is.

So, making widgets work in a declarative, GPU friendly world where ease of
> customisation is more important than standard look’n'feel would have
> required many changes to widgets. Those would have been impossible to make
> without invalidating or breaking a lot of code out there, and still not
> given us the UI components we would have needed.
>

You should mentioned that by 'declarative' you mean the way you want to
render in batches/jobs (nothing wrong with this, btw.). The widgets (the
forms specifically) are declarative enough, the problem is that when you
start painting them you end up constantly setting and resetting the
painting state.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Guide me through the Qt offerings for GUIs

[Konstantin Shegunov]

On Thu, Apr 22, 2021 at 4:59 PM Jérôme Godbout  wrote:

> I wonder if it would be possible to totally declare the QtQuick scene from
> C++ without any Qml files actually, with Qt6 you got C++ binding and the
> Qml is compiled to C++ anyway. Maybe I miss something but it could be
> possible to actually only write C++ to create the actual scene?!
>

It will have been (even in Qt5) if the classes were public. In the end the
QML engine is really a glorified object factory. There are other problems
with that though, one such example is the tree control: GPL/Commercial for
QtQuick, while with widgets you get that directly with the same license as
the whole library (there are other such cases too, if I'm not mistaken) ...
and the mentioned already "native" look'n'feel.

I would not actually do this myself but it might attract some user that are
> scare of declarative
>

Many of us avoid it not because we are 'scared' as such, but because of
other more practically-relevant reasons.


> I stop using QWidgets a few years ago and I don’t miss it a bit, haven’t
> seen anything I could not achieved into Qml yet, some are a bit trickier
> than they should but in the end prototyping and modifying the GUI is so
> quick, I often make the change live when I’m working with my graphic
> designer and KDAB GammaRay (just need to apply those change after).
>

Well, I can build a nuclear power plant at home - probably I can achieve
it, but the fact of the matter is, should I? There are a couple of
considerations here. Firstly a lot of code is already written with the
widgets and even with best practices it's generally not trivial to do a
'face-lift'. Secondly, QML fails to sell its point to desktop devs due to
its C++ integration being a great PITA already. Anything that's non-trivial
ends up with (a) huge boilerplate wrapper(s). And while graphics
performance does matter, it's not typically the driving force on desktop,
where usually we value convenience over performance (on desktop you rarely
are pressed for resources). In fairness, exposing the property bindings
natively to C++ is a step, no doubt about it.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML bug?

[Konstantin Shegunov]

On Fri, Apr 16, 2021 at 2:26 PM Alexander Dyagilev 
wrote:

> Hello,
>
> Hi,

> Why are not they defined? These are ids of items defined in the same qml
> file.
>
Could you try binding the property in a `Component.onCompleted` handler?
Does that solve it?
(My suspicion is that all the dependent items hadn't been yet instantiated
at the point of the binding).

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtQuick over Qt3D (Qt 5.15)

[Konstantin Shegunov]

On Thu, Apr 1, 2021 at 8:40 AM Paul Lemire  wrote:

> Hello Paul,
>
Hello,

> It sounds to me like Scene2D is what you want as it renders a QtQuick
> scene into an offscreen texture which can then be applied to a Qt 3D mesh.
> Unfortunately it can only be used from QML.
>
> That being said, nothing is stopping you from having 90% of the Qt3D code
> in C++ and just having a small part in QML that essentially only
> instantiates your 3D Scene and the Scene2D and povides the 3D scene with
> the Scene2D texture. I think that would be the easiest.
>
Yes, that's what I've been using to "guide me through". And I do
acknowledge I can use it from QML, but there's also this thing:
https://bugreports.qt.io/browse/QTBUG-90411

> If you want to do it purely in C++, another approach (but more complex to
> set up and that would have to be tested) is to use a QSharedGLTexture to
> tell Qt3D about an existing OpenGL texture by textureId. This means using
> the Qt shared OpenGL context, and manually rolling your own
> QQuickRenderControl to render QtQuick into a QOpenGLTexture, and then
> providing the QOpenGLTexture's id to the QSharedGLTexture. You'll also need
> to ensure proper synching using fences (QWaitFence/QSetFence) to ensure
> that Qt3D is not trying to render while the the shared texture is being
> updated. This would be more or less similar to one of the manual test we
> have in Qt3D
> https://code.qt.io/cgit/qt/qt3d.git/tree/tests/manual/sharedtexture?h=5.15.2
>
> I hope that helps,
>
Indeed, thanks! Still, it doesn't seem there's a way I can hook into the
frame graph and just have anything drawn directly on the screen, is there?
The best I could do, as far as I can tell, is to have an ortographic camera
looking at a quad, which I can texture with whatever comes from the QtQuick
scene, it appears (i.e. what Florian Blume's code does here:
https://github.com/florianblume/Qt3D-BackgroundImage). Is this correct?

On Thu, Apr 1, 2021 at 11:15 AM Oleg Evseev  wrote:

> By the way in Qt 5.14 there comes an option to use Scene3D as underlay
> without FBO:
>
> https://doc.qt.io/qt-5/qml-qtquick-scene3d-scene3d.html#compositingMode-prop
>
> I did tried this, but encountered with a problem when using together with
> OnDemand:
> https://bugreports.qt.io/browse/QTBUG-82861
>

Indeed. It does seem bugs reports've accumulated for Qt3D over time. View3D
also segfaults (the example) for some reason.

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QtQuick over Qt3D (Qt 5.15)

[Konstantin Shegunov]

On Wed, Mar 31, 2021 at 6:32 PM  wrote:

> Hi Konstantin,
>

Hello Eric,


> Welcome to the hell that is 3D in Qt.
>
>
>
> To understand the problems that you are facing, you need to know a little
> history. Other users can perhaps provide additional insight or correct any
> errors, since my recollection and understanding of these matters is
> probably not perfect.
>

I know a little bit about the history. I've been hanging around Qt from the
4.5 days, or thereabouts.

Qt3D was introduced in 2016 to much fanfare and was going to be the primary
> 3D solution for Qt. The idea was that Qt3D would provide a high-performance
> core capable of modern 3D graphics. Then, in 2017, Qt Co. had a
> philosophical shift and realized that rather than offering 3D functionality
> through LGPL/C++ (which could also be used by those darned open-source
> users), they could make more money in the short-term by locking in John
> Deere/others into subscription-based commercial licensing to display their
> little tractor animations. Because of the KDE agreement, they could not
> simply modify the license on Qt3D going forward, so they had to start from
> scratch with a new GPL/QML package: enter QtQuick3D.
>
>
>
> The result was that Qt3D was mostly abandoned in a half-finished and
> unpolished state and development efforts shifted to QtQuick3D. In doing so,
> Qt Co. shot themselves in the foot in the long-term, of course, since, as
> you have probably noticed, in the absence of a public C++ interface,
> QtQuick3D is not particularly useful for "complex use cases". As a result,
> "complex users" have either stuck with native OpenGL or have bashed their
> heads on the wall trying to adopt Qt3D, and the dream of modern 3D graphics
> in Qt applications has died.
>

While I share some or more of the sentiments expressed, I really don't want
to get into this. The Roland thread(s)™ are epic enough and I've been
keeping quiet on purpose. (Note: Qt3D is a project of KDAB's, not of QtC's
making)


> This brings us to your use case. As you have noticed, the Qt3D examples
> are outdated and many are broken. This is by design to discourage use. In
> Qt6, you can’t even use Qt3D unless you build it from source (not sure
> about the state of the Qt3D examples, I’m sticking with Qt5). QtQuick3D
> (like QtQuick as a whole) has no public C++ interface, even though exposing
> the internal classes would be trivial. This is also by design to lock
> commercial users into QML.
>

Even if this were true, which is what I assume Peppe's reacting to, it's
really beside the point. I asked a very specific _technical_ question, I
don't intend to get into the politics of it at this time.

So what to do? The answer depends on whether your 3D needs fall into the
> category of "complex use", e.g. more than little tractor animations. If
> not, and if you're okay with GPL/commercial licensing, you're honestly
> probably better off switching to QtQuick3D.
>

Yes to the first, no to the second. Or to phrase it another way, it's a pet
project for which I'm evaluating Qt3D and QtQuick. That's why I was so
specific about my requirements. I don't make money of it, so the commercial
offering is out of the question. I'm poor, so to say. As for GPL I
generally dislike the philosophy of it, it's basically like the commercial
licenses, but from the other side. What I write to be used as open source
(which isn't that much, but still ...) I license under weak copyleft
licenses. That's how I do it, that's what I like, that's what I want to use
(i.e. the LGPL).

Otherwise, you have a few options. If you’re completely committed to Qt3D,
> but not completely committed to QtQuick for your overlay, you may want to
> use Dear ImGUI on top of Qt3D (Lazlo has a mostly working example on top of
> Qt3D: https://github.com/alpqr/imgui-qt3d). You can also use Dear ImGUI
> directly on top of RHI for Qt5.12+ (https://github.com/alpqr/qrhiimgui).
> I haven’t dug into the code, but you may be able to repurpose these samples
> to instead blit/render QtQuick over top of Qt3D/RHI, without the need to
> create a billboard.
>

This is useful, thanks! I'm not committed to any of it, but I'm going to go
through the code to see if I can indeed get some idea of how to do what I
want to do. I took a peak at ImGUI, but honestly, I'm not really convinced.
Still I'm going to consider the suggestion, so thank you for that too!

I would seriously ask yourself whether you want to be developing a new
> application with Qt3D, however. If you’re doing anything more than
> displaying a model or two, there are various open source 3D graphics
> engines/frameworks under active development with better performance and
> features that you can embed into a Qt widget (I’d suggest Magnum, Ogre, and
> BGFX, depending on desired level of abstraction – all have working ImGUI
> overlay examples).
>

Yes, I've used OGRE into a Qt widget before. Actually it was before Qt had
QWindow and QWidget::createWindowContainer, so hackin

[Interest] QtQuick over Qt3D (Qt 5.15)

[Konstantin Shegunov]

Hello,
I want to overlay a QtQuick UI over a Qt3D scene I'm having, however (here
comes the "but") I want to do it from C++. I don't want to get into
instantiating Scene3D at all, I want to drive the Quick scene from Qt3D,
not vice versa (i.e. I don't want to render the 3D content to an FBO, and I
don't intend to depend on the QML engine to setup the Qt3D parts).
Sound(ed) like a simple-enough task at first, but I'm having the worst time
figuring it out.

To start, I've set the Qt3D things up and I can show my mesh. For the
second part, I read a lot of the sources around Scene3D, Scene2D and Qt3D
examples but it doesn't appear this "obvious" thing to do is covered
anywhere, notwithstanding half the Qt3D examples being broken (either
segfaulting or not building at all).

I was initially intending to get some ideas from Scene3D, but it appears it
works directly with the private classes for one, and for two it forces
synchronous rendering that's driven from the quick scene ... and as a
typical QtQuick item it doesn't expose a public C++ class ...
If I missed something there, please feel welcome to correct me.

So after the next batch of sifting through Qt3D's own internals, the
renderer plugin and such, I am relatively convinced the only reasonable way
to do this is to render the UI offscreen to a texture and to just slap that
texture on the screen on each Qt3D frame. Is this correct? If that's so,
let's say I can render the quick scene to a texture, how do I go about
putting it on the screen after the framegraph's been executed? I couldn't
see a framegraph node that'd do that for me. Am I to write my own? Is it
the case that I need to create a "fake" quad (i.e. a billboard) that I must
reorient together with the camera? I saw in one of Florian Blume's
repositories that he uses a second camera and another branch in the
framegraph to put a background image in. Is this the way to do it, or is
there some better way?

Additional question(s):
Do I spin my thread (which I sync manually) for rendering the quick scene?

Thanks for any and all pointers.

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] is it ok to push audio on a background thread, not a timer?

[Konstantin Shegunov]

On Wed, May 20, 2020 at 2:13 AM David M. Cotter  wrote:

> is it possible i'm just using QThread wrong?  and it HAPPENS to work fine
> on mac but fails on windows?
>
> is this blogger really revealing the ONE TRUE NATURE of QThread:
>
> https://mayaposch.wordpress.com/2011/11/01/how-to-really-truly-use-qthreads-the-full-explanation/
> ?
>

The one true nature? Probably not, but the rather the habitual way of
threading an event driven piece of code (like some sort of QObject
controller class, a socket or w/e). One can derive from QThread, obviously,
for an imperative piece of code (like numbercrunching), however in case
you're going to use a worker object that's just not quite necessary (i.e.
just use composition). I've seen people derive from QThread, and initialize
objects in the run() method, and then call exec(), but as far as opinions
go, mine is that this is a poor choice of approach (correct if it may be).

Concretely, touching QAudioDeviceInfo::availableDevices() from a thread is
probably a race condition, as the function isn't marked as thread-safe. If
you really need to use its result, I'd say you'd need to pull the info
while you're in the main thread (say in your constructor) and then delegate
it on. However, a thing, which's worrying somewhat, is
that QAudioOutput's methods aren't marked as reentrant (unlike QObject's)
so unless that's a miss in the documentation you're not going to be able to
use it from a separate thread at all.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Why doesn't my model filter update?

[Konstantin Shegunov]

On Tue, Feb 18, 2020 at 11:20 PM Matthew Woehlke 
wrote:

> On 18/02/2020 15.35, Matthew Woehlke wrote:
> I wonder if anyone else can spot it? ;-)
>

Without knowing anything about the code at all, my best guess based on a
very quick glance would be the range for the dataChanged is wrong.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt widget parent and child visibility

[Konstantin Shegunov]

On Mon, Dec 16, 2019 at 8:13 PM Thiago Macieira 
wrote:

> On Monday, 16 December 2019 05:58:52 PST Ramakanth Kesireddy wrote:
> > Is there any means to hide parent and then show child widget in Qt 5.13?
>
> No. All child widgets are displayed inside the parent. If the parent is
> not
> visible, then the children aren't either.
>

Could making the child a native widget work? (just curious)
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Expected event execution order in this multi-thread application

[Konstantin Shegunov]

On Mon, Sep 30, 2019 at 6:07 PM Ola Røer Thorsen  wrote:

> What's wrong with the sleep functions in particular?
>

They're uninterruptible. In 99.9(9)% of cases there's a better way to
suspend a thread for some time than unconditionally putting it to sleep.


> Are they worse than calling for example unistd.h's "usleep" or
> "std::this_thread::sleep_for(std::chrono::milliseconds(x));"?
>

No.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Connect to signal QProcess::finished on MSVC 2017

[Konstantin Shegunov]

On Wed, May 15, 2019 at 4:37 AM jlk  wrote:

> However, on MSVC 2017, I've now read about a bug (in the
> C++ standard requirements, I guess) that prevents qOverload from
> working. Could someone suggest a workaround for my case?
>

If you can't use qOverload or QOverload<...>::of(), then you have only two
other options. Static casting the signal to the exact method type, or
specifying the template parameter explicitly.
Either:
QObject::connect(process, static_cast(&QProcess::finished), receiver, slot);
or
QObject::connect(process,
&QProcess::finished, receiver, slot);
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] My first 5 years with Qt and 2 suggestions

[Konstantin Shegunov]

On Fri, May 10, 2019 at 4:07 PM Shawn Rutledge  wrote:

> So “stable” just means old in practice, and thus uninteresting for
> developers.


Old AND stable. There are specific criteria the debian project uses to mark
a package as stable. Old may not mean stable, but usually stable means old
(although not always).


> “Guix follows a so-called 'rolling release' model, so you can run guix
> pull at any time to get the latest and greatest bits of free software.”


Debian does that with the testing flavour. If you want the latest and
greatest without making much of a compromise on the stability that's the
one. (This is what I use, there are also "unstable" and "experimental"). An
argument for both approaches can be made either way, but the fact of the
matter is that the testing flavor gets Qt (re)packaged pretty quickly after
its release.


> But Qt 5.11.3 … ugh.  https://www.gnu.org/software/guix/packages/Q/  One
> would think if their goal is a rolling release that they probably have
> tried to automate building newer stuff and trying to upgrade continuously.


That's also the version I have on the debian testing I run. It may be that
5.12 is considered to buggy to (re)package from experimental to unstable to
testing, but there may be other (significant) contributing factors. Here's
what I get from the repository (some architectures and versions cut):

stretch (stable) (libs): Qt 5 core module
5.7.1+dfsg-3+deb9u1: amd64 arm64 armel armhf i386 mips mips64el mipsel
ppc64el s390x
buster (testing) (libs): Qt 5 core module
5.11.3+dfsg1-1: amd64 arm64 armel armhf i386 mips mips64el mipsel ppc64el
s390x
sid (unstable) (libs): Qt 5 core module
5.11.3+dfsg1-1: alpha amd64 arm64 armel armhf hppa hurd-i386 i386
kfreebsd-i386 m68k mips mips64el mipsel powerpcspe ppc64 ppc64el riscv64
s390x sh4 sparc64 x32
experimental (libs): Qt 5 core module
5.12.3+dfsg-1: amd64 arm64 armel armhf hppa hurd-i386 i386 kfreebsd-i386
m68k mips mips64el mipsel powerpcspe ppc64 ppc64el s390x sh4 sparc64 x32
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Issue with QSqlModel and QSortFilterModel

[Konstantin Shegunov]

On Thu, Apr 18, 2019 at 12:25 PM Bernhard Lindner <
priv...@bernhard-lindner.de> wrote:

> Did you write an issue tracker entry about that?
>

No, I haven't written a jira ticket, although I didn't get which issue you
meant by "that".
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Issue with QSqlModel and QSortFilterModel

[Konstantin Shegunov]

On Thu, Apr 18, 2019 at 12:41 AM Scott Bloom  wrote:

> Any thoughts?
>

Hi!
As a matter of fact I was facing a similar issue for my current project,
but in my case I need to fetch the data over the network, from a DB as
well, but one that I don't have direct access to. You can imagine I
struggle(d) as you with how to orchestrate the whole thing. Unfortunately,
what I concluded is that the model framework is designed in such a way that
it's not possible out of the box to run high-latency operations. To give an
example - take QAbstractItemModel::canFetchMore and
QAbstractItemModel::fetchMore, on the one hand it's well intentioned to
allow the underlying data layer to fetch data incrementally, the problem is
the assumption(s) that are made, namely that fetchMore is going to return
when the data is available (i.e. populate the data synchronously),
otherwise you just stick to the default implementation, which does nothing.
There's no fetchMore and a fetchedMore counterpart and so on ... Note,
also, that the model is often not well suited to hold the actual data,
except in the simplest of cases.

What I ended up doing in the end is to "invent" a real data layer, to which
my derived model (think QAbstractItemModel implementation) is a proxy. The
data source signals the changes and the model just (re)translates the
(internal) identifiers into QModelIndex instances for the view. This comes
with its own battery of problems and is quite a lot of work, but it seems
to work well. Bear in mind that when I start-up the model and the data
source, I stream (in manageable chunks) all the data for the model to the
client, and then handle the changes as unsolicited notifications from the
network peer (i.e. the server). As far as my research into the issue goes,
depending on the internal framework for incremental loading is futile. The
model-view framework doesn't care about partial datasets, it only cares
that the children data for a given parent index is loaded; it has no notion
of paging the data.
What was somewhat challenging was to batch-up the inserts/updates/deletions
that are signaled from the data source, because the model expects them to
be grouped by parent, which naturally isn't always the case; in the end
there is some boilerplate to organize that as well. As for the filtering
part, currently I have a couple of sort-filter proxies, but as work goes
along I'm planing to wrap up my own filter proxy that has multiple filter
fields. For large(-ish) datasets the multiple model index remappings eat a
lot of time and memory.

I hope that helps you a bit

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Signals, slots before the event loop starts?

[Konstantin Shegunov]

On Thu, Apr 11, 2019 at 4:57 PM Jason H  wrote:

> Update on this:
> It didn't work. I called it, nothing (discernable) happened. Got a bunch
> of serial port not open errors
>

Something else's amiss. Here's the test-case:


#include 

#include 


int main(int argc, char *argv[])

{

QCoreApplication app(argc, argv);


QObject::connect(&app, &QCoreApplication::aboutToQuit, [] () -> void  {

qDebug() << "Goodbye cruel world!";

});

QMetaObject::invokeMethod(&app, &QCoreApplication::quit,
Qt::QueuedConnection);


return QCoreApplication::exec();

}

Which produces (as expected):


17:05:37: Debugging starts

Goodbye cruel world!

17:05:38: Debugging has finished
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Signals, slots before the event loop starts?

[Konstantin Shegunov]

On Thu, Apr 11, 2019 at 3:48 PM Jason H  wrote:

> What is the best way to do that? I think in the past, I used a 0ms timer,
> but that always feels janky.
>

QMetaObject::invokeMethod(qApp, &QCoreApplication::quit,
Qt::QueuedConnection);

is my preference.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Parsing data from serialport

[Konstantin Shegunov]

On Thu, Apr 4, 2019 at 6:42 PM Jérôme Godbout  wrote:

> You jus did the same loop into your slot, the function I did made can be
> called as slot to the connect you just told, I agree the
> serial_port->waitForReadyRead(5); is not necessary, just often the
> transmission have partial or bunch of data by small burst (USB VCOM) and
> was handy for me, but it is not ncessary in any way.
>
A similar loop yes, however your loop goes until there's something to read
on the port, mine is run a few times only when the port already has some
information pending in its buffer. The QSerialPort class already knows if
data has arrived and buffers it*, so what would be the point to loop over
the port when there's no data? When you talk with someone do you ask every
5ms if [s]he has something to say to you? I really doubt it. You'd normally
just wait for something to be said to decide if and how to respond to it.

> Side note: ReadLines made it less general purpose, you will need a
> protocol that use endline to signal end of message which is not always the
> case.
>
Involving realistic protocol handling is another kettle of fish. It would
require much more thought and effort and is beyond the scope of what was
asked initially.

* Unless it's in unbuffered mode, as Thiago already noted.

>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Parsing data from serialport

[Konstantin Shegunov]

On Thu, Apr 4, 2019 at 9:37 PM  wrote:

> Try testing them with a million+ row table.
>

Been there, done that. Be a lamb and stop with the nonsense. I'm sure you
run every file operation in a dedicated thread, 'cause you'd *"never ever
ever do I/O in the main GUI thread of a Qt application" ...*
Writing like a politician, with the all the generalizations without any
context, and context is everything, ain't impressing nobody here. You're
talking to devs, not to some old lady in the mall.

On Fri, Apr 5, 2019 at 5:14 PM Jason H  wrote:

> Yea, I'm going to have to agree with Denis over Roland.
>

Makes three of us then (and I'm sure many more silent ones if they cared to
comment on the silliness).


> In general it's not good to do synchronous operations (expecially I/O) in
> the main thread, but Qt I/O is mostly* asyc.
>

Yes, depending on the case, the volume of information and latency you're
after. For a console application I wouldn't care much about blocking the
event loop most of the time ...

>

> A lot of people don't realize that as soon as you ask for I/O your thread
> gets suspended by the kernel anyway.
>

Indeed. It used to be, on low-level side of things, that waiting/sleeping
was implemented like an empty IO operation (not sure if it's still the
case).
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Parsing data from serialport

[Konstantin Shegunov]

On Thu, Apr 4, 2019 at 5:46 PM Jérôme Godbout  wrote:

> It relief the main thread from read data all the time and keep a good
> reactivity. The dedicated thread try to read and can wait until something
> come along and once it found something that can be parsed, it emit his own
> signal that the main thread only have to handle into normal slot (will be
> queued, since it's not the same thread).
>
> But yeah, you can have the main thread do it and process the readyRead(),
> you main thread will perform the read and parsing. if you have any CRC and
> other things, this might be bad for application reactivity, depending on
> the amount of data flowing.
>
> -Original Message-
> From: Interest  On Behalf Of Paolo
> Angelelli
> Sent: April 4, 2019 10:19 AM
> To: interest@qt-project.org
> Subject: Re: [Interest] Parsing data from serialport
>
> What is the advantage of having such a continuous reading loop in a
> separate thread?
>
> I mean it as opposed to reacting to the readyRead() signal, and having a
> while(canReadLine()) { ... } in the reacting slot.
>

I think the point is that there's little reason to poll the serial port if
you can react to the event. Exactly what you'd do if you had a network
socket. Qt already does the heavy lifting for you, so you only need to
react to the signal and read as much as you want/need. Basically:

QSerialPort * port;
QObject::connect(port, &QIODevice::readyRead, port, [port] () -> void  {
while (port->canReadLine())  {
QByteArray data = port->readLine();
// emit with data as argument and do the parsing
}
});

Whether you have the port in another thread or not is irrelevant in this
case, either can work fine (unlike your while-sleep loop).
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Using a QAbstractScrollArea

[Konstantin Shegunov]

On Fri, Mar 22, 2019 at 8:25 PM Bob Hood  wrote:

> How do I use this as a concrete Qt class type?  Do I inherit from
> QScrollArea
> and then somehow change my parent to it?  Or do I have to inherit from the
> third-party class, and then recreate the entire QScrollArea interface so
> it
> "quacks" like a QScrollArea instance?
>

Hi!
What I usually do is to promote a placeholder that's as close to the custom
widget as it can be. It's _probably_ going to work if you place a
QScrollArea as placeholder and then promote it you your custom type (and
don't modify its properties too heavily from the designer), but in case it
doesn't you can always use a QWidget.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] popcnt for QFlags

[Konstantin Shegunov]

On Fri, Mar 15, 2019 at 4:08 PM Giuseppe D'Angelo via Interest <
interest@qt-project.org> wrote:

> Yes, this is public API.
>

Indeed, the point was that the API is a bit mismatched in regards to the
used types. QFlags uses int, while qPopulationCount accepts only unsigned
integers, so I'd have to static cast the integers. And I may get badly
surprised in the future if/when the API changes as I'd've suppressed the
type warnings with a static cast. In any case I decided to wrap something
small for my use case, because I decided that using QFlags is actually
abusing the API a bit.

Thanks for the input, anyway.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] popcnt for QFlags

[Konstantin Shegunov]

PS. should I just use qPopulationCount?

>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] popcnt for QFlags

[Konstantin Shegunov]

Hello,
Do we have some Qt way to count the raised bits in a QFlags instance. I saw
there's an inline qt_builtin_popcount, however it's not documented. Can I
rely that it's going to always exist (probably not)? Can we get a method in
QFlags that does this - counting the number of raised bits, instead of
working around it (or implementing it myself)?

Thanks!
Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Recommended exception handling

[Konstantin Shegunov]

On Tue, Mar 12, 2019 at 11:04 PM Thiago Macieira 
wrote:

> No. Catch it before it goes back to Qt code.
>

Roger that!
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Recommended exception handling

[Konstantin Shegunov]

On Mon, Mar 11, 2019 at 10:56 PM william.croc...@analog.com <
william.croc...@analog.com> wrote:

> I wrote and installed my own notify function.
>

Yes, thanks, but as far as I understand from the docs this is going away in
the future (or at least it is in threaded code), which is the reason for my
inquiry.

On Tue, Mar 12, 2019 at 3:07 AM Thiago Macieira 
wrote:

> The advice for QCoreApplication::notify is no longer valid. If an
> exception
> escapes, BadThings™ will happen. Your application may crash before getting
> to
> notify(), or abort by std::terminate(). Or it may cause data corruption.
>

Noted. My question was more in line with: "Are we getting some kind of a
replacement or workaround?"
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Whole edit window closes.

[Konstantin Shegunov]

Hello,
I remembered reading something akin in the forum recently, so I dug up a
bit. I think this[1] might be related to your case. I hope it helps.

Kind regards.

[1]:
https://forum.qt.io/topic/96811/close-itemdeligate-in-view-when-some-other-widget-is-clicked
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Recommended exception handling

[Konstantin Shegunov]

Hello,
Is there a current recommended way of catching exceptions before they
unwind through the event loop? I want this for "debug purposes" only. I
have few methods that throw and I (think I) catch (all of) my exceptions
before they reach the event loop, but I wanted to be sure I hadn't
forgotten something somewhere. Shouldn't happen anyway, but I was wondering
if there's (or if there's going to be) a replacement
for QCoreApplication::notify.

Thanks in advance!

Kind regards,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Disable -Og when configuring as developer build

[Konstantin Shegunov]

On Fri, Feb 15, 2019 at 4:57 PM Allan Sandfeld Jensen 
wrote:

> Btw. If(when) the output isn't debug friendly, it is really a gcc bug


True, and I (hope) I haven't implied otherwise.


> should be reported to them if you have the time, and want it to improve in
> the
> future.
>

Perhaps, but as is of now (with disabling the optimizations) it works for
me. If I get some time in I'd try to reproduce and report it, although I'm
not completely sure how I should format that report ... maybe I should
provide the assembly alongside the source to serve as an illustration ...

Cheers,
Konstantin.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Disable -Og when configuring as developer build

[Konstantin Shegunov]

On Fri, Feb 15, 2019 at 4:40 PM Konstantin Shegunov 
wrote:

> How can I disable it? Is there -no-optimize-debug flag I could use?
>

Yes, apparently there is, and it worked beautifully.
Thank you both!
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Disable -Og when configuring as developer build

[Konstantin Shegunov]

On Fri, Feb 15, 2019 at 4:05 PM Mitch Curtis  wrote:

> Is it the -optimize-debug configure flag?
>

No, not really. The configure script adds it by default to all debug builds
as far as I could tell. Here's my configure line:
$> ./configure -developer-build -opensource -confirm-license -nomake
examples -nomake tests

and I get this as the compile command being executed:

g++ -c -include .pch/Qt5Gui -pipe -g -Og -std=c++1z -fvisibility=hidden
-fvisibility-inlines-hidden -fno-exceptions -Wall -W -Wvla -Wdate-time
-Wshift-overflow=2 -Wduplicated-cond -Wno-stringop-overflow -Werror
-Wno-error=cpp -Wno-error=deprecated-declarations -Wno-error=strict-overflow
-Wno-error=implicit-fallthrough -D_REENTRANT -fPIC -DQT_NO_USING_NAMESPACE
-DQT_NO_FOREACH -DENABLE_PIXMAN_DRAWHELPERS
-DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_GUI_LIB
-DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT
-DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS
-DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_CORE_LIB -I. -I../../include
-I../../include/QtGui -I../../include/QtGui/5.12.2
-I../../include/QtGui/5.12.2/QtGui -I.tracegen -isystem /usr/include/libdrm
-I../../include/QtCore/5.12.2 -I../../include/QtCore/5.12.2/QtCore
-I../../include/QtCore -I.moc -isystem /usr/include/libpng16
-I../../mkspecs/linux-g++ -o .obj/qstatictext.o text/qstatictext.cpp
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Disable -Og when configuring as developer build

[Konstantin Shegunov]

On Fri, Feb 15, 2019 at 4:17 PM Olivier B. <
perso.olivier.barthel...@gmail.com> wrote:

> qtbase/configure.json says it is "optimize_debug" option that adds it
>

Okay. I don't pass that manually to configure, however in the summary I
read the following:

Build type: linux-g++ (x86_64, CPU features: mmx sse sse2)
Compiler: gcc 8.2.0
Configuration: use_gold_linker sse2 aesni sse3 ssse3 sse4_1 sse4_2 avx avx2
avx512f avx512bw avx512cd avx512dq avx512er avx512ifma avx512pf avx512vbmi
avx512vl compile_examples enable_gdb_index enable_new_dtags f16c
headersclean largefile optimize_debug precompile_header
rdrnd shani warnings_are_errors x86SimdAlways private_tests shared rpath
debug c++11 c++14 c++1z concurrent dbus reduce_exports reduce_relocations
release_tools stl
Build options:
 Mode ... debug; optimized tools
 Optimize debug build ... yes

How can I disable it? Is there -no-optimize-debug flag I could use?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Disable -Og when configuring as developer build

[Konstantin Shegunov]

Hello,
That flag's been a pain for me to debug the Qt codebase for a while now,
I'm really annoyed that configure generates it when using -developer-build.
Long story short it prevents me to do step-by-step with gdb as the compiler
reorders the code as it sees fit (no clue why). I remember I had found a
commit from about 2-3 years ago which introduced it, and even found how to
disable it, but for the life of me I couldn't find it again during my most
recent searches.
How can I disable the debug optimizations, and I mean completely?

Thanks!
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Netiquette [was: Feature Request - QtCreator - Multiple right margins]

[Konstantin Shegunov]

>
> [...]
> I do appreciate the open discussion style on this list. I even do
> appreciate a somewhat harsh style, if it has a factual base and is
> getting straight to the point instead of b*s*ing around. But those
> lengthy wallpapers our President of Logikal solutions commonly utters,
> have long since crossed the border from amusing to annoying.
>

I, myself, still perceive them more as amusingly misguided, than really
angering (annoying at times, yes). This is just me, though, I have
experience with that kind of thing. However, I can very well imagine how
you, and most certainly others, are finding them taxing; not surprising at
all.
Plus, as I rule, I tend to discard anything that references fortran or
cobol as examples of anything ... ;)
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Interest Digest, Vol 88, Issue 2

[Konstantin Shegunov]

On Thu, Jan 3, 2019 at 4:17 PM Roland Hughes 
wrote:

>
> On 1/3/2019 4:00 AM, Konstantin Shegunov wrote:
> >> Yes QApplication destructor is invoked last..Does it makes sense to use
> >> deleteLater() in the widget destructors instead of existing delete if it
> >> could be cleaned up as part of qApp-quit()?
> >>
> > Your example code clearly shows otherwise. You have a QObject that's
> > created before and destroyed after the application object.
>
> Wow!
>
> Perhaps a better question would be, "How is it that doesn't fault today?"

Just wondering if the test compilation "worked" due to luck of the draw.
>

I don't know, I'm not intimately familiar with all the internals. QObjects,
I think, rely/relied on a global state that's initialized in
QCoreApplication. What I can say for sure is that thread information is
initialized by the application object. Just for illustration purposes, this
is also the reason why you can't run a QThread and have the application
object in its QThread::run override. The thread object is going to set up
the global thread info and then you're going to get weirdness - warnings
such as "Not creating the application object in the main/GUI thread".
Possibly segfaults at exit. If you actually need to do such stuff you
really need to spin a system thread (std::thread, pthread, w/e) and then
create the application object (besides issues you have with the event loop
integration on osx).

So, even if it worked before, it had been wrong all along, so it should be
fixed anyway.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Wed, Jan 2, 2019 at 5:55 PM Roland Hughes 
wrote:

> By then, Qt has abandon them.


Yeah, recently I had worked on a couple of projects for one such company
(in aviation meteorology). They were "abandoned" for many years because it
takes at least minimal effort to actually follow the new releases and
support your code, which they did not. And as Qt6 is peeking around the
corner, they've finally ported the old code to Qt5 (5.6). I wonder how much
time it's going to take them to get from Qt5 to Qt6, perhaps I'll be old
and frail by then. Complex programs won't just run by themselves forever if
you are not willing to put in the time to support them, don't expect others
to do the dirty work for you. Just hoping, and also spreading such
expectations, that a library (or a system) is going to guarantee
compatibility and at the same time get updates forever is neither
realistic, nor is it going to happen, Qt is no exception.

I don't know for certain and don't care enough to dig into it again,
> but, I believe someone stated at some point that when a parented QObject
> was created some of the parents didn't connect the destroyed() signal to
> a slot which would remove the child from their list.


Removal from the children list is done through an event, not through
connecting to QObject::destroyed. The latter is for your convenience.

2) Forget all assumptions about what one can do in threads and how to
> create them.
> ...
> When it comes to threading, don't derive from QThread.


Deriving from QThread (or using QThread::create) is perfectly valid if you
don't intend to process events. Also everything that's done with an event
loop can be done without, it just takes more effort and care.


> [...]
>

Additional obnoxious and irrelevant stuff I have no intent addressing at
all.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Wed, Dec 19, 2018 at 11:51 AM Ramakanth Kesireddy 
wrote:

> Yes QApplication destructor is invoked last..Does it makes sense to use
> deleteLater() in the widget destructors instead of existing delete if it
> could be cleaned up as part of qApp-quit()?
>

Your example code clearly shows otherwise. You have a QObject that's
created before and destroyed after the application object.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Use QMetaEnum::keyCount() to initialise array

[Konstantin Shegunov]

On Wed, Dec 19, 2018 at 11:22 AM Tom Isaacson  wrote:

> Is it possible to use QMetaEnum::keyCount() to initialise an array? Something 
> like:
>
> const QMetaEnum metaEnum = QMetaEnum::fromType();
> int MyArray[metaEnum.keyCount()];
>


const QMetaEnum metaEnum = QMetaEnum::fromType();

int MyArray[metaEnum.keyCount()];
Compiles for me (with g++ 8.2, -std=gnu++11 which is expanded from
CONFIG += c++11).
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Tue, Dec 18, 2018 at 8:25 AM Ramakanth Kesireddy 
wrote:

> Thanks for your mail..Yes did try with valgrind but couldn't detect memory
> issue may be due to the way our app is designed using threading.
> But wondering why it throws segmentation fault if qApp instance is created
> on stack but not on Heap as I understand that it is mandatory to construct
> qApp instance on stack by design.
>

QObject (and QCoreApplication) doesn't impose such a limitation, no, you
can have them in the heap or stack. I'd be really surprised, though, if you
don't get the same segfault at the point of the delete call. If you mean
that you just don't free it up, however, then that's a major code smell.
>From your description I'd hazard a guess that you have a QObject which
outlives the application (probably a global). This is not allowed, and as
Thiago already said you must clean up before the Q*Application's
destructor's run.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Mon, Dec 17, 2018 at 7:00 PM Ramakanth Kesireddy 
wrote:

> Yes we do have Qt running in worker thread(pthread)..Does it throws
> segmentation fault if we donot wait for the thread(like pthread::join) to
> exit event loop and destroy objects accordingly?
>

Segmentation faults are not thrown, they are not exceptions, albeit linux
allows you to catch the system signal. It means you've violated the memory
segment boundary, hence the name, on windows it's called "Access
violation". In any case it's one of the most generic messages for one of
the most common programming bugs - corrupt memory access. To answer your
question, it may, it may not, depends on many things one of which is
execution order, which isn't exactly deterministic when working with
multiple threads without ordering. It's a (serious) bug, so you should fix
it.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Mon, Dec 17, 2018 at 1:39 PM Andrew Ialacci  wrote:

> Assuming each threads quit() is called and all operations are stopped in
> each thread correctly is using a loop and sleep still ok?
>

Ok's a relative term, but I wouldn't do (or recommend) it. That's the whole
reason you have QThread::wait (and pthread_join, std::thread::join and so
on) to begin with. Just wait for the threads the usual and recommended way
instead of polling them for no obvious reason. :)

>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Segmentation fault on exiting Qt event loop

[Konstantin Shegunov]

On Mon, Dec 17, 2018 at 1:26 PM Andrew Ialacci  wrote:

> I’ve had this issue on Windows especially when destroying worker threads
> on an application exit.
>

Which you shouldn't do.

What I ended up doing was sleeping the main thread until each worker
> threads isRunning() return false;
>
> I’d love to know if this is the //best// solution to this problem but from
> what I’ve found it works very well.
>

Nope. Call QThread::quit or QThread::requestInterruption (depending on
whether you have a running event loop in the thread(s)). And wait for them
with QThread::wait before allowing the QThread objects to be destroyed.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Updated Debian packages or ppa for Qt 5.9+

[Konstantin Shegunov]

On Sat, Nov 10, 2018 at 12:23 AM Lisandro Damián Nicanor Pérez Meyer <
perezme...@gmail.com> wrote:

> > Pin debian testing repos with a low priority in the apt configuration and
> > you can get the binaries from there. Current it 5.11.2.
>
> Only if you really know what you are doing. If you use KDE stuff (kwin for
> example) you will certainly have to upgrade it, and thus half your system,
> because it uses Qt's private methods.
>

It's been some time since I did this kind of stuff, but I think you
*should* be able to pull the 5.11 only alongside the standard one that
comes from stable. It's true, however, that a lot of stuff is going to be
pulled alongside. It also means no metapackages, though, so I'd agree it's
a risk/work that's probably not worth it. I'd say building yourself is
probably faster/safer in that context (or even pulling it through the Qt
maintenance tool). Correct me if I'm wrong but also trying to "ignore" the
deps may work in some cases, depending on how far stable is behind testing.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Updated Debian packages or ppa for Qt 5.9+

[Konstantin Shegunov]

On Wed, Nov 7, 2018 at 9:59 AM Hamish Moffatt 
wrote:

> Does anyone know of a repository for updated Qt packages for Debian
> stable (stretch / 9)?
>

Pin debian testing repos with a low priority in the apt configuration and
you can get the binaries from there. Current it 5.11.2.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt API annoyances: where to log/discuss?

[Konstantin Shegunov]

On Tue, Oct 30, 2018 at 5:39 PM Jason H  wrote:

> I was wondering if there is a place to log annoyances/discuss with the Qt5
> API for fix in Qt6?
>

Probably a good idea is to submit a suggestion to the bugtracker as well.

Two I am thinking of right now is:
> - QUrl::port() returns an int, but QTcpServer accepts a quint16, so no
> matter what I do, unless I add a cast, I get a warning.
>
- Similarly with QImage::pixel there are signed/unsigned issues between
> pixel and qRgb().
>

Yep, happens from time to time when the codebase grows, e.g.
https://bugreports.qt.io/browse/QTBUG-69752
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] SQL databases and threading

[Konstantin Shegunov]

Hello,
Is there any way to tell (besides looking at the sources) if a given SQL
plugin, or single methods of it, is reentrant/thread safe? The docs are
rather evasive on the issue ...
What would be allowed to do if I want to thread the SQL queries? Can I
serialize the exec/prepare and then pull the resultset in another thread?
Ideally I would like to process the results in a thread if possible, even
if I have to serialize the exec.

Currently I'm working with the PQSQL driver, but general answers are
acceptable as well.

Thanks in advance.
Kind regards.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Qt Datetime display

[Konstantin Shegunov]

On Sun, Oct 7, 2018 at 12:42 PM Ramakanth Kesireddy 
wrote:

> Is there any date time widget which would serve this purpose?
>

QDateTimeEdit will do.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Event inspection after delivery

[Konstantin Shegunov]

On Sun, Jul 22, 2018 at 7:08 PM, Sérgio Martins  wrote:
>
> For statistics you probably want to use tracepoints [1].

[1] http://lists.qt-project.org/pipermail/development/
> 2017-February/028762.html
>

On Sun, Jul 22, 2018 at 8:13 PM, Giuseppe D'Angelo via Interest <
interest@qt-project.org> wrote:
>
> And in particular this patch:
>
> https://codereview.q 

*ETW may refer to: East to West, an American Contemporary Christian music
> duo active 1993–1997; Eastern Trombone Workshop, one of the largest annual
> ...*

t-project.org/#/c/229165/ 


Thanks, but please correct me if I'm wrong though. Isn't the purpose of
this to profile and/or trace around the code for optimization purposes?
Can I get realtime information while my program's running and can I get
this in release mode through an API of sorts?
I'm trying to balance out worker objects in a thread pool, so I'd need to
process this in-code.

On Sun, Jul 22, 2018 at 7:05 PM, Thiago Macieira 
wrote:
>
> > Yes, I read the warning, that's why I posted here. My follow up
> question(s)
> > would then be:
> > How will the fine grained control that notify() gives be replaced, or
> will
> > it be at all?
>
> Unknown. That needs to be developed.
>
> The problem in question is that notify() is a virtual function in
> QCoreApplication, which means we can't thread-safely deliver events in
> auxiliary threads while the main thread is either constructing or
> destructing
> the QCoreApplication. My inkling is to simply ignore the QCoreApplication
> when
> outside the main thread. Hence the warning.
>
> > And is considering event post-processing (akin to the event filter which
> > goes before the QObject::event) sensible?
>
> It hasn't been necessary for the last 25 years.
>
> > I realize mine is somewhat of an edge case, but I'd be surprised if no
> one
> > had needed that before ...
>
> Surprise!
>

Okay, fair enough.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Event inspection after delivery

[Konstantin Shegunov]

On Sun, Jul 22, 2018 at 6:54 PM, Thiago Macieira 
wrote:
>
> QCoreApplication::notify will help you for now, but that will not work in
> Qt
> 6.
>

Yes, I read the warning, that's why I posted here. My follow up question(s)
would then be:
How will the fine grained control that notify() gives be replaced, or will
it be at all?
And is considering event post-processing (akin to the event filter which
goes before the QObject::event) sensible?
I realize mine is somewhat of an edge case, but I'd be surprised if no one
had needed that before ...
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Event inspection after delivery

[Konstantin Shegunov]

On Sun, Jul 22, 2018 at 6:36 PM, Thiago Macieira 
wrote:
>
> If you only need this for a particular class,


Unfortunately no, not for a particular class. Ideally I'd use something
like an event filter that'd be triggered after the event was delivered, but
I'm not aware of any such functionality. Did I miss any possible options,
or those two just about cover it?
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

[Interest] Event inspection after delivery

[Konstantin Shegunov]

Hello,
Is there any way to inspect an event that was delivered, just after the
fact? Looking at the source it seems the only way to do this is to have
QObject::event or QCoreApplication::notify overridden, is that correct?

I'm interested in QEvent::MetaCall specifically. I want to collect some
statistics about slot execution times.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] QDatastream, QMap, QImage serialization

[Konstantin Shegunov]

On Tue, May 22, 2018 at 4:22 PM, Thiago Macieira 
wrote:

> On Tuesday, 22 May 2018 05:07:05 -03 Konstantin Shegunov wrote:
> > Wouldn't it be the same from the point of view of a GUI application, when
> > the platform plugins are already loaded?
> > And fail for console apps, where there are no loaded plugins to be
> queried,
> > so it'd default to the raster engine?
> > If this is the actual case then probably this is quite acceptable ...
>
> Please rephrase. Your question doesn't make sense. I wouldn't be asking if
> it
> were the same.


Forget it. Your latter comments made what I was thinking about a moot point.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest