Hello Christoph,
----- Mail original -----
De: "Christoph Noack" <christoph@dogmatux.com>
unbelievable ... at least for me: after several weeks I've finally
managed to have a running libo-daily :-) So let's get back to work
and
have a look on your fine changes.
Cool!
Am Donnerstag, den 18.08.2011, 14:42 +0200 schrieb Cedric Bosdonnat:
On Wed, 2011-07-06 at 09:52 +0200, Cedric Bosdonnat wrote:
I just moved the color definition to the options in the master
branch:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=d40dce0f0f00b88dd645a0f334e3d7b2d6af6515
I also changed the way the colors are defined: you define the main
color
(the one of the line) and the background color is that color with
the
luminance multiplied by 2.5. I tested with several colors and it
looks
quite nice in those cases too.
I hope this helps to make it a nice feature,
Thanks! At the moment, I'm thinking about how to make use of that -
we
have several hard-coded elements that would benefit if we could share
those color(s).
What are you thinking about? Those colors are already shared in the options... or there is
something I don't understand
So, what was the real intention of the feature - please bear with me
if
I didn't get it so far. Here some proposals to choose from (or to add
one):
1. It should be avoided that people accidentally enter the
header/footer and "destroy" the given content / formatting
(on
several pages at once).
2. It should be avoided that people are distracted from headers
/
footers when writing on the document content. Thus, the
remaining elements get grayed out when not working on them.
3. It should be avoided that people don't know what kind of
header/footer they are editing.
4. 1 ... 3 at once
First it was #1, but then the user/customer requested the separator thing... so I guess they were
way too used to that thing. I wasn't really found of that UI thing... but you know how customers
are ;)
The original problem was that we had tons of .DOC documents with an enormous picture anchored as
background in the header to live with. In a lot of cases, clicking in the document body picked the
picture instead of picking some paragraphs... that's why I needed to avoid the user to mistakenly
click on the picture from the header / footer.
So, given all the alternatives, the current implementation misses
some
bits and pieces. From my POV, #1 could be solved differently, #2
de-WYSIWYGs Writer, #3 could be solved differently. Personally, I
really
need to know what was the original requirement ...
I agree with the de-WYSIWYG-ation of Writer, do you have an idea to show that more clearly? I have
to admit that I had to hack the painting quite intensively to get it working in almost all cases...
and I'm not too proud how some bits in that area.
I'm ready to make it better, though I spent quite a lot of time and energy to make it working
almost nicely and would be quite disappointed if I had to throw it all away.
Some of the things I've noticed:
* Enter: It is hard to identify how to enter the header /
footer -
the given visualization (borders) highlight active text areas
that can be entered via one click. But these areas are
inactive ... unless the user double-clicks (which is not
visualized to the user).
Is there anything we could do to make it easier to identify?
* Abort: It is hard to identify how / and cumbersome to go back
to
the document content. In contrast to MSO, there is no
visualization / hint how to do that. Examples:
* Double-click is unusual (in LibO) and there is no
visual
clue
What kind of clue / mechanism would be more natural to users then?
* Although single-click doesn't work to go back to the
document content, right-clicking once works - why?
Doh! that's a bug / something I missed in the implementation.
* ESC in header/footer goes back to the last position
in
the document, but: if the user moved to another page
in
the meantime, it jumps to the old location
Where should it go to in those cases? Should it be moved to the beginning of the current page in
all cases?
* Usability issues:
* I've noticed (as Cor pointed out) some issues, e.g.
it
doesn't work well with Notes. For example:
* Edit the header content
* You can change into an existing note with
single
click (is that different to the document
content?)
* For exit, press ESC - the cursor is moved
back
to the document, but the content is shown
inactive (although I can edit it) --> users
get
lost
* It also doesn't work well if headers/footers are
removed
when editing them ... all the highlighting stays (the
banner and the grayed out document). --> users get
lost
Ok, those are clearly bugs and I need to fix them.
* I think the "Edit - Headers&Footers" behavior is a
bit
strange. Its deactivated, if there is no
header/footer
on the page. But, its activated if either header or
footer is there. Then, the missing item gets
highlighted
anyway ... without providing a clue how to really add
this missing element. --> could be more supporting
An option here is to enable that menu item in all cases. If triggered when there is no
header/footer in the document, then it would add them to the current page style. How does it sound?
* Technical issues: In my test environment (Fedora 15,
VirtualBox), I regularly have ghost cursors showing up - if
you
change the mode when the blinking cursor is shown, it doesn't
get removed (e.g. entering the header from the document, the
document keeps a non-blinking cursor).
Could it come from the fact it's in a virtual machine? I had that fixed a while ago... but I may
have missed something.
* I'm still thinking how it should work in "facing pages" mode
...
--> the common elements are usually mirrored in such
situations
Ouch... I haven't though about that case! There may be some tricky cases there.
* The feature could (as already pointed out) be more helpful if
we
actively show options like "exit, add header/footer, remove
header/footer", ...
Sure! Where would they be best to be placed? In some menu, a toolbar or somewhere else?
Argh, just to mention that, beginning on Thursday, we'll have our
family
vacation until the Hackfest ... and there won't be any Internet
connection, as far as I know.
Hackfest will be a good time to brainstorm lively on that :D
--
Cedric
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.