General and Desktop

@Kent-Dorfman Moles and trolls...Moles and trolls...LOL Seen your own DP lately? Great Projection, so very helpful to newbies this is surely helping Qt stay afloat. Oh whats this? https://news.ycombinator.com/item?id=28627022 “Engineers can't explain it, legal can't understand it", “What companies want is certainty… Qt lacks it”,"It’s not just cost — it’s fear of getting licensing wrong",,"Qt's corporate owners have been openly hostile to the community for a while" are common sayings in the community? I was even being well civil but now i shall and will be otherwise: can't even answer lack of basic devops fundamental industry flows in QT, or improve itself while worse companies like microsoft can. May the likes of Oracle and Qt and others with majority investors from banking sectors may drown in their yachts in random storms.. metaphorically. @Christian-Ehrlicher ban my soon to be autoscripted posts from my x many emails as x many times you want, truth will remain that Qt is abandonware without KDE and ugly frankenstein's monster with pinochio's nose thanks to yall bloodthirstynachtzikapitalists. You'r both getting traction at bilbili already. it will be fun :D Well i was able to rework my QT app to a better cross platform technology in just few hours and removed all Qt bs from my home now, also have I blocking my own account notifications coming from QT all ze bezt

@nicholas_ru Since that directory has various files with qt6 in their name and comment Change CMake code to enable building against Qt 5 or 6 I would guess it has already been made to work with Qt6 for you..... You did look inside e.g. CMakeLists.txt to check you are asking for Qt6 instead of Qt5, didn't you?

@Jacek-Marcin-Jaworski This is user forum, you should rather file a bug report in https://qt-project.atlassian.net/jira/projects

Hi, I think this article about translation in Qt can help you understand the voodoo behind language selection.

@Yunus You will need to attach a qsizegrip to your windows. Check this https://github.com/jordanprog86/QtTransparentWindow.git

I code PostreSQL DB in 2018-2019y., but try to call stored stored procedure from select: query.prepare("select call insert_expense_detail_record(:expense_id, :expense_date, :expense_amount)"); The reason is that "SQL data manipulation language" (beside "SQL data definition language") allow only insert, select, update and delete commands. BTW: In order to avoid typo like above, you can use convenient psql CLI command line in order to test your queries. BTW: Please use </> in your 1. message in this thread - because it looks ugly.

I change the code to read: QPoint position = timingTree->mapToGlobal( moveEvent->position( ).toPoint( ) ); QToolTip::showText( position, error.what( ), ui->timingTree ); and this works.

@JonB said in QLayout retroactive parenting?: @Estelyen said in QLayout retroactive parenting?: dlg->setLayout(layout); // will btn be retroactively made a child of dlg here? So far as I know, yes. In any case, it's so easy to check e.g. btn->parent() after this, so if you're worried why not do so? Okay, facepalm moment for me, I searched fo so long and never tried checking it myself. Need some sleep, apparently. Anyways, I just did a test and it indeed assigned dlg as parent of btn. At least the memory addresses are the same. Thanks for the help!

@Christian-Ehrlicher Thanks!!

@Christian-Ehrlicher Thanks a lot. We already started a couple of years back in this project, and we went for 5.15.2. To make things even weird I asked about it in Qt subbreddit here and the answer proposed works fine for this test app, but the actual project is still doing weird stuff.

@Joe-von-Habsburg Ah ha! One of us should have mentioned this when you said about sender packet size :(

@marlonbuilder For your choice of using a thread --- and especially if you are not familiar with threads and their requirements --- as @jsulm has said it is not clear why you need one at all. Try it from the main event loop and only look into threads if there is a problem. Newcomers to Qt often rush into sub-threads when there is no need. For your updating of widget(s). Assuming you have some widget listening for dataChanged() signal. If you say that is happening too frequently and thereby causing lag --- is it? have you actually tried? if you are only emitting dataChanged() "a certain number of times per second" that may be fine, depending on how many times --- then you have a couple of choices. Basically you would want to "delay" emission of signal causing update so that you can "accumulate" multiple updates into one update for redraw. You might interpose a QIdentityProxyModel between your model and the widget to control signal emission. Or since you seem to have a setStat() which calls dataChanged() explicitly itself you might do it there. You would introduce a QTimer --- single shot or repeating --- which you start when setStat() is called and only when that times out would you emit a dataChanged(), with the data as it is at that point, having accumulated/ignored the earlier updates. Make the frequency of the timer sufficient for user, e.g. does user really need to see updates more than, say, 10 times per second? Although the situation is rather different, the principle is similar to that recently discussed in my post at https://forum.qt.io/topic/164540/spin-box-and-slider-tracking/11.

I've marked this as solved. Whilst I didn't get a perfect / ideal answer, I Did some good responses and enough information to make a decision for my use case. In the end I decided that a refactor would be too much work, and while i came up with other more elegant solutions, they really all just boiled down to an extra call to setGeometry, so i ended up going with the existing fix. Thanks everyone though.