[TYPO3-hci] TYPO3 4.2 blog entry

[Niels Fröhling]

 Hy Dimitry;
>> Yes, 184 days to come up with a document which is a compromise, pleasing 
>> all end every resisting voice, and 1 day to detect, he just has to 
>> upgrade the version number of t3skin.
>>
>> The problem is old and everywhere, the change does not come because it's 
>> too much, it's because of conservatism ("we can't make that change 
>> there?", "yes", "why?", "it breaks typo3 in IE <6").
>>     
> Why don't you do it then if it is easy? :)
>   
 Because I don't want to fork typo3, and I prefer to have a comunity 
participating and backupped solution.
> I guess you didn't come to t3dd08, where some radical ideas were proposed but estinates is half a year of dedicated work.
>   
 I left germany long ago to a far far place. :-)
 So no chance for me to come by ...
> I afraid you simply don't know TYPO3 code when you wrote the phrase above.
>   
 I didn't say something about the complexity of the change, I said that 
the change does not not (double negation) come because of the 
complexity. Complexity is just an obstacle (in comparison to human 
decision processes).
 But don't think I'm too simple, I maintain a 90MB source code 80.000 
line project on sourceforge, in C++. And I did very big reworks in the 
past. Just don't think I don't know what I'm talking about, just think 
that I think more radical than others, and I don't fear change. It's 
better to have control over the code, instead the other way around.
>> Obviously it is 
>> nessessary to search for a different GUI-renderer instead of a different 
>> GUI-backend. Then GUI is no thing of core-developers anymore, I can have 
>> my own GUI-renderer (and I don't need to care about IE at all) exactly 
>> because I don't need to cover every case since typo3's existence (50+ 
>> Browsers?, 25+ OSs?), then there are poping up 20 other and the problem 
>> of "everybody's freezed" doesn't exist anymore.
>>     
>
> Well, may be you don't but others have to. So use your BE, no problem at all. But big players cannot have a BE for one browser only.
>   
 That wasn't the point. The point was, that when I want to offer a 
special GUI, my custom Typo3, I can have that without the agreement of 
others.
 At this moment, I can't, you as a core-developer can't. Why don't you 
give me the tool at hand, with that I may decide what to support and 
what not.
 I wonder if a "big player" is happier with not being able to brand his 
typo appropriatly, or with being unclear if his modification works in IE3.5
 Also don't think too complicated what GUI-renderer means, it just means 
streaming all HTML generation through a centralized place. Later you 
decide how complex the actual generation is (fe.: replace the 
file-upload button by a custom one), or if it's dependent generation 
(fe.: scroll on tbody for IE7+, xhtml+xml for Firefox).
>> Just develop a layouter and a widget.set (awt/swing-style, not the API 
>> or the stupid stuff, the concept) and lean back. I once programmed a 
>> medium Intranet, after three days I startet a js/php-widget library. And 
>> it's also relative incomplicated work, because without actually changing 
>> the functionality of the backend, it all still looks the same, if only 
>> 35 of the 56 tables are really rendered by the new system is invisible.
>>     
>
> Great! Develop it for TYPO3! ;
 I do what I can without forking: t3skin_adsignum/t3skin_frohling
 The problem that you immediately face customizing the typo-GUI is the 
missing underlying GUI-paradigma. You have to start to introduce hacks 
for single elements that are horrible to address because they are not 
IDd (fe.: the versioning "button", the only non-icon? why?). I often 
wish the GUI would be as thoroughly classed and tagged (thead, tfoot, 
caption, ...) and hierarchicaly grouped as css_styled_content.

 I at the end just want to say that I don't speak with bad intentions, 
but to say a complicated thing may not be that complicated. :-)

Ciao
    Niels