Some udpates and changes

[Vadoola]

Hi, I know it's been a couple of years since this project was last updated. I thought I would go ahead and updated the dependencies an see what else I could do with the code base.

Even though it's been 2 years with no updates, I thought before permanently forking the project I would create a pull request and see if you wanted to continue maintenance on it.

Kind regards

[antonioaja]

Hello,

I stopped working on this mostly due to it meeting my needs at the time (i.e. fast conversion for both work & school projects). The only thing I would think would be worth adding is support for the last few entities in the dxf format as well as support for multiple layers.

Looking through the commits, it seems many of the changes are a major refactoring of the code which would be a bit much for a single pr. I don't have any current plans to keep working on this project in the coming months except perhaps updating the README & letting the qelectrotech forums know about the "dynamic text" feature (someone requested this & I implemented it that day, just never bothered to officially update the release).

Feel free to fork the project and do what you wish. Again, adding the last few entities & support for multiple layers is the only thing this converter is missing functionality wise. Also, you may find adding multi-threading to be cumbersome to do as well as being not too much faster and even slower in some cases due to generally small file sizes of 2d dxf files. For testing, when I was making this program initially, I used a small dxf file with all entities the program could convert as well as a large one (10+MB) - I saw one of your comments asking about tests.

Please let me know if you have any questions, thanks!

[Vadoola]

I stopped working on this mostly due to it meeting my needs at the time (i.e. fast conversion for both work & school projects).

Fair enough I certainly understand. As there was no updates on this project or your github in general the status of the project as a whole was unknown.

The only thing I would think would be worth adding is support for the last few entities in the dxf format as well as support for multiple layers. I was hoping to add support for other entities as well, in fact, while I haven't pushed it to github yet, I already have a rough version of support for blocks added in.

Looking through the commits, it seems many of the changes are a major refactoring of the code which would be a bit much for a single pr.

This wasn't intentional. I don't have a lot of experience with submitting pull requests on github. Back when I submitted the PR initially the changes were actually all pretty minor. Cleaning up some clippy lints, updating a few function calls to features in newer versions of rust (like the inline variables int he format!() calls), and updating dependencies. The biggest change at the time was swapping file_name from a String to a PathBuf, and adding the wild crate so passing something like ab*.dxf would work on Windows (since Windows doesn't do glob expansion and expects the programs to handle it). It would appear that the pull request however covers the entire branch and includes all subsequent commits after the pull request was made. I guess in a way it makes sense as that way updates and fixes to problems with the initial PR would essentially stay part of the same PR, then the branch can be discarded after being merged and that's that. Unfortunately, I'm and Electrical Engineer by trade, and almost all of the programming I do is solo work (internal tools and the like). The only job I had where I programmed with a team was about 14 years ago now and we used SVN.

Also, you may find adding multi-threading to be cumbersome to do as well as being not too much faster and even slower in some cases due to generally small file sizes of 2d dxf files.

After I submitted the pull request I did start a bigger refactor that I thought might make adding some things like blocks easier, and might improve the the code for trying to add multi-threading. I don't think adding in multi-threading would be too difficult and already have some ideas on how to do it, but I haven't tried yet and could be wrong. You also may be completely right that the overhead of dealing with multi-threading may not improve performance at all. I figured I would try to add it and do some testing. If it ends up too complicated or doesn't improve the performance, I'll roll it back.

Feel free to fork the project and do what you wish. I've already mentioned my fork on the QElectrotech forums, and have been in discussions with them. Not knowing the status of this project I didn't want to try and "take over" making my fork the official QElectrotech recommended one as maybe you intended to come back to it someday. If you have no further plans to continue working on it, would you be Ok with QElectrotech moving their recommendation to my fork?

For testing, when I was making this program initially, I used a small dxf file with all entities the program could convert as well as a large one (10+MB) - I saw one of your comments asking about tests.

I was hoping to add in some proper unit tests, so that when making some changes I could run the changes against a bunch of dxf files and make sure I wasn't breaking something. My plan was to try and create some of my own, but also maybe find some creative commons dxf files I could add into the repo for the unit tests. If you could possible share the ones you were using to test that would be great. I understand if you aren't able to do that though.

Thanks for starting this project and I wish you the best in whatever you do next.

[antonioaja]

Yeah, I would be ok with doing that. However, I'd like to release my "final" version with some of the changes I haven't put into an official release yet (I've been procrastinating this for almost 2 years now lol). I plan on doing this by Friday (9/13). I'll make an announcement on the forum, and archive this repo.

I'm glad you've found some use with this program, and happy you've thought of some ways to improve it!