I need some help tweaking the Autodesk Viewer UI. I am working on the files as provided by a localised version output from http://extract.autodesk.io/.
I have not done any custom editing. I need help locating the relevant code and suggestions for the changes in the following areas:
The Model Browser docking panel. This opens by default with the first group in the tree Expanded (see picture). I want this first element and all other elements to open by default as Collapsed, so just the parent names are shown.
Staying in Model Browser. The Scroll Bars, (seen when model elements names are listed beyond the Model Browser window size) display correctly in the Opera and Chrome browsers,
however, they display unstyled as wide windows style scroll bars in the Firefox browser. What is needed for Firefox to display scrollbars as intended?
What code might override camera zoom property AFTER correctly loading default zoom value ?
The viewer version from http://extract.autodesk.io/ imports the scene camera properties for the start view ok, but overrides the Zoom property with another value shortly after intial page load.
1.I want this first element and all other elements to open by default as Collapsed, so just the parent names are shown.
Unfortunately far as I know there's no straightforward, native config option in Viewer to achieve this. However you can:
Hook an one-off click listener onto Model Browser button to programmatically fire a click on the corresponding notes you'd like to collapse, or directly add ‘.collapsed’ class to them. You can get a hold of the nodes either by their lmv-nodeid or their label text:
<div lmv-nodeid="9" class="collapsed group visible">
<lmvheader style="padding-left: 13px;">
<div class="visibility"></div>
<label>Switch:1</label>
</lmvheader>
</div>
Extend and build your own browser using the instanceTree and Autodesk.Viewing.UI.DockingPanel, see an example here
2.What is needed for Firefox to display scrollbars as intended?
Here is a great answer to your question. But looks like the status quo is still far from perfect, with no definite hack discovered so far. So again for a thorough solution you'd need to create your own styling (can do so with the help of something like) and apply them to .docking-panel and append .model-structure-panel or any other panels you'd like to narrow the scope to.
3.What code might override camera zoom property AFTER correctly loading default zoom value ?
This should be the code you are after.
You can manipulate camera with viewer.autocam.goToView( newView ), and see below for a sample view config:
const newView = {
position: newPosition,
up: currentView.up,
center: newCenter,
pivot: newPivotPoint,
fov: currentView.fov,
worldUp: currentView.worldUp,
isOrtho: (currentView.isOrtho === false)
}
Related
I am having an app, which uses the Forge API. The UI displayed when pushing the Forge button "Settings" in "settingsTools group", overlaps one of my buttons.
However since my app zIndex is set (I am in react code) the click upon close of the setting UI, triggers my buttons instead of the close button.
Hence, I am intrested in setting the "Settings UI" to front so the click upon the close button triggers close. My front end code is in the react framework hence a simple zIndex parameter to set could do the trick.
How can I do so?
Instead of playing with hacky ways, consider using the docking panels provided by Forge Viewer. From my understanding, it can also work with React.
To elaborate the usefulness of panels, consider the following example:
Here I have a floating div, showing me some information related to the model. Obviously I've set a high z-index, to bring it upfront and here I have the same problem as you have - when opening things like settings, properties, model tree, etc, they all appear behind my div. Moreover, when changing the size of the window, I have to deal with my div position.
On the other hand, Forge Viewer uses everywhere panels, like this very Settings dialog.
Thus, if you would place your button into this kind of panel, this would save you from headache with z-index, docking, rescaling etc, as all the panels are working nice one with each other, as the below Robot Control Panel:
For more information on how to create a panel, I suggest checking http://learnforge.autodesk.io/#/viewer/extensions/panel
I'm working with the MarkupsCore extension and want to keep my added UI open inside the viewer while adding or working with Markups.
From what I can tell once I call enterEditMode the UI won't return until I hide all of my Markups. The buttons I have added don't seem to change state and their still marked as visible when I'm debugging, yet they don't show.
I tried setVisibility on the objects but the method returns false because it evaluates the buttons as not hidden.
Is there something I'm missing?
If I'm understanding your question right, that's expected as you cannot move/rotate/zoom the model when editing the Markups, mainly because these are SVG shapes on top of the view. Ideally you should also keep the Viewer state to restore when viewing the markups later.
In my project I've got a gameCamera which is used to diplay the things inside my level and a uiCamera which displays the ui-elements.
I'm trying to take a screenshot which only consists of the level-elements and not the ui.
My attempt was to hide the uiCamera which works but it also briefly hides the ui for the user and it doesn't look very nice.
This was the code:
// hide the camera
this->getUiCamera()->setVisible(false);
utils::captureScreen([](bool captureBool, std::string path) {
// do something to make UI visible again, left this out because its not really relevant
}, "level_screenshot.png");
I also tampered around with renderTexture but that didn't work out well probably because of the parallax effect I use in the level.
Is there any way I can take a screenshot while hiding the uiCamera? Is it possible to take a Screenshot of only the gameCamera itself, maybe by using renderTexture?
My cocos version is 3.9
You can do it by adding all the Nodes(which should not be present in the screenshot) in an Array, disable the visibility of all nodes just before taking the screen shot. Enable the visibility after the screen shot taken.
I am porting a Desktop WPF application to WinRT and I'm facing a little issue.
I had a ItemsControl and I had a context menu on every item to delete / edit the item.
I have been told that PopupMenu are not good in WinRT and I should use a AppBar.
I think I'm doing something wrong or I misunderstood that.
I thought that I could put that options on a AppBar and when I select an element, popup the bar and click where I need.
The problem is that the AppBar will show up when I right click on any part of my app, so that buttons will show up with an item selected.
So can I change the layout of the AppBar on different contexts (because it seems that Microsoft wants us to use AppBar as context menu without context capabilities) or only show it when I want via code?
Would be good to have a TopAppBar with some App-wide options and a BottomAppBar just for ListView's item context menu.
Or maybe I'm doing all this stuff wrong and I have to use another approach to put extra options on the Listview's items.
You are thinking about this correctly. AppBar is the place where you should put all your non-essential and selection based commands.
The guidelines here and here suggest that they should be arranged as follows:
Navigation commands should be in TopAppBar
Commands related to selection should on the left side of BottomAppBar
The rest of page specific commands should be on the right side of BottomAppBar
Contextual commands should only be shown when a relevant item to that command is selected. For that purpose you should set Visibility of these commands accordingly. Also AppBar should open automatically when an item with contextual commands in it is selected. You can do that programmatically by setting its IsOpen property. You should also set it to sticky mode by via IsSticky property.
If you're using MVVM you can bind your viewmodel properties to all Button and AppBar properties mentioned above.
There's a CustomAppBar control available in WinRT XAML Toolkit. I haven't used it myself yet but it has a couple of extra features that might prove useful in your case.
This document outline from my sample Storyboard shows what I'm working with.
I have a custom container view controller and two content view controllers connected via embed segues.
Here is the storyboard itself.
ZetaViewController has to create some programmatic views (within ZetaView, of course). I noticed when I was centering these programmatically created views they seemed really off center.
ZetViewController is centering things by examining self.view.bounds.size.height and self.view.bounds.size.width and doing some appropriate arithmetic.
When I added debug logging to ZetaViewController, I noticed that self.view.bounds.size.height and self.view.bounds.size.width had dimensions equal to ContainerView (768 x 1004) and not ZetaView (728 x 637). The Size Inspector in IB confirms these values.
I created a distinctive value for the tag attribute of ZetaView and logged it. ZetaViewController.view really is ZetaView because the tag value confirms it.
So what is going on? Why would ZetaView, shown clearly with smaller dimensions on the Storyboard and in the Size Inspector, show the wrong values in it's properties during run time?
My problem had nothing to do with Storyboards, segues, or custom container view controllers vs content view controllers. It had to do with the new Cocoa Auto Layout features introduced in iOS 5.
My problem arose from inspecting view bounds size in viewDidLoad instead of in viewWillLayoutSubviews. At the time viewDidLoad is called, the view controller's view has not been given its proper size yet. When I moved the code which programmatically centers views to viewWillLayoutSubviews, it worked as I expected. I still leave view creation code in viewDidLoad because viewWillLayoutSubviews is called repeatedly as layout changes.
See also the View Programming Guide for iOS section "Tweaking the Layout of Your Views Manually".
Ok,I'm going to point to an excellent post that I found: (updated)
http://kevindew.me/post/18579273258/where-to-progmatically-lay-out-views-in-ios-5-and
I was having an awful time adding shadow calayers to views after autolayout had done its magic. viewDidLoad, viewWillLoad etc did not have everything correctly laid out.
viewWillLayoutSubviews is called quite a few times and the state isn't fully set up. However... In viewDidLayoutSubviews, finally everything was set up as I expected.