17 Apr
2012
17 Apr
'12
12:35 a.m.
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
17 Apr
17 Apr
4:19 a.m.
New subject: [trinity-devel] TQt Rationale
On Tue, Apr 17, 2012 at 8:35 AM, Timothy Pearson
<kb9vqf(a)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. :)
9:36 a.m.
New subject: [trinity-devel] TQt Rationale
On 17 April 2012 04:19, Aleksey Midenkov <midenok(a)gmail.com> wrote:
On Tue, Apr 17, 2012 at 8:35 AM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
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
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. :)
1:01 p.m.
New subject: [trinity-devel] TQt Rationale
On Tue, Apr 17, 2012 at 5:36 PM, Calvin Morrison <mutantturkey(a)gmail.com> wrote:
On 17 April 2012 04:19, Aleksey Midenkov
<midenok(a)gmail.com> wrote:
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 8:35 AM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
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.
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. :)
2:02 p.m.
New subject: [trinity-devel] TQt Rationale
On Tue, Apr 17, 2012 at 5:36 PM, Calvin Morrison
<mutantturkey(a)gmail.com>
wrote:
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
On 17 April 2012 04:19, Aleksey Midenkov
<midenok(a)gmail.com> wrote:
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 8:35 AM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
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.
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. :)
4650
days inactive
4650
days old
4 comments
3 participants
participants (3)
-
Aleksey Midenkov -
Calvin Morrison -
Timothy Pearson