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