pythoncad-developer Mailing List for PythonCAD (Page 15)
CAD Application entire developed in Python
Status: Beta
Brought to you by:
matteoboscolo
You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
(13) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(30) |
Feb
(65) |
Mar
(32) |
Apr
(42) |
May
(32) |
Jun
(18) |
Jul
(4) |
Aug
(30) |
Sep
(31) |
Oct
(28) |
Nov
(4) |
Dec
(40) |
2011 |
Jan
(18) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2012 |
Jan
(7) |
Feb
(3) |
Mar
|
Apr
(3) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <ger...@gm...> - 2010-02-04 21:39:45
|
Hi all, I did some thinking about the entity geometry. The current version maintains one point list where all entities make use of. I want to preserve this method because it has some advantages. But I want to change the way the entities use these points. The current version defines different geometries for each entity (segment, polyline, arc, etc.). I want to define only two different geometry objects that all entities can share. It consist of only points, no start-, end angles, center points or radius. Because there are only points in the geometry transformations can be done really quick, all points are multiplied by the same matrix. If needed the program must calculate the center point, radius and angles of circles and arcs. This is done far less often than entity drawing so this is more efficient. The main advantage is creating point lists for cairo drawing is more easy. All entities share the same geometry class, a single function is used to draw them all. It is more easy to optimize a single draw function for speed than all different functions for all entities. This excludes hatches of course which will have it own draw function. Some preliminary code: class Point(object): """ Indicates a single point with x and y ordinates (2D point) The interpretation indicates how the connection is drawn to the next point. With this construction linear and circular lines are constructed. These point objects are stored in a single table in the database. """ def __init__(self): # id of point self.__id = 0 # X ordinate self.__x = 0.0 # Y ordinate self.__y = 0.0 # interpretation connection to next point # L = linear # C = circular # None = not used (single point geometry) # more interpretation values needed for dimensions? self.__interpretation = 'L' class SGeometry(object): """ Indicates a single geometry. This is used in segment, polyline, arc, circle. examples: 1) A segment geometry consists of a list of two points. The point interpretation from the first to the second point is 'L' (linear) 2) An arc geometry consists of a list of three points. The first point is the start point of the arc, the second point is on the arc and the third point is the end point. The point interpretation from the first to the second point is 'C' (circular) The point interpretation from the second to the third point is 'C' (circular) 3) An polyline consists of a list of three or more points. The point interpretation can be 'L' (linear) or 'C' (circular) This gives the opportunity to create polylines with linear and arc segments. 4) An circle geometry consists of a list of five points. A circle is represented as two arcs where the first and fifth point are the same. The point interpretation from the first to the second point is 'C' (circular) The point interpretation from the second to the third point is 'C' (circular) For a single geometry the geometry interpretation is None. Interpretation is used for complex geometries. """ def __init__(self): # list of points ids self.__point_ids = [] # interpretation used in complex geometry # O = outer ring # I = inner ring # None = not used. self.__interpretation = None class CGeometry(object): """ Indicates a complex geometry. This is used in hatches. A hatch can contain islands. The list contains a outer ring and a inner ring (island). The rings are closed polylines (SGeometry objects). ??? Can inner rings contain other inner rings (nested islands) ??? """ def __init__(self): # list of single geometries. # order in the list is important, first a outer ring, than the inner rings self.__sgeometries = [] Even a text can have the same geometry as a segment (two points). The first point is the text location, the second point is the rotation. The distance between the first and second point is the text height. Regards, Gertwin |
From: <ger...@gm...> - 2010-02-04 06:55:40
|
Hi Yagnesh, That's all right, your skills will improve. We all can learn from each other. I saw Arts coding conventions just recently. It is good to have some unity in our code. Regards, Gertwin Op schreef Yagnesh Desai <yn...@gm...>: > Gretwin; > I know the coding done by me needs lot of touch up. > I need to improve my coding skills as this is the first time > I am doing any coding for such project. I only used to > do editing of recorded macros. > Also I am not good at OOP and whatever coding I did > was with good help of Matteo. > Hope to improve and learn more while contributing to > PythonCAD. > If the convention in old wiki is what can be followed > we must use it for there must not be any difference > in the way old and new one. > On Thu, Feb 4, 2010 at 2:07 AM, Gertwin Groen ger...@gm...> > wrote: > > Hi all, > > > > Now the we start working on the best PythonCAD ever it is time to > > think about some coding convention. > > In the old wiki this is mentioned but it is not followed by us in the > > last months. > > > > I think the easiest thing to do is to follow the PyGTK coding > conventions: > > > > example: > > > > class gtk.CellEditable(gobject.GInterface): > > def start_editing(event) > > def editing_done() > > def remove_widget() > > > > Lower case package, module (and file) names. > > Mixed upper and lower case for class names, each word starts with a > > capital letter. > > Functions and class members are lower case, words are divided by a > underscore. > > Variable names are lower case, words are divided by a underscore. > > > > See the pygtk-demo for examples. > > > > Any comments? > > > > Regards, > > Gertwin > > > > > ------------------------------------------------------------------------------ > > The Planet: dedicated and managed hosting, cloud storage, colocation > > Stay online with enterprise data centers and the best network in the > business > > Choose flexible plans and management services without long-term > contracts > > Personal 24x7 support from experience hosting pros just a phone call > away. > > http://p.sf.net/sfu/theplanet-com > > _______________________________________________ > > Pythoncad-developer mailing list > > Pyt...@li... > > https://lists.sourceforge.net/lists/listinfo/pythoncad-developer > > > -- > Best regards > Yagnesh Desai > Save a tree...please don't print this e-mail. > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Pythoncad-developer mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncad-developer |
From: Yagnesh D. <yn...@gm...> - 2010-02-04 06:07:36
|
Gretwin; I know the coding done by me needs lot of touch up. I need to improve my coding skills as this is the first time I am doing any coding for such project. I only used to do editing of recorded macros. Also I am not good at OOP and whatever coding I did was with good help of Matteo. Hope to improve and learn more while contributing to PythonCAD. If the convention in old wiki is what can be followed we must use it for there must not be any difference in the way old and new one. On Thu, Feb 4, 2010 at 2:07 AM, Gertwin Groen <ger...@gm...> wrote: > Hi all, > > Now the we start working on the best PythonCAD ever it is time to > think about some coding convention. > In the old wiki this is mentioned but it is not followed by us in the > last months. > > I think the easiest thing to do is to follow the PyGTK coding conventions: > > example: > > class gtk.CellEditable(gobject.GInterface): > def start_editing(event) > def editing_done() > def remove_widget() > > Lower case package, module (and file) names. > Mixed upper and lower case for class names, each word starts with a > capital letter. > Functions and class members are lower case, words are divided by a underscore. > Variable names are lower case, words are divided by a underscore. > > See the pygtk-demo for examples. > > Any comments? > > Regards, > Gertwin > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Pythoncad-developer mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncad-developer > -- Best regards Yagnesh Desai Save a tree...please don't print this e-mail. |
From: Yagnesh D. <yn...@gm...> - 2010-02-04 03:20:11
|
Yes Gertwin; OpwnGL & PyQT are kept only for future use (just to indicate the level at which any other GUI renderer might be sitting) GENERIC - Entities - Exchange - Tools - Core I think we can also look at interface. INTERFACE - GUI_Common - command - preference - menu - viewport - Cairo -"renderer specific modules" - GTK -"renderer specific modules" -Cocoa - "renderer specific modules" (any existing codes) - OpenGL - "renderer specific modules" (Future) - PyQT - "renderer specific modules" (Future) - - - - - - Best regards Yagnesh Desai Save a tree...please don't print this e-mail. > > > > > > Yes you are right about the Generic structure. And you are right about the Interface structure it also need some improvement. Is it right to say that the GUI_Common package contains no pygtk related/dependent code? Maybe put the Cairo on the same level as OpenGL? INTERFACE - GUI_Common - command - preference - menu - GTK -"renderer specific modules" - OpenGL - "viewport render specific modules" - Cairo - "viewport render specific modules" - PyQT - "render specific modules" The packages OpenGL and PyQt are ment for future use I think? Gertwin On Wed, Feb 3, 2010 at 2:05 AM, <ger...@gm...> wrote: > Hi All, > > For me the current package structure is not all satisfying. > The package "Generic" contain to much code with different purposes. > I would like to see modules that have some of a relationship with each other > in one package. > > My proposal to replace the package "Generic" by several other packages: > > * Entities. > * Exchange. > * Tools. > * Core. > > Tools have already been separated from the rest of Generic but is still to > large I think. > > Entities: > This package contain all entity definitions. > For instance the modules point, segment, circle, polyline, arc, etc. > > Exchange: > This package contain all the import and export to other formats (maybe split > exchange into import and export). > > Tools: > This package contain the entity creation and modification tools (maybe split > tools into create and modify). > > Core: > This package contain the interface to the database. > Quad tree tables, snap functionality etc. > > > Regards, > Gertwin > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Pythoncad-developer mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncad-developer > > |
From: Gertwin G. <ger...@gm...> - 2010-02-03 20:43:11
|
Hi all, Now the we start working on the best PythonCAD ever it is time to think about some coding convention. In the old wiki this is mentioned but it is not followed by us in the last months. I think the easiest thing to do is to follow the PyGTK coding conventions: example: class gtk.CellEditable(gobject.GInterface): def start_editing(event) def editing_done() def remove_widget() Lower case package, module (and file) names. Mixed upper and lower case for class names, each word starts with a capital letter. Functions and class members are lower case, words are divided by a underscore. Variable names are lower case, words are divided by a underscore. See the pygtk-demo for examples. Any comments? Regards, Gertwin |
From: Matteo B. <mat...@bo...> - 2010-02-03 13:24:27
|
For editing the wiki page you need to subscribe you as wiki user . After that you are able to modifie the pages .. Let me konu if you found any issue on this Regards Matteo |
From: Matteo B. <mat...@bo...> - 2010-02-03 08:30:55
|
Hi all, I think the some of Yagnesg, openGl is a big effort even if for pakege the program, I'm get some truble with py2exe and gtk on windows pc .. so i do not want to add more layer of pakege at the solution. We have spend a lot of time to migrate to cairo so now i want to go on with the develop ... We can work together to really understand witch is the best way to get the cairo work. There are a lot of picture program that use gtk and to manipulate the picture so we can do the some .. So for my point of view i prefer to go on with cairo and gtk. Regards Matteo Hi Gertwin; Thanks for your effort on identifying and issue with the performance in PythonCAD. My vote is for cairo + homebrew for near future, As the interface modules will be kept separate people should be able to add other renderer in case they need I have these reasons: 1. We are PYTHONCAD and so bringing in non python related modules is not very good idea. Also staying cross platform is MUST. Currently our packaging is having issues with installation on LINUX as well as Windows. 2. Having said that we will stay 2D and more complete then attempting a 3D. We can leave the 3D to other successful projects (like FreeCAD which is NOT completely in python). WE MUST DECIDE ON THIS BEFORE ADDING MUCH OF FURTHER EFFORTS, ALSO SHOULD GIVE PROVISION AT VARIOUS LEVELS IF WE GO FOR 3D. Infact we should also clearly say how different we are from QCAD, and focus our efforts to exploit the difference. 3. Real time PAN and ZOOM is is more like a wish then necessity (Well with Python people should not expect ALL the bells and whistles). 4. With OpenGL there is a learning curve for the team. As you had pointed out rightly, first issue with performance is in the GENERIC. Hence solving the issue of DOM should be our first priority. - - - - - - Best regards Yagnesh Desai Save a tree...please don't print this e-mail. On Wed, Feb 3, 2010 at 1:42 AM, <gertwin.groen@gm...> wrote: > Hi All, > > Starting a new thread about the renderer to choose. > For the user interface we have chosen pygtk but the renderer is still > unclear to me. > > A remainder from our emails: > > OpenGL: > Pros: > * very fast > * in case we want to go on 3d no change of the way we show the entity > > Cons: > * we need to learn how it works (personally i never use it) > * installation problem we need more pakage to make it works > * as gertwin say on mac we get some trouble. > > > Cairo + homebrew display list: > Pros: > * no need to change the way that we draw the entity > * it's no so slow if we build some smart algorithm > > Cons: > * No real time zooming and panning possible, only on small parts of the > drawing. > > > Personally I would like to use OpenGL, realtime zooming and panning is a > must have feature I think. > Op OSX the cairo 3 second redraw time for 100000 elements is too much for > such a feature. > On linux we can use the gtkglext but on OSX I have to take a different > approach. > > What are the opinions? > If OpenGL is a no go I will let it rest, otherwise I am going to test > gtk+opengl on OSX. > > Regards, > Gertwin |
From: Yagnesh D. <yn...@gm...> - 2010-02-03 06:29:05
|
Hi Gertwin; Thanks for your effort on identifying and issue with the performance in PythonCAD. My vote is for cairo + homebrew for near future, As the interface modules will be kept separate people should be able to add other renderer in case they need I have these reasons: 1. We are PYTHONCAD and so bringing in non python related modules is not very good idea. Also staying cross platform is MUST. Currently our packaging is having issues with installation on LINUX as well as Windows. 2. Having said that we will stay 2D and more complete then attempting a 3D. We can leave the 3D to other successful projects (like FreeCAD which is NOT completely in python). WE MUST DECIDE ON THIS BEFORE ADDING MUCH OF FURTHER EFFORTS, ALSO SHOULD GIVE PROVISION AT VARIOUS LEVELS IF WE GO FOR 3D. Infact we should also clearly say how different we are from QCAD, and focus our efforts to exploit the difference. 3. Real time PAN and ZOOM is is more like a wish then necessity (Well with Python people should not expect ALL the bells and whistles). 4. With OpenGL there is a learning curve for the team. As you had pointed out rightly, first issue with performance is in the GENERIC. Hence solving the issue of DOM should be our first priority. - - - - - - Best regards Yagnesh Desai Save a tree...please don't print this e-mail. On Wed, Feb 3, 2010 at 1:42 AM, <ger...@gm...> wrote: > Hi All, > > Starting a new thread about the renderer to choose. > For the user interface we have chosen pygtk but the renderer is still > unclear to me. > > A remainder from our emails: > > OpenGL: > Pros: > * very fast > * in case we want to go on 3d no change of the way we show the entity > > Cons: > * we need to learn how it works (personally i never use it) > * installation problem we need more pakage to make it works > * as gertwin say on mac we get some trouble. > > > Cairo + homebrew display list: > Pros: > * no need to change the way that we draw the entity > * it's no so slow if we build some smart algorithm > > Cons: > * No real time zooming and panning possible, only on small parts of the > drawing. > > > Personally I would like to use OpenGL, realtime zooming and panning is a > must have feature I think. > Op OSX the cairo 3 second redraw time for 100000 elements is too much for > such a feature. > On linux we can use the gtkglext but on OSX I have to take a different > approach. > > What are the opinions? > If OpenGL is a no go I will let it rest, otherwise I am going to test > gtk+opengl on OSX. > > Regards, > Gertwin > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the > business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Pythoncad-developer mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncad-developer > > |
From: <ger...@gm...> - 2010-02-02 20:35:20
|
Hi All, For me the current package structure is not all satisfying. The package "Generic" contain to much code with different purposes. I would like to see modules that have some of a relationship with each other in one package. My proposal to replace the package "Generic" by several other packages: * Entities. * Exchange. * Tools. * Core. Tools have already been separated from the rest of Generic but is still to large I think. Entities: This package contain all entity definitions. For instance the modules point, segment, circle, polyline, arc, etc. Exchange: This package contain all the import and export to other formats (maybe split exchange into import and export). Tools: This package contain the entity creation and modification tools (maybe split tools into create and modify). Core: This package contain the interface to the database. Quad tree tables, snap functionality etc. Regards, Gertwin |
From: <ger...@gm...> - 2010-02-02 20:12:23
|
Hi All, Starting a new thread about the renderer to choose. For the user interface we have chosen pygtk but the renderer is still unclear to me. A remainder from our emails: OpenGL: Pros: * very fast * in case we want to go on 3d no change of the way we show the entity Cons: * we need to learn how it works (personally i never use it) * installation problem we need more pakage to make it works * as gertwin say on mac we get some trouble. Cairo + homebrew display list: Pros: * no need to change the way that we draw the entity * it's no so slow if we build some smart algorithm Cons: * No real time zooming and panning possible, only on small parts of the drawing. Personally I would like to use OpenGL, realtime zooming and panning is a must have feature I think. Op OSX the cairo 3 second redraw time for 100000 elements is too much for such a feature. On linux we can use the gtkglext but on OSX I have to take a different approach. What are the opinions? If OpenGL is a no go I will let it rest, otherwise I am going to test gtk+opengl on OSX. Regards, Gertwin |
From: <eu...@li...> - 2010-02-02 10:03:49
|
we have found an issue on the setup program .. please do not install it since we will fix the problems Thanks Matteo >----Messaggio originale---- >Da: eu...@li... >Data: 01/02/2010 15.59 >A: "cad...@fr..."<cad...@fr...>, "cad- li...@fr..."<cad...@fr...>, "pythoncad-developer@lists. sourceforge.net"<pyt...@li...>, "pythoncad@python. org"<pyt...@py...> >Ogg: [PythonCAD] Pythoncad : New Setup.exe file for windows installation > >Hi All, > >It's now avaiable from sourceforge.net the new installation package for >windows users. > >This is a normal windows setup and you don't need to install gtk and python. > >Let me know for any issue. > >Regards >Matteo > > > >_______________________________________________ >PythonCAD mailing list >Pyt...@py... >http://mail.python.org/mailman/listinfo/pythoncad > |
From: Yagnesh D. <yn...@gm...> - 2010-02-02 08:56:48
|
Matteo; It would be gr8 to have Jose to administer the wiki. Do check if you can extend the related rights to him. 2010/2/2 José Antonio Martín Prieto <jan...@gm...>: > Hi Yagnesh, > I think this is a good idea. In fact, I was thinking about asking Matteo how > to do it. > Hosting the wiki in sourceforge would have at least two advantages: > - 24/7 availability. I can't ensure this at home. > - A more appropriate url. > > Maybe I can pack the source files and send them to Matteo, or if he gives me > access to the sourceforge wiki administration I can migrate the files myself > in a few days. > > By the way, does the sourceforge wiki support different languages or > namespaces? > > Regards, > José Antonio > > > 2010/2/2 Yagnesh Desai <yn...@gm...> >> >> Dear Matteo; >> >> Mr José Antonio Martín Prieto had helped us create the >> wiki and hosted it on server at his home. >> >> It is a dokuwiki (ie a flat file php wiki) and as you can >> see it has become rich because of contributions. >> >> We can request him to provide the native files so >> that we can host it on the sourceforge. >> >> - - - >> Best regards >> >> Yagnesh Desai >> Save a tree...please don't print this e-mail. >> >> >> >> >> >> On Tue, Feb 2, 2010 at 11:54 AM, Matteo Boscolo >> <mat...@bo...> wrote: >> > We do not know how long the wiki site will work... >> > It's under a private server and we do not know how long can host our >> > project. >> > Best think will be to move the wiki page on sourceforge and write the >> > use case there.. >> > >> > What do you think ? >> > >> > Regards, >> > Matteo >> > >> > > > > > -- > "In a world without frontiers, who needs Gates and Windows? > -- Best regards Yagnesh Desai Save a tree...please don't print this e-mail. |
From: José A. M. P. <jan...@gm...> - 2010-02-02 07:32:03
|
Hi Yagnesh, I think this is a good idea. In fact, I was thinking about asking Matteo how to do it. Hosting the wiki in sourceforge would have at least two advantages: - 24/7 availability. I can't ensure this at home. - A more appropriate url. Maybe I can pack the source files and send them to Matteo, or if he gives me access to the sourceforge wiki administration I can migrate the files myself in a few days. By the way, does the sourceforge wiki support different languages or namespaces? Regards, José Antonio 2010/2/2 Yagnesh Desai <yn...@gm...> > Dear Matteo; > > Mr José Antonio Martín Prieto had helped us create the > wiki and hosted it on server at his home. > > It is a dokuwiki (ie a flat file php wiki) and as you can > see it has become rich because of contributions. > > We can request him to provide the native files so > that we can host it on the sourceforge. > > - - - > Best regards > > Yagnesh Desai > Save a tree...please don't print this e-mail. > > > > > > On Tue, Feb 2, 2010 at 11:54 AM, Matteo Boscolo > <mat...@bo...> wrote: > > We do not know how long the wiki site will work... > > It's under a private server and we do not know how long can host our > > project. > > Best think will be to move the wiki page on sourceforge and write the > > use case there.. > > > > What do you think ? > > > > Regards, > > Matteo > > > > > -- "In a world without frontiers, who needs Gates and Windows? |
From: Yagnesh D. <yn...@gm...> - 2010-02-02 07:12:36
|
Yes Matteo; Use case on wiki will help as many users can contribute using GIT is not very easy for every user. - - - - - Best regards Yagnesh Desai Save a tree...please don't print this e-mail. On Tue, Feb 2, 2010 at 12:06 PM, Matteo Boscolo <mat...@bo...> wrote: > I have added the media wiki at surcefoge web site > > Regards > Matteo > > > |
From: Yagnesh D. <yn...@gm...> - 2010-02-02 07:08:28
|
Dear Matteo; Mr José Antonio Martín Prieto had helped us create the wiki and hosted it on server at his home. It is a dokuwiki (ie a flat file php wiki) and as you can see it has become rich because of contributions. We can request him to provide the native files so that we can host it on the sourceforge. - - - Best regards Yagnesh Desai Save a tree...please don't print this e-mail. On Tue, Feb 2, 2010 at 11:54 AM, Matteo Boscolo <mat...@bo...> wrote: > We do not know how long the wiki site will work... > It's under a private server and we do not know how long can host our > project. > Best think will be to move the wiki page on sourceforge and write the > use case there.. > > What do you think ? > > Regards, > Matteo > > |
From: Yagnesh D. <yn...@gm...> - 2010-02-02 06:51:33
|
Hi Matteo; Traceback (most recent call last): File "gtkpycad.py", line 281, in <module> File "gtkpycad.py", line 259, in main File "PythonCAD\Interface\Gtk\gtkimage.pyc", line 157, in __init__ glib.GError: Failed to open file 'gtkpycad.png': No such file or directory Traceback (most recent call last): File "gtkpycad.py", line 32, in <module> File "gtk\__init__.pyc", line 40, in <module> File "gtk\_gtk.pyc", line 12, in <module> File "gtk\_gtk.pyc", line 10, in __load ImportError: DLL load failed: The specified procedure could not be found. |
From: Yagnesh D. <yn...@gm...> - 2010-02-02 06:47:50
|
Hi Matteo; That's gr8 But the current wiki hosted is a dokuwiki and we might face problem transferring the complete wiki from the current host to media wiki -- Best regards Yagnesh Desai Save a tree...please don't print this e-mail. On Tue, Feb 2, 2010 at 12:06 PM, Matteo Boscolo <mat...@bo...> wrote: > I have added the media wiki at surcefoge web site > > Regards > Matteo > > > |
From: Matteo B. <mat...@bo...> - 2010-02-02 06:36:44
|
I have added the media wiki at surcefoge web site Regards Matteo |
From: Matteo B. <mat...@bo...> - 2010-02-02 06:24:18
|
We do not know how long the wiki site will work... It's under a private server and we do not know how long can host our project. Best think will be to move the wiki page on sourceforge and write the use case there.. What do you think ? Regards, Matteo On Tue, 2010-02-02 at 07:15 +0530, Yagnesh Desai wrote: > Why do we need to create such documents > we can use issue tracker or wiki which has better > visibility and control. > > On Tue, Feb 2, 2010 at 4:41 AM, Gertwin Groen <ger...@gm...> wrote: > > Hi All, > > > > I have made a start with the use cases. > > I have put them in the repository: "R38/pythoncad/Doc/use cases" > > > > The document "use cases.odt" contain a list of use cases, for each use > > case there is one file. > > I made a start with the use case "share point.odt", take a look at it. > > If you have remarks, add them to the document. > > > > If you mis a use case list it in "use cases.odt" and create a new > > skeleton "new use case.odt" document. > > > > We should describe all the actions etc. that the user can do in PythonCAD. > > Please assist me to write the use cases, use many pictures for new > > dialogs (glade mock-ups or made with the gimp, doesn't care). > > > > This way we can create a consistent user interface and forces us to > > think about the implementation. > > Also this can act as an input for the user manual. > > We can assign use cases to each other and to new developers. > > > > Regards, > > Gertwin > > > > > > > > > > 2010/2/1 Matteo Boscolo <mat...@bo...>: > >> Hi all, > >> > >> I think that implementing pyGui take a lot of time, and the code command are not the some of gtk. > >> I do not make any deep analysis but it seems to me that we are going to make a lot of work to migrate in pygui. > >> Even if the installation require 2 setup in windows pygui and pywin32 (ok may be the installation is easier the pygtk but for common windows user will be difficult).I do not test pygui but it seems that not a lot of people are using it. > >> And with pygui you are using a more layer of code ..(Bad performance) > >> May be it will be a good choice if we start from zero ... > >> For my point of view the best choice is to stay on gtk and became more skilled to deploy installer package that are very easy to use for windows user add mac user. > >> Have a look at https://sourceforge.net/projects/py2exe/ this package is able to create an a single axe file starting from a python script. > >> I will make some test if it works for pythoncad and let you know. > >> > >> > >> Regards, > >> Matteo > >> > >> > >> -----Original Message----- > >> From: Yagnesh Desai [mailto:yn...@gm...] > >> Sent: 01 February 2010 06:20 > >> To: ger...@gm... > >> Cc: Matteo Boscolo > >> Subject: Re: Re: Test on new canvas render > >> > >> Front End related > >> > >> 1. I feel PYGUI is gr8 as it seems more native [and above all its PYTHON] > >> > >> 2. opengl may be very fast but needs more non python codes to > >> integrate, we are 2D CAD > >> and need to attract more CAD engineers than Programmers. We will leave > >> 3D for FreeCAD and > >> other existant projects. > >> > >> 3. GTK we may stick to it till next 1 or 2 release, by the time new > >> solution is available. > >> > >> > >>>>> > >> My additions to the decision list: > >> > >> > >> opengl: > >> good think: > >> very fast > >> in case we want to go on 3d no change of the way we show the entity > >> bad think: > >> > >> we need to learn how it works (personally i never use it) > >> installation problem we need more pakage to make it works > >> as gertwin say on mac we get some trouble (see remark). > >> > >> Remark: > >> 1) We can use the PyGui library, no additional install needed. > >> 2) Or we can create a separate OpenGL window which is not embedded in > >> the application. > >> Pros: > >> Usable on all platforms, view is not dependent on a toolkit. > >> We can define multiple views in which the user can work on different > >> parts of the drawing (like the old MicroStation V4). > >> Multiple screens can be effectively used by multiple graphical views. > >> cons: > >> Looks a little old fashioned, see some thing like: > >> http://geuz.org/gmsh/gallery/screenshot.png > >> > >> > >> > >> gtk with displaylist: > >> good think: > >> no need to change the way that we draw the entity > >> it's no so slow if we build some smart algorithm > >> bad think: > >> > >> at the moment no bad think in mind > >> No real time zooming and panning possible, only on small parts of the drawing. > >> > >> > > > > > > -- > Best regards > > Yagnesh Desai > > Save a tree...please don't print this e-mail. > |
From: Yagnesh D. <yn...@gm...> - 2010-02-02 02:52:25
|
Thanks a lot Matteo; Let us monitor if we have any increase in weekly downloads which is currently between 100 and 160. I will surly test and revert. -- Best regards Yagnesh Desai Save a tree...please don't print this e-mail. On Mon, Feb 1, 2010 at 8:29 PM, eu...@li... <eu...@li...> wrote: > Hi All, > > It's now avaiable from sourceforge.net the new installation package for > windows users. > > This is a normal windows setup and you don't need to install gtk and python. > > Let me know for any issue. > > Regards > Matteo > > > > > ------------------------------------------------------------------------------ > The Planet: dedicated and managed hosting, cloud storage, colocation > Stay online with enterprise data centers and the best network in the business > Choose flexible plans and management services without long-term contracts > Personal 24x7 support from experience hosting pros just a phone call away. > http://p.sf.net/sfu/theplanet-com > _______________________________________________ > Pythoncad-developer mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/pythoncad-developer > |
From: Yagnesh D. <yn...@gm...> - 2010-02-02 02:49:43
|
Why do we need to create such documents we can use issue tracker or wiki which has better visibility and control. On Tue, Feb 2, 2010 at 4:41 AM, Gertwin Groen <ger...@gm...> wrote: > Hi All, > > I have made a start with the use cases. > I have put them in the repository: "R38/pythoncad/Doc/use cases" > > The document "use cases.odt" contain a list of use cases, for each use > case there is one file. > I made a start with the use case "share point.odt", take a look at it. > If you have remarks, add them to the document. > > If you mis a use case list it in "use cases.odt" and create a new > skeleton "new use case.odt" document. > > We should describe all the actions etc. that the user can do in PythonCAD. > Please assist me to write the use cases, use many pictures for new > dialogs (glade mock-ups or made with the gimp, doesn't care). > > This way we can create a consistent user interface and forces us to > think about the implementation. > Also this can act as an input for the user manual. > We can assign use cases to each other and to new developers. > > Regards, > Gertwin > > > > > 2010/2/1 Matteo Boscolo <mat...@bo...>: >> Hi all, >> >> I think that implementing pyGui take a lot of time, and the code command are not the some of gtk. >> I do not make any deep analysis but it seems to me that we are going to make a lot of work to migrate in pygui. >> Even if the installation require 2 setup in windows pygui and pywin32 (ok may be the installation is easier the pygtk but for common windows user will be difficult).I do not test pygui but it seems that not a lot of people are using it. >> And with pygui you are using a more layer of code ..(Bad performance) >> May be it will be a good choice if we start from zero ... >> For my point of view the best choice is to stay on gtk and became more skilled to deploy installer package that are very easy to use for windows user add mac user. >> Have a look at https://sourceforge.net/projects/py2exe/ this package is able to create an a single axe file starting from a python script. >> I will make some test if it works for pythoncad and let you know. >> >> >> Regards, >> Matteo >> >> >> -----Original Message----- >> From: Yagnesh Desai [mailto:yn...@gm...] >> Sent: 01 February 2010 06:20 >> To: ger...@gm... >> Cc: Matteo Boscolo >> Subject: Re: Re: Test on new canvas render >> >> Front End related >> >> 1. I feel PYGUI is gr8 as it seems more native [and above all its PYTHON] >> >> 2. opengl may be very fast but needs more non python codes to >> integrate, we are 2D CAD >> and need to attract more CAD engineers than Programmers. We will leave >> 3D for FreeCAD and >> other existant projects. >> >> 3. GTK we may stick to it till next 1 or 2 release, by the time new >> solution is available. >> >> >>>>> >> My additions to the decision list: >> >> >> opengl: >> good think: >> very fast >> in case we want to go on 3d no change of the way we show the entity >> bad think: >> >> we need to learn how it works (personally i never use it) >> installation problem we need more pakage to make it works >> as gertwin say on mac we get some trouble (see remark). >> >> Remark: >> 1) We can use the PyGui library, no additional install needed. >> 2) Or we can create a separate OpenGL window which is not embedded in >> the application. >> Pros: >> Usable on all platforms, view is not dependent on a toolkit. >> We can define multiple views in which the user can work on different >> parts of the drawing (like the old MicroStation V4). >> Multiple screens can be effectively used by multiple graphical views. >> cons: >> Looks a little old fashioned, see some thing like: >> http://geuz.org/gmsh/gallery/screenshot.png >> >> >> >> gtk with displaylist: >> good think: >> no need to change the way that we draw the entity >> it's no so slow if we build some smart algorithm >> bad think: >> >> at the moment no bad think in mind >> No real time zooming and panning possible, only on small parts of the drawing. >> >> > -- Best regards Yagnesh Desai Save a tree...please don't print this e-mail. |
From: <eu...@li...> - 2010-02-01 15:00:13
|
Hi All, It's now avaiable from sourceforge.net the new installation package for windows users. This is a normal windows setup and you don't need to install gtk and python. Let me know for any issue. Regards Matteo |
From: <eu...@li...> - 2010-01-19 12:35:52
|
Hi Yagnesh, I'm dirtectly in contact with the people that mantain the pythoncad pakage in debian/ubuntu. For any future request we can directly email to this people Regards Matteo ----Messaggio originale---- Da: yn...@gm... Data: 19/01/2010 12.46 A: <Pyt...@py...> Cc: <pyt...@li...> Ogg: Re: [PythonCAD] URGENT: Pythoncad's new home at Sourceforge needs gr8 attention. In ubuntu R37 is available in "Lucid"I have registered a request to backport it tothe LTS versions.http://packages.ubuntu.com/search?keywords=pythoncad&searchon=names&suite=lucid&section=all On Tue, Jan 19, 2010 at 3:43 PM, eu...@li... <eu...@li...> wrote: Hi Yagnesh, As soon i have time i will do the setup for the windows installation. Actually R37 is present on the testing/unstable repository on debian and ubunt(I have not check ) as you can see in the wiki page: http: //morgul.no-ip.com/dokuwiki/doku.php?id=installation for other linux installation McOs we have to use the source pakage .. Regards, Matteo >---- Messaggio originale---- >Da: yn...@gm... >Data: 19/01/2010 9.12 >A: <pyt...@li...>, <Pyt...@py...> >Ogg: Re: [PythonCAD] URGENT: Pythoncad&#39;s new home at Sourceforge needs gr8 attention. > >Dear Matteo; > >Thanks for the prompt action. > >In install instruction we must also say >that till we have beta release one can >start pythoncad by just doing > >$ python gtkpycad.py > >in the relevant directory. Also in ubuntu I find that >R35 is only available >_______________________________________________ >PythonCAD mailing list >Pyt...@py... >http://mail.python.org/mailman/listinfo/pythoncad > -- Best regardsYagnesh DesaiSave a tree...please don't print this e-mail. |
From: Yagnesh D. <yn...@gm...> - 2010-01-19 11:46:28
|
In ubuntu R37 is available in "Lucid" I have registered a request to backport it to the LTS versions. http://packages.ubuntu.com/search?keywords=pythoncad&searchon=names&suite=lucid§ion=all On Tue, Jan 19, 2010 at 3:43 PM, eu...@li... <eu...@li...>wrote: > > Hi Yagnesh, > > As soon i have time i will do the setup for the windows > installation. > > Actually R37 is present on the testing/unstable repository on > debian and ubunt(I have not check ) as you can see in the wiki page: > http: > //morgul.no-ip.com/dokuwiki/doku.php?id=installation > > for other linux > installation McOs we have to use the source pakage .. > > > Regards, > Matteo > > >---- > Messaggio originale---- > >Da: yn...@gm... > >Data: 19/01/2010 9.12 > >A: > <pyt...@li...>, <Pyt...@py...> > >Ogg: Re: > [PythonCAD] URGENT: Pythoncad's new home at Sourceforge needs gr8 > attention. > > > >Dear Matteo; > > > >Thanks for the prompt action. > > > >In install > instruction we must also say > >that till we have beta release one can > >start > pythoncad by just doing > > > >$ python gtkpycad.py > > > >in the relevant directory. > Also in ubuntu I find that > >R35 is only available > > >_______________________________________________ > >PythonCAD mailing list > > >Pyt...@py... > >http://mail.python.org/mailman/listinfo/pythoncad > > > > > -- Best regards Yagnesh Desai Save a tree...please don't print this e-mail. |
From: <eu...@li...> - 2010-01-19 10:13:46
|
Hi Yagnesh, As soon i have time i will do the setup for the windows installation. Actually R37 is present on the testing/unstable repository on debian and ubunt(I have not check ) as you can see in the wiki page: http: //morgul.no-ip.com/dokuwiki/doku.php?id=installation for other linux installation McOs we have to use the source pakage .. Regards, Matteo >---- Messaggio originale---- >Da: yn...@gm... >Data: 19/01/2010 9.12 >A: <pyt...@li...>, <Pyt...@py...> >Ogg: Re: [PythonCAD] URGENT: Pythoncad's new home at Sourceforge needs gr8 attention. > >Dear Matteo; > >Thanks for the prompt action. > >In install instruction we must also say >that till we have beta release one can >start pythoncad by just doing > >$ python gtkpycad.py > >in the relevant directory. Also in ubuntu I find that >R35 is only available >_______________________________________________ >PythonCAD mailing list >Pyt...@py... >http://mail.python.org/mailman/listinfo/pythoncad > |