Customization Advice
I'm attempting to organize my CUI files to accomplish the following:
> Allow the user to perform some minor customization
> Easily update and push a company set of commands, menus, ribbons, and toolbars.
> Incorporate a growing set of 3rd party cui files
My current thought is:to
USER.CUI Launch BricsCAD with a USER.CUI as the main cui.
> COMPANY.CUI Partially load the COMPANY.CUI into the USER.CUI
> DEFAULT.CUI Partially load DEFAULT.CUI and the 3rd party CUI into COMPANY.CUI
> ARD.CUI
> MAPWORKS.CUI
> TOOLPAC>CUI
I'm specifically concerned about Workspaces in this setup. I'd appreciate any advice or recommendations.
> Allow the user to perform some minor customization
> Easily update and push a company set of commands, menus, ribbons, and toolbars.
> Incorporate a growing set of 3rd party cui files
My current thought is:to
USER.CUI Launch BricsCAD with a USER.CUI as the main cui.
> COMPANY.CUI Partially load the COMPANY.CUI into the USER.CUI
> DEFAULT.CUI Partially load DEFAULT.CUI and the 3rd party CUI into COMPANY.CUI
> ARD.CUI
> MAPWORKS.CUI
> TOOLPAC>CUI
I'm specifically concerned about Workspaces in this setup. I'd appreciate any advice or recommendations.
0
Comments
-
I don't know about workspaces, but generally if there are duplicate definitions the ones in CUI files loaded later take precedence over those loaded earlier. So unless you want "default.cui" to take precedence over the company and user menus you might want to consider Roy's idea of using an empty CUI file as the Main. Then you can load all the others as Partials to that, in reverse order of precedence. Maybe something like this:
EMPTY.CUI
> DEFAULT.CUI
> ARD.CUI
> MAPWORKS.CUI
> TOOLPAC.CUI
> COMPANY.CUI
> USER.CUI
That would allow the company menu to override what's in Toolpac, and the individual user's menu to override what's in company, and all the custom menus would override what's in the default menu. Any time you install a new version of Bricscad or Toolpac, etc, you won't have to make any change to the menu file. The newer versions will automatically be loaded in place of the older ones.
Here's what Roy found to be the minimum code for an empty CUI file:
[code]<?xml version="1.0" encoding="UTF-8"?>
[/code]0 -
That code box wasn't supposed to be blank. Something wrong with the Insert Code feature.
You can see the code for an empty CUI file in post #3 at http://forum.bricsys.com/discussion/124390 -
Thanks Anthony.
In your example, isn't maintaining the user cui more painful for the user? Also, wouldn't toolbar order and location be stored in Empty.cui as they were relocated?0 -
You can edit a CUI file in the Customize window even while it's loaded as a "Partial," so there's no problem for the user. Of course, the user can also edit Company.cui in the same way, so you'll have to tell them not to do that.
And nothing would get stored in Empty.cui except the names and paths of the other CUI files that are attached to it, and the order in which they're attached.
The system is similar to Xref's. Any CUI file can be a main, or it can be a "partial" to any other CUI file; just as any DWG file can be the main drawing or it can be an xref to any other DWG file. When you attach an xref to a DWG file, that attachment becomes part of the main file, but the attachment doesn't make any change to the externally referenced file. Similarly, the "partial" CUI file isn't altered by being made a partial to another CUI file; only the main CUI file is changed, and the only change is the reference to the file that's always to be loaded along with it.
The phrase "Load Partial" was an unfortunate choice by Autodesk, especially when they were already using the same idea and calling it "attach xref" and everyone understood that.0 -
It appears that workspaces in partial CUIs are not exposed. Only ones in the main CUI are shown?
I'm continuing to test ...0 -
Hi Donald,
There is a statement on workspaces in the release notes:
"WORKSPACES: when a new default.cui is being installed, and one or more custom workspaces are detected in the current cui file, these can now be merged into the new cui file."
The statement isn't that clear, but infers that there is a method to merge workspaces. However this results in the workspace details being transferred to the root cui. As far as I'm aware, workspaces can only be configured in the root cui. Workspaces defined in partial cui will be ignored.
The methodology for using a small root cui to attach other cui as discussed by Anthony and Roy is sound. I've seen this same approach recommended for working with AutoCAD, in particular for enterprise set-ups. The original posting is from a while ago, so would need to be updated to reflect the introduction of workspaces. i.e. you would need to include WorkspaceRoot in your root cui.
Workspaces store the visibility of menus, toolbars etc. So you would need to configure this in the root cui first before deploying. Also to prevent users from corrupting this cui, you would probably want to store it in a read-only location on your server. Provide write access only to the User cui.
Regards, Jason Bourhill CAD Concepts0 -
Workspaces store the visibility of menus, toolbars etc. So you would need to configure this in the root cui first before deploying. Also to prevent users from corrupting this cui, you would probably want to store it in a read-only location on your server. Provide write access only to the User cui.
You wouldn't allow each user to control the visibility of menus and toolbars on his own station?0 -
You wouldn't allow each user to control the visibility of menus and toolbars on his own station?
IMHO it's the lesser of two evils. If you in a multi-user environment with a company standard setup, then you will want to take steps to protect your development, and provide a consistent environment for the user. If you leave it accessible, then users will modify the root cui wittingly, or unwittingly. If you have WSAUTOSAVE on, then every time you change your workspace your root cui is updated.
It is the addition of workspaces that creates this dilemma. Again IMHO, workspaces look to a be a solution in search of a problem. Possibly I'm wrong, but I would expect that most people would be not be clamouring for its inclusion. It adds another layer of complexity for those that need to manage the CAD environment. Also the implementation with BricsCAD seems to mix in Profile related features. For example when you change workspaces, BricsCAD will change your default template (BASEFILE). If you open the default.cui you will see references to different templates
[code]<Name>2D Drafting</Name>
<Description>General 2D Drafting and Annotation</Description>
<WSTemplate imperial="Default-imperial.dwt" metric="Default-mm.dwt"/>[/code]
This is somewhat alarming as:- Your users could unwittingly change from the company prescribed templates.
- It changes your user profile, as it updates BASEFILE with the template name in the cui.
- Confusing. The user will be unaware of this change until they begin a new drawing. They will see that they have not started with the correct template, but won't know why this has changed.
- Its undocumented.
Regards, Jason Bourhill CAD Concepts0 -
I don't understand what would be wrong with copying the root CUI file to each hard drive and letting the user edit the local copy only. It's true that the user would have to re-do any customization any time you update the root file, but it sounds like that would happen very rarely. In particular, it sounds like any changes that a customizing user would want to incorporate would happen only when you add a new custom partial CUI file or remove one entirely. Or am I missing something?0
-
I've continued ... this is where I've ended up, for the moment anyway.
USER.CUI I do want them to be able to control the visbility of toolbars and menus.
> Default.cui
> 3rd Party.cui
> Company.cui
I've created 2 Workspaces in USER.cui
> MyWorkspace is configured but the is the one I expect them to customize
>2D Drafting almost identical to the BricsCAD version used as a safety net when the user screws up his.
It's not perfect but seems like it will work pretty well.0 -
Sounds like a good plan. Any user who wants to customize the context menus will be able to attach a fourth partial CUI for that purpose. And a custom pull-down menu can be added either at the left or right end of the menu bar, depending on whether it's added to the user's root CUI or to a fourth partial CUI.0
-
For anyone interested, this is what I have for a root cui:
- CCL-Root - Minimal.cui is the minimum required for a root cui. The root cui has to have at least one worskspace defined, which this has, but it hasn't been populated.
- CCL-Root - Default Workspaces.cui provides a root cui with the same workspaces as the default.cui. For this to work the default.cui must be loaded as a partial. The cui is already set to load the default.cui, it just needs to be somewhere on your support file search path.
- Notes on the philosophy of CUI (AUGI)
- Notes on the philosophy of CUI (ADESK)
- Managing the CUI and Empowering the Users
- Give users access to the root cui, which they may inadvertently break. It would be important in this case to keep a backup of the original root cui that you can push back out. The root cui would also need to be in a location that doesn't affect any other users.
- Lock the root cui down, which also removes the ability for the user to make any changes.
Regards, Jason Bourhill CAD Concepts0 - CCL-Root - Minimal.cui is the minimum required for a root cui. The root cui has to have at least one worskspace defined, which this has, but it hasn't been populated.
This discussion has been closed.