Re: [Development] List of available Qt mirrors

[Ch'Gans]

On 17 May 2017 at 01:36, Li Xu  wrote:
> hi,
>
> I got 4 mirrors from the link from China mainland,
>
> http://mirrors.ustc.edu.cn/qtproject/online/qtsdkrepository/windows_x86/root/qt/Updates.xml
> (cn, prio 100)
> http://mirrors.tuna.tsinghua.edu.cn/qt/online/qtsdkrepository/windows_x86/root/qt/Updates.xml
> (cn, prio 100)
> http://mirror.bit.edu.cn/qtproject/online/qtsdkrepository/windows_x86/root/qt/Updates.xml
> (cn, prio 100)
> http://mirrors.neusoft.edu.cn/qt/online/qtsdkrepository/windows_x86/root/qt/Updates.xml
> (cn, prio 100)

From New Zealand, I do not see the Chinese servers. I get 2 Japanese
one at the top of the list, and then some European ones followed by
Brazil and Canada.

Chris

>
> I don't think they are vanished from list, mb they were just not there when
> you were not located in China.
>
> Regards,
> Li
>
> On Mon, May 15, 2017 at 9:38 PM, Sze Howe Koh  wrote:
>>
>> A user from China has reported that the Chinese mirrors are no longer
>> visible to him [1]. I also don't see any when I visit
>> http://download.qt.io/online/qtsdkrepository/windows_x86/root/qt/Updates.xml.mirrorlist
>> (from Australia)
>>
>> Now, from my experience (which is a few years old and possibly outdated),
>> the Chinese mirrors tend to perform quite poorly, even for users within
>> China [2]. Nonetheless, I'm still surprised to see that they have vanished
>> from the list; at least one server seems up to date [3].
>>
>> Is this behaviour expected? Has the mirror management system been updated
>> to hide mirrors that don't meet certain performance criteria or something
>> like that?
>>
>>
>> Regards,
>> Sze-Howe
>>
>> [1] https://github.com/JKSH/QtSdkRepoChooser/issues/5
>> [2]
>> http://lists.qt-project.org/pipermail/interest/2013-December/010336.html
>> [3] http://mirrors.ustc.edu.cn/qtproject/online/qtsdkrepository/
>>
>> ___
>> 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] Lack of base classes/interfaces? Q*, Q*F

[Ch'Gans]

On 17 April 2017 at 13:25, Jason H  wrote:
> I am wondering why all the Q* and Q*F classes (where $1 in [Rect, Point, 
> etc]) don't use an interface?
>  I recently moved some code from ints to floats, and I had to change far more 
> code than I should have > had to.
>
> My proposal is to change QRect to QRectI, and make QRect an interface.

This is only the tip of the iceberg, there's the storage type and then
the dimension, Qt has specialised class for int and double in 2 and/or
3 dimensions, and then there's the family of 2+ dimensions with float
(QVector2/3/4D, QMatrixNxM, QQuaternion, ...). I saw a patch not so
long ago about bringing in qfloat16, ...
And I won't mention coordinate systems, ...

Coming with a set of interfaces that plays well together is not an
easy task and things get complicated very quickly. Have a quick read
at boost.geometry "design rational"[1], it looks very sexy at first,
but once you start using it, you realised how cumbersome it can get.

IMHO, there are different use-cases, just to list a few of them:
- 1. GUI/painting tasks (int in 2D 'top-left' CS)
- 2. 3D rendering tasks (float in 2 or 3D)
- 3. Quick and inexact geometry (double in 2 or 3D)
- 4. Exact and robust geometry (other in nD)
- 5. [insert your own here]

I don't believe that you can cover them them all with just one set of
interfaces, different needs require different solutions.

I guess there is lot of history behind Qt current API, it all started
with managing pixels on a screen, didn't it?

I personally would love to see a non-gui module that sits b/w 4 and 5
with "native" support for non-linear curves in 2/3D space...

Chris

[1] 
http://www.boost.org/doc/libs/1_61_0/libs/geometry/doc/html/geometry/design.html

>
> In the past, I think I remember some pain points between QList and QVector, 
> (or was it QMap, QHash?) which should be QIterable (QIndexable)? Similarly 
> all the string types.
>
> I'm not fan of MS's Ieverything, but I think base classes/interfaces are 
> under used in Qt. Why aren't there more of them?
> ___
> 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] Does anyone know anything about QPolygon or QPainterPath? (QTBUG-60024)

[Ch'Gans]

On 10 April 2017 at 05:19, Thiago Macieira  wrote:
> https://bugreports.qt.io/browse/QTBUG-60024
>
> All the commits in qpolygon.cpp or qpainterpath.cpp in the last 6 years are
> either doc updates, licence updates, or simple fixes (remove "register", make
> constructors explicit, etc.).
>
> This bug is about intersected(), but I have absolutely no clue about its
> implementation.

Hi,

The only thing that I know about QPainterPath, QPolygonF and co, is
that you should *never ever* use them to do geometry work. They simply
don't work. I use QPainterPath and QPolygonF only for _rendering_
geometries.

When it comes to manipulating geometry (predicates or construction),
one is better off using Boost.Geometry, CGAL or the likes.

Chris

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Passing QSize, QPoint, QTime and other small structs by value

[Ch'Gans]

On 8 April 2017 at 03:21, Thiago Macieira  wrote:
> Em sexta-feira, 7 de abril de 2017, às 06:02:55 PDT, Lars Knoll escreveu:
>> Those rules sound about right. We can do this nowadays, as x86 will become
>> rather irrelevant for Qt 6 (where passing structs by reference would
>> probably be better in most cases due to the limited amount of available
>> registers).
>
> x86 doesn't pass in registers anyway. The best you'd get is the elements of
> the struct pushed on the stack, instead of pushed elsewhere on the stack and
> an address to the stack pushed on the stack.

What about FPU registers? Qt API always pass 'qreal' by value...

Chris

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Moving Qt's undo framework out of Qt Widgets

[Ch'Gans]

On 6 April 2017 at 00:02, Morten Sørvig  wrote:
>
>
>> On 5 Apr 2017, at 12:37, Oswald Buddenhagen  wrote:
>>
>> On Wed, Apr 05, 2017 at 09:24:15AM +, Mitch Curtis wrote:
>>> So, should this get its own module, and if so, can widgets depend on
>>> it?
>>>
>> an own module just for that seems over the top - i don't think we want
>> to end up with 100 micro-libraries.
>>
>> however, splitting up qtcore has been raised multiple times, and
>> putting this into one of the resulting libs would seem reasonable. for
>> example, this seems conceptually quite related to item models. possibly
>> also state machine. and animation. these are all things which initially
>> elicit a "huh, this is core?" response, until you think a bit about it.
>> GuiSupport may be a better name for it (i'm sure some will disagree).
>
> So both QtCore and QtGui could be split up into “Core” and “Kitchen Sink”;
>
> QtCoreCoreQtGuiCore
> QtCoreSinkQtGuiSink

You forgot QtCoreKitchen, QtGuiKitchen, QtCoreKitchenSinkSupport,
QtGuiKitchenCoreSinkSupport and of course
QtCoreKitchenGuiSinkCoreSupport! ;)
I would even consider a new QtCoreGuiBridge module to help with
decoupling GUI from Core and Sink from kitchen. Of course all class
names would start with QAbstract, eg
QAbstractCoreGuiKitchenSinkBridge.
This goes without saying that to help with creating object of
arbitrary concrete types a QCoreGuiKitchenSinkBridgeFactory is a must
have! Along with a proper
QCoreGuiKitchenSinkBridgeFactoryPluginInterface and for user's
convenience (and the fun of it) a
QCoreGuiKitchenSinkBridgeFactoryPluginLoader.

-> []

Chris

>
> QtWidgets and QtDeclarative would depend on all of these; are we gaining
> anything? Well:
>
> 1) The “Core” versions will be satisfyingly uncluttered.
> 2) Those who do not use QtWidgets or QtDeclarative can possibly depend
>on smaller libraries.
>
>>
>> also, a plan for splitting up qtbase wouldn't be entirely off the mark.
>> untangling tests and examples would be the major effort here.
>
> (At the risk of derailing the discussion (sorry Mitch)) No, we should
> follow Google and Facebook’s lead: large monolithic repos (as large as
> the infrastructure can handle), which can be updated atomically.
>
> Morten
>
>
> ___
> 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] RFC: Containers member functions for algorithm

[Ch'Gans]

On 25 March 2017 at 07:00, Kevin Kofler  wrote:
> Michael Winkelmann wrote:
>> The reason why STL is using free function is because it separates data
>> structures (aka containers) and algorithms.
>> A bad example what happens if you dont separate can be seen here:
>> https://www.imagemagick.org/api/Magick++/Image_8h_source.html
>>
>> ...and your data structure will be bloated with member functions.
>
> Why is that bad? It is convenient and object-oriented. Moving everything to
> freestanding functions goes against the principles of OOP.

"OO was hip in the 80s and 90s, but its time we moved beyond!".
>From http://www.boost.org/doc/libs/1_63_0/libs/graph/doc/faq.html
item 3, last paragraph.

I'm not advocating for free functions, i really hate them. I have been
working with boost graph recently and find this technique awful to
write, awful to read and counter intuitive. I hope Qt won't become
like boost.

Chris

>
> That said, even freestanding functions would be better than the current
> boilerplate myContainer.begin(), myContainer.end() copypasta.
>
> Kevin Kofler
>
> ___
> 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] Problem loading plugins with gcc 4.9.2

[Ch'Gans]

On 9 March 2017 at 00:33, Alex Blasche  wrote:
> This is an ancient thread but just to keep this in mind (it certainly cost me 
> a day re-figuring this out).
>
> If you do Qt development for Android you are going to be hit by this. The 
> four most recent Android NDKs (11c, 12b, 13b & 14) are affected by this bug 
> when using Linux (not all Linux distros though but certainly Ubuntu 16.04) as 
> host platform. The only decent choice is 10e at this point in time.
>
> I am tempted to just submit a patch that renames the damn loader variables. 
> Any opinions?

Please stop top-posting: http://letmegooglethat.com/?q=top+posting=1
and stop sending HTML emails:
http://www.catb.org/~esr/faqs/smart-questions.html#formats

Grumpy Chris.

>
> --
> Alex
> 
> From: development-bounces+alexander.blasche=theqtcompany@qt-project.org 
>  on 
> behalf of Thiago Macieira 
> Sent: Wednesday, 4 March 2015 4:48:11 PM
> To: development@qt-project.org
> Subject: Re: [Development] Problem loading plugins with gcc 4.9.2
>
> On Wednesday 04 March 2015 11:53:04 Albert Astals Cid wrote:
>> Yes, same issue.
>>
>> Reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65309
>>
>> Would be great if someone could verify i didn't say lots of silly things
>
> Given they've just confirmed, produced a fix and committed it, I'm guessing 
> you
> didn't say anything silly :-)
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Documentation typo fixes

[Ch'Gans]

Hi guys,

Who do I need to invite as reviewers for these typo fixes?
https://codereview.qt-project.org/186292


Thanks,
Chris

On 8 February 2017 at 11:03, Ch'Gans <chg...@gna.org> wrote:
> On 7 February 2017 at 23:18, Edward Welbourne <edward.welbou...@qt.io> wrote:
> [...]
>>
>> Sze Howe Koh (7 February 2017 04:35) replied:
>>> See http://wiki.qt.io/Branch_Guidelines (Note: Qt module repositories
>>> don't have a "master" branch)
>>>
>>> Right now, the branches that accept documentation fixes are:
>>>
>>> * 5.8 (stable branch)
>>> * 5.9 (next release branch)
>>> * dev (development branch)
>>>
>>> Simply put, patches will merge from the top of the list to the bottom
>>> of this list. For example, patches that go into "5.8" will eventually
>>> be merged into "5.9", which in turn will eventually be merged into
>>> "dev".
>>>
>>> Typo fixes are not new features or major/risky changes, so they can go
>>> into the stable branch ("5.8").
>>
>> Indeed.  This is all being formalised in QUIP 5:
>> https://codereview.qt-project.org/178906
>> where you can find out all you wish to know about which changes should
>> go to which branches,
>
> Thanks both of you for the information.
> Chris
>
>>
>> Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Bug (and fix) in QGItem::itemChange() (?)

[Ch'Gans]

FYI, I've just created https://bugreports.qt.io/browse/QTBUG-58988.

Regards,
Chris


On 16 February 2017 at 17:52, Ch'Gans <chg...@gna.org> wrote:

> Hi there,
>
> Here is my use-case:
> An item has "handles" child items, when the user moves around an handles,
> the parent item update it's geometry and position accordingly. Simple
> concept to let the user change an item geometry by dragging handles.
> Imagine, you're using a drawing application, you select a circle and 5
> handles appear on the screen, one in each corner to resize the circle, and
> one in the center to move the circle around.
>
> The way i implement it is to let the circle item filter an handle item's
> 'itemChange()' notification. This work nicely for resizing handles, but
> fails for the 'move handle'. Here is the simplified pseudo code:
> QVariant HandleItem::itemChange(change, value)
> {
>  // Move the parent to where the handle wants to go...
>  parentItem()->setPos(parentItem()->mapToParent(value);
>  // ... and leave the handle at parent's origin
>  return QPointF(0, 0);
> }
>
> After banging my head for a while, i finally pin-pointed what I think is
> the problem:
>
> This is related to how items are moved in qt5/qtbase/src/widgets/
> graphicsview/qgraphicsitem.cpp. When a move begins, the 'initial
> position' of the item is stored in the scene. This initial position is
> simply the value of item->pos(), which is in parent's item CS:
>
> initialPositions = d_ptr->scene->d_func()->movingItemsInitialPositions;
> if (initialPositions.isEmpty()) {
>   foreach (QGraphicsItem *item, selectedItems)
> initialPositions[item] = item->pos();
>   initialPositions[this] = pos();
> }
> d_ptr->scene->d_func()->movingItemsInitialPositions = initialPositions;
>
> As the move goes on, the item's pos is updated based on this 'initial
> position' (expressed in an outdated parent's CS) and the parent position
> relative to the item's position:
>
> currentParentPos = item->mapToParent(item->mapFromScene(event->scenePos()
> ));
> buttonDownParentPos = item->mapToParent(item->mapFromScene(event->
> buttonDownScenePos(Qt::LeftButton)));
> [...]
> item->setPos(initialPositions.value(item) + currentParentPos -
> buttonDownParentPos);
>
> Basically the above 3 lines would be correct only and only if the
> initialPositions were expressed in a dynamic way, that is, if they were
> independent of the parent's CS since it can change during the move.
>
> The following pseudo-code modifications fixes that:
>
> // 'Capture' time
> initialPosition = item->mapToScene(item->mapFromParent(item->pos())); //
> Independent of parent CS
> [...]
> // 'Update' time
> initialPosition = item->mapToParent(item->mapFromScene(initialPosition));
> // up-to-date w/ changed parent's CS
> item->setPos(initialPosition + currentParentPos - buttonDownParentPos);
>
>
> This modification fixes my use-cases, and doesn't seem to break the "4
> chips" and other demo/example.
> The scene's private 'movingItemsInitialPositions' is only set/used by
> QGI::mouseMoveEvent() and cleared by QGI::mouseReleaseEvent(), so this is
> not an invasive change
>
>
> So my chain of question is:
> - Is changing the item's parent position in an item's itemChange() a
> supported feature?
> - if it is, then isn't there a bug in qgraphicsitem.ccp as i described
> above?
> - if positive, is the above fix correct and would you accept this sort of
> things if i push that to gerrit?
>
>
> Chris
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Bug (and fix) in QGItem::itemChange() (?)

[Ch'Gans]

Please find attached a simple demo:
If you try to move the big green rect by dragging the small red rect, the
big rect will goes "wild", using my proposed fixed, the big rect follows
the mouse as you drag the small rect.

Chris

On 16 February 2017 at 17:52, Ch'Gans <chg...@gna.org> wrote:

> Hi there,
>
> Here is my use-case:
> An item has "handles" child items, when the user moves around an handles,
> the parent item update it's geometry and position accordingly. Simple
> concept to let the user change an item geometry by dragging handles.
> Imagine, you're using a drawing application, you select a circle and 5
> handles appear on the screen, one in each corner to resize the circle, and
> one in the center to move the circle around.
>
> The way i implement it is to let the circle item filter an handle item's
> 'itemChange()' notification. This work nicely for resizing handles, but
> fails for the 'move handle'. Here is the simplified pseudo code:
> QVariant HandleItem::itemChange(change, value)
> {
>  // Move the parent to where the handle wants to go...
>  parentItem()->setPos(parentItem()->mapToParent(value);
>  // ... and leave the handle at parent's origin
>  return QPointF(0, 0);
> }
>
> After banging my head for a while, i finally pin-pointed what I think is
> the problem:
>
> This is related to how items are moved in qt5/qtbase/src/widgets/
> graphicsview/qgraphicsitem.cpp. When a move begins, the 'initial
> position' of the item is stored in the scene. This initial position is
> simply the value of item->pos(), which is in parent's item CS:
>
> initialPositions = d_ptr->scene->d_func()->movingItemsInitialPositions;
> if (initialPositions.isEmpty()) {
>   foreach (QGraphicsItem *item, selectedItems)
> initialPositions[item] = item->pos();
>   initialPositions[this] = pos();
> }
> d_ptr->scene->d_func()->movingItemsInitialPositions = initialPositions;
>
> As the move goes on, the item's pos is updated based on this 'initial
> position' (expressed in an outdated parent's CS) and the parent position
> relative to the item's position:
>
> currentParentPos = item->mapToParent(item->mapFromScene(event->scenePos()
> ));
> buttonDownParentPos = item->mapToParent(item->mapFromScene(event->
> buttonDownScenePos(Qt::LeftButton)));
> [...]
> item->setPos(initialPositions.value(item) + currentParentPos -
> buttonDownParentPos);
>
> Basically the above 3 lines would be correct only and only if the
> initialPositions were expressed in a dynamic way, that is, if they were
> independent of the parent's CS since it can change during the move.
>
> The following pseudo-code modifications fixes that:
>
> // 'Capture' time
> initialPosition = item->mapToScene(item->mapFromParent(item->pos())); //
> Independent of parent CS
> [...]
> // 'Update' time
> initialPosition = item->mapToParent(item->mapFromScene(initialPosition));
> // up-to-date w/ changed parent's CS
> item->setPos(initialPosition + currentParentPos - buttonDownParentPos);
>
>
> This modification fixes my use-cases, and doesn't seem to break the "4
> chips" and other demo/example.
> The scene's private 'movingItemsInitialPositions' is only set/used by
> QGI::mouseMoveEvent() and cleared by QGI::mouseReleaseEvent(), so this is
> not an invasive change
>
>
> So my chain of question is:
> - Is changing the item's parent position in an item's itemChange() a
> supported feature?
> - if it is, then isn't there a bug in qgraphicsitem.ccp as i described
> above?
> - if positive, is the above fix correct and would you accept this sort of
> things if i push that to gerrit?
>
>
> Chris
>
// export LD_LIBRARY_PATH=~/Projects/qt5/lib/
// g++ -o test -fPIC main.cpp -I ~/Projects/qt5/include/ -L ~/Projects/qt5/lib/ -lQt5Widgets -lQt5Gui -lQt5Core
// ./test

#include 
#include 
#include 
#include 
#include 

class Rect: public QGraphicsRectItem
{
public:
Rect(QGraphicsItem *parent = nullptr):
QGraphicsRectItem(parent)
{
setFlag(ItemSendsGeometryChanges);
setFlag(ItemIsMovable);
}

protected:
virtual QVariant itemChange(GraphicsItemChange change, const QVariant ) override
{
if (change == ItemPositionChange && parentItem())
{
parentItem()->setPos(parentItem()->mapToParent(value.toPointF()));
return QPointF();
}
return value;
}
};

int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QGraphicsScene scene;
scene.setSceneRect(-20, -20, 40, 40);
QGraphicsView view;
view.setScene();
Rect big;
big.setRect(-10, -10, 20,

[Development] Bug (and fix) in QGItem::itemChange() (?)

[Ch'Gans]

Hi there,

Here is my use-case:
An item has "handles" child items, when the user moves around an handles,
the parent item update it's geometry and position accordingly. Simple
concept to let the user change an item geometry by dragging handles.
Imagine, you're using a drawing application, you select a circle and 5
handles appear on the screen, one in each corner to resize the circle, and
one in the center to move the circle around.

The way i implement it is to let the circle item filter an handle item's
'itemChange()' notification. This work nicely for resizing handles, but
fails for the 'move handle'. Here is the simplified pseudo code:
QVariant HandleItem::itemChange(change, value)
{
 // Move the parent to where the handle wants to go...
 parentItem()->setPos(parentItem()->mapToParent(value);
 // ... and leave the handle at parent's origin
 return QPointF(0, 0);
}

After banging my head for a while, i finally pin-pointed what I think is
the problem:

This is related to how items are moved in
qt5/qtbase/src/widgets/graphicsview/qgraphicsitem.cpp. When a move begins,
the 'initial position' of the item is stored in the scene. This initial
position is simply the value of item->pos(), which is in parent's item CS:

initialPositions = d_ptr->scene->d_func()->movingItemsInitialPositions;
if (initialPositions.isEmpty()) {
  foreach (QGraphicsItem *item, selectedItems)
initialPositions[item] = item->pos();
  initialPositions[this] = pos();
}
d_ptr->scene->d_func()->movingItemsInitialPositions = initialPositions;

As the move goes on, the item's pos is updated based on this 'initial
position' (expressed in an outdated parent's CS) and the parent position
relative to the item's position:

currentParentPos = item->mapToParent(item->mapFromScene(event->scenePos()));
buttonDownParentPos =
item->mapToParent(item->mapFromScene(event->buttonDownScenePos(Qt::LeftButton)));
[...]
item->setPos(initialPositions.value(item) + currentParentPos -
buttonDownParentPos);

Basically the above 3 lines would be correct only and only if the
initialPositions were expressed in a dynamic way, that is, if they were
independent of the parent's CS since it can change during the move.

The following pseudo-code modifications fixes that:

// 'Capture' time
initialPosition = item->mapToScene(item->mapFromParent(item->pos())); //
Independent of parent CS
[...]
// 'Update' time
initialPosition = item->mapToParent(item->mapFromScene(initialPosition));
// up-to-date w/ changed parent's CS
item->setPos(initialPosition + currentParentPos - buttonDownParentPos);


This modification fixes my use-cases, and doesn't seem to break the "4
chips" and other demo/example.
The scene's private 'movingItemsInitialPositions' is only set/used by
QGI::mouseMoveEvent() and cleared by QGI::mouseReleaseEvent(), so this is
not an invasive change


So my chain of question is:
- Is changing the item's parent position in an item's itemChange() a
supported feature?
- if it is, then isn't there a bug in qgraphicsitem.ccp as i described
above?
- if positive, is the above fix correct and would you accept this sort of
things if i push that to gerrit?


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

Re: [Development] Documentation typo fixes

[Ch'Gans]

On 7 February 2017 at 23:18, Edward Welbourne  wrote:
[...]
>
> Sze Howe Koh (7 February 2017 04:35) replied:
>> See http://wiki.qt.io/Branch_Guidelines (Note: Qt module repositories
>> don't have a "master" branch)
>>
>> Right now, the branches that accept documentation fixes are:
>>
>> * 5.8 (stable branch)
>> * 5.9 (next release branch)
>> * dev (development branch)
>>
>> Simply put, patches will merge from the top of the list to the bottom
>> of this list. For example, patches that go into "5.8" will eventually
>> be merged into "5.9", which in turn will eventually be merged into
>> "dev".
>>
>> Typo fixes are not new features or major/risky changes, so they can go
>> into the stable branch ("5.8").
>
> Indeed.  This is all being formalised in QUIP 5:
> https://codereview.qt-project.org/178906
> where you can find out all you wish to know about which changes should
> go to which branches,

Thanks both of you for the information.
Chris

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

[Development] Documentation typo fixes

[Ch'Gans]

Hi there,

It's been a while that I notice some typos here and there in Qt5
documentation (mainly qtbase), and i decided that i would start
correcting them in the source code.
Most of them are really straight forward, eg. in QGraphicsView::setTransform:
"To simplify interation with items using a transformed view, ..."
should be:
"To simplify interaction with items using a transformed view, ..."

It's just one example from this morning. Not a big of a deal, but
documentation looks always nicer without typos.

I would like to know to which branch should i target such "code
review" on gerrit.
Should it be "Current release", "Next release", "dev" or "master"?
My gut feeling tells me "dev", so that from there, maintainers can
decide if they want to propagate or not.
Could someone confirm this?

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

Re: [Development] Calendar Systems proposal

[Ch'Gans]

On 16 December 2016 at 10:10, Sune Vuorela  wrote:
> On 2016-12-15, Soroush Rabiei  wrote:
>> 2.History
>>
>
> Hi
>
> I would welcome more calendar systems.  Personally I hope for french
> revolutionary calendar. Because it is funny.
>
> I think you need to touch quite some of the 'inner bits' of date / time,
> and while you are there, I'd love if the design could make it easier to
> implement my two missing pet features:
>  - Partial dates
>  - Date/time intervals/delta's.
>
> You might need the latter part for the implementation.
>
> (By partial dates, I mean e.g. my friend has birthday on november 1st.
> every year. or unknown year.)
>
> (by date/time deltas, I e.g. I started working somewhere on november 1st
> 2014. and stopped january 3rd 2015. How long did I work there)

Boost have them all: date/time, calendar, time zone, time period and
time duration
Date/Time is a very tricky subject, why not rely on boost implementation?

http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/group__date__time.html


Chris


>
> /Sune
>
> ___
> 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] Please test Qt 5.6.2 final packages

[Ch'Gans]

On 8 October 2016 at 00:26, Jani Heikkinen  wrote:
>
> Hi all,
>
> We have final Qt 5.6.2 packages here:
>
> Windows: http://download.qt.io/snapshots/qt/5.6/5.6.2/571/
> Linux: http://download.qt.io/snapshots/qt/5.6/5.6.2/505/
> Mac: http://download.qt.io/snapshots/qt/5.6/5.6.2/442/
> src: http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/ (mirroring 
> might still be ongoing)
>
> Please test the packages & report all new blockers immediately. If packages 
> are still good enough we will release these packages as Qt 5.6.2 during the 
> next week
>
> Packages are RTA tested and all seems to be OK.

Hi Jani,

Sorry for the dumb question, but may I ask what "RTA tested" mean?

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

Re: [Development] How can I only select border not inside rectangle to select QGraphicsRectItem

[Ch'Gans]

On 4 October 2016 at 10:51, itviewer  wrote:

> Hi,
> I draw a rectangle with QGraphicsRectItem. it only has a border and not
> be filled. like this:
>
> when I click inside the rectangle,it will be selected，but I would like
> only click on the border  to select, not inside.
> how can i get it?
>

Reimplement shape(), and use QPainterPathStroker ?

Chris


> Thanks.
>
>
> --
> itviewer
>
> ___
> 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] Qt API review with clazy

[Ch'Gans]

On 12 September 2016 at 21:13, Mathias Hasselmann
 wrote:
> Hello Chris,
[...]
> Besides clazy being blasting fast you are comparing apples with oranges. The
> issues clazy blames are plain Qt usage bugs. Just the same kind of issues
> the compiler reports for regular C++ already. Ideally the compilers would
> checks those issues out of the box already. Obviously they can't because Qt
> layers stuff on top of C++.

BTW, have you tried to use clazy by adding the flags in QtC C++ clang
model? (tools->options->C++->code model)
I have no clue if it is even doable, i'm just asking.

Chris

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

Re: [Development] Qt API review with clazy

[Ch'Gans]

On 12 September 2016 at 21:13, Mathias Hasselmann
 wrote:
> Hello Chris,
>
>> On 12 September 2016 at 19:06, Mathias Hasselmann
>>  wrote:
>>>
>>> Just that the approach of clang-tidy is fundamentally wrong:
>>
>>
>> Hi Mathias,
>>
>> No offense, but you arguments are fundamentally wrong too. Your
>> workflow is not everyone's workflow!
>>
>>>
>>> You simply don't do static checks as a after thought, at random times
>>> when
>>> sun, mars and moon are in proper constellation.
>>
>>
>> I don't see the problem, people are free to choose if, when and which
>> checks they fancy run.
>>
>>> Why? Because when running this checks occasionally too much cruft will
>>> have
>>> accumulated that it is worth and reasonable to fix those issues: Too big
>>> chunk of boring and still expensive work. Too big risk to introduce
>>> regressions.
>>
>>
>> Running clang-tidy is way slower than compiling code, a nightly check
>> might be enough (or not, again this is a personal choice), or you
>> could decide to run the checks systematically on pull requests because
>> you don't trust the authors (for whatever reason, inc the usual "oops,
>> forgot to do that", human do errors).
>
>> Sanity checks ran by clang-tidy can be of arbitrary complexity, and as
>> such can take really long time. You might not want to be slow down by
>> this while you're actively developing.
>
> Well, with clang-tidy being slow you just gave another reason to have a
> compiler plugin for this quick, very obvious tests. In my experience clazy
> has no measurable impact to compile time.

I never said that clazy was not useful, I was just saying that you
should use the right tool for the right job. Both tools are
complimentary, people have different use-cases.

>
>> If you go this way, then why don't you always run your applications in
>> profiling mode to make sure you don't introduce bottle-necks or memory
>> leaks "as-you-go"? Well we all know the answer: Because it is way too
>> slow.
>
>
> Besides clazy being blasting fast you are comparing apples with oranges. The
> issues clazy blames are plain Qt usage bugs. Just the same kind of issues
> the compiler reports for regular C++ already. Ideally the compilers would
> checks those issues out of the box already. Obviously they can't because Qt
> layers stuff on top of C++.

Effectively, I'm not sure we're talking about the same things here.
Maybe clazy plugin could be even use by Qtc clang code model if it's
that fast (I really like the "compile errors/warnings" as you type,
altho not perfect). I was talking about "deeper" checks, like the ones
listed in the "group of checks" table as per
http://clang.llvm.org/extra/clang-tidy/index.html#using-clang-tidy
They are really more than what clazy proposes (for now). And you
definitely don't want them to be run each time you build your app.

So, all in all, it looks to me that the clazy plugin is the way to go
for fast checks, and clang-tidy for the more thoughtfully ones. Hence
my message about being able to use these new checks both form the
compiler command and from an external tool such as clang-tidy. Deeper,
time-consuming, Qt-specific checks would be welcome as a new
clang-tidy check group.
The checks clang-tidy propose are not limited to "potential bugs", it
does cover as well coding guideline and styles and AFAIR Qt use custom
perl scripts for style and basic errors checking (might have changed
since last time i checked).

Cherry on the cake, with clang-tidy (actually a llvm feature used by
clang-tidy) is that it can generates the fixes as well, and even apply
them in one go. A feature which I believe is used by QtC to propose
you the "hot fix" accessible with Alt-Return (On Linux).

"clang-tidy -checks=* -list-checks" here gives me a list of 184 checks
(LLVM v3.8.0). Not all are useful and some of them are not always
applicable or sometimes give false positive, but it should give you a
fair idea of what does already exists in there.

Chris

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

Re: [Development] Qt API review with clazy

[Ch'Gans]

On 12 September 2016 at 19:06, Mathias Hasselmann
<math...@taschenorakel.de> wrote:
> Just that the approach of clang-tidy is fundamentally wrong:

Hi Mathias,

No offense, but you arguments are fundamentally wrong too. Your
workflow is not everyone's workflow!

>
> You simply don't do static checks as a after thought, at random times when
> sun, mars and moon are in proper constellation.

I don't see the problem, people are free to choose if, when and which
checks they fancy run.

> Why? Because when running this checks occasionally too much cruft will have
> accumulated that it is worth and reasonable to fix those issues: Too big
> chunk of boring and still expensive work. Too big risk to introduce
> regressions.

Running clang-tidy is way slower than compiling code, a nightly check
might be enough (or not, again this is a personal choice), or you
could decide to run the checks systematically on pull requests because
you don't trust the authors (for whatever reason, inc the usual "oops,
forgot to do that", human do errors).

> You really want to make this checks part of your daily development
> experience, you want the compiler to tell you about your mistakes as soon as
> you compile that code for the first time. It's much easier to fix your
> mistakes if you just wrote them. It's much safer to fix them before even
> doing the first tests. Well, and you'll learn much earlier about possible
> anti-patterns, so you'll write less of such code.

Maybe, but again, this is a personal choice based on personal usage of
the said tool.

> I hear you saying "but you could add clang-tidy" to your build scripts, but
> that's not a valid argument adding the following flags is considered too
> much effort already:
>
>   -Xclang -load -Xclang ClangLazy.so -Xclang -add-plugin -Xclang clang-lazy

This has nothing to do with clang-tidy, this is how you would use
Sergio's *clang plugin*.
Clang tidy is a separate tool that you can run externally once you
have extracted the compilation database from your project. clang-tidy
doesn't compile anything, it just run sanity checks, period.

Sanity checks ran by clang-tidy can be of arbitrary complexity, and as
such can take really long time. You might not want to be slow down by
this while you're actively developing.
If you go this way, then why don't you always run your applications in
profiling mode to make sure you don't introduce bottle-necks or memory
leaks "as-you-go"? Well we all know the answer: Because it is way too
slow.

Chris.

> Thanks,
> Mathias
>
> Disclaimer: I am working with Sergio and using his awesome plugin since its
> very first days.
>
>
> Am 12.09.2016 um 08:38 schrieb Ch'Gans:
>>
>> On 12 September 2016 at 10:34, Sergio Martins <sergio.mart...@kdab.com>
>> wrote:
>>>
>>> On Sunday, 11 September 2016 21:43:46 WEST Jérémie Delaitre wrote:
>>>>
>>>> Can the same checks be implemented in clang-tidy instead of having yet
>>>> another tool? clang-tidy now has boost specific checks so maybe they
>>>> would
>>>> also accept a Qt specific module in there.
>>>
>>>
>>> I haven't been able to use clang-tidy on big qmake projects such as Qt,
>>> it
>>> either crashes or stops with "include not found" errors. It also requires
>>> an
>>> intermediate step, where you generate a "compiler command database" file
>>> with
>>> yet another tool [1]
>>
>>
>> Both CMake (since 2.8.5, see [1]) and Qbs (master branch) can generate
>> this "compiler command database".
>> Maybe your tool could be made to work with this DB (via clang-tidy)
>> and as a clang plugin.
>> The DB approach has the added advantage that it doesn't require
>> modifying CXX flags, which can be a problem on projects that have
>> "buggy" build files.
>> Having your checks run by clang-tidy would also definitely widen your user
>> base.
>> clang-tidy have specific rules for LLVM, boost, google, ... Would be
>> nice to add Qt.
>>
>> Chris
>>
>> [1]
>> http://clang.llvm.org/docs/JSONCompilationDatabase.html#supported-systems
>>
>>> clazy, otoh, is a compiler plugin, it integrates with your normal
>>> compilation
>>> run, you don't have to run any more tools after doing "make" as you
>>> usually
>>> do.
>>>
>>> Enabling clazy is just a matter of modifying your CXX flags,  which you
>>> can
>>> easily do with qmake or mkspec. Or ENABLE_CLAZY in CMake if you're
>>> building
>>> KDE.
>>>
>>>
>>> [1] https://github.com/rizsotto

Re: [Development] Qt API review with clazy

[Ch'Gans]

On 12 September 2016 at 10:34, Sergio Martins  wrote:
> On Sunday, 11 September 2016 21:43:46 WEST Jérémie Delaitre wrote:
>> Can the same checks be implemented in clang-tidy instead of having yet
>> another tool? clang-tidy now has boost specific checks so maybe they would
>> also accept a Qt specific module in there.
>
> I haven't been able to use clang-tidy on big qmake projects such as Qt, it
> either crashes or stops with "include not found" errors. It also requires an
> intermediate step, where you generate a "compiler command database" file with
> yet another tool [1]

Both CMake (since 2.8.5, see [1]) and Qbs (master branch) can generate
this "compiler command database".
Maybe your tool could be made to work with this DB (via clang-tidy)
and as a clang plugin.
The DB approach has the added advantage that it doesn't require
modifying CXX flags, which can be a problem on projects that have
"buggy" build files.
Having your checks run by clang-tidy would also definitely widen your user base.
clang-tidy have specific rules for LLVM, boost, google, ... Would be
nice to add Qt.

Chris

[1] http://clang.llvm.org/docs/JSONCompilationDatabase.html#supported-systems

> clazy, otoh, is a compiler plugin, it integrates with your normal compilation
> run, you don't have to run any more tools after doing "make" as you usually
> do.
>
> Enabling clazy is just a matter of modifying your CXX flags,  which you can
> easily do with qmake or mkspec. Or ENABLE_CLAZY in CMake if you're building
> KDE.
>
>
> [1] https://github.com/rizsotto/Bear
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt Experts
> ___
> 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] Notes on "Qt Build Systems" @ QtCon 2016

[Ch'Gans]

On 7 September 2016 at 01:47, Viktor Engelmann <viktor.engelm...@qt.io>
wrote:

>
> Am 06.09.2016 um 06:52 schrieb Ch'Gans:
>
> On 6 September 2016 at 16:20, Thiago Macieira <thiago.macie...@intel.com> 
> <thiago.macie...@intel.com> wrote:
>
> Which is, in itself, an argument: why learn yet another buildsystem?
>
> ...
>
> Why learn yet another programming language?
>
> ...
>
> An average software developer knows about, says 10 to 20 programming
> languages, maybe even more depending on the definition of "language".
> Why should he/she knows just one build system?
>
> Chris
>
>
> My 2 cents: I want to spend my time on programming = being productive -
> Not waste my time fighting against an incredibly stupid build system...
>
> In my opinion, build systems in general haven't matured the way compilers
> have. Using classes and polymorphism, you can easily explain arbitrarily
> complex situations to compilers. I have yet to see a build system that
> understands more complex situations than "FILE1 IS OLDER THAN FILE2".
>

This is the Makefile approach, the whole Makefile thing is based on "FILE1
IS OLDER THAN FILE2" (and so is CMake). I think that Qbs is way more than
this. Maybe have a quick look at the documentation to realise how the
approach is completely different. Qbs understand the concept of classes and
polymorphism. In my projects, I define a "base class" (a Product in Qbs
terminology), and I can derive this product into more specific product, of
course derived products inherit from their base behaviours and properties,
and of course i can overwrite properties (inc, full overwrite, append,
prepend, transform, ...).

Qbs is really different.

See eg. http://doc.qt.io/qbs/language-introduction.html


They don't even have the slightest understanding of the commands they
> execute - they just slap some raw strings together (which YOU have to
> provide) and pass them to a shell. Oh, these raw strings were for a
> different OS? Or even just a different version of the same compiler on the
> same OS? well too bad...
>
> It kind of reminds me of this joke:
> http://www.ebaumsworld.com/jokes/blond-hole-diggers/80432143/
>

Will have to check this one at home, corporate "firewall" tells me: "404:
Access denied - Adult detected" ...

Chris


>
>
> Viktor
>
> --
>
>
> Viktor Engelmann
> Software Engineer
>
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> viktor.engelm...@qt.io
> +49 151 26784521
> http://qt.io
>
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht
> Charlottenburg, HRB 144331 B
> <http://qt.io>
> <http://www.facebook.com/Qt> <http://www.twitter.com/qtproject>
> <https://www.linkedin.com/company/the-qt-company/>
> <https://plus.google.com/104580575722059274792>
> <https://www.youtube.com/QtStudios>
> [image: Qt World Summit 2016] <http://qtworldsummit.com/>
> Qt World Summit 2016 | Pier 27, San Francisco, CA
> Experience Exponential Potential on October 18-20
> www.qtworldsummit.com
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Ch'Gans]

[Keeping discussion posted on ML]

On 7 September 2016 at 20:08, Viktor Engelmann 
wrote:

> Really? I haven't checked out Qbs yet, but that sounds like the build
> system I was looking for.
>
> So maybe I don't have to write my own build tool after all :-D
>
Give it a try, but beware: Qbs is addictive.

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Ch'Gans]

On 6 September 2016 at 16:20, Thiago Macieira <thiago.macie...@intel.com> wrote:
> Em terça-feira, 6 de setembro de 2016, às 13:40:40 PDT, Ch'Gans escreveu:
>> On 6 September 2016 at 01:52, Konstantin Tokarev <annu...@yandex.ru> wrote:
>> > 05.09.2016, 16:38, "Kevin Kofler" <kevin.kof...@chello.at>:
>> >> Andrew Knight wrote:
>> >>>  * Quick survey: which build system do you use (raise of hands by ~40
>> >>>  people)
>> >>>  - CMake ~70%
>> >>>  - qmake ~20%
>> >>>  - Qbs ~10%
>> >>
>> >> That basically says it all. :-)
>>
>> Yes, that basically says it all: 90% of people were certainly unaware
>> or unfamiliar with Qbs! ;)
>
> Which is, in itself, an argument: why learn yet another buildsystem?

Good question, maybe because it's more powerful, it fits better your
needs, it is more fun, it uses new concepts, ...
Or just out of curiosity!

Why learn yet another programming language?

If I followed this reasoning, I would still be writing my programs in
Motorola assembler...
Luckily, I've learned other languages like C, C++, Python, Lua, JS,
Qml, etc, ...

An average software developer knows about, says 10 to 20 programming
languages, maybe even more depending on the definition of "language".
Why should he/she knows just one build system?

Chris

>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Ch'Gans]

On 6 September 2016 at 01:52, Konstantin Tokarev  wrote:
> 05.09.2016, 16:38, "Kevin Kofler" :
>> Andrew Knight wrote:
>>>  * Quick survey: which build system do you use (raise of hands by ~40
>>>  people)
>>>  - CMake ~70%
>>>  - qmake ~20%
>>>  - Qbs ~10%
>>
>> That basically says it all. :-)

Yes, that basically says it all: 90% of people were certainly unaware
or unfamiliar with Qbs! ;)

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

Re: [Development] Notes on "Qt Build Systems" @ QtCon 2016

[Ch'Gans]

On 5 September 2016 at 23:08, NIkolai Marchenko  wrote:
> Been using QBS for the last 6 months, transformed all projects to it(from
> qmake). Never looked back.
> It just clicks for me. Most everything seems logical (if poorly explained)
> when you understand how to do it.

I have switched quite a few projects from qmake to Qbs, and me too I
never looked back!
QtCreator has decent support for Qbs (could be improved tho, qmake
support could be improved too and same goes with CMake)
I never wanted to use CMake b/c for me it look like a gross hack
(Reminds me of GNU M4).
Qbs has been designed from the ground up to tackle build management,
and it does it very well in a very elegant and efficient way.
Qbs is a radical change compared to the usual Makefile-generator approach.
Qbs relies on Qt, Qt declarative and Qt JS, which brings a work horse
CMake cannot even dream of.
I would compare CMake and Qbs, the same way Linus Torvald compares SVN and Git:
SVN claims to be CVS but better => Epic fail, Git has been designed to
address devs need using a new and efficient approach.

I've recently contributed to Qbs (with great help from Jake and
Christian), and I've been amazed how easy, simple and straight-forward
the job was.
We're talking 500 lines of raw source code (inc blanks, comments,
autotests, qbs files, ...) to add a Clang Database generator to
Qbs!
This was that easy because of Qbs architecture but Qt did help a lot
too, generating a JSON Db with Qt was a piece of cake.

I know that lot of project use CMake, but as someone noted, projects
use CMake because they have to, not because they want too.
What are the other cross-platform choices? Autotools, hand-crafted
Makefiles, Scons, Maven, ...
Quite some years ago I was a happy GNU autotools user. Yes I was happy
with it! Why? b/c I didn't have choice back at that time.
Now, each time I have to hack an autotools-based project, I want to
wash my hands 200 times in a raw, yuck!

> One thing QBS needs is better documentation, because a lot of things that
> are "obvious" to Christian Kandeler and Jake Petroules (sorry if misspeled)
> are not ever mentioned in the docs or are in obscure places.
> Using QBS effectively is literally impossible without knowledge of
> freenode:#qt-qbs

Yeah, sort of true. I've learned Qbs by looking at Qbs's own qbs files
and QtCreator's ones too. And of course the documentation, which is
"just" good enough to get started.
It didn't take long to get my projects ported. I now have a
easy-to-read, easy-to-understand, easy-to-extend cross-platform build,
test and packaging (inc. installer) system. Bye bye qmake!

Makefiles are out-dated (no punt intended) and so is CMake and any
other Makefile-based tools.
Makefiles are dead! CMake is ill! (Friendly, easy and provocative argument)

Long live Qbs!

My 2 cents,
Chris

>
> On Mon, Sep 5, 2016 at 1:27 PM, Sune Vuorela  wrote:
>>
>> On 2016-09-05, Andrew Knight  wrote:
>> > tl;dr: Lots of discussion on the merits of which build system (CMake,
>> > Qbs) should replace qmake in building Qt; lots of supporters of CMake
>> > but no volunteers to do the work, many reasons to use Qbs as well. Some
>>
>> I do think that there is volunteers to get Qt building with cmake if
>> there is a likly chance of getting it accepted. I think I also
>> commmunicated that at the session.
>>
>> /Sune
>>
>> ___
>> 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] RHEL 7.2 added to Coin

[Ch'Gans]

BTW, is it just me or http://testresults.qt.io/ci/status/ has some problems:

error fetching data from http://testresults.qt.io/cgi-bin/ci-api:
error; Can't connect to 127.0.0.1:7181 (Connection refused); Can't
connect to 127.0.0.1:7181 (Connection refused)
LWP::Protocol::http::Socket: connect: Connection refused at
/usr/share/perl5/LWP/Protocol/http.pm line 51. ()

Chris


On 28 June 2016 at 00:30, Frederik Gladhorn  wrote:
> Hi all,
>
> good news when it comes to packaging on Linux, we added red hat 7.2 as the new
> packaging config for the dev branch - Qt 5.8 that is. We'll also run it as
> developer build with the 5.7 branch. I'll flip the switch to actually run it 
> in
> a few minutes.
>
> I'd not be terribly surprised if some module has issues, even though we did
> successfully produce complete builds of all modules and run all tests, but
> there is a chance that something changed or new flaky ness is added.
>
> If you see things that look suspicious on the new platform, please let me
> know.
>
> Cheers,
> Frederik
>
> ___
> 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] API Change in QtRemoteObjects

[Ch'Gans]

Was going through the changes out of curiosity and found that:
Is a '\n' is missing at line 51? See
https://codereview.qt-project.org/#/c/144624/10/examples/RemoteObjects/ModelViewClient/main.cpp

My 2 cents,
Chris

On 3 January 2016 at 06:51, Stottlemyer, Brett (B.S.)  wrote:
> Hello,
>
> For those of you using the QtRemoteObjects playground module (QtRO for
> short), some changes went in over the holidays that changed the public
> API.  So you will need to update your code when you update to any version
> of master past 16959709b59db45c07385ecc13b76061de851edf (or see the
> (merged) review: https://codereview.qt-project.org/#/c/144624/).
>
> From the commit message:
>> Convert Nodes to QObject based class(es)
>>
>> This change affects lots of lines of code, but is
>> basically a refactoring, not changing much.  It
>> does change the QtRO API, though.
>>
>> In the interest of making it easier to expose QtRO
>> types to QML, the move to QObject types for Nodes was
>> necessary.
>>
>> The static generators allowed for different "types²
>> of Nodes to be created with different combinations of
>> 1 or 2 QUrl parameters, but this also forced a Node
>> type that had methods that might not make sense (for
>> instance, enableRemoting() from a Node that wasn't a
>> Host Node).  And Nodes needed to be copy-able.
>>
>> This change addresses those issues by creating
>> three distinct types.  QRemoteObjectNode is
>> the most basic type, and only supports acquiring
>> Replica objects.  QRemoteObjectHost Nodes add the
>> ability to share Source objects on the network.  Both
>> Node and Host types support connecting to a Registry.
>>
>> QRemoteObjectRegistryHost Nodes host a Registry object
>> other nodes can connect to.
>>
>> This change requires converting end-user code from
>> the static functions (createHostNode, etc) to using
>> the new types explicitly.
>>
>> Aside from the obvious change from static generator
>> functions, there are two other impacts to user code:
>> 1) connect() was renamed to connectToNode to not
>> conflict with QObject's connect()
>> 2) default QUrls for Hosting and Registry were removed
>> (it was too easy to create name clashes with unexpected
>> results).
>
> Apologies for any inconvenience, but this will make QML integration
> simpler, and makes the APIs more aligned with other Qt APIs.
>
> Happy Holidays/Happy New Year!
> Brett
>
> ___
> 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] Setup QT creator for developing QT apps on wandboard-Error

[Ch'Gans]

On 29/07/14 18:44, Nilesh Kokane wrote:
 Hi Christian,

 First of all thanks for your valuable reply.

 Based on your  suggestion I pinged the board with the boards ip address
 which i found it from the serial console

 $ ping 127.0.0.1

Hi Nilesh,

127.0.0.1 is your local network node, so it's very unlikely it will ever 
failed. This is all very basic Unix/networking knowledge...

You need to find out the IP address of your board, I don't know how your 
computer is setup, nor do I know how your board is. So I'm sorry but I 
can't help you on that one

 gave success

 Also i pinged the host PC trough the board with

 $ ping 127.0.0.2

 Gave success

Forget about 127.0.0.2... this is not what you are after.


 But with SSH from the host

 $ ssh root@127.0.0.1 mailto:root@127.0.0.1


 Connecting to host...

 SSH connection failure: Connection refused

Forget about that one too...

 $ find
 /home/minda/bin/fsl-community-bsp/build/tmp/sysroots/wandboard-solo
 -name libicui18n.so.51 -o -name libz.so.1


 /tmp/sysroots/wandboard-solo -name libicui18n.so.51 -o -name libz.so.1
 /home/minda/bin/fsl-community-bsp/build/tmp/sysroots/wandboard-solo/lib/libz.so.1
 /home/minda/bin/fsl-community-bsp/build/tmp/sysroots/wandboard-solo/usr/lib/libicui18n.so.51

Interesting, can you try this then:
$ find 
/home/minda/bin/fsl-community-bsp/build/tmp/sysroots/wandboard-solo 
-name 'libQt*'

 What does this command gives?
 $ sh -x ./qtcreator.sh


 + source
 /opt/poky/1.4.1/environment-setup-armv7a-vfp-neon-poky-linux-gnueabi
 ./qtcreator.sh: 2: ./qtcreator.sh: source: not found

Not good, in a previous email you mentioned /opt/poky/1.6.1/..., and now 
it seems to be /opt/poky/1.4.1/...

Which version of Poky are you really using?

One key question you need to ask yourself is whether you need Qt4 or 
Qt5. Can you answer that?

If you keep changing your environment all the time, we won't be able to 
help, you might be interested in this FAQ: 
http://catb.org/~esr/faqs/smart-questions.html

[...]

 Have you tried the bitbake meta-toolchain-qt5 command?

 No i didn't tried ,can you please provide the step for that

Try this:
$ cd /home/minda/bin/fsl-community-bsp/
$ bitbake meta-toolchain-qt5


Chris

-- 
QtCreator/qmakeparser.cpp:42
// Parser ///
#define fL1S(s) QString::fromLatin1(s)
namespace { // MSVC2010 doesn't seem to know the semantics of static ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Cross compile Qt5 for QtCreator -Problem

[Ch'Gans]

On 25/07/14 22:49, Nilesh Kokane wrote:
 HelloChristian  Thiago

 First of all thanks for your suggestions.


 I know the documentation you cited states to manually cross-build Qt5 to
 setup QtCreator, but why don't you just bitbake meta-toolchain-qt5?

 can you please provide the URL for bitbake meta-toolchain-qt5?

This is just a command line to be run within your poky/yocto directory.


 I found out
 http://wiki.wandboard.org/index.php/Setup_QT_creator_for_developing_QT_apps_on_wandboard
 for that, will that work?

Yes, although it's ugly, but to my knowledge it's the only way to go.
I'm saying it's ugly because it will lock your QtCreator to your 
cross-Qt version, you won't be able to build for anything else than for 
your i.mx6 board.

You might get better support on the yocto mailing lists or on IRC:
https://www.yoctoproject.org/tools-resources/community/mailing-lists

Chris


 sorry, I'm novice to Qt


 Thanks
 Nilesh kokane


 On Fri, Jul 25, 2014 at 10:58 AM, Christian Gagneraud chg...@gna.org
 mailto:chg...@gna.org wrote:

 On 25/07/2014 4:59 p.m., Nilesh Kokane wrote:
   Hello,
  
   i followed
  
 
 http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard#Cross_compile_Qt5_for_QtCreator
   and
  
   1)I've downloaded the QtCreator from
  
 
 http://download.qt-project.org/official_releases/qt/5.1/5.1.1/single/qt-everywhere-opensource-src-5.1.1.tar.gz.mirrorlist
  
   2)/home
 export PATH=$PATH:/opt/poky/1.6.1/
   sysroots/i686-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi
  
  
   3)/qt-everywhere-opensource-src-5.1.1
  
 ./configure -v -opensource -confirm-license -device imx6
   -device-option
  
 
 CROSS_COMPILE=/opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-
   -sysroot
 /home/bin/fsl-community-bsp/build/tmp/sysroots/wandboard-solo
   -prefix ~/qt5arm -platform linux-g++ -shared -no-pch -no-rpath
   -pkg-config -no-accessibility -no-dbus -no-icu -no-directfb -evdev
   -no-fontconfig -no-opengl -opengl es2 -eglfs -no-glib -no-gtkstyle
   -no-iconv -system-libjpeg -no-kms -system-libpng -no-linuxfb
 -no-mitshm
   -no-nis -openssl -qt-pcre -release -no-sm -no-sql-db2 -no-sql-ibase
   -no-sql-mysql -no-sql-oci -no-sql-odbc -no-sql-psql -no-sql-sqlite
   -no-sql-sqlite2 -no-sql-tds -nomake tests -tslib -libudev -widgets
   -no-xcb -no-xcursor -no-xfixes -no-xinerama -no-xinput -no-xinput2
   -no-xkb -no-xrandr -no-xrender -no-xshape -no-xsync -no-xvideo
 -system-zlib

 Why do you set the sysroot to /home/bin/fsl-community-bsp/build/...?
 Is it really where you built the toolchain?

   it popped with ld errors and
  
  
 
 /opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
   -c -fvisibility=hidden fvisibility.c
   Symbol visibility control enabled.
  
 
 /opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++
  
 --sysroot=/home/bin/fsl-community-bsp/build/tmp/sysroots/wandboard-solo
   -o libtest.so -shared -Wl,-Bsymbolic-functions -fPIC
 bsymbolic_functions.c
  
 
 /opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/ld:
   cannot find crti.o: No such file or directory
  
 
 /opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/ld:
   cannot find crtbeginS.o: No such file or directory
  
 
 /opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/ld:
   cannot find -lstdc++
  
 
 /opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/ld:
   cannot find -lm
  
 
 /opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/ld:
   cannot find -lgcc_s
  
 
 /opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/ld:
   cannot find -lc
  
 
 /opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/ld:
   cannot find -lgcc_s
  
 
 /opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/ld:
   cannot find crtendS.o: No such file or directory
  
 
 /opt/poky/1.6.1/sysroots/i686-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/ld:
   cannot find crtn.o: No such file or directory
   collect2: error: ld returned 1 exit status
   Symbolic function binding disabled.

 Because it sounds like there's nothing in this directory...

 I know the 

Re: [Development] Support for your evaluation of Qt

[Ch'Gans]

On 11/07/14 18:50, Ziller Eike wrote:

 On Jul 11, 2014, at 6:21 AM, Christian Gagneraud chg...@gna.org wrote:

 On 11/07/2014 11:22 a.m., Thiago Macieira wrote:
 On Friday 11 July 2014 10:05:03 Christian Gagneraud wrote:
 Boot To Qt for Embedded Linux (Not talking about android here), is based
 on Yocto (which is open-source), there exists a Qt5 layer (Dedicated
 Yocto sub-project), and I think that Digia should be the official
 maintainer of this project. Digia could work hand and hand with Silicon
 Company like Intel, Texas Instrument, Freescale, Xilinx (these companies
 maintain their own SoC specific Yocto layers). Everyone would win if the
 Qt5 Layer was in a good shape and tested on platform based on the
 above-mentioned SoC's manufacturers.
 Today, these SoC manufacturers provide SDKs (Linux kernel + cross
 toolchain + demo image) and few provide a SDK that contains Qt5. I think
 it is Digia's role to help spread the Qt technology on embedded Linux.

 Participating in Yocto by maintaining the Qt5 layer and working on Boot to 
 Qt
 are orthogonal to each other.

 Digia could do both if it wanted to.

 Well at least before they started Boot to Qt w/ Android, working on
 boot to Qt implied polishing the Yocto Qt5 layer or writing another one
 from scratch. They obviously did some work on that and it's a pity that
 nothing have been given back to the community. That was my point.

 Or someone else could do the maintaining of the Qt 5 layer in Yocto. I don't
 see the problem with that either: the Qt Project has a lot of people from
 different companies collaborating together. We don't depend on Digia doing
 everything.

 No, Qt doesn't depend on Digia, but Digia depends on Qt!
 When you look at their Qt Enterprise Embedded, it's Qt, QtCreator,
 QtSimulator, GNU, Linux, Android,  with a pinch of Enterprise
 plug-in's and add-on's all well packed together.

 You should have a look at commit reality in Qt: 
 http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png
 and Qt Creator: 
 http://www.macieira.org/~thiago/qt-stats/current/creator.employer.relative.png

It looks like you got a point! ;)
According to these stats, 70% of Qt commits (qt-all.employer.relative) 
go to Digia, 80% of QtCreator commits (creator.employer.relative) go to 
Digia.
That's quite impressive I have to say and I would like to take this 
opportunity to give a big thanks to all of you.

I think Thiago was more about the Open Governance side of Qt, and I was 
just trying to point to the fact that the core business of Digia is Qt, 
so getting Qt widespread is good for Digia and so having an easily 
accessible Boot to Qt is good for Qt, so at the end it's good for 
Digia too.

If you look at https://github.com/meta-qt5/meta-qt5/graphs/contributors, 
you won't find any Digia traces, which is quite surprising when you 
think that this is the key technology behind Digia's Qt Enterprise 
Embedded.
bad-jokeI even beat you all, with my single 3 lines commit/bad-joke

So now, let's have a look at https://qt.gitorious.org/qt-labs/simulator, 
or maybe not

I'm not here to start an argument, I was more looking for an open 
discussion. Outside of Android, Embedded Linux is very important, it is 
everywhere, in your car, your fridge, your watch, your phone, your 
weight scale, your house alarm system, your home router, ... insert 
your preferred gizmo here, the more embedded Linux system using Qt out 
there, the more likely Digia will have business opportunity, please 
don't follow Silicon Vendors in their closeness habits, embrace the Open 
Source philosophy, it works!

Chris



 Br, Eike


 Besides, IIRC the Boot to Qt project was trying to use the Android base 
 layer
 because that's the best BSP that most silicon vendors provide. Notably, the
 vendors not participating in Yocto.

 They might have switched to Android (Well, apparently not really [1],
 Yocto is used both for targeting Android and Pure Embedded Linux), but
 AFAIK you can boot to Qt in less than 0.5s with a bare embedded Linux
 (using Yocto or similar), whereas it takes 10 times longer with Android.

 Having said all these, Digia has its own business model, maybe I was
 expecting Digia to behave much like Nokia, my mistake.

 Chris

 [1]
 http://linuxgizmos.com/qt-embedded-gui-adds-yocto-recipes-hops-up-emulator/
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


-- 
QtCreator/qmakeparser.cpp:42
// Parser ///
#define fL1S(s) QString::fromLatin1(s)
namespace { // MSVC2010 doesn't seem to know the semantics of static ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Support for your evaluation of Qt

[Ch'Gans]

On 11/07/14 18:50, Ziller Eike wrote:

 On Jul 11, 2014, at 6:21 AM, Christian Gagneraud chg...@gna.org wrote:

 On 11/07/2014 11:22 a.m., Thiago Macieira wrote:
 On Friday 11 July 2014 10:05:03 Christian Gagneraud wrote:
 Boot To Qt for Embedded Linux (Not talking about android here), is based
 on Yocto (which is open-source), there exists a Qt5 layer (Dedicated
 Yocto sub-project), and I think that Digia should be the official
 maintainer of this project. Digia could work hand and hand with Silicon
 Company like Intel, Texas Instrument, Freescale, Xilinx (these companies
 maintain their own SoC specific Yocto layers). Everyone would win if the
 Qt5 Layer was in a good shape and tested on platform based on the
 above-mentioned SoC's manufacturers.
 Today, these SoC manufacturers provide SDKs (Linux kernel + cross
 toolchain + demo image) and few provide a SDK that contains Qt5. I think
 it is Digia's role to help spread the Qt technology on embedded Linux.

 Participating in Yocto by maintaining the Qt5 layer and working on Boot to 
 Qt
 are orthogonal to each other.

 Digia could do both if it wanted to.

 Well at least before they started Boot to Qt w/ Android, working on
 boot to Qt implied polishing the Yocto Qt5 layer or writing another one
 from scratch. They obviously did some work on that and it's a pity that
 nothing have been given back to the community. That was my point.

 Or someone else could do the maintaining of the Qt 5 layer in Yocto. I don't
 see the problem with that either: the Qt Project has a lot of people from
 different companies collaborating together. We don't depend on Digia doing
 everything.

 No, Qt doesn't depend on Digia, but Digia depends on Qt!
 When you look at their Qt Enterprise Embedded, it's Qt, QtCreator,
 QtSimulator, GNU, Linux, Android,  with a pinch of Enterprise
 plug-in's and add-on's all well packed together.

 You should have a look at commit reality in Qt: 
 http://www.macieira.org/~thiago/qt-stats/current/qt-all.employer.relative.png
 and Qt Creator: 
 http://www.macieira.org/~thiago/qt-stats/current/creator.employer.relative.png

It looks like you got a point! ;)
According to these stats, 70% of Qt commits (qt-all.employer.relative) 
go to Digia, 80% of QtCreator commits (creator.employer.relative) go to 
Digia.
That's quite impressive I have to say and I would like to take this 
opportunity to give a big thanks to all of you.

I think Thiago was more about the Open Governance side of Qt, and I was 
just trying to point to the fact that the core business of Digia is Qt, 
so getting Qt widespread is good for Digia and so having an easily 
accessible Boot to Qt is good for Qt, so at the end it's good for 
Digia too.

If you look at https://github.com/meta-qt5/meta-qt5/graphs/contributors, 
you won't find any Digia traces, which is quite surprising when you 
think that this is the key technology behind Digia's Qt Enterprise 
Embedded.
bad-jokeI even beat you all, with my single 3 lines commit/bad-joke

So now, let's have a look at https://qt.gitorious.org/qt-labs/simulator, 
or maybe not

I'm not here to start an argument, I was more looking for an open 
discussion. Outside of Android, Embedded Linux is very important, it is 
everywhere, in your car, your fridge, your watch, your phone, your 
weight scale, your house alarm system, your home router, ... insert 
your preferred gizmo here, the more embedded Linux system using Qt out 
there, the more likely Digia will have business opportunity, please 
don't follow Silicon Vendors in their closeness habits, embrace the Open 
Source philosophy, it works!

Chris



 Br, Eike


 Besides, IIRC the Boot to Qt project was trying to use the Android base 
 layer
 because that's the best BSP that most silicon vendors provide. Notably, the
 vendors not participating in Yocto.

 They might have switched to Android (Well, apparently not really [1],
 Yocto is used both for targeting Android and Pure Embedded Linux), but
 AFAIK you can boot to Qt in less than 0.5s with a bare embedded Linux
 (using Yocto or similar), whereas it takes 10 times longer with Android.

 Having said all these, Digia has its own business model, maybe I was
 expecting Digia to behave much like Nokia, my mistake.

 Chris

 [1]
 http://linuxgizmos.com/qt-embedded-gui-adds-yocto-recipes-hops-up-emulator/
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development


-- 
QtCreator/qmakeparser.cpp:42
// Parser ///
#define fL1S(s) QString::fromLatin1(s)
namespace { // MSVC2010 doesn't seem to know the semantics of static ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Support for your evaluation of Qt

[Ch'Gans]

On 09/07/14 19:53, Andrea Barna wrote:
 Hi,

 I am Andrea from Digia Qt, I have recently taken over the Qt
 businessin your region.

Hi Andrea,

All the best for your new position!

 I noticed that you downloaded the trial version of Qt last year and
 Iwas wondering whether the evaluation went well.

 It would be helpful to understand why you were evaluating Qt, and
 learn more about what type of application you are developing.

I downloaded your evaluation version of Qt to see how different it is 
from the open source one. I am especially interested in embedded and 
industrial application and as such I was curious about your Boot to Qt 
technology.
I was not really surprised to discover that your proprietary Boot to 
Qt technology is based on the open-source Yocto project [1], and I 
think that instead of keeping this technology closed, you should be the 
official maintainer of the Qt5 Yocto layer (lot of work is needed there, 
and you have handles in-house), I think you should contact the Linux 
Foundation [2], they will be glad to see you being a major actor in the 
open-source embedded Linux world.

  Furthermore is there anything that Digia–Qt can help you with?

Definitely yes: please open up your open source based 
commercial/proprietary boot to Qt technology.
I am not asking that because I am an open-source fanatic, I am asking 
that because this is the only reliable and efficient way to get Qt 
massively adopted on the embedded/industrial Linux market, I think that 
Digia should be a (publicly visible) key actor in this sector.

Maybe one day you will be able to replace your Code once, run 
everywhere with Code once, run everywhere, without pain!.
Getting Qt5 + Yocto + OpenGL-ES running across different ARM SoCs is a 
real pain.

Best regards,
Chris

PS: No disrespect to you, Digia, Nokia, TrollTech and all the Qt trolls, 
hat off and thumb up to all you guys! I am just tired to see a beautiful 
open-source SW community being permanently fooled by professional 
closed-source HW company. Please don't be part of this masquerade!

PS2: I've CC'ed the Qt developer mailing list (public archived available 
[3]), hoping this could be useful to someone, somehow, someday.

[1] https://www.yoctoproject.org/
[2] http://www.linuxfoundation.org/about/contact
[3] http://lists.qt-project.org/pipermail/development/



 I look forward to hearing about your project. 
 Best Regards,
 Andrea

 Andrea Barna | Junior Sales Executive
 Digia Norway AS, Sandakerveien 116, PoBOX 23 Nydalen, 0410 Oslo, Norway
 Email: andrea.ba...@digia.com | Phone : +47 210 80 420 | Fax : +47 21080439
 http://qt.digia.com |Qt Blog: http://blog.qt.digia.com/ |Qt Facebook: 
 www.facebook.com/qt  |Qt Twitter: @QtbyDigia

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


-- 
QtCreator/qmakeparser.cpp:42
// Parser ///
#define fL1S(s) QString::fromLatin1(s)
namespace { // MSVC2010 doesn't seem to know the semantics of static ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Embedded (Linux) specific features

[Ch'Gans]

On 16/02/2014 9:46 AM, Pau Garcia i Quiles pgqui...@elpauer.org wrote:




 On Sat, Feb 15, 2014 at 9:05 PM, Laszlo Papp lp...@kde.org wrote:

 I wrote some C++ classes 1.5-2 years ago for some of the following
features:

 * GPIO
 * Eeprom
 * Power management
 * LED
 * Hardware Monitoring
 * DMA
 * Real Time Clock
 * I2C
 * SPI
 * etc.

 Out of curiosity: is there anyone working on such classes in Qt? Would
 such features be welcome in Qt in general? If not, why not, if yes,
 where would they fit into the overall architecture?

 It is not necessarily embedded Linux specific, but at least embedded.
 They might be useful on QNX, etc, but I cannot be sure. I would have a
 hard time suggesting place like QtEmbeddedExtras or so. I have no
 clear idea at this point.

 These are generic features, and I only thought about bringing this
 topic up because I see customers and hobbyists reimplementing the
 same, e.g. for the raspberry pi.

 Apologies if there are no interest at all for this.


 I'm interested in almost all of the above, (and CAN bus communication)


Yes, me too. It would be nice to group this kind of things in a module.
Linux-iio is in my list too.

It might be worth looking at Qt internal to see if they have some reusable
components for interacting with /sys.

Is your code accessible somewhere? Maybe we should start a discussion here
or on Qt project wiki. What about starting with usecases collection?

Chris

 --
 Pau Garcia i Quiles
 http://www.elpauer.org
 (Due to my workload, I may need 10 days to answer)

 ___
 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