Bug 162738 - Revert Changes to "File Properties / Description box
Summary: Revert Changes to "File Properties / Description box
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.8.0.3 release
Hardware: All All
: medium normal
Assignee: Heiko Tietze
URL:
Whiteboard: target:25.2.0
Keywords:
Depends on:
Blocks: File-Properties
  Show dependency treegraph
 
Reported: 2024-09-01 16:36 UTC by larrybradley
Modified: 2024-09-05 05:38 UTC (History)
3 users (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 larrybradley 2024-09-01 16:36:46 UTC
Description:
For some reason the formatting and content of File Properties / Description were changed. It's ugly, clumsy, and less useful. Adding 8 Fields (Contributor, Coverage,...Type) to a drop-down box removes the user's ability to describe more than one piece of data, such as Publisher. I almost always use more than one of the fields in the drop-down, but now I cannot. What was the rationale? I mean, the new dialog box takes up the same amount of real estate as the old box, but now it is much less useful.

Steps to Reproduce:
1.Click on File, Properties, Description.
2.Click on drop-down box.
3.Select one of the items in the drop-down box. 

Actual Results:
A drop-down box that contains eight field names is available, which results in the ability to use only one of the field names. 

Expected Results:
The user should be presented (as previously) the opportunity to enter data into all available fields individually, not just the ability to enter data into a single field chosen from among the 8 field names in the drop-down box.


Reproducible: Always


User Profile Reset: No

Additional Info:
Prior to the drop-down box, each field was presented as a separate choice. I could enter data into all 8 fields, or a combination thereof. Now the user is limited to entering data into only the field selected, with no place to add data for the other seven fields, which renders the Description box far less useful than previously.
Comment 1 Mike Kaganski 2024-09-01 17:50:47 UTC
You can still set any - or all - of the listed elements. It's just an awful idea that you select the item, then fill its value, then select next item, then fill the next value. The same as in Options->Load/Save->General, where "Document type" is chosen first, then "Always save as" is selected for the chosen document type.
Comment 2 V Stuart Foote 2024-09-02 02:07:19 UTC
This was commit https://gerrit.libreoffice.org/c/core/+/168139 in place for a 24.8.0 release.

This particular tab of the Properties dialog holding DC and other meta attributes was not responding to os/DE proportional scaling--so the listbox was used to consolidate the attributes for selection.

A different approach (to a list box selector) for presenting the meta attributes is needed, while the framework composing the dialog tab needs to be made responsive to os/DE scaling.
Comment 3 Heiko Tietze 2024-09-02 09:09:00 UTC
(In reply to larrybradley from comment #0)
> What was the rationale?
The request from bug 138792 led to an oversized dialog, reported in bug 160937 and solved with the dropdown. Feel free to make a suggestion for improvements.
Comment 4 Mike Kaganski 2024-09-02 12:27:34 UTC
(In reply to Heiko Tietze from comment #3)
> Feel free to make a suggestion for improvements.

A good option is a scrollable list control, identical to the Custom Properties tab, for all the properties except the multiline comments. Title, Subject, Keywords, Contributor, etc. in the single pre-filled list (of course, unlike the Custom Properties tab, here we don't need the "Type" column). It allows to clearly show the list to the user, and not create a wrong impression that the current solution does. It creates consistency (the two tabs - Description and Custom Properties - look and feel in a similar way, and so the user doesn't need to accommodate to the two different tabs). And it is a familiar paradigm, used everywhere - in LO, and in all other applications and operating systems, unlike this our unique invention implemented currently.
Comment 5 V Stuart Foote 2024-09-02 12:40:12 UTC
(In reply to Mike Kaganski from comment #4)

> A good option is a scrollable list control, identical to the Custom
> Properties tab...

+1
Comment 6 Heiko Tietze 2024-09-02 12:57:14 UTC
More opinions please.
Comment 7 larrybradley 2024-09-02 16:48:58 UTC
(In reply to Mike Kaganski from comment #1)
> You can still set any - or all - of the listed elements. It's just an awful
> idea that you select the item, then fill its value, then select next item,
> then fill the next value. The same as in Options->Load/Save->General, where
> "Document type" is chosen first, then "Always save as" is selected for the
> chosen document type.

Thanks for pointing out this method, but honestly, that just makes the problem even more hideously inconvenient and unproductive. One step you did not mention: It's not as simple as selecting an item, setting its value, then selecting the next item. The actual sequence is : select an item, enter the value, CLICK OK, WHICH THEN RETURNS YOU TO YOUR DOCUMENT WHERE YOU MUST AGAIN SELECT FILE \ PROPERTIES\DESCRIPTION before you can select the next item and enter its value. in short, if you want to enter three values for three properties, you must open File\Properties\Description three times.  

As of the other comments in this thread suggesting new or better ways to correct this mess, I'm not sure why anyone would want to do anything other than say "we screwed up and should have left well-enough alone." 

Finally, and there is nothing that can be done about this at this point, I'm sure, this change wiped out every property I had set in every one of my documents, where that property was one of the items in the new drop-down, wiping out hours and hours or work over the past several years.
Comment 8 Mike Kaganski 2024-09-02 17:47:55 UTC
(In reply to larrybradley from comment #7)
> As of the other comments in this thread suggesting new or better ways to
> correct this mess, I'm not sure why anyone would want to do anything other
> than say "we screwed up and should have left well-enough alone." 

I'm unsure if you have noticed, that the previous state caused problems, and was changed for a purpose, so it wasn't "well-enough". That the solution was itself not ideal is another (this) story, but reverting to the old state is not acceptable, too.
Comment 9 V Stuart Foote 2024-09-02 18:26:43 UTC
Would point out that bug 160937 did not affect all VCL backends, and that majority of users were unaffected by the errant dialog scaling.
Comment 10 larrybradley 2024-09-02 18:55:52 UTC
(In reply to Mike Kaganski from comment #8)
> (In reply to larrybradley from comment #7)
> > As of the other comments in this thread suggesting new or better ways to
> > correct this mess, I'm not sure why anyone would want to do anything other
> > than say "we screwed up and should have left well-enough alone." 
> 
> I'm unsure if you have noticed, that the previous state caused problems, and
> was changed for a purpose, so it wasn't "well-enough". That the solution was
> itself not ideal is another (this) story, but reverting to the old state is
> not acceptable, too.

What problems did the previous state cause? I have been a power user of LO since its inception. and never experienced a problem with the previous state. I will take your word for it, but would really like to know what brought about the changes. Thanks.
Comment 11 larrybradley 2024-09-02 18:58:14 UTC
(In reply to V Stuart Foote from comment #9)
> Would point out that bug 160937 did not affect all VCL backends, and that
> majority of users were unaffected by the errant dialog scaling.

If you are talking about the scaling of the dialog boxes, it seems to be a problem only with Linux, not with Windows.
Comment 12 QA Administrators 2024-09-03 03:14:57 UTC Comment hidden (obsolete)
Comment 13 Mike Kaganski 2024-09-03 04:03:11 UTC
(In reply to larrybradley from comment #11)
> (In reply to V Stuart Foote from comment #9)

> If you are talking about the scaling of the dialog boxes, it seems to be a
> problem only with Linux, not with Windows.

This is the same for any bug: only some part of users experience it, yet we fix it for all.
Comment 14 Cor Nouws 2024-09-04 09:18:02 UTC
(In reply to larrybradley from comment #7)
> ...
> then selecting the next item. The actual sequence is : select an item, enter
> the value, CLICK OK, WHICH THEN RETURNS YOU TO YOUR DOCUMENT WHERE YOU MUST
> AGAIN SELECT FILE \ PROPERTIES\DESCRIPTION before you can select the next
> item and enter its value. in short, if you want to enter three values for
> three properties, you must open File\Properties\Description three times.  
I can simply 
- select an item
- tab, add a value
- shift-tab back to the dropdown
- select another
- tab, add a value
etc.
Alt-O saves & closes
Comment 15 Cor Nouws 2024-09-04 09:24:33 UTC
(In reply to V Stuart Foote from comment #5)
> (In reply to Mike Kaganski from comment #4)
> 
> > A good option is a scrollable list control, identical to the Custom
> > Properties tab...
> 
> +1
Wouldn't it make sense to keep some 'always' used props apart?
If so, then maybe metadata of EPUB files give a good direction: Identifier; Title, Author; Language; Date
Comment 16 Cor Nouws 2024-09-04 09:26:21 UTC
(In reply to Cor Nouws from comment #15)
> (In reply to V Stuart Foote from comment #5)
> > (In reply to Mike Kaganski from comment #4)
> > 
> > > A good option is a scrollable list control, identical to the Custom
> > > Properties tab...
> > 
> > +1
> Wouldn't it make sense to keep some 'always' used props apart?
> If so, then maybe metadata of EPUB files give a good direction: Identifier;
> Title, Author; Language; Date
Oh, a *scrollable list control*, not all in a *list*..
Then forget my suggestion and read 
+1
Comment 17 Commit Notification 2024-09-05 05:38:10 UTC
Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/3631c6ffcb2f27090cfc1b1c9dd492451d3d485c

Resolves tdf#162738 - Revert tdf#160937

It will be available in 25.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.