Re: we need a (official) GUI

Jörn Reder  wrote:
> Phil Ehrens wrote:
> 
> > Perl and Python are NOT platform independent at the same level.
> > Have you coded in Perl, Python, and Tcl for Windows, OSX, Linux,
> > and Solaris? I have. You will spend at LEAST three times as much
> > time doing this with Perl or Python as you would with Tcl/Tk.
> 
> I do this since 12 years with Perl on Solaris, Irix, Linux and Windows.
> Never did it with Tcl/Tk, because I'am happy how good it works with Perl
> ;)

Because of where I work, I'm not free to become attached to any
one scripting language. I'm *supposed* to consider long-term
support over the next 30 years for whatever I develop. 12 years
ago I thought Perl was the only way to go ;^)

> > It should have no priority at all, but I thought that Transcode
> > supported Windows. My bad.
> 
> You really thought transcode supports Windows? I am stunned.

Sorry, even though I maintain the wiki, I only ever really cared
about Transcode's ability to help me make dvd's, and never paid
much attention to it otherwise. Transcode has done SO much for me
that I feel obliged to maintain the wiki for as long as it's
considered useful.

> > I'm not kidding. I have no idea why you find this so unbelievable.
> 
> Because _Internet technology_ for video editing / transcoding purposes 
> is just not the best technology you can choose (of course anything is 
> _possible_ ...). I did many HTML/JavaScript/Ajax coding in my life and I
> never would try to cover a video editing solution with that technology.
> It's simply not appropriate for that and bloats things up tremendously 
> (if it's not just a simple HTML form, which just generates one simple 
> command line and just spits out transcode's output... but I think that's
> not the idea of an "offical GUI" we're originally talking about 
> here...).

Video EDITING?! Does Transcode support editing?! Jeez, I really am out
of the loop then.

> > All the gui needs to be able to do is take user input, build
> > command lines, and hook output from Transcode, right?
> 
> That would be the minimum. More than that for example would be realtime
> previewing which needs some more effort than "just" wrapping command 
> lines. As well it sounds very easy: user input -> build cmdline -> grab
> transcode output. Building an intuitive GUI which supports the user in 
> his _goals_ (not just enumerating command line options), is much more 
> difficult. This challenge is of course mostly independent from the 
> toolkit used.

Hence my suggestions, which were made in the spirit of minimising the
amount of toolkit related hacking that the GUI author would have to
deal with.