I was wondering how Qt does all its styling. I need to create a custom control and I'd like for it to meet the standards such that my control won't feel out of place on different platforms and styles.
For example, I'm going to need a cursor that's used in text, does Qt provide a method for drawing it? And how would I go about implementing it such that I don't redraw the entire widget for the blinking of the cursor?
What you typically do to create custom widgets is two-folded:
combine existing widgets
derive from existing widgets
That means, e.g., if you want to create a custom text input widget, use an existing one and only change the parts you need to change in overloads. Or maybe your customization does not need to change the text input part at all, but just plug it in at the right place. The widget I am talking about right now is QLineEdit. It is actually very basic and customizable.
There actually exist two methods (at least) on how to combine widgets to form your custom one. The first is to create a .ui file and use it in your custom class (or create widgets in code). The second one is to use a QGraphicsScene. There you can combine freehand painting (QPainter), with customly positioned objects and fully-fledged widgets.
If it is too hard to solve your problem by combining widgets and/or deriving from them, the last resort is always to take an existing widget with the desired functionality (e.g. QLineEdit that has a text-edit cursor) and read/copy the code (Note: license issues may arise).
To give a better answer to your question we would need more details on what exactly you want to achieve.
Related
I would like to have a collapsable Widget like seen here. The Problem with the accepted solution for me: I want to dynamically change the content of the collapse-widget (adding / removing widgets while it is collapsed or expanded). The provided solution copies the content height on creation, and is thus not responsible as I need.
I already experimented a lot with Layout-SizeConstraint and Widget-Sizehints, but did not manage to adjust the solution there to be responsive.
How can I create a collapsable widget that allows for content size changes?
You should take a look at Qt Animation Framework.
This is for Widgets, but QML also has almost identical functionality. You just define different states (like, for example: "DEFAULT", "COLLAPSED", "EXPANDED") and transition animations (with easing curves, delays and other fancy stuff). If you have more questions regarding states and animation, let me know.
I am building an editor using C++/Qt which has a click-and-drag feel to it. The behavour is similar to schematic editors (Eagle, KiCAD, etc), Microsoft Visio, or other programs where you drag objects from a toolbar into a central editing area.
My problem is that when the user clicks inside the custom widget I want to be able to select the instance of the box-like object and manipulate it. There will also be lines connecting the boxes together. However, I can't decide on an efficient method for selecting those objects.
I have two main thoughts on how to do the programming for this: The first is that the widget which is drawing the entire editor would simply encapsulate every one of the instances of the box. The other is to have each instance of the box (which is in my Model) carry with it an instance of a QWidget which would handle rendering the box (which would be in my View...but it would end up being strongly attached to the model). As for the lines connecting them, since they don't have a square bounding boxes they will have to be rendered by the containing widget.
So here is the summary of how I see this being done:
The editor widget turns into a container which holds the widgets and the widgets process their own click events. The potential issues here are that I don't know how to make the custom widget turn into a layout which lets click-and-drag functionality.
The editor widget takes care of all the rendering and processes the mouse clicks (the easier way in that I don't have to worry about layout...its just selecting the instances efficiently that I don't know what would be best).
So, now that there is a bit of background, for the 2nd method I plan on having each box-like instance having a bounding rectangle and the lines being represented by 3-4 pixel wide bounding rectangle segments (they are at 90 degree angles). I could iterate through every single box and line, but that seems really inefficient.
The big question: Is there some sort of data structure I can hold rectangles in and link them to widgets (or anything else for that matter) and then give it two coordinates (such as mouse coordinates) and have it spit me out the bounding box or linked object that those coordinates are inside of?
It sounds like your real question is about finding a good way to implement your editor, not the specifics of rectangle intersection performance.
You may be interested in Qt's "Diagram Scene" example project, which demonstrates the QGraphicsScene API. It sounds like a good fit for the scenario you describe. (The full source for the example ships with Qt.)
The best part is that you still don't have to implement hit testing yourself, because the API already provides what you are looking for (e.g., QGraphicsScene::itemAt()).
It's worth noting that internally, QGraphicsScene uses a simple iterative method to perform hit tests. As others have pointed out, this isn't going to be a serious bottleneck unless your scenes have a lot of individual items.
I want to create a slider which contain a different slider handle and i want to paint it according to slider handle position in the slider.
You could use QProxyStyle to ovrride drawComplexControl method - you will have to draw entire control on your own, as there is no separate flags in QStyle::ControlElement for parts of QSlider.
maybe you should look at this: http://doc.qt.io/qt-4.8/stylesheet-examples.html#customizing-qslider
If I understand you correctly, you want a slider that changes not only its position but also its appearance as you slide, right? For example, a mix of QDial and QSlider, ie. a slider with a turning knob.
If so, you will need to subclass either QSlider or QAbstractSlider (or QDial) and do the painting in your own paintEvent(). Note, however, that you will loose all style-awareness unless you care about that yourself (and that is an interesting topic in itself, see http://doc.qt.io/qt-4.8/style-reference.html for more info).
The Qt demos and examples, or the QSlider/QDial source code itself may serve as examples on how to overload a paintEvent().
I'm having all sorts of size problems with Qt. I am creating my own widgets and using different layouts (generally, I need my own to make them work properly without spending hours on the "powerful" default layouts... which don't lay things out as intended.)
Once I'm done with a widget and its layout though, it doesn't work right. The size is never getting set properly unless I call widget->resize(1, 1); which finally forces a "resize" and makes the widget look correct (i.e. recompute the geometry.) Even the updateGeometry() call has no effect.
This is a dreadful problem when the resize() needs to be called on the parent widget (yuck!) and from what I'm reading should not be necessary were the layouts properly programmed.
Is there a sample that works and is not several thousand of lines long, or does Qt require several thousand lines to make anything work perfectly, even the simplest widget?
What are the minimal functions to be called to make a widget & its layout work at once?
Thank you.
Alexis
P.S. I tried to implement the sizeHint(), minimumSize(), maximumSize(), others that I'm missing? I was hoping that would be enough. Obviously, I also implement the setGeometry() on the layout to resize the children appropriately.
--- addition 1
There is a sample image with a layout that clearly isn't available as is in Qt. The positioning, functions, and colors of the different keys is XML driven and works for any keyboard in the world.
(note, this sample doesn't show the Enter key displayed on two rows and wider below than at the top; more or less, not doable at all with the regular layouts; of course, it works with my version.)
--- clarification
I'm not too sure how to describe the problem better. I was thinking to write a test widget next to see how I can reproduce the problem and then post that and eventually fix it. 8-)
The default layout function that the internal Qt layouts make use of require a lot of coding. I would like to avoid having to copy/paste all of that because for maintenance, it makes it close to impossible.
--- today's findings
As I needed to tweak one of the widgets, I decided to add a VBoxLayout and make it work.
I actually found the problem... One of the widgets in my tree is a QScrollArea and that sizeHint() returns (-1, -1). Not exactly what I'd expect but... whatever you put inside that widget has better know how to compute its width and height or else... it fails.
Looking at the code closely, I could actually compute the width by using the widest width found. Once I used that, the widget would appear (and it actually resizes itself as things change in the list, kinda cool.)
This being said, my earlier comment about having a tree of widgets that auto-resize themselves stands. From the root up to the parents of the leaves in your tree, all of those widgets will need a valid layout. Once I added one in the top widget it resized itself and its children properly (well... in my case up to the QScrollArea, the rest required a bottom to top resizing. Funny how that works!)
--- ah! ha! moment (or: what you find reading the implementation code!)
Today I bumped in another problem which just needed the correct call... I just couldn't find anything worth it in the documentation.
All the objects have a layout now, but a certain parent would not resize properly. Plain simple.
I had a call to the parent as following:
// changes to the children are changing the geometry
parentWidget()->updateGeometry();
Yeah. The docs says that's what you have to do. Nothing happens at all with that call. No idea what it's supposed to do, I did not look at that function. It never did anything for me anyway.
So... I looked at the layout to try to understand how it would send the info up/down. I did not see much except for one interesting comment:
// will trigger resize
This is said of the SetFixedSize mode. To reach that function you need to make the layout for update. Ah! Yes... the layout, not the parent widget... let's try that instead:
parentWidget()->layout()->update();
And voila! It resizes correctly in all cases I have. Quite incredible that the widget updateGeometry() doesn't trigger the same effect...
Although it's possible to do what you want it sounds like the problems you are having are because you're using Qt in a way that it's not meant to be used. Why do you need separate widgets for each key represented on the keyboard?
I see two options, both of which are better in some way:
Use QGraphicsScene and QGraphicsView.
A single custom widget that uses custom drawing to display the keyboard (and likely uses hover for hints).
The first option is probably better. Your keys could then be represented by QGraphicsSimpleTextItem's or even a QGraphicsSvgItem. It also provides a number of standard layouts or you could choose to write your own layout. By default you can use the keyPressEvent or mouseReleaseEvent to respond to user interactions.
I'd highly recommend you take a look at the QGraphicsView examples to get an idea what you can do.
If you go the second route you'll need to record the different key locations so you can respond accordingly as the user moves the mouse around, clicks, etc.
This won't help you with your immediate issue but I wanted to show you a keyboard I made using standard layouts and buttons. It's not perfect and it still won't help you with an enter key that spans two rows but it's not bad. It's resizable too by resizing the window, although I'm not sure if that will be apparent from the images below as SO may be scaling them. (you can view the actual images by opening them in their own tab)
Anyway, this was done using only Qt Designer with no manual coding. It consists of a top level vertical layout with 5 horizontal layouts in it. The buttons are then inserted into one of the 5 horizontal layouts. The size of the keys can be controlled by setting the horizontal and vertical size policies to "ignored" for most of the buttons and then horizontal "minimum" for buttons that you want to be wider. Things can be tweaked by setting min and max size restrictions to buttons. When resized, the buttons will not maintain their relative proportions though, that would probably take some custom programming.
The styling in your example could be approximated pretty well using css style sheets and background images. Still not a minor effort but you should be able to get most of the way there without custom layouts and buttons.
I am looking for the best way to dynamically swap in and out controls within Qt on a predefined layout created from the Qt Designer.
I come from a ASP.NET background, where often I would use the idea of a "placeholder" for this type of task and add controls as children at runtime.
Does Qt support this type of functionality or something similar?
You can just add a layout control to any widget and later on dynamically add controls to the layout:
for(int i = 0; i < 10; i++)
{
QLabel *plbl = new QLabel(myform);
plbl->setText(QLabel::tr(L"My dynamic text box"));
mylayout->addWidget(plbl);
}
Edit: There are different Layout classes that support different "fill" styles (e.g. horizontal next to each other, grid layout, vertical layout, etc.). You won't need any placeholders or similar - just a widget (or layout) as parent to fill.
If your Qt Layout already uses layouts, then best idea would be to leave some place for runtime controls in layout tree, or perhaps even a empty layout just for those. Layouts have ability to dynamicaly add or remove widgets and sub-layouts, so that solves the problem. If you want to insert new widgets immediatley after removing old ones interface might flicker as qt will try to reuse temporarly freed space. It might slow application down if there are any slow rendering widgets.
Another soultion would be to insert empty widget - that is more similar to ASP.NET approach. It is a bit more crude method, but might be a good way to avoid flickering of interface. It would prevent layout from reusing space even if you don't display any widget and leave unused space - it might suggest to a user, that after some interaction something might appear here - if it's desired behavior i would suggest this way.
If you have several sets of controls apperaing always in the same groups you might consider using QStackedWidget, that allows you to create those widgets already at design stage and swich between groups at runtime.