From ahaas at airmail.net  Tue Aug  3 01:03:48 2004
From: ahaas at airmail.net (Art Haas)
Date: Tue Aug  3 01:04:08 2004
Subject: [PythonCAD] New stuff in repo, but beware!
Message-ID: <20040802230348.GN7321@artsapartment.org>


Sounds scary! I've updated the code in the public repo, and you can get
your first glimpse at the currently very primitive printing code as well
as some new text code. The printing code adds a 'Print Screen' menu
choice as well as a normal 'Print' choice. Both choices are currently
hard coded to generate a file called '/tmp/pycad.ps' for an 8.5"x11"
piece of paper in portrait mode. A proper 'Print' menu choice will have
a dialog box letting you select the paper size, portrait or landscape
mode, as well as an option to print to a file or send the print to a
printer via some command like 'lpr'.

The new text code is a reworking of the current TextStyle and TextBlock
classes, and the new code is less convoluted than the older text code,
as well as more similiar in class heirarchy to other bits of code in the
program. The text stuff is stil changing heavily, so if you update your
code with to what's in the repo, expect some odd behavior.

I don't usually check in code that is still changing as much as I expect
the text and printing code to do, but I'm going to be working away from
home for a bit, and I want my current code accessible via 'svn update'.

-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822
From csomerlot at gmail.com  Thu Aug 12 15:10:47 2004
From: csomerlot at gmail.com (Chris Somerlot)
Date: Thu Aug 12 15:10:49 2004
Subject: [PythonCAD] file saving broken
Message-ID: <9a8f0670408120610169d4b6@mail.gmail.com>

The addition of text to a drawing prevents me from saving a valid file
on windows. Art, should I try looking into it, or wait for further
code developments before starting?
From ahaas at airmail.net  Thu Aug 12 19:15:04 2004
From: ahaas at airmail.net (ahaas@airmail.net)
Date: Thu Aug 12 19:15:12 2004
Subject: [PythonCAD] file saving broken
In-Reply-To: <9a8f0670408120610169d4b6@mail.gmail.com>
References: <9a8f0670408120610169d4b6@mail.gmail.com>
Message-ID: <34023.24.158.217.63.1092330904.squirrel@webmail.airmail.net>

> The addition of text to a drawing prevents me from saving a valid file
> on windows. Art, should I try looking into it, or wait for further
> code developments before starting?

Things are in flux right now, so I suggest holding off. The code in the
public subversion repo has the first set of changes from the reworking of
text handling, and there will be more stuff coming shortly. I apologize
for the breakage, but it should be temporary.

Art
From ahaas at airmail.net  Thu Aug 12 19:22:10 2004
From: ahaas at airmail.net (ahaas@airmail.net)
Date: Thu Aug 12 19:22:14 2004
Subject: [PythonCAD] Re: PythonCAD.pth and Interfaces.py
In-Reply-To: <20040812164350.GD20145@www.async.com.br>
References: <20040812164350.GD20145@www.async.com.br>
Message-ID: <34031.24.158.217.63.1092331330.squirrel@webmail.airmail.net>

>
> Hey Art,
>
>     We're running into trouble when running PythonCAD in conjunction
> with the ZODB BTrees. Both are doing naughty things <wink>.

Oooooo, naughtiness.

> BTrees tries importing an Interface module, and PythonCAD inserts itself
> into the PYTHONPATH via a .pth file -- and it has a top-level Interfaces
> package. This leads to nuclear meltdowns inside BTrees -- sometimes as
> far deep as inside Zope's guts -- because the Interface it's expecting
> isn't the Interface it's finding.

> Can this be fixed? Is adding bits to the global pythonpath really
> necessary? If anything, it burdens every other application in the system
> to run and look for modules in yet another directory, and leads to
> problems like this. If the .pth file is indeed essential, than at least
> protect the modules contained in the top-level package by a nice
> uniquish name -- like PythonCAD :-)

I'd thought that the way the modules are handled within PythonCAD wouldn't
conflict with other packages, but I guess that's not the case. Putting the
files into a 'PythonCAD' directory shouldn't be a problem (I think).

I'm hoping to make the next release at the end of this month, so I'll try
and get reorganize things so that the modules are in a safer directory.

Art
From ahaas at airmail.net  Sun Aug 22 19:25:48 2004
From: ahaas at airmail.net (Art Haas)
Date: Sun Aug 22 19:26:04 2004
Subject: [PythonCAD] New stuff in the repo
Message-ID: <20040822172548.GC2205@artsapartment.org>

Hi.

I've sent the changes made over the last few weeks to the repo, so those
of you using subversion to get the code can do an update and take a look
at the various changes made to text and dimension entities. There are
quite a few, and while not yet complete, the changes address some of
the problems PythonCAD has in dealing with text sizing.

The last batch of changes had some text changes where I'd added 
newTextStyle, newTextFormat, and newTextBlock classes. The latest
set of changes involve renaming the existing text stuff by adding
and 'old' prefix, and removing the 'new' prefix from the new work,
as well as removing the newTextFormat class altogether. The class
hierarchy for Text stuff is simpler without the TextFormat class,
and the class behavior made more similar to the other classes in
the program with regards to things like changing attributes and
resetting the defaults.

There were lots of changes made in handling dimensions, and still more
are on the way. While working on handling the dimension text display
I'd found some really dumb code in the Dimension class, as well
as code that is charitably described as sub-optimal. I've tried to
address these problems, and think the new dimension code is a definite
improvement.

There are still some issues to work out with the new text and dimension
code, in particular the setting of the text size. Previously the size
was defined in points, and the text was always displayed in that size
regardless of zooming in or out of the view. Now, text is defined as
a float value, and zooming in makes the text look larger, and zooming
out makes it smaller. The dimension text is defined currently at a
small size, so seeing the display dimensional value is difficult. I'll
be working on fixing this problem this week. The display of TextBlocks
has the same problem. A quick workaround is to hack the code so the
default values are larger than 1.0 units. Look in the
Generic/dimension.py file for the DimStyle options
DIM_PRIMARY_TEXT_SIZE, DIM_SECONDARY_TEXT_SIZE, and the soon-to-be
deprecated DIM_PRIMARY_FONT_SIZE and DIM_SECONDARY_FONT_SIZE, and
set these values to something larger.

There is also a good bit of commented out code in the changes. As there
had not been any code checked in recently, I wanted to get these changes
out and made available before cleaning up some of the stuff no longer in
use. The commented out code will be removed prior to the next release.

The changes made have affected the file format slightly. Newly saved
files will have changes in their TextBlock, TextStyle, and the
various Dimensions. Older files should be read without problem, but
older versions of PythonCAD will certainly not read the new files
correctly as there are new fields in the XML entities that older
versions of the code do not examine.

I'm becoming doubtful about making my next release at the end of the
month. I've been less productive than hoped over the last few weeks, and
there are still more text changes I need to make, so the next release
will probably be in the middle of September. Sorry about that.

Art
-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822
From ahaas at airmail.net  Mon Aug 30 22:23:19 2004
From: ahaas at airmail.net (Art Haas)
Date: Mon Aug 30 22:23:36 2004
Subject: [PythonCAD] Repo update with text scaling
Message-ID: <20040830202319.GK4974@artsapartment.org>

Hi.

The repo has been updated with my latest text scaling work. I've found a
workable approach to adjusting the font size given the current view of a
drawing, and while not perfect it is better than what existed before. A
suggestion or two from the PyGTK mailing list helped, so my thanks to
the people who responed to my posting there.

The code to scale the text is in the Interface/Gtk/gtktext.py file; look
for the set_textblock_bounds() function at the top of the file if you
are curious.

The text sizes are still (by default) very small, so I'm going to work
on improving the ability to adjust the text size for both TextBlocks and
Dimensions. Also, the new text drawing stuff simplifies a bit of the
drawing of Dimension text strings as an added bonus. Code reuse is good.

There are also a number of other fixes in this set of changes. I made a
change to the Quadtree class dealing with how and when in splits a node
in the tree. Also, a number of changes to various entity inRegion()
methods were made as to define the entity falling within the region of
interest if the entity had an endpoint/keypoint fall on the edge.
Previously a point on the edge of the boundary was not considered in the
region, but now it will be. This change came about after finding some
odd behavior in Quadtree storage with horizontal and vertical
construction lines. The inRegion() change fixed this odd behavior, as
led to a few modifications to some of the getNodes() methods in the
various Quadtree subclasses.

Onward and upward ...

Art
-- 
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.

-Thomas Jefferson to James Smith, 1822