Problem description: If you add a custom border to a style, it works correctly and you have have different sizes to each (i.e., top and bottom). However, if you go back in to re-edit them, the UI shows both as being the default of 0.05 pt even if you changed them. If you keep top and bottom at the same value, the UI reloads the modified value correctly. This may be a bigger problem with other settings as well, but I only noticed it with borders.
Steps to reproduce:
1. set an H1 style in Writer
2. modify the style to have a border top and bottom
3. change the thickness of them
4. save changes ("OK")
5. re-edit style
6. make the top and bottom border different
7. save changes ("OK")
8. re-edit style
4. style updates "correctly" (oh my...so many bugs in styles ATM).
5. borders width show up correctly allowing re-editing
7. different thickness borders show up "correctly"
8. border widths reset to 0.05pt instead of pulling up the custom values you set it to. There is no way to get those values back correctly via UI.
8. the customs widths you put in would be shown again for each item you set it with.
Platform (if different from the browser):
Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
oops, pushed wrong key, let me complete that...
this problem has nothing to do with styles but is a general
problem of the borders tabpage, which already existed in OOo:
if the border lines are different, then it will not display
the properties nicely; this is difficult to do anyway with
a single width/style/color control.
what could be done easily though is to update the width/style/color
control when the user selects an individual line, to display
the properties of that line.
the tab page already has 4 different padding(line spacing)
controls, it would be possible to do the same for
the lines but it needs up to 6 controls (when the dialog
is for a Table there are inner and outer lines),
and it is going to become very cluttered.
some input from UX would be nice, what is the best way
to go here?
AFAIR the dialog is implemented in these files:
While I can agree that it needs some work, I still think it is a bug rather than an enhancement. If I apply a special style that hits this issue, there is no way to edit it without recreating it. I can't imaging that was ever the "correct behavior" as intended.
*** Bug 39336 has been marked as a duplicate of this bug. ***
adding LibreOffice developer list as CC to unresolved EasyHacks for better visibility.
see e.g. http://nabble.documentfoundation.org/minutes-of-ESC-call-td4076214.html for details
Restricted my LibreOffice hacking area
Migrating Whiteboard tags to Keywords: ( EasyHack SkillCpp TopicUI)
Tested in LibO 3.3.0, so setting to inherited.
Also, a better description of the behaviour I would expect:
On click of a button styling (all 4 edges, sides, etc.), it would set those boarders on at the current settings for parameters.
On first click of an edge on the preview, it would load the current settings into the parameters. Once loaded, subsequent click on that edge would toggle the state.
Clicking on a different edge would restart the process.
JanI is default CC for Easy Hacks (Add Jan; remove LibreOffice Dev List from CC)
Please add keyword 'needsUXEval' and CC 'firstname.lastname@example.org' if input from UX is needed.