Re: [Interest] Editor history (was: Re: Signal/Slot connection, fails, ...)
On 2/17/20 5:00 AM, interest-requ...@qt-project.org wrote:
One of the only two(*) things I miss about using Eclipse is that it
automatically kept a history of file changes every time you saved (up to
some configurable time period). And a built-in diff viewer where it was
easy to compare revisions, revert all or parts, etc. Would be great to
have that option in QtCreator.
I believe UltraEdit had something like this as well. It just had a
wretched K type coding style it forced on you.
https://www.ultraedit.com/support/tutorials-power-tips/ultraedit/version-backup.html
On OpenVMS we never had to worry about this because RMS (Record
Management System) (one of those pesky things "not needed" by Linux or
other PC based operating systems) created a new version of the file
right where it was every time you saved. Ascending version numbers from
1 - 32767. You got rid of the lower version numbers via the PURGE
command and if you were really worried you could rename the current
version to version 1 after that.
The still high priced highly restrictive licensed SlickEdit also has the
feature you request. They call it Backup History.
https://www.slickedit.com/products/slickedit/cool-features#h-files-editing
Sublime Text has a plugin for this.
https://packagecontrol.io/packages/Automatic%20Backups
Within QtCreator and KDevelop such a feature is wonderful. I tend to use
Sublime for lots of general editing, not just code. My "history" could
get massive.
I seem to remember vEdit having this feature back in the days of DOS.
https://www.vedit.com/
Seem to remember the Watcom IDE having this feature under OS/2, perhaps
all platforms, back in the day
I know we can manually commit from QtC, but it's not as simple or
foolproof (even an automated commit message like "version from 1/1/2000
13:05:15" would be helpful). And if the project is already under a VCS
like git which will be published publicly, I don't want all my interim
saves clogging it up. (Make a branch, yeah... then remember to not push
it, and to switch branches before any "real" commits..., and clean it
out regularly so the index doesn't get out of hand. I already try to do
that to some extent ("WIP" branch) but it's not ideal.) Would love to
know about a better way.
It's a culture shift you won't find in the AGILE universe which is why
it is so poorly supported via PC tools. In the midrange and mainframe
world where software engineering actually exists and any attempt at
bringing in AGILE will ensure you spend the rest of your career saying
"Hi, welcome to Walmart", it's a completely different story.
I had a long section about it in this book:
http://www.theminimumyouneedtoknow.com/app_book.html
Code management in these environments is all about capturing _relevant_
changes while protecting the developer from themselves. That particular
concept has not translated down to the small machines. Maybe with
GitKraken or something like that you can push from tip without bringing
the baggage, but I haven't dug into it. I have a professional license
for GitKraken, just don't have it installed anywhere because nobody uses
Git in the medical device world. Mostly Perforce family of products.
Each developer assigned a new project is given their copy of The Four
Holy Documents and assigned a development area. These number from D01 to
D99. They are full environments with some snapshot of production data.
The developer deletes the code management system creating a shiny new
one with a copy of the very tip of the production CMS. The build
procedures all build from the CMS. You can single compile a file from
the command line or within your editor, but you cannot build & debug ala
PC IDE because all changes must be checked in.
When the developer believes they have a fully functioning project
solution that matches the actual specs without violating the SAD (System
Architecture Document) and which doesn't introduce any new
tool/library/whatever that has not been signed off on and approved for
use by project management, they create a CMS Class. This includes
whatever specific version of whatever specific source files the
developer believes should be promoted for integration testing. They then
are assigned an integration test environment T01 - T99. They wait for
the test team to inform them the environment is ready for their
promotion. After that they run the promotion script where only the files
in the class, and not the 10 billion check-ins required to make it work,
are promoted into test.
Once it passes integration testing others are responsible for scheduling
a promotion into the production CMS as well as a full production turn.
Immediately in front of the production promotion and full production
turn the current production will be snapped to the support CMS and build
area. Yes, one could fall/roll back, but this is faster and the support
area allows production issues to be verify on the development
[Interest] process setting on QWidget - how
QProcess *process = new QProcess();
QStringList progargs;
progargs << "/C" << "start C:\\ProgramData\\Microsoft\\Windows\\myapp.exe
dicom:get C:\\Slicer\\Testing\\Data\\Input\\DWIDicom\\MR_0004_0028.dcm";
process->start("C:/windows/system32/cmd.exe", progargs);
if (process->waitForFinished())
{
return;
}
QWindow *appWindow = QWindow::fromWinId(process->processId());
appWindow->setFlags(Qt::FramelessWindowHint);
_patient_gui->widget->createWindowContainer(appWindow);
/
This is the code snippet, with which I am trying to launch an external
application and setting it on a QWidget. But it is not working.
Can I get some help on this, can you check what is wrong in this code.
___
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
Hi Matthew, On 2/17/2020 4:27 PM, Matthew Woehlke wrote: On 15/02/2020 00.40, Max Paperno wrote: 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*, Well, no, I did mean the same object (shared lifetime can be dubious, I agree). But you're right, a rare situation, especially in well-designed/robust object code. Maybe for a QueuedConnection, but that of course would require the 5-argument overload anyway (or just using a queued QMetaObject::invoke(this, ...) in the first place). But for example a simple button subclass which does something internal (change color, show a message, self-destruct :-P ) when pressed... so one could just connect to the clicked signal in the c'tor and do something "self-contained" which doesn't affect anything besides itself. Yea... I'm probably reaching here. On 2/17/2020 4:27 PM, Matthew Woehlke wrote: On 15/02/2020 00.40, Max Paperno wrote: 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. Of course. Explicitly queued can be very useful, I agree. Cheers, -Max ___ 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
Il 08/02/20 03:37, Jonathan Purol ha scritto: 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. By the way: there's QSignalBlocker for not forgetting... HTH, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ 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] QWebSocket text methods should be utf8?
14.02.2020, 23:56, "Thiago Macieira" : > On Friday, 14 February 2020 11:13:24 PST Jason H wrote: >> After reviewing the QWebSocket spec ( https://tools.ietf.org/html/rfc6455 ) >> text frames are supposed to be UTF-8 encoded, which would mean that >> QByteArray would be the proper class. > > No, QString is the proper class because it's *text*. QWebSocket will convert > from UTF-8 to UTF-16 and back for you. FWIW, having to do useless transcoding just to use an API doesn't fit into my definition of "proper". > >> Now I'm having to toUtf8() all the things I receive, and QString() the ones >> I send. I am sure this leads to some degree of madness. I'm wondering if it >> would be possible to provide proper overloads: >> - sendTextMessage(const QByteArray ) >> - textMessageReceived(const QByteArray ) >> - textFrameReceived(const QByteArray , bool isLastFrame) > > https://codereview.qt-project.org/c/qt/qtwebsockets/+/268194 > > Feel free to pick up where I left off. I have absolutely no interest in web > sockets so will not work on this. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QWebSocket text methods should be utf8?
Il 15/02/20 15:46, Roland Hughes ha scritto: The QString class, by virtue of the little yippy-yappy dogs it is running on isn't big-endian hence your continually calling toUtf8(). Endianess has nothing to do with this: 1) QString is UTF-16 encoded (in host byte order). The whole ordeal is that it's *not* UTF-8, therefore it needs to transcode from it (even on big-endian systems). 2) UTF-8 has the same byte order everywhere. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Editor history (was: Re: Signal/Slot connection fails, ...)
One of the only two(*) things I miss about using Eclipse is that it
automatically kept a history of file changes every time you saved (up to
some configurable time period). And a built-in diff viewer where it was
easy to compare revisions, revert all or parts, etc. Would be great to
have that option in QtCreator.
I know we can manually commit from QtC, but it's not as simple or
foolproof (even an automated commit message like "version from 1/1/2000
13:05:15" would be helpful). And if the project is already under a VCS
like git which will be published publicly, I don't want all my interim
saves clogging it up. (Make a branch, yeah... then remember to not push
it, and to switch branches before any "real" commits..., and clean it
out regularly so the index doesn't get out of hand. I already try to do
that to some extent ("WIP" branch) but it's not ideal.) Would love to
know about a better way.
-Max
* The other is being able to mouseover a macro and see it expanded into
formatted code, including parameter substitution if the macro uses
arguments. IIRC it was even recursive, meaning any other macros in the
base macro would also get expanded. Didn't work 100% of the time, but
still a useful feature.
On 2/14/2020 3:05 PM, Matthew Woehlke wrote:
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.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QML property lint suggestion
> I'm here watching Ulf's QtWS19 QML talk and had a thought... I might > be dumb or crazy (either are equally likely) but, the other day I > added a property called 'data' and completely broke my application. > It was to store data I received. However QML also declares a property > 'data' which is essential to Qt. But I never got an error or warning. > So my suggestion is to have some warning (or error?) like "declared > property 'data' shadows an existing property" You probably mean QQuickItem::data(). It is not QML that came up with the name, but rather QtQuick. It would be appropriate to make that property FINAL in Qt6, so that you do get a warning when trying to shadow it. I don't think we can change the name at this point, but adding an alias might be possible. Ulf ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
