some bugs?!

[JP]

With the latest version (trunk\source) I'm experiencing a few bugs (some I had already with a few of the previous versions as well):

1.
With the latest version the about screen isn't popping up.

With the previous version for windows:  The compressed file did not contain the images\dxf2gcode_logo.png - this had the result that the about screen did not show this picture and instead it showed a broken picture (which indicates file cannot be found, obviously)

2.
When you start dxf2gcode.py
it shows the following message in the message box
Version pyQT Beta ($Date:: 2013-07-24 20:22:16#$:)
while one of the previous dxf2gcode showed the following
Version pyQT Beta ($Date: 2013-04-01 20:05:08 +0200 (Mo, 01 Apr 2013) $)

Also I would say the current version should show pyQT4 instead of pyQT.

3.
Then with the file I have added to this Topic "2DSAMP2.DXF" (sample file from gcode2000) I am experiencing some selecting errors. For instance, if I click on the most left circle (shape 0) it automatically selects the big outer shape (shape 2) - the same happens when I try to select the other circle (shape 1). Also the outer shaper (shape 2) is damn hard to deselect. Even if you succeed in deselecting it you can see it select him again (99%)…

So when trying to detect where I click it makes some sort of fault (also happened in the previous version).

4.

When you export the shapes it says (by default) save as G-CODE for EMC2 (*.ngx)

So what you actually would expect when you press save, that it saves a file as “filename.ngx”, but instead it saves it as “filename.ngx.ngx”. Now I know this is not something you have just recently, but I cannot understand why you would do it like this. I cannot come up with any other program that saves a file with a double output_format.

A consequence of this is that when you have already exported shapes in to a file, let’s say “filename.ngx.ngx”, then when you double click on this file a window will pop-up with the message “filename.ngx.ngx” already exists. Do you want to replace it? Then when you press yes what will happen is that it saves it as “filename.ngx.ngx.ngx”. So basically it did not replace the file at all, but made a new one with “.ngx” behind it. So that double output_format is causing some unwanted situations.

 

[JP]

About bug 1 it states the following reason
...\dxf2gcode.py, line 408, in about "</body></html>") % (c.VERSION, c.REVISION,c.DATE,c.AUTHOR) UnicodeDecodeError: áscii' codec can't decode byte 0c3 in position 24: ordinal not in range(128)

So bug 1 and 2 are related must have something to do with Core.constants

[Christian Kohlöffel]

Hello JP,

sorry for the late answer, but i was busy with family :-) ....
Please find the answers below in the bugs you mentioned. I hope this answers the most.

regards
Christian

Am 11.08.2013 22:18, schrieb JP:

About bug 1 it states the following reason

...\dxf2gcode.py, line 408, in about "</body></html>") % (c.VERSION, c.REVISION,c.DATE,c.AUTHOR) UnicodeDecodeError: �scii' codec can't decode byte 0c3 in position 24: ordinal not in range(128)

So bug 1 and 2 are related must have something to do with Core.constants

On Sunday, August 11, 2013 3:13:02 PM UTC+2, JP wrote:

With the latest version (trunk\source) I'm experiencing a few bugs (some I had already with a few of the previous versions as well):

1.
With the latest version the about screen isn't popping up.

With the previous version for windows:� The compressed file did not contain the images\dxf2gcode_logo.png - this had the result that the about screen did not show this picture and instead it showed a broken picture (which indicates file cannot be found, obviously)

My mistake, i will fix this for next issue. Thats the 2nd time i deleted some of the required files. Next time i won't delete anything ...

2.
When you start dxf2gcode.py
it shows the following message in the message box
Version pyQT Beta ($Date:: 2013-07-24 20:22:16#$:)
while one of the previous dxf2gcode showed the following
Version pyQT Beta ($Date: 2013-04-01 20:05:08 +0200 (Mo, 01 Apr 2013) $)

Also I would say the current version should show pyQT4 instead of pyQT.

The change from pyQt to pyQt4 would be a good improvement. For the change why i changed from
Version pyQT Beta ($Date: 2013-04-01 20:05:08 +0200 (Mo, 01 Apr 2013) $) to

Version pyQT Beta ($Date:: 2013-07-24 20:22:16#$:)

There was a bug report from EMC2 which sayed something like double enbraced comment. Therefore i limited the length of the string replacement of SVN to a certain length, not to have the brackets in it.

3.
Then with the file I have added to this Topic "2DSAMP2.DXF" (sample file from gcode2000) I am experiencing some selecting errors. For instance, if I click on the most left circle (shape 0) it automatically selects the big outer shape (shape 2) - the same happens when I try to select the other circle (shape 1). Also the outer shaper (shape 2) is damn hard to deselect. Even if you succeed in deselecting it you can see it select him again (99%)�

So when trying to detect where I click it makes some sort of fault (also happened in the previous version).

I worked a lot on the selecting function of pyQt4 and also on the function of Tkinter before. But finally i didn't succeed to get a better result then this. The only way to improve selecting is to zoom into the plot and then select based on the higher zoom, this improves accuracy.
If you have any futher suggestions to improve the selecting function of dxf2gcode (pyQt4) im open to it. You can find it in the function Gui/myCanvasClass the mouseReleaseEvent. I tried different possibilities and buit in function but no big difference at all even with changing the line width for selecting of contour in Core/Shape.py function paint and shape, but this also didn't improve it.

4.

When you export the shapes it says (by default) save as G-CODE for EMC2 (*.ngx)

So what you actually would expect when you press save, that it saves a file as �filename.ngx�, but instead it saves it as �filename.ngx.ngx�. Now I know this is not something you have just recently, but I cannot understand why you would do it like this. I cannot come up with any other program that saves a file with a double output_format.

A consequence of this is that when you have already exported shapes in to a file, let�s say �filename.ngx.ngx�, then when you double click on this file a window will pop-up with the message �filename.ngx.ngx� already exists. Do you want to replace it? Then when you press yes what will happen is that it saves it as �filename.ngx.ngx.ngx�. So basically it did not replace the file at all, but made a new one with �.ngx� behind it. So that double output_format is causing some unwanted situations.

No special reason for this. I just copied it from the Tkinter Version and changed it to match with pyQt4 but it seems like i did forget something.� Don't hesitate to improve it, i would apreciate that.

--
--
You received this message because you subscribed to the Google
Groups-group "dxf2gcode-dev".
To post a message, send mail to dxf2gc...@googlegroups.com
To unsubscribe, send mail to dxf2gcode-de...@googlegroups.com
See http://groups.google.de/group/dxf2gcode-dev?hl=en for more options
and the dxf2gcode project page at http://code.google.com/p/dxf2gcode/
---
You received this message because you are subscribed to the Google Groups "dxf2gcode-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dxf2gcode-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
�
�

[JP]

Allright thanks for the reply.
I fixed bug 1 (2 Not. Corrected it back :P but it still accepts Extended ASCII Codes) So now it can show Kohlöffel correctly instead of coming up with an error and not showing the about screen at all.

So no mistake of you at all. No file was removed incorreclty it just had to accept Extended ASCII Codes. Now it should work correctly (atleast it will show the about screen).

For bug 4
I have changed to single output format! Now if you want double it should be changed in postpro_config.cfg (output_format = .ngx.ngx)

Since I now know a bit more about bug 3... I will look into that.

[JP]

I think bug 3 isn't PyQt related; it has to with the function self.currentItems=self.items(rect) (located in mycanvasclass.py). This one isn't working properly. Zooming doesn't make a difference at all! Check for instance (in 2DSAMP2.DXF) the two outer lines (the most left and right one of the big shape) if you want to select them from the outside you really have to click (almost) on the black line, but if you approach it from the inside then you can select the item WAY earlier. With this design you can really find all kind of errors like this.

I also found a new bug (this one has to something with treehandling.py)
see the attached file Drawing2.
Here are three boxes on three layers. Then if you look in the entities tab you will see that they are ordered 0 1 2 but in the layer tab they are ordered as 0 2 1.

The error you get is that when you select an item, for instance item 1 in the entities tab and then you go to the layer tab and select item 0, then switch back to the entities tab you will directly see the error.
It isn't updating correctly (if you select an item in the entities tab you only change a selection of the name in the layer tab, but the [en] selection stays the same with what you had pressed in the layer tab. Vice versa…)

 

Also found a bug with shape 0 when you optimize it shows the line really short , or not at all (only the arrows of shape 0 stays; the line, and number disappear).  But when you optimize and export then it will appear again…

 

So two new bugs, together with bug 3 of the first post are in my opinion really bugs in the code and are not related to PyQt at all. Sadly enough I find it way too hard to fix it in this code. Maybe somebody else can look at it.

[JP]

Just fixed bug 5 :D
Bug 3 and 6 remain. 6 shouldn't be that hard to fix if I can only find out were it is all managed (show and don't show that line)

[Christian Kohlöffel]

Hello Jp,

please find my comments below:

The answer to bug 6 will be given in other e-mail.

I think bug 3 isn't PyQt related; it has to with the function self.currentItems=self.items(rect) (located in mycanvasclass.py). This one isn't working properly. Zooming doesn't make a difference at all! Check for instance (in 2DSAMP2.DXF) the two outer lines (the most left and right one of the big shape) if you want to select them from the outside you really have to click (almost) on the black line, but if you approach it from the inside then you can select the item WAY earlier. With this design you can really find all kind of errors like this.

I know this behaviour. Normally different selection methods should change the behaviour, but finally i didn't succeed in changing the behaviour at all. I think i found the similar problem below, maybe that solution works, my previous ones didn't work. But that was before and this solution is quite new.
http://www.riverbankcomputing.com/pipermail/pyqt/2013-April/032612.html

I also found a new bug (this one has to something with treehandling.py)
see the attached file Drawing2.
Here are three boxes on three layers. Then if you look in the entities tab you will see that they are ordered 0 1 2 but in the layer tab they are ordered as 0 2 1.

The error you get is that when you select an item, for instance item 1 in the entities tab and then you go to the layer tab and select item 0, then switch back to the entities tab you will directly see the error.

It isn't updating correctly (if you select an item in the entities tab you only change a selection of the name in the layer tab, but the [en] selection stays the same with what you had pressed in the layer tab. Vice versa�)

�

Also found a bug with shape 0 when you optimize it shows the line really short , or not at all (only the arrows of shape 0 stays; the line, and number disappear).� But when you optimize and export then it will appear again�

�

So two new bugs, together with bug 3 of the first post are in my opinion really bugs in the code and are not related to PyQt at all. Sadly enough I find it way too hard to fix it in this code. Maybe somebody else can look at it.

--

[Christian Kohlöffel]

Am 13.08.2013 12:34, schrieb JP:
> Just fixed bug 5 :D
> Bug 3 and 6 remain. 6 shouldn't be that hard to fix if I can only find
> out were it is all managed (show and don't show that line)
>

Everything which is related to the Canvas is done in the file
Gui/myCanvasClass.py (so thats not the location i think).

The most things related to the tree is done in Gui/TreeHandling.py (I
think thats the location you are searching). Finally i can't help a lot
on that. This function was not coded by me it was done by Xavier Izard
and i think the did a great job, maybe we can get some support from him
if required.

Both of those files are handling the Callbacks only. If you are looking
for the drawing functions of the line which are finally doing the
drawing, this is done in Core/Shape.py, which is finally the "line" you
mean.

[JP]

Great find of bug 3. It indeed looks quite similar to that one. Will look into that later on.
Yeah Xavier did indeed a great job, although there were some bugs and functions not completed. I have fixed them all (at least, the ones I noticed ;) ). Still, I want to do some work on the optimal path selection in the tree. At the moment it isn't working as I would like to see it. Now you have to check them individually (even with the shortcut ctrl+o), but I want that it works with the already highlighted selections. But momentarily I don't know what function I could use for that - have to search the net for it or I might come up with some kind of trick.

For bug6 I don't think I will find the solution in shape.py I think I have to search it in the function where optimal path is located. Since now I know what it actually does: it calculates one path to much while still having only three lines. So what it does it places two of them on each other. I can see this if I look closely to the displayed numbers.
But I will find that error later. Unless somebody else wants to do it :P

I have also updated the title bar a bit: added the icon and the file location of the current file - makes it look more professional.

[JP]

Alright bug 3 is sort of fixed (it's still present with the rubber band, but yeah that's also not really meant for accurate selection anyway).
Tried to fix it with self.items(rect) in combination with QRectF, but sadly that one does not support Floats, even though http://nullege.com/codes/search/PyQt4.QtCore.QRectF states it should accept it...

But I used http://www.riverbankcomputing.com/pipermail/pyqt/2013-April/032612.html in combination with the old method (otherwise it was too slow if I wanted some high accuracy in combination with a large amount of shapes). Result is with a single click you can only select a single item (this is in the exact selection range as before but now it will select the item which is located the nearest to your mouse point).

bug 6 remains, and will not fix that one atm - currently got no time for that.

[Christian Kohlöffel]

Hello JP,

thx for the help on the open issues. As you could imagin there is a lot of work behind such a tool. It's not only writting the code also answering all the questions on different lists etc. But i'm happy having a running new pyQT implementation now. This was a big bunch of work and took nearly 1 and a half year getting here. So i appreciate your help a lot to get the tool improved.

Am 15.08.2013 21:32, schrieb JP:

Alright bug 3 is sort of fixed (it's still present with the rubber band, but yeah that's also not really meant for accurate selection anyway).
Tried to fix it with self.items(rect) in combination with QRectF, but sadly that one does not support Floats, even though http://nullege.com/codes/search/PyQt4.QtCore.QRectF states it should accept it...
But I used http://www.riverbankcomputing.com/pipermail/pyqt/2013-April/032612.html in combination with the old method (otherwise it was too slow if I wanted some high accuracy in combination with a large amount of shapes). Result is with a single click you can only select a single item (this is in the exact selection range as before but now it will select the item which is located the nearest to your mouse point).

Great work, thx.

bug 6 remains, and will not fix that one atm - currently got no time for that.

I'm not sure anymore if i really did understand bug6. I think now you are searching the function which generates the shapes dependend on all given lines etc. This is done during the import of the dxf.
This error could also be related to duplicated lines coming from the dxf file itself.

The function which is doing all this is located in DXFImport/Import.py search for the function Get_Contour

For now dxf2gcode has no function to look for duplicated lines which are importet and if there are any this might cause such a problem. There already has been ca function which was intendet for that but i never finished it.
def Remove_Redundant_Geos(self, geo=None, points=None):

Can you tell me the file and the location of this bug, in order to have a look on that itself.
Please see example of similar problem below ?

On Wednesday, August 14, 2013 10:14:35 PM UTC+2, JP wrote:

Great find of bug 3. It indeed looks quite similar to that one. Will look into that later on.
Yeah Xavier did indeed a great job, although there were some bugs and functions not completed. I have fixed them all (at least, the ones I noticed ;) ). Still, I want to do some work on the optimal path selection in the tree. At the moment it isn't working as I would like to see it. Now you have to check them individually (even with the shortcut ctrl+o), but I want that it works with the already highlighted selections. But momentarily I don't know what function I could use for that - have to search the net for it or I might come up with some kind of trick.

For bug6 I don't think I will find the solution in shape.py I think I have to search it in the function where optimal path is located. Since now I know what it actually does: it calculates one path to much while still having only three lines. So what it does it places two of them on each other. I can see this if I look closely to the displayed numbers.
But I will find that error later. Unless somebody else wants to do it :P

I have also updated the title bar a bit: added the icon and the file location of the current file - makes it look more professional.

--

[JP]

Well that's not the bug 6 that I had in mind - let's call that one number 7 :P

but I have seen this error as well, but if I reproduce the exact same picture with AutoCAD 2004... then this bug does not appear. So then we have the question is this really a bug of dxf2gcode...
So this one is not yet clear to me.

But all AutoCAD 2004 files (don't know if other versions also) show two error messages in the beginning of the loading, even though everything is loaded correctly (check the added file to this post)...

I have partially fixed issue 11 Entry/Exit moves should start in the middle of an edge
Implemented a split edges function specially for EMC users http://code.google.com/p/dxf2gcode/issues/detail?id=11
not yet functioning for arcs and rect (option is selectable in option list and default is set in config.cfg – default is false) and I have to say this works really great especially with the fix of bug 3

bug 6 has to do with: when you go to options=>optimize paths. Just run that file I have added to that post (Drawing2.dxf, have added it again to this post) then click optimize and you will see what I meant. Watch the arrows (those dark ones). You will also see those two error messages

[JP]

So with bug 6 (saw there went something wrong with previous post (no attachment))
Please see the attachments. This error happens when I work on multiple layers.

With shape 0 when you optimize it shows the G0 line really short,(or not at all). What it probably does is that it calculates one path to optimize too much. So what it does it places two of them on each other Look at path (3,1) and (0,1) they are placed on each other... Also where is (1.1)????

When working on multiple layers the optimization is just not working as it is supposed to.

But when you press export it is sort of fixed (still wrong numbering though).
Please just try some things out. I think the error is quite easy to fix as soon as we have located the origin of the problem.

Let me know what you think (also about the displayed errors of "Drawing2.dfx" - which happens always with AutoCAD2004, while it still does shows everything....)

But when you optimize and export then it will appear again…

[Christian Kohlöffel]

Hello JP,

please find the comments below.

So with bug 6 (saw there went something wrong with previous post (no attachment))
Please see the attachments. This error happens when I work on multiple layers.

With shape 0 when you optimize it shows the G0 line really short,(or not at all). What it probably does is that it calculates one path to optimize too much. So what it does it places two of them on each other Look at path (3,1) and (0,1) they are placed on each other... Also where is (1.1)????

When working on multiple layers the optimization is just not working as it is supposed to.

But when you press export it is sort of fixed (still wrong numbering though).
Please just try some things out. I think the error is quite easy to fix as soon as we have located the origin of the problem.

I saw the problem but didn't fix it until now. The error should be located somewhere around dxf2gcode.py function exportShapes.

Let me know what you think (also about the displayed errors of "Drawing2.dfx" - which happens always with AutoCAD2004, while it still does shows everything....)

Fixed that warning message box. Now there is an information in the logging window only which shows that there have been not supported items like text etc. Just update your workingcopy.

But when you optimize and export then it will appear again�

On Saturday, August 17, 2013 5:21:51 PM UTC+2, JP wrote:

Well that's not the bug 6 that I had in mind - let's call that one number 7 :P

but I have seen this error as well, but if I reproduce the exact same picture with AutoCAD 2004... then this bug does not appear. So then we have the question is this really a bug of dxf2gcode...
So this one is not yet clear to me.

But all AutoCAD 2004 files (don't know if other versions also) show two error messages in the beginning of the loading, even though everything is loaded correctly (check the added file to this post)...

I have partially fixed issue 11 Entry/Exit moves should start in the middle of an edge
Implemented a split edges function specially for EMC users http://code.google.com/p/dxf2gcode/issues/detail?id=11

not yet functioning for arcs and rect (option is selectable in option list and default is set in config.cfg � default is false) and I have to say this works really great especially with the fix of bug 3

I also did implement something which kind of fixed this issue befor. Within the context menu of the canvas you are able to change the starting point of the shape. Did you check that too.

bug 6 has to do with: when you go to options=>optimize paths. Just run that file I have added to that post (Drawing2.dxf, have added it again to this post) then click optimize and you will see what I meant. Watch the arrows (those dark ones). You will also see those two error messages

--

[JP]

|
|"I also did implement something which kind of fixed this issue befor. Within the context menu of the canvas you are able to change the starting point of the shape. Did you check that too."

Of course I had checked that out. But with that you can only move the starting point to the corners, start/end of the line, and with the arcs ad a few distinct points. Thus you still kept the error with compensation for EMC users. Now it should be fixed (except for the rectangles and arc)

Quote: "For G41/G42 compensation to work correctly, the entry and exit moves should start in the middle of an edge and not at a corner."

Now it is possible to set nearest point in the middle of an edge, through that canvas menu ;)

Just check it out you will see the difference (note: you should check option=>Split edges).

|
|"Fixed that warning message box. Now there is an information in the logging window only which shows that there have been not supported items like text etc. Just update your workingcopy. "

Great! Now I can see it precisely where it happens. It were some text messages and a point. Are you still planning to implement points as you proposed in issue 31??? Because I think that will be the best way to handle points.

Also found a bug with the arc’s start and end points in the generated gcode. Since all the arcs are actually generated through a radius, but exported in a I,J format you can get end points that do not correspond to the I,J and the start point. Now you can get an offset in it of e.g. 0.001  mm. These errors you can see if you make use of e.g. NCPlot (g-code simulator). But I will fix this error soon.

[JP]

Found bug 6 and fixed it. Arrows are now like they should, and I made an extra improvement such that the arrows better represent the actual path (with multiple layers).

Also found some more bugs when reloading/reopening a file; will fix those too - soon.

[JP]

Alright… I have fixed quite a few bugs in the past days.

The control and shift key were having some focus errors. These were noticeable when you were pressing a key in the canvas and then, while holding it, moved to the treeview, released the key and went back to the canvas. The result was that it still thought that key was pressed. Fixed this issue by relocating the keypress events, etc.

The keys for selecting/deselecting items/path optimization (“O” and “space”) are now really functioning as they should. First they only worked for single items – now you can make use of them on the whole tree.

The treeselection is changed – no longer only the first two columns are highlighted - the whole row is now selected. But PyQt sucks when trying to select a whole row – it becomes really slow- therefore I have rewritten it as in http://www.riverbankcomputing.com/pipermail/pyqt/2010-April/026378.html

Have updated the screenshot on the info page - which one was outdated, and dxf2gcode didn’t look like that anymore. I also have placed a new win32 version in the download feature list (I have left out the i18n files since they need to updated - especially the French version).

Let me know if there are some more bugs / features that should be implemented ;)

[tux...@gmail.com]

Hi 

I have different problem under Linux with file 2013-08-24-DXF2GCODE_pyQT4_beta_source.zip

When I'm trying to export my work, program displays as default filename "test".

If I simply click <save> i get error :  

Traceback (most recent call last):

  File "./dxf2gcode.py", line 354, in exportShapes

    pp_file_nr = self.MyPostProcessor.output_format.index(fileExtension)

ValueError: '' is not in list

 When I'm trying full name like test.ngc, I get similar error :  

Traceback (most recent call last):

  File "./dxf2gcode.py", line 354, in exportShapes

    pp_file_nr = self.MyPostProcessor.output_format.index(fileExtension)

ValueError: '.ngc' is not in list

If the filename is with extension .ngx file is saved.

But default extension in LinuxCNC is .ngc not .ngx . 

Regards

[JP]

Well I cannot reproduce this error at all. Maybe somebody else can confirm that he/she also get this error, since I really don't have a problem like this at all.

[tux...@gmail.com]

Are you using Linux ?

[tux...@gmail.com]

diff -Naur old/dxf2gcode.py new/dxf2gcode.py

--- old/dxf2gcode.py 2013-08-24 00:48:32.000000000 +0200

+++ new/dxf2gcode.py 2013-09-02 20:53:19.687595641 +0200

@@ -403,7 +403,7 @@

         (beg, ende) = os.path.split(str(self.load_filename))

         (fileBaseName, fileExtension) = os.path.splitext(ende)

         

-        default_name = os.path.join(g.config.vars.Paths['output_dir'], fileBaseName)

+        default_name = os.path.join(g.config.vars.Paths['output_dir'], (fileBaseName + ".ngc"))

         

         selected_filter = self.MyPostProcessor.output_format[0]

         filename = QtGui.QFileDialog.getSaveFileName(self, self.tr('Export to file'),

diff -Naur old/PostPro/PostProcessorConfig.py new/PostPro/PostProcessorConfig.py

--- old/PostPro/PostProcessorConfig.py 2013-08-20 16:36:42.000000000 +0200

+++ new/PostPro/PostProcessorConfig.py 2013-09-02 20:23:57.274856309 +0200

@@ -48,8 +48,8 @@

     str(POSTPRO_VERSION) + '")\n' + \

 '''

     [General]

-    output_format = string(default=".ngx")

-    output_text = string(default="G-CODE for EMC2")

+    output_format = string(default=".ngc")

+    output_text = string(default="G-CODE for LinuxCNC")

     output_type = string(default="g-code")

     

     abs_export = boolean(default=True)

diff -Naur old/postpro_config/postpro_config.cfg new/postpro_config/postpro_config.cfg

--- old/postpro_config/postpro_config.cfg 2013-08-24 01:54:46.000000000 +0200

+++ new/postpro_config/postpro_config.cfg 2013-09-02 20:23:39.422767785 +0200

@@ -9,8 +9,8 @@

     config_version = 2

 

 [General]

-    output_format = .ngx

-    output_text = G-CODE for EMC2

+    output_format = .ngc

+    output_text = G-CODE for LinuxCNC

     output_type = g-code

     

     abs_export = True

[JP]

No I'm not using Linux...
But this error that you have seems to be related to PyQt and not really our sourcecode, since on windows it just works as it is supposed to.
 "default_name = os.path.join(g.config.vars.Paths['output_dir'], (fileBaseName + ".ngc"))" this is really a dirty fix, which I dislike...but we can do something like that with the file extension.

The ngx ngc is definitely wrong... saw that already a long time ago but yeah you are free to change that to whatever you want just change it in the config file.. (like you did).

[Christian Kohlöffel]

Hello JP,

are you already working on that, otherwise i will change it right now in the way you supposed it.

regards
Christian

--

[JP]

Hi Christian,
I will change it.

[Christian Kohlöffel]

OK, thanks for the support.
regards
Christian

[tux...@gmail.com]

W dniu wtorek, 3 września 2013 11:24:35 UTC+2 użytkownik JP napisał:

 "default_name = os.path.join(g.config.vars.Paths['output_dir'], (fileBaseName + ".ngc"))" this is really a dirty fix, which I dislike...but we can do something like that with the file extension.

You are right.

The extension should be read from config file.

This was quickly and works, I published it for explanation.

Regards

[JP]

Alright I have fixed it

Just update it from the svn ;)

What it now does: it checks which output format is selected. If it's not present in the name it adds it.

So if you try to save a file as test.txt then it changes it to test.txt.ngc (if ngc was selected). I believe other programs, at least in windows, act in the precise same way.

[tux...@gmail.com]

In my opinion, default extension should be add only if no extension was given at all.

If user wants to change extension to any, let him.

Regards

[JP]

Well I'm not going to change it to that. If another developer thinks it should be changed ok, but I'm not going to do that :P

This is how notepad and all those other basic programs do it, so I stay with this logic! But the source code is available for a reason.. you can tweak it the  way you want to... so go ahead tweak it.


ps I will only still make a small change with overwriting files that already exists such that it will not add this additional file extension.

[tux...@gmail.com]

W dniu wtorek, 3 września 2013 18:53:28 UTC+2 użytkownik JP napisał:

This is how notepad and all those other basic programs do it, so I stay with this logic! 

If dxf2gcode is to be cross-platform, we need to agree on the bad habits of the DOS era.

In the free world filenames may have no extension at all, or may have any.

My proposal is a compromise, the name must have the extension, but may not default. 

If one wishes so, here is the diff:

diff -Naur old/dxf2gcode.py new/dxf2gcode.py

--- old/dxf2gcode.py 2013-09-03 19:21:22.636551610 +0200

+++ new/dxf2gcode.py 2013-09-03 19:14:20.000000000 +0200

@@ -359,7 +359,7 @@

                 MyFormats = name + format_

                 if filename[1] == MyFormats:

                     pp_file_nr = i

-            if fileExtension != self.MyPostProcessor.output_format[pp_file_nr]:

+            if fileExtension == "":

                 self.save_filename = self.save_filename + self.MyPostProcessor.output_format[pp_file_nr]

             

             self.MyPostProcessor.getPostProVars(pp_file_nr)

[JP]

I'm sorry but you are truly missing the whole concept of the file type format selection. This has nothing to do with dos or what so ever!!!

And I still will not implement this truly dirty fix. It is now as like all programs work even non dos based programs!!!

The only thing that I am still willing to add is in the type selection an additional option such that you can save it to whatever you want. But for now you should change it in the config file or make dirty fixes like that one.

[tux...@gmail.com]

For me, dxf2gcode file is an executable not because that is .py at the end, just because it has the execute bit set and begins with #!/usr/bin/python.

Under Linux you can name it dxf2gcode.jpg and it still runs.

DOS imposed 8+3 filename and file type attributed to the extension.

Windows and Linux are completely different philosophies.

You can not keep rigidly to what established for DOS and Win95, if it is to be useful also for Linux.

In Linux filename extension is optional and determines nothing.

I know not any unix text editor which adds .txt extension to saved file, like Windows Notepad does.

Regards

[JP]

You still don't get the idea of the list where you can select file types.
When you select
Files of type: All Files (*.*)  (or something like that)
Then only you could specify whatever you want (even no extension at all). In all other case it should make sure it has the specified file type extension.
And this idea has nothing to do with what platform you are working on. This is just how it works, so don't focus too much on a program that I had listed as an example, because I can name a million programs that works like this.
Now we don't have this option All Files (*.*). Voila, so let’s quit this conversation because this truly leads to nothing. Unless you have found a different problem.