Re: [xine-devel] xiTK : alive

[Michael R. <mr...@us...>]

Hi,

> > xiTK can become a beautifull thing, but it's like no-one works on that
> > anymore, will it be dropped in the future or what?
>
>   the main goal of xiTK isn't to be another toolkit, there are already
> dozens of toolkits, but this one was originally created for xine (in the
> monolitic time). Currently, i just try to made it stable as possible and i
> will add two or three missing features (like cut'n paste, text
> selection).

I hope I am not offending Daniel with what I am saying, because that is in no 
way my intention, but xitk and xine-ui as a whole is troubling me. I think 
there are too few people working on it and I think the reason is that its 
code is IMO quite hard to understand. I would like to help in xine-ui 
development and I have read some parts of the code here and there, but I have 
not gotten the whole picture yet. This might be due to xine-ui's history, 
where more and more features were simply pushed into the existing design, 
making the code somewhat crowded and making the implementation of one feature 
span across multiple files. I think Daniel is used to his code, that's why 
the quality of his contributions has always been high, but any newcomer 
wanting to help with xine-ui will have quite a hard time. I also think there 
is quite a number of things that need to be improved in xine-ui and these 
things will need more developers working on it. Other frontends like kaffeine 
are already starting to overtake; I don't think that's a bad thing, but we 
should use it as an encouragement to overthink the direction, xine-ui is 
heading.

I don't know a good solution to this problem. The idea I find most appealing 
personally is to redesign xine-ui from scratch using FLTK 
(http://www.fltk.org/), a lightweight toolkit designed to be statically 
linked into the binary. I think we can still transplant a lot of xine-ui's 
application logic (that is: non-GUI code that purely implements the features; 
"the heart of xine-ui", if you want). But that idea might be too radical, 
since it would require switching xine-ui to C++. (I personally consider C++ a 
better choice than C for GUI applications, since you tend to need some of the 
C++-only functionality like constructors, but I know that I will be quite 
alone with this opinion among the xine-devel citizens. ;) )

Michael

-- 
#ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT
	2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c