I am trying to make a QTreeView automatically resize to its contents. This is my setup: I am trying to create a "smart" tool tip which is a QWidget with Qt.Tool | Qt.FramelessWindowHint as its WindowFlags, which works nicely. It contains a layout with some buttons (the size of which is constant) and the QTreeView. Now, whenever lines are added to the QTreeView's model, the QTreeView should automatically increase its size to avoid vertical scroll bars.
Setting QSizePolicy.Expanding on both the tool tip widget and the QTreeView did not change anything - maybe I am missing some additional flag or something here.
I also tried the following, brute-force method:
class ToolTip:
def __init__(self):
...
self.itemView.setVerticalScrollMode(QAbstractItemView.ScrollPerPixel)
self.itemView.verticalScrollBar().rangeChanged.connect(self.resizeViewVertically)
def resizeViewVertically(self, min, max):
self.resize(self.width(), self.height() + max)
which works most of the time, but not always. Every once in a while (every second time, to be exact, but I don't know if that is coincidence or not), using this code, the view resizes correctly (ie. all contents fit and there would be no need for the scroll bar), but the scroll bar does not disappear, allowing to scroll into the empty space below the last line.
You may want to reference how this item works:
http://ftp.ics.uci.edu/pub/centos0/ics-custom-build/BUILD/PyQt-x11-gpl-4.7.2/examples/layouts/flowlayout.py
May give you some hints as to what you need. Its a layout you can drop into a scrollwindow for isntance, and when the main window gets rsized, it wiill re-order all widgets inside to fit
Related
I am working on a Qt-UI with PyQt and found this nice snipped to create a custom collapsible box widget here: How to create collapsible box in PyQt
I have just replaced the internal QScrollArea by a QFrame.
It works perfectly, as long as the content of the layout that is added stays the same.
However, I allow the user to add or remove widgets from that layout dynamically during use. Here I need some help. I am adding a Grid Layout with, say, 3 widgets inside there (initial creation of the box with .setContentLayout) and once the user adds a 4th widget:
the layout is compressed and keeps its original size
all widgets inside are compressed to fit in the newly created one
overall size of the collapsible box is kept constant.
I have played with various options like updateGeometry() on the content_area and all surounding widgets. It seems I don't fully understand what this code does, I am not really familiar with these animations yet. My best guess is, that the animation somehow blocks the update of the height of the collapsible box, causing the layout to be compressed.
I would be really happy for a pointer where to look / what to adjust to get the size of the collapsible box reacting to the size of the containing layout.
Thanks!
I'm working on a GTK program in Rust (someone can probably answer this if they don't know Rust, as I can figure out how to translate between different bindings and the native C API) via the gtk-rs bindings for which I want to have a non-editable TextView who's contents are constantly updated in my code. I want the user to be able to resize the TextView to any size, after which my code will re-calculate its contents accordingly. Unfortunately, GTK prevents any resize from taking place that would hide any contents that are current in the TextView. I can't use a ScrolledWindow because I don't want visible scrollbars, and disabling the scrollbars on a ScrolledWindow prevents the resizing behavior that I want. I also tried calling set_size_request to set the size to both 1, 1, and 0, 0 after every text change, but this does not change the behavior at all either — the user still can't properly resize the TextView (by resizing the window).
How can I enable the resizing behavior that I want?
Probably this is not possible. What would be the point of resizing the text view smaller, if the user can never see the text that is outside of the viewport because you don't want scrollbars? That seems like it would confound the user's expectation of how such a component would usually work.
Maybe an approach could be that you pick a certain number of lines to show, make that the size of the viewport, and delete the old contents of the text view that scroll outside of the viewport?
I have a window whose size I need to change when the user clicks on it. I am using [self setFrame:windowFrame display:YES animate:YES] to accomplish this.
Even though the window successfully changes size (I increase its height), it moves the contents of the window up with it. How do I prevent this from happening? I want the contents to remain in place.
I am on OSX Mountain Lion developing an app for OSX using Objective-C and Cocoa.
EDIT: Constraints and/or Springs and Struts will not work as I need to move the contents around after the window is resized.
Constraints and/or Springs and Struts will not work as I need to move the contents around after the window is resized.
In that case, you should use NSViewAnimation.
A single view animation can actually perform multiple animations to multiple views, and you can even do one to a window, despite the class's name and the fact that windows aren't views in Cocoa.
You create a view animation with initWithViewAnimations:, which takes an array of dictionaries. Each dictionary identifies the target (NSViewAnimationTargetKey) and what to do to it: Either change the target's frame (NSViewAnimationStartFrameKey and NSViewAnimationEndFrameKey) or fade the target in or out (NSViewAnimationEffectKey). For your case, you'll be changing the targets' frames.
When the user does the thing that causes the resize of the window, you'll need to compute the desired overall size of the window (taking care to adjust its frame's position so it doesn't grow off the screen), as well as the new frames—both positions and sizes—of your views. Everything that will move and/or change size, create a dictionary for it and throw it into the array. Then create the view animation.
An NSViewAnimation is a kind of NSAnimation, which provides all the methods for starting and stopping the animation, monitoring its progress, hooking into it, and chaining multiple NSAnimations together. If nothing else, you'll need to start the animation.
If you are using the Interface Builder to build these views, then I believe one approach is to set the "struts and springs." These are available under the "size inspector" and are the red arrows and bars above the "autosizing" label. Play around with these to get the effect that you want, but the general idea is that the arrows control how the size of the view adjusts to changes in the size of the parent view, and the bars control the relationship of the edges of the view to the edges of the parent view as the size changes.
In constraint-based layout, set the views around the edge of your window to be a fixed distance from their superview's edge.
Xcode will infer a lot of resizability from that; if anything still isn't resizing properly, adjust its constraints so that its width and/or height is no longer constant.
The easiest way is to move your views until blue lines show up in the editor. Each blue line corresponds to a rule in the HIG about how things should be lain out, and if you drop the view there, Xcode will create constraints matching those guidelines. For example, if you set a view 20 points from the right edge of its superview, you'll get a blue line for that, and if you drop the view there, you'll create a constraint that the view must remain that distance from that edge.
The superview isn't the only view with which you can create HIG-based constraints. You can also create guideline constraints between sibling views. For example, if you put a button next to another button at the appropriate distance, you'll get a blue line across that distance, and if you drop it, you'll create a constraint that those two buttons must remain that distance from each other.
If you want to do something really custom, the three buttons in the lower-right corner of the nib editor will let you create any constraint you want. What you have selected determines what constraints you can create; the nib editor's outline view will help you make sure you have the selection you want.
You are going to have to iterate through all of your subviews and change their frame positions based on the delta of your window frame.
so if you expand your window frame by 20 in all directions, all your subviews are going to have to increase their frame positions by (20,20) to offset the windows movement.
Initially I was under the impression that it uses the table row slideup/down animations while inserting/deleting new rows but I doubt if it's doing that as it does it so fluidly even with thousands of items in the list (otherwise it would take a lot of time for the deletions/insertions to work).
Am I right in my assumption that it's simply attaching a new instance of the News list at the bottom of the screen, shrinking the above one while the one at the bottom expands to fill up space?
UPDATE:
Please see this video of what I mean: http://dl.dropbox.com/u/4960327/ReederAnim.mov
I can not tell you exactly how Silvio Rizzi made this, but as you see in the playback, a list view is added behind the shown list view, and the front list view fades out (.alpha = 0.0;) while the list view behind it expands its height per row.
When you desicate it frame by frame it becomes quite clear what he does, and it is really not that advanced. But I have to admit, with the white "milky" polished interface, it looks quite neat.
In addition, you can see that while animating, the background list view only renders the top 7 entries (hopefully calculated by dividing the view height with the average height of the cells shown) making the list view quick to load. Then afterwards, he can load an extended array of cells once you start scrolling, or in a background thread starting once the animation is complete.
I'm trying to show the "selection" of a certain sub-string in a
gtk.TextView by drawing a border around the word. The only way to mark
text in a TextView that I've found so far is by placing TextTags with
modified properties. This does not seem to offer a way to draw a border,
though, DOES GTK SUPPORT THIS OR IS THIS A PROBLEM WITH ONLT PYGTK
I figured out how to draw on a text view !!!
To begin with lets assume the reference to your gtk.TextView is in a variable called viewer, Inside one of ur classes
Also the draw function has to be called with an event called expose-event else the drawings will be refreshed and will not stay on the screen
The next part is the gtk.TextView consists of 7 types of gtk.gdk.windows on which u can draw
gtk.TEXT_WINDOW_WIDGET
gtk.TEXT_WINDOW_TEXT
gtk.TEXT_WINDOW_LEFT - not displayed by default
gtk.TEXT_WINDOW_RIGHT - not displayed by default
gtk.TEXT_WINDOW_TOP - not displayed by default
gtk.TEXT_WINDOW_BOTTOM
gtk.TEXT_WINDOW_PRIVATE
For the drawing to appear on gtk.TextView We have to draw on gtk.TEXT_WINDOW_TEXT
An Example Code is as shown Below
if(viewer!=None):
viewer.connect("expose-event", expose_view)
self.drawable=viewer.get_window(gtk.TEXT_WINDOW_TEXT)
def expose_view(self,window,event):
if(self.drawable!=None):
self.drawable.draw_line(self.drawable.new_gc(),1,1,30,30)
# (1,1) and (30,30) are the coordinates and u can give the values accordingly
In a gtk.TextBuffer tags are used to set one or more pre-defined text attributes. Without subclassing, this is limited to the properties of a gtk.TextTag, and doesn't include anything akin to a border or outline property. There is no difference between PyGTK and plain GTK+ in this regard.
While somewhat hacky, the easiest way to do what you want to do is to connect to the expose-event of your gtk.TextView, get the coordinates of your string and draw on event.window, which is the gdk.Window of the event provided in the expose callback.
(Note that you don't have to get and store the gtk.TEXT_WINDOW_TEXT window, you just need to check what window the expose event is for in the callback, probably ignoring the expose if it's not for the text window.)
Instead, you could presumably subclass one or more of TextBuffer/TextView/TextTag to add a border tag, but whether it's reasonable to do so is another question.