Hi Fred, More details on the "ui" env vars can be found easily in the documentation. For a start, most of them arise from the Options->User Preferences in the CIW - so hit Help on that form and it takes you to the relevant document (chapter 6 Customizing Your Design Environment in current versions of the Virtuoso Design Environment User Guide manual). If you search through that chapter for .cdsenv there are various links to specifying parts of the form using cdsenv which take you to sections of Chapter 7, Specifying Environment Settings - this covers the ui variables in detail. You will not find anything on uiLoadTrigger. This is a private (internal) function which is triggered when the cdsenv is loaded containing "ui" entries and takes care of synchronising the UI-related forms (such as the User Preferences and Log Filter forms). You would never call it yourself - it only shows up because of this bug where it is attempting to call the function in an environment where it isn't defined. Whilst I completely understand about unifying user preferences, I don't think doing this via the libInit.il is a good idea. Some of the user preferences are indeed user preferences and don't necessarily impact cross-usage efficiency. By setting them in the libInit.il, you rob the user of the ability to customise them personally. What I would do is set the things that truly are technology-specific there (e.g. default snap spacings, what the default multi-part path template is, that kind of thing), but other unified preferences I would set via a central .cdsenv file which is loaded at startup (probably via the CSF - Cadence Search File mechanism). That allows users to inherit the default settings and most likely use them, but still gives the ability to override them if they want to. The disadvantage of doing this in the libInit.il is that the file is loaded the first time you access the technology library - which will override anything you have previously set in the environment. Of course, this depends on how much a company wants to force how individual users work. My experience is that users vary considerably and forcing everyone to adopt the same settings for absolutely everything tends to lead to frustration. I've seen this in PDKs in the past where completely different bindkeys were loaded - and the PDK was being provided outside the company that created it; we were always being asked how to stop those bindkeys from being redefined every time they used that PDK. Regards, Andrew.![]()
↧