Re: Idea for backend maintainers: "reversal of roles"

At 11:41 +0100 01/03/2003, Magnus Lie Hetland wrote:
>Hellen Claggett <[email protected]>:
>>
>[snip]
>>
>> I'd just like to second this idea! Personally, I'd like to see a
>> published anygui API hit version 0.2 final with only a single reference
>> backend and then see the various other backends developed to support the
>> API after the 'official' release.
>
>Hm. This *is* an interesting idea -- and it might even make the
>project more viable. The prolification of back-ends in the
>distribution is one of the major issues holding back a release, as
>they must all be de-bugged, tested and the like.

I've been in a similar situation for years - OOFILE is a database API with
a range of front-ends (above the database API is a report-writer, graphing
engine, XML parsing and forms engine on Mac and Windows) and backends (two
simple streaming backends, our own dBase-compatible which counts as two
because it does dBase III+ and IV format, and the professional c-tree Plus
backend which can count as about 3 minimal variations and blow out to about
12 given the mix of single/multi-user/client-server and other options).

I've been a believer in regression testing since I first encountered it as
a VMS sysadmin installing DEC packages in 1985 and OOFILE's had it since
day one and it HAS helped but is an expensive help.

Manual, even partly-automated, regression testing doesn't really help small
teams with this kind of problem (the OOFILE nearest equivalent to anygui
issues would probably be the report writer) because the eyeball time is
excessive and judgement as to whether something like an embedded graph
drawn in Word after rendering to RTF correctly matches a laser printout
from Mac is highly subjective :-(

I suspect that partly-automated regression testing CAN help if you have a
big enough fan-out of users and an issue tracking system which
a) obviously has minimal barrier to people posting issues

b) makes it easy for them to find existing postings of a similar problem so
they can describe their experience as annotation to that report

c) allows the developers to search flexibly so they can correlate reports
to different areas of code and prioritise fixes

d) gives them a range of examples sufficient for them to easily compare
their problems against an expected result (I can't emphasize this too
highly - if you're feeling paranoid about how your use of 7 text fields and
a listbox in a tabbed layout looks, being able too see expected snapshots
on two different platforms of something similar gives people a lot of
confidence and the boost to report problems in a usefully detailed manner).

In the last couple of years I've had the chance to work heavily with
cppunit in particular using it on a project which included some heavily
graphical work, under the direction of a CTO who'd used it before for
graphics. It opened my eyes as to the level of comparison that can be
automated.

>I think a natural choice for a "standard" back-end...would be tkgui
Agreed.

>Actually finishing 0.2 with a solid and _simple_ tkgui
>(for example) might help.

Hugely.

You desperately need at least one believably complex range of examples so
people can make their minds up in 30 seconds that it is possible to use
anygui for their project.

The next strategic step is picking the backend with the MOST DIFFERENT
architecture to the first and smothering it with a blanket of examples.
That proves the core "anygui" nature.

>Then the various toolkits could get "Anygui certified" if they wanted to
>get in
>on the fun...
Yes, this is a very good long-term goal.
Your range of examples has to be good enough to make people's GUI's look
good if certification is to mean anything.

>BTW: I've been thinking about generating API docs with epydoc
>(epydoc.sf.net).

This desperately needs automating like Doxygen. If epydoc is similar, use it.


>I believe that a solid, up-to-date API
>documentation is sorely needed...
For years, OOFILE had moderate API docs and only an excellent range of
examples - some people particularly like the annotated ones
<http://www.oofile.com.au/oofdoc/features.htm>

Then I got heavily into Doxygen.
<http://www.oofile.com.au/oofile_ref/html/index.html>

There are two types of user - "gimme a reference manual" and "for XX sake
show me how to do it with examples" and sometimes we shift between camps.

You need to satisfy both.

I don't know how to not make this painful but for something as
architecturally complex as anygui I don't think it is possible to succeed
without satisfying both camps of potential users and giving people
confidence with a range of working stuff that demonstrates you really can
deliver.

The core idea of anygui is "just working" on top of a range of backend GUI's.

You will get a few subscribers to the project but until people can see
enough online to believe in that core idea, you're sitting in Catch22-land.
Anygui is a great idea and has received some good press but is big enough
to need proving for most folks.
-- 
Andy Dent BSc  MACS  AACM   http://www.oofile.com.au/
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf