To view parent comment, click here.
To read all comments associated with this story, please click here.
Well you see, Timothy should not have to do this but unfortunately he does because there is no coherence between toolkits. The foundation of every toolkit is different! There should be like a central protocol where all developers can turn to and follow.
If what you said is true, it means that the functionality I specified is hard-coded to handle various different messages from different toolkits but this is not Timothy's fault and he should be praised for this because he tries to at least cover, lower the extent of the mess created by other developers!
With Windows, based on my own experience, regardless if the program looks like Office XP (super flat buttons), Office 95 (3D), Office 97 (flat) or is using the Ribbon UI, they all follow the same rules.
- Every window has a Window Procedure
- Every window receive the same messages: WM_ACTIVATE, WM_LBUTTONDBLCLK, WM_KEYDOWN ... you name it because they all derive from the same object.
This is why everything works with Windows because there is one central foundation to everything that's running and they are all related to particular objects following the same rules.
From what I have experienced, X.ORG does not have these rules and that's why everything is broken and nothing is compatible with each and even toolkits themselves are not compatible with each other with different versions. It's a joke but this can be fixed. Put everything in the past and start-over, create a protocol or if starting over is bad then take one toolkit and make it official and then everyone can use the same toolkit and improve it.
Edited 2012-11-10 07:59 UTC




Member since:
2006-06-12
Sorry to burst your bubble, but it is the same reasons they dropped XMMS(1.x) or any other top GTK1 apps. It is not because they were not getting the job done anymore, but because of how hard they were to maintain. The TDE guy have to support over 10 million lines of code. Everytime something change and break compatibility, it have to be fixed. Every GCC version that change default settings and break compilation, it have to be fixed. Everytime upstream libraries bump API levels it have to be ported or removed. Scale that to 10 million lines of code and maintenance/packaging/support is not cost effective. It is that simple. It also serve a very small niche. Unless the maintainer is very motivated, TDE will get to a point where it will be impossible to maintain without forking even more libraries and making the problem even bigger.
TDE should have forked KDE 3.7 or 3.8, not 3.5. At least 3.7/3.8 were ported to Qt4, but it was before KDE4 features were merged in. It would have allowed to keep only the KDesktop and Kicker (possibly the old Konqueror and Kontact too) while enjoying upstream support of the base libraries and ability to blend in KDE4 apps when the new version is simply better, aka, Kate, Konversation, Digikam, KDenlive.