I’m a big fan of Firefox’s mini grid view in the web inspector, which provides
a small version of the currently overlaid grid, which is in proportion to the real thing.
Hovering over the different areas of the mini grid causes the equivalent area on the grid overlay to also highlight, along with a tooltip containing useful information such as the dimensions of that area, its row and column numbers, etc. [my emphasis]
It bugs me to no end, though, that the tooltip emphasised in the quote does not appear if the highlighted grid row/column is too close to the viewport’s edge. Instead of adjusting for this by moving the tooltip into view, the behaviour seems to be just to not show it at all, which rather defeats the purpose – especially when, as far as I know, this tooltip is the only way to see the calculated size of empty grid tracks.
I can’t find any bugs regarding this on Bugzilla, but then I can virtually never find anything on there, so there’s a decent chance I’m just bad at searching.
Is there some setting I can’t find that will allow me to see the tooltips even for edge rows/columns? Or if this is just a bug, has it been addressed?
I've tested this in Firefox 98.0 and could reproduce it. As this is definitely a bug in the Firefox DevTools and I couldn't find one either in Bugzilla, I now created a bug report for it.
Related
When reading the famo.us docs in desktop Chrome, I see an overshoot effect when scrolling past the top or bottom of the center container (i.e. below the header). It seems famo.us emulates the overshoot to resemble the native overshoot of iOS apps.
Is there an option (declaratively or programmatically) to disable the overshoot?
Assuming your talking about a Scrollview, you can define pretty much all of the aspects that effect how it handles input. In the options object when creating the ScrollView you can set edgePeriod = 0. In physics, the period is the time taken for one cycle of vibration. So this should make sense. More options are documented in the docs.
P.S There seem to be a few typos and glitches with the docs generated, I'll file a an issue and see about normalizing it. (egePeriod??)
I'm developing a Qt application and it's currently in an internal beta test. One member of the company has Windows configured to display text larger than its normal size, which breaks my UI. The About page, for example, currently looks like this:
but under his settings, looks like this (note the clipped text):
Coming from a C#/Winforms background, I'm amazed that I can't seem to find some easily configurable label property such as Form.AutoSize that will automatically size the labels to fit their containing text. I've tried messing with sizePolicy, scaledContents, and a few other properties, but none seem to do this.
I've come across various threads (such as this one) which give instructions for scaling the text to the label, but I want to do the opposite - scale the label to the text to facilitate for those with enlarged text settings like my co-worker. Is there a straightforward way to do this?
There are at least three solutions to this problem.
Use layouts. Their contents are scaled according to the size of the window.
Make a code which is executed whenever window size is changed. In that code, you get the width of the longest text in the window (How?)(another way) and then set window wider than that.
Do the same as in solution #2, but execute the code only when the dialog is shown. After that, alter the window properties so that its size cannot be changed.
I developed Silverlight application under 1280x1024 screen resolution Its look and feel is good in this(1280x1024) resolution.. But under 1024x768 screen resolution looks badly.
please help me in this issue.
Thanks in advance
I'm guessing you create your components inside a canvas or you simple drag and dropped then into the xaml page. If this is the case then the layout will be affected by resolution changes.
To solve this problem you should put all your components inside one (or usually more than one) stack panel and align the controls (left, right, height, width, etc...) in relation to the stack panel.
It is not difficult to do it but it may take a little bit of time and effort to get familiar with it. But I can guarantee you that the result is well worth the effort.
VERY IMPORTANT: To space the controls (and the stack panels) between thenselfs and the borders, always use the Margins properties.
Silverlight is great in this aspect. An application developed using this aproach can work very well in different resolutions.
folks!
I use a listview (Icon mode) to display items which consist of an image and a label.
As you can see in the shots the row height is variable on y depending on the label length. The problem is that I want the complete labels to be drawn, but they are automatically shrinked into two lines:
The strange thing about it is that once you select an item the whole label will be shown:
This is also the case when deselecting the item, but when another item gets selected, only that one will be shown completely.
Is there a way (without drawing the text manually) to avoid truncation in my case?
If some code is needed to answer this question, don't hesitate to ask.
Greetings,
Satara
I'm guessing this was a design choice: make things look less cluttered. E.g. picture your desktop with all labels shown completely... will look messy in my case.
However, you can fix this by drawing the label yourself. Have a look into custom draw which is a service provided by the list control. The thing is that it's usually an all or nothing approach, so this will likely require you to draw everything yourself: border, image, label, etc. The other option is to get hacky: subclass the window and draw the labels again after Windows did in response to several messages (unfortunately Windows does not restrict the painting to WM_PAINT, an optimization that is a left-over from the old days...)
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.