On Tue, 29 Jan 2008, Herman Robak wrote: > For you an me? Very little. But please realise how irrelevant that is. > Potential users and developers think Cinelerra is "stuck in the 90s" > because of its GUI. Users believe the whole application must suck at > least as much as its GUI. Developers don't think it's worthwhile to > learn about a GUI toolkit that is only used for _one_ application. > > Bottom line: To many users and coders, Cinelerra doesn't LOOK worthy > of their time and effort.
For my two cents, the reasons Cinelerra doesn't seem to be worth my time and effort are: - It crashes. - It won't build. - It can't handle DV. - It's not open source. All of those require some qualification, but none of them are directly related to the GUI. Except for a few minor annoyances, I have no real objections to the current GUI and I don't think "fixing" the GUI should rank above those four points. The people who think making it pretty is a higher priority than making it stable, buildable, work with DV, and open source, are not a group of people I want to join. "It crashes" - this point has actually improved a lot over the last few years, and it's a big part of the reason I haven't given up on Cinelerra entirely. When I first started using it, which was when it was called "Broadcast 2000," it wasn't really usable. Now it's painfully usable, due to the heroic efforts of the community development team. But fixing all segfaults and all hangs should still be top priority. Those kinds of thing are completely unacceptable in a production environment; if I'm doing paid work with a tool I can't afford to be worrying about when it'll next just happen freeze up, how much work I'll lose when that happens, and how much time I'll waste digging back in my backup stack to find the edit list that doesn't trigger the bug. It seems to be largely the GUI's fault that Cinelerra crashes so much - and a big part of it is because a custom set of widgets was used instead of a library - but the problem is behind the scenes, not anything to do with how the GUI looks on screen. "It won't build" - I should never be told that a needed library is "missing" when the library in question is already installed on my system; but I have to install new versions of everything just for Cinelerra because it can't look on my system for the libraries I already have installed. Then I have to go through commenting out lines of assembly language because the versions of libraries that Cinelerra needs, won't build properly either without modification - they lack the appropriate conditionals to work with the assembler I have. And so on. Also, I expect software to have a configure script that generates a Makefile that actually works. This point is also one that has improved significantly since the community development effort started; but it would be an absolute dealbreaker for someone who didn't have my considerable C, C++, and assembly-language programming background to customize the build system for my machine in the way that the configure script ought to. "It can't handle DV" - I don't actually use DV myself, so this isn't directly important to me, but it seems like a significant fraction of the questions we get from new potential users are "How do I load/save raw DV files?" and "How do I record a DV signal from my camcorder?" and the answers appear to be "You can't, even though it is on the menu." and "Use kino instead." respectively. Those clearly aren't acceptable answers, but this situation has persisted for years and I haven't seen a real effort to do anything about it. "It's not open source" - this may be the most dangerous item on my list, but someone's going to have to say it out loud eventually: Adam Williams has made clear that Cinelerra is HIS project, not OUR project. Although he releases a source package, it's not realistically possible to build from it (I have, kind of, sort of, built from it... but not with a realistic amount of work, and the result kept crashing). It comes with a warning telling you you ought to use the binary instead, and another warning saying there's no warranty even though there is a no-warranty warning built into the GPL already. The GPL isn't good enough for Adam, and Adam's "source release" is not a real source release. A real source release would be buildable. He's made clear that this situation will not change in the future, that community suggestions and contributions will not be considered or used unless they happen to save him work on things he wanted already, and that nobody but him can ever be a real first-class participant in Cinelerra development. That is not the open-source way. And on the community side, even the people who want to fork the project and make an actually open-source version, still want to call it Cinelerra. As a courtesy to Adam they're going to change the name, but the question isn't "What name will we give our project?", it's "What euphemism shall we apply to Cinelerra 3 so that people will know it's Cinelerra 3 but it won't be technically named Cinelerra 3?" Honestly, it's depressing how many of the suggestions I've seen are still obviously trying hard to work in as many letters from "Cinelerra" as possible, and still calling it "Cinelerra 3" in the discussion of what official name to give it. It's clear that in people's minds, it *is* Cinelerra 3, and the result of the naming discussion won't change how it's thought of. How about a *really* new name, not based on a modification of "Cinelerra," and a *really* new project to match? I think all that is a lot more important than how the GUI looks on my screen. -- Matthew Skala [EMAIL PROTECTED] Embrace and defend. http://ansuz.sooke.bc.ca/ _______________________________________________ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
