Color commentary follows: On Monday 04 February 2008 11:17, Richard Spindler wrote: > Hi, > > We had a little discussion about UI stuff in Cin3, some points raised > were rather interesting, so I'd like to put a little attention on > those. :-) > > The first Part of the Mail is a little ranting, so scroll down, if you > are not into flamebaits. ;-) > > Some of the suggestions of different People were into totally opposite > directions, like for example: > > Stefan de Konink <[EMAIL PROTECTED]> says: > > If in your perception we are making an 'office like' application that > > edits video, I might be wrong. But we probably can stick with what > > already exists. I am hoping we will design a GUI that is thought > > 'out-of-the-box'. As a toolkit and not some application, something you > > will focus on 100% when you use it. > > Artem Baguinski <[EMAIL PROTECTED]> says: > > A "Serious" reason to reuse widgets wouldn't be lazyness of > > programmers, but satisfaction of users. The less skills user has to > > forget each time s?he starts another application - the better. > > > > What you really want is to make sure the same things are done the same > > way, similar things are done similar way, and things that are unique > > to your application are kept to minimum. > > I am with Artem in this case, because I don't think we should try to > outsmart everyone else by making something totally crazy and > unconventional. I think we are going for a solid, stable and reliable > tool, and I don't think that this is the place to get sidetracked by > experimenting with to many new ideas. > > I am open to apply novel and innovative interface concepts in isolated > well defined use-cases. But for the overall application and Interface, I > strongly vote for and suggest to go the way of boring, well proven and > familiar concepts. > > Other than that, and this is just my opinion and observation. I do not > think that Stefan de Koninks Comments are moving us forward very much. > Stefan, while I value your willingness to discuss, and to contribute > your thoughts and Ideas, I also hope that I can point out some flaws in > your arguments, not to offend you, but to encourage you to make even > better suggestions. :-) > > This is going to be a serious App, and somehow compromises are > necessary. I am not saying that there is no room for freewheeling and > unconventional ideas, but lets assume that we do have some limitations > both in the resources that we have and in the problems that we want to > solve. Try to think inside that box. ;-) >
I agree with you that the "stock" UI should be as you describe - nothing fancy, but functional. That said, if the "core" is designed carefully, the flexibility will be there to allow someone like Stefan to go "out-of-the-box" with a custom front-end. Might even want to leave some capability for some scriptable CLI interface for bulk processing. > Stefan de Konink <[EMAIL PROTECTED]> says: > > I'm sorry developer time is more expensive? Where do you come from? We > > are not starting a NewCinelerra company and probably want to have the > > best (not the optimal) solution for the system. > > Yes, developer time is actually expensive, why? Because we only have > very little of it. I guess most of us are hobbiests, working in our free > time. So better use that time efficiently, and not waste it. > > Sure we do not have any deadlines, we can take as much time as we wont > to, but if it takes 10 years to write a better cinelerra, then I don't > think this is going to make anyone here happy. Think about it, if we can > come to a resonable implementation in 1 Year, we have 9 more years to > play around with crazy innovative concepts. ;-) > > The Point is, that we will use an existing well proven toolkit, because > it will save us Time and Headache. There is no serious alternative. BUT: > This does not mean that there is no room for fancy stuff. We just have > to deal with it that all the basics are standard of the shelf Widgets, > Like: Buttons, TreeViews, TextEdit Fields, File Open Selectors, and so > on.... While it might look like trivial stuff, creating all those basic > things will take time, and if you want to do it right, it will take a > long time! So better don't do it ourselves. > > So I repeat myself: > GTK as well is Qt are well up to the task provide a > Widgetset for a Video Editor. Period. So don't even think about > recommending your personal favorite niche Toolkit. > > =========================================================== Again, I think this should be designed so that there is as little interaction with the GUI as is absolutely necessary, and that those interactions be through well-defined and thought-out interfaces. Then you can make a front-end using whatever toolkit your heart desires. Maybe video processing is something that might be too cumbersome to effect a reasonable separation between the GUI and "core", but I think it's something that should have a serious look. > =========================================================== > > So after all that Ranting, I'll move on to less Fluff, more Stuff. ;-) > > Ichthyostega <[EMAIL PROTECTED]> says: > > When working with the current "state of the art" in any real world > > project, I constantly have *too much* tracks, *too much* effect > > windows open, *too much* sliders, *too much* knobs, I need to scroll > > around all the time, poke through endless tabs/lists/bins, while > > actually working at any time with only a limited focus set of > > entities. The problem being, this focus is not constant, it doesn't > > fit with the systematic hierarchy and is not known in advance. > > We should try to improve things here! > > This of course is a problem that is very disconnected from the "Core" > Video Editing Problem, and therefore an ideal candidate to develop > individually. But it is also a very difficult Problem, because it is > what I like to call a "Workflow" Problem. The Problem varies widely > between people, because everyone has a different Workflow, some people > might shoot lots of footage for a particular project and want to > organize that information, others already have a large pool of stuff > that they tend to reuse again and again in a remixing fashion, others > might have lots of takes of the same scene and want to single out the > best shot, etc.... There are plenty of use cases that I can think of > here, and all of them are different. > > This is also a problem that is not so technical but much more about > Perception, and Information Categorization and Organisation. > Implementation will probably not too difficult, so whoever wants to take > up on that task should be willing to do lots of Screen Mockups and > Detailed Workflow Examples and Explainations. ;-) > > I suggest to look at the following applications to get some inspirations > about footage organization: > > http://picasa.google.com/ > http://macslow.thepimp.net/?p=125 > http://f-spot.org/ > > If you have more links, please add them. If you are interested to work > on that problem, send in your proposals. :-) > > Cheers, > and have fun, > -Richard > As you may have guessed, I actually envision several front-ends to a (whatever it's actually called) Cin3 back-end core. These front-ends would be tailored to the different workflows that exist out there in the wild. Start simple, but allow the flexibility to adapt the GUI interace(s)/plugins later. But have a rock-solid core to it. Anyone have any thoughts on the utilization of Cg and/or SIMD in the processing functions/methods? My two-cents. Dave _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
