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!
Tim
On Tue, Apr 17, 2012 at 8:35 AM, Timothy Pearson kb9vqf@pearsoncomputing.net 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. :)
On 17 April 2012 04:19, Aleksey Midenkov midenok@gmail.com wrote:
On Tue, Apr 17, 2012 at 8:35 AM, Timothy Pearson kb9vqf@pearsoncomputing.net 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:
- 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
On Tue, Apr 17, 2012 at 5:36 PM, Calvin Morrison mutantturkey@gmail.com wrote:
On 17 April 2012 04:19, Aleksey Midenkov midenok@gmail.com wrote:
On Tue, Apr 17, 2012 at 8:35 AM, Timothy Pearson kb9vqf@pearsoncomputing.net 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:
- 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.
There are working examples in bug 900. Please look at lib_vinegret.tar.gz (C example) and qt_vinaigrette.tar.gz (C++ Qt3 and Qt4 example).
On Tue, Apr 17, 2012 at 5:36 PM, Calvin Morrison mutantturkey@gmail.com wrote:
On 17 April 2012 04:19, Aleksey Midenkov midenok@gmail.com wrote:
On Tue, Apr 17, 2012 at 8:35 AM, Timothy Pearson kb9vqf@pearsoncomputing.net 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:
- 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.
There are working examples in bug 900. Please look at lib_vinegret.tar.gz (C example) and qt_vinaigrette.tar.gz (C++ Qt3 and Qt4 example).
I looked at the examples on that bug report and wrote a brief response. Please let me know if I have missed anything important.
Tim
-
Aleksey Midenkov -
Calvin Morrison -
Timothy Pearson