Re: Tests, demos, and all that



Trog <trog@gtk.org> writes:

> On 13-Jun-2000 Owen Taylor wrote:
> > 
> >  - testgtk badly needs to be split into multiple files and cleaned
> >    up. Right up testgtk mostly is a 'demo' but has various tests
> >    embedded in it that don't really fit this model and actually
> > look
> >    like bugs.
> > 
> >    ("Foo" handlebox in the handlebox test, "Reparent Out" button in
> >    scrolled window test, etc.)
> > 
> >    I'd like to see testgtk cleaned up and made into a nice demo of
> >    GTK+. We should replace the buttons with a tree or list, (a
> >    GtkTLView test...), and add descriptions for each test.
> > 
> >    The Tk widget demo feature where each test has a button to show
> > the
> >    source code is nice too, and shouldn't be hard to implement if
> > we
> >    break up testgtk into one file per test.
> 
> 
> It would seem sensible (to me at least) to "merge" testgtk and the
> examples/* code. As most of the examples/* code is derived from
> testgtk anyway. I don't believe that would interfere with your other
> ideas. The only down side is that the code is likely to be more
> comprehensive (and complicated) than is required for the Tutorial
> (the examples/* code are the tutorial demos) but I don't think that
> will lead to any major problems.

I don't think merging them is a good idea. Many of the testgtk
examples (button-box, list, notebook) are meant to demonstrate
all, or a large subset of a widget's capabilities. On the other
hand, the tutorial examples should concentrate on showing typical
usage of the widget.

Cluttering up a tutorial example with 18 checkbuttons and 5
radiobuttons to set various options is not going to make for
clear code.

Right now, quite a bit of testgtk also has bits of bad-practice 
which were meant to test something (like the radio menu items
in the option menus.) Unfortunately, that bad practice has propagated
out to applications and (at least in some cases, perhaps fixed now), the
tutorial.

> >  - The examples/ directory doesn't get built as part of the build
> >    process and has ad-hoc Makefile's instead of automake.
> > 
> >    I guess the intention of the makefiles in there is that they can
> > be
> >    copied out somewhere else and used without modification.
> > 
> >    But I don't think that advantage outweighs the more substantial
> >    advantages of having the examples controlled by a Makefile.am:
> > 
> >    - We make sure that they continue to build
> >    - The programs can be tried out in place without installing
> >      GTK+.
> > 
> >    If we changed over the build process for the examples, we
> > probably
> >    should flatten the directory structure. From past experience
> >    (with the GIMP expecially), having a large number of
> > Makefile.am's
> >    can make the build process really crawl.
> 
> There are a couple of issues here. Those makefiles were added because
> they weren't there and I got fed up with hand compiling them.
> 
> I think makefile.am would be overkill for these examples. All the
> makefiles are extremely simple and I've never had a report of any
> problems with them across platforms.

It's not a question of cross-platform support. The examples directories
lead us to the egregious EXTRA_DIST line in the toplevel makefile, 
they don't get included in a make clean, as I said above, you can't
build them until you install GTK+. They just aren't integrated 
into the build process at all, and I think that is a bad thing.

Integrating them into the build process with anything other than
a full automake support, however, would be a mistake. It's going
to make at least as complicated and will be different from everything
else. (And you won't get all of automakes nice features like
include-file dependencies.)
 
> Flattening the directory structure to artificially add automake
> support would be a lose, IMHO. It just doesn't seem to be required.
> There may be a requirement to makefile.in (yes, thats what I meant)
> the top-level examples makefile, but I'm not sure.

What advantage do you see from the leafy structure? Almost
all the directories have only one source file in them. The maximum
number of source files is 3.

Regards,
                                        Owen




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