When a Client connects to my application a new QProgressbar will show and display his set name and display some more information. This works fine. But based on the length of the name it doesn't look perfect if multiple people connect. And it is getting harder to read.
What i want is two labels. One For the name which is left aligned and one on the right side for the other information with right alignment
So is there a way to display two different labels on top of the progressbar and have one aligned to the left and one to the right?
Such behaviour is not provided by standard Progress Bar, you must subclass and implement your behaviour yourself.
Related
Not sure if this is possible, but I have two CListBox controls which I need to vertically sync, but the controls may have different amount of data in them as well as each row may be of different heights. I want it such that no matter what is in each control, when I get to the top or bottom of one, I get to the same top or bottom of the other.
To do this right, I need to vertically scroll the items such that they don't necessarily align on an item boundary. Like the following example:
Left side shows the top of row one, the middle shows the top of row two. The right image shows a partial of row 1, which is what I need.
Is this possible, or am I going to have to do a major refactor requiring that I swap the controls out with something else? (definitely not preferable due to potential risk)
Oh, and before anyone asks why it was done like this, the answer is legacy.
I'm still looking into this, but if the control can't be forced to to this, might there be a workaround where I could have some sort of virtual CListBox which I could possibly BitBlt from, or would that entail more work then swapping out controls? Is there a better way?
Perhaps I could encapsulate the control in another window which would be able to have a larger view and clip that view to what I want to see?
I want to make a menu that will take an undetermined quantity of labels and spread them out horizontally so that 3 are visible on screen at once. When pressing left/right it will go to the next one, the one that is selected is always in the center of the screen horizontally with the other two on the left/right of the screen.
The problem is that I also want a smooth transition not just a replacement. They need to wrap endlessly.
Not sure where to begin, not finding examples on google.
The concept you are talking about was popularized by Apple under the name "Cover Flow".
There is a widget like that available under a permissive license here: https://code.google.com/p/pictureflow/
I take it you want something a bit simpler (only show three labels, less fancy 3D effect), but I assume this is a good starting point.
Another one is the PathView QML element:
http://qt-project.org/doc/qt-5/qml-qtquick-pathview.html#details
It is even closer to what you like to do, feature-wise. It is also available in Qt4 and there is a tutorial here: http://qt-project.org/doc/qt-4.8/declarative-modelviews-pathview.html
I'm making my own UI from scratch using OpenGL that is why I'm asking this and please don't make any discouragement as this is just a hobby project.
Currently, I'm stuck implementing how this scrollbars really work. In my current implementation, the content scrolls at the wrong step value as well as the thumb, meaning, I set the value manually like 1px step for each of them.
The structure of my scrollbar implementation is describe as follows:
I draw scrollbars i.e the main rectangle where the 3 button lies.
Those 3 buttons are, thumb, buttonBack and buttonNext.
All of them do the basic logic of scrollbars i.e when I click each one of them, they moved. But the whole part(scrollbar) don't know how to scroll contents
So what I did is: I make another object and I call it scrollarea
It has two scrollbars, vertical and horizontal scrollbar.
I made a function called scrollToX and scrollToY which
does what I named to them.
But the step values I set to them are
manually set up.
I try to google some scrollbar, scrollarea, scrollview or whatever you call to that scrollable rectangle thing, but all I see are implementation and I cannot find any guides how to build your own. I have no choice but to look at their implementation. I try my best to comprehend what they did but their implementation of how their whole UI structure is very different to mine, and I cannot find anything useful there.
So I ask again here if anybody can explain me well how to make a properly functional scrollbar.
Most specific things I'm really concerned of are:
How do I determine the thumb step value?
How do I determine the content step value?
All of these depend on your content -
Is it just an image ? If so, you only need to change the offset depending on the size of the image.
Is it a list of values like in Windows explorer ? Then you need to create a data structure first that contains all of it, and shows the content that fits within the window as it scrolls.
OpenGL does not fit into this discussion.
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.
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.