trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2012

Re: [trinity-devel] QT API renaming! Why?!

From: "Timothy Pearson" <kb9vqf@...>
Date: Wed, 7 Mar 2012 01:31:19 -0600
> On Wed, Mar 7, 2012 at 9:31 AM, Timothy Pearson
> <kb9vqf@...> wrote:
>>> Will someone tell me or put the link to the description of why someone
>>> would need to rename QT API?
>>>
>>> I know that for programmer this is a disaster!!! This will strangle
>>> the development!
>>
>> I have addressed this issue multiple times on this mailing list.  It is
>> impossible to use Qt4-based libraries in TDE, such as Webkit, while the
>> symbols from Qt3 conflict with those from Qt4.
>
> But why would you need both Qt3 and Qt4? Just choose one and stick
> with it. Do you want Qt4, then migrate completely.

It's not that simple.  Porting TDE fully to Qt4 is easily 5-10 years of
solid work with current manpower.

>>
>> You can blame the developers of C++ and Qt if you like, but unless we
>> want
>> TDE to remain niche by never integrating well, and also not being able
>> to
>> take advantage of all the work put into Qt4-based libraries, this
>> renaming
>> had to be done.
>
> Can you put some examples of what issues with Qt4 this renaming addresses?

Yes!  I'll pick an obvious example, KHTML.  I would like to replace the
broken KHTML engine with Webkit using Qt4.  Problem is, I can't link a Qt4
library into a TDE library or program due to symbol conflicts.  Even if
you trick the compiler and linker, the program will crash at runtime
because the C++ runtime will not know which symbols (Qt3 or Qt4) to use
when function names and static members have the same name.

>> It isn't hard to adapt BTW, just tack a "t" onto the front of the old
>> "q<foo>" functions and static members.
>
> There are standard API and standard documentation, and development
> tools that are designed for this standard. Getting into this business
> you doom yourself on endless job of synchronizing with Qt4 API
> evolution. Not saying about the deep of current API coverage. That is
> not the work for one man!

???  I'm NOT doing that!  Qt4 is lacking basic features TDE needs.

>>
>> "Stock" Qt3 is available if it is needed, but I am personally using TQt3
>> so that I can take advantage of Qt4-based system libraries in the
>> future.
>>
>> Tim
>>
>
> If f.ex. I will utilize reference countable pointers from Qt4, then
> Qt3 will go to depreciation at once! So this TQt looks like all big
> nonsense... :-(

No, (T)Qt3 will still be needed as the foundation for much of the TDE
code.  Just because I can take advantage of a few new Qt4 features
***where appropriate***, to add new functionality to TDE, does not mean
that the need for the existing foundation of (T)Qt3 has been magically
replaced.

All I am doing is making it so that I can use Qt4 libraries in newly
written TDE code, for specific tasks where it is the best tool to use
(i.e. a well-supported library has been built with Qt4).  Does this make
sense?

Also, I'm currently down with the flu, so I may be coming across a bit
stronger than I should. ;-)

Tim