https://bugs.freedesktop.org/show_bug.cgi?id=43910
--- Comment #2 from Kurt <[email protected]> 2011-12-29 09:50:54 PST --- Created attachment 54949 --> https://bugs.freedesktop.org/attachment.cgi?id=54949 Screenshot illustrating two examples of the usefullness of stacking controls Is the request for information in order to assign an importance/priority to the bug? I ask because the question sounds like what is being debated is whether or not the feature should be part of LO in the first place. Anyways, here is the case for working control stacking: Background: Screen real estate for forms that have complex information can be very much at a premium. This is especially the case if the form has aesthetics as a design consideration, where visual elements take up some of that valuable real estate. In many cases, squeezing controls closely together can be a challenge if stacking order is not honoured. In other cases, adding in aesthetic elements can be impossible without correct stacking order. Attached to this comment is a screen shot of a Pathfinder RPG spell database form that illustrates two instances of where failed stacking order impedes a form's design goals: Situation 1, Label field impinging on data field borders It is difficult at times to get the text of a label field as close as one would like to the data field it is labelling without the border of the label field impinging on the data field. You will notice in the area labelled "Situation 1" that the label is overlapping the top of the text box. Even using the vertical alignment setting in a label doesn't always help, depending on the font selected. Fonts with deep descenders (like the underlined label on the scroll) cause more of a problem and I ended up not being able to use the font I wanted because I could not effectively set the stacking order so that the text boxes were and stayed on top. Which makes for very ugly looking text boxes when their borders are overwritten by labels. Situation 2, Cannot put visual elements on top of controls, even when the visual elements are themselves a control. In order to save some space labelling, and to make it (in my opinion) visually more appealing, I decided to label some of the text boxes with partially transparent labels. I quickly noticed that it is absolutely impossible for the stacking order of any non-control element to make it appear over top of a control. This, I believe, is a design issue and will be addressed by a feature request. However, since using normal Draw-style text boxes for this was out of the question, I switched to an image control. I created my partially transparent image with no problem, but even with an image control I still could not get the image to reliably stay on top. It is displayed on top in the attached screen shot, but will disappear underneath if any one of dozens of cases. There are two detailed situations. In reality, though, there are a myriad of cases where stacking order is important for form element. Whether it's something as simple as reducing the time it takes to develop by not needing to bother to be picky about where label, checkbox, radio button, etc borders end (a separate issue from not being able to get labels as close as one would like to other elements), to using stacking order as a method of dynamic control selection, to overlaying buttons or controls over unused areas of other controls to save space. It's an important feature and I cannot think of any other form design software that omits it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
