Re: [Interest] QOpenGLWindow inside QSplitter horizontal layout ?
On 21/05/2021 00.02, Nicholas Yue wrote: I am learning about QOpenGLWindow I saw examples which utilizes it via QWidget::createWindowContainer() What examples were those? This seems like a really bad technique. I am wondering if there is a way to house it as a widget inside a layout ? As already noted, use QOpenGLWidget. I suppose QOpenGLWindow makes sense if you are implementing something like an immersive game where you will always, always be rending your entire window content as an OpenGL scene. I can't think of any other reason why you'd want to use QOpenGLWindow. If you are trying to use OpenGL in a portion of a window that is otherwise using widgets (or even just multiple OpenGL views), you almost surely should be using QOpenGLWidget instead. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Designer Plugin : QOpenGLWindow
On 20/05/2021 00.41, Nicholas Yue wrote: I am new to Qt Designer Plugin development. I recently wrote a plugin for a QOpenGLWidget derived class It was successful, I can drag and drop the new widget in Qt Designer I am wondering about QOpenGLWindow. Is that something we can also write a Designer plugin as it is derived from QWindow and not QWidget ? What would that even *do*? Designer is a way to define widgets and layouts that can be added to *your own window*. AFAIK designer *never* specifies the top-level window class. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] L Word
On 30/04/2021 11.20, Jason H wrote: I have mixed feelings about the whole situation. I think Roland is right, or at least has a valid point most of the time, even if it is technical or limited to a specific use case. [...] Personally, I don't understand why if he hates it so much he participates the way he does? Isn't it obvious? Once upon a time, before they "lost their way", Qt was useful to him. He was passionate about *that* Qt and wants it back. I understand *exactly* how he feels. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] L Word
On 29/04/2021 15.24, Ben Haller via Interest wrote: If I'm not mistaken, not a single person has posted to this "L Word" thread in defense of Roland's right to act as he has been acting, have they? Given that we live in a culture where anyone doing so is likely to get banned right alongside Roland, is that really so surprising? We live in a world where dissent from certain positions is simply not tolerated. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] L Word
On 03/05/2021 11.23, eric.fedosej...@gmail.com wrote: I find this whole argument that Qt is not appropriate for functional safety very puzzling. Aren’t vehicle dashboards QtC’s main market these days? What are vehicle dashboards if not safety critical? Are they? I thought it was infotainment systems. There's quite the difference between those two. (At least in most cars; Teslas I think may be starting to blur that distinction, and to an extent that likely alarms some people.) Oh, fun story... before it died entirely, my Prius's dashboard would sometimes fail completely. The car still *moved*, but I had no idea how fast I was going, or how much fuel I had left :-D. Fun times... and an interesting point of discussion for whether or not the dashboard is, in fact, "safety critical". -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Guide me through the Qt offerings for GUIs
TL;DR: We agree that QPlainTextEdit is "bad" (see below for definition
of "bad"). We (apparently) disagree on what's required to correctly
parse a file for syntax highlighting.
On 20/04/2021 15.03, Roland Hughes wrote:
On 4/20/21 9:18 AM, Matthew Woehlke wrote:
On 20/04/2021 09.10, Roland Hughes wrote:
Close on the heels of that "Why are they highlighting the whole
thing?" when you only need the currently visible lines and possibly a
screen up/down. Open up a 10,000 line source file in editors using
Scintilla or the Electron JavaScript based things, or even GUI Emacs
even on an i5-gen3 and you are almost instantly taken to the line you
were on with perfect syntax highlighting.
Frankly, I am skeptical. At best I think you are misrepresenting the
problem.
It's well known that you *have* to highlight the whole file, at least
to the current position, for accurate ("perfect") highlighting. At
least in the general case. There may be some files and/or syntaxes for
which that it not the case, but vim has had partial highlighting for
almost forever, and I've seen it drop the ball on plenty of occasions,
because something earlier in the file changes correct highlighting for
the visible part.
No, it's not well known or even accurate. IF one is taking a student
type approach and attempting to use regular expressions all mushed
together as one nasty bundle, the statement is true.
Let's look at three editors that seem to do it right.
KATE
Well, I find it ironic you include Kate (which really means katepart,
i.e. Kate, KWrite, KDevelop and maybe others), since AFAIK that *does*
highlight the whole file. It also *definitely* uses regular expressions
(and Qt's RE engine, AFAIK), although it also uses a mix of other stuff
optimized for common cases.
But maybe we're talking about different things. When I say "highlight",
what I really mean is "syntax parse". Trying to *render* the entirety of
a large file is, indeed, madness.
...and see my previous comments; QPlainTextEdit was never meant for
that. Frankly, if you are using QPlainTextEdit to hold more than ~16KiB
of text... stop that.
Now lets pick on Featherpad trying to do it "the Qt way"
I'm not sure what you consider "the Qt way". IMHO, katepart *is* "the Qt
way". It's the way (well, *a* way, anyway) any sane person using Qt
would implement a text editor that's intended to be usable with large
documents.
To highlight only the visible subset one simply needs to know the outer
most enclosing boundaries.
Well... yes. And no. The problem is, in order to know those boundaries,
you have to look at *everything* in them. You can't just, for instance,
see a '{' and decide you can skip everything until the next '}', because
that brace might be inside a string literal.
I haven't looked at katepart's guts enough to know how they work or if
they try to employ any clever optimizations. I *have* written
highlighters for katepart, however, and knowing what those look like,
I'm far from convinced that any such optimizations are implemented, or
indeed, even possible. Katepart's highlighting is based on a context
stack, with each detection rule potentially altering that stack. You
can't just skip rules, because doing so means the wrong rule might end
up gobbling some token, which will lead you into a wrong stack state,
and things will just get worse from there.
Of course, this may all be happening in a separate thread, and it isn't
using QPlainTextEdit; katepart I'm almost certain has its own structures
for managing state and keeping track of breaking the text into
highlighted chunks.
Text isn't a stream.
Katepart would disagree. Although the way of *expressing* how to handle
line ends is different from handling other tokens, they are, at the end
of the day, handled almost exactly the same as any other token. The
difference is mainly that the rule to detect a newline is built-in and
uses different syntax to express how said rule should modify the context
stack.
There is no magic that allows you to begin parsing in the middle of a
file. If you do that, you will get something that is *wrong*.
(Admittedly, not always, but sometimes, and vim is proof.)
Moreover, if you insist on expecting "text" to be structured in nice,
neat records delimited by "line breaks", you are going to be in for a
rude awakening when someone decides to try to open a "condensed" XML,
JS, or whatnot. (Katepart *mostly* handles these gracefully. By default,
it gives up at IIRC 1024 characters and forces a line break. You can
raise that limit... admittedly, at your own peril. In a sense, katepart
can get bogged down due to taking the approach you are *recommending*.)
Despite what people say, it's almost always LF CR in a file.
This is trivially disproven by `unix2dos`. Or looking at most text files
crea
Re: [Interest] Guide me through the Qt offerings for GUIs
On 20/04/2021 09.10, Roland Hughes wrote:
Close on the heels of that "Why are they highlighting the whole thing?"
when you only need the currently visible lines and possibly a screen
up/down. Open up a 10,000 line source file in editors using Scintilla or
the Electron JavaScript based things, or even GUI Emacs even on an
i5-gen3 and you are almost instantly taken to the line you were on with
perfect syntax highlighting.
Frankly, I am skeptical. At best I think you are misrepresenting the
problem.
It's well known that you *have* to highlight the whole file, at least to
the current position, for accurate ("perfect") highlighting. At least in
the general case. There may be some files and/or syntaxes for which that
it not the case, but vim has had partial highlighting for almost
forever, and I've seen it drop the ball on plenty of occasions, because
something earlier in the file changes correct highlighting for the
visible part.
That said, Qt definitely does not have a widget that can do a reasonable
job of syntax highlighting a large file. Katepart, which does a pretty
good job, is very much its own implementation of a text editor with very
little high level Qt code involved. (At least that used to be the case;
I think some of the actual text parsing may have moved *into* Qt *from*
katepart. Back when I was involved with it, however, it used Qt for text
rendering and low level input, but I believe all the higher level logic
for input handling and layouting was reimplemented.)
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Guide me through the Qt offerings for GUIs
On 15/04/2021 06.25, Rui Oliveira wrote: I feel very hesitant to start a project on QWidgets. It feels like starting a project on dead tech. I know QWidgets are no longer "interesting". Even KDE moved on from them... Is there an example of a *serious* application that uses QQC? (I don't count plasma-desktop.) Or even, any serious application using something *like* QQC? I'm talking something like gimp, krita, libreoffice, inkscape, thunderbird... AFAIK all of these — indeed, everything to my knowledge that I use on a regular bases — use Qt Widgets or something similar. -- Matthew ___ 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
On 28/03/2021 09.52, Jason H wrote: The developers at Qt Co need to push back and tell Digia "that's not how this works" before we get to the points of users revolting in threads on the forums / lists. *Before*? I guess this thread, and the multiple others like it, are then discussions on the variation in carrying capacity of English and African swallows. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 24/03/2021 18.25, Thiago Macieira wrote: On Tuesday, 23 March 2021 09:02:04 PDT Matthew Woehlke wrote: On 23/03/2021 11.44, Volker Hilsheimer wrote: I wished I had seen the level of energy y’all are putting right now into this email thread over the last two years when we discussed where to go with Qt 6, and when the work actually happened. IIRC, I complained plenty about QList at the time. I wouldn't be surprised if I complained about QHash also. And lo and behold, QList and QHash are completely rewritten for Qt 6, because of the major complaints that existed against them, especially against QList. Wow, you *totally* misunderstood that. QList in Qt5 is mostly fine (and there's always QVector if needed). Qt 6 got rid of a useful container type. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience,, methods
On 24/03/2021 09.45, Volker Hilsheimer wrote: On 24 Mar 2021, at 13:20, Roland Hughes wrote: death of OpenSource LTS Get the patches you need from the dev branch. Wait, so is TQtC *asking* the community to fork Qt? Because that's how this reads: 'TQtC has killed open source LTS; we (TQtC) won't provide any such thing, but we hope someone else will step up to do so'. I started a new one were we can focus on substantial and constructive conversation about what needs to be brought back to make Qt 6 better and porting easier. Step 1: make a Qt 6 that is usable. Yeah, I know, "working on it". The problem is more that you forgot Step 0: don't kill Qt 5 until Step 1 is complete. -- Matthew ___ 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...)
On 24/03/2021 09.46, Giuseppe D'Angelo wrote:
And anyways these methods are still fully supported within Qt 5.
Tell that to all the people that compile with -Werror. Or just want
their code to compile without being full of warning spam.
"Just ignore it" may not be an option; sometimes there are *policies*
that preclude this.
...And, again, even that would be less of an issue if it didn't require
different code to support 5.14 and 5.15.
Yes, it does not generalize to every possible container type, but I
don't know that anyone is asking for that (and I agree we shouldn't try
to support that).
All the contrary, this is one big crux of the problem: toX() for a
completely arbitrary closed set of X is bad API. Why QSet::toList and
not toVector? Why QList::toSet and not, say, MULTI sets?
Because history. If you want those, do them the "right" way. Meanwhile,
don't "break" existing code.
Again, I think a lot of the reason folks are making such a big stink is
because we had:
5.14: toSet() is fully supported, no alternative is available
5.15: toSet() is deprecated, use ...
6.0: there is no toSet()
If things had *instead* looked like:
5.9: toSet() is fully supported, "better" alternative is available
5.12: toSet() is deprecated, "better" alternative is available
5.15: same as 5.12
...we might not be having this conversation.
We're not talking about adding many, many variations
upon this theme, just*not* removing the ones that already existed. The
ones that do exist, exist because they are more convenient to use, and
because they cover*the most common* use cases.
Can I hear some use cases then please? Because from the experience of
usages within Qt, it was a nail/hammer problem, call it an education
problem ("I know containers; I don't know algorithms; let me use
containers to solve an algorithmic problem"), of which we're entirely
responsible (Qt docs teach a lot about containers, but not about
algorithmic design.)
An example I know offhand:
https://github.com/Kitware/qtextensions/blob/0ff5b486f08435c8cdfbc9f05d2f104f63b16aed/util/qtUiState.cpp#L268
Yes, in fairness, using a set to de-duplicate is arguably an algorithm
problem. OTOH, I'm not sure I really want to trade hashed lookup for
generating a collection of an unbounded number of duplicates. Also, yes,
most programmers probably don't know offhand how to de-duplicate a
collection using algorithms. (I'd also want to see performance numbers
that the latter approach is actually more efficient, because offhand I'm
not *at all* convinced it is, and wouldn't be surprised if it's *worse*).
The reality is that using containers to solve algorithm problems (e.g.
"I'm using a map because I need the values to be sorted") is extremely
common.
Ranges will fix some, but not all, of this.
Miscellanea examples from Qt itself,
* I need to remove duplicates from my list, let me do:
list = list.toSet().toList();
Right. Although note that the above example is doing a multi-merge with
de-duplication, so the "use a set as an intermediary" approach has a
better chance of being more efficient, since each merge will never
result in duplicates existing in the collection in the first place. I
agree that the above example is probably not optimal.
In any case, I'm not convinced that removing API is the solution to this
problem. It seems more like something for clazy to complain about.
* I need to keep the list, process it in order, but avoid processing
duplicate elements; 99% of the time the list is a handful of elements;
let me do
QSet s; for (elem : list) { if (!s.contains(elem)) { s.insert(elem);
process(elem); } }
And what, exactly, is the solution here?
* I've got a square peg (a QList) and a round hole (an function I made
that takes a QSet), so I need conversions to call it.
And what, exactly, is the solution here? Probably "ranges", but those
aren't available yet.
--
Matthew
___
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...)
On 24/03/2021 07.17, Giuseppe D'Angelo via Interest wrote:
On 22/03/2021 17:19, Thiago Macieira wrote:
I thought we'd fixed that and reverted them. Or didn't we add
toContainer?
Peppe, what was our final conclusion here?
There was no conclusion reached, unfortunately, and didn't manage to
provide a replacement in time. I was (and still am) afraid at simply
reintroducing .to() functions.
One reason is purely API quality: implementing them "correctly" in
C++14/17 without ranges/concepts is not exactly funny (just look at the
ranges::to proposal for how many corner cases are there to consider),
and there's indeed already ranges-v3::to as the ready-made solution (so
why spending time redoing it).
Huh?
Let's take e.g. QList::toSet as an example. The deprecation message says
to use `QSet(list.begin(), list.end())` instead. How, then, is the
correct implementation *not*:
QSet QList::toSet() { return QSet{begin(), end()}; }
What was so hard about that? If that's wrong, then so AFAICT is the
deprecation message.
Yes, it does not generalize to every possible container type, but I
don't know that anyone is asking for that (and I agree we shouldn't try
to support that). We're not talking about adding many, many variations
upon this theme, just *not* removing the ones that already existed. The
ones that do exist, exist because they are more convenient to use, and
because they cover *the most common* use cases.
Oh, another problem I've run into is that the replacements for a lot of
these deprecated methods aren't even available until the same version
that deprecated them. That makes it a PITA to write warning-free code
when we have to support older versions of Qt.
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 23/03/2021 11.44, Volker Hilsheimer wrote: I wished I had seen the level of energy y’all are putting right now into this email thread over the last two years when we discussed where to go with Qt 6, and when the work actually happened. IIRC, I complained plenty about QList at the time. I wouldn't be surprised if I complained about QHash also. One of the reasons I don't try to contribute more than I do is because, when I *have* contributed patches, it hasn't accomplished anything. So far, all I've seen is "C++ also deprecates stuff". You haven't shown that the deprecations are actually *harmful* to the C++ community. > Personally, I’m siding with those folks in the committee that believe that not changing things (ref ABI discussion) is more harmful than if we’d be able to fix now and again what is objectively broken. Likewise. I've even said before that it might be beneficial if C++ could more aggressively deprecate bad stuff, even mentioning Qt as an example to follow. Not all deprecations are bad. However, I still maintain that *some* of the Qt 6 changes are problematic. Also, TBH, I think the real issue is less that Qt 6 made changes, and more that Qt 5 support got pulled well before Qt 6 is viable for most folks. That didn't happen with Qt 4 → 5. I also don't recall Qt 4.8 suddenly deprecating a bunch of stuff that was immediately removed in Qt 5.0, although I may be wrong about that. I personally wonder why people that never want to change what they built last year want to develop software development. Isn’t that what makes building stuff out of bits and ideas so much more interesting than building stuff out of sticks and stones? Is this really so surprising? People want to spend their time making *their* software better, not chasing an ever-shifting foundation on which their software is *built*. Time spent adapting to library changes, especially changes seen as unnecessary or actively harmful, is time *not* spent developing new and exciting features, or even squashing existing bugs. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 23/03/2021 10.36, Benjamen Meyer via Interest wrote: On 3/23/21 10:09 AM, Matthew Woehlke wrote: Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any change, not just on a mailing list, but in person. Anyone can, in theory (in practice, depending on where you live, there may be a non-trivial membership fee required) *vote* against a change. We, as the committee, generally try to be considerate of the community when making changes, and there is quite a lot of emphasis on not breaking existing code, even as far back as C++98. How many C++ devs are on those? Hundreds, which is probably more than the number of people making decisions for Qt. Likely only those whose companies are paying them to be, and a few that got there via academics (I've personally known and worked with one person; outside of the folks I've seen here on the Qt lists.) Even so, that's a lower bar than "you must be an employee of TQtC" (and even that is probably not sufficient). The bar also happens to be much lower right now due to COVID, since there are no in-person meetings happening. In any case, you've made an unsubstantiated allegation that the committee does not care about C++ users. Please provide evidence to back that up. So far, all I've seen is "C++ also deprecates stuff". You haven't shown that the deprecations are actually *harmful* to the C++ community on anything like the scale to which Qt's recent changes have been harmful. Deprecations, even in Qt, aren't always bad. Some recent Qt deprecations, however, have caused major pain. Now you are apparently claiming that C++ is "just as bad", but I have yet to see that claim substantiated. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 23/03/2021 09.16, Michael Jackson wrote: Having read this entire conversation I find it interesting that we as developers are complaining about features being deprecated and removed in Qt but yet where is the anger when C++ spec removes features? Oh, it's there. However, C++ is *far* more conservative than Qt about what it removes, and most of the removals are genuinely unuseful. (Seriously, *trigraphs*? Are *you* using trigraphs? Or auto_ptr?) If you're seriously going to advance this argument, you need to point out one or more *specific* changes that you believe are harmful. Even then, chances are your compiler will continue to support that stuff for another 10 years. Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any change, not just on a mailing list, but in person. Anyone can, in theory (in practice, depending on where you live, there may be a non-trivial membership fee required) *vote* against a change. We, as the committee, generally try to be considerate of the community when making changes, and there is quite a lot of emphasis on not breaking existing code, even as far back as C++98. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 23/03/2021 06.59, Roland Hughes wrote: 30 years is __nothing__ for production systems. It is ordinary for a well developed system to run 10+ years without any modifications. On that note, how many people are aware there's a computer that has been running non-stop for almost 45 years? :-D You kids and your uptime measured in hours... The phone world [...] [is] actually how this downward spiral started, with the introduction of QML and forcing people to re-write, re-write, re-write. That does, indeed, seem to have been the turning point. The Qt OpenSource model simply does not work. It cannot really be made to work. You can't pursue licensing from lone wolfs and shoestring startups and expect well run legitimate companies to have any respect for you. It's not going to happen. 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. Here, however, I'm going to have to disagree. I fail to see why the open source version can't be the latest and greatest, so long as the paid support *does* actually provide support, as you're saying. (Dislaimer: This is my employer's business model. It seems to be working quite well for us.) What I think it broken is the commercial licensing model. Either pay for support (and *get* support), or don't pay, and get whatever the community gives you. I'm not actually convinced that paying Qt customers aren't getting the support they paid for; that information is generally not going to be publicly available. What *is* broken is the alimony licensing model and all the fear-mongering around the licensing terms. *Proper* commercial support for open source products lets you try before you buy with no punishment afterward, no penalties if you want to drop support later, or drop it and pick it up again. You pay, you get support, *period*. For that matter, it seems like Qt's commercial model is working just fine *for them*, at least at the moment. Ironically, the arguments you are making probably are *why* it's working. The problem is that they're busy killing the community and doing severe, possibly irreparable damage to Qt's reputation. It's highly doubtful that any company could pull in the staff to maintain all of the markets and eliminate all of the bugs, but that would have to be the starting point for such a venture. Right, which is why we *need* a community, or a consortium, or something of that nature. We need everyone that cares about what Qt *could* be, without Digia's efforts to break it, to pool their resources. I believe that if we could pull that off, Qt can still have a bright future. Because they don't have bugs that have been rotting for over a decade, CopperSpice went to a support and consulting contract only model. It seems to be working. I haven't much looked into CS, but that sounds plausible. Again, that's basically how my own employer works. It's a perfectly functional business model for organizations with the commitment and ethos to pull it off. I'm also not sure how much I *want* to look into CS. The CoW stuff scares me, and I think they've gone too far in throwing out the good parts of Qt with the bad. There are quite a few changes in Qt5 that are good (the new OpenGL framework for one, not to mention all the C++11 related changes). Ditching MOC is IMO questionable, especially when the overhead of MOC is so negligible these days. No, I don't for a moment think QML is on that list :-). I looked at it once, briefly, and didn't see the point, and you're probably right about how it adds too much complexity for whatever dubious value proposition it might have. (For that matter, I'd like to see all the style sheet crud ripped out of Widgets as well.) Medical devices, industrial controls, even desktop apps want a long stable platform. Phones only care about what is shipping next week. Yup, and this is the same reason why I loathe and want nothing to do with web development. Learning a new "platform" every month is a waste of time. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 114, Issue 23
On 23/03/2021 01.21, Tuukka Turunen wrote: Feedback on the Qt 6 API is valuable and we are very interested in it. Portability was one of the key design principles and we have avoided making changes when not needed. That said, there can surely be some items that are unnecessarily changed. Why are the QHash changes needed? The main outcome of that seems to be encouraging people to use std::unordered_map instead and destroying trust in Qt's API. Why is QList removed? (I don't mean the *name* "QList", I mean the container with indirect storage and reference stability. It's useful, and unlike QHash, there is no STL equivalent available.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience methods
On 22/03/2021 23.18, Jason H wrote: Qt needs to go back to LGPL, or risk getting abandoned/replaced. Seems like some of the long time users here on this list have come to a similar conclusion. I've said this before, and I'll say it again: Qt needs to go the way of OpenOffice.org. That is, we need some folks to step up and decide that we're through with TQtC and we're going to continue Qt on our own, very possibly from 5.15, as pure LGPL. It probably isn't possible for contributors to retract rights already given to TQtC, but stop giving them new rights. Stop contributing under a CLA. It would help tremendously if KDE was on board; wherever they go, the community will probably follow. Right now I'm worried that they're headed toward oblivion, which would make me really sad, because I do *not* care for Gnome. (That's not to say I think Gnome developers or users are terrible people, I just *personally* don't care for it.) (I'd love to take CMake from 6.x, but I'm not exactly neutral in that respect, particularly as I've never used qmake. I'm not sure how much else from 6.x would be worth keeping. *Maybe* some of the move toward QVector. *Not* the total removal of QList, or the changes to QHash.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Mixing Commercial and Open Source license for, different, projects
On 18/03/2021 08.10, Roland Hughes wrote: https://www.logikalsolutions.com/wordpress/information-technology/qlist/ You can also take a big hit if there happens to be 100+ things referring to this particular value instance when it needs to change. Think a working/scratch object you load a “default” value into from some external source then use to initialize a hundred element list. Not an integer, but a substantial object like a page of text or a QPixmap image. Later on in the code your working QPixmap needs to load a different image. That image pays the price. A hundred copies now have to be made before the first image change can happen. The second image change pays no such price so it is very fast. Uh... that's not true. When you need to change a shared object, the one *being changed* gets copied. The other 99 continue to point to the old object, the new one points to a new object that you just created. *One* copy, not one hundred... which you needed to pay for anyway; CoW just delays payment until you definitely need the copy instead of when you logically make the copy. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Odd focus behavior with multi-widget item delegate?
I have a QTreeView with a complex (consists of multiple widgets) item delegate for some columns. This behaves strangely. For example, the enter key seems to "finish" editing, but causes the cell to render in inactive colors (gray bg), while the rest of the row renders in active colors (blue bg). Clicking away from the editor causes it to lose focus but not go away. How do I fix this? The delegate creates a custom widget type that is basically a QWidget containing a QDoubleSpinBox and a QComboBox. (It is a value picker that allows the user to also specify units via the combo box. No, I do *not* want to mess with trying to subclass QDoubleSpinBox to allow the units to be typed, both because of the code complexity, and because typing units will be more obtuse for users.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] how to get and purge events from queue?
On 05/11/2020 12.24, Jérôme Godbout wrote: Maybe you can add an event filter and remove some of the events if they are happening too close to each others. But I thing doing that logic into the event handler is a betetr idea, where you can either cumulate and delay execution of the behavior. This. Separate your logic that decides an update is needed from the logic that actually does the update, and have the former *queue* (if not already queued) an event to do the latter. I've used this technique on quite some occasions and IIUC Qt uses it internally when repainting widgets (n.b. QWidget::update). If possible, also move some of that slow logic to a different thread... -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Matching borders between QFrame and QGraphicsView
I'm doing some heavily tweaked rendering, and having trouble getting frames to render correctly. In particular, I have (subclasses of) QFrame and QGraphicsView. The QGraphicsView seems "mostly" sane except that I can't get it to use all the way to the widget's outer edge... but that's not necessarily the end of the world. The problem I'm having is that QFrame has the same issue, but here, I *do* need it to use all the way to the edges of the widget. I can make that happen by fiddling with the contents margins... but then I run into problems. If I adjust the contents margins, I can get the frame to use its entire size, *BUT* this also pushes the frame border outside the widget. I can compensate by tweaking the render code... but then the QGraphicsView is wrong, because changing the contents margins on that has no effect on the frame. Why does the behavior differ, and how can I fix it? (I'd rather not have to tweak the style rendering to have to be sensitive to what QFrame subclass it is drawing...) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QPainter::drawRect incorrectly "rounds" corners
On 21/10/2020 13.16, David M. Cotter wrote: are your pixels specified in floating point? have you accounted for the half-pixel offset? Yes (although there's a related story there; sigh). Turns out the default corner style is... unhelpful. Ick. I still think there's a bug; the corners should at least all be the same... -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] QPainter::drawRect incorrectly "rounds" corners
I'm implementing a custom widget style for an application, and running into a strange problem with QPainter::drawRect. Namely, it is not making the corners square. This may be a problem specific to high-DPI displays and/or using a pen width more than one physical pixel. The corner *should* look like this: # # ## ## ## ...but it looks like this: # ## ## ## Oddly, only the *left* corners have this issue; the *right* corners are correct. How can I fix this? p.s. On a hunch, I tried ensuring that antialiasing was *off*, but that had no effect. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Suppress titlebar of dock widget?
On 08/09/2020 15.41, Sérgio Martins wrote: On 2020-09-08 19:46, Matthew Woehlke wrote: I have a dock widget that cannot be moved, closed or floated (essentially, I need something that takes up the dock corner preferentially), but I want it to *not* have a titlebar. Is there a way to accomplish this? Note: I am also implementing my own QStyle. My initial idea was to tweak the QStyle to detect this widget and fiddle with the size/metrics (I don't need exactly zero pixels; if I can make the titlebar 1-2 pixels tall, that is good enough), but my attempt to make the titlebar smaller/hidden that way is not working... However, I'm not sure if I know what to change. So far I have fiddles with the pixel metrics and subcontrol rects, but I don't see anything else I can affect? https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qdockwidget.cpp.html#537 It's using the height of the font, so no matter what you do, you can't. Ah, well, answers that question anyway.; thanks. QDockWidget::setTitleBarWidget() sounds good for you, as long as you never float it, as that brings other problems. Not a problem; this particular "dock" isn't floatable either. The only reason I'm even using QDockWidget, really, is because I want this: ┌──┬┐ │ ││ │ ││ │ ├┤ │ ││ └──┴┘ ...and not this: ┌──┬┐ │ ││ │ ││ ├──┴┤ │ │ └───┘ ...where the bottom panel is (also) a QDockWidget. (In that case, one that *can* be floated or closed.) In all other respects, though, I want the side panel to be a fixed UI element. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Suppress titlebar of dock widget?
On 08/09/2020 14.46, Matthew Woehlke wrote: I have a dock widget that cannot be moved, closed or floated (essentially, I need something that takes up the dock corner preferentially), but I want it to *not* have a titlebar. Is there a way to accomplish this? Note: I am also implementing my own QStyle. My initial idea was to tweak the QStyle to detect this widget and fiddle with the size/metrics (I don't need exactly zero pixels; if I can make the titlebar 1-2 pixels tall, that is good enough), but my attempt to make the titlebar smaller/hidden that way is not working... However, I'm not sure if I know what to change. So far I have fiddles with the pixel metrics and subcontrol rects, but I don't see anything else I can affect? It seems like there must be a way to control this, as I'm pretty sure I've seen styles with different sized titlebars! Sigh. Should've checked SO: https://stackoverflow.com/questions/18918496. Apparently, the answer is 'replace the titlebar widget'. ...but I'm still curious why I can't get fiddling with the style to have any effect? -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Suppress titlebar of dock widget?
I have a dock widget that cannot be moved, closed or floated (essentially, I need something that takes up the dock corner preferentially), but I want it to *not* have a titlebar. Is there a way to accomplish this? Note: I am also implementing my own QStyle. My initial idea was to tweak the QStyle to detect this widget and fiddle with the size/metrics (I don't need exactly zero pixels; if I can make the titlebar 1-2 pixels tall, that is good enough), but my attempt to make the titlebar smaller/hidden that way is not working... However, I'm not sure if I know what to change. So far I have fiddles with the pixel metrics and subcontrol rects, but I don't see anything else I can affect? It seems like there must be a way to control this, as I'm pretty sure I've seen styles with different sized titlebars! -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Making a bunch of labels the same width?
I have a custom widget that internally consists of a couple other widgets, including a QCheckBox, in a horizontal layout. I have another custom widget that provides a collection of these in a vertical layout. I'd like to arrange for everything to line up neatly. (Because of the hierarchy, it would require non-trivial refactoring to use a grid layout instead of nested layouts. Also, the 'sub'-widget is meant to be usable in other contexts that might not have a parent layout, or would have some other layout.) My offhand idea is to set a minimum size on the QCheckBoxes, but I'm not sure how to go about getting the minimum size (since it isn't computed yet at the "obvious" points to ask for it). Is there an easy way to make the labels (QCheckBoxes) the same width? -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] [Development] Windows 7 support will be, dropped in Qt 6
On 18/06/2020 11.11, Roland Hughes wrote: Could someone from such a background learn enough C syntax to write a student C program like this one? [example program elided] Maybe. To the point various others are making, just because someone hasn't learned the fundamentals doesn't mean they're incompetent. OTOH, not everyone can learn competence. The point is, *you just don't know*. Could that same person write a page swapping system for a Linux-like OS from scratch? No. Again, *maybe*. Not, perhaps, without learning the fundamentals first, but as noted, just because they haven't learned *yet* doesn't mean they can't. But, again, there are plenty of people that can muddle through basic stuff with "training wheels" languages that *can't* grasp the fundamentals well enough for such tasks, and that's the point you (Roland) and I are making. When one comes from the scripting/interpreted language background; especially if they never got a degree from a good school that taught them proper fundamentals of software development; that is the training wheels never off the bike. Put them on C. No garbage collection. Requires proper understanding of the fundamentals, especially Application Design, System Architecture, and Data Structures. Basically it requires the skill to ride a bike that goes very fast and can never have training wheels put on it. Yup... Some can figure it out. Some won't. To be fair, I might be in the latter category. I don't recall *formally* learning much about memory management (although there was some generic algorithms stuff); nevertheless, my first professional job was pure C and I managed well enough. I'd like to think I'm competent, if not amazing. As an example, I don't consider deleteLater a major source of headaches (and most of my stuff *does* run on reasonably modern machines). Almost always if I use deleteLater, it's because I *know* that I can't just delete it *now*. I'm aware of needing to ensure that objects are either a) not deleted while in use, or b) are always referenced through *checked* weak pointers. (Right now I'm working on unit tests for a non-Qt signal/slot system that needs to handle race conditions between the signal being emitted or destroyed at the same time the receiver is destroyed. Fun times, but not a problem outside of my experience, as it would be for someone that only knows Java/Python/etc.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6
On 16/06/2020 18.59, Jonathan Purol wrote: it's well "known" that you can teach C programmers Java, but you can't teach Java programmers C How is that well known? What studies can you provide for this? No studies, but it seems to be a common attitude among most or all technical professionals with which I've worked. That said, yes, there is some exaggeration there. Obviously, some people *can* learn "real" programming regardless of what they started out doing. The fact is, however, there are plenty more people that *can't*; people that can only perform certain tasks with the help of technological "crutches". For evidence, look no further than the large number of people that struggle with basic arithmetic. You may be blessed to not have to work with many of these people (indeed, they aren't the sort of people that make desirable employees in any case). What I was saying was intended to reflect Roland's point, which is that there are plenty of people that can muddle through "programming" tasks when you give them an "easy" language (e.g. "Qt6" QML + javascript) that are in over their heads if you ask them to do something in e.g. Qt3 + C++. Yes, there *are* people that can learn, but they are less common than the muddlers that can passably do the former job and are hopeless when it comes to the latter. I think the *real* point is that if none of your candidates already know "real" programming, it can be difficult to separate the ones with real underlying skill from the muddlers. Most of my local universities teach Java, do you want to imply those people will never ever be able to learn C? All of them? No. *Some* of them? Absolutely. People can learn, people can change. All that's required is the incentive to do so, which is probably where you should have put your argument at instead: If Qt migrates away and drops win7 support, you get fewer and fewer people over time that have the incentive to learn the skills required to still develop for older versions. That was, indeed, part of the point. However, I also believe that not everyone is capable of every task, no matter how incentivized. (Plus, not everyone has the necessary determination.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] [Development] Windows 7 support will be dropped in Qt 6
On 15/06/2020 14.26, Jérôme Godbout wrote: If your developer have hard time learning Qt3 to Qt5, I feel sorry for you You have that backwards. Kids who only learn the new stuff can't be hired to support the old because they cannot even begin to function. I suggest you hired from different schools. While that may be a valid suggestion, it's well "known" that you can teach C programmers Java, but you can't teach Java programmers C. Most "skript kiddies" lack the technical foundations to understand "real" programming. Unfortunately, not so many schools turn out programmers with the required backgrounds. This is the equivalent of turning out "mathematicians" that can punch buttons on a calculator but don't know how to actually do math if you take away their gadgets. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Handling of ~ paths
On 11/06/2020 14.33, Scott Bloom wrote:
On 11/06/2020 14.24, Matthew Woehlke wrote: >> On 11/06/2020 14.03, Scott Bloom wrote:>>> If you are working with a
path, for use in QDir, QFileInfo, QFile etc>>> etc, and the path string
is using a ~, either of the form ~/foo.txt or>>> ~user/foo.txt, Qt seems
to be treating it as a relative path of the>>> current user, and
prepends “/home/scott” in my case to the path,>> >> Uh... yeah? A path
starting with "~/" or "~/" has been "shorthand">> for that user's
home directory ("~/" → current user) for decades.> > Maybe I wasn’t
clear, that is 100% exactly what I would expect.
But instead what is returned is "/home/scott/~/foo.txt"
Ah, I see, what you mean is that *the current working directory* is
appended. (Which in your example is $HOME, which confused me, since
replacing ~ with $HOME is expected.)
Yeah... well, the bad news is that tilde expansion (not unlike variable
expansion) is usually a shell function and/or needs to be invoked
manually, rather than an OS function. It appears that QFileDialog also
does the expansion, but if your path comes from another source, I guess
you need to do it yourself.
So you are basically asking the same as
https://stackoverflow.com/questions/1833261/qt-expand-to-home-directory.
Unfortunately, the answer there does not appear relevant.
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Handling of ~ paths
On 11/06/2020 14.03, Scott Bloom wrote:
If you are working with a path, for use in QDir, QFileInfo, QFile etc
etc, and the path string is using a ~, either of the form ~/foo.txt
or ~user/foo.txt, Qt seems to be treating it as a relative path of
the current user, and prepends “/home/scott” in my case to the path,
Uh... yeah? A path starting with "~/" or "~/" has been "shorthand"
for that user's home directory ("~/" → current user) for decades. I'm
not sure what you were expecting?
$ cd /
$ ls -d ~
/home/matthew
and of course, the canonicalPath returns an empty string because that
file path is invalid and doesn’t exist.
Why is it invalid? Did you somehow manage to have your home directory
not exist?
What is the Qt way to handle this? It cant be to tell your users not
to use ~. Can it?
If your intention is to treat "~/foo" as a relative path, the first
component of which is literally "~", then... yeah, don't do that; that
isn't the "traditional" interpretation of such a path. If that's what
you want, use "./~/foo" instead. (If you just need to suppress tilde
expansion, you may be able to check for paths that start with "~" and
always add "./" to the beginning of them. Beware, however, that users
that expect tilde expansion to work may be confused or annoyed.)
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] CMake AUTOMOC & Windows linking
On 15/05/2020 11.17, Andy wrote:
I'm running into a link problem on Windows. I only have Windows on CI, so
debugging this is... challenging.
- cmake 3.10+
- AUTOMOC is ON for the project in the top level cmake file
- Dynamic Library "A":
class LIB_IMPORT_EXPORT Foo
{
Q_OBJECT
...
where LIB_IMPORT_EXPORT uses Q_DECL_EXPORT/Q_DECL_IMPORT properly
depending on who's building.
This isn't necessarily your problem, but if you're using CMake, I would
recommend using generate_export_header to define your ABI decoration
symbols rather than rolling your own using Q_DECL_EXPORT/Q_DECL_IMPORT.
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Writing custom Qt Widgets is overly complicated
On 28/04/2020 06.04, Jonathan Purol wrote: Hello everyone, I'm at a bit of a rough point right now. Up until this point Qt has never disappointed me - everything I wanted to do was possible to do in a seamless and understandable way. Yesterday however I put my hands on trying to implement my first custom widget. The item in question is what I would describe as a "Tag Textfield". You can find an example of this when asking a question on stack-overflow at the very bottom. [...] I think you may be taking a poor approach. My knee-jerk reaction is that you should be using a custom object in a rich text edit. While this appears feasible for rendering, it seems¹ that mouse handling is not well thought-out. (¹ https://stackoverflow.com/questions/22538270) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] How to get icon theme?
On 21/04/2020 14.57, Matthew Woehlke wrote: How do I determine what icon theme my application is using? QIcon::themeName() just returns an empty string. (But QIcon::fallbackThemeName() says "breeze"!) I am actually using "breeze-dark", and if I don't do anything, I get icons from that theme. I need to know because my application will use its own theme in order to provide additional icons and a consistent look within the application, so I need to be able to kick the system theme down to the fallback theme. (If I leave it as "breeze", I get illegible icons due to my color theme.) Since no one here has answered yet, maybe SO will have better luck? https://stackoverflow.com/questions/61367582 -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] How to get icon theme?
How do I determine what icon theme my application is using? QIcon::themeName() just returns an empty string. (But QIcon::fallbackThemeName() says "breeze"!) I am actually using "breeze-dark", and if I don't do anything, I get icons from that theme. I need to know because my application will use its own theme in order to provide additional icons and a consistent look within the application, so I need to be able to kick the system theme down to the fallback theme. (If I leave it as "breeze", I get illegible icons due to my color theme.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
On 20/04/2020 12.21, André Pönitz wrote:
On Mon, Apr 20, 2020 at 10:04:38AM -0400, Matthew Woehlke wrote:
On 19/04/2020 08.23, André Pönitz wrote:
QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
TypeB based e.g. on alphabetical order of their .typeName().
If wanted, this can be refined to make e.g. all integral types comparable.
No:
int{5} <=> JsonObject{...} => lesser
int{5} <=> long{3} => greater
long{3} <=> JsonObject{...} => greater
...oops.
"make comparable" means lumping them into a common "type", say
"@integral", with values covering the union set of the values
of the original type.
...and now your rule for heterogeneous comparisons ***isn't***
'according to the type name'. It's 'according to the type name, *except*
'. Yuck.
You'd have to make all integral types sort before (or after) all other
types, but then you're back to not having a reliable ordering by type name.
No.
Really? Please explain how this is *not* the case.
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QVariant compare operator
On 19/04/2020 08.23, André Pönitz wrote:
QVariant(TypeA) and QVariant(TypeB) can be ordered for different TypeA and
TypeB based e.g. on alphabetical order of their .typeName().
If wanted, this can be refined to make e.g. all integral types comparable.
No:
int{5} <=> JsonObject{...} => lesser
int{5} <=> long{3} => greater
long{3} <=> JsonObject{...} => greater
...oops.
You'd have to make all integral types sort before (or after) all other
types, but then you're back to not having a reliable ordering by type name.
It makes *much* more sense that some comparisons just come back
"incomparable".
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt and Open Source
On 09/04/2020 08.28, Florian Bruhin wrote: Today, The Qt Company released a quick statement: https://www.qt.io/blog/qt-and-open-source The Qt Company is proud to be committed to [...] open source, and the Qt governance model. Recent actions: [A]fter more and more moves against the open-source side of Qt recently, I place a lot more trust in statements coming from KDE rather than those coming from TQtC... ...say otherwise. 2) Qt tried to bluff in order to force KDE to change some other provision of their contract, possibly even using the current pandemic as an excuse to do so. I find this repulsive, but unfortunately, it seems the most likely explanation, especially given this part of KDEs announcement: "The Qt Company says that they are willing to reconsider the approach only if we offer them concessions in other areas. I am reminded, however, of the situation half a year ago. We had discussed an approach for contract updates, which they suddenly threw away by restricting LTS releases of Qt instead." Even assuming this *is* the case, it still doesn't bode well for their *actual* attitude towards the FLOSS community. The evidence strongly suggests that TQtC is FLOSS-hostile and that they are doing the bare minimum necessary to avoid triggering the 'kill provisions'. 3) Qt is just trying to do damage control and still intends to follow through with those changes. Like I said, I always try to assume good faith, but the lack of transparency on TQtC's side about this topic really doesn't help. This may be the best case scenario, and I suppose it's possible, but even this would be a case of TQtC (upper management, anyway) being completely out of tune with the FLOSS community. I know some readers will have very strong opinions against the Qt Company after the announcement Probably. My opinion is unchanged; just solidified. Remember OOo... -- Matthew ___ 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
On 02/04/2020 01.39, Tuukka Turunen wrote: > I know licensing in general can be a challenging topic, 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. For me, personally, I'm not (intentionally) trying to twist anything... but "less than friendly"? Sure. Why? Because every time licensing comes up on the mailing lists, we seem to get the same answers: "it depends on the particulars of the case" and "talk to your lawyer". And over and over, I see the same reaction: "we will no longer use or recommend Qt". (Moreover, this is *in addition* to technical concerns that various folks, myself included, have expressed.) This creates an impression that Qt commercial licensing is a legal minefield, which scares off some people. Some of the "gotchas", combined with other recent actions (installers requiring an account) creates an impression of a TQtC that is not particularly friendly to the OSS community. Is it any wonder people are reacting with a "less than friendly" attitude? TQtC is coming across as increasingly adversarial; it's no wonder the community is becoming adversarial right back. In political terms, recent actions have resulted in a significant drop in TQtC's approval rating, at least with the OSS community. If you / TQtC can't understand why this is, well, that's part of the problem right there. Apparently TQtC has a healthy commercial relationship with... well, someone. Unfortunately, Qt OSS seems to be suffering hugely. -- Matthew ___ 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
On 31/03/2020 16.12, Krzysztof Kawa wrote: > This got me thinking about quite a simple case that doesn't seem so > simple now: Lets say I make a game using open-source licensed Qt, or > even just open-source licensed Qt Creator. After few years of > development I decide to publish the game. It just so happens that my > publisher has a storefront app using commercial Qt or even just > written in Qt Creator under commercial license. To put my app in their > store there's usually some API, config file or whatever that > technically makes it mixing the two, even if not through Qt based > interface. Are you talking about an API that *your game* will use (e.g. for IAPs)? Or just the process of submitting your content to be distributed? > Does that mean I can't publish my app in that store? *You* are fine, so long as publishing doesn't prevent you from fulfilling your [L]GPL obligations. The store, OTOH... I have no idea. (Lucky for you that's not *your* problem.) -- Matthew ___ 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
On 31/03/2020 09.46, Andy wrote: > Even a solo developer needs to hire a lawyer before touching anything > Qt-related. Fortunately for the OSS community, you forgot "commercial" in that sentence. > Once you start trying to codify all the different scenarios in your > licensing, it becomes toxic and people will avoid it Yup. Just in this thread, I've seen messages *from Tuukka* that said "yes", "no", and avoided answering in various ways. It's no wonder people are confused. -- Matthew ___ 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
On 30/03/2020 13.49, Andy wrote: > That makes no sense. Your license prevents a company from using an > open-source tool? It says "if you license our stuff you cannot use the > open-source tool X"? That is, indeed, what I am hearing, and also how I would interpret the FAQ. > This whole thread is yet another great example of where the Qt Company is > totally tone-deaf. Yup... except I'd probably use some less polite terms than "tone-deaf". This sort of thing, and also the recent installer changes, continues to make me think that TQtC is *trying* to commit suicide. That, or whoever is making these decisions is hopelessly incompetent. > Nobody understands your licensing. You have fewer people using Qt and > Qt-based things because of this. Probably. -- Matthew ___ 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
On 31/03/2020 14.16, Francis Herne wrote: > Having looked through said document, the relevant sections seem to be: > >> 1. ... “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. ... > > Can't use licensed Qt Creator to develop open-source Qt apps; ok. That *is* what the above appears to say. It's also *beyond* asinine. YTH should TQtC care if I buy their IDE and use it to develop OSS software? This just strikes me as a reason to *not* buy their IDE. I fail to see how it is in any way beneficial to TQtC. The *intent* here is to not use the licensed Qt *libraries* to build a product which also leverages the OSS version of Qt in any way, to avoid people "shirking" by writing most of their code against OSS Qt and then later bolting on a tiny proprietary bit. I won't comment whether I think that approach makes sense, but it's at least comprehensible. > In general, the only "clear" policy is that The Qt Company deliberately > obfuscates the conditions under which the GPL version can be used, to put > people off exercising the rights that do exist. > > This goes along with the general downplaying of, and FUD about, the GPL > option > on the website, and the bizarre retrospective licensing. > > It's disrespectful to the outside contributors who've built so much of Qt and > its ecosystem in exchange for those rights, and doesn't bode well for the > future of Qt in the free software community. No argument here... -- Matthew ___ 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
On 27/03/2020 08.55, Tuukka Turunen wrote: > Correct. All users need to have commercial license. It is not allowed for > part of the team to use commercial and part use open-source. Even though Qt > Creator is great, it can feel odd to pay for full Qt license and only use the > Creator IDE. > > We have been thinking about selling Qt Creator separately, but so far no > decisions made on this. Wait, *WHAT?!* AFAIK, GPL imposes no restrictions on material created *using* GPL'd software (with possible exceptions if such use results in materials that incorporate parts of the software used, e.g. bison/flex). That said, I wouldn't know what sorts of crazy provisions the Qt commercial licensing may contain... IMHO though requiring licensees to not use a particular IDE is pretty asinine. > On 25.3.2020, 21.09, "Interest on behalf of Vyacheslav Lanovets" > wrote: > > Hi, > > Situation. > > A company has a few developers with Qt Commercial subscription who > write applications in Qt for iOS. > There are many other developers, who work on other projects and don't > use Qt libraries. > They talk to each other and sometimes even work on the same code. > > Is it still possible for the developers who don't use Qt libraries in > any way, use Qt Creator IDE for editing and debugging? > To be on the safe side, company plans to prohibit usage of Qt Creator > IDE for all employees. > I reckon this is a popular solution. > If I understand correctly, Qt even sells a special option to ban all > company IP addresses for open-source installer. > > But is it really so? > > Regards, > Vyacheslav > ___ > 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 > -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt archives corrupted?
On 30/03/2020 16.14, Giuseppe D'Angelo via Interest wrote: > Il 30/03/20 22:02, Matthew Woehlke ha scritto: >> What happened to the Qt archives? I can download 1.41, but 5.2 - 5.8 and >> 5.10 and 5.11 are missing? > > They have been moved here > > https://download.qt.io/new_archive/qt/ ...and what, pray tell, is the point of leaving the old archives in a half-broken state? I would either fix them, at least as far as being correct-if-frozen-in-the-past, or take them down entirely with a note where the new archives are located. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Qt archives corrupted?
What happened to the Qt archives? I can download 1.41, but 5.2 - 5.8 and 5.10 and 5.11 are missing? -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Why doesn't my model filter update?
On 18/02/2020 18.38, Sze Howe Koh wrote: > The last valid row index is (rows-1), not (rows). Right > Do I get the other half-cookie? Sure → -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Why doesn't my model filter update?
On 18/02/2020 16.31, Konstantin Shegunov wrote:
> On Tue, Feb 18, 2020 at 11:20 PM Matthew Woehlke wrote:
>> I wonder if anyone else can spot it? ;-)
>
> Without knowing anything about the code at all, my best guess based on a
> very quick glance would be the range for the dataChanged is wrong.
Okay, I'll give you half a cookie, since I can't really say much more
without giving it away. (Incidentally, if I hadn't already figured it
out, you comment probably would have helped!)
Here's the broken code:
if (auto const rows = this->rowCount())
{
auto const& first = this->index(0, 0);
auto const& last = this->index(rows, 0);
emit this->dataChanged(first, last, {MyFilterRole});
}
It fell victim to one of the two hard problems of programming (as
enumerated by Leon Bambrick¹). To wit, `last` is an invalid index, which
trips one of the sanity checks in QSortFilterProxyModel's internal logic.
If you can't tell *why* `last` is invalid, well, keep looking until you
can ;-). All the information you need to spot the problem is in the
above snippet, and it's *obvious* once you see it. (Note: assume that
the class otherwise behaves in a correct fashion.)
(¹ https://www.goodreads.com/quotes/7443069)
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Why doesn't my model filter update?
On 18/02/2020 16.16, Marian Beermann wrote: > Are you emitting dataChanged for the relevant roles? A Qt view would > not, generally, care about data changes for user-defined roles, for example. "The filter *does* have filterRole set correctly". That wasn't the problem. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Why doesn't my model filter update?
On 18/02/2020 15.35, Matthew Woehlke wrote: > I have a QAbstractItemModel. I also have a QSortFilterProxyModel acting > as a filter for the model, which in turn is used to feed a QTreeView. > The filter accepts or rejects rows based on a custom data role of the > source model. > > However, when the source model's data changes, the tree view does not > update, and the filter's filterAcceptsRow is never called. What could I > be doing wrong? > > The filter *does* have filterRole set correctly, and *does* have > dynamicSortFilter set. (filterKeyColumn isn't set, but I'm using 0, and > anyway setting it to -1 had no effect.) I've verified that the source > model is emitting dataChanged() and is not blocking signals. > > The filter setup is at > https://github.com/Kitware/seal-tk/blob/master/sealtk/gui/AbstractItemRepresentation.cpp#L47-L48. > The model dataChanged is emitted at > https://github.com/Kitware/seal-tk/blob/master/sealtk/core/AbstractProxyModel.cpp#L135. Sigh... I found the problem. I wonder if anyone else can spot it? ;-) (Hint: it's near one of the bits of code linked above.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Why doesn't my model filter update?
I have a QAbstractItemModel. I also have a QSortFilterProxyModel acting as a filter for the model, which in turn is used to feed a QTreeView. The filter accepts or rejects rows based on a custom data role of the source model. However, when the source model's data changes, the tree view does not update, and the filter's filterAcceptsRow is never called. What could I be doing wrong? The filter *does* have filterRole set correctly, and *does* have dynamicSortFilter set. (filterKeyColumn isn't set, but I'm using 0, and anyway setting it to -1 had no effect.) I've verified that the source model is emitting dataChanged() and is not blocking signals. The filter setup is at https://github.com/Kitware/seal-tk/blob/master/sealtk/gui/AbstractItemRepresentation.cpp#L47-L48. The model dataChanged is emitted at https://github.com/Kitware/seal-tk/blob/master/sealtk/core/AbstractProxyModel.cpp#L135. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Signal/Slot connection fails, even though QMetaObject::activate is called
On 15/02/2020 00.40, Max Paperno wrote: > On 2/14/2020 11:19 PM, Tony Rietwyk wrote (in part): >> Both overloads have the following warning: > > No they don't... Looking at doc.qt.io for 5.14 anyway. Only the one with > `context` has the part about the context being destroyed (emphasis mine): > > "The connection will automatically disconnect if the sender **or the > context** is destroyed." > > To me this says that you specifically want the connection to be > destroyed when the `context` object goes away, in case the sender and > receiver/context objects aren't the same for some reason. The sender and receiver/context are *rarely* the same... that would be a self-signalling object. You probably meant that they *share lifetime*, and you'd be right that that is often the case... until it isn't. Just because it's true *today* doesn't mean it will be true *tomorrow* as your project changes. Some UI element you expected to be around "forever" or to have exactly one instance might suddenly become dynamic. It's *always* safer to be explicit about the receiving context. > If the lambda code only affects stuff in the sender object (or stuff > unrelated to any object), then it probably doesn't matter. Right; in this case, you can *maybe* get away with it... but see also the follow-up about the *thread* context. Even here, you're probably safer reusing the sender as the receiving context. > Seems clear that for objects in different threads the sender and > receiver/context wouldn't be the same, hence the connection type > parameter in that overload. Sure, but the connection type has other uses. Sometimes, for instance, you want to force a queued connection to defer handling of an event. (Especially true for cases where you might handle several of the same event in one event loop "cycle". Techniques like merging update requests are usually implemented with explicitly queued events.) I don't think I've *ever* used DirectConnection, but I've definitely used QueuedConnection. (Most of the time, of course AutoConnection is correct.) >> In my experience, coding in particular ways "because it scares you" >> often leads to poor results. WG21 disagrees. Many C++ programmers think that naked `new`/`delete` are scary, and the general direction is to *encourage* this. Being "scared" of a programming practice that is *well known* to be easily and frequently misused is not a bad thing. If you'd said something like "my code *never* checks for array bounds overflow", I would have the same reaction. (Note: "because my indexing operators will throw" doesn't count; that *is* checking.) >> A C++ lambda is basically a temporary object with the copied or >> referenced state Right. And if the owner of those references goes out of scope before the lambda... (Keep in mind that copied pointers are, effectively, *also references*. You're probably okay for non-capturing lambdas or lambdas that genuinely only capture values, but in my experience, those are rare, at least as slots. The vast majority of my lambdas capture either `this` or `d`.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Signal/Slot connection fails, even though QMetaObject::activate is called
On 16/02/2020 21.33, Max Paperno wrote: > Happened to stumble upon this clazy check while searching on a > completely different issue. > Seems to explain the reasoning pretty well. > > https://github.com/KDE/clazy/blob/master/docs/checks/README-connect-3arg-lambda.md Thanks for sharing the link! This is good information for anyone that doesn't understand the issue. One particular point to note is... > On 2/15/2020 12:40 AM, Max Paperno wrote: >> On 2/14/2020 11:19 PM, Tony Rietwyk wrote (in part): >>> In the shorter overload, I would assume that the context is simply >>> the current thread object. ...that this is wrong; a 3-arg connection *doesn't have* a context argument. The connection will exist for as long as the sending object, and you *don't know what thread it will execute in*. Seriously. Let that sink in. "Oh, well, it will run in the sender's thread," I hear you thinking. NO! You *don't know that*! I've written code that invokes signals in a thread other than the one to which the owning object belongs. (Typically, for objects whose purpose is to manage a worker thread.) With AutoConnection and a receiving context this is generally safe (in fact, it is often the *purpose* of such code to use the signals to pass data across threads), but if you don't supply a context, your code might suddenly execute in what was supposed to be a private worker thread. Don't use context-free connections. Just don't ;-). -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fwd: Re: Signal/Slot connection fails, even though QMetaObject::activate is called
On 07/02/2020 21.37, Jonathan Purol wrote: > After manually removing every line of code to see when a MVCE would > work, I found a loose `blockSignals(true)` flying around that was there > from a debugging session. `git diff`? Stuff like this is why you should use a VCS (it doesn't have to be git) even for personal projects, and commit early and often, so that when you're working on something, it's easy to see what's changed. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Signal/Slot connection fails, even though QMetaObject::activate is called
On 07/02/2020 19.10, Tony Rietwyk wrote: > Does it work if you don't pass 'this' as the third argument to connect? > I never use that particular overload of connect. I usually pass the > lambda as the third argument. That scares me. The third argument is the context in which the slot runs, i.e. the "receiver". If your lambda contains any state, not passing a context risks the slot being called after whatever owns that state has ceased to exist, which will likely lead to UB. (It also risks the lambda running in the wrong thread.) Basically, if your lambda has *any state at all*, you should *always* pass a context. The context should be a QObject which owns that state and whose thread can safely use the state. The context should only be omitted if your lambda is stateless, and even then I'd avoid doing so unless you really need to, or are making a deliberate choice that no one should "own" the connection. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] QInputDialog as item delegate?
I have a QTreeView. For one of the columns, rather than editing the data in-place, I want to pop up a QTextEdit. (For now, I'm hoping I'll be able to use QInputDialog, but I may end up needing to roll my own.) Is it reasonable to execute the dialog (QDialog::exec()) in an override of QAbstractItemDelegate::createEditor, or do I need to hook itemActivated or some such? (Maybe QAbstractItemDelegate::editorEvent would be better?) What is the best way to trigger the editor? -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] TLS/SSL XML encryption security
On 17/10/2019 09.56, Roland Hughes wrote: > This presents the perfect challenge. Once "The Mother Road" it is now > difficult to navigate having many turns, stops and 30 MPH stretches. > Most importantly there are huge sections without cellular/wireless > coverage. Some sections satellite coverage doesn't work. The vehicle > will have to retain all of the knowledge it needs for the trip because > updates will be sparse. I think you overestimate the difficulty of doing this. My ten year old car has maps of the entire US in onboard memory. IIRC it fits on a single DVD. Yes, this is now 10 years out of date, and doesn't include things like speed limits, but I doubt we're talking about an amount of data that can't fit on a single SSD. The car knows where it is from a combination of GPS, inertial guidance, and the assumption that it is on a road. Combine this with the car *knowing* what it is trying to do and being able to actually "see" the road and street signs, and you have a system that should be able to navigate at least as well as a human under most conditions. This isn't guessing, it's experience... based on technology that was close to mainstream *ten years ago*. BTW, I believe Google Navigation has already solved the "retain the data you need for the whole trip" problem. Combine this with some form of version control system so that the vehicle can frequently download updates for its entire operational area, and I just don't see how "spotty network coverage" is going to be an issue. (Maybe for someone who *lives* in an area with no coverage. Well, such people may just not be able to use autonomous vehicles. I doubt that is going to deter the folks working on AV's.) Yes, situations will come up that it can't handle, at which point it will have to get the human involved. Until we have something approaching "real AI", that will be the case. That said, I like your viability test :-). -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] TLS/SSL XML encryption security
On 04/10/2019 20.17, Roland Hughes wrote: > On 10/3/19 5:00 AM, Matthew Woehlke wrote: >> On 01/10/2019 20.47, Roland Hughes wrote: >>> To really secure transmitted data, you cannot use an open standard which >>> has readily identifiable fields. Companies needing great security are >>> moving to proprietary record layouts containing binary data. Not a >>> "classic" record layout with contiguous fields, but a scattered layout >>> placing single field bytes all over the place. For the "free text" >>> portions like name and address not only in reverse byte order, but >>> performing a translate under mask first. Object Oriented languages have >>> a bit of trouble operating in this world but older 3GLs where one can >>> have multiple record types/structures mapped to a single buffer (think a >>> union of packed structures in C) can process this data rather quickly. >> >> How is this not just "security through obscurity"? That's almost >> universally regarded as equivalent to "no security at all". If you're >> going to claim that this is suddenly not the case, you'd best have >> some *really* impressive evidence to back it up. Put differently, how >> is this different from just throwing another layer of >> encry^Wenciphering on your data and calling it a day? > > _ALL_ electronic encryption is security by obscurity. > > Take a moment and let that sink in because it is fact. > > Your "secrecy" is the key+algorithm combination. When that secret is > learned you are no longer secure. People lull themselves into a false > sense of security regurgitating another Urban Legend. Well... sure, if you want to get pedantic. However, as I see it, there are two key differences: - "Encryption" tries to make it computationally hard to decode a message. - "Encryption" (ideally) uses a different key for each user, if not each message, such that compromising one message doesn't compromise the entire protocol. (Okay, granted this isn't really true for SSL/TLS unless you are also using client certificates.) ...and anyway, I think you are undermining your own argument; if it's easy to break "strong encryption", wouldn't it be much *easier* to break what amounts to a basic scramble cipher? > One of the very nice things about today's dark world is that most are > script-kiddies. If they firmly believe they have correctly decrypted > your TLS/SSL packet yet still see garbage, they assume another layer of > encryption. They haven't been in IT long enough to know anything about > data striping or ICM (Insert Character under Mask). So... again, you're proposing that replacing a "hard" (or not, according to you) problem with an *easier* problem will improve security? I suppose it might *in the short term*. In the longer term, that seems like a losing strategy. > He came up with a set of test cases and sure enough, this system which > worked fine with simple XML, JSON, email and text files started > producing corrupted data at the far end with the edge cases. Well, I would certainly be concerned about an encryption algorithm that is unable to reproduce its input. That sounds like a recipe guaranteed to eventually corrupt someone's data. > Even if all of that stuff has been fixed, you have to be absolutely > certain the encryption method you choose doesn't leave its own tell-tale > fingerprint. Some used to have visible oddities in the output when they > encrypted groups of contiguous spaces, nulls, etc. Plus, there are quite > a few places like these showing up on-line. Again, though, it seems like there ought to be ways to mitigate this. If I can test for successful decryption without decrypting the *entire* message, that is clear grounds for improvement. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 96, Issue 19
On 01/10/2019 20.47, Roland Hughes wrote: > If you are using XML, JSON or any of the other trendy text based > open standards for data exchange, you've made it easy for the hackers. > They don't have to put any human noodling into determining if they > cracked your transmission or not. It can be fully automated. As soon as > one of the attempts returns something like this > > John > > or this > > "firstName" : "John" > > a tiny bit of code which runs through the result looking for an opening > tag with a matching closing tag or colon delimited quoted strings can > tell a brute force method to stop and notify the hacker of success. Isn't the fix for this just to encrypt your data twice (using different keys, or maybe better, different algorithms)? Offhand, it seems like this should exponentially increase the difficulty of decryption for each layer added. > To really secure transmitted data, you cannot use an open standard which > has readily identifiable fields. Companies needing great security are > moving to proprietary record layouts containing binary data. Not a > "classic" record layout with contiguous fields, but a scattered layout > placing single field bytes all over the place. For the "free text" > portions like name and address not only in reverse byte order, but > performing a translate under mask first. Object Oriented languages have > a bit of trouble operating in this world but older 3GLs where one can > have multiple record types/structures mapped to a single buffer (think a > union of packed structures in C) can process this data rather quickly. How is this not just "security through obscurity"? That's almost universally regarded as equivalent to "no security at all". If you're going to claim that this is suddenly not the case, you'd best have some *really* impressive evidence to back it up. Put differently, how is this different from just throwing another layer of encry^Wenciphering on your data and calling it a day? > If they targeted something which uses XML documents to communicate, they > don't need to brute force attempt everything, just the first 120 or so > bytes of each packet until they find the one which returns > > > and they are done. That seems like a flaw in the encryption algorithm. It seems like there ought to be a way to make it so that you can't decrypt only part of a message. Even an initial, reversible step such as XOR-permuting the message with some well-known image of itself (e.g. "reversed") might suffice? -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Why can't I sort QTreeView?
On 11/09/2019 15.52, Matthew Woehlke wrote: > I have a QTreeView. The model is set to a subclass of > QAbstractSortFilterProxyModel, which is in turn proxying a subclass of > QAbstractItemModel. > > I've set sortingEnabled, but for the life of me, I can't get sorting to > actually work (under user control); no sorting indicator is shown, and > clicking on the column headers does nothing. > > What am I missing? Um.. okay, answering my own question, sort-of, QHeaderView::restoreState borked it somehow. So, I can work around it by nuking the "bad" settings, but what did QHeaderView::restoreState to bork it, and how would I fix it in code? -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Why can't I sort QTreeView?
Okay, this is driving me nuts... I have a QTreeView. The model is set to a subclass of QAbstractSortFilterProxyModel, which is in turn proxying a subclass of QAbstractItemModel. I've set sortingEnabled, but for the life of me, I can't get sorting to actually work (under user control); no sorting indicator is shown, and clicking on the column headers does nothing. What am I missing? -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Static build of Qt - debug mode and plugins
On 26/08/2019 12.18, Elvis Stansvik wrote: > Den mån 26 aug. 2019 17:32Matthew Woehlke skrev: >> ...or just run `make VERBOSE=1`. > > I didn't know if he was using ninja or make, so suggested the solution that > I believe will work with both (with recent versions of CMake) :) Fair point. I'm pretty sure the `[1%] ...` is not Ninja (Ninja would normally be e.g. `[1/52] ...`), but it might have been Visual Studio. For some reason I took one look and immediately believed it to be `make`, but now I think that was my bad :-). (Possibly related to how often I use Windows these days... hardly ever. Also, when I do have to use Windows, I still use Ninja ;-).) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Q_NAMESPACE is not portable?
On 26/08/2019 11.56, Giuseppe D'Angelo wrote: > On 26/08/2019 17:29, Matthew Woehlke wrote: >> BTW, what happened to the doc? Macros aren't class members... > > I'm thinking it's still https://bugreports.qt.io/browse/QTBUG-76822 Could be. >> (Relatedly, any word on lifting the implied dependency on >> several of these?) > > I agree in principle at moving these macros elsewhere, didn't *you* push > a patch that got stuck just because of documentation issues? :-) Yes (https://codereview.qt-project.org/c/qt/qtbase/+/265168). I would like to see it un-stuck :-). -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Static build of Qt - debug mode and plugins
On 25/08/2019 03.09, Elvis Stansvik wrote: > Den sön 25 aug. 2019 kl 02:56 skrev Thiago Macieira: >> On Saturday, 24 August 2019 10:53:45 PDT Jakub Narolewski wrote: >>> [ 1%] Linking CXX executable mrserver_debug >> >> Please expand this line. > > Jakub, to do this you can pass -DCMAKE_VERBOSE_MAKEFILE:BOOL=TRUE to CMake. ...or just run `make VERBOSE=1`. Or, better yet, install Ninja and use `-G Ninja` when running CMake ;-). (And then `ninja -v`.) Your build times will thank you. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Q_NAMESPACE is not portable?
On 23/08/2019 19.02, Giuseppe D'Angelo via Interest wrote: > On 24/08/2019 00:10, Matthew Woehlke wrote: >> Am I doing something wrong, or is it impossible to use Q_NAMESPACE >> correctly without platform-specific PP conditionals? > > I've fixed this in 5.14, see > >> https://doc-snapshots.qt.io/qt5-dev/qobject.html#Q_NAMESPACE_EXPORT Okay... that's both good and bad news... good that it's fixed, bad that it isn't available in a released version. BTW, what happened to the doc? Macros aren't class members... (Relatedly, any word on lifting the implied dependency on several of these?) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Q_NAMESPACE is not portable?
Am I missing something, or is it impossible to portably use Q_NAMESPACE?
If I just use Q_NAMESPACE on its own, e.g.:
namespace foo {
Q_NAMESPACE
}
...then I get unresolved externals on Linux. If I attempt the obvious fix:
namespace foo {
Q_NAMESPACE
extern FOO_EXPORT const QMetaObject staticMetaObject; // Ugh
}
...then I get 'redefinition, different linkage' errors on Windows.
Am I doing something wrong, or is it impossible to use Q_NAMESPACE
correctly without platform-specific PP conditionals?
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] Using Q_ENUM_NS?
Is it *really* impossible to use Q_ENUM_NS (in the same namespace) in
more than one header? If not, how does one do so correctly?
If I don't have code that looks *exactly* like this:
namespace whatever {
Q_NAMESPACE
Q_ENUM_NS(...)
}
...moc is unhappy. But if Q_NAMESPACE appears in more than one header, I
get duplicate definition errors.
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt free software policy
On 14/08/2019 16.22, John Weeks wrote: > We are a small company selling a very large and complex application which is > now based on Qt open source. At the time we first considered porting to Qt > (version 4.3?) the license was very expensive for small company (six > programmers) and the evaluation period simply wasn't adequate to deciding if > it was the right way to go. So we went open-source when it became available > when Nokia took over. > > Since then, we have wished that we had a commercial license in order to get a > bit more traction on some bugs. The Qt Company wanted us to pay for all the > licensing that had accrued since we started using the LGPL version. That > up-front cost is prohibitive, so we haven't done it. Does TQtC *not* sell commercial-level *support* without the additional commercial licensing rights (and retroactive costs)? If not, that seems like an idiotic missed opportunity... -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Add row to model *with data*?
On 16/08/2019 09.27, Jérôme Godbout wrote: > Maybe you can add a type to your model and make a map of type to > Component, when initalizing the view element, use a Loader that will > create the proper Item view based on your type. Not sure this is > what you are looking for. I honestly didn't follow any of that. Right now, my work-around is to make all of my models subclass some intermediate interface type (which itself subclasses QAbstractItemModel) that provides an 'addRowWithData' method. This version doesn't take an index; instead it *returns* the index where insertion happened. (Anyway, the design of my models is that they present data in an arbitrary order, with the expectation that a QSortFilterProxyModel will be used to present them.) > As for sorting, if you use a QVariantList, you can call javascript > sort() on the array if you have a small list or you could make your > own method in C++ that will sort the element. I don't see how this relates? My model isn't using QVariantList. The actual model data is backed by a custom container type that has specific ordering requirements. As a result, users of the model cannot control the order in which rows are inserted. Instead, they must ask to insert a row *with data*, and the underlying container will determine *where* that rowdata *must* be inserted. I don't need sorting. I need for users to be able to ask to insert a row without specifying *where* to insert the row. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Add row to model *with data*?
So... I have a (subclass of) QAbstractItemModel. This class internally represents data using some other container, which has specific requirements on both the item, and on the order of items. Thus, I can't just add rows anywhere and with no data, to be filled in later. My users are intended to work with *just* the QAbstractItemModel API. (I eventually expect to have multiple model implementations.) Is there any way, with the existing QAbstractItemModel API, to specify the data that the row should contain in the same call that adds the row? Even better, is there any way to ask the model to add a row, with data, but *not* specify where the row is to be added? (The model would then return the new row index, or -1 if it could not complete the operation as requested.) If not, is this something that would make sense to add? -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Q_ATOMIC_INT64_IS_SUPPORTED: Qt Compile errors on macOS
On 26/06/2019 21.17, Thiago Macieira wrote: > The whole reason the file exists is to avoid > having to call the compiler to find out its details every time that qmake is > started. In order to do what you are asking for, we need to call out to the > compiler, which defeats the purpose. Can't you make that depend on *the compiler*? .qmake.stash: /usr/bin/g++ (I guess this wouldn't behave well with ccache, but oh well...) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QMetaObject::invokeMethod thread safety
On 17/05/2019 13.47, Thiago Macieira wrote: > On Friday, 17 May 2019 10:25:15 PDT Matthew Woehlke wrote: >> IOW, I have some shared object owner by Thread 1 which is eventually >> deleted. In Thread 2, I want to queue a call to a slot on that object. > > Thread-safety does not apply while the object in question is being destroyed. > [...] > So, no, you can't race against the object's destruction. Ensure that the > destructor has not begun running when you post an event or make a metacall or > basically anything else. Okay, thanks for confirming! I will continue to use a shared pointer to the object in question; that way the invokeMethod caller/thread owns a reference to the object ensuring it can't be destroyed until invokeMethod completes. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] QMetaObject::invokeMethod thread safety
Yes, yes, I know the doc says it's thread safe, but I'm still not
entirely sure about this particular example:
QPointer foop; // global
void bar1()
{
auto* foo = new Foo;
foop = foo;
QtConcurrent::run();
// ...later...
delete foo;
}
void bar2()
{
QMetaObject::invokeMethod(foop, ::whatever, ...);
}
IOW, I have some shared object owner by Thread 1 which is eventually
deleted. In Thread 2, I want to queue a call to a slot on that object.
Historically I have used a shared pointer to pass the object between
threads, because I *know* that is safe (the call will be queued before
the object can possibly be deleted; if it gets deleted before the queued
call dispatches, that's okay; I just care that the program doesn't crash
/ corrupt memory / eat kittens). If, OTOH, I were to use a bare pointer,
I *know* that is unsafe, because I have no guarantee the object still
exists (or, worse, that the pointer now refers to some other object)
when I go to queue the call.
What's less clear (without trying to dig through the guts of Qt's event
queuing at least) is; in something like the above, is invokeMethod is
guaranteed to be able to queue the call successfully if another thread
deletes the target object some time between the start of the call to
invokeMethod and when the event is fully created on Foo's thread's event
queue (at which point it is "safe")?
In fact, given that invokeMethod takes a QObject* and not a QPointer, I
think the answer is that it *can't* be fully thread-safe? (If the caller
does not own the target object, how could Qt prevent the passed-in
pointer from being destroyed and recycled between the caller obtaining
the QObject* from the QPointer and the first instruction of invokeMethod
executing?)
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] Confused about GL context sharing
Let's say I have a QOpenGLWidget in a dock widget. Every time I dock or undock the dock widget, the GL widget gets a new context. I would like to use context sharing so that I only need to create my GL resources (shaders, textures, buffers) once, and reuse them as the widget is docked and undocked. Well... it seems to be working with buffers and shaders... but if I try to "reuse" textures (i.e. not destroy and recreate them when the context "changes"), my application crashes: = Invalid read of size 8 =at 0x5990F94: glBindTexture (qopenglfunctions.h:623) =by 0x5990F94: bind (qopengltexture.cpp:247) =by 0x5990F94: QOpenGLTexture::bind() (qopengltexture.cpp:2474) = Address 0x1a5f5fe0 is 0 bytes inside a block of size 8 free'd =at 0x483A0D6: operator delete(void*, unsigned long) =by 0x570224F: QOpenGLContext::destroy() (qopenglcontext.cpp:655) Am I missing something? Is this not supported? TBH, it feels a little buggy; AFAICT, the QOpenGLTexture retains a copy of the QOpenGLFunctions from the context which created it, which is *unique* to that context rather than being shared between shared contexts... which all seems a little bit dodgy. (Note: I am using Qt::AA_ShareOpenGLContexts...) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Odd crash with QPainter + QOpenGLWidget
On 27/03/2019 21.05, Thiago Macieira wrote:
> On Wednesday, 27 March 2019 14:48:16 PDT Matthew Woehlke wrote:
>> ==12997==by 0x598A728: QOpenGLVertexArrayObjectPrivate::destroy()
>> (qopenglvertexarrayobject.cpp:212)
> [...]
>> ==12997== Address 0x8 is not stack'd, malloc'd or (recently) free'd
>
> Line 212:
>
> if (QThread::currentThread() != qGuiApp->thread()) {
>
> There is a pointer being dereferenced on that line: qGuiApp, which is:
>
> #define qGuiApp (static_cast(QCoreApplication::instance()))
>
> That means you're somehow running this code after the application object was
> destroyed. Your backtrace wasn't long enough to tell where this was being
> called from (run valgrind with --num-callers=20), but my guess is that it's a
> global destructor keyed to the font engine.
>
> But I also don't see how this could be *your* fault. If you can get the full
> backtrace, I think you should report as a bug.
Here's the full trace:
==1742== Invalid read of size 8
==1742==at 0x5D1F4E4: QObject::thread() const (qobject.cpp:1420)
==1742==by 0x5989728: QOpenGLVertexArrayObjectPrivate::destroy()
(qopenglvertexarrayobject.cpp:212)
==1742==by 0x59899AA:
QOpenGLVertexArrayObject::~QOpenGLVertexArrayObject()
(qopenglvertexarrayobject.cpp:392)
==1742==by 0x5986286:
QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()
(qopengltextureglyphcache.cpp:87)
==1742==by 0x59862AC:
QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()
(qopengltextureglyphcache.cpp:93)
==1742==by 0x5769DAB: ~QLinkedListNode (qlinkedlist.h:69)
==1742==by 0x5769DAB:
QLinkedList::freeData(QLinkedListData*)
[clone .isra.119] (qlinkedlist.h:345)
==1742==by 0x5BB00E8: QHashData::free_helper(void
(*)(QHashData::Node*)) (qhash.cpp:572)
==1742==by 0x57699BA: freeData (qhash.h:585)
==1742==by 0x57699BA: ~QHash (qhash.h:254)
==1742==by 0x57699BA: QFontEngine::~QFontEngine() (qfontengine.cpp:271)
==1742==by 0x18C145FC: QFontEngineFT::~QFontEngineFT()
(qfontengine_ft.cpp:794)
==1742==by 0x5769AE4: QFontEngineMulti::~QFontEngineMulti()
(qfontengine.cpp:1792)
==1742==by 0x18C1D41C:
QFontEngineMultiFontConfig::~QFontEngineMultiFontConfig()
(qfontenginemultifontconfig.cpp:57)
==1742==by 0x575E25E: QFontCache::clear() (qfont.cpp:2796)
==1742==by 0x575E516: QFontCache::~QFontCache() (qfont.cpp:2752)
==1742==by 0x575E5CC: QFontCache::~QFontCache() (qfont.cpp:2753)
==1742==by 0x5B62ED8: QThreadStorageData::set(void*)
(qthreadstorage.cpp:163)
==1742==by 0x56BCB2F:
QGuiApplicationPrivate::~QGuiApplicationPrivate() (qguiapplication.cpp:1594)
==1742==by 0x50A7B4C: QApplicationPrivate::~QApplicationPrivate()
(qapplication.cpp:179)
==1742==by 0x5D2830A: cleanup (qscopedpointer.h:60)
==1742==by 0x5D2830A: ~QScopedPointer (qscopedpointer.h:107)
==1742==by 0x5D2830A: QObject::~QObject() (qobject.cpp:884)
==1742==by 0x5CFB32D: QCoreApplication::~QCoreApplication()
(qcoreapplication.cpp:880)
==1742==by 0x56BEE7C: QGuiApplication::~QGuiApplication()
(qguiapplication.cpp:631)
==1742==by 0x50A9CA3: QApplication::~QApplication()
(qapplication.cpp:788)
==1742==by 0x4011A8: main (Main.cpp:22)
...but also, I think I found the bug:
int main(int argc, char** argv)
{
// ...some init code...
QApplication app{argc, argv};
auto* window = new my::Window;
window->show();
return app.exec();
}
(I didn't write that!)
I suspect the window outliving the QApplication instance (and also,
never being reaped properly) is the problem. After changing the above
code to stack-allocate the Window, no more crash.
Should I still report this?
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] Odd crash with QPainter + QOpenGLWidget
I've cargo-culted some code to render text over a QOpenGLWidget from
another project:
void MyWidget::paintEvent(QPaintEvent* event)
{
QOpenGLWidget::paintEvent(event);
auto const& text = /* elided */;
QPainter painter{this};
painter.setPen(Qt::white);
painter.setFont(font());
painter.drawText(rect(), Qt::AlignCenter, text);
painter.end();
}
In the "donor" project, this works fine, but the "recipient" project is
crashing on exit:
==12997== Invalid read of size 8
==12997==at 0x5D204E4: QObject::thread() const (qobject.cpp:1420)
==12997==by 0x598A728: QOpenGLVertexArrayObjectPrivate::destroy()
(qopenglvertexarrayobject.cpp:212)
==12997==by 0x598A9AA:
QOpenGLVertexArrayObject::~QOpenGLVertexArrayObject()
(qopenglvertexarrayobject.cpp:392)
==12997==by 0x5987286:
QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()
(qopengltextureglyphcache.cpp:87)
==12997==by 0x59872AC:
QOpenGLTextureGlyphCache::~QOpenGLTextureGlyphCache()
(qopengltextureglyphcache.cpp:93)
==12997==by 0x576ADAB: ~QLinkedListNode (qlinkedlist.h:69)
==12997==by 0x576ADAB:
QLinkedList::freeData(QLinkedListData*)
[clone .isra.119] (qlinkedlist.h:345)
==12997==by 0x5BB10E8: QHashData::free_helper(void
(*)(QHashData::Node*)) (qhash.cpp:572)
==12997==by 0x576A9BA: freeData (qhash.h:585)
==12997==by 0x576A9BA: ~QHash (qhash.h:254)
==12997==by 0x576A9BA: QFontEngine::~QFontEngine() (qfontengine.cpp:271)
==12997==by 0x18C155FC: QFontEngineFT::~QFontEngineFT()
(qfontengine_ft.cpp:794)
==12997==by 0x576AAE4: QFontEngineMulti::~QFontEngineMulti()
(qfontengine.cpp:1792)
==12997==by 0x18C1E41C:
QFontEngineMultiFontConfig::~QFontEngineMultiFontConfig()
(qfontenginemultifontconfig.cpp:57)
==12997==by 0x575F25E: QFontCache::clear() (qfont.cpp:2796)
==12997== Address 0x8 is not stack'd, malloc'd or (recently) free'd
Any ideas why? Is this a reasonable approach to rendering text in a
QOpenGLWidget, or is there a better way? (I am "fairly confident" that
the problem is the text rendering, above, since the crash goes away if I
comment out said code.)
--
Matthew
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Confused about High-DPI icons...
On 13/03/2019 18.41, Sérgio Martins via Interest wrote: > Do you have: > > QApplication::setAttribute(Qt::AA_EnableHighDpiScaling); Uh... *why* is that not the default? Without that, I still get a scaled UI, but it is an ugly mix of stuff that's *properly* scaled (and making use of the higher resolution) and stuff that isn't. AFAIK, applications that don't turn that on are still susceptible to scaling problems... -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Confused about High-DPI icons...
I'm trying to add High-DPI icons to my application. Currently, I have a bunch of icons as resources, e.g.: :/icons/16x16/open :/icons/16x16/quit ... From reading the documentation, it *sounds* like all I should have to do is add higher resolution icons with "magic" names: :/icons/16x16/open@2x :/icons/16x16/quit@2x ... ...but this doesn't work; I still get the actually-16x16 icons scaled up 2x. (Note: I am testing with QT_SCALE_FACTOR=2/QT_SCREEN_SCALE_FACTORS=2 as I don't have a "real" High-DPI display.) Has anyone gotten this to work? Am I doing something wrong? Am I misreading the documentation? -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Taking back a widget from a QBoxLayout?
On 22/02/2019 15.19, Jason H wrote: > 1. > ''' > void QLayout::addItem(QLayoutItem *item) > ... > void QLayout::addWidget(QWidget *w) > Adds widget w to this layout in a manner specific to the layout. > This function uses addItem(). > ''' > > How can addWidget(QWidget *w) use addItem(QLayoutItem *item) ? > I assume by use, it means "call"? Layouts and Widgets only share QObject... Internally, that function creates a QLayoutItem for the widget (at least, I assume so WCTS¹). (¹ https://cygwin.com/acronyms/) > 2. Furthermore, I am confused about "ownership" vs "parent"ing "Ownership" is used in the general C++ sense, i.e. who is responsible for deleting an object (C++ sense, not QObject) when it is no longer needed. Parenting refers to a special property of some Qt classes by which they "own" certain objects. I would say that, generally speaking "parenting" is "ownership" plus additional stuff, e.g. parenting also has implications for how objects will interact, and often the child knows the identity of its parent. > and why the note about the reparenting during add is not mentioned > in the docs. Hmm... *that* is a fair question :-). > "Note: The ownership of item is transferred to the layout, and it's > the layout's responsibility to delete it." > > However, deletion happens when the parent is deleted. This is > confusing several concepts. Why would the layout ever be responsible > for deleting it? The layout isn't responsible for deleting the widget. It *is* responsible for deleting the layout item. This is partly a convenience, but may be a *necessity*... considering that some functions internally generate layout items, it would be awkward if the caller was responsible for later deleting those. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Taking back a widget from a QBoxLayout?
On 22/02/2019 14.31, Jason H wrote: > addItem: Note: The ownership of item is transferred to the layout, > > and it's the layout's responsibility to delete it. > removeItem: Note: The ownership of widget remains the same as when it > was added. > > So addItem parents it as it's own, then removeItem leaves it. No > wonder it was crashing. This might be a bug? I don't know why > removing it would keep the parent (the layout) then your subsequent > call to delete deleted the widget and it's layout, so the parent was > left dangling. I would have expected that the parent be nulled out, > rather than keep it referencing the layout it had just been added to > and removed from. Perhaps a Troll can comment? If I delete the layout, would that delete the widgets, also? Right now, I can just delete the layout, and the widgets will remain parented to the parent widget. If removing them from the layout also deparented them, it would be easy to leak widgets. It's a combination of convenience and sanity that adding a widget to a layout adds it to the layout's widget. However, a layout is just a thing to manage the position of widgets. It isn't intended to manage the *existence* of widgets. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Taking back a widget from a QBoxLayout?
On 22/02/2019 14.42, Jason H wrote: >>> https://doc.qt.io/qt-5/layout.html#tips-for-using-layouts > From that: > ''' > When you use a layout, you do not need to pass a parent when > constructing the child widgets. The layout will automatically > reparent the widgets (using QWidget::setParent()) so that they are > children of the widget on which the layout is installed. > > Note: Widgets in a layout are children of the widget on which the > layout is installed, not of the layout itself. Widgets can only have > other widgets as parent, not layouts.> ''' > > However: > ''' > void QLayout::addItem(QLayoutItem *item) > [...] > Note: The ownership of item is transferred to the layout, and it's the > layout's responsibility to delete it. > > void QLayout::addWidget(QWidget *w) > Adds widget w to this layout in a manner specific to the layout. This > function uses addItem(). > ''' ...but that's talking about a *QLayoutItem*, which is *not* a QWidget (or even a QObject). It's a class that encapsulates a "thing" (widget, other layour, spacer, ...) that is present in a QLayout. Let's say you have widgets P and C, with P having layout L which contains C. P "owns" C and (AFAIK) L. There *also* exists a layout item I. L owns I. I *references*, but does not own, C. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Replacement for Qt4 QMatrix4x4?
On 22/02/2019 11.39, Jason H wrote: > Well I think if you want such things eigen > (http://eigen.tuxfamily.org/index.php?title=Main_Page) is what you > need. However, I would love to see Qt incorporate some basic > operations. We *almost* had that with QVectorNd and QMatrixNxN... until Qt5 went and made them float. Sigh. What I would *really* love is to see Eigen or the like standardized as part of C++23 :-D. But that's getting OT... -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Replacement for Qt4 QMatrix4x4?
On 22/02/2019 04.08, Paolo Angelelli wrote: > You aren't telling us much, except that you need to invert it and multiply > points with it. > If QtPositioning-private is an acceptable dependency instead of pulling in > eigen (or others), > you could probably get away with the private QDoubleMatrix4x4 that is in > there, basically > a double QMatrix4x4. No... I'm developing *with* Qt. I'm not developing Qt itself :-). Mostly, I was surprised that QGenericMatrix has no method to invert the matrix. (Obviously such method would be conditional on square matrices, but...) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Replacement for Qt4 QMatrix4x4?
So... after a full day of debugging, trying to port my Qt4 app to Qt5 and chase down a nasty case of stack clobbering, I discovered that the problem is that QMatrix4x4 changed from qreal to float. (Uh...why? I am not particularly amused by the loss of precision, nor the extremely subtle incompatibility.) Alas, there does not seem to be any feasible replacement in Qt. I can't use QGenericMatrix because it can't be used to transform QPointF's, nor can it be inverted, both of which are features I require. I *really* don't want to throw out the precision of double, especially as I have tons of other code that still uses double and would have to wade through mountains of conversion warnings to do so. Am I missing something, or do I need to drag in Eigen? -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] moc: undefined interface - only on macOS?
On 01/02/2019 16.07, Matthew Woehlke wrote: > I am trying to build https://github.com/kitware/qtextensions. It builds > fine on Windows and Linux, but on macOS, I get strange errors (from moc) > when trying to build the designer extensions: > [snipped] > > Anyone have any idea why this would not work on macOS, and *only* on macOS? I don't know the *entire* "why", but I found some additional information (and also a work-around), and I'm pretty sure there is a Qt bug here: https://bugreports.qt.io/browse/QTBUG-73500. (Additional details are in the bug report.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] moc: undefined interface - only on macOS?
I am trying to build https://github.com/kitware/qtextensions. It builds fine on Windows and Linux, but on macOS, I get strange errors (from moc) when trying to build the designer extensions: Users/kitware/Jenkins/workspace/FletchMacPR/build/buildqtExtensions/designer/qtOverlayWidgetInterface.h:18: Error: Undefined interface /Users/kitware/Jenkins/workspace/FletchMacPR/build/buildqtExtensions/designer/qtDoubleSliderInterface.h:18: Error: Undefined interface /Users/kitware/Jenkins/workspace/FletchMacPR/build/buildqtExtensions/designer/qtProgressWidgetInterface.h:18: Error: Undefined interface /Users/kitware/Jenkins/workspace/FletchMacPR/build/buildqtExtensions/designer/qtThrobberInterface.h:18: Error: Undefined interface /Users/kitware/Jenkins/workspace/FletchMacPR/build/buildqtExtensions/designer/qtExpanderInterface.h:18: Error: Undefined interface /Users/kitware/Jenkins/workspace/FletchMacPR/build/buildqtExtensions/designer/qtColorButtonInterface.h:18: Error: Undefined interface /Users/kitware/Jenkins/workspace/FletchMacPR/build/buildqtExtensions/designer/qtSqueezedLabelInterface.h:18: Error: Undefined interface Anyone have any idea why this would not work on macOS, and *only* on macOS? The lines that are producing the errors are all: Q_INTERFACES(QDesignerCustomWidgetInterface) The classes all derive (indirectly and through a templated class) from QDesignerCustomWidgetInterface. I'm using Qt 5.11.2 built from sources. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] 80 column enforcement under Linux
On 18/01/2019 17.44, rol...@logikalsolutions.com wrote: > I was unaware Artistic Style is dead. Haven't found a line length thing > in it anyway. I am using Artistic Style for formatting because the > default QtCreator coding style and a project level .astylerc of this: Hmm... well, maybe, maybe not. Last I remember looking, the code had been untouched in quite some time. Looking again, I see the last commit is in April 2018, which is less bad than I thought, but still not terribly active. Again, last I knew, it didn't work very well on "modern C++" (which is to say, using C++11 or later), but of course if you're only doing C, that may not matter for you. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] 80 column enforcement under Linux
On 18/01/2019 13.54, Michael Jackson wrote: > I would think that clang-format should be able to help you out with this. It > is part of the LLVM download. Ugh... clang-format... Be warned: clang-format's version of line length enforcement is *very* draconian. There is exactly one, and *only* one way to wrap a line (for a given configuration, anyway¹). If you try to wrap a line differently, because it improves readability... that's wrong, and clang-format will "fix" it for you. I can't recommend astyle, since it is basically dead, but please do yourself a favor and also look at uncrustify, which is active and can be configured to be far less rigid than clang-format while still enforcing a line length limit. (¹ Basically, clang-format supports "one item per line", "greedy", and nothing in between². You can choose between them, but only globally, not on a per-case basis.) (² Pedantically, it also supports "leave it alone", but only if you turn off line length enforcement, so that doesn't help you.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt5 porting woes - metatype with private ctor
On 07/01/2019 19.07, Thiago Macieira wrote: > On Monday, 7 January 2019 12:57:56 PST Matthew Woehlke wrote: >> Can I use std::unique_ptr in a signal? > > No. If you connected two slots to the signal, which one would get the pointer? ...whichever one is dispatched first, "naturally". For my use case, this never happens, so it's not an issue, however I understand not wanting to support it in general. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Qt5 porting woes - metatype with private ctor
I have a class¹ that implements a "transferable" pointer. The idea is that it is memory-managed, but can be used in signals/slots without the overhead of an atomic reference count. It is a "throw it over the wall" type of thing, the idea being that once it is emitted as a signal argument, the caller can't use it any more. In Qt4, I implemented this by granting special access to qMetaTypeConstructHelper to allow Qt's guts to access the "copy" constructor (which is actually a move ctor, but this code predates C++11). However, it seems in Qt5 I have to poke into the QtMetaTypePrivate namespace in order to do this. This make me... grumpy. Is there a better way to solve this problem? Can I use std::unique_ptr in a signal? Alternatively, is making it so difficult to provide a user-supplied ctor really a good thing? (See also https://bugreports.qt.io/browse/QTBUG-15313, which essentially is asking the same question.) Note that I *have* to have a "smart" pointer, as the use case is to create something and toss it over a wall where it may or may not be received, i.e. Qt needs to free it if no one is connected to the signal. I don't want to just make the ctor public because "normal" users should be prevented from making "copies"; only the signal/slot system should be allowed to make copies. (¹ https://github.com/Kitware/qtextensions/blob/master/core/qtTransferablePointer.h) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QComboBox - rect of actual menu vs widget area
On 29/12/2018 07.54, Roland Hughes wrote: > Method 1: show/hide interesting widget > > Place a label with the animated GIF at the exact same spot as the combo > box. An *animated GIF*? Ugh. No anti-aliasing, won't follow the color scheme... A better option would be to use a "busy indicator" widget. For example, https://github.com/Kitware/qtextensions/blob/master/widgets/qtThrobber.cpp. (Too bad there isn't one in Qt proper :'(.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] [ANN] build2 - C++ build toolchain
On 2016-02-09 04:04, Diego Iastrubni wrote: > On Mon, Feb 8, 2016 at 11:21 PM, Thiago Macieira wrote: >> qmake's philosophy is "assume everything is there and just use it". >> It's meant mostly for using Qt itself, so you can be sure that all >> of it is present. If you use third-party libraries and they're not >> present, you'll get a compilation error somewhere. > > Yes, right. That is why I am probably barking at the wrong tree. I need > CMake support only. > > Integrating 3rd party software into Java/ObjC/Swift code is trivial, there > are lots of project handling this. Its very sad that in 2016 we still don't > have something like that can help integrating 3rd party libraries into my > C++ code. > > How do you guys integrate 3rd party libraries into your code? Don't do that. By doing so, you are assuming responsibility for all the bugs (especially security issues) of said libraries. Most Linux distributions refuse to package any software that bundles third party components for this reason (and others, but the security issue is a deal-breaker). Another down side is that I may not want to use the version you are trying to bundle. For one, it's superfluous if I already have that library. The reason you can get away with this with e.g. Java is because it is a much more closed ecosystem with a rigidly specified mechanism for providing package information (but still has all of the downsides listed above). Unfortunately we don't have that for C++ (although properly written CMake does a darned good job of coming close). -- Matthew ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [ANN] build2 - C++ build toolchain
On 2016-02-09 22:43, Konstantin Podsvirov wrote: > And the Qt project provides great support CMake, how to use the frame (export > modules), and support Qt Creator IDE. Yes, Qt is practically a poster child for what projects *ought* to be doing to make themselves easy to use by other CMake projects... and it's not even itself built with CMake! Seriously, you all (Qt folk) do a really great job there; *thank you* :-). p.s. For "embedding" third party libraries in a CMake-based project, CMake external projects are The Right Thing To Do. (But as elsewhere stated, that's rather OT for here.) -- Matthew ___ 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
On 2016-01-30 08:09, Bernhard Lindner wrote: > 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. You might have better luck creating a repository where you already have your source files :-). (If you're worried about what QtC does, you can just run 'git init .' in your existing source tree. This will create a .git subdirectory but won't touch anything else. I suspect this is all QtC does, but I don't use QtC.) > 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. Your source files must reside in the repository directory. You can copy them there (as Thiago suggests), or see above. -- Matthew ___ 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
On 2016-01-28 19:48, Jason H wrote: >> 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? > > Perforce is free for 20 users / 20 workspaces. I really like it. I used Perforce years ago. Unless it's gotten much better, the only feature it has that I ever found useful is that its history tracks the integration of individual changesets, rather than just branch heads (useful if you want to merge only the later part of a branch; if you decide later to merge the rest, p4 knows which changesets were skipped the first time). Otherwise, I prefer git in every way. (Having to "open" files before they can be edited, for instance, is especially annoying and IMO unnecessarily inefficient.) > But use git. Even though it's overkill if not doing distributed > development, _everyone_ uses it. It may be overkill, but it's also a joy to use. Here's how to set up a git repository for personal use: $ git init . *That's it*. I'm not going to try to explain how to set up a svn or p4 instance for personal use. Suffice to say, it's nowhere near as easy as git. This "only" gets you a local repository, but it's similarly trivial to add a remote repository later. (Unlike centralized VCS's, git repositories are "peers"; associations can be created or dropped at any time, and the idea of a "primary" repository is a purely sociopolitical convention.) -- Matthew ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] OT: perforce (was: Local version control with Qt Creator on Linux)
On 2016-01-28 19:54, Thiago Macieira wrote: > On Friday 29 January 2016 01:48:06 Jason H wrote: >> Perforce is free for 20 users / 20 workspaces. I really like it. The only >> issue is by default files not checked out are readonly. This causes >> problems when building for iOS/Android as the manifest files can't be >> changed without a checkout. > > 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. I've run into situations where certain files really should be checked in, but for some reason the build needs to be able to "modify" them (probably a sign of a badly designed build tool, but sometimes you're stuck with those). Back when I used p4 (years ago, and it was an old version even then), you could tell the repo that certain files should always be writable... -- Matthew ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Can't login to bugreports
On 2016-01-21 11:37, Thiago Macieira wrote: > On Thursday 21 January 2016 16:18:52 Jason H wrote: >> It seems the login now requires an @, and something is amiss in my account. >> >> Can someone look into it? The password reset link isn't working. I'm not >> sure which email domain it is going to, but none of them have received a >> password reset link. > > This was announced several times. You need to log in with your Qt account > (see > http://account.qt.io). Jason, do you *have* a Qt account? I didn't. I had to create one using my Jira e-mail. Once I did that, I could log into Jira and see my old bug reports. -- Matthew ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
