Regarding adding your new features to Arch, I would suggest the following:
We add your repo to the the FreeCAD addons repo. You should fill the “description” field on your github repo so it appears on the addon manager
Your scripts (straightrebar, ushaperebar, etc) must become FreeCAD commands (a toolbar button and/or menu item). Making such a command is easy, it’s basically a class like this:
class MyTool:
def GetResources(self):
return {'Pixmap' : ':/icons/someIcon.svg',
'MenuText': QtCore.QT_TRANSLATE_NOOP("Arch_Rebar_Straight", "My Tool"),
'ToolTip' : QtCore.QT_TRANSLATE_NOOP(Arch_Rebar_Straight", "Explanantion of what my tool does")}
# Arch_Rebar_Straight above must be the same name as used in "addCommand" below
def IsActive():
# this is optional but always good
if FreeCADGui.ActiveDocument:
return True
else:
return False
def Activated(self):
# this is executed when the tool has been invoked (toolbar button or menu item has been pressed)
# ex.
import StraightRebar
StraightRebar.doSomeStuff()
FreeCADGui.addCommand('Arch_Rebar_Straight',MyTool())
I suggest you add all those GUI commands/tools in a separate file (ex. RebarTools.py)
That file should also have a function that returns all command names that the module adds, ex: [“Arch_Rebar_Straight”,“Arch_Rebar_UShape”]
Once you have that file, I’ll add some code to Arch to try to import it (try: import RebarTools).
If the import succeeds, it means your stuff is present. Then the Arch module can grab a list of the new commands with the function from point 4)
Instead of the current rebar button, it will display a drop-down tool with all the different tools that you have
I think this will allow you to keep working without the hassle to submit pull requests all the time, and when you are ready for a big merge, there will be almost no modification needed to have your stuff merged in Arch.
Thanks for the reply. Yes, sending PR to FreeCAD on a small change is also a bit difficult for me.
As I shared my TODO list in this thread (https://forum.freecadweb.org/viewtopic.php?f=8&t=22760#p176520) and I have completed all tasks (present in my TODO list). I think reinforcement of Straight and U-Shape rebar is almost completed and presently I am working on a task which you have shared in your previous post.
Okay now Amritpal’s module is available from the FreeCAD addons repo (it’s called “Reinforcement”). When it is installed, the Arch WB will now detect it on load, and add its tool under the current Rebar tool (later on I think we can switch the order and leave the current one as the last one).
I just tested the 2 currently available tools, things begin to work very well, bars stay editable with the same dialogs after creation, etc. Congrats Amritpal, this is very good work so far.
One little detail: I would remove the OK button from your dialog, and instead use the built-in one from the task panel system. I think you just need to add the Ok button to your getStandardButtons function: return int(QtGui.QDialogButtonBox.Close+QtGui.QDialogButtonBox.Ok). I think there is nothing else to change in your code. Maybe you can use Cancel instead of Close too, seems more logical.
One small bug I found too, when creating a bar, everything works ok, but when editing it afterwards, the “ok” button doesn’t do anything (the dialog is not closed and the rebar is not changed).
Astonished. I have tested my scripts on different OS (Linux and Windows) and on both OS it works well. All functions working as desired. Can you tell output error of FreeCAD console?
I think each of these tools has a corresponding make…() function that can be used from python.
About the rebar not moving with the host, this is part of a bigger issue, and there would be several ways to attack the problem. One way to attack the problem could be to add a function to every Arch object that if its Placement changes, all of its children placements change too.
But there might be problems with this idea, some of the object’s children we might not want that they move (for ex. the base sketch of an object). One way to address that, is to move only the children that have a MoveWithHost property, and that property is set to True.
But there is a more interesting mechanism, which is that a sketch (or any other 2D object) stays attached to a face of its Support object. So there would be no need to change any placement. That could work for Rebars and Windows, for example. The problem is that this mechanism creates circular dependencies in Arch objects. But I thought of a way to get rid of the circular dependency entirely, which is: instead of having the host object keep the relationship to its children, let’s have the children keep the relationship to which host it is part of. This would bring a little bit of hassle (a wall, for example, would need to “query” its children each time to find out which windows are included in it), but I think it’s worth it. It would allow to use all kinds of attachment systems the FreeCAD has (external edges in sketches, etc) properly.
We could try that with Rebar and Window objects, I think at the moment those are the only two that have circular dependency problems.
I have no idea about the problem at hand, just want to note that “moving things together” can also be achieved with making the parent a geofeaturegroup. This does not change the child’s placement directly on move, but as it really contains the child’s in its coordinate system it moves them still globally (like app part or body but without the origin objects). Maybe that’s helpful.
Very good, just tested right now, this is a very good use of a non-planar rebar path. It works very well, good job!
A couple of small improvements I’d like to suggest (not critical nor urgent):
Add the diagram that appears inside the task panel to the warning message that pops out when you try to run one of the tools without selecting a face first. That will help the user to choose the right face before launching the tool. Maybe you won’t be able to use the default QMessageBox for that, and you’ll need to create a custom dialog.
Allow the user to change the selected face once the task dialog is running (for ex. in case he picked the wrong one, or, later on, if things need to be fixed later on, which can always happen while TopoNaming is untrustable). I believe you would simply need to add a “pick selected face” button.
What comes next in your plan? I guess now you’ll attack stirrup distribution?
I will complete implement “pick selected face” button in this week.
I think before attacking on rebar distribution we should first define how user will give input for rebar distribution. I have an idea regarding rebar rdistribution, we will add a new property to the Rebar object that will take input in a specific format like 5@100+2@200+5@100 (which means we have 12 rebars and spacing between first five rebars are 100, spacing from 6-7 rebars are 200 and spacing between 8-12 rebars are 100). Give your views on that?
I think you need to separate the question in two: 1) How to store that custom spacing information in the object, and 2) How to make it nicely editable by the user.
I think your proposal responds okay to 1). You can simply store that in a PropertyString. But for the users, this would be a pity, after you gave them nice dialogs, that they need to learn some syntax
I would suggest to add an “edit spacing” button, that would open an external dialog. In that dialog you could invent a system, for example a list widget that would display stirrup groups. The user would be able to add, delete and edit those groups. Check the Arch Structure → Concrete presets → Pillar, I added a system to add dents, you could do something like that. Arch Axis also has such an editable list, made in a different way (you can edit the values directly in the list)
But that doesn’t need to happen inside the task panel, you could do that in a separate dialog too.
another one came in minde. Some times I used a wrong input and on pressing ok there was an error message. But than one has to do all again. An apply button would be cool. If some input is wrong, one changes just these input and presses apply again and do not loose all input.
Ahh I like the thing that the rebars do not get destroyed if the base object changes. They even can stay alone without any base object. That is really important!
Another one. Attached a file and a screen. Something went wrong. May be the reason is between the monitor and the chair …
great work so far. I hopefully can give more input from now.
Yes, sending PR to FreeCAD on a small change is also a bit difficult for me.
