Re: [Interest] Feature Request - QtCreator - Multiple right margins
Hello, Il 08/02/19 15:19, rol...@logikalsolutions.com ha scritto: While it would be awesome if QtCreator could let it be completely arbitrary as Sublime does: "rulers": [80, 100, 120], "word_wrap": true, "wrap_width": 120 It would be nice to be able set 2 with the farthest one being the wrap point if wrapping is enabled. Most shops strive for 80 but put in their "overrides" for the standard a hard limit of 130. As it stands now we can see what we strive for or the hard wall, but not both. Submit a "feature request" on Jira? It's the best way to have something like this properly tracked. Also, there's a dedicated mailing list for Qt Creator users, you may want to ask there as well. Regards, -- 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] Issue using QSettings INI format on Windows
> Well there's always QSettings::registerFormat ( > https://doc.qt.io/qt-5/qsettings.html#registerFormat ) > > Haven't tried it myself but it will give you a QSettings::SettingsMap > which means you'll still have to serialize out it yourself to a QString, > but at least you can get rid of the file i/o by ignoring those > QIODevices that QSettings hands over. /Rgrds Henry I didn't notice that one. That might work for our needs, I'll have to play around with it... Thanks (twice now!) Sean This message has been scanned for malware by Forcepoint. www.forcepoint.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Issue using QSettings INI format on Windows
On 2019-02-08 23:56, Murphy, Sean wrote: Hi, just tested your example program in MSVC 2017 Qt 5.12.1 and it fails as well. But a simple fix is just to make sure that the QFile file isn't open at the same time as you write out the settings to it. I.e. in your example program, it suffices to move that first file.close(); up to just before the "// write out via QSettings" comment line is, then it runs flawlessly. But perhaps that's not possible to keep those writes separate in time in your "real" app that your porting? Thanks for testing! Yes, I discovered that issue as well, and then forgot to post a follow-up here. Where I had trouble, and something I did differently in the real app vs. the minimal example, is that the file I was trying to use to write the settings to was a QTemporaryFile. I stumbled across the same fix you did in the example, but that fix never seemed to work in my real app with a QTemporaryFile. After testing, I believe that is because the QSettings object is trying to open the associated settings file with write permissions, and it isn't able to acquire them. In my example, it was because I already had opened the file with write permissions (mistakenly thinking I needed to do that before all the QSettings stuff). In my real app, I think that it must be because QTemporaryFile holds a lock on the file so it can remove it when the QTemporaryFile object goes out of scope, and therefore the QSettings object gets an access error because the file is already in use. What I'm actually trying to accomplish is far more simple: I don't actually want an INI file, I just want to get data that I've put into a QSettings object written to a QString, in the INI file format. I couldn't see any other way to do that than to write it out to a file, then read the file contents back into a QString. So if you see a simpler solution for that, I'm open to suggestions! Well there's always QSettings::registerFormat ( https://doc.qt.io/qt-5/qsettings.html#registerFormat ) Haven't tried it myself but it will give you a QSettings::SettingsMap which means you'll still have to serialize out it yourself to a QString, but at least you can get rid of the file i/o by ignoring those QIODevices that QSettings hands over. /Rgrds Henry ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Issue using QSettings INI format on Windows
> Hi, just tested your example program in MSVC 2017 Qt 5.12.1 and it fails > as well. > > But a simple fix is just to make sure that the QFile file isn't open at > the same time as you write out the settings to it. > I.e. in your example program, it suffices to move that first > file.close(); up to just before the "// write out via QSettings" comment > line is, then it runs flawlessly. > > But perhaps that's not possible to keep those writes separate in time in > your "real" app that your porting? Thanks for testing! Yes, I discovered that issue as well, and then forgot to post a follow-up here. Where I had trouble, and something I did differently in the real app vs. the minimal example, is that the file I was trying to use to write the settings to was a QTemporaryFile. I stumbled across the same fix you did in the example, but that fix never seemed to work in my real app with a QTemporaryFile. After testing, I believe that is because the QSettings object is trying to open the associated settings file with write permissions, and it isn't able to acquire them. In my example, it was because I already had opened the file with write permissions (mistakenly thinking I needed to do that before all the QSettings stuff). In my real app, I think that it must be because QTemporaryFile holds a lock on the file so it can remove it when the QTemporaryFile object goes out of scope, and therefore the QSettings object gets an access error because the file is already in use. What I'm actually trying to accomplish is far more simple: I don't actually want an INI file, I just want to get data that I've put into a QSettings object written to a QString, in the INI file format. I couldn't see any other way to do that than to write it out to a file, then read the file contents back into a QString. So if you see a simpler solution for that, I'm open to suggestions! In my real app, I've solved it by using removing the QTemporaryFile object, and just letting QSettings do its thing, writing to a file. Then when the file has been written, I read it back in to a QString, and delete the file since I have no further use for it. Sean This message has been scanned for malware by Forcepoint. www.forcepoint.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Issue using QSettings INI format on Windows
On 2019-02-08 14:46, Murphy, Sean wrote: I'm porting an old application from Qt 5.3.2 to Qt 5.9.6 (yeah, I know, we're a lot behind...). I'm running into an issue where code we had that was writing out settings via the QSettings constructor that takes a file name doesn't work anymore. I've attached a fairly minimal example that shows this. What I've found so far: - this code works perfectly on Windows using Qt 5.3.2 (mingw 4.8.2) - this code works perfectly on a Mac using Qt 5.9.6 (clang) - this code fails on Windows using Qt 5.9.6 (mingw 5.3.0) Anyone have any ideas? Sean Hi, just tested your example program in MSVC 2017 Qt 5.12.1 and it fails as well. But a simple fix is just to make sure that the QFile file isn't open at the same time as you write out the settings to it. I.e. in your example program, it suffices to move that first file.close(); up to just before the "// write out via QSettings" comment line is, then it runs flawlessly. But perhaps that's not possible to keep those writes separate in time in your "real" app that your porting? Rgrds Henry ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Netiquette [was: Feature Request - QtCreator - Multiple right margins]
> > [...] > I do appreciate the open discussion style on this list. I even do > appreciate a somewhat harsh style, if it has a factual base and is > getting straight to the point instead of b*s*ing around. But those > lengthy wallpapers our President of Logikal solutions commonly utters, > have long since crossed the border from amusing to annoying. > I, myself, still perceive them more as amusingly misguided, than really angering (annoying at times, yes). This is just me, though, I have experience with that kind of thing. However, I can very well imagine how you, and most certainly others, are finding them taxing; not surprising at all. Plus, as I rule, I tend to discard anything that references fortran or cobol as examples of anything ... ;) ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Netiquette [was: Feature Request - QtCreator - Multiple right margins]
Yep. Why don't we use our Code of Conduct here? https://codereview.qt-project.org/#/c/243623/ On 2/8/19, 6:47 PM, "Interest on behalf of m...@herrdiel.de" wrote: "All", somebody who calls a whole platform "idiot" lacks any respect for those who work in that field. Doing so repetetively whenever mentioning "phones", is not a slip of the keyboard but is done intentional - which puts the author in the very vincinity of his own vocabulary. I don't want to read this kind of indignity ever and anon. I've rarely seen such constantly condescending and trolling behavior being tolerated as long as with this individual. Loaden with self-advertizing links, his rants and unproven premises often need no more factual base than his opinion and in their narcissistic self-repetition they have long become spam. It is fine to have an opinion. It's ok to state it clearly. But to hawk it with almost every email and in every non-related context is getting a tad tedious. I don't want programmers (like me) to be insulted as "script kiddies" and "12 year old boy"s with "shabby skill levels" that write "idiot apps" for "idiot phones" that have "the lifespan of a fruit fly". It's ok to be carried away a bit, but these deliberate defamations are a pattern. I don't want to read all that self-righteous boasting about his experience from the age of vacuum tubes and Zuse I. I just don't care. It's just OT, as Giuseppe D'Angelo pointed out a while ago. I don't want to read stuff like "QML (puke)" from somebody who has long passed puberty. I do appreciate the open discussion style on this list. I even do appreciate a somewhat harsh style, if it has a factual base and is getting straight to the point instead of b*s*ing around. But those lengthy wallpapers our President of Logikal solutions commonly utters, have long since crossed the border from amusing to annoying. As for me, I have just plonked Roland Hughes again (no, not the first time). But that doesn't help if I have to read through all the avalanches of replies who just feed the troll (like mine now, probably). I'd be happy to see him banned, at least temporarily. But then again, I am just a 12-y-o script kiddie (not true) with a shabby skill level (true), so you won't really need advice from me. Sorry for the rant. Won't happen again on this topic. Sebastian Am 08.02.2019 um 15:19 schrieb rol...@logikalsolutions.com: > > All, > > Slightly off topic but still relevant, if Qt cares even slightly about > still being used in the embedded world. If all they care about are > idiot phones and that declining market, I guess this doesn't matter. > > https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard > > Given much of the embedded world tries to adhere (mostly) to the Barr > standard but falls victim to the wordiness of our C++ world (even > COBOL looks askance at Q_PROPERTY macros) we tend to work in worlds > which require multiple right margins, only one of which has a hard > wrap. While it would be awesome if QtCreator could let it be > completely arbitrary as Sublime does: > > "rulers": [80, 100, 120], > "word_wrap": true, > "wrap_width": 120 > > It would be nice to be able set 2 with the farthest one being the wrap > point if wrapping is enabled. Most shops strive for 80 but put in > their "overrides" for the standard a hard limit of 130. As it stands > now we can see what we strive for or the hard wall, but not both. > > Thanks > -- http://www.classintouch.de - Tablet-Software für Lehrer ___ 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
Re: [Interest] Netiquette [was: Feature Request - QtCreator - Multiple right margins]
"All", somebody who calls a whole platform "idiot" lacks any respect for those who work in that field. Doing so repetetively whenever mentioning "phones", is not a slip of the keyboard but is done intentional - which puts the author in the very vincinity of his own vocabulary. I don't want to read this kind of indignity ever and anon. I've rarely seen such constantly condescending and trolling behavior being tolerated as long as with this individual. Loaden with self-advertizing links, his rants and unproven premises often need no more factual base than his opinion and in their narcissistic self-repetition they have long become spam. It is fine to have an opinion. It's ok to state it clearly. But to hawk it with almost every email and in every non-related context is getting a tad tedious. I don't want programmers (like me) to be insulted as "script kiddies" and "12 year old boy"s with "shabby skill levels" that write "idiot apps" for "idiot phones" that have "the lifespan of a fruit fly". It's ok to be carried away a bit, but these deliberate defamations are a pattern. I don't want to read all that self-righteous boasting about his experience from the age of vacuum tubes and Zuse I. I just don't care. It's just OT, as Giuseppe D'Angelo pointed out a while ago. I don't want to read stuff like "QML (puke)" from somebody who has long passed puberty. I do appreciate the open discussion style on this list. I even do appreciate a somewhat harsh style, if it has a factual base and is getting straight to the point instead of b*s*ing around. But those lengthy wallpapers our President of Logikal solutions commonly utters, have long since crossed the border from amusing to annoying. As for me, I have just plonked Roland Hughes again (no, not the first time). But that doesn't help if I have to read through all the avalanches of replies who just feed the troll (like mine now, probably). I'd be happy to see him banned, at least temporarily. But then again, I am just a 12-y-o script kiddie (not true) with a shabby skill level (true), so you won't really need advice from me. Sorry for the rant. Won't happen again on this topic. Sebastian Am 08.02.2019 um 15:19 schrieb rol...@logikalsolutions.com: > > All, > > Slightly off topic but still relevant, if Qt cares even slightly about > still being used in the embedded world. If all they care about are > idiot phones and that declining market, I guess this doesn't matter. > > https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard > > Given much of the embedded world tries to adhere (mostly) to the Barr > standard but falls victim to the wordiness of our C++ world (even > COBOL looks askance at Q_PROPERTY macros) we tend to work in worlds > which require multiple right margins, only one of which has a hard > wrap. While it would be awesome if QtCreator could let it be > completely arbitrary as Sublime does: > > "rulers": [80, 100, 120], > "word_wrap": true, > "wrap_width": 120 > > It would be nice to be able set 2 with the farthest one being the wrap > point if wrapping is enabled. Most shops strive for 80 but put in > their "overrides" for the standard a hard limit of 130. As it stands > now we can see what we strive for or the hard wall, but not both. > > Thanks > -- http://www.classintouch.de - Tablet-Software für Lehrer ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Feature Request - QtCreator - Multiple right margins
All, Slightly off topic but still relevant, if Qt cares even slightly about still being used in the embedded world. If all they care about are idiot phones and that declining market, I guess this doesn't matter. https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard Given much of the embedded world tries to adhere (mostly) to the Barr standard but falls victim to the wordiness of our C++ world (even COBOL looks askance at Q_PROPERTY macros) we tend to work in worlds which require multiple right margins, only one of which has a hard wrap. While it would be awesome if QtCreator could let it be completely arbitrary as Sublime does: "rulers": [80, 100, 120], "word_wrap": true, "wrap_width": 120 It would be nice to be able set 2 with the farthest one being the wrap point if wrapping is enabled. Most shops strive for 80 but put in their "overrides" for the standard a hard limit of 130. As it stands now we can see what we strive for or the hard wall, but not both. Thanks -- Roland Hughes, President Logikal Solutions (630) 205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog http://lesedi.us ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Issue using QSettings INI format on Windows
I'm porting an old application from Qt 5.3.2 to Qt 5.9.6 (yeah, I know, we're a lot behind...). I'm running into an issue where code we had that was writing out settings via the QSettings constructor that takes a file name doesn't work anymore. I've attached a fairly minimal example that shows this. What I've found so far: - this code works perfectly on Windows using Qt 5.3.2 (mingw 4.8.2) - this code works perfectly on a Mac using Qt 5.9.6 (clang) - this code fails on Windows using Qt 5.9.6 (mingw 5.3.0) Anyone have any ideas? Sean This message has been scanned for malware by Forcepoint. www.forcepoint.com <> ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
