Re: [Development] Qt 5.2 RC1 candidate packages available
Simon Lees [simon.l...@codanradio.com] > The version of QtCreator shipped with the package crashes my x everytime > i attempt to launch it. It was the Android Linux x86_64 package running > on openSUSE 12.3 with Enlightenment as the window manager and the > proprietary NVIDIA Driver Could you try to add the '-noload Welcome' command line option when starting Qt Creator and see whether this still crashed immediately? (The option prevents loading of the Qt Quick 2 based Welcome screen, session management would still be available under Files->Sessions/ Files->Session Manager) Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Coding style proposal
Jiergir Ogoerg wrote: > Ironically, not even the IDE (QtCreator) sorts them out, in my example > parse...() is the 1st in the list, and locale() is the last one (16th). There's a "Sort alphabetically" check box in the context menu of whatever-that-combobox-that-I-never-use-for-navigation-is-called. Maybe using that helps to ease your pain. The main point here is that there's no "intrinsic" ordering of function implementation, and "alphabetically sorting" is as arbitrary as anything else. The preferred way to locate a method in Qt Creator is to use the Locator facility, i.e. press Ctrl-K to open the Locator, further 'm', to select functions: (independently of the file), or '.', for C++ symbols in the current file. There's no need to guess where a function definition is, or rely on coding standards, when you can jump there directly. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Coding style proposal
André Somers wrote: > Poenitz Andre schreef op 2-1-2014 23:49: > > Jiergir Ogoerg wrote: > >> Ironically, not even the IDE (QtCreator) sorts them out, in my example > >> parse...() is the 1st in the list, and locale() is the last one (16th). > > There's a "Sort alphabetically" check box in the context menu of > > whatever-that-combobox-that-I-never-use-for-navigation-is-called. > > Well, that's a find! I wonder why it is not enabled by default? Probably because the current code follows the rule of "Don't switch on a fancy option by default unless it's clearly better than the alternative", and I even tend to agree that the rule applies here, and the current default is good. But since I don't use the combobox at all, that's not a strong opinion. If people who actually use the combobox agree that alphabetical order should take precedence over the order in which the functions are defined, the default can be changed. A patch is now on Gerrit (#74614) and awaits comments. Regards, André > Thanks for pointing out this little hidden feature! It will certainly ease my > navigation. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Let's get rid of qDebug/qWarning/qCritical!
Koehne Kai wrote:
> On quinta-feira, 9 de janeiro de 2014 07:28:07, Koehne Kai wrote:
> > if qCWarning() would expand to an if (myCategory().isEnabled()) ...
>
> That's why it would have to expand to if (!myCategory().isEnabled()) {} else
>
> Well, we can't, since the << arguments are not part of the macro :) That
> would end up with s.th. lie
>
> if (!myCategory().isEnabled()) { QMessageLogger(__FILE__, __LINE__,
> __FUNCTION__).debug() {} else {} << "Hello World";
>
> which doesn't compile.
This is only a problem because you insist on creating partial statements
with the macro instead of full statements.
If the "streaming syntax" would be
qFoo(myCategory(), a << b << c);
instead of
qFoo(myCategory()) << a << b << c;
there's no "else" to worry about, and it would also solve the problem of
a "compile time" "null stream":
#define qFoo(stream, stuff) /*nothing*/
We had this discussion before.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Let's get rid of qDebug/qWarning/qCritical!
Koehne Kai wrote:
> > -Original Message-
> > From: development-bounces+kai.koehne=digia@qt-project.org
> > [...]
> > As a blueprint I've started a patch for a 'qt.core.io' category:
> >
> > https://codereview.qt-project.org/#change,74862,patchset=1
>
> Andre raised concerns about the (runtime/space) overhead of the
> QDebug streaming style, compared to the printf style.
> Here are some conclusions (gcc 4.8, release build, CONFIG+=c++11) ...
>
> RUNTIME OVERHEAD
>
> I did a quick benchmark where I did following variants in a
> QBENCHMARK (category was enabled, to output was generated
> to a file. I had to patch qtestlib to not intercept the qWarning output...):
>
> void CatLogBench::qWarningPrintf1() { QBENCHMARK { qWarning("Hi there"); } }
> void CatLogBench::qWarningPrintf2() { QBENCHMARK { qWarning("%s", "Hi
> there"); } }
> void CatLogBench::qWarningStream() { QBENCHMARK { qWarning() << "Hi there"; }
> }
> void CatLogBench::qCWarningStream() { QBENCHMARK { qCWarning(cat) << "Hi
> there"; } }
> void CatLogBench::qCWarningPrintf() { QBENCHMARK { qCWarning(cat, "Hi
> there"); } }
>
> (the last one is a new variant enabled by
> https://codereview.qt-project.org/#change,75029 .)
>
> And here are the results:
>
> PASS : CatLogBench::qWarningPrintf1()
> RESULT : CatLogBench::qWarningPrintf1():
> 0.0010 msecs per iteration (total: 67, iterations: 65536)
> PASS : CatLogBench::qWarningPrintf2()
> RESULT : CatLogBench::qWarningPrintf2():
> 0.0013 msecs per iteration (total: 90, iterations: 65536)
> PASS : CatLogBench::qWarningStream()
> RESULT : CatLogBench::qWarningStream():
> 0.0016 msecs per iteration (total: 54, iterations: 32768)
> PASS : CatLogBench::qCWarningStream()
> RESULT : CatLogBench::qCWarningStream():
> 0.0018 msecs per iteration (total: 59, iterations: 32768)
> PASS : CatLogBench::qCWarningPrintf()
> RESULT : CatLogBench::qCWarningPrintf():
> 0.0010 msecs per iteration (total: 69, iterations: 65536)
> PASS : CatLogBench::cleanupTestCase()
> Totals: 7 passed, 0 failed, 0 skipped
>
> So, there is of course some measurable overhead, but I wouldn't say it
> disqualifies the streaming variant per se :)
BINARY SIZE
On to the binary size. I removed the QBENCHMARK macro and disassembled the gcc
output. Here it shows that QDebug is completely inlined, the streaming operator
variants do indeed generate a hell lot of instructions ! But since this is
quite a bogus metric here are the size increase of Qt5Core with, and without
the core.io patch included (again a release non-developer build with gcc 4.8.2):
-rwxr-xr-x 1 kkoehne users 5311213 Jan 10 12:55 libQt5Core.so.5.3.0.original
-rwxr-xr-x 1 kkoehne users 5357104 Jan 10 12:58 libQt5Core.so.5.3.0_patch
So the overhead is measurable.
Given these concerns, I'd like to propose adding a printf style overload to
qCDebug:
https://codereview.qt-project.org/#change,75029
Note the patch is fairly ugly because we're gracefully handling the case where
the toolchain doesn't respect Q_COMPILER_VARIADIC_MACROS, I'll post a second
mail about this soon ...
Regards
Kai
___
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] Let's get rid of qDebug/qWarning/qCritical!
Grr... OWA. > And here are the results: > > PASS : CatLogBench::qWarningPrintf1() > RESULT : CatLogBench::qWarningPrintf1(): > 0.0010 msecs per iteration (total: 67, iterations: 65536) > PASS : CatLogBench::qWarningPrintf2() > RESULT : CatLogBench::qWarningPrintf2(): > 0.0013 msecs per iteration (total: 90, iterations: 65536) > PASS : CatLogBench::qWarningStream() > RESULT : CatLogBench::qWarningStream(): > 0.0016 msecs per iteration (total: 54, iterations: 32768) > PASS : CatLogBench::qCWarningStream() > RESULT : CatLogBench::qCWarningStream(): > 0.0018 msecs per iteration (total: 59, iterations: 32768) > PASS : CatLogBench::qCWarningPrintf() > RESULT : CatLogBench::qCWarningPrintf(): > 0.0010 msecs per iteration (total: 69, iterations: 65536) > PASS : CatLogBench::cleanupTestCase() > Totals: 7 passed, 0 failed, 0 skipped > > So, there is of course some measurable overhead, but I wouldn't > say it disqualifies the streaming variant per se :) This indicates an overhead of 30%, or 80%. In core functionality. While this does not immediately disqualify the approach, there needs to be some kind of benefit to compensate. So far I am not seeing that. > BINARY SIZE > > On to the binary size. I removed the QBENCHMARK macro > and disassembled the gcc output. Here it shows that QDebug > is completely inlined, the streaming operator variants do indeed > generate a hell lot of instructions ! > > But since this is quite a bogus metric here are the size increase > of Qt5Core with, and without the core.io patch included > (again a release non-developer build with gcc 4.8.2): > > -rwxr-xr-x 1 kkoehne users 5311213 Jan 10 12:55 libQt5Core.so.5.3.0.original > -rwxr-xr-x 1 kkoehne users 5357104 Jan 10 12:58 libQt5Core.so.5.3.0_patch > > So the overhead is measurable. > > Given these concerns, I'd like to propose adding a printf style overload to > qCDebug: > > https://codereview.qt-project.org/#change,75029 > > Note the patch is fairly ugly because we're gracefully handling the c > ase where the toolchain doesn't respect Q_COMPILER_VARIADIC_MACROS, > I'll post a second mail about this soon ... What about post-poning the whoie idea until we can rely on variadic macros? Regards, Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build Hotspots in the Qt build process
Shane McIntosh [mcint...@cs.queensu.ca] wrote:
> Hi Qt developers!
>
> My name is Shane. I’m a PhD student at Queen’s University in Canada.
>
> I’ve been working on an approach for detecting build hotspots, i.e.,
> files that not only take a long time to rebuild, but also change often.
> We think that these files are ideal candidates for refactoring that could
> shave time off of incremental builds that are really impacting software teams.
That sounds like a good idea in general.
Looking at your list at
> http://sailhome.cs.queensu.ca/~shane/content/qt_hotspots.txt
I wonder a bit how e.g. xmlpatterns can be considered a "hotspot"
that according to your definition "changes often". The actual
code has not been changed much for a while except for occasional
merges and the annual bumps in copyright headers.
My gut feeling is that any refactoring there is not worthwhile.
> I’m happy to provide a more detailed Qt dataset when I
> return to my lab next week.
It would be nice to see some reason ("numbers") why files ended
up on the list.
Best regards,
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] qmlx11 plugin
Rutledge Shawn [shawn.rutle...@digia.com] > On 5 Feb 2014, at 11:16 AM, Damian Ivanov wrote: > > I made a c++ QML plugin for X11 functions like windowlist, active > > window, setting, getting icon of apps, names, id and setting netwm > > properties. Source code is here > > https://build.opensuse.org/package/show/home:damianator:qmlx11/qmlx11 > [...] > Personally I wish we had some of that as QPA APIs (at least window list > and window icons), but of course it assumes that we can do the same > thing on the other platforms. I don't see why that "of course" assumes that we can do the same on the other platforms. Having stubs doing nothing/returning something harmless would be easier to handle in such cases for user code than to build special platform dependent packages, integrate with build systems etc. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] On the effectiveness of time based releases
Koehne Kai [kai.koe...@digia.com] > > [...] > > > Before merging a feature the maintainers consider if yes or not the > > > feature is ready for integration. If bad decisions are made, I don't > > > think the "time- based" releases have anything to do with that. > > > > It has to some degree, because it leads to rushing features in before the > > deadline; and then API reviews, blatant bug fixes, writing examples, source > > cleanups, etc. happen in stable after the merge (and not, as I said, before > > even merging into dev). > > The thing is, you can't get out any release of something as big as Qt > without deadlines. And with deadlines comes the rush to get stuff in ... Worse, it creates a bias. When the more responsible people hold back their changes early to not delay the release and others keep shuffling in rushed last minute implementations, the majority of features will be rushed. > [...] Maybe we do indeed take features in too lightly. And maybe we > have to be more strict following up on new features to make sure > that they're really polished & ready at release time. But for all of > this, having a predictable schedule is IMO a necessary prerequisite. Not "maybe", it's certain. It's dead easy to get a feature in, especially in modules that are not as tightly controlled as qtbase. And it's basically impossible to get something out again, due to the "binary compatibility promises". So we keep accumulating semi-broken, politically "unfixable" stuff, making Qt fatter, and stretching out resources thinner and thinner. And this _is_ a pure policy issue, nothing technical here. To stop this trend, there must be a tight reign on feature development in _all_ modules. Having a centralized "joint API sanity master instance" would definitely be a step into the right direction. It sort of used to work at a time... Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qt_add/removeObject hooks
volker.kra...@kdab.com:
> > > So unless there's some compiler magic I missed I think this needs a
> > > different approach to be reliable and cross-platform, such as callbacks.
> > > Would this be acceptable? If so, would a minimal approach similar to
> > > qt_register_signal_spy_callbacks() or rather something using
> > > QInternal::registerCallback() be preferred?
> >
> > We should probably move those functions to a separate .cpp, so the optimiser
> > doesn't kick in. We don't build with LTCG enabled.
>
> I tried to avoid tricks that more or less worked by accident, in order to have
> something that would survive the next compiler update. With explicit compiler
> flags to disable optimization for the separate files this might work though.
I think that creating some setup relying on the optimizer to work (or even
not work) in a specific way is quite fragile.
> > But feel free to make the best API that works for GammaRay and for Squish.
> > You're the only users of such an API. We'll abide by the solutions you come
> > up with.
>
> API-wise we are quite flexible (can't get any more dirty than what we do now
> ;) ), I was mainly asking due to this being on a performance-relevant path.
> The QInternal callback system is obviously more flexible (and thus would be my
> preferred choice), but also slightly more expensive at runtime. The signal spy
> approach would be slightly more light-weight, at the cost of thread-safety.
> So, if from the performance point of view there are no objections to the
> QInternal callback approach, I'll make sure the Squish team is happy with that
> too, and propose a patch accordingly.
>
> Should this include the removal of the old add/removeObject hooks or are they
> considered public API (they are exported)?
Isn't all that is needed just one indirection through a function pointer stored
in
some global variable, i.e roughly something like
// hookstuff.h
#include
extern quintptr qHookStuff[];
// hookstuff.cpp
#include
void qFooHook() { printf("fooo\n"); }
// Only add to the end, and bump version if you do.
quintptr qHookStuff[5] = {
1, // version
sizeof(qHookStuff) / sizeof(qHookStuff[0]), // length
QT_VERSION,
(quintptr)&qFooHook,
42,
};
// "User"
#include
void myFoo() { printf("bar\n"); }
int main()
{
const int fooIndex = 3;
Q_ASSERT(qHookStuff[0] > 0); // minimum version of the extra data we want
Q_ASSERT(qHookStuff[1] > fooIndex); // half-baked sanity check there's a
suitable entry
Q_ASSERT(qHookStuff[2] > 0x30308); // minimum Qt version we want to operate
on
//...
((void(*)())qHookStuff[fooIndex])(); // default implementation
debugStuff[fooIndex] = (quintptr)&myFoo; // overrider it...
((void(*)())debugStuff[fooIndex])(); // custom now.
}
Something like that (specifically something that does not need a function
call to extract data like qVersion() does) would be very helpful for "normal"
debugging, too.
Add/removeObject would just be two slots in the array and can be "replaced"
at runtime, as often as needed. (or keep default as '0' and have the corelib
code check for != 0 before calling the hook)
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Categorized logging inside Qt
shawn.rutle...@digia.com wrote: > On 10 Apr 2014, at 7:20 PM, Frederik Gladhorn wrote: > > > Hi all, > > > > I just started to port accessibility to the new and shiny categorized > > logging. > > http://blog.qt.digia.com/blog/2014/03/11/qt-weekly-1-categorized-logging/ > > > > I'd propose we decide on a certain style of declaring categories. > > > > A quick grep shows that we already have some variety, I'd like to unify this > > before Qt 5.3 is out of the door. I actually saw a patch adding DBG_FOOBAR > > as > > new category, that made me wonder about which style we should use. > I think the pattern is OK though: all uppercase, with a prefix like DBG and > try to keep > them as short as possible since they get repeated all over. We tend to avoid abbreviations, so DBG instead of DEBUG looks odd. Your reasoning that it's REPEATED ALL OVER also MAKES ME THINK that USING ALL CAPS might be NO GOOD IDEA as it gives ME the feeling the code is constantly SHOUTING AT ME. Andre' PS: The time such features are contributed the "style guide" should be part of the original documentation to avoid after-the-fact bike shedding ;-} ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new "debugsupport" module and API)
Kurt Pattyn [pattyn.k...@gmail.com]: > This makes sense. Maybe the WebSockets module can be > integrated into the network module in that case? Is there something Network really needs out of Websockets? Especially for security sensitive areas like network "nice to have" is not a good reason for code inclusion. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] new "debugsupport" module and API
Ulf Hermann: > Is anyone opposed to keeping this in a separate qtdebugsupport.git > repository, then? With what compatibility promises regarding code and protocol? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Gerrit dropping CI failure mails?
Blasche Alexander wrote: > Oswald Buddenhagen wrote: > >i tried to reduce the flood somewhat by denying the bots (including CI) > >the right to mail reviewers, so only the owner now gets the emails. > >on the downside, you now need to pay more attention in case you adopt a > >change from someone else, as you are still a reviewer as far as gerrit > >is concerned ... > > > Please revert this "feature". Why is this important? > > 1. ) I don't have to frequently poll all the changes which I review for their > failures. I use gerrit via email push and not website poll. Why should > I change to back to such less efficient method? > > 2.) I receive a significant number of patches from devs who don't have > approver rights and need some considerable hand-holding. Now they > have to constantly ping me when something fails. This is especially > bad when it was me who was staging it on their behalf. If you have > weired CI errors, license check failures or unintended platform side > effects the amount of handholding goes up signficantly. > > 3.) I monitor progress in my code areas because I review the parts which > are relevant. Subsequently I don't just want to monitor their success. > > I can understand that some code lines are very buggy and require more > attempts (hence more failure "spam"). Then again we should focus > on stabilizing them. > > Also it is dead simple to filter those failures out of your mailbox. > All you have to look for is "FAILURE" and check that "Gerrit-Owner:" > is not you. This way you don't force a behavior change on everybody > else. Right now I am feeling forced. > > Is it just me or how much does everybody else rely on it? It's not just you. I pretty much prefer mails in my inbox in case something happens (or fails) over polling a web interface too. I am also mildly surprised that such a workflow defining feature gets deactivated without any discussion. Andre ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Gerrit dropping CI failure mails?
Oswald Buddenhagen [oswald.buddenha...@digia.com] > > > [...] > > > Is it just me or how much does everybody else rely on it? > > > > It's not just you. I pretty much prefer mails in my inbox in case > > something happens (or fails) over polling a web interface too. > > > > I am also mildly surprised that such a workflow defining feature > > gets deactivated without any discussion. > > > the question is why you find it workflow-defining. why do you in your > role as a _reviewer_ need to track integration progress? the process is > supposed to be contributor-driven. Initiated by the contributor, but the actual process is a shared effort. Especially in cases of repeated unrelated CI failures and reviewers and contributor not sharing the same working hours it helps a lot if they can easily take turns in staging stuff, in time. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
Olivier Goffart wrote:
> Jędrzej Nowacki wrote:
> > 1. Are we allowed to add new conversions?
> > The question is tricky because adding a new conversion is a behavior
> > change, as this code:
> > if (variant.canConvert(QMetaType::int)) ...
> > may work differently. If we add custom types into the mix, everything
> > is even more complex.
>
> I'd say yes, for sensible conversion
> You are right that it is a behaviour change, but i think it is worth changing
> it.
Why?
On one hand you promise binary compatibility. On the other hand
behaviour changes are proposed to be done on an "nice to have"
base?
Do we really think that's ok to disallow changing some int foo() { return
42; } to some int bar() { return 42; } that's easy to discover at build time,
but it's fine to change int foo() { return 42; } to int foo() { return -1; } ?
> so Qt can know it and use it. For certain types we can do much better,
> because we can automatically convert some types. For example:
> QVector -> QLinkedList
QVector v; v.append(130);
QLinkedList l = /*some"Sensible"AutomatedConversion*/(v);
assert(l.first() == 130) ? "Depends" ?
> > A conversion may be arbitrary. For example, most of the conversions
> > to QString. Should "bool(false) -> QString" return "False", "0", "false"?
> > What about precision of, for example, "double -> QString" ?
> We use common sense on a case by case basic.
I tend to believe the common sense in type conversion land is pretty
close to "avoid to do it automatically, prefer to make it explicit".
Already now it's far too easy to make mistakes based on the "nice
and easy" QByteArray -> QVariant -> QString conversions when
accidentally writing QByteArrays into QSettings and reading QStrings
back. There shouldn't be more of that.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
Olivier Goffart wrote:
> > > I'd say yes, for sensible conversion
> > > You are right that it is a behaviour change, but i think it is worth
> > > changing it.
> > Why?
> >
> > On one hand you promise binary compatibility. On the other hand
> > behaviour changes are proposed to be done on an "nice to have"
> > base?
> >
> > Do we really think that's ok to disallow changing some int foo() { return
> > 42; } to some int bar() { return 42; } that's easy to discover at build
> > time, but it's fine to change int foo() { return 42; } to int foo() {
> > return -1; } ?
>
> It's always a dilemma. We have to look at how likely we are to break
> applications and I don't think adding a conversion is likely to cause
> breakages.
Type safety is a safety net that catches errors very early in the
software production and deployment cycle, and one of the features
that makes a programming language usable for the development
of large applications at a reasonable pace.
Implicit type conversions kill type safety. This is widely recognized
as a bad thing. In case of C++ some are "unavoidable" due to the
C legacy, but e.g. for user-defined conversion operators we now got
"explicit", _because_ people learned the hard way that implicit
conversions are causing more trouble than wanted.
[...]
> > > We use common sense on a case by case basic.
> >
> > I tend to believe the common sense in type conversion land is pretty
> > close to "avoid to do it automatically, prefer to make it explicit".
> >
> > Already now it's far too easy to make mistakes based on the "nice
> > and easy" QByteArray -> QVariant -> QString conversions when
> > accidentally writing QByteArrays into QSettings and reading QStrings
> > back. There shouldn't be more of that.
>
> What's the mistake here? Wrong encoding? Bad performances?
Wrong encodings under circumstances that are typically not present on
the developers or test machines. Here the lack of type safety postpones
a problem that would be immediately visible (and fixable) at compile time,
to the time after the application has been shipped.
In the best case this "only" causes a bug report that needs to be handled
"normally", i.e. needs triaging/fixing/integration (and hopefully is not so
critical to require an immediate emergency release, but can be delivered
with the next regular one). Worst case this could mean that the application
is unusable in a larger part of the world. With or without someone reporting
the problem.
This is a kind of "convenience" I don't need, and I pretty much prefer
the inconvenience of having to spell out type conversions explicitly.
> When one use QVariant, it is because we want to enjoy dynamic typing
> and nice conversions.
I wholeheartedly disagree. Most of my QVariant uses are there because
the Qt API requires me to use it, and I sometimes use it voluntarily for
type-agnostic storage or transport of "things". But in those cases I never
want to extract anything else from the variant than exactly the "thing"
I put into it.
I _never_ (at least not intentionally) use QVariant as a kind of "magic
converter bag" where I put something in and get something
"conveniently" munged back.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
Olivier Goffart:
> Poenitz Andre wrote:
> > I wholeheartedly disagree. Most of my QVariant uses are there because
> > the Qt API requires me to use it, and I sometimes use it voluntarily for
> > type-agnostic storage or transport of "things". But in those cases I never
> > want to extract anything else from the variant than exactly the "thing"
> > I put into it.
>
> So if I understand you and Eike correctly, what you want is some kind of
>
> template T qvariant_cast_safe(const QVariant &v) {
> Q_ASSERT(v.userType() == qMetaTypeId())
> return *reinterpret_cast(v.constData());
> }
This would alleviate the "environment dependency" of the problem,
i.e. presumably increase the probability that the issue is caught in
local testing. (Of course, a real compile-time check i.e. something
that would also catch errors in code paths that are not executed during
testing would be preferable, but that's not achievable in this setup)
> I _never_ (at least not intentionally) use QVariant as a kind of "magic
> converter bag" where I put something in and get something
> "conveniently" munged back.
> > When you play with qml or itemview, it's cool that there is a
> > QVariant::toString() that puts some string out in order to show
> > to the user what's in it.
That's a one-way route for a specific purpose, pretty much like
qPrintable(). There's nothing wrong with a .toDisplay() (or similar)
function, but that's don't think this is the kind of type conversion
that triggered this thread.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
Jędrzej Nowacki wrote: > Eike wrote: > > [...] > >>> We use common sense on a case by case basic. > > > > Either there is no “common sense” common to me, or this rule has failed in > > the past already ;) > > bool -> string ? > > bytearray -> int/long/double ? > > keysequence -> int ? > > string -> bool ? > > string -> bytearray ? > > string -> int ? > > What is wrong with string -> int or bytearray -> int? At the very least, _implicit_ conversions should not lose data, i.e. a A a1; B b = a1; A a2 = b; round trip ideally should yield a1 == a2. If I am ready to give up information, I'd like to need to say so in the code explicitly. (And yes, part of the deed is done in the core language, but even there compilers start to nag about it.) Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Converting types in Qt
Olivier Goffart wrote: > Jędrzej Nowacki wrote: > [...] > > > What is wrong with string -> int or bytearray -> int? > > > > At the very least, _implicit_ conversions should not lose data, > > i.e. a A a1; B b = a1; A a2 = b; round trip ideally should yield > > a1 == a2. > > > > If I am ready to give up information, I'd like to need to say so > > in the code explicitly. (And yes, part of the deed is done in the > > core language, but even there compilers start to nag about it.) > André, QVariant conversions are not implicit, they are explicit. I am aware of that. I tried to answer the question of "What is wrong with string -> int or bytearray -> int". We admittedly left the original context here (and in other parts of the discussion), but the question was posed in context that I read an example of an conversion that one would always consider convenient to have, and I started with "At the very least, _implicit.." supposedly setting the context of the answer. Anyway. To summarize my position in the original context: QVariant is as it is. It is convenient at times, and it is already too convenient at times. "Easy type conversion" is a different use case than "Type agnostic storage". QVariant does a bit of both, only the second one has ever been useful _to me_, I have been bitten by the first. As there are typically also more direct ways to convert types than to pass through QVariant, I consider the possibility to do type conversion through QVariant a mis-feature, and adding even more conversion abilities would be a step into the wrong direction _for me_. This is a personal opinion. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Debugging Android App on Qt Creator 3.1.2 and real device (Python scripting)
Fernando Pelliccioni wrote: > I just made a bug report, but I want to comment on this forum to get earlier > feedback. Sorry if it is not the place to do it. It's not the place to do it. Anyway... > I can not debug an Android application using Qt 5.3.1 and Qt Creator 3.1.2 > and a real device (Samsung Galaxy S2 GT-9100) > I am getting this error: > "The selected build of GDB does not support Python scripting" So Google managed to package a broken GDB in r10... > So, any workarond? The r9d NDK contains a GNU gdb (GDB) 7.3.1-gg2 with working Python (at least on Linux...) You could install r9d next to your r10 and copy the arm-linux-androideabi/bin/arm-linux-androideabi-gdb and share/gdb to your r10 installation. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QOptional
Иван Комиссаров wrote: > I've started working on a QOptional class > (https://codereview.qt-project.org/#/c/92006/). > As Thiago mentioned in gerrit, there are some things to discuss. 3) Why do we need that class at all? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QOptional
Иван Комиссаров [abba...@gmail.com] wrote: > The goal is to get rid of ugly "int QString::toInt(bool *ok = 0)" functions. Can you maybe spell out some code to demonstrate why this is ugly, and how the use of QOptional would improve that? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QOptional
Milian Wolff [m...@milianw.de] > On Thursday 21 August 2014 13:13:15 Иван Комиссаров wrote: > > Of course, i can:) > > > > bool ok; > > const int value = string.toInt(&ok); > > if (ok) > > qDebug() << "value is" << value; > > > > // > > const auto value = string.toInt(); > > if (value) > > qDebug() << "value is" << *value; > > This is a source-incompatible change (and the bool* ok = 0 is optional). You > cannot add such an API in Qt 5. You'd need to chose a different name. > > While I agree that the existing API is not nice, coming up with new names > won't be much nicer. In Qt 6, I we can just use std::optional and similar. In > Qt 5, personally, I'd say lets stick with what we have and not try to reinvent > yet another part of the STL. Exactly my thinking. Andre' PS: > But that's just me. Doesn't look like it ;-) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QOptional
Hausmann Simon wrote: > On Thursday 21. August 2014 13.13.15 Иван Комиссаров wrote: > > Of course, i can:) > > > > bool ok; > > const int value = string.toInt(&ok); > > if (ok) > > qDebug() << "value is" << value; > > > > // > > const auto value = string.toInt(); > > if (value) > > qDebug() << "value is" << *value; > > To be honest: I find the "bool ok" variant much easier to read. > "if (value)" on an auto variable can mean so many things. In the > above example you could very easily think: Ah, toInt returns an int, > so the type of "value" is probably int, so if (value) checks if it's non-zero. So the "ugliness" of the "traditional" code is essentially hidden by the use of 'auto' in contexts where the type is not obvious to the casual reader. Another can of worms. In practice this would end up often enough with bool ok; const int value = string.toInt(&ok); if (ok) qDebug() << "value is" << value; vs const QOptional value = string.toInt(); if (value) qDebug() << "value is" << *value; which is as cluttered as before in my eyes. Andre' PS: > I don't think that makes for a very intuitive API. Yes, it's less to type, > but less isn't always more :) Indeed. Apart from that, if 'less typing' would be the primary goal, progress could be made by switching the return value and parameter: // Hypothetical: bool QString::isInt(int *value) const int value; if (string.isInt(&value)) qDebug() << "value is" << value; [No, I am not suggesting to add that to QString, it's just an example, but it's even shorter than the QOptional auto version and "reads" as something that can/should be checked with an 'if'] ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QOptional
Julien Blanc wrote:
> There are two strong arguments in favor of optional :
> - real life tends to show that the optional &ok parameter is often
> missed in context it should not, leading to hard to find bugs.
> - optional is much more friendly to static verification than &ok
(dependancy between variables is a mess to check).
Logically, in the presence of more than two alternatives, an argument
against the current solution is not necessarily an argument in favour
of QOptional, let alone a 'strong' one.
The first "laziness" issue would e.g. also be addressed by the aforementioned
bool QString::isInt(int *value) setup which provides an obvious way to
check success without giving the programmer the feeling to need to
jump through hoops before being able to check for errors.
I am actually not quite sure what you mean with the second item.
Something like the following?
struct S { int m_a, int m_b, int m_c);
// "Tradtional, wrong result"
bool S::parse(QString a, QString b, QString c)
{
bool ok;
m_a = a.toInt(&ok);
m_b = b.toInt(&ok); // Oops, overwrites first ok value.
m_c = c.toInt(&ok);
return ok;
}
vs
// "Tradtional, right result"
bool S::parse(QString a, QString b, QString c)
{
bool oa, ob, oc;
m_a = a.toInt(&oa);
m_b = b.toInt(&ob);
m_c = c.toInt(&oc);
return oa && ob && oc;
}
vs
// "Optional"
bool S::parse(QString a, QString b, QString c)
{
auto oa = a.toInt();
auto ob = b.toInt();
auto oc = c.toInt();
m_a = *oa;
m_b = *ob;
m_c = *oc;
return oa && ob && oc;
}
vs
// "isInt"
bool S::parse(QString a, QString b, QString c)
{
bool oa = a.isInt(&m_a);
bool ob = b.isInt(&m_b);
bool oc = c.isInt(&m_c);
return oa && ob && oc;
}
vs
// "something else"
bool S::parse(QString a, QString b, QString c)
{
return a.isInt(&m_a) && b.isInt(&m_b) && c.isInt(&m_c);
}
If so, the "Optional" variant doesn't look much simpler than any
of the others, even less so when one doesn't accept the use of
'auto' there.
> Still, the issue about the semantic of “if(value)” when value == 0 /
> false is still a concern (and one of the reason optional is not part of
> the standard iirc)
... and a show-stopper when it comes to using it with QString::toInt
(with exactly that 'toInt' function name)
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiler warnings
Kurt Pattyn wrote: > > On 14 Oct 2014, at 10:21, Bo Thorsen 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] RFC: Proposal for a semi-radical change in Qt APIs taking strings
Marc Mutz wrote: > > I think too we should embrace the standard library more and don't replicate > > their features. > > So you think that QStringView is too experimental and _at the same time_ > replicating the standard. Sounds paradoxal to me. It's not paradoxical at all. It would be a new implementation with the usual need for maturing even if it implements a well-known standard concepts. And there is indeed room for actual experiments, e.g. when it comes structure layout. Pointer+int offset is not the only possible choice. You cannot do that in Qt proper, due to BC promises. Compile-time opt-in is a way to exempt it from BC, but then your main reason to have it in Qt and not in Creator, namely 'more widespread use', is void, as barely anyone will opt in. You'll get more public exposure (with less risk!) if it's used by default in Creator code for a while before the then-matured implementation goes to the library. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: more liberal 'auto' rules?
Lars wrote: > I don’t think there is a full consensus. Indeed, there isn't. > Let me try to summarise where > we are, what I think we agree upon and then add my thoughts :) > > As a primary goal, auto should be used wherever it increases readability > of the code. I think we all agree here. The problem is that there’s dissent > in what ‘more readable code’ is in practice. > > I think everybody also agrees one the use cases listed in > https://wiki.qt.io/Coding_Conventions#auto_Keyword , so the question now > is what additional use cases do most of us agree to? > > And how to put that into rules, as a listing with 50 entries won’t help > anybody. I agree with that so far. > While I don’t think we should go and implement aaa right now, I would > probably > be ok with a somewhat broader usage than the current coding conventions imply. > Marc presented some use cases. Going through those, I don’t think I heard > any disagreement about using auto in template, so I think we can probably > add that one to our guidelines. Marc's proposal included to *require* use of "auto" in some cases. I do not agree with that *required* use at all. That's not just because "auto is required in templates" would give the AAA supporters suddenly a big incentive to start writing or converting normal functions to templates just because they can use auto freely there, but since I don't believe visible types are bad per-se and far less of a "problem" than the AAA faction tries to make me believe. I would accept (and probably use myself) "optional use of auto" for - *some* template code (e.g. the mentioned 'typename' case) - references to elements in a collection *with "non-trivial" type*, i.e. something that is a template instance, or in deeply nested namespaces. (i.e. ok for std::pair, not ok for 'int' or 'QString') Marc's *optional* proposal "Optional use of auto: whereever it makes sense. Use your own judgement, but remember: fear is a bad advisor." pretty much opens the door for AAA, as for an AAA supporter "auto" will *always* make sense. So effectively the proposal consists of two attempts to implement an AAA policy. That's going way too far in one step. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fixing QRect::width() / height()
On Tuesday 15 March 2016 13:08:42 Bo Thorsen wrote: > > Den 15-03-2016 kl. 14:07 skrev Marc Mutz: > [...] > > There is another option that doesn't mean a change of signature: Bound > > the result. So if the real result is > INT_MAX, return INT_MAX. Same for > > INT_MIN. > > > > Yes, it's not the correct result, but I completely agree with you that > > it's a theoretical problem. As long as it's documented in the width() I > > really don't see the problem with this solution. > > I like the idea to change width() to return a bounded result to avoid UB for > old users, but we need a code path that returns the correct result for new > users without everyone of them going quint64(1) + r.right() - r.left() by > themselves... You seem to claim that new users would need 64 bit QRects. This is unlikely. Bo's proposal addresses the problem and does not require API changes. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fixing QRect::width() / height()
Marc Mutz wrote:
> > Cluttering up the API doesn’t seem nice. Also not sure what you mean by
> > new users needing such large rectangles… if they do, why don’t they use
> > QRectF?
>
> For one, QRectF has different semantics w.r.t. wdith()/height(), for another,
> sizeof(QRectF) == 2 * sizeof(QRect).
That does not mean that the needed semantics would not be achievable.
> > Or is it about a security hole?
>
> Yes, that, too. If you read a rectangle from user input, then an attacker can
> currently force you to construct a QRect with overflowing bounds. ATM, calling
> width() on this QRect invokes UB. Bo's idea would fix the UB, but return
> something other than the width().
The return value would be the same before, except for values around INT_MAX.
Such values are *not* expected in a legitimate use of QRect ("Screen
coordinates"),
so a behaviour change there will not affect normal users.
The clamping achieves exactly what is wanted: It plug the hole without
side-effects for supported uses.
> It's not impossible that this could be
> exploited, too, e.g. if the app divides by a non-isNull rect's width and the
> attacker forges the coordinates such that width() return 0
Please describe how that can happen.
width() return will only change around INT_MAX, not around 0.
> But it's also about designing an API that's easy to use correctly and hard to
> use incorrectly.
Adding a second width() version is exactly that: It designs an API that's
harder to use ("which version do I need"?), leaves all existing users
in the rain, and would trigger major changes in code that wants to adapt.
Clamping width() fixes the problem for existing user code automatically,
and leaves the API unambiguous.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI]
Marc Mutz wrote: > I said then and I repeat it now that imho template aliases are not interesting > for library development. In particular, I don't think something like > > > > > template > > > > using QNodeCreatedChangePtr = QSharedPointer>; > > should be part of an API of a library. We have auto to avoid having to type > this type. The typedefs just hide the (essential) fact that this is a shared > pointer type. Do I understand correctly that you argue that the fact that the actual type is a shared pointer is so important that it shall not be hidden by a template alias whereas it would be completely fine to hide everything related to type by using auto? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI]
Marc Mutz wrote: > On Monday 21 March 2016 12:07:24 Poenitz Andre wrote: > > Marc Mutz wrote: > > > I said then and I repeat it now that imho template aliases are not > > > interesting for library development. In particular, I don't think > > > something like > > > > > > > > > template > > > > > > using QNodeCreatedChangePtr = > > > > > > QSharedPointer>; > > > > > > should be part of an API of a library. We have auto to avoid having to > > > type this type. The typedefs just hide the (essential) fact that this is > > > a shared pointer type. > > > > Do I understand correctly that you argue that the fact that the actual > > type is a shared pointer is so important that it shall not be hidden by > > a template alias whereas it would be completely fine to hide everything > > related to type by using auto? > > Yes, you understood me correctly. > > And to answer your implied objection, too: > > No, there's no contradiction, because auto is for use in implementations and I > was talking explicitly about APIs (which implies API documentation, too). It's > one thing to write > > auto o = factory->create(); > > and quite another to have > >QNodeCreatedChangePtr create() [virtual] > > (to make up a plausible, but nonsensical example) in the docs. > > Thanks, > Marc I will argue that if user code looks ugly by default, or needs one specific, controversial coding style when using an API, the API is bad. A possible question here is why there's a need to have the QSharedPointer show up in the API at all. Is it meant to be a vehicle to provide value semantics? If so, why isn't the sharing hidden in the implementation of the object? Is it meant to hide unclear ownership and object lifetime? If so, shouldn't ownership and lifetime better be clear? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI]
Sean Harmer wrote: > On Monday 21 March 2016 12:23:44 Poenitz Andre wrote: > > I will argue that if user code looks ugly by default, or needs one specific, > > controversial coding style when using an API, the API is bad. > > > > A possible question here is why there's a need to have the QSharedPointer > > show up in the API at all. > > > > Is it meant to be a vehicle to provide value semantics? If so, why isn't > > the sharing hidden in the implementation of the object? > > > > Is it meant to hide unclear ownership and object lifetime? If so, shouldn't > > ownership and lifetime better be clear? > > It's to support one-to-many delivery of an event-like object to backends > potentially running on multiple threads concurrently. Is a receiver of this "event-like object" meant to be able modify the shared data while the other receiver keep hold of their "copy", i.e. is this effectively as shared_thing or is it a conscious decision to let receivers modify object state behind other receivers' back? In the first case, the shared ptr should be an implementation detail of the class and the class itself made appear to have value semantics. No need for the user to worry about ownership at all. The second case should be banned to start with. Making something modifiable, creating multiple ways to access it, and relying on distant parts of an application to cooperate when modifying that state is calling for trouble. > > The type is not a QObject so can't be managed by the QObject > > parent-child relationship. Using a naked pointer goes against modern > > C++ recommendations and would mean having to put in place code > > to delete the objects after all consumers are done with it. Just replacing a naked pointer by a shared pointer does not solve the ownership problem. At best, it addresses part of the lifetime aspect. "Being modern for the sake of being modern" is also no a good enough reason here. The trend seems to go towards value semantics lately. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Branching for Qt 5 repositories
From: development-bounces+andre.poenitz=digia@qt-project.org [development-bounces+andre.poenitz=digia@qt-project.org] on behalf of Loaden [loa...@gmail.com] > I prefer: > dev -> next > stable -> master > release -> release -1, and +1 for the originally proposed version. For someone wanting to just check out something that works, the "dev"/"stable"/"release" naming gives a fairly decent idea of what to expect. "master" has completely different meaning in different projects, there's no way to know what it might contain without consulting "external" documentation. Also, since "master" has been used in the past, re-using it for a different(!) level will cause confusion, as people will run into outdated information all over the net. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
Thiago Macieira: > On sexta-feira, 19 de outubro de 2012 06.07.34, Kalinowski Maurice wrote: > > On Windows there is no global qmake or such to call and distinguish between > > versions. Each Qt version will have to live in its own package, either made > > by the binary distribution or self-compiled. Hence that argument is > > obsolete. > > For Windows, that's correct. > > > So you are creating distribution scripts which then point to the currently > > used Qt version for qmake? If not, who is creating those for the other > > libraries/tools, which follow a similar attempt of having a simlink in > > /usr/bin or /usr/local/bin pointing to libexec. Has anyone talked to those > > package managers how they see it? > > No, we're not creating scripts. As I replied to Lorn, I don't see the value in > having qmake duplicated in $bindir and $libexecdir. > > Since $bindir/qmake is already taken, if we put something in $bindir, it needs > to be called something else. The only other option is to not install anything > in $bindir. If we choose that, however, how will users find qmake in the first > place? > > So we have $bindir/qmake5 and we update all the documentation to say "qmake5". > What's the use of $libexecdir/qmake now? > > In my plan, "qmake" will never be for Qt 5. Whether it's for Qt 3 or for Qt 4, > it's undefined. That mess is already present and we can't fix it anymore. I started -2'ing the changes, based on the outcome of a cost/benefit "analysis": - The "problem" only exists on Linux * There are existing, working solutions to the "problem" there * There are skilled people (distro packagers) there perfectly capable of handling the "problem" * The majority of Qt users is not affected at all. - The "solution" is invasive. * Some of the follow-up changes are only triggered by the renaming E.g. the "need" to co-install lupdate does not exist yet, but is _introduced_ by the qmake changes. * It affects any user project setup involving moc, uic, etc "custom buildstep", like the ones _all_ Qt using Visual Studio projects have, therefore eliminating the possibilty of having a code base running on both Qt 4 and Qt 5, and even hampering a direct Qt 4 -> Qt 5 port. * Documentation needs to be adjusted. * Existing third party documentation of Qt in use, howto's, tutorials, in the *net lose value, because it will be not accurate anymore. This is a completely unreasonable trade-off. Andre' Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
Sorvig Morten wrote: > Knoll Lars wrote: > > Hi, > > > > looks like there's quite some discussion about Thiago's proposal. > > Let's see if we can get at least agreement on most of the changes > > and then focus on the parts that are controversial. > > To me this looks like a case where there clearly won't be a consensus, > which means we're going to need a Chief Maintainer decision at some > point. I hope we can all respect what ever that will be, and then move on. The problem is only solved by a decision if the decision is "stay put". In the other case, someone has to cleanup the fallout. Neither tooling nor user projects will magically adjust just because there was a Word. Andre' PS: I honestly start wondering how a change with such an impact can be seriously considered _at all_ that late in the process. Trivial additions have been rejected for months because we are in feature freeze and now _that_. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Summary of renaming changes
Sune Vuorela [nos...@vuorela.dk] > I have, as a distributor, frequently gotten 'hate' in #qt for providing > switchable qmakes. > And from a 'user support' PoV, having to write "depending on what you > have set as your default you can maybe write qmake, maybe you need to > oither switch the default to qt5 or alternatively write qmake5 to > build things" is a much longer sentence than > > "write qmake5 to build things". > > The advantage of doing it upstream, rather than having me to do it, > kevin to do it, will to do it, jonathan to do it, ... is that > - the implementation is the same > - the result is the same > - you do not have to consider what distribution teh user is on when >trying to help in #qt, on interest@ or in forums. just write 'use >qmake5 That's achievable by a few lines of text: Linux distributors are strongly advised to install all Qt 5 related executables (qmake, uic, rcc, ...) with unmodified names to a directory that is not in $PATH and set up symlinks 'qmake5' etc that are in $PATH. Linux distributors are strongly advised to install all Qt 4 related executables (qmake, uic, rcc, ...) with unmodified names to a _different_ directory that is not in $PATH and set up symlinks 'qmake4' etc that are in $PATH. If Linux distributors feel strong about it, they may use their distributions "native" system to handle alternatives to set up 'qmake' etc links in the path to point to the qmake binary in either the Qt 4 or the Qt 5 binaries directory, [Suggesting to modify PATH is probably the saner choice, I don't really care about this part] User support could then be: "write qmake5 to build Qt 5 things" Users/Admins could then use the distribution's "defaults" system to switch the "system" Qt version, they can also override the system setup by modifying their local PATH settings, per-shell even. None of these operations are "unusual", or "technically challenging", or "cumbersome", and it does not require, or even only benefit, from the proposed renaming of the binaries. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending decisions on co-installation
Sune Vuorela:
> This is something that will happen to be done. and for the sake of
> documentation and support, please let it be consistant not only across
> distributions, but also across platforms so that documentations don't
> have to be
> if mac | upstream-provided-linux-builds {
> run qmake
> } else if windows {
> run qmake.exe
> } else if debian {
> run qmake-qt5
> } elese if fedora {
> run qmake5
Nobody was asking for that.
The attempts at a solution were revolving so far around
(a) providing a means to select a sandboxed Qt version
(b) running qmake
(a) can be as much as "nothing" on all setups that only have a single
version of Qt around, or some other means to switch (like when using
Creator, or whatever distributions consider "native" on their system),
and (b) is obviously cross-platform.
> Yes. we need to do something. and if the 'something' is to ask Lars as
> chief maintainer to override Ossi, then we must do that.
This is not about "overriding someone". This is about ranking the user
experience of the majority of users higher than the convenience of a
handful of Linux distribution packagers - half which will do their own
renaming anyway, no matter what the official solution will look like.
Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] binary compatibility promise (was: Re: Frameworks on Mac?)
Peter Hartmann wrote: > On 11/23/2012 12:12 AM, André Pönitz wrote: > > (...) > > The reality is that this guarantee often enough does not hold in > > practice. Vendors of "binary" Qt based application typically test their > > setup against one specific (often enough patched) version of Qt which > > is then shipped with the application. Users are not expected to switch > > Qt versions, except when upgrading the whole application. Insofar are > > rules like "we can't add symbols in patch releases" not much more then > > self-inflicted pain without measurable gain. > > This situation is different on mobile (and I guess embedded as well); > for BlackBerry10 we have one version of Qt on the device Do you intend to upgrade this version of Qt that's installed on the device without upgrading the applications using it? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QMake behaviour change
> Nope, but I guess that a common interpretation of pro-files between > qmake and QtCreator are of interest to most. You need contemporary versions of Qt Creator for use with recent versions of Qt. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] abandoning stale changes on gerrit
Oswald Buddenhagen wrote: > > No, and that's my point : I don't really care how many changes others > > have. I'll deregister myself from those I'm not interested in. > > > all changes i'm subscribed to are somehow interesting to me, obviously. > that means that i don't want to unsubscribe, as i'd miss any relevant > activity. therefore they should be abandoned if they are dead, rather > than having everyone remove themselves (and in the worst case spam all > other subscribers with a request to be re-invited). > > > Can you elaborate a bit on what practical issue this would solve? > > (beyond "there are many changes in gerrit"). > > > apart from the above, it also skews the metrics (in case somebody ever > decides to use the number of open changes for something). > > also, the matter is not up for discussion: the cleanup of dead changes > was decided before we launched. i'm just executing. Than this decision should be revised. My dashboard still fits a screen, even with a few old items in it. If yours doesn't and you don't like that (I wouldn't...) unsubscribe yourself. Destroying other people's work is not an option. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
Samuel Rødal wrote: > What use is a QPlatformPixmapHandle having per-platform typedefs > (xcb_pixmap_t, HDC, etc) without #ifdefs to manipulate it using native > code in the first place? > > Can you give a platform-independent example use case? :) It helps reducing the amount of user code within #ifdef therefore the risk of breaking branches that are not "active" on a developers machine. It can postpone the need to switch to native code, so helper function merely passing on such handles can be written completely #ifdef free. Structures keeping such handles can be defined more cleanly, similarly class interfaces. Ports to new platforms with new platform specific handles are easier as they touch less code. Etc etc. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
Rodal Samuel wrote: >On 02/14/2013 10:39 AM, Poenitz Andre wrote: >> Samuel Rødal wrote: >>> What use is a QPlatformPixmapHandle having per-platform typedefs >>> (xcb_pixmap_t, HDC, etc) without #ifdefs to manipulate it using native >>> code in the first place? >>> >>> Can you give a platform-independent example use case? :) >> >> It helps reducing the amount of user code within #ifdef therefore >> the risk of breaking branches that are not "active" on a developers >> machine. > >There's still the problem that it's not possible to do such typedefs as >easily as in Qt 4.x since back then the windowing system was known at >compile time. This sounds like a contradiction. Are you saying you can use the native type at compilation time, but not a typedef with a platform-neutral name for it? > You would have to find a common denominator for all Unix > platform plugins for instance, covering KMS, Android, XCB, Wayland, > and more. The needed common denominator for is "existence", and on the technical side some "would be nice if the handle (not the object) is copyable so it's possible to store and pass around". >> It can postpone the need to switch to native code, so helper >> function merely passing on such handles can be written >> completely #ifdef free. >> >> Structures keeping such handles can be defined more cleanly, >> similarly class interfaces. > >As for passing such handles around you might just as easily be able to >pass the QPixmap * or similar around. In some cases there might be >multiple handles associated with a resource, such as on X11 in 4.x days, >where a QPixmap had both a handle() and a x11PictureHandle(). Perhaps. Perhaps not. What with cases that really operate on native handles only. And of course a typedef cannot be used if it does not convey the necessary information. All I am saying is that the Qt library side should try hard to make it possible for user code to stay platform-agnostic to the largest extend possible. This might not possible in all cases. Bad luck there, but no need to pro-actively make cases harder where it would be possible. Andre' PS: > [...] A problem with exposing too much of theinternals is that you >remove the flexibility of changing the implementation without breaking > applications (like when we made QPixmap raster-based on X11). This restriction of presumably needing this or that kind of compatibility is completely self-imposed. There is no conceptual difference between saying "set QT_I_DO_NOT_NEED_COMPATIBILTY than you get a few extra features. Use it if you want, but you are on your own" and "There is this module, add it to your build system, etc, Use it if you want, but you are on your own" _except_ that the latter imposes more work for the user. Lots of real-world use cases like our very own Qt installers or the binary Qt Creator builds do e.g. not require binary compatibility on the Qt side at all (even source-incompatibility would be tolerable) but would pretty much prefer to not need a platform-independence layer on top (or alongside) Qt proper. But that's mostly a different story. We can discuss that too, but perhaps in a separate thread. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Creator Debug - GDB error
Majid Khan wrote: > I am trying to debug Qt Creator (working on #7044) but when I debug > (its new linux mint 14 Nadia Cinammon) my gdb gives error > > Starting executable failed: > "/home/majid/projects/qtcreator-build/bin/qtcreator.sh": not in executable > format: File format not recognised That's the wrong run configuration (the one for the wrapper script, not the application itself). Select 'app', not 'bin' in the Target selector or under Projects/Run Run configuration. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fwd: Change in qt/qtbase[dev]: Enable -Werror for all of qtbase
That's wasting our time, as predicted. ../../corelib/tools/qdatetime.cpp: In function 'time_t qt_mktime(QDate*, QTime*, QDateTimePrivate::Spec*, QString*, bool*)': ../../corelib/tools/qdatetime.cpp:258:34: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] cc1plus: all warnings being treated as errors Together with the recent insistence that it's fine to submit non-compilable chances I start wondering about the direction. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] #error for unreleased MSVC versions
Thiago Macieira [thiago.macie...@intel.com] > I'm going to add an #error to qcompilerdetection.h for any unreleased version > of MSVC. > > ==> In other words, adding new Q_COMPILER_xxx defines for C++11 for MSVC > breaks >binary compatibility <=== > > For that reason and because we don't know what features newer MSVC will > support, I am right now declaring all future versions unsupported until > there's a Qt release that adds the defines. Am I understanding this right that this will make such versions of Qt uncompilable _even for people who do not care about binary compatibility_? Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
