I'm trying to draw some block diagrams in inkscape using predefined paths that I adjust in length/height, but my paths are moving as soon as I adjust them using the "select and transform"-tool (F1).
Here is an example:
I snap my path to the correct position
I then adjust its size by dragging the bottem-left corner of the selection
My path has changed its position
I'm not sure why exactly this is happening, so I'd like to know how to keep it in place when changing its size.
First, enable Geometric bounding box in Preferences -> Tools -> Bounding box to use.
This ensures that the bounding box of a selection ends at the nodes and not at the visual limits of the selection (which includes half trace width, arrows, etc.). This way, when you scale your selection dragging from one side, nodes on the other side of the bounding box stay where they are.
Check here for documentation on transformations.
You should also uncheck the tool control icons for scaling line width and rounded corners (also explained in the link above), so that when you scale a selection, line widths remain fixed.
Related
I am new to C++,Qt and Visual Studio and this is my first post on Stack Overflow.
I apologize in advance if this is a repeated question, I tried searching for a similar question but couldn't find one. Let me know if this is a repeated question and I will delete it.
I am trying to create a line plot using QWidget::paintEvent(). The line plot I am drawing is actually a QPainterPath. I want to detect when the mouse hovers over my line plot and so I create a small rectangle where my mouse cursor is and detect when this rectangle intersects with my line plot using bool QPainterPath::intersects() function. The problem is that this function returns true even when my mouse is not exactly over my line plot. In the Image 1 (I am not allowed to embed images yet) my line plot is the thick black curve and the bool QPainterPath::intersects() returns true even when my cursor is over the yellow region. As per the Qt document this is because:
There is an intersection if any of the lines making up the rectangle crosses a part of the path or if any part of the rectangle overlaps with any area enclosed by the path.
There is no way to have a QPainterPath without any enclosed area as Qt only provides two types of fill for QPainterPath: Qt::OddEvenFill or Qt::WindingFill. (To be honest, I find this kind of annoying, since an open path is a series of line segments connected end-to-end, if someone wants to enclose an area they can easily connect the first and last point using either QPainterPath::lineTo() or QPainterPath::moveTo() functions)
Anyway, I decided to get smarter than Qt and drew two extra QPainterPath with pathUp being a few pixels above my line plot and pathDn being a few pixels below my line plot. Image 2 shows these 3 line plots, red one is pathUp, black one is real line plot and green one is pathDn. I thought I coould detect the intersection in the QWidget::mouseMoveEvent() by using the following code:
// cRect: Rectangle at mouse cursor position
if((pathUp.intersects(cRect) && (!pathDn.intersects(cRect))) || ((!pathUp.intersects(cRect)) && pathDn.intersects(cRect)))
{
qDebug() << "Intersects";
}
But this still produces wrong results because now the enclosed area is different, as you can see in Image 3 the green area is an enclosed area of pathDn and red area is the enclosed area of pathUp. The thick black curve is again the line plot that I want to detect my mouse hover on. This enclosed area is not affected by Qt::setFillRule of QPainterPath.
What's even more frustrating is that I tried this technique using QPolygonF instead of QPainterPath on QWidget and the results were exactly the same. I also tried QGraphicsView, there I used QGraphicsPathItem to create my line plot and then used QGraphicsScene::focusItemChanged() signal to detect when I click on my line plot. It again produced the same result of detecting the click when my cursor is over the enclosed area. I do not want to create a custom QGraphicsItem (unless I absolutely have to) just to reimplement it's hoverEnterEvent() and hoverLeaveEvent() method because of the limitations imposed on the boundingRect() of the QGraphicsItem as explained in Qt Docs:
QGraphicsScene expects all items boundingRect() and shape() to remain unchanged unless it is notified. If you want to change an item's geometry in any way, you must first call prepareGeometryChange() to allow QGraphicsScene to update its bookkeeping.
Since I making a plot in real-time the boundingRect() will change quite frequently (> 20 Hz), which will result in an extra computational burden on the software. Is there any way I can solve my problem without creating a custom QGraphicsItem?
P.S. I have been using Stack Overflow for many years whenever I got stuck. I just never made an account here because I never needed to post anything. You guys are the best and I am very happy to be a part of this community!
I have to segment a few things in a dataset I have (.nrrd-file) by drawing a rectangle around the area of interest and saving the segments (also as .nrrd-files).
I tried everything in the Segmentation-Tool that comes with MITK but I cannot seem to find a way to draw rectangles. I also tried to do some key combos (like holding shift, ctrl or alt) while drawing but in vain.
I know I can use the Measurement-Tool to select rectangles and save them (as .pf-files), but using that I'd have to write a some code to convert those selected rectangles into rectangle segmentations later on.
Does anyone know whether there's a possibility (that I didnt find yet) to draw rectangles in the Segmentation tool, or some other way so there's no need to write a workaround?
You can use the Image Cropper plugin in MITK 2016.11 for rectangular image masking and cropping (scissors icon).
Open the plugin, select your image in the Data Manager and click on the New button in the plugin to create a bounding object. You can modify the rectangular bounding shape in the render windows by dragging its red handles. You can move the whole shape by hovering over the bounding shape (it will turn green), click, and than drag.
Click on the Mask button if you want to get an image with the same dimensions in which all pixels outside the bounding shape are set to a user defined value (see the Advanced settings in the plugin). Click on the Crop button otherwise.
Note that you can always press F1 in any active MITK plugin to open a help page with detailed instructions.
My software is based on just a frame dividen into two panels
For example, if I click the button "let's draw", the first panel on the left should becone a toolbox (with colour palette, brush and so on), the second panel should become a paint like panel
If I click the button "let's sing", on the left should appear four button, on the right the song to sing
What's the best tecnique to obtain that result?
I render the four panel (two for drawing, two for singing). The two I use are in position 0,0; the other are in position -1000,0
I create some function changeLeftPanelIntoDrawing(), changeRightPanelIntoDrawing(), changeLeftPanelIntoSinging(), changeRightPanelIntoSinging(), then I call them on click
Other hint?
In wxWidgets 3.0 you have wxSimplebook which allows you to just add different pages (i.e. arbitrary windows) to it and switch between them. If you're using an earlier version you can still just drop the contents of wx/simplebook.h into your project and use it, it's a very simple class and you can read its code in 30 seconds to see how it is implemented.
I'm using a CListCtrl with my own "DrawItem" to draw some custom graphics into the first column, in front of the text. The text is moved ~20 pixels to the right for this. That part works.
If the user double-clicks the column divider in the header, Windows calculates the best column width. But of course Windows doesn't know my custom drawing. So the result is ~20 pixels too small for the first column.
How can I correct that?
Found a workaround:
I can trick MFC into thinking that the list control uses checkboxes:
pMyList->SetExtendedStyle(pMyList->GetExtendedStyle() | LVS_EX_CHECKBOXES);
The user will never ever see the system's checkboxes (because of my custom drawing), but this gives me just the space that I need.
In Visual Studio you need to set the extended window style to get a reading-order of right to left (WS_EX_LAYOUTRTL). Why is this required since if I'm using UNICODE and displaying Arabic characters the only possible way to display it is right-to-left? I'm surprised the system doesn't simply render it the correct way around. To note: this is on a Windows Mobile system where I've copied the Arial Unicode MS font onto it, which perhaps might explain why it can't cope.
Windows' support for RTL is more complex than just the text: WS_EX_LAYOUTRTL is actually about controling the layout of other elements in the window - from MSDN:
The window layout applies to text but also affects the other GDI elements of the window, including bitmaps, icons, the location of the origin, buttons, cascading tree controls, and whether the horizontal coordinate increases as you go left or right. For example, after an application has set RTL layout, the origin is positioned at the right edge of the window or device, and the number representing the horizontal coordinate increases as you move left.
So if you create a dialog that has this, the dialog will be "flipped" automatically (because the coordinates are reversed). If a scrollbar is present, it will be on the left side of the window, not the right. Treeviews will have the expand/collapse box and connecting lines on the right side, not the left - and so on.
In the case of a static, which doesn't contain other windows, the style may not appear to make much difference - but it likely will flip the justification: a static that is right-justified using SS_RIGHT would likely end up actually left-justified when WS_EX_LAYOUTRTL is used.
Also, as the other answer notes, not all text is spans of a single language. It's possible to have a single string that mixes scripts: you can have L-to-R spans within R-to-L, and vice versa, so having Windows "do the right thing" based on the text used would be very fragile.
Also consider the case of a treeview that displays the filenames running on an Arabic system: the treeview should keep a right-to-left layout (aligned against the right side) even if the user just happens to be browsing a directory or file system that happens to have english filenames.
Long story short: WS_EX_LAYOUTRTL is really about overall window layout, not specifically text direction itself. Even without this flag, you should still get Arabic/Hebrew rendered correctly as R-to-L if using the standard APIs/controls.
Presumably because it can't be determined what you're going to display at the window level - you could be displaying nothing, a language read left to right or a language read right to left. Thus you need to set it explicitly rather than having it attempt to deduce based off incomplete information.