Re: [Development] Qt/3D

2013-02-11 Thread Laszlo Papp 
Depends on the type of the question. If it is more usage oriented then the
interest mailing list (or #qt on IRC @ freenode), but if it is more about
the development of it, then this list (or #qt-labs on IRC @ freenode).

Used to be a dedicated qt3d list, but perhaps it is not worth migrating to
the Qt Project: http://lists.qt.nokia.com/mailman/listinfo/qt-3d

Used to be an IRC channel on freenode, called #qt-3d, but this is not much
used anymore either.

Laszlo

On Mon, Feb 11, 2013 at 11:33 PM, Federico J. Fernández <
federico.fernan...@gmail.com> wrote:

> All,
>
> I want to know what is the best place to ask questions about the Qt3D
> library.
>
> Probably the best resource is not this list, but I couldn't find another
> more specific mailing list.
>
> Thanks.
>
> --
> federico
>
> ___
> 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/3D

2013-02-11 Thread Jake Thomas Petroules 
I think you are looking for: 
http://lists.qt-project.org/mailman/listinfo/interest

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

On Feb 11, 2013, at 6:33 PM, Federico J. Fernández 
 wrote:

> All,
> 
> I want to know what is the best place to ask questions about the Qt3D 
> library. 
> 
> Probably the best resource is not this list, but I couldn't find another more 
> specific mailing list.
> 
> Thanks.
> 
> --
> federico
> ___
> 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] Qt/3D

2013-02-11 Thread Federico J . Fernández 
All,

I want to know what is the best place to ask questions about the Qt3D
library.

Probably the best resource is not this list, but I couldn't find another
more specific mailing list.

Thanks.

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

[Development] most suit implementation for global calendar systems

2013-02-11 Thread Mohsen Akhlaghi 
Hello all,

I'm thinking of a global calendar support including Julian (as base),
Gregorian, Hebrew (jewish), Hijri (Islamic) and Jalali (Persian).

I know there's already discussions on localizations in Qt but I believe the
calendar system isn't just limited to locales but it's a feature that should
be truly available even as a separated class. Besides, defectively
implementations of this object would be a leading to rework in future where
other calendars want to add to the game.

BTW, what I need to start developing such class is just a little information
on how to start and how to implement that could be qualified as a piece of
Qt code in near feature.

. should I subclass another object (might be QCalendarSystem or
QDateTime)? Or is it preferred to have a new class with its own methods or
same as what on the QDate?

. Should I implement switching to OS native date calculation on
environments which have those calendars supported natively such as KDE?
(however doesn't make sense to me)

. Should it be a playground project at first? And how to ask the
maintainer to open a project on gerrit for me?

 

I already have those c++ implementations of calendars which was tested for
many years and I'm sure I'm able to forward it to Qt as well neat and clean.

Probably you've experiences and lots of information for helping me move and
growth.

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

[Development] Android: Merge or no merge?

2013-02-11 Thread Eskil Abrahamsen Blomfeldt 
Hi,

We have a disagreement on how to integrate the Android port into Qt 
which we need to get resolved.

Here's the discussion:

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

tl;dr: Should we merge or rebase the Android branch when integrating it 
into Qt mainline?

The main issue originates from the fact that Necessitas was integrated 
as one large, atomic commit.

Our plan to minimize the effect of this was to

1. Create separate patches for the non-Android-specific parts of that 
change, and commit these separately to dev ahead of time. (In progress)
2. Collect feedback on the total diff of the branch using Paul's large 
squashed commit and fix the issues as they are brought up. (In progress)
3. Do a merge which retains the blame-history of the changes that were 
already committed to dev, so that the only parts which will show up as 
the large initial commit in a git blame are the lines which are 
Android-specific and which have not been disputed and therefore altered.

This way we keep the SHA1s which are already linked to tasks in Jira and 
we have the full history of the Android port at least back to the point 
where Necessitas was integrated in Qt 5 (kind of like the initial Qt 5 
commit, but for the Android port.)

However, there was some disagreement about whether this was acceptable 
or whether the branch should be rebased on top of dev instead.

The problems:

1. The initial commit does not have a review-stamp. The only way to get 
around this would be to rebase and rewrite the commit to include my 
review, or to post the commit itself to dev ahead of time and then merge 
on top of that, which would break the rule of only committing finished 
features.
2. There is clutter in the commit log, i.e. changes that change code 
style and whitespace errors.

In my opinion, the amount of history we submit seems like a luxury 
problem. I would very much like to be able to track the development of 
the Android branch after merging it, so in my opinion having the history 
intact is nice, even if they are not interesting to everyone. One of the 
major history-based problems in the Qt 4 days was that we would squash 
together commits from topic branches and lose the history in those branches.

Squashing the "clutter" commits and rewriting the entire history is a 
lot of work, and I fear it will jeopardize our chances of meeting the Qt 
5.1 deadline. Since it only serves to remove information and history and 
would take up too much valuable time, it does not seem justifiable to 
me. Since we did get reviews for all changes except the initial one, the 
idea was that we would not have to do this kind of history rewrite later.

A compromise would be to rebase on top of dev, review the initial 
commit, and then rebase the rest of the branch on top of this. This 
would break the references in Jira tasks, though, so personally I'd 
prefer not to do this. I also wonder how it's achieved technically, 
since most of the changes have been reviewed already and therefore do 
not need additional reviews, but I'm sure this is not a huge problem.

So what do you think?

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

Re: [Development] B-Tree containers instead of STL in Qt

2013-02-11 Thread Samuel Rødal 
On 02/08/2013 09:51 AM, Illya Kovalevskyy wrote:
> Hello.
>
> I found one Google thing, a useful thing -
> http://google-opensource.blogspot.com/2013/01/c-containers-that-save-memory-and-time.html.
> According to benchmarks: they are faster than STL containers.

For some use cases. As they note if you have an expensive key-compare 
function red-black trees will be more efficient.

--
Samuel

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

Re: [Development] B-Tree containers instead of STL in Qt

2013-02-11 Thread jamey.hicks 
Hi Illya,

I think it is an interesting idea to try B-Trees as an alternative to other 
search trees for in-memory data structures. As with any data structure, you 
have to consider the circumstances in which they perform better than an 
alternative. These days, caches are so large and DRAM latency has grown to 
quite a few CPU cycles, so it would not surprise me if there are cases where 
in-memory B-Trees perform better because the search would get to make more 
comparisons per cache line fetch.

There is a Qt module that was under development that uses B-Trees: Qt Json Db, 
but its B-Trees were all designed to index non-volatile secondary storage so I 
do not know if it would be helpful to you.

If you are interested in pursuing B-Trees for Qt applications, I would 
recommend defining an interface similar to QMap and doing some performance 
tests to characterize if/when it performs better. There is an advantage to 
being able to swap one container structure for another without rewriting the 
code using the container.

Cheers,
Jamey



On Feb 8, 2013, at 3:51 AM, ext Illya Kovalevskyy 
mailto:illya.kovalevs...@gmail.com>> wrote:

Hello.

I found one Google thing, a useful thing - 
http://google-opensource.blogspot.com/2013/01/c-containers-that-save-memory-and-time.html.
 According to benchmarks: they are faster than STL containers.

Afaik, Qt uses STL containers in its QVector, QMap, etc. Maybe it's a good idea 
to port it to usage of B-Tree containers, is it?

--
Happy Coding,
Illya Kovalevskyy

___
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] Qt5: are Q_WS_ platforms defines truly deprecated?

2013-02-11 Thread Sorvig Morten 
On Feb 7, 2013, at 1:42 PM, Sergei Nevdakh  wrote:

> Hi!
> 
> I haven't found any defininions of old platform defines Q_WS_MAC, Q_WS_WIN  
> in Qt5 sources, but these defines are still used in Qt itself. 
> Is it ok?

You are correct that those are not in use. They will be replaced with Q_OS_* 
versions or removed.

Morten

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

Re: [Development] B-Tree containers instead of STL in Qt

2013-02-11 Thread Olivier Goffart 
On Friday 08 February 2013 10:51:14 Illya Kovalevskyy wrote:
> Hello.
> 
> I found one Google thing, a useful thing -
> http://google-opensource.blogspot.com/2013/01/c-containers-that-save-memory-> 
> and-time.html. According to benchmarks: they are faster than STL containers.
> 
> Afaik, Qt uses STL containers in its QVector, QMap, etc. Maybe it's a good
> idea to port it to usage of B-Tree containers, is it?

Qt don't use STL containers.
B-Tree makes no sens at all in QVector or other containers.
The only Qt container where it would perhaps makes sens is QMap, but it cannot 
be changed until Qt6 without breaking binary compatibility.

Qt tries to be general purpose with its containers. You never can satisfies 
everyone's need with general purposes.
If you are doing an application that requires a b-tree implementation, feel 
free to use Google containers, or any of the many other implementations out 
there.

-- 
Olivier

Woboq - Qt services and support - http://woboq.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Mock objects in Qt

2013-02-11 Thread Laszlo Papp 
Not yet.

On Fri, Jan 18, 2013 at 4:38 AM, Raja, Kushal <
kushal.r...@imagingsciences.com> wrote:

>  Hi,
>
> ** **
>
> I’m new to Qt and trying to use Test Driven Development for Qt project. Is
> it possible to create mock objects for abstract classes? Let’s say I have
> an interface class to connect to database and implementations for various
> database. Is it possible to mock interface class causing function to return
> mock for a search?
>
> ** **
>
> Thanks,
>
> Kusha;  
>
> Please be advised that this email may contain confidential information. If
> you are not the intended recipient, please notify us by email by replying
> to the sender and delete this message. The sender disclaims that the
> content of this email constitutes an offer to enter into, or the acceptance
> of, any agreement; provided that the foregoing does not invalidate the
> binding effect of any digital or other electronic reproduction of a manual
> signature that is included in any attachment.
>
> ___
> 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] B-Tree containers instead of STL in Qt

2013-02-11 Thread Illya Kovalevskyy 
Hello.

I found one Google thing, a useful thing -
http://google-opensource.blogspot.com/2013/01/c-containers-that-save-memory-and-time.html.
According to benchmarks: they are faster than STL containers.

Afaik, Qt uses STL containers in its QVector, QMap, etc. Maybe it's a good
idea to port it to usage of B-Tree containers, is it?

-- 
Happy Coding,
Illya Kovalevskyy
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Qt5: are Q_WS_ platforms defines truly deprecated?

2013-02-11 Thread Sergei Nevdakh 
Hi!

I haven't found any defininions of old platform defines Q_WS_MAC, Q_WS_WIN
in Qt5 sources, but these defines are still used in Qt itself.
Is it ok?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Code Coverage of QtBase - new report available online

2013-02-11 Thread Sébastien Fricker 
Hi,
the Qt5 code coverage report is displaying now the code coverage report of the 
modifications since Qt5.0.0.

So for QtBase 3 reports are  now online:
The actual coverage report of the master branch (computed on a daily basis)
The code coverage of Qt5.0.0 (never updated)
The code coverage of the difference between master and qt5.0.0  (computed on a 
daily basis)

The difference is computed on following basis:
If the source code of a function was modified since Qt5.0.0, the function 
should be retested and so is included into the coverage report.
If the function is not modified since Qt5.0.0, its coverage report is ignored.

The result looks promising:
The report of the modification only concerns only 1% of the global QtBase code 
(245000 instrumentation for Qt5, the diff is working on 2000 instrumentations)
It permits to check if the new code and fixes for Qt5.0.1 are correctly tested 
by the unit tests
The text differences are highlighted like for a usual diff tool (see: 
http://download.froglogic.com/public/qt5-squishcoco-report/cmp_QtBase/source_112.html#line382)


To watch the report: http://download.froglogic.com/public/qt5-squishcoco-report/

Regards,
Sébastien___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Qt-creator] Orgad Shaneh is maintainer of ClearCase plugin in Qt Creator now

2013-02-11 Thread Orgad Shaneh 
Hi,

Sorry for the late response...

Thanks a lot for all your support! It's a real pleasure to work with you
guys :)

- Orgad


On Fri, Jan 18, 2013 at 1:19 PM, Tobias Hunger wrote:

> Hello everybody!
>
> I proposed Orgad Shaneh for maintainer in November already, so everybody
> had enough time to speak up even with christmas holidays and the Qt 5
> release. I just asked Ossi to add him into the maintainers group on
> Gerrit as well as added him to the maintainers wiki page, so he is
> officially a maintainer now.
>
> Congratulations to Orgad for his outstanding work!
>
> He is now responsible for the ClearCase plugin to Qt Creator.
>
> Best Regards,
> Tobias
>
> --
> Tobias Hunger, Senior Software Engineer - Digia, Qt
> Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
> Sitz der Gesellschaft: Berlin. USt-IdNr: DE xxx xxx xxx
> Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
> ___
> Qt-creator mailing list
> qt-crea...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/qt-creator
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] submitting a multi-dimensional container class for Qt: QNDArray

2013-02-11 Thread Glen Mabey 

On Jan 21, 2013, at 2:36 AM, Stephen Kelly wrote:

> Yes. But note that the user does not have to do anything special in order to 
> put the container in a QVariant. 

> Not needed at all.

*That* is what I didn't understand -- and I don't see any notion of that in the 
QMetaType docs, but that's okay; I'm just glad for the clarification.

My attempt to directly use Q_DECLARE_METATYPE_TEMPLATE_2ARG failed, and I'm 
pretty sure that's because the first template argument is not really a class 
but instead is a base data type, qint8.  

So, I copied it out and started modifying it (outside of any macro) and ended 
up with the following, which seems to work fine:

template< qint8 N, class DTYPE >
struct QMetaTypeId< QNDArray >
{
enum {
Defined = QMetaTypeId2::Defined
};
static int qt_metatype_id()
{
static QBasicAtomicInt metatype_id = Q_BASIC_ATOMIC_INITIALIZER(0);
if (const int id = metatype_id.loadAcquire())
return id;
QVarLengthArray name;
name.append("QNDArray", sizeof("QNDArray") - 1);
name.append('<');
QByteArray tName = QByteArray::number(N);
name.append(tName.constData(), tName.size());
name.append(',');
const char *uName = QMetaType::typeName(qMetaTypeId());
Q_ASSERT(uName);
name.append(uName, int(strlen(uName)));
if (name.last() == '>')
name.append(' ');
name.append('>');
const int newId = qRegisterNormalizedMetaType< QNDArray >(
QByteArray(name.constData(), name.size()),
reinterpret_cast< QNDArray *>(quintptr(-1)));
metatype_id.storeRelease(newId);
return newId;
}
};

Where I'm not really happy with it is in the use of a QByteArray, as I think 
that the purpose for using QVarLengthArray in the original macro was to avoid 
heap allocations such as QByteArray will necessarily bring.

Is there something that can be done about that?

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

[Development] Mock objects in Qt

2013-02-11 Thread Raja, Kushal 
Hi,

I'm new to Qt and trying to use Test Driven Development for Qt project. Is it 
possible to create mock objects for abstract classes? Let's say I have an 
interface class to connect to database and implementations for various 
database. Is it possible to mock interface class causing function to return 
mock for a search?

Thanks,
Kusha;


Please be advised that this email may contain confidential 
information.  If you are not the intended recipient, please notify us 
by email by replying to the sender and delete this message.  The 
sender disclaims that the content of this email constitutes an offer 
to enter into, or the acceptance of, any agreement; provided that the 
foregoing does not invalidate the binding effect of any digital or 
other electronic reproduction of a manual signature that is included 
in any attachment.

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

[Development] QtWindowsExtras

2013-02-11 Thread Jake Thomas Petroules 
As we have a QtMacExtras and QtX11Extras, could someone please create a 
QtWindowsExtras as well?

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821

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