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.
