When using an Oculus Rift, if the Touch controllers are disabled (turned off), there is a pointer attached to the HMD and I can use the Gaze Provider, but when at least one of the controllers is enabled, the pointer associated with the Gaze Provider disappears.
Is this the intended behaviour?
Is there a way to re-enable the Gaze Provider pointer?
This sounds like the currently intended behavior, but I'd like to better understand your use case to try to support it better.
Do your controllers gain their own pointing ray when connected? If not (and your pointers profile contains a DefaultControllerPointer prefab)
then we might have some misconfigurations with regards to the Touch controllers.
Otherwise, if you never want controller-specific pointers and only want to use the gaze pointer, you can select and delete the DefaultControllerPointer definition, or uncheck Oculus Touch from the Controller Type dropdown.
Related
I want to draw into a Tk 8.6 frame using Cairo C/X11 code. I found that I could prevent the frame from redrawing itself in case of Expose events (e.g. window size changes) by passing -background "" as option to the frame (so basically the frame doesn't know what to redraw). Two questions:
Is there a better way to tell a frame to not redraw itself but to leave it to somebody else?
Can I replace Tk's internal event handlers (for Expose etc.) by my own on the C level? (At the moment I'm doing it on the Tcl level by bind $frame <Expose> "myExposeHandler...".)
Thanks for your help!
(The -container yes option seems to have no effect, btw.)
The -background "" option is the one which disables redraws of frames, and is typically used where you're going to hand off the XId of the frame as the handle to draw on to some other process. (This used to be how people would integrate video players; I don't know how practical that still is.) There's also the -container true option, as you found, but that's intended only for use where you're going to embed a toplevel from another Tk process inside the frame (it enables a special protocol for exchanging geometry manager information, IIRC) and isn't what you want here.
However, if you're already working with your own C code then you might as well make your own widget. Then you'll have complete control over all the event handling and can do anything you want. The usual place for people to start when doing this is with the square widget in the Tk sources (too long to include here). That demonstrates a lot of things about how Tk does event handling, such as postponing of updates until “idle” (i.e., effectively event coalescing) and handling Tk's configuration system. The key things are that you define a widget record that has all the configurable fields and anything else you need to make the widget work in it (see the Square typedef), a list of option specifications that describe what bits are to be configured and what the defaults are (see the optionSpecs static declaration), a constructor command (SquareObjCmd), an instance command (SquareWidgetObjCmd), an event handler (SquareObjEventProc), and a drawing callback (SquareDisplay). There's other bits too, like how to delete things and so on, but I'm sure you'll get the hang of those. Then all you have to do is register the constructor command as normal for Tcl commands; it's the usual for any code that extends Tcl/Tk.
Doing it this way is a bit more work, but it will make a much more robust binding between your real code and Tcl. It's up to you to decide how much complexity you put in the instance command; Tk's own widgets vary from the very simple (the messagebox widget is only slightly more complicated than the square example widget) to the hugely complicated (both the canvas and the text are really complicated pieces of code).
I'm starting a new project from scratch, and while I've also been creating and handling views and viewcontrollers programmatically so far (some some xibs from time to time, for some simple views), I'm now wondering if it's time to switch to Storyboards. It looks like Apple is pushing for them really hard, and maybe I shouldn't fight against them and embrace the new approach? (not really new, but maybe now mature?)
Pros:
You can really see your app and the connections between the app. If you have some UI that doesn't need logic (for example Terms Of Service with some static text and an Agree button that takes you to the next screen) you don't even need to create the controller part of that.
Cons:
If you're in a big team, storyboards can be really hard to merge when using version control.
Fore more info:
http://www.youtube.com/watch?v=XciUazpOfFU
Almost only cons. Here's is a list of their problems, copied from iraycd:
Storyboards fail at runtime, not at compile time: You have a typo in a segue name or connected it wrong in your storyboard? It will blow up at runtime. You use a custom UIViewController subclass that doesn't exist anymore in your storyboard? It will blow up at runtime. If you do such things in code, you will catch them early on, during compile time. Update: My new tool StoryboardLint mostly solves this problem.
Storyboards get confusing fast: As your project grows, your storyboard gets increasingly more difficult to navigate. Also, if multiple view controllers have multiple segues to multiple other view controllers, your storyboard quickly starts to look like a bowl of spaghetti and you'll find yourself zooming in and out and scrolling all over the place to find the view controller you are looking for and to find out what segue points where. Update: This problem can mostly be solved by splitting your Storyboard up into multiple Storyboards, as described in this article by Pilky and this article by Robert Brown.
Storyboards make working in a team harder: Because you usually only have one huge storyboard file for your project, having multiple developers regularly making changes to that one file can be a headache: Changes need to be merged and conflicts resolved. When a conflict occurs, it is hard to tell how to resolve it: Xcode generates the storyboard XML file and it was not really designed with the goal in mind that a human would have to read, let alone edit it.
Storyboards make code reviews hard or nearly impossible: Peer code reviews are a great thing to do on your team. However, when you make changes to a storyboard, it is almost impossible to review these changes with a different developer. All you can pull up is a diff of a huge XML file. Deciphering what really changed and if those changes are correct or if they broke something is really hard.
Storyboards hinder code reuse: In my iOS projects, I usually create a class that contains all the colors and fonts and margins and insets that I use throughout the app to give it a consistent look and feel: It's a one line change if I have to adjust any of those values for the whole app. If you set such values in the storyboard, you duplicate them and will need to find every single occurrence when you want to change them. Chances are high that you miss one, because there's no search and replace in storyboards.
Storyboards make you do everything twice: Are you building a universal app that runs both on iPad and on iPhone? When you use storyboards, you will usually have one storyboard for the iPad version and one for the iPhone version. Keeping both in sync requires you to do every UI or app-workflow change in two places. Yay. Update: In iOS 8 and Xcode 6, you can use a single Storyboard for iPhone and iPad.
Storyboards require constant context switches: I find myself working and navigating much faster in code than in storyboards. When your app uses storyboards, you constantly switch your context: "Oh, I want a tap on this table view cell to load a different view controller. I now have to open up the storyboard, find the right view controller, create a new segue to the other view controller (that I also have to find), give the segue a name, remember that name (I can't use constants or variables in storyboards), switch back to code and hope I don't mistype the name of that segue for my prepareForSegue method. How I wish I could just type those 3 lines of code right here where I am!" No, it's not fun. Switching between code and storyboard (and between keyboard and mouse) gets old fast and slows you down.
Storyboards are hard to refactor: When you refactor your code, you have to make sure it still matches what your storyboard expects. When you move things around in your storyboard, you will only find out at runtime if it still works with your code. It feels to me as if I have to keep two worlds in sync. It feels brittle and discourages change in my humble opinion.
Storyboards are not searchable: A project-wide search in Xcode is not really a project-wide search when you use storyboards. They are not included in the search. So when you remove a custom class from your code or rename it, you will have to manually go through the storyboard or look at its raw XML to make sure it is on par with your code changes. No sir, I don't like it. Update: Storyboards are searchable in Xcode 6.
Storyboards are less flexible: In code, you can basically do anything you want! With storyboards you are limited to a subset of what you can do in code. Especially when you want to do some advanced things with animations and transitions you will find yourself "fighting the storyboard" to get it to work.
Storyboards don't let you change the type of special view controllers: You want to change a UITableViewController into a UICollectionViewController? Or into a plain UIViewController? Not possible in a Storyboard. You have to delete the old view controller and create a new one and re-connect all the segues. It's much easier to do such a change in code.
Storyboards add two extra liabilities to your project: (1) The Storyboard Editor tool that generates the storyboard XML and (2) the runtime component that parses the XML and creates UI and controller objects from it. Both parts can have bugs that you can't fix.
Storyboards don't allow you to add a subview to a UIImageView: Who knows why.
Storyboards don't allow you to enable Auto Layout for individual View(-Controller)s: By checking/unchecking the Auto Layout option in a Storyboard, the change is applied to ALL controllers in the Storyboard. (Thanks to Sava Mazăre for this point!)
Storyboards have a higher risk of breaking backwards compatibility: Xcode sometimes changes the Storyboard file format and doesn't guarantee in any way that you will be able to open Storyboard files that you create today a few years or even months from now. (Thanks to thoughtadvances for this point. See the original comment)
It's McDonald's: To say it in Steve Jobs' words about Microsoft: It's McDonald's (video)!
One other Pro exclusive to UIStoryboards: Static table view cells. Per Apple, "With static content, the number of rows is a finite quantity that’s known at compile time. A table view that presents a detail view of an item is a good candidate for static content."
recently, i ran into a problem where i needed to access the List object from the List's custom cell renderer class.
there were 2 options:
listen for and dispatch a custom event to communicate between the 2 classes.
reference the List from the cell renderer class with the parent property: List(parent.parent.parent)
while it's much easier to choose the second option, i feel that dispatching and listening for a custom event would result in code that's more inline with the design of AVM2, offers greater control for communication and, as it's expected AS3, should be less difficult to debug or maintain within new hands.
however, i also feel that using an event is more expensive, requires attention to resource management perhaps making it more difficult to debug and maintain and could be generally overkill.
is this simply a matter of needs or taste? should dispatching/listening for custom events be avoided if they can be?
Don't forget that you can't see the control flow of event listeners from single glances at the code.
While I'm not against event listeners completely, if you use them, you should try to use them in the most self-documenting and simple way possible. If you have clever stuff, like adding/removing event listeners, and it goes wrong, then it can be a nightmare to debug because you cannot see what dispatchEvent is going to do.
If owner gets you the right object, then I would just go with that, myself.
I would look at it from another angle. If the other option ends up creating more dependency between the two classes, I would definitely opt for event dispatching.
In that regard , I'm not sure why you think that an event driven application would be harder to debug & maintain. It would seem to be the opposite, but it would of course depends on how one implements the event dispatching in the application. But saying this and re-reading your question I realize you seem to contradict yourself! Of course , I tend to agree with the first statement.
...offers greater control for communication and, as it's expected AS3,
should be less difficult to debug or maintain...
...perhaps making it more difficult to debug and maintain and
could be generally overkill.
Suppose the application will only use a single-purpose view controller. Is there anything inherently bad with allocating the required UIWindow object as a member of the view controller subclass?
The programming guide does not provide any examples built this way, although they also don't seem to emphasize whether that's truly allowed or not.
I was asking the same question and found yours. After a look around, I found that going back to basics was the correct thing to do, so
http://developer.apple.com/library/ios/#documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/Introduction/Introduction.html
I am writing a game in AS3 and have, as an example, around 40 objects on screen. Let's say they are clouds. I'm wondering which of the two paths would be less a strain on system resources:
a) Put an eventListener on each object and have it update itself, or
b) Loop through the array and manually update each object
Or is the performance difference negligable? Does either solution scale better than the others?
I would expect the performance to be fairly negligable either way. Once you get a lot of objects you might see a difference (with the loop being the winner). From my experience Adobe put a lot of work into optimizing the actionscript event listener path.
This is a tricky one, purists would say to to go with the array looping method, as with this method it would be possible to cut out the 'view' out of the MVC and still have the system working (which is a good test of any system). However, if you are working with the events you can cut some corners with event bubbling and strict typing.
For example if we assume you make a custom event called CloudEvent that has a property called cloud that contains a reference to the dispatching CloudSprite, then as long as the event bubbles by default, you don't need to add an event listener to each one, just to the DisplayObjectContainer which holds them (which I am imaginatively calling CloudContainer). This way the event bubbles up and you only have to add one listener, and don't have to worry about managing listeners on child items.
public function CloudContainer()
{
super();
addEventListener(CloudEvent.CHANGE, cloudChangeHandler);
}
private function cloudChangeHandler(evt:CloudEvent):void
{
var cloud:CloudSprite = evt.cloud;
cloud.update();
}
Hope this helps
I am under the impression that event listeners require more resources so it is better to use an array when performance is required. It would also scale better for that reason. If you are using Flash 10 then use a Vector, I believe it offers better performance than an array (and type saftey).
Use EventListeners! Just make sure you manage them properly ie. remove them when you done, use weak references.
You wont really find much performance from doing things like this. Usually better performance comes from the bigger ticked items, like not using filters, lowering the frame-rate etc. So punishing your code clarity and OO for the sake of a half a millisecond is not worth it in my book.
There are a few really great guides out there that will teach you all about optimizing in AS3. The best one I have found is Grant Skinner's; AS3 Resource Management. And I just found a quicker seven step version. I would definitely recommend everyone doing AS3 should read the Grant Skinner slides though.
Of course don't just take my word (or anyone else answering your question), you can do you own tests and actually see whats up using a profiler. See Lee Brimlow's latest video tutorial for how to do this. It is worth the watch! Check it out here: GotoAndLearn - ActionScript 3 Performance Testing.