I had a problem with the ui-effects-wrapper covering other elements at seemingly random spots, thus creating dead zones particularly for anchors. Problem was solved simply by adding a z-index:-1; to the css for .ui-effects-wrapper.
Related
For the context, I'm working with Capella, an Eclipse RCP application based on Sirius (hence, EMF, GMF and draw2d). This application is used for MBSE, that basically means diagram representations for industrial systems.
I'm developping an add-on (viewpoint) to display custom labels next to diagram elements. These diagram elements are, to put it simply, boxes inside boxes. My problem is that usually the label text is larger than the space between a box and its container, so the label gets hidden. What I need is these labels to always be in foreground. As I'm more used to web development, what I'm looking for would be the equivalent of the z-index CSS property.
Currently I have no idea of how to achieve this, I'm using a custom .odesign that allows me to control some rendering options, like labels text, the color of some elements or to add decoration, but I dont think its the way to go for my problem. Maybe I should use a custom EditPart or a custom StyleConfiguration (I already used these components for other projects) but I have no clue where to start for this issue.
Any leads will be greatly appreciated.
We recently did this kind of changes to keep some labels in Sirius Sequence diagrams always on top: the combined fragments are placed behind the lifelines (z order) but we wanted to keep the labels of the CombinedFragments visible event their bounds intersects Lifelines, Executions or States).
This has been handled in Bug 564239 for Sirius 6.3.2 (used in Capella 1.4.1).
You could find some hints the bugzilla (Gerrits and commits can be retrieved from the See also section).
In Sirius Sequence diagram , we use org.eclipse.sirius.diagram.sequence.ui.tool.internal.layout.SequenceZOrderingRefresher to control the z-order of CombinedFragments : all the figures that composes them comes from some expressions in the odesign, and synchronization with the Capella model for exemple.
But in your case you want to control only the label, so it must not be dealt on the edit par level, but on the figure one. The "overlay" layer and figure lead might be a good one.
Do not forget another thing: in GMF/GEF, the labels of an element is displayed/shown/rendered/visible if it fits to the visible area of the parent container: in the case of a node in a container with scrollbar, the visible are will impact the visibility of the sub nodes (extended to their border nodes, edges, labels, ...)
Regards
Maxime
This is a very basic CSS design question.
When I have two block-elements
+----------+ +----------+
|~~~~~~~~~~| |**********|
|~~~~~~~~~~| |**********|
|~~~~~~~~~~| |**********|
+----------+ +----------+
and I want to set the space between them, there are three possibilities:
Left block with right margin
Right block with left margin
Margin for both blocks
What are the pros and cons for each one and—most importantly—what is considered
best practice?
It is generally a good idea to choose a direction (margin-left OR margin-right) and to stick to it on the whole project so designing will be easier and more consistent.
For more on the subject you can read this blog post: Single-direction margin declarations
That said, margin-left on boxes means "I do not want to be too close to the box before me" while margin-right means "I do not want other boxes to be too close to me".
So on designs where boxes have a margin by default, use margin-right (and margin-bottom) and on designs where boxes have no margin by default, use margin-left (and margin-top) on the few boxes with a margin. If it is mixed, choose the direction that seems the most coherent to you and stick to it.
No pros and cons, it is totally on your design, what you want to go for, using margin-right will make the last element have margin-right for no good reason, so say for example, you have three boxes, floated to the left, or they are displayed inline-block so because of the right margin, the last box won't touch the extreme right of the template, instead it will wrap and move down.
Do you see the red space, it's margin-right for the last element, which you won't need. shifting it more will result your div to move down.
Solution?
If you are willing to support legacy browsers, assign a class to the last element and write margin-right: 0;, say you are having 3 li elements floated, so you will write
ul.class_name li.class_name {
margin-right: 0;
}
Else, you can use :last-child pseudo to get rid of the extra margin.
So it will be
ul.class_name li:last-child {
margin-right: 0;
}
Same thing will go for the left, but instead of using :last-child and margin-right you need to use margin-left and :first-child respectively.
Last but not the least, using margin on both sides, will create a space on both the sides, again, resulting in disorientation of your layout.
In the above case, you will have to use both, either assign class to first and last element, or you need to use :first-child and :last-child to get rid of margin on the left for first element and margin on the right for last element.
Conclusion: For the two boxes you have, you should use margin-right
and use a class or :last-child to remove the extra margin on the
last element.
It depends where you will use it and how you will use it there is no exact rule for this. However if you will use some grid system for elements it is best practice. If your element cannot be suitable for grid system you can use any approach.
P.S. And there is another possibility to use pseudo element after or before I guess.
Simple Answer: It depends
It all depends on what you are trying to do, and what elements are those.
For example, if your site is oriented to the left, and those are two floating divs, with the same class, you wouldn't want to use margin-left, because that will introduce some space on the left of the first block.
It obviously makes no sense to add margin to both elements, unless you have dynamic content that may appear in between.
So, other than the obvious styling manner that you want your page to have, there is no difference in performance, but mostly readability of your code
I trying to create a fixed border to the site that dynamically change size with the browser window from this sprite (it isn't perfect I know.): http://fc07.deviantart.net/fs70/f/2011/269/7/0/bordersprite_by_nakos-d4ayzne.png
DEMO on jSFiddle
My problem as you can see is the vertical wall part. As the #falJ and #falB are height:100% they include the bottom wall's end too with the space between the two wall sprites. Is there a way to force backround-position to only use vertical wall part without bottom wall's end?
Thanks in advance.
Solution: http://jsfiddle.net/vonkly/Ld43B/
It's not the prettiest thing in the world, but it achieves what you want. Check out the source code & direct link for the background images to see what you'll need to do. It's currently set at 299px wide; I imagine you'll be using something wider.
I'd also suggest adding some padding around your content (either with a p tag, span, another div, etc.) - the way it is currently set up isn't what I'd recommend for readability.
EDIT
The only way I can imagine achieving a fluid width + height box with the borders that you have in the way that you want is to use a second image for the west and east containing divs. This should work with your current method.
I am a beginner at ActionScript3, and for my learning purpose, I am trying to build a match3 kind of game. I am making is a clone of bejeweled kind of game. but instead of swapping, I have to delete those elements and shift the upper elements down and add new elements above those shifted elements.
I am able to delete matched elements and after matching I'm removing those elements but I am stuck with the shifting code. I am not able to shift those elements down.
I believe that you should take a look at Richard Lord's Tetris source code as your game may be somehow similar in mechanics to Tetris. Tetris shifts down rows when you get lucky.
Richard Lord is one of the Flash Gurus and his way of doing things may seem pretty advanced for a starter like you. Take a look over the source code and see if it fits you. What I can tell is that this is the proper way to make a game but maybe it's not the best point to start for a novice like you that is in urgent need.
http://www.richardlord.net/blog/actionscript-3-tetris-source-code
I would approach it like this in 2 parts.
Loop through your array of board positions starting from the bottom row and check for an empty unoccupied slot, if you find one do another loop through the row above till you find a piece on the same column. If you find a piece on the row above apply a tween to move it down to the empty slot and continue your loop.
Once you have looped through all rows, and animated all the tweens you need to loop through again to find all the gaps that need gems dropped into them. Create new elements at those positions and then move them up by (element height * row), apply another tween to animate them back to their starting position.
I have a two-column paper where space restrictions are very tight.
I just looked at my last version of the manuscript and saw that the upper half contains a figure (as expected), but in the lower half there is a lot of vertical space between paragraphs (enough to squeeze 10 more lines), and that LaTeX probably added it so that in the beginning of the next page a new numbered section will begin at the top of the page.
I know there's a way to adjust this so LaTeX doesn't try so hard, but I'm not sure how. any help? Thanks!
The parameter that controls inter-paragraph spacing is called \parskip(See Paragraph Spacing ). You set it (with "rubber" values) using something like:
\setlength{\parskip}{1cm plus4mm minus3mm}
The defualt value of \parskip is class dependent. The "plus" and "minus" parts tell TeX how much it can adjust the value to improve the layout (that is they make the spacing elastic, thus the "rubber" designation). Reducing (or eliminating) the "plus" part of the rubber might help.
Watch out though, you can cause other layout artifacts if you constrain TeX too much.
Other things to think about:
The widow and club penalties probably apply section headings, and may be affecting TeX's layout choices (see https://stackoverflow.com/questions/512967/how-can-one-keep-a-section-from-being-at-the-end-of-a-page-in-latex for a discussion).
You may also want to consider messing with \baselineskip which controls the allowed spacing between lines of text and can also have rubber values.
This is a common problem, and there are probably some fairly sophisticated treatments already prepared on CTAN.
\vfill before the new section worked perfectly for me.