Qt and digiKam

[Aditya Bhatt]

Hi,

I just implemented a large part of the tagging widget in the libkface example.

It allows you to "write" names directly below the face in a text field.

I just realized that it uses Qt 4.6's classes for a lot of things, most notably the QGraphicsObject base class, which is required for a lot of useful things such as QGraphicsWidget, QGraphicsTextItem (Used for the editing names of faces) and QGraphicsSvgItem( Which, I think, could be used for implementing the arbitrary polygonal region tagging, if we ever do it, that is ).

What I realized after all this coding is that Qt 4.5 has a lot of methods which were totally removed from Qt 4.6, and Qt 4.6 has a lot of classes which are too useful to be left alone, like the above. I'd rather not spend time trying to duplicate those above classes, only to revert back to 4.6's implementaion in a later release.

I don't have Qt 4.5 on my system, (KDE 4.4 absolutely needs 4.6) so I can't test if it will work with 4.5.

So I'd like to know if I can use 4.6 methods.

Can I know what sort of compatibility policy should be used? Will Qt 4.6 be "okay" for digiKam when the time comes to merge the GSoC branch to trunk? 

Thanks
--
Aditya Bhatt
Blog : http://adityabhatt.wordpress.com
Face Recognition Library : http://libface.sourceforge.net

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> I don't have Qt 4.5 on my system, (KDE 4.4 absolutely needs 4.6) so I can't
> test if it will work with 4.5.

We can instead talk about which KDE releases we support:
4.2 (January 2009)
4.3 (July 2009)
4.4 (February 2010)
4.5 (to be released in August)

4.3 means Qt4.5, 4.4 means Qt4.6.

We need to keep in mind that we already require libkexiv2/libkdcraw from
trunk, I think to be released with 4.5.

For me it's ok to make a cut and depend on KDE4.4 / Qt4.6 for the release
incorporating the GSoC changes. It makes sense to do it now when we have a
real need for new technology provided by Qt4.6. (we can also expect lots of
QGV bugs in Qt4.5).

But Gilles still runs Qt4.5 as we have seen, so he may have a different
opinion.

>
> So I'd like to know if I can use 4.6 methods.
>
> Can I know what sort of compatibility policy should be used? Will Qt 4.6 be
> "okay" for digiKam when the time comes to merge the GSoC branch to trunk?
>
> Thanks

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2010/6/22 Marcel Wiesweg <[hidden email]>:

>
>
>> I don't have Qt 4.5 on my system, (KDE 4.4 absolutely needs 4.6) so I can't
>> test if it will work with 4.5.
>
> We can instead talk about which KDE releases we support:
> 4.2 (January 2009)
> 4.3 (July 2009)
> 4.4 (February 2010)
> 4.5 (to be released in August)
>
> 4.3 means Qt4.5, 4.4 means Qt4.6.
>
> We need to keep in mind that we already require libkexiv2/libkdcraw from
> trunk, I think to be released with 4.5.
>
> For me it's ok to make a cut and depend on KDE4.4 / Qt4.6 for the release
> incorporating the GSoC changes. It makes sense to do it now when we have a
> real need for new technology provided by Qt4.6. (we can also expect lots of
> QGV bugs in Qt4.5).
>
> But Gilles still runs Qt4.5 as we have seen, so he may have a different
> opinion.

well, i still in QT 4.5, because i still in Mandriva 2010.0 stable
which is based on. I'm waiting Mandriva 2010.1 which is based on Qt
4.6 and will be released soon.

Anyway, i can test this code under Windows (Yes :=))), because it's
based on Qt 4.6...

So it's fine for me to break Qt 4.5 compatibility there. But, Cmake
script must be changed somewhere to said Qt 4.6 dependency.

README files need to be changed too.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel