Re: [Development] QConfig update.
Please do not assert on the library, you're going to make everyone's
program crasheable by just editing a file by hand.
On Tue, Oct 14, 2014 at 7:06 PM, Milian Wolff milian.wo...@kdab.com wrote:
On Tuesday 14 October 2014 13:44:30 Tomaz Canabrava wrote:
On Tue, Oct 14, 2014 at 1:35 PM, Milian Wolff milian.wo...@kdab.com
wrote:
On Tuesday 14 October 2014 13:22:51 Tomaz Canabrava wrote:
People, I'v read everything on the other two e-mails and I'v changed
quite
a few things here and again I ask for some advice.
What I'v done:
QConfig / QConfigGroup / QConfigWatcher combo classes, to be used
from
the
user
QConfigIniBackend, to be used internally.
QConfig:
uses a 'global' QHashQString, QConfigIniBackend for different
files
in
a way that we don't destruct the info when the object is destroyed,
but
reuses the JSON information stored, and parse it to the config
object.
it has a QConfigGroup 'global' value that can be acced directly via
.setValue and .value
Why the global state? A QConfig should be valid for a single file and
constructed on-demand. If you want to share stuff and keep it open,
adding
something like a KSharedConfig might be a good idea. But again, that is
something that could/should be built on-top of QConfig (imo).
so I don't need to open a config file and parse it every time the user
created a QConfig object.
Then provide a QSharedConfig or let the user store the QConfig himself, if
it
turns out to be a performance-bottleneck for him. If you add global state
to
QConfig, you'll need synchronization or otherwise you are doomed in a
multithreaded application.
Also: If you add a cheap JSON cache, is it really worth to optimize at all?
Furthermore: If you keep the QConfig in memory all the time, you'll
probably
end up duplicating the stuff as soon as you add the fancy high-level
interface
on-top. QConfig will operate on JSON after all and you'll incur a
conversion
penalty whenever you read a value from it. The high-level interface should
(hopefully) read the values once and store it internally in the proper
type.
If you don't do this and always read from QConfig, you'll end up with
issues
in this pattern:
void HighLevelConfig::setFoo(quint64 foo)
{
if (foo == m_foo) {
return;
}
m_foo = foo;
emit fooChanged(foo);
}
If this would read from QConfig, instead of directly comparing to the
quint64
m_foo member, you'll get rounding errors etc. pp. This, the more I think
about it, is actually a big issue with a JSON cache in general. .ini does
not
have that issue as the byte-array gets interpreted based on the type you
pass
along (a kind of duck-typing). It might mean that you'll have to store
everything as a string in JSON to prevent a loss of data when storing e.g.
std::limitsquint64::max() (note: JSON only knows double). But storing
everything as a string looses the difference between
foo=1
and
foo=1
Afaik this issue has not yet been discussed, has it?
QConfig and QConfigGroup *does not* support setting a default value
on
the
getter, I know that this is used in a lot of places but this can
cause
inconsistencies:
Main.cpp
QConfig c;
c.value(window-width, 800);
MainWindow.cpp
c.value(window-width, 1200);
so we must create a better way for that. for now, I simply removed
the
possibility for that, we can only do
c.value(window-width);
And how do you check whether window-width was read or not? What do you
return
on error? A default-constructed value? What type does the value have
for
that
matter?
Imo, this makes this API extremely inconvenient. Yes it's possible to
do
an
error, but that is life. You should only add such error-prevention
stuff
into
the high-level schema stuff, not into QConfig itself.
Without the ability to provide a default value, one can never figure
out
whether `c.value(some-int) == 0` means the value could not be read
and a
default should be used, or whether the value is 0.
Since I wanted to add schema-validation on the low level stuff, this
wouldn't be an issue,
'value couldn't be read' would cause an assert.
but I can postpone this for later.
Most applications, (all KDE applications btw), would then assert.
Initially,
no configuration file is available after all.
And again: Please do not overdesign QConfig. KISS! Add fancy
schema-validation
and stuff on-top of that. Don't remove something as essential as reading a
setting with a default value fallback mechanism!
Bye
--
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbHCo KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Re: [Development] QConfig update.
On 14/10/2014 19:06, Milian Wolff wrote: It might mean that you'll have to store everything as a string in JSON to prevent a loss of data when storing e.g. std::limitsquint64::max() (note: JSON only knows double). To be more precise : JSON itself does not assume anything about number precision. JavaScript, as well as QJsonValue, do assume that any number is a double precision, but nothing in RFC 4627 says that. libjson (at least) assumes that number values in JSON can be signed int64. This specific issue may be better handled in QJsonValue than in a QConfig class. Regards, Julien Blanc ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Calculating JIRA bug priorities
Hi, While doing some bug triaging yesterday I noticed that we don't have a common process to assess the priority of a bug. That is, JIRA lists some criteria, and I think there's a common understanding what P0, P1 means ... but when it comes to the difference between P2, P3, P4, and P5 it gets IMO really blurry. So here is my little attempt to formalize the assessment bit, and come up with a somewhat reproducible bug priority based on severity, visibility, whether it's a regression, and whether there's a workaround: http://qt-project.org/wiki/JIRA-Priorities Do you think that's helpful, and does this match the results your intuition? If we can reach some consensus it might be worthwhile to integrate into http://qt-project.org/wiki/Triaging_Bugs . Regards Kai PS: Obviously, the result of any such scheme should be considered not more than a hint. There are lots of additional factors that might play a role. It also applies mostly to bugs in the Qt source code itself, e.g. documentation bugs, packaging bugs, ... might have different factors to check for. Kai Köhne, Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: kai.koe...@theqtcompany.com | Mobile: + 49 151 55155601 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Kurt Pattyn pattyn.k...@gmail.com wrote: On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote: Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. On second thought, I think this is a very bad example. Even while you keep binary compatibility, you break semantics here. This is typically a case where one should break binary compatibility. Are you seriously asking for a new major Qt release just because a new implementation of some function does not require some parameter anymore? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
From: development-bounces+martin.smith=theqtcompany@qt-project.org development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Poenitz Andre andre.poen...@theqtcompany.com Sent: Wednesday, October 15, 2014 9:48 AM To: Kurt Pattyn; Bo Thorsen Cc: development@qt-project.org Subject: Re: [Development] Compiler warnings Kurt Pattyn pattyn.k...@gmail.com wrote: On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote: Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. On second thought, I think this is a very bad example. Even while you keep binary compatibility, you break semantics here. This is typically a case where one should break binary compatibility. Are you seriously asking for a new major Qt release just because a new implementation of some function does not require some parameter anymore? But maintaining binary compatibility is now a necessary facet of software engineering, so maybe it is time for the C++ standard to support it. A keyword could be added to the parameter declaration, compatibility or placeholder for example, could precede a parameter declaration that is kept for binary compatibility. The compiler would not warn that the parameter was not used. martin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QConfig update.
Milian Wolff schreef op 14-10-2014 18:35:
QConfig and QConfigGroup *does not* support setting a default value on the
getter, I know that this is used in a lot of places but this can cause
inconsistencies:
Main.cpp
QConfig c;
c.value(window-width, 800);
MainWindow.cpp
c.value(window-width, 1200);
so we must create a better way for that. for now, I simply removed the
possibility for that, we can only do
c.value(window-width);
And how do you check whether window-width was read or not? What do you return
on error? A default-constructed value? What type does the value have for that
matter?
Imo, this makes this API extremely inconvenient. Yes it's possible to do an
error, but that is life. You should only add such error-prevention stuff into
the high-level schema stuff, not into QConfig itself.
Without the ability to provide a default value, one can never figure out
whether `c.value(some-int) == 0` means the value could not be read and a
default should be used, or whether the value is 0.
Indeed. I think default values are vital, even if the issue you (Tomaz)
point out is valid like I argued yesterday. That is why we only use
QSettings anymore from within our own type-safe settings class.
I plan to set the defaults via a schema-based file ( could be the KConfigXt
based, but I dislike having to edit XML by hand, so something more similar
to QML would be best ).
Any tougths on that?
If you store JSON, maybe use JSON? The mapping will give you the default value
and from there you get a type.
{
foo : 1,
bar : { lala: string }
}
XML hand-editing is of course not needed. If XML would be used (like it
is for .ui files and .rcc files in Qt), an editor for this type can be
added to Creator. That would get rid of the need to hand-edit XML files.
JSON could also work of course. Perhaps it is important however to first
have a clear goal on use cases the schema has to solve, before going
into a file format for it. To me, some requirements would be:
1) Easy generation of type-save settings class
2) Management of default values
3) Capable of handling custom types, including enums
4) Makes it easy to avoid writing boilerplate getters and setters, but
possible to do so if needed
5) Also generates changed signals
Furthermore, I'd like to have the ability to have more than one of
these. That is: we are in a large project with several libraries. These
libraries need to access part of the settings. The overall application
needs to access the whole settings structure of course (for instance for
showing a settings dialog), preferably in some nice unified way.
I think settings resemble properties to a very large extend. Perhaps it
would, as an alternative to the XML or JSON schemes already suggested,
but possible to build on the Qt property system instead for this. It is
familiar to developers, does not require a special editor, and allows
for using your own code instead of generated boilerplate quite naturally
(point 4 above). Perhaps something like:
class AppSettings: public QTypedConfig
{
Q_SETTINGS(); // Q_OBJECT, but perhaps with some extra's like the
ability to include generated function declarations for getters and setters
Q_SETTING(int width SETTING dialog/window-width DEFAULT 800);
//use generated getter, setter and notify
Q_SETTING(MyCustomType myValue READ myValue WRITE setMyValue NOTIFY
myValueChanged); //use custom getter and setter
public:
AppSettings(QObject* parent = 0);
MyCustomType myValue() const;
void setMyValue(const MyCustomType value);
Q_SIGNAL void myValueChanged(const MyCustomValue value);
}
André
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 Beta snapshot available
On Tuesday 14 October 2014 14:28:05 Thiago Macieira wrote: The changes are ready, just pending approval: https://codereview.qt-project.org/95531 https://codereview.qt-project.org/95532 https://codereview.qt-project.org/95533 https://codereview.qt-project.org/96073 The important ones are the second and third ones. The fourth one is an optimisation that can be added at any time. The important patches have +1, so I can do maintainer-approval of them. I just need a confirmation that if I stage them now, they will still be in the beta. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On Wed, 15 Oct 2014, Smith Martin wrote: But maintaining binary compatibility is now a necessary facet of software engineering, so maybe it is time for the C++ standard to support it. A keyword could be added to the parameter declaration, compatibility or placeholder for example, could precede a parameter declaration that is kept for binary compatibility. The compiler would not warn that the parameter was not used. ... and emit an error if it is :) Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 Beta snapshot available
-Original Message- From: development-bounces+kai.koehne=theqtcompany.com@qt- [...] I just need a confirmation that if I stage them now, they will still be in the beta. That'll delay the beta at least till next week, and potentially even longer (given our problems of getting both qtbase and qt5 git to integrate ...). The beta is already much delayed, I don't like to see it being delayed further for an unknown time. I'm with Simon Lars on this one: This sounds like something you can integrate also after the beta. Alternatively you might also decide to pull QVersionInfo out of Qt 5.4, and keep it for Qt 5.5. My 2 cents Kai -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calculating JIRA bug priorities
Good idea. :) I like the idea of using 3 as the base, as that's a good fallback when it's not really obvious. You might want to explain that a lower number equals a higher priority, though. At least in my mind (even knowing that lower is higher in this case), adding 1 to a priority is synonymous with increasing the priority. On 15/10/14 09:43, Koehne Kai wrote: Hi, While doing some bug triaging yesterday I noticed that we don't have a common process to assess the priority of a bug. That is, JIRA lists some criteria, and I think there's a common understanding what P0, P1 means ... but when it comes to the difference between P2, P3, P4, and P5 it gets IMO really blurry. So here is my little attempt to formalize the assessment bit, and come up with a somewhat reproducible bug priority based on severity, visibility, whether it's a regression, and whether there's a workaround: http://qt-project.org/wiki/JIRA-Priorities Do you think that's helpful, and does this match the results your intuition? If we can reach some consensus it might be worthwhile to integrate into http://qt-project.org/wiki/Triaging_Bugs . Regards Kai PS: Obviously, the result of any such scheme should be considered not more than a hint. There are lots of additional factors that might play a role. It also applies mostly to bugs in the Qt source code itself, e.g. documentation bugs, packaging bugs, ... might have different factors to check for. Kai Köhne, Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: kai.koe...@theqtcompany.com | Mobile: + 49 151 55155601 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calculating JIRA bug priorities
On 15-Oct-14 09:43, Koehne Kai wrote: Do you think that's helpful, and does this match the results your intuition? If we can reach some consensus it might be worthwhile to integrate into http://qt-project.org/wiki/Triaging_Bugs . I just want to point out that there already is this nice explanation of priorities: https://bugreports.qt-project.org/secure/ShowConstantsHelp.jspa?#PriorityLevels Your calculation approach depends a bit less on intuition and might be helpful to some. For others might applied common sense be sufficient. ;) Also, bug priorities can change over time due to changed customer requirements and whatnot (those unknowns in your algo that add numbers). IMO it's not worth it to invent a process to calculate such things. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On 15 Oct 2014, at 09:48, Poenitz Andre andre.poen...@theqtcompany.com wrote: Kurt Pattyn pattyn.k...@gmail.com wrote: On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote: Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. On second thought, I think this is a very bad example. Even while you keep binary compatibility, you break semantics here. This is typically a case where one should break binary compatibility. Are you seriously asking for a new major Qt release just because a new implementation of some function does not require some parameter anymore? Yes, if the semantics of the method changes. I can hardly imagine that obsoleting a parameter from a method does not have any behavioural impact in the calling application. This even holds for the case when the signature of the method does not change at all, but the semantics do. I remember once having replaced strict floating point compares with qFuzzyCompares. Although this was internal to Qt this change was - correctly - rejected. Cheers, Kurt Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Oh, come on. It's just one example of one bad rule. And even if you don't accept my example for it, I can just give you another. I have a base class that declares an interface for subclasses. One method requires that the subclass looks at one of the input files and determines the date. To do this, the method declaration has three different arguments, and each of the subclass will use anything from one to three of those. When a subclass doesn't use one of the arguments, it breaks the rule. Obviously a rule written by C programmers that thought they could just apply their knowledge to C++. I will stand by my initial statement: MISRA is irrelevant for a framework. Whether you might use it in your application is up to you. But even here, I can see you break this example. I won't respond again to this thread, it's already too far off topic. Bo. Den 15-10-2014 kl. 10:52 skrev Kurt Pattyn: On 15 Oct 2014, at 09:48, Poenitz Andre andre.poen...@theqtcompany.com wrote: Kurt Pattyn pattyn.k...@gmail.com wrote: On 14 Oct 2014, at 10:21, Bo Thorsen b...@vikingsoft.eu wrote: Den 14-10-2014 08:59, Kurt Pattyn skrev: how do these applications comply with MISRA? MISRA is impossible to comply with for a framework. For example, consider the required rule 0-1-11: There shall be no unused parameters (named or unnamed) in non-virtual functions. With this, void f(int /*no_longer_used*/) is illegal. For any non-trivial framework that keeps binary compatibility, this will over time be hit. On second thought, I think this is a very bad example. Even while you keep binary compatibility, you break semantics here. This is typically a case where one should break binary compatibility. Are you seriously asking for a new major Qt release just because a new implementation of some function does not require some parameter anymore? Yes, if the semantics of the method changes. I can hardly imagine that obsoleting a parameter from a method does not have any behavioural impact in the calling application. This even holds for the case when the signature of the method does not change at all, but the semantics do. I remember once having replaced strict floating point compares with qFuzzyCompares. Although this was internal to Qt this change was - correctly - rejected. Cheers, Kurt Andre' Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Calculating JIRA bug priorities
-Original Message- [...] I just want to point out that there already is this nice explanation of priorities: https://bugreports.qt- project.org/secure/ShowConstantsHelp.jspa?#PriorityLevels Well, my issue with this is that it has only some 'hard' hints for P0, P1. It doesn't actually say much about P2, P3, P4, P5. In practice we tend to but a _lot_ of stuff in the P2 bucket, and don't use P3, P4, P5 that much. Some stats to back this up: Here's the numbers of unresolved Qt bugs that affects any Qt 5.3, 5.4 JIRA versions, split by priority: P0: 3 P1: 139 P2: 847 P3: 428 P4: 90 P5: 7 So, we've more bugs in P2 than in all the other buckets combined! Ideally we should spread this out somewhat more, to have a better visibility of things that are important, and things that aren't _that_ important ;) Your calculation approach depends a bit less on intuition and might be helpful to some. For others might applied common sense be sufficient. ;) Also, bug priorities can change over time due to changed customer requirements and whatnot (those unknowns in your algo that add numbers). IMO it's not worth it to invent a process to calculate such things. Fair enough, nobody is of course forced to use this ;) I'm personally always a bit confused what is a P3, P4, P5, that's why I started this. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 Integration
Hi Simo, On Friday, October 03, 2014 05:32:12 AM Fält Simo wrote: Hi, It is time to bring the old topic to table: http://lists.qt-project.org/pipermail/development/2014-February/015426.html Some of you might have noticed that during the last couple of nights there was an e-mail with [Qt CI Nightly] title sent to the ci-repo...@qt-project.org mailing list. That was a status e-mail from CI pointing to Qt5 nightly build logs and test results. Same data can be found from QtMetrics also. Now that the push notification is working, we will proceed with the original plan described by Frederik in his e-mail linked above, to disable auto tests from Qt5 integration. After that it will be build test only and possible test regression is found nightly. Please also do notice that, nightly build has no 'forcesuccess' nor 'qt.test.insignificant' properties, so the result is actually worse than what you see from integration builds, where some of the tests are forced to succeed or marked as insignificant. I think this is a great and important step to speeding up qt5.git integration and will speed up releases (the current beta of 5.4 is a good example of where this will help). One think still missing is visibility - can we get a bot ping on #qt-labs for example whenever the results are there? I had a look at the results yesterday and saw quite a few platforms not passing as expected, but only people subscribed to the ci-reports mailing list will see this information. So in summary, we need more noise about this. If someone feels like writing a simple web site that parses the results that would also be great, interpreting them should not be that hard and many scripts can be re-used. Let me know if you're interested in helping out there. I want to work on this myself but won't find time any time soon. Cheers, Frederik Br, Simo Fält The Qt Company Email: simo.f...@theqtcompany.com | Mobile: + 358 40 740 6136 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject Facebook: www.facebook.com/qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QConfig update.
On Tue, Oct 14, 2014 at 07:06:30PM +0200, Milian Wolff wrote: On Tuesday 14 October 2014 13:44:30 Tomaz Canabrava wrote: On Tue, Oct 14, 2014 at 1:35 PM, Milian Wolff milian.wo...@kdab.com wrote: On Tuesday 14 October 2014 13:22:51 Tomaz Canabrava wrote: it has a QConfigGroup 'global' value that can be acced directly via .setValue and .value Why the global state? A QConfig should be valid for a single file and constructed on-demand. If you want to share stuff and keep it open, adding something like a KSharedConfig might be a good idea. But again, that is something that could/should be built on-top of QConfig (imo). so I don't need to open a config file and parse it every time the user created a QConfig object. Then provide a QSharedConfig or let the user store the QConfig himself, if it turns out to be a performance-bottleneck for him. as i previously pointed out, this is one of the things i consider *bad* about kconfig. i wouldn't necessarily make a real cache, but the objects should be automatically shared in the background. that's what happens when you natively use the windows registry anyway. If you add global state to QConfig, you'll need synchronization or otherwise you are doomed in a multithreaded application. yes. so what? Furthermore: If you keep the QConfig in memory all the time, you'll probably end up duplicating the stuff as soon as you add the fancy high-level interface on-top. QConfig will operate on JSON after all and you'll incur a conversion penalty whenever you read a value from it. The high-level interface should (hopefully) read the values once and store it internally in the proper type. you are right with that (that's why i don't think using the json classes as anything else than backend storage and having an abstraction layer on top makes sense), but i don't see how that correlates with the config objects being shared+cached. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Disabling -Bsymbolic when using wayland-scanner
On Tuesday 14 October 2014 22:52:45 Dmitry Cherkassov wrote: Closer look revealed that you remove bsymbolic_functions from building: CONFIG -= bsymbolic_functions Didn't you intend to remove bsymbolic and add bsymbolic_functions to CONFIG instead: CONFIG -= bsymbolic CONFIG += bsymbolic_functions There's no bsymbolic.prf file. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
On Wednesday 15 October 2014 09:26:34 Kurt Pattyn wrote: I am talking about missing default switch statements, incomplete switch statements, implicit conversion between signed and unsigned integers, aso. default labels in switches may be intentionally missing. When the swtch handles all possible values, it's unnecessary to add a default. Especially when the switch handles all possible values of an enum, you don't want a default label so you'll get a warning later when a new enum value may be added. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 Beta snapshot available
On Tuesday 14 October 2014 20:41:22 Knoll Lars wrote: In my opinion those changes - as big as they may seem - could go in after the beat. Yes, they change the implementation a lot, but they barely affect the API. The beta is about being able to try out new features in Qt and getting feedback about for example regressions. IMO that's not in conflict with your changes. I'm agreeing with Simon Thanks for agreeing, but the point of the beta is to test the implementation, especially of new classes. I find it really weird if we told people *not* to test the current implementation because it's already obsolete by the time the beta is released. Usually, if we found in the beta feedback that a major new feature requires a large refactoring, we'd either pull the feature back or we'd release a new beta so it could be tested. Relatively speaking, this is a major refactor of QVersionNumber. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QConfig update.
On Tuesday 14 October 2014 13:44:30 Tomaz Canabrava wrote: so I don't need to open a config file and parse it every time the user created a QConfig object. I quite frankly don't see this as a problem. I think this syntax of using QSettings is just plain weird: QSettings settings; if (settings.contains(foo)) doSomething(); Applications should just keep a global singleton of theirs for their config. Clearly, QConfigGroup would need to be thread-safe. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 Beta snapshot available
On Wed, Oct 15, 2014 at 11:36:40AM +0200, Thiago Macieira wrote: Relatively speaking, this is a major refactor of QVersionNumber. yes, but absolutely speaking, it is trivial (because the whole class is almost trivial, and thus such excellent material for bikeshedding :D). so get on with it already and ignore the beta release process. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [QtIFW] CPack IFW Generator
Hello dear developers! The first time I write to this list :-) Our history is being made and created technology! It is no secret that the projects CMake and Qt long friends. Soon they would be friends even better. The next version of CMake will contain the new CPack IFW generator. http://ifw.podsvirov.pro/cmake/doc/sphinx/release/3.1.0.html#cpack This has contributed Yours truly (that's me). CPack IFW generator generates installers using QtIFW. You can try this using the latest version for developers. http://www.cmake.org/files/dev Or wait CMake version 3.1.0-rc1. Why do I write here? I need help! I want information about this technology appeared in the documentation for Qt, Qt Creator, and perhaps in Qt Installer Framework. For example here: http://qt-project.org/doc/qt-5/cmake-manual.html and here: https://qt-project.org/doc/qtcreator-3.2/creator-project-cmake.html and here: http://qt-project.org/doc/qtinstallerframework-1.5/index.html If You have any questions, ask them here or email me personally. Hope to communicate with the people responsible for creating documentation. (Sorry for my poor English) Regards, Konstantin Podsvirov ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 Beta snapshot available
On Wednesday 15 October 2014 11:43:46 Oswald Buddenhagen wrote: On Wed, Oct 15, 2014 at 11:36:40AM +0200, Thiago Macieira wrote: Relatively speaking, this is a major refactor of QVersionNumber. yes, but absolutely speaking, it is trivial (because the whole class is almost trivial, and thus such excellent material for bikeshedding :D). so get on with it already and ignore the beta release process. Marc has just pushed a large refactoring on top of my refactoring. To avoid further delaying of the final release, I'm going to pull QVersionNumber from 5.4. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QConfig update.
On Wednesday 15 October 2014 10:02:59 André Somers wrote:
snip
I think settings resemble properties to a very large extend. Perhaps it
would, as an alternative to the XML or JSON schemes already suggested,
but possible to build on the Qt property system instead for this. It is
familiar to developers, does not require a special editor, and allows
for using your own code instead of generated boilerplate quite naturally
(point 4 above). Perhaps something like:
class AppSettings: public QTypedConfig
{
Q_SETTINGS(); // Q_OBJECT, but perhaps with some extra's like the
ability to include generated function declarations for getters and setters
Q_SETTING(int width SETTING dialog/window-width DEFAULT 800);
//use generated getter, setter and notify
Q_SETTING(MyCustomType myValue READ myValue WRITE setMyValue NOTIFY
myValueChanged); //use custom getter and setter
public:
AppSettings(QObject* parent = 0);
MyCustomType myValue() const;
void setMyValue(const MyCustomType value);
Q_SIGNAL void myValueChanged(const MyCustomValue value);
}
I like the idea!
Bye
--
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbHCo KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QConfig update.
On Wed, Oct 15, 2014 at 10:02:59AM +0200, André Somers wrote: snip XML hand-editing is of course not needed. If XML would be used (like it is for .ui files and .rcc files in Qt), an editor for this type can be added to Creator. That would get rid of the need to hand-edit XML files. No! Not everyone uses Creator or whatever tool. I strongly dislike the idea of having to depend on a specific toolset. What is productive to some can be counter-productive to others. We need to KISS and use a human-readable format that offers the possibility to be manually edited if desired. And for that XML is a huge PITA IMHO. Please, please don't go down that road. -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QConfig update.
On Wed, Oct 15, 2014 at 12:22:32PM +0200, Milian Wolff wrote:
On Wednesday 15 October 2014 10:02:59 André Somers wrote:
snip
I think settings resemble properties to a very large extend. Perhaps it
would, as an alternative to the XML or JSON schemes already suggested,
but possible to build on the Qt property system instead for this. It is
familiar to developers, does not require a special editor, and allows
for using your own code instead of generated boilerplate quite naturally
(point 4 above). Perhaps something like:
class AppSettings: public QTypedConfig
{
Q_SETTINGS(); // Q_OBJECT, but perhaps with some extra's like the
ability to include generated function declarations for getters and setters
Q_SETTING(int width SETTING dialog/window-width DEFAULT 800);
//use generated getter, setter and notify
Q_SETTING(MyCustomType myValue READ myValue WRITE setMyValue NOTIFY
myValueChanged); //use custom getter and setter
public:
AppSettings(QObject* parent = 0);
MyCustomType myValue() const;
void setMyValue(const MyCustomType value);
Q_SIGNAL void myValueChanged(const MyCustomValue value);
}
I like the idea!
+1
--
Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - Qt Experts - Platform-independent software solutions
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.4.0 Beta snapshot available
Hi, To avoid further delaying of the final release, I'm going to pull QVersionNumber from 5.4. careful: it is already used in: qtactiveqt/examples/activeqt/webbrowser/main.cpp Regards, Friedemann -- Friedemann Kleint Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: friedemann.kle...@theqtcompany.com | www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtIFW] CPack IFW Generator
-Original Message- From: development-bounces+kai.koehne=theqtcompany.com@qt- Subject: [Development] [QtIFW] CPack IFW Generator Hello dear developers! [..] CPack IFW generator generates installers using QtIFW. You can try this using the latest version for developers. http://www.cmake.org/files/dev Or wait CMake version 3.1.0-rc1. Very nice :) [...] If You have any questions, ask them here or email me personally. It would be certainly nice to link to this feature from the Qt Installer Framework documentation. For Qt Creator / Qt documentation, it's not clear to me in which depth this should be documented, since the functionality is not really specific to developers using Qt: People might as well use one of the other backends available in cpack, right? To rephrase: Are there strong reasons apps using Qt + cmake should prefer the new ifw backend, compared to the other backends available? Also, what's the time frame for CMake version 3.1.0 ? I don't want to add links to a yet unreleased feature ... Regards Kai Koehne Hope to communicate with the people responsible for creating documentation. (Sorry for my poor English) Regards, Konstantin Podsvirov ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QConfig update.
On Wed, Oct 15, 2014 at 02:36:51PM +0200, Thiago Macieira wrote: On Wednesday 15 October 2014 08:39:27 Rafael Roquetto wrote: No! Not everyone uses Creator or whatever tool. I strongly dislike the idea of having to depend on a specific toolset. What is productive to some can be counter-productive to others. We need to KISS and use a human-readable format that offers the possibility to be manually edited if desired. And for that XML is a huge PITA IMHO. Please, please don't go down that road. The only issue is that the more human-editable the source form is, the harder it is to write a parser and toolchain to configure. Of course, we need to find a compromise in between. In other words, KISS but no simpler. I am not suggesting something based on natural language, actually, I am just arguing against an approach which enforces the usage of an specific tool/editor as an alternative for a better designed textual format. Specially when it comes to settings or schemas. The suggested QTypedSettings class is an example of a human-editable source form which is easy to read (*arguably* easier than condensed XML *IMHO*) being at the same time tool agnostic (any editor will do) and parser/compiler friendly. -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QConfig update.
On Wednesday 15 October 2014 10:09:47 Rafael Roquetto wrote: On Wed, Oct 15, 2014 at 02:36:51PM +0200, Thiago Macieira wrote: On Wednesday 15 October 2014 08:39:27 Rafael Roquetto wrote: No! Not everyone uses Creator or whatever tool. I strongly dislike the idea of having to depend on a specific toolset. What is productive to some can be counter-productive to others. We need to KISS and use a human-readable format that offers the possibility to be manually edited if desired. And for that XML is a huge PITA IMHO. Please, please don't go down that road. The only issue is that the more human-editable the source form is, the harder it is to write a parser and toolchain to configure. Of course, we need to find a compromise in between. In other words, KISS but no simpler. I am not suggesting something based on natural language, actually, I am just arguing against an approach which enforces the usage of an specific tool/editor as an alternative for a better designed textual format. Specially when it comes to settings or schemas. The suggested QTypedSettings class is an example of a human-editable source form which is easy to read (*arguably* easier than condensed XML *IMHO*) being at the same time tool agnostic (any editor will do) and parser/compiler friendly. I'm not sure you got my meaning. How is a config editor tool in Qt Creator going to read write those files? How is the code generator going to read the QTypedSettings source header to genete the equivalent .cpp? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [QtIFW] CPack IFW Generator
Hello dear developers! Yesterday I wrote a letter with the title [QtIFW] CPack IFW Generator and was told by two people. (http://lists.qt-project.org/pipermail/development/2014-October/018800.html) 15.10.2014, 13:47, Konstantin Podsvirov konstan...@podsvirov.pro: The next version of CMake will contain the new CPack IFW generator. CPack IFW generator generates installers using QtIFW. You can try this using the latest version for developers. http://www.cmake.org/files/dev I want information about this technology appeared in the documentation for Qt, Qt Creator, and perhaps in Qt Installer Framework. 15.10.2014, 16:33, Miettinen Riitta-Leena riitta-leena.mietti...@theqtcompany.com: I'm responsible for writing documentation for the Qt tools (including Qt Creator and Qt Installer Framework) and can help you write documentation for the CPack IFW generator. Thank you! This is what I need. I have a Gerrit account (user: kot). But I haven't contributed in Qt code. What sequence of actions? What instruction I to read? I can also create a patch with boilerplate topics or sections where you can add the information. For planning purposes, do you have information about the generator somewhere that I could look at? A working version of CMake is not accompanied by a public documentation, but on my server I put and periodically update the version for developers. Here is the link: http://ifw.podsvirov.pro/cmake/doc/sphinx Information on IFW generator here: http://ifw.podsvirov.pro/cmake/doc/sphinx/module/CPackIFW.html (there is a small example of use in the creation of the installer) Working with IFW generator in CMake is no different from working with other generators. On cmake.org/Wiki there is a good example about creating installers on the basis of the components is that the IFW generator does best: http://www.cmake.org/Wiki/CMake:Component_Install_With_CPack The example is complete, but slightly outdated. Not all variable must be set separately. Can to use a more convenient macros. 15.10.2014, 16:48, Koehne Kai kai.koe...@theqtcompany.com: Very nice :) It would certainly be nice to link to this feature from the Qt Installer Framework documentation. For Qt Creator / Qt documentation, it's not clear to me in which depth this should be documented, since the functionality is not really specific to developers using Qt: People might as well use one of the other backends available in cpack, right? All right. CPack contains a dozen generators. Each has its own specifics. But IFW generator allows you to create graphical installer, which looks the same for all major desktop! Supports online and offline modes and the ability to upgrade components! To rephrase: Are there strong reasons apps using Qt + cmake should prefer the new ifw backend, compared to the other backends available? For platforms that have built the package managers prefer to use it. But in the General case, the question of the deployment of the application is always up to date. I think people who use Qt I want the installers as Qt :-) But to create them is not so simple. The deployment of the applications described here: http://qt-project.org/doc/qt-5/deployment.html And specific to each platform. There QTDIR/bin/xxxdeployqt applications which create the correct folder... it's not so easy as expected. I created IFW generator driven by the documentation: http://qt-project.org/doc/qtinstallerframework-1.5/index.html There are all clearly, but to do all this by hand is very tedious. My solution is a generator. CMake provides a General model of application development, where all States: applications, libraries, plugins and different files. Clearly set out what and where to install. One has only to add a generator that does what is described in the documentation QtIFW and get ready installer :-) But the idea to deploy Qt applications: If you create for each platform online repository with distributed components from Qt (without headers, file linking, and debugging), you can create installers that contain only user-developed modules and refer to Qt components. In other words create an environment to distribute applications. Also, what's the time frame for CMake version 3.1.0 ? I don't want to add links to a yet unreleased feature ... I contacted the developer CMake, but still have not received a reply. I think that the output of CMake version 3.1 will not require much time... (Sorry for my poor English) Best regards, Konstantin Podsvirov ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
