16 Sep
2013
16 Sep
'13
1:42 p.m.
On Sat, Sep 14, 2013 at 5:41 AM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
> 2013/9/13 Aleksey Midenkov
<midenok(a)gmail.com>
>
>> I watch over Trinity project for as long as 3 years. I want to give my
>> grade on its development activity. I think that the project is not
>> capable of public use and rather suited for small group of inside
>> hackers.
>>
> Strictly speaking, this is not true I've talked to a couple people who are
> using trinity and not subscribed to the developer mail list ;-)
> Although I'm not sure if there are any other such people anywhere...
>
>>
>> Along the history of development there were too much lame
>> unprofessional decisions. It was fulfilling some strange unpractical
>> ideas. In fact, it came to a logical unsuccessful end.
>>
> I believe you are speaking about qt3 API breakage. If so, I'm totally
> agree
> with you... IMO that was really crappy choice independently of reasons. I
> can name some other controversial moments but they are relatively small...
And not only about that. There were more things that have taken years of time
and was needless to end user and a handicap to programmers.
Since TDE now uses TQt3, the old Qt3 libraries
(unmaintained as they are!)
can be installed at the same time as TDE. At this point I don't see any
serious drawbacks to changing the TQt API; would anyone consider it a
major problem if Trolltech had changed the Qt3 API?
You are not Trolltech. You have no such human resources neither by count,
nor by experience. Moreover, there is no reason to dig in depreciated code.
Want better lib? Gradually switch to Qt4, one program after another. If you
weren't doing all these stupid things with TQt, Qt3 API changes, K* -> T*
renames you would already have finished.
But I wouldn't recommend that either. Bug-fixes, functionality and UI.
Only these are important.
We all probably would
have complained about it a bit and then moved on--how is this different
from the TDE project *improving* Qt3/TQt3 (e.g. adding proper threading
support) and changing the API as needed?
There is no need in that. UI programs are not high-load programs, they don't
require bleeding edge performance optimization. Everything worked fine there
before Trinity! You've digging wrong places. Do UI, not system libs.