I am building a graphic board like project where i am facing a design issue.
Main Class is Board which is a canvas responsible for handling mouse events when drawing shapes. It also has context variables such as currentShape or snapFlag to activate grid magnetism.
To handle the moving / resizing / rotating of the shapes, they inherit from a third party open source tool called ObjectHandles (flex).
I have a baseShape extending ObjectHandles main class to override some of its internal functions, like the onMove function.
When creating a shape (mouse down, move, mouse up) this is handle by the Board and it knows about his own snap flag.
var mouseUpPoint:Point = boardCanvas.globalToLocal(new Point(event.stageX, event.stageY));
var snapMouseUpPoint = snapPoint(mouseUpPoint.x, mouseUpPoint.y);
In my overidden onMove method i would like the shape to be aware of the Board snap flag and when its changing. How do i do this ?
Do i pass the Board as a parameter in my basicShape constructor so that i can check snap ?
Do i pass the flag as a parameter and somehow make all shapes listen for change ?
What is the cleanest solution ?
Thanks a lot.
I would approach this from a slightly different angle. I assume that the Board object traps mouse events first, so that it can decide which shape has been clicked on. I would have the board trap mouse movements as well, passing the correct (snapped or unsnapped) coordinates "down" to the selected Shape object, rather than letting the shape object figure it out.
This leaves the grid snap handling to the Board, and keeps your Shape object onMove method free of clutter.
Not knowing your app:
Is it ever possible for a Shape to have it's own 'snap' behavior? That is, could a Shape be excluded from snapping while others aren't? If so, make snapFlag a member of Shape. When snapFlag is set on the Board, iterate through your Shapes and set or don't set according to your rules.
If snapping behavior applies to all Shapes on the Board, consider an event-driven model (if it's available - I'm a Flex noob). When a Shape moves, have it raise an OnMove event. The Board can then respond and decide to 'snap' the Shape into place if it's appropriate.
If snap behavior applies to all Shapes and events aren't available, I'd just say the hell with loose coupling in this case - make the Shapes Board-aware. It sounds like you're saving a bunch of code by using the ObjectHandle. That benefit may out-weigh the cost of coupling your UI elements.
Just trying to think together with you..
I see no big deal in Shapes having IBoard interface.
Though, I don't like the idea that they have to check the flag on the board...
How would you pass the flag as parameter? In OnMove() method? didn't understood this quite well...could you expand?
Though..
If you try to think a bit about SRP - single responsibility principle...what is the responsibility of Shape classes?
Yea, this is what eJames wrote already.
It feels to me that their main responsibility is probably NOT handling mouse events...here need to know more about your application, but my general feeling is why not someone else get this mouse down and then figure out what the shape should do with it and for instance call Draw() on the Shape with new coordinates?
Let's say you want to apply something like Composite pattern (Shapes inside shapes...) and you want them to be able to handle those mouse events themselves...but then
Then it would be logical if they perceived this mouse event in their local coordinates, but then I think you should provide all the information through this event (local coordinates, mouse status...) so that they don't have to ask for "global" variables on the board...
Passing the flag as a parameter for the shape constructor. But it wont be good since flag is going to change and i have to make each shape to update their flag copy on change.
Its true that shape responsibility is not to know how to handle mouse events. But thats what ObjectHandles do: react to events, update height width rotation parameter of the shape.
Maybe i should transfer some of the library code in my board class to handle shape selection and movement / resizing / rotation.
OnMouseMove ObjectHandles
protected function onMouseMove(event:MouseEvent) : void
{
if( ! visible ) { return; }
if( ! event.buttonDown )
{
setMouseCursor( event.stageX, event.stageY );
return;
}
if(parent == null )
{
return;
}
var dest:Point = parent.globalToLocal( new Point(event.stageX, event.stageY) );
var desiredPos:Point = new Point();
var desiredSize:Point = new Point();
var desiredRotation:Number = 0;
... plenty more
then
if( wasMoved ) { dispatchMoving() ; }
if( wasResized ) { dispatchResizing() ; }
if( wasRotated ) { dispatchRotating(); }
So i can not listen for move event and tell the board to snap it since the shape is already moving freely. I should add snap here:
var dest:Point = parent.globalToLocal( new Point(event.stageX, event.stageY) );
All shapes follow the snap rule there can not be one snapping and the other free.
Solved it this way:
Since i overridde onMouseMove in my baseShape class and i am using PureMVC framework, i just made baseShape aware of my boardMediator.
override protected function onMouseMove(event:MouseEvent) : void
{
[...]
// added on override
var board:BoardMediator = ApplicationFacade.getInstance().retrieveMediator(BoardMediator.NAME) as BoardMediator;
Then
desiredPos = board.snapPoint(desiredPos.x, desiredPos.y);
Maybe not super pretty but it works, o
Overridding the globalToLocal method in my board view did work too but some more calculations were done inside onMouseMove resulting in an out of alignment snap move.
Use ObjectHandles Version 2, and then create a constraint to do what you want.
Related
A-frame provides easy to use and powerful audio capabilites via its <sound> component.
After playing around with various sound options such as native html5 for my game (in progress), I came to the conclusion that A-frame sound is the best option because it automatically provides spatialized sound (e.g. that varies with head rotation), as well as varying in intensity as you near the sound source -- things that increase VR presence and all for the cost of defining a simple html tag.
Unfortunately, A-frame doesn't provide a fadeout utility to taper the sound upon stoppage, and thus can generates a distinctly audible and annoying click on some waveforms, esp. sounds that are of variable length and not tapered in the waveform itself (for instance, a space ship's thrust). This is a well known problem with computer audio.
I was able to find some html5 audio solutions and a really good three.js audio three.js audio solution, but I could find none specific to A-frame.
What's the best way to taper out a sound in A-frame to reduce/eliminate this click?
Introduction
A-frame sound audio wraps the three.js positional audio API, which in turns wraps native html 5 audio. Most solutions out there are tailored for either pure html5 or for pure three.js. Since A-frame is a hybrid of the two apis, none of the provided solution are great fits for A-frame.
After two false starts at coming up with something, I disovered tween.js, which is not only built-in to A-frame (don't even have to download the library), but is also a useful API to know for other forms of computer animation. I provide the main solution here as well as a plunker in the hopes that others can find something useful.
Note that you don't need to do this for short burst sounds like bullets firing. These sounds have a fixed lifetime, so presumably whoever creates the waveform makes sure to taper them in and out. Also, I only deal with fade out, not fade in becuase the sound I needed only had problems with fadeout. A general solution would include fadein as well.
Solution
1) We start off with creating a real basic scene onto which we can our audio:
<a-scene>
<a-assets>
<audio id="space-rumble" src="https://raw.githubusercontent.com/vt5491/public/master/assets/sounds/space-rumble.ogg" type="audio/ogg"></audio>
crossorigin="anonymous"
type="audio/ogg"></audio>
</a-assets>
<a-box position="-1 0.5 -3" rotation="0 45 0" color="#4CC3D9"
sound="src: #space-rumble; volume: 0.9"
></a-box>
</a-scene>
The cube and scene in this solution are really just placeholders -- you don't need to enter VR mode to click the buttons and test the sound.
2) The code presents three buttons: one to start the sound, one to "hard" stop it using the A-frame default, and a third to "easy" stop it using tween to taper it down to zero. A fourth input allows you to vary the taper time. While it might look like quite a bit of code, keep in mind about 50% is just html boilerplate for the buttons, and is not part of the solution "proper":
// created 2017-10-04
function init() {
let main = new Main();
}
function Main() {
let factory = {};
console.log("entered main");
factory.boxEntity = document.querySelector('a-box');
factory.sound = factory.boxEntity.components.sound;
factory.volume = {vol: factory.sound.data.volume};
factory.boxEntity.addEventListener('sound-loaded', ()=> {console.log('sound loaded')});
factory.startBtn =document.querySelector('#btn-start');
factory.startBtn.onclick = ( function() {
this.sound.stopSound();
let initVol = factory.sound.data.volume;
this.volume = {vol: initVol}; //need to do this every time
this.sound.pool.children[0].setVolume(initVol);
console.log(`onClick: volume=${this.sound.pool.children[0].getVolume()}`);
this.sound.currentTime = 0.0;
if( this.tween) {
this.tween.stop();
}
this.sound.playSound();
}).bind(factory);
factory.hardStopBtn =document.querySelector('#btn-hard-stop');
factory.hardStopBtn.onclick = (function() {
this.sound.stopSound();
}).bind(factory);
factory.easyStopBtn =document.querySelector('#btn-easy-stop');
factory.easyStopBtn.onclick = (function() {
let sound = factory.sound;
this.tween = new TWEEN.Tween(this.volume);
this.tween.to(
{vol: 0.0}
, document.querySelector('#fade-out-duration').value);
this.tween.onUpdate(function(obj) {
console.log(`onUpdate: this.vol=${this.vol}`);
sound.pool.children[0].setVolume(this.vol);
console.log(`onUpdate: pool.children[0].getVolume=${sound.pool.children[0].getVolume()}`);
});
// Note: do *not* bind to parent context as tween passes it's info via 'this'
// and not just via callback parms.
// .bind(factory));
this.tween.onComplete(function() {
sound.stopSound();
console.log(`tween is done`);
});
this.tween.start();
// animate is actually optional in this case. Tween will count down on it's
// own clock, but you might want to synchronize with your other updates. If this
// is an a-frame component, then you can just use the 'tick' method.
this.animate();
}).bind(factory);
factory.animate = () => {
let id = requestAnimationFrame(factory.animate);
console.log(`now in animate`);
let result = TWEEN.update();
// cancelAnimationFrame is optional. You might want to invoke this to avoid
// the overhead of repeated animation calls. If you are putting this in an
// a-frame 'tick' callback, and there's other tick activity, you
// don't want to call this.
if(!result) cancelAnimationFrame(id);
}
return factory;
}
Analysis
Here are some relevant items to be aware of.
Mixed API's
I am calling some native A-frame level calls:
sound.playSound()
sound.stopSound()
and one html5 level call:
this.sound.currentTime = 0.0;
but most of the "work" is in three.js level calls:
this.sound.pool.children[0].setVolume(initVol);
This does make it a little confusing, but no single api is "complete" and thus I had to use all three. In particular, we have to do a lot at the level that is wrapped by A-frame. I learned most of this by looking at the aframe source for the sound component
Sound Pools
Aframe allows multiple threads for each sound, so that you can have the same sound fire off before the prior one has completed. This is controlled by the poolSize property on the sound component. I'm only dealing with the first sound. I should probably loop over the pool elements like so:
this.pool.children.forEach(function (sound) {
..do stuff
}
});
But doing the first one has worked well enough so far. Time will tell if this is sustainable.
'this' binding
I chose to implement all the functionality using a factory object pattern, and not placing all the methods and variables in the global document space. This mimics the enviornment you would have if you're implementing in Angular2 or as a native A-frame component. I mention this because we now have callbacks nested inside function nested inside a wrapping "main" function. Thus be aware that "this" binding can come into play. I bound most of the support functions to the factory object, but do not bind the tween callbacks, as they are passed information in their "this" context, and not passed via parms. I had to resort to closures for the callbacks to get access to the instances variables of the containing class. This is just standard javascript "callback hell" stuff, but just keep in mind it can get confusing if you're not careful.
canceled animation
If you have a tick function already, use that to call TWEEN.update(). If you're only fading out sound, then it's overkill to have an animation loop running all the time, so in this example I dynamically start and stop the animation loop.
tween can be chained.
Tweens can be chained in jquery fluent API style as well.
Conclusion
Using tween.js to phase out the sound definitely feels like the right solution. It takes care of a lot of the overhead, and design considerations. It also feels much faster, smoother, and robust than the native html5 calls I previously used. However, it's pretty obvious that it's not trivial to get this working at the application level. A fadeout property, implemented in Tween.js, seems like it should be part of the A-frame sound component itself. But until that time, maybe some people will find some of what I provide here useful in some form. I'm only currently learning about html audio myself so apologies if I'm making this seem harder than it really is.
I did some survey, if it might be possible to use QtTest to test some of my custom Qt Widgets.
I was able to build and run tests and I was also able to simulate events and check them with QSignalSpy.
The widgets I'm going to tests are not revealing their internal subwidgets, so that I have to simulate the positions of my mouse clicks relative to their parent widget.
For some reason I'm failing with this approach. The following snippet shows what I'm trying to achieve.
auto button=new QPushButton("Hello");
auto grpBox = new QGroupBox("Group Box");
grpBox->setLayout(new QVBoxLayout);
grpBox->layout()->addWidget(button);
QSignalSpy spy(button, &QPushButton::clicked);
grpBox->show();
QTest::mouseClick(button, Qt::MouseButton::LeftButton);
QTest::mouseClick(grpBox, Qt::MouseButton::LeftButton, Qt::KeyboardModifier::NoModifier, QPoint(250,70));
QCOMPARE(spy.count(), 2); // 1!=2
The first click is considered correctly, whereas the second one vanishes somehow. Why is that?
I'm wondering, if I really understood how to use the framework correctly, as dealing with mouse positions, seems to be too tedious and fragile for a practical test framework.
Revision:
It's obvious that using coordinates in a GUI test are very fragile. Hence, I found a solution utilizing findChild that actually does the same thing.
auto button=new QPushButton("Hello");
button->setObjectName("PushButton");
auto grpBox = new QGroupBox("Group Box");
grpBox->setLayout(new QVBoxLayout);
grpBox->layout()->addWidget(button);
QSignalSpy spy(button, &QPushButton::clicked);
grpBox->show();
QTest::mouseClick(button, Qt::MouseButton::LeftButton);
if (auto btn = grpBox->findChild<QPushButton*>("PushButton")) {
QTest::mouseClick(btn, Qt::MouseButton::LeftButton, Qt::KeyboardModifier::NoModifier);
} else {
QVERIFY(false);
}
QCOMPARE(spy.count(), 2);
This combines two advantages. Firstly, it is no longer necessary to deal with coordinates and secondly you still doesn't need to touch the code of the widgets you are going to test.
For this approach it seems to be advantageous, if every gui element has a unique objectName() supporting an easy search mechanism.
We created a small painting application in JavaFX. A new requirement arose, where we have to warn the user, that he made changes, which are not yet persisted and asking him, if the user might like to save first before closing.
Sample Snapshot:
Unfortunately there are a lot of different Nodes, and Nodes can be changed in many ways, like for example a Polygon point can move. The Node itself can be dragged. They can be rotated and many more. So before firing a zillion events for every possible change of a Node object to the canvas I`d like to ask, if anyone might have an idea on how to simplify this approach. I am curious, if there are any listeners, that I can listen to any changes of the canvas object within the scene graph of JavaFX.
Especially since I just want to know if anything has changed and not really need to know the specific change.
Moreover, I also do not want to get every single event, like a simple select, which causes a border to be shown around the selected node (like shown on the image), which does not necessary mean, that the user has to save his application before leaving.
Anyone have an idea? Or do I really need to fire Events for every single change within a Node?
I think you are approaching this problem in the wrong way. The nodes displayed on screen should just be a visual representation of an underlying model. All you really need to know is that the underlying model has changed.
If, for example, you were writing a text editor, the text displayed on the screen would be backed by some sort of model. Let's assume the model is a String. You wouldn't need to check if any of the text nodes displayed on screen had changed you would just need to compare the original string data with the current string data to determine if you need to prompt the user to save.
Benjamin's answer is probably the best one here: you should use an underlying model, and that model can easily check if relevant state has changed. At some point in the development of your application, you will come to the point where you realize this is the correct way to do things. It seems like you have reached that point.
However, if you want to delay the inevitable redesign of your application a little further (and make it a bit more painful when you do get to that point ;) ), here's another approach you might consider.
Obviously, you have some kind of Pane that is holding the objects that are being painted. The user must be creating those objects and you're adding them to the pane at some point. Just create a method that handles that addition, and registers an invalidation listener with the properties of interest when you do. The structure will look something like this:
private final ReadOnlyBooleanWrapper unsavedChanges =
new ReadOnlyBooleanWrapper(this, "unsavedChanged", false);
private final ChangeListener<Object> unsavedChangeListener =
(obs, oldValue, newValue) -> unsavedChanges.set(true);
private Pane drawingPane ;
// ...
Button saveButton = new Button("Save");
saveButton.disableProperty().bind(unsavedChanges.not());
// ...
#SafeVarArgs
private final <T extends Node> void addNodeToDrawingPane(
T node, Function<T, ObservableValue<?>>... properties) {
Stream.of(properties).forEach(
property -> property.apply(node).addListener(unsavedChangeListener));
drawingPane.getChildren().add(node);
}
Now you can do things like
Rectangle rect = new Rectangle();
addNodeToDrawingPane(rect,
Rectangle::xProperty, Rectangle::yProperty,
Rectangle::widthProperty, Rectangle::heightProperty);
and
Text text = new Text();
addNodeToDrawingPane(text,
Text::xProperty, Text::yProperty, Text::textProperty);
I.e. you just specify the properties to observe when you add the new node. You can create a remove method which removes the listener too. The amount of extra code on top of what you already have is pretty minimal, as (probably, I haven't seen your code) is the refactoring.
Again, you should really have a separate view model, etc. I wanted to post this to show that #kleopatra's first comment on the question ("Listen for invalidation of relevant state") doesn't necessarily involve a lot of work if you approach it in the right way. At first, I thought this approach was incompatible with #Tomas Mikula's mention of undo/redo functionality, but you may even be able to use this approach as a basis for that too.
I have a component I created that works like a Viewstack but the next index component slides in from one of the four sides. I've got it working well enough that it's acceptable to use, but I want to make it more efficient.
Right now I'm using a Canvas as the base component, I create a snapshot of the current view using an ImageSnapshot (new Bitmap( ImageSnapshot.captureBitmapData( this ) )), and I slide the new index on top of that image on index change.
I'm basically looking for suggestions on how to do this a better way. By taking the Image after the component loads, and after the slide happens, I've gotten the initial jaded moves down to a minimum, but we normally use this for transitioning grids so it's almost always slow on the first or first couple slides.
Here's what some of it looks like so far:
private function creationComplete(e:Event):void
{
tmpImage.source = new Bitmap( ImageSnapshot.captureBitmapData( this ) );
}
public function set selectedIndex(value:int):void
{
if(_selectedIndex == value + 1)
return;
_selectedIndex = value+1;
var obj:UIComponent;
tmpImage.height = height;
tmpImage.width = width;
tmpImage.visible = true;
tmpImage.x = 0;
//tmpImage.includeInLayout = true;
for (var i:int = 1; i < numChildren; i++)
{
obj = UIComponent(getChildAt(i));
//obj.x = width;
if(i == _selectedIndex){
obj.visible = true;
objDisplay = obj;
}
else
obj.visible = false;
}
mv1.target = tmpImage;
mv2.target = objDisplay;
switch ( direction )
{
// X/Y sliding logic
}
parEfect.play();
tmpImage.source = new Bitmap( ImageSnapshot.captureBitmapData( this ) );
}
If you're wondering, I'm using index 0 of the canvas for the image, and offset my custom selectedIndex by 1.
I'll post more of it if need be, but I want to keep the question down to a minimum and this pretty much sums it up.
Any help is greatly appreciated! I really want to get this component to perform better. Also, this has to be done using Flex 3
What are mv1 and mv2? Are they Flex Effects? If so they are notoriously slow, I recommend using TweenLite. If you absolutely need to use them set suspendBackgroundProcessing = true on them. Last but not least, make sure you do not have a layout set on them. If you do you are causing a re-layout every frame which can easily bog down animation.
You are probably getting some memory hits from all the components being created and then immediately being converted to an image. I would definitely try adding some intelligence at creation time. Try checking the memory usage and test against maximum mem load before creating the image:
http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/system/System.html
However, I would need to look at what is being created in the object. I suspect that you are loading some pretty heavy objects in each of the views. And if you are loading data from the server for each object, there will be a lag, possibly.
Set up a priority queue for creating objects within the class that is being created . . . e.g., if you have a menu system that is hidden by default, load the front-end, then load the menu drop-down only when a user clicks on it, or after all other immediately visible objects have been created. You will also have the advantage of being able to take a snapshot when all the immediately visible objects are in place, and before the hidden objects are created.
Finally, add event listeners after object creation, if you can, and remember to remove listeners asap.
Do you use Flex 3 or Flex 4?
Because if you use Flex 4, I would recommand to use Animate Filter with Shader Filter.
Shader Filters use Pixel Bender so you can build a shader in Pixel Bender that will do the transition between your 2 images.
See these 2 videos for more info :
http://tv.adobe.com/watch/codedependent/pixel-bender-shaders-and-flex-4/
http://tv.adobe.com/watch/codedependent/shader-transitions-in-flex-4
It would be helpful to see how you're creating your Move effects, mv1 and mv2. It is possible to set combinations of the *From, *To, and/or *By attributes--or various manipulations of the properties that control the tween's speed/duration--that together can cause "jitter" or "jerkiness" in the resulting animation.
of course, it's also possible that you're hitting against a performance barrier of some sort, but I suspect it's something more insidious. Simple translation ("x/y sliding") of any clip should perform relatively well, as long as the clip hasn't been rotated, skewed, or scaled; and as long as the processor isn't completely maxed out with some other operation that's going on at the same time.
In most cases, when defining a Move effect, you want to set as little information as possible, and let Flex compute the optimum values for the other things. Usually, this means setting only xTo and yTo.
Also, be sure to call end() on your tweens before you start setting up the new values (just in case any previous sequence is still running).
Finally - make sure that you're not competing with the component's layout manager during the tween. While the tween is running, you should disable the layout completely (by setting autoLayout=false on your container component)--or you can change the layout (temporarily) to an absolute layout. Either way, the tween must be allowed to move things around while it's running, and the moving of stuff must not cause the layout manager to recompute things until after it's all over. Once it's finished, you can re-enable whatever layout manager you had originally.
Maybe I should further qualify this - Is there a way to specify which direction a ComboBox will open without copying and pasting the entire ComboBox class and ripping out the code where it determines which direction it will open in...
I'm my specific case - I need it to open upwards - always.
UPDATE: You can't fix this by subclassing it because the function that handles the direction of the opening is:
private function displayDropdown(show:Boolean, trigger:Event = null):void
And that bad boy uses a fair amount of private variables which my subclass wouldn't have access to...
If you build up the Menu object yourself, you can place the menu anywhere you want by simply setting the x,y coordinates of the menu object. You'll need to calculate those coordinates, but you might be able to do this easily without subclassing ComboBox.
I am doing something similar with PopUpButton; you might find it easier to work with PopUpButton. This is based on real code from my current project:
private function initMenu(): void {
var m:Menu = new Menu();
m.dataProvider = theMenuData;
m.addEventListener(MenuEvent.ITEM_CLICK, menuClick);
m.showRoot = false;
// m.x = ... <-- probably don't need to tweak this.
// m.y = ... <-- this is really the interesting one :-)
theMenu.popUp = m;
}
<mx:PopUpButton id="theMenu" creationComplete="initMenu()" ... />
BTW, to get the PopUpButton to act more like I wanted it (always popup, no matter where the click), setting openAlways=true in the MXML works like a charm.
I doubt it - you'd need to subclass the control (which isn't that big a deal.)
Maybe you could mess with the real estate so it's placed in such a fashion (e.g. crowded into the lower right corner) that up is naturally coerced?
I would recommend checking out this post. Yes, you do have to grab the ComboBox code and modify it, but at least now you have an idea where the modifications need to go.
You could set the MaxDropDownHeight, if you set it big enough Windows will automatically set the direction upwards.
This irritated me no end. I have uploaded a solution, its a simple Class that extends the PopUpButton and removes the logic of stage bounds detection as it failed 50% of the time anyway. My code just allows you to simply specify whether you want to open the menu up or down:
http://gist.github.com/505255