dimensioning

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

dimensioning

Ed Richley

Hi:

Can anyone reproduce this problem, using the latest version?:

1) Be sure that drawing and primary dim units are set to "inches" (edit
prefs.py manually)
2) Open a new drawing
3) Draw a 1.000 x 1.000 rectangle
4) Dimension one side (say, with horizontal dimension)
5) See that it shows 0.039 instead of 1.000, as if it thought the drawing units
were mm.

If dim units are set to "millimeters", then it works correctly (even though
I want inches).

Also, there seems to be a problem with edit->preferences, for when I try
to edit the primary dim units I get the error:

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkmenus.py",
line 458, in prefs_cb
    gtkprefs.prefs_dialog(gtkimage)
  File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkprefs.py",
line 2719, in prefs_dialog
    preferences.save_user_prefs()
  File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py",
line 1660, in save_user_prefs
    _save_dimstyle_values(_f)
  File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py",
line 1471, in _save_dimstyle_values
    if abs(_val - _ds.getOption('DIM_EXTENSION')) > 1e-10:
TypeError: unsupported operand type(s) for -: 'Color' and 'float'


It appears that the DIM_EXTENSION attribute if getting the value of the
DIM_COLOR.

I'm trying to learn Python and fix this (at the same time), but it's hard :-(.
Can someone please at least reproduce the problem?

Thanks.


Ed


_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: dimensioning

Art Haas
Hi.

I'll see if I can duplicate this, and if so fix it ASAP.

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
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: dimensioning

Ed Richley
In reply to this post by Ed Richley

Art:

It seems that I can't reply to [hidden email].

In cany case, I've been looking at the code a lot, trying to learn. I do know
that when it fails, the "DIM_EXTENSION" has the value of the "DIM_COLOR", as if
some index was off by one. But, I really don't understand what's going on in
preferences.py. Or, why the prefs.py has what looks like a dictionary (is that
correct?) for primary dimension parameters, and then suplements these with
variable assignments like:

dim_primary_extension = 0.1

at the bottom. Maybe you can explain some of this so I can figure out
some of these problems.

Thanks for looking into it.


Ed


_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: dimensioning

Art Haas
In reply to this post by Ed Richley
On Tue, Jun 12, 2007 at 07:48:50AM -0400, Ed Richley wrote:

>
> Hi:
>
> Can anyone reproduce this problem, using the latest version?:
>
> 1) Be sure that drawing and primary dim units are set to "inches" (edit
> prefs.py manually)
> 2) Open a new drawing
> 3) Draw a 1.000 x 1.000 rectangle
> 4) Dimension one side (say, with horizontal dimension)
> 5) See that it shows 0.039 instead of 1.000, as if it thought the drawing
> units were mm.
>
> If dim units are set to "millimeters", then it works correctly (even though
> I want inches).

I've duplicated this. I'm investigating right now.

> Also, there seems to be a problem with edit->preferences, for when I try
> to edit the primary dim units I get the error:
>
> Traceback (most recent call last):
>   File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkmenus.py",
> line 458, in prefs_cb
>     gtkprefs.prefs_dialog(gtkimage)
>   File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkprefs.py",
> line 2719, in prefs_dialog
>     preferences.save_user_prefs()
>   File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py",
> line 1660, in save_user_prefs
>     _save_dimstyle_values(_f)
>   File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py",
> line 1471, in _save_dimstyle_values
>     if abs(_val - _ds.getOption('DIM_EXTENSION')) > 1e-10:
> TypeError: unsupported operand type(s) for -: 'Color' and 'float'
>
>
> It appears that the DIM_EXTENSION attribute if getting the value of the
> DIM_COLOR.
>
> I'm trying to learn Python and fix this (at the same time), but it's hard :-(.
> Can someone please at least reproduce the problem?

I'll take a look at this too, and reply to your other mail as well.

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
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: dimensioning

Art Haas
In reply to this post by Art Haas
On Tue, Jun 12, 2007 at 07:30:39AM -0500, Art Haas wrote:
> Hi.
>
> I'll see if I can duplicate this, and if so fix it ASAP.

This was interesting. The core problem was that there are two ways to
set the units in a drawing - one with the setUnits() method and the
other by setOption('UNITS', xxx). The trouble various places used
setOption() to do the dirty work, but it didn't go through.

The small patch below fixed things for me. Please apply and let me know
that it works for you as well.

The next challenge is to figure out the other bug you described.

Art

Index: PythonCAD/Generic/image.py
===================================================================
--- PythonCAD/Generic/image.py (revision 2760)
+++ PythonCAD/Generic/image.py (working copy)
@@ -721,6 +721,8 @@
         self.__units.setUnit(unit)
         if unit != _ou:
             self.sendMessage('units_changed', _ou)
+            self.__options['UNITS'] = unit
+            self.sendMessage('option_changed', 'UNITS', _ou)
             self.modified()
 
     units = property(getUnits, setUnits, None,
@@ -1651,6 +1653,9 @@
               key == 'DIM_SECONDARY_FONT_FAMILY'):
             if value not in self.__fonts:
                 self.__fonts[value] = True
+        elif key == 'UNITS':
+            self.setUnits(value)
+            return # bail out
         else:
             pass
         self.__options[key] = value

--
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
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: dimensioning

Art Haas
In reply to this post by Ed Richley
On Tue, Jun 12, 2007 at 07:48:50AM -0400, Ed Richley wrote:

>
> Also, there seems to be a problem with edit->preferences, for when I try
> to edit the primary dim units I get the error:
>
> Traceback (most recent call last):
>   File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkmenus.py",
> line 458, in prefs_cb
>     gtkprefs.prefs_dialog(gtkimage)
>   File "/usr/lib/python2.4/site-packages/PythonCAD/Interface/Gtk/gtkprefs.py",
> line 2719, in prefs_dialog
>     preferences.save_user_prefs()
>   File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py",
> line 1660, in save_user_prefs
>     _save_dimstyle_values(_f)
>   File "/usr/lib/python2.4/site-packages/PythonCAD/Generic/preferences.py",
> line 1471, in _save_dimstyle_values
>     if abs(_val - _ds.getOption('DIM_EXTENSION')) > 1e-10:
> TypeError: unsupported operand type(s) for -: 'Color' and 'float'
>
>
> It appears that the DIM_EXTENSION attribute if getting the value of the
> DIM_COLOR.

Grrrrrr .... dumb paste-o.

Index: PythonCAD/Interface/Gtk/gtkprefs.py
===================================================================
--- PythonCAD/Interface/Gtk/gtkprefs.py (revision 2763)
+++ PythonCAD/Interface/Gtk/gtkprefs.py (revision 2764)
@@ -2205,8 +2205,7 @@
     else:
         raise TypeError, "Unexpected widget for DIM_COLOR: " + `type(_widget)`
     _r, _g, _b = _get_rgb_values(_color)
-    _dimcolor = get_color(_r, _g, _b)
-    globals.prefs['DIM_EXTENSION'] = get_color(_r, _g, _b)
+    globals.prefs['DIM_COLOR'] = get_color(_r, _g, _b)
 
 def _set_background_color(prefstate):
     _widget = prefstate.getWidget('BACKGROUND_COLOR')

--
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
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: dimensioning

Ed Richley
> Grrrrrr .... dumb paste-o.
>

Great. I just did a svn update and it works much better now. Thanks.
Oddly, my old drawing must contain something inconsistent with the
new code, because it still wants the dimension units to be millimeters.
But, a new drawing works fine.

Can you explain how all the preferences are stored? My simple mind (ruined by
self-taught C-programming) would have a bunch of variables that get set at
start-up and when editing, and written when edit->preferences is told "OK".
But, here there are a bunch of lists, dictionaries, tuples, etc., and it was
really hard for me to follow what was going on. I'm sure there is a good
reason,
but I'd like to know more so I can help.

Thanks.



Ed



_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: dimensioning

Art Haas
On Tue, Jun 12, 2007 at 08:25:37PM -0400, Ed Richley wrote:
> > Grrrrrr .... dumb paste-o.
>
> Great. I just did a svn update and it works much better now. Thanks.
> Oddly, my old drawing must contain something inconsistent with the
> new code, because it still wants the dimension units to be millimeters.
> But, a new drawing works fine.

Weird.

> Can you explain how all the preferences are stored? My simple mind (ruined by
> self-taught C-programming) would have a bunch of variables that get set at
> start-up and when editing, and written when edit->preferences is told "OK".
> But, here there are a bunch of lists, dictionaries, tuples, etc., and it was
> really hard for me to follow what was going on. I'm sure there is a good
> reason, but I'd like to know more so I can help.

The 'prefs.py' file is python code (obviously), and the code for loading
and saving the values is found in 'PythonCAD/Generic/preferences.py'.
The file itself has a couple of comments in it to explain what type of
values the next bunch of variables should be, so in my 'prefs.py' file
the follow appear:

# [ ... snip ... ]
#
# Boolean variables
#
autosplit = True
highlight_points = True
#
# Size variables (float values)
#
chamfer_length = 1.5
fillet_radius = 2.0
leader_arrow_size = 10.0
# [ ... snip ... ]

When the defined variable is a dictionary, the variable itself is a
style, textstyle, or dimstyle. Each key represents one option with
the style. If you've adjusted any of the values in the style to some
value other than that defined by the style, the key and value are
listed after the dictionary. Again, in my 'prefs.py' file I have
the following:

#
# Standard GraphicObject parameters
#
line_style = {
    'name' : 'Default Style',
    'linetype' : ('Solid', None),
    'color' : '#ffffff',
    'thickness' : 1.0
}
line_thickness = 0.10000000000000001

So, the 'line_thickness' in the style is overriden; the value will be
0.1 instead of 1.0.

The 'prefs.py' file is parsed using routines found in the the 'imp'
module. The initial call to find_module() determines if the file
is there or not, and if it is the code is loaded via load_module().
The values of everything in the file can be examined by testing if
certain attributes exist within the newly loaded module. Using the
bits of my 'prefs.py' file above, the module 'prefs' is tested for
attributes 'autosplit', 'highlight_points', 'chamfer_length',
'fillet_radius', 'leader_arrow_size', 'line_style', etc. The complete
list of attributes is defined in the '_preflist' variable in
'preferences.py'. If the attribute is found, then the value defined
by that attribute gets picked up and placed into the 'global.prefs'
dictionary, so in my case global.prefs['AUTOSPLIT'] is True,
global.prefs['HIGHLIGHT_POINTS'] is True, etc.

When the 'line_style' attribute is found, globals.prefs['LINE_STYLE]'
gets set to a Style instance defined by the keys/values in 'line_style'.
If any overriden values were seen, as is the case above with
'line_thickness', then the matching key/value pair in globals.prefs
gets the override value. In my case, globals.prefs['LINE_THICKNESS']
is set to 0.1, overriding the value defined in the style (1.0).

I hope the explanation above sheds some light on the structure of
the 'prefs.py' file and how the values get pulled into and used by
PythonCAD.

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
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: dimensioning

Art Haas
On Wed, Jun 13, 2007 at 12:56:45PM -0500, Art Haas wrote:
>
> When the 'line_style' attribute is found, globals.prefs['LINE_STYLE]'
> gets set to a Style instance defined by the keys/values in 'line_style'.
> If any overriden values were seen, as is the case above with
> 'line_thickness', then the matching key/value pair in globals.prefs
> gets the override value. In my case, globals.prefs['LINE_THICKNESS']
> is set to 0.1, overriding the value defined in the style (1.0).

Hi.

I was poking around with this code today and fixed what is arguably an
oversight on my part. When the globals.prefs['LINE_STYLE'] value is
set, the 'LINE_TYPE', 'LINE_THICKNESS', and 'LINE_COLOR' values are
not set to whatever values defined by the just-set Style. I've just
added the code so those three values get set after LINE_STYLE. Any
overriden Style values, such as in my example in the previous mail, will
then set the appropriate key/value pair in globals.prefs.

When the preferences.py file has 'text_style', the code is supposed
to set the globals.prefs['TEXT_STYLE'] key with the suitable Style. The
line of code to do this, though, was missing (!), so the TEXT_STYLE
was not be set correctly. This problem is now fixed, and when the
TEXT_STYLE is set the various TEXT/FONT options get set as well.

I've pushed my changes out to the repo, so just do an 'svn update' and
you'll get them.

Also, some of you may have noticed that the repo now has '.gitignore'
files. They have not been added by mistake, as I've imported the
PythonCAD Subversion repo into 'git' and am now using it as my
development tree. I'm working to set up 'git clone' and 'git pull'
access from the PythonCAD site, but it isn't available yet. My work
flow now is done in the PythonCAD git repo, and after commiting
my changes I extract the change(s) as a patch, apply it to my old
Subversion development tree, then commit the patch to the Subversion
repo as I've always done. This is a manual process, but as long as
the patches are small this works.

I wrote earlier that I wanted to switch to a distributed SCM, and
the response was that most people were happy with Subversion access
and the current setup. I think the approach I've taken in making
the switch while still providing Subversion access will work for
the foreseeable future. Once I make my 'git' repo accessible then
people who want to develop PythonCAD with git will be able to do
so while Subversion users will not be abandoned. Ideally there would
be a git->svn tool that does the patch application, but I don't
know of such a beast. Git does have a 'git svn' command but it is
structured so that a Git user can push/pull from an Subversion
repo with the idea that the Subversion repo is the "master" repo.
I want a simpler "export-only" type transfer from git to svn.

When my git repo becomes public I'll send a message to the mailing
list giving the location, and those wanting to use git instead
of Subversion will be welcome to clone my tree and develop away!

Art Haas
--
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
_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad
Reply | Threaded
Open this post in threaded view
|

Re: dimensioning

Ed Richley
In reply to this post by Art Haas

> I hope the explanation above sheds some light on the structure of
> the 'prefs.py' file and how the values get pulled into and used by
> PythonCAD.
>
> Art
> --

Yes, it does. I'll dig into it more when I get a chance.

Thanks.


Ed


_______________________________________________
PythonCAD mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/pythoncad