Re: [Interest] Behavior of write() to stdErr in Qt Creator

2023-04-29 Thread Bernhard Lindner
Ok, I see. That is plausible. I will create an issue.

Thanks for your support.

On Fr, 2023-04-28 at 16:21 -0700, Thiago Macieira wrote:
> On Friday, 28 April 2023 01:31:39 PDT Bernhard Lindner wrote:
> > Please note that lines are not interleaved. Still a line feed is added after
> > each write() call when executing the code snippet from a sub thread.
> > 
> > The effect is completely reproducible when starting the debug build from Qt
> > Creator under gdb supervision. However when manually stepping through the
> > code or when running the debug build without debugger the output looks just
> > fine.
> 
> I can reproduce this with the attached test. The problem appears to be that 
> when Qt Creator reads from the pipe, it assumes that whatever it read is a 
> full line after a time out, when it isn't. It doesn't update the previous 
> line 
> when more characters are received.
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Best Regards,
Bernhard Lindner
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


[Interest] Behavior of write() to stdErr in Qt Creator

2023-04-28 Thread Bernhard Lindner
Hi all!

In a Qt/C++ application I need to use write() to print some text to stderr. I'm 
doing
something like this multiple times:

  write(stdErrDescriptor, "H", 1);
  write(stdErrDescriptor, "e", 1);
  write(stdErrDescriptor, "l", 1);
  write(stdErrDescriptor, "l", 1);
  write(stdErrDescriptor, "o", 1);
  write(stdErrDescriptor, "\n", 1);

I'm calling that from the main thread and a sub thread. The output of the 
threads should
be serialized by internal program logic. This means the main thread should not 
print at
the same time as the sub thread. This seems to be true since in reality I could 
never see
interleaved lines on the console. Still there is something going on that I do 
not
understand.

I expected to see something like this:

   Hello
   Hello
   Hello
   Hello
   Hello
   Hello

However I get this:

   Hello
   Hello
   H
   e
   l
   l
   o
   
   H
   e
   l
   l
   o
   
   Hello
   Hello

Please note that lines are not interleaved. Still a line feed is added after 
each write()
call when executing the code snippet from a sub thread.

The effect is completely reproducible when starting the debug build from Qt 
Creator under
gdb supervision. However when manually stepping through the code or when 
running the debug
build without debugger the output looks just fine.

I'm running the code on Kubuntu 20.04 and GCC 12.

What is going on?

-- 
Best Regards,
Bernhard Lindner
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


Re: [Interest] Official linuxdeployqt ?

2022-08-09 Thread Bernhard Lindner
AppImages are a breeze. For both developer and user.

An easy to use Qt-provided tool for that purpose would be fantastic.

On Mo, 2022-08-08 at 18:03 -1200, Vadim Peretokin via Interest wrote:
> Just to correct some biases here, in my opinion as a software publisher 
> AppImage is
> still the simplest way for a user to run your app. 
> 
> To get Mudlet (a FOSS text games client) all you need to do is go to 
> https://www.mudlet.org/download, download the .tar, right-click to extract it 
> and
> double-click to run. 
> 
> It really is that simple; experienced and unexperienced users alike across 
> many
> different Linux distributions make it work.
> 
> Try to replicate that with snap or flatpak - you won't be able to without 
> messing in the
> terminal or relying on distro-specific distribution channels. Nothing beats 
> AppImage for
> a truly distro agnostic image distribution format, and I'm speaking from 
> having used it
> for years to distribute my software.
> 
> BR
> 
> On August 8, 2022, Vadim Peretokin via Interest  
> wrote:
> > On 8/8/22 16:09, Jörg Bornemann wrote:
> > > Mitch already pointed you to QTBUG-74940.  The biggest question 
> > > regarding a linuxdeployqt is: what exactly is the deployment format 
> > > going to be?  There's no standard way of deploying Linux applications. 
> > > There are many.
> > >
> > > The community contributions create AppImage packages.  That seems to 
> > > be a reasonable choice.  Other opinions?
> > 
> > 
> > Like Roland said, it has to be Flatpak. I haven't seen anyone talking 
> > about AppImage in years, and Snap is too Ubuntu-specific.
> > 
> > 
> > windeployqt doesn't package anything though, so should linuxdeployqt? 
> > macdeployqt only sort of does, with its dmg support.
> > 
> > 
> > Hamish
> > 
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Gruß, Bernhard

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


Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

2022-02-24 Thread Bernhard Lindner
> Evidently, the people commenting in this thread care deeply enough about Qt 
> on the
> desktop to participate in the discussion. And I suppose most of us on this 
> list are
> software engineers, many perhaps for more reasons than to put food on the 
> table. My
> question to you is: how can we make it easier, or more fun, or more 
> motivating to
> contribute to Qt, and to help with making things better?

I don't know how to make it more attractive for OSS developers to contribute. 
But I know
how to make it more unattractive... OSS hostile licenes are one way. 

Recently in one of the biggest german IT news portals there was a news about 
Qt. It got
exactly one comment thread that said "After the new licensing model, Qt is dead 
anyway". 
If this is the conventional wisdom among OSS developers, then no further effort 
is needed.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Is there a good alternative to the QML Controls in Qt6 for native desktop integration purposes?

2022-02-21 Thread Bernhard Lindner
Hi,

QML is nice for basic applications but widgets is important for professional, 
technical
and high-density applications. 

But that doesn't matter. From my point of view Qt stopped being developed as a 
desktop
framework a long time ago. Other industries seems to have priority now.

On Mo, 2022-02-21 at 16:42 +0100, Mark Gaiser wrote:
> Hi,
> 
> I'm facing so many bugs in QML Controls in Qt6 (they used to be Controls V2 
> in the Qt 5.x
> days) that I don't want to use them at all anymore. They are bugged beyond 
> repair and
> downright unusable for native desktop integration purposes.
> 
> Is there another good open source component set out there that integrates 
> with the
> desktop. Specifically with Windows but preferably also with Linux (kde and 
> gnome) and Mac.
> 
> Using QWidgets should not be an alternative as it slows down development a 
> lot. But given
> the crap that QML Controls is makes me consider switching to QWidgets instead.
> 
> 
> Best regards,
> Mark
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Ashamed bug :)

2021-09-04 Thread Bernhard Lindner

> So please don't tell us something is easy and we should be ashamed of not 
> having done it, if one has yet to attempt.

This is all about very different expectations (or maybe perceptions?) of 
quality. Again.
We had these discussion many, many, *sigh*, many times before. 
*cough*roland*cough*

I guess Alexander would be ashamed or embarassed if one of his products had an 
bug that
has been reported but not fixed after five years. For Qt on the other hand this 
seems to
be totally normal.

I don't think this thread can come to an end. Surely not by writing harsh 
posts. If
Alexander has higher quality requirements than Qt provides and does not want to
contribute, maybe he should consider if he is using the proper framework for his
project(s).

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Ashamed bug :)

2021-09-04 Thread Bernhard Lindner

> The entire process is either difficult or easy.

No. Actually it can be both: Difficult for an outsider and easy for a 
experienced Qt
developer. 

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Ashamed bug :)

2021-09-03 Thread Bernhard Lindner
> We’re all looking forward to your contribution!
> 
> https://wiki.qt.io/Qt_Contribution_Guidelines

Once upon a time finding, analyzing and reporting bugs was considered a 
contribution as well.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] List traffic disappearing?

2021-08-20 Thread Bernhard Lindner
Well, considering the latest decisions of TQC this isn't surprising. New Qt5 
releases are
for commercial customers only (who probably don't use this list much) and Qt6 
is still not
useable for most people. I guess this reduces traffic a lot.

Also one special person was banned from the list. He surely started a lot of 
controversies
and even fights but he was also responsibly for a significant part of the 
trafic :-) 

Personally, I generally lost interest in Qt because I am not target audience of 
Qt
anymore. But I have no idea if other people feel this way as well.

> I've been on this list (and it's predecessor) for a couple of decades, and 
> have noticed
> that the traffic on it seems to have slowed significantly over the past few 
> months. Is
> there somewhere else people are going, like https://forum.qt.io/, or have 
> people just
> stopped discussing Qt for some other reason?
> 
> Sean 
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Learning solutions survey

2021-06-16 Thread Bernhard Lindner
Never heard about that license. I was very interested until I read the FAQ:

"Under the educational license, limitations apply. Applications and/or devices 
may not be
distributed to third parties and must be used for internal use only. 
Subcontracting in any
direction is not allowed under this license. Professional support of Qt is not 
included
either."

This means that as soon as the students use the software in the practical part 
of their
studies and have to publish the software as part of their scientific work or as 
part of
their degree, they are forced to go back to the OSS license. That's ridiculous. 
For me,
that means avoiding Qt altogether in our curriculum or, if at all, relying 
exclusively on
the OSS license.
It seems like there is an internal company rule that requires all license terms 
to be
written in such a way that licensees are annoyed under all circumstances. 

> Took a while to study your case Rolf. I'm very sorry that we have ignored 
> your EDU
> license requests. 
> 
> Each EDU license request is automatically assigned to a person, who should 
> continue the
> process:
> validate that the request is from a proper university and so on. 
> I can see in our records that you have requested an EDU license for three 
> times, but the
> person in-charge has 
> never replied to any of those requests. This is very unfortunate and please 
> accept my
> apologies. We clearly need 
> to improve our processes to guarantee that each and every request gets 
> answered. 
> 
> It is important for us that we do our best to enable Qt teaching at 
> universities all
> over the world. 
> --
> Tino Pyssysalo
> Product management
> The Qt Company
> 
> 
> On 9.6.2021, 11.37, "Interest on behalf of Rolf Winter" <
> interest-boun...@qt-project.org on behalf of rolf.win...@gmail.com> wrote:
> 
> Hi,
> 
> I have one improvement you could implement. Some time ago, I have
> tried to reach out to the Qt Edu Team via
> https://www.qt.io/qt-for-educational-program. I tried several times
> over a couple of months through the form on that site and never got a
> response. I then I turned to the Qt in Education Forum
> (
> https://forum.qt.io/topic/110451/qt-in-education-contact-through-web-interface-unresponsive
> )
> and somebody (I assume from the Qt Company) kindly forwarded my Email
> to the responsible people inside the Qt company. I still have not
> received a response to date, but it has only been a year now. I
> basically stopped teaching Qt but if you want people to educate devs
> for you, you really need to start responding to queries or take down
> the education site if nobody pays attention to it.
> 
> Best,
> 
> Rolf
> 
> On Tue, Jun 8, 2021 at 4:04 PM Jarko Vihriala  
> wrote:
> >
> > Hello all,
> >
> > We would like to hear what you have to say regarding the learning 
> solutions about
> Qt and QML. Please check out my blog post at 
> https://www.qt.io/blog/learning-solutions-survey and give your honest 
> feedback by
> clicking the link to the survey. Thanks in advance!
> >
> > Results from the survey will be used to make our learning solutions 
> better for
> anyone using Qt or wanting to use Qt.
> >
> > Br, Jarko
> >
> >
> >
> >
> >
> > ___
> > Interest mailing list
> > Interest@qt-project.org
> > https://lists.qt-project.org/listinfo/interest
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
> 
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest

-- 
Gruß, Bernhard

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


Re: [Interest] Another Qt disappointment

2021-05-04 Thread Bernhard Lindner

> I don't know how they can sleep at night. 

I guess Uncle Scrooge would argue that you can sleep very good on a mattress 
stuffed with
banknotes, no matter where the money came from ;-D

I agree to all of your statements.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] L Word

2021-04-30 Thread Bernhard Lindner

> > 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.

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.

> > The main problem isn't trolling.
> 
> Actually it is.

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

Still I would never write e-mails in his style and I wish he would drop those 
borderline
insults.

Actually my biggest problem with his posts are their length and the slangy 
language (both
makes reading his mails hard for a non-native speaker like me). 

> > 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.

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

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

Also don't forget that fights always need two persons: One person who provokes 
and someone
else who volunteers to escalate the situation. As much as I can't understand 
Rolands style
of speech I also can't understand people fighting back in the same style and 
then
complaining about Roland.

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

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] L Word

2021-04-30 Thread Bernhard Lindner

> The other part of the problem is that he doesn't come from the world of 
> well-adjusted,
> well-behaved people. This could answer your question.

Well, I have met a lot of such people in my life. Such people tend to think 
different
and/or critical and/or they are straight, which is something I like and that 
can be very
useful. Of course the underlying intentions must be constructive anyway - which 
should be
the main question when considering to ban someone.

Do you think Roland's main intentions are destructive?

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] L Word

2021-04-29 Thread Bernhard Lindner
The main problem isn't trolling. The main problem is: Roland comes from a 
completely
different world. The world of functional safety. This world is difficult and a 
completely
different from conventional software development. It is particularly different 
from
smartphone and web development. And it doesn't have much to do with desktop 
software
development. I have also been in this world for more than 3 years. A world where
programming is the least important thing. Where documentation is important. And 
the law.
And prison. And accuracy and multi-level tests and reliability and verification 
and
validation and standards. And many years of support. And certifications. A 
person who has
worked in this world for a long time has different priorities. Roland calls 
this "True
Software Engineering".

Obviously, Qt has nothing to do with this type of software engineering. And 
it's obviously
not suitable for functional safety (at least not if you take it seriously).

What I don't understand is why Roland doesn't just leave the mailing list and 
forget about
Qt. Qt is not suitable for use in his industrial sector, so I can't understand 
why he
spends so much time writing about the conflict between the reality of Qt and 
the reality
of his industrial sector. If I were him, I would have given up trying to 
influence Qt's
strategy a long time ago.

(Actually, I'm about to give up my hopes for desktop development with Qt). 

So, Roland, why are you keeping the conflicts going? 

-- 
Best Regards,
Bernhard Lindner

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


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

2021-04-22 Thread Bernhard Lindner

> 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.

Hm, this kind of confirms my impression: Quick is lightweight, simplified and 
suited for
embedded and touch. While widgets are more powerful and suited for complex 
desktops
applications. This makes me wonder even more why Qt gave up widgets. The logical
explanation is, Qt kind of gave up desktop.

You explained why the widgets concept is not compatible with the Quick concept. 
Can you
also explain why it was not possible to implement Quick as an additional, 
mostly widget-
independent C++ layer and then wrap it declaratively?

-- 
Best Regards,
Bernhard Lindner

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


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

2021-04-21 Thread Bernhard Lindner

> Personally, I think the exsting QtQuick element should be scrapped and just 
> focus on QML
> versions of the existing Widget functionality. I love the QML syntax, hate 
> that it's not
> just a layer on top of widgets.

+100

Why this wasn't done from the start is one of the hardest puzzles! I ask myself 
this
question every time I read the three letters "QML" :-) 

-- 
Best Regards,
Bernhard Lindner

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


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

2021-04-21 Thread Bernhard Lindner

> Judging from the influx in the CopperSpice world, a lot of companies with 
> projects large
> and small are biting the bullet.

How did you come to this result? Are there any hard numbers, links, reports, 
etc. that you
can share?

-- 
Best Regards,
Bernhard Lindner

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


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

2021-04-19 Thread Bernhard Lindner
On Mo, 2021-04-19 at 11:01 +0100, Rui Oliveira wrote:
> Well, let's then hope that Mr Volker Hilsheimer's statements hold to a 
> bright future.
> 
> As I said before, I wouldn't even mind to wait for the RHI backend on 
> Widgets if that meant a cleanup up effort of the error log.
> 
> Let's see what the future brings.

How patient do you plan to be? 

I've waited about 10 years now and Qt is going down the drain faster year after 
year (at
least from my point of view). The ratio between steps forward and backward is 
steadily
deteriorating. Only greed grows continuously :(

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly

2021-03-28 Thread Bernhard Lindner

> hush-hush "call for pricing" is a truly bogus business practice usually 
> utilized by scams and used car dealers.
> 
> This "gouge them for all they are worth in private" business model 
> really isn't valid. Even if you adamantly claim that isn't what is going 
> on, that is __exactly__ what it looks like from the outside.

So true!

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly

2021-03-28 Thread Bernhard Lindner

> What would really help, is to get this documented out in the open... None of 
> this
> "contact sales for pricing"

You have not yet received the most important and most common advice in this ML: 
"Ask a
lawyer"! LOL SCNR

But seriously, what would really help would be giving the technology to people 
who don't
ruin it with greed. 

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread Bernhard Lindner

> I don't know about other parts of the world, but in the U.S.A. the FDA 
> is very adamant. Only the binary set that they have tested gets installed.

Pretty much the same in Germany. Also for other safety related (non-medical) 
industries.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] The willy-nilly deletion of convenience, methods

2021-03-23 Thread Bernhard Lindner
> Raise your hands.
> 
> How many of you have reported bugs that have sat open for over a year?

A year? LOL. 1 year is the age of the newest unresolved issue I have. Most of 
them are
many years old, including multiple issues dated 2012.

> Raise your hands.
> 
> How many of you have bugs reported against earlier versions of Qt that sat 
> open until
> they were closed as being against an unsupported version?

Actually this did not happen to me as far as I can remember. LOL! Probably 
because most of
my unresolved issue are rotting in the issue tracker as "Reported" and are 
ignored
forever.

> How many of you have had to scrap products or features because bugs you 
> reported were
> blockers and they were just rotting in the bug database? How many of those 
> bugs are
> still rotting?

Not scraped anything. But rewritten a lot. Hunted long known bugs. Reinvented 
the wheel
and wrote horrible work arounds.

> The only thing that is going to work for the big ticket companies is a 100% 
> commercial
> product that happens to release its older stuff as OpenSource and sometimes 
> accepts
> software developed by others for free. Nobody wants to hear that, but that is 
> the only
> model that works. With that model comes fixing all bugs inside 90 days. None 
> of this
> hoping someone in the OpenSource community fixes it for free.

You are right. But that has nothing to do with "Open Source" in the first 
place. I have
seen larger companies that insisted in "Open Source" for critical components - 
still with
the full, the reliably commercial support you are talking about. I think you 
are mixing
"Open Source" and "Community driven" here.

> That QML stuff really has to be ripped out and put into its own commercial 
> package so
> the rest of the world doesn't have to pay the heavy price. 

+1

> The Wolfe oven needed a stacked widget, not a state machine. Project craters 
> like these
> aren't helping the reputation of Qt.

Can you explain that? I have seen software going down the drain because people 
didn't use
state machines. I have seen software using state machines without urgend need. 
But I have
never seen a software that failed *due to* using state machines (at least not 
when fully
understood).

> Roughly half of my bugs reported via the forum are fixed within a couple of 
> days.

Seriously? Wow. What kind of bugs? What impact?

> Phones only care about what is shipping next week.
> As I said before, those are diametrically opposed markets.

I agree?

> Just my 0.0002 cents.

How do to change that? LOL, SCNR

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)

2021-03-22 Thread Bernhard Lindner
Hi Roland,

has any framework crossed your way that implements CoW?

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-21 Thread Bernhard Lindner

> I don't know if it is current or not, but the KDE Manjaro has is really 
> nice. They don't stick you with the really bad KDE packages either, like 
> Calligra and KMail either. Apologies to our resident KMail fan.

KMail has several problems. THis is why I am using Evolution. But you don't 
need to switch
the distro. Simply install your favourite tools and remove the nasty ones. I 
have a script
for that purpose.

Alas the are KDE Tools with not real replacement. Like smb4k. I guess this is 
one of the
most frustrating tools I have ever used but there is no replacement when using 
KDE :(

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] The willy-nilly deletion of convenience methods (was: Mixing Commercial and Open...)

2021-03-21 Thread Bernhard Lindner
Hi!

> Licensing FUD + death-of-perpetual-license + death-of-OpenSource-LTS + 
> Qt-6-rolling-out-incomplete + deleted-convenience-methods = 
> customers-leaving

I wonder if the loss of confidence in the current Qt owners can ever be 
compensated.

Even if TQC took back their critical decisions, I can't imagine that people 
would ever
trust them again. This could cause fatal damage to Qt in the long run if they 
don't sell
it to someone more responsible.

-- 
Best Regards,
Bernhard Lindner

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


[Interest] QCoreApplication, argc parameter type

2021-01-07 Thread Bernhard Lindner
Hi!

Can someone tell me why QCoreApplication uses an 'int ' type parameter 
instead of a
plain 'int argc'? Does QCoreApplication expect the value to change? Does it 
change the
value by itself?

When deriving from QCoreApplication this can cause funny crashes if one forgets 
to use a
reference type in the derived class' constructor parameter. So I guess there 
must be a
very good reason why QCoreApplication uses a reference instead of copy-by-value.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Qt Designer zombie widget phenomenon

2020-12-03 Thread Bernhard Lindner
Thanks, Roland, for the interesting answer!

I wasn't using Designer much recently. But as soon as that happens again, I 
will check
what you described. 

I used layouts a lot and yes, some of them orginate from Qt4. But I am not sure 
how many.
I started using Qt5 a long time ago. Hard to say if this actually happens for 
Qt4 UIs
only.

I guess there is no way to grep such hidden layouts?

Is there, by any chance, a Designer developer wo maybe knows more details?

> During early Qt 4.x days, this and corrupted .ui files that had to be 
> hand edited using a basic editor were common problems. Recently I had to 
> crack open some .ui files created during the 4.x days using the 4.x era 
> Designer. I had this _exact_ problem crop up using the QtCreator bundled 
> in both Ubuntu 18.04 LTS (base for your KDE Neon version) and the one in 
> Ubuntu 20.04 LTS.
> 
> I didn't dig horribly deep into the problem given everything else life 
> was tossing at me, but I did open the .ui files BlueFish 
> http://bluefish.openoffice.nl/index.html and a couple of other editors. 
> When I searched for the object names the Designer gave me for the Zombie 
> objects I found they were all inside a "hidden" layout. Even things that 
> I had just deleted were there.
> 
> This problem did not manifest itself in any .ui files I created from 
> scratch, only in those that had originally been created using 4.x era tools.
> 
> If you still have the original files and have in your notes (or can 
> simply reproduce the problem) you should obtain the name of the 
> object(s) then open the .ui in an XML highlighting editor and search for 
> them. I suspect you will find them in a "hidden" layout. What I remember 
> from the experience is it seemed like deleted objects were "stored for 
> safe keeping" in a "deleted" layout in case you wanted to restore them. 
> Again, this only happened in .ui files that had been created with 4.x 
> era tools. Even when I used the new tools they seemed to put anything I 
> deleted in that layout for safe keeping. I guess in case I wanted to 
> undelete it?
> 
> The Zombie effect has to do with the mysteries of layout sizing and 
> visibility calculations. It is decided for you that some little piece of 
> that layout is now "visible" and the object contained in that area appears.
> 
> Being quite busy and seeing there were no need for layouts in these 
> dialogs anyway (it was fixed size having no max/min buttons) I nuked 
> every layout. One did need the min/max buttons. I recreated the .ui from 
> scratch and there were no mystery objects revealed in the XML editors.
> 
> On 9/6/20 5:00 AM, Bernhard Lindner wrote:
> > Hi!
> > 
> > Ok, that is kind of crazy and ridiculous. And maybe it is something stupid 
> > I am doing.
> > But
> > I can't figure it out. It suddenly started many months ago after some Qt 
> > Creator
> > update
> > and at the beginning I simply ignored it. But now it is driving me nuts.
> > 
> > This is what happens:
> > I open a window UI in Qt Creator Designer, I change something random like a 
> > text and I
> > save the changed design. Then I close the designer and build the 
> > application. After
> > starting the application, sometimes a new, completely random widget (e.g. a 
> > QComboBox)
> > appears somewhere embedded in a new random layout cell in my window. That 
> > widget is
> > blank
> > and everything else in the window is unchanged. If this happens I can go 
> > back to the
> > designer and simply delete the additional "zombie widget". Then everything 
> > is back to
> > normal after building the application... until I edit a design and with a 
> > small chance
> > some other zombie widget pops up from nowhere. The zombie widget is not 
> > visible when
> > editing/saving/closing the design, only after reloading it from disk.
> > 
> > I could not find a system when or why this happens. I don't think it is an 
> > unwanted
> > drag-
> > n-drop action.
> > 
> > I am using KDE Neon 18.04 and the most recent Qt Creator with Qt 5.14.2.
> > 
> > Has this happend to someone else before?
> > 

-- 
Gruß, Bernhard


signature.asc
Description: This is a digitally signed message part
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


[Interest] Qt Designer zombie widget phenomenon

2020-09-05 Thread Bernhard Lindner
Hi!

Ok, that is kind of crazy and ridiculous. And maybe it is something stupid I am 
doing. But
I can't figure it out. It suddenly started many months ago after some Qt 
Creator update
and at the beginning I simply ignored it. But now it is driving me nuts.

This is what happens:
I open a window UI in Qt Creator Designer, I change something random like a 
text and I
save the changed design. Then I close the designer and build the application. 
After
starting the application, sometimes a new, completely random widget (e.g. a 
QComboBox)
appears somewhere embedded in a new random layout cell in my window. That 
widget is blank
and everything else in the window is unchanged. If this happens I can go back 
to the
designer and simply delete the additional "zombie widget". Then everything is 
back to
normal after building the application... until I edit a design and with a small 
chance
some other zombie widget pops up from nowhere. The zombie widget is not visible 
when
editing/saving/closing the design, only after reloading it from disk.

I could not find a system when or why this happens. I don't think it is an 
unwanted drag-
n-drop action.

I am using KDE Neon 18.04 and the most recent Qt Creator with Qt 5.14.2.

Has this happend to someone else before?

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Three-file modules vs. moc

2020-09-02 Thread Bernhard Lindner
> If you turn automoc on, it tries to guess which moc files need to be 
> generated 
> and which ones are #included by way of regular expressions too. If you don't 
> like that, don't use automoc.

Ok, I see, thanks.

If cmake/automoc uses the same basic search and if there is no interest/plans 
in making it
smarter, I will drop the original idea.

Currently I would like to prefer to drop moc ;)

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Three-file modules vs. moc

2020-09-01 Thread Bernhard Lindner
Hi Thiago!

> > Well, what about coming cmake in Qt6? I assume Qt Creator will support cmake
> > based projects for application developers. Do you see a chance to fix the
> > problem using the new tool set?
> 
> Qt Creator has supported CMake for 10 years or more. Building Qt applications 
> with CMake has been officially supported since 5.0.

LOL! Well, sorry, shame on me, I never had a reason to look for anything 
different than
qmake (for Qt development).

Anyway, how does cmake behave regarding the described moc target detection 
problem? Does
it work smarter than qmake?

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Three-file modules vs. moc

2020-09-01 Thread Bernhard Lindner
Hi Thiago!

> Correct, qmake does not preprocess, but it does try to guess what your 
> dependencies are. This is not restricted to moc outputs: any #include found 
> that match a source file is automatically removed from the list of targets to 
> build too.

Oh my! :-(

> A more correct way to do this would be to use GCC's makefile dependencies 
> output flags (-MM, etc.). But I guess no one wants to implement new features 
> for qmake.

You are probably right :-(

Well, what about coming cmake in Qt6? I assume Qt Creator will support cmake 
based
projects for application developers. Do you see a chance to fix the problem 
using the new
tool set?

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Three-file modules vs. moc

2020-09-01 Thread Bernhard Lindner
Hi!

> Add to your module.cpp:
> 
> #include "moc_module.cpp"
> 
> This is recommended anyway, regardless of your problem. Always #include the 
> module output for your headers in your corresponding .cpp files.

I tried a variant of the above using C++17 __has_include:

   #if __has_include("moc_module.cpp")
  #include "moc_module.cpp"
   #endif

My goal was easier module maintenance by automatic inclusion of moc-code in 
case moc found
relevant code in the header. Especially after reworking a module this can be 
easily
forgotten without the above.

Then I get this error: 

   No rule to make target 'moc_module.cpp', needed by 'core_module.o'.  Stop.

I also tried this:

   #if 0
  #include "moc_module.cpp"
   #endif

Same error.

It appears to me that qmake is looking for "#include "moc_module.cpp"" using 
some simple
regular expression which does not take any conditional compilation into 
account. Is this
correct?

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Three-file modules vs. moc

2020-08-27 Thread Bernhard Lindner
Hi Thiago!

> Add to your module.cpp:
> 
> #include "moc_module.cpp"

Works well, thank you!

> This is recommended anyway, regardless of your problem. Always #include the 
> module output for your headers in your corresponding .cpp files.

Can you explain that general recommendation? It seems to me that such includes 
are only
useful in special cases like mine and like .cpp files containing moc relevant 
code.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Three-file modules vs. moc

2020-08-27 Thread Bernhard Lindner
Hi!

> I wonder how clients of the class declared in the .hpp file can use that 
> class at all.
> Unless I am missing something, they won’t be able to (at least not in the 
> general case)
> unless they also include the .inl file.

Depends from what part of the module API you want to use. E.g. if only macros or
types/classes are need, including the .hpp is faster and sufficient. This means 
a .hpp
will typically include other .hpp.

If you want to call functions you will include .inl. This means a .cpp or a 
.inl will
typically include other .inl.

> Wouldn’t it be simplier to #include the inl file in the hpp file? That way 
> you still
> have separation of declaration and definition on a file-level, but don’t 
> expose users of
> your C++ headers (including moc) to your way of organizing things.

Tried that before. Then it turned out that on the .inl level a mutual 
dependency lock can
happen (similar to what you get if normal hpp/cpp modules try to include 
include eachother
without using forward declarations). Only the two-level-inclusion as described 
above
reliably solves all mutual inclusion issues.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Three-file modules vs. moc

2020-08-27 Thread Bernhard Lindner
Hi!

> Can you make an example of your structure (what's exactly in each of the 
> three files)? It's not entirely clear.

Ok, I attached an example of a module containing some pseudo code. Please tell 
me if you
need more information.

> You might also use a custom extra compiler -- that still invokes moc, 
> but for each foo.h also tells moc to include foo.inl, bar.h -> bar.inl, 
> and so on...

Hm, I see. Has something like that been done before, is there code I could 
reuse?

-- 
Best Regards,
Bernhard Lindner

#include "spinbox.inl"

SpinBoxU64::SpinBoxU64(QWidget* pParent) noexcept :
   AbstractSpinBox(pParent)
{
}
#ifndef SPINBOX_HPP
#define SPINBOX_HPP

template 
class AbstractSpinBox : public QAbstractSpinBox
{
   public:
  explicit AbstractSpinBox(QWidget* pParent = nullptr) noexcept;

  T value() const noexcept;
  void setValue(const T& pValue) noexcept;

  T minimum() const noexcept;
  void setMinimum(const T& pMinimum) noexcept;

  T maximum() const noexcept;
  void setMaximum(const T& pMaximum) noexcept;

  ...
};

class SpinBoxU64 : public AbstractSpinBox
{
  Q_OBJECT

  Q_PROPERTY(quint64 minimum READ minimum WRITE setMinimum)
  Q_PROPERTY(quint64 maximum READ maximum WRITE setMaximum)
  Q_PROPERTY(quint64 value READ value WRITE setValue NOTIFY valueChanged USER true)

   public:
  explicit SpinBoxU64(QWidget* pParent = nullptr) noexcept;

   signals:
  void valueChanged(const quint64& pValue);

  ...
};

#endif // SPINBOX_HPP
#ifndef SPINBOX_INL
#define SPINBOX_INL

#include "spinbox.hpp"

template 
AbstractSpinBox::AbstractSpinBox(QWidget* pParent) noexcept :
   QAbstractSpinBox(pParent)
{
   
}

template 
void AbstractSpinBox::setMinimum(const T& pMinimum) noexcept
{
   
}

template 
void AbstractSpinBox::setMaximum(const T& pMaximum) noexcept
{
   
}

template 
void AbstractSpinBox::setValue(const T& pValue) noexcept
{
   
}

template 
inline T AbstractSpinBox::minimum() const noexcept
{
   
}

template 
inline T AbstractSpinBox::maximum() const noexcept
{
   
}

template 
inline T AbstractSpinBox::value() const noexcept
{
   
}

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


Re: [Interest] Three-file modules vs. moc

2020-08-27 Thread Bernhard Lindner
Hi!

> > I added all .hpp file names to the .pro file using Qt Creator. All moc 
> > relevant
> > .hpp files are parsed fine by moc and a moc_module.cpp file is generated for
> > each module as usual.
> 
> Have you tried adding the .inl files to HEADERS instead?

Yes. But it didn't work. Even more undefined references. 

module.inl never contains moc relevant code but module.hpp does. I guess for 
this to work,
moc would need to resolve the contained #include "module.hpp". It generally 
doesn't
resolve includes, does it?

> > Unfortunately the moc_module.cpp files includes module.hpp only, since
> > module.inl are unknown to moc.
> > So all function definitions from moc_module.inl are unknown during
> > compilation of moc_module.cpp and I get undefined reference linker errors
> > (e.g. for property related setters called in the moc_module.cpp code).
> 
> You can let moc add additional includes in it's output via -f argument,
> Custom options to moc can be set in qmake via QMAKE_MOC_OPTIONS. 

Hm. I am not sure I get it. That is a global option, right? I have a LOT of 
modules, each
with a different name. When adding an -f option for each of them, each 
moc_*.cpp file
would include all *.inl includes... which would increase compile time 
exponentially. I
would like to avoid that.

-- 
Best Regards,
Bernhard Lindner

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


[Interest] Three-file modules vs. moc

2020-08-26 Thread Bernhard Lindner
Hi!

Currently I am facing a problem with a Qt Creator managed Qt 5 project.

The projects consists of a lot of modules and implements a special but useful 
file
concept. Each module has 3 files:
   module.hpp - Public types, macros and declarations
   module.inl - Template function definitions, constexpr and inline function 
definitions
   module.cpp - All other definitions
module.cpp includes module.inl and module.inl includes module.hpp.

I added all .hpp file names to the .pro file using Qt Creator. All moc relevant 
.hpp files
are parsed fine by moc and a moc_module.cpp file is generated for each module 
as usual.
Unfortunately the moc_module.cpp files includes module.hpp only, since 
module.inl are
unknown to moc.
So all function definitions from moc_module.inl are unknown during compilation 
of
moc_module.cpp and I get undefined reference linker errors (e.g. for property 
related
setters called in the moc_module.cpp code).

Maybe I could use a lot of Q_MOC_RUN preprocessor conditions to work around but 
that would
pollute the code awfully.

How can I solve this problem on the moc side? Is there a way to tell moc via 
the .pro
project on a per-module basis to include module.inl instead of (or along with) 
module.inl
in moc_module.cpp?

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] List on moderation

2020-07-16 Thread Bernhard Lindner

> Ps: I usually don't read emails from xyz fully, but every now and then, I 
> like the
> critical approach, I just wish that these emails were straight to the point.

Same here.

Roland, maybe you would reach more people if you could make it short and a 
little less emotional?

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Roland Qml

2020-07-15 Thread Bernhard Lindner

> Some of the best programmers I know

Knowing how to program is not important. Knowing software engineering methods is
important. This is something I have learned the hard way when working in a 
functional
safety company for more than three years.

It seems regarding functional safety Roland knows what he is talking about.

-- 
Best Regards,
Bernhard Lindner

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


[Interest] Reason for omitted stream syntax of qFatal

2020-06-28 Thread Bernhard Lindner
Hi!

Can someone tell me why exactly qFatal does not provide the stream syntax that 
was
implemented for qDebug and friends?

-- 
Best Regards,
Bernhard Lindner

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


[Interest] QDateTime::toString() fails when used in exit handler

2020-06-19 Thread Bernhard Lindner
Hi!

I tried to log `std::exit` calls in my GCC10 compiled Qt 5.14.2 application 
under KDE Neon
18.04. This fails when turning a `QDateTime` object into a string. It can be 
reproduced
with the following snippet:

void exitHandler() noexcept
{
   QString b = QDateTime::currentDateTime().toString();
}

int main(int pArgc, char* pArgv[]) noexcept
{
   std::atexit();
   QString a = QDateTime::currentDateTime().toString();
   std::exit(1);

   return 0;
}

Variable `a` contains the expected date/time while variable `b` is empty. When 
using UTC
time, `b` is " GMT". I am not aware of any related restrictions of 
exit-handlers.

Can someone tell me what is going wrong here?

-- 
Best Regards,
Bernhard Lindner

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


[Interest] Connecting signal handler to Qt application - async-handler-safety

2020-06-15 Thread Bernhard Lindner
Hi!

I wrote a logging application containing a signal handler that is registered 
using
std::signal(). The handler receives signals like SIGFPE, SIGSEGV, etc.

Now I would like to connect that handler to some Qt based logging code.
Unfortunately I could not find a portable solution to do that.

Are there any functions in Qt that are considered async-handler-safe? 

I'm especially looking for a way to send a (queued) signal. Other portable ways 
to wake
the application from the event loop would be fine as well.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] CONFIG c++2a vs. QMAKE_CXXFLAGS += -std=c++2a

2020-05-06 Thread Bernhard Lindner
Ok, I see. Thanks a lot Thiago!

Is this documented somewhere?

> > Can somebody please explain the difference between t
> > he following QMAKE
> > project lines when building a GCC project:
> > 
> > CONFIG += c++2a
> > 
> > QMAKE_CXXFLAGS += -std=c++2a
> > 
> > I expected both to have the same effect but there must be a difference since
> > the latter gives me compilation errors while the first does not.
> 
> The latter is equivalent to:
> 
> CONFIG += c++2a strict_c++

-- 
Best Regards,
Bernhard Lindner

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


[Interest] CONFIG c++2a vs. QMAKE_CXXFLAGS += -std=c++2a

2020-05-05 Thread Bernhard Lindner
Hi!

Can somebody please explain the difference between the following QMAKE project 
lines when
building a GCC project:

CONFIG += c++2a

QMAKE_CXXFLAGS += -std=c++2a

I expected both to have the same effect but there must be a difference since 
the latter
gives me compilation errors while the first does not.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] QVariant compare operator

2020-04-20 Thread Bernhard Lindner
Hi!

> In other cases this such silent breakage is called "bug fix"
> and has a positive connotation.

YMMD :-)

For this reason, Qt does not have a formal requirements engineering 
sub-process. Without
requirements, everything is debatable and you can pretty much do what you want. 
Including
defining bugs and features :-)

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] QVariant compare operator

2020-04-20 Thread Bernhard Lindner

> So, if we ever want to have the relational operators in QVariant with
> "better" semantics, we need an upgrade path that clearly signals the
> breakage. Any proposals for that?

qFatal() would be a clear signal. It depends from the actual solution if all 
changes
result in qFatal.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] QVariant compare operator

2020-04-18 Thread Bernhard Lindner
Hi!

> The biggest problem right now is that the behaviour of QVariant 
> comparisons is largely undocumented, that is, dictated by the 
> implementation. Any change to the these behaviours, as sensible as it 
> could be, will lead to silent breakages.

Well, if the chance to create documention during requirements phase was missed 
it should
at least be documented now.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] QVariant compare operator

2020-04-18 Thread Bernhard Lindner
Hi!

> The problem are not missing conversions, but too many conversions.

If it is not possible to document and fix conversions to behave consistently 
(which should
be possible), it still is reasonable to allow >/< comparisons for equal types 
only. That
is easy to implement, simple to document, simple to understand and propably 
better than
removing the feature completely.

However, considering the fact that even ==/!= comparisons with implicit 
conversion do not
work as expected, it is obvious that removing >/< comparison isn't a solution 
to the
underlying problem.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] QVariant compare operator

2020-04-18 Thread Bernhard Lindner
Hi!

> > > Relational comparisons with QVariant are deprecated in 5.15 and will be
> > > removed because they are a misfeaure.
> > > Redesign your code so your question does not need to be asked.
> > 
> > Could you please explain why comparing two QVariants is a misfeature?
> 
> Not comparing for equality. Comparing for ordering.
>
> What comes first, QSize(1, 1) or QRegularExpression("^$") ?

Well, if QVariant::canConvert() says right operand can be converted to type of 
left, then
convert and compare the result. If it can't convert, behavior should be 
undefined and
qFatal() should be called (or whatever Qt 5.15 prefers to do in detectable 
cases of
undefined behavior).

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] QVariant compare operator

2020-04-18 Thread Bernhard Lindner
Hi!

> Relational comparisons with QVariant are deprecated in 5.15 and will be 
> removed because they are a misfeaure.
> Redesign your code so your question does not need to be asked.

Could you please explain why comparing two QVariants is a misfeature?

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

2020-04-02 Thread Bernhard Lindner
Hi Tuukaa!

> TTT: This part is difficult to generally answer, as it depends how these are 
> used and
> what these are used for. Intention of the mixing restriction is to prevent 
> cases where
> someone (e.g. a company) uses the open-source version of Qt in cases where 
> they should
> use commercial version. Typical example of this is a case where only part of 
> the
> developers using Qt together would have a commercial license. We are aware of 
> the fact
> that the way how it is written is such that it might extend further than the 
> primary
> intention. This is a topic that we do not currently have a proper solution 
> for. 

Then you should find a solution. This puts customers / developers / users in 
the situation
that they depend on the goodwill of a for-profit corporation. However, there is 
no good
will in a profit-making business.

It must be perfectly clear that development projects are not affected by the 
fundamental
use of third-party Qt-based applications.

I probably will not use Qt for new projects and I cannot recommend it (but I 
have to add
that this decision is also driven by the fact that the technical priorities in 
the Qt
project have not been in line with my priorities for a few years) .

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

2020-04-02 Thread Bernhard Lindner
Hello Tuukka,

maybe I missed something. Did you answer the following most critical question 
brought up
by Juergen Bocklage-Ryannel and others? From Juergens E-Mail:

> > I guess the conflicting terms are these:
> > 
> > “Prohibited Combination” shall mean any means to (i) use, combine, 
> > incorporate, link 
> > or integrate Licensed Software with any software created with or 
> > incorporating Open 
> > Source Qt, (ii) use Licensed Software for creation of any software created 
> > with or 
> > incorporating Open Source Qt, or (iii) incorporate or integrate 
> > Applications into a 
> > hardware device or product other than a Device."
> > 
> > Especially this combination: “use … Licensed Software with any software 
> > created with 
> > … Open Source Qt”
> > 
> > KDE, doxygen, Wireshark (just to name a few) are using Open Source Qt. 
> > 
> > Can someone reflect how does it apply to that software? Can a customer use 
> > them to 
> > create software under the Qt commercial License terms?

What about this?

> I know licensing in general can be a challenging topic, 

Non-technical terms like "use", "combine", "integrate" and "incorporate" are a 
lawyer's
paradise and make me sit up and take notice. If you want to make things less
'challenging', use techncial terms. Otherwise complaints and distrust will 
never end.

> but I can't help thinking if some people are intentionally trying to twist 
> things 
> around.  At least there are quite many who have not been talking about this 
> in a 
> friendly tone.

No matter if you are wrong or right... if you are writing in behalf of a 
company, such
generalized blames are a cardinal error. If you think a certain person uses 
inadequate
words, criticize directly.

> That said, I hope there are at least some recipients in the mailing list who 
> consider
> this discussion valuable. Unless there is any new actual question, this is my 
> last email
> to the topic. 

See above.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Qt Creator licensing for companies with Qt Commercial developers

2020-03-31 Thread Bernhard Lindner
Hi Tuukka!

> I have also tried to explain these, but your tone feels rather aggressive. I 
> do not
> understand what makes you say: “Even a solo developer needs to hire a lawyer 
> before
> touching anything Qt-related.” 

Because this is what users hear in MLs and forums, when they ask about Qt 
licensing
issues. The recurring answer is: "don't know, don't understand, hire a lawer". 

And because this is written in your FAQ: "It is always recommended to contact a 
lawyer
familiar with open source licenses for a full review of your project to 
determine whether
you can fulfill all of the obligations of applicable open source licenses".

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Handling XML Schemas in Qt without QXmlSchemaValidator

2019-05-21 Thread Bernhard Lindner
It seems that information is not correct.

I started a thread in the development ML and it was said Qt Xml and Qt 
XmlPatterns are in
state "Done" not "Deprecated"!

If that is true, that announcement is wrong and even the documentation about Qt 
Xml is
misleading.

AFAI understand both components can be used. 

> See here: https://wiki.qt.io/New_Features_in_Qt_5.13
> 
> Quote:
> > Deprecated Modules
> > The following modules are part of Qt 5.12 release, but deprecated and 
> > considered for
> > removal in subsequent releases of Qt:
> >  Qt Script
> >  Qt Quick Controls 1
> >  Qt XmlPatterns

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Handling XML Schemas in Qt without QXmlSchemaValidator

2019-05-20 Thread Bernhard Lindner
Thanks a lot for that information!

What a bummer. Again a deprecated module without replacement!? This time one I 
considered essential.
There really is not better way to frustrate developers. Maybe except bad issue 
handling... wait... :-(

Seriously, I do not understand what is going on.

-- 
Best Regards, 
Bernhard Lindner

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


Re: [Interest] Handling XML Schemas in Qt without QXmlSchemaValidator

2019-05-20 Thread Bernhard Lindner

> The QXmlStream[..] classes are part of the Core module. We were talking about 
> the
> QXmlSchema[..] classes, that are part of the XmlPatterns module.

Sorry, confused the modules. Read "Xml" and "Deprecated" and thought of the XML 
DOM classes.
 
Since when is the XmlPatterns module deprected? Is that written somewhere? Qt 
XML Patterns main page doesn't mentioned that.
That one would hit me hard as well should it ever be removed.

-- 
Best Regards, 
Bernhard Lindner

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


Re: [Interest] Handling XML Schemas in Qt without QXmlSchemaValidator

2019-05-20 Thread Bernhard Lindner
> regarding the 'deprecated' state of XmlPatterns: There wont be an further 
> development
> for this module, but I also doubt that it will be removed before Qt 6. 

I hope that will never happen. It would be a disaster.

The streaming classes can NOT replace the DOM based classes for important use 
cases.
Removing them (without an equal replacement) would destroy a lot of 
applications.

-- 
Best Regards, 
Bernhard Lindner

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


Re: [Interest] QFile/QDir: force move mode only?

2019-05-13 Thread Bernhard Lindner
> QFile::rename should rename always or fail! It should never do 
> completely different operation - copy!

I agree. 

-- 
Best Regards, 
Bernhard

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


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Bernhard Lindner

> You were asking when static_casts between int and size_t are needed.
> Interfacing Qt-based code with Standard Library types is one of such cases.

Yes, and it is a nightmare.
But this has been discussed in a different thread before.

-- 
Best Regards, 
Bernhard Lindner

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


Re: [Interest] Operator QMap[] is casting to int?

2019-05-07 Thread Bernhard Lindner

> 1) the the change to qsizetype as an index type has not 
> happened yet, anyhow. It's still a huge question if it's doable in the 
> first place.

It is still discussed? I thought it is pretty high at the priority list anyway.

I mean, if you don't do that in 2020 (Qt6), when will you do it? You can't do 
it in a
minor release, can you? 

x64 is standard in many applications and memory sizes are growing. I have seen 
to many
platforms/frameworks die an early death because developers where afraid to 
enforce
fundamental architectural fixes/improvements (including evolving language)... 
until it was
too late.

-- 
Best Regards,
Bernhard Lindner

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


Re: [Interest] Issue with QSqlModel and QSortFilterModel

2019-04-18 Thread Bernhard Lindner
Did you write an issue tracker entry about that?

> 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

-- 
Best Regards
Bernhard Lindner

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


[Interest] Save and restore a Qt5 QWindow

2019-04-04 Thread Bernhard Lindner
Hi!

With Qt5 the QWindow class was introduced. I would like to store and restore 
the complete
state and geometry of such objects.

I have working Qt4 code that saves and restores the geometry of QWidget based 
windows
(using move(), resize(), windowState(), screenAt(), frameGeometry(), 
normalGeometry()
etc.).

I planned to port that code to QWindow. QWindow provides almost everything 
needed. Alas
there is no normalGeometry().

Is there a way to get the Qt::WindowNoState geometry of a QWindow other than 
tracking
state changes and corresponding geometries for each object (which is an effort 
I would
really like to avoid)?

-- 
Best Regards
Bernhard Lindner

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


Re: [Interest] clang-tidy version in Qt Creator

2019-02-06 Thread Bernhard Lindner
Am Dienstag, den 05.02.2019, 20:33 +0200 schrieb Nikos Chantziaras:
> That's for running the checks live in the code model. For a static 
> analysis run (when selecting "Clang-Tidy and Clazy..." in the "Analyze" 
> menu) performance is not important, and it should be possible to use the 
> system install clang tools there.

I agree. For static analysis flexibility is more important than speed. For the 
code model
it is the other way around.

Alas, I am not sure if such a suggestion would ever be implemented.

-- 
Best Regards, 
Bernhard Linder

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


Re: [Interest] Individual static analysis warning suppression in Qt Creator

2019-02-05 Thread Bernhard Lindner
Hi!

> This is https://bugreports.qt.io/browse/QTCREATORBUG-20201

Again, thanks a lot for your help!

Such a significant defect... still it isn't even evaluated :-(

-- 
Best Regards, 
Bernhard Lindner

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


Re: [Interest] clang-tidy version in Qt Creator

2019-02-05 Thread Bernhard Lindner
Hi!

> > Is there a way to switch/select the clang-tidy version used by Qt Creator 
> > for static
> > code
> > analysis on Linux?
> 
> No as Qt Creator can only use the shipped/customized clang binary for 
> this. While this come with some advantages (performance in case tidy and 
> clazy checks are requested, same lib interface), it does not permit 
> switching versions that easily.
> 
> You would need to wait until we upgrade the shipped clang or compile Qt 
> Creator against a more recent LLVM/Clang yourself.

Ok, thank you very much for the information!

What version does Qt Creator use?
Would it help to create an issue asking for an update?

-- 
Best Regards, 
Bernhard Lindner


signature.asc
Description: This is a digitally signed message part
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest


[Interest] Individual static analysis warning suppression in Qt Creator

2019-02-04 Thread Bernhard Lindner
Hi!

I tried to suppress individual clang-tidy warnings resulting from clang-tidy 
static
analysis runs in Qt Creator.

I added // NOLINT and // NOLINTNEXTLINE comments to my code (both variants, 
with and
without a specific list of checks, like described here: 
http://clang.llvm.org/extra/clang-tidy/#suppressing-undesired-diagnostics) for 
a few
warnings of different warning types but the comments have no effect.

Has someone used those kind of suppression comments successfully in Qt Creator? 
Are they
supposed to work?

-- 
Best Regards, 
Bernhard Lindner

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


[Interest] clang-tidy version in Qt Creator

2019-02-04 Thread Bernhard Lindner
Hi!

Is there a way to switch/select the clang-tidy version used by Qt Creator for 
static code
analysis on Linux?

I have several clang versions installed on my system for evaluation and 
testing. The
different versions of clang-tidy are available as "clang-tidy-7", 
"clang-tidy-8", "clang-
tidy-9" executables. But I could not find a way to select the desired 
executable in Qt
Creator.

-- 
Best regards, 
Bernhard Lindner

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


Re: [Interest] Qt Creator, Clang Code Model, supplying specific GCC symbols

2018-12-22 Thread Bernhard Lindner

> > What is the best/designated way to supply relacement macros for those
> > symbols so the clang analysis succeeds? Is there some configuration/setting
> > in Qt Creator? Should I patch the code? Should I pass this to clang as
> > command line arguments?
> 
> You should contribute the functionality to Clang so that when the code model 
> links to that version of LLVM/Clang, it will know how to proceed.

Is that the only solution? There is no way to work around?

-- 
Best Regards, 
Bernhard

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


Re: [Interest] Qt Creator, Clang Code Model, supplying specific GCC symbols

2018-12-22 Thread Bernhard Lindner
Sorry for asking again... I have not found a solution yet.

I tried to define the macros using #ifdef __clang__ / #endif but it seems 
__clang__ is not
defined during code model parser run. Also all GCC smybols are defined so I can 
not
disinguish clang from GCC. 
I also tried to add a -D argument to the clang command line in the code model 
settings but
the "sanity checks" of Qt creator do not allow that.

Any idea anyone?

> I am using the new Clang Code Model in Qt Creator to highlight violations.
> 
> Recently I introduced some experimental C++20 functions in my code. These 
> functions are
> integrated using a GCC header () that 
> introduces three
> intrinsics that are unknown to clang:
> 
> __builtin_FILE()
> __builtin_FUNCTION()
> __builtin_LINE()
> 
> As a result, the clang code analysis fails (indicated above the editor as a 
> yellow
> warning sign).
> 
> What is the best/designated way to supply relacement macros for those symbols 
> so the
> clang analysis succeeds? Is there some configuration/setting in Qt Creator? 
> Should I
> patch the code? Should I pass this to clang as command line arguments?

-- 
Best Regards, 
Bernhard

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


[Interest] Qt Creator, Clang Code Model, supplying specific GCC symbols

2018-12-20 Thread Bernhard Lindner
Hi!

I am using the new Clang Code Model in Qt Creator to highlight violations.

Recently I introduced some experimental C++20 functions in my code. These 
functions are
integrated using a GCC header () that introduces 
three
intrinsics that are unknown to clang:

__builtin_FILE()
__builtin_FUNCTION()
__builtin_LINE()

As a result, the clang code analysis fails (indicated above the editor as a 
yellow warning
sign).

What is the best/designated way to supply relacement macros for those symbols 
so the clang
analysis succeeds? Is there some configuration/setting in Qt Creator? Should I 
patch the
code? Should I pass this to clang as command line arguments?

-- 
Best Regards
Bernhard Lindner

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


Re: [Interest] Qt Creator vs inline headers

2018-12-15 Thread Bernhard Lindner

> > I can fix that in the MIME settings but it seems to make no sense.
> > 
> > Why is Qt Creator configured that way?
> 
> Because the MIME type says it's source, not header.

Yes. But that doesn't make sense. An .inl file is a header. It contains inline 
code and
especially template definitions. It is compiled by including it (indirectly 
through the
main header) in all translation units using those definitions. It can not be 
compiled by
its own as a source file.

> I had never seen an .inl file and had never heard of that extension being 
> used. So I googled for it and found a couple of examples in 
> https://stackoverflow.com/questions/1208028/significance-of-a-inl-file-in-c.

Yes, that is what I am talking about. And it means the MIME definition is 
wrong. It should be registered as header file not as source file.

Since there is no convention, people use different extensions like tpp, tcc, 
txx, ipp,
icc, etc. Maybe you have seen one of those before.

-- 
Best Regards, 
Bernhard

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


[Interest] Qt Creator vs inline headers

2018-12-14 Thread Bernhard Lindner
Hi!

*.inl files are usually used as cascaded headers containing template and inline
definitions.

Qt Creator handles such files as source files (similar to *.cpp) instead of 
header files(similar to *.hpp). 

I can fix that in the MIME settings but it seems to make no sense.

Why is Qt Creator configured that way?

-- 
Best Regards,
Bernhard

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


[Interest] QTableView behavior; word wrapping plus rows resize to content

2018-12-13 Thread Bernhard Lindner
Hi!

I am using a QTableView with word wrapping enabled and rows configured to 
resize to
content automatically.

Is it desired behavior that the view a does NOT update the row height when 
columns are
manually resized in a way that a cell changes from single-line to double-line 
text (or
vice versa)?

The following line solves the problem:

CHECK_TRUE(connect(ui->tableView->horizontalHeader(), 
SIGNAL(sectionResized(int, int,
int)), ui->tableView, SLOT(resizeRowsToContents(;

However it seems strange that the above does not work out of the box. Is that 
behaviour a
bug?

-- 
Best Regards, 
Bernhard

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


Re: [Interest] Porting Qt to our RTOS

2018-10-01 Thread Bernhard Lindner
Hi!

Forgive me for butting into this off-topic discussion about "true software 
egnineering"
(which is a horrible wording).

AFAI understand that discussion is about quality.

Well, if you want to know how to develop quality software, you need to look 
into safety
(not security!) industry. People which are responsible for other peoples life 
and health
tend to start *really* caring about quality. So if you want to learn about 
methods to
increase software quality, go checking what safety engineers do.

Of course safety is a different and expensive world by its own and you can not 
copy their
methods for conventional software since the effort is too big, but still it 
shows you
which methods are suited to increase quality.

You will see that what Roland states is a part of these methods.

PS: I have more or less given up reporting Qt bugs and suggestions for years. 
Judge
yourself if this a reasonable and/or desired effect of your way of handling 
issues or not.
I miss Qt 4.0.0 times a lot. It was fun back then.

-- 
Best Regards
Bernhard Lindner

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


[Interest] “Qt Embedded” fonts in Qt Creator

2018-07-11 Thread Bernhard Lindner
Hi!

When selecting a font for a widget in Qt Creator 4.6.2, some of the fonts have 
a postfix
[Qt embedded] in their name. E.g. "DejaVu Sans Mono [Qt Embedded]".

What does [Qt Embedded] mean exactly?

-- 
Best Rergards,
Bernhard


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


Re: [Interest] Qt cross plattform installer, offline configuration

2018-04-16 Thread Bernhard Lindner
Hi!

> How do you want to "remove the application" without any type of
> application? In its simplest format, that is what the maintenance
> tool does. You can also call in "uninstall" if that is all you want
> it to do.

Well, the installer itself should provide the function for
removal/uninstall. If the installer doesn't find an existing
installation it should provide Install operation only. If it finds an
existing installationen, it should provide uninstall operation. If it
finds an outdated installation it should provide Update operation.

I know Maintenance tool does this, however I would like to avoid the
installation of additional maintenance tool. I would prefer the old-
school way... implementing the maintenance and deplayoment features in
the installer and the application.

> In regards to 4, that is possible with the Installer Framework, but I
> remember this to be an undocumented feature. I suggest to check the
> source code for that, specifically where the update location /
> repository is specified. That can be a folder on your local disk.

So the Maintenance tool would take the application from the local disk?
Interesting idea.

But how to put the application to the disk after installer has been
started? 

Also the maintenance tool would still be installed (but with a useless
update function) wouldn't it?

> Rejecting to install into an existing directory is a default setting,
> I do not fully remember whether there is an option to disable that.

What a pitty. Anyway, how can an offline update work without that
feature?

-- 
Regards, Bernhard


signature.asc
Description: This is a digitally signed message part
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


[Interest] Qt cross plattform installer, offline configuration

2018-04-16 Thread Bernhard Lindner
Hi!

I am currently reviewing different ways of creating cross plattform
installers for Qt applications (Windows and Linux mainly).

The installers shall work in a classical way, i.e. they shall:
1. work completely offline
2. install no maintenance tool
3. support installing and removing the application
4. be able to do an offline update by running a newer installer
5. work without additional RTEs (like Java)

I consider this a very basic configuration. Still it seems that the Qt
Installer Framework is unable to provide 2. and 4.

At least from what I read in the documentation, in the Qt bug tracker
and in the web, such configuration isn't supported.
Maybe that information is not up-to-date. It seems hard to believe that
such a basic configuration should be a problem.

Regarding the maintenance tool, there seems to be no opt-out config
switch.
Regarding offline-upgrade, the installers seem to refuse installing
into existing application folders.

Is it correct that the above isn't officially supported by the Qt IF?

-- 
Regards, Bernhard


signature.asc
Description: This is a digitally signed message part
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


[Interest] selectionChanged on remove

2017-06-12 Thread Bernhard Lindner
Hi there!

Could someone please explain me some odd behavior of Qt 5.7 models and
the corresponding selection models?

Please start the "Editable Tree Model" example. Remove all rows except
two. Select the first row. Then set a breakpoint to the following line
of function MainWindow::updateActions() in file mainwindow.cpp:

int row = view->selectionModel()->currentIndex().row();

Then remove the first row.

When I do this, I can see that the MainWindow::updateActions() function
is called two times. The first time it is called by the signal/slot
connection from the selectionChanged signal; the second time it is
called from MainWindow::removeColumn() by the application.

The problem: In the first call, the new selected row is 1. This is fatal
because after removing the first of two rows there is no row with index
1 anymore.
The second call to MainWindow::updateActions(), done by the application,
fixes that problem but I wonder why it is necessary.

In my application I have the same behavior except that I totally rely on
the seletionChanged() signal... which is why my application crashes.

Is that actually desired behavior?

-- 
Best Regards
Bernhard Lindner



signature.asc
Description: OpenPGP digital signature
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] QTextStream vs UTF-8 string literals

2016-10-29 Thread Bernhard Lindner
> > http://stackoverflow.com/q/40318671/1421332
> > 
> > It asks why operator<<(const char *string) expects latin-1 strings
> > (especially considering that Qt source files shall be UTF-8 now).
> > 
> > Is that desired behavior?
> 
> No. It's something I didn't notice when I changed the encoding for literals
> in Qt 5.0. See commit cec8cdba4d1b856e17c8743ba8803349d42dc701
> 
> http://code.qt.io/cgit/qt/qtbase.git/commit/?
> id=cec8cdba4d1b856e17c8743ba8803349d42dc701
> 
> > Is there an easy way to stream a lot of UTF-8 string literals (in an UTF-8
> > source code) without wrapping each literal in a QString()?
> 
> No.

Ok, thanks a lot for your answer!

-- 
Regards, Bernhard

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


[Interest] QTextStream vs UTF-8 string literals

2016-10-29 Thread Bernhard Lindner
Please note this questions in StackExchange:

http://stackoverflow.com/q/40318671/1421332

It asks why operator<<(const char *string) expects latin-1 strings (especially 
considering that Qt source files shall be UTF-8 now).

Is that desired behavior?

Is there an easy way to stream a lot of UTF-8 string literals (in an UTF-8 
source code) without wrapping each literal in a QString()?

-- 
Regards, Bernhard

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] What don't you like about Qt?

2016-10-03 Thread Bernhard Lindner
1. New features (quantity) are priorized over bug fixing (quality). Suggestions 
are almost sensless. I reduced writing bug reports and totally gave up writing 
suggestions due to this.

2. Widgets have too low priority. In general new fancy features are priorized 
above bread-and-butter features from my point of view.

3. Components have been declared outdated while the replacements did not 
provide the same feature set. This seriously damages Qt's reputation.

> It's not unusual for us developers and contributors to lose
> perspective of what's important.
> After many years spent on very particular implementation details, it
> becomes difficult to see outside of the box.
> 
> And because we already know the good aspects I'm asking only about the bad.
> No need to discuss or reach an agreement, just go ahead and enumerate
> what you don't like.

-- 
Regards, Bernhard

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Sending mail with line breaks using QDesktopServices::openUrl

2016-08-16 Thread Bernhard Lindner
> Please try xdg-open on the command-line with that URL. My guess is that it
> will fail too, in which case it's not Qt's fault.

It fails in the same way: Body set but no line break.
I also tried KMail directly: Body set but no line break.

So it is probably a problem of KMail. I am using version 5.1.3.

Well, obviously this solution is not reliable. Is there an alternative?

-- 
Gruß, Bernhard

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Sending mail with line breaks using QDesktopServices::openUrl

2016-08-16 Thread Bernhard Lindner
> this opened kmail with the recipient, subject and body being set
> correctly (with line break)

Which KMail version?

-- 
Regards, Bernhard Lindner

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Sending mail with line breaks using QDesktopServices::openUrl

2016-08-15 Thread Bernhard Lindner
> I can't confirm that it works. I tried on the command-line with xdg-open and
> by directly clicking the link above in KMail. Neither time was the body
> present at all.

When using the link in the mail, it doesn't work for me too.
When clicking the same link in a local html file it works.

Very strange.

I also tried Qt 5.7. No change... body visible but no line break.

Well, seems that is getting complicated.

Any ideas?

-- 
Regards, Bernhard

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


[Interest] Sending mail with line breaks using QDesktopServices::openUrl

2016-08-15 Thread Bernhard Lindner
Hi!

I tried to send an e-mail with a prepared subject, receiver and body using Qt. 
The mail shall open in the system default mail client. I am testing on Linux 
with KMail and Qt 5.5.

This is the code I intended to use:

QDesktopServices::openUrl(QUrl("mailto:?
to=t...@test.com=Test=line1%0D%0Aline2", QUrl::TolerantMode));

The mail window opens, subject and receiver are ok. Unfortunately the line 
breaks in the body do not work. I also tried , \n, \r\n but none of these 
worked. I also tried other ways of constructing a QUrl but it only get worse.

It seems not to be an KMail issue because when writing the following into a 
HTML document, opening it in Firefox and clicking the link in the browser, it 
does exactly what I want (including line breaks in the body text):

mailto:?to=t...@test.com=test=line1%0D%0Aline2;>test

Any idea how to solve the line break problem?

-- 
Best Regards
Bernhard Lindner

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Design Issue with QAbstractItemModel & QTreeView

2016-08-04 Thread Bernhard Lindner
I have seen that problem before:

http://stackoverflow.com/q/36412671/1421332

Unfortunately no answer there too.

> I'm not sure what are you talking about. But what about
> beginInsertRows() and endInsertRows()? Between this methods you should
> add new data, and this data can has child rows.
> 
> What is the problem?
> 
> On 04.08.2016 19:48, Sébastien Le Ray wrote:
> > Hi list,
> > 
> > I'm currently designing an application which presents its data in a
> > tree. I have a QAbstractItemModel making a bridge between these data
> > and the view, so far so good.
> > 
> > However I'm stuck when it comes to react to underlying data structure
> > changes, specifically when rows are added and removed. Model has to
> > react before and after the row is added, however, the only information
> > it gets is "row added" signal. Worse, adding a row can add the row and
> > some subitems (some objects creates mandatory children).
> > 
> > What is the proper way to deal with this? Should I have some kind of
> > proxy between the data and the mode?
> > 
> > Regards

-- 
Regards

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Qt ownership model

2016-06-07 Thread Bernhard Lindner
> > All those class names and function names with capital letters don't line
> > up with the standard library, so the argument is not accepted.
> 
> And that's why I /love/ Qt so much and would choose it anytime again over an
> API that_looks &*like_this();

+1

-- 
Regards, Bernhard

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


Re: [Interest] Local version control with Qt Creator on Linux

2016-01-30 Thread Bernhard Lindner
> You shouldn't need to do a p4 checkout for building. If you have to do that,
> then you checked files in that you shouldn't have added.

Thanks for all of the kind answers.
Git obviously is the consensus :-)

I installed git and I can see the "Git" pull-down menu in Qt Creator. I 
selected the "Create Repository" menu entry and chose an empty folder.

Now... how can I add my existing project(s) to that repository? All other menu 
entries of the "Git" menu are ghosted. Seems I can not to anything else than 
creating new repositories.

-- 
Regards, Bernhard

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


[Interest] Local version control with Qt Creator on Linux

2016-01-28 Thread Bernhard Lindner
Hi!

I am experimenting with Qt5 + Qt Creator on Linux Kubuntu. I would like to try 
using the version management integration of Qt Creator.

I don't want to use a public server so I need to setup something local. 

I am not an expert in Linux administration... setting up the server side and 
connecting it to Qt Creator should be pretty simple. Easy backup of the 
repository would be nice.

I have experiences in using SVN (as client side user with Tortoise and other 
clients) and I am very satisfied with it. I am a single user and there are no 
plans of any team work.

What version management software should I try to install in your opinion?

-- 
Regards, Bernhard

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Using QDBusConnection::sessionBus()

2015-12-21 Thread Bernhard Lindner
> Bus is the connection valid? Is it connected?

Yes.

> From what I can tell here, you're doing nothing wrong. The bug is in
> systemd.

Well... that's a pitty. So I will try to achive the same using QProcess 
command line invocations.

I should probably report that in some way. Is it a (K)Ubuntu or a systemd 
issue? I also wonder if it makes sense to report it using a Qt code snippet. 
Would that be commonly understood?

-- 
Regards
Bernhard

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] Using QDBusConnection::sessionBus()

2015-12-20 Thread Bernhard Lindner
Thanks Thiago that you actually responded to that confusing question. I was 
exhausted and didn't add the most important information. Let me try again 
after getting some sleep:

I intended to use QDBusConnection::sessionBus() (Kubuntu 15.10 running 
Qt5.4.2) to access the systemd user session bus like this:

QDBusConnection dBus = QDBusConnection::sessionBus();
QDBusInterface systemDManagerInterface("org.freedesktop.systemd1", "/org/
freedesktop/systemd1", "org.freedesktop.systemd1.Manager", dBus);

That creates an invalid interface. Using systemBus() my code works fine but I 
need to access the user session bus not the system bus.

I tried a lot of things and this is what I could observe:

1 ."busctl --user | grep systemd" lists "org.freedesktop.systemd1" as 
"(activatable)"

2. "qdbusviewer" does not list something that contains "systemd" in its 
"Session Bus" tab.

3. "systemctl --user list-units" works and prints a long list of devices.

4. I installed the systemd settings panel in KDE and the "user units" tab is 
ghosted and can not be selected while the "units" tab works fine.

5. I was able to create a .service file in the "~/.config/systemd/user/" 
folder, and I was able to enable, start and dsiable that daemon using 
"systemctl --user"

I am pretty new to linux and totally new to systemd and D-Bus. And confused.
Any ideas why the above code does not return a valid systemd bus interface 
using sessionBus()?

-- 
Regards
Bernhard

signature.asc
Description: This is a digitally signed message part.
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest