https://bugs.documentfoundation.org/show_bug.cgi?id=46028
Zenaan Harkness <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
See Also| |https://bugs.documentfounda
| |tion.org/show_bug.cgi?id=44
| |597,
| |https://bugs.documentfounda
| |tion.org/show_bug.cgi?id=10
| |1765,
| |https://bugs.documentfounda
| |tion.org/show_bug.cgi?id=89
| |082,
| |https://bugs.documentfounda
| |tion.org/show_bug.cgi?id=62
| |603,
| |https://bugs.documentfounda
| |tion.org/show_bug.cgi?id=62
| |071
--- Comment #6 from Zenaan Harkness <[email protected]> ---
I call this 'subroutineing' - styles are appropriate for placement, and other
properties such as font, size, anchoring (possibly), but not for content,
although list styles do specify certain content for example.
Arguably, styles could support content to provide this subroutineing
capability. I can easily imagine a "Footer" style which is both a paragraph
style, but also contains the footer text. Come to think of it, footer text is
evidently
"somehow attached"
in Page styles, but Page styles modify dialog box does not provide for direct
editing of this content - the WYSIWYG "View -> Normal" view is more than able
for such editing, and quite arguably the correct place for such editing.
There is a real argument however, to make these
style <--> content
connections more "visible" in the UI, both to increase contextual awareness for
the end users (that's us :) as well as to promote consideration and thinking
about UI and UX flows.
For example: Page style (or other styles?), when Footer or Header is enabled,
--really should-- :
a) display a mini preview of the current footer for that Page style, and
b) provide a CLEARLY VISIBLE note, to tell the user where to go to actually
create content which will thereafter display as that preview
Since page styles have attached content (header and footer - and these should
have previews), and list styles have embedded content (and sort of have
previews), LO SHOULD have frame styles which include embedded content, and
provide a preview, to solve the OPs problem.
Yes, this would be a very nice feature - and the if there is no dissent, and a
developer can say "yes, that makes sense" then the subject title of this bug
could be updated to, e.g.:
[RFE, FORMATTING, UX, UI] Allow frame styles with attached content, and
properties dialog preview
ALSO, in MSWord (since at least WordXP), para styles may have an attached frame
style: What this means is that for marginalia of any sort (special character,
image, text etc), one can simply insert it as a paragraph, then double click on
the pre-designed paragraph style, and voila, that para is perfectly placed as a
marginalia to the subsequent para. Another feature I guess..
Might also need a search and replace option to -avoid- frames content (not sure
if this currently applies), or to avoid frames which contain default content
(like footer) - these UX and UI details really need to be handled well, e.g.
see bug #62603.
Similarly, bugs like bug #62071 must be carefully considered in relation to the
above proposed enhancements.
Next question: should we create a series of "enhancement request" bugs to
detail these enhancements (I don't mind doing that if it's "the right" thing to
do), or just keep this current bug alive for these various enhancement
requests? I would appreciate someone knowledgeable chiming in on this one;
thanks heaps.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
