Re: [CinCVS] Re: User interface toolkits and Cin-3

2008-01-31 Thread Martin Ellison
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

2008-01-31 Thread Herman Robak

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

2008-01-30 Thread Richard Spindler
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


Re: [CinCVS] Re: User interface toolkits and Cin-3

2008-01-30 Thread Burkhard Plaum

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

2008-01-30 Thread Martin Ellison
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-01-30 Thread Richard Spindler
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

2008-01-30 Thread Richard Spindler
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-01-30 Thread Christian Thaeter
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-01-30 Thread Timothy Baldridge
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

2008-01-30 Thread Richard Spindler
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

2008-01-30 Thread Timothy Baldridge
 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

2008-01-30 Thread Herman Robak
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

2008-01-30 Thread Aaron Newcomb
 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

2008-01-30 Thread Richard Spindler
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

2008-01-30 Thread Richard Spindler
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-01-30 Thread Timothy Baldridge
 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-01-30 Thread Timothy Baldridge
 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

2008-01-30 Thread Richard Spindler
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

2008-01-30 Thread Timothy Baldridge
 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-01-30 Thread Richard Spindler
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


[CinCVS] Re: User interface toolkits and Cin-3

2008-01-29 Thread Gour
 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