Actually, how can I extract size of gui elements in general in PyQt?
So far I have only found sizeHint mentioning anything regarding sizes in PyQt.
Could anyone please explain how sizes works in PyQt?
In general, it's not possible to guarantee the exact sizes of widgets, because there are so many different factors that come in to play. Widgets will rendered differently depending on the window manager in use, the current GUI style, the fonts, etc - and each platform has it's own peculiarities.
To get a better understanding of all this, I would suggest you take a look at Qt's own overviews of window geometry, widgets and layouts and layout management.
To answer the specific question on the height of QListWidgetItems: they will have whatever height is calculated by the QListWidget when it lays out its items. This may take into account the items' sizeHint, which can be set programmatically with QListWidgetItem.setSizeHint.
Related
I have 19451 points exported by coordinates in a JSON file. I am trying to render them in an efficient way on the map with circles. How can I achieve this? It is the first time I am using https://github.com/react-native-maps/react-native-maps with expo, so I am not that experienced in using maps services. I don't even know where to start from. I was thinking of something like rendering the points dynamically, based on whether one point is to be found in the region of the map that is currently shown on the screen, although I have no idea how to actually achieve this. The first thing I tried was to obviously render them at once: it takes ages and it is very buggy!
You have several options:
Use some kind of clustering when there are multiple circles in the same area, for example when you're zoomed out. Have a look at react-native-maps-clustering. Performance wise is decent enough but it may lag on older devices.
When you go over a zoom level you can limit the number of circles you draw, I guess they overlap anyways. When your limit has been reached, you can display some warning to let the user know that the number of circles was limited and he should zoom in. From my experience, drawing max 50 custom markers was the upper limit to avoid lag on older devices. With circles, that limit might be different.
Manually filter your data and decide whether the circle belongs to the current viewport (visible part of the map) or not.
Some code would help me to give you some more hints.
Good morning!
I'm currently trying to create a view similar to this mockup.
I have put down 3 different screen sizes so you can see the issue.
I have a header background image (grey box) with an angled bottom. On the right I want to display an image, which obviously needs to be positioned.
Positioning it horizontally is no issue but how can I position the image vertically? I have it positioned fixed for one screen size but obviously need to make it flexible.
Any ideas? Help would be much appreciated!
David
You can definitely use measure as #rajesh pointed out, or you can use Dimensions. As far as getting the layout consistent across devices, using position absolute and measuring the device height should allow you to get consistency across these devices.
Check out this example I set up, it should be a good starting point at least.
https://rnplay.org/apps/pSzCKg
I have searched for quite a while to find the answer.
Unfortunately, there is not even single one answer can be found on the Internet.
I only have one ApplicationBarMenuItem inside the ApplicationBar which is "About". And after I saw the effect of the "opened" ApplicationBar, I think it is too "fat" (the height of the item is too much, or maybe the line spacing/margin-top and margin-bottom/padding-top and padding-bottom etc...I'm trying to create an image for you, because I don't know how to get a screen shot for that, but anyway I'm sure you know what I mean :))
So here again is the question, is it possible to change the height of ApplicationBarMenuItem in Windows Phone 8?
Many thanks.
No, you can't change the AppBar menu item height.
But... i think this is the way the appbar looks in any system application you can take a look at, and the user isn't going to be dissapointed by the size, is just the expected size. Only my two cents, but i don't think you need to worry about that.
I have a tvtk SceneEditor for a mayavi scene in my traitsui application. When defining this editor, I asked it to have size 500x500.
Because of the mayavi toolbar, the scene editor itself understands that it has a smaller size than this under normal circumstances:
>>> self.scene.scene_editor.get_size()
wx.Size(500, 468)
And when the window is enlarged so that the editor takes up much more space, it understands this too
>>> self.scene.scene_editor.get_size()
wx.Size(500, 781)
However, if the editor is made much smaller, it refuses to take up less space (even if the contents could easily be rescaled) because the editor was specified to take up 500x500. It allows the editor to be resized, but just cuts off part of the display until it is enlarged again.
I want to know if there is a way to a) ask how much of the editor is currently displayed on the screen (instead of the minimum size the editor is willing to display) and b) make the editor default to 500x500 but be willing to ask its contents to rescale themselves if it is made smaller.
I am using the wxpython backend.
edit: It is also important that the scene is contained within a layout='split' Group -- after exploring this question and running into the enormous number of sizers that wx generates when adding traitsui widgets, I realized this might matter as well.
After hacking around for a few days, I have an answer to part a) (though it is hacky and not necessarily general purpose and it might be specific to the layout='split' layout).
self.scene.scene_editor.control.Parent.Parent.Size describes the size of the viewport in which the editor is being displayed, at least with layout='split' but I can easily imagine that it would be different for other layout types (which I didn't test).
Armed with this information, I managed to write a wrapper that resizes the editor to be at least this small before making snapshots.
More gory details:
The sizer associated with self.scene.scene_editor.control isn't the right one, probably because that sizer refers to the window containing the editor, whereas the sizer associated with the size of window within the containing splitter widget is allowed to "cover" that window and ignore its size.
I found out that the process of adding traitsui widgets defines so many boxes (assuming a nontrivial number of widgets) that there result is this enormous glut of wx Windows with their associated wx Sizers that all depend on their child widgets to determine the current size, so it is extremely difficult to control things like this. This is probably why enaml exists; so that these constraints can be explicitly specified by the user. Maybe someday I will convert my program to use enaml, but that seems like a lot of effort for something that currently works pretty well.
I still don't have an answer to part b), so I am leaving this question open. It would be nice if there were a way to specify at construction to the mess of wx sizers that resizing this window below its initial size is allowed, but there probably isn't one.
I am designing a simple music app where the user gets to play instruments i.e. Drums, and the problem that I am facing is with resolutions.
The drums are images, which I have converted them into buttons. Everything looks great at the state that I have designed it.
However, when I switch to other resolution states, the button(image) are distorted, e.g. skewed, scaled, and looks nasty.
I have tried designing or arranging them via selecting 'Enable state Recording', but the specific designs for that state are not being saved.
Have you tried the approaches discussed here? http://msdn.microsoft.com/en-us/library/windows/apps/hh465362.aspx For the actual button sizes, make sure you are not fixing the width/height with pixel values. Use * weighted rows and columns to layout your grids and have the buttons autosize to fill a given cell in the grid. Then match with the appropriate image resource per the article.
Grids are great for dividing up available space but they can't account for changes in aspect ratios. If your items are still set to Stretch (or Fill) then they can end up out of aspect ratio. Another option is to design the entire layout at a fixed size (let's say 1024 x 768 or 1366 x 768) and wrap the entire thing in a ViewBox. ViewBox will scale all elements equally and maintain the aspect ratio, adding letterboxing (or empty space) on the sides / top & bottom if necessary. This might be a better approach for a drum kit.
Hope that helps.
Redid the whole project of designing again.
This time, I put the image inside a specific grid and that made things lot better. :)