From ahaas at airmail.net Wed Mar 1 23:15:05 2006 From: ahaas at airmail.net (Art Haas) Date: Wed, 1 Mar 2006 16:15:05 -0600 Subject: [PythonCAD] More updates at repo and release probable this week In-Reply-To: <20060228201656.GG2618@artsapartment.org> References: <20060228201656.GG2618@artsapartment.org> Message-ID: <20060301221505.GC29812@artsapartment.org> On Tue, Feb 28, 2006 at 02:16:56PM -0600, Art Haas wrote: > Hi. > > I've sent another batch of changes to the repo. At long last, the > ability to toggle the RadialDimension entities to display the > value of a diameter instead of a radius is now available, and > the ability to invert an AngularDimension is also present as > well. There is a redraw glitch with the AngularDimension that I'm > going to get fixed, hopefully today or tomorrow. For those using > subversion the new code is just an 'svn update' away. I've fixed the redraw glitch and sent the changes to the repo. The next release will appear tomorrow or Friday barring the discovery of any major problems. 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 Fri Mar 3 22:06:10 2006 From: ahaas at airmail.net (Art Haas) Date: Fri, 3 Mar 2006 15:06:10 -0600 Subject: [PythonCAD] [ANNOUNCE] Twenty-ninth release of PythonCAD now available Message-ID: <20060303210610.GD14032@artsapartment.org> Hi. I'm pleased to announce the twenty-ninth development release of PythonCAD, a CAD package for open-source software users. As the name implies, PythonCAD is written entirely in Python. The goal of this project is to create a fully scriptable drafting program that will match and eventually exceed features found in commercial CAD software. PythonCAD is released under the GNU Public License (GPL). PythonCAD requires Python 2.2 or newer. The interface is GTK 2.0 based, and uses the PyGTK module for interfacing to GTK. The design of PythonCAD is built around the idea of separating the interface from the back end as much as possible. By doing this, it is hoped that both GNOME and KDE interfaces can be added to PythonCAD through usage of the appropriate Python module. Addition of other PythonCAD interfaces will depend on the availability of a Python module for that particular interface and developer interest and action. The twenty-ninth release of PythonCAD contains various improvements to the internal entity creation and manipulation code. The routines for transferring entities between layers has been reworked, as have the routines for deleting entities. This code rework flushed out a number of bugs and sub-optimal code issues which have been resolved. The code for creating and modifying Dimension entities was both simplified by removing redundant arguments to various methods and some missing undo/redo abilities were added as well. In addition to internal code improvements, the ability to toggle RadialDimension entities to display diameter values and the ability to invert an AngularDimension entity have been added to the interface. Lastly, a variety of miscellaneous bug fixes and code improvements are present in this release. A mailing list for the development and use of PythonCAD is available. Visit the following page for information about subscribing and viewing the mailing list archive: http://mail.python.org/mailman/listinfo/pythoncad Visit the PythonCAD web site for more information about what PythonCAD does and aims to be: http://www.pythoncad.org/ Come and join me in developing PythonCAD into a world class drafting program! 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 From fb102 at soton.ac.uk Sat Mar 4 16:13:06 2006 From: fb102 at soton.ac.uk (Floris Bruynooghe) Date: Sat, 4 Mar 2006 15:13:06 +0000 Subject: [PythonCAD] other notes about development In-Reply-To: <20050620155519.GH25478@artsapartment.org> References: <20050617204023.GS31997@artsapartment.org> <200506171706.29021.ewilhelm@sbcglobal.net> <20050618133856.GB25478@artsapartment.org> <42B6A284.9070107@mmn-arquitectos.com> <20050620155519.GH25478@artsapartment.org> Message-ID: <20060304151306.GB9672@laurie.sheepb.homeip.net> [ Terribly late reply here, but still thought it worthwile ] On Mon, Jun 20, 2005 at 10:55:19AM -0500, Art Haas wrote: > On Mon, Jun 20, 2005 at 01:03:32PM +0200, Rafael Villar Burke wrote: > > Another point I humbly think makes difficult to grow a community of > > developers is that some architectural decisions such as the generic UI > > layer, which were made to have some more flexibility in the future, make > > current development too complex and burdensome. The current situation > > makes difficult to take advantage of the underlaying toolkit > > capabilities and to attract developers that are proficient in a specific > > toolkit. I must somehow agree here. I remember looking at the code more closely a while ago. Initially I applauded the separation. But then I discovered that the core/engine/whatever was too much linked with the GUI. Specifically I remember the menu layout being specified in the GUI-independent part, this did really put me off. I was hoping to find a much more generic core/engine where one can then build several UI's on. For example, why should it not be possible to build two GTK GUI's that look different? Appart from that I must agree with everyone else in this thread: thanks for keeping up the great work! Personally I have wanted to get involved a few times but mostly haven't because of a lack of time. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org From ahaas at airmail.net Sat Mar 4 18:29:45 2006 From: ahaas at airmail.net (Art Haas) Date: Sat, 4 Mar 2006 11:29:45 -0600 Subject: [PythonCAD] other notes about development In-Reply-To: <20060304151306.GB9672@laurie.sheepb.homeip.net> References: <20050617204023.GS31997@artsapartment.org> <200506171706.29021.ewilhelm@sbcglobal.net> <20050618133856.GB25478@artsapartment.org> <42B6A284.9070107@mmn-arquitectos.com> <20050620155519.GH25478@artsapartment.org> <20060304151306.GB9672@laurie.sheepb.homeip.net> Message-ID: <20060304172945.GK14032@artsapartment.org> On Sat, Mar 04, 2006 at 03:13:06PM +0000, Floris Bruynooghe wrote: > [ Terribly late reply here, but still thought it worthwile ] > > On Mon, Jun 20, 2005 at 10:55:19AM -0500, Art Haas wrote: > > On Mon, Jun 20, 2005 at 01:03:32PM +0200, Rafael Villar Burke wrote: > > > Another point I humbly think makes difficult to grow a community of > > > developers is that some architectural decisions such as the generic UI > > > layer, which were made to have some more flexibility in the future, make > > > current development too complex and burdensome. The current situation > > > makes difficult to take advantage of the underlaying toolkit > > > capabilities and to attract developers that are proficient in a specific > > > toolkit. > > I must somehow agree here. I remember looking at the code more > closely a while ago. Initially I applauded the separation. But then > I discovered that the core/engine/whatever was too much linked with > the GUI. Specifically I remember the menu layout being specified in > the GUI-independent part, this did really put me off. I was hoping to > find a much more generic core/engine where one can then build several > UI's on. For example, why should it not be possible to build two GTK > GUI's that look different? The initial menu code was in the 'Generic' code, but that is no longer true. When I first started working on PythonCAD I thought that was the way things should be done, so the interface would use the 'menus.py' file and build a menu/toolbar/something from that file. That approach has since been abandoned, and all the menu code is now done in the 'gtkmenus.py' file. The 'menus.py' file is still around but is not used. I need to 'svn delete' it ... > Appart from that I must agree with everyone else in this thread: > thanks for keeping up the great work! Personally I have wanted to get > involved a few times but mostly haven't because of a lack of time. The current approach of building the menu used in the interface from code defined in the 'Interface' portion of PythonCAD is closer to what you want described above. If you find some time I'd welcome suggestions and/or patches to make PythonCAD have an improved UI. 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 From sdb at cloud9.net Sat Mar 4 22:34:29 2006 From: sdb at cloud9.net (Stuart Brorson) Date: Sat, 4 Mar 2006 16:34:29 -0500 (EST) Subject: [PythonCAD] other notes about development In-Reply-To: <20060304172945.GK14032@artsapartment.org> from "Art Haas" at Mar 04, 2006 11:29:45 AM Message-ID: <20060304213429.40A162AA07@earl-grey.cloud9.net> > > I must somehow agree here. I remember looking at the code more > > closely a while ago. Initially I applauded the separation. But then > > I discovered that the core/engine/whatever was too much linked with > > the GUI. Specifically I remember the menu layout being specified in > > the GUI-independent part, this did really put me off. I was hoping to > > find a much more generic core/engine where one can then build several > > UI's on. For example, why should it not be possible to build two GTK > > GUI's that look different? > > The initial menu code was in the 'Generic' code, but that is no longer > true. When I first started working on PythonCAD I thought that was the > way things should be done, so the interface would use the 'menus.py' > file and build a menu/toolbar/something from that file. That approach > has since been abandoned, and all the menu code is now done in the > 'gtkmenus.py' file. The 'menus.py' file is still around but is not used. > I need to 'svn delete' it ... Hi Art and company, This has been an interesting thread. I also am kind of confused about how the GUI part of the code relates to the GUI-independent back end. Art has graceously and helpfully tried to explain it in e-mails, and that has been useful. However, I wonder if it would help prospective developers to have some kind of UML drawing showing how the GUI stuff is supposed to relate -- and communicate -- with the non-GUI stuff. Some time ago I made a quick class drawing of PythonCAD in pseudo-UML & contributed it to the project. It is kind of limited, but I found the exercise useful. However, that is only a small step. Since then I have thought that another diagram showing how a representative drawing is made up would be a good thing. The drawing would show how the different graphic objects were related to or point to each other. That is, take a drawing of a segment, a circle, and perhaps a dimension, and show how each object is instantiated, in which object list it lives, etc. Another useful UML-type drawing would be a protocol/communication drawing showing how the GUI stuff is supposed to communicate to the non-GUI stuff in response to various user commands (e.g. place a segment, move a segment, erase a segment, undo/redo an operation, etc.). Just some thoughts. I may look at making one or more of these drawings at some point, but my day job & other activities prohibit me from getting too involved right now. :-( Stuart From ahaas at airmail.net Wed Mar 8 19:13:03 2006 From: ahaas at airmail.net (Art Haas) Date: Wed, 8 Mar 2006 12:13:03 -0600 Subject: [PythonCAD] Goals for next release Message-ID: <20060308181303.GH16135@artsapartment.org> Hi. Now that the twenty-ninth release is out, I'm beginning the work on the next release. I know of one problem with the new transfer code that needs fixing regarding transferring an entity that has a dimension associated with the entity's points. If this entity is transferred from one layer to another, undoing the transfer invalidates the points used by the dimension. The fix to this problem will involve some cleverness in handling the undo operation, but right now I don't have my cleverness bag handy. I know I'll be looking at the code in 'split.py', as it needs some cleanup, and I'd also like to address some issues regarding user preferences, but we'll see what happens over the next couple of weeks. I'm hopeful that the next release will appear in the first week of April. 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 Fri Mar 10 17:41:36 2006 From: ahaas at airmail.net (Art Haas) Date: Fri, 10 Mar 2006 10:41:36 -0600 Subject: [PythonCAD] [PATCH] Two small patches fixing typos Message-ID: <20060310164136.GO16135@artsapartment.org> Hi. I found these two (dumb) typos while working yesterday. I am embarrassed they slipped through. Art Index: PythonCAD/Generic/arc.py =================================================================== --- PythonCAD/Generic/arc.py (revision 2204) +++ PythonCAD/Generic/arc.py (revision 2205) @@ -728,7 +728,7 @@ _aymin = _y - _r - _t _aymax = _y + _r + _t _arcs = [] - for _arc in self.getInRegion(_xmin, _ymin, _xmax, _ymax): + for _arc in self.getInRegion(_axmin, _aymin, _axmax, _aymax): _cx, _cy = _arc.getCenter().getCoords() if ((abs(_cx - _x) < _t) and (abs(_cy - _y) < _t) and Index: PythonCAD/Generic/move.py =================================================================== --- PythonCAD/Generic/move.py (revision 2205) +++ PythonCAD/Generic/move.py (revision 2206) @@ -40,7 +40,7 @@ from PythonCAD.Generic import util def _adjust_dimensions(op, np): - _users = point.getUsers() + _users = op.getUsers() for _user in _users: if isinstance(_user, Dimension): if isinstance(_user, LinearDimension): -- 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 Mar 13 19:54:55 2006 From: ahaas at airmail.net (Art Haas) Date: Mon, 13 Mar 2006 12:54:55 -0600 Subject: [PythonCAD] Problem with entity transfer code and other news Message-ID: <20060313185455.GC31215@artsapartment.org> Hi. I've been trying to fix the problem in transferring entities between layers where Dimension entities become invalid, and it seems like the change I made to the delObject() Layer method is a poor approach. The method was changed so that deleted objects do not have to have a finish() method invocation if delObject() is called with an optional 'False' argument, leaving the entity with whatever values/users it had while disconnecting from the storing layer. The trouble is when doing an undo/redo operation, delObject() is called without the optional argument, so finish() gets invoked, and things get messed up. I have a couple of ideas on how to fix this, and I'll be testing them over the next few days. When I hit on a solution I like I'll send a message out to the list. In other news, I find myself once again having to move, probably by the end of April at the latest, so my work may be a bit sporadic for the next couple of weeks. If I can fix the transfer problem I will probably make a release so that the improved transfer code plus the bug fixes I sent patches out will be available in the latest release, and then I can deal with moving issues. 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 Thu Mar 16 18:00:09 2006 From: ahaas at airmail.net (Art Haas) Date: Thu, 16 Mar 2006 11:00:09 -0600 Subject: [PythonCAD] Problem with entity transfer code and other news In-Reply-To: <20060313185455.GC31215@artsapartment.org> References: <20060313185455.GC31215@artsapartment.org> Message-ID: <20060316170009.GH32491@artsapartment.org> On Mon, Mar 13, 2006 at 12:54:55PM -0600, Art Haas wrote: > Hi. > > I've been trying to fix the problem in transferring entities between > layers where Dimension entities become invalid, and it seems like the > change I made to the delObject() Layer method is a poor approach. The > method was changed so that deleted objects do not have to have > a finish() method invocation if delObject() is called with an > optional 'False' argument, leaving the entity with whatever values/users > it had while disconnecting from the storing layer. The trouble is when > doing an undo/redo operation, delObject() is called without the optional > argument, so finish() gets invoked, and things get messed up. > > I have a couple of ideas on how to fix this, and I'll be testing them > over the next few days. When I hit on a solution I like I'll send a > message out to the list. I've tried a couple of ideas, but things just aren't working out. The problem always gets sticky when trying to handle undo/redo operations for the Layer 'added_child' and 'removed_child' messages. Presently it looks like I'll revert most of the changes to the 'transfer.py' file and make some simplifications to the restored code, but I'm still not giving up on finding a better solution based on the new code. 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 Fri Mar 17 21:24:14 2006 From: ahaas at airmail.net (Art Haas) Date: Fri, 17 Mar 2006 14:24:14 -0600 Subject: [PythonCAD] Second cut at reworking the entity transfer code now on repo Message-ID: <20060317202414.GK32491@artsapartment.org> Hi. Once again I've reworked the code for transferring entities between layers, and my first cut of the code is now at the repo. This reworking brings the code back closer to the clone() based approach that was used in the first version, but the code is much simpler and clearer now. While redoing the code above I found that the problems I saw regarding undo/redo behavior on dimensions in the reworked code I added to the latest release has been present for much longer than I'd realized. The code now at the repo now has abilities for undo/redo operations on 'point_changed' and 'dimobj_changed' Dimension messages that I'd thought were already in the code but in fact were not present. In addition to correcting that oversight, I added clone() routines to the various Dimension entities that, at present, are slightly incomplete. I'll be adding the needed enhancements this afternoon and weekend, so things will be more complete on Monday. For those wanting to test the code out, just do an 'svn update' and you'll get the changes. 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 Sun Mar 19 00:47:10 2006 From: ahaas at airmail.net (Art Haas) Date: Sat, 18 Mar 2006 17:47:10 -0600 Subject: [PythonCAD] Second cut at reworking the entity transfer code now on repo In-Reply-To: <20060317202414.GK32491@artsapartment.org> References: <20060317202414.GK32491@artsapartment.org> Message-ID: <20060318234710.GM32491@artsapartment.org> On Fri, Mar 17, 2006 at 02:24:14PM -0600, Art Haas wrote: > Hi. > > Once again I've reworked the code for transferring entities between > layers, and my first cut of the code is now at the repo. This reworking > brings the code back closer to the clone() based approach that was used > in the first version, but the code is much simpler and clearer now. > > While redoing the code above I found that the problems I saw regarding > undo/redo behavior on dimensions in the reworked code I added to the > latest release has been present for much longer than I'd realized. The > code now at the repo now has abilities for undo/redo operations on > 'point_changed' and 'dimobj_changed' Dimension messages that I'd thought > were already in the code but in fact were not present. In addition to > correcting that oversight, I added clone() routines to the various > Dimension entities that, at present, are slightly incomplete. I'll be > adding the needed enhancements this afternoon and weekend, so things > will be more complete on Monday. Hi. A variety of fixes have been added since yesterday, and things are looking pretty good for the new code. I'll still be making various changes over the next few days as well, but it looks like the code is mostly settled down. 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 patrick.hetu at gmail.com Sun Mar 19 21:21:21 2006 From: patrick.hetu at gmail.com (patrick.hetu) Date: Sun, 19 Mar 2006 15:21:21 -0500 Subject: [PythonCAD] Internationalization of pythoncad with gettext Message-ID: <1142799681.19069.14.camel@localhost.localdomain> Hi Art and everyone, I'm using pythoncad and i think it could touch more people if menus and instructions are in there own language. Do you think its a good idea to include Internationalization module like gettext? I try to include it to the code for giving you a patch but I'm really not sure where i must put the function and how call it and i don't know how the installation of the .mo file could be include in the setup module. I talk french and I'm pretty sure that i can translate almost every message in my language and even the web site if you want to. Regards Patrick H?tu From ahaas at airmail.net Tue Mar 21 15:56:37 2006 From: ahaas at airmail.net (Art Haas) Date: Tue, 21 Mar 2006 08:56:37 -0600 Subject: [PythonCAD] Internationalization of pythoncad with gettext In-Reply-To: <1142799681.19069.14.camel@localhost.localdomain> References: <1142799681.19069.14.camel@localhost.localdomain> Message-ID: <20060321145637.GB21646@artsapartment.org> On Sun, Mar 19, 2006 at 03:21:21PM -0500, patrick.hetu wrote: > Hi Art and everyone, > I'm using pythoncad and i think it could touch more people if menus and > instructions are in there own language. > Do you think its a good idea to include Internationalization module like > gettext? An i18n version of PythonCAD would be wonderful! As you write above, the program would be more appealing to many people if the menus and prompts were in their native language. > I try to include it to the code for giving you a patch but I'm really > not sure where i must put the function and how call it and i don't know > how the installation of the .mo file could be include in the setup > module. I'm not sure how to handle '.mo' files in the 'setup.py' file either, but that hasn't been a problem as there were no '.mo' files to deal with. Adding the hooks into the code is a matter of using the 'gettext' module that is shipped with Python - see the docs for more info. As for the PythonCAD code, the text to be translated gets adjusted like so: s = 'blah blah blah' ==> s = _('blah blah blah') This change is simply wrapping the string in a function call _(). > I talk french and I'm pretty sure that i can translate almost every > message in my language and even the web site if you want to. I would welcome patches to make PythonCAD have French text. As for the website, it needs a major overhaul as it looks just too "texty". 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 From ahaas at airmail.net Tue Mar 21 23:27:21 2006 From: ahaas at airmail.net (Art Haas) Date: Tue, 21 Mar 2006 16:27:21 -0600 Subject: [PythonCAD] [ANNOUNCE] Thirtieth release of PythonCAD now available Message-ID: <20060321222721.GJ21646@artsapartment.org> Hi. I'm pleased to announce the thirtieth development release of PythonCAD, a CAD package for open-source software users. As the name implies, PythonCAD is written entirely in Python. The goal of this project is to create a fully scriptable drafting program that will match and eventually exceed features found in commercial CAD software. PythonCAD is released under the GNU Public License (GPL). PythonCAD requires Python 2.2 or newer. The interface is GTK 2.0 based, and uses the PyGTK module for interfacing to GTK. The design of PythonCAD is built around the idea of separating the interface from the back end as much as possible. By doing this, it is hoped that both GNOME and KDE interfaces can be added to PythonCAD through usage of the appropriate Python module. Addition of other PythonCAD interfaces will depend on the availability of a Python module for that particular interface and developer interest and action. The thirtieth PythonCAD release addresses a number of issues that appeared in the rewritten entity transfer code made available in the previous release. By once again rewriting the entity transfer code, the problems found in the last release have been fixed and additionally a number of latent problems for handling undo/redo operations on Dimension entities were addressed. In addition to the reworked entity transfer code, a number of internal code enhancements appear in this release. The use of the 'weakref' module has been eliminated, and a number of other bug fixes and improvements have been applied to the code. A mailing list for the development and use of PythonCAD is available. Visit the following page for information about subscribing and viewing the mailing list archive: http://mail.python.org/mailman/listinfo/pythoncad Visit the PythonCAD web site for more information about what PythonCAD does and aims to be: http://www.pythoncad.org/ Come and join me in developing PythonCAD into a world class drafting program! 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 From ahaas at airmail.net Wed Mar 22 17:29:37 2006 From: ahaas at airmail.net (Art Haas) Date: Wed, 22 Mar 2006 10:29:37 -0600 Subject: [PythonCAD] Goals for next release Message-ID: <20060322162937.GA15028@artsapartment.org> Hi. The short time between the twenth-ninth and thirtieth release was primarily caused by my need to find a new place to live. I'd wanted to work on updating the entity splitting code, but the undo/redo problems I found in the first reworking of the entity transfer code necessitated my time and effort on fixing those issues. The new transfer code fixed the problems I found, and as I wrote in the release announcement exposed a number of other problems for handling undo/redo operations on Dimensions, so the second rework was certainly worth it. My housing situation is still up in the air, and the next several weeks will be spent trying to get something resolved, so expect to see few changes appear on the repo. In addition to reworking the entity splitting code, I'll also start making the i18n changes in the code. Hopefully numerous people will send in the '.mo' files with translations. 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 fulvio at pc.jaring.my Wed Mar 22 11:51:02 2006 From: fulvio at pc.jaring.my (Fulvio) Date: Wed, 22 Mar 2006 18:51:02 +0800 Subject: [PythonCAD] [ANNOUNCE] Thirtieth release of PythonCAD now available In-Reply-To: <20060321222721.GJ21646@artsapartment.org> References: <20060321222721.GJ21646@artsapartment.org> Message-ID: <200603221851.03105.fulvio@pc.jaring.my> Alle 06:27, mercoled? 22 marzo 2006, Art Haas ha scritto: > I'm pleased to announce the thirtieth development release of PythonCAD, > a CAD package for open-source software users Thank you alot for your great job. I'd like to think if somebody would go into expand it to have the feature to manipulate Fidocad's files. Unfortunately the program sources exist only for win, I've tried to compiled for linux, but I'm not so skill for that. Hope some interest will grow :) From barbieri at gmail.com Thu Mar 30 22:03:26 2006 From: barbieri at gmail.com (Gustavo Sverzut Barbieri) Date: Thu, 30 Mar 2006 17:03:26 -0300 Subject: [PythonCAD] Port to Maemo/Nokia 770 Message-ID: <9ef20ef30603301203v35f69051y6484c518270bab2e@mail.gmail.com> Hello, I have a nokia 770 (http://nokia.com/770) and want to port PythonCAD to it. I'm not a CAD user, but I follow PythonCAD development because it's an interesting project and I have some friends from closed-source world that want to move to open alternatives. Why PythonCAD? My company, http://www.indt.org.br, is porting Python to maemo platform and I think that PythonCAD would be a great test program to it. It would also help engineers to have their drawings at hand while on field analysis. Limitations: - 770 is really low on performance and memory, it doesn't have a FPU and have low RAM available. - 770 has a great screen, 800x480, but it's high DPI, which make drawing on the device not a great thing. So I plan to disable most "edit" features, like undo steps and optimize to "view". Any feedback is welcome, but mainly on these areas: - How to improve startup times? I did put PythonCAD dir in a zipfile and used zipimport, it helps a bit, but need to make it faster... I want to know if some imports could be lazy imports. - How to improve viewing/zoom? - How to improve memory usage, the lower the better Thanks! -- Gustavo Sverzut Barbieri -------------------------------------- Jabber: barbieri at gmail.com MSN: barbieri at gmail.com ICQ#: 17249123 Skype: gsbarbieri Mobile: +55 (81) 9927 0010 Phone: +1 (347) 624 6296; 08122692 at sip.stanaphone.com GPG: 0xB640E1A2 @ wwwkeys.pgp.net From ahaas at airmail.net Fri Mar 31 20:56:02 2006 From: ahaas at airmail.net (Art Haas) Date: Fri, 31 Mar 2006 12:56:02 -0600 Subject: [PythonCAD] Port to Maemo/Nokia 770 In-Reply-To: <9ef20ef30603301203v35f69051y6484c518270bab2e@mail.gmail.com> References: <9ef20ef30603301203v35f69051y6484c518270bab2e@mail.gmail.com> Message-ID: <20060331185602.GH12502@artsapartment.org> On Thu, Mar 30, 2006 at 05:03:26PM -0300, Gustavo Sverzut Barbieri wrote: > Hello, > > I have a nokia 770 (http://nokia.com/770) and want to port PythonCAD to it. Neat! > I'm not a CAD user, but I follow PythonCAD development because it's an > interesting project and I have some friends from closed-source world > that want to move to open alternatives. > > Why PythonCAD? My company, http://www.indt.org.br, is porting Python > to maemo platform and I think that PythonCAD would be a great test > program to it. It would also help engineers to have their drawings at > hand while on field analysis. > > Limitations: > - 770 is really low on performance and memory, it doesn't have a FPU > and have low RAM available. > - 770 has a great screen, 800x480, but it's high DPI, which make > drawing on the device not a great thing. > > So I plan to disable most "edit" features, like undo steps and > optimize to "view". Elimination of undo/redo will help somewhat in reducing memory, and I'm certain that a number of other memory saving opportunities exist in the program. > Any feedback is welcome, but mainly on these areas: > - How to improve startup times? I did put PythonCAD dir in a zipfile > and used zipimport, it helps a bit, but need to make it faster... I > want to know if some imports could be lazy imports. My initial thoughts are that some sort of lazy 'import' calls will not work. If I had some patches that demonstrated how it could be done I would happily admit I was wrong. > - How to improve viewing/zoom? The current implementations are not great but they do work. I've wanted to improve viewing/zooming operations by replacing the 'GTKImage' class currently used for drawing display to other classes in the 'gtkshell.py' file. Last summer I'd started working towards this goal but I have not completed the coding unfortunately. > - How to improve memory usage, the lower the better Reducing memory will be difficult as PythonCAD is built on top of both Python, the PyGTK bindings, and GTK+. I don't have any immediate ideas other than working to ensure the code does not keep unnecessary references around on entities it no longer needs. Accomplishing this goal requires more eyes scanning through the code, or perhaps some clever Python coding that will flush out stray references. Let me know what I can do to help you make your porting easier. 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