There is an app call DurionLite (free on iPhone) which plays a word game where letters are clicked and dragged into word construction slots to create words. As the dragged letter gets near the construction slots, the borders of the nearest construction slot is highlighted and if you then release the letter, it goes into the highlighted construction slot. You can also then click and drag letters from the construction slots (although not back to their original locations). I'm trying to do a similar thing but can't figure out how that can be done. Can anyone enlighten me?
The second one worked man. It seems more complicated but part of the code doesn't even need to be there.
Related
I have programmed a 90 second sequence in Google Earth Studio and I want to slow down the middle section only.
(I think there could be a long and dirty workaround by changing the overall time of the video in project settings and selecting scaling, then swaping in copies of the original start and finish, and link them all back together - but there must be an easier way to do this!?)
If there is a better forum for Google Earth Studio programming questions, please share in Comments.
I have found a better way to slow down a section of Google Earth Studio but it's still a bit clunky.
Increase the overall length of the animation in project setting, see above.
Highlight all the keyframes AFTER and including the end of the section to stretch (the spots on the keyframe editor, bottom half of screen).
Drag the selected keyframes to the right. This increases the time to get between the 2 keyframes (section to be stretched) automatically slowing the section down.
Tip 1: Selecting multiple keyframes (spots) - click and drag mouse but remember to select all keyframes including those out of sight. Scroll down to lower attributes.
Tip 2: Roll up (shrink) attributes before selecting multiple keyframes. This usually means that you can see everything without needing to scroll down. Click the small arrow next to the attribute (far left of keyframe editor).
Tip 3: You can always select keyframes manually, just hold down shift when you click on them to add to original selection.
Add to the comments if you know an easier way slow down a section of Google Earth Studio.
I've implemented a musical keyboard as a subclass of Fixed and where each individual key is a subclass of DrawingArea, and so far, it works great: custom drawing code in expose, press+release functionality working... kind of. See, here's the problem: I want the user to be able to drag the mouse across the keyboard with the mouse down to play it. I currently capture the button press and release signals, as well as enter and leave notify. Unfortunately, this doesn't quite work because the widget seems to grab focus of the mouse as soon as the mouse is pressed over it. This makes sense for normal buttons, but not for a musical keyboard. Is there any good way to remedy this other than rewriting the entire keyboard to be one massive DrawingArea?
Also, it shouldn't matter, but in case it does I'm using GTK#.
You might consider using GooCanvas: You can represent each of the keys as CanvasPolylines, fill them with the colors you need. Each of the Canvas items is a GtkWidget, so you can act on events like enter, leave, button-pressed etc.
This method seems to make more sense (to me) than separate DrawingAreas. As each drawn element is still accessible, you can even change colors/size and other properties dynamically. Also, Polyline lets you make more complex shapes.
I have a bunch of Tank objects inserted into a quad tree. Some of these tank objects can be clicked on if they implement a Clickable interface. The problem is that in order to know what is being clicked, I need to query the same quadtree, but the quadtree has both clickable and non-clickable objects in it.
Potential solutions:
I could using instanceOf to see which ones in a specified region were clickable when the user clicks the screen, but I hear that using instanceOf is bad practice.
I could maintain TWO quadtrees. one for just tanks, and one for clickable objects. But then I could have to update tanks that implement the clickable interface TWICE since they would be in two seperate quadtrees, which would be slow considering I have to update every step, and people only click the screen every so often.
I could only insert clickable objects into the quadtree, and simply make non-clickable objects define dummy click methods. This would solve the problem, but it doesn't feel right because if something is non-clickable, then it shouldn't be implementing a clicking methods to begin with even if it is an empty one. Or is this ok?
I'm thinking #3 is probably the best way to do it, but I'm not sure. Any pointers?
EDIT: Now that I think about it, #3 would have some problems dealing with overlapped clicks. If a non-clickable tank overlaps a clickable one, and I click in the overlap section, unless I call all click methods for everything at that point, I could end up calling the click method of the wrong tank. To avoid doing THAT, I'd have to use instanceOf and find the clickable object and only call ITS click method.
So maybe #2 is better because I could easily cycle through all clickable objects at the clicked region and choose the one that is either at the top, or closest to the center of the region, and only call that tanks click method.
It could also not necessarily be that they overlap, but are just close together. If I were to make this game touch based, your finger isn't a point, but a region, so it might be better to cycle through objects in a region and find the closest clickable object, which would be hard to do with 3# without sifting through a bunch of non-clickable objects.
#3 sounds pretty good. You could maybe enhance it by creating another interface that ALL your objects implement, for example "GameObject", which has a method "isClickable". Then you can have your clickable objects implement a "return true" for isClickable.
To better explain this I'll use Doodle Jump as an example. Assuming that the platforms are recycled, when the character jumps up and the new platforms appear (by scrolling down) there is occasionally a propeller hat on one of them. is there a recommended method to manage this new object? Should I instantiate a single one of these power-ups in the game level's "init" method, and then set a boolean to flag whether it appears in my render method and update methods? Or should I instantiate it at the time that I want it to appear (i.e. just before the new platform scrolls down from its position just above the screen) and release it when it's a) grabbed by the character sprite or b) moves off the screen untouched?
Thanks!
Scott
I vote for the latter - instantiate it at the time you want it to appear. If you use some flag to determine whether to display it or not, you'll end up with a bunch of special-case code; not something you want, especially for something this relatively simple.
Considering that you're developing for a mobile device, if for some reason the construction of this object is effecting performance, then I would look into alternate methods (i.e., instantiate once, use flag to render/update).
I am creating an application with call functionality, I want to have the phone image on the right hand side and the name of the contact on the left hand side. Currently this has been implemented by placing the 2 buttons side by side, hence if the user clicks on any of the buttons, the same functionality (calling the contact) happens.
Is this allowed according to Apple HIG? Please let me know.
Thank You,
Ashvin
I don't think anything in the HIG specifically disallows this, but it seems like a bad idea, for a couple of reasons:
If there are two buttons side-by-side, users will assume the buttons do different things, and will be confused when they don't.
It wastes screen real-estate that could probably be put to better use.
From your description it is hard to tell exactly what this looks like, but it sounds like something that needs to be re-designed.
Overlapping buttons?
It might not give you an intuitive UI, as the content of the overlapped button might get truncated by the overlapping button.
As Kristopher has explained, it will result in a bad user experience.
It is possible, that your app might get rejected because of the truncations as the user will not be readily able to perceive the content.
If look of the button is what you are concerned about, then you can just set one image (whether odd shaped or not) to one button, as long as the user is able to perceive that it is a button.
In the odd shaped image, you should also ensure that the functionality does not get triggered when the user touches the transparent area of the image, otherwise it might confuse the user.
Hope these points help!
Is there any mention about overlapping the buttons? Suppose for better design/look and feel, I have to place two buttons which partially overlaps each other, is it disallowed? Still the screen looks good and there will not be any confusion about the buttons. But only point is they are two different buttons, which assumes same functionality and has overlapped.
Adding some more information on the about query.
The buttons are overlapping as one is just a graphics and another is a rounded rectangle button whose Title changes dynamically.
If they can not be overlapped, can we have an odd shape button on the screen as long as user feels that they are buttons?
Thanks.