trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2012

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

From: Aleksey Midenkov <midenok@...>
Date: Wed, 7 Mar 2012 11:54:19 +0400
On Wed, Mar 7, 2012 at 11:31 AM, Timothy Pearson
<kb9vqf@...> wrote:
>> 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.

Agree. That's why it must be gradual. How to do this is different
subject of discussion.

>
>>>
>>> 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.

But that is what the linker does. Isn't it? Looks at symbolic names
and puts addresses instead. Therefore you shouldn't have name
conflicts at runtime. The crash you may encounter is because the
linker chosen wrong symbols to link together in one algorithm. But
this have obvious solution. Put the code you want to link with Qt4 in
separate module and link only with Qt4. I still don't understand how
is renaming better solves this. Could you please refer exact source
file and function?

>
>>> 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.

You mean there are some Qt3 features that are lacking in Qt4? I were
not saying about replacing classes of KDE like KApplication with Qt
equivalents. That is impossible and senseless.

>
>>>
>>> "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?

I suppose this could be done in more easy way without renaming.

>
> Also, I'm currently down with the flu, so I may be coming across a bit
> stronger than I should. ;-)
>
> Tim
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: trinity-devel-unsubscribe@...
> For additional commands, e-mail: trinity-devel-help@...
> Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/
> Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
>