Re: [CinCVS] Re: User interface toolkits and "Cin-3"
Can we end the GUI debate now, and get back to it once there is a real effort to make a new GUI? On Thu, 31 Jan 2008 14:10:45 +0100, Martin Ellison <[EMAIL PROTECTED]> wrote: The important point for GUI design is the workflow. 'Skins' and other eye candy are attractive for the first five minutes and then just get in the way of getting work done. Cutting the code to do button clicks is tedious but straightforward. But designing the workflow and designing a user interface that supports the workflow is not trivial. Hear, hear! There is a nasty difference between the UI and the inner workings. For the inner workings, the programmer can just test and verify that they do what he had intended. If they do, the program works. For the UI, the programmer can test and verify that it does what he had intended. If it does, the program works as far as the programmer is concerned, but it may still suck. You can't really test the UI properly without a test panel of users who don't share the developer's assumptions, habits and taste. What you get by slapping buttons with callbacks in a dialog template with a WYSIWYG GUI builder is a "mockup" that can demonstrate actual functionality. --which is OK, at this early stage! All that said; it is still premature to debate GUIs and workflows for Cin3. So please let that topic rest for now. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
The important point for GUI design is the workflow. 'Skins' and other eye candy are attractive for the first five minutes and then just get in the way of getting work done. Cutting the code to do button clicks is tedious but straightforward. But designing the workflow and designing a user interface that supports the workflow is not trivial. -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
Are you aware that cinelerra is very multithreaded, an a, ... well, strange Way? qt should be okay, though, I could agree to that. 2008/1/30, Timothy Baldridge <[EMAIL PROTECTED]>: > > Have you ever programmed a highly multithreded application? > > Yep. And done correctly (from the beginning) it's not that hard. The > important thing is decouple to gui from the rest of the code as much > as possible. This is why I recommend QT. Allot of the gui code is > thread safe, and when it's not, their threading tools are top notch. > And they even have support for Read/write mutexes (or is it > mutexies?). Really a NLE is the simplest program to multi-thread. > Every part of it is embarrassingly parallel. > > Timothy > > ___ > Cinelerra mailing list > Cinelerra@skolelinux.no > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra > -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
> Have you ever programmed a highly multithreded application? Yep. And done correctly (from the beginning) it's not that hard. The important thing is decouple to gui from the rest of the code as much as possible. This is why I recommend QT. Allot of the gui code is thread safe, and when it's not, their threading tools are top notch. And they even have support for Read/write mutexes (or is it mutexies?). Really a NLE is the simplest program to multi-thread. Every part of it is embarrassingly parallel. Timothy ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
2008/1/30, Timothy Baldridge <[EMAIL PROTECTED]>: > Another thing I thought of once, is why can't we decouple the GUI from > the underlying media handling code enough to make the gui > multitasking. For instance, start a tape importing, and a project > encoding, and then start editing another project. Sure there will be a > performance hit, but with the systems we have available today, this > should be possible (to some degree). Have you ever programmed a highly multithreded application? -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
> Really, UI Design is not that hard. The underlying technical > foundations are. When seeking is slow, or importing media takes half > an hour, all the fancy screenshots and buttons can be all bling and > shiny, and it still sucks. I read an article once about how preceived performance is linked to GUI responsiveness. For instance, a Quad core rendering a file in 2 minutes will seem slower than a single core taking 8 minutes to render a file if the quad's GUI is locked up (with no user feedback) while rendering. So keeping the gui responsive is a must. Another thing I thought of once, is why can't we decouple the GUI from the underlying media handling code enough to make the gui multitasking. For instance, start a tape importing, and a project encoding, and then start editing another project. Sure there will be a performance hit, but with the systems we have available today, this should be possible (to some degree). Timothy ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
2008/1/30, Timothy Baldridge <[EMAIL PROTECTED]>: > To quote you, "no offense intended", but why do we need mpeg2 support > at all? I did videography work for a few years and never had a need > for that. Convert your mpeg to a real editing format and go from > there. For that matter, I prefer image sequences. Give me an example > of a single program that natively handles mpeg2 video and I'll show > you 4 that don't. Premiere, FCP, Flint/Effect, After Effects, they > don't. mpeg is a distribution format never, ever, edit in mpeg2 it > looks like trash compared to DV and uncompressed video. The only > reason I can think of where I'd want mpeg2 is for editing DVDs and > hopefully we're reaching for a bigger audience than that. HDV == MPEG2 HDV is getting more popular. Reencoding to a "real editing format" takes A) Time B) Much more diskspace. (No matter how much diskspace you have, it tends to get filled, so don't waste it) and C) Some people would like to preserve their footage in the form that it was originally captured in. And above all, it CAN be done (see libmpeg3, it is almost complete!!) therfore it HAS to be done! Cheers -Richard PS.: We want it for mpeg4 too, AVCHD == MPEG4 -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
2008/1/30, Timothy Baldridge <[EMAIL PROTECTED]>:
> > What open source applications do you
> > think fit this description? Surely The GIMP and Blender are out ("no
> > offense intended" to continue the thread).
>
> That's the issue, when it comes to the GUI, almost all of Linux is
> out. I can't think of a single app I was floored by that I said "this
> GUI is awesome" except for Blender. But I'm sure to get assassinated
> for saying that ;-). When it comes to NLEs though I'd say FCP has a
> nice design. Enough hot-keys to make it fast, but it still has enough
> buttons to make it usable for new users. Finding that balance is hard.
> Blender is blazing fast once you know how to use it. The forums are
> filled with users who say that they can model twice in fast with
> Blender than in Maya (in fact some model in Blender and then export to
> Maya) but for new users it is hard.
There is plenty of information available online, and in books about
User Interface Design, User Interaction Design, Usability Testing,
etc...
Apart from that, the "Standard" UI of a NLE is pretty much fixed, they
all have a timeline, a Preview, and Selection of assorted Buttons
sprinkled over the Rest of the UI.
Really, UI Design is not that hard. The underlying technical
foundations are. When seeking is slow, or importing media takes half
an hour, all the fancy screenshots and buttons can be all bling and
shiny, and it still sucks.
Cheers
-Richard
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
> What open source applications do you
> think fit this description? Surely The GIMP and Blender are out ("no
> offense intended" to continue the thread).
That's the issue, when it comes to the GUI, almost all of Linux is
out. I can't think of a single app I was floored by that I said "this
GUI is awesome" except for Blender. But I'm sure to get assassinated
for saying that ;-). When it comes to NLEs though I'd say FCP has a
nice design. Enough hot-keys to make it fast, but it still has enough
buttons to make it usable for new users. Finding that balance is hard.
Blender is blazing fast once you know how to use it. The forums are
filled with users who say that they can model twice in fast with
Blender than in Maya (in fact some model in Blender and then export to
Maya) but for new users it is hard.
Timothy
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
On Wed, 30 Jan 2008 17:22:54 +0100, Timothy Baldridge <[EMAIL PROTECTED]> wrote: No offense intended, but is anyone up to the task and willing to either add the following missing functionality to libmpeg3 or another mpeg2 decoder, or can point me to a piece of code in the free software community that does the following: Accurate Seeking + Fast inaccurate seeking without Image corruption + GOP extraction + Access to stream infos such as Field-Order and PAR and Chroma placement. To quote you, "no offense intended", but why do we need mpeg2 support at all? I did videography work for a few years and never had a need for that. Convert your mpeg to a real editing format and go from there. For that matter, I prefer image sequences. Give me an example of a single program that natively handles mpeg2 video and I'll show you 4 that don't. Premiere, FCP, Flint/Effect, After Effects, they don't. mpeg is a distribution format never, ever, edit in mpeg2 it looks like trash compared to DV and uncompressed video. The only reason I can think of where I'd want mpeg2 is for editing DVDs and hopefully we're reaching for a bigger audience than that. Um, and for HDV. Or XDCAM, for that matter. Temporally compressed video as aquisition formats are becoming _more_ common. Not less. Your statement would have been appropriate 5 years ago. Not today. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
> Sure, anyone can create a gui, but who can create a good looking gui
> that's both fast and intuituve? That's a hard find.
>
Here, here! I know we need to focus on the underlying pieces, but I am
wondering if there is anyone out there in the greater open source
community that we think has a talent for the above. And, if there is,
would it be possible to get them to work with us on just the gui piece
(when the time comes of course)? What open source applications do you
think fit this description? Surely The GIMP and Blender are out ("no
offense intended" to continue the thread).
--
Thanks,
Aaron Newcomb
http://www.thesourceshow.org
http://www.opennewsshow.org
___
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
> No offense intended, but is anyone up to the task and willing to > either add the following missing functionality to libmpeg3 or another > mpeg2 decoder, or can point me to a piece of code in the free software > community that does the following: > > Accurate Seeking + Fast inaccurate seeking without Image corruption + > GOP extraction + Access to stream infos such as Field-Order and PAR > and Chroma placement. To quote you, "no offense intended", but why do we need mpeg2 support at all? I did videography work for a few years and never had a need for that. Convert your mpeg to a real editing format and go from there. For that matter, I prefer image sequences. Give me an example of a single program that natively handles mpeg2 video and I'll show you 4 that don't. Premiere, FCP, Flint/Effect, After Effects, they don't. mpeg is a distribution format never, ever, edit in mpeg2 it looks like trash compared to DV and uncompressed video. The only reason I can think of where I'd want mpeg2 is for editing DVDs and hopefully we're reaching for a bigger audience than that. Sure, anyone can create a gui, but who can create a good looking gui that's both fast and intuituve? That's a hard find. Timothy ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
Can we stop that GUI funny talk? GUIs are easy cheesy, everyone can start a dialog editor drag some buttons to a canvas and write some code that is run when the button is pressed. :-P Lets talk about the serious stuff. ;-) No offense intended, but is anyone up to the task and willing to either add the following missing functionality to libmpeg3 or another mpeg2 decoder, or can point me to a piece of code in the free software community that does the following: Accurate Seeking + Fast inaccurate seeking without Image corruption + GOP extraction + Access to stream infos such as Field-Order and PAR and Chroma placement. Additionally it would be nice if the decoder could reproduce the encoding params of a given File and feed those to an mpeg2 encoder. And of course the API should be nice and clean and easy to use, for examples of decent API design look at libsndfile and libquicktime. Thanks, and have fun -Richard ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
QT is very easy to use and powerful, but it normally wants to dictate how the gui is coded. moc, uic, and qmake need to be the backbone of the project. If you use these tools, building QT applications can be easy and painless (I speak from experience), but you are forced into their coding styles. If possible, I'd like to mention FOX GUI. It's fast, stable and has a good feature set. Another good one is FLTK. Until recently Nuke used it before switching to QT(I think). Both of these are fast and powerful, but they do give that '90's look. Which I don't mind, but some may. Still QT is nice for theming seeing as it supports CSS styling for widgets. Just some thoughts. Timothy ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
Burkhard Plaum wrote: > Hi, > > Richard Spindler schrieb: >> 2008/1/30, Gour <[EMAIL PROTECTED]>: >>> Martin> (For Qt), Is it possible for the community (ie anyone outside >>> Martin> TrollTech) to write user interface widgets? Cin3 will need to >>> Martin> write some specialist widgets -- how will this fit in with the >>> Martin> toolkit and the toolkit's development process? >>> >>> No idea. Let me just say that GTK+ toolkit is getting native on Mac OS >>> X, works on Win and it's not property of Nokia ;) >> >> Writing Custom Widgets is possible in every Toolkit, and Qt has been >> "native" OSX for a long time. But indeed, GTK seems to catch up. >> >> Discussing Toolkits is pointless btw. without someone actually writing >> the Code for said toolkit. > > Actually I didn't want to participate in toolkit discussions, but if we > agree, that > > 1. All plugin interfaces are C because this is the smallest common base to make it bindable to other languages. The idea is to make the plugin interface easy bindable to other languages. > > 2. Plugins should be allowed to make their own configuration widgets > > we are already restricted to a C-toolkit or not? C binding would be sufficent, and it should not do too much, just being an UI toolkit and not expect we will use its object system/types for anything else than the GUI. > > Burkhard > > ___ > Cinelerra mailing list > Cinelerra@skolelinux.no > https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
2008/1/30, Burkhard Plaum <[EMAIL PROTECTED]>: > 1. All plugin interfaces are C > > 2. Plugins should be allowed to make their own configuration widgets > > we are already restricted to a C-toolkit or not? *cough* xembed *cough* -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
2008/1/30, Martin Ellison <[EMAIL PROTECTED]>: > > Discussing Toolkits is pointless btw. without someone actually writing > > the Code for said toolkit. > > Best to think about what code we are going to write before we start writing > the code. We don't want to spend two years coding and then find that we > should have taken a different approach. About 5% of the total effort needs > to go on planning and tracking. For every widely available Toolkit on Linux, big and capable applications were written, so obviously they are all up to the task. He who happens to write the GUI gets to choose the Toolkit, and nobody else gets to complain. ;-) Cheers -Richard -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
Hi, Richard Spindler schrieb: 2008/1/30, Gour <[EMAIL PROTECTED]>: Martin> (For Qt), Is it possible for the community (ie anyone outside Martin> TrollTech) to write user interface widgets? Cin3 will need to Martin> write some specialist widgets -- how will this fit in with the Martin> toolkit and the toolkit's development process? No idea. Let me just say that GTK+ toolkit is getting native on Mac OS X, works on Win and it's not property of Nokia ;) Writing Custom Widgets is possible in every Toolkit, and Qt has been "native" OSX for a long time. But indeed, GTK seems to catch up. Discussing Toolkits is pointless btw. without someone actually writing the Code for said toolkit. Actually I didn't want to participate in toolkit discussions, but if we agree, that 1. All plugin interfaces are C 2. Plugins should be allowed to make their own configuration widgets we are already restricted to a C-toolkit or not? Burkhard ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
On 30/01/2008, Richard Spindler <[EMAIL PROTECTED]> wrote: > > > Discussing Toolkits is pointless btw. without someone actually writing > the Code for said toolkit. > Best to think about what code we are going to write before we start writing the code. We don't want to spend two years coding and then find that we should have taken a different approach. About 5% of the total effort needs to go on planning and tracking. -- Regards, Martin ([EMAIL PROTECTED]) IT: http://methodsupport.com Personal: http://thereisnoend.org
Re: [CinCVS] Re: User interface toolkits and "Cin-3"
2008/1/30, Gour <[EMAIL PROTECTED]>: > Martin> (For Qt), Is it possible for the community (ie anyone outside > Martin> TrollTech) to write user interface widgets? Cin3 will need to > Martin> write some specialist widgets -- how will this fit in with the > Martin> toolkit and the toolkit's development process? > > No idea. Let me just say that GTK+ toolkit is getting native on Mac OS > X, works on Win and it's not property of Nokia ;) Writing Custom Widgets is possible in every Toolkit, and Qt has been "native" OSX for a long time. But indeed, GTK seems to catch up. Discussing Toolkits is pointless btw. without someone actually writing the Code for said toolkit. -- Are you teaching the What and the How but without the Why and the When? ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
[CinCVS] Re: User interface toolkits and "Cin-3"
> "Martin" == Martin Ellison <[EMAIL PROTECTED]> writes: Martin> (For Qt), Is it possible for the community (ie anyone outside Martin> TrollTech) to write user interface widgets? Cin3 will need to Martin> write some specialist widgets -- how will this fit in with the Martin> toolkit and the toolkit's development process? No idea. Let me just say that GTK+ toolkit is getting native on Mac OS X, works on Win and it's not property of Nokia ;) Sincerely, Gour pgp9zNLmTvIlZ.pgp Description: PGP signature
