Bug Hunting Session
Bug 64970 - Styles & Formatting and Find & Replace UI/functional enhancements
Summary: Styles & Formatting and Find & Replace UI/functional enhancements
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-24 22:20 UTC by ghostwriter402
Modified: 2016-03-09 10:02 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ghostwriter402 2013-05-24 22:20:17 UTC
There are a number of barriers to use of Styles and Formatting, and these are some suggestions on how to overcome a few of these. While this is extensive, most of the code for all of these already exists. This is almost exclusively a UX problem.



Find?Replace irrespective of type: It would be useful to find text only within certain styles, or finding existing direct formatting and replacing them with a style. This should be doable through Find/Replace and/or the Styles and Formatting interface.

Blank Style: Allow an option to remove all rules from a style. Preferably allow removal of ANY rather than only all, but either would be useful.

Recreate Style: The option to recreate a style as if one had deleted it and created it again, but retaining all uses throughout a document and any style hierarchy.

Simplify Style: Appropriate to a number of contexts with slightly different meanings: In the styles manager, it makes sense to have this refer strictly to the inheritance chain of the style, removing any rules from this style that are also defined in the parent. In the main editing area, the option may or may not apply to direct formatting, but it would certainly apply to character styles overtop a paragraph and page style, and to a paragraph over a page, etc.. Some scheme for selecting the style intended would be required. The result is that the style definitions that have no effect are removed. 

Simplify Direct Formatting: Any rules defined by underlying style information are removed from the direct formatting, but any others are retained. 

View All Styles: Pull in any direct formatting rules into styles. (again, it already does this, so the coding should be easy) Any character modes applied to an entire paragraph probably ought to be pulled into a paragraph style. This is already done behind the scenes, anyhow, so simply make an option in UI to access them. (In that case, the visibility of the rules is one of the style view options, and the hidden styles are simply less hidden.)

View Applied Formatting: The direct formatting behind the scenes have names. Styles also have unique names. Provide some form of graphics that show where the beginning and end tags for each are placed in the document and allow direct manipulation of them. Deleting an end tag should be equivalent to deleting the beginning tag, but should probably not normally be possible in standard editing. (preferably somewhat differently for each type of tag) 

Find Duplicate Rules:  Hunt through the styles and check if a given pattern already exists. If so, add that to the list of duplicates. 

Replace Style: Instead of just using Find/Replace, (which should still work, mind) this would be part of the style manager. Obviously, it should simply allow one style to replace another. If written properly, it could accept a list of styles that are to be deleted in favor of another.

Condense Duplicate Styles: Searches for either a given style or runs through all styles and presents the user an option to pick the survivor. If the styles are all Direct Formatting Styles, it can just collapse them. If only one of a set is manually created, it automatically wins.
Comment 1 Cor Nouws 2013-05-25 18:33:29 UTC
Hi,
thanks for the issue. A nice avalance of ideas :)

Few requests:
- Could you pls be so kind to split this in various reports, which makes it easier to work on?
- And could you also pls to look at already existing issues around styles / the window Style and Formatting to include/group those too?

Remark: From my experience with end users (all types) I'm not yet convinced that e.g. showing 'styles' as 'Default + Arial 14 + Bold' and 'Heading 1 + TNR 9 + normal' would realy enhance oversight for users and would make it easier to work with styles.
- Thus I think it's wise to discuss one and another before starting implementation. 

I think this issue could be changed to a sort of container issue, pointing to the various issues for all the separate subjects.
But I doubt a bit, since it's a rather broad area. e.g. GUI, functionality, various modules, ... 
Some might need a clear discussion on UX list / analyses on wiki maybe?
- May I aks if you have an idea or even preference on this?

thanks a lot,
Cor
Comment 2 Cor Nouws 2013-05-25 18:35:40 UTC
set to the oldest LibreOffice version - all (with some small exceptions on handling of character styles and the function "Remove direct formatting") is here since the start.
Comment 3 ghostwriter402 2015-11-11 19:09:43 UTC
It bears noting, I suppose, that I DID raise all of these points with the UX team back when I thought of it and was still a member of the development channels. (2010-11) UX was only interested in discussing graphics. UX channel suggested, rather rudely, that changes to the styles interface dialog were a development issue. The main development team, of course, referred me back to UX. That environment was toxic, so I left.

I tried broaching the subject with the dev  team, again, a year or two later. (I really do think that these features would improve function( They suggested using the bug system for logging the ideas, which lead to this entry.

As the dates should imply: I've essentially washed my hands of the matter. This clearly isn't something that the developers care to address. At best, only some of the required groups care. Do not expect to see movement on this matter.

Workaround:
Use LO for the things it's good for---documents with mathematical equations and simple styles. Spring for a word processor if you're doing anything more complex than that.