I'm using UICollectionView with self sizing cells and have set the estimatedItemSize property for this to work.
When performing a delete animation however, the cells animate to their position if they were sized with the estimatedItemSize property, rather than their auto layout (actual) size.
What's worse is that our cells are variable sizes and there doesn't seem to be a method like UITableView where we can pass an estimated size per index path.
I attempted to subclass the collection view flow layout and override the initialLayoutAttributesForAppearingItemAtIndexPath(_:) and finalLayoutAttributesForDisappearingItemAtIndexPath(_:), but on inspection the superclass's return values for these methods are correct.
Does anyone know of a solution to this seemingly basic bug?
Related
I'm trying to make components resize to keep their starting ratio depending on the size of the window.
Using an AnchorPane I can set the constraints to be in pixels, the problem is that resizing the window to make it bigger makes all the elements stretch to keep the exact same amount of pixels defined in the constraints.
What I want to be able to do is define them in terms of percentages or in some other way in order to keep the aspect ratio and position consistent between window sizes.
So far I've seen two possible solutions:
Compute constraints on the fly
Compute the constraints on each resize event as proposed in this question:
AnchorPane Constraints in percentages, but that means that piece of code could be potentially called once every pixel change.
Nest Panes and surround the element with rows/columns
Another way is to nest panes and components, something like:
Root > AnchorPane > GridPane > AnchorPane > Component
Now to position it where you want you add one row above, one below, one column before and one after where your component should be (surrounding it) and set the resize percentage of them.
This works by "leaking" the resizing behavior of the AnchorPane to the Component, and the width/height weight of the rows/columns.
My question is: Is there a better way to do this?
While both could work, none of them seem quite right. One involves calling code once every pixel change and the other one adds (a lot of) unused elements.
Example using the second approach
I have a custom QAbstractTableModel for my data and the model currently contains fixed number of columns (12). I also have a custom QTableView to display this model. When I added this widget to my dialog, it always clapped the last few columns like this
I use standard layouts (QFormLayout, QVBoxLayout) for adding widgets to the dialog and I haven't specify minimumSize() for my widgets, hoping the layout engine to calculate the best for me.
So, how do I setup the model class / QTableview class so that it will automatically expand to show all the columns? Or how do I make the minimumSize of my tableView depends on the width of table columns?
(I don't want to hardcode the pixel values for the windows, as whenever the columns changes, I will have to adjust the values again manually)
As you can see, scroll bars are inside your table, not outside of it. QTableView extends QAbstractScrollArea, which creates them, when content does not fit into viewport. Minimal size of viewport is controlled by method QSize QAbstractScrollArea::maximumViewportSize () const (which is not virtual, by the way).
I think, the best way would be to save QWidget::saveGeometry() (is it QMainMindow?) and QTableView::horizontalHeader()->saveState() in QSettings in your widget's destructor, and resotre them in constructor.
I am a little confused about the setActualSize method. It appears from what I've read, that if it is not called on a component by its parent, the component will not be rendered.
So it appears that setActualSize is a critical method that is directly bound to rendering the UIComponent. It also appears that the width and height properties of UIComponent override the functionality of the width and height properties of flash.display.DisplayObject, in that they are not directly bound to the rendering of the object but are virtual values that are mainly used by the getExplicitOrMeasured when the parent of the component calls the component's setActualSize method.
So the question are:
1) Why isn't the default behavior of every component to just call setActualSize(getExplicitOrMeasuredWidth(),getExplicitOrMeasuredHeight()) on itself?
2) I guess this question stems from the above question and the behavior as I understand it as described above: does setActualSize change the visibility of the component?
It appears that that the behavior is that a component is not rendered until setActualSize is called, but if it contains display object children itself (expected behavior as it can calculate measure on itself) and is added to the display list, the only reason why flash isn't rendering it, is because its not visible.
The answers to your questions are in the way the Flex component life cycle works, consider these two phases:
measurement:
The Flex framework will call the measure() method of your component. You can override this method to set a default and/or minimum size for your component.
Flex components first measure themselves to provide a default and/or minimum size suggestion to the layout/container classes. Flex does this from a bottom up approach, so that the lowest level objects are measured first. Thus when each parent object measures itself, the preferred sizes of it's child objects has been established.
rendering:
Later Flex calls the updateDisplayList() method of your component. You can override this to size/position your component's child objects. This is where setActualSize() is intended to be used: the parent calls setActualSize() on it's child objects, not on itself.
Note the method signature of updateDisplayList():
protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
Measurement was done from the bottom up. However, rendering is done from the top down. So at render time, updateDisplayList(unscaledWidth, unscaledHeight) gets executed on your component. Flex is telling your component the space it has been allotted to render itself, and your component must size/position it's child objects accordingly and/or do programtic drawing.
The sizes passed in to updateDisplayList() are based on various factors:
how/if you override the measure() method (measure is not called when
your component has a fixed width/height)
the types of sizing
parameters (fixed, percent, constraint) and layouts that you use
An old but good resource on this topic
setActualSize() is one of the crutial and most interesting methods in Flex layout process:
1) Notice that setActualSize() is an entry point for parent's layout to set the component size, and it has to be called by parent (container) almost exclusively!
This is because only the parent knows the amount of space available for each child (this method is being called after all children are measured and the container knows it's own given size).
(note: the example of not calling it by layout posted below)
This method exists because if parent would set 'width' and 'height' on children directly, they would immediately turn into fixed size children, and they won't be measured anymore.
Using this method, only the rendering size is being changed - not the (explicit) width and height but _width and _height - meaning if for some reason the container resizes again, the children will be resized by given rules (percentage of the parent, expanding to child component's children size etc.)
2) Yes, because if this method isn't called at all, the component has a (rendering) size of (0, 0), so this is the reason of it's invisibility (not setting 'visible' to false)! ^_^
Note that THERE HAS TO BE A LAYOUT (even a non attractive one) to trigger this method call. By 'non attractive' I consider the layout that isn't supposed to do anything smart, like CHANGE THE WIDTH AND HEIGHT of children at all (like absolute layout)!
Now, look at the PopUpManagerImpl's class addPopUp() method: there is an interesting case of calling setActualSize():
IUIComponent(window).setActualSize(
IUIComponent(window).getExplicitOrMeasuredWidth(),
IUIComponent(window).getExplicitOrMeasuredHeight());
Explanation: PopUpManager does stuff that layout should normally do, because it WANTS TO KNOW THE POPUP DIMENSIONS IMMEDIATELY, so it could center the popup on stage. It has no time to wait for the layout pass!
If you comment those 3 lines in the framework code, you'll see that popup is being centered with it's top left corner - just like it's size is (0, 0). Anyway, it is rendered with proper width and height because at rendering time the dimensions are known.
Hope this makes things a bit clearer...
Cheers! ^_^
Danko Kozar
Hi i'm trying to get a photoshop-like behaviour for my QGraphicsScene
The grid in the background should not resize with the call of scale. And I must be able to save the picture with QPixmap::grabWidget(view) but without the background grid. I can probably do it with removing the background layer just before saving the picture, but i'm not sure if its cleanest way to do it.
Any ideas ?
thx.
Question 1
The grid in the background should not resize with the call of scale.
Use the QGraphicsItem::ItemIgnoresTransformations flag.
The item ignores inherited transformations (i.e., its position is
still anchored to its parent, but the parent or view rotation, zoom or
shear transformations are ignored). This flag is useful for keeping
text label items horizontal and unscaled, so they will still be
readable if the view is transformed. When set, the item's view
geometry and scene geometry will be maintained separately.
In order to set this flag use the setFlag function when creating the grid item.
Question 2
I must be able to save the picture with QPixmap::grabWidget(view) but without the
background grid.
Call the hide function on the grid item before calling the grabWidget. After you have grabbed it you show it again by calling the show function.
I've noticed that the default behaviour for a DataGrid's vertical scroll bar is to scroll one row at a time. This is all well and good when the rows are all uniform and small (e.g. displaying a single line of text), but gets really ugly as soon as you have rows with variable heights.
I'm curious, is there a way to make DataGrid scrolling "smooth"? For instance, is there a way to have the DataGrid scroll by a set number of pixels, lines of text, etc. rather than scrolling one row at a time?
So far, the only solution I've managed to come up with is to place the DataGrid in a Canvas and have the Canvas do the scrolling instead of the DataGrid. The issue with this approach, though, is that as soon as the Canvas scrolls far enough, the DataGrid headers scroll off-screen. Ideally, I'd like to get the smooth-scrolling nature of the Canvas, but also keep the DataGrid headers visible. Is that possible?
The way that ItemRenderer's work in Flex 3 makes smooth scrolling difficult to achieve. Basically Flex recycles item renderers scrolled off of the top of the list as the display objects used for new data at the bottom of the list. Adobe's implementation of most list components in Flex 3 creates and adds these items as they come on to the screen rather than just off the screen, so they "pop in" and smooth scrolling isn't available. I'm not sure why they couldn't have done it in a similar manner for items +/- one position above or below the current scroll pane, but they didn't, and we're stuck with sticky scrolling by default.
Work-arounds do exist, though the one you've noted (dropping the datagrid into a canvas) negates the display-object saving intention of item renderers and incurs a performance cost. This will be fixed for most list-based Flex components in Flex 4, though it won't be fixed immediately for DataGrid. The DataGrid / AdvancedDataGrid component is maintained by a separate team based in India, last time I heard, and so it tends to be a bit behind the rest of the SDK.
I'd recommend trying something similar to this implementation of a smooth-scrolling list by Alex Harui. I'm not sure exactly how well it'd work for DataGrid or AdvancedDataGrid, but this is the most intuitive technique I can think of for making the list scroll correctly.
Try this... It's still based on Alex's code that was mentioned above. His should still be a great start for removing the snap-to-row behavior. Original source:
http://blogs.adobe.com/aharui/2008/03/smooth_scrolling_list.html
Alex's original some code for smooth vertical scrolling but that was not an issue I had with the DataGrid. It was smooth scrolling horizontally that I needed. I am using the DataGrid in an unorthodox manner for analyzing plain text reports output by our database (great way of providing visual feedback on a document). The code below allows content to go off screen and the user can scroll without that snap-to-column behavior.
You can adapt this to use the same math routines for vertical scrolling and then it will make scrolling possible and ignore the snap to row behavior. In particular switch the usage of the listContent.move method to move the contents vertically and use a inverse of the rounded pixel value you calculate from the vertical scroll bar (as opposed to my using the horizontal).
This method is bit simpler than Alex's method from the link above - a lot less code so try adapting and see how it works.
override protected function scrollHandler(event:Event):void
{
// Override the default scroll behavior to provide smooth horizontal scrolling and not the usual "snap-to-column" behavior
var scrEvt:ScrollEvent = event as ScrollEvent;
if(scrEvt.direction == ScrollEventDirection.HORIZONTAL) {
// Get individual components of a scroll bar for measuring and get a horizontal position to use
var scrDownArrow:DisplayObject = horizontalScrollBar.getChildAt(3);
var sctThumb:DisplayObject = horizontalScrollBar.getChildAt(2);
// I replaced maxHorizontalScrollPosition in Alex's code with "1300" to fix my exact application. In other situations you may finding using some property or different value is more appropriate. Don't rely on my choice.
var hPos:Number = Math.round((sctThumb.y - scrDownArrow.height) / (scrDownArrow.y - sctThumb.height - scrDownArrow.height) * 1300);
// Inverse the position to scroll the content to the left for large reports
listContent.move(hPos * -1, listContent.y);
}
// Go ahead and use the default handler for vertical scrolling
else {
super.scrollHandler(event);
}
}