Unofficial Window X64 and X32 Development Snapshots

[microelly2]

At sometime I need to add a license file and I believe pyqt4 is a potential problem if I want to mimmick FreeCAD's LPGL2 so I need to think what to do about this.

I have already switched my workbenches to pyside, so pyqt4 will not be a problem.
I have still a problem with the assemby 2 wb and the drawing dimension wb - a dll is not found on other pcs, so I need to understand this first.

[jmaustpc]

Hi all
PyQt4/Pyside was discussed and a decision was made to move to Pyside. All the pros and cons were discussed at the time, a decision one way or the other was required and was made. Please now respect that decision. Change your macro/etc. code to use Pyside. PyQt4 was removed for licensing reasons.

I don't like the sound of non-standard FreeCAD versions becoming too commonly used. There are issues. Like what is FreeCAD? You are welcome to fork FreeCAD change the name and do your own thing, the wiki explains how, but that is different from making something different and still pushing it around as "FreeCAD". Of course FreeCAD does and is intended to allow user installable custom plug ins etc. and that is OK. But it needs to be clear what is "official" "FreeCAD" and what is some third party extension etc.

The official downloads from sourceforge should, in my opinion, only contain "official" versions of FreeCAD compiled with some agreed/understood set of defaults.

Then there is the support madness. We currently very rarely get users posting their Help about FreeCAD data, and are constantly asked questions without sample files or complete information. Users terminology is often wrong so we are left constantly trying to interpret what the user really needs as distinct from what they say. Adding to this confusion with many custom so called "FreeCAD" versions with goodness knows what extras or compile options, would seem likely to only increase support difficulties. Bug reports and support requests will increase that relate to some plug-in or other, that are irrelevant to "official" FreeCAD.

There is also a need for consistence with settings etc. so that we can all share files on the help forum and for bug reports. Which is why most of us regulars have agreed to not turn on auto refine options (if this setting is different, default is off, then the model's history is likely to be corrupted). As we get more add ons there is more chance that there will be compatibility issues of various sorts.

General solutions and future direction
[*]Developing an infrastructure, both in terms of web repositories and in terms of FreeCAD code to make it easier for users to apply add-ins (Like FireFox and others do), would be a good development goal. As far as I know, it is generally agreed that this will one day be done.

[*]smaller release version more often, its been generally agreed that we should be create release version much more often. If you want to help make this happen and can not code, then make accurate detailed bug reports, get involved with the translations and fix up the wiki.

[*] If you are a developer, talk to the others, work together and aim to get your code into master, where appropriate. Of course there is still a place for plug-ins, Macros, etc. But unless your code gets into master then it will either require regular maintenance or will eventually bit rot into uselessness.

[*]PyQT4/Pyside, it would be good if someone or some people who know what they are doing would volunteer to go through the wiki and remove (and/or convert to Pyside) all PyQT reference from all the macro's etc.

[sgrogan]

@jmaustpc

All very good points. I was hesitant to post any build at first but Win is so far behind the Linux PPA I decided to do something. PyQT4 was especially an issue for me. The goal was not to proliferate a bunch of non-standard Windows builds to muddy the waters. The build I have posted uses the official FreeCAD Win Libpack and all standard defaults.

@microelly

Thanks for updating your workbenches to Pyside.

I have been contacted by a developer and I will work with him to make official dev builds on Windows. These builds will be scripted so therefore consistent with known rules and defaults. They of coarse will not contain the add-ons.

After this is done I will re-visit making installing the add-ins easier for Windows users. There has already been discussion about giving these add-ons more prominence in the Wiki, with the goal of increased use and testing so they may be improved and maybe someday included in master. In the mean time they provide increased functionality for the user.

[microelly2]

Hallo all,

I accept and support all the arguments and the ideas how to proceed. I see that with the new libpack now users have the ability to use all the nice new functions of the current FreeCAD. And users are not developers - so there should exist an usable binary. There also should be a clear distinction between core and addons in source code and responsibility. Different groups have special interests and there should exist ways how they can communicate their questions. I have started to promote the use of FreeCAD in school. There we have sometimes other interest than engineers and handcrafts. So I look for a way to bring my colleagues together and to give the students an easy to use tool which can accompany them during the higher classes.

I will do some investigation in a feature/tutorial to easy install and update third party workbenches on top of the freecad version. I think that workbenches are very more powerful and comfortable than macros and can be designed to help to solve complex tasks and to support workflows. workbenches can combine features from different core workbenches. In this way there can be a clear difference between the product FreeCAD and addons.
As mentioned other products like firefox, moodle and dokuwiki already support plugins in a comfortable way.
So I will separate my compiled win32 version from the workbenches. then there will be no difference to the official master and libpack and whoever wants can uses it without own compiling.
When a regular process of building current versions is established I will stop this activity.

[shoogen]

First of all i would like to thank you microelly2 for combining these versions, compiling and distributing them.
As long as there is sufficient support for the end users available I think distributing 'flavors' of FreeCAD. Your website is very clearly pointing out the fact that these builds are not to be considered "official". If your are proud of your edition, you could, for example customize the splash screen as well, advertising for the additional functionality workbenches.
But when it comes to answer users questions in the forum, i see a problem.
Your 32-bit windows built claims to be build from the branch "master". The hash is present in the blessed repo and the revision is correct with regard to the commit hash. The Version Control is set to "(Git)".
IMHO using the branch "master" should mean to apply only minimal modifications (such as a linux distro would have to do).
To me adding workbenches (even pure python ones) is a significant change that need clearly reflected in the version information, that the people will be posting here on the forum.I think that you should at least change the branch name.
(If you don't want to do it in git you edit the Version.h manually; after running cmake, but before recompiling.)
In long run I would like to see a public repo that includes all modifications and enables to retrieve the full source code form the git hash in the version information. (This is, of course, not a requirement.) But I think it would be nice to have.
Once again I'd like to emphasize that I appreciative your efforts to promote and enhance FreeCAD.

[sgrogan]

Thanks all

I think this is a very productive discussion.
This started out as a way to make FreeCAD more accesible to Window$ users, but has pointed out an issue with addons.

For myself at least, my attempt was to give window's users more access to the rapid developement of Freecad.

To Shoogen's point, I believe there is no mechanism to identify addd-on's in the About FreeCAD data. I think this is true whether from a third party build or if a user adds a wb themselves onto the offiial distribution (PPA, Windows installer etc.)

FreeCAD becomes aware of the workbench and adds it to the menu. Is there a way to feed this into the About FreeCAD data?
I realize the .h file is created before compile.

[jmaustpc]

To Shoogen's point, I believe there is no mechanism to identify addd-on's in the About FreeCAD data.

there is, but not directly. that would ultimately be part of a "add ins" infrastructure, some where you can go and see, and manage your "add ins" in your installation of FreeCAD.

To Shoogen's point, I believe there is no mechanism to identify addd-on's in the About FreeCAD data. I think this is true whether from a third party build or if a user adds a wb themselves onto the offiial distribution (PPA, Windows installer etc.)

FreeCAD becomes aware of the workbench and adds it to the menu. Is there a way to feed this into the About FreeCAD data?
I realize the .h file is created before compile.

The version data reads Git data. The normal work process would be that you first create a Git branch, then build from that. Then the Help about FreeCAD version data shows your Git branch name.

I realize the .h file is created before compile.

Its automatically created when you run Cmake or Cmake-gui. This is why you must run "cmake ." (cmake space dot) after Git pull and before "make" every time you compile FreeCAD.

But after you have run "cmake ." you can just open that file in a text editor and change it to anything you want.


I have to go out right now, this was a quick post ....

[sgrogan]

Thank you jmaustpc

I understand . space cmake (thanks to you I use it every day )

My point is that if a user installs a python work bench after compiling, this information is not captured by the About FreeCAD data.

microelley2 can fix this by either method shoogan points out if he choses to include wb add-ons. Which he has said he won't inclede add-ons.

You're original post about not confusing official FreeCAD and "flavours" as shoogan has pointed out is the key.

An infrastructure in FreeCAD to to this would be great! I do not have the skills to do this. In the mean time I would like to make FreeCAD more accesible to window's users. Both the core FreeCAD and the increased funtionality thru the Python interface.

Again, I thank everyone for the conversation. This is more relevant to windows users, it is much easier on Kubuntu.

[microelly2]

I would add an extra menu/menu entry for plugins (workbenches and macros)


*Install plugin: requires an url to the git where the workbench rests - then in the background a git clone

for every installed plugin:

*activate/deactivate plugin - hide/unhide in the list of workbenches so everyone can customize his workbench list
*update plugin: git pull
*remove plugin: delete the Mod subdirectory


every workbench should exist as a git repository
every workbench should have a master branch and a readme file , which can be displayed in the help window

and there should be a page on the freecadweb.org website with short descriptions and links

to organize discussion there can be a section in the forum "plugins", where functionality and errors of plugins can be discussed separated from the core freeecad.


https://www.dokuwiki.org/plugins is a good example to start.
here you can seee the state of the plugins, the downloads and the development story.
you have always access to the current version and the plugin update is easy too.

I can create a prototype of such an interface (still in python - I have not the time to start c++ coding)
or is there aleady something available?

[sgrogan]

Hello microelly2

It sounds like a good plan to me.

I think you should wait for some feedback before investing too much effort.
Also some additional feedback from the moderators of the forum would be welcome.