Re: [Development] Qt Coding Guidelines

[Rutledge Shawn]

On 18 Mar 2016, at 08:48, Jędrzej Nowacki 
> 
wrote:

Every time someone discuss coding style issues my blood boils. I understand
that it is important to have consistent coding style, but discussing where to
put braces or spaces is just waste of developing time.

Agreed, but that’s what code review is all about, as it turns out.  

I'm totally for an automated solution. I would even say that every rule
formatting related which is not expressed in some tooling aware code should
disappear. In addition, I really do not like that sanity bot is complaining
about typos after I pushed patches to gerrit and even worse it is commenting
on my code instead of proposing a fix.

Well, it would be nice if gerrit allowed reviewers to propose fixes too, so 
that you can just accept or reject individual proposed diff lines without 
having to do a git checkout to get exactly back the same state (which means you 
first need to commit or stash whatever you were doing, because it will be 
interrupted by fixing nitpicks), fixing the nits and pushing again.  Just like 
you can edit the commit message right on gerrit.  But, who’s going to implement 
it...

As you said coding convention are a bit bigger topic, but it also should be
automated. Seriously, rules about where to place Q_DECLARE_METATYPE or a check
if an include is missing are quite easy to express.

So I think, that we should not discuss what is better qdoc or md. The real
discussion is about tooling, what is the best tool to sanitize Qt code. We
need something that:
1. Can work as a sanity bot
2. Can re-format the code by applying changes (git hook?)

Forcing it on everyone that way will be controversial, because there is still 
some leeway in formatting, whereas automation would remove any chance of 
personal preference, and probably screw up in some cases.  But we could at 
least start by adding the clang-format config file to git so that it’s 
available for doing this manually.  Then in a few years maybe everybody will 
get used to it enough, and it can be refined enough, to become near-universal.

Otherwise there is the problem of running it for the first time, which the 
nitpicking reviewers would insist should be a separate commit.  So somebody 
would probably want to run clang-format on the whole repo, and make one big 
formatting-fix commit, which brings up said opportunity for clang-format to 
screw up alignment of code and comments in ways that will piss people off.  So 
I guess it would have to rather be done one file at a time, but due to the rule 
that we can’t fix whitespace and code at the same time, that would result in 
lots of extra noise in the commit logs: clang-format this.cpp, clang-format 
that.h and so on.

Not fixing code and whitespace in the same patch is a stupid rule of ours IMO.  
(It’s OK to fix the copyright header at the same time, but never dare to remove 
or add a single misplaced space at the same time.)  I think we should abandon 
that rule and allow formatting fixes at the same time as code fixes, especially 
if the formatting fixes are being done by some tool anyway.  Especially if 
gerrit could have a checkbox to ignore whitespace changes, like most offline 
diff viewers do.  Then when reviewing you look twice: once to see the code 
changes, and once to ensure that the whitespace changes are sane.  (But the 
sanity bot already does that.)

3. Rules are easy to express and they can be exported (qdoc, html, fooBar)
4. Works on diff level (so it doesn't complain about the whole world being
broken)

Bonus:
5. C++, js, qml awareness

Cheers,
Jędrek
___
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] Fixing QRect::width() / height()

[Rutledge Shawn]

> On 15 Mar 2016, at 15:43, Marc Mutz  wrote:
> 
> On Tuesday 15 March 2016 13:08:42 Bo Thorsen wrote:
>> Den 15-03-2016 kl. 14:07 skrev Marc Mutz:
> [...]
>> There is another option that doesn't mean a change of signature: Bound
>> the result. So if the real result is > INT_MAX, return INT_MAX. Same for
>> INT_MIN.
>> 
>> Yes, it's not the correct result, but I completely agree with you that
>> it's a theoretical problem. As long as it's documented in the width() I
>> really don't see the problem with this solution.
> 
> I like the idea to change width() to return a bounded result to avoid UB for 
> old users, but we need a code path that returns the correct result for new 
> users without everyone of them going quint64(1) + r.right() - r.left() by 
> themselves…

Cluttering up the API doesn’t seem nice.  Also not sure what you mean by new 
users needing such large rectangles… if they do, why don’t they use QRectF?

Or is it about a security hole?

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

Re: [Development] Scalable UIs in QtQuick (take 2)

[Rutledge Shawn]

> On 2 Mar 2016, at 09:37, Welbourne Edward  
> wrote:
> 
> Andreas Hartmetz said:
>> Arcminutes are a really good idea. The size of screen elements isn't
>> really about physical dimensions, it's about size on retina (the
>> actual biological thing ;) really, or legibility.
> [...]
>> If the system had "known" that the typical user to screen distance was
>> 2-3 meters and acted accordingly, that wouldn't have happened.  Of
>> course, you need to know the "typical viewing distance" for a screen,
> 
> So perhaps what we should be using to configure UI scaling isn't a scale
> factor but this typical viewing distance; as long as the system has some
> way to discover the physical dimensions of the screen and its pixels, it
> then know everything it needs to scale the UI sensibly.

But some devices tell lies in their EDID data, and some don’t.  And with a 
projector you don’t know the physical size either.  So we can’t always discover 
the physical dimensions without user intervention.  (At least xorg.conf 
provides a way to override it.)

We could have some kind of calibration tool to help close the loop: a wizard 
that detects all possible settings, tries some tweaks, asks you to measure some 
calibration rects and text (rendered with both QtQuick and widgets) with a 
ruler, and then suggests settings that you probably need to adjust manually.  
Kindof like using a colorimeter to calibrate color.  Except other software and 
hardware would keep changing out of our control, so this tool would never be 
“done”.  And really the desktop environment should have a sufficiently powerful 
control panel that we don’t need to write that.  But maybe it’s worth a try 
anyhow.

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

Re: [Development] QDesktopWidget for an X display

[Rutledge Shawn]

On 25 Feb 2016, at 08:46, Shiva sitamraju 
> wrote:

Hi,

I am trying to put a widget on a given X Display from inside QT application. 
Also posted same question on stackexchange 
http://stackoverflow.com/questions/35498895/qdesktopwidget-for-an-x-display .

Would be very grateful if anyone can help me in this regards

I answered it on stackoverflow.

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

Re: [Development] Scalable UIs in QtQuick (take 2)

[Rutledge Shawn]

> On 18 Feb 2016, at 11:50, Hausmann Simon  
> wrote:
> 
> Hi,
> 
> A little while ago Lars and I proposed to introduce physical units in the QML 
> language for use in QtQuick. The idea was to make it easier to write user 
> interfaces that adapt to different display resolutions by "pinning" your UI 
> to physical dimensions. For example you could say
> 
>Image {
>source: "mypprofilephoto.png"
>width: 5cm
>height: 5cm
>}
> 
> and the image size in physical pixels would scale accordingly to always 
> produce a 5cmx5cm profile image on the screen. The proposed units included 
> "px", which was really an alias for nothing.
> 
> We've had some very good discussions around this at last year's contributor 
> summit as well as in smaller face-to-face discussions. The main feedback I 
> recall was that this would seem like a nice feature on paper but in practice 
> people create their resolution independent interfaces using the current 
> "pixels" and a scale factor that they introduce in a qml file or as a context 
> property. That's another way of saying that perhaps the feature wouldn't 
> really find any use, which is fair :). Instead the desire was expressed that 
> making it _easier_ to scale "logical" pixels in the application would perhaps 
> be better.
> 
> So today during a discussion another idea came up:
> 
> (1) In order to make it really easy to scale "logical" pixels without having 
> to introduce your own context property or factor in a .qml file that you 
> multiply everywhere, we could turn the regular "pixels" in QtQuick into truly 
> logical pixels that scale with an application wide (or window wide) factor. 
> So Image { width: 100 ... } will scale automatically from 100 logical pixels 
> to maybe 200 physical pixels on a x2 display. This assumes the availability 
> of API to change this mapping.
> 
> (2) In the events where you still _want_ to use physical pixels, you could 
> use "px" units.
> 
> So at first nothing would change for app developers at all because we map 
> logical pixels to physical pixels. But
> if you'd like to, you could opt into changing this mapping and having a 
> relatively easy fallback to physical pixels using for example the "px" unit. 
> We might as well offer the other physical units anyway, that probably causes 
> little to no harm.
> 
> What do you think?

I thought support for units was on the way a long time ago.  How soon can it be 
finished?  It would be great to have extensible unit support, and not all of 
them need to be direct physical units either.  I think we need some unit which 
is related to the user’s choice of default font size somehow (e.g. Android 
provides global settings for this, and so do some desktop environments).  CSS 
specifies it in various ways:  
https://www.w3.org/TR/css3-values/#font-relative-lengths

It took me a while to find again the reference to measuring in arc-minutes, but 
that is here:

http://article.gmane.org/gmane.comp.lib.qt.devel/6863

But it’s easier to empirically adjust readability of text than to measure the 
user's ability to perceive a single dot; eye charts are made with text for a 
reason I think.  And what’s really more important than designers being able to 
specify what they want, is for the end user to have total control.  It’s very 
important to have a zoom control of some sort - preferably both a global one 
(like the Android font size setting - do we even respect that yet? or like Qt’s 
various confusing env variables), and a more-local one for correcting design 
mistakes (just like ctrl+ / ctrl- or ctrl-mousewheel in your browser, same 
thing in Creator’s editor, in our help system, etc).  For the global setting, 
the easiest thing for the user is to specify a default font size - that’s a 
subjective choice based on preference as well as visual acuity and distance.  
So maybe the best way to design the visual aspect of most applications is to 
use font-based units (like the em space) for physical sizes, but for touch UIs, 
to also use physical measurements as a minimum.  e.g. width: Math.max(7mm, 3em) 
- will it be possible, or can we have nicer syntax?  For example a button must 
be able to fit its text (unless it’s so long that the designer plans for it to 
be elided), but the button must also be at least 7mm in both dimensions to be 
touchable.  The user should choose the text size, while the designer should 
choose the minimum widget size, and otherwise tie physical size to text size.  
If the user chooses too large a text size, then less stuff fits on the screen… 
that’s the usual tradeoff.  And Qt has always had decent layout management, to 
make use of increasing or diminishing space effectively.

Qt’s lack of non-integral devicePixelRatio has been problematic.  Users need 
fine-grained control without tweaking individual applications and style sheets 
and preferences, all in app-specific incompatible ways.  Fortunately 

Re: [Development] Request for a new playground project

[Rutledge Shawn]

And then “backend” is awfully vague, could be anything other than application 
UI.  (QPA is a kind of backend, so is ODBC.)  Yes it’s a buzzword, but will it 
sound too dated or even more vague in 10 years?

> On 15 Feb 2016, at 07:30, Petroules Jake  
> wrote:
> 
> Drop the "mobile". Qt is a cross platform project and there does not seem to 
> be any technical reason to restrict this to mobile platforms. So, just 
> "Backend as a Service".
> 
>> On Feb 14, 2016, at 3:54 AM, Guillaume Charbonnier 
>>  wrote:
>> 
>> Hi all !
>> 
>> Following my last message regarding Qt new module for "Mobile Backend as a 
>> Service », what is the procedure to follow for creating a Qt playground 
>> project ?
>> My project is in a very early phase, it can only support REST api of 
>> Firebase for now but I felt it could help to mutualize our effort if we 
>> could have a published playground project.
>> 
>> Best regards.
>> Guillaume
>> 
>>> Le 12 févr. 2016 à 14:54, Guillaume Charbonnier 
>>>  a écrit :
>>> 
>>> Hi all,
>>> 
>>> Following engin.io services ramping down notification, Qt mobile developers 
>>> (like me) are lacking a MBaaS (mobile backend as a service) that would play 
>>> nicely with Qt. 
>>> I think this lack could be quite a big impedance for the promotion of Qt 
>>> for mobile development as most mobile applications use the basic features a 
>>> MBaaS offer...
>>> 
>>> I would like to start a playground project (with the help of everyone 
>>> interested in that topic) to offer a set of Qt classes and QML elements to 
>>> manage the following services :
>>> • authentification and authorization (with social login)
>>> • datastore (nosql)
>>> • push notifications
>>> • statistics
>>> 
>>> I think it would be great to design this new module to be backend agnostic. 
>>> Thus supporting several backend providers such as :
>>> - google Firebase
>>> - BaasBox
>>> - IBM Cloudant
>>> - Apigee
>>> 
>>> I have never participate in Qt project so I am an absolute beginner in this 
>>> field. 
>>> I have read the development topics in the wiki despite some of them state 
>>> to be outdated - any advice and recommandation will be greatly appreciated.
>>> Here is a link to the corresponding forum topic : 
>>> https://forum.qt.io/topic/63777/looking-for-engin-io-replacement-joining-our-effort-initiative
>>> 
>>> To conclude, I think it would be helpful to create a playground project for 
>>> this project, hence my request :
>>> Description : Qt Mobile Backed as a Service
>>> Playground project name : MBaaS
>>> 
>>> Best regards.
>>> Guillaume
>> 
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
> 
> -- 
> Jake Petroules - jake.petrou...@theqtcompany.com
> Consulting Services Engineer - 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] Extending touch semantic information and Qt backends

[Rutledge Shawn]

> On 11 Feb 2016, at 11:35, Александр Волков  wrote:
> Angle is not enough, because for compatibility with older apps 
> TouchPoint::rect() should be as close as possible to the rotated rect.
> See https://codereview.qt-project.org/#/c/114238/
> In other words it should be a projection of the rotated rect, so you should 
> introduce a separate method to get the rotated rect.

TUIO models the touchpoint as a rotated ellipse though, right?  
http://www.tuio.org/?specification  And I think that’s nice, for finger 
touchpoints at least (although markers could be any shape).  It can be assumed 
to be the ellipse inscribed in a rect; but I don’t think for the next-gen API 
that it makes sense to change the dimensions just because it’s rotated, because 
that makes it hard to visualize the ellipse, and hard to turn the size of the 
contact patch into a pressure (if you have hardware which gives you the contact 
patch but not the pressure).

Typical capacitive touchscreens (or window-system APIs) don’t provide the 
contact patch either, do they?  I’m not sure why it’s not more common.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Extending touch semantic information and Qt backends

[Rutledge Shawn]

> On 11 Feb 2016, at 02:13, Ariel Molina  wrote:
> 
> Hi, 
> 
> Research is strong on natural user interfaces, and now market is stronger 
> than ever and growing. I was working on the TUIO QPA and found a couple of 
> bugs, which I already pushed patches [1] [2] which I hope make it to 5.6.x.
> 
> OTOH, to further enhance touch interfaces I want to bring the discussion 
> about multiple touch layers, person-tagged touches, identified touches with 
> area information and objects with unique marker identification.
> 
> - Multiple touch devs/layers and Person tagged touches. Can be easily added 
> by extending QWindowSystemInterface::TouchPoint with a device identification, 
> like device(). This will also work for TUIO. 
> - Area & rotation. There is TouchPoint::area() and ::pressure() but currently 
> there is no support for ::angle(). Angle can be zero when not supported.
> - Unique identification. On research and advanced interactive surfaces the 
> usage of "markers" [3] is quite common. This is just a code extracted either 
> visually or by other mechanisms which is passed along the touch information. 
> I conjunction with area, rotation and uuid this paves the way for very rich 
> interaction.
> 
> I would like to know your thoughts about this topics, specially to know if it 
> would be acceptable for me to submit patches enhancing those areas (and to 
> whom add for review). I'd love to see marker uuid and angle() support at 
> least.

I’m interested.  But I will warn you that my attempts to make MouseArea and 
Flickable handle touch events directly have run into issues with the complexity 
of handling two completely independent event types with similar-but-different 
code, backwards compatibility, getting reviews on the patches, getting tests to 
continue passing, etc.  They handle only mouse events, which are synthesized on 
a touchscreen; changing MouseArea to handle touch is too hard; and that makes 
it too hard to change Flickable, because so many applications have MouseAreas 
in delegates in ListViews.

So, in existing releases of QtQuick, only PinchArea and MultiPointTouchArea 
handle touch events directly.  Maybe you are thinking of enhancing MPTA and its 
TouchPoints?  That’s probably doable, but do you think that API is useful 
enough for your applications?  If not, what kind of API would you rather have?

Now the plan is to write a new set of event handlers which are lighter-weight: 
not Items themselves but declared inside any Item (inspired by the Keys 
attached property, but not quite the same).  There can potentially be lots of 
types of handlers, and even several handler instances inside one Item when 
necessary; some will be hardware-agnostic “gesture” recognizers (e.g. 
TapHandler and PinchHandler) while others will be hardware-specific.  So maybe 
we can come up with a good way to handle markers within that framework, 
although I don’t have access to a fancy touch table which supports them (but 
have a capacitive touchscreen).  And yes the multi-user scenarios are 
interesting too.  I figured the new QQuickPointerEvent can have some sort of ID 
for user or “seat", whichever makes most sense.  Do you think it should simply 
be a numeric ID?

Likewise I don’t have a touchscreen which supports rotation, but have a Wacom 
tablet which does.  QQuickPointerEvent has a rotation property, on the 
assumption that it will become more common (but I can only test it with the 
tablet for now).

What do you mean about layers?

The PointerEvent/PointerHandler patches have been mostly waiting for me to get 
back to them since last summer, but I plan to get back to them soon.  
https://codereview.qt-project.org/#/c/123122/ is currently the ‘tip’, and you 
can follow dependencies backwards from there.  The plan is to put them into a 
branch soon so that it’s easier to follow progress.  Then we’ll see if it gets 
done in time for 5.8.  So far only the simplest Handlers work, others have 
issues remaining, and some aren’t written yet.

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

Re: [Development] [Interest] 5.7 feature freeze

[Rutledge Shawn]

> On 27 Jan 2016, at 13:34, mark diener  wrote:
> 
> The other major problem is that QQuickItem does not allow for
> QSGTextRect, so updatePaintNode CANNOT have text rendering
> in coordination with QSGGeometry.  The current recommendation is to
> try to coordinate using signals between 2 different QQuickItems, 1
> with text, the other
> with graphical geometry.  This is a restriction that appears to have
> occurred by chance.

That’s not the right class name AFAICT, but you mean you want public C++ API to 
populate text nodes into the scene graph, right?  Following the pattern that 
QSGSimpleRectNode and QSGSimpleTextureNode are public.  Yes this has been a 
sore thumb for quite some time.

Meanwhile, you can use private API.  If we make it public, then we are 
committed to keeping it compatible from now on, so I think that’s why the 
text-related nodes have not been made public so far: fear of losing flexibility 
to evolve.

We know that text rendering in Qt Quick needs to be more efficient.  What if 
that involves some refactoring?

And text rendering is complex, more or less depending on how fancy layout you 
need.  So I think in the long term we need some lower-level stuff, like a Glyph 
object in some QtQuick module (for putting FontAwesome icons [and future 
color-font icons!] on tool buttons, and selecting them by name rather than by 
unicode ID), and a PlainText item restricted to left-to-right rendering in a 
single font and color (no character spans, no markup, no harfbuzz, no RTL, but 
maybe with tab stops), as long as such an approach actually speeds up the 
common case.  Maybe such simple classes will be easier to make public, too, 
because they will have thin API.  (And then I would like to use the PlainText 
item to build a wicked-fast plain-text TableView.)

But, I did this https://codereview.qt-project.org/#/c/125753/ because in 
addition to being private, QQuickTextNode wasn’t even exported from the module; 
that must have been an oversight.  But that’s for 5.7.  So at least you can 
work at the level of Items rather than scene-graph nodes, using private C++ 
API.  And there is also private API for manipulating the scene graph nodes.  
This came up for me when I wanted to label the tick marks on the axes of a line 
graph.  (I didn’t want to use bindings to position individual Text items.)  I 
tried adding

QT+=quick-private
#include 

and managed to spit out a few glyphs, but realized that our layout API is a 
little cumbersome (and I found a bug while I was at it, which has since been 
fixed if memory serves), and figured I’d need more time than I thought to get 
it working well.  So then I tried using QQuickTextNode instead, which works now 
(on 5.7 branch).  But it’s not the fastest possible way to do simple 
left-to-right labelling, so I should probably go back to the first way at some 
point.  And if you haven’t, you should try it too, and then be careful what 
kind of public API you wish for.  ;-)

> This cripples custom controls capabilities and forces me to explain to
> customers about Qt limitations.
> 
> So how can we get the header file for QQmlEngine changed for 5.7

What is that about?

> feature freeze to add those 3 function declarations and un-sandbox
> QSGTextRect
> and still pass maintainer acceptance all by Monday?

If nobody started that yet, that means it’s potentially 5.8 material, right?  
And as soon as dev is branched for 5.7, it implies that any further development 
on dev branch is actually for 5.8.  So someone could potentially have a full 
half-year cycle to make the existing private APIs decent, and/or write the new 
stuff, debug it, document it, do API review, use it in some pet application(s), 
and catch all the gotcha’s.  Assuming that everyone involved can be persuaded 
that it actually ought to be public at all, within that time frame, or assuming 
that somebody finds the time to implement APIs which are definitely good enough 
to make public and support over the long term.  (I would like to actually, but 
my main goal for 5.8 is the set of new pointer handlers, which is notoriously 
time-consuming stuff: it’s hard to get reviewers to be interested and have 
sufficient attention span, autotests take a lot of work, etc.)

> 
> Cheers,
> 
> md
> 
> 
> On Wed, Jan 27, 2016 at 2:30 AM, Knoll Lars  
> wrote:
>> Hi everybody,
>> 
>> we’re slightly past the originally planned date for the feature freeze, for 
>> various reasons (new stuff being open sourced, license change and being late 
>> with 5.6). But I believe most things should be in place now to do the 
>> feature freeze for 5.7 next Monday.
>> 
>> There are currently three exceptions to the freeze:
>> 
>> * ok to finish the printing support in web engine
>> * ok for BTLE support for Linux in qtconnectivity (merge neard branch)
>> * Modules that are flagged as TP can also have some more time
>> 
>> If anybody else has a feature he believes absolutely 

Re: [Development] Charts and DataVis Questions

[Rutledge Shawn]

On 23 Jan 2016, at 19:52, Sean Harmer 
> wrote:

On 23/01/2016 12:45, Uwe Rathmann wrote:
Hi,

The OpenGL acceleration in Charts module is really impressive ...
Unfortunately part of the truth is, that the performance of the software
renderer does not necessarily be that far behind.

Now try it against OpenGL with 100k points rendering to a 4k screen. The 
difference between software and hardware will increase with those parameters 
(up to some fill rate or vertex rate that the hardware can handle).

You especially don’t want to do antialiasing with the software renderer (been 
there done that: it was about 2008 and using AA when rendering a QPainterPath 
made it several times slower than without), whereas vertex antialiasing with 
OpenGL is doable.  QtCharts so far uses GL_LINES for the line graph, but AFAIK 
the only way to get antialiasing with that approach is to turn on 
multi-sampling, which performs well only on certain desktop graphics cards 
(line graphs are simple enough, but it wouldn’t be so great to turn on MSAA in 
the whole QtQuick scene if your app is complex and you expect it to be 
portable).  I’ve been working on an antialiasing line graph, outside of Qt 
Charts so far though.  It’s similar to 
qtdeclarative/examples/quick/scenegraph/graph but does mitering right in the 
vertex shader, and antialiasing by setting the transparency proportional to 
distance away from the virtual line, in the fragment shader.

And of course with GPU rendering you can have full-frame-rate dynamism, whether 
the data is actually changing that fast or you are interacting - zooming, 
panning, moving a time cursor to see the corresponding data point, etc.  My 
laptop can render 60FPS while keeping the CPU at its lowest clock rate.  Or 
maybe a raspberry pi would have sufficient power to run an oscilloscope 
display, with the trace so smooth that it looks like an analog scope; I haven’t 
tried that, but it would make a nice demo.

Data modelling is another consideration.  I think the holy grail would be if we 
could send the actual data to the GPU unmodified, and render it there.  Vertex 
AA requires generating duplicate vertices though, to be able to expand them 
away from the line, to give it thickness.  So, for speed (but not memory 
conservation) we want to keep that array of vertices around, add new datapoints 
to one end and remove old ones from the other - as opposed to generating 
vertices each time we render one frame.  So it needs to have that kind of API, 
and you then should try to minimize any additional copying: store the data how 
you like but manage the vertices incrementally, or add each new sample to the 
vertex array and don’t bother keeping your own copy.  So I tried writing a data 
model which works that way: it stores the vertices on behalf of the rendering 
code, without exposing them directly in the API.  Whereas QLineSeries both 
stores data and renders it, as you can see in the example with the use of the 
append() function.  So maybe it could be refactored so that you can instead 
implement a model by subclassing an abstract base class, similar to the way 
that QListWidget is a QListView with an internal model, whereas in non-trivial 
applications you write your own QAIM and use QListView and/or QML ListView.  
But a time series is just one kind of data, and only makes sense with certain 
types of visualization.  So we could follow through and write abstract model 
classes for other kinds of data that can be visualized, but this kind of 
modelling amounts to making assumptions, which requires a lot of care to keep 
it as widely applicable as possible.

Later I want to try using a geometry shader to expand the datapoints into 
vertices.  That will be less portable though (won’t work on OpenGL ES).  But 
maybe it would make zero-copy (on the CPU) visualization possible, as long as 
you are OK to model the data the way that the rendering code expects (a 
time-value struct, just two floats or doubles per data point; or maybe two 
arrays, one for times and one for values).

My mitering shader has trouble with excessively high-frequency data, so 
resampling is useful, to get the sample rate down to one sample per horizontal 
pixel, or less.  There is some recent research on how to do that while 
preserving the psychological impression of how the data looks, which I’ve been 
implementing (only on the CPU so far):

http://skemman.is/stream/get/1946/15343/37285/3/SS_MSthesis.pdf

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

Re: [Development] Update QtWayland CI to Wayland 1.6+

[Rutledge Shawn]

> On 14 Jan 2016, at 16:05, Jędrzej Nowacki  
> wrote:
> 
> On Thursday 14 of January 2016 06:39:29 Thiago Macieira wrote:
>> On Thursday 14 January 2016 10:15:40 Jędrzej Nowacki wrote:
>>> I guess the whole point of having Ubuntu 14.04 LTS in CI is to support
>>> that
>>> 
>>> platform as long as it is important. As you said it will be important
>>> until
>>> 16.04 release. I think we could potentially remove 14.04 from CI on dev
>>> branch after Qt 5.7 release. Can't you "ifdef" you code, so it "works"
>>> with
>>> the older Wayland too?
>> 
>> I don't think it makes sense to support Wayland that old, especially not on
>> a distro that decided to not support Wayland. It's probably better to just
>> skip building Wayland altogether if the found libraries are too old.
>> 
>> We just need a newer distro that does support Wayland to be present.
> 
> True, so the assumption is that Qt should compile on the 14.04 for now. It 
> doesn't mean that the provided Wayland will be used. I'm fine with that :-)

But the one that we ship with the Qt installer had better work, right?  It’s 
built on some version of RedHat AFAIK.

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

Re: [Development] Proposal to change connectSlotsByName behavior

[Rutledge Shawn]

> On 4 Dec 2015, at 09:01, André Somers  wrote:
> I'd like to add a new alternative (though it does not exclude a change now 
> either):
> 
> - Deprecate the behaviour and remove in Qt 6.
> 
> I have never thought this feature to lead to good design. It makes for 
> "magic" in the sense that it is tricky to trace what happened. It leads to 
> un-Qt-ish naming of methods, and it leads to naming methods based on when 
> they are triggered instead of what they do. I find the latter usually leads 
> to more readable code, more so if there is more than one way to trigger the 
> behaviour encoded in the method. Last, I think private slots (for which this 
> would be most used) are largely on the way out anyway. Trivial slots can be 
> replaced by lambda's and non-trivial ones need a good function name anyway.

The main reason I (and probably many others) end up using this feature is 
because Creator will automatically write the handler for any signal if you 
right-click on a widget in the designer view and select Go to Slot…  So after 
we’ve decided what the pattern should really be, somebody needs to make Creator 
do it in the optimal way.  Otherwise we are effectively promoting use of this 
feature.  I’ve never used it when writing handlers by hand.

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

Re: [Development] QML import versions

[Rutledge Shawn]

On 18 Sep 2015, at 20:15, Nurmi J-P  wrote:

>> On 18 Sep 2015, at 17:33, Robin Burchell  wrote:
>> 
>> On Fri, Sep 18, 2015, at 05:12 PM, Nurmi J-P wrote:
>>> - QtQml 2.2
>>> - QtQml.Models 2.3 (++)
>>> - QtQuick 2.6 (++)
>>> - QtQuick.Particles 2.0
>>> - QtQuick.Controls 1.5 (++)
>>> - QtQuick.Layouts 1.3 (++)
>>> - QtQuick.Dialogs 1.2
>> 
>> You missed QtQuick.Window I think :)
>> 
>> ... which brings me to this:
>> 
>>> Is this something that would be possible to implement already in Qt 5, or
>>> is this Qt 6 material? Does someone strongly oppose the idea?
>> 
>> I have some opposition to the idea because it entirely prevents us from
>> making changes if they are needed. An example of this came up just the
>> other day on IRC: Window{} has a number of major (or at least quite
>> irritating) flaws. A few of us were discussing whether/how it would be
>> possible to fix them in a QtQuick.Window 3.0, without breaking backwards
>> compatibility with older code, and without waiting for Qt 6.
> 
> I think it’s a reasonable trade-off. Qt has lived with this restriction for 
> quite long. :)
> 
> If this is about the Item-based Window, would it make sense to give a 
> different name? Panel? Popup? There’s also something related in the works in 
> Qt Quick Controls 2.

To me, neither of those names create a mental image of a decorated window on a 
desktop system.  They allow me to continue to wonder if you are looking beyond 
menus and combo-boxes.

We are talking about a direct replacement for Window, just as flexible as the 
existing one, but additionally capable of being a simulation of a window on 
devices that can’t have real windows.  That’s the main reason it needs to be an 
Item rather than a QQuickWindow.  Other behaviors like being a popup or 
omitting the frame can be achieved with flags, just as they are now with 
Window.  We should be able to keep the API the same, as much as possible.

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

Re: [Development] Requesting New Repository - QtZeroConf

[Rutledge Shawn]

On Sep 10, 2015, at 12:05, Konstantin Tokarev  wrote:

> 
> 
> 10.09.2015, 00:56, "Jonathan Bagg" :
>> Project name: QtZeroConf
>> 
>> Project description:
>> QtZeroConf is a wrapper class for various mDNS discovery libraries across
>> multiple platforms:
>> 
>> Linux -> Avahi-client
>> Android -> Avahi-core or Android Network Discovery Service
>> Embedded -> Avahi-core
>> MAC -> Apple's Bonjour
>> iOS -> Apple's Bonjour
>> Window -> Apple's Bonjour
>> 
>> Responsible persons: Jonathan Bagg
>> 
>> (playgound unless suggested otherwise)
>> Desired repository name: playground/qtzeroconf
> 
> 
> Does SSDP (UPnP) discovery fit into this project?

Maybe we should call the module something more generic like QtServiceDiscovery. 
 Zeroconf can be used to discover both devices and services, but a service on a 
device is the more specific thing of interest, right?

Zeroconf also covers self-assigning a network address if there is no DHCP 
server, but that’s irrelevant to this module, I suppose.  (e.g. dhcpcd does 
that if it times out while trying to find a DHCP server)

There are many attempts to come up with a less centralized alternative to DNS.  
(namecoin, ipfs, various other projects using the DHT concept, even the magnet 
links used for bittorrent, etc)  So, maybe one of those would be in scope some 
day too.  Again the goal would be to map a well-known name to some sort of URI 
which identifies a service, or a specific file.  

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

Re: [Development] Qt Quick Controls Dialogs -- enabled state of the standard buttons (API choices)

[Rutledge Shawn]

On 22 Aug 2015, at 14:41, Filippo Cucchetto filippocucche...@gmail.com wrote:

 I totally agree with the solution proposed by mitch c. With the only 
 exception that i would add a DialogButtonGroup qml element into which put the 
 buttons. This allows us to add functions and logic without clutturing the 
 Dialog component. Furthermore it matches the widget implementation.

My plan was basically that: to have a button box component, so you would have 
two ways to add buttons to the dialog: the StandardButtons enum as now, or 
declare the button box explicitly and put buttons inside.  And you’d be able to 
set buttonBox: null (or something like that) to make it go away completely.  In 
ApplicationWindow you need to declare a toolbar if you want one; but in the 
case of dialogs, the button box has to be automatically created (or exist by 
default) in case you simply set standardButtons, because it was introduced with 
that (oversimplified?) API.

But I didn’t get around to implementing that just yet.

 
 F.
 
 Il 22/ago/2015 13:57, Curtis Mitch mitch.cur...@theqtcompany.com ha 
 scritto:
 
 
 From: development-bounces+mitch.curtis=theqtcompany@qt-project.org 
 development-bounces+mitch.curtis=theqtcompany@qt-project.org on behalf 
 of Vladimir Moolle vmoo...@ics.com
 Sent: Saturday, 22 August 2015 01:22
 To: development@qt-project.org
 Subject: [Development] Qt Quick Controls Dialogs -- enabled state of the 
 standard buttons (API choices)
 
 [snip] 
 
 6. Finally, Dialog could accept (optional) delegates for the buttons created, 
 allowing for arbitrary customizations, i.e.:
 Dialog {
 ...
 StandardButtonDelegate {   //name arguably could be better
 role: StandardButton.Apply // could be “roles” here even
 StandardButton {   // a Button, but with default bindings for 
 “text”, etc.
 enabled: some binding expression
 }
 }
 StandardButtonDelegate {   //name arguably could be better
 role: StandardButton.Apply // could be “roles” here even
 Rectangle {// a very custom “button”
...
 signal clicked // or a warning emitted by Dialog if absent
 enabled: some binding expression
 }
 }
 }
 
 [snip]
 
 At this stage, wouldn't it just be easier to declare regular buttons as 
 children of the dialog and then introduce some Dialog.buttonRole attached 
 property? For example:
 
 Dialog {
 Button {
 Dialog.buttonRole: StandardButton.Ok
 }
 Button {
 Dialog.buttonRole: StandardButton.Cancel
 }
 }
 
 The dialog can still take care of the layouting of the buttons, and the text 
 would even be set for you (unless you want to set your own). We could 
 document this as overriding the standardButtons property if both are 
 specified for whatever reason.
 
 
 ___
 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] Backwards compatibiltiy break in Qt 5.5

[Rutledge Shawn]

On 28 Jul 2015, at 10:48, Marc Mutz marc.m...@kdab.com wrote:

 On Monday 27 July 2015 20:44:48 Thiago Macieira wrote:
 On Monday 27 July 2015 21:41:44 NIkolai Marchenko wrote:
 Yes,but this requires making override visible in every file of the
 project.
 
 We can solve this by having a global #ifdef that can change the setting.
 
 Or an environment variable, so you don't have to recompile the world…

+1 to that.  And I think the homograph-debugging should be the non-default one, 
so we go back to getting readable output by default.

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

Re: [Development] Nominating Sérgio Martins for Approver status

[Rutledge Shawn]

On 21 Jul 2015, at 13:27, Giuseppe D'Angelo giuseppe.dang...@kdab.com wrote:

 Hi,
 
 I'd like to nominate Sérgio Martins for the Approver status in the Qt project.
 
 In the last years Sérgio has pushed lots of patches in a number of 
 components: he worked on the QNX/BB platform plugin, on sensors support in 
 QtMobility for BB10, on Windows and Windows CE features and bugfixes, on the 
 addition of the qmllint tool; these days he's very active doing various 
 optimizations throughout the entirety of the Qt code base.
 
 You can find his work on Gerrit here:
 
 https://codereview.qt-project.org/#/q/owner:%22S%25C3%25A9rgio+Martins+%253Csergio.martins%2540kdab.com%253E%22,n,z
 
 Would anyone like to second?

+1

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

Re: [Development] New Module for Serial Buses

[Rutledge Shawn]

On 28 May 2015, at 13:35, Marc Mutz marc.m...@kdab.com wrote:

 Please don't overengineer this. If this is about CAN, call it QtCanBus. If 
 it's about i2c, call it QtI2cBus. These are separate libraries. You get the 
 idea. This is not like the web (ftp, http, ...) where there's an established 
 abstraction (URLs) and the vast majority of applications shouldn't care about 
 the actual protocol underlying a URL (thus, QNAM is ok, even though I note 
 that it loses functionality compared to QHttp, just as QHostInfo lost 
 functionality compared to QDns).
 
 I don't know about CAN, but taking KNX as an example I know well, you want 
 (preferably static, as opposed to type-erased) access to the KNX data formats 
 and group addresses. Yes, all the way up to QML, not just C++.
 
 QAbstactSocket is listed in the Wiki as a design mistake.
 
 Don't repeat it, please.

Back before URLs were standardized, someone could have objected that it’s too 
hard because Windows uses drive letters and colons and backslashes in file 
paths, or that network addresses are different between TCP/IP, Novell and 
token-ring networks, or that making a namespace for so many protocols (file, 
http, ftp, telnet, ssh, gopher etc.) is hopeless.  But it got done anyway, and 
does anybody think it was a mistake?

So I disagree that trying to make up a standardized namespace abstraction for 
all the buses is necessarily a futile effort.  In fact it would be surprising 
if nobody had tried by now.

As a result of the IoT hype, the idea of assigning a URL to a 
network-accessible device is inevitable.  But now we are talking about the 
other end of some bridge device, which translates network requests into local 
bus requests.

Another common abstraction on Unix-like systems is that everything is a file.  
One sensor-bus project I’m familiar with is http://owfs.org which is about 
communicating with sensors and other devices on one-wire networks, regardless 
how those networks are connected.  (There are USB adapters and serial-port 
adapters for PCs, GPIO hacks on various embedded systems, etc.)  The name comes 
from the fact that it started with a FUSE daemon to make possible “mounting” 
the network and then accessing each sensor as a virtual file: you can read from 
a particular path to get the temperature from a temperature sensor, for 
example.  Which is pretty cool because you need nothing more than your favorite 
shell to interact with anything on the network.  But pretty soon the project 
had defined a network protocol too, and also a way of accessing the same 
sensors over http, which means every sensor has a URL too.  “Mounted” networks 
are served up by a network daemon, and remote network-accessible sensor buses 
can also be “mounted” locally.

A similar thing was done for the X10 and Insteon home automation powerline 
remote-control systems: there’s a daemon to handle virtual files for the 
devices.  (But X10 doesn’t have any discovery capability, so the filesystem 
nodes needed to be created in advance.)  At my last house I had one-wire and 
X10 devices available as “files” on the same Linux box, and it was possible to 
do some home automation with nothing more than cron jobs echoing commands to 
certain paths.  Reacting to button presses from remote X10 panels required a 
tiny bit of scripting though.

Likewise a BlueZ serial link can be pre-configured at a particular file path so 
that when you open the “file”, you open a link to that device.

Of course the /dev/ttyS? tradition started much earlier.  RS-232 ports just 
need extra out-of-band configuration for baud rate, stop bits, flow control 
etc., but otherwise the file abstraction holds.  The main reason we have 
QtSerialPort is the serial port's lack of automatic configuration, which newer 
buses tend to have.

So to an extent, Qt wouldn't need extra code for communicating with diverse 
buses, as long as this tradition of mapping things to the filesystem continues.

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

Re: [Development] Imageformats v2

[Rutledge Shawn]

On 19 May 2015, at 21:00, Konstantin Ritt ritt...@gmail.com wrote:
 IIUC, this already covered by the idea: since we can not (currently?) support 
 animated pages, we treat both a multi-page tiff and an animated gif as a 
 document with N frames”.

I thought so.
 
 
 What you described sounds more like mipmap support. We can not say this is a 
 thumbnail for page N by looking at the image size only.

Some PDF viewers are rendering their own thumbnails anyway, and ignoring the 
built-in ones, because built-in thumbnails are often missing, and if they exist 
they have a fixed smallish size.  So in practice it works well enough to 
translate a requested image size into a decision: to use the built-in thumbnail 
which is close enough in size (saving some CPU time), or to just render the 
actual size as requested.  (PDF is a complex case compared to other image 
formats, because it can contain vector graphics, text etc.  But there are other 
vector graphic formats which can contain raster thumbnails.)  Some formats 
(like ico and icns) provide several sizes in the same file, so it’s again a 
matter of choosing the closest one to what was requested.  And some formats can 
efficiently provide a smaller image using a subset of the data rather than 
having to take the maximum resolution and scale it down, so again, choose the 
closest available size.  Whether or not the application chooses to treat one 
particular size as the “thumbnail” resolution is just an application detail.  
The thumbnails might be expected to be scalable anyway in some particular UI 
(as in Finder on OS X), but then there is some lag while the re-rendering is 
done after each change in scale.  So if you ask for 72px and a PDF happens to 
be using that size for page thumbnails, great, let’s use it; but if you ask for 
120px, then the page needs to be rendered at that resolution, although 72px 
would be OK temporarily (scaled up to 120px) while the re-rendering takes place.

So maybe it would be useful to have a flag specifying whether it’s OK to use 
close-enough sizes, or to require that the image be returned at exactly the 
requested size.

Of course if everyone wants an additional API to specifically limit the output 
to whatever is identified as a thumbnail in image formats which provide them, 
that’s probably a good idea too.  But then you would often fail to get an image 
at all, and need to follow up by requesting a non-thumbnail anyway.

 property int page: 0
 readonly property int pagesCount: pdf.framesCount
 ImageDocument {
 id: pdf
 source: path/to/file.pdf
 }
 Image {
 id: pageViewer
 source: pdf
 frame: page
 }
 Image {
 id: pagePreview
 source: pdf
 frame: page
 mipLevel: -1
 }

ImageDocument has its uses, but I don’t think it should be required for all use 
cases.  A full-featured PDF viewer needs such an object to access the text 
objects on each page (with bounding boxes), document metadata etc.  A less 
full-featured one would not.  And anyway the backend for it is outside the 
scope of the imageformats API, isn’t it?  PDF has a very extensive feature set, 
beyond what most image formats provide.  So more like import package.pdf and 
then have a PdfDocument, which links to whatever PDF library on its own.  
Whereas simple all-format image viewers wouldn’t need those features, so they 
could get by with Image.

So I’d add both frame and frameCount to Image, which would be enough in this 
example, and then you don’t need the ImageDocument for such a simple use case.

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

Re: [Development] Imageformats v2

[Rutledge Shawn]

I think the new API should have multi-page support.  It would be useful for 
pdf, djvu, multi-page tiff, and for looking at individual frames of animated 
gif, png, etc., to the extent that we write plugins for those.

I wrote a QQuickImageProvider for PDF (using poppler), but requestImage takes 
only an “id” string to identify the image.  So I had to make up a composite id 
containing both the filename and the page number.  (much like a URL format 
would be, if you had to request multiple pages from a web server)  So that’s 
the next API that needs to have some support for paging.

Can “frame” be considered the same as “page”?  But I see that you also have a 
subimage concept in mind.

Sometimes (as in icon files, or in any kind of file that also includes a 
smaller preview image) the sub images would be the same thing at different 
resolution, right?  That is orthogonal to the idea of paging: a PDF file can 
have multiple pages, and also embedded thumbnails for each page.  In order for 
an image format plugin to be enough to write a PDF reader application, it would 
need to support paging, and also getting the thumbnails for the pages.

In QQuickImageProvider::requestImage, requestedSize can also be given.  So 
that’s one way to specify a thumbnail: if the available thumbnail is near 
enough to requestedSize, return that instead.  The API anyway does not 
guarantee that you get exactly the size that you ask for.

Eventually we could get to the point that a plain Image in QML could be used as 
a PDF viewer, all by itself.  It would also need a paging API.

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

Re: [Development] New (optional?) dependency: xcb-util-errors

[Rutledge Shawn]

On 27 Apr 2015, at 00:53, Thiago Macieira thiago.macie...@intel.com wrote:

 On Sunday 26 April 2015 21:39:23 Uli Schlachter wrote:
 The actual question that I want to ask with this mail: This is a new
 external dependency. Is it ok to add this dependency to Qt?
 
 How common is that library? What distros often have it? How long have they 
 had 
 it?

It’s a completely new library, so nobody has it yet.  But the patch includes a 
copy of the lib in 3rdparty.  But if it had already existed, we’d modify 
configure to try to use the system library by default, whereas if you pass 
-qt-xcb to configure, then it would use the 3rdparty copy, right?  So should we 
do that now, with the expectation that it will eventually start showing up on 
some distros, or should we try to always use the 3rdparty copy for now?

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

Re: [Development] Rotating JPEG images by default

[Rutledge Shawn]

On 17 Apr 2015, at 12:10, Allan Sandfeld Jensen k...@carewolf.com wrote:

 On Friday 17 April 2015, Sorvig Morten wrote:
 On 17 Apr 2015, at 10:48, Allan Sandfeld Jensen k...@carewolf.com wrote:
 
 
 Ideally the orientation could also be kept as metadata in QImage.
 
 I’d like to see general metadata support in QImage. The closest thing we
 have seems to be QImage::text(), which supports QString data only.
 
 My specific use case setting and preserving the NSImage “template” property
 [1] across QImage - NSImage conversions. This does not really deserve a
 separate setter/getter: a key/value API would be ideal.
 
 I tried starting on a possible API, just to see if it could be done: 
 https://codereview.qt-project.org/#/c/110685/

QTBUG-22367 needs to get fixed too, which I was trying to do here

https://codereview.qt-project.org/#/c/101084/

and I have a patch to show metadata in the imageviewer example

https://codereview.qt-project.org/#/c/101083/

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

Re: [Development] image format plugins

[Rutledge Shawn]

On Mar 19, 2015, at 21:57, Thiago Macieira thiago.macie...@intel.com wrote:

 On Thursday 19 March 2015 19:30:40 Konstantin Ritt wrote:
 I didn't say we *should* do it. Simply asking for opinions.
 
 There is no any single .ico file in qtbase (except of ones in
 qicoimageformat auto-test) and we don't support -no-ico/-qt-ico/-plugin-ico
 configure options, which makes it a good candidate.
 
 There are plenty of icons on websites (favicon.ico), which is why the ICO 
 engine was placed in Qt in the first place. In addition, there's no 
 third-party 
 library required, this is all Qt-based code. I don't see why it should be 
 disabled at all.
 
 There is also just a single .gif file in widgets/movie example, though we
 support -no-gif configure option and widgets/movie example never checks if
 gif format is really supported.
 ^ So why bloating qtbase?
 
 Removing the files will not make the repository smaller. The actual checkout 
 size for most people will also be the same, since we're not proposing 
 removing 
 from Qt, just moving around.

Several years ago I started writing a giflib-based plugin with features that 
the existing one doesn’t have (to read and write text comments in the gif file 
was what I wanted, but probably giflib can do a few more things too).  If I was 
to get it integrated, where should it live?  It would need a config option, 
because of depending on a system library: the existing plugin is better if you 
don’t have giflib, or don’t want the dependency.

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

Re: [Development] Problem loading plugins with gcc 4.9.2

[Rutledge Shawn]

On Mar 3, 2015, at 14:55, Sergio Martins 
sergio.mart...@kdab.commailto:sergio.mart...@kdab.com wrote:

Hi,



So that you don't waste time pulling your hair out: plugin loading is broken 
with gcc 4.9.2



There's some clash between global static QFactoryLoader instances.
Reproduced on Archlinux (and on Fedora by jpnurmi).

I run Arch, and the main problem the last couple of weeks has been that I have 
to export QT_QPA_PLATFORM_PLUGIN_PATH or it will say that it can’t find the 
platform plugins.  Is that the same problem?

Oh and jpeg loading broke too.

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

Re: [Development] C++11 for Examples

[Rutledge Shawn]

On 3 Mar 2015, at 11:30, Guido Seifert warg...@gmx.de wrote:

 
 Make it unconditional and let people disable with -nomake tests or 
 -no-compile-examples if they have older compilers.
 
 Why not make different example categories? One category, which has the same 
 policies as Qt itself, i.e. it compiles
 with all the compilers Qt supports. Additionally a category, which uses all 
 new stuff C++11 stuff. And perhaps an 
 experimental cat, which is insane and requires C++2x --- ok, slight 
 exaggeration.

Schrödinger’s cat?

 Then the cats could be disabled with  -no-compile-examples, 
 -no-compile-examples-modern, -no-compile-examples-insane.

Creator has those “tags” on the examples page (so that you can e.g. find all 
the examples that show off certain platforms, or that use QtQuick), so the 
easiest would be to tag whichever examples we get around to updating to use 
some c++11 features.

 I was in several projects where I have been told: Don't use this feature, 
 don't use that feature. Sometimes the reasons
 where understandable, sometimes I had the feeling the reason was the project 
 manager was stuck in 98 and did not understand
 anything beyond that. 
 
 Now it is not Qt's task to teach modern C++, but if examples using those new 
 features help/convince other people to migrate,
 it also helps Qt.

and the ones who are “stuck” will use it as as an excuse not to use Qt, if none 
of the examples work on their compilers, or they just have mental blocks to 
understanding them.  So we should probably start small.

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

[Development] possible change in behavior: QGuiApplication::primaryScreen() can return null

[Rutledge Shawn]

With these patches (and earlier ones)

https://codereview.qt-project.org/#/c/87885/
https://codereview.qt-project.org/#/c/107504/
https://codereview.qt-project.org/#/c/107433/

we’ve been trying to fix bugs which have always existed in Qt 5 regarding 
behavior on Linux/X11 when screens are detached and re-attached: applications 
sometimes would crash, or sometimes stay running but disappear, no longer 
showing windows even when one more more screens are connected again.  One of 
the most annoying cases is when you are running Creator on your laptop, you 
connect an external monitor to relieve eye strain, and move Creator there; then 
later you need to pack up and go, so you simply disconnect the monitor.  The 
behavior has been different from version to version, varied depending on window 
manager, and on which screen was considered the primary.

The approach I took is to ensure that nothing in Qt will crash when there are 
no screens (so some checks needed to be added), and rendering will stop.  There 
were already other fixes in the past which dealt with letting the window 
manager move the windows back to the screen which got connected, or for Qt to 
do it otherwise.

So in 5.5 the behavior I’m trying to achieve is that while you cannot start a 
graphical application if there is no screen, if you already had one running and 
then all screens were disconnected, the application continues to run without 
rendering; and if you then connect one or more screens, the application will 
start rendering again.  That’s the worst case to handle, and yet you can see 
that non-Qt applications usually handle it just fine.  Of course when a screen 
is removed, but one or more remain, the application should also not crash or 
disappear, and should be able to render on whatever screen its windows are 
mapped to.

It may be a surprise though, for some applications, that 
QGuiApplication::primaryScreen() can return null in the case where there is 
really no screen attached.  It’s a rare use case, but it’s possible that some 
applications could crash if they are using that pointer at the wrong time, 
without checking.  And there are also some platforms where a dummy screen will 
normally exist even if no actual monitors are connected.  It’s just that it 
doesn’t seem to be necessary to have one on xcb, so we are trying to avoid 
needing to create one artificially.  It seems right to have the code modeling 
the real world: if there is nothing on which you can view the graphical output 
of your application, then there should not be a QScreen instance.

Does anyone have any objection?

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

Re: [Development] OSX 10.7 dropped from Qt?

[Rutledge Shawn]

On 2 Mar 2015, at 13:59, Sorvig Morten morten.sor...@theqtcompany.com wrote:

 On 27 Feb 2015, at 14:34, Blasche Alexander 
 alexander.blas...@theqtcompany.com wrote:
 
 If 10.7 is required then it should be added back to main CI targets. If it 
 is not added back then I will remove consequently remove every trace of it.
 
 I don’t think it will be added back. You should remove it from your branch as 
 well.

But only for 5.6, right?

___
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?

[Rutledge Shawn]

On 12 Feb 2015, at 08:55, Konstantin Ritt ritt...@gmail.com wrote:

 2015-02-12 11:53 GMT+04:00 Konstantin Ritt ritt...@gmail.com:
 2015-02-12 11:39 GMT+04:00 Rutledge Shawn shawn.rutle...@theqtcompany.com:
 
 On 11 Feb 2015, at 18:15, Konstantin Ritt ritt...@gmail.com wrote:
 
  FYI: Unicode codepoint != character visual representation. Moreover, a 
  single character could be represented with  a sequence of glyps or vice 
  versa - a sequence of characters could be represented with a single glyph.
  QString (and every other Unicode string class in the world) represents a 
  sequence of Unicode codepoints (in this or that UTF), not characters or 
  glyphs - always remember that!
 
 Is it impossible to convert some of the possible multi-codepoint sequences 
 into single ones, or is it just that we prefer to preserve them so that when 
 you convert back to UTF you get the same bytes with which you created the 
 QString?
 
 Not sure I understand your question in context of visual representation.
 Assume you're talking about composing the input string (though the same 
 string, composed and decomposed, would be shaped into the same sequence of 
 glyphs).
 A while ago we decided to not change the composition form of the input text 
 and let the user to (de)compose where he needs a fixed composition form, so 
 that QString(wellformed_unicode_text).toUnicode() == wellformed_unicode_text.
 
 P.S. We could re-consider this or could introduce a macro that would change 
 the composition form of a QString input but…why?

It might be almost within our power to index into a QString and get a single, 
complete, renderable glyph, which is practical at least for rendering, and 
maybe for editing too.  But if we did that by storing the unicode that way, 
we’d lose this feature of being able to reproduce the input text exactly:
QString(wellformed_unicode_text).toUnicode() == wellformed_unicode_text
Consequently we have to do conversion each time we need the renderable text, 
and/or cache the results to avoid converting repeatedly.  Right?

But it would also be possible to go the other direction: save only UTF-8 form 
in memory, so by definition we can reproduce text that was given in UTF-8 form. 
 But if the QString was constructed from text in some other UTF form, can we 
simply remember which UTF it was, convert to UTF-8, and then be able to 
reproduce it exactly by converting back from UTF-8?  And we still need to be 
able to do conversion to renderable glyphs, and maybe cache them.

I see that QTextBoundaryFinder has
 const QChar *chars;
so that is nearly a cache of glyphs, right?  except that e.g. a soft hyphen 
could exist in that list, and yet may or may not be rendered depending where 
the line breaks fall?  So at the end, rendering must still be done iteratively 
by calling toNextBoundary repeatedly and pulling out substrings and rendering 
those.  (QTextBoundaryFinder doesn’t have a QChar grapheme() accessor.  I guess 
that’s done elsewhere.)  But some of the decisions have been made already, and 
embodied into that array of QChars.  I was wondering whether it’s worthwhile to 
do more work each time we iterate, by using UTF-8 form directly, instead of 
converting to an array of QChars first.  So the memory to store the string 
would be less, but the code to do the glyph-by-glyph iteration at rendering 
time would become more “branchy”, and that is also bad for CPU cache 
performance.

Oh but there’s another way of storing glyphs: the list of QScriptItems in the 
text engine.  That looks kindof bulky too, depending how long we keep it around.

So Unicode is a mini-language which has to be interpreted at some point on the 
way to rendering; there’s no pre-interpreted form we could store it in.  
TrueType is also a mini-language.  Maybe it would be possible to write a 
compiler which reads UTF-8 and TrueType and writes (nearly) branch-free code to 
render a whole line or block of text, so we could cache code instead of data.  
It could be more compact and CPU cache-friendly.  I imagine nobody has done 
that yet.  But then if you think about all the fancy stuff TeX can do, it could 
get even more complex than what Qt currently does.  And I don’t understand much 
about what Harfbuzz does yet, either.

___
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?

[Rutledge Shawn]

On 11 Feb 2015, at 18:15, Konstantin Ritt ritt...@gmail.com wrote:

 FYI: Unicode codepoint != character visual representation. Moreover, a single 
 character could be represented with  a sequence of glyps or vice versa - a 
 sequence of characters could be represented with a single glyph.
 QString (and every other Unicode string class in the world) represents a 
 sequence of Unicode codepoints (in this or that UTF), not characters or 
 glyphs - always remember that!

Is it impossible to convert some of the possible multi-codepoint sequences into 
single ones, or is it just that we prefer to preserve them so that when you 
convert back to UTF you get the same bytes with which you created the QString?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Item creation time in QML

[Rutledge Shawn]

On 9 Feb 2015, at 11:25, Gunnar Sletta gun...@sletta.org wrote:

 Hi,
 
 Thought I would share a couple of benchmark numbers for item creation time in 
 QML. The sources are found here: 
 https://github.com/sletta/stuff/tree/master/qml/benchmarks. The motivation is 
 that we can generally animate a large number of items, but we often stutter 
 when adding and removing stuff from the scene or when scrolling complex lists.
 
 How the benchmark works is that the it tries to figure out how many 
 operations of a given type is possible each frame (not per second) while 
 sustaining a perfect 60 fps (or whatever other fps you target). For these 
 numbers, we’re looking at delegation creation and destruction. You can look 
 at the content of each specific benchmark here: 
 https://github.com/sletta/stuff/tree/master/qml/benchmarks/benchmark/creation.
  
 
 This was measured on my 13” MacBookPro, Intel i5 2.6Ghz, Intel Iris GPU using 
 ‘dev’. On lower end mobile and embedded, the numbers can be an order of 
 magnitude lower. 
 
  ./qmlbench --delay 2500 --repeat 5 --fullscreen --fps-interval 2000  
  benchmark/creation
 running: benchmark/creation/delegates_blendedrect.qml
  485 ops/frame
  490 ops/frame
  487 ops/frame
  477 ops/frame
  489 ops/frame
  485.6 ops/frame average
 running: benchmark/creation/delegates_buttoncontrol.qml
  10 ops/frame
  10 ops/frame
  10 ops/frame
  10 ops/frame
  10 ops/frame
  10 ops/frame average
 running: benchmark/creation/delegates_complex.qml
  11 ops/frame
  11 ops/frame
  11 ops/frame
  11 ops/frame
  11 ops/frame
  11 ops/frame average
 running: benchmark/creation/delegates_image.qml
  303 ops/frame
  304 ops/frame
  301 ops/frame
  304 ops/frame
  304 ops/frame
  303.2 ops/frame average
 running: benchmark/creation/delegates_labelcontrol.qml
  81 ops/frame
  81 ops/frame
  80 ops/frame
  81 ops/frame
  82 ops/frame
  81 ops/frame average
 running: benchmark/creation/delegates_longtext.qml
  37 ops/frame
  37 ops/frame
  37 ops/frame
  37 ops/frame
  37 ops/frame
  37 ops/frame average
 running: benchmark/creation/delegates_rect.qml
  527 ops/frame
  530 ops/frame
  527 ops/frame
  526 ops/frame
  531 ops/frame
  528.2 ops/frame average
 running: benchmark/creation/delegates_script.qml
  382 ops/frame
  387 ops/frame
  387 ops/frame
  374 ops/frame
  385 ops/frame
  383 ops/frame average
 running: benchmark/creation/delegates_text.qml
  128 ops/frame
  128 ops/frame
  127 ops/frame
  128 ops/frame
  127 ops/frame
  127.6 ops/frame average
 running: benchmark/creation/delegates_text_nativerendering.qml
  138 ops/frame
  137 ops/frame
  136 ops/frame
  137 ops/frame
  136 ops/frame
  136.8 ops/frame average
 running: benchmark/creation/delegates_text_plain.qml
  130 ops/frame
  129 ops/frame
  128 ops/frame
  128 ops/frame
  129 ops/frame
  128.8 ops/frame average
 running: benchmark/creation/delegates_text_richtext.qml
  46 ops/frame
  46 ops/frame
  46 ops/frame
  46 ops/frame
  46 ops/frame
  46 ops/frame average
 running: benchmark/creation/delegates_text_styled.qml
  125 ops/frame
  125 ops/frame
  126 ops/frame
  126 ops/frame
  125 ops/frame
  125.4 ops/frame average
 running: benchmark/creation/delegates_tworects.qml
  314 ops/frame
  312 ops/frame
  313 ops/frame
  314 ops/frame
  315 ops/frame
  313.6 ops/frame average
 All done...
 
 —
 
 Being able to do 500+items rectangles in one frame is decent, but not 
 awesome. Being able todo 130 text items in one frame, is less than ideal, 
 given that we often use several text items per cell in a list or table. Text 
 is probably the most important UI element we have. Being able to do 10 
 buttons is, well, unfortunate :) If we look at Button, we see that it is a 
 fairly complex QML beast. Hierarchy is 
 
 Button - BasicButton - Control - FocusScope
 
 and there are quite a bit of stuff on every level, including the dynamic 
 style handling which will in turn create a StyleItem. 
 
 And keep in mind that even though this isn’t the most high-end mac, it is 
 sitll a pretty decent computer, Qt is supposed to run on much worse hardware 
 than this.
 
 —
 
 There have been a few changes going into 5.5 which make these numbers better 
 than 5.4, but I still think we got quite a ways to go. 

That’s very interesting.

Do you think it was ever better in past versions?

What do you think we should do about it?  Mainly focus on trying to create 
fewer objects, or is there still a lot of headroom for making the creation more 
efficient?  Is creation expensive because of constructor code, making too many 
signal/slot connections, or something else?

___

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

[Rutledge Shawn]

On Feb 10, 2015, at 17:08, Julien Blanc julien.bl...@nmc-company.com wrote:

 On 10/02/2015 16:33, Knoll Lars wrote:
 IMO there’s simply too many questions that this one example doesn’t answer
 to conclude that what we are doing is bad.
 
 Two arguments :
 - implicit sharing is convenient, and really developer friendly. It is 
 probably a good idea since strings are really present a lot in signals 
 and slots (and afaik, passed by value in these context)
 - implicit sharing is implicit, you don’t have the choice not to pay for 
 it, which is a bad thing.
 
 From my experience, QStrings are slow. About two times slower than 
 using plain std::string in our use cases, but the culprit for this 
 slowness is, as far as we know, the internal 16 bits encoding, whereas 
 our data sources are all using utf-8. We have no evidence that the 
 implicit sharing cost is significant or not.

Should we try to use UTF-8 in some future version of Qt?  I’ve wondered that 
for a while: 16 bits is not enough for any possible Unicode character, whereas 
32 bits would be; and yet 8 bits is enough most of the time.  Isn’t 16 bits the 
worst choice then?  (some bloat for European languages, and algorithmic 
inefficiency for others)  With 32-bit characters, operator[] is always O(1).  
If we use UTF-8, the code would often have to iterate a variable number of 
bytes to get to the next character.  But is it worth it to save memory?  
Especially considering the point from earlier that operations on data which fit 
entirely within cache memory will be so much faster that it swamps the 
O(whatever) efficiency of some algorithms: keeping strings as small as possible 
should be a good thing.  And maybe there are some clever tricks to get faster 
character indexing, using bitfields or binary search or an occasional weak 
reference to a 32-bit decoded version when it’s really needed.  Emphasizing use 
of iterators instead of operator[] would help too.

I googled utf-8 character indexing and the top hit was this (which I’ve 
probably seen before): http://utf8everywhere.org/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

[Rutledge Shawn]

On 9 Feb 2015, at 13:42, Smith Martin martin.sm...@theqtcompany.com wrote:

 Everyone wishing to use a QMap should implement one before
 using it for the first time. Then you'd see what you inflict on the world.
 
 If that sentiment is valid, then we owe it to our users who are contemplating 
 using a QMap to explain to them when and why a QMap should be used and when 
 and why a QVector should be used instead.  
 
 IMHO: A lot of this is information you find in a CS course or in a book.
 Not in the Qt documentation.
 
 I came out of a CS course, but I would find that information helpful. Plus, 
 we hope to attract users to Qt who didn't come out of a CS course. 

+1 to that.

I also didn’t think that QMap was so bad, because O(log n) doesn’t sound bad; 
and I don’t remember having written a red-black tree from scratch before, 
either.  The docs also say that QHash is faster but QMap is sorted.  So my 
inclination is if I really want the built-in sorting (maybe because I want to 
be able to iterate the keys or values in a predictable order), and I want to 
map arbitrary keys to arbitrary values, where the two are not related, or when 
the value contains the key but also contains other stuff, then I’d tend to use 
a QMap.  If the value does not contain the key, and you want to use a sorted 
vector instead, you would have to create an artificial “node” class (or use 
QPair) just to put the key together with the value so that you can put it into 
the vector, right?  If that is a better way, maybe we should have a wrapper 
class to make it easy.  The help about QVector does not even contain the word 
“sort”, so you have to know to use std::sort (or by reading the qSort doc where 
it says to use std::sort instead).  Nor do we have any classes called 
QSortedSomething.

Or should we recommend to use more STL structures instead of Qt ones?  But the 
advantage of Qt data structures is the implicit sharing.

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

[Development] Open Source Developers' Conference in Oslo

[Rutledge Shawn]

We are intending to have a Qt track at this conference, so anyone who would 
like to come and present something in May should sign up at the URL below.

Begin forwarded message:

 From: Per Henrik Oja p...@oja.no
 Subject: Communities! Participate!
 Date: 4 February 2015 11:49:44 GMT+1
 To: prog...@osdc.no, organiz...@osdc.no
 Cc: internatio...@mysociety.org, ha...@mysociety.org, ge...@mysociety.org
 
 Hi!
 
 OSDC Nordic is an upcoming open-source friendly community-oriented
 event, held May 8th - 10th in Oslo.
 
 Open Source Developers' Conference exists to enable the many Nordic
 open source communities to come together and share their enthusiasm.
 
 Read more about the event on
 http://osdc.no/cfp.html
 
 We want you and your friends to come together to learn, hack and share
 their enthusiasm!
 
 Participate by presenting a talk, hosting a workshop, involving your
 community, by volunteering, or simply by participating in this awesome
 and unique event. Register on http://goo.gl/forms/fgUhby8aU9
 
 Feel free to contact us with any questions on organiz...@osdc.no
 
 And finally. To build a great community event we need everybody care by 
 sharing.
 
 Help us spread the word! Forward this email to any of your friends you
 think might like this invitation .
 
 --
 Best regards
 Per Henrik Oja
 Program Commitee
 OSDC Nordic
 http://osdc.no

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

Re: [Development] Requesting a break in behavior in QML Text element

[Rutledge Shawn]

On 29 Jan 2015, at 23:46, Olivier Goffart oliv...@woboq.com wrote:

 On Thursday 29 January 2015 23:24:51 Robin Burchell wrote:
 tl;dr: I'd like to request a behavior break in QML's Text element. I
 would like to change the default value of Text::textFormat from
 Text.AutoText to Text.PlainText.
 
 Personally, that's what I am doing in the QML project I am working on
 (We had to develop our own set of component (it was started before QtQuick 
 controls), and the text component default to Test.PlainText)
 
 Given the security implication, I do believe PlainText should be the default.
 
 However, I think it's too much of a breaking change for anyone who has used 
 html tags on purpose and did not explicitly set the format.
 
 Is it possible to do the change if we do
 import QtQuick 2.5
 That is, the default of textFormat changes depending on the number in the 
 import statement.

+1 to that.  If you update your import versions, you can expect some minor 
changes; and if you are editing the QML anyway, it implies that you are ready 
to take the time to re-test your application and make small fixes and 
improvements.

On 29 Jan 2015, at 23:24, Robin Burchell robin...@viroteck.net wrote:
 Seperately, we may want to look at a restriction on the loading of
 remote resources in Text. I can understand allowing remote URIs in
 Image, but Text seems like an unexpected behavior to me.

If we do that, there needs to be a way to override the restriction, maybe by 
adding a property to control whether loading of anything outside the QML is 
allowed.  It would IMO be OK to have this property false by default, since the 
majority of use cases don’t need it.

I can imagine that loading remote resources is a useful feature which some apps 
are relying on.  In fact, a single Text element is practically a web browser 
already, for certain limited purposes.  It's kindof cool to forego the need for 
a real web engine if you need only to display lightweight mid-90’s HTML.

I also think we should add a source URL property like Image has.  It’s 
unfortunate to need to rely on ugly hacks like this one 
http://rschroll.github.io/beru/2013/08/12/opening-a-file-in-qml.html just to be 
able to read a file.  And I/O should be more agnostic about local and remote 
resources, as long as the fact that you are doing I/O is explicit rather than 
unintended.

Sometimes you want network access to be really easy.  Other times you want to 
avoid security problems that come from unintentional network or filesystem 
access.  So we need to make it easy to go either direction, and enforce it 
consistently.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Timur Pocheptsov as approver

[Rutledge Shawn]

+1 from me

On Jan 22, 2015, at 7:52, Blasche Alexander 
alexander.blas...@theqtcompany.com wrote:

 Hi,
 
 I'd like to nominate Timur Pocheptsov for approver status. He wrote the OSX 
 and iOS implementations for QtBluetooth and lately has been increasing his 
 footprint in other modules for the same platforms.
 
 https://codereview.qt-project.org/#/q/owner:tpochep,n,z
 https://codereview.qt-project.org/#/q/reviewer:tpochep,n,z
 
 A big thank you from me to Timur.
 --
 Alex
 ___
 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] CI configuration changes

[Rutledge Shawn]

On 21 Jan 2015, at 08:19, Turunen Tuukka tuukka.turu...@theqtcompany.com 
wrote:

 
 On 20/01/15 21:44, Thiago Macieira thiago.macie...@intel.com wrote:
 
 On Tuesday 20 January 2015 19:21:04 Sarajärvi Tony wrote:
 What's your timeline for this?
 
 If I don't get any objections here, I could start the work immediately.
 Goal
 is to do it right away, so that we have time to verify the platforms
 before
 5.5 feature freeze.
 If you're looking at this for before the Qt 5.5
 feature freeze, OS X 10.7 will break and will be effectively
 unsupported
 for 5.5 because I won't bother fixing forkfd for it.
 
 My understanding is that OS X 10.7 is allowed to break in 5.5.
 
 Usually we give people a one version notice... So we shouldn't allow it
 to 
 break in 5.5, but announce that support drops in 5.6.
 
 OS X 10.7 has been listed as Tier 2 already for Qt 5.4:
 http://doc.qt.io/qt-5/supported-platforms.html
 
 That said, we should of course carefully consider whether or not it is
 supported with Qt 5.5.

Maybe we should leave it in CI for the 5.5 timeframe.  What would we have to 
give up to do that?

This is an example of why I’d like our CI system to be transformed into a 
distributed one: it should be possible for anyone to add machines to the pool.  
Even if some of them are non-binding… e.g. a contributed machine would only be 
able to do +1/-1 on a patch, as a warning that a certain patch will break a 
tier 2 platform.  There are many such platforms which we aren’t testing.

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

Re: [Development] A better headersclean test

[Rutledge Shawn]

On Jan 6, 2015, at 16:52, Thiago Macieira thiago.macie...@intel.com wrote:

 On Tuesday 06 January 2015 10:14:35 Curtis Mitch wrote:
 For development I usually do debug builds, so it would be nice to avoid
 the extra build time (and extra nagging during the build) most of the
 time, and just let CI enforce it, as long as that is reliable.
 +1
 
 So I guess both of you are ok with having the option to opt-out with the 
 default being to compile headers.

Yeah passing one more argument to configure is OK.

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

Re: [Development] A better headersclean test

[Rutledge Shawn]

On 6 Jan 2015, at 01:06, Thiago Macieira thiago.macie...@intel.com wrote:

 On Monday 05 January 2015 23:15:24 Giuseppe D'Angelo wrote:
 Il 02/01/2015 17:55, Thiago Macieira ha scritto:
 I'm giving it another week due to the Christmas/New Years break, after
 that I will consider it ML consensus to enable by default.
 
 Can we make it opt-in instead of opt-out? I don't see why all Qt
 developers should pay by default for the extra compilation times (or,
 modify their configure to add even more options), while this can be
 easily enforced by CI.
 
 The current solution I sent to Gerrit is opt-in. The email here was to ask to 
 make it opt-out.
 
 I am assuming the CI will opt-in for some configs.

For development I usually do debug builds, so it would be nice to avoid the 
extra build time (and extra nagging during the build) most of the time, and 
just let CI enforce it, as long as that is reliable.

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

Re: [Development] changing Q_GADGET

[Rutledge Shawn]

On 28 Nov 2014, at 12:19, Simon Hausmann simon.hausm...@theqtcompany.com 
wrote:

 Hi,
 
 Monsieur Goffart did awesome work in the dev branch on allowing structures 
 with 
 Q_GADGET to have properties and invokable methods. This brings the macro to a 
 much wider audience and I'd like to use this opportunity to propose a slight 
 change to it that may be controversial:
 
 The macros Q_OBJECT and Q_GADGET both - towards the end of their definition - 
 change the member access permission level to private. It's always been that 
 way.
 
 I'd like to propose changing Q_GADGET to not change the access permission 
 level, so that you can write
 
 struct MyStructure
 {
Q_PROPERTY(int x MEMBER x)
Q_GADGET
 
int x;
 }
 
 
 I feel that Q_GADGET has its primary use with structures and the default 
 access level for those is public. I find it awkward that you currently have 
 to 
 write:
 
 structure MyStructure
 {
Q_PROPERTY(int x MEMBER X)
Q_GADGET
 public:
int x;
 }
 
 
 The proposed change would have two effects:
 
 1) It makes any existing code that _relies_ on Q_GADGET turning to private 
 suddenly expose members in structures.
 
 2) On paper it breaks binary compatibility with MSVC, in the unlikely event 
 that somebody 
a) produces a DLL and cares about binary compatibility
b) exposes bare structures
c) relies on Q_GADGET turning access permission levels to private
 
 
 I feel that the effects are negligible compared to the benefit of a better 
 API.

Is it really only about the desire to avoid writing “public:” above the public 
data?  But on the other hand, if you wanted the data to be private you would 
probably have declared it that way, in either a class or a struct; so the 
convenience of having either macro make the default private is limited, right?

What are the right reasons to use structs instead of classes?  Is it only for 
the reason that members are public by default?

Why is Q_GADGET mainly used for structs and not classes?  Now that it has more 
features, maybe it could get used for some classes too.

Should we have public documentation for Q_GADGET?

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

Re: [Development] Issues with QApplication::startDragDistance

[Rutledge Shawn]

On 13 Nov 2014, at 11:11, Jeremias Bosch jeremias.bo...@basyskom.com wrote:

 Dear all,
 I was looking into deploying a simple QML App on a wide range of devices. The 
 App consists basically of two QML Lists which are used for horizontal and 
 vertical page navigation. The ranges of Display DPI differ a lot between 
 those devices.
 
 Now there are two issues I ran into.
   • On High DPI cases the sensitivity of the lists is very high, 
 basically touching the screen is already registered as a drag and pressing 
 buttons is pretty hard. On Low DPI its fine. Of course you can tweak the 
 startDragDistance with QApplication::startDragDistance, or the corresponding 
 value in your Platform Style. However, this would mean that you need to 
 adjust for each target device to get the expected behavior, which might not 
 be possible and preferable - I think that the default value should respect 
 the screen DPI.
   • I would like to have the vertical page navigation list to be less 
 sensitive than the horizontal page navigation list and the horizontal page 
 navigation list even less sensitive than all other normal content lists. 
 I couldn't find a way to adjust the sensitivity on a case by case situation. 
 All I found was a feature request 
 https://bugreports.qt-project.org/browse/QTBUG-18792, but it was closed 
 invalid back in 2011, without any comment.
 Maybe I overlook a feature and this is already possible?
 What do you think?
   • Wouldn't it make sense to make the default start drag distance 
 respecting screen dpi?
   • What do you think about to add a property on the QML Flickable in 
 order to customize startDragDistance for this one QML Flickable? Are there 
 any concerns about having such a property?

Yeah we will get there eventually.  e.g. there’s just a start here

https://codereview.qt-project.org/#/c/79480/
https://codereview.qt-project.org/#/c/91242/

But there are potentially a lot of these “feel” constants which should depend 
on the platform and on display density: the flick speed is slower than it 
should be, and the behavior doesn’t feel the same as in other apps on the 
platform.  So they need to be adjusted in the platform plugin, IMO, or in some 
sort of platform-specific style or theme, rather than adding new properties to 
Flickable and other items, because you shouldn’t need to adjust them yourself.  
Correcting things that we should have already gotten right by default isn’t a 
good reason for cluttering up the public API, IMO.  And we actually need more 
of such constants rather than assuming the threshold is the same for flicking 
as for dragging etc.  And there are acceleration/deceleration, bounce behavior 
etc. which are actually hard to quantify with just a number or two.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Issues with QApplication::startDragDistance

[Rutledge Shawn]

On 13 Nov 2014, at 13:19, Jeremias Bosch jeremias.bo...@basyskom.com wrote:
 
 I have two combined lists. One vertical, one horizontal. You can imagine it 
 like a grid. One item in those lists has the size of the screen. The user can 
 navigate horizontal and vertical from each item. 
 
 What I need is:
   • the user needs to move his finger about 1/3 of the screen in 
 horizontal direction until his movement is recognized by the horizontal list 
 as a scroll.
   • the user needs to move his finger about the 1/2 size of the screen in 
 vertical direction until his movement is recognized by the vertical list as a 
 scroll.
 All other lists should show standard system behavior. 

That sounds like snapping behavior; maybe a GridView or a couple of PathViews 
would work?  because they have snapMode.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [FYI] new git-gpush features, a.k.a. the smart way of pushing to gerrit

[Rutledge Shawn]

On 24 Oct 2014, at 12:38, Jędrzej Nowacki jedrzej.nowa...@digia.com wrote:
 
 I admire that you want to improve everyones working process, but I think you 
 took the wrong way. You are fixing the problem on odd level, I strongly 
 believe 
 that you should fix Gerrit, enforcing a tool on everyone is at the best far 
 from ideal.
 
 don't rebase unnecessarily - For us, Gerrit is always cherry-picking, 
 which 
 means a user do not really control final parent of a change. Therefore in 
 theory rebase should not be a problem. Sadly It is because of two things:
 1. It crates new patchset, which sends notification and reset score
 2. It breaks web diff.
 Both should be fixable on the Gerrit level

I agree.  I’ve always thought the “don’t rebase” advice is artificial, because 
I prefer not to try to integrate a patch until I’ve made sure that it can be 
rebased on top of the latest code, and still works.  (If you don’t do that, 
then you will often waste the reviewers’ time again anyway, because the need 
for rebase is a surprise at the end after they’ve finally given in and +2’d.  
Maybe even a few hours before a code freeze.)  So it’s often a multi-step 
process when revising a patch:

1) cherry-pick
2) make changes
3) build and test
4) git checkout sha1 of the parent patch of the one gerrit has; or, use the 
gerrit checkout link
5) cherry-pick the real patch onto this point in history to keep reviewers from 
complaining about the rebase
6) make sure it builds (or not; if it applied cleanly it should be OK)
7) push again
8) go back to the branch tip again to continue work on something else
and now because headers were touched because of the jumping back and forth, the 
build will take some time.

And the only reason AFAICT is that gerrit shows all the intermediate diffs too, 
not just the changes that I actually made, whenever it compares a new version 
of a patch with an old version, and there was a rebase in between.  There are 
two cases: one is that the latest patch can apply cleanly on top of either the 
sha1 that it was originally applied to, or on top of the newer one.  In that 
case, gerrit could show a cleaner diff automatically, by doing the same thing 
that I do manually.  The other case is that the rebase was actually necessary, 
in which case the reviewers still have to deal with the extra noise anyway.  At 
least by working on the tip instead of in the past, I already found out about 
that, so there’s no surprise at the end when trying to integrate.

And besides, when reviewing it’s better to give the entire patch one more look 
before giving +2, to make sure that the whole thing still makes sense in 
context.  Some people prefer to see the inter-patch diffs, but if there is 
noise because of rebasing, what’s wrong with re-reading the whole thing? Many 
of our patches are small enough that it’s not unreasonable.

We also need to be friendly enough for outside contributors.  I don’t usually 
complain to them about unnecessary rebasing: better to just be thankful that 
they are doing necessary work that we didn’t get around to.

But the real reason for not fixing Gerrit is just that we don’t own it, right?

Now you will just brag again about how your tools are better than whatever 
anyone else can possibly ever think of, and make more of your usual ad-hominem 
accusations.  But your dictatorial attitude leaves a bad taste and actually 
does not make me want to try them at all, compared to the mail a couple of days 
ago where you were just pitching them on the basis of usefulness.  That one was 
actually tempting.

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

[Development] Should a QMessageBox (or other dialog) NOT dismiss itself automatically when the Help button is pressed? (QTBUG-34566)

[Rutledge Shawn]

It has been proposed that in QtQuick.Dialogs, the Help, Apply and Reset buttons 
should not dismiss any dialog automatically.  I agree conceptually, but the 
issue is that to be completely consistent, we need to change the behavior of 
QMessageBox (and various native dialog implementations) to match.  The desire 
to be consistent is actually the reason that the QtQuick.Dialogs MessageDialog 
always dismisses the dialog when any button is pressed (except for the Show 
Details… button, because that only makes a self-contained visual change inside 
the dialog, and doesn’t emit a signal).

(Just to review: if you instantiate a MessageDialog in QML, you might get a 
native dialog if it’s available (only on Android so far); otherwise if you are 
using a QApplication, widgets are available, so you will get a QMessageBox; 
only if neither of those options work, will it fall back to the QML 
implementation in DefaultMessageDialog.qml.  So you are more likely to get a 
message dialog which does dismiss on Help, even after applying patch 97372 
below.)

When a message dialog is open, and a user presses the Help button, what 
behavior provides the best usability?  My opinion is that if some help is going 
to open up in another window, it would be nice to be able to read the message 
dialog and the help side by side, especially if the purpose of the help is to 
clarify a choice that the message dialog is providing.  If pressing the help 
button dismisses the dialog, it is then too late to make the right choice, so 
the help is not particularly useful.

QDialogButtonBox can have a help button too, but in that case it is up to the 
application developer to connect to the signals (accepted, rejected and 
helpRequested) to dismiss the dialog or do something else.  Whereas in 
QtQuick.Dialogs.Dialog, the buttons are built-in (another design decision that 
we could re-visit), so the behavior is also built-in.  To be consistent with 
MessageDialog, Dialog also dismisses itself automatically when any button is 
pressed.  (That case is worse, because you could also have an Apply or 
RestoreDefaults button, and you probably don’t expect the dialog to be 
dismissed when those buttons are pressed either; but it does.)

On the other hand, if the message dialog is modal, the user may not be able to 
interact with the help.  But maybe the help is simple enough to fit on one 
page, so being able to see it is enough.

And if we change the behavior of such an old dialog as QMessageBox, someone 
will eventually complain, of course.  But if the developer wants the help 
button to dismiss the dialog, it’s also not very hard to connect to the 
buttonClicked signal to do that.

So I think maybe since it’s a behavior change, we should wait until 5.5; the 
purpose of this mail is to ask if anyone has an objection to changing it at 
all.  Or on the other hand, if anyone has been annoyed and needed to work 
around this problem for ages already.  ;-)

https://codereview.qt-project.org/97372 is the patch for QtQuick.Dialogs, which 
IMO should not go in until we can ensure that the behavior is consistent 
regardless of dialog implementation.

https://codereview.qt-project.org/97814 adds Help buttons to a couple of the 
widget examples, to demonstrate the differing behaviors.

The code which closes the dialog when a button is pressed is in 
QDialog::done(int r), so I guess that is where it will need to be made 
conditional on the role.

Another related issue is that we should probably be using the special Help 
button on OS X:  https://bugreports.qt-project.org/browse/QTBUG-34565
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers

[Rutledge Shawn]

Den 16 Sep 2014 kl. 9:31 AM skrev Reinio Topi:

I'd like to nominate Venugopal Shivashankar and Nico Vertriest as approvers in
the Qt Project. They are both documentation engineers and integral part of
the of Qt documentation team.

Venugopal Shivashankar:
https://codereview.qt-project.org/#/q/owner:veshivas,n,z
https://codereview.qt-project.org/#/q/reviewer:veshivas,n,z

Nico Vertriest:
https://codereview.qt-project.org/#/q/owner:vertries,n,z
https://codereview.qt-project.org/#/q/reviewer:vertries,n,z

Both Venu and Nico have been working on Qt for a long time (pre-Qt 5.0)
already, contributing numerous improvements to Qt documentation. Many people
rely on them for documentation and language reviews, and having them as
approvers would speed up documentation work and ease the review-burden on
other team members.

-Topi

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

[Development] Direct-lookup translation, even for English (was Re: [Interest] get english translation)

[Rutledge Shawn]

On 1 Sep 2014, at 8:32 PM, Thiago Macieira wrote:

 On Monday 01 September 2014 12:50:23 Graham Labdon wrote:
 Hi
 My application is internationalized, however, in some circumstances I need
 the English version of the string no matter what translator is being used.
 Anyone have any suggestions on how to achieve this?
 
 You have the English text. The way to get the English text from that is to 
 use 
 it as-is.
 
 Don't translate, don't transform it in any way.

Some projects like to use programmer shorthand for strings and then leave the 
final text up to a different team.  Such teams tend to be capricious and change 
the English text multiple times (PR and marketing reasons), so it's an 
advantage not to treat the English text as the key for looking up the 
translation.  (And then the shorthand can be written in any language the 
programmer likes, too.)

I had a previous job like that.  They had their own cross-platform 
cross-toolkit translation system, so I wasn't allowed to use tr() at all, and 
they convinced me that their way was better.  They wanted to have all the 
strings for all the languages inside the binary.  And there was a utility to 
generate an enum for the shorthand strings.  Imagine opening up Designer and 
creating a button, and setting its label to BUTTON_OK.  Then you run uic.  Then 
you post-process the generated header file and make it do something like 
tr(BUTTON_OK), which will use the enum to look up the actual string at runtime, 
in a fixed-length array in which all strings for a particular language are 
stored.

- Since the header modification is part of the build process, it costs the 
developer no time at all if the translation team wants to change the English 
text.  They do their work independently, and then the application is re-built. 

- At runtime, this kind of lookup is much more efficient than the usual Gnome 
and KDE ways of looking around the filesystem for separate translation files 
(but at the cost of bloating the binary somewhat).  

- It is clear to everyone when the translation mechanism is not working or 
there is an un-translated string: you see the enum shorthand strings instead of 
the correct strings - no need to wait for a non-English-speaking tester to 
discover it.

- There will never be a user who cannot use the app because it wasn't installed 
correctly and therefore the translation file was not found: the strings are 
guaranteed to be present as long as someone did the translation work before it 
shipped.

The current way of using separate translation files should be kept as a 
fallback mechanism though, so that people in countries which were neglected by 
the development team can still do their own translations.  This is the good 
part of the KDE way, that the translation work can be distributed to lots of 
people around the world.  But it's also possible that they could contribute 
their work back to the original git repo, so that some future build of the 
application will have those strings built-in.

I think it's a worthwhile goal that at least commercial Linux binaries ought to 
be self-contained and portable, so that there is no installation process beyond 
putting the binary in some directory which is in your path.  It wouldn't hurt 
if the free software community had the goal of zero-install binaries too.  The 
strings could be packaged as compressed resources, so the total space consumed 
is less.  And perhaps resources which are not needed for the current language 
could even be expunged from memory (at the cost that you then cannot switch 
languages dynamically).

But even if it were not for the enum-lookup implementation that they insisted 
on, our assumption that English needs no translation does not fit the 
multi-team workflow.  There is often an assumption that programmers cannot 
design UIs because they are not artistic people or because they don't have 
psychology degrees or haven't studied usability enough.  This is why we have 
separate tools for UI designers to use.  It's very similar to the way that some 
people assume that programmers cannot write good English either.  Stereotypes 
in general are wrong, and offensive to people with multi-disciplinary 
abilities.  Nevertheless we can probably agree that UI design and the wording 
of text are often subject to later revision; so it's useful not to choose a 
changing string as a lookup key, for the same reason that imperative code 
should not assume too much about the declarative structure of the UI.

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

Re: [Development] export gobal enums to QML

[Rutledge Shawn]

On 2 Sep 2014, at 8:36 AM, Bo Thorsen wrote:

 Den 02-09-2014 07:48, Salomon, Florian skrev:
 Hi,
 i’d like to know, if there is any possibility to export global enums
 (defined in a separate header file) to QML?
 #include “errcodes.h”
 Class A : QObject
 {
 Q_OBJECT
 Q_ENUMS(eErrorIDs)
 public:
 enum globalErrCodes eErrorIDs;
 }
 
 Hi Florian,
 
 No, you have to declare the enums directly in the QObject derived class. 
 The generated moc code won't work if you don't.

There's also Q_GADGET.  In QtQuick.Dialogs it is used to export the 
StandardButton enum separately.  (see qquickdialogassets_p.h)

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

Re: [Development] Why is libxcb needed if GUI is disabled in build?

[Rutledge Shawn]

libX11 also ends up being linked into the eglfs platform plugin.  Even when 
configured with -no-xcb.  I must be missing something, otherwise how could any 
of the non-X11 embedded or Raspberry Pi stuff work…  Of course you can build on 
a machine that doesn't have the libs or headers available; I got that to work 
once.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build failure: GUI example being compiled even with -no-gui -no-widgets

[Rutledge Shawn]

On 29 Aug 2014, at 2:02 AM, Mandeep Sandhu wrote:

 All,
 
 I'm getting a build failure when the hellowindow example is being compiled.
 
 Configure options:
 $ ../qt5/qtbase/configure -opensource -confirm-license
 -developer-build -release -no-gui -no-widgets -no-cups -no-dbus
 -no-xcb
 
 Build output:
 ...
 cd hellowindow/  ( test -e Makefile ||
 /home/msandhu/work/qt5base-x11/bin/qmake
 /home/msandhu/work/qt5/qtbase/examples/opengl/hellowindow/hellowindow.pro
 -o Makefile )  make -f Makefile
 Project ERROR: Unknown module(s) in QT: gui gui-private
 ...
 
 As you can see, I've disabled GUI (and widgets) in my configure
 options and its still trying to build a GUI example. Is this a bug or
 am I missing something obvious?

QWindow is a GUI feature.  You can probably still use -no-widgets, but not 
-no-gui.  In any case, that example does not link with widgets even if they 
have been built: you can verify with ldd that the only Qt libs that it links 
with are libQt5Gui.so.5 and libQt5Core.so.5.  Therefore running that example 
will not load the widgets lib into memory.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QStorageInfo

[Rutledge Shawn]

On 29 Aug 2014, at 1:01 PM, Иван Комиссаров wrote:
 29 авг. 2014 г., в 14:46, André Somers an...@familiesomers.nl написал(а):
 Thiago Macieira schreef op 29-8-2014 06:32:
 Could be, but I want to be really clear that it should only be local, 
 remote and unknown. I don't want other types like removable 
 magnetic, removable optical, removable solid state, virtual 
 regular filesystem, virtual special, etc. 
 Just wondering, but what exactly is the problem with providing more 
 details if such details are available? A combination of flags local, 
 removable and optical would be quite informative.
 
 André
 
 The problem is you can't rely on that information. For example, optical is 
 totally useless on Linux (we can't get that info).

The kernel knows, and so does udevd (http://en.wikipedia.org/wiki/Udev) (it has 
to know in order to create the device node, /dev/sr0 on my system).  But 
talking to it involves dbus (and we already discussed the problem that it's a 
dependency).  My last suggestion was that maybe we can dynamically load 
/usr/lib/libudisks2.so or /usr/lib/libudev.so.1, either of which has plain C 
API, right?  (Use the dlopen / QLibrary technique, and try not to use APIs that 
are too new or likely to change later, if there are any such.)  Or we can use 
qdbus via a plugin, or by whatever means such that not having qdbus or not 
having udevd is not fatal.  If any of that fails, it merely means we don't know 
the type of the disk, and that's what we have the zero flag for.  It should 
work most of the time.  But I think udisks only takes care of local volumes, so 
if there is a drive that udisks doesn't know about, it could be taken as a clue 
that it might be a network drive.  But the current code already shows the 
protocol as the filesystem if it's a remote drive.

http://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Drive.html#gdbus-property-org-freedesktop-UDisks2-Drive.MediaCompatibility

What about btrfs subvolumes, does udisks know about those too?

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

Re: [Development] QStorageInfo

[Rutledge Shawn]

On 29 Aug 2014, at 4:23 PM, Thiago Macieira wrote:

 On Friday 29 August 2014 18:05:30 Иван Комиссаров wrote:
 Thiago was against introducing a QStorageInfoPlugin. However, i thinkg we
 can try to dopen a udisks library. But why not simply try to link to it on
 Linux? Are there any linux versions that doesn't have udisks now? 
 
 Yes.
 
 And those libraries will open a D-Bus connection that we can't reuse, so 
 that's more system resources spent.

Well it's not like there isn't a technical solution to using qdbus instead.  
(Would multiple instances of qdbus share resources?  If we can do that, why 
does udisks not do it?)  But it will take memory to load qdbus too, whereas 
libudisks2 may already be loaded.  And the fact that dbus does IPC with sockets 
is out of our control.

But I guess I will stop thinking about it if everybody's OK with leaving out 
such obvious features.

 I'd still prefer to leave the detailed information to Solid. It's there 
 already, has done that job for years and it doesn't depend on anything but Qt 
 itself.

Maybe we didn't need to add QStorageInfo at all then?  Solid is so universal 
that every app can use it on every platform?  I suppose on non-Linux platforms 
though, you'd typically have to ship it along with the app (along with Qt 
itself).  On my system it's a whole megabyte.  (And still depends on Qt 4, but 
that will change eventually.)

I guess it has happened before that we got interested in doing something that 
KDE already did.

We could remove QStorageInfo (it's not released yet).  Or solid could come to 
depend on it, and maybe shrink a bit by removing code that duplicates what ours 
is doing.  (Doesn't seem likely though, does it…)

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

Re: [Development] QStorageInfo

[Rutledge Shawn]

On 28 Aug 2014, at 8:06 AM, Lorn Potter wrote:

 On 27/08/2014 9:56 pm, Bo Thorsen wrote:
 Den 27-08-2014 10:40, Knoll Lars skrev:
 I agree that there are many complex corner cases where we can’t exactly
 know. But let’s not forget about the common case, where we actually can
 determine whether the file system is local or not. I think we all agree
 that it’s very helpful to many applications to know this. So saying we
 don’t help at all here because we can’t solve 100% of the problems is
 wrong and not what Qt is about.
 
 So I am all for a tri/quad state here. Local, Remote  Other/Unknown. And
 maybe a Special for things such as procfs. Let’s be conservative with it
 and rather have a bit too much in Other/Unknown, but let’s also help
 people that need the information and give the right answer for the common
 cases.
 
 So I’d say let’s add the enum and getters for it. We can have a default
 implementation that returns Unknown, and then reimplement it on each
 platform to do something more sensible.
 
 I haven't seen anyone ask for info on what type a drive is, if it's not
 local. André did, but when he explained later, he said that what they
 check for is if it's a local drive or not.
 
 The two use cases I saw in this thread were both of the type where they
 checked that storage was on a local drive because something else would
 be too slow. This assumption might be wrong in some cases anyway, so I
 hope they only warn that it might be bad.
 
  From following the discussion, it sounds like what actually be needed
 is a isLocal() method that return yes, no or unknown/somethingelse.
 That's a bit simpler and has the advantage that we won't have to expand
 on it to be exact when people come up with weird new hybrid solutions.
 
 I agree something simpler like this would be better. As mentioned 
 previously, detecting remote drives on all platforms is not fool proof, 
 and hard to implement and I am not sure it's worth trying to get all the 
 niche cases fixed.
 
 Heck just figuring out if its a usb drive is not 100% for sure.

But isLocal is the wrong name for something that isn't a bool, and also implies 
that local drives are normal or preferred (which is a matter of current 
fashion, while the future is debatable).  If we want an enum, maybe we'd better 
go back to calling it some sort of type flag, but only have 3 possible values 
for now?  It is more extensible: we can add new flags whenever we are sure that 
they can be set reliably on all platforms.  And ORing them is more extensible 
than making them mutually exclusive, because we don't know what flags we will 
add later.  So let's have zero be the unknown, and the type of this property 
should be QFlags. What should its name be?

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

Re: [Development] QStorageInfo

[Rutledge Shawn]

On 28 Aug 2014, at 4:03 PM, Thiago Macieira wrote:

 On Thursday 28 August 2014 06:57:30 Rutledge Shawn wrote:
 But isLocal is the wrong name for something that isn't a bool, and also
 implies that local drives are normal or preferred (which is a matter of
 current fashion, while the future is debatable).  If we want an enum, maybe
 we'd better go back to calling it some sort of type flag, but only have 3
 possible values for now?  It is more extensible: we can add new flags
 whenever we are sure that they can be set reliably on all platforms.  And
 ORing them is more extensible than making them mutually exclusive, because
 we don't know what flags we will add later.  So let's have zero be the
 unknown, and the type of this property should be QFlags. What should its
 name be?
 
 I don't want flags because this will lead people to assume that only local 
 and 
 remote are mutually exclusive and then write code that assume it's always one 
 or the other.
 
 I want an API that makes it clear that detection may fail or be ambiguous. 
 Call it storage locality or storage remoteness or, hopefully, some better 
 name.
 
 The more types we start to add, the more difficult it becomes. We can provide 
 an 
 extra attribute for those types that are determined to be local to report 
 whether they're fixed, removable, virtual or unknown.

There could be a hybrid (maybe it's even common already… I'm not a user of 
commercial cloud storage yet so don't know): cloud storage with a big local 
cache, so that many files are available offline, but not everything.  In the 
database use case maybe it should be considered local, because performance will 
be OK, but it's not strictly true.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Linux release binaries too old

[Rutledge Shawn]

On 26 Aug 2014, at 10:45 AM, Blasche Alexander wrote:
 This leaves me with only one option. We have to deploy Bluez 4.101 headers to 
 11.10 machines.  It doesn't even have to be a full backport as the dependency 
 is a compile time dependency.  My tests have shown that calling ::connect() 
 with an extended sockaddr_l2 struct doesn't seem to cause any trouble on 
 those older distros. 

While you're at it, maybe you could get around to deploying newer XInput 
headers and libs too?  QTBUG-35583 has been unresolved for a really long time.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QStorageInfo

[Rutledge Shawn]

On 26 Aug 2014, at 8:19 AM, Bo Thorsen wrote:
 Which is probably the way people will have to go about doing it. Since 
 this distinction isn't reliably available on Linux and it is on Windows, 
 then the proper way would be to be able to get the native handle on the 
 drive to call Windows methods on it.

But see again what I wrote a couple of days ago: QStorageInfo should not report 
that a network drive is NTFS.  On Linux, an NFS mount has fileSystemType nfs. 
 On OS X, if I mount a Windows drive and run the storageview example, that 
drive has fileSystemType smbfs.

So even after over-simplifying, we already have API which is inconsistent on 
Windows compared to the other platforms.  This is making the problem of how to 
identify network drives worse, so IMO some kind of fix needs to be done.  I 
wrote up https://bugreports.qt-project.org/browse/QTBUG-40980 but I didn't find 
a Windows API to directly give us that string: the network protocol used to 
mount the drive.  see 
http://stackoverflow.com/questions/10800616/determine-protocol-of-a-network-drive

This version of the patch was the last one which had RemoteVolume as a 
VolumeTypeFlag:

https://codereview.qt-project.org/#/c/73945/41/src/corelib/io/qvolumeinfo.h

and here

https://codereview.qt-project.org/#/c/73945/41/src/corelib/io/qvolumeinfo_win.cpp

is how to use GetDriveType on Windows.  (Even the current version uses it 
internally and doesn't expose the result.)  And here (line 318)

https://codereview.qt-project.org/#/c/73945/41/src/corelib/io/qvolumeinfo_unix.cpp
 

is a (primitive) way of consulting a list of known network types on Linux.  
It's unfortunate to need such a list at all, but if there really is no other 
way to find out, maybe it's not so bad?  I don't worry much about the 
maintenance burden because new filesystem sharing protocols are not invented 
very often, and anyone can submit a patch to add a new one to the list.

After the harrowing review process (92 rounds of patches over 9 months!) the 
VolumeTypeFlag didn't end up in the final patch.  It's a credit to Ivan that he 
had the patience to finally get the current form of QStorageInfo into 5.4 
branch at all.  But obviously some users have a need to distinguish network 
drives from local ones anyway, so IMO there's nothing wrong with writing 
another patch to make this info available again.  Of course trying to 
distinguish all the other types: internal, removable, optical, and RAM drives, 
would probably be futile on many platforms.  We have several bools already, so 
how about adding a bool isRemote() accessor?

If we don't do that, then we know what to expect: some developers will try to 
make their own lists of network drive types (incomplete of course) and check 
the fileSystemType against the list.  (And it won't even work on Windows.)  In 
a global way of thinking it's much worse to impose this burden than to take it 
upon ourselves.  And yet on Windows  GetDriveType can already tell us whether 
it's a network volume or not.  That is what the original poster is asking for, 
and it doesn't seem so hard to provide.

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

Re: [Development] QStorageInfo

[Rutledge Shawn]

25 авг. 2014 г., в 14:20, Matthias WALTER 
matthias.wal...@neuf.frmailto:matthias.wal...@neuf.fr написал(а):

Hello,

I see the preview doc about « QStorageInfo » on this website : 
http://doc-snapshot.qt-project.org/qt5-5.4/qstorageinfo.html#fileSystemType

But I don’t see anything about the “type” of the drives : internal, external, 
remote, …

Will it come in the near feature ?


On 25 Aug 2014, at 12:30 PM, Иван Комиссаров wrote:

No, not in the near future. Implementation of this functionality is flawed for 
Linux/Unix and i don't know (yet) how to implement it in the other way.

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

It seems that on Windows it will say what is the remote filesystem type (e.g. 
ntfs) whereas on Linux it will tell you the type of mount (e.g. nfs).  Maybe it 
would be more appropriate if the type was CIFS or SMB on Windows too, because 
remote mounting is an abstraction: you shouldn't care what is the type of the 
remote FS, but knowing that it is a remote drive would be useful.

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

Re: [Development] [Releasing] HEADS UP: Qt 5.4 feature freeze - branch created

[Rutledge Shawn]

On 10 Aug 2014, at 5:36 PM, Иван Комиссаров wrote:

 I've done renaming to QStorageInfo 
 (https://codereview.qt-project.org/#/c/73945/); but i don't have time to 
 review correctly and build on Mac (however, it seems it should compile). 
 Also, i'm not able to compile on Windows at all and i will be able to compile 
 on Linux tomorrow.
 
 Can someone try building for win?

We're trying to integrate again.  It was working on Windows on Friday.

I think we should also have Ivan's example in 5.4 because it shows how to use 
the new class.  Any objections?  

If not, can we have this patch retargeted to 5.4 branch as well?

https://codereview.qt-project.org/#/c/74323/

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

Re: [Development] QTabletEvent in QML

[Rutledge Shawn]

On 11 Jul 2014, at 10:34 AM, Dean Floyd wrote:

 I have been using the Wacom Cintiq HD 24 Touch for some of my research 
 efforts, and I have tried to use MultiPointTouchArea to handle the touch 
 events, however, this has not lead to a great deal of success. To remedy the 
 situation, I decided to use the Wacom SDK to intercept these events and 
 create my own QML component to do what MultiPointTouchArea usually does, 
 which isn't awfully fast with the signal emitting and all, but sufficiently 
 smooth - I use touch events to control a camera in a 3D scene graph.

Yeah there is QTBUG-39572 for Linux, but if you are using the Wacom SDK I 
suppose you must be on Windows.  We plan to get touch working with Wacom touch 
devices.  I guess your Cintiq is different than the Bamboo relative-touch 
device (more like a touchpad) which I test with sometimes.

 Now, I would like to draw using the Wacom Pen, and, although I can do this 
 through QWidget::tabletEvent(), I was not able to find a suitable QML 
 component which offers the same tabletEvent() functionality. I see some 
 examples using MouseArea to draw with a pen, but I would like to be able to 
 distinguish between a mouse and a pen device. In other words, I would like to 
 intercept QTabletEvent events within QML. Is there a way to do this? If not, 
 could somebody confirm that this is not possible? I would highly appreciate 
 any help. Thank you.

No there is no support for QTabletEvents in QtQuick 2 yet.  I experimented with 
it during a hackathon last year; the patch which adds support for them is

https://codereview.qt-project.org/#/c/74202/

But after you've got the events in QtQuick, what next?  We are also missing 
public API for creating and manipulating polylines and ink objects.  You 
could take the events individually and then try to use Canvas in QML, or 
implement your own means of using QPainterPath in C++, or use Qt.labs.shapes 
from 

https://codereview.qt-project.org/#/admin/projects/playground/scenegraph

I tried to use the latter approach.  It depends whether you want to create 
vector shapes that can be manipulated later, in small quantities and 
unfortunately without antialiasing; or to have an art-oriented painting 
program, in which case you might want to try Krita.  It will be ported to Qt 5 
eventually.  But I'm thinking more about vector drawing...

We don't have polylines (sequences of lines, arcs, Bezier curves etc.) in Qt 
Quick because we need to figure out how to render them antialiased (maybe even 
without relying on MSAA) and also animatable.  But what would the code look 
like to apply an animation to one of the control points within a polyline?  You 
wouldn't want every point to be a QObject just to be able to make the 
occasional binding; and usually the points would come from non-QML data sources 
like sequences of tablet events, or SVG paths.  A JS API for appending points 
to a path is not enough.

An even stickier problem is how to serialize the Item graph in memory (after 
you have drawn some new shapes with your tablet) into a QML file.  I tried and 
got a hacky incomplete solution working, but it became evident that QML just 
isn't designed for that.  So if you want to create a vector drawing program in 
the short term, you need to create your own C++ model anyway.  So then you 
might as well handle the tablet events in C++ too.  To integrate with Qt Quick 
you could wrap the whole drawing renderer into a QQuickItem subclass which 
implements its own updatePaintNode() to render the vector shapes, or have one 
of those per shape.

So there are several problems left to solve, and then maybe there's a chance 
Qt.labs.shapes could be converted into something worth shipping with Qt. Maybe 
we could even build a complete framework for vector drawing applications.  I 
would like to, because as was just discussed in another thread, GraphicsView is 
at this point the easier solution to code up this type of use case, but it's 
older and isn't really the way forward for the future.

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

Re: [Development] Make WebKit an add-on

[Rutledge Shawn]

On 20 Jun 2014, at 08:32, Knoll Lars lars.kn...@digia.com wrote:

 Hi,
 
 Currently Qt WebKit and Qt WebKit Widgets are marked in our documentation
 as Qt Essentials. I’d like to propose to move them to the add-on category
 for 5.4.
 
 There are several reasons for that, the main ones being:
 
 * Qt WebKit is not supported on Android, iOS and WinRT
 * We can’t develop it much further (esp we can't update with newer
 versions of webkit), as the webkit project has moved into a different
 direction
 * Qt WebEngine is going to replace it over time
 
 Unless someone has a very good reason against changing this, I’d like to
 change the status of the 2 modules in time before the 5.4 branch is being
 created.

Will all of our own usage of WebKit (such as in Assistant and Creator) be 
replaced with WebEngine in time for 5.4?

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

Re: [Development] QtNetwork QtCS Session

[Rutledge Shawn]

On 13 Jun 2014, at 17:26, Thiago Macieira thiago.macie...@intel.com wrote:

 Em sex 13 jun 2014, às 05:52:57, Rutledge Shawn escreveu:
 It makes no sense to build Qt without any platform plugin, for example.
 The  plugins must stay with QtGui, which implies that QtCore, QtNetwork
 and QtDBus must too.
 
 But maybe the platform plugins’ dependencies on d-bus could be made optional
 and resolved at runtime, so that some features are missing if it is not
 available but otherwise they continue to function?
 
 I don't see how they'd do that. In order to dlopen anything, we need a C API. 

Supposedly it can be done even with C++, with some caveats:

http://stackoverflow.com/questions/1067346/alternatives-to-dlsym-and-dlopen-in-c
http://tldp.org/HOWTO/C++-dlopen
http://www.linuxjournal.com/article/3687

I tried the code from the last one.  Seems the main idea is that if you got a 
C++ object from the dlopen’d library, you are free to call methods on it (as 
long as the methods were declared in base classes to which the compiler had 
access already, and I suppose that could cause some code duplication), but you 
need an extern “C function to get the object.  Maybe the plugins' usage of 
D-Bus could be made to fit that pattern then?

Sorry if I’m repeating an idea that was previously shot down, seems like it 
must have been brought up by now.  But I’ve always had a conceptual problem 
with the idea that dlopen doesn't work with C++.  If the world just needs a 
smarter way of doing run-time linking on-demand instead of at the application 
startup time, why wasn’t it written by now?

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

Re: [Development] QtNetwork QtCS Session

[Rutledge Shawn]

On 13 Jun 2014, at 03:24, Thiago Macieira thiago.macie...@intel.com wrote:

 Em qui 12 jun 2014, às 12:21:32, Jędrzej Nowacki escreveu:
 On Thursday 12 of June 2014 11:47:49 Oswald Buddenhagen wrote:
 On Thu, Jun 12, 2014 at 10:40:03AM +0200, Jędrzej Nowacki wrote:
 Hi,
 
  Thanks for sending the notes :-) I have a question about this point:
 Move QtNetowrk into its own git modules
 
   Thiago: Network cannot swapped out into its own module, due to dbus
   reqiring it in the future
 
 Why dbus can not be moved to a separate module or together with
 networking
 stack?
 
 because some plugins depend on dbus.
 
 Ah, of course
 
 if we modularize the repos more, we need to go full monty and modularize
 *everything*.
 i really wouldn't want to do that with the current build system.
 
 I guess it would be a nice long term goal.
 
 I'm sorry, that's pointless. I don't think that's a nice goal at all.
 
 The modules were invented so that we'd have related libraries together and 
 they could release at different pace if required. It's technically supposed 
 to 
 be possible to use only a subset of the modules.
 
 It makes no sense to build Qt without any platform plugin, for example. The 
 plugins must stay with QtGui, which implies that QtCore, QtNetwork and QtDBus 
 must too.

But maybe the platform plugins’ dependencies on d-bus could be made optional 
and resolved at runtime, so that some features are missing if it is not 
available but otherwise they continue to function?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Rutledge Shawn]

On 29 Apr 2014, at 7:51 PM, Alan Alpert wrote:

 (3) Document that accessing ids from other .qml files without any interface 
 (just relying on the fact that they are in the context) creates hard to 
 maintain QML code.
 
 Agreed (honestly, it should already be there, I guess
 https://bugreports.qt-project.org/browse/QTBUG-20453 was never
 finished...).
 
 Again, we have some rough plans for a .pragma strict. Which should ban this.

What exactly do you want to ban and what are the best alternatives?  Without 
any interface implies there is a right way to share.  

- attached properties need to be created in C++ and are anyway unintuitive
- singletons need to be created in c++ and don't restrict the scope
- objects can be put in the context in c++
- a shared JS file could be used but that's not declarative
- there is no extern keyword; would it make sense to have something analogous?  
but like singletons everything would be in the same name space
- combined use of parent, and the dot operator to drill down to something not 
directly accessible, quickly becomes ugly

In practice I'm often not sure about the scoping rules, so when something that 
I think should be accessible is not, I'm often not sure if that is a bug but 
just start looking for another way to do it (which sometimes can be clumsy).

https://bugreports.qt-project.org/browse/QTBUG-38591 doesn't seem to have a 
really satisfying solution at first glance…

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

Re: [Development] [Interest] GridView

[Rutledge Shawn]

On 30 Apr 2014, at 2:37 AM, Joshua Kolden wrote:

 I get strange scrolling behavior with QML's GridView on OSX with with a 
 touchpad doing the typical two finger scrolling gesture.  Click drag seems to 
 be doing what two finger click drag should be.  Is this a bug or am I missing 
 a step?

Click drag is supported for use with a plain old mouse, although I've always 
thought that's a dubious use case given that most mice have wheels and given 
that mouse emulation on touchscreens ought to go away over time.  The OSX 
trackpad emulates a wheel when you flick with two fingers, so that should work 
too.

 Also I have a large data base (orm) of image assets that I display in the 
 grid view and get periodic updates from the server with ‘windows’ of data 
 about 1000 items long.  Any tips on segmenting ListModels to allow for 
 continuos scrolling of large datasets like this?  Is it safe to just let the 
 y displacement accumulate to very large numbers?

I don't have experience with that yet.

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

Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Rutledge Shawn]

On 29 Apr 2014, at 3:34 PM, m...@rpzdesign.com wrote:

 Is there a class diagram on the current code base?

You can run doxygen on it and get the automatically-generated ones, but AFAIK 
there has never been any emphasis on doing internal documentation, only 
user-facing documentation.  I don't know all the reasons why.  For one thing we 
don't have an agreement on where to put hand-created internal docs in the git 
tree.  Probably nobody wants to put a lot of time into doing it by hand anyway, 
and it would tend to stay out of date unless it was automatically generated.  
From experience I can say that they aren't quite as useful for everyday 
reference as you would think, unless they are integrated into your workflow 
interactively instead of just being a static diagram that you hang on the wall 
(even if you could find a big enough sheet of paper for a Qt class diagram). 
And diagrams generated by static code analysis don't show all the object 
relationships that will exist at runtime.  It could be introspected at runtime 
though.

Doxygen is good at generating class diagrams, but we can't use it for all docs 
because there has been so much divergence in the feature sets that doxygen 
cannot generate our user docs.  But generating class diagrams automatically 
with some kind of tool (probably built on dot the way doxygen does it) ought 
to be doable.  (And then where would we put them…)  One big diagram would be 
too complex, but Doxygen does a good job of using just the relevant subtree on 
each doc page and letting you click to navigate docs.

Another idea is maybe Creator could have dynamically generated diagrams which 
can be used to navigate the code, the way you can do in Eclipse.  But a 
prerequisite would be better support for diagramming applications in Qt Quick 
2.  That's one of my long-term background tasks: it would be a good start to be 
able to draw connected-node diagrams by hand.  (But that in turn depends on 
having a proper path element.)  Automating it should then be doable too.

 This would help newbies when trying to contribute to the refactoring
 strategy.
 
 The code supporting the QML, JS, and C++ must be layered and sensibly
 separated so that people can opt-in on various parts at compile/link time.

I would like that too; at least the scene graph should be separable from Qt 
Quick so that other language bindings become possible. The usual answers I've 
heard to that proposal are

1) the scene graph is documented public API (it's just that there is no way to 
link it without the JS engine and the rest of QtQuick) 
http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html

2) https://codereview.qt-project.org/#change,52682 will break that link to make 
a standalone scene graph (but the patch is out of date and doesn't apply 
cleanly nowadays).  It has been claimed the patch can't be integrated because 
it's incompatible with building the whole integrated Qt the way we usually ship 
it.  But I hope we get to a point where it can be.

3) you would lose so much functionality that it becomes uninteresting, or at 
least you have to redo a lot of work as part of the other language binding.  
Much functionality is implemented in the Qt Quick objects: input event handling 
(including gestures, since we don't have a centralized gesture recognition), 
bindings, animation etc.  At the same time, if you intend to get rid of 
baggage, you cannot do without the qtcore and qtgui modules, even if your 
application doesn't need big parts of it.  But qtgui gives you cross-platform 
windows and opengl and events, you just have to decide all over again what to 
do with the events (and from experience, this is tricky to say the least)

Nevertheless, I still think it ought to be possible to build the scene graph 
without QtQuick, just for what it's worth.

Trying to refactor and separate modules at other points to depend less on 
JavaScript will run into these issues: 

1) the JS engine would get loaded into memory anyway, because QtQuick 
increasingly depends on the JS object model.  

2) we value the efficiencies to be gained by tight coupling.  JS objects are 
more efficient than QObjects and QVariants, so we expect the coupling to become 
tighter rather than looser.

3) QML and Quick implementation details are private so they can be free to 
evolve

But can we separate the object model from the interpreter, and make a nice C++ 
API for that?  I don't know, but it seems daunting, and doing it too early 
would limit the evolution too much.  Anyway the hypothetical API would only 
give you a base on which to build applications (or alternative language 
bindings) in verbose C++ instead of clean-looking QML, and some useful 
functionality would be left behind.

(disclaimer: much of the above is personal opinion and speculation about which 
others will disagree)

 When respected people like Thiago Macieira put forth the idea that
 there is no public API at the C++ level for Scene Graph and 

Re: [Development] Question about Qt's future

[Rutledge Shawn]

On 28 Apr 2014, at 9:32 AM, Gunnar Sletta wrote:

 
 On 28 Apr 2014, at 07:53, Peter Kümmel syntheti...@gmx.net wrote:
 
 ...
 
 ATM the problem is to get started because I don't know much about the
 current architecture of the graphic stack.
 
 http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html
 http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
 
 Any hints where to start for a first hello world?
 
 I started on this some time ago, but it has been sitting there ever since as 
 the interest for splitting it out has been non-existent. It will for sure not 
 compile, but it contains the general idea :)
 
 https://codereview.qt-project.org/#change,52682

That was a good patch to have around, but it hasn't applied cleanly for some 
time.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] utf-8 BOM and parsers

[Rutledge Shawn]

On 14 Apr 2014, at 2:26 PM, Simon Hausmann wrote:

 We have various parsers in Qt that parse source code and do things with it, 
 such as the QML parser…

I was just baffled by this issue this morning for a couple of hours:  tried to 
port some QML code that was working fine with Qt 5.2.1 to 5.3.0 and got a 
nonsense error message that it expected a numeric value at row 1 col 1 in the 
file.  I didn't suspect the BOM until I showed the message to someone who 
happened to have seen this happen before.  So I can say that as of this moment 
we definitely are not compliant with Postel's Law  
(http://en.wikipedia.org/wiki/Robustness_principle): we should ignore the BOM 
rather than being surprised by it, but also not require it.  I suppose others 
have a better idea where to make this change, but if the lower layers insist on 
keeping it, then it will need to mean the parser should ignore it (the first 
part of Postel's Law).  This needs to be fixed before we ship, otherwise it 
will be a show-stopper for someone if they can't figure out what this 
impertinent error message really means.  I never intentionally put that BOM 
there, so it must be that some old version of Creator or some other editor did 
it.  I do agree with the principle that BOMs should be avoided, because UTF-8 
is a good default assumption about the code page if it's otherwise unknown.

Are the parsers still generated by qlalr?  Then maybe the fix could go there.

It might also be a good idea for Creator to strip the BOM, or at least warn 
about it, if it's really an inadvisable thing to ever want in a source file 
(second part of Postel's law).

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

Re: [Development] Harmonizing the Qt 5.x Documentation

[Rutledge Shawn]

On 13 Apr 2014, at 8:10 PM, André Pönitz wrote:

 Shawn wrote:
 On 2 Apr 2014, at 6:07 PM, Ariel Molina wrote:
 
 Please whatever you do, do not break this anymore, the current
 state is already messed up.
 
 I agree.  But I think the idea was to change it one last time and then 
 never change it again, and the docs that google finds should be always
 the latest rather than a particular version.  I hope that goal is achieved...
 
 I hope the same, and hope dies last... 
 
 Experience is another thing, though. Judging from the last half-dozen or so
 changes redirection worked better in theory than in practice.

Maybe we should be doing this

https://support.google.com/webmasters/answer/139066?hl=en

link rel=canonical href=…

Not that I know much, just now googled how to do that...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQuickComponents ComboBox with QEglFSWindow

[Rutledge Shawn]

On 11 Apr 2014, at 10:15 PM, Matt Broadstone wrote:

 Hi,
 We're experiencing an odd crash while running our Qt Quick application in a 
 VirtualBox session using eglfs on the framebuffer. The application works 
 perfectly passing the '-platform eglfs' options, however, when we try to use 
 a ComboBox we get a segfault/qFatal, with the resulting backtrace (only first 
 twelve frames included for brevity): 
 
 #0  0x7eff7c041389 in raise () from /usr/lib/libc.so.6
 #1  0x7eff7c042788 in abort () from /usr/lib/libc.so.6
 #2  0x7eff7c956895 in qt_message_fatal (context=..., message=...) at 
 global/qlogging.cpp:979
 #3  QMessageLogger::fatal (this=this@entry=0x7fff32b96030, 
 msg=msg@entry=0x7eff7768e380 EGLFS: OpenGL windows cannot be mixed with 
 others.) at global/qlogging.cpp:384
 #4  0x7eff7766cfb7 in QEglFSWindow::create (this=this@entry=0x1db8030) at 
 qeglfswindow.cpp:115
 #5  0x7eff7766b60e in QEglFSIntegration::createPlatformWindow 
 (this=optimized out, window=0x1db66f0) at qeglfsintegration.cpp:122
 #6  0x7eff7d03180b in QWindow::create (this=this@entry=0x1db66f0) at 
 kernel/qwindow.cpp:480
 #7  0x7eff7d032150 in QWindow::setVisible (this=0x1db66f0, 
 visible=optimized out) at kernel/qwindow.cpp:426
 #8  0x7eff6c888d6a in QQuickPopupWindow::show (this=this@entry=0x1db66f0) 
 at qquickpopupwindow.cpp:95
 #9  0x7eff6c888579 in QQuickMenuPopupWindow::show (this=0x1db66f0) at 
 qquickmenupopupwindow.cpp:57
 #10 0x7eff6c884efb in QQuickMenu::__popup (this=0x1bff2e0, x=optimized 
 out, y=optimized out, atItemIndex=0) at qquickmenu.cpp:403
 #11 0x7eff6c897f53 in QQuickMenu::qt_static_metacall 
 (_o=_o@entry=0x1bff2e0, _c=_c@entry=QMetaObject::InvokeMetaMethod, 
 _id=_id@entry=22, _a=_a@entry=0x7fff32b96550) at .moc/moc_qquickmenu_p.cpp:227
 #12 0x7eff6c898427 in QQuickMenu::qt_metacall (this=0x1bff2e0, 
 _c=QMetaObject::InvokeMetaMethod, _id=22, _a=0x7fff32b96550) at 
 .moc/moc_qquickmenu_p.cpp:330
 
 There is some mention on the i.MX6 wiki page about multiple windows 
 (http://qt-project.org/wiki/i.MX-6), but that appears to be related to mixing 
 Quick views and widgets, which we are not doing. There also seems to be an 
 existing ComboBox bug (https://bugreports.qt-project.org/browse/QTBUG-35989), 
 but this looks like it's quite different. 
 
 Any insight would be appreciated, I just wanted to do some further 
 investigation here before creating the bug report.

What version do you have?  Looks like the combo box is trying to create another 
window for the dropdown list, and we're not allowed to have more than one 
window on eglfs.  I don't think it should be doing that anymore on platforms 
where it's not supported.


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

Re: [Development] Categorized logging inside Qt

[Rutledge Shawn]

On 10 Apr 2014, at 7:20 PM, Frederik Gladhorn wrote:

 Hi all,
 
 I just started to port accessibility to the new and shiny categorized logging.
 http://blog.qt.digia.com/blog/2014/03/11/qt-weekly-1-categorized-logging/
 
 I'd propose we decide on a certain style of declaring categories.
 
 A quick grep shows that we already have some variety, I'd like to unify this 
 before Qt 5.3 is out of the door. I actually saw a patch adding DBG_FOOBAR as 
 new category, that made me wonder about which style we should use.

I think the pattern is OK though: all uppercase, with a prefix like DBG and try 
to keep them as short as possible since they get repeated all over.

I guess we shouldn't ever put Q_DECLARE_LOGGING_CATEGORY declarations in public 
headers, right?  Or would it be an advantage to expose a few so that 
applications can send messages to a few common, documented categories?  If not, 
then the pattern should probably be to put them in private headers so that they 
can be used across multiple modules.  E.g. in qtdeclarative I have a patch to 
add qt.quick.touch, qt.quick.mouse, qt.quick.focus etc. to qtquickglobal_p.h 
because I expect that tracing handling of touch events etc. will eventually be 
pervasive in quite a few classes, although for now it's only used in 
QQuickWindow.  Historically I keep writing patches to add log messages over and 
over again, and never commit them.  It will save some work later to have these 
nicely organized into categories that can be enabled any time, even when a user 
reports some bug in the field.  I'm also worried about the runtime and memory 
cost of having them always there… but we were told not to worry.  ;-)  I hope 
it's true.

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

Re: [Development] Categorized logging inside Qt

[Rutledge Shawn]

On 11 Apr 2014, at 10:11 AM, Poenitz Andre wrote:

 
 shawn.rutle...@digia.com wrote:
 On 10 Apr 2014, at 7:20 PM, Frederik Gladhorn wrote:
 
 Hi all,
 
 I just started to port accessibility to the new and shiny categorized 
 logging.
 http://blog.qt.digia.com/blog/2014/03/11/qt-weekly-1-categorized-logging/
 
 I'd propose we decide on a certain style of declaring categories.
 
 A quick grep shows that we already have some variety, I'd like to unify this
 before Qt 5.3 is out of the door. I actually saw a patch adding DBG_FOOBAR 
 as
 new category, that made me wonder about which style we should use.
 
 I think the pattern is OK though: all uppercase, with a prefix like DBG and 
 try to keep
 them as short as possible since they get repeated all over.
 
 We tend to avoid abbreviations, so DBG instead of DEBUG looks odd.
 
 Your reasoning that it's REPEATED ALL OVER also MAKES ME THINK
 that USING ALL CAPS might be NO GOOD IDEA as it gives ME the 
 feeling the code is constantly SHOUTING AT ME.

Not having all caps would be fine, but I still think they should be short, and 
don't see a problem with abbreviations because the context is obvious; it 
doesn't obscure the meaning like making a member variable or function name too 
short would do.  qCDebug is already an abbreviation for Qt categorized logging 
of the debug variety.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qt5 dbus on mac

[Rutledge Shawn]

On 4 Apr 2014, at 7:19 PM, Nancy Feng (defeng) wrote:

 I tried to build qt5 with dubs on Mac OS X. I installed dbus from 
 Macport, but when building qt5, it still complains not able find dbus. If I 
 let it go by -continue option, build fails with unsatisfied dubs headers.
 
 Any instructions to build qt5 on mac with dbus module? Also how to get the 
 satisfied dbus build dependences? 

I have dbus installed from homebrew, and tried the remotecontrolledcar example 
on OSX.  qtdbus was already built, and the example caused the session daemon to 
start up, so it worked well.

For me the includes are in /usr/local/include/dbus-1.0/dbus/ and libs in 
/usr/local/lib:

/usr/local/lib/libdbus-1.3.dylib/usr/local/lib/libdbus-1.a  
/usr/local/lib/libdbus-1.dylib

You can add -I and -L options to configure if it's not finding them on your 
system.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Harmonizing the Qt 5.x Documentation

[Rutledge Shawn]

On 2 Apr 2014, at 6:07 PM, Ariel Molina wrote:

 The current state of Qt docs is very sad, making online searches near to 
 useless. All Google searches refer either to broken pages, to 4.x doc pages, 
 to incomplete 5.0 unstables or even to 3.3 documentation. What's the point on 
 having 5.x (or any) docs if you keep moving them around hiding it from search 
 engines and breaking links on every site that links to you?
 
 You might point a root folder, but, let's be honest, none uses any root 
 folder to search, everyone uses Google or another search engine.
 
 Please whatever you do, do not break this anymore, the current state is 
 already messed up. 

I agree.  But I think the idea was to change it one last time and then never 
change it again, and the docs that google finds should be always the latest 
rather than a particular version.  I hope that goal is achieved...

 
 Ariel
 
 
 On Wed, Apr 2, 2014 at 8:34 AM, Oswald Buddenhagen 
 oswald.buddenha...@digia.com wrote:
 On Wed, Apr 02, 2014 at 01:55:46PM +, Pasion Jerome wrote:
  Hello all,
 
  Thanks for the feedback.
 
  We plan to deploy the redirects next week to avoid the Easter break; 
  hopefully, Monday.
 
  Some more notes:
  A) The Qt 5.0, 5.1, and 5.2 documentation sets are already hosted in the 
  archives: http://doc.qt.digia.com/archives/index.html
  There will be links to them from qt-project.org/doc/.
 
 what sense does that make? qt-project.org should not have external
 dependencies.
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
 
 
 
 -- 
 Ariel Molina R.
 
 Oficina: +52 (222) 3723196
 Movil: +521 2226 758874
 http://edis.mx
 ___
 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] One 'qt' branch to rule 'em all!

[Rutledge Shawn]

On 1 Apr 2014, at 2:37 PM, André Somers wrote:

 Diego Iastrubni schreef op 1-4-2014 14:17:
 I agree.
 
 As we move to  a more linear development cycle, we can finally drop
 git and update to svn, where we are going we don't need branches
 anyway.
 I'd actually like to suggest an upgrade to CSV then.

There is already code available for parsing comma-separated values.

http://qt-project.org/wiki/Handling_CSV

Or were you referring to http://www.cvs.com/?

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

Re: [Development] [Interest] qmlx11 plugin

[Rutledge Shawn]

On 5 Feb 2014, at 11:16 AM, Damian Ivanov wrote:

 Hi,
 
 I made a c++ QML plugin  for X11 functions like windowlist, active
 window, setting, getting icon of apps, names, id and setting netwm
 properties. Source code is here
 https://build.opensuse.org/package/show/home:damianator:qmlx11/qmlx11
 
 Right now you can do all the stuff mentioned already, but the
 windowList and the window
 properties are not updated automatically via XEvent's instead
 hackishly I have a Timer reloading
 the active window and the windowList every few seconds.
 
 Could anyone interested assist me in properly receiving the XEvent's
 so the qmlx11 plugin
 properly emits signals according to the received XEvent's (actually
 that's not the problem, but I couldn't manage to receive the XEvents
 at all).

Personally I wish we had some of that as QPA APIs (at least window list and 
window icons), but of course it assumes that we can do the same thing on the 
other platforms.  In my experience, the window list is tricky stuff on X11 
though, because there are so many windows you don't normally want to show in a 
task list.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Remove OSX 10.6 Build?

[Rutledge Shawn]

On 21 Jan 2014, at 8:01 AM, Sarajärvi Tony wrote:

 You are talking about dropping 10.6 support, whereas we are dropping 10.7 as 
 well from the CI.
 I know support and CI aren't the same thing, but you might want to object our 
 plan which as of now hasn't received any criticism.

I'm surprised the market share for 10.7 is as low as it is and for 10.6 that 
it's so high.  One of my macs at home, and my main mac at work, are both stuck 
on 10.7 because of old hardware.  (At least the one at work can potentially 
upgrade if I buy it a new video card.)  But why do people stay with 10.6?  I 
was surprised that we dropped support for 10.5 years ago already, because 
anyone with a PPC machine is still stuck with it, and no version of Qt 5 was 
supported.  Seems to me that 10.6 is probably as obsolete now as 10.5 was back 
then, but 10.7 might not be quite yet.  At least I will probably continue 
testing 10.7 for a while even if CI doesn't, so it will begin to get 
frustrating if lots of bugs start to happen.  (It's also possible that won't 
happen, since there aren't big kludges for 10.7 support AFAIK.  Or maybe I will 
just buy the video card and upgrade.)

I should point out again that it would be a good idea to always have some CI 
machines which use a case-sensitive filesystem, since otherwise I end up fixing 
bugs related to that.  Case-sensitive is not the default when installing OS X, 
but since Linux is case-sensitive, it doesn't take much effort to keep it 
working on OSX too, as long as we get the CI feedback about it.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML Image aliasing when animating

[Rutledge Shawn]

On 22 Jan 2014, at 4:03 AM, Joshua Kolden wrote:

 Image {
id: c4CameraImage
fillMode: Image.PreserveAspectFit
source: “path/to/c4camera.png
anchors.left: parent.left
anchors.top: parent.top
anchors.bottom: parent.bottom
smooth : true

Did you try antialiasing: true?  
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] thoughts about a shared models module, and models in general (was Re: Would a (QML) model aggregator class a welcome addition?)

[Rutledge Shawn]

On 10 Dec 2013, at 11:43 PM, Alan Alpert wrote:

 On Tue, Dec 10, 2013 at 12:32 PM, Alberto Mardegan
 ma...@users.sourceforge.net wrote:
 Hi all!
  For one of my projects, I found the need to merge several models into
 a single model. I wrote a class for it, and I think it's generic enough
 to be useful for other people, and I wonder if it could be put into Qt
 itself:
 
 https://gitlab.com/mardy/mappero/blob/directions/lib/Mappero/model-aggregator.h
 
 Note that the thing is not complete (especially the implementation),
 it's just in a state where I can use it in my application; it needs a
 bit of more work before being ready for the generic use.
 I'm wondering if I should make this extra effort or not. :-)
 
 If the answer is yes, should it be added to QtCore or QtDeclarative?
 Right now it's using QQmlListProperty so that the source models can be
 declared inline,
 
 ModelAggregator {
Model1 { ... }
Model2 { ... }
...
 }
 
 but that could be removed and substituted by a simple QList of models if
 desired.
 
 
 This doesn't sound core enough to really benefit from going into
 QtDeclarative (please stop developing for QtQuick 1 :P ; but I know
 you meant qtdeclarative the repo) or QtCore (no QML types can go into
 QtCore, because QtCore cannot depend on QtQml).
 
 Maybe we should have an add-on repository like qt-qml-extras which
 contains small but useful QML modules. Candidate content being this
 model aggregator, Qt.labs.folderlistmodel, (and I have a couple
 imports at home that I could clean up and contribute too) maybe even
 QtQuick.XmlListModel or Qt.GraphicalEffects?  Some of the add-on level
 imports, like Qt.GraphicalEffects, are large enough for their own
 repo. And some, like QtQuick.XmlListModel, feel core enough to go in
 qtdeclarative as an essential. But there's scope for a lot of small
 but useful QML modules, like ModelAggregator and
 Qt.labs.folderlistmodel, where a shared and non-essential repository
 would make more sense. The alternative is telling each of these little
 modules to get their own github/gitorious/playground repo and then
 we'd have to organize them with something like inqlude...
 
 Anyone else want a qml-extras repository for collecting small QML imports?
 
 And should it be qt-labs, playground, or qt (add on, not essential!)?

I like the idea, but the trouble with models is you typically want to create 
and populate them from C++, which means you need the collection to be in a 
library which you can link with.  The QML modules that get installed e.g. under 
qml/QtQml/Models aren't used that way because everything under qml is meant to 
be instantiated only from QML.  But it would be nice if these models could be 
instantiated both ways.  The C++ interface is more urgent IMO, because so far 
the choices seem to be 

http://qt-project.org/doc/qt-5.1/qtquick/qtquick-modelviewsdata-cppmodels.html

subclass QAbstractItemModel yourself (that requires some overhead, mostly 
boring code being rewritten each time); use a QStringList (but only for one 
column and only strings); use a QList of QObjects, which at least is quite 
flexible (but then each row has all the QObject overhead); or use one of the 
models that you can only instantiate from QML, and then you will have to write 
more Javascript to populate it.  I started writing 
https://codereview.qt-project.org/#change,74986 and then realized I can't link 
with it.

So this module would have to be installed under lib I suppose?  and then just 
because it's a separate, optional module, there would be an objection to 
depending on that module in any Qt essential module, such as Qt Quick Controls. 
 I want to use such a model for the shortcuts in the next-generation FileDialog 
(which will be using QtQuick.Controls, and therefore lives in the same git 
repository now), and we have another potential use case for font families for 
the font dialog, so it has to be OK for Controls to depend on it, wherever it 
goes.  The easy solution (and also the one which doesn't encourage reuse) is to 
put this model in QtQuick.Dialogs.Private because that's where I need it.  If 
someone else wants it, they can always copy the code.  It's not much code 
anyway, hardly worth worrying about.  But altogether we could end up with a 
worthwhile collection of models if various people have various ideas.

Maybe it should rather be a static library to have one less runtime dependency? 
 Another advantage would be that a typical application might only need one of 
the models from the lib, so the memory cost would be lower if the linker was 
free to leave out the ones that you didn't use.  But then if QtQuick.Dialogs is 
already going to use it once, that means if your app uses it too, you've 
already got 2 copies.  Then if you run several Qt apps at the same time, the 
copied model code is taking up more memory than if you had linked with a 
modestly-sized dynamic library, even if each app only uses 10% of it.  I think 
that's the same 

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Rutledge Shawn]

On 13 Jan 2014, at 8:06 PM, David Faure wrote:

 On Monday 13 January 2014 22:00:53 abba...@gmail.com wrote:
 But I think maybe we should get the C++ APIs into qtbase, so that
 QtQuick.Controls.FileDialog doesn't depend on qtsystems. 
 
 Let me rewind a bit here... I thought QtCore would have query stuff, not 
 mount 
 functionality - which most apps don't need.
 
 Is this because you want to offer mounting devices in QFileDialog?
 But in practice QFileDialog is reimplemented on almost all platforms via the 
 QPA, or should be, right? So that seems a bit pointless.

If a volume shows up in the list, the FileDialog should be able to examine its 
contents.  On Windows, the removable-media drives appear even if there is not a 
disk in the drive.  But the mounting/unmounting is a loose concept anyway 
right?  On OSX and Linux, the removable-media drives do not appear if there is 
no disk, so maybe we can do without mounting on-demand from the file dialog; 
although it would be an improvement if one could e.g. plug in a USB thumbdrive 
and have it appear in the dialog right away, whether or not it was mounted.  
But I at least need notification from somewhere that a drive has been mounted, 
so when the user opens the dialog and then mounts the drive from elsewhere in 
the OS, the dialog can see it.  With QDriveInfo and my patch as they are now, 
you have to restart the Qt application because FileDialog only gets the list of 
QDriveInfo objects once.  But maybe the watcher could use a QFileSystemWatcher 
on /dev/disk/by-label instead of d-bus?  I verified
  that it's possible to get a directoryChanged() signal when I plug in a thumb 
drive.  (But it doesn't tell what new link appeared.)

But volume mounting notification does seem like a good thing to add to QPA as 
long as it can be done without big dependencies like d-bus.

 And QtQuick.Controls.FileDialog might not be currently reimplemented via the 
 QPA, but then that's a bug - it should be, to provide consistent dialogs to 
 the user.

Yes it has been preferring the QPA dialog since the beginning.  So far the QML 
dialog is just for cases where neither a QPA dialog nor a QFileDialog is 
possible (e.g. on tablets and embedded devices, in applications which do not 
link the widget module).  The 5.1 DefaultFileDialog.qml is feature-poor, just a 
fallback to make sure that you will always get something when you set a 
FileDialog visible.  In 5.3 it will be using QtQuick Controls, so it becomes 
possible to have more features, such as a list of shortcuts for available 
volumes, favorites which can be stored in the application's settings, a 
ComboBox for the filters, etc.

 So e.g. KDE can provide the same mounting capabilities (via the Solid 
 framework) in both dialogs.
 Hmm, OK, on Windows I suppose embedding the native file dialog into QtQuick 
 is 
 not so great?

It works fine; it's not really embedding, just using QPA to manage the 
OS-created dialog.  It's the same with GTK on Linux and the OSX file dialog.  
There is some trouble to use the KDE 4 dialog from Qt 5 though:  Qt versions 
can't be mixed within the same process, so that dialog would have to be in a 
different process if we were to use it.  Maybe it's not worth the effort if KDE 
will be using Qt 5 soon enough anyway.  On KDE, Qt 5 apps use a plain 
QFileDialog by default.  The QML dialog might end up being an improvement over 
that if we add enough features.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Rutledge Shawn]

On 13 Jan 2014, at 5:06 PM, Alvin Yulo wrote:

 Here are the QDrive APIs that Tony mentioned below:
 https://codereview.qt-project.org/#change,75336,patchset=1

Cool.

But I think maybe we should get the C++ APIs into qtbase, so that 
QtQuick.Controls.FileDialog doesn't depend on qtsystems.  So does that mean we 
need the watchers added on top of 
https://codereview.qt-project.org/#change,73945 ?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] moving some SystemInfo stuff into qtbase (was Re: QtDriveInfo module in Playground)

[Rutledge Shawn]

On 1 Mar 2013, at 11:20 PM, Lorn Potter wrote:

 On 02/03/13 07:59, Thiago Macieira wrote:
 On sábado, 2 de março de 2013 07.51.04, Lorn Potter wrote:
 Wasn't there already similar functionality in QtMobility?
 QSystemStorageInfo seems to provide similar functionality?
 
 Yes it does.
 
 Or did all
 that get scrapped in Qt 5?
 
 It's there in qtsystems, which is a hidden module.
 
 As I said before when QSystemStorageInfo came about, I think the 
 functionality
 belongs in QtCore. With less emphasis in QML and mobile, of course.
 
 systeminfo works on all platforms, mobile or not.
 The udisks functionality would have to be removed if moved to core.

I would like to at least have something like 
QSystemStorageInfo::logicalDrives() to use in building the QML FileDialog.  
(QDir::drives() provides drive letters on Windows but not mount points on 
Linux, which is asymmetric IMO.)  The reason is to have similar functionality 
on operating systems which will rely on the QML FileDialog as on Windows and 
OSX: when you plug in a removable drive, or mount a network drive, there should 
be a shortcut to access it in the file dialog.  So where should we start, and 
how much should we try to bring over in the first pass?  Is anyone else 
interested in working on patches for that?

If it doesn't have public QML API, that's OK for now, because I have some C++ 
support code for the dialogs anyway.  But maybe we should try to bring back 
(and improve) some of the QML APIs too?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QWidget mouse events - different order

[Rutledge Shawn]

On 23 Dec 2013, at 5:37 PM, Rick Stockton wrote:

 QTBUG-25831 is re-opened, and assigned to me. The linked gerrit change
 would solve the problem for Widgets- creating the issue that a LOT of
 Qt5 modules are listening only for single-click, and would now need to
 listen for both events if they need to respond properly to a big
 sequences of fast single-clicking.
 
 (Half of the fast clicks would now show as ButtonDblClick events, and
 Qt5 would no longer provide corresponding clicks to for those modules to
 see.)
 Shawn Rutledge has suggested making the change configurable (see his
 comment in the bug, he says it much better than I can paraphrase).

I don't think I did any work on this (unless I forgot something), other than 
thinking a bit and making a comment.  ;-)  But I'm glad that a plan seems to be 
coming together.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.2.0 compilation fails on ArchLinux

[Rutledge Shawn]

On 21 Dec 2013, at 9:00 PM, Wilhelm wrote:

 Hi all,
 
 I'm trying to compile qt-5.2.0 on arch linux, but with/without
 icu-support I get the following error:
 
 make[3]: Entering directory
 '/usr/local/src/qt-everywhere-opensource-src-5.2.0/qtbase/src/platformsupport'
 LD_LIBRARY_PATH=/usr/local/src/qt-everywhere-opensource-src-5.2.0/qtbase/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
 /usr/local/src/qt-everywhere-opensource-src-5.2.0/qtbase/bin/qdbusxml2cpp -i
 struct_marshallers_p.h -a deviceeventcontroller_adaptor.h:
 ../3rdparty/atspi2/xml/DeviceEventController.xml
 /usr/local/src/qt-everywhere-opensource-src-5.2.0/qtbase/bin/qdbusxml2cpp:
 error while loading shared libraries: libicui18n.so.51: cannot open
 shared object file: No such file or directory
 Makefile:3407: recipe for target 'deviceeventcontroller_adaptor.h' failed
 make[3]: *** [deviceeventcontroller_adaptor.h] Error 127
 
 
 Arch Linux has icu-5.2

I don't have this problem when building from the git tree.  Are you sure you 
started with a clean source tree?  Maybe there are leftover makefiles or 
something which remember that your system had version 51 before, or some other 
version of qmake gets called or some such.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] StereoViewport for Qt3D

[Rutledge Shawn]

On 17 Nov 2013, at 11:11 PM, Svenn-Arne Dragly wrote:
 
 I hope so too, but if I don't hear anything I'll just try pushing it to
 gerrit and see how it goes.

Sounds good.  I could conceivably test it at home; just got a 3D TV and haven't 
used it for anything more than movies yet.

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

Re: [Development] QML and JavaScript extensions

[Rutledge Shawn]

On 11 Nov 2013, at 9:38 AM, Topi Mäenpää wrote:
 Consequently, I have needed to hack my extensions by using hidden 
 low-level APIs. As mentioned, this was just a matter of finding a 
 pointer to the internal QScriptEngine in Qt4. In Qt5, I have used the V8 
 API directly. Now that 5.2 uses a new engine I need to rework my 
 extensions once again.
 
 Would it be possible to either fix the JS engine or, preferably, provide 
 a stable JavaScript extension API that could be used from QML?

It sounds like an interesting project.

I just wonder why you prefer pure Javascript over QML?  It's not so hard to 
expose C++ objects or classes to QML, depending on whether you want to use 
pre-created objects or create instances via QML declarations.  Are there some 
JS examples which demonstrate why this kind of code really needs to be 
procedural instead, perhaps to describe an order of doing things, as opposed to 
declaring objects which will then handle events from sensors or from users?

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

Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats

[Rutledge Shawn]

On 8 Nov 2013, at 9:59 AM, Mikkel Krautz wrote:
 That's how I'm imagining it working as well.  No 3rdparty source tree
 needs to be bundled (it isn't bundled in qt-solutions either, at the
 moment) - but link against the JasPer lib if it's present on the
 system, or JASPER_CFLAGS and JASPER_LIBS are specified to configure
 (or however we want it to function).

Why should it use jasper instead of OpenJPEG?  I'm not familiar with either one 
but wikipedia seems to say OpenJPEG implements more of the spec.

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

Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats

[Rutledge Shawn]

On 7 Nov 2013, at 11:11 PM, Mikkel Krautz wrote:

 On Tue, Nov 5, 2013 at 9:57 AM, Saether Jan-Arve
 jan-arve.saet...@digia.com wrote:
 
 Is there any big benefits in having ICNS support on other platforms than OSX?

…

 So my own use of the icon engine is restricted to OS X.  As such, my
 own use of the engine could just as well be satisfied by having an
 ICNS icon engine in QtMacExtras (or wherever) that wraps NSImage - or
 some native code in Mumble to load the icons via native APIs.

Still, I don't see a good reason to try to avoid making it available on the 
other platforms.  As I wrote elsewhere in the thread, maybe .icns can even turn 
out to be a good cross-platform icon solution.  And JPEG2000 might be useful in 
other contexts, too; however that comes at the cost of linking with yet another 
library.  As long as we ensure that when the library is missing, the ability to 
decode the larger versions of the icons is missing (or the ability to decode 
the icons at all is missing), and that doesn't cause any other problems at 
runtime, is there any other reason not to have it available?  It's not like 
we'd have to include the JPEG2000 decoder source with Qt, just have the ability 
to detect the library and compile the plugin only if it's there, right?

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

Re: [Development] StereoViewport for Qt3D

[Rutledge Shawn]

On 28 Oct 2013, at 10:35 PM, Svenn-Arne Dragly wrote:
 Secondly, I was missing a stereo option for the default QML Viewport
 element, and decided to have a look at the implementation in QGLView to
 see if I could port that to the QML Viewport element. Luckily this was
 quite easy (thanks to Qt3D being well designed) and I have uploaded the
 resulting StereoViewport element to a GitHub repository:
 
 https://github.com/dragly/stereoviewport
 
 This should compile with Qt5.1.1 and the latest master branch of Qt3D.

Cool.  Are you using it with an Oculus Rift, 3D TV or something else?
 
 Now, I'm wondering if this feature should be a part of the original
 Viewport element. Should I contribute this into the main Qt3D
 repository? If so, what steps should I take before doing this, apart
 from those listed in the Qt Contributing Guidelines? I'm for instance
 not sure if I might have introduced some bugs or damaged any features of
 the original Viewport element. How should I verify that I haven't done so?

I don't know much about that but I'm sure you will get a reply from someone who 
does.  But it sounds like a good feature to have.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats

[Rutledge Shawn]

On 6 Nov 2013, at 6:56 PM, Иван Комиссаров wrote:

 Sorry for an offtop:)
 I have a DDS image format plugin, does someone interested?:) 
 https://gitorious.org/andromeda/imageformats/source/c637e7d8c3719e0a5cf27a32f8ea425adc09f40c:src/plugins/imageformats/dds

DirectDraw Surface?  http://en.wikipedia.org/wiki/DirectDraw_Surface
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats

[Rutledge Shawn]

On 4 Nov 2013, at 10:51 PM, Mikkel Krautz wrote:

 Hello,
 
 I'm process of attempting to integrate support for the ICNS (OS X icon
 files) format into Qt as an icon engine.
 (https://codereview.qt-project.org/#change,60290)
 
 An optional, but desirable part of the ICNS format is support for
 JP2/JPEG2000 images. It's desirable because all variants of the icon
 greater than 128x128 are stored as JPEG2000 - so without JPEG2000
 support, the icon engine will only be able to render images at 128x128
 and below.
 
 It was pointed out during the review that a jp2 image format is
 available in the qt-solutions repository:
 
 https://github.com/qtproject/qt-solutions/tree/master/qtjp2imageformat
 
 and that it might make sense to move it into qtimageformats along with
 the icns icon engine itself.
 
 Does anyone see and/or have any problems with moving qtjp2imageformat
 to qtimageformats?

JPEG2000 apparently has some advantages, such as having multiple resolutions in 
one file and otherwise scaling better, as well as having a lossless compression 
option.  So it seems like a good format to use for icons.  I keep hoping that 
some day we will have the toolset to generate application icons from a single 
master file: .ico, .icns, various sizes for various Linux desktops, etc.  It 
should be enough to specify something like

ICON = myapp.jp2 (or svg)

in your .pro file and we should take care of the rest, consistently on all 
platforms.  (https://bugreports.qt-project.org/browse/QBS-73)  (Of course those 
who want to have separate icons for separate platforms would still be able to.)

I had thought SVG would be the best, but JPEG2000 would be a nice alternative 
for those who prefer a high-res raster representation.  Then maybe we should 
write a cross-platform icon editor which allows managing the various 
resolutions, if possible, or do the lower resolutions have to be generated from 
the high-res original?  If that were possible then maybe Apple would not have 
needed multiple sizes inside the .icns file at all.

BTW (unrelated) a fractal compresson format would be nice to have too; the 
patents from 1987 have expired now.  
http://en.wikipedia.org/wiki/Fractal_compression

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

Re: [Development] Moving JP2 imageformat from qt-solutions to qtimageformats

[Rutledge Shawn]

On 5 Nov 2013, at 5:47 PM, Jake Petroules wrote:

 I do. Qt is by nature a cross platform framework, limiting support for ICNS 
 files only to OS X doesn't really make sense.
 
 What if you want to create a cross platform icon editor or some other app 
 that deals with image files? Or reuse your OS X icon(s) on Windows and other 
 platforms, saving time and space not having to create multiple versions of 
 everything? If you don't want to build the ICNS plugin, simply disable it 
 when you configure qtimageformats. It's a common and well known format and it 
 should be supported on all platforms Qt supports, just as ICO is supported on 
 OS X, Linux and others.
 
 I could understand refusing to include it in QtCore, but we're talking about 
 QtImageFormats here, the perfect place where something like this belongs.
 -- 
 Jake Petroules
 Chief Technology Officer
 Petroules Corporation · www.petroules.com
 Email: jake.petrou...@petroules.com
 
 On Nov 5, 2013, at 11:37 AM, Thiago Macieira thiago.macie...@intel.com 
 wrote:
 
 On terça-feira, 5 de novembro de 2013 08:57:12, Saether Jan-Arve wrote:
 Is there any big benefits in having ICNS support on other platforms than
 OSX?
 
 I don't think anyone wants ICNS outside OS X. But JPEG2000 might be useful.

ICNS could maybe be a useful cross-platform icon format as long as it doesn't 
have encumbrances.  I assume not, since http://icns.sourceforge.net/ is LGPL.  
(Wikipedia says there are some JPEG2000 patents, but the committee has set up 
agreements so that it can be royalty-free in practice).  It would be a neater 
alternative to the current naming convention on Linux (find /usr/share/icons 
-type d, each theme has a subdirectory and each resolution has a directory 
under that).  Of course ubiquity would depend on at least one of the major 
desktops to adopt the practice; but even if not, it would still be nice to have 
one icon file per app as the icon's source and generate the others.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Nominating Gatis Paeglis as approver

[Rutledge Shawn]

+1, thanks for all the help with input handling and xcb in general.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Port QT 5 to Haiku

[Rutledge Shawn]

On 17 Oct 2013, at 2:45 AM, Giovanni Mugnai wrote:
 I’m writing here, since to me and some other Haiku users, we’d like to
 find a programmer/expert developer able to fully port the latest
 version of Qt 5 on Haiku. With “fully port” we mean to port the Qt 5.x
 in a perfect way: complete of any components (eg shared memory, phonon
 and with the latest revision of QtWebKit) and bug free.. A first class
 port.

That sounds like a worthwhile goal, but here are a couple of details I can 
think of:

- Qt Multimedia is not based on phonon anymore.  But of course you can probably 
get the new version working.

- You should probably use Qt WebEngine instead of the existing webkit.  But 
there are other things to do first anyway, so by the time you get there it 
should be quite mature.  
http://blog.qt.digia.com/blog/2013/09/12/introducing-the-qt-webengine/

- OpenGL is quite important to Qt nowadays, but I see in your FAQ that Haiku 
often falls back to VESA drivers.  Does it have OpenGL support at all, with the 
right combination of drivers and hardware, or does it have a fallback software 
implementation?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QT4.8.5 issue: multi-touch message cannot handled by close button

[Rutledge Shawn]

On 13 Sep 2013, at 7:53 AM, Duan Fugang-B38611 wrote:

 Hi, all,
  
 We use the X.Org X Server 1.14.0 + QT4.8.5 to do one demo, but I  catch one 
 issue: multi-touch message is not handled by “close” button.
  
 I use egalax touchscreen for the multi-touch test.
 After kernel up, evtest test the multi-touch message, all pass. Use xinput to 
 do the test, also pass.
  
 Open one QT app, all multi-touch message can be processed, but the window of 
 the app cannot be closed by click the “X” in the right-up region.
 I test GNOME destop with the same kernel,  any apps’ window can be closed.
  
 So, It is strange, maybe it is KDE issue for multi-touch ?
 Any response is appreciative.

This X button is the one provided by the window manager, right?  If you are 
running KDE then it must be kwin.  (Which is probably still using Qt 4)  But it 
probably relies on mouse emulation at some level to detect pressing that 
button.  Maybe the egalax driver or the X server does it, so that any legacy 
X11 apps will work.  (You can try really old X apps that definitely don't 
support touch, like xman, xmessage etc.)  If you have a widget-based 
application with a QPushButton, or a qml application with a MouseArea, can you 
press those via the touchscreen?  because they also need to get mouse events 
rather than touch events (so far).

Which driver is the X server using for the touchscreen?  (check 
/var/log/Xorg.0.log)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] QT4.8.5 issue: multi-touch message cannot handled by close button

[Rutledge Shawn]

On 13 Sep 2013, at 9:44 AM, Duan Fugang-B38611 wrote:
 The KDE is not kwin, is matchbox-window-manager.

OK I can reproduce it, so it seems to be an issue with matchbox (and matchbox 
is not using Qt).  But it was designed for PDAs, so maybe there is a solution.  
The touch drivers for Linux PDAs back then (iPaq, Zaurus, Agenda etc.) only 
provided mouse events, because XInput didn't have touch until recently, and 
anyway a resistive touchscreen is just like a single-button mouse.  But the 
evdev driver should be making your multi-touch screen emulate a mouse too, so 
then I wonder what matchbox is doing so that it doesn't work.  Maybe it has 
been partially updated to support touch but doesn't do it correctly?  But you 
can google and/or find a matchbox mailing list or forum to ask about that, or 
look at the source and see if it uses xinput or just the conventional old X11 
mouse events.

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

Re: [Development] MouseWheel issue with Flickable - abandoned issue QTBUG-21328?

[Rutledge Shawn]

On 27 Aug 2013, at 1:39 PM, Ola Røer Thorsen wrote:

 Hi, I wanted to create an issue about a mouse wheel issue in QtQuick 
 Flickable, but figured out it has been reported already:
 https://bugreports.qt-project.org/browse/QTBUG-21328
 
 Is this a lost case as I see the assignee is closed/inactive? Maybe it 
 should be re-assigned to someone else?

I did that.  I agree that it's a long-standing bug.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] System-wide font preferences for monospace font

[Rutledge Shawn]

On 9 May 2013, at 2:09 PM, Jan Kundrát wrote:

 In Qt5, the situation looks a bit better, the 
 qtbase:gui/kernel/qplatformtheme.h contains QPlatformTheme::Font enum with 
 support for multiple fonts to be used in the application menus, labels etc. 
 Unfortunately, the support for a fixed font is not there. and in addition 
 to that, this feature does not appear to be visible to the user code as it's 
 a private header.


On 15 May 2013, at 5:40 PM, Jan Kundrát wrote:

 On Thursday, 9 May 2013 22:41:07 CEST, Jan Kundrát wrote:
 However, both KDE and Gnome's settings each include more data, 
 including the font size and options like bold, italic etc. Are 
 these also handled by fontconfig, so that when I ask for a 
 Monospace I always get the font with a correct size and 
 style?
 
 It doesn't seem so, based on my reading of the docs. If I am right, this 
 means that there is some value in having a cross-platform way of obtaining 
 user's preferred fixed-width font, including the font size. For example on 
 this machine, I have a DejaVu Sans 10 as the default font but Monospace 
 9, whatever it actually is, as the fixed width font. If I relied on 
 fontconfig, I'd get a 10pt Monospace which is too big for my preferences.
 
 Am I right here?

It seems that way to me, at least it would be self-consistent to have that 
preference alongside the others.

In your patch though, on gnome you start a process to run gconftool-2 to get 
the font.  Is that really the right way to get those settings?  Only for Gnome 
2, right?  Because (last time I checked) src/plugins/platformthemes/gtk2 still 
needs work IMO: we need to get the theme colors correctly, but that's 
complicated, so it didn't seem to me that there is just one place to look (one 
config file or one gtk function to call).  Maybe you're right that it needs to 
be done this way, because gconftool knows all the places that the settings can 
be overridden, but then it would be nice if we could run gconftool once and get 
all the settings that we need for all colors and fonts.  It looks like qt 4 
runs gconftool multiple times.  But it's not very efficient.  Is there no way 
to do this with some library that can be linked?  Gnome applications never need 
to do this?

$ gconftool-2 -a /desktop/gnome/interface
 enable_animations = true
 document_font_name = Sans 8
 can_change_accels = true
 gtk_theme = Ambiance
 use_custom_font = true
 cursor_blink = false
 buttons_have_icons = true
 font_name = Ubuntu 7
 icon_theme = ubuntu-mono-dark
 monospace_font_name = Monospace 8

Only 3 fonts and no colors.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QML - PathView not responding on drag event with touch

[Rutledge Shawn]

On 30 Apr 2013, at 9:13 AM, Matteo Brichese wrote:

 PathView, like many QtQuick components that you might think of as 
 touch-oriented, is actually only handling mouse events.  So it works 
 because it will get synthesized mouse events on devices that don't already 
 provide them.  (The upside is it should work the same with mouse and touch. 
  The downside is the circuitous path the touch events take to get there.)
 If your device is running Linux with x11 you might try xev or xinput or 
 mttest to see if it sends any events otherwise.  It's strange that just 
 having multitouch makes it worse.  Can you send the output of lsinput?
 
 I don't have lsinput command on my board, it's an angstrom distribution.

You say that like it's a bad thing.  ;-)  Angstrom is a meta-distribution built 
with openembedded (or yocto), so if you're developing a product you have a lot 
of flexibility to customize it and build whatever packages you want; no need to 
depend on some vendor to keep it up to date either.  You can also install gcc 
right on the embedded system if that makes it easier to quickly build and test 
things.  But there is a learning curve to fix the inevitable build problems 
when you start using bitbake to rebuild the whole distro.

 If you are using evdevtouch, I guess it's because the X11 driver isn't 
 working or isn't installed or you aren't running X?  So probably Qt will 
 only see touch events, not mouse events, by reading them directly from 
 evdev, and there are about 3 places mouse events could be synthesized, but 
 we expect that they should be synthesized in QQuickWindow.  Hopefully you 
 are using QGuiApplication, but if you have a QApplication you might need to 
 turn off the Qt::AA_SynthesizeMouseForUnhandledTouchEvents attribute to 
 make sure it can't happen twice.  (That type of synthesis will probably be 
 removed, by this patch:  https://codereview.qt-project.org/#change,54816  
 because it seems redundant.)
 
 I'm using X and xcb plugin, no eglfs by now, it's a Tegra2 device, 
 touchscreen is an eGalax touchscreen (USB+DVI), I'm using QApplication, and 
 the only thing I do is to launch the main.qml file.

With qmlscene or your own C++?

 Nowadays Qt has support for multitouch via xinput 2.2, so if you have a 
 recent X server, xinput and evdev, you shouldn't need the evdevtouch plugin 
 anymore.
 
 I don't know why I'm using evdevtouch, but it's seems that the multitouch 
 capabilities only works if I specify the evdevtouch parameter, if I don't 
 specify anything or some other options like -plugin evdev:/dev/input/event1 
 or with tslib or xinput, multitouch simply doesn't work.
 
 My Xorg version is :
 X.Org X Server 1.11.2
 Release Date: 2011-11-04

So it's too old for xinput 2.2; that was done early in 2012.

I tried on my Lenovo S10-3t, disabling the touchscreen evdev support in X and 
using the evdevtouch plugin instead, with a path view.  It seems OK (except for 
the physics being a bit off as documented in bug 29801).  You can try the qml 
from that bug too, to see if it's just PathView or some combination that is 
behaving strangely.

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

Re: [Development] QML - PathView not responding on drag event with touch

[Rutledge Shawn]

On 29 Apr 2013, at 5:25 PM, Matteo Brichese wrote:

 Hi everyone, I'm having some trouble using a PathView on QtQuick2.0 (Qt5.0.2) 
 with my multitouch panel.
 
 If I use a ListView and I drag it, it scroll smooth and istantly, same as 
 with mouse.
 If I use a PathView and I drag it, it don't scroll istantly bu after some 
 delay, the movement isn't smooth too, it's unusable. onDragStarted and 
 onDragEnded events went in the right moment (as I start dragging)

We were looking at this bug recently, maybe it's related, but I don't think 
it's as severe as what you are describing:

https://bugreports.qt-project.org/browse/QTBUG-29801

 I launch my test with the option: -plugin evdevtouch:/dev/input/event1 for 
 enable the multitouch, if I launch it with -plugin 
 evdevtouch:/dev/input/event0 I enable only one touch at a time (mapped over 
 the mouse) and everything goes fine.
 
 So, my question is: is it possible to remap the touch events on the PathView? 
 It's an unhandled situation or there is some hack that I didn't know? Google 
 didn't help me much.
 
 It could be a problem of my panel as well, but before starting to debug my 
 panel I want to know if some of you is using a PathView with his multitouch 
 device.

PathView, like many QtQuick components that you might think of as 
touch-oriented, is actually only handling mouse events.  So it works because it 
will get synthesized mouse events on devices that don't already provide them.  
(The upside is it should work the same with mouse and touch.  The downside is 
the circuitous path the touch events take to get there.)

If your device is running Linux with x11 you might try xev or xinput or mttest 
to see if it sends any events otherwise.  It's strange that just having 
multitouch makes it worse.  Can you send the output of lsinput?

If you are using evdevtouch, I guess it's because the X11 driver isn't working 
or isn't installed or you aren't running X?  So probably Qt will only see touch 
events, not mouse events, by reading them directly from evdev, and there are 
about 3 places mouse events could be synthesized, but we expect that they 
should be synthesized in QQuickWindow.  Hopefully you are using 
QGuiApplication, but if you have a QApplication you might need to turn off the 
Qt::AA_SynthesizeMouseForUnhandledTouchEvents attribute to make sure it can't 
happen twice.  (That type of synthesis will probably be removed, by this patch: 
 https://codereview.qt-project.org/#change,54816  because it seems redundant.)

Nowadays Qt has support for multitouch via xinput 2.2, so if you have a recent 
X server, xinput and evdev, you shouldn't need the evdevtouch plugin anymore.

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

Re: [Development] Stand alone scene graph module

[Rutledge Shawn]

On 3 Apr 2013, at 10:16 AM, Sletta Gunnar wrote:

 Hi,
 
 The original idea of scene graph was that is was to be a stand alone module, 
 but because it was developed in conjunction with Qt Quick and because we 
 didn't want to compromise on any performance aspects for the sake of making a 
 more generic framework, we placed them together. As it keeps popping up here 
 and there that people still want to use it stand alone, I figured makes sense 
 to at least make it possible.
 
 I've started making some patches that make it possible to extract the 
 scenegraph core API's from declarative and build them as a separate module. 
 This should make it possible to create normal C++ apps using this API, 
 depending only on QtCore and QtGui. 
 
 https://codereview.qt-project.org/#change,52682
 https://codereview.qt-project.org/#change,52683
 
 This still preserves some the private headers as private, but exposes it in a 
 way that it doesn't require the full QML / JS stack. 
 
 Also, what is included is the coreapi and some utilities. The QML item 
 implementations are another debate, which I will not address with this 
 module. At least not immediately. Things like the distance field glyph nodes 
 and shader effects are currently too tied up with the Qt Quick module to be 
 extracted, but the module offers textures, materials, nodes and renderer and 
 should be usable for games and such.
 
 The module is graphics only, it does not involve stuff like input, 
 animations, etc.
 
 Any opinions?

That sounds excellent, and perhaps a good way forward for alternate language 
bindings, like Scheme, Haskell and Python?  But for that purpose, reusable 
animation and input support would be nice too.  Maybe it would be achievable by 
using the v4 bindings with an alternate LLVM-based compiler.

It would be nice to have less duplicated input and animation functionality 
between QtQuick and widgets anyway, to avoid (or at least concentrate) bugs, 
reduce code size, and have the same behaviors available to both widget and 
QtQuick apps.

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

Re: [Development] Stand alone scene graph module

[Rutledge Shawn]

On 3 Apr 2013, at 11:25 AM, Sletta Gunnar wrote:

 
 On Apr 3, 2013, at 10:51 AM, Dmitrii Volosnykh dmitrii.volosn...@gmail.com
 wrote:
 
 Hi, Gunnar.
 
 At first glance scenegraph module and Qt3D have similar feature sets.
 
 Not at all :)
 
 The scene graph in Qt Quick is a very tiny api, meant to formally structure 
 OpenGL graphics calls so that we can optimally render a 2D interface with 
 bling (it supports 3D transformations and geometry, but it doesn't manage 3D 
 geometry per se). The primary purpose is to allow sorting, reordering of the 
 GL calls and 
 
 It is meant to be tiny and fast when supporting the usecase of highly 
 dynamic, lots of small things chaning all the time, with bling and some 
 light-weight 3D. It will do worse when trying to render something like 
 google-earth :)
 
 Qt3D in its current state is more like QGraphicsView. It puts items into a 
 scene and renders them without any logic to try to improve on the 
 performance. It does contain a scene graph, but it is purely procedural in 
 its execution. Sean Harmer posted a mail a while back outlining how he 
 envisions Qt3D evolving into a proper 3D engine, something which will be 
 suitable for larger 3D apps. This solves a different usecase from what the 
 scene graph and will not be suitable for UI rendering, for instance.

What happens when you try to combine the two, are they just in layers?  For 
example I tried to make a piano app as a multi-point touch demo, and found it 
difficult to make fake semi-3D-looking piano keys.  One can rotate a Rectangle 
in any direction around any axis, so I thought I could have a 90-degree rotated 
rectangle for the front of the key, and a rotated woodgrain texture for the 
sides.  But when you rotate to 90 degrees, it disappears, even if you then 
rotate the entire key by a few degrees.  I got something a little better by 
tweaking the angles slightly and tweaking the length heavily, but it didn't 
scale well.  So the ideal might be to render using a 3D model, but every key 
top should have a MultiPointTouchArea.  Or else the 2D scene graph should 
handle the rotated cases more realistically; is that doable, or is there not 
much hope because we want to avoid using perspective rendering in typical 2D 
apps?

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

Re: [Development] White space / coding style patches welcome?

[Rutledge Shawn]

On 15 Mar 2013, at 2:03 PM, Alberto Mardegan wrote:
 
 Not much relevant here, but just in the unlikely event that everyone
 will confess to like this style more, here's what I use in my own projects:
 
 
 MyClass::MyClass(...):
GvbWidget(parent),
m_background()
 {

I do that too.  But I usually put a space before the colon.

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