bug-vcdimager
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[VCDImager Bugs/Devel] RFC: plans for a gnome GUI...


From: Herbert Valerio Riedel
Subject: [VCDImager Bugs/Devel] RFC: plans for a gnome GUI...
Date: Wed, 16 May 2001 16:47:17 +0200 (CEST)

hi,

(this is meant as a RFC, ie I want to discuss this... ;)

intro
~~~~~

as many know already, the cvs version has added support for the major
missing VCD2.0/SVCD features, most prominently an almost complete PBC
support including menus (by using selection lists and segment items) and
multiple entry points per sequence track...

for this features to be used, the command line would get too complex, and
since I'm a fan of markup languages, and decided XML to be appropriate
for this task, I've come up with a new 'frontend' (which actually will be
used as backend by the GUI in the first time) which can be found in
frontends/xml, it will supercede the old cli frontends when time goes by,
which will actually be just wrappers for the vcdxml variants, generating
some simple videocd xml description, which will be fed to vcdxml...

well, since I don't people expect to write complex interactive by hand in
xml (but they can and it will be the only way to accomplish that before
there ain't any GUI tool which helps people with that) there's no a real
necessity for some GUI tool (in the past it would have been just a nice
addition whereas now it would really improve user friendly-ness)

some of you may already have seen tools for authoring menu structures
like I-Author or philips SVCD designer and alike...

the plan
~~~~~~~~

I'd like to give the user the possibility to design graphically the
control/menu flow by connecting boxes through lines and alike...
it should be a simple approach, giving full flexibility to use all
possible available features (it doesn't have to be able to do it in the
first version, but it should be designed in way to be able to add support
lateron -- and anyway, people will be able to edit the .xml files by hand
in any case if they need exotic stuff)

in its first incarnation the GUI should be just a kind of 'editor' for vcd
xml descriptions, that is, it should be able to let the user design a
videocd, and write that to a xml file... reading the description back
should be possible too...
a quick'n'dirty fork()ing of vcdxml, possibly making use of it's
output for progress indication should be quite easy...

fyi, I don't like direct linking with libvcd yet, since I want to redesign
the libvcd api a bit, and having to change 2 or 3 frontends depending on
that api would be quite annoying... error handling is not yet finished in
libvcd (and btw, there are known memleaks left, which I don't want to care
for yet)

I'd like to use C++ if nobody has problems with it. (this doesn't mean
yet, one has to use gtk--/gnome--, although I'd like to as well :-)

for the graphic design stuff I'd like to use gnome canvas (see articles on
the IBM page at the end of this mail)

the xml part should be libxml2 based, either directly by using directly
the C interface, or by using one of the c++ wrappers to it... whatever
means less problems :-)

the interface should be designed by using glade and libglade where
possible.

I'll investigate whether 'bakery' would be usefull for this project, which
should make less work needed for document oriented programs by providing
some framework...

that's enough for now.... I should get back to coding, instead of
vaporware production ;)

future stuff/features/ideas:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

*) vcd simulation (possibly by remote controlling some bonobo'ized or
whatever mpeg player) -- could be enhanced into a full videocd player

*) possibility to define selection areas for extended selection lists
(yes, there are provisions in the standards to select menu items by some
pointing device... that's what those X-files in /EXT  are for ;)

*) different views of control flow, maybe some table-like/low level
representation in addition to the highlevel flowchart

*) printing the flow chart

*) keep it open, to enable integration/interfacing to other video editing
GUIs (or even cli tools) which may evolve through time... drag and drop
from/to other applications comes to mind... e.g. say we had a 'CDR'
object, then one could drag and drop the vcd project on that object, and
it would get burned... :-) don't know if you ever have played around with
openstep or macos... there are plenty of such cool interaction ways...

programming links:
~~~~~~~~~~~~~~~~~~

*) the official gnome developer site
http://developer.gnome.org/

*) some usefull gnome intro
http://www.ibm.com/developerworks/library/gnome-programming/
(especially check those gnome articles by george lebl, see next link for
getting articles by author)

*) ...some index...
http://www.ibm.com/developerworks/papers.nsf/dw/linux-papers-bynewest?OpenDocument&Count=500

*) pdf rendered versions of the html pages:
ftp://www6.software.ibm.com/software/developer/library/

greetings,
-- 
Herbert Valerio Riedel       /    Phone: (EUROPE) +43-1-58801-18840
Email: address@hidden       /    Finger address@hidden for GnuPG Public Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748  5F65 4981 E064 883F 4142




reply via email to

[Prev in Thread] Current Thread [Next in Thread]