the main problem is —— how to force an user to trust you. I’d never installed any mzp file to my machine before the checking what hell is that. so, mzp sucks…
Hehe. What would your solution be?
(And do you do the same with any other program you install? )
I can do just as nasty things in a regulair script or macro, so it’s just a matter of trust.
Maybe a optinal popup with ‘do you trust the source if this script?’
I think Denis argued that he’d first look at the script itself, before using it. I wonder what he’d do with an encrypted script though…hehe.
I’ve added an installer action that will allow the developer to create a new toolbar. This is done by parsing and adding to the cui file. It is of course undo-able as well.
The next step is to create an installer action for adding items to toolbars. But this should not be too hard now that the code for parsing the cui file is mostly done.
I have also ported the class that handles hotkey assignment, which I had previously made in maxscript. The approach here is much the same as for the cui file: read -> parse -> adjust -> write back.
If you’re interested in the code, you can have a look here:
CuiFile:
http://code.google.com/p/scriptcenter/source/browse/trunk/ScriptCenter/ScriptCenter/Installer/Actions/CuiFile.cs
CreateToolbarAction:
http://code.google.com/p/scriptcenter/source/browse/trunk/ScriptCenter/ScriptCenter/Installer/Actions/CreateToolbarAction.cs
KbdFile:
http://code.google.com/p/scriptcenter/source/browse/trunk/ScriptCenter/ScriptCenter/Installer/Actions/KbdFile.cs
AssignHotkeyAction:
http://code.google.com/p/scriptcenter/source/browse/trunk/ScriptCenter/ScriptCenter/Installer/Actions/AssignHotkeyAction.cs
Adding buttons to a toolbar is done now too. It took a bit of reverse engineering the cui file, which is a somewhat peculiar file, but I think it worked out nicely.
You can also add a separator to the toolbar, something which you cannot do through the customize user interface dialog I believe. There is a dummy macroscript which is basically a button with a separator icon, but its not as nice as the real thing. The only slight issue with the proper separator is that it is difficult to undo it. They have no identifier or anything unique, so its tricky to know which separator to remove. For now I will keep it as an ‘un-undoable’ action though, since it might be nice when building a complete toolbar.
I don’t know if either of you are interested, but maybe someone could look into how to create ribbons and add panels/buttons to ribbons. I spent an hour or two trying to get something going through the AdWindows.dll assembly, but couldn’t really get things to save properly.
Make a backup of your ModelingRibbon.xaml before you run this, because it will become corrupted!
RibbonTab t = new RibbonTab();
t.Title = "Test";
RibbonPanel panel = new RibbonPanel();
RibbonPanelSource source = new RibbonPanelSource();
RibbonButton btn = new RibbonButton();
btn.Text = "Test Btn";
btn.ShowText = true;
source.Items.Add(btn);
panel.Source = source;
t.Panels.Add(panel);
ComponentManager.Ribbon.Tabs.Add(t);
//This does not seem to generate the right xaml....
String ribbonState = ComponentManager.Ribbon.SaveState();
String ribbonConfig = ManagedServices.PathSDK.GetRibbonConfigPath() + "/ModelingRibbon.xaml";
using (System.IO.StreamWriter str = new System.IO.StreamWriter(ribbonConfig))
{
str.Write(ribbonState);
}
--based on code found on: [ http://forums.cgsociety.org/archive/index.php/t-790598.html ]( http://forums.cgsociety.org/archive/index.php/t-790598.html)
ComponentManager=dotnetclass "Autodesk.Windows.ComponentManager"
Mx_Tab=dotnetobject "Autodesk.Windows.RibbonTab"
Mx_Tab.Title="Just added"
ComponentManager.Ribbon.Tabs.Add(Mx_Tab)
Mx_Panel=dotnetobject "Autodesk.Windows.RibbonPanel"
RibbonPanelSource=dotnetobject "Autodesk.Windows.RibbonPanelSource"
Mx_Panel.Source=RibbonPanelSource
Mx_Button1=dotnetobject "Autodesk.Windows.RibbonButton"
Mx_Button1.Text="new Button"
Mx_Button1.showtext=true
RibbonPanelSource.items.add(Mx_Button1)
Mx_Tab.Panels.Add(Mx_Panel)
--MaxRibbon.SaveRibbonConfig "E:\Projects est.ribbon"
We’ve look at this method earlier, but I’ve did a bit of more trail and error testing.
The code above works fine in maxscript, except the save command gives a system exception when uncommented.
I’ve found another anomaly… When a pannel+button is added with above code, it looks different in Max’s ‘customize ribbon’ dialog.
First I have to check to ‘show all hidden ui’ toggle to view the contents of the panel, second the panel is displayed as a ‘[spacer panel]’ with no properties. just compare it with a manually added panel to see what is different about it.
A ‘RibbonPanel’ might need some extra properties, this could be corrupting the save? On the other hand it saves fine when saved trough the ribbon’s context menu…
Found it…
I compared these two:
Added via maxscript:
<ads:RibbonTab
IsActive="true"
Title="Just added"
UID="fe821bea-0f33-4f86-98d3-29422864fd15">
<ads:RibbonPanel
FloatingGroup="0"
FloatingOrder="0"
UID="ad5ab836-fd1b-470d-b9d0-a43170425579">
<ads:RibbonPanelSource
UID="941bf2e4-7244-4780-ba9d-dc25d6a197d1">
<ads:RibbonButton
IsCheckable="false"
IsToolTipEnabled="true"
MinWidth="0"
ResizeStyle="HideText"
ShowText="true"
Text="new Button"
UID="0dc8c3bf-c6aa-4350-8514-a2b35f702750" />
</ads:RibbonPanelSource>
</ads:RibbonPanel>
</ads:RibbonTab>
Added manually via ‘customize ribbon’ dialog:
<wpfcust:MaxRibbonTab
Title="New Tab"
UID="3f7933c0-dabf-47a4-bbdb-5a3c37957b46">
<wpfcust:MaxModelingRibbonPanel
CollapsedPanelImage="Icons/MissingImage.ico"
FloatingGroup="0"
FloatingOrder="0"
UID="d0db41c1-ecda-4136-9f76-3f03196da2da">
<wpfcust:MaxRibbonPanelSource
Title="New Panel"
UID="4309c45d-e841-49b5-862a-c934d82580b6">
<ads:RibbonButton
Image="Icons/MissingImage.ico"
IsCheckable="false"
IsToolTipEnabled="true"
LargeImage="Icons/MissingImage.ico"
MinWidth="0"
ResizeStyle="HideText"
ShowText="false"
UID="a6d80f13-ebba-4cb8-98c8-4c3012ee6141" />
</wpfcust:MaxRibbonPanelSource>
</wpfcust:MaxModelingRibbonPanel>
</wpfcust:MaxRibbonTab>
The panel is missing a title, and when looked at in customize-ribbon dialog there was a missing ‘visible’ flag.
showProperties (dotnetobject “Autodesk.Windows.RibbonTab”)
Reveals an ‘isVisible’ flag, setting that to true doesn’t make a difference.
But when I set the ‘Title’ of a panel to something it works again in in the customize-ribbon dialog. With out the title it becomes a ‘[spacer panel]’ what ever that may be, and you cant add anything to it anymore…
The only ‘bug’ is you have to enable the ‘show all hidden UI’ toggle to make it visible in the customize-ribbon dialog, the front-end of the ribbon works fine.
So in short: this adds a working tab+panel+button to an eisting ribbon and saves it.
(you might want to change the save path since it your username will unlikely to be ‘jcdeblok’ )
ComponentManager=dotnetclass "Autodesk.Windows.ComponentManager"
Mx_Tab=dotnetobject "Autodesk.Windows.RibbonTab"
Mx_Tab.Title="Tab title"
Mx_Tab.IsVisible=true
ComponentManager.Ribbon.Tabs.Add(Mx_Tab)
Mx_Panel=dotnetobject "Autodesk.Windows.RibbonPanel"
RibbonPanelSource=dotnetobject "Autodesk.Windows.RibbonPanelSource"
RibbonPanelSource.Title="panel title"
Mx_Panel.Source=RibbonPanelSource
Mx_Button1=dotnetobject "Autodesk.Windows.RibbonButton"
Mx_Button1.Text="new Button"
Mx_Button1.showtext=true
RibbonPanelSource.items.add(Mx_Button1)
Mx_Tab.Panels.Add(Mx_Panel)
MaxRibbon.SaveRibbonConfig "C:\Users\jcdeblok\AppData\Local\Autodesk\3dsmax\2012 - 64bit\enu\UI\my_dynamic_.ribbon"
Nice work Jonathan!
Meanwhile, I did a bit of work on the interface for creating the installer configuration:
So with this little editor, you will not even have to write a configuration file by hand, how nice is that? :bounce:
The UI is still a little rough here and there of course, I’m concentrating on functionality now.
Looking good!
That is exactly what we’re going for actually But that’s the long-term plan. Step 1 is the installer ‘framework’. It is being designed so that the installation/uninstallation logic and the UI are very loosely coupled. So the installation can be run without the typical standalone installer UI, but from a tool as you describe here.
Im with you on this – installers suck.
[…]
As to .mzp’s – i edit them in notepad and remove anything zippish before running them. Usermacro’s are a pain in the ass alone without having to remove scripts your were just testing.
I must say that I genuinely don’t understand the problems you all have with installers… Take the installer for the Outliner for example, it is simple, it cleans up after itself, what more could you want? Surely that’s better than having to copy files into various places by hand, and having to find them again when uninstalling?
And if it is shoddy implementation by ‘beginners’, then this concept should be an improvement, right?
If it’s installers meddling with your UI that you don’t like, then I guess we could have a “don’t mess with my UI” checkbox in the installer, which would skip all UI related actions.
Without going into the details to much, just a few of the main things we’re aiming for:
-good housekeeping, clean install/uninstall/updates
-Automatic, but still user controlled, toolbar/ribbon/hotkey assignments
-Repository system including in-max browsing, managing and update notifications
-Easy syncing/restoring of toolsets among workstations
The installer, and the tool that creates the installer [top-secret] plus a special meta-data file [/top-secret], plays a central role in this. Since this can work standalone we’ve decided that it should be released first so it can have some field testing while we work on the rest of the system.
So keep in mind that we’re focusing on the installer first, but we do have a bigger plan. Lets keep our eyes on the installer for now!
About the .MZP worries:
That’s just the dual nature of an installer and not something we can fix:
-It’s a blackbox that does unknown things to your system.
-It’s an easy way of (un)installing/updating items even for the less technical users.
What we can do is show a ‘list of actions’ that is about to be done, so you can review those before running the installer. In theory we could even make a system where you could uncheck those you don’t want.
All the toolbar/ribbon/hotkey assignments will have to be confirmed by the user, so you’ll have some control there as well.
But then again, maxscript just isn’t safe by nature and that goes for mzp, mcr and ms… so I just comes down to commonsense and ‘do I trust the developer?’.
So in short the whole security issue is not something we can address. What we can offer is a framework for doing (un)installs properly and thus minimizing the risk of messing up accidentally.