On 17 April 2012 04:19, Aleksey Midenkov <midenok@...> wrote:
> On Tue, Apr 17, 2012 at 8:35 AM, Timothy Pearson
> <kb9vqf@...> wrote:
>> All,
>>
>> I have written a brief draft document with some of the rationale behind
>> the TQt interface layer and the TQt conversion on the Wiki here:
>> http://trinitydesktop.org/wiki/bin/view/Developers/TQTRationale
>>
>> Thank you to all who have (gently) reminded many times to get some kind of
>> rationale written up.  The current document is not complete, and I welcome
>> questions and corrections on the provided Etherpad so that I may address
>> all concerns from the developers here on this matter.
>>
>> If this works out, and I think it will, we will have features that no
>> other KDE 3.5.10 fork can ever attain.  Please keep this in mind before
>> ripping into the implementation details; I took a significant risk in
>> doing this and I am already seeing benefits in the existence of a viable
>> TDE Qt4 theme engine alone--who knows what will happen now that Webkit and
>> other libraries are suddenly available for use in TDE!
>>
>
> But there is an alternative exists that seem to be better in following aspects:
>
> 1. Proxying is limited to only Qt4. TQt proxies both Qt3 and Qt4. This
> minimizes performance overhead and leaves less space for unforeseen
> problems.
> 2. Narrower API that require intrusion. This means much less man work.
> 3. Gradual switch from Qt3 to Qt4. When have more Qt4 objects than
> Qt3. Proxying may be switched to Qt3 and Qt4 will be called direct.
> 4. Transparency. Leaves original code intact. As in p.2 this saves
> much of man work. Less bugs. Programmers are happy to see familiar
> code. Less keyboard presses. Electricity save. Shorter lines.  Eye
> exertion save. Time save. Whatever. :)
>

I would like to see an example of this that works before even
considering it. many things are great in theory and fail miserably in
reality.

Calvin