Any interest in hierarchical Layers support in LibreCAD? Like this about librecad HOT 8 OPEN

This one looks great to me.

from librecad.

Appropriate code is in this repo https://github.com/sand1024/LibreCAD.

All functionality was commited by one large commit - sand1024/LibreCAD@80ed4c2...08dac86

I'm not sure whether it's practical to create pull request at the moment, however, it will be great if somebody may check the implementation and let me know any feedback (both features and implementations).

I think feedback with issues/discussions in that fork's repo will work better rather than directly there? Anyway, I'm more than open for the feedback and suggestions.

from librecad.

Many thanks for your intention to share this feature!

I've cherry picked your commit 80ed4c2, the fix for rs_actiondefault.h, as this is another issue.
As old as QCAD and unbelievable, that this wasn't found yet 🤣. Nice catch.

I haven't gone through the implementation yet, but I have two recommendations so far.

• To keep your master in sync with the main repo, you should move the feature commit into a separate branch. This makes pull request and merging much easier. So you should pull the new master with your fix and on this commit (which is different from yours, SHA de9cb37) create a branch for the feature.
  Don't hesitate to ask if you need help with git here.
• For all the new files please replace the prefix qg_ by lc_. qg_ files are QCAD origins and for newly implemented files we use lc_ to keep them apart.

from librecad.

Thank you for your comments. Yes, basically that issue with define was a bit annoying - I've commiteed initilal version of CMakeLists.txt also (yet without plugins build so far) - hope it may be good start for adding support of cmake for the project too.

BTW, when I've tried to achive build of the project via cmake - I've noticed lots of files that are part of repo but are excluded from build.

It seems that they are not needed so far, so probably it's better to move them in to some separate directory (if they are needed, say, for some historical reasons)? Such files are commented in CMakeLists.txt in that repo.

Regarding the prefix - yes, got your point, I'll refactor naming accordingly. Indeed, it was not clear for me why there are different prefixes for classes, so I've just used conventions from List widget.

If there are naming/style etc. conventions that should be followed to keep the overall codebase of the project - please let me know that.

Also, I think there might be another generic issue with my current implementation - tha generic decomposition and organizing of the code. I'll be glad to know your opinion there.

Actually, I've tried to affect the existing codebase as little as possible, and that's a reason why, for example, dialogs are shown not via QG_DialogFactory or why some operations are implemented not as actions but directly as slotts.

Of course, existing code may be reworked in such way and that may be more consistent approach - however, I'm rather concerned thare that it may introduce some regression issues and will require additional testing.

And indeed, good point regarding git - I'll follow the way you've mentioned, thank you.

from librecad.

commit for renamed version is there sand1024@b4ed526#diff-1bb2ab9ac4bfc2228b67aa44a05372fad1349775561b8e6915ad124b462664ff

Hope branch is created fine, yet if something should be changed - please let me know.

from librecad.

Thanks for the changes! I think this is a good base now to inspect code and work on your forks branch until we have it ready to merge.
With nearly 8000 lines added, it may take some time to get behind the code.
Don't worry about code style. Our huge mature code base has so many styles meanwhile that it's not worth the efforts to unify them.

Concerning the unused files I assume they're fragments from earlier features or test code and were forgotten to delete. We have to check them in history, if they were ever used at all. Probably they can be deleted, git remembers them anyway.
Maybe some are only used with specific preprocessor macros defined, that has to be checked too.
But this is additional work for another branch or the main repo itself, we should not mix up separate concerns.

The direct link to the branch: https://github.com/sand1024/LibreCAD/commits/layer_tree_view/

from librecad.

Hi there. This is exactly what I was looking for. How can I get a version with this widget to try it ?

from librecad.

Try to build from source.

I feel we should provide a simple script to build from scratch using any GitHub branch.

from librecad.