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.
Related
Old-school computer graphics sometimes produced animations (cycles and fades) without actually redrawing anything to video memory, purely by updating the color palette.
Is it possible to do this in an animated gif? That is, optimise (reduce file-size of) the gif by only providing a single frame of (significant) raster content, but have each (delayed) animation frame update colour values in the (global) palette?
The short answer is no.
According to the existing standard, every GIF frame containing a local palette must have its own data to be displayed using that palette, otherwise the local palette is of no use.
One of the possible solutions is to define your own GIF Application Extension block (like Netscape did; see the link) to store additional palettes and their time delays. Apparently, those extension blocks should appear after frames whose data they affect.
The downside of this approach is that no one except your decoder would support palette cycling unless your block type somehow makes its way to become a new de-facto standard.
Nevertheless, your handcrafted GIFs would remain valid for all other GIF decoders (even though without any palette cycling), as the standard requires them to silently ignore any GIF Application Extensions with IDs unknown to them.
Now I could be wrong about this but after testing it all day, I have discovered...
When adding a widget and setting the z-index, the value "0" seems to be the magic depth.
If a widget's Z is at 0, it will be drawn on top of everything that's not at 0, Z wise.
It doesn't matter if a widget has a z-index of 99, -999, 10, -2 or what ever... It will not appear on top of a widget who's z-index is set to 0.
It gets more strange though...
Any index less than -2 or greater than 2 seems to create an "index out of range" error. Funny thing is...when I was working with a background and sprite widget, the background's Z was set to 999 and no errors. When I added another sprite widget, that's when the -2 to 2 z-index limitation appeared.
Yeah I know...sounds whacked!
My question is, am I right about "0" being the magic Z value?
If so, creating a simple 23D effect like making a sprite move being a big rock will take some unwanted code.
Since you can only set Z when adding,a widget, one must remove and immediately add back, with the new Z value...a widget.
You'll have to do this with the moving sprite and the overlapping object in question. Hell, I already have that code practically written but I want to find out from Kivy pros, is there a way to set z-index without removing and adding a widget.
If not, I'll have to settle for the painful way.
My version of Kivy is 1.9.0
What do you mean by z-order? Drawing order is determined entirely by order of widgets being added to the parent, and the index argument to add_widget is just a list index at which the widget will be inserted. The correct way to change drawing order amongs widgets is to remove and add them (actually you can mess with the canvases manually but this is the same thing just lower level, and not a better idea).
I found a working solution using basic logic based on the fact widgets have to be removed and added again in order to control depth/draw order.
I knew the Main Character widget had to be removed along with the object in question...so I created a Main Character Parent widget, which defines and control the Main Character, apart from its Graphic widget.
My test involves the Main Character walking in front of a large rock, then behind it...creating a 23D effect.
I simply used the "y-" theory along with widget attach and detach code to create the desired effect.
The only thing that caught me off guard was the fact my Graphic widget for my Actor was loading textures. That was a big no no because the fps died.
Simple fix, moved the texture loading to the Main Character Parent widget and the loading is done once for all-time.
PS, if anyone knows how to hide the scrollbars and wish to share that knowledge, it'll be much appreciated. I haven't looked for an API solution for it yet but I will soon.
Right now I'm just trying to make sure I can do the basic operations necessary for creating a commercial 23D game (handhelds).
I'm a graphic artist and web developer so coming up with lovely visuals won't be an issue. I'm more concerned with what'll be "under the hood" so to say. Hopefully enough, lol.
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. :)
I read here:
http://wiki.wxpython.org/Getting%20Started#Windows_or_Frames.3F
that there are advantages to arranging content within a frame using Sizers instead of panels; sizers are more flexible. However many of the matplotlib examples with wxpython use panels anyway. Typically they difine a panel for the plot. I have designed a GUI using Sizers, and wish to put my matplotlib canvas into one of the Sizers without the apparent restrictions of a panel. Does anyone know how this is done, or where I can find a very simple example?
Many thanks, Andrew.
I am not familiar with matplotlib but I happened to come across this previous SO question about embedding matplotlib canvases.
From what I can tell the canvas is actually inside a sizer but that sizer is then wrapped inside a panel. The advantage of this is that you encapsulate all the relevant variables and keep them together. I.e. the canvas and all the relevant variables are kept as a single item that can be called. This is good if you plan to have multiple canvases or if your canvas will be only one part of a more complex GUI.
That said, I see no reason you NEED to put it panel. If your application is very simple (i.e. it will consist of JUST the canvas and nothing else) you could place it in you frame's sizer (see that previous question's answer and change wx.Panel to wx.Frame).
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.