Mouseevent when near an Element with Raphael - mouseevent

According to this question
Raphael - event when mouse near element
i create a invisible rectangle around another rectangle ,
when the mouse is over that large rect, a circle will appear.
but because the large rect is on top of the small rect,
i can't process another event when mouse is over the small rect.
(if the small rect is on top , the point will disappear when i reach the small rect)
And i want also to have another event with the circle.
Is there any solution for this?
Hier is the code

Kind of mimicking the events of the larger rectangle with the smaller one:
var paper = new Raphael(0, 0, 500, 500);
createRect(100, 100, 100, 50);
function createRect(x, y, width, height) {
var boundrect = paper.rect(x - 30, y - 30, width + 60, height + 60).attr({
"fill": "pink",
"stroke": "none"
}).mouseover(function(event) {
topCtrl.show()
}).mouseout(function(event) {
topCtrl.hide()
})
,
rect = paper.rect(x, y, width, height).attr({
"fill": "white",
"stroke": "red"
}).mouseover(function(event) {
topCtrl.show();
topCtrl.attr({
"fill": "white"
})
}),
topCtrl = paper.circle(x + (width / 2), y, 5).attr({
"fill": "red"
});
}

Related

Cytoscape.js layout edge length

Hi I'm trying to build a web-crawler visualization tool for a school project. I decided to use Cytoscape.js and it's been really nice to use. The problem i'm having is the edge lengths for some of the layouts (circle, breadth first, concentric) seem too large and the graph looks odd.
When I first start the application, I manually make and load a graph(it's a tree) with 100 nodes and that looks good in Circle layout:
However after I perform a web-crawl the new graph( this one has 44 nodes) doesn't fit in the view for circle:
Is there a way to get this to work so that the edges are not so long and the nodes look larger?
Edit:
Here's the code I use to change the layout:
changeLayout = function(layoutName, title, root){
var numOfNodes = cy.filter('node').length;
//extent changes when I repeatedly change the layout to circle, (don't understand this behavior)
var extent = cy.extent();
var rect = document.getElementById("cy-container").getBoundingClientRect();
var x1 = rect.left;
var x2 = rect.right;
var y1 = rect.top;
var y2 = rect.bottom;
var height = (y2 - y1);
var width = (x2 - x1);
var fact = (height < width) ? (height/numOfNodes) : (width/numOfNodes);
fact *= 5;
var myRadius = height < width ? (height-fact) : (width-fact);
switch(layoutName){
case 'circle':
myLayout = cy.makeLayout(
{ name: layoutName,
radius: myRadius,
boundingBox: {x1: x1, x2: x2, y1: y1, y2: y2},
fit: true,
avoidOverlap: false
});
break;
case 'concentric':
myLayout = cy.makeLayout(
{ name: layoutName,
height: height,
width: width,
fit: false,
avoidOverlap: true
});
break;
case 'breadthfirst':
myLayout = cy.makeLayout(
{ name: layoutName,
boundingBox: {x1: x1, x2: x2, y1: y1, y2: y2},
fit: true,
roots: root,
avoidOverlap: false
});
break;
default :
myLayout = cy.makeLayout(
{
name: layoutName
});
}
myLayout.run();
$('#graphTitle').text(title + " Layout");
};
The length of an edge is a function of the positions of the nodes. The layout sets the positions, so you have to set the layout options to make the nodes closer together.
For force-directed (physics simulation) layouts, you adjust the forces. In other layouts, you can adjust spacing values or enforce a bounding box to affect how spread out the nodes are.

How do I get the frame of visible content from SKCropNode?

It appears that, in SpriteKit, when I use a mask in a SKCropNode to hide some content, it fails to change the frame calculated by calculateAccumulatedFrame. I'm wondering if there's any way to calculate the visible frame.
A quick example:
import SpriteKit
let par = SKCropNode()
let bigShape = SKShapeNode(rect: CGRect(x: 0, y: 0, width: 100, height: 100))
bigShape.fillColor = UIColor.redColor()
bigShape.strokeColor = UIColor.clearColor()
par.addChild(bigShape)
let smallShape = SKShapeNode(rect: CGRect(x: 0, y: 0, width: 20, height: 20))
smallShape.fillColor = UIColor.greenColor()
smallShape.strokeColor = UIColor.clearColor()
par.maskNode = smallShape
par.calculateAccumulatedFrame() // returns (x=0, y=0, width=100, height=100)
I expected par.calculateAccumulatedFrame() to return (x=0, y=0, width=20, height=20) based on the crop node mask.
I thought maybe I could code the function myself as an extension that basically reimplements calculateAccumulatedFrame with support for checking for SKCropNodes and their masks, but it occurred to me that I would need to consider the alpha of that mask to determine if there's actual content that grows the frame. Sounds difficult.
Is there an easy way to calculate this?

Fabricjs line coordinates after (moved, scaled, rotated) - canvas.on('object:modified'…

I need to find the Line coordinates(x1,y1,x2,y2) after the object has been modified. (moved, scaled, rotated)
I thought to use the oCoords information and based on angle and flip information to decide which corners are the line ends, but it seems that it will not be too accurate…
Any help?
Example:
x1: 164,
y1: 295.78334045410156,
x2: 451,
y2: 162.78334045410156
x: 163, y: 161.78334045410156 - top left corner
x: 452, y: 161.78334045410156 - top right corner
x: 163, y: 296.78334045410156 - bottom left corner
x: 452, y: 296.78334045410156 - bottom right corner
When Fabric.js calculates oCoords - i.e. object's corners' coordinates - it takes into account the object's strokeWidth:
// fabric.Object.prototype
_getNonTransformedDimensions: function() {
var strokeWidth = this.strokeWidth,
w = this.width + strokeWidth,
h = this.height + strokeWidth;
return { x: w, y: h };
},
For most objects, stroke is kind of a border that outlines the outer edges, so it makes perfect sense to account for strokeWidth it when calculating corner coordinates.
In fabric.Line, though, stroke is used to draw the body of the line. There is no example in the question but I assume this is the reason behind discrepancies between the real end-point coordinates and those in oCoords.
So, if you really want to use oCoords to detect the coordinates of the end points, you'll have to adjust for strokeWidth / 2, e.g.
const realx1 = line.oCoords.tl.x + line.strokeWidth / 2
const realy1 = line.oCoords.tl.y + line.strokeWidth / 2
Keep in mind that fabric.Line's own _getNonTransformedDimensions() does adjust for strokeWidth, but only when the line's width or height equal 0:
// fabric.Line.prototype
_getNonTransformedDimensions: function() {
var dim = this.callSuper('_getNonTransformedDimensions');
if (this.strokeLineCap === 'butt') {
if (this.width === 0) {
dim.y -= this.strokeWidth;
}
if (this.height === 0) {
dim.x -= this.strokeWidth;
}
}
return dim;
},

Xcode UILabel upside down

I want to have a label which should be displayed upside down. That means after creating the label I want to turn it around 90 degrees. That works but now the label is anywhere. I don't know HOW the label is rotated. Maybe one could help me. The code is the following:
let label = CreatorClass.createLabelWithFrame(CGRect(x: 10, y: 10, width: 150, height: 15), text: "aString", size: 12.0, bold: false, textAlignment: .Left, textColor: UIColor.whiteColor(), addToView: self)
label.transform = CGAffineTransformMakeRotation(CGFloat(M_PI_2))
CreatorClass creates a label and add it to a certain view (it adds to self because this code is called in a subclass of UIView). Actually it's self-explanatory I think.
you label rotate around its center, that means:
You label rotate around : x = 10 + 75 = 85
y = 10 + 7.5 = 17.5
This is also the center of the new position, what has a width of 15.0 and height of 150;
The new rect of your view, after the transfer is:
x = 85 - 7.5 = 77.5;
y = 17.5 - 75 = -57.5;
width = 15 , height = 150.
It could be out of the self bounds.
You might want to go back your label to its init position, only need to put it to init position:
label.frame = CGRect(x: 10, y: 10, width: 15, height: 150)

How to handle the orthographic projection when auto-rotating screen?

I have this method for performing the ortho projection:
void myGL::ApplyOrtho(float maxX, float maxY) const
{
float a = 1.0f / maxX;
float b = 1.0f / maxY;
float ortho[16] = {
a, 0, 0, 0,
0, b, 0, 0,
0, 0, -1, 0,
0, 0, 0, 1};
GLint projectionUniform = glGetUniformLocation(m_simpleProgram, "Projection");
glUniformMatrix4fv(projectionUniform, 1, 0, &ortho[0]);
}
It works fine for iPad screen when I do this:
ApplyOrtho(2, 2*1024/768);
Here's my rendered image:
However, when I rotate to landscape, it looks like this:
Now my assumption is this is because the ApplyOrtho matrix is setting a fixed projection and that projection does not rotate while the image is rotating within that projection, thus getting displayed fatter.
Incidentally, this is the rotation:
void myGL::ApplyRotation(float degrees) const
{
float radians = degrees * 3.14159f / 180.0f;
float s = std::sin(radians);
float c = std::cos(radians);
float zRotation[16] = {
c, s, 0, 0,
-s, c, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1
};
GLint modelviewUniform = glGetUniformLocation(m_simpleProgram, "Modelview");
glUniformMatrix4fv(modelviewUniform, 1, 0, &zRotation[0]);
}
It is used right before drawing.
So I experimented and tried this at the same time I rotate:
ApplyOrtho(2*1024/768, 2);
However this has no effect whatsoever, even though the rotation is definitely happening at the same time. My image remains "fat".
Is my interpretation of why the fatness is happening correct?
How to handle the orthographic projection when auto-rotating screen?
UDPATE: Also tried this on iPhone using the 2/3 dimensions of the screen (not iPhone 5) and using ApplyOrtho(2,3) and ApplyOrtho(3,2) but the "fat" triangle in landscape remains.
Also: the viewport is setup just once, before the first Ortho:
glViewport(0, 0, width, height);
Where width and height are the dimensions of the Portrait screen.
The cause of the above discrepancies is that the orthographic projection is not matching the width and height ratio of the screen, thus the X and Y coordinates are not the same screen size. Making the orthographic ratio match the viewport ratio resolves this issue. As a result, when rotating, the image will remain exactly the same shape and size.