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

Re: [ZooLib-dev] New to ZooLib

[Dario A. <ad...@so...>]

On Tuesday, June 18, 2002, at 12:58 , Conrad Weyns wrote:

> Here are my MacCVSPro 2.5.1 PPC settings of interest for zoolib:
>
> Checkout and Update Options
>     Default Module: zoolib
>     Default Revision: (blank)
>
>
> Remote Host information
>     Server Hostname: cvs.zoolib.sourceforge.net
>     CSB Root: /cvsroot/zoolib
>
>     CVS Usaer Name: anonymous
>     CVS Password: (blank)
>     CVS Command: cvs

I have checked out the sources from CVS and imported the
PainterTest project, assigned the required source trees,
and attempted a build of the Carbon debug target on OS X
using CodeWarrior Pro 7.2, which results in:
---
Couldn=92t find compiler =93ZooLib Asset Compiler=94.
[repeated twice]

Error   : illegal token
zconfig.h line 70
[repeated a few times]

Error   : error during open of "PainterTest_Assets_en.zao"
PainterTest_Resources.r line 1   read 'ZAO_' (20000,=20
"PainterTest_Assets_en") "PainterTest_Assets_en.zao";
[repeated twice]

Error   : illegal token
zconfig.h line 70
[repeated about a hundred times]
---
Any help would be appreciated.

Thanks and ciao,
Dario

Re: [ZooLib-dev] New to ZooLib

[Conrad W. <we...@on...>]

>Hello,
>
>I would like to try out ZooLib under Mac OS X (10.1.5) using
>CodeWarrior Pro 7.2
>
>Should I get the latest sources via CVS ?
> From the Web site it's unclear whether the project is actually
>available via CVS or not.

Here are my MacCVSPro 2.5.1 PPC settings of interest for zoolib:

Checkout and Update Options
    Default Module: zoolib
    Default Revision: (blank)


Remote Host information
    Server Hostname: cvs.zoolib.sourceforge.net
    CSB Root: /cvsroot/zoolib
 
    CVS Usaer Name: anonymous
    CVS Password: (blank)
    CVS Command: cvs

No problem getting latest. (When asked for password, just hit the enter key).

>
>If I manage to compile the library and some demo application
>(preferably the PainterTest), I would like to help (if I can)
>with whatever unresolved Carbon issues there might be.

I haven't used or build it for a long time, so I can't say much more.
Cheers,
Conrad Weyns.


>
>Thank you,
>Dario
>
>
>----------------------------------------------------------------------------
>                   Bringing you mounds of caffeinated joy
>                      >>>     http://thinkgeek.com/sf    <<<
>
>_______________________________________________
>ZooLib-dev mailing list
>Zoo...@li...
>https://lists.sourceforge.net/lists/listinfo/zoolib-dev
>
>

[ZooLib-dev] New to ZooLib

[Dario A. <ad...@so...>]

Hello,

I would like to try out ZooLib under Mac OS X (10.1.5) using
CodeWarrior Pro 7.2

Should I get the latest sources via CVS ?
 From the Web site it's unclear whether the project is actually
available via CVS or not.

If I manage to compile the library and some demo application
(preferably the PainterTest), I would like to help (if I can)
with whatever unresolved Carbon issues there might be.

Thank you,
Dario

[ZooLib-dev] C++ Style at Kuro5hin

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

I wrote an article entitled "Musings on Good C++ Style" which is presently on 
the front page at http://www.kuro5hin.org/  The full article is at:

http://www.kuro5hin.org/story/2002/5/9/205040/3918

K5 is a pretty good web community, much more general in focus and more civilized 
than Slashdot.

The article discusses controlling header dependencies, memory management with 
smart pointers (the ZRef, in ZooLib's case), initializing member variables, and 
the choices of how to store and represent data and the reasons for choosing each 
one.  I also talk about optimization.

It is a very condensed version (4800 words) of my much longer piece, Pointers, 
References and Values (20000+ words) which is at

http://www.goingware.com/tips/parameters/

Best,

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

  Subscribe to the GoingWare Newsletter at http://www.goingware.com/newsletter/

     Tilting at Windmills for a Better Tomorrow.

[ZooLib-dev] Now in sourceforge CVS

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

Andy put ZooLib into SourceForge's CVS a few weeks ago actually.  But I did't 
get it together to update the CVS instructions page until just now, for which I 
apologize:

http://zoolib.sourceforge.net/doc/cvs.html

A considerable amount of work has been done on zoolib since the last official 
release.  I know a lot of work for Carbon (Mac OS X native mode with Mac OS 8.6 
& 9 compatibility) has been done.  Also Andy created a new format for storing 
resources called ZAsset.  You can do a lot more than you could with the Mac or 
Windows resources, plus ZAsset supports Linux.  There's been more than this done 
but I'm not sure what all there is.

The CVS is well worth looking at but there are likely still some loose ends so I 
don't think it's quite ready for a release.  Next time I talk to Andy I'll see 
what we can do about getting a release ready.

I will likely resume work on the ZooLib Cookbook soon.

Best,

Mike Crawford
-- 
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] ZooLib Cookbook Progress

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

I ended up doing quite a bit more work on the Cookbook today and have
posted it again:

http://www.goingware.com/zoolib/cookbook/

The chapter on ZHelloWorld is not far from finished, with a few more
things and some editing I will post it on the main website and make a
documentation release from the project's sourceforge download page.

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

     Tilting at Windmills for a Better Tomorrow.

[ZooLib-dev] Cookbook in CVS

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

I have placed the ZooLib Cookbook DocBook XML source in CVS at 
sourceforge.  Be sure to read the README file - you'll have to fiddle 
with a shell script if you want to build the DocBook yourself.  I will 
probably make this more automatic in the future.  Don't be too 
discouraged if you have trouble getting DocBook working on your system, 
most people do.

This is the first thing to go into public CVS.  There are instructions 
for accessing ZooLib's CVS now at:

http://zoolib.sourceforge.net/doc/cvs.html

and I added a link to this page from http://zoolib.sourceforge.net/ and 
the doc index page.

ZooLib's source code is not yet in sourceforge CVS.  Andy wants to put 
it there, but some work will be required to get this ready, and he's 
been swamped with work.  Also, the most active users of ZooLib, Learning 
in Motion and OISE, will need to change some of their build systems once 
this is done, to allow themselves to access ZooLib from the public 
archive while keeping their private code in their own CVS.  It's coming 
though.

I have a pointer to some ssh and cvs clients on the cvs.html page, but 
I'd like to add more if you know of any.  I'd be particularly interested 
to know if there is a way to access CVS via SSH on classic Mac OS.  It 
would work fine on Mac OS X but I'm not sure there is a way to do it on 
classic.

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

     Tilting at Windmills for a Better Tomorrow.

Re: [ZooLib-dev] ZooLib Cookbook Progress

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

> I have put what I have so far up at:
>
> http://goingware.com/zoolib/cookbook/

Very nice. I am so happy to see this. 

I don't have time right now to give it a thorough technical review, but it 
seems to have succeeded well in it's capacity as a tutorial. I can't wait for 
the next installment.

-- 
David Johnson
___________________
http://www.usermode.org
pgp public key on website

[ZooLib-dev] ZooLib Cookbook Progress

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

I am able to work on the ZooLib cookbook fairly regularly now, although 
I have not been able to put a whole lot of time into it.

Happily, I have DocBook XML working both on my Debian PowerPC macintosh 
and my Slackware pentium III laptop.  So I can take my laptop down to 
the cafe and have a latte and a bagel while writing.

I have put what I have so far up at:

http://goingware.com/zoolib/cookbook/

I have an introduction and part of a chapter on ZHelloWorld.  When I get 
the chapter on ZHelloWorld finished, I will put it up at:

http://zoolib.sourceforge.net/doc/

I would vastly appreciate your comments on what I have written so far. 
Is it well written?  I know it's probably not as organized as well as it 
could be.  Is it accurate?  Can you think of better ways to express some 
of what I say?

Is the general direction appropriate?  What I plan to do is write a 
chapter on each of the ZooLib demos, and discuss in detail each new 
concept that the demos provide.  So far there are just two demos, 
ZHelloWorld and ButtonMessage.  Once I get the chapter on ButtonMessage 
done, I will write more demos, with two or three new concepts introduced 
in each new demo.

Best,

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

    Tilting at Windmills for a Better Tomorrow.

[ZooLib-dev] article on cross-platform basics

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

Friends,

I have written an article on some of the rudiments of cross-platform 
software development.  "Writing Cross-Platform Software - Getting 
Started" is at

http://www.byteswap.net/mikesnotes/2002/getting-started/

I plan to write more columns regularly, covering all aspects of portable 
and cross-platform development, exploring the architecture of frameworks 
such as ZooLib, AbiWord and Mozilla, and so on. http://www.byteswap.net/ 
will also have a links and resources page for finding info and software 
related to cross-platform programming, that will be driven by a web 
database.

I'm very interested to know what people think of the article.

Also you will see it was published in DocBook HTML.  I got DocBook 
working on my Debian PowerPC mac a while back, but when I upgraded to 
debian unstable, everything broke.  I had to understand what I was 
really doing to get it working again.  My next bit of writing will be to 
resume the ZooLib manual, I promise.

Best,

Mike
cra...@go...
http://www.goingware.com/

[ZooLib-dev] The ZooLib cookbook 0.00001

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

Well, I actually started writing something finally.  I wrote a bit of 
documentation a little over a year ago, but I was creating DocBook source 
freehand and couldn't get the thing to validate, so I thought it would be better 
to start afresh.

What I'm going to do to start with is write what I'm calling "The ZooLib 
Cookbook", which will explain each of the demo programs in detail.  So far we 
only have two demos, ZHelloWorld and ButtonMessage, but I plan to write more, 
eventually with one program to illustrate each important concept in building a 
ZooLib application, and then something larger that ties it all together.  Then 
I'll write a programmer's manual, but I think it's more useful to write the 
cookbook first as we will also be able to document ZooLib's API using Doxygen 
(kind of like Javadoc but for C++).

You can see my first timid steps at:

http://goingware.com/zoolib/cookbook/

I'll put updates there regularly until I have something that is at least mostly 
complete and coherent, then I'll post it at the sourceforge site.  Soon I will 
also check the XML document source into CVS at sourceforge also.

I thought it would be nice to show you tonights first bit of work so you can see 
what it looks like.  I particularly like how quoted source code is formatted 
with the gray box around it.

As you will see I'm releasing it under the GNU Free Documentation License.  You 
can find out more about the FDL at:

http://www.gnu.org/licenses/licenses.html#FDL

Note that ZooLib itself is released under the MIT license, not the GPL.  Doing 
that enables writers of commercial software to use ZooLib without releasing your 
own source code.  But the programmer's manuals won't be part of your products, 
and I think the Free Software Foundation (most likely RMS) makes a pretty good 
case for using licenses like the FDL in "Free Software and Free Manuals" at:

http://www.gnu.org/philosophy/free-doc.html

I'm only going to be able to work on the doc sporadically so don't hold your 
breath waiting for it yet.  As always the best way at present to learn how to 
use ZooLib is to read the sample source code and ask questions on the mailing list.

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

   Tilting at Windmills for a Better Tomorrow.

     "I give you this one rule of conduct. Do what you will, but speak
      out always. Be shunned, be hated, be ridiculed, be scared,
      be in doubt, but don't be gagged."
      -- John J. Chapman, "Make a Bonfire of Your Reputations"
         http://www.goingware.com/reputation/

Re: [ZooLib-dev] WooHoo! DocBook works

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

On Tuesday 06 November 2001 06:42 pm, Michael D. Crawford wrote:

> It doesn't come with Slackware, which is the Linux I normally use, and
> building it from scratch and getting all the dtd's and catalogs and
> everything installed is just beyond my capacity.

On Slackware disk #4, in the contribs directory, is a package called 
sgmltools.tgz. You can also find it at 
"ftp.slackware.com/pub/mirrors/slackware/slackware-8.0/contrib". It has 
everything you need except the XML version. I also believe that XEmacs 
included psgml by default as well (I don't know about Emacs though).

If you ever go back to Slackware keep it in mind. You will go back, they 
always do :-)

-- 
David Johnson
___________________
http://www.usermode.org
pgp public key on website

[ZooLib-dev] WooHoo! DocBook works

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

Well I finally found a way to make docbook work for me without having an 
aneurism.  Now I can start doing meaningful work on writing a programmers manual 
for ZooLib, and hopefully make it much more approachable for all of you.

It doesn't come with Slackware, which is the Linux I normally use, and building 
it from scratch and getting all the dtd's and catalogs and everything installed 
is just beyond my capacity.

But I installed Debian PowerPC on my Macintosh, and happily one can select 
DocBook as an install option.  When one selects the initial packages for 
installation there is an option for SGML stuff.


With a little RTFMing I was able to get psgml working well to type up my first 
docbook document in Emacs.  I could validate it OK.  But I had trouble using 
db2html to format my test document as HTML.  I kept getting lots of cryptic errors.

I got help from the doc...@li... mailing list and made a 
small modification to db2html (it's a shell script) that made things work for me.

As it stands, db2html will format DocBook SGML documents, which I think is the 
official standard for what DocBook means.  But DocBook XML is in developmet, and 
is working well, although I don't think it has been ratified as a standard yet. 
  There are a lot of advantages to preparing documents in XML rather than the 
more general SGML - basically since its easier to parse there is a lot of free 
software available for manipulating XML documents but not a whole lot for SGML.

The following patch, when applied to a copy of /usr/bin/db2html will make it 
process DocBook XML documents.  Keep both versions around and you can process 
both kinds.  What would be a little better is to detect the file extension and 
do it the right way in just one script:

--- db2html     Tue Nov  6 22:25:15 2001
+++ mydb2html   Tue Nov  6 22:17:03 2001
@@ -4,6 +4,7 @@
  DB_STYLESHEET=/usr/lib/sgml/stylesheet/dsssl/docbook/cygnus/cygnus-both.dsl
  HTML_STYLESHEET=/usr/lib/sgml/stylesheet/css/cygnus/docbook.css
  ADMON_GRAPHICS=/usr/lib/sgml/stylesheet/dsssl/docbook/nwalsh/images/*.gif
+XMLDCL=/usr/lib/sgml/sgml/xml.dcl

  output=db2html-dir
  TMPDIR=DBTOHTML_OUTPUT_DIR$$
@@ -52,10 +53,10 @@
  SAVE_PWD=`pwd`
  if [ $1 = `basename $1` ]; then
    echo "working on ../$1"
-  (cd $TMPDIR; jade -c $CATALOG -t sgml -ihtml -d ${DB_STYLESHEET}\#html ../$1;
  cd $SAVE_PWD)
+  (cd $TMPDIR; jade -c $CATALOG -t xml -ihtml -d ${DB_STYLESHEET}\#html ${XMLDC
L} ../$1; cd $SAVE_PWD)
  else
    echo "working on $1"
-  (cd $TMPDIR; jade -c $CATALOG -t sgml -ihtml -d ${DB_STYLESHEET}\#html $1; cd
  $SAVE_PWD)
+  (cd $TMPDIR; jade -c $CATALOG -t xml -ihtml -d ${DB_STYLESHEET}\#html ${XMLDC
L} $1; cd $SAVE_PWD)
  fi

  if [ $# -eq 1 ]


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

   Tilting at Windmills for a Better Tomorrow.

     "I give you this one rule of conduct. Do what you will, but speak
      out always. Be shunned, be hated, be ridiculed, be scared,
      be in doubt, but don't be gagged."
      -- John J. Chapman, "Make a Bonfire of Your Reputations"
         http://www.goingware.com/reputation/

Re: [ZooLib-dev] Window flicker

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

On 12 Oct 2001 14:31:33 -0700, Mark Wrenn wrote:
> +----------------+
> |    Back Win    |
> |                |
> |                |
> |                |
> |          +----------------+
> |          |  A  |          |
> |          |     |          |
> +----------|-----+          |
>            |                |
>            |                |
>            |    Front Win   |
>            +----------------+
> 
> When clicking to Back Win I only want to repaint the A area.
> 
> Is this a problem with the way I am using SetClip()?  Who maintains the
> coordinates of the A area?
> 
> Sample code anyone?

Short answer
------------
Somewhere (hopefully not everywhere) you're probably doing something like this:
MyPane::DoDraw(const ZDC& inDC, const ZDCRgn& inBoundsRgn)
	{
	ZDC localDC(inDC);
	localDC.SetClip(ZRect(0, 0, 100, 200));
	...
	}

When the SetClip call should be:

	localDC.SetClip(localDC.GetClip() & ZRect(0, 0, 100, 200));

which will tighten the clip down to include only those pixels already in the
clip *and* in the rectangle (0, 0, 100, 200).

Who owns the A area?
--------------------
In short, the invalid region for a window is owned by ZOSWindow. This is an
implementation detail of ZooLib as it stands, all panes requiring only that they
are ultimately owned by a ZFakeWindow derivative, and the only released
implementation of the ZFakeWindow protocol is ZWindow, which wraps a ZOSWindow.
So for most purposes you should think in terms of the invalid region being owned
by ZWindow.

The invalid region is modified in four ways, two that augment it and two that
clear it.

Augmenting the invalid region:
1) OS-level notifications (WM_PAINT messages, updateEvt events, and
Expose/GraphicsExpose events) add pixels to the invalid region. These events are
received by the ZOSApp_XXX event loop and are passed to the affected
ZOSWindow_XXX, which unions them into the invalid region, invalidates the
effective clip region of an extant ZDCCanvas_XXX_Window and posts a message to
itself if the region was previously empty.
2) Explicit calls to ZFakeWindow::InvalidateRegion, usually invoked by
ZWindow::InvalidateWindowRegion which is in turn usually invoked by
ZSubPane::Invalidate.

Clearing the invalid region:
1) When the ZOSWindow_Std::DispatchMessageImp receives a "zoolib:Invalid"
message it checks its invalid region and if not empty copies it into a temp
variable, empties it, sets up a ZDC with the invalid region as the clip and
calls its owner's OwnerUpdate method passing the ZDC. As the owner of a
ZOSWindow is usually a ZWindow you should look at ZWindow::OwnerUpdate to see
how things work. Note that we clear the invalid region *before* calling
OwnerUpdate, so if in the process of drawing we end up calling Invalidate we
won't lose that invalidation (not that you should do so, but it does work).
2) A call to ZOSWindow::UpdateNow, usually invoked by ZWindow::UpdateWindowNow,
itself usually invoked by ZSubPane::Update, will do all the work that the
receipt of a "zoolib:Invalid" message does, including calling any affected
panes' DoDraw methods.

It should be noted that there is _no_ way to query the invalid region for a
window. Each window has a dedicated thread which handles its messages, so a
window can be quite lax about taking up CPU time without making other windows in
the same application unresponsive. The OS itself may also multi-process
preemptively, so other applications can be showing, hiding and resizing windows
whilst the code for a ZooLib application's window is executing. Those other
window operations in the same app or in the machine as a whole can cause changes
to the invalid region for a window _at any time_, so querying and then acting on
an invalid region will have problems that show up from time to time which would
be difficult or impossible to manage.

The behavior of a ZDC attached to a ZooLib window takes all this into account.
As pixels are added to a window's invalid region they are removed from the
window's effective clip region, so your code can't draw to them. Even if those
pixels are removed whilst you're in the middle of drawing operations they will
be cleanly locked out on your behalf, and an update message will be delivered to
your window at the next opportunity. Blitting pixels from place to place within
a window also takes account of the invalid region -- blitting which tries to
copy invalid pixels will not copy them but will instead augment the invalid
region.

The ideal model
---------------
ZooLib is most supportive of a model where the pixels in a window are considered
to be a cached version of a rendering of an application's internal state. That
is, they reflect a subset of the application's state at some time, potentially
in the distant past. For the window to accurately reflect a fairly current state
it needs to be managed as any other cache is managed -- changes to the state
should determine which pixels are affected by those changes and should
invalidate them. If you have code that makes changes that must be reflected in
the window immediately, say because you have a sequence of images to show that
should not be interrupted by user actions, simply change the state, invalidate
the relevant pixels then call ZSubPane::Update (or ZWindow::UpdateWindowNow),
change the state, invalidate, update etc...


Andrew Green

[ZooLib-dev] Window flicker

[Mark W. <mr...@bi...>]

I'm noticing that when I switch between windows in my application that I see
a lot of screen flicker as the entire window is repainted.  Is there a
recommended solution for this?

For example:

+----------------+
|    Back Win    |
|                |
|                |
|                |
|          +----------------+
|          |  A  |          |
|          |     |          |
+----------|-----+          |
           |                |
           |                |
           |    Front Win   |
           +----------------+

When clicking to Back Win I only want to repaint the A area.

Is this a problem with the way I am using SetClip()?  Who maintains the
coordinates of the A area?

Sample code anyone?

Mark

Re: [ZooLib-dev] CodeWarrior 7 for windows

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

On 26 Sep 2001 21:37:14 +1000, David L Robinson wrote:
> Just purchased CodeWarrior 7 for Mac & Windows, unwrapped and 
> installed, started to compile ButtonMessage demo. All source files 
> compile with no problems except for ZDragClip_Win.cpp .

The problem actually showed up, if I remember correctly, in CW Pro 6.
The windows headers' declaration of QueryInterface was 'helpfully'
enhanced to take either a pointer to a pointer to void or to be a
template function taking only a pointer to a pointer to a type -- the
detected type is then used to invoke the compiler intrinsic __uuidof.

There's a revised set of code at:
 <http://www.zoolib.org/bleedingedge>
that has Pro 6 fixes.

I'm getting pretty settled in to my new house and office, which process
has kept me from getting zoolib checked into CVS on sourceforge, at
which point fixes for the problems that get reported on this list will
be not just implemented but also be available in a timely fashion.

A+

Re: [ZooLib-dev] Confused by color

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

On 25 Sep 2001 16:55:34 -0700, Mark Wrenn wrote:
> I'm confused by Zoolib color support.  I would expect the following to fill
> the rectangle with the color red:
> 
> ZDCInk *ink = new ZDCInk( ZRGBColor( 255, 0, 0 ) );
> inDC.SetInk( *ink );
> inDC.Fill( theRect );
> 
> Instead I get a black rectangle.  I don't get it.  Tracing through the code
> hasn't helped.  Maybe this is a Mac issue?

ZRGBColor's components are 16 bit unsigned ints, although most pixmaps,
screens etc have at most a resolution of 8 bits per component -- 255
thus gets truncated to 0 (0x00FF --> 0x00), ie to black. On the other
hand, ZRGBColorSmall (better name anyone?) has 8 bit unsigned
components, and when it's converted to a ZRGBColor the 8 bits are
'smeared' across the full 16 bit range, so 0xFF --> 0xFFFF and 0x88 -->
0x8888.

Note that ZDCInk is geared towards use as a value-based type -- it's not
necessary nor generally desirable to allocate it from the heap. Under
the hood there is a reference counted representation, which will hold
either a single ZRGBColor, or a pair of colors and a bi-color pattern,
or a pixmap. It also has conversion constructors from ZRGBColorPOD (the
POD base for ZRGBColor) So to draw a red rectangle the following
suffices:

  inDC.SetInk(ZRGBColor(0xFFFF, 0, 0));
  inDC.Fill(theRect);

Or you could use the convenience static ZRGBColor::sRed thus:
  inDC.SetInk(ZRGBColor::sRed);

ZRGBColor (and ZRGBColorSmall) also support basic arithmetic -- adding
two ZRGBColors does a clamped add of each colors' components.

A+

[ZooLib-dev] CodeWarrior 7 for windows

[David L R. <*@drobinson.com.au>]

Just purchased CodeWarrior 7 for Mac & Windows, unwrapped and 
installed, started to compile ButtonMessage demo. All source files 
compile with no problems except for ZDragClip_Win.cpp .

Under the Windows version I get the following error:
#Start of CodeWarrior Error Message
Error   : function call 'QueryInterface(const _GUID, 
ZDragClip_Win_DataObject **)' does not match
'IUnknown::QueryInterface(const _GUID &, void **)'
'IUnknown::QueryInterface<...>(T0 **)'
ZDragClip_Win.cpp line 204 
T)(inIDataObject->QueryInterface(ZDragClip_Win_DataObject::sIID, 
&theDataObject)) >= 0)
#End of Message

Is it finding the wrong QueryInterface?

#From ZDragClip_Win.cpp
ZTuple ZDragClip_Win_DataObject::sAsTuple(IDataObject* inIDataObject)
	{
	ZTuple theTuple;
	ZDragClip_Win_DataObject* theDataObject;
HERE-->		if (SUCCEEDED(inIDataObject->QueryInterface 
(ZDragClip_Win_DataObject::sIID, &theDataObject)))
		{
		theTuple = *theDataObject->GetTuple();
		theDataObject->Release();
		}
	else
		{
		vector<FORMATETC> filteredVector;
		::sFilterNonHGLOBAL(inIDataObject, filteredVector);

		for (size_t currentFormatIndex = 0; 
currentFormatIndex < filteredVector.size(); ++currentFormatIndex)
			{
			bool isString;
			string thePropertyName;
			if 
(ZDragClipManager::sGet()->LookupCLIPFORMAT(filteredVector[currentFormatIndex].cfFormat, 
thePropertyName, isString))
				{
				ZAssertStop(1, thePropertyName.size() > 0);
				FORMATETC theFORMATETC = 
filteredVector[currentFormatIndex];
				STGMEDIUM theSTGMEDIUM;
				HRESULT theHRESULT = 
inIDataObject->GetData(&theFORMATETC, &theSTGMEDIUM);
				if (SUCCEEDED(theHRESULT))
					{
					if (theSTGMEDIUM.tymed & TYMED_HGLOBAL)
						{
						void* globalPtr = 
::GlobalLock(theSTGMEDIUM.hGlobal);
// Special case text, to find and ignore the zero terminator, and to 
store a string.
						if 
(theFORMATETC.cfFormat == CF_TEXT)
							{
 
	theTuple.AddString(thePropertyName, 
string(reinterpret_cast<char*>(globalPtr)));
							}
						else
							{
							size_t 
theSize = ::GlobalSize(theSTGMEDIUM.hGlobal);
 
	theTuple.AddRaw(thePropertyName, globalPtr, theSize);
							}
 
	::GlobalUnlock(theSTGMEDIUM.hGlobal);
						}
					::ReleaseStgMedium(&theSTGMEDIUM);
					}
				}
			}
		}
	return theTuple;
	}

// 
====================================================================================================
#pragma mark -
#pragma mark * ZDragClip_Win_Enum

-- 
David L Robinson - me...@dr... - ICQ# 8955819
YahooID: drobinsoncomau - MSN: dro...@ho... - AIM: drobinsoncomau
Phone: 1800 222 589 int +61 2 66287472
Mobile: +61 (0)412 458477
Fax: 1800 222 FAX (1800 222 329) int +61 2 66283492
My Web: http://drobinson.com.au
UHF CB Radio: SARC63 (Cell Call ID: 63) Ch 7 North Coast NSW Only
SnailMail: P.O.Box 550, Lismore, NSW 2480
Me(I Think): Real Geeks never die. Their E-mail addresses just bounce.
Send Urgent messages to ur...@dr... The Subject is sent 
to my Mobile Phone.

[ZooLib-dev] Confused by color

[Mark W. <mr...@bi...>]

I'm confused by Zoolib color support.  I would expect the following to fill
the rectangle with the color red:

ZDCInk *ink = new ZDCInk( ZRGBColor( 255, 0, 0 ) );
inDC.SetInk( *ink );
inDC.Fill( theRect );

Instead I get a black rectangle.  I don't get it.  Tracing through the code
hasn't helped.  Maybe this is a Mac issue?

Any ideas?

Mark Wrenn

Re: [ZooLib-dev] Problem compiling ButtonMessage under RedHat.

[David L R. <zo...@dr...>]

At 20:40 -0700 9/9/2001, David Johnson wrote:
>On Sunday 09 September 2001 08:04 pm, David L Robinson wrote:
>
>>  [drobinso@rush ButtonMessage-build-posix]$ g++ -v
>>  Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
>>  gcc version 2.96 20000731 (Red Hat Linux 7.0)
>
>Despite Redhat angry insistance that there's nothing wrong with gcc 2.96, it
>was never officially released or approved by its authors. I would strongly
>suggest using gcc 2.95.3, which was the last *stable* version of gcc released
>by GNU.

Just for fun, I downloaded GCC 3.0.1. And after 3 minor changes to 
ZooLib it worked! No compiler faults.

Tut, tut Mr RedHat.

Just waiting for my copy of CodeWarrior v7 Mac & Win to arrive, then 
I can compile Zoolib on  Mac OS & Windows 98, YAY!

-- 
  David L Robinson - me...@dr... - ICQ# 8955819
YahooID: drobinsoncomau - MSN: dro...@ho... - AIM: drobinsoncomau
Phone: 1800 222 589 int +61 2 66287472
Mobile: +61 (0)412 458477
Fax: 1800 222 FAX (1800 222 329) int +61 2 66283492
My Web: http://drobinson.com.au
UHF CB Radio: SARC63 (Cell Call ID: 63) Ch 7 North Coast NSW Only
SnailMail: P.O.Box 550, Lismore, NSW 2480
Me(I Think): Real Geeks never die. Their E-mail addresses just bounce.
Send Urgent messages to ur...@dr... The Subject is sent 
to my Mobile Phone.

[ZooLib-dev] Problem compiling ButtonMessage under RedHat.

[David L R. <zo...@dr...>]

[drobinso@rush ButtonMessage-build-posix]$ make
/usr/bin/g++  -I../../zoolib-demos/ButtonMessage/source/ 
-I../../zoolib/experimental/  -I../../zoolib/files/ 
-I../../zoolib/foundation/  -I../../zoolib/graphics/ 
-I../../zoolib/platform/be_only/  -I../../zoolib/platform/posix_only/ 
-I../../zoolib/streams/  -I../../zoolib/text/ 
-I../../zoolib/threads/  -I../../zoolib/uicore/ 
-I../../zoolib/uiextra/  -I../../zoolib-demos/ButtonMessage/zconfig/ 
-I../../zoolib/experimental/  -I../../zoolib/files/ 
-I../../zoolib/foundation/  -I../../zoolib/graphics/ 
-I../../zoolib/net/  -I../../zoolib/platform/be_only/ 
-I../../zoolib/platform/mac_only/ 
-I../../zoolib/platform/posix_only/ 
-I../../zoolib/platform/win_only/  -I../../zoolib/printing/ 
-I../../zoolib/resources/  -I../../zoolib/streams/ 
-I../../zoolib/text/  -I../../zoolib/threads/  -I../../zoolib/uicore/ 
-I../../zoolib/uiextra/  -I../../zoolib/util/ 
-I../../zoolib/zconfig/  -I../../zoolib/_other/misc/ 
-I../../zoolib/_other/ZBTree/  -I../../zoolib/_other/ZDBase/ 
-I../../zoolib/_other/storage/   -O3   -DDEBUG  -c 
../../zoolib/graphics/ZDC.cpp -o ZDC.o
../../zoolib/graphics/ZDC.cpp: In method `ZRGBColor ZDCCanvas::GetPixel
(ZDCState &, short int, short int)':
../../zoolib/graphics/ZDC.cpp:37: Internal compiler error in
emit_move_insn, at expr.c:2577
Please submit a full bug report.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make: *** [ZDC.o] Error 1
[drobinso@rush ButtonMessage-build-posix]$

ZRGBColor ZDCCanvas::GetPixel(ZDCState& inState, ZCoord inLocationH, ZCoord inL
         {
// By default ZDCCanvases have no backing store. ZDCPixmap defines GetPixel cal
// bounds as returning black, so we do the same.
37:        return ZRGBColor::sBlack;
         }

If I comment this return out the compiler will die on another use of sBlack.

I don't see why sBlack is any different or special. Apart from it 
being '0' in value.

[drobinso@rush ButtonMessage-build-posix]$ g++ -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.0)

I'm going to upgrade to RedHat 7.1 incase this has been fixed. I'll 
send another E-mail if this works.

-- 
David L Robinson - me...@dr... - ICQ# 8955819
YahooID: drobinsoncomau - MSN: dro...@ho... - AIM: drobinsoncomau
Phone: 1800 222 589 int +61 2 66287472
Mobile: +61 (0)412 458477
Fax: 1800 222 FAX (1800 222 329) int +61 2 66283492
My Web: http://drobinson.com.au
UHF CB Radio: SARC63 (Cell Call ID: 63) Ch 7 North Coast NSW Only
SnailMail: P.O.Box 550, Lismore, NSW 2480
Me(I Think): Real Geeks never die. Their E-mail addresses just bounce.
Send Urgent messages to ur...@dr... The Subject is sent 
to my Mobile Phone.

[ZooLib-dev] More on Linux debugging

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

It seems that the Linux kernel doesn't fully support debugging
multithreaded applications, as is discussed in the thread here on
Slashdot:

http://slashdot.org/comments.pl?sid=20762&cid=2204619

I'm going to follow up with a couple of the people who posted here and
see what there is to do about it.

Best,

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] gdb & threads

[mike <cra...@go...>]

I've had trouble using GDB on Linux to debug ZooLib applications, and
was asking around about it a couple months ago.

Somebody must have pulled my mail out of an old archive and wrote in to
ask about it.

He says he had the same problems, but the 5.1 bleeding edge version of
gdb worked better for him.  I'll give it a try in a couple days.

The bug I get is that when I try to single step after a breakpoint, I
get the message "ptrace: no such process", and then you can't debug
anymore.

Mike Crawford
cra...@go...
http://www.goingware.com/

[ZooLib-dev] ZooLib builds with CygWin/g++ on Windows

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

But it doesn't run - yet.

I have been tinkering around with getting ZooLib to work on Windows by building
it with CygWin.

If you're not familiar with it, CygWin is a GNU Unix-like shell environment for
Windows.  You can download it from http://sources.redhat.com/cygwin/  Source
code is provided for everything, and most of the components are under the GNU
General Public License.  It's about 100 megabytes and comes with a lot of stuff.

The usual purpose of programming with CygWin is to port some Unix command-line
tool to Windows.  Andy was pretty horrified when I told him I wanted to try
building ZooLib with it.
But it turns out it's not too hard to build a traditional Windows application
with CygWin, the developers have written their own versions of the win32 header
files and linking libraries.

Once I really got a chance to concentrate on it it took about 5 hours to get a
ZooLib application to successfully link with gmake and g++ under CygWin.  There
seem to be only a couple places where I had actual incompatibilities in the
code, as most of ZooLib's code already builds with g++ on Linux.

So far it doesn't run, although I haven't tried much to debug it.  Happily,
CygWin provides a nice GUI version of the GDB debugger and I can see at least
that my crash is consistent.
So I expect I can get it working before long, and then I'll write up some more
detailed notes.

I was working with a fairly recent version of the development sources.  I'll
make sure I have the latest before I finish.  These are later than what is
publicly released on SourceForge.  I think Andy would like to make a new source
drop to the public before too long but his life's been all topsy-turvy lately
with a move to a new home.

There's some other stuff I want to get working in ZooLib myself for the next
release - BeOS PowerPC, FreeBSD, and at some point Solaris Sparc.

I managed to build it with small modifications to the "makefile" in my build
directory and "realmake" in the project's source directory.  The project I'm
using is a tool for testing out some ideas on making ZPaneLocators easier to
use, and I'll be releasing the source to that at least by the next time ZooLib
itself is released.

The problems I had were:

- I needed to specify a few flags on the g++ command line through the makefile,
notably "-DZCONFIG_OS=ZCONFIG_OS_Win32".   CygWin defines _WIN32_ or whatever in
the preprocessor so it probably is possible to have the zconfig headers
automatically tell we're on windows even though gcc is used.

- Andy has defined compiler-specific versions of ZMain() in ZMain.cpp (the newer
code supports visual C++) and I added another to support GCC.  It appears that
GCC knows about __argc and __argv to give the command line parameters to a Win32
application, but the link fails if it's a GUI app.  Or something.  Anyway, I
couldn't use __argc and __argv.

- the Win32 header files provided by CygWin aren't quite compatible with those
provided by Metrowerks and Microsoft, so I had to add some header files to those
included in ZDragClip.h.  This started with trying to get a definition for
CLIPFORMAT, but then I needed to include some others to make the header that had
that in it compile.

- I think gcc is funny about using the function form of typecasting.  That is,
some constructions that contain stuff like:

   short( 42 );

this caused trouble in a line that cast the results of the HIWORD and LOWORD
macros somewhere.  It worked to change the code slighly to something else that
was equivalent.

I mentioned on another mailing list that g++ won't compile the following line,
while Visual C++ and Codewarrior will:

	unsigned long ul;

	ul = unsigned long( 25 );

and someone told me that it was actually g++ that had the correct behaviour. 
I'm not enough of a language lawyer to know.  My understanding is that this form
of a cast is actually a call to the copy constructor, and I guess there aren't
exactly copy constructors for built-in types.  Whatever.

- CygWin doesn't provide #include <limits>, so I had to add another case to
where this is already handled for Posix.

- There was some problem I just couldn't figure out with the use of ::toupper in
some menu code.  I just #ifdefed the code out for now.

- I had to add references to the source files for the windows-specific platform
code to my realmake file.  In general it should work to include all the
platform-specific files in any platform's build, because the whole files are
guarded with #if's - at worst it just makes one's builds a little bit slower. 
So I should be able to build for BeOS, Linux and Win32 with the same realmake
file.

- most of the inline assembler seems to be OK, as it seems to pick up the
GCC-style syntax that was originally written for the Linux build when compiling
the ZAtomic stuff.  But there is some additional inline assembler in
ZDebug_Win.cpp that just uses syntax compatible with CodeWarrior and Visual
C++.  I put in conditionals and wrote down my best guess as to what would work
for gcc, but it didn't work.  I'll see if I can find a tutorial on gcc inline
assembler.  It's not a big deal for now, I used conditional code to make the
check for a debugger always return true, and made the call to
ZDebug_DisplayMessage call abort().

Oh, yeah, and my executable came out being named "panelocators.exe-debug".  I
just renamed it after the build.

Mike
-- 
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] Is ZooLib ready for real-world use?

[Joshua J. <ju...@nc...>]

At 6:01 PM -0700 2001-05-22, Andrew Green wrote:
>Hi Joshua,
>
>Using this mailing list would be most valuable, rather than sending
>directly to my email. I get the feeling that although there must be at
>least 1000 people who've downloaded the source, most of them have not
>been able to get into it because of the paucity of documentation and
>sample code. A richer mailing list archive might be helpful, and could

And the latest source archive on SourceForge doesn't compile out of 
the box with the current version of the dominant Mac compiler.  I 
suspect many people quit at this point.

>seed a documentation effort (I can dream).

If you build it, they will come. :-)  Eventually.

>wrt cvs, my copy of ZooLib is managed out of a private cvs server that
>supports the product development work of Learning in Motion and OISE.
>Every month or so I post a package of source at
><http://www.zoolib.org/bleedingedge/>,
>which I intended as an interim measure until I figured out how to handle
>keeping the source in two cvs servers simultaneously. Unfortunately I
>don't have any experience with that kind of setup -- in fact if I'm
>doing anything other than a checkin or update I have to hit the cvs
>manual to refresh my memory. If you (or anyone else reading this) has
>any suggestions about how to handle this I'd love to hear from you.

Well, you may find it rewarding to use a more intuitive CVS client. 
I have nothing against the command-line (and I rely on it on 
occasion) but for general use I use MacCVS Pro, the development 
version of which supports SSH.  My only objection is that binary 
distribution of MacCVS Pro violates the GPL.  There's also a Mac port 
of GNU cvs, but it's basically a front-end to the command-line 
program -- not as cool as MacCVS Pro.

As for the repositories, I haven't tried maintaining a project in 
more than one at the same time, and until the software supports it I 
don't recommend trying.  I specifically recommend keeping ZooLib in a 
repository that offers anonymous read access, and write access to the 
appripriate ZooLib developers (whom you may not wish to grant access 
to your private server).  I suggest you either run a separate ZooLib 
repository on your own server and open it to the public as outlined 
above, or just move it to SourceForge.  You can download the nightly 
tarball if you're paranoid.

Generally speaking, people want to contribute, and if you make it 
easy and rewarding, they will.  For me, contributing will be easier 
if I have (even read-only) access to a CVS server.  My vote is on 
SourceForge.  And I'll even set it up if you like -- make those tax 
dollars work for you! :-)

>Looking forward to hearing from you,
>Andrew Green

Looking forward to CVS.  I don't think I can be more clear than that. :-)

Josh