Kino

On Thu, 2002-10-24 at 20:35, The Surprises wrote:
> Hi,  here are my 2.5 cents on the GUI redesign effort.  If we look at
> what a 'typical' user wants in an editor:  he/she has a set of footage,
> probably all taken from a single camera.  

For many people, the requirements stop here. For a large majority of
users, all they want to do is remove adverts^H^H^H^H^H^H^Hunwanted
footage and convert to mpeg/divx - these people are the easiest to
satisfy.

> He will have a main video
> track where he will mainly want to put transitions/effects between
> scenes.  

For many people, it stops here. 

> He will also want to have a separate audio track for
> background music.  Optionally he will also want a 'title' track where
> he will want to easily overlay titles.
> 
> The more advanced user will want to do constant audio volume matching of
> disparate scenes.  He will probably have another audio track for sound
> effects.  He will want to sync up various actions in the main video with
> the sound track, so a view of the waveform would be necessary.  He will
> probably want another couple video tracks to do interesting things like
> video overlay, blue screen effects, custom gradient alpha channel
> overlays..

OK - the point I'm trying to make is that some people simply don't want
the clutter or the bloat of a fancy set of functionality, especially if
that clutter makes their immediate requirements seem inaccessible. I
feel a multi-layered timeline shoved in your face and requiring
attention is a turn off to the first two types of users (and I would
imagine that many of our users fall into this category if only by dint
of the fact that that is pretty much all we provide :-)).

In my view, a timeline is one of many views that are valid when tackling
video editing - there is simply no magic bullet that satisfies all
users.

> Whether you're a typical user or more advanced, you will have a bunch of
> things happening concurrently, and in my opinion the multitrack timeline
> editor is the only place where you can 'visualize' what's happening in
> your design.  Admittedly, you can probably do everything you want with
> the current FX flow, but I feel that the current approach becomes
> unmanageable for complex designs.  It feels too 'all or none.'  Once you
> create an FX, it's rendered and in your playlist.  There's no history of
> the FXs you performed.  It's difficult to quickly do what-if analyses or
> change around your ideas.  You also shouldn't have to use the FX flow to
> do the most used tasks like volume control on audio and maybe fader
> control on video.

Just to set the record straight, the current FX implementation was never
meant to be a *good* solution - it was a quick hack that got adopted in
kino to provide some very basic functionality (I will admit that the
quick hack took much longer than I had anticipated - time that probably
would have been better spent on doing it correctly, but, what the hell,
I think the results are kind of fun ;-)).

The idea is that Dan's new DOM will take care of the editing
requirements (by essentially serialising the FX configuration into the
SMIL document) and potentially, we will be able to provide lazy
evaluation from there thus removing the render *requirement* [but not
the functionality].

Up to now, our concentration has been on ieee1394 integration and
simple, but essential, functionality such as the SMIL implementation,
reliable playback, copy/cut/paste and trim and so on. Only recently did
libdv start exposing an interface for encoding, so that particular
functionality has only been available to us for a few months (there was
simply no point in even considering a multi-layered timeline until that
functionality came on board).

> So I kinda disagree with Charles and feel that the timeline is perhaps
> the most important function and should be readily available instead of
> under one of kino's pages.  I think the user will spend most of his time
> here.

The way I see it, whether the timeline is the default presentation
shouldn't present an issue at all... at most, it'll be one click or key
press away. 

The timeline workspace can carry its own preview window and provide a
full complement of functionality - what I definitely want to retain is
the current Editor, which is a keyboard driven, friendly, sensible and
covers the requirements of many of our users.

In relation to the other responses on this thread, maybe we could even
have a way of reorganising the workspaces so that you can select your
own default? Dunno - hardly seems like an issue to me. 

> Hence, I started to write one!  I've written several GUIs, but this is
> the first GTK+ one.  Regarding the global widget structure, I'll admit
> that I cringed when I took a first look at the Kino widget architecture.

Heh - no surprise there. When I came on board, I took the original
design of the app as my introduction to gtk/glade et al, and failed to
see how glade could be used to make more refined widgets. Hence I
settled for the activation/deactivation of the 'global' widgets as at
least it would avoid the issues of duplicating parts of the GUI
throughout the applications window. This was not the best approach, but
it's served us OK up to now... the first task I want to resolve in the
re-design is removing these global widgets, and replacing them with
multiply occurring objects.

> The way I've written GUIs in the past is to have each component of the
> design own it's widgets, so the global nature of the Kino widgets was
> different to me.  However, I decided to mirror the Kino architecture for the
> timeline design so that it could hopfully be placed into Kino more
> easily.  So, I ramped up on GTK and glade.  One of the things I like
> about this style now is that you decouple the GUI development with the real
> content of the design.  This allows you to iterate on the GUI looks
> without having to touch the other code.  I've made wholesale changes to
> the timeline GUI over the past few weeks to get it just right.  It would
> have been more difficult to do if each section of the timeline owned
> it's widgets.  We do lose the ability to create multiple widgets, but if
> the widgets have no reason to be duplicated, then maybe it's not that
> big of a deal.

Well, I'd like to have a proper chance to review your code here. I've
found a few ways to use glade to produce multiply occuring widgets, and
my initial take on the demo you sent me was that it would fit right in
there. The main thing to do is simply not use glades built-in callback
mechanism (as it doesn't provide a very clean way of associating events
to the instance of a widget - short of using a bunch of nasty globals
anyway).

> Regardings libsigc++ and gtkmm.  I also don't like the event mechanism
> of GTK+.  I'm doing the static to c++ method callback workaround in the
> timeline and don't like it.  libsigc++ seems to fix this.  I have
> written a couple GUIs using the QT GUI toolkit (www.trolltech.com),
> which is a full c++ GUI package.  I really liked it.  They also have a
> very nice signal/slot event mechanism that I thought was very intuitive.

At one point I was all in favour of QT, but after getting to grips with
the way the GTK+ environment works, I must admit that QT has totally
lost its appeal (but then, knowing what I do about the GTK+ environment,
being exposed to QT again would probably make me switch back :-)). For
now though, I'll just point you to my reply to Tim's mail this
morning...

Anyway, many thanks for your input, and please let me know when you have
a new timeline demo which I can play with :-).

Cheers,

Charlie

On Thu, Oct 24, 2002 at 09:58:15PM +0200, Charles Yates wrote:
> On Thu, 2002-10-24 at 20:35, The Surprises wrote:
> > Hi,  here are my 2.5 cents on the GUI redesign effort.  If we look at
> > what a 'typical' user wants in an editor:  he/she has a set of footage,
> > probably all taken from a single camera.  
> 
> For many people, the requirements stop here. For a large majority of
> users, all they want to do is remove adverts^H^H^H^H^H^H^Hunwanted
> footage and convert to mpeg/divx - these people are the easiest to
> satisfy.
> 

Hmm.  You're definitely right here, and current Kino works very well for
this without any need for a timeline..

> > He will have a main video
> > track where he will mainly want to put transitions/effects between
> > scenes.  
> 
> For many people, it stops here. 
> 
> > He will also want to have a separate audio track for
> > background music.  Optionally he will also want a 'title' track where
> > he will want to easily overlay titles.
> > 
> > The more advanced user will want to do constant audio volume matching of
> > disparate scenes.  He will probably have another audio track for sound
> > effects.  He will want to sync up various actions in the main video with
> > the sound track, so a view of the waveform would be necessary.  He will
> > probably want another couple video tracks to do interesting things like
> > video overlay, blue screen effects, custom gradient alpha channel
> > overlays..
> 
> OK - the point I'm trying to make is that some people simply don't want
> the clutter or the bloat of a fancy set of functionality, especially if
> that clutter makes their immediate requirements seem inaccessible. I
> feel a multi-layered timeline shoved in your face and requiring
> attention is a turn off to the first two types of users (and I would
> imagine that many of our users fall into this category if only by dint
> of the fact that that is pretty much all we provide :-)).
> 
> In my view, a timeline is one of many views that are valid when tackling
> video editing - there is simply no magic bullet that satisfies all
> users.
> 
> > Whether you're a typical user or more advanced, you will have a bunch of
> > things happening concurrently, and in my opinion the multitrack timeline
> > editor is the only place where you can 'visualize' what's happening in
> > your design.  Admittedly, you can probably do everything you want with
> > the current FX flow, but I feel that the current approach becomes
> > unmanageable for complex designs.  It feels too 'all or none.'  Once you
> > create an FX, it's rendered and in your playlist.  There's no history of
> > the FXs you performed.  It's difficult to quickly do what-if analyses or
> > change around your ideas.  You also shouldn't have to use the FX flow to
> > do the most used tasks like volume control on audio and maybe fader
> > control on video.
> 
> Just to set the record straight, the current FX implementation was never
> meant to be a *good* solution - it was a quick hack that got adopted in
> kino to provide some very basic functionality (I will admit that the
> quick hack took much longer than I had anticipated - time that probably
> would have been better spent on doing it correctly, but, what the hell,
> I think the results are kind of fun ;-)).
> 
> The idea is that Dan's new DOM will take care of the editing
> requirements (by essentially serialising the FX configuration into the
> SMIL document) and potentially, we will be able to provide lazy
> evaluation from there thus removing the render *requirement* [but not
> the functionality].
> 
> Up to now, our concentration has been on ieee1394 integration and
> simple, but essential, functionality such as the SMIL implementation,
> reliable playback, copy/cut/paste and trim and so on. Only recently did
> libdv start exposing an interface for encoding, so that particular
> functionality has only been available to us for a few months (there was
> simply no point in even considering a multi-layered timeline until that
> functionality came on board).
> 
> > So I kinda disagree with Charles and feel that the timeline is perhaps
> > the most important function and should be readily available instead of
> > under one of kino's pages.  I think the user will spend most of his time
> > here.
> 
> The way I see it, whether the timeline is the default presentation
> shouldn't present an issue at all... at most, it'll be one click or key
> press away. 
> 
> The timeline workspace can carry its own preview window and provide a
> full complement of functionality - what I definitely want to retain is
> the current Editor, which is a keyboard driven, friendly, sensible and
> covers the requirements of many of our users.
> 
> In relation to the other responses on this thread, maybe we could even
> have a way of reorganising the workspaces so that you can select your
> own default? Dunno - hardly seems like an issue to me. 
> 

I also like the editor.  It's a very nice interface for working with
individual clips.  I also agree that this should remain.  This could be
where you edit all of your clips, cutting, pasting, arranging, video
effects.  Then you could drag the clips into the timeline, or you could
push a button and snarf the whole thing into the timeline for further
editing.

> > Hence, I started to write one!  I've written several GUIs, but this is
> > the first GTK+ one.  Regarding the global widget structure, I'll admit
> > that I cringed when I took a first look at the Kino widget architecture.
> 
> Heh - no surprise there. When I came on board, I took the original
> design of the app as my introduction to gtk/glade et al, and failed to
> see how glade could be used to make more refined widgets. Hence I
> settled for the activation/deactivation of the 'global' widgets as at
> least it would avoid the issues of duplicating parts of the GUI
> throughout the applications window. This was not the best approach, but
> it's served us OK up to now... the first task I want to resolve in the
> re-design is removing these global widgets, and replacing them with
> multiply occurring objects.
> 

> > The way I've written GUIs in the past is to have each component of the
> > design own it's widgets, so the global nature of the Kino widgets was
> > different to me.  However, I decided to mirror the Kino architecture for the
> > timeline design so that it could hopfully be placed into Kino more
> > easily.  So, I ramped up on GTK and glade.  One of the things I like
> > about this style now is that you decouple the GUI development with the real
> > content of the design.  This allows you to iterate on the GUI looks
> > without having to touch the other code.  I've made wholesale changes to
> > the timeline GUI over the past few weeks to get it just right.  It would
> > have been more difficult to do if each section of the timeline owned
> > it's widgets.  We do lose the ability to create multiple widgets, but if
> > the widgets have no reason to be duplicated, then maybe it's not that
> > big of a deal.
> 
> Well, I'd like to have a proper chance to review your code here. I've
> found a few ways to use glade to produce multiply occuring widgets, and
> my initial take on the demo you sent me was that it would fit right in
> there. The main thing to do is simply not use glades built-in callback
> mechanism (as it doesn't provide a very clean way of associating events
> to the instance of a widget - short of using a bunch of nasty globals
> anyway).
> 

Seems like all signs point to gtkmm.  I just took a look at it and it
gives the same look and feel as QT, which is good for me :)

> > Regardings libsigc++ and gtkmm.  I also don't like the event mechanism
> > of GTK+.  I'm doing the static to c++ method callback workaround in the
> > timeline and don't like it.  libsigc++ seems to fix this.  I have
> > written a couple GUIs using the QT GUI toolkit (www.trolltech.com),
> > which is a full c++ GUI package.  I really liked it.  They also have a
> > very nice signal/slot event mechanism that I thought was very intuitive.
> 
> At one point I was all in favour of QT, but after getting to grips with
> the way the GTK+ environment works, I must admit that QT has totally
> lost its appeal (but then, knowing what I do about the GTK+ environment,
> being exposed to QT again would probably make me switch back :-)). For
> now though, I'll just point you to my reply to Tim's mail this
> morning...
> 
> Anyway, many thanks for your input, and please let me know when you have
> a new timeline demo which I can play with :-).
> 

I have made a few more enhancements to the timeline.  You can add
transiiton tracks.  Transition tracks have the unique ability to be
resized, which isn't available to the other tracks.  I've also snarfed
the custom hruler from Ardour which creates a time based hruler instead
of just a set of numbers representing the frame.  It gives you a better
idea of where you are in the timeline.  I don't quite like how it was
implemented - the ruler ticks don't move, only the numbers change.  It's
kind of awkard to look at when you're scrolling.  Ah well, maybe I'll
back out of it.

I can send you what I currently have.  It's currently in a state of flux
because I'm trying to implement drag-n-drop of clips to other tracks,
but I can patch it up and send you something working.


Thanks,
Jason

On Thu, 2002-10-24 at 16:33, The Surprises wrote:
> > Anyway, many thanks for your input, and please let me know when you have
> > a new timeline demo which I can play with :-).
>
> I can send you what I currently have.  It's currently in a state of flux
> because I'm trying to implement drag-n-drop of clips to other tracks,
> but I can patch it up and send you something working.
> 
Charlie sent it to me to check out too. I did, and it looks like a
decent start. I did like how you have a little glade file showing how it
fits into a glade-based container to make it easier for us to integrate.
Please send any updates to me as well.
Do you think its better to develop to GTK2 so we don't have to later
port it? I heard developing on GTK2 is easier, but perhaps there is not
as many good examples.

On Thu, Oct 24, 2002 at 04:57:17PM -0400, Dan Dennedy wrote:
> On Thu, 2002-10-24 at 16:33, The Surprises wrote:
> > > Anyway, many thanks for your input, and please let me know when you have
> > > a new timeline demo which I can play with :-).
> >
> > I can send you what I currently have.  It's currently in a state of flux
> > because I'm trying to implement drag-n-drop of clips to other tracks,
> > but I can patch it up and send you something working.
> > 
> Charlie sent it to me to check out too. I did, and it looks like a
> decent start. I did like how you have a little glade file showing how it
> fits into a glade-based container to make it easier for us to integrate.
> Please send any updates to me as well.
> Do you think its better to develop to GTK2 so we don't have to later
> port it? I heard developing on GTK2 is easier, but perhaps there is not
> as many good examples.
> 

I think we need to figure out exactly how we're going with this (GTK2,
gtkmm, object oriented widget creation, etc) before I start making
changes.  I want to make sure we're all clear on the goals before
jumping into the redesign..  I'll send out the latest code I have that
implements sizable transition clips and a custom hruler.

On Thu, 2002-10-24 at 20:35, The Surprises wrote:
> 
> I think we need to figure out exactly how we're going with this (GTK2,
> gtkmm, object oriented widget creation, etc) before I start making
> changes.  I want to make sure we're all clear on the goals before
> jumping into the redesign..  I'll send out the latest code I have that
> implements sizable transition clips and a custom hruler.
> 
I understand. We all agree that we need a multitrack timeline. Charlie
is just saying it needs to be implemented as view/super-widget that can
be put into one of several workspace configrations, and I believe there
is enough concensus on that point.

Now, the move to GTK2 and whether to use gtkmm are two separate issues.
Charlie, as demonstrated already, will likely contribute more than
anyone else, so his opinion weighs heavier. I hope he agrees that
adopting GTK2 for a major GUI overhaul at this point is just plain
practical. I think it will take a while to get it done. Meanwhile, GTK2
is not as bleeding edge as GNOME2, and was released much earlier than
GNOME2. It is much easier for users to adopt a GTK2 app than a GNOME2
app. I would like to get his opinion on that approach. GTK2 apps do not
require the GNOME2 desktop, and the libraries coexist peacefully
alongside GTK+1.2. We can also see what distros are including GTK2. But
this is a more cutting edge application than, say, a web server, and
most of our users are updating their desktops sooner than later.

I personally, don't have a strong opinion about gtkmm vs. straight gtk.
I think Charlie has a good point regarding the user base, library
dependencies and all. I think he was disappointed Kino did not ship with
Mandrake 9, but glad it wasn't the 0.51 version =). OTOH, I have stated
before that I don't mind adding libs as long as it does not spiral out
of control and provides justifiable value. I don't know the popularity
of gtkmm; it seems to be gaining. I honestly do not have enough of a
software engineering and object oriented design background to really
appreciate what value gtkmm and libsig++ can bring to the table, but I
would love to learn more and take that approach.

Not to add even more to think about, but have you guys noticed that
GStreamer is starting a NLE called gnolin? 

http://gnonlin.sourceforge.net/ 

I checked out the CVS but couldn't get it to compile.  I'm just curious
if there is anything to gain from using any of the GStreamer framework? 
I believe the idea of gstreamer is that its a full framework to work
with correct? Would using GStreamer inside of kino be of any benefit?

I may be completely off here.  I don't know if there is any advantage at
all other than headaches.  So I won't be offended if you tell me there
is nothing usefull. :-)  I just figured since your talking about a
pretty drastic redesign you might as well know all your options. :-)

On Thu, 2002-10-24 at 20:35, The Surprises wrote:
> On Thu, Oct 24, 2002 at 04:57:17PM -0400, Dan Dennedy wrote:
> > On Thu, 2002-10-24 at 16:33, The Surprises wrote:
> > > > Anyway, many thanks for your input, and please let me know when you have
> > > > a new timeline demo which I can play with :-).
> > >
> > > I can send you what I currently have.  It's currently in a state of flux
> > > because I'm trying to implement drag-n-drop of clips to other tracks,
> > > but I can patch it up and send you something working.
> > > 
> > Charlie sent it to me to check out too. I did, and it looks like a
> > decent start. I did like how you have a little glade file showing how it
> > fits into a glade-based container to make it easier for us to integrate.
> > Please send any updates to me as well.
> > Do you think its better to develop to GTK2 so we don't have to later
> > port it? I heard developing on GTK2 is easier, but perhaps there is not
> > as many good examples.
> > 
> 
> I think we need to figure out exactly how we're going with this (GTK2,
> gtkmm, object oriented widget creation, etc) before I start making
> changes.  I want to make sure we're all clear on the goals before
> jumping into the redesign..  I'll send out the latest code I have that
> implements sizable transition clips and a custom hruler.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future 
> of Java(TM) technology. Join the Java Community 
> Process(SM) (JCP(SM)) program now. 
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0003en
> _______________________________________________
> Kino-dev mailing list
> Kino-dev@...
> https://lists.sourceforge.net/lists/listinfo/kino-dev
>

On Thu, 2002-10-24 at 22:00, Bill Peck wrote:
> Not to add even more to think about, but have you guys noticed that
> GStreamer is starting a NLE called gnolin? 

Yes, I am aware of it, but not the details. I have been tracking
gstreamer since it first started about 1.5 years ago. We have discussed
it a few times. There are some fundamental things about its approach
that make it difficult to swallow. First of all, it is very
comprehensive and complex. This means it takes care of a lot of things
making control over how it operates difficult. I don't know enough about
the API layers to know for sure how easy or difficult it is to achieve
certain things, and I fear get mired down in its idiosyncracies. I admit
it is intimidating. You basically setup the pipeline and let it rip. It
has taken them a long time to get to where they are, and it is still
fragile (using 0.4.1 here).

Kino is built entirely on a model of GetFrame(n). In fact, you see that
method in several places, and called upon a lot. This is not possible
yet in gstreamer as it is fundamentally a streaming model. It requires
what Wim Taymens (sp?) calls segment-based seeking, which are they
working towards. Could we change? I dunno; our model works pretty good
for us and non-temporal-compressed video. I really have no interest in
editing temporal-compressed or variable bitrate media formats because
they are publishing formats not meant for editing except for maybe
cuts-only.

So, let's look at what it would buy us:
* A playback engine: what we have now works pretty good thanks to
Charlie. Anything that can be put into a GetFrame() would work.
* pluggable support for many media formats: yes, we could use that, but
there are other options....
* pluggable support for FX: Charlie and Tim have and are working on that
with good progress in short time. 
* pluggable support for input sources and output methods (ALSA, OSS, Xv,
SDL, 1394, V4L, etc.). This is a weak area for us, but some user are
telling us they don't want Kino to turn into the "kitchen sink."
* An FX pipeline engine: I don't know if Charlie and Tim have anything
in store, but the DOM will take care of some of this. A
Document::getFrame(n) method will have to take care of determing all the
steps necessary to render the delivered frame of audio and video.

As for pluggable media support, I have been very lightly involved with
another project called libquicktime. It is a fork of quicktime4linux. It
uses an autotools build system, adds a codec plugin API, strips out all
embedded libs/projects, and maintains a registry of plugins and
parameters. It is API compatible with QT4L and contains the very same QT
code. The QT4L API is also based upon a GetFrame(n) model making it easy
to integrate. It is also compelling to have nice interop with Cinelerra.
So, this would solve the pluggable media support above while only adding
one additional dependent lib. It recently added AVI support, which we
can enhance if needed or find a way to uses its codec plugin API with
our AVI code. To me that satisfies the requirement of justifiable value
for adding a dependent lib. I will do a personal experiment with Kino
and rudimentary libquicktime support.

As for pluggable inputs and outputs, while not pluggable, we support
1394 and V4L. We support GDK and Xv display methods; I don't really see
the need for anything else. However, we really could use support for
Arts, ALSA, and Esound.

On Fri, 2002-10-25 at 03:38, Dan Dennedy wrote:
> I understand. We all agree that we need a multitrack timeline. Charlie
> is just saying it needs to be implemented as view/super-widget that can
> be put into one of several workspace configrations, and I believe there
> is enough concensus on that point.
> 
> Now, the move to GTK2 and whether to use gtkmm are two separate issues.
> Charlie, as demonstrated already, will likely contribute more than
> anyone else, so his opinion weighs heavier. I hope he agrees that
> adopting GTK2 for a major GUI overhaul at this point is just plain
> practical. I think it will take a while to get it done. Meanwhile, GTK2
> is not as bleeding edge as GNOME2, and was released much earlier than
> GNOME2. It is much easier for users to adopt a GTK2 app than a GNOME2
> app. I would like to get his opinion on that approach. GTK2 apps do not
> require the GNOME2 desktop, and the libraries coexist peacefully
> alongside GTK+1.2. We can also see what distros are including GTK2. But
> this is a more cutting edge application than, say, a web server, and
> most of our users are updating their desktops sooner than later.

Well, the overwhelming feeling I'm getting here is that a migration to
GTK2 is the common concensus. 

The question I have is does gtkmm support GTK2? The reason I ask is to
protect Tim's interest in this API - as you know, I want plug-ins
everywhere, and I want the plug-in implementation to be open to personal
choice (within reason of course - I'd hardly think that you would be
able to create a QT plug-in, but that would be kinda nice :-)). 

> 
> I personally, don't have a strong opinion about gtkmm vs. straight gtk.
> I think Charlie has a good point regarding the user base, library
> dependencies and all. I think he was disappointed Kino did not ship with
> Mandrake 9, but glad it wasn't the 0.51 version =). 

That pretty much sums up my feelings here :-).

> OTOH, I have stated
> before that I don't mind adding libs as long as it does not spiral out
> of control and provides justifiable value. I don't know the popularity
> of gtkmm; it seems to be gaining. I honestly do not have enough of a
> software engineering and object oriented design background to really
> appreciate what value gtkmm and libsig++ can bring to the table, but I
> would love to learn more and take that approach.

Well, adoption of these kind of things follows applications - so, even
if only kino adopts it and kino becomes a regular fixture on distros,
then the issue goes away :-). To save me searching the web, does anybody
know of any popular/good/brilliant/jaw dropping gtkmm applications?

Cheers,

Charlie

On Fri, 2002-10-25 at 08:04, Dan Dennedy wrote:
> 
> So, let's look at what it would buy us:
> * A playback engine: what we have now works pretty good thanks to
> Charlie. Anything that can be put into a GetFrame() would work.
> * pluggable support for many media formats: yes, we could use that, but
> there are other options....
> * pluggable support for FX: Charlie and Tim have and are working on that
> with good progress in short time. 
> * pluggable support for input sources and output methods (ALSA, OSS, Xv,
> SDL, 1394, V4L, etc.). This is a weak area for us, but some user are
> telling us they don't want Kino to turn into the "kitchen sink."
> * An FX pipeline engine: I don't know if Charlie and Tim have anything
> in store, but the DOM will take care of some of this. A
> Document::getFrame(n) method will have to take care of determing all the
> steps necessary to render the delivered frame of audio and video.

I think it can be delayed here - we don't need to apply fx on the
GetFrame, but rather on the specifics of extracting the image or the
audio or the dv encoded data. (We really need to abstract the Frame
class btw - what we need is a Frame interface and DvFrame/MjpegFrame etc
implementations...).

Personally, I do want to use gstreamer and have been planning to do so
for a while. I do not want it to be an intrinsic part of the kino core
though, as I feel it is better suited to Import and Export type
functionality (in our environment anyway) - and this should be provided
via a plug-in. As Dan points out, and I completely agree with, we do not
want to start providing editing facilities for temporal-compressed or
variable bitrate media formats.

If you want to edit these, then the option will be via import only.

Cheers,

Charlie

On Fri, 2002-10-25 at 02:52, Charles Yates wrote:
> audio or the dv encoded data. (We really need to abstract the Frame
> class btw - what we need is a Frame interface and DvFrame/MjpegFrame etc

How would this work in a pluggable framework? Does this fall into a
dynamic casting scenario similar to FX API 2? The plugin implements
DVFrame, and it gets casted into an abstract Frame object?

Charles Yates wrote:
> On Fri, 2002-10-25 at 03:38, Dan Dennedy wrote:

> Well, the overwhelming feeling I'm getting here is that a migration to
> GTK2 is the common concensus. 

Getting tough to tell the players without a scorecard ... :)

> The question I have is does gtkmm support GTK2? The reason I ask is to
> protect Tim's interest in this API - as you know, I want plug-ins
> everywhere, and I want the plug-in implementation to be open to personal
> choice (within reason of course - I'd hardly think that you would be
> able to create a QT plug-in, but that would be kinda nice :-)). 

Yes - you may or may not have noticed that I'm using gtkmm for timfx, 
but the bottom-line is that gtkmm is still GTK+ at heart - there are 
accessor methods in all the gtkmm widgets to get at the "native" GTK+ 
objects (you should also note my suggested 
kino::gtk::embeddable_user_interface plugin API class uses native GTK+ 
widgets as parameters for this reason).

>>I personally, don't have a strong opinion about gtkmm vs. straight gtk.
>>I think Charlie has a good point regarding the user base, library
>>dependencies and all.

>>OTOH, I have stated
>>before that I don't mind adding libs as long as it does not spiral out
>>of control and provides justifiable value. I don't know the popularity
>>of gtkmm; it seems to be gaining. I honestly do not have enough of a
>>software engineering and object oriented design background to really
>>appreciate what value gtkmm and libsig++ can bring to the table, but I
>>would love to learn more and take that approach.

> Well, adoption of these kind of things follows applications - so, even
> if only kino adopts it and kino becomes a regular fixture on distros,
> then the issue goes away :-). To save me searching the web, does anybody
> know of any popular/good/brilliant/jaw dropping gtkmm applications?

There's a list of apps at http://gtkmm.sourceforge.net/extra.shtml - 
Ardour (the hard disk audio recorder) and Terraform (fractal terrain 
generation) are standouts to me, personally.  You can also add a 
portable computing application under development by yours truly :)

Cheers,
Tim

On Fri, 2002-10-25 at 10:15, Timothy M. Shead wrote:
> Charles Yates wrote:
> > Well, the overwhelming feeling I'm getting here is that a migration to
> > GTK2 is the common concensus. 
> 
> Getting tough to tell the players without a scorecard ... :)

True :-) - looking back on the thread I see that we have a split vote.
Correct me if I'm wrong, but it looks as though Dan and Alvaro are
voting for GTK2, you and Bill are going for gtkmm and I'm sitting on the
fence right now (though swinging between GTK+ and GTK2) :-). 

> Yes - you may or may not have noticed that I'm using gtkmm for timfx, 
> but the bottom-line is that gtkmm is still GTK+ at heart - there are 
> accessor methods in all the gtkmm widgets to get at the "native" GTK+ 
> objects (you should also note my suggested 
> kino::gtk::embeddable_user_interface plugin API class uses native GTK+ 
> widgets as parameters for this reason).

Yep. Question is, how well would this co-exist in a GTK2 application?
Presumably there would be issues, right?

> There's a list of apps at http://gtkmm.sourceforge.net/extra.shtml - 
> Ardour (the hard disk audio recorder) and Terraform (fractal terrain 
> generation) are standouts to me, personally.  You can also add a 
> portable computing application under development by yours truly :)

Heh. Thanks for the feedback.

Cheers,

Charlie

Charles Yates wrote:
> On Fri, 2002-10-25 at 10:15, Timothy M. Shead wrote:
> 
>>Charles Yates wrote:
>>
>>>Well, the overwhelming feeling I'm getting here is that a migration to
>>>GTK2 is the common concensus. 
>>
>>Getting tough to tell the players without a scorecard ... :)
> 
> 
> True :-) - looking back on the thread I see that we have a split vote.
> Correct me if I'm wrong, but it looks as though Dan and Alvaro are
> voting for GTK2, you and Bill are going for gtkmm and I'm sitting on the
> fence right now (though swinging between GTK+ and GTK2) :-). 

I'm going to have to demand a recount, as I thought I detected a hanging 
chard for gtkmm on Dan's ballot ... ;)  As far as GTK+ vs. GTK2, I'm 
pretty indifferent.  If the gang goes with GTK2 then Kino will become my 
incentive to install it!

>>Yes - you may or may not have noticed that I'm using gtkmm for timfx, 
>>but the bottom-line is that gtkmm is still GTK+ at heart - there are 
>>accessor methods in all the gtkmm widgets to get at the "native" GTK+ 
>>objects (you should also note my suggested 
>>kino::gtk::embeddable_user_interface plugin API class uses native GTK+ 
>>widgets as parameters for this reason).
> 
> 
> Yep. Question is, how well would this co-exist in a GTK2 application?
> Presumably there would be issues, right?

Uh, based on our existing experience (timfx gtkmm plugins within a GTK+ 
app), I'd suggest the opposite - seems to work surprisingly well.  My 
point above was that adopting gtkmm for the Kino application wouldn't 
prevent the opposite - plugin authors who prefer "native" GTK+ or Glade 
... though why I can't imagine - we *are* giving them a stiff dose of 
that good 'ole OO medicine with the version 2 API :)

Cheers,
Tim

On Fri, 2002-10-25 at 10:48, Timothy M. Shead wrote:
> I'm going to have to demand a recount, as I thought I detected a hanging 
> chard for gtkmm on Dan's ballot ... ;)  As far as GTK+ vs. GTK2, I'm 
> pretty indifferent.  If the gang goes with GTK2 then Kino will become my 
> incentive to install it!

LOL - Jason has yet to vote too...

> Uh, based on our existing experience (timfx gtkmm plugins within a GTK+ 
> app), I'd suggest the opposite - seems to work surprisingly well.  My 
> point above was that adopting gtkmm for the Kino application wouldn't 
> prevent the opposite - plugin authors who prefer "native" GTK+ or Glade 
> ... though why I can't imagine - we *are* giving them a stiff dose of 
> that good 'ole OO medicine with the version 2 API :)

Well, gtkmm is based on gtk+ right? So it would surprise me if gtkmm
WOULDN'T co-exist in a gtk+ application. I don't see that as proof of
whether a gtk+ based gtkmm will co-exist in a gtk2 application, or
whether a gtk+ plug-in will co-exist with gtk2... or am I missing
something about the architecture here?

Cheers,

Charlie

On Fri, 2002-10-25 at 09:07, Dan Dennedy wrote:
> On Fri, 2002-10-25 at 02:52, Charles Yates wrote:
> > audio or the dv encoded data. (We really need to abstract the Frame
> > class btw - what we need is a Frame interface and DvFrame/MjpegFrame etc
> 
> How would this work in a pluggable framework? Does this fall into a
> dynamic casting scenario similar to FX API 2? The plugin implements
> DVFrame, and it gets casted into an abstract Frame object?

Well, what I was thinking of was something along the lines of the
following heirarchy. It's mostly designed to be plug-in friendly (ie: in
theory, you should be able to introduce new file types externally from
the core application).

I will point our that some of this overlaps and pulls in a slightly
different direction to Tim's classes and interfaces - I'm using these as
they're easier for me to explain (Tim, could you post your docs on the
new plug-in so we can compare and constrast the two approaches?):

// Colour space enumeration
typedef enum { RGB24, RGB565, YUV422, YUV420, HSV, etc } ColourSpace;

// This is a concrete class which you need to define before you can 
// extract an image.
class UncompressedImage
{
   public:
     // Required parameters which are fixed and specified up front
     UncompressedImage( ColourSpace colour, int width, int height );
     // These methods are used to extract and populate the image
     uint8_t *GetImage( );
     int GetWidth( );
     int GetHeight( );
     int GetSize( );
     ColourSpace GetColourSpace( );
     // Utility function
     void Convert( UncompressedImage &output );
};

// This is a concrete class which you need to define before you can 
// extract audio.
class UncompressedAudio
{
   public:
     // Required parameters which are fixed and specified up front
     UncompressedAudio( int frequency, int channels, int sample_size );
     // These methods are used to extract and populate the audio
     int16_t *GetAudio( );
     int GetNumberOfSamples( );
     int GetFrequency( );
     int GetChannels( );
     int GetSampleSize( );
     // Utilility function
     void Convert( UncompressedAudio &output );
};

// This interface provides all information about a video frame and 
// provides the extraction mechanism
class VideoInfo
{
  public:
    virtual int GetWidth( ) = 0;
    virtual int GetHeight( ) = 0;
    virtual bool IsPAL( ) = 0;
    virtual bool IsWide( ) = 0;
    virtual bool Provides( ColourSpace ) = 0;
    virtual bool Extract( UncompressedImage & ) = 0;
};

// This interface provides all information about an audio frame and 
// provides the extraction mechanism
class AudioInfo
{
  public:
    virtual int GetFrequency( ) = 0;
    virtual int GetChannels( ) = 0;
    virtual int GetSampleSize( ) = 0;
    virtual int GetNumberOfSamples( ) = 0;
    virtual bool Extract( UncompressedAudio & ) = 0;
};

// This class provides the compression data and functionality
class CompressionInfo
{
  public:
    virtual uint8_t *GetData( ) = 0;
    virtual int GetSize( ) = 0;
    virtual bool Encode( UncompressedImage &, UncompressedAudio & ) = 0;
    virtual bool Encode( UncompressedImage & ) = 0;
    virtual bool Encode( UncompressedAudio & ) = 0;
};

// The frame interface itself is an abstract factory which provides a
// frame instance and concrete implementations of the VideoInfo,
// AudioInfo and CompressionInfo interfaces as they relate to the 
// physical frame extracted from a file handler
class Frame 
{
  public:
    virtual static Frame &GetFrame( ) = 0;
    virtual VideoInfo &GetVideoInfo( ) = 0;
    virtual AudioInfo &GetAudioInfo( ) = 0;
    virtual CompressionInfo &GetCompressionInfo( ) = 0;
    virtual void DoneWithFrame( );
};

// The base file handler
class FileHandler
{
  public:
    virtual bool Open( string ) = 0;
    virtual bool Create( string ) = 0;
    virtual Frame &Get( int ) = 0;
    virtual bool Put( Frame & ) = 0;
    virtual int GetSize( ) = 0;
    virtual bool Close( ) = 0;
};

// Factory method for opening a file
FileHandler &OpenFileHandler( string filename );

// file type enumeration for creation (OK - this is not plug-in
// friendly... we need to be able to register file types at 
// run-time...).
typedef enum { DVAVI1, DVAVI2, RAWDV, MJPEG, etc } FileType;

// Factory method creating a file
FileHandler &CreateFileHandler( string filename, FileType type );

Now, assuming that we have concrete implementations of:

* DvFrame, DvVideoInfo, DvAudioInfo, DvCompressionInfo
* MjpegFrame, MjpegVideoInfo, MjpegAudioInfo, MjpegCompressionInfo

and the filehandlers:

* Avi1FileHandler
* Avi2FileHandler
* RawDvFileHandler
* MjpegFileHandler

regardless of the input, the following code would be valid:

// Open a file
FileHandler &handler = GetOpenFileHandler( "afile.avi" );

// Get the first frame
Frame &frame = handler.Get( 0 );

// Get the video info of the frame
VideoInfo &info = frame.GetVideoInfo( );

// Define an uncompressed image
UncompressedImage image( RGB24, info.GetWidth(), info.GetHeight() );

// Extract the image
frame.GetVideoInfo( ).Extract( image ); 

// Convert this image to something else
UncompressedImage other( YUV422, image.GetWidth(), image.GetHeight() );
image.Convert( other );
etc

// Say that we're done with this frame
frame.DoneWithFrame( );

// Close the file
handler.Close();

Now let's go a bit further and say that we have a PNG or GIF file
handler and frame objects. This can be inserted into the system without
problems (though they will have a zero length audio). The converse is
true for WAV or other audio formats - no image, but audio.

OK - very rough, but something along those lines anyway... If you want,
I could implement a couple of these as a proof of concept (but I would
imagine that Tim would want me to adopt his UncompressedImage and
UncompressedAudio classes - Tim, could you give me a hand here?).

Cheers,

Charlie

Heh - kind of forgot to answer the original question.

Nope, no dynamic casting is required - when we're dealing with images
and audio, strictly speaking, we don't need to know the physical
implementation. 

To convert from an unknown format to a known one we would need to do
something like this (following assumes that we want to output a PAL DV
frame).

Frame &ConvertToPALDvFrame( Frame &frame )
{
    // Get the video and audio info of the frame
    VideoInfo &video = frame.GetVideoInfo( );
    AudioInfo &audio = frame.GetAudioInfo( );

    // Define an uncompressed image and sound
    UncompressedImage image( YUV422, 720, 576 );
    UncompressedAudio sound( 48000, 2, 2 );

    // Extract the image and sound
    video.Extract( image ); 
    audio.Extract( sound ); 

    // Obtain a DV frame
    Frame dv_frame = DvFrame.GetFrame( );

    // Re-encode
    dv_frame.GetCompressionInfo().encode( image, sound );

    // Return the converted frame
    return dv_frame;
}

Obviously this isn't code we'd use, but it kind of demonstrates how
things would work.

As for how this would apply to a lazy evaluation of a video/audio from
the PlayList - well, the playlist GetFrame method needn't return the
filehandlers Frame object directly... it can return a Frame object which
holds a reference to the file handlers frame, and overrides the returned
objects from the GetVideoInfo, GetAudioInfo and GetCompressionInfo
methods (and of course, if no FX are applied, the application would have
access to the original frame, but this would be entirely transparent).

Hope that clarifies what I'm meaning here (and apologies for moving so
far away from the original intention of this thread....).

Cheers,

Charlie

Quoting Charles Yates <charles.yates@...>:

> On Fri, 2002-10-25 at 10:15, Timothy M. Shead wrote:
> > Charles Yates wrote:
> > > Well, the overwhelming feeling I'm getting here is that a migration to
> > > GTK2 is the common concensus. 
> > 
> > Getting tough to tell the players without a scorecard ... :)
> 
> True :-) - looking back on the thread I see that we have a split vote.
> Correct me if I'm wrong, but it looks as though Dan and Alvaro are
> voting for GTK2, you and Bill are going for gtkmm and I'm sitting on the
> fence right now (though swinging between GTK+ and GTK2) :-). 
> 

Thanks for the mention!  I hope I'll be able to contribute code.  Since I'm
learning more java right now than C I'm hopeing that gtkmm might make it easier
for someone who is familear with java to program.

> > Yes - you may or may not have noticed that I'm using gtkmm for timfx, 
> > but the bottom-line is that gtkmm is still GTK+ at heart - there are 
> > accessor methods in all the gtkmm widgets to get at the "native" GTK+ 
> > objects (you should also note my suggested 
> > kino::gtk::embeddable_user_interface plugin API class uses native GTK+ 
> > widgets as parameters for this reason).
> 



-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

On Fri, Oct 25, 2002 at 11:16:35AM +0200, Charles Yates wrote:
> On Fri, 2002-10-25 at 10:48, Timothy M. Shead wrote:
> > I'm going to have to demand a recount, as I thought I detected a hanging 
> > chard for gtkmm on Dan's ballot ... ;)  As far as GTK+ vs. GTK2, I'm 
> > pretty indifferent.  If the gang goes with GTK2 then Kino will become my 
> > incentive to install it!
> 
> LOL - Jason has yet to vote too...
> 
> > Uh, based on our existing experience (timfx gtkmm plugins within a GTK+ 
> > app), I'd suggest the opposite - seems to work surprisingly well.  My 
> > point above was that adopting gtkmm for the Kino application wouldn't 
> > prevent the opposite - plugin authors who prefer "native" GTK+ or Glade 
> > ... though why I can't imagine - we *are* giving them a stiff dose of 
> > that good 'ole OO medicine with the version 2 API :)
> 
> Well, gtkmm is based on gtk+ right? So it would surprise me if gtkmm
> WOULDN'T co-exist in a gtk+ application. I don't see that as proof of
> whether a gtk+ based gtkmm will co-exist in a gtk2 application, or
> whether a gtk+ plug-in will co-exist with gtk2... or am I missing
> something about the architecture here?
> 

Anyone know where I can find the differences between gtk 1 and gtk 2?
I poked around their website but couldn't find anything.  It would help
to know exactly what is new to see if there is any real incentive to move.
If there is nothing we can't do with gtk1 than I don't see a reason to
move just yet.

Regarding gtkmm.  I spent a few minutes looking at it yesterday and I
like it.  The timeline is a pretty dynamic widget, so I am doing a lot
of widget generation/manipulation.  the C++ classes will greatly reduce
the amount of code I have.  Plus I am doing a lot of event manipulation,
which is well suited for libsigc++.  I really disklike the way I've
implemented some of the event handling so far because of this
limitation.  This will also help in making the timeline a true custom
widget.  Just think, adding just the following two lines in the Kino
GUI code to add a timeline:

Timeline *timeline_widget = new Timeline();

kino_table.attach (timeline_widget);


Thanks,
Jason

On Fri, 2002-10-25 at 12:42, The Surprises wrote:
> 
> Anyone know where I can find the differences between gtk 1 and gtk 2?

http://developer.gnome.org/doc/API/2.0/gtk/gtk-changes-2-0.html

On Fri, 2002-10-25 at 12:42, The Surprises wrote:
> Anyone know where I can find the differences between gtk 1 and gtk 2?
> I poked around their website but couldn't find anything.  It would help
> to know exactly what is new to see if there is any real incentive to move.
> If there is nothing we can't do with gtk1 than I don't see a reason to
> move just yet.

I believe the incentive is to avoid coding to a legacy toolkit!

Anyway, there was an outstanding issue about whether one can use the
canvas widget in GTK2. What I found out is that in GNOME2, the Canvas is
split out into its own lib/header so you don't need all of GNOME2. I
don't if that helps much:

http://developer.gnome.org/dotplan/porting/ar01s08.html#libgnomeui-canvas

Charles Yates wrote:

> Well, gtkmm is based on gtk+ right? So it would surprise me if gtkmm
> WOULDN'T co-exist in a gtk+ application. I don't see that as proof of
> whether a gtk+ based gtkmm will co-exist in a gtk2 application, or
> whether a gtk+ plug-in will co-exist with gtk2... or am I missing
> something about the architecture here?

OK, misunderstood the question and took some knowledge for granted.  You 
have GTK+ ---> gtkmm, and GTK2 ---> gtkmm2.  So one way of looking at 
the decision-making process is to:

Choose the toolkit - GTK+ or GTK2?
Choose to go with the native toolkit, or to go gtkmm* (the correct 
version, of course).

My assertion was that if Kino were built on either version of gtkmm, 
plugins could be written using the correct corresponding version of the 
"native" GTK*.  The reverse should continue to be true, as we've seen in 
Kino + timfx (though obviously this isn't what I'm rooting for).

Tim

On Fri, 2002-10-25 at 04:18, Charles Yates wrote:
> On Fri, 2002-10-25 at 10:15, Timothy M. Shead wrote:
> > Charles Yates wrote:
> > > Well, the overwhelming feeling I'm getting here is that a migration to
> > > GTK2 is the common concensus. 
> > 
> > Getting tough to tell the players without a scorecard ... :)
> 
> True :-) - looking back on the thread I see that we have a split vote.
> Correct me if I'm wrong, but it looks as though Dan and Alvaro are
> voting for GTK2, you and Bill are going for gtkmm and I'm sitting on the
> fence right now (though swinging between GTK+ and GTK2) :-). 
> 
I see all of the options as:
a) GTK+ 1.2/GNOME 1.4 (status quo)
b) gtkmm[/gnomemm]
c) GTK2 only
d) GTK2/GNOME2
e) gtkmm2
f) gtk2mm/gnome2mm

There are a lot of bleeding edge options, but I think d or f will be the
long term goal. So, what is the best way to get there at this point?
Right now my vote is for gtkmm/gnomemm because then we can avoid issue
with the gnome canvas. I think using gtkmm (and gnomemm?) will ease the
transition to GTK2 and eventually GNOME2.

What GNOME features are we really using? We are using the GNOME file
entry in a lot places, the timeline will use a canvas, and I believe the
file dialogs are GNOME, and, oh yeah, a simple GNOME function to open
online help. Any others?

On Fri, 2002-10-25 at 19:14, Timothy M. Shead wrote:
> OK, misunderstood the question and took some knowledge for granted.  You 
> have GTK+ ---> gtkmm, and GTK2 ---> gtkmm2.  So one way of looking at 
> the decision-making process is to:

Ah - that's what I was missing. I guess I should have checked, but I
wasn't aware that gtkmm2 was available... the fact that it is makes me
much more confident about gtkmm as a longer term solution...

Thanks for clarifying that one (.. extend that Dan whose mail arrived at
the same time as yours).

Charlie

> What GNOME features are we really using? We are using the GNOME file
> entry in a lot places, the timeline will use a canvas, and I believe the
> file dialogs are GNOME, and, oh yeah, a simple GNOME function to open
> online help. Any others?

Quite a few :-/:

* config in preferences
* icon lists in Timeline and the scene list
* color pickers in fx
* file entries in export and common
* stock pixmaps on the tool bar
* message boxes in common and FX

Charlie

On Fri, 2002-10-25 at 14:05, Charles Yates wrote:
> 
> > What GNOME features are we really using? We are using the GNOME file
> > entry in a lot places, the timeline will use a canvas, and I believe the
> > file dialogs are GNOME, and, oh yeah, a simple GNOME function to open
> > online help. Any others?
> 
> Quite a few :-/:
> 
> * config in preferences
> * icon lists in Timeline and the scene list
> * color pickers in fx
> * file entries in export and common
> * stock pixmaps on the tool bar
> * message boxes in common and FX
> 
I think dropping GNOME will add too much for us. This further
discourages a near term migration to GTK2, and further encourages my
interest in gtkmm/gnomemm to hopefully make the eventual migration
easier--from the engineering perspective it ought to, right, due to all
the properties of OO?

On Fri, 2002-10-25 at 20:58, Dan Dennedy wrote:
 
> I think dropping GNOME will add too much for us. This further
> discourages a near term migration to GTK2, and further encourages my
> interest in gtkmm/gnomemm to hopefully make the eventual migration
> easier--from the engineering perspective it ought to, right, due to all
> the properties of OO?

This seems like a sensible move - I am keen to redevelop the GUI with a
few to future maintenance (even if it means the immediate work is short
term and may not even get released...).

So I decided to test the tools and see how well they work. Installed all
the gtkmm, gnomemm and glademm stuff on my laptop. The compilation of
glademm failed due to an inconsistent use of _GNU and _GNU_SOURCE in the
standard IO header files (on rh 7.2 anyway) and after resolving that I
was able to compile and install. 

I started off by defining a simple GUI, using a vbox of 2, and I placed
an aspect frame in the first box and a drawingarea on top of that. In
the second box I placed a horizontal button box and replaced the labels
with textual representations of our transport and made sure that this
remained centered below the aspect frame using a fixed amount of space,
regardless of the containing window size. Saved and built - so far so
good.

During compilation of the generated code, it baulked on the AspectFrame
widget, and when I removed that, the generated code compiled but the
presentation was incorrect, with the horizontal buttons stretching along
the entire length of the drawing area above (even though the glade
presentation behaves correctly)...

I *really* don't want to be forced into hand generating the GUI, nor do
I want to be forced to patch the generated code :-/. 

Anyone have any suggestions here?

Cheers,

Charlie

El s=E1b, 26-10-2002 a las 11:00, Charles Yates escribi=F3:
> On Fri, 2002-10-25 at 20:58, Dan Dennedy wrote:
> =20
> > I think dropping GNOME will add too much for us. This further
> > discourages a near term migration to GTK2, and further encourages my
> > interest in gtkmm/gnomemm to hopefully make the eventual migration
> > easier--from the engineering perspective it ought to, right, due to all
> > the properties of OO?
>=20
> This seems like a sensible move - I am keen to redevelop the GUI with a
> few to future maintenance (even if it means the immediate work is short
> term and may not even get released...).
>=20
> So I decided to test the tools and see how well they work. Installed all
> the gtkmm, gnomemm and glademm stuff on my laptop. The compilation of
> glademm failed due to an inconsistent use of _GNU and _GNU_SOURCE in the
> standard IO header files (on rh 7.2 anyway) and after resolving that I
> was able to compile and install.=20
>=20
> I started off by defining a simple GUI, using a vbox of 2, and I placed
> an aspect frame in the first box and a drawingarea on top of that. In
> the second box I placed a horizontal button box and replaced the labels
> with textual representations of our transport and made sure that this
> remained centered below the aspect frame using a fixed amount of space,
> regardless of the containing window size. Saved and built - so far so
> good.
>=20
> During compilation of the generated code, it baulked on the AspectFrame
> widget, and when I removed that, the generated code compiled but the
> presentation was incorrect, with the horizontal buttons stretching along
> the entire length of the drawing area above (even though the glade
> presentation behaves correctly)...
>=20
> I *really* don't want to be forced into hand generating the GUI, nor do
> I want to be forced to patch the generated code :-/.=20
>=20
> Anyone have any suggestions here?

Is it a good idea to generate code at all?

I usually only use Glade to create the UI. The I use libglade to load
the XML file and work with the widgets using libglade to take the
widgets form the XML file.

Cheers

-- Alvaro

>=20
> Cheers,
>=20
> Charlie
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: ApacheCon, November 18-21 in
> Las Vegas (supported by COMDEX), the only Apache event to be
> fully supported by the ASF. http://www.apachecon.com
> _______________________________________________
> Kino-dev mailing list
> Kino-dev@...
> https://lists.sourceforge.net/lists/listinfo/kino-dev
>=20

On Sat, 2002-10-26 at 05:00, Charles Yates wrote:
> 
> During compilation of the generated code, it baulked on the AspectFrame
> widget, and when I removed that, the generated code compiled but the
> presentation was incorrect, with the horizontal buttons stretching along
> the entire length of the drawing area above (even though the glade
> presentation behaves correctly)...
> 
Sounds discouraging with just a simple project.

On Sat, Oct 26, 2002 at 11:00:45AM +0200, Charles Yates wrote:
> On Fri, 2002-10-25 at 20:58, Dan Dennedy wrote:
>  
> > I think dropping GNOME will add too much for us. This further
> > discourages a near term migration to GTK2, and further encourages my
> > interest in gtkmm/gnomemm to hopefully make the eventual migration
> > easier--from the engineering perspective it ought to, right, due to all
> > the properties of OO?
> 
> This seems like a sensible move - I am keen to redevelop the GUI with a
> few to future maintenance (even if it means the immediate work is short
> term and may not even get released...).
> 
> So I decided to test the tools and see how well they work. Installed all
> the gtkmm, gnomemm and glademm stuff on my laptop. The compilation of
> glademm failed due to an inconsistent use of _GNU and _GNU_SOURCE in the
> standard IO header files (on rh 7.2 anyway) and after resolving that I
> was able to compile and install. 
> 
> I started off by defining a simple GUI, using a vbox of 2, and I placed
> an aspect frame in the first box and a drawingarea on top of that. In
> the second box I placed a horizontal button box and replaced the labels
> with textual representations of our transport and made sure that this
> remained centered below the aspect frame using a fixed amount of space,
> regardless of the containing window size. Saved and built - so far so
> good.
> 
> During compilation of the generated code, it baulked on the AspectFrame
> widget, and when I removed that, the generated code compiled but the
> presentation was incorrect, with the horizontal buttons stretching along
> the entire length of the drawing area above (even though the glade
> presentation behaves correctly)...
> 
> I *really* don't want to be forced into hand generating the GUI, nor do
> I want to be forced to patch the generated code :-/. 
> 
> Anyone have any suggestions here?

I also started playing around with it.  I got the same compile problem
for glademm, but other than that, all seems to be well.  I tried some
simple gui stuff through glade and it all worked well.   I decided to go
for it, and run the timeline glade project through glademm as well.  It
worked without a hitch.

Thanks,
Jason

On Sun, 2002-10-27 at 02:40, The Surprises wrote:
> I also started playing around with it.  I got the same compile problem
> for glademm, but other than that, all seems to be well.  I tried some
> simple gui stuff through glade and it all worked well.   I decided to go
> for it, and run the timeline glade project through glademm as well.  It
> worked without a hitch.

Well, that's interesting, but your use of glade is far simpler than the
current kino project. The same test does not apply there with errors
being reported during the build step - amongst them: unkown widget types
for GnomeFileEntry and GnomeIconList...

There is a libglademm project, and I'll have a quick look into this...

Cheers,

Charlie

On Sun, 2002-10-27 at 08:37, Charles Yates wrote:
> There is a libglademm project, and I'll have a quick look into this...

Hmmm... interesting. 

The default configure failed on gtkmm test (testing for > 1.2 with
1.2.10 installed fails...). Reconfigured with --disable-gtkmmtest and
Makfiles were built.

Make failed on the build of xml_test and xml_test_gnome due to a missing
include path to gnome-1.0 header files. After adding that, compilation
succeeded I could run the test programs. xml_test_gtk reports a failure
on 'my_custom_label' (not looked into why but not too concerned about
that) and xml_test_gnome worked fine.

For the next test, I copied over my test case project (complete with
AspectRatio frame) onto the myinterface.glade and
myinterface-gnome.glade files and re-ran the tests. Presentation was
correct in both cases (not using any gnome widgets here).

I then tried copying over kino.glade on the myinterface-gnome.glade.
This presented most of the windows defined there, reported a whole heap
of unconnected signals and finally seg faulted before the main window
was fully rendered.

After removing all the signal elements, this test sort of worked - all
the windows where presented sort of correctly, except the tool bar which
showed the text of the icons. I may have been a bit over zealous in the
removal of the signals as the menu and tab control were inactive.

Adding a variety of gnome widgets and tab controls to my original test
case and they all worked out fine though there were some minor anomalies
in the glade and libglademm presentation - button widgets with a relief
of none where presented as normal for example. This is obviously not a
major issue in itself, but it makes a bit wary as it suggests that other
issues will crop up from time to time.

Well, this is an improvement, but now I have a bunch of new stuff to
learn :-/ - I need to work out how we build our custom widgets, how to
attach those where we need them and how signals are attached within the
gtkmm/glademm environment...

But going back to the beginning here, the initial compilation issues
with glademm make me a little nervous about pushing this into our
environment. I will start harranging the libglademm and glademm people
about these issues... 

As I stated up front, the prospect of having to hand code the
presentation is one which I simply don't want to be forced into, esp. as
I (still) feel that a GTK+/glade environment is still an option for
short term implementation/longer term design.

Cheers,

Charlie