I'm trying to add a custom background to my horizontally laid out container. There are two ways mentioned to accomplish this:
Use a SkinnableContainer with a HorizontalLayout
Use a Group with a Rect and another HGroup inside it.
Which is a better option according to memory? Also, is placing multiple groups, hgroups and vgroups in a nested fashion a major flaw in design?
Thanks in advance!
Which is a better option according to memory?
You'll have to test and see, but from a theoretical approach; a SkinnableContainer will perform a lot more processing than a group. My first approach would be to use a group with a Rect inside it. Or, if you're doing mobile development, use a group and draw a Rect on top of it using the graphics API.
Also, is placing multiple groups, hgroups and vgroups in a nested
fashion a major flaw in design?
Not a major design flaw, but it could very well contribute to the lack of performance in an application. It it becomes an issue, you should evaluate your use of containers and see if you can minimize. Sometimes using a basicLayout and writing a layout algorithm will give you a lot more performance, and flexibility. It may very well take longer to write, depending on the complexity, though.
Related
Why do we need to define the grid for mobile?
What is the advantage of doing so?
Check this example: common layouts with ccs grids on MDN
So, we could have the same results for mobile without defining a grid, just defining the grid at the first breakpoint would do the job.
You're correct for the most part. With the example in that tutorial, there is no difference if you declare the grid at the first breakpoint. The only differences are semantic.
Some of the benefits:
Consistency and clarity:
Your code will be more consistent and easier to intuit what is going on if the same layout method is used across all your breakpoints. Good css is easy to read, even for people who are not familiar with the project, who are not familiar with your coding style. If you intend to use grid layout, it should be consistent and used across the board.
Complexity of layout:
The example doesn't require grid layout for mobile, but that doesn't mean that will always be the case. As you iterate over the design, you may need to add more complexity later. If the structure is in place from the get-go, the refactoring process becomes easier.
Still, there is an argument to be made for only including code that is absolutely necessary to implement the correct layout. It's really down to personal preference whether you include it or not.
I'm working with a large flex applications and I have noticed that one of our largest components (with lots of child canvases) takes about 6 seconds between the initialize and creationComplete events. I've been doing some reading and have found that having lots of nested canvases can cause slowdowns, but i'm not sure if this is where the slowdowns would be? Anyone have any suggestions on speeding this up, or even diagnosing exactly where the slowdowns are coming from?
It's been my experience that nested containers with dynamic sizing are the most common cause of these types of lags. Some things to try:
Set explicit sizes/positions for your containers/components whenever possible. This reduces the incredible amount of measuring that goes on within the framework during the creation process.
Reduce the number of nested containers. Sounds obvious, but it's amazing how much you can cut away when you start looking critically at how your UI is set up. Specifically, are there HBox and VBox containers you can get rid of by simply setting explicit positions/sizes for the child components? Do you really need to use a Form container?
Switch your containers to the much lighter weight Spark Groups instead of using the heavier weight Canvas where possible.
Hope that helps. If not, post some code so we can dig in to your particular issue.
The biggest thing to consider is to use VBox's and/or HBox's in place of some dynamically generated x's and y's. VBox and HBox are much more efficient. Look into it!
Adding many display objects to the display list all at once can take a long time, especially if we're talking about Flex containers that have layout and scrolling logic in the mix. Since you say you're using many Canvas containers, that could certainly be the issue you're running into.
I know that a lot of developers abuse the creationPolicy property. Normally, it is set to "auto" which allows Flex to defer instantiation of a container's children until a very short time "later". Often, before the next frame, so you don't even see the difference. Do you happen to set creationPolicy to "all" anywhere in that hierarchy? This could be forcing the Canvases and their children to be created immediately.
On a form designed with Qt Designer, I have two QGroupBoxes with a bunch of controls in each of them. Both group boxes have nearly the same contents (QLineEdits with associated labels).
What I want to do, however, is to align the controls together, as if they were part of the same grid layout. But since they are in separate containers, they can't share the same layout, and I don't want to give them a fixed width.
Is there a way to do it in Qt Designer? If not, is there a way to do it in code?
Thanks!
There is no way to do this in Designer. As far as I know, Qt does not provide a good way to do this in code either. If you really want this, you will probably have to rely on something a little hacky.
Here's my first idea: Override resizeEvent() in the widget that contains the two group boxes to get the preferred size (via sizeHint() or minimumSizeHint()) of all of the labels and set the fixed width of all the labels to the largest preferred width.
I would encourage you to ask yourself if this really matters (is it worth the development time?) and consider whether you can avoid the problem entirely with a slightly different UI design.
BTW, you might want to take a look at QFormLayout if you haven't already.
Since I new with CSS, I just started to work with CSS Grid system. I would like to know if are there any technical issues in use CSS grids? I mean, which are the reasons for you to not use grid?
Thanks
Flexibility
Once you start using the grid, you are stuck with it. Any other issues you might wind up finding you will have to conform to.
In my opinion (and every other designer I've talked to) it is far easier to simply define your own columns and default sizes as classes and apply them as-needed. A custom grid if you will. Then changing the styling is as easy as changing a line or two of CSS, instead of either re-generating the grid system or redesigning the site and sacrificing in order to use the grid.
I'm a fan resets and some minor love from Blueprint (especially the Typography), but that's about it.
I've just started using object oriented CSS (OOCSS). I'm really enjoying it because it provides a very basic and minimalistic grid system. It allows you to create relative sized grids by dividing an element into halves, thirds, fourths, or fifths. The divided elements are infinitely nestable.
OOCSS is more of a philosophy than a framework. It's all about how you extend a very basic foundation.
Check out these links:
http://oocss.org/
http://developer.yahoo.net/blogs/theater/archives/2009/03/website_and_webapp_performance.html
http://www.youtube.com/watch?v=j6sAm7CLoCQ
The only real reason is that they can lead to bloated markup, sometimes you have to do some serious nesting depending on the layout and desired effects+flexibilty.
They also lead to excessive class name lists on elements. However, you can avoid this at least if you move the CSS to semantic classes/ids before deploying... but thats can be alot of extra work. Blueprint is the excpetion here because it has acommand line tool to allow you to apply the rules from its framework classes to semantic selectors.
Overall i generally use them because its alot easier to teach a designer how to use a grid template. That why im not do alot of production art tasks when i go to slice things down. It jsut makes the whole process smoother IMO.
If your site has a column layout AND repeatable design patterns throughout the site... then there aren't any reasons not to include a grid. A grid adds: organization, proportion and alignment to your page. So why not keep that consistent? There is no reason.
Just don't Overuse A Grid
Some people say a grid is inflexible? That's not totally true - you can use it where you need it. You can always remove it or adjust. Just don't overuse it.
It depends on the grid system. Most grids have a fixed amount of columns, which restrict you in how you create your layout. For example, they don't allow you to combine 30%/30%/40%, 50%/50%, 25%/75% and whatever other combinations you can think of.
Some grid systems also don't allow nesting. That means you can't use a grid element as a grid for child elements in those grid systems, which makes it a lot more difficult for many layouts to be coded to HTML.
Also, some grid systems use techniques that don't work in older browsers. Before you use a grid system, you should always make sure it supports the browsers you need to support with your project.
There are frameworks out there without such restrictions, though. Cascade Framework, in fact, has a grid system far more flexible than that of any other framework out there and works fine in both IE6-8 and modern browsers alike.
I was told that there is an increase in performance when using Canvas versus HBox or VBox when laying out out the position of children. As a result, a number of our components have been converted over to using Canvas. However, now there is code being added to calculate the x and y positioning of some of the child elements based off of the width and height of other children. Is it worth using a Canvas to increase performance if code needs to be added to determine the coordinates/positions of the children? Is there a better method or technique available that should be practiced other than just minimizing the number of ui components added and specifying positioning absolutely?
There are a number of middle-of-the-road techniques, one of which is to use rendering-type components, such as TileGrid or ItemRenderers, if your layout fits a certain formula. If you're using forms, try using the Form layout component instead of using a custom layout.
If you do need to use the layout engine in Flex, the way to optimize your usage is to remember that certain techniques are used by the framework in increasing performance load, loosely following the below list, the last being the most performance intensive:
absolute positioning (<Canvas>)
relative positioning (<VBox>)
constraint-based positioning (right=0)
advanced constraint-based positioning (<constraintColumns>)
Using relative positioning is usually not that performance intensive. If you are finding that it is, it could be that you're using too many nested containers. Look at your layout architecture and try to find out ways in which your objects may be "over-laid out", and simplify them. A good tool for this is FlexSpy, which lets you introspect object layout at runtime.
Another common performance bottleneck is that your application is attempting to do some number-crunching at the exact same time that your GUI is attempting to respond to user interaction. Although no green threading frameworks exist at the moment which enable you to run UI and logic in separate 'threads', you can use a good architectural framework such as Cairngorm or Mate (there are many) which uses Commands instead of straight up methods, so that functionality execution which may take up processing cycles waits until the UI has finished responding to the user.
A couple things you want to keep in mind while optimizing a Flex UI:
Avoiding excessive nesting of containers. Consider using a Canvas with absolute or constraint-based positioning over nesting lots of HBox / VBox elements. However this doesn't mean you should NEVER use VBox/HBox. You can mix and match, such as using a Canvas as the main container and positioning child Boxes inside them as needed, just try to avoid too much nesting.
Using the UIComponent model properly in custom components. In particular, using invalidateProperties(), invalidateSize() and invalidateDisplayList() so that their companion functions (commitProperties(), measure() and updateDisplayList()) are invoked at an optimal time for the Flash Player. Deepa gives a great talk about this here:
http://tv.adobe.com/#vi+f15384v1002
She explains how making heavy use of the invalidation scheme allows the Flash Player to execute your code at an ideal time, i.e. not in the middle of a screen update. These principles are used by all Flex components and can/should be leveraged regardless of the framework being used.
To make sure I understand:
You heard that Canvas can position children faster than [VH]Box
Canvas only does absolute positioning
Some (many?) of your components have an absolute position, so you switched to using Canvas
But some of your components have a relative position, so you need to write code to position them
Is that correct?
Anyway, assuming I'm correct (which may not be the case), the first thing you want to do is pick the functioning interface which requires the fewest lines of code, then decide if it's "good enough". You want the one with the fewest lines of code because studies have shown that there is a correlation between lines of code and number of bugs (and you don't want bugs). You want to see if it's "good enough" because, if it IS "good enough", you don't need to do anything (if you do try and make it faster, you're committing Premature Optimization).
But that's probably not what you wanted to hear :)
So I'll also suggest that, if you want to stick with Canvas-based layout, you try sticking all the relatively positioned content inside [VH]Boxes, which are then absolutely positioned inside the Canvas. There's a good chance the code Adobe has written is faster than code, so you should try to take advantage of it.
But the only way to know for sure is to try it and profile it.