zoolib-dev — Development list for the ZooLib cross-platform application framework

[ZooLib-dev] Mac CW Pro 6.1 compile errors

[Austin S. <aus...@pa...>]

Hi folks,

[I guess there's not a lot of traffic on this list - yet...]

I'd like to also chime in with Andreas Kaenner's note (11/28/2000 Problems
to compile ZHelloWorld with CodeWarrior). I downloaded 8.1 of ZooLib and got
18 many compilation errors for the Macintosh PPC targets using CodeWarrior
6.1 on my G3 iBook running Mac OS 9.0.4. I'll be looking into these (as time
permits!) but would appreciate any help in the meantime:

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 251   if (fRep == nil || fRep->GetRefCount() > 1)

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 270   else if (fRep == nil || CheckFormat(fRep->fFormat,
ZCONFIG_API_Graphics_QD))

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 1152   else if (fRep == nil || CheckFormat(fRep->fFormat,
ZCONFIG_API_Graphics_QD))

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 1500   if (fRep == nil || (hInset == 0 && vInset == 0))

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 1505   else if (fRep == nil || CheckFormat(fRep->fFormat,
ZCONFIG_API_Graphics_QD))

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 1717   if (fRep == nil)

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 1756   if (fRep == nil)

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 1925   else if (fRep == nil)

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 1927   else if (inOther.fRep == nil)

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 2058   if (fRep == nil)

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 2279   if (fRep == nil)

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 2313   if (inOther.fRep == nil)

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCRgn::Rep>::operator==(const ZRef<ZDCRgn::Rep> &)const '
'ZRef<ZDCRgn::Rep>::operator==(const void *)const '
'ZRef<ZDCRgn::Rep>::operator==(int)const '
ZDCRgn.cpp line 2379   if (fRep == nil)

Error   : out of registers for local variable @3686
Try using optimization level 1 or greater
ZDCPixmap.cpp line 885   }

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZDCInk::Rep>::operator==(const ZRef<ZDCInk::Rep> &)const '
'ZRef<ZDCInk::Rep>::operator==(const void *)const '
'ZRef<ZDCInk::Rep>::operator==(int)const '
ZDCInk.cpp line 246   if (fRep == nil || inOther.fRep == nil)

Error   : function call 'ZDCSetupForQD(ZUITextEngine::DC_Host, bool)' does
not match
'ZDCSetupForQD::ZDCSetupForQD(ZDC &, bool)'
'ZDCSetupForQD::ZDCSetupForQD(const ZDCSetupForQD &)'
ZUITextEngine_Mac.cpp line 69   :
fSetupForQD(ZUITextEngine::DC_Host(inTextEngine), false),

Error   : ambiguous access to overloaded function
'operator!=(int, long)'
'ZRef<ZUIFactory>::operator!=(const ZRef<ZUIFactory> &)const '
'ZRef<ZUIFactory>::operator!=(const void *)const '
'ZRef<ZUIFactory>::operator!=(int)const '
ZUIFactory.cpp line 52   ((2)<=2 && !(sUIFactory != 0L) ?
ZDebug_DisplayMessage(2, eDebugAction_Stop, "ZUIFactory.cpp", 52,
"sUIFactory != nil",

Error   : ambiguous access to overloaded function
'operator==(int, long)'
'ZRef<ZUICaption>::operator==(const ZRef<ZUICaption> &)const '
'ZRef<ZUICaption>::operator==(const void *)const '
'ZRef<ZUICaption>::operator==(int)const '
ZUIRenderer_Platinum.cpp line 1300   sRenderPopup(inDC, inButtonRect,
inState, inCaption == nil || !inCaption->IsValid(), false);








****************************************************************************
Austin Shelton
<mailto:aus...@pa...>
<http://austinshelton.homepage.com/> 

[ZooLib-dev] ZooLib updated on Freshmeat

[Michael D. C. <cra...@go...>]

Freshmeat II, http://freshmeat.net , was launched a few days ago with 
lots of whizzy new features, most importantly more detailed categories 
and the ability to track multiple branches of a project, and also have 
extra items of information like mailing lists and Zip files.

Awaiting freshmeat staff approval (so it'll be a day or two before my 
changes are
visible), I've updated

http://freshmeat.net/projects/zoolib/

With the following items:

- Added multiple categories for ZooLib and successfully lobbied the Freshmeat staff 
to add "application frameworks" as a new category.  Now someone searching for 
software to suit a particular purpose will be more likely to find ZooLib (as 
opposed to specifically doing a name search for "ZooLib").

- I added a "demos" branch and issued a 1.0.1 release for it

This is for the demo source - not sure if I want to add the demo binaries as
a separate branch, as each of the individual programs is a separate download.  Anyone
who visits the sourceforge pages will see the demo binaries anyway.

(*** HEY YOU! *** Wanna write some more demos?  They'd be really helpful!  They
don't have to be big, actually smaller ones are usually better!)

- Updated the main description to point out that the demo source is needed for
building the whole thing

Lots of people were grabbing just the main sources and then not being able to build.

- Issued a 0.8.1 release.  I should have done this on Freshmeat a long time ago as
Andy updated the sources on SourceForge soon after I released 0.8, but my life has
been quite topsy turvy.  Anyone looking at the sourceforge page would have found
0.8.1, but if someone just grabbed the .tgz file directly off of Freshmeat's link
they would have got obsolete code

In the 0.8.1 change notes I acknowledged the known problems of building on xBSD,
MS Visual C++, and BeOS PowerPC with the promise we're working on it.

Note that my life is showing promise of returning to some semblance of normality
now that I'm actually living in the house I bought a few months ago.  And in fact 
I'll be getting a new hard disk for my PC in the next few weeks, and will
be running both a BSD on it and Intel BeOS, and I've been fiddling with BeOS PowerPC
on my Mac.

Besides making the Freshmeat information current, ZooLib should spend a brief period
on Freshmeat's front page which should cause a small spike of interest.

It's possible to correct the content of a release without causing a re-release of
the project to appear on Freshmeat's homepage.  If you have any corrections that I
should make to our Freshmeat entries, please let me know right away and I'll fix
them.

Thine in Utter Torment,

Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
cra...@go...

   Tilting at Windmills for a Better Tomorrow.

Re: [ZooLib-dev] Quick tips on DocBook

[David J. <da...@us...>]

On Monday 05 February 2001 05:24 pm, Michael D. Crawford wrote:

> But check out:
>
> http://www.linuxdoc.org/LDP/LDP-Author-Guide/
>
> The Linux Documentation Project has settled on DocBook as its standard
> format as we have, but helpfully they've also figured out the tools and
> have provided a pretty clear HOWTO on how to write HOWTO's.

Also check out the FreeBSD Documentation Project. It has a nice user guide, 
and hints on using Jade. Although parts of it are FreeBSD specific, there is 
a lot of good info in it. Check it out at 
http://www.FreeBSD.org/tutorials/docproj-primer/

--
David Johnson
___________________
http://www.usermode.org

[ZooLib-dev] Quick tips on DocBook

[Michael D. C. <cra...@go...>]

Greetings from wintry Maine!

I was going to write a much longer mail but frequent power outages due to
tonight's blizzard have been impeding progress.

When reliable power is restored, I think I'll at last be able to make a serious
go of writing some ZooLib manuals in DocBook.  I like to write, but I've had no
luck with DocBook so far.  Real Soon Now, I promise.

But check out:

http://www.linuxdoc.org/LDP/LDP-Author-Guide/

The Linux Documentation Project has settled on DocBook as its standard format as
we have, but helpfully they've also figured out the tools and have provided a
pretty clear HOWTO on how to write HOWTO's.  

I think if one doesn't have the cash for Frame+SGML then Emacs with psgml is the
best bet:

http://www.lysator.liu.se/~lenst/about_psgml/

I installed psgml in my emacs and it seems to work with the little test given in
the LDP HOWTO.

Note that Emacs will run on many platforms and psgml is written in emacs lisp,
so you could use it in Windows, for example.

The LDP also says how to use Jade or OpenJade to translate one's DocBook to
HTML.  I found OpenJade's webpage pretty perplexing.  You need to get a lot of
stuff set up just right before anything works.

One might be able to get OpenJade to work on Windows with CygWin, a GNU/Unix
emulation for Win32.

Andy's been able to get a program called "db2html" working but this is
apparently not universally provided with Linux distributions.

Finally see:

http://freshmeat.net/projects/treenotes/

and

http://alphaworks.ibm.com/tech/xeena

which are two Java XML editors.  Treenotes is available as open source under the
BSD license.  Being Java, you can run them on almost any platform, but I found
that Xeena wasn't really robust enough to edit something with a DTD as complex
as DocBook's.  Partially it was slow and partially the UI was confusing when I
had dozens of elements I could choose from in a given context.

Finally, I'd like to recommend that if you're going to write ZooLib
documentation, you should choose the XML DocBook DTD rather than the SGML DTD. 
Both forms are still available and supported, but if you use XML DocBook we can
run our manuals through all manner of XML tools.  There's a lot more work being
done these days for XML than there is for the more general SGML.  The actual
differences in practice between the two DTD's are quite minor.

-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com/
cra...@go...

   Tilting at Windmills for a Better Tomorrow.

Re: [ZooLib-dev] compiling in win32

[Andrew G. <ag...@em...>]

> i do not have CodeWarrior.
> i've tried to compile the ZHelloWorld app with Visual C++ and BC++,
> but i didn't how to start.
> i've also tried with cygwin gnu c++.
>
> can anyone explain me how to compile the example with any of these
> compilers?

The source as posted on sourceforge does _not_ build with Visual C++, but
I'm close to wrapping a new release that will (amongst other changes) build
with Visual C++.
As far as BC++ goes, I'll need some help to get zoolib building there. It
should have fewer problems than VC++, being a somewhat more comliant
compiler, but I don't use it and thus can't do the porting work myself.

gcc should actually be the least problematic as far as source compatibility
goes, provided you're using gcc 2.95 or later. ZoolIb has built with gcc
2.7.x in the past, but there's at least some template code that will likely
not build successfully and I don't plan to backport to 2.7.x.

A
__________________________________________________________________
Andrew Green                                  mailto:ag...@zo...
ZooLib Guy                                   http://www.zoolib.org
350 25th Avenue, Suite #1                   Vox: +1 (415) 831 2471
San Francisco, CA 94121-1912                Fax: +1 (415) 831 2472

[ZooLib-dev] compiling in win32

[David P. <dav...@ep...>]

i do not have CodeWarrior.
i've tried to compile the ZHelloWorld app with Visual C++ and BC++,
but i didn't how to start.
i've also tried with cygwin gnu c++.

can anyone explain me how to compile the example with any of these
compilers?

thank you.
David.

Re: [ZooLib-dev] Compilation error on BeOS

[Andrew G. <ag...@em...>]

> /boot/.../ZString.cpp: In function `static class string  
> ZString::sFromStrResource(short int)':
> /boot/.../ZString.cpp:259: aggregate `struct app_info info' has
> incomplete type and cannot be initialized
> /boot/.../ZString.cpp:260: confused by earlier errors, bailing out
> make: *** [ZString.o] Error 1
>
> Any ideas?!

AndreasKaenner posted a message to the zoolib forum on SourceForge with the
following mods for BeOS compilation:

I had some problems to compile the helloworld example. Here are my fixes:

ZDCRgn.cpp --> line 685:
virtual ~FakeBRegion() = 0;

ZUIUtil.cpp --> insert before line 46:
#include <app/Roster.h>

ZString.cpp --> insert before line 246:
#include <app/Roster.h>

Although we checked the demo apps under the various OSes, It's clearly the
case that we never built under BeOS 5.0.

When I'm working on the core library features it's a massive timesaver for
me to have just a single copy of the source that's accessible from all my
build machines -- I can make a change to implement or fix a feature for one
OS, and trigger a build on all the others to be sure that I didn't break
something elsewhere. I keep a single copy of the zoolib source on a linux
server running netatalk, samba and NFS. netatalk provides access from my
MacOS machine, samba does the same for Windows and NFS lets me access the
source from BeOS 4.5. Unfortunately, and I have reported this to Be on
several occasions, under BeOS 5.0 neither Andreas Huber's NFS filesystem
driver nor the SMB support that ships as part of BeOS 5.0 work for gcc's
purposes. So for BeOS I still run 4.5, and thus didn't catch these 4.5/5.0
problems. Sorry.


> And then another question. I plan to use zoolib for a graphics
> intensive app mainly for BeOS and Windoze. Does anyone have experiance
> with
> zoolibs graphic speed (lines, polygones, circles...).

It all depends on what you're doing. For example, ZooLib lets you have
multiple ZDC's that all reference the same destination, but maintain
different origins, inks, clip regions etc. If you plot a pixel through one
ZDC, then plot a pixel through another, then go back to the first, the vast
majority of the CPU's effort will be expended in pushing state values from
the ZDCs into the native port. But if you set up a ZDC, then make several
calls to fill shapes, the port will be configured only when the first call
is made, and the overhead of subsequent calls comprises a virtual method
dispatch, the comparison of a few change counts, and some math to convert
coordinates; the vast majority of the time will be spent by the native code
writing pixels to the port and the overhead will be unnoticeable.

What's likely to be most important in real code is actually how one goes
about building up an image. For example, I had a 16 by 16 palette of color
chips in a menu implemented with ZooLib. Under BeOS on my laptop I could
*see* the chips ripple into the menu, but a similar menu implemented by
another BeOS app just appeared instantaneously. Obviously this bothered me,
so I wrote a purely native version. It *also* rippled onto the screen. I
went back and forward on this with Benoit at Be -- my native code was taking
450ms, the ZooLib code was taking roughly the same. When I simplified the
code to *not* draw a one pixel frame around each of the 256 color chips my
time dropped to 60ms. But on his machine it was taking 2ms. Clearly the
problem was my laptop's graphics driver -- the frames were being drawn by
BeOS making four additional calls to the graphics driver's fill rect
operation, and that operation was just slow (go figure). The similar looking
palette from another BeOS app appeared instantaneously because it was being
blitted from offscreen. The performance problem was not in ZooLib, but in
how I'd decided to image the palette.

The upshot is that on average there's a fairly fixed overhead per call. That
overhead is not large in itself, but for very simple operations it might
make a difference in some circumstances. But it's likely that in those
circumstances the overhead of the native call itself is also significant,
and thus it would be better to have hand coded some alternate implementation
in any case.

A
__________________________________________________________________
Andrew Green                                  mailto:ag...@zo...
The ZooLib Guy                               http://www.zoolib.org
350 25th Avenue, Suite #1                   Vox: +1 (415) 831 2471
San Francisco, CA 94121-1912                Fax: +1 (415) 831 2472

[ZooLib-dev] Compilation error on BeOS

[Rainer R. <ri...@na...>]

Hi all!

I downloaded zoolib-0.8.1.tgz and zoolib-demos-1.0.1.tgz and tried to  
compile ZHelloWorld on BeOS. I finally ended up with the following error 
 
message: 
 
/boot/.../ZString.cpp: In function `static class string  
ZString::sFromStrResource(short int)': 
/boot/.../ZString.cpp:259: aggregate `struct app_info info' has  
incomplete type and cannot be initialized 
/boot/.../ZString.cpp:260: confused by earlier errors, bailing out 
make: *** [ZString.o] Error 1  
 
Any ideas?! 
 
And then another question. I plan to use zoolib for a graphics  
intensive app mainly for BeOS and Windoze. Does anyone have experiance 
with  
zoolibs graphic speed (lines, polygones, circles...). 


Rainer

[ZooLib-dev] List Newbie

[David J. <da...@us...>]

I'm new to this list (but aren't we all :-))

I just heard about ZooLib, and it's a great concept. Unfortunately, I'm a 
POSIX/X11 guy, so the lack of resources and menus is a big crimp. I'm right 
in the middle of a project, but maybe in a couple of months I'll be free 
enough to see what my limited skills could contribute...

Without wanting to pressure anyone, any word on when some API docs would be 
available?

-- 
David Johnson
___________________
http://www.usermode.org

[ZooLib-dev] Problems to compile ZHelloWorld with CodeWarrior

[Andreas K. <a.k...@me...>]

Hello,

I get the following error:

Error   : function call 'ZDCSetupForQD(ZUITextEngine::DC_Host, bool)' does
not match
'ZDCSetupForQD::ZDCSetupForQD(ZDC &, bool)'
'ZDCSetupForQD::ZDCSetupForQD(const ZDCSetupForQD &)'
ZUITextEngine_Mac.cpp line 69   : fSetupForQD(
ZUITextEngine::DC_Host(inTextEngine), false),
Project: ZHelloWorld.µ, Target: ZHelloWorld-ppc-Release, Source File:
ZUITextEngine_Mac.cpp



regarding this code:



ZUITextEngine_TextEdit::BeInPort::BeInPort(ZUITextEngine_TextEdit*
inTextEngine)
:    fSetupForQD( ZUITextEngine::DC_Host(inTextEngine), false),
    fTextEngine(inTextEngine)
    {
    ZAssert(fTextEngine);

    fOldPort = fTextEngine->fTEHandle[0]->inPort;
    RGBColor theForeColor(fTextEngine->GetTextColor());
    RGBColor theBackColor(fTextEngine->GetBackColor());
    ::PenNormal();
    ::RGBForeColor(&theForeColor);
    ::RGBBackColor(&theBackColor);
    fTextEngine->fTEHandle[0]->inPort = fSetupForQD.GetGrafPtr();
    }

Do you have any tips?

Thank you,

Andreas

[ZooLib-dev] New ZooLib file mirror

[Michael D. C. <cra...@go...>]

I've mirrored the ZooLib download files (but not yet the whole website)
at

http://www.goingware.com/zoolib

We've received reports of trouble downloading the files from sourceforge
recently.

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com
cra...@go...

  Tilting at Windmills for a Better Tomorrow.

[ZooLib-dev] First come, first served

[vio <vmi...@sy...>]

Hello Michael,

Just a word of encouragement and introduction on my part.
First, I just learned of the ZooLib project today. In my view, this promises to be BIG, BIG, BIG. Many thanks for opening it up.

Second, congrats on the great and very professional work on the ZooLib web site. I must say that I really liked your Apple story. Apple (PowerMac 6100/66) was my first "real" computer in 1995 (before that: zx80 - hope I recall the name correctly, then the mighty Commodore 64). That's where I learned that computers can also be very "religious" (the anti-MS feelings and bashing). As everybody, I had fallen in love with your company's products, believed its hype (you know, that the PPC was beating Wintel with ease). But then these rumors starting to pollute my Apple magazines, about my favorite fruit being slowly eaten alive by the very competitive Wintel.
Somewhere in 1997 I read Jim Carlton's excellent and very instructive (to a mere outside user) "Apple: the inside story of Intrigue, ...". To learn that God isn't using a one button mouse after all. To learn that it's not the best products that win market share, it's the best generals on the field. That ego is a deadly handicap on the heat of the battle. That Bonaparte had been reincarnated inside a body with a funny name: Gates.

Today, although my PowerMac isn't powered very often (if ever), it is still connected on my little home LAN with my Penguin box, which occasionally puts on the Win98 (non-Red) Hat for a Starcraft session.

I downloaded the lib and examples for my Linux box, and read "Future Directions for ZooLib" with great interest. As soon as I grasp an understanding of how the code works, and manage to make it do its deeds successfully, you can count me in for the linux side (though I can obviously also work on the Win98 and Mac 7.5 - oldie, agreed - I'm mostly at home on Linux).


Hope to start contributing useful code very soon.
Vio

[ZooLib-dev] First Post, Again!

[Michael D. C. <cra...@go...>]

Hey, is this thing on _now_?

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com
cra...@go...

  Tilting at Windmills for a Better Tomorrow.

[Zoolib-dev] First Post!

[Michael D. C. <cra...@go...>]

Hey, this thing on yet?

-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com
cra...@go...

  Tilting at Windmills for a Better Tomorrow.