Hi Francesco!
Am 31.01.2009 um 17:28 schrieb Francesco Romani:
On Sat, 2009-01-31 at 13:37 +0100, Jörn Reder wrote:
Francesco Romani wrote:
- The GUI should be coded in C or in C++. We're already full of
dependencies, so I'm really reluctant to add new _core_ dependencies
(modules are a different story) unless necessary.
If the GUI will be in C or C++, that's another point _against_ a
frontend and in favour of a native approach.
Probably another approach towards getting a GUI (official or not ;)
could be: provide a stable C-API to be bound by scripting
languages like
Perl, Python, Ruby etc. So the GUI stuff could be done in an
interpreted
language, which makes things easier in my opinion.
You're raising a very interesting point.
Which, unfortunately, isn't easy to address :)
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.
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.
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 ;-)
Regards
Michael
