Advisability of making a fork of LibreCAD for making pull requests into the main repository

Development / Github
1

To start with, I will be keeping all my own changes in a stash for constant merging into my build each time I pull from GitHub.

But if it is likely that my changes would be approved into the project, once those changes are firmed up (none are today), it would make sense for me to make pull requests (haven’t checked yet whether I am even authorized to yet).

Years ago, on other open source projects, the gatekeeping was too strict. So none of my pull requests were approved.

Two examples of changes I feel I need for my own use and I think would be useful to others, that I think are within my current understanding of the LibreCAD source code to make (both in the properties widget)

Tiny change: I want more precise positioning of instances of BLOCKS. So I use the X and Y position fields in the Properties Widget (instead of the various dragging methods in the main window). But I want non integer values. Currently, you can type in non integer values and they affect the object, but aren’t displayed. I want to fix the display. Also sometimes (I haven’t figured out how to reproduce) you change something unrelated in that Widget, it also changes the X or Y value from the stored value to the displayed rounded value. I want to fix that.

I doubt many other people work in inches (as I do) and care about those fractional inches. But I would expect fractional values to be more important to people working in meters.

Big change: I use a LOT of rectangles. It is great that you can create “rectangles”. But you can’t then modify “rectangles”. You create a “rectangle” but you modify a “polyline” and the fact that it is a polyline rather than a rectangle makes it harder to modify (assuming your intent is that when modifying, it remains a rectangle).

This “big” change is the first phase of treating a rectangle as a rectangle. The properties widget when loading a polyline would detect “rectangle” (closed polyline with 4 sides, whose two diagonals are of equal length and the midpoints of those two diagonals are the same point, within a very tight but nonzer tolerance). Then it would populate a dialog appropriate to “rectangle(polyline)” including a control for a one time switch to the polyline dialog. I would never use that control (to switch back to polyline to make some change that doesn’t make sense for it staying a rectangle), but I wouldn’t consider a pull request without that detail.

There a several other things I want to do within “treat a rectangle as a rectangle”, but I don’t yet know enough about what is where in the LibreCAD source code to plan those.

If anyone read this far, what I’m trying to ask is whether feature changes like that would be approved and even if so, whether a new project member is likely to be met with gatekeeping (on factors unrelated to the correctness and robustness of the change) that is too strict to be worth fighting.

2

1) I want more precise positioning of instances of BLOCKS. So I use the X and Y position fields in the Properties Widget (instead of the various dragging methods in the main window). But I want non integer values. Currently, you can type in non integer values and they affect the object, but aren’t displayed.

I think you need to check Drawing Preferences first. And there, check which precision is used for linear and angle units.

These settings controls how many zeros will be shown in ui.

As far as I can see - for insertion point of RS_Insert a standard editor for coordinates is used, so it’s definitely it should not support ints only.

image
image1465×753 34 KB

  1. Rectangles in properties

Well, that in general doable, I suppose, yet might be complicated to support it properly.
I didn’t considered this in details, yet several notes to think about:
a) Properties widget support editing of multiple entities - and so it will be necessary to check for all polylines.

b) detection of rectangle is runtime only - as there is no such notion as rectangle in dxf - only polyline. That may affect performance.

c) Rotated rectangles - complicates things even more.

d) User Coordinates System - with rotation - add an additional complexity into proper calculations and editing.

I suppose you’d like to change width and height of rectangle - and calculating vertexes may require various coordinates calculations.

From the other side - I’m not sure that direct approach with editing polylines in special way is a right way in general.

More common way for solving such tasks is using blocks with attributes.

So far LibreCAD does not support parametrized blocks, yet it could be much more natural to rely on them for rectangles editing (at least, it if will be implemented).

As for pull request - well, if they are written in good code style and follow the overall ui and code approaches used by codebase - well, why not.

3

Thankyou. That suggestion saved me significant effort.

I’m sure when I found the time to actually make (rather than just plan) the code change I intended, I would have understood what the existing code does and then backtracked to the preference setting controlling it. I’ve done that in customizing other open source programs for my own use: Fail to find a feature I need in the documentation and UI; Take a lot of time to find the right place in the source code where that feature ought to be added; See it is already there; Backtrack in the source code to find the place in the UI where the feature can be turned on.

That was the first topic I researched: Is it practical to keep the rectangle as a rectangle? I concluded it is not.

I think not. On the fly detection of being a rectangle is trivial compare to many other actions that happen every time the place where that would go is executed.

I believe rotation does not complicate it at all. The detection of a rectangle is simple math that does not care about rotation.

I haven’t yet tried UCS. I don’t know if or how it scales. Any “translation” (adding or subtracting of coordinates), or rotation or uniform scaling, all leaves rectangleness identical in the before or after coordinate system. Non uniform scaling does not generally preserve rectangleness. But one coordinate system is active for any given operation (I’ll understand that better once I’ve tried UCS). The on-the-fly check of is-it-a-rectangle would obviously be done in whatever coordinate system is active.

I have so far found BLOCKS rather fragile. I don’t know how much of that is my misunderstanding of intended behavior vs. how much is bugs.

For most of my uses of rectangle, you are correct (assuming that copying instances of blocks were less fragile) I would be better off simply using instances of a block that contains just a rectangle.

But I still think rectangles should be treated as rectangle, both for my own use and for any beginer who creates a rectangle and then is confused by the behavior of the resulting polyline.

4

Just curious, what editing options you’d like to support for rectangles?

Editing coordinates of some corner plus editing both width and height?

5

I want to show various values, most importantly length and width, and have various “lock” options I could check, both for interaction with other values, and for interaction with dragging handles in the drawing.

It would be great if I could draw to correct angle, but not to scale, a mini rectangle in the widget with 8 lock point that can be marked (each middle of side and each corner), so I could lock a few things and then change other things (by numeric edit of handle drag) in a way that recomputes the remaining things (those neither locked nor directly changed) to keep it a rectangle.

I have little use for changing the angle. But I think the angle (initially world angle of a long side) should be displayed and locked by default and unlockable and directly editable. There is some complication that changes even with the angle locked may eith make width longer than length or swap length vs. width and by doing so make a 90 degree change in the world angle of the longer. Choosing the moment to normalize is a bit messy but not really a big deal.

6

well, this is suspiciously similar to Rect 1 Point command.
Yet for sure that command is used for creation of rectangles, not for editing.
However, in that command it is possible to specify snapping (or insertion) point of rectangle + width and height.

7

I often don’t have the ability to get a rectangle correct on the first try, neither to do the computations to get it right numerically nor the manual dexterity etc. to get it right with the mouse.

I tend to place things in best guess position, then measure various relationships to other objects, then tweak the size and position.

With blocks (due to some bugs, I will try to find cleaner reproduction for and then report later) in can be a pain to place them approximately where I want. But after doing so, it is pretty easy numerically to fix whatever rotation or mirroring (negation of one of X or Y scale) was trashed when placing (the preview differs from the original copied instance and the placed object differs from both the preview and original), then fix the position consequences of fixing the rotation or mirror, then finally tweak the position.

Placing a rectangle is trivial. But then tweaking it can be hard enough that it is easier to delete it and place it again. It should be much easier to tweak, both when it has just been placed slightly wrong and when other things are edited creating a need to edit that rectangle.