Re: [Development] Qt 5.12 new features

[Mark Gaiser]

On Thu, Aug 16, 2018 at 4:17 PM Vlad Stelmahovsky <
vladstelmahov...@gmail.com> wrote:

> A bit unclear about deprecating QQC1
> Since in QQC2 no TreeView and even no plans for this, isn't it a bit too
> early to deprecate QQC1?
>
> thanks
>
> On Thu, Aug 16, 2018 at 4:02 PM Jason H  wrote:
>
>> 5.11 included WebGL TP2. Is there any change? Why is it staying TP2, or
>> should it be TP3?
>>
>> 5.12 looks like it'll be a pretty great update!
>>
>> I'm not sure what's on the agenda for 5.13... but as I mentioned on
>> interest, one pain point I continually have is the amount of custom
>> platform integrations for mobile. This is one area where Xamrain excels, as
>> they have a simple property on an object you can set to control things like
>> the status bar visibility, the screen brightness, etc. The downside is the
>> Xamarin stuff is all platform-specific so using a iOS property on Android
>> won't work. This is one area where Qt can leapfrog the other platforms
>> including React Native by being cross platform. Anything that doesn't
>> require me to write Obj-C is a very good thing!  I figure this would need
>> to be a few Qt Quick/QObject Singletons. Notifications should be supported
>> too, and this could also be used for desktop platform notifications as
>> well. The notifications support would only need to cover being messaged my
>> the platform, and not any display - this would get me out of having to deal
>> with Obj-C almost completely. (My beef wi
>>  th ObjC is other than being not good at it, is whatever I'm writing
>> isn't cross-platform. Java I am more comfortable with, so I complain less,
>> but I still cringe on the non-portability!)
>>
>> Looking forward to 5.12!
>>
>> > Sent: Wednesday, August 15, 2018 at 12:50 AM
>> > From: "Jani Heikkinen" 
>> > To: "development@qt-project.org" 
>> > Subject: [Development] Qt 5.12 new features
>> >
>> > Hi,
>> >
>> > Qt 5.12 Feature Freeze will be in effect Mon 20th August and we should
>> have already now pretty good understanding what is new in Qt 5.12. So
>> please update 5.12 new features page here:
>> https://wiki.qt.io/New_Features_in_Qt_5.12
>> >
>> > br,
>> > Jani
>> >
>
>
Why deprecate QQC1?
If you aim for a native looking QML application in Windows 7 then QQC1 is
basically the only viable way to go.
I know there is a third party plugin for QQC2 and the QWidgets style (thus
also Windows 7) integration, but it's a third party one [1] and not shipped
with Qt. I have no clue how much of the QWidgets style is supported by that
plugin.

I think it would be nice to not deprecate the only QML way to make native
looking Windows 7 applications in the Qt 5.xx lifecycle.
Or do deprecate it, but offer the plugin [1] from within the Qt installer
as an alternative.

Also, i vaguely remember that QQC1 was meant for integrating applications
in QML with your host OS and QQC2 was targeted at mobile and to be free of
QWidgets to allow for performance improvements.
So they both serve a different target group despite having quite some
overlap in functionality.

[1] https://github.com/KDE/qqc2-desktop-style
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Coding style for lambdas, particularly their open-brace

[Mark Gaiser]

On Fri, Aug 18, 2017 at 2:17 PM, Edward Welbourne 
wrote:

> Hi all,
>
> We have a draft policy for lambdas at [0], in a section that begins with
>
>   Note: This section is not an accepted convention yet.
>   This section serves as baseline for further discussions.
>
> That section is now a quarter decade old; it's had a few updates since
> it was added (2015-02-27), so may fairly be said to be evolving (albeit
> it's had more formatting changes than substantive ones); but perhaps
> it's about time we agreed that at least its low-level bits about
> formatting can be promoted to [1], without such a caveat.
>
> * [0] https://wiki.qt.io/Coding_Conventions#Conventions_for_C.
> 2B.2B11_usage
> * [1] https://wiki.qt.io/Qt_Coding_Style#Braces
>
> In particular, I'd like to (at least) amend the first exception in [1],
>
>   Function implementations and class declarations always have the left
>   brace on the start of a line:
>
> to include "(but not lambdas)" in a judicious place, so that lambdas are
> excluded from the exception and fit into our general pattern, putting
> the open-brace on the same line as its controlling preamble: e.g.
>
>   Function implementations (but not lambdas) and class declarations
>   always have the left brace on the start of a line:
>
> Does anyone object to this minimal change ?
> (How long do I have to wait before I can claim lazy consensus ?)
>
> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

The explicit return type rule should probably be changed, as that was for
VS2010. And that compiler has been dropped in 5.7.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-Quick] GridStar layout for QML

[Mark Gaiser]

On Sun, May 28, 2017 at 5:00 AM, Casey Sanchez  wrote:

> I've created a grid layout that I find to be more functional than the
> default that is provided.
>
> For full documentation please see:
> https://forum.qt.io/topic/64699/gridstar-layout
>
> The Git Repo can be found here:
> https://github.com/Tannz0rz/GridStarLayout/tree/master/Quick
>
>
> Any suggestions are appreciated. Thank you for your consideration.
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
Hi,

That looks neat!
Just a couple of questions (without reading the code or playing with it)

1. Does it allow dynamic row/comumn add/removal? A usecase for that would
be a column based file browser where opening a folder would create a new
column.
2. Are states and transitions supported? So when a cell changes in size,
can that change be animated (obviously provided the transition effect is
defined in qml, it isn't be default)?
3. "GridStar.rowSpan: 0 // Span remaining rows" doesn't look intuitive to
me. Something like "auto" or "fill" would perhaps be more fitting?

I've been playing with an improved Grid concept as well. In my case it is
inspired by the CSS Grid Layout [1]. I would define the layout in ASCII. A
simple example would be something like this:

ApplicationWindow {
  width: 800
  height: 600

  GridLayout {
anchors.fill: parent
layout: [ "header",
  "col content",
  "footer" ]

Rectangle {
  id: header
  height: 100
}

Rectangle {
  id: col
  width: 50
}

Rectangle {
  id: content
}

Rectangle {
  id: footer
  height: 25
}
  }
}

Not defining sizes (width/height) would distribute all available space
evenly.
The "content" element in this example therefore has no width/height. It
simply takes all remaining space.

This concept worked quite well and i had some working code (the example
above actually worked!).
It quickly became rather complicated when cell spacing would be included,
animations and dynamic additions/removal of cells and layout
re-calculations. That's where i left it i think.


[1] https://www.w3.org/TR/css-grid-1/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QHash iteration vs std::unordered_map

[Mark Gaiser]

On Sun, Apr 16, 2017 at 9:48 PM, Samuel Gaist <samuel.ga...@edeltech.ch> wrote:
>
>> On 16 Apr 2017, at 17:53, Thiago Macieira <thiago.macie...@intel.com> wrote:
>>
>> Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
>>> That again makes me wonder, why did Qt diverge from that?
>>
>> We didn't diverge. We never had that. The Qt style predates the Standard
>> Library having relevance in Qt. When the first QHash-like class was added, it
>> was just like that.
>>
>> Also remember that at the time, you wouldn't think of a Standard Library
>> associative container as such. It was just a sequential container that held a
>> std::pair, with some convenience functions for searching the first of the 
>> pair.
>> Returning a pair was a consequence of that. I don't know if it was 
>> intentional
>> thinking, or it just happened.
>>
>>> And... if Qt plans to change it in Qt6?
>>
>> No, cannot due to source compatibility. Ever.
>>
>> --
>> 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
>>
>
> Hi,
>
> Just in case, there’s a work in progress at
>
> https://codereview.qt-project.org/#/c/151511/
>
> to add these "missing" iterators to QHash and QMap.

Ohh, that's great!

One question. Would it be possible and sane to - by default - provide
it as the patch implements it there, but with the addition of a define
that can influence the behavior of the iterators?
For instance a "QT_STL_COMPATIBLE_ITERATORS" (just made that up,
doesn't exist) when defined gives the iterators
begin/constBegin/cbegin/enc/constEnd/cend STL compatible output (so
give an std::pair with key and value)?
When not defined (the default i guess) it falls back to what Qt uses now.

Providing this option makes the Qt containers easier to use with STL algorithms.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QHash iteration vs std::unordered_map

[Mark Gaiser]

On Sun, Apr 16, 2017 at 5:53 PM, Thiago Macieira
<thiago.macie...@intel.com> wrote:
> Em domingo, 16 de abril de 2017, às 08:05:21 PDT, Mark Gaiser escreveu:
>> That again makes me wonder, why did Qt diverge from that?
>
> We didn't diverge. We never had that. The Qt style predates the Standard
> Library having relevance in Qt. When the first QHash-like class was added, it
> was just like that.

With regards to QHash vs std::unordered_map, yes.
But STL also has std::map which certainly predates Qt and also gives
back an std::pair.
>
> Also remember that at the time, you wouldn't think of a Standard Library
> associative container as such. It was just a sequential container that held a
> std::pair, with some convenience functions for searching the first of the 
> pair.
> Returning a pair was a consequence of that. I don't know if it was intentional
> thinking, or it just happened.
>
>> And... if Qt plans to change it in Qt6?
>
> No, cannot due to source compatibility. Ever.
>
> --
> 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] QHash iteration vs std::unordered_map

[Mark Gaiser]

On Sun, Apr 16, 2017 at 4:44 PM, Corentin <corentin.ja...@gmail.com> wrote:
> Funny, a friend at kdab asked me about that exact question a few minutes
> ago.
> The reason for the difference is most certainly an historical one ( and
> can't be changed because it would break quite a bit of code ).
>
> If you want the same behavior, you can create a proxy for your associative
> container instance, with a custom iterator whose operator*() returns a std
> pair ( or a QPair ) - quite a bit of boilterplate code.

It probably does come down to historic reasons, but that would be
strange as well.
I doubt that the C++ committee changed what is returned by operator*()
(correct me if i'm wrong) so i'm inclined to think that the
std:: stuff is returning it as an std::pair for quite a
while now.
That again makes me wonder, why did Qt diverge from that?

And... if Qt plans to change it in Qt6?

>
>
>
>
> Le dim. 16 avr. 2017 à 15:57, Mark Gaiser <mark...@gmail.com> a écrit :
>>
>> Hi,
>>
>> Take this simple example:
>>
>>   QHash<int, QString> test = {
>> {10, "aaa"},
>> {20, "bbb"},
>> {30, "ccc"}
>>   };
>>
>>   for (const auto : qAsConst(test)) {
>> qDebug() << entry;
>>   }
>>
>> It returns:
>> "aaa"
>> "ccc"
>> "bbb"
>>
>> and the std::unordered_map version:
>>   std::unordered_map<int, QString> test = {
>> {10, "aaa"},
>> {20, "bbb"},
>> {30, "ccc"}
>>   };
>>
>>   for (const auto : test) {
>> qDebug() << entry;
>>   }
>>
>> it returns:
>> std::pair(30,"ccc")
>> std::pair(10,"aaa")
>> std::pair(20,"bbb")
>>
>> As you can see, the QHash iteration directly returns the value. The
>> std::unordered_map returns a std::par with the key and value for the
>> current iteration (in it's respective first and second members). Both
>> approaches probably have arguments in favor and against. What i'm
>> curious about is why there is a difference at all?
>>
>> I'm curious because the behavior is a bit unexpected when compared to
>> std::unordered_map. I would have guessed QHash to follow the same
>> logic as std::unordered_map, only with a Qt syntax. So for instance a
>> return of QPair(...), not the value directly.
>>
>> Thanks,
>> Mark
>> ___
>> 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

[Development] QHash iteration vs std::unordered_map

[Mark Gaiser]

Hi,

Take this simple example:

  QHash test = {
{10, "aaa"},
{20, "bbb"},
{30, "ccc"}
  };

  for (const auto : qAsConst(test)) {
qDebug() << entry;
  }

It returns:
"aaa"
"ccc"
"bbb"

and the std::unordered_map version:
  std::unordered_map test = {
{10, "aaa"},
{20, "bbb"},
{30, "ccc"}
  };

  for (const auto : test) {
qDebug() << entry;
  }

it returns:
std::pair(30,"ccc")
std::pair(10,"aaa")
std::pair(20,"bbb")

As you can see, the QHash iteration directly returns the value. The
std::unordered_map returns a std::par with the key and value for the
current iteration (in it's respective first and second members). Both
approaches probably have arguments in favor and against. What i'm
curious about is why there is a difference at all?

I'm curious because the behavior is a bit unexpected when compared to
std::unordered_map. I would have guessed QHash to follow the same
logic as std::unordered_map, only with a Qt syntax. So for instance a
return of QPair(...), not the value directly.

Thanks,
Mark
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QList

[Mark Gaiser]

On Sat, Mar 18, 2017 at 10:51 AM, Marc Mutz  wrote:
> On Saturday 18 March 2017 09:06:09 Ville Voutilainen wrote:
>> There's been a fair amount of talk about QList's future, so I'm curious:
>>
>> 1) What are the problems with QList?
>
> See Konstantin's reply. For me, the performance issue is pretty strong
> already, but that stability of references into QLists may depend on such
> subtleties as the machine's word size or whether Q_DECLARE_TYPEINFO has been
> called for the type is also a big correctness issue.
>
>> 2) What do we plan to do about those problems?
>
> Kill QList in Qt 6.
>
>> 3) How do we expect to migrate code that uses it?
>
> Possibly provide a QArrayList that _always_ uses the heap, and thus _always_
> provides stability of references. There's some code that actually depends on
> stability of references (QToolBox, e.g.).
>
> Try to minimize use in new code. That hasn't worked out as planned. Look at
> the dates of my two contributions Konstantin linked to, then look at the API
> reviews for 5.9. It's almost guarateed that Q_DECLARE_TYPEINFO (or the similar
> Q_DECLARE_SHARED) have been "forgotten". Review regularly fails for such
> things.
>
> This experience, over several years, has thaught me that we need a technical
> solution. And so we started to specialize QList as an empty class.
> So far, this is the only workable solution I have found, and believe me, I am
> very determined.
>
> I think we should do this for all new (non-polymorphic) classes.
>
> And since we now depend on enough C++11, replacing QList with QVector in
> generic code is trivial: either use auto, or when you can't, use
> QListOrVector, introduced here: https://codereview.qt-project.org/188858
>
> So, here's my proposal for a QList exit strategy:
>
> In Qt 5:
>
> 1. Replace QList in generic code by QListOrVector, tell users to hold QLists
>they get from Qt API only in type-deduced variables.
> 2. Fix any QList API missing (and not actively harmful) on QVector. E.g. I
>don't think toSet() should be either on QList nor QVector, because it
>creates nonsense like qHash(QItemSelectionRange) (please, please, look it
>up :)
> 3. Disable QList for all new QFoo value types (by specializing QList as
>an empty class).
> 4. Provide QArrayList for code that needs stability of references (stability
>statically checked in Qt 5, enforced in Qt 6).
>
> In Qt 6:
>
> 5. Replace all QList uses left with ... what ? QVector? std::vector?
>-> separate discussion
> 6. Kill QList or keep it as a deprecated class.
>
> Thanks,
> Marc

Hi Marc,

I'm fine with replacing QList usages with QVector in codebases i
maintain, but even with the latest Qt version, that isn't always
possible or convenient.
For instance, at this very moment i want a QVector with all keys from
a given map (QMap) but Qt itself doesn't provide a
direct way of doing that.

The keys method on the map returns a QList.
QList has a "toVector" method which gives me the QVector i want.

It works, yes. But it's really indirect.

The key kinda has to be unique in a map (and hash) so it would be
perfectly fine for it to be a QVector, but it isn't.
Is there a technical reason for it or is it just because of Qt's history?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Branch request: wip/itemviews in qtdeclarative

[Mark Gaiser]

On Sat, Jan 14, 2017 at 5:06 PM, J-P Nurmi  wrote:

> Hi,
>
> Nice, looks great! It would be a very welcome contribution. We could
> polish and add the missing bits in the WIP branch if you’re interested? I
> haven’t thought about the exact details and requirements for
> SortFilterProxyModel yet, but we probably need to support multiple model
> columns. The plan is to make the new TableView support both, “proper” table
> models with multiple columns, and the old way of (ab)using roles as
> columns. :)
>
>
That new TableView is really going to support models that derive
QAbstractTableModel? Without any changes required on the model side? So if
it works in QTableView (C++ widget) then it will work in the new TableView
(QML component)?
That would be a big win!

Would the view also have transition support?
The current TableView [1] component doesn't have it, the GridView [2]
component does, but it basically only eats list models and requires role
foo..

Do you plan the new TableView to be a styled component (like one of the
many other control components) or a bare component where the user needs to
define the delegates for the contents, header and sidebar?
My preference would be a bare component.

Lots of questions ;)

[1] http://doc.qt.io/qt-5/qml-qtquick-controls-tableview.html
[2] http://doc.qt.io/qt-5/qml-qtquick-gridview.html


> --
> J-P Nurmi
>
> On 14 Jan 2017, at 14:06, Pierre-Yves Siret  wrote:
>
> Hi,
> I started implementing SortFilterProxyModel cause we needed it and
> published it here : https://github.com/oKcerG/SortFilterProxyModel
> For the moment it is not really documented or tested enough.
> I left it kinda alone for the past couple months but I plan to do more
> work on it, documenting, testing, adding some features and doing some
> refactoring.
> I also wanted to nominate it as a TP for 5.10.
> I guess it needs to be reworked before a potential inclusion in Qt (pimpl,
> using private headers from QAIM and ItemViews, etc.).
>
> I think what's interesting in my library is the ability to have multiple
> filters and sorters declaratively (as shown in the 2nd more advanced
> usecase of the readme), I also have a branch that I haven't pushed yet
> where you could define new roles defined from existing source roles.
>
> Where you thinking of that for the SortFilterProxyModel you wanted ?
>
> One of the shortcoming of my SFPM is that it is not really meant to be
> used for multiple columns, only roles, and it doesn't support tree models.
>
> Pierre-Yves Siret
>
> 2017-01-14 13:37 GMT+01:00 J-P Nurmi :
>
>> Hi,
>>
>> I'd like to request a WIP branch for the Qt Quick item views. There are
>> plenty of items on the roadmap/wishlist:
>>
>> - refactor QQuickItemView
>>   - add support for multiple delegate types (QTBUG-26681)
>>   - add support for multi-selection
>>   - add support for multiple columns
>> - implement TableView (QTBUG-51710)
>> - implement HeaderView
>> - implement SortFilterProxyModel
>> - productize TreeModelAdaptor (QTBUG-54390)
>>
>> Early feedback from the CI system would be invaluable.
>>
>> --
>> J-P Nurmi
>>
>>
>> ___
>> 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
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Use of Standard Library containers in Qt source code

[Mark Gaiser]

On Fri, Jul 1, 2016 at 8:36 PM, Thiago Macieira 
wrote:

> Premises not under discussion:
>
> Qt source code is product and meant to be read by our users
> Qt source code must be clean and readable
>
> The above is not up for debate.
>
> For some time now, we've had a flurry of changes to Qt source code that
> uses
> the Standard Library's containers and algorithms, in the name of
> performance
> and often code size gains.
>
> I'm not disputing that there is a gain. But I am wondering about the
> trade-off
> we're making with regards to readability. For example, I was just reviewing
> this code:
>
> if (d->currentReadChannel >= d->readHeaders.size()
> || d->readHeaders[d->currentReadChannel].empty()) {
> Q_ASSERT(d->buffer.isEmpty());
>
> The use of the Standard Library member "empty" is highly confusing at first
> sight because it does not follow the Qt naming guidelines. It's even more
> confusing because the next line has "isEmpty". When I read this code, I
> had to
> wonder if that "empty" was a verb in the imperative, meaning the author was
> trying to remove all elements from the container.
>
> I had to look up the definition of readHeaders in the review and note that
> it
> was a std::deque, not a Qt container.
>
> What do we do?
>
> Option 1:
> Not use Standard Library containers, just use the Qt containers as they
> exist.
>
> Option 2:
> Create new Qt containers to have the same complexity as Standard Library
> containers, but following the Qt naming conventions. Possibly with implicit
> sharing.
>
> Option 3:
> Create Qt API wrappers for those containers like std::deque, adding only a
> few
> inline functions to match the Qt-style API where the Standard Library API
> deviates. Examples are:
> empty   ->  isEmpty
> push_back   ->  append
> front   ->  first
> pop_front   ->  takeFirst
> cbegin  ->  constBegin
> cfind   ->  constFind
>
> I don't get why you would be confused by - for instance - the empty method.
STL has that method, but so does Qt [1] apparently in an attempt to be
compatible with the STL API.

Even if you don't want to learn or know how the STL API looks like, it
should not matter since the very same members also apply on Qt containers
with the same .
This is the case for all your examples in Option 3.

Imho it would be nice - when using Qt and STL containers in the same
statement - to use common functions that mean the same in both API's. Thus
in your example both should have been empty() calls, even on the Qt
container to be consistent. But that's just my opinion :)

[1] http://doc.qt.io/qt-5/qlist.html#empty
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] commas in ctor-init-lists

[Mark Gaiser]

On Wed, Jun 1, 2016 at 2:41 PM, Marc Mutz  wrote:

> Hi,
>
> There seems to have been a silent underground move to uglify the Qt sources
> , by using commas to introduce lines
> . I have no idea where this came from
> , but it looks butt
> -ugly and it is in violation of http
> ://wiki
> .qt
> .io
> /Qt_Coding_Style
>
> QFoo::QFoo()
>   : QBase(),
> m_f1(),
> m_f2()
> {
>
> }
>
> -not-
>
> QFoo::QFoo()
>   : QBase()
>   , m_f1()
>   , m_f2()
> {
>
> }
>
> (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the
> _end_ of wrapped lines")
>
> Thanks,
> Marc
>
>
The "butt-ugly" style looks more readable to me.
And imho it reduces the possibility of forgetting a forgetting a comma in
the begin since then your arguments will look out of alignment.

Funny in the coding style you mention. For operators: "An operator at the
end of the line is easy to miss if the editor is too narrow." The exact
same could be said for commas at the end of the line.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QVariant performance

[Mark Gaiser]

Hi,

Just a fyi since the article might be of interest to some on this list.
I just stumbled upon this github project [1].
The article and rationale for that project can be found here [2].

It claims to be a stack based "variant" implementation made for performance
and as little overhead as possible. Perhaps the code has some nice tricks
that could be used to make QVariant faster? QVariant in those benchmarks,
as seen in [1], seems to be the slowest when compared to std::any,
boost::any and his own variant.

[1] https://github.com/david-grs/static_any
[2] http://david-grs.github.io/low_latency_stack_based_boost_any/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Security bulletin: Deprecating QRect

[Mark Gaiser]

On Fri, Apr 1, 2016 at 10:58 AM, Friedemann Kleint <
friedemann.kle...@theqtcompany.com> wrote:

> Hi,
>
> as discussed in the thread "Re: [Development] Fixing QRect::width() /
> height()", QRect can be misused to trigger undefined behaviour. This
> pattern has been observed in recent ransomware attacks using the new High
> DPI feature in Qt 5.6 to place windows at bottom right positions on High
> DPI screens inducing undefined behaviour. To fix this, the class QRect will
> be deprecated as of now in a patch release 5.6.0.1. The maintainers are
> kindly asked for a quick review of
> https://codereview.qt-project.org/154371 and the release team to prepare
> the patch release.
>
> Regards,
> Friedemann
>
> --
> Friedemann Kleint The Qt Company
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

hehe, you nearly had me there.
April fools ;)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] About qfilesystemwatcher: what events?

[Mark Gaiser]

On Mon, Nov 30, 2015 at 11:07 AM, Stef Bon  wrote:

> Hi,
>
> I'm looking at qfilesystemwatcher.
> It's not possible to configure what events it watches. For example:
>
> when watching a directory and an event happens on an entry in this
> directory: it's changed.
> The size for example is changed. qfilesystemwatcher doe not give this
> information: it only signals that the "something" has been changed in
> the directory.
>
> This means that you have to scan through the directory and compare
> each file one by one.
> FS Watches to watch a whole directory are used a lot, but it should
> give more information about the event (name of entry, and a mask,
> simular to inotify).
>
> Is this planned?
>
> Stef
>
>
Hi Stef,

What you describe is planned by me for the inotify backend (linux), but
that's on my schedule for at least a year now so don't bet on that ending
up in Qt anytime soon.
Even if i make it, the other backends (Mac, Windows and the other supported
Qt platforms) have to be adjusted accordingly as well and i don't even know
if those backeds support the "flexibility" of inotify.

If you (or anyone else) can offer help, it would be much appreciated.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Enhancement to QIODevice?

[Mark Gaiser]

On Wed, Sep 16, 2015 at 1:13 PM, Andrzej Ostruszka <
andrzej.ostrus...@gmail.com> wrote:

> On 09/16/2015 08:57 AM, Thiago Macieira wrote:
> >>> You could use peek() to search the buffer, then read() exactly as much
> as
> >>> you really need.
> >>
> >> I understand that we are talking about
> >> QIODevicePrivateLinearBuffer::peek() here.
> >
> > No, I meant QIODevice::peek()
>
> First of all - I do not claim that I have mastered Qt internals!
> So everything below you should take with a grain of salt :)
>
> QIODevice::peek() is implemented in terms of QIODevice::read() (which
> then uses QIODevicePrivate::read() which does the memcpy()) and later
> putting it back.  Pretty convoluted but it really does not matter - I
> just assumed the simpler case of direct peek into the buffer.
>
> >> In your approach I'd be copying data twice, but I can eliminate one with
> >> peek()ing
> >> directly to the output buffer and later skip()ping in successful case.
> >> However in case
> >> when delimiter is not yet available I'd have unnecessary copying.
> >
> > Then please provide a patch that avoids the unnecessary second copy when
> the
> > read() destination is a null pointer.
>
> Here I must say that I don't understand.  Let me rephrase what I've said
> earlier.  Suppose that there is some data in buffer and I want to know
> if delimiter is in it.  Without direct access to this buffer memory I
> can only:
> 1. copy (by peeking()) it to some other place (possibly the final output
> buffer)
> 2. search for delimiter in my copy
> 3. if found: drop "number of bytes to delimiter" from buffer
>
> What I'm saying is that in successful case (when delimiter is found)
> this sequence is optimal.  However, in case when there is no delimiter
> yet in the buffer, operation 1 is wasted (not really needed).  And I
> don't see how to avoid it without allowing user to search in the
> internal buffer.
>
> Possible ways to allow for searching in this buffer are (I'm shortening
> names here):
> A. Add optional param to canReadLine() readLine() (for QIODP or maybe
> even QIOD)
> B. Add this QIODPLB::countTo() functionality (which does not break or
> interfere with anything)
> C. Add QIODPLB::data() function to buffer which will return "first" (I'm
> talking in terms of QIODPLB implementation)
> D. ???
>
> As for C.  This is another solution - which also does not interfere with
> anything.  The amount of data is already available via size().
> Then any kind of "packet" termination can be implemented (not just by
> single char) on top of it.  Value returned by this QIODPLB::data() is
> only invalidated by explicit user reading so this would be pretty safe
> too and its only one line of code.
>
> So what do you think?
>
> >> And while peek()ing I'd have to use the min(max size of my output
> >> buffer, size())
> >> which would mean that I'd be copying "overlapping" parts more than once.
> >
> > I didn't understand this.
>
> What I wanted to say is that:
> - in operation 1 above the number of bytes to peek need to be specified
> - the only reasonable choice - without using some application specific
> heuristic - is the amount of bytes already available (lets forget for a
> moment possible constrains of my output buffer size)
>
> Then in situation when in buffer is more then just one "line" available
> I would be copying parts of data after first delimiter in order to later
> put them back and read them again on next data arrival.
>
> > I think there are easier ways to do this, so I don't think it makes
> sense to
> > accept this suggestion.
>
> Yes one can peek() at buffer but as I've tried to state this approach
> has some drawbacks (from performance point of view).  I can also
> understand that maintainers are worried about growing complexity and
> maintenance burden but honestly I don't see any growth in these from
> options B and C above.  These are internal, no testing for them is
> needed, they don't interfere with any other functionality etc.
>
> So Your Honour, what is the verdict? ;)
>
> Regards
> Andrzej
>

I'm curious, why is QIODevicePrivate::peek (both versions of it) doing:
- calling read (which resizes the internal buffer to whatever is left after
reading). It does this via memmove.
- then it restores the buffer to it's original by taking the current buffer
and appending what was read. It does this via memcpy.

Rather then doing:
- call QIODevicePrivateLinearBuffer::peek (on the buffer object in
QIODevicePrivate) and leave the internal buffer untouched? The function is
just sitting there [1], but it isn't being used by either
QIODevice(Private)::peek function.

It would avoid fiddling with the internal buffer and just copy (a part of)
the internal buffer to the user. That is what peek should do according to
the documentation.
Peek would the not call QIODevice::read anymore.

Performance wise, this likely makes peek faster (no more read call, no more
memmove, no more memcpy on the internal buffer), memory wise there still is

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Mark Gaiser]

On Fri, Jul 17, 2015 at 12:07 PM, André Somers an...@familiesomers.nl
wrote:

 Marc Mutz schreef op 17-7-2015 om 12:21:
 
  What might also be a consideration when making a container like this, is
  that I find the key is often (not always of course) already part of the
  value data structure. For instance, if I store employee records and key
  them by id, that id is also in the record itself. It would be nice to
  have a fast and friendly key-based container that could handle that
  without duplicating the data...
  You can have that with C++11 std::*set, and a custom transparent
 comparator,
  but of course, they are not cache-friendly. But it's testament to the
 value of
  having the ability to _have_ a custom comparator. QFashHash consequently
 has
  that ability, but its a map, not a set, so it won't fit your use-case.
 
 I guess this [1] would work, but that is C++14, not 11. Otherwise, I
 don't quite see how to retreive my Employee record again if I just have
 the id...

 André

 [1] http://en.cppreference.com/w/cpp/container/set/find variants 3 and 4


You can use std::find_if for that on any container.
Works for C++11 and even before that. C++11 gives the benefit of using a
lambda in the std::find_if UnaryPredicate.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Container benchmark was HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Mark Gaiser]

On Fri, Jul 17, 2015 at 2:13 PM, André Somers an...@familiesomers.nl
wrote:

 Mark Gaiser schreef op 17-7-2015 om 13:44:
 
  You can use std::find_if for that on any container.
  Works for C++11 and even before that. C++11 gives the benefit of using
  a lambda in the std::find_if UnaryPredicate.
 Sure, but wouldn't that revert you back to a linear search? That sounds
 like getting the worst of both worlds: using a complicated red/black
 tree data structure and then iterating over it lineary to find an item
 that I could have found using the structure itself in logarithmic
 time... Or am I overlooking some very clever specialization in the
 find_if algorithm then?

 André


Yes, that would give you linear search indeed.
Guess you have to use that C++14 function then :)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New Qt 4.8.7 snapshot build is available

[Mark Gaiser]

Does this qualify as a release blocker?
https://bugreports.qt.io/browse/QTBUG-45100

Would be a shame if it missed the 4.8.7 release imho.

On Mon, Feb 16, 2015 at 12:01 PM, Salovaara Akseli 
akseli.salova...@theqtcompany.com wrote:

  Hi,



 New Qt 4.8.7 snapshot build is available
 http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-02-16-4/

 Snapshot is built against sha1 2b7758a8763a8fe6ca13a2f04e0137df79c849d2
 Don't leak RENDER Pictures in QPixmap::paintEngine() (current HEAD).



 Changes compared to previous snapshot:
 http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-02-16-4/4.8.7-snapshot-2015-02-16-4-changes

 Changes compared to Qt 4.8.6:
 http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-02-16-4/4.8.7-snapshot-2015-02-16-4-all-changes



 Please test these snapshots, report possible regressions to
 bugreports.qt.io and send email about that (with bug id) to
 releas...@qt-project.org.



 Br,

 Akseli

 --

 Akseli Salovaara

 The Qt Company



 ___
 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] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

[Mark Gaiser]

On Fri, Feb 20, 2015 at 2:26 AM, Thiago Macieira thiago.macie...@intel.com
wrote:

 On Friday 20 February 2015 00:17:00 Mathias Hasselmann wrote:
  Use std::cref() if not sure about your container's constness.
 
   for (auto const item : std::cref(c)) { ... }

 Do NOT do this. This will crash:

 for (auto const item : std::cref(somefunction()) { ... }

 See my other email for an explanation.

 And another reason is that std::cref is a C++11 Standard Library addition
 and
 we cannot depend on that yet.


Disclaimer: i don't know a thing about the C++ committee and how they
handle papers. What follows might be completely irrelevant if the paper was
rejected. Do you know if it is?

I've read about this range-based-for stuff before and there was this paper
[1] that apparently wants to introduce the next generation of it. It would
introduce the syntax (WITHOUT auto!):
for (elem : range)

Which would be exactly the same as:
for (auto elem : range)

Now i wonder, even if that paper is accepted, would it solve the issue for
the Qt containers when that syntax would be used on them?

[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3853.htm
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Mime database size

[Mark Gaiser]

On Tue, Feb 17, 2015 at 12:17 PM, Arnaud Vrac raw...@gmail.com wrote:

 On Tue, Feb 17, 2015 at 12:13 PM, Иван Комиссаров abba...@gmail.com
 wrote:

 Hello, Arnaud Vrac. What tool should should generate binary cache on Mac
 OS/Windows?


 I think the update-mime-database binary can also be compiled for Windows
 and Mac, but it unfortunately depends on glib and libxml.

 Here is the source for update-mime-database:


 http://cgit.freedesktop.org/xdg/shared-mime-info/tree/update-mime-database.c

 Glib and libxml also compile under windows.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Why can't QString use UTF-8 internally?

[Mark Gaiser]

On Wed, Feb 11, 2015 at 12:33 AM, Thiago Macieira thiago.macie...@intel.com
 wrote:

 On Tuesday 10 February 2015 23:17:21 Allan Sandfeld Jensen wrote:
  Maybe with C++11 we don't need QString that much anymore. Use std::string
  with UTF8 and std::u32string for UCS4.
 
  For Qt6 it would be worth considering how many of our classes still makes
  sense. Those we want CoW semantics on would make sense, but if we don't
  really want that on strings, maybe every framework having its own string
  class is finally obsolete in C++?

 Eh... have you tried to convert a UTF-8 or UTF-16 or UCS-4 string to the
 locale's narrow character set without using QString?

 Have you tried to convert a number to string? You need C++14 to do that
 reasonably, since std::to_string didn't exist in C++11. How about the
 reverse?
 The only way to do that is sscanf or std::istringstream.


What do you mean with C++14? According to cppreference [1] C++11 allows
this just fine.
[1] http://en.cppreference.com/w/cpp/string/basic_string/to_string


 Have you tried to uppercase or lowercase a string using only the Standard
 Library?


std::string s(hello);
std::transform(s.begin(), s.end(), s.begin(), ::toupper);

and
std::transform(s.begin(), s.end(), s.begin(), ::tolower);

Not sure about the performance though :)


 We may want to have this discussion for QVector vs std::vector. For QString
 and QByteArray, there's no discussion: they stay, period.

 --
 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] New Qt 4.8.7 snapshot build is available

[Mark Gaiser]

On Wed, Jan 14, 2015 at 12:34 PM, Salovaara Akseli 
akseli.salova...@theqtcompany.com wrote:

 Hi,

 4.8.7-snapshot-2015-01-12-2-all-changes file uploaded next to installers
 (
 http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-01-12-2/4.8.7-snapshot-2015-01-12-2-all-changes
 ) to substitute actual change log file inside packages.
 4.8.7-snapshot-2015-01-12-2-changes file published yesterday describes
 delta to previous snapshot.

 Similar changes files will be uploaded for the next snapshots.
 Change log file inside packages will be updated closer to actual release.

 Br,
 Akseli

  -Original Message-
  From: development-bounces+akseli.salovaara=theqtcompany.com@qt-
  project.org [mailto:development-
  bounces+akseli.salovaara=theqtcompany@qt-project.org] On Behalf Of
  Calogero Mauceri
  Sent: 13. tammikuuta 2015 17:09
  To: development@qt-project.org
  Subject: Re: [Development] New Qt 4.8.7 snapshot build is available
 
  Hi,
 
  would it be possible to have a full changelog for this snapshot. The
  changelog file inside the pachage is empty.
 
  Thanks,
   Calogero
 
  Il 1/13/2015 4:04 PM, Salovaara Akseli ha scritto:
   Hi,
  
   New Qt 4.8.7 snapshot build is available
  http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-01-12-2/
   Snapshot is built against 50223ce5eebfdff01a88474f0589259137997458
  Introduce Windows version 10.
  
   Changes compared to previous build:
  50223ce5eebfdff01a88474f0589259137997458 Introduce Windows version
  10.
  6f55f3dbbb2cdae33a8b0d00b7bf2ada7fe79a04 Fix empty arrays in QML 1
  18c5ff04103eadcb532d03d526714385943295ab Windows: Fix OS version
  determination for Windows = 8
  8d831f5f444802879ae416bd110184d5a6cf1b26 QDateTime: Fix time format
  in doc
  48194c74d3e2d2316fa4c57cf8b2e6687d8d6416 Fix compilation with
  QDND_DEBUG.
  6f83ee60cf616731fb37d7a4357fc264fc167b2e Add Hebrew translation for
  Qt Linguist
  25d972e12eda9dadf212d24af8d8f524572bdbfa Check world matrix is true
  when seeing if transformations are supported
  62323e8d1b16167662c85e412d35804418593cc6 QIdentityProxyModel:
  remove slow bounds-checking, for more performance
  87b82fb345a3384243da50240dab93589d072d7e Autotest: Setting
  tst_qaudiooutput and tst_qsound as insignificant
  
   Please test these snapshots, report possible regressions to
 bugreports.qt.io
  and send email about that (with bug id) to releas...@qt-project.org.
  
   Br,
   Akseli
   --
   Akseli Salovaara
   The Qt Company
  
   ___
   Development mailing list
   Development@qt-project.org
   http://lists.qt-project.org/mailman/listinfo/development
 
  --
  Calogero Mauceri
  Software Engineer
 
  Applied Coherent Technology Corporation (ACT)
  www.actgate.com
 
 
  ___
  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


Hi,

I've just hit this bug: https://bugreports.qt.io/browse/QTBUG-13776 in Qt
4.8.x which is fixed in 5.0 via this patch:
https://codereview.qt-project.org/#/c/41984/
Could that patch be backported to 4.8.7?

My work environment requires 4.8.x. I've hit this issue when porting the
work project from vcxproj to pro files (which would then be used to
generate vcxproj files).
The generated vcxproj files work just fine, but manually running nmake
debug (or install) makes this issue pop up.

Best regards,
Mark
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QTBUG-39477 - Enable QWidget based classes to be used in QML files

[Mark Gaiser]

On Sat, Jan 17, 2015 at 4:49 PM, Fanda Vacek fanda.va...@gmail.com wrote:

 Hi,

 please, is there anybody with +2 who can make review for patch on this
 bug (https://bugreports.qt.io/browse/QTBUG-39477)?

 It is marked as CRITICAL since 5.2 and patch is prepared for review. We
 have 5.4.1 now and the bug is still here.

 The bug is really blocker for my project
 (https://github.com/fvacek/quickbox), so please, can somebody help me?

 Best Regards

 Fanda

 I don't even get why a P1 bug isn't blocking the release in the first
place. P1 bugs are supposed to be release blockers, right?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Adding new third party component three.js to Qt?

[Mark Gaiser]

On Fri, Jan 9, 2015 at 3:39 PM, Keränen Pasi pasi.kera...@theqtcompany.com
wrote:

 Hi Louai,

 The changes required to the library were originally quite large. But
 thanks to the bug fixes in V4VM, maturing of Canvas3D and writing of some
 wrapper classes to make e.g. Image loading look and smell like in HTML
 land, the delta has been getting smaller and smaller. Here is a pretty
 complete list based on quick compare between the R69 original three.js and
 the Canvas3D port of the R69 release of three.js. There might be something
 I’m forgetting to mention here. But as I said the delta has been getting
 smaller and should get even smaller in Qt 5.5 and 5.6. But there will be
 some delta always as QtQuick is not HTML.

 * We don’t have performance timers in Qt Quick JS, so the Clock class must
 be modified to not use those.

 * In some files the class is declared with syntax of ( function (THREE) {
 blahblabh }( THREE ) ); that V4VM seems to dislike and in some cases self
 executing functions don’t seem to work, V4VM just refuses to load the
 file. I haven’t been able to replicate this behaviour with a small
 example, so probably it’s relates to some complex situation arising when
 loading a large JavaScript file OR then there is some minute detail in
 that self executing function that I can’t spot.

 * Resizing of images has to be modified as that is usually done with HTML
 trickery that doesn’t work at the moment with Canvas3D.

 * Accessor functions defined in prototypes with:
 get x() { return this._x },
 set x(value)  { this._x = value; this.onChangeCallback(); }

 * Must be rewritten with the (older?) syntax of:
 this.__defineGetter__(x, function(){return this._x;});
 this.__defineSetter__(x, function(value){this._x =
 value;this.onChangeCallback();});

 * Canvas3DRenderer is new code, ported from WebGL. Main differences are to
 do with initialization differences between Canvas3D and WebGL. Handling of
 some Canvas3D Tech Preview quirks like the handling of TypedArray wrappers
 (should be ok to remove in 5.5 when we have proper V4VM TypedArrays in
 place and function overloading should work). And I’ve wanted to support
 the logging features of Canvas3D objects, by setting the .name attribute
 of some objects so that when you turn on logging you can see what
 UniformAttribute, what Shader3D object you are looking at in the logs..
 Plus a couple of workarounds for weird behavior (e.g. boolean as attribute
 name in the renderer causes V4VM not to load the file, but again a minimal
 example of this doesn’t have this problem so can’t replicate it). Again,
 the delta should get smaller with WebGLRenderer, but I’d expect there to
 always be some delta.

 That is all the delta I can list quickly, if you are interested in details
 just get the R69 release from three.js git and the stable branch of
 QtCanvas3D port and do a detailed compare of those.

 Reagrding this delta I’ve thought a bit how to reorganise the delta so
 that it could live in a separate folder inside three.js. If I can make
 that happen, then maybe it would be possible to get these few changes in
 to three.js upstream and make it possible to always use the latest from
 there as well if one so wishes. But that will require a bit more work on
 V4VM I think before we’re there. E.g. Add support for binary file loading
 with XMLHttpRequest and track down why those few anomalies occur when
 loading self executing functions declared in the manner they are in
 three.js so that the upstream code should run as much as possible
 unmodified on top of Canvas3D with just the few changes we need in place.

 Regards,
 Pasi



 On 08/01/15 12:54, Al-Khanji Louai louai.al-kha...@theqtcompany.com
 wrote:

  On Wednesday 7. January 2015 06.03.14 Keränen Pasi wrote:
   Hi,
  
   I¹d like to open the discussion on including the three library as
 part of
   Qt 5.6 and onwards. Mainly because this would give our users a better
   experience if we¹d bundle the right, tested version of Three.js
 together
   with the Qt version it was tested on.
  
   I¹ve been pushing the Qt Canvas3D component onwards and timewise it
  should
   be landing to Qt 5.5 release. The WebGL-like API (non-conformance
 tested)
   it offers is very low level and most users will not like to work on
 that
   level. To that end I¹ve ported the WebGL based Three.js scenegraph
 library
   available at http://threejs.org on top of Canvas3D. You can find the
   latest version from master branch at
 https://github.com/tronlec/three.js
  
   The reason for picking this particular library over others are:
   * It¹s one of the most active WebGL scene graph projects out there.
   * It¹s well done, with examples, API documentation etc.
   * It has excellent support form community in the form of tutorials,
   websites, discussion forums etc.
   * It is available under permissive MIT license:
   https://github.com/mrdoob/three.js/blob/master/LICENSE
  
   In Qt 5.5 we¹ll include a few examples that will 

Re: [Development] qt.io download-open-source page updated

[Mark Gaiser]

On Tue, Oct 7, 2014 at 9:13 AM, Anttila Janne
janne.antt...@theqtcompany.com wrote:
 Hi,

 Thanks for your feedback related to qt.io opensource downloads page:
 http://www.qt.io/download-open-source/

 The page is now updated based on your comments - the major changes are:
 1. Automatic download is now completely removed
 * Recommended download is still highlighted and you can start download with
 button click
 2. All downloads from http://qt-project.org/downloads page have been added
 to new page
 * No need to jump between sites anymore

 In addition some other smaller changes were implemented. We have some visual
 Improvements in backlog, but those want change functionality or content of
 the page.

 Does the page fulfil purpose  your needs now? If you have any comments,
 please use Help is improve button on right hand side of the page.

 Br,
 --
 Janne Anttila

Some more feedback.

1. The download to the community version of Qt from
http://www.qt.io/download/ links to http://www.qt.io/?p=323 which
redirects to http://www.qt.io/download-open-source/ .. A bit weird.
2. Again on http://www.qt.io/download/ the Download button for
community is grey. So it lookslike the button is disabled which it
isn't. Just make it green like the other download buttons.
3. Different tick marks are used. http://www.qt.io/support/ and
http://www.qt.io/download/

Cheers,
Mark
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Requesting removal of qtjsondb

[Mark Gaiser]

On Wed, Sep 17, 2014 at 11:05 AM, Joerg Bornemann
joerg.bornem...@digia.com wrote:
 The qtjsondb module is dead. It doesn't build since ages and has zero
 users. As civilized people we should bury our dead.
 Therefore I'd like to request the removal of qtjsondb from Qt's mother
 repository.

 Please raise any objections here or on codereview:
 https://codereview.qt-project.org/#/c/95086/

It was one of the modules i was looking forward to while Qt 5.0 was in
development. It seemed to be quite promising at the time.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Requesting removal of qtjsondb

[Mark Gaiser]

On Wed, Sep 17, 2014 at 11:18 AM, Joerg Bornemann
joerg.bornem...@digia.com wrote:
 On 17-Sep-14 11:13, Mark Gaiser wrote:

 It was one of the modules i was looking forward to while Qt 5.0 was in
 development. It seemed to be quite promising at the time.


 The alternative to removal is fixing. Are you stepping up? :)

No :)

I don't even know if i would use it. It just seemed promising.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] www.qt.io/download-open-source is broken

[Mark Gaiser]

On Wed, Sep 17, 2014 at 9:37 PM, Kuba Ober k...@mareimbrium.org wrote:
 I’d like to personally scold whoever came up with the idea of starting the 
 “default” download at www.qt.io/download-open-source. I, for one, never 
 download the default installer since it was always subtly broken in one 
 fashion or another, I always build from source. So now, the genius 
 responsible for this is also responsible for wasting tons of bandwidth for 
 useless downloads, and for wasting 20MB *repeatedly* off of my 1GB monthly 
 mobile plan. Thank you very much (NOT).

 So much for the usability of the new site, and for wishing to explore it from 
 a phone. The person responsible should be scolded until it sinks in. I’m not 
 kidding. This is form over substance at its finest. I like modern designs, 
 but they must be actually usable. qt.io right now is like a very well 
 manicured pig (with apologies to bacon).

Why so hostile?
Please try to give constructive feedback to those making the site.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] New company name for Qt part of Digia and unified web site

[Mark Gaiser]

On Tue, Sep 16, 2014 at 2:11 PM, Knoll Lars lars.kn...@digia.com wrote:
 Hi everybody,

 I’m happy to tell you that we’re making significant progress towards the
 new unified web page that I’ve first been talking about at the contributor
 summit. We just launched the first stage of it on http://qt.io. For now
 qt.digia.com is going to redirect to it. I hope you will like the new web
 page. Please have a look and give us your feedback.

 In addition, we also now have a new company name for the Qt part of Digia.
 It’s simply ‘The Qt Company’.

 For more details check out my blog at
 http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unifie
 d-website-and-20e25-monthly-indie-mobile-package/ and of course
 http://qt.io

 Moving forward, we would like to slowly move some more pieces that are now
 on qt-project.org over to qt.io. We don’t have concrete plans yet on when
 and what will move, but would probably want to start with simple things
 such as the documentation. Any feedback on this is of course also more
 than welcome.

 Cheers,
 Lars

 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

I like the site! It looks clear and to the point imho.

But i kinda fail to see the point in having - yet another - domain for Qt.
I mean, we've had:
- Trolltech
- qt.nokia...
- qt.digia...
- qt-project
and now we have qt.io. Yes, it's a nice short domain, but having
domain changes every few years or so isn't very good for the search
results.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Qt 5.4 feature freeze - is frozen now

[Mark Gaiser]

On Sat, Aug 9, 2014 at 10:39 PM, Hausmann Simon
simon.hausm...@digia.com wrote:
 Hi,

 I sincerely hope that the class name will be reconsidered, given how generic 
 and therefore ambiguous the term volume is. Please consider making it more 
 specific by adding Storage or something else to the name and avoid that 
 people guess wrongly and avoid people finding this class when they search for 
 the audio volume api elsewhere in Qt. Pretty please with a cherry :)

First thing i though when seeing the QVolumeInfo name was:
Oh cool, so this abstracts the _sound_ volume information between
windows/mac/linux.
Which it's not.

The first thing one associates volume with is sound, not mounted
volumes hence the current name is ambiguous.

QStorageInfo would be a much better fit imho.


 Simon

   Opprinnelig melding
 Fra: Иван Комиссаров
 Sendt: 11:24 lørdag 9. august 2014
 Til: Buddenhagen Oswald
 Kopi: development@qt-project.org; releas...@qt-project.org
 Emne: Re: [Development] HEADS UP: Qt 5.4 feature freeze - is frozen now


 Thank you for notification. Please, re-rarget QVolumeInfo to 5.4 branch 
 (https://codereview.qt-project.org/#/c/73945/78).
 And review patchset 78, someone:)

 Иван Комиссаров

 09 авг. 2014 г., в 12:16, Iikka Eklund (via Oswald Buddenhagen) 
 oswald.buddenha...@digia.com написал(а):

 Hi,

 the ‘dev’ branch is now temporarily closed. From now on, all changes
 targeted to Qt5.4.0 need to be pushed to ‘5.4’ branch (once available).

 Note that Ossi will continue re-staging changes on dev that fail to
 integrate for no fault of their own, until some reasonable deadline.

 We will inform you when the ‘5.4’ branch is available and when ‘dev’
 branch is opened for changes for Qt5.5.0.

 Changes intended for 5.4 which were already pushed for dev can be
 re-targeted server-side by administrative action without abandoning and
 re-pushing. Drop Ossi a line.

 Fixes for 5.3, especially those already uploaded, should NOT be
 re-targeted to 5.4 - 5.3 will be merged to 5.4 for weeks to come.

 -- Iikka
 -- (edited  sent by Ossi)

 On 07/29/2014 11:20 AM, Heikkinen Jani wrote:
 Hi,

 Please remember: Qt 5.4 feature freeze is Friday 8th August 2014 12:00
 CET. It means:

 -‘Dev’ branch will be temporarily locked 8th August 2014 12:00 CET

 oAfter that time any changes that are required for Qt 5.4.0 needs to be
 pushed to the '5.4' branch. So if your changes are not in by that time,
 please wait until the branching is done and re-target it to the '5.4'
 branch.

 -All new features/modules targeted to Qt 5.4 must be in ‘dev’ –branch at
 that time  must fulfill criteria for new features/modules (from Lars’s
 old email):

 oPlease make sure that all new functionality

 §Compiles on all reference platforms

 · (If a module/feature is only for one platform, make sure qmake/make
 does nothing on the other platforms)

 §Have tests

 ·Automated tests should cover as much as possible of the new
 functionality. If certain areas are not covered by automated tests, I'd
 like to hear how testing will be done for those

 §Have documentation

 · No undocumented public API. Basic docs have to be there, only
 polishing should still be required after the freeze

 §Have examples

 ·Have some examples showing how to use the API. Examples need to be
 linked from documentation.

 oIn addition, new modules need to

 §Follow the branching scheme

 ·A new module can be ok to only have dev, with ‘5.4’ being created at
 branching time.

 oHave a CI system

 §New modules that are going to be part of Qt releases need to have a CI
 system set up. Please contact CI team early enough….

 -Each new module needs to be a part of qt5.git already in ‘dev’ branch.
 Please notify release team about any new module for Qt 5.4 immediately!

 -‘5.4’ will be branched from ‘dev’ Mon 11^th August 2014

 Br,

 Jani



 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development



 --
 Br,
 Mr. Iikka Eklund
 Senior software engineer

 Elektronikkatie 10
 FI-90590 Oulu
 Email: iikka.ekl...@digia.com

 Visit us at: www.digia.com or qt.digia.com
 --
 PRIVACY AND CONFIDENTIALITY NOTICE
 This message and any attachments are intended only for use by the named
 addressee and may contain privileged and/or confidential information. If
 you are not the named addressee you should not disseminate, copy or take
 any action in reliance on it. If you have received this message in
 error, please contact the sender immediately and delete the message and
 any attachments accompanying it. Digia Plc does not accept liability for
 any corruption, interception, amendment, tampering or viruses occurring
 to this message.
 --
 ___
 Development mailing list
 Development@qt-project.org
 

Re: [Development] HEADS UP: Qt 5.4 feature freeze - is frozen now

[Mark Gaiser]

On Sun, Aug 10, 2014 at 12:25 PM, Иван Комиссаров abba...@gmail.com wrote:
 Unfortunately, QStorageInfo is already used in Qt: 
 https://qt.gitorious.org/qt/qtsystems/source/f0ca4494ccca6f247ac2548041503f52c64b306d:src/systeminfo/qstorageinfo.h

 Originally, my class was called QDriveInfo, but that's not corrrect due to 
 network volumes, which are not drives, actually.

 Any other suggestions?

QMountInfo perhaps?


 Иван Комиссаров

 10 авг. 2014 г., в 14:21, Knoll Lars lars.kn...@digia.com написал(а):

 I agree with Simon and Mark. Volume is a term that IMO will confuse most
 people in this context. Storage sounds a lot better to me as well. Can we
 please fix that? And a name change of course doesn’t block it from 5.4 :)

 Cheers,
 Lars


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Qt 5.4 feature freeze - is frozen now

[Mark Gaiser]

On Sun, Aug 10, 2014 at 1:39 PM, Иван Комиссаров abba...@gmail.com wrote:
 I was thinking a bit and made a conclusion that volume is the exact word 
 for a mount point.

 Mac OS API uses volume to represent mounted disks 
 https://developer.apple.com/library/mac/documentation/CoreFoundation/Reference/CFURLEnumeratorRef/Reference/reference.html

 Windows uses terms drives, partitions and volumes 
 http://msdn.microsoft.com/en-us/library/dd163559.aspx

 Even QStorageInfo uses terms drives and volumes 
 http://qt.developpez.com/doc/5.0-snapshot/qstorageinfo/

 If we ever will have any class that deal with sound volume, we can name it 
 QSoundVolumeInfo:)

 This is sorted list of variants (top i like most, bottom - dislike):
 QVolumeInfo
 QDriveInfo
 QStorageInfo (can' be used, but let it be here)

Why exactly can't you use that?
If i look on the Qt module page [1] then QtSystems is not mentioned
anywhere so i assume it's not even a supported module? I could be
wrong though.


[1] http://qt-project.org/doc/qt-5/qtmodules.html

 QMountPointInfo
 QMountInfo
 QStorageDeviceInfo (some mount points do not refer to devices and it's really 
 too long name)

 Иван Комиссаров

 10 авг. 2014 г., в 15:21, Knoll Lars lars.kn...@digia.com написал(а):

 Slightly longish, but how about QStorageDeviceInfo if you don’t like drive?

 Cheers,
 Lars


 ___
 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] How does QML versioning work?

[Mark Gaiser]

 Also, where are the changelogs for each new version of a QML module?
 (e.g. what's the difference between QtQuick 2.2 and QtQuick 2.3?)

I was going to say:
I would like to know that as well since it only seems to be visible
in the actual git logs

But then i started looking at the new changes in Qt 5.3 and noticed a
New QML Types and New QML Properties part in the New Classes and
Functions in Qt 5.3 wiki page which you can find here:
http://qt-project.org/doc/qt-5/newclasses53.html

That will probably help you. But i don't know the conditions to raise
the QtQuick version number. Or does the minor version number stay in
sync with the Qt minor version number? Since we have Qt 5.3.x now and
QtQuick 2.3. Would that mean that Qt 5.4 gives us QtQuick 2.4?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt High-dpi QtCS report and patch status (on hold)

[Mark Gaiser]

On Wed, Jul 2, 2014 at 2:33 PM, Sorvig Morten morten.sor...@digia.com wrote:
 A quick report from the contributors summit (I apologize for the delay and 
 sketchy notes):

 * I went though the general approach:

 - Setting the scale factor:
 - platform plugin: QWindow::devicePixelRatio, 
 QScreen::devicePixelRatio
 - the user: QT_HIGHDPI_SCALE_FACTOR=2
 - per-screen config file?

 - Layering
 - QtWidgets / QtQuick / Application : device-independent pixels
 - QPA: QWindow/QWindowSystemInterface :scaling layer
 - Platform plugins:  device pixels

 - QWindow and platform plugins
 - setGemetry()/geometry() is in device-independent pixels
 - platform plugins must scale when using QWindow API

 * There was discussion on several points:
 - There are font kerning issues on Linux (and probably Windows) due 
 to the scaling. How can we resolve this?
 - Do we really want to add scaling to QtGui? The alternative is to 
 wait until there is OS support.
 - Windows and its three high-dpi modes.

 On to the patch status: (https://codereview.qt-project.org/#/c/86107/)

 Based on the patch reviews on gerrit and some discussion on irc I’ve decided 
 that we don’t have a good enough consensus to merge the patches. I’m putting 
 them on hold until after the summer break at least.

 Morten

Just a slight note of concern with this along with the idea to make Qt
5.4 or 5.5 an LTS version. Whatever you folks decide, please consider
including highdpi support in the version of Qt that is going to be the
LTS version. I ask because company's already tent to lag a couple
releases behind (or are still in 4.8.x). If a company updates they
prefer an upgrade to an LTS version. It's very much possible that this
upcoming LTS version is going to be used for years to come. Not having
highdpi support in there would be a missed opportunity imho.

Cheers,
Mark
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt (5.3.0) QML on Mali 400 armsoc driver. Could it be broken?

[Mark Gaiser]

Hi,

I'm trying to run Qt5 QML examples on the odroid-x. That device has
the mail 400 gpu with the armsoc driver.

I have a working graphical environment and i can run a OpenGL ES 2
demo benchmark (non Qt) glmark2-es2. That seems to be working just
fine.

However, if i try to run qmlscene (or qmlviewer) i'm keep getting this message:

Cant find EGLConfig, returning null config
Unable to find an X11 visual which matches EGL config 0
Could not initialize OpenGL

followed by a core dumped line.

Could this driver + Qt5 be broken?
If there are any commands or tests you want me to run for more
information, please don't hesitate to ask. I'd gladly help.

Cheers,
Mark
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt (5.3.0) QML on Mali 400 armsoc driver. Could it be broken?

[Mark Gaiser]

Op 30 mei 2014 01:39 schreef Mark Gaiser mark...@gmail.com:

 Hi,

 I'm trying to run Qt5 QML examples on the odroid-x. That device has
 the mail 400 gpu with the armsoc driver.

 I have a working graphical environment and i can run a OpenGL ES 2
 demo benchmark (non Qt) glmark2-es2. That seems to be working just
 fine.

 However, if i try to run qmlscene (or qmlviewer) i'm keep getting this
message:

 Cant find EGLConfig, returning null config
 Unable to find an X11 visual which matches EGL config 0
 Could not initialize OpenGL

 followed by a core dumped line.

 Could this driver + Qt5 be broken?
 If there are any commands or tests you want me to run for more
 information, please don't hesitate to ask. I'd gladly help.

 Cheers,
 Mark

And it's fixed.
When people see me using root in pastebins for console output they always
say you really should not use root, make a user or something along those
lines. (I fully agree to that BTW)

Well, I did for the Qt stuff. As a user I get the issues mentioned in the
first post.

As root I actually have everything working just fine. Qt QML examples work
perfectly. I actually wasn't expecting an example like samegame to be
buttery smooth, but it is! Pros to the Qt team!

So it seems to be some issue with permissions. And that is certainly not
clear when looking at the output I saw (in the first post).

On big fat note though. Do not use startx with twm. Qt examples and windows
then open in some bugged transparent way. Use a slightly more modern
window manager like openbox.

Now I just have to figure out which permissions are missing for the user.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Question about Qt's future

[Mark Gaiser]

On Sun, Apr 27, 2014 at 10:37 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
 Em dom 27 abr 2014, às 12:55:58, Peter Kümmel escreveu:
 Having imperative code on the JS side is also the root of the rejection of
 QML for many C++ developers. If QML would have been just a improved .ui
 nobody would have complained.

 We'd end up with one of the problems of CSS which is that you can't do
 calculations in the bindings. I can't do

 width: 50% - 10em



Actually, you can..
http://css-tricks.com/a-couple-of-use-cases-for-calc/

And even Internet Explorer has support for it: http://caniuse.com/#feat=calc

 The moment you start adding some math, you need stuff like Math.random() and
 you end up again in JS.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Quick Controls Calendar

[Mark Gaiser]

On Wed, Feb 12, 2014 at 2:12 PM, Mitch Curtis mitch.cur...@digia.com wrote:
 On 01/17/2014 05:34 PM, Mitch Curtis wrote:
 On 12/06/2013 02:02 PM, Mitch Curtis wrote:
 Hello.

 At the beginning of this year I started work on a Calendar for Qt Quick
 Controls as a sort of side project. After removing the WIP from the
 commit message, I got some feedback from developers who either a) had
 also wrote a Calendar for KDE stuff or b) suggested I ask for feedback
 from plasma-devel. Rather than add to the already massive list of patch
 sets for that change, I thought it would be better to truly open up the
 Calendar for contributions before it goes in by creating a WIP branch
 for it in the Qt Quick Controls repo [1]:

 wip/calendar

 It'll be a throwaway branch, so every commit must be atomic and follow
 all of the normal Qt commit policies [2][3]. At the end, we'll resubmit
 every individual change to qtquickcontrols' dev branch.

 Please feel free to submit patches or provide feedback on what's already
 there. For example, it has already been suggested that there should be a
 C++ backend for the models, dates, etc.

 Cheers.

 [1]
 https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a
 [2] http://qt-project.org/wiki/Branch-Guidelines
 [3] http://qt-project.org/wiki/Commit_Policy
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


 For the Plasma folk that are interested - an example that demonstrates
 events (which are stored in an SQL database) integrated into the
 Calendar: https://codereview.qt-project.org/#change,75883
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


 We've changed a direction a bit and have instead squashed the WIP branch
 changes into one change, as the history was not really that useful and
 it makes it easier to review. The final change is:

 https://codereview.qt-project.org/#change,77806

 Styling improvements will come afterwards, but hopefully before 5.3. :)

Hi Mitch,

I just went over all the code (just skimming over it) and i really
like the approach you've chosen :)
A real good cool job on your side!

Too bad i couldn't provide any help during the development of this.
But i will gracefully use your creation when trying to hook in the
Akonadi calendar events once Qt 5.3 is out.

Thanks again!

Cheers,
Mark
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQuick: Drag pixmap

[Mark Gaiser]

On Tue, Jan 28, 2014 at 11:32 PM, Alan Alpert 4163654...@gmail.com wrote:
 On Tue, Jan 28, 2014 at 1:25 PM, Mark Gaiser mark...@gmail.com wrote:
 On Tue, Jan 28, 2014 at 8:28 PM, Alan Alpert 4163654...@gmail.com wrote:
 On Wed, Jan 22, 2014 at 10:42 AM, Mark Gaiser mark...@gmail.com wrote:
 On Wed, Jan 22, 2014 at 12:11 AM, Fabien Castan fabcas...@gmail.com 
 wrote:
 Hi,

 Qt 5.2 adds the possibility to use dragdrop from/to external 
 applications.
 To allows to drag an item from QML to an external application, we can't
 simply set a target item, because we want to see this item ouside of the 
 qml
 window.
 In Qt, we could set a pixmap on drag events:
 http://qt-project.org/doc/qt-4.8/qdrag.html#setPixmap

 I don't see something like that in QtQuick (Qt 5.2):
 http://qt-project.org/doc/qt-5/qml-qtquick-drag.html

 Is there a solution to do such thing in pure QML?

 Regards,
 Fabien

 While browsing through the code (qquickdrag.cpp) i found these two
 commented lines:
 // TODO: how to handle drag image?
 // drag-setPixmap(iconPixmap);

 Along with that no more function for setPixmap that is exposed to QML.
 That makes me fear that the setPixmap property is not there anymore.

 Odd, since it would be an API break which i can't really imagine from Qt.

 I hope someone else more knowledgeable in this area can chime in?

 Use of direct QPixmaps in QML is discouraged, because there's no real
 way to manage the memory of the pointer. If there were a QObject or
 QJSValue wrapper around QPixmap then a setPixmap could be added,
 similar to the setPixmap in QDrag (although not actually accepting a
 QPixmap type).

 So without a good solution handy, that part has been left for later.

 Alan, would it be possible to use a Image{...} item as pixmap?
 Yes, right now it's not possible, but just as an idea for a workable
 implementation.

 Not really. The Image element contains much more than just the pixmap,
 such as positioning and rendering hints, so it's both too heavy and
 most of the properties would be lost. We'd ideally like a lightweight
 JS wrapper which just takes a URL (possibly one from an image
 provider), so long as it can be used declaratively.

Ahh, didn't know that.

So if we continue that idea, would it make sense to re-create the
Image{} component in two parts? One for representing the actual image
data, one for representing is's place in the QML app.

Lets call the one just representing the image data ImageData {}. It
only knows how to represent a image based from an url or image
provider.
The Image{} component that inherits from ImageData{} and adds whatever
it needs to be on par with the current Image{} component.

Would an approach like that make sense?
just thinking out loud now :)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQuick: Drag pixmap

[Mark Gaiser]

On Wed, Jan 22, 2014 at 12:11 AM, Fabien Castan fabcas...@gmail.com wrote:
 Hi,

 Qt 5.2 adds the possibility to use dragdrop from/to external applications.
 To allows to drag an item from QML to an external application, we can't
 simply set a target item, because we want to see this item ouside of the qml
 window.
 In Qt, we could set a pixmap on drag events:
 http://qt-project.org/doc/qt-4.8/qdrag.html#setPixmap

 I don't see something like that in QtQuick (Qt 5.2):
 http://qt-project.org/doc/qt-5/qml-qtquick-drag.html

 Is there a solution to do such thing in pure QML?

 Regards,
 Fabien

While browsing through the code (qquickdrag.cpp) i found these two
commented lines:
// TODO: how to handle drag image?
// drag-setPixmap(iconPixmap);

Along with that no more function for setPixmap that is exposed to QML.
That makes me fear that the setPixmap property is not there anymore.

Odd, since it would be an API break which i can't really imagine from Qt.

I hope someone else more knowledgeable in this area can chime in?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Does Qt support FreeSync and G-Sync?

[Mark Gaiser]

Hi,

As you might (or might not) know, nvidia introduced g-sync which is
going to be supported by some monitor vendors shipping monitors this
year.

AMD made a twist on that - smart as they are - by introducing their
own FreeSync which they claim is just using the vesa specification.
So no special hardware is needed provided that your current monitor
even has the firmware to support it.

Since this syncing stuff depends on rendering i guess it also needs to
be supported on the software side? Just like good old vsync is. So
will Qt support this or is Qt supporting this already?

Just asking out of curiosity. I have no hardware that supports either
g-sync or freesync.

Cheers,
Mark
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Quick Controls Calendar

[Mark Gaiser]

On Fri, Dec 27, 2013 at 4:15 PM, Sebastian Kügler se...@kde.org wrote:
 On Saturday, December 21, 2013 19:50:30 Mark Gaiser wrote:
 I hope some of the plasma folks can provide some feedback on the ideas
 proposed in this thread.

 Which ideas exactly? The thread is quite convoluted, and it's hard to make
 sense of it to me. I also might be missing an email or two.

 If you can point out specific questions, I'd be happy to weigh in, otherwise,
 this discussion has become unmanageable to me. :/

 Cheers,
 --
 sebas

 http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

Feedback.. Anyone?

If there is no feedback this week then i'm going to assume that my
proposal is probably the best way to go and start implementing it.
It's actually kinda demotivating since i would expect the plasma folks
to care, welcome it and have tons of feedback and suggestions which
would benefit everyone involved.

Kinda makes me feel sorry for Mitch for listening to me and posting this here.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Quick Controls Calendar

[Mark Gaiser]

On Tue, Jan 7, 2014 at 2:49 PM, Martin Klapetek
martin.klape...@gmail.com wrote:
 On Fri, Dec 6, 2013 at 3:08 PM, Mark Gaiser mark...@gmail.com wrote:


 Below is my feature list that i'd like to have in that calendar.
 Since i have some experience in that area i will try to help out as
 much as i can.

 -- QML part --
 * Controls for the calendar grid
 * Controls for next/forward or just a few functions. This should at
 least have a nextMonth/previousMonth. Perhaps also nextYear and
 previousYear for convenience.


 nextMonth/prevMonth totally agreed. For years, that depends on the UI imho,
 so that the header is not too cluttered with different arrows. I can imagine
 a fading up/down arrows above/below the year, not sure how much would that
 work in practice though...

next/previous year would be just convenience.
Perhaps there should be a more abstract way to do this:

obj.setMonth(obj.month -12)

which would give you the previous year, same month.
That would be easy for manipulating the calendar view without the need
to reset the full date when you want to change to a different month.

Then nextMonth and previousMonth won't be implemented on the C++ side.
Rather, they would be implemented on the QML side as simple functions:
function nextMonth() {
  obj.setMonth(obj.month + 1)
}

function previousMonth() {
  obj.setMonth(obj.month - 1)
}

function nextYear() {
  obj.setMonth(obj.month + 12)
}

etc..

That allows for far more flexibility and a clean C++ interface without
much convenience functions.



 * Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And
 the ability to change the name to shorter/longer variants.


 What would be the usecase for longer variants? Full screen/huuge calendars I
 assume? Here's an important question imho - should the days be capitalized
 or not? Qt's locale follows, well, the locale and for example the Czech
 weekday names are not capitalized because we do not capitalize them, like
 for example Friday in English is. However, when it's put standalone, I think
 it should always be capitalized. It simply looks better.

You're thinking just about the calendar grid now. For that you don't
need more then 3 char day names.
But my intention is more to have a general data model that can be
easily used for more then just a calendar grid though the grid would
be it's primary goal.
So it is tailored towards a grid, but not limited to it.

An example where you might want longer daynames is in a event overview
which just sums up the upcoming events. The current plasma calendar
even has that so i think it should have the ability to set the day
name lengths with the possibilities that you can also find in QDate.

As for capitalize the first char.
I think the model (the C++ side) should just return the string that
the locale gives. Without modification. The QML side - the view - can
then capitalize it. It's kinda pointless to add a model property:

bool capitalizeFirstDayChar..

Possible, but seems a bit odd.



 * Controls for the weeknumbers that are shown in the grid.


 Optional with default off. But if the visual side is made good enough
 looking, it might work. But in 76% of times you don't need to know the week
 number, then it just clutters the grid.

It's just a model :) on/off is decided by the view i guess.


 As far as i understand the QML code, all but the weeknumbers are in.


 Yup, but it's made as one single component (for consumers) iirc.


 -- Locale --
 In KDE there was already an issue with differences between the
 JavaScript date object and the QDate object. I don't know the fine
 details here, someone else will probably fill that in i hope. I know
 there where issues, just not what exactly.


 I already posted it before, but for the sake of completeness, QDate starts
 weekdays and months with 1 while JS Date object starts both with 0, so eg.
 QDate weekday value 7 is Sunday while JS Date would give you undefined for
 7.

Right, so we either should do no modification in from the C++ model
and let it be done by the view. Or we should do all modifications -
which i can't even think of - and just hope that it won't ever
interfere with the view.
I vote for sending date objects to QML and let the view decide what to
do with it.


 -- C++ part --
 This is the part where i really would like some feedback. I have a
 general idea of how it should be done, but i don't know the details or
 implications it might have.
 It is my hope that calendar controls like Mitch is proposing now will
 be extensive enough to simply swap the models to another backend.
 Akonadi comes to mind. However, there should obviously be a
 non-akonadi based version for default Qt usage.

 My idea on that is as follows. Again, i don't know the implications of
 it or if it's really viable to take this route. Feedback is very much
 welcome here!
 The calendar model should be based on a new model that provides some
 default functionality and properties. I would say:
 QAbstractCalendarModel

Re: [Development] Qt Quick Controls Calendar

[Mark Gaiser]

On Fri, Dec 27, 2013 at 4:15 PM, Sebastian Kügler se...@kde.org wrote:
 On Saturday, December 21, 2013 19:50:30 Mark Gaiser wrote:
 I hope some of the plasma folks can provide some feedback on the ideas
 proposed in this thread.

 Which ideas exactly? The thread is quite convoluted, and it's hard to make
 sense of it to me. I also might be missing an email or two.

 If you can point out specific questions, I'd be happy to weigh in, otherwise,
 this discussion has become unmanageable to me. :/

 Cheers,
 --
 sebas

 http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

For me this one specifically [1].
In that one i mainly want feedback on the proposed model structure.

[1] http://mail.kde.org/pipermail/plasma-devel/2013-December/027379.html
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Quick Controls Calendar

[Mark Gaiser]

On Fri, Dec 6, 2013 at 4:11 PM, Mitch Curtis mitch.cur...@digia.com wrote:
 On 12/06/2013 03:08 PM, Mark Gaiser wrote:

 On Fri, Dec 6, 2013 at 2:02 PM, Mitch Curtis mitch.cur...@digia.com
 wrote:

 Hello.

 At the beginning of this year I started work on a Calendar for Qt Quick
 Controls as a sort of side project. After removing the WIP from the
 commit message, I got some feedback from developers who either a) had
 also wrote a Calendar for KDE stuff or b) suggested I ask for feedback
 from plasma-devel. Rather than add to the already massive list of patch
 sets for that change, I thought it would be better to truly open up the
 Calendar for contributions before it goes in by creating a WIP branch
 for it in the Qt Quick Controls repo [1]:

 wip/calendar

 It'll be a throwaway branch, so every commit must be atomic and follow
 all of the normal Qt commit policies [2][3]. At the end, we'll resubmit
 every individual change to qtquickcontrols' dev branch.


 I've been told that this is incorrect; the correct statement is:

 even though this is a throw-away branch (whose commits will be re-submitted
 to dev individually), the usual policies should be followed


 Please feel free to submit patches or provide feedback on what's already
 there. For example, it has already been suggested that there should be a
 C++ backend for the models, dates, etc.

 Cheers.

 [1]

 https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a
 [2] http://qt-project.org/wiki/Branch-Guidelines
 [3] http://qt-project.org/wiki/Commit_Policy


 Hi Mitch,

 It's awesome that you pull in the KDE plasma folks. I wonder who gave
 you that idea? ;)

 Below is my feature list that i'd like to have in that calendar.
 Since i have some experience in that area i will try to help out as
 much as i can.

 -- QML part --
 * Controls for the calendar grid
 * Controls for next/forward or just a few functions. This should at
 least have a nextMonth/previousMonth. Perhaps also nextYear and
 previousYear for convenience.
 * Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And
 the ability to change the name to shorter/longer variants.
 * Controls for the weeknumbers that are shown in the grid.

 As far as i understand the QML code, all but the weeknumbers are in.


 Yep.


 -- Locale --
 In KDE there was already an issue with differences between the
 JavaScript date object and the QDate object. I don't know the fine
 details here, someone else will probably fill that in i hope. I know
 there where issues, just not what exactly.


 From the testing that I did with it [1], it has some differences when it's a
 negative year, so the current implementation of the Calendar only allows
 positive years, up to the year 275759; a significantly smaller range than
 QDate [2].


 -- C++ part --
 This is the part where i really would like some feedback. I have a
 general idea of how it should be done, but i don't know the details or
 implications it might have.
 It is my hope that calendar controls like Mitch is proposing now will
 be extensive enough to simply swap the models to another backend.
 Akonadi comes to mind. However, there should obviously be a
 non-akonadi based version for default Qt usage.

 My idea on that is as follows. Again, i don't know the implications of
 it or if it's really viable to take this route. Feedback is very much
 welcome here!
 The calendar model should be based on a new model that provides some
 default functionality and properties. I would say:
 QAbstractCalendarModel : public QAbstractListModel { ... }
 This model should provide the default - should be implemented -
 properties:
 * day -- INT number of the day in a current month
 * isCurrentMonth -- returns true for the current month (aka, the month
 you are viewing in the calendar). Returns false for the days before
 and after the currently viewing month. Based on the position in the
 grid you can then calculate if the entry where isCurrentMonth
 returns false is before or after the current month.
 * containsEvents -- true if the day contains events, false otherwise

 day and isCurrentMonth should be convenience implemented in the
 QAbstractCalendarModel.

 Next there should be a model for core Qt calendar usage. Or in other
 terms: no akonadi dependency.
 That would be a class like:
 QSimpleCalendarModel : public QAbstractCalendarModel { ... }

 That class should probably have some basic storage in json files
 somewhere? Or ini or sqlite or..? Just something so that it can be
 used out of the box without any other requirements beyond Qt.
 Till this point is what would probably go in Qt. Everything after this
 line becomes Akonadi specific and should not be in Qt.

 If a structure like the above is approved then Akonadi can be very
 easily used in KDE with the Qt calendar components.
 We'd just have to make out own QAbstractCalendarModel implementation
 that uses akonadi data. That would be a class like:
 (K

Re: [Development] Qt Quick Controls Calendar

[Mark Gaiser]

On Fri, Dec 6, 2013 at 2:02 PM, Mitch Curtis mitch.cur...@digia.com wrote:
 Hello.

 At the beginning of this year I started work on a Calendar for Qt Quick
 Controls as a sort of side project. After removing the WIP from the
 commit message, I got some feedback from developers who either a) had
 also wrote a Calendar for KDE stuff or b) suggested I ask for feedback
 from plasma-devel. Rather than add to the already massive list of patch
 sets for that change, I thought it would be better to truly open up the
 Calendar for contributions before it goes in by creating a WIP branch
 for it in the Qt Quick Controls repo [1]:

 wip/calendar

 It'll be a throwaway branch, so every commit must be atomic and follow
 all of the normal Qt commit policies [2][3]. At the end, we'll resubmit
 every individual change to qtquickcontrols' dev branch.

 Please feel free to submit patches or provide feedback on what's already
 there. For example, it has already been suggested that there should be a
 C++ backend for the models, dates, etc.

 Cheers.

 [1]
 https://qt.gitorious.org/qt/qtquickcontrols/source/4c3196c979d9a7f46b3f37b14140026dd74bf79a
 [2] http://qt-project.org/wiki/Branch-Guidelines
 [3] http://qt-project.org/wiki/Commit_Policy

Hi Mitch,

It's awesome that you pull in the KDE plasma folks. I wonder who gave
you that idea? ;)

Below is my feature list that i'd like to have in that calendar.
Since i have some experience in that area i will try to help out as
much as i can.

-- QML part --
* Controls for the calendar grid
* Controls for next/forward or just a few functions. This should at
least have a nextMonth/previousMonth. Perhaps also nextYear and
previousYear for convenience.
* Controls for the day names (mon, tue, wed, thu, fri, sat, sun). And
the ability to change the name to shorter/longer variants.
* Controls for the weeknumbers that are shown in the grid.

As far as i understand the QML code, all but the weeknumbers are in.

-- Locale --
In KDE there was already an issue with differences between the
JavaScript date object and the QDate object. I don't know the fine
details here, someone else will probably fill that in i hope. I know
there where issues, just not what exactly.

-- C++ part --
This is the part where i really would like some feedback. I have a
general idea of how it should be done, but i don't know the details or
implications it might have.
It is my hope that calendar controls like Mitch is proposing now will
be extensive enough to simply swap the models to another backend.
Akonadi comes to mind. However, there should obviously be a
non-akonadi based version for default Qt usage.

My idea on that is as follows. Again, i don't know the implications of
it or if it's really viable to take this route. Feedback is very much
welcome here!
The calendar model should be based on a new model that provides some
default functionality and properties. I would say:
QAbstractCalendarModel : public QAbstractListModel { ... }
This model should provide the default - should be implemented - properties:
* day -- INT number of the day in a current month
* isCurrentMonth -- returns true for the current month (aka, the month
you are viewing in the calendar). Returns false for the days before
and after the currently viewing month. Based on the position in the
grid you can then calculate if the entry where isCurrentMonth
returns false is before or after the current month.
* containsEvents -- true if the day contains events, false otherwise

day and isCurrentMonth should be convenience implemented in the
QAbstractCalendarModel.

Next there should be a model for core Qt calendar usage. Or in other
terms: no akonadi dependency.
That would be a class like:
QSimpleCalendarModel : public QAbstractCalendarModel { ... }

That class should probably have some basic storage in json files
somewhere? Or ini or sqlite or..? Just something so that it can be
used out of the box without any other requirements beyond Qt.
Till this point is what would probably go in Qt. Everything after this
line becomes Akonadi specific and should not be in Qt.

If a structure like the above is approved then Akonadi can be very
easily used in KDE with the Qt calendar components.
We'd just have to make out own QAbstractCalendarModel implementation
that uses akonadi data. That would be a class like:
(K)AconadiCalendarModel : public QAbstractCalendarModel { ... }

It can still use the base QAbstractCalendarModel implementation for
it's grid stuff and re-implement the containsEvents property to be
filled with data from akonadi.

Well, that's it for my idea thus far. I'm looking forward to some
opinions on this.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] OpenGL drivers

[Mark Gaiser]

On Wed, Dec 4, 2013 at 12:37 PM, Mitch Curtis mitch.cur...@digia.com wrote:
 On 12/04/2013 11:47 AM, Sletta Gunnar wrote:
 QWidget has the exact opposite problem. Layouts, styles and rendering 
 happens in pixel units while fonts are sized in point size. This is also a 
 problem when moving between platfoms as the pixelsize of a point has a 
 different definition on each platform. When running widgets on a hidpi 
 screen, the fonts are usually huge compared to spacing, lines and icons. In 
 addition to looking quite ugly it easily breaks the layout scheme set up by 
 the application because the text takes up too much space.

 As long as one sticks to one unit type through the application everything is 
 fine. Mixing leads to problems.

 Just thinking out loud:

 Sticking to pixels makes it possible for the application developer to make 
 the right decision based on what he/she wants to achieve. Layout out 
 relative to millimeters can quite easily be done by providing supporting 
 logic in Qt.

 If we added conversion functions for inch(), cm(), mm(), points() to 
 QQuickItem, it could look up its current window/screen object and figure out 
 the relationship between each unit for the screen the item is on and just 
 set that. The app can then layout in the unit space it prefers with 
 information readily available.

 Text {
  font.pixelSize: cm(0.5);
  anchors.left: parent.left
  anchors.margins: cm(0.25);
 }


 Making them functions makes it impossible to listen for screen changes which 
 in turn trigger dpi changes so they would have to be properties...

 Text {
  font.pixelSize: 0.5 * cm;
  anchors.left: parent.left
  anchors.margins: 0.25 * cm;
 }

 The properties would look up the item's window and then the screen and do 
 the calculation from there so no extra memory for each item to store the 
 properties. And since they don't change all that often, the added 
 calculation is a negligible overhead. When the item is not associated with a 
 window, it will have to use the OS definition of a point instead, usually 72 
 or 96.

 Just an idea.

 -
 Gunnar


 That's a pretty cool idea! It would make it so painless to design stuff
 for different screens' DPIs.

I'm confused.
I thought we has pointSize for that reason, no?

To me it sounds like two different ways to accomplish the same thing.
Also, if i'm setting a font.pixelSize i'm expexting pixels to be
drawn. adding a * cm makes that moot since the real pixels that will
be drawn are calculated based on whatever cm is.

In other words, don't use pixelSize for it. Just making up a name now,
but how about something like this:

Text {
  ...
  font.realSize: 0.5 cm
  ...
}

seems more readable to me and gives me the expectation that the font
is going to be 0.5 CM (per char).


 
 Fra: development-bounces+gunnar.sletta=digia@qt-project.org 
 [development-bounces+gunnar.sletta=digia@qt-project.org] p#229; vegne 
 av Thiago Macieira [thiago.macie...@intel.com]
 Sendt: 3. desember 2013 18:09
 To: development@qt-project.org
 Emne: Re: [Development] OpenGL drivers

 On terça-feira, 3 de dezembro de 2013 10:27:24, Thomas Hartmann wrote:
 Hi,

 we really should think about introducing em or percent for font sizes.

 But non pixel size fonts create a lot of problems for complex layouts.

 QWidget has worked with that for 15 years, so I don't accept that as an
 excuse. We have anchor layouts in Qt Quick, which are a lot more powerful 
 than
 the grids and spacers that we used in QWidget.

 Desktop support does not require pixel perfection. It does require scaling
 over widely different resolutions and DPIs, though -- from 1366x768 to
 3200x1800, for example.

 --
 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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Can the hidden QML properties please be documented?

[Mark Gaiser]

On Mon, Dec 2, 2013 at 10:06 AM, Smith Martin martin.sm...@digia.com wrote:
 For a QML type in a .qml file, qdoc reports an error if it sees a QML 
 property it thinks should be in the public API for that QML type and there is 
 no \qmlproperty comment immediately preceding that property in the .qml file.

 But for a QML type that is represented by a C++ class, qdoc doesn't know 
 which C++ properties are meant to be be documented as QML properties, so it 
 can't report an error if a C++ property is not documented as a QML property.

 Maybe we should change this policy and tell qdoc to require a \qmlproperty 
 for every C++ property that has a \property ?

That sounds like a good thing to do if that prevents properties being
hidden. Remember, these 2 i mentioned are just the ones i discoverd in
recent months, i had more of those early on on Qt 5.0 and 5.1. Right
now it seems like the properties from the C++ QML components are too
easy to get wrong resulting in the property being undocumented. Even
while it might be properly documented, but just in the wrong order
(like renderType was).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Can the hidden QML properties please be documented?

[Mark Gaiser]

On Sun, Dec 1, 2013 at 11:09 AM, Nurmi J-P jpnu...@digia.com wrote:


 On 01 Dec 2013, at 00:42, Mark Gaiser mark...@gmail.com wrote:

 Hi,

 Recently i was searching for a way to influence the dragDistance in
 QML. The documentation (i even looked at dev snapshot docs) didn't
 provide any clue, but the code did. Turns out there is a hidden
 property:

 drag.threshold (it is underlined in red in QtCreator, but works just fine!).

 Perhaps you're reading Qt 5.1.x docs? MouseArea::drag::threshold is a new 
 property that was added in September. The documentation is there in the 
 latest snapshot: 
 http://doc-snapshot.qt-project.org/qt5-release/qml-qtquick-mousearea.html


 For font rendering there is the hidden property:

 renderType

 Which works just fine, but is nowhere to be found in the Qt documentation.


 QQuickText::renderType was indeed missing from the docs. It has been fixed in 
 Qt 5.2.0:
 - https://bugreports.qt-project.org/browse/QTBUG-35018
 - https://codereview.qt-project.org/#change,72391

 --
 J-P Nurmi

That's awesome!
It still makes me wonder, how many more are hidden? I hope none :)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] OpenGL drivers

[Mark Gaiser]

On Fri, Nov 29, 2013 at 7:01 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
 On sexta-feira, 29 de novembro de 2013 12:27:44, Sletta Gunnar wrote:
 So, I'm asking that if you encounter issues with flickering, crashes, bad
 rendering and similar, help us track which things are problematic by filing
 a bugreport on bugreports.qt-project.org and use the label driverissue in
 the task. Please  include OS, windowing system, graphics hardware and
 driver version. And since most of the workarounds have been applied to Qt
 5.2, do test against the 5.2 RC1 or later.

 Do you consider fonts looking the wrong size to be bad rendering and a driver
 issue? Fonts in the Creator welcome screen look to be of a different size than
 the rest of Creator.

 I'd consider it a font issue only, not a driver issue.


What you refer to are probably the fonts rendered through QML. By
default QML renders fonts with the distance field stuff [1]. It
looks awesome on mobile, but looks horrible on the desktop. This has
been known for a while [2] but apparently there is no effort ongoing
to improve the situation for the desktop users.

Globally setting the QML_DISABLE_DISTANCEFIELD variable makes it use
the native font system again and makes it look nice:)

[1] 
http://blog.qt.digia.com/blog/2011/07/15/text-rendering-in-the-qml-scene-graph/
[2] https://bugreports.qt-project.org/browse/QTBUG-28993
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Can the hidden QML properties please be documented?

[Mark Gaiser]

Hi,

Recently i was searching for a way to influence the dragDistance in
QML. The documentation (i even looked at dev snapshot docs) didn't
provide any clue, but the code did. Turns out there is a hidden
property:

drag.threshold (it is underlined in red in QtCreator, but works just fine!).

For font rendering there is the hidden property:

renderType

Which works just fine, but is nowhere to be found in the Qt documentation.

When reading the Qt documentation i would very much like to rely on it
and believe that the doc at the very least specify all exposed
properties. Searching the respective C++ classes in the Qt code to see
if any property is missing is a bit cumbersome to say the least.

So please, document those hidden properties. These are just the ones i
found, but i'm sure there is quite a bit more out there. I know that
both of the above where mentioned that they should be documented
somewhere on the mailing lists or in comments of bug reports (don't
know where though, quite a while ago).

Why are some properties not documented anyway? It should just be
documented if it has a Q_PROPERTY(...) right? Even if there is no
description.

Cheers,
Mark
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QInotifyFileSystemWatcherEngine might have incomplete data?

[Mark Gaiser]

On Sun, Nov 17, 2013 at 9:23 PM, Mark Gaiser mark...@gmail.com wrote:
 On Sun, Nov 17, 2013 at 9:20 PM, Mark Gaiser mark...@gmail.com wrote:
 On Sun, Nov 17, 2013 at 8:03 PM, Olivier Goffart oliv...@woboq.com wrote:
 On Sunday 17 November 2013 19:07:48 Mark Gaiser wrote:

 4. GDB (or whatever you used) should hit the bearkpoint. Now inspace
 the event members (name specifically). It's empty while it shouldn't
 be.

 Hi,
 I'd add a qDebug()  to be sure.
 Maybe it's just GDB giving wronf information.  Perhaps the data as been
 optimized.  Perhaps gdb think the name has lengh 0 because it is declared 
 as a
 char[].

 Hi Oliver,

 I tried your suggestion and that indeed works though not as i would expect 
 it.
 Yes, it does get printed on screen when i put event.name in a qDebug line.

 However, none of the emit signals in that function (readFromInotify)
 work anymore when i use event.name there. Anywhere! I just tried
 that out since you've had send the reply.
 You can find the diff of the stuff that's i've done thus far. Just
 adding this to your code breaks all the emits and i have no clue as to
 why that happens or how it's even possible.

 If you have any clue.. please do tell.

 Sorry, forgot the diff: http://pastebin.kde.org/pzqb2jph6
 Lifetime of 30 days.

Nevermind thiis issue. It works just fine now.
I had - shamefully - copied the part the checks if the emitted folder
is in face being watched. Then i had changed it's value without
changing the check so i ended up in this case that didn't made sense
at the time. Now it does :)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QInotifyFileSystemWatcherEngine might have incomplete data?

[Mark Gaiser]

Hi,

I'm trying to make my first little steps in making a Qt patch to implement a:

signal created(const QString path)

because that would allow you to know which files get created in a
folder that is being watched. KDirWatch has that feature,
QFileSystemWatcher doesn't.

However, when trying to implement that feature i was faced with an
empty inotify_event,name.

According to the inotify docs [1]. Specifically:
-- QUOTE --
The name field is only present when an event is returned for a file
inside a watched directory; it identifies the file pathname relative
to the watched directory. This pathname is null-terminated, and may
include further null bytes to align subsequent reads to a suitable
address boundary.
-- END QUOTE --

I'm not quite sure of this is a bug, something intentional or
something i'm doing wrong. The steps to reproduce this are as follows:

1. Create a simple that watches a folder:
#include QCoreApplication
#include QFileSystemWatcher

int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);

QFileSystemWatcher* watcher = new QFileSystemWatcher(a);
watcher-addPath(/path/to/folder/);

return a.exec();
}

2. Set a breakpoint within the
QInotifyFileSystemWatcherEngine::readFromInotify() function after the
point where you have an event object.

3. Create a new file in the folder you're monitoring.
4. GDB (or whatever you used) should hit the bearkpoint. Now inspace
the event members (name specifically). It's empty while it shouldn't
be.

Just to be sure that inotify works, i tested the same by typing the command:
inotifywait -m -e create /path/to/folder/
Creating a new file then gives me a new line like:
/path/to/folder/ CREATE newFileName

Which leads me to think that inotify itself is working just fine.

I hope someone could take a look at this and see if i'm wrong or if
this is a bug somewhere?

CCing the people that changed the readFromInotify function.

Cheers,
Mark

[1] http://linux.die.net/man/7/inotify
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QInotifyFileSystemWatcherEngine might have incomplete data?

[Mark Gaiser]

On Sun, Nov 17, 2013 at 8:03 PM, Olivier Goffart oliv...@woboq.com wrote:
 On Sunday 17 November 2013 19:07:48 Mark Gaiser wrote:

 4. GDB (or whatever you used) should hit the bearkpoint. Now inspace
 the event members (name specifically). It's empty while it shouldn't
 be.

 Hi,
 I'd add a qDebug()  to be sure.
 Maybe it's just GDB giving wronf information.  Perhaps the data as been
 optimized.  Perhaps gdb think the name has lengh 0 because it is declared as a
 char[].

Hi Oliver,

I tried your suggestion and that indeed works though not as i would expect it.
Yes, it does get printed on screen when i put event.name in a qDebug line.

However, none of the emit signals in that function (readFromInotify)
work anymore when i use event.name there. Anywhere! I just tried
that out since you've had send the reply.
You can find the diff of the stuff that's i've done thus far. Just
adding this to your code breaks all the emits and i have no clue as to
why that happens or how it's even possible.

If you have any clue.. please do tell.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QInotifyFileSystemWatcherEngine might have incomplete data?

[Mark Gaiser]

On Sun, Nov 17, 2013 at 9:20 PM, Mark Gaiser mark...@gmail.com wrote:
 On Sun, Nov 17, 2013 at 8:03 PM, Olivier Goffart oliv...@woboq.com wrote:
 On Sunday 17 November 2013 19:07:48 Mark Gaiser wrote:

 4. GDB (or whatever you used) should hit the bearkpoint. Now inspace
 the event members (name specifically). It's empty while it shouldn't
 be.

 Hi,
 I'd add a qDebug()  to be sure.
 Maybe it's just GDB giving wronf information.  Perhaps the data as been
 optimized.  Perhaps gdb think the name has lengh 0 because it is declared as 
 a
 char[].

 Hi Oliver,

 I tried your suggestion and that indeed works though not as i would expect it.
 Yes, it does get printed on screen when i put event.name in a qDebug line.

 However, none of the emit signals in that function (readFromInotify)
 work anymore when i use event.name there. Anywhere! I just tried
 that out since you've had send the reply.
 You can find the diff of the stuff that's i've done thus far. Just
 adding this to your code breaks all the emits and i have no clue as to
 why that happens or how it's even possible.

 If you have any clue.. please do tell.

Sorry, forgot the diff: http://pastebin.kde.org/pzqb2jph6
Lifetime of 30 days.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development