Szóval hogy hát előválasztás, mi jobbak vagyunk (amúgy egyenként is), mint aki lenyomott minket stb. fázis elérkezett, lehet örülni, hogy mindenkiben van némi győzni vágyós indulat.
There's about a trillion reasons why I shouldn't be doing coding work today - but so is an equally mounting earlier evidence of habitually avoiding doing the thing I should be doing... 👍
The below apology stopped working for a while.
Fortunately now it's back and good as new. (The underlying flaky, lagging, almost entirely sub-operational service didn't really change a jot IMHO.)
"If you have breakfast, you have everything. If you had breakfast, you had everything, but you ate it."
... just theoretically as I like the taste :)
The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.
https://12factor.net/config
so here comes industry best practice! "seemingly a bit paradoxical"
(Note that my thoughts might be opinion-based. And yes, I guess an implicit assumption that there are only a handful of variables fixes this. Namespace-resemblant naming etc.. There are workarounds.
However, that backdoor to unwanted interdependency creeps is starting to open in any case :) and human patience as well as developer discipline I guess are typically very finite things ...)
Guessing the desktop option can be a little bit young, but 30-50% offset consumption (of one) CPU (core) feels like a bit too much of bottoms up, doesn't it?
Seems I tried a current and stable version though:
Perhaps it's just the Linux/Snap build? Someday I'll have a 2nd look.
Apart from this, can be a useful tech to add to the stack, maybe more on the mobile development side at this point. A little disappointed :(
I think this is when you say, 'yes, business value was finally understood'.
QMouseEvent
In PyQt6
QMouseEventobjects no longer have the.pos(),.x()or.y()shorthand property methods for accessing the position of the event. You must use the.position()property to get aQPointobject and access the.x()or.y()methods on that. The.position()method is also available in PySide6.
There are other fancy feature renames/move around in packages too. Welcome to the 2020's!
(Except that not sure anyone ever asked for this change? Will anyone's life get better after this? Will we have a lot of fun? Sure... well, you can't please everyone, can you.)
UPDATE: Quite pleased to say QRegExp has been renamed to QRegularExpression. I can now update my source code for that additional reason too - was worth getting up :) <3
Feels like we're actually going somewhere no!
UPDATE2: and a hardfelt welcome goes out to QRegularExpressionValidator! Feeling spoiled now :))
UPDATE3: it seems indeed a good idea. I like how QMouseMoveEvents can now provide us QPointF positions() instead of the bad old integer QPoints under the tasteless pos() name, which then considerately cannot be passed in to helper methods on other classes. Hopefully it isn't the only case, as it's really a good idea to make large scale inconsistent design changes, which are cemented in until the next major release can hit our heads, and we're finally allowed again to make some (unusually) irresponsible updates to our source code <3
UPDATE4: maybe it's too much of good things for a day... let's leave it for now ... (remark: at least one package my project relies on lacks PySide6 support ... and not that I am overly sensitive but I was a little surprised to get QMouseWheel events in a mouseMove() method :) it might be me to blame for that, but then my Shiboken2 problems weren't gone either.)
De azért marha jól néz ki :)
https://www.ebay.co.uk/itm/Fake-Fine-Gold-Bullion-Bar-Paper-Weight-Door-Stop-6-Prop-Home-Decor/383924904639
