I have a number of UI elements like panels, edit fields, buttons, labels etc. so panels contain other panels which contain input fields, editors and so on. Most of the elements are editable and/or resizable which means whenever I change anything, a lot of adjacent UI elements should change their width, height and x/y position on the pane. It works fine with a small number of elements but incredibly slow when the number of elements is thousands.
Is there a fast layout algorithm which can be used in this case? Note that I cannot use any existing layout managers and should come up with my own implementation.
I'd suggest taking a leaf out of the Android playbook and have a larger 'grid' and keep everything sized in modular multiples - this avoids you needing to solve the knapsack problem everytime!
For example, instead of having a button with an width of 80 and a height of 40 you store this as metadata as {2:1} (assuming your layout grid is 40^40 squares).
This way if you have a work panel with space of, say, {2:12} this could be filled with two objects of size {2:6} or maybe 3 of size {2:4}.
It's pretty simple to fit-to-max too as any available space can just be scaled up (say you delete a {1:1} item you can just expand the one next to it to take the space etc - you can of course create your own rules around whether objects can scale in single directions etc.
The other advantage of this approach is that you can easily manage different screen sizes and resolutions too while still keeping the same framework and look and feel.
Related
Since Jason Smith didn't recommend Relative layout and said that we should use Absolute layout I have a question how can we deal with RelativeToView concept?
Absolute Layout sets proportional coordinates and sizes of the elements within itself relative to itself not to each other as RelativeLayout. What to do if I need some elements to be relative to each other? Creating additional Grids and StackLayouts? I would rather use RelativeLayout then or I am missing something.
Decided to add a simplest example and consider we are talking ONLY about Relative and Absolute layouts, no Stack, no Grid. I have 2 buttons and I want to place them as shown in the picture
With absolute layout I could define the position of the top button and say it's height 10% of the screen. Now I could shift the bottom button by saying it starts at 11% of the screen. BUT this will change my top button height. If I want my top button to be it's natural "auto" size I cannot do that. So, how can I put my bottom button under top one if I have no idea how much top button occupies on screen? I know how to do it with Relative but how I can do it with Absolute Layout?
It looks like the solution is nest bunch of layouts https://developer.xamarin.com/guides/xamarin-forms/user-interface/layouts/absolute-layout/
Is that the only way? Is that performance still better than Relative layout?
By its nature RelativeLayout is powerful and offers layouting options that no other Layout on its own does. But that power comes at a cost in performance. Resolving the constraint dependencies consistently and obtaining a final layout doesn't come cheaply.
The point is not necessarily that RelativeLayout should never be used, rather that often times other Layouts can do the job, and yes, even 2-3 nested Layouts can be more performant than a single equivalent RelativePanel.
Grid in particular is a powerful option with which similar effects can be achieved by astute use of Auto, Star, and/or absolute-sized rows and columns as appropriate, plus RowSpan and ColumnSpan, plus element margins, etc.
To consider your specific example, I don't know of a way to achieve what you want with an AbsoluteLayout, at least without the added complication of attached properties. But it seems like a natural fit for a Grid with RowSpan="Auto" on the first row. From a diagram alone I can't tell exactly what other constraints you're going for.
My app needs to show several buttons, without overlap, and preferably without scrolling or zooming. They must be big enough to poke with a finger and read the text. Button width depends on its text length, and the height is constant. The screen size is known.
Each button represents a food about which I know some nutritional information. I'll calculate a protein:carb ratio and a fat content, both ranging from 0% to 100%.
I want to put the buttons close to a position that reflects their nutritional content: e.g. protein-rich at the top, carby at the bottom, fatty on the right and lean on the left. So cake would be bottom right and meats would be somewhere on the top edge.
Often, there'll be overlap and I'll have to nudge them away from each other.
The puzzle is to invent an algorithm for that nudging. The desiderata in order of priority are:
1) Readable and pokeable size, no overlap.
2) No scrolling or zooming required, although it'll happen when there are so many buttons that they could never fit on the screen even if we didn't care where they were.
3) Buttons should be close to where the user would look based on knowing the nutritional content of the food.
Incidentally, I'm using JS on a smartphone, not prolog or the like.
(There are some seeming dupes, but no solutions. One is about diagonal stalks, another just advocates throwing it at a game engine, but most are devoid of answers.)
Ther MArVL group at Monash University does work on constraint-based layout work. Some of their software might be applicable to your problem.
I'm trying to display images in a grid layout that is 4 units wide by an arbitrary number of units high.
Each image in the grid may be 1x1, 1x2, 2x1 or 2x2 units. I'm also using jQuery masonry to try and eliminate some gaps in the layout.
The size an image is displayed at (1x1, 2x2, etc.) is a "preferred" size based on its dimensions.
I'm thinking that the easiest way to eliminate gaps in the layout would be to display certain images in the layout at sizes other than their preferred size. How can I do this algorithmically, maintaining the largest number of photos that are displayed at their preferred size, while overriding for those that are determined to be necessary for a gapless layout.
A visual example; I want to turn this:
into something like what they have on this website: http://500px.com/
Just a start: I think this is an instance of bin packing which is NP-complete in the general case (see this pdf). Might be helpful to start searching for things in those terms... this is not a complete answer by any means.
The simplest thing you can do is group pairs of 1x2s together, pairs of 2x1s together, and quadruples of 1x1s together. Laying out lots of 2x2s is then easy, and only the odd-images out will need to be resized. This (or something like it) is almost certainly what 500px.com does.
I suspect this solution doesn't really jive with your "laid out left-to-right, top-to-bottom" restriction. But I'm not sure what that restriction means, exactly. Perhaps if you could make it clear what that means we could help you better.
I'm implementing the CSS3 flexible box layout module as defined by the W3C, which is similar to Mozilla's box model for xul. While these standards specify how the model should behave, they don't give any details on how they should be implemented.
The parts of the model I'm interested in are:
Boxes have a width and height.
Boxes can contain other boxes.
Container boxes (parent boxes) are responsible for sizing and positioning the boxes they contain (child boxes).
Boxes have orientation which may be horizontal or vertical. The orientation determines how the child boxes are positioned and resized.
Child boxes may be flexible or inflexible. If the child box is inflexible it is drawn at the size specified in the width and height parameters. If it is flexible, then it is resized to fit into the available space in the parent container.
Flexibility is relative to other child boxes in the same container, boxes with higher flexibility are resized more than boxes with lower flexibility.
Child boxes can be constrained to a minimum or maximum size. If the child box is flexible, the parent box will never resize it below the minimum size, or above the maximum size.
Features 1-5 can be implemented quite efficiently. Feature 6 is problematic as the most efficient algorithm I can come up with is quite naive. The algorithm works as follows:
Place all the boxes in a list.
Loop through each child box and resize it using the flexibility to determine the amount to resize it by.
If the size exceeds one of the limits, then set the box size to the limit and remove it from the list, and start from the beginning of the list.
Step 3 is where the efficiency drops. For example, if there are ten items in the list, and the last one has a constraint, then the algorithm calculates the size for the first nine items, then when it reaches the tenth one it needs to redo all of the calculations. I have considered keeping the list sorted and first sizing all the constrained boxes, however this comes with the cost of added complexity and the overhead of sorting the list.
I expect there is a recognised optimal solution considering this is a fairly common feature in browsers and frameworks (XUL, .Net, Flex, etc).
Most box/container layout algorithms use a 2 pass algorithm. In the case of .NET (WPF) they are called "Measure" and "Arrange". Each control can measure its content and report a "desired size" in the recursive measure pass.
During the second pass (arrange) if the childrens desired sizes will not fit inside the parent, the parent uses its layout algorithm to provide the actual size to each child, for example by assigning the actual size weighted by desired size. Minimum/maximum sizes, box flexibility etc can come into play here.
More information on the WPF layout system
http://msdn.microsoft.com/en-us/library/ms745058.aspx
Xul layout
http://www-archive.mozilla.org/projects/xul/layout.html
I need the user to set a number of percentage values which should always add up to 100%. What are standard ways to archieve this? I came up with the following:
1) have a standard slider control for each value you need to set. Moving one slider will automatically adjust all the others so the sum will always come out as 100%. You can fix inidividual sliders with a checkbox displayed next to it. Only the remaining, "free", sliders will be adjustable.
Pro: consists entirely of standard widgets users already know
Con: lots of widgets, lots of screen real estate used, looks ugly when you have lots of sliders and thus low percentage values, normalization to 100% isn't immediately obvious.
2) have a slider control with several sliding knobs.
Pro: normalization is implicit and obvious because the length of the slider is fixed, relative weight is easy to see at a glance
Con: non-standard, knobs can easily overlap each other, knobs aren't easy to fix, no obvious place to put a text/number representation for each interval/percentage
3) display a standard pie chart.
Pro: normalization is implicit and obvious, relative weight is easy to see
Con: non-standard for interactive use, hard to make intuitive slice resizing work, no place to put a text/number representation for each slice
4) ... ?
I'm not happy with either of these hence my question here. Any better ideas? I'm dealing with 3-10 individual percentage values on a rich windows client (i.e. not web).
cheers,
Sören
What about vertical sliders? Like a sound mixer. I think it looks a lot better than a list of 10 horizontal sliders.
Or fixed width bar with several sliders on them, a bit like the gradient control of Photoshop if you know it.
Similar to the timeline idea, how about a slider like the partitioning interface in GParted or similar disk partitioning tools?
You could display the percentage values and actual numbers above the dynamically resizing bars to allow the user to edit them numerically instead of using the sliders if they want to configure it manually.
How about a time line view; (gantt chart) kind of like in Microsoft Expression Blend or in flash where you have multiple layers for each action and each action can be within a range on the scale from 0 to 100.