I am currently calculating xFov, yFov for my SCNCamera when creating a SCNView. This worked find up to now, since the scene has always occupied the entire screen.
I now need to support a scenario where this is no longer the case, i.e. the cameras field of view (xFov, yFov) should be recalculated whenever the SCNView changes its size.
Where is the best place to insert the code that does the recalculation? If possible, I would prefer not to subclass SCNView.
Since Yosemite NSViewController exposes viewWillLayout and viewDidLayout. It might be the right place recalculate your fields of view.
Related
I know this is bad, but I'm asked to adopt to a given interface, which manually performs layout transitions of render targets before submit/present calls.
So, while I usually would want to specify (in the creation of the corresponding render pass) the initialLayout resp. finalLayout of the VkAttachmentDescription corresponding to such an render target to be VK_IMAGE_LAYOUT_UNDEFINED resp. VK_IMAGE_LAYOUT_PRESENT_SRC_KHR and the layout of the corresponding VkAttachmentReference to be VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL, I have no idea how I should set these fields now.
It seems like there is no possibility to tell the API to perform a no-op, i.e. preserve the current layout of given the attachment.
(BTW, is there an analogue of D3D12's D3D12_RESOURCE_STATES::D3D12_RESOURCE_STATE_UNORDERED_ACCESS?)
A "no-op" doesn't make sense. You must control the layout, and you are required to know the layout of every image you are using for any given purpose at the time you use it for that purpose. If you are working in code where someone else determines what the layout is, then those people need to tell you what layout those images are in (if you need the render pass image's data to be preserved, which is rather rare) and/or need to be in after the render pass.
If you're working with an API or code structure that does not give you this information, then that is what you need to change.
I have 2 Objects that I have combined with the union/fusion control
The result is as expected, but now I would like to remove the remaining lines of the separate objects (at least in my view).
I understand the underlying principle of the stacking object tree and its good to have them still all available as single entities, but I would like to hide what would not be seen in reality also in my view.
Any takers?
Thanks
For anyone who's interested I found the solution. The view property dialog allows you to change the document window setting to "shaded" which hides the lines.
good demo of my problem: http://fabricjs.com/hovering
If you select any item, it is displayed on top.
In earlier versions (1.5.0 - 1.6.2) this problem does not exist.
Sorry for bad English.
If you dont want thie behaviour, you can set the preserveObjectStacking to true. Check the docs here: http://fabricjs.com/docs/fabric.Canvas.html
However, there is this one issue with background objects, so beware https://github.com/kangax/fabric.js/issues/3095
Hopefully, they'll push a fix soon otherwise your last resort would be going back to 1.6.2.
I believe that is meant as a convenience for the user. Although the object moves to the front while selected, as soon as it is deselected, it falls back to its original z-order.
You can test this out at the hovering demo you linked. Superimpose two objects and determine which is front of the other then select and deselect the object in the back. When you hover over them, the order should still be observed to be the same.
When using the Ext.Lib Name Picker control connected to the NAB, the default is to view the first 50 entries from selected view (depending on whether groups/Persons is selected in property).
But there are no scroll/paging buttons on the dialog.
If I want to pick an entry from the NABPicker and the entry is after the first 50 I must use the Search button to find it.
Is this working as designed or a feature not yet added?
/Mike
You might be interested in using the viewpicklist control from openntf instead, link
It is very felxable, just set it to use the names.nsf and whichever view you need.
As far as I know this is working as designed. The server only returns a set number of entries so that the amount of data transfered when opening the Name Picker dialog box is kept nice and small, this way the dialog box opens faster.
You can increase the number of entries returned by increasing the maximum limits in the server document and internet site document and then increasing the maxRowCount attribute on the picker but you will seriously affect the performance of your application and it is not recommended.
Hopefully in a future release of the control they will add some sort of ajax based scroll similar to the inbox scroll in iNotes.
Mike:
I think the answer is "both". Working as designed and feature not added yet...
The Ext Lib is a open source initiative designed to support the simplistic Discussion, Team Room, and Document Library applications. The designers have limited experience with more complex applications and clearly limited exposure to large address books in their development arena.
The NAB pickers are a source a major disapointment to those of us trying to build larger scale applications. Perhaps at some point it will become a usable component but is is only marginally usable at this point.
/Newbs
I know i can use
<mt:EntryAssets lastn="1">
<img src="<$mt:AssetThumbnailURL width="100"$>" />
</mt:EntryAssets>
to show the 'last' asset...how do I show the 'first' or 'oldest' assest?
[I'll point out here that "first" and "oldest" are not necessarily the same question.
You'll see why this is important below. Given the snippet you used, I'm going to assume what you're asking for is first as in position within the entry content. Sorry for length, but this is one of my pet bugs.]
Technically, you can't. That bug(summarized further down if you don't have an Fbz account) has finally been attached to a milestone, so hopefully this won't always be the case.
Practically, reversing the sort order will usually probably output what you expect:
<mt:entryassets limit="1" sort_order="ascend">
...as long as you compose your entries top-to-bottom, and don't later mess with the assets much
The underlying problem is that the current EntryAssets implementation doesn't actually take your content into account. It just loads a list of associated assets and then sorts them by the created_on dates of the assets themselves, not what physical order they appear in or even when they were attached to that particular entry. So as an extreme example, if you insert five images into a post, my snippet above will return the first image, as expected. If you later reverse their order and save, it'll still output that same image, which is now the (ordinal) last one. So, back to what I said at top, you're thinking "first" and MT is always giving you "oldest." And this requires an even further assumption that you're always uploading the assets at time of composition. If one of them was already in the system from say, two years ago, it's going to get returned because it's just older than everything else.
If you're using MT4.3x with the Entry Asset Manager in the sidebar of the composition screen and use it to attach(rather than insert) assets, this is going to get even more complicated, because there's no way to distinguish between assets that were associated with the entry via each manner.
So.
If you absolutely need the returned asset to be predictable, you'll need to actually distinguish it from the group in some way. There's this suggestion to tag the asset with "#first" or something similar. It's not great, but you'll at least know what you're getting(assuming you only tag one asset per entry as such). If you've got custom fields available, you might see if it makes more sense to create a separate "featured/thumbnail image" asset field that it would go into so that you could explicitly test for it. It'll ultimately depend some upon why you're wanting to extract this particular asset.