Qtopia-interest Archive, August 2007
[Fwd: Re: Qtopia4.2 on QtopiaCore4.3.2-snapshot]
Message 1 in thread
4.2 was designed to be compiled against 4.2 stream Qt, 4.3 is designed
to be compiled against 4.3 stream Qt. Trying to do anything else will be
an excercise in futility and madness :)
Other answers I can supply are included inline.
Holger Freyther wrote:
> Hey All,
>
> I'm currently trying to compile Qtopia on top of a recent QtopiaCore
> (e.g. to use the new XML classes) and I wonder if you already have
> fixed some of the issues I ran into:
>
> -Missing Q_OBJECT in a lot of header files
>
> -Both Qt and Qtopia have files to generate a md5, Sadly the
> MD5Final signature is different in the two copies. At least most parts
> in Qtopia could use QCryptoGraphicHash now
>
> -A lot of #error for Qt4.3 on how you want to do things
> differently. It would be appreciated to document what you want to do
> different as well.
>
> -You copy so much code into the Qtopia source tarball, you might
> want to copy a sqlite3.c as well to be not dependant on the version
> inside the Qt package.
To keep a single point of reference for the sqlite. We bump the qt
version on a regular basis, and qtopia code expects/works on a certain
version. There are bugs that we have to work around in later versions,
that once we know we can rely on a certain version of sqlite being
around, we then move out of the code-tree.
>
> -I wonder why you create/link a qtopia-sqlite library and can't
> use the QtSql classes? Is QtSql classes, bloated, inefficient or what
> is the reason not to use it?
No, we do however need access to some internal functions from the
library, and gcc 4's function export facility, it means that we can't
get access to the functions unless we build the sqlite library and link
to it separately. Generally as a rule, we use QtSql as generically as
possible, but, sadly in the case of locale aware sorting, sqlite fails
abysmally, so we have to provide our own collation sequence.
>
> -QContentUpdateManager(Private)'s use of Q_GLOBAL_STATIC isn't
> legal anymore, is it time for a QTOPIA_GLOBAL_STATIC or creating a new
> variant of Q_GLOBAL_STATIC?
See my above about the versionings of qtopia and qt. We have coded
around this, this exact question has been raised with the Qt team. There
is sufficient need, there may be a QTOPIA_GLOBAL_STATIC in the future,
I'd rather we get Qt to provide support tho if we can at all.
>
> -many more minor issues...
>
>
> -I had a look at this script called configure. And I wonder why it
> has to remove files from a tarball I get from your site? Why it tries
> to fix header files from your own company included in the same tarball
> I got from your site? But I better stop here...
>
>
> So is there any interest in a patch? Will it be available in the
> qtopia rsync afterwards, or when is Qtopia4.3 going to be released?
Probably not at this point, because of my answer about version lineups
above, we're working heavily on 4.3 as we speak, we're in bugfixing
phase right now, and expect a quite pleasant surprise :)
>
>
> z.
>
> --
> To unsubscribe - send "unsubscribe" in the subject to
> qtopia-interest-request@xxxxxxxxxxxxx
>
>
--
[ signature omitted ]
Message 2 in thread
Am 24.08.2007 um 00:30 schrieb Bill KING:
> 4.2 was designed to be compiled against 4.2 stream Qt, 4.3 is designed
>
> to be compiled against 4.3 stream Qt. Trying to do anything else
> will be
> an excercise in futility and madness :)
>
> Other answers I can supply are included inline.
Hi Bill,
you might consider that insane. But there is a ten year old project.
It has thousands lines of code, applications ranging from PIM suite,
to games, to networking, office and many more.
We develop against one version of Qt we think is stable but people
can try newer versions of it. Some people use rsync of a stable
release, some even the bleeding edge.
So why is KDE so insane to not design itself for one version of Qt?
Well, because we know there will be a next version of Qt. We don't
use internals where we were told that they will break but sometimes
are forced to duplicate (e.g. in the case of Q_GLOBAL_STATIC).
What is the benefit of not 'designig' for a specific Qt version?: One
can try bugfixes from rsync, explore new features from the bleeding
edge and this really works well for KDE.
So you should consider not designing for one version of Qt but to
allow an upgrade path. Because one of the cool things about Qt is
that it is API and ABI compatible with future releases...
>
> Holger Freyther wrote:
>> Hey All,
>>
>> I'm currently trying to compile Qtopia on top of a recent QtopiaCore
>> (e.g. to use the new XML classes) and I wonder if you already have
>> fixed some of the issues I ran into:
>>
>> -Missing Q_OBJECT in a lot of header files
So you are going to fix that yourself or did already fix that?
>>
>> -Both Qt and Qtopia have files to generate a md5, Sadly the
>> MD5Final signature is different in the two copies. At least most
>> parts
>> in Qtopia could use QCryptoGraphicHash now.
Waht is your approach in Qtopai4.3? Use QCryptographicHash but make
the packagemanger use the internal copy of md5 to avoid reading the
complete file into memory?
>>
>> -A lot of #error for Qt4.3 on how you want to do things
>> differently. It would be appreciated to document what you want to do
>> different as well.
Any comments?
>>
>> -You copy so much code into the Qtopia source tarball, you might
>> want to copy a sqlite3.c as well to be not dependant on the version
>> inside the Qt package.
>
> To keep a single point of reference for the sqlite. We bump the qt
> version on a regular basis, and qtopia code expects/works on a certain
> version. There are bugs that we have to work around in later versions,
> that once we know we can rely on a certain version of sqlite being
> around, we then move out of the code-tree.
You might want to copy the sqlite3.c of Qt4.3 into Qtopia to keep
working with
>>
>> -I wonder why you create/link a qtopia-sqlite library and can't
>> use the QtSql classes? Is QtSql classes, bloated, inefficient or what
>> is the reason not to use it?
>
> No, we do however need access to some internal functions from the
> library, and gcc 4's function export facility, it means that we can't
> get access to the functions unless we build the sqlite library and
> link
> to it separately. Generally as a rule, we use QtSql as generically as
> possible, but, sadly in the case of locale aware sorting, sqlite fails
> abysmally, so we have to provide our own collation sequence.
So what kind of internal functions/data do you need to access/call?
In that case you really should copy a sqlite3.c into Qtopia and also
rename the symbols to avoid a clash with people using QtSql which
might load a system installed libsqlite3? Or how do you gurantee that
the mixing of QtSql and qtopia-sqlite is going to be okay?
Your addition might make sense for QtSql as well?
>> -many more minor issues...
>>
>>
>> -I had a look at this script called configure. And I wonder
>> why it
>> has to remove files from a tarball I get from your site? Why it tries
>> to fix header files from your own company included in the same
>> tarball
>> I got from your site? But I better stop here...
>>
>>
>> So is there any interest in a patch? Will it be available in the
>> qtopia rsync afterwards, or when is Qtopia4.3 going to be released?
>
> Probably not at this point, because of my answer about version lineups
> above, we're working heavily on 4.3 as we speak, we're in bugfixing
> phase right now, and expect a quite pleasant surprise :)
Good luck, OpenMoko is out there and getting a lot of attention (mine
as well).
kind regards
z.
--
[ signature omitted ]
Message 3 in thread
Okay, I only answere the questions I answered, because that's my area in
here, reasking me the questions I didn't answer, will not get them
answered, so, I'll again, respond to the fields I'm responsible for/can
answer, and will let the others in trolltech on the list fill in the
blanks with the other answers. (BTW, I'm "just an engineer", so keep
that in mind when I answer).
>
> Hi Bill,
>
> you might consider that insane. But there is a ten year old project.
> It has thousands lines of code, applications ranging from PIM suite,
> to games, to networking, office and many more.
> We develop against one version of Qt we think is stable but people can
> try newer versions of it. Some people use rsync of a stable release,
> some even the bleeding edge.
>
> So why is KDE so insane to not design itself for one version of Qt?
> Well, because we know there will be a next version of Qt. We don't use
> internals where we were told that they will break but sometimes are
> forced to duplicate (e.g. in the case of Q_GLOBAL_STATIC).
>
> What is the benefit of not 'designig' for a specific Qt version?: One
> can try bugfixes from rsync, explore new features from the bleeding
> edge and this really works well for KDE.
>
> So you should consider not designing for one version of Qt but to
> allow an upgrade path. Because one of the cool things about Qt is that
> it is API and ABI compatible with future releases...
>
Sadly, not my call, but yes, there are things we expect certain versions
of qt to have, that change between the versions badly enough, that we
can't rely on different versions of qt working correctly for us,
Q_GLOBAL_STATIC is a perfect example of this, amongst others, the md5
stuff is another. We work with what we can get, and make it work the
best we can.
>>>
>>> -Both Qt and Qtopia have files to generate a md5, Sadly the
>>> MD5Final signature is different in the two copies. At least most parts
>>> in Qtopia could use QCryptoGraphicHash now.
>
> Waht is your approach in Qtopai4.3? Use QCryptographicHash but make
> the packagemanger use the internal copy of md5 to avoid reading the
> complete file into memory?
I'll dig through the 4.3 code later and give you a definitive. I'm
fairly sure we do just use QCryptographicHash tho.
>
>
>>>
>>> -You copy so much code into the Qtopia source tarball, you might
>>> want to copy a sqlite3.c as well to be not dependant on the version
>>> inside the Qt package.
>>
>> To keep a single point of reference for the sqlite. We bump the qt
>> version on a regular basis, and qtopia code expects/works on a certain
>> version. There are bugs that we have to work around in later versions,
>> that once we know we can rely on a certain version of sqlite being
>> around, we then move out of the code-tree.
>
> You might want to copy the sqlite3.c of Qt4.3 into Qtopia to keep
> working with
>
>
>>>
>>> -I wonder why you create/link a qtopia-sqlite library and can't
>>> use the QtSql classes? Is QtSql classes, bloated, inefficient or what
>>> is the reason not to use it?
>>
>> No, we do however need access to some internal functions from the
>> library, and gcc 4's function export facility, it means that we can't
>> get access to the functions unless we build the sqlite library and link
>> to it separately. Generally as a rule, we use QtSql as generically as
>> possible, but, sadly in the case of locale aware sorting, sqlite fails
>> abysmally, so we have to provide our own collation sequence.
>
> So what kind of internal functions/data do you need to access/call? In
> that case you really should copy a sqlite3.c into Qtopia and also
> rename the symbols to avoid a clash with people using QtSql which
> might load a system installed libsqlite3? Or how do you gurantee that
> the mixing of QtSql and qtopia-sqlite is going to be okay?
> Your addition might make sense for QtSql as well?
We use qt's standard configuration system, to point at a project in our
source tree that uses the source files in the qt source tree. It's a
hack, but it means that we get either, the system sqlite library to link
against, or we get a linkable version of the library in qt. Either way
it works, and gives us access to the functionality we need.
>
>
>>> -many more minor issues...
>>>
>>>
>>> -I had a look at this script called configure. And I wonder why it
>>> has to remove files from a tarball I get from your site? Why it tries
>>> to fix header files from your own company included in the same tarball
>>> I got from your site? But I better stop here...
>>>
>>>
>>> So is there any interest in a patch? Will it be available in the
>>> qtopia rsync afterwards, or when is Qtopia4.3 going to be released?
>>
>> Probably not at this point, because of my answer about version lineups
>> above, we're working heavily on 4.3 as we speak, we're in bugfixing
>> phase right now, and expect a quite pleasant surprise :)
>
>
> Good luck, OpenMoko is out there and getting a lot of attention (mine
> as well).
Personal opinion warning!!!
Openmoko is, and it's good for the community. I personally however, have
no time for a toolkit written in c, trying badly to be c++. I commend
opemoko for their effort, definately, but I personally feel it's being
based upon a highly inferior (software) product, being pitched against a
system that has a lot of the groundwork already done that openmoko has
yet to tread. I wish you all the best of luck, and I also think we can
co-exist and work in harmony, rather than in conflict. I'm not seeing
much of that happening sadly, but who knows what the future holds? :)
>
>
> kind regards
> z.
>
--
[ signature omitted ]
