On Sun, 2009-02-01 at 12:11 +0100, Michael Müller wrote: > > Anyway, granted my lack of experience, the mere GUI building step > > should > > not be _that_ hard; I thought since the beginning some kind of > > designer > > should be used, as glade or the QT equivalent (QT designer?). > > > > Once the .glade file is done, to write down a (thin) glue layer > > should'nt be a big deal, I guess I can afford without so much > > problems. > > > > Maybe it's just easier if I put together some ideas, fire up glade and > > make avalaible a mockup :) > What is your general idea of such a GUI? Should it just offer a > graphical interface for the many transcode options or should it also > offer functionality that helps to find the best parameters for some > options, as e.g. in Jörns dvd::rip that detects the right aspect > ratios and size of the black bars at the top and bottom to cut them. > The only bad thing is that it can only handle DVDs. I have here a lot > of movies recorded with my DVB-T stick that I would like to transcode > to save space but I don't want to determine the crop and rescale > parameters manually. Such functionality is what I would expect from a > GUI for transcode. You could also say that it should define a > workflow, again dvd::rip is a good example here.
Hi, My idea of GUI reflects your thoughts. I'd like to put together somethign that actually helps the transcoding process, and it is NOT a catalog of transcode options presented using some cool (or not) widgets. So, the GUI has (or should) - to follow through the user in each setup step (e.g. filter, encoding options, preset, output format...) _but_ without forcing the user doing each step every time (I'm thinking to some really annoying wizards seen in the past). In nutshell, a proper GUI (better: a proper UI) should be useful and comfortable both for inexperienced and advanced user - to present sensible defaults, and to allow the user to change (almost) everything _but_ without throwing all the settings all together on the user (seen on some KDE panels). - to help the user doing right the parameters hard to figure out, as the crop/resize settings you mentioned. - (more to come). Of course this can't come all together, I'm expecting a gradual growth. As first step, IMO it's enough if the GUI should present the base workflow and a polished, hierarchical configuration of the processing stages. I'm taking the handbrake GUI as a good example/model for that. > And regardless which GUI library or scripting language you select it > should run on every platform transcode is able to run. It would be > bad to read: You can compile transcode on Mac OS X too but the GUI > only runs under Windows and Linux. Definitively. But since transcode runs only on POSIX systems, I guess we don't have to restrict our choice here :) > Since for the GUI part it is not important to run with maximum speed > a scripting language shouldn't be so bad compared to a compiled > program. A problem of a scripting language would be that a further > programming language would become part of the project and at least > the project maintainers should be able to use both ;-) The speed isn't important, and surely Joern made a point into his former message by pointing out that the major languages are already widespread enough (I speak python only, though). Anyway, is not the GUI application logic that scares me. Is the UI design, the part done using QT designer or Glade or whatever :) It's also the vast majority of the work needed. To put it out using different words, if a well-done .glade files drops out from the sky, the ~90% of the work for the GUI version 1.0 is done :) Bests, -- Francesco Romani // Ikitt http://fromani.exit1.org ::: transcode homepage http://tcforge.berlios.de ::: transcode experimental forge
