I'm using jqPlot to render a graph with zooming enabled.
For example:
http://www.jqplot.com/tests/zooming.php
In the example above, when you make a selection on the graph, the graph canvas is painted in grey (apart from the selection). Does anyone know how to customise this colour?
I've been unable to find which jqPlot CSS option to tweak in jquery.jqplot.css.
I am afraid that no css is involved in this particular process of painting. Though there is one class which can point you in the right direction. My suspect is the jqplot-zoom-canvas class. Though I think that the painting is defaulted to grey.
Thus, I see only two options:
Changing the painting directly in the jqplot script.
Or on painting of zoom selection start change the colour of the jqplot-zoom-canvas then change it back to default on painting zoom stop. But I do not know if there are hooks for these sort of events. Therefore, you might actually be left with only the option no. 1.
Related
I have made a small example showing the problem: http://bl.ocks.org/nvcleemp/df035fc9c14f9955d4f0
When you click any of the two links, then you see a small animation which changes the background colour. This animation always starts from black, while I want it to start at the current colour. This is just a small example, in the real problem there are many more links that have to change colour, and I don't 'know' which is the correct starting colour. (I can always look it up, but I cannot hard-code it into the function)
The safest way to have a transition start from a well-known state is to set that state yourself. In your case, set the background colour at the beginning:
d3.select("#test1").style("background", notSelectedColor);
d3.select("#test2").style("background", notSelectedColor);
Complete demo here.
I am learning d3js and trying to incorporate zooming/panning features on a graph, however on the initial zoom event it jumps to a random spot and zooms in. After that, the zooming and panning work as expected. Why is the initial event moving the starting point and adjusting the scale oddly?
Code and example here: bl.ocks.org/dbaileychess/7570631
This is because the zoom behaviour is attached to a different element than the one you're zooming. It determines the position of the mouse cursor relative to its own position and passes that information to the callback. If you're zooming a different element, the relative coordinates are no longer correct.
To fix, add the offset between the elements that the zoom behaviour is attached to and the elements you're zooming to the translation. This question has come up a number of times already, see e.g. here.
Is there a way (API) of getting the size (vertical and horizontal) in pixels of the resize corners?
I am referring to the area at each of the corners of a window where you can resize the window in both directions (Left-to-Right and Top-to-Bottom) at the same time using your mouse. You will know you are there with your mouse cursor when you hover over the corners of the window and the mouse cursor is a Diagonal Resizing cursor.
Thank you
Edit:
An example: Hover your mouse over the right edge of a sizable window. Start in the middle (vertically) of the window and move the mouse up along the edge until the horizontal sizing cursor changes to a diagonal sizing cursor. How do I determine by asking the OS how far that position when the cursor changes, is from the top of the window.
I would suggest to use the size of the scrollbars. Call GetSystemMetrics with SM_CYHSCROLL and SM_CXVSCROLL. May be also SM_CYSIZEFRAME and SM_CXSIZEFRAME sizes can be combined.
But I think a better value is to use the height of the status bar. However even Microsoft Windows seems to use some fixed value as can seen on the screenshot.
Comparing the results of GetClientRect and GetWindowRect will tell you how wide the non-client (border) area is along each edge of the window.
If you're concerned that it might not all be active for sizing (true especially along the top), or you want to distinguish the diagonal sizing areas from edge sizing areas, you can take the coordinates discovered in step 1 and pass them to SendMessage(WM_NCHITTEST) See its documentation for the various return codes. There's no problem sending this message repeatedly -- it's designed to be called for each mouse move event and therefore is very fast.
I'm trying to apply readable labels to a D3 Streamgraph that is rendered using completely dynamic data - various different datasets that are evolving over time from live data and the controls offered to manipulate what is shown too. All this works well - the problem is how to clearly label the streams - short of using a legend.
The great variation of hues and luminance needed makes choosing readable styling for labels that float over the graph extremely tricky, particularly with the limited SVG styling available cross platform and that the labels will inevitably overlap on the background sometimes too. For instance black coloured labels 'work' but it's hard to read sometimes over the top of darker colours (which we really need to ensure a good range)...
Anyone done anything similar/addressed same challenge? I'm currently pondering using a legend instead.
A couple of ideas may help:
Add a background rectangle around the text with opacity set to 0.7 (the color being the same as the data series). This helps make the text pop. For the border of the rectangle, use d3js rgb.darker or rbg.brighter.
var pathStroke = d3.rgb( item.color ).darker(1.4).toString()
For preventing overlapping labels, I can think of two solutions - both hard. Use d3js Force Layout or write your own layout code. We ended up writing our own layout code for tooltips in d3-traits. See tooltips.js and layout.js.
d3.trait.layout.verticalAnchorLeftRight( foci, self.chartRect())
layout.js does have some general purpose and very flexible layout routines. It will layout rectangles within a bounding box avoiding overlap and determines if the labels need to be left or right justified. If the origins of the rects are toward the right edge of the bounding box, they are right justified.
I am trying to calculate the correct mouse coordinates, in user coordinate space, in an SVG document from within Javascript code when scrollbars come into existence when that SVG file is viewed from within FireFox. But it is not quite correct. This is needed to get SVG-based tooltips drawn correctly even when the SVG is scrolled horizontally or vertically.
I desire to have the coordinate transformations be correct across IE and Firefox browsers. Also, I want to do this with a single-source Javascript+SVG solution that hopefully does not require browser-specific conditional code. I am currently using FireFox 3.5.10, but I would consider upgrading to a more recent version of FireFox, and I have not tested IE yet.
The problem I ran into is the coordinate offsets for the scrollbars: The mouse coordinate transformation is not sufficient when scrollbars come into existence over the SVG element inside Firefox. As a debugging aid to figure out the coordinate transformations, I am working with a simple SVG file that contains Javascript handlers, all in one file, that simply draws crosshairs at the mouse cursor as SVG line objects. Find it posted at svg_cross_hairs.svg. If you load that file into FireFox and shorten the FireFox window down until scrollbars appear, and then scroll either the vertical or horizontal scrollbars, you will find that the crosshairs drawn by the Javascript are offset by the amount of either horizontal or vertical scrolling amount, which is not correct in order to draw a tooltip object on or near where the mouse cursor actually is.
I do see the Firefox: Get mouse coordinates of top-left corner of viewport question that talks about the scrollTop property.
msg#00056 clarifies that there is confusion of the meanings of element.{pageX,pageY,clientX,clientY} attributes and the element.getscreenCTM method.
Is there a cleaner way to arrive at the correct mouse coordinate, in the in user coordinate system?
You can use evt.pageX / evt.pageY or window.pageXOffset / window.pageYOffset to arrive at something that works even if the svg is scrolled.