pythoncad-developer — Developer Mailing List

[Pythoncad-developer] Pushed many changes to the R38 branch

[<ger...@gm...>]

Hello,

I just pushed many changed into the R38 repository.

This means the old drawing methods are mostly replaced by the new cairo  
ones.
All draw functions (entity draw and rubberbanding and future selection  
draw) are now in the <entity>draw.py modules.

Not all entity draw functions are replaced by new ones, I will convert them  
one by one the next days.
There are issues with drawings when a very large part of the entity is off  
screen (maybe need some clipping).
There are issues with rubberbanding which can be slow at some times (after  
dynamic zoom with mouse wheel while drawing).
Mouse wheel zoom is pointer position sensitive, zooming is done around the  
mouse pointer and not screen center.

At this stage the cairo drawing should give a good indication of the  
performance which can be achieved.
I have not done any optimizations but I don't think it will be more than  
1.5x faster as it is now.
At least the panning is faster now (but after pan a redraw it needed which  
can be slow for large drawings).
Also each dynamic zoom with the wheel mouse button requires a redraw.
When zoomed into a small part of the drawing less entities are drawn than  
redraw is faster, whole drawing redraw is still slow.

Please look at the drawing performance and share your feelings (is it fast  
enough, does it need changes).
I think for really good performance you need display lists as used in  
opengl.

Regards,
Gertwin

[Pythoncad-developer] Adverse comment in Ratings and Reviews

[Gertwin G. <ger...@gm...>]

Hi Yagnesh and others,

First I think while PythonCAD is alpha or beta don't install files
outside the users home directory.
Even if someone want to try a alpha or beta stage application it don't
want it to install files on its computer which he thinks may can do
harm to its computer.

I think when pythoncad is in alpha or beta stage no installation
should be necessary.
Just unpack the PythonCAD-DS1-R37.tar.gz and start a file from the bin
directory (which is provided in the .tar.gz).
The file from the bin directory adjust the necessary paths and starts
the application by executing the pythoncad.py file.

If there is an PythonCAD update the user can just delete the old one
and unpack the new one.

For osx (starting from R38) I will put all the dependencies in the
.tar.gz file (even libgtk and pygtk and maybe python) so no additional
installation is needed.
In that way I provide the same environment in which I tested PythonCAD
to the user, no differences in libgtk, python or 32/64 bits versions
versions.

Regards,
Gertwin

[Pythoncad-developer] Adverse comment in Ratings and Reviews

[Yagnesh D. <yn...@gm...>]

Friends;

There is a food for thought for all of us. Thumbs down comment does
have some truth in it.

QUOTE:
#   Thumbs down

your packaging is completely fucked up ( extacting to
/usr/lib/python2.5/site-packages/ ?! .pyc files?!) and there is not
even a hint as to how to start the thing, let alone any sort of
documentation. Here's a clue: YouTube videos of the fillet (more…)
your packaging is completely fucked up ( extacting to
/usr/lib/python2.5/site-packages/ ?! .pyc files?!) and there is not
even a hint as to how to start the thing, let alone any sort of
documentation. Here's a clue: YouTube videos of the fillet command
don't do a damn thing if there's no way to launch the program. Would a
README file kill you? It seems like you took over an alpha, but usable
project and turned it into an amateur hour trainwreck that only you
understand.
:UNQUOTE

As a first timer I also had faced some difficulties installing PythonCAD.
Few things that I can make out is

1. README file do not tell any thing on how to install.
     - Let us put one line under readme file which tells about refer
INSTALL file to do installation.
     - Do we need to run setup.py ? What I do is just download the R38
dir and run gtkpycad.py to run pythoncad.
     - Also we use gtkpycad.py  can it not be named pythoncad.py to
look more obvious for first timer.

2. On documentation front :
     - Can we transfer our wiki
(http://morgul.no-ip.com/dokuwiki/doku.php) to
http://pythoncad.sourceforge.net/ there seems a way to host a dokuwiki
on this home page.
     - If not we can put links pythoncad.org and
http://morgul.no-ip.com/dokuwiki/doku.php on
http://pythoncad.sourceforge.net.

3. Youtube is what this user seems to have seen and which have brought
him to our project. So we can check
if we can publish the how to install video on Youtube.

4. I still have my wish of install_pythoncad.msi unfulfilled.

Since more and more people will visit this project once we are on
sourceforge we need to improve our
first impression.

Cheers
Yagnesh Desai

[Pythoncad-developer] subscribe

[Yagnesh D. <yn...@gm...>]

I will be using this email id for pythoncad
hence forth.

-- 
Best regards

Yagnesh Desai

Save a tree...please don't print this e-mail
as it will never be deleted from "GMAIL"

[Pythoncad-developer] PythonCAD performance

[Gertwin G. <ger...@gm...>]

Hello developers,

I did a quick performance measurement on PythonCAD.

I imported the "8th floor furniture.dxf" (4.4 mb) file in PythonCAD
and saved it as "8th floor furniture.xml.gz" (0.85 mb).

The performance measurements are done with the "8th floor
furniture.xml.gz" file on a quad core 64 bits linux box with 4Gb
memory.
I think a 0.85 mb drawing is rather small than big.
I consider drawings ten times that size as big.

Before loading PythonCAD in memory 332 mb is used.
After loading PythonCAD in memory 348 mb is used (that is OK).

Opening the "8th floor furniture.xml.gz" takes about 1:30 min and
costs about 960 mb of memory (PythonCAD + drawing = 1316 mb).
(I think this is a very huge memory consumption)

The time to redraw the drawing on screen is around 4 seconds, that is
not to bad.

Closing the drawing cost a lot of time, around 9:40 minutes.
After closing the drawing still 1316 mb memory is used but maybe no
garbage collection was done at that moment.

I tested this with the old and new drawing functions, there are no
significant differences between the two.

I think the time to open the drawing is to long, maybe half the
loading time is good.
Closing the drawing takes way to long, I think it is OK when it takes
the same amount of time as loading.
Memory consumption is to high.

What do you all think about this?
Do you experience the same issues?

I can investigate this after I finished the new viewport drawing.

Regards,
Gertwin

[Pythoncad-developer] Merry Christmas ---

[Matteo B. <mat...@bo...>]

Hi all,

I Wish you a very nice Christmas and Happy New Years.

Hope to see you soon on this list

Matteo
  

Re: [Pythoncad-developer] [PythonCAD] Collada format in Python

[Matteo B. <mat...@bo...>]

Hi All,

Collada File format seems interesting even if in the future when we well
work side by side with a 3d program ... (if we well find one )

Do not forget that our file is an xml file (clear text ) so anyone can
read it ..

so we can add this as a Traker wish ... but i hope we focus our
attention on the actual open traker ;-)

Regards,
Matteo 



On Sun, 2009-12-20 at 14:12 -0800, Glenn Meader wrote:
> I agree that Collada file format does not look very useful for a 2D
> CAD program such as PythonCAD.
>  
> There are however several Pythom libraries available to work with
> Collada files.
> Just Google: Python Collada
> 
> 
> ______________________________________________________________________
> From: pythoncad-bounces+glenn=chr...@py...
> [mailto:pythoncad-bounces+glenn=chr...@py...] On
> Behalf Of ger...@gm...
> Sent: Sunday, December 20, 2009 1:44 PM
> To: Yagnesh Desai
> Cc: pyt...@py...; pyt...@li...
> Subject: Re: [PythonCAD] Collada format (xml based 3D data transfer)
> 
> 
> 
> Hi Yangnesh,
> 
> Did you look at the schema?
> The collada schema only supports a subset of the geometric entities
> PythonCAD support.
> I PythonCAD was a full 3D CAD program you had a point but I don't see
> the use for a 2D CAD program.
> You can never make PythonCAD read or write a collada file without
> significant loss of data.
> 
> I think this is not in line with the original principles of PythonCAD:
> * a 2D CAD program
> * fully programmed in python.
> 
> Are there any common file formats for 2D CAD files besides dxf?
> 
> Regards,
> Gertwin
> 
> 
> On Dec 20, 2009 6:09pm, Yagnesh Desai <yn...@ln...> wrote:
> > 
> > 
> > Friends;
> > 
> > 
> > 
> > Pythoncad uses xml based format to save the file
> > 
> > now this is Non-Standard format (ie not based on
> > 
> > any of the published standard) and cannot
> > 
> > be opened by any other softwares.
> > 
> > 
> > 
> > I came across this Collada format
> > 
> > http://en.wikipedia.org/wiki/COLLADA
> > 
> > while looking at Google Sketchup.
> > 
> > (There must be something in this format
> > 
> > as google sketchup is supporting it out of box . . !)
> > 
> > 
> > 
> > If we migrate to (or support) something like such
> > 
> > a format we might make pythoncad more utilizable.
> > 
> > 
> > 
> > There are host of softwares supporting this format.
> > 
> > 
> > 
> > Regards
> > 
> > 
> > 
> > Yagnesh Desai
> > 
> > Save a tree : Think before printing this email.
> > 
> > Disclaimer :This email and any files transmitted with it are
> intended solely for the use of the addressee(s) only and may contain
> confidential and/or privileged information. If you are not the
> addressee, then this message is not intended for you and be advised
> that you have received this email in error and that any use ,
> dissemination , forwarding, printing or copying of this email is
> strictly prohibited. In such case please notify the sender and delete
> this email and any attachments with it from your system
> immediately.Receipt of this email by you shall not give rise to any
> liability on the part of Larsen & Toubro Limited 
> >

Re: [Pythoncad-developer] [PythonCAD] Collada format in Python

[Glenn M. <gl...@ch...>]

I agree that Collada file format does not look very useful for a 2D CAD
program such as PythonCAD.
 
There are however several Pythom libraries available to work with Collada
files.
Just Google: Python Collada

  _____  

From: pythoncad-bounces+glenn=chr...@py...
[mailto:pythoncad-bounces+glenn=chr...@py...] On Behalf Of
ger...@gm...
Sent: Sunday, December 20, 2009 1:44 PM
To: Yagnesh Desai
Cc: pyt...@py...; pyt...@li...
Subject: Re: [PythonCAD] Collada format (xml based 3D data transfer)


Hi Yangnesh,

Did you look at the schema?
The collada schema only supports a subset of the geometric entities
PythonCAD support.
I PythonCAD was a full 3D CAD program you had a point but I don't see the
use for a 2D CAD program.
You can never make PythonCAD read or write a collada file without
significant loss of data.

I think this is not in line with the original principles of PythonCAD:
* a 2D CAD program
* fully programmed in python.

Are there any common file formats for 2D CAD files besides dxf?

Regards,
Gertwin


On Dec 20, 2009 6:09pm, Yagnesh Desai <yn...@ln...> wrote:
> 
> 
> Friends;
> 
> 
> 
> Pythoncad uses xml based format to save the file
> 
> now this is Non-Standard format (ie not based on
> 
> any of the published standard) and cannot
> 
> be opened by any other softwares.
> 
> 
> 
> I came across this Collada format
> 
> http://en.wikipedia.org/wiki/COLLADA
> 
> while looking at Google Sketchup.
> 
> (There must be something in this format
> 
> as google sketchup is supporting it out of box . . !)
> 
> 
> 
> If we migrate to (or support) something like such
> 
> a format we might make pythoncad more utilizable.
> 
> 
> 
> There are host of softwares supporting this format.
> 
> 
> 
> Regards
> 
> 
> 
> Yagnesh Desai
> 
> Save a tree : Think before printing this email.
> 
> Disclaimer :This email and any files transmitted with it are intended
solely for the use of the addressee(s) only and may contain confidential
and/or privileged information. If you are not the addressee, then this
message is not intended for you and be advised that you have received this
email in error and that any use , dissemination , forwarding, printing or
copying of this email is strictly prohibited. In such case please notify the
sender and delete this email and any attachments with it from your system
immediately.Receipt of this email by you shall not give rise to any
liability on the part of Larsen & Toubro Limited 
>

Re: [Pythoncad-developer] [PythonCAD] Collada format (xml based 3D data transfer)

[<ger...@gm...>]

Hi Yangnesh,

Did you look at the schema?
The collada schema only supports a subset of the geometric entities  
PythonCAD support.
I PythonCAD was a full 3D CAD program you had a point but I don't see the  
use for a 2D CAD program.
You can never make PythonCAD read or write a collada file without  
significant loss of data.

I think this is not in line with the original principles of PythonCAD:
* a 2D CAD program
* fully programmed in python.

Are there any common file formats for 2D CAD files besides dxf?

Regards,
Gertwin


On Dec 20, 2009 6:09pm, Yagnesh Desai <yn...@ln...> wrote:


> Friends;



> Pythoncad uses xml based format to save the file

> now this is Non-Standard format (ie not based on

> any of the published standard) and cannot

> be opened by any other softwares.



> I came across this Collada format

> http://en.wikipedia.org/wiki/COLLADA

> while looking at Google Sketchup.

> (There must be something in this format

> as google sketchup is supporting it out of box . . !)



> If we migrate to (or support) something like such

> a format we might make pythoncad more utilizable.



> There are host of softwares supporting this format.



> Regards



> Yagnesh Desai

> Save a tree : Think before printing this email.

> Disclaimer :This email and any files transmitted with it are intended  
> solely for the use of the addressee(s) only and may contain confidential  
> and/or privileged information. If you are not the addressee, then this  
> message is not intended for you and be advised that you have received  
> this email in error and that any use , dissemination , forwarding,  
> printing or copying of this email is strictly prohibited. In such case  
> please notify the sender and delete this email and any attachments with  
> it from your system immediately.Receipt of this email by you shall not  
> give rise to any liability on the part of Larsen & Toubro Limited

[Pythoncad-developer] Collada format (xml based 3D data transfer)

[Yagnesh D. <yn...@ln...>]

Friends;

Pythoncad uses xml based format to save the file
now this is Non-Standard format (ie not based on
any of the published standard) and cannot
be opened by any other softwares.

I came across this Collada format
http://en.wikipedia.org/wiki/COLLADA
while looking at Google Sketchup.
(There must be something in this format
as google sketchup is supporting it out of box . . !)

If we migrate to (or support) something like such
a format we might make pythoncad more utilizable.

There are host of softwares supporting this format.

Regards

Yagnesh Desai
Save a tree : Think before printing this email.
Disclaimer :This email and any files transmitted with it are intended
solely for the use of the addressee(s) only and may contain confidential
and/or privileged information. If you are not the addressee, then this
message is not intended for you and be advised that you have received this
email in error and that any use , dissemination , forwarding, printing or
copying of this email is strictly prohibited. In such case please notify
the sender and delete this email and any attachments with it from your
system immediately.Receipt of this email by you shall not give rise to any
liability on the part of Larsen & Toubro Limited

[Pythoncad-developer] Saving views

[<ger...@gm...>]

Hi All,

What do you think about a functionality which makes it possible to save the  
current view and restore it later?

For instance you zoom in onto a detail and save that view with a name.
Later on when you are zoomed to an other part of the drawing you can  
restore the view by selecting the name and push a button.
The program can show a list with one or more saved views that can be  
restored.
The saved views are stored in the drawing file so they are persistant  
across sessions.

Also what about a zoom previous/next command?

Other ideas, comments?

Regards,
Gertwin

[Pythoncad-developer] Commandline use in PythonCAD

[<ger...@gm...>]

Hi All,

I want to start a discussion about the use of the commandline in PythonCAD  
(besides the bugtracker issue).
I do not want to talk about a timeline (R38, R40 1.0 etc) only  
functionality we want to have.

I think the commandline is very important and I like to see it gets more  
features.

At this moment we have a commandline interface and a menu based interface.
As far as I can see the two interfaces are seperated (in the source code)  
from each other.
I think the menu based interface should also work through the commandline.
Than we only have to maintain and test one input method.

Also we can construct the menubar (and toolbars/palettes) from an external  
resource (xml file).
If a commandline gets a new function only the xml file has to be altered,  
no programming needed for the menus.
All the menuitems can do their call to the commandline which handles the  
function.

Also I like to see the commandline able to process script files.
These script files are a simple sequence of commands, the same as the user  
can enter these on the commandline.
In this way we can also implement macro recording.

Commandline history?

More ideas, comments?

Regards,
Gertwin

[Pythoncad-developer] Subscribe

[José A. M. P. <jan...@gm...>]

[Pythoncad-developer] test message

[Matteo B. <mat...@bo...>]

[Pythoncad-developer] test message

[<eu...@li...>]

Re: [Pythoncad-developer] Pythoncad-developer post from gertwin.groen@gmail.com requires approval

[<ger...@gm...>]

Hi Matteo,

I did not mean your code and I was not talking about code quality, I am  
sorry if you took it personally.
I think the project has grown over time and it is not a bad idea to do some  
restructuring, now it takes to much time to understand the code.

Maybe we can arrange the code into modules, for instance a module "display"  
or "render" in which all the code for rendering the image is.
I did not think about such a structure but in that way you know where to  
look for the code.

If we first do this rearrange of code, splitting the files and put them  
into separate modules.
After that we can modify some code that is hard to understand.
For me the handiest way is to change the code when I touch it.
What I mean is when I need to change the code for new functionality or else  
that is the time to take a good look at the current state of the code and  
if there is a need to simplify is (at class or member/function level), not  
to do to many changes at once.

Maybe we can think about the structure of the code and both post a proposal  
in the next few days that we can discuss.

And about the toolkit, you are right, pygtk is a good choice and is a waste  
of time to throw away the code.

Regards,
Gertwin



On Oct 31, 2009 7:28am, "eu...@li..." <eu...@li...> wrote:
> Hi Getwin,

> This is the first time that I discuss of pythoncad code, so for me It's  
> ok to review some code..I take me lot of time to understand how It  
> works...

> I agree with you that my code is not so good.... but sometimes I work 1/2  
> ha day so It's easy to forget what you have done few day before ...



> We can make a list of file & Functions classes that need improvements and  
> work together to rich the objective.



> One of the files that need to be splitted is the gtkentitys.py, tool.py,  
> gtkmenus.py that provide the command functionality.

> Here we can make a deep split one file for each command.

> One exsample culd be:

> segmendCommand.py in witch we can put all comand for the segment..

> like tools menu callback.



> Another File that need to be restructured is the gykImage.py it's not  
> easy to understand ....and in there i have made my first modification of  
> pythoncad for zooming and panning :-)



> So if you agree with this kind of split I can start splitting the file  
> gtkmenu,gtkentitys,tools...



> >> I don't know what is the best choice.

> Me too. We can decide it later, gtk is cross platform and it wide (Es  
> Gimp) used.

> So it's not a so bad choice ...:-)



> If you have any suggestions please tell me so we can discuss it and make  
> the best choice for pythoncad future.



> Regards,

> Matteo





> > Hi Matteo,

> >

> > I don't think it is only one source file wich I want to split.

> > Most of the source files are huge (even more than 100kb) and it cost a

> > large amout of time to find my way in it.

> > Also the use of local variables within member functions in wich member

> > variables are copied makes it very hard to understand the code.

> > No offence but I think some parts of the code need a cleanup to make

> > it better mainainable.

> >

> > For the user interface, switching to an other toolkit of cource means

> > a complete rewrite of the code.

> > But writing an interface separate for each platform is not something I

> > want to do.

> > I think the user interface should be as native as possible to the

> > user, so tkinter is not a very good choice.

> > Gtk is native on linux/gnome but not on linux/kde, windows and os-x.

> >

> > If you want to rewrite the userinterface we must make a choice from:

> > - gtk/pygtk

> > - Qt/pyQt

> > - swing with jython

> > - tkinter

> > - ??

> >

> > I don't know what is the best choice.

> > swing with jython look great on os-x but not so on linux.

> > Maybe Qt is the most "near native" of the toolkits.

> >

> > Regards,

> > Gertwin

> >

> >

> >

> >

> > 2009/10/30 eu...@li... eu...@li...>:

> > > Hi Gertwin,

> > > Nice to see you ..

> > >

> > >>Question is can I break up some of the source files in several smaller

> > >>source files?

> > > Of course yes... but we need to decide witch file you what to split.

> > > The best think is that we make the split in R37 and the you create a  
> r37_Osx branch.. so the future marge will be less drastic.

> > > Do you think that we can delete the cairo folder from  
> pythoncadinstallation folder ?

> > >

> > > We can sumarize the work in this step.

> > >

> > > * decide the file to be splitted

> > > * make the split

> > > * test that the R37 work after the split.

> > > * create the new branch

> > >

> > > It's realistic thinking to migrate to tkinter interface ?

> > > What do you think ?

> > > Dose tkinter give you less problem than gtk in osx enviroment ?

> > >

> > > Regards,

> > > Matteo

> > >

> > >

> > > ---------- Initial Header -----------

> > >

> > > From : pyt...@li...

> > > To : pyt...@li...

> > > Cc :

> > > Date : Thu, 29 Oct 2009 21:28:51 +0000

> > > Subject : Pythoncad-developer post from ger...@gm...  
> requires approval

> > >

> > >

> > >

> > >

> > >

> > >

> > >

> > >> As list administrator, your authorization is requested for the

> > >> following mailing list posting:

> > >>

> > >> List: Pyt...@li...

> > >> From: ger...@gm...

> > >> Subject: OS X version of pythoncad

> > >> Reason: Post by non-member to a members-only list

> > >>

> > >> At your convenience, visit:

> > >>

> > >> https://lists.sourceforge.net/lists/admindb/pythoncad-developer

> > >>

> > >> to approve or deny the request.

> > >>

> > >

> > >

> >

Re: [Pythoncad-developer] Pythoncad-developer post from gertwin.groen@gmail.com requires approval

[euro_ii\@libero\.it <eu...@li...>]

Hi Getwin,
This is the first time that I discuss of pythoncad code, so for me It's ok to review some code..I take me lot of time to understand how It works...
I agree with you that my code is not so good.... but sometimes I work 1/2 h a day so It's easy to forget what you have done few day before ...

We can make a list of file & Functions classes that need improvements and work together to rich the objective.

One of the files that need to be splitted is the gtkentitys.py, tool.py, gtkmenus.py that provide the command functionality.
Here we can make a deep split one file for each command.
One exsample culd be:
segmendCommand.py in witch we can put all comand for the segment..
like tools menu callback.

Another File that need to be restructured is the gykImage.py it's not easy to understand ....and in there i have made my first modification of pythoncad for zooming and panning :-)

So if you agree with this kind of split I can start splitting the file gtkmenu,gtkentitys,tools...

>> I don't know what is the best choice.
Me too. We can decide it later, gtk is cross platform and it wide (Es Gimp) used.
So it's not a so bad choice ...:-)

If you have any suggestions please tell me so we can discuss it and make the best choice for pythoncad future.

Regards,
Matteo

     
> Hi Matteo,
> 
> I don't think it is only one source file wich I want to split.
> Most of the source files are huge (even more than 100kb) and it cost a
> large amout of time to find my way in it.
> Also the use of local variables within member functions in wich member
> variables are copied makes it very hard to understand the code.
> No offence but I think some parts of the code need a cleanup to make
> it better mainainable.
> 
> For the user interface, switching to an other toolkit of cource means
> a complete rewrite of the code.
> But writing an interface separate for each platform is not something I
> want to do.
> I think the user interface should be as native as possible to the
> user, so tkinter is not a very good choice.
> Gtk is native on linux/gnome but not on linux/kde, windows and os-x.
> 
> If you want to rewrite the userinterface we must make a choice from:
> - gtk/pygtk
> - Qt/pyQt
> - swing with jython
> - tkinter
> - ??
> 
> I don't know what is the best choice.
> swing with jython look great on os-x but not so on linux.
> Maybe Qt is the most "near native" of the toolkits.
> 
> Regards,
> Gertwin
> 
> 
> 
> 
> 2009/10/30 eu...@li... <eu...@li...>:
> > Hi Gertwin,
> > Nice to see you ..
> >
> >>Question is can I break up some of the source files in several smaller
> >>source files?
> > Of course yes... but we need to decide witch file you what to split.
> > The best think is that we make the split in R37 and the you create a r37_Osx branch.. so the future marge will be less drastic.
> > Do you think that we can delete the cairo folder from pythoncadinstallation folder ?
> >
> > We can sumarize the work in this step.
> >
> > * decide the file to be splitted
> > * make the split
> > * test that the R37 work after the split.
> > * create the new branch
> >
> > It's realistic thinking to migrate to tkinter interface ?
> > What do you think ?
> > Dose tkinter give you less problem than gtk in osx enviroment ?
> >
> > Regards,
> > Matteo
> >
> >
> > ---------- Initial Header -----------
> >
> > From      : pyt...@li...
> > To          : pyt...@li...
> > Cc          :
> > Date      : Thu, 29 Oct 2009 21:28:51 +0000
> > Subject : Pythoncad-developer post from ger...@gm... requires approval
> >
> >
> >
> >
> >
> >
> >
> >> As list administrator, your authorization is requested for the
> >> following mailing list posting:
> >>
> >>     List:    Pyt...@li...
> >>     From:    ger...@gm...
> >>     Subject: OS X version of pythoncad
> >>     Reason:  Post by non-member to a members-only list
> >>
> >> At your convenience, visit:
> >>
> >>     https://lists.sourceforge.net/lists/admindb/pythoncad-developer
> >>
> >> to approve or deny the request.
> >>
> >
> >
> 

Re: [Pythoncad-developer] Pythoncad-developer post from gertwin.groen@gmail.com requires approval

[Gertwin G. <ger...@gm...>]

Hi Matteo,

I don't think it is only one source file wich I want to split.
Most of the source files are huge (even more than 100kb) and it cost a
large amout of time to find my way in it.
Also the use of local variables within member functions in wich member
variables are copied makes it very hard to understand the code.
No offence but I think some parts of the code need a cleanup to make
it better mainainable.

For the user interface, switching to an other toolkit of cource means
a complete rewrite of the code.
But writing an interface separate for each platform is not something I
want to do.
I think the user interface should be as native as possible to the
user, so tkinter is not a very good choice.
Gtk is native on linux/gnome but not on linux/kde, windows and os-x.

If you want to rewrite the userinterface we must make a choice from:
- gtk/pygtk
- Qt/pyQt
- swing with jython
- tkinter
- ??

I don't know what is the best choice.
swing with jython look great on os-x but not so on linux.
Maybe Qt is the most "near native" of the toolkits.

Regards,
Gertwin




2009/10/30 eu...@li... <eu...@li...>:
> Hi Gertwin,
> Nice to see you ..
>
>>Question is can I break up some of the source files in several smaller
>>source files?
> Of course yes... but we need to decide witch file you what to split.
> The best think is that we make the split in R37 and the you create a r37_Osx branch.. so the future marge will be less drastic.
> Do you think that we can delete the cairo folder from pythoncadinstallation folder ?
>
> We can sumarize the work in this step.
>
> * decide the file to be splitted
> * make the split
> * test that the R37 work after the split.
> * create the new branch
>
> It's realistic thinking to migrate to tkinter interface ?
> What do you think ?
> Dose tkinter give you less problem than gtk in osx enviroment ?
>
> Regards,
> Matteo
>
>
> ---------- Initial Header -----------
>
> From      : pyt...@li...
> To          : pyt...@li...
> Cc          :
> Date      : Thu, 29 Oct 2009 21:28:51 +0000
> Subject : Pythoncad-developer post from ger...@gm... requires approval
>
>
>
>
>
>
>
>> As list administrator, your authorization is requested for the
>> following mailing list posting:
>>
>>     List:    Pyt...@li...
>>     From:    ger...@gm...
>>     Subject: OS X version of pythoncad
>>     Reason:  Post by non-member to a members-only list
>>
>> At your convenience, visit:
>>
>>     https://lists.sourceforge.net/lists/admindb/pythoncad-developer
>>
>> to approve or deny the request.
>>
>
>

[Pythoncad-developer] Fwd:Re:Pythoncad-developer post from gertwin.groen@gmail.com requires approval

[euro_ii\@libero\.it <eu...@li...>]

Hi Gertwin,
Nice to see you ..

>Question is can I break up some of the source files in several smaller
>source files?
Of course yes... but we need to decide witch file you what to split.
The best think is that we make the split in R37 and the you create a r37_Osx branch.. so the future marge will be less drastic.
Do you think that we can delete the cairo folder from pythoncadinstallation folder ?
 
We can sumarize the work in this step.

* decide the file to be splitted
* make the split 
* test that the R37 work after the split.
* create the new branch

It's realistic thinking to migrate to tkinter interface ?
What do you think ?
Dose tkinter give you less problem than gtk in osx enviroment ?

Regards,
Matteo


---------- Initial Header -----------

>From      : pyt...@li...
To          : pyt...@li...
Cc          : 
Date      : Thu, 29 Oct 2009 21:28:51 +0000
Subject : Pythoncad-developer post from ger...@gm... requires approval







> As list administrator, your authorization is requested for the
> following mailing list posting:
> 
>     List:    Pyt...@li...
>     From:    ger...@gm...
>     Subject: OS X version of pythoncad
>     Reason:  Post by non-member to a members-only list
> 
> At your convenience, visit:
> 
>     https://lists.sourceforge.net/lists/admindb/pythoncad-developer
>         
> to approve or deny the request.
> 

[Pythoncad-developer] OS X version of pythoncad

[<ger...@gm...>]

Hi,

I finally got gtk-osx and pygtk build on snow leopard, this was not so easy  
because snow leopard (and my machine) are all 64 bits.
Because gtk-osx and pygtk only works as a 32 bits build it took me a while  
to puzzle how to build it.

At this moment pythoncad is running on osx but not as it should be.

What I need to do for a usable osx version is:
The menubar needs to be on top of the screen and not in the pythoncad  
window.
Only drawing with cairo works well, using the graphic context leaves  
artefacts all over the screen, this has to be changed.

The problem I have at this moment is that the source files are huge and it  
very difficult to find your way in it.
Question is can I break up some of the source files in several smaller  
source files?
If so is it better to work in a different branch and later merge that with  
the R37 branch?

Also all the drawing done with the device context must be replace by cairo  
drawing.
It will be a lot of work but work has to be done to improve performance  
anyway.

If anyone has thoughts about it let me know.

Greetings,
Gertwin