Bug 83373 - UI: LibreOffice dialogs become too wide when long path+name is pasted in field 'File name' to open the file
Summary: UI: LibreOffice dialogs become too wide when long path+name is pasted in fiel...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
4.4.0.0.alpha0+ Master
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard: target:5.1.0 target:5.0.3
Keywords: bibisected, bisected, regression
Depends on:
Blocks: LO-File-Dialog
  Show dependency treegraph
 
Reported: 2014-09-01 20:27 UTC by Cor Nouws
Modified: 2017-10-18 19:45 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Dialogs 4.1.3.2 release vs. 4.4 (113.75 KB, image/png)
2014-09-03 07:48 UTC, Joel Madero
Details
Screenshots in Daily and 431 (156.03 KB, image/png)
2014-09-03 11:56 UTC, Cor Nouws
Details
photo of the dialog (73.28 KB, image/jpeg)
2015-02-25 21:43 UTC, Cor Nouws
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cor Nouws 2014-09-01 20:27:02 UTC
Set to use LibreOffice dialogs via Tools > Options > General

File Open
Dialog is too wide IMO around 1200 pxl
(and not so high)

Was better in 4.3.x
Comment 1 Joel Madero 2014-09-03 07:48:32 UTC
Attached is what I see. Left is 4.4 built a couple days ago, right is 4.3.1.2 release. Looks like 4.4 is actually taller but same width? You seeing something different Cor?
Comment 2 Joel Madero 2014-09-03 07:48:50 UTC
Created attachment 105666 [details]
Dialogs 4.1.3.2 release vs. 4.4
Comment 3 Cor Nouws 2014-09-03 11:56:17 UTC
Created attachment 105677 [details]
Screenshots in Daily and 431

Hi Joel,
See my screenshots attached
Comment 4 Cor Nouws 2014-09-12 14:21:49 UTC
Hi!

Checked in daily from 20140902.

With a clean user profile, or a clean usermodifications.xcu, it works fine (now).
(looks as if I caused an error with copying profiles around. Not sure. But apologies nevertheless.)

Kind regards,
Cor
Comment 5 Cor Nouws 2014-09-12 14:29:38 UTC
Ah, found the problem :)

I often open a file by copying full name (path + name) from the file manager to the field "File name" in the dialog "Open".
And then hit Enter.
Now if that full name is long.. the next time I do Ctrl+O the dialog ís very wide.
Comment 6 Joel Madero 2014-11-04 03:53:58 UTC
Moving back to UNCONFIRMED so someone can confirm with new instructions.
Comment 7 Cor Nouws 2014-11-04 09:07:30 UTC
Joel, I've been doing QA from back in 2004 or so.
The summary of this bug already explains how to reproduce.
(I would love to see more attention for that key information, rather then some ... :( )
Comment 8 Joel Madero 2014-11-04 15:14:18 UTC
@Cor - bugs should still be confirmed by a third party independent triager (I never confirm my own bugs) - anyways, it was set to REOPENED which was wrong status regardless, NEW is more appropriate.
Comment 9 Cor Nouws 2014-11-04 15:48:13 UTC
(In reply to Joel Madero from comment #8)
> @Cor - bugs should still be confirmed by a third party independent triager
> (I never confirm my own bugs) - anyways, it was set to REOPENED which was
> wrong status regardless, NEW is more appropriate.

If I take freedom to set my own bugs to new, I'm confident.
Maybe some additional testing reveals that it's e.g. related to CPU (32 bits) but then that will be clear.
Comment 10 Cor Nouws 2015-01-05 19:35:07 UTC
Hi,

Why is this minor? It looks ugly, and there is no means to bring back a normal size, unless I dump my config.. (or hack it ;) )
Comment 11 Adolfo Jayme 2015-01-06 13:59:49 UTC
Cor, why does that matter? I’m planning to do tweaks to reduce its size, please give me a few days.
Comment 12 Matthew Francis 2015-02-13 11:05:08 UTC
For reference it looks like it was this UI conversion that changed the behaviour

commit f90eb33a268bdcd1c52aea5670a58267b0907096
Author: Szymon Kłos <eszkadev@gmail.com>
Date:   Sat Jun 28 16:10:39 2014 +0200

    DLG_FPICKER_EXPLORERFILE conversion to .ui
    
    Change-Id: I5d8f5d0182fb6af5111b60caa29912d313c2efa0
Comment 13 Cor Nouws 2015-02-25 21:43:48 UTC
Created attachment 113689 [details]
photo of the dialog

dialog widens to flow over two screens..
Comment 14 romain 2015-08-20 19:29:28 UTC
== For the context ==
I prefer put my comment in this Bug (because of a bigger history) than in mine (https://bugs.documentfoundation.org/show_bug.cgi?id=92867) which actually seems to be a duplicate. (I would agree if you do it but don't do it myself, because I do not know the architecture of the software).

== Remark ==
What I understand from outside is, that it seems there is something like a window template/container whose width is given by the templatedWindow/content.
_
Fine: let's avoid developing twice the same thing


Some of the windows are defining there opening width dynamically (in this bug, using the previous inputed string / in my bug, using the max string size of all elements of the selected column)
_
Fine: let's give some freedom to the customisation

_
What is here missing are some borders into the template/container


_____
As a regular SW tester I see the possible problems which could come from this fix and want to give them here, in the form of specifications (based on what I would expect) - please consider, I am ONE (not all the other users) and my perception is perhaps false or GNOME oriented (I don't know -and care- about the other UIs):

I will use:
- size to avoid writing twice for width and height
- template for the container or the template (I don't know how it works)
- final window for the customized window based on the template or into the container


1/ The wished size must be defined by the final window

2/ The application adequate size must be the limitation to the application width of the wished size(computed at the template level)

3/ The probable size must be the limitation to a minimum readable size (given by the final window)

4/ The size is a limitation of the probable size to the desktop (or current screen?) size at the template level


==> the check 3 will make me happy because I often split vertically a screen with 2 applications and I don't want to have really unreadable windows because of that 
==> the check 4 is just because I am a fan of "belt and suspenders" solutions and as library provider never trust my users :D
Comment 15 romain 2015-08-20 19:38:41 UTC
For the record, if my bug is closed, please consider: earlier version affected for this bug should be changed to 4.2.8.2 (maybe it helps for the investigation)
Comment 16 Maxim Monastirsky 2015-08-20 19:51:57 UTC
(In reply to romain from comment #14)
> mine (https://bugs.documentfoundation.org/show_bug.cgi?id=92867) which
> actually seems to be a duplicate.
That's not a duplicate for sure, just a similar bug.
Comment 17 romain 2015-08-20 19:56:20 UTC
I agree but I am sure that if all the discussion is grouped into one bug, it would have more weight to choose to resolve it.

(then I will come back with my Bug and say: can you please fix it here also? :D)
Comment 18 Cor Nouws 2015-09-27 10:44:01 UTC
Set this to fixed with commit https://gerrit.libreoffice.org/#/c/18844/1 from Caolan. For which thanks!
Comment 20 Cor Nouws 2015-10-06 12:06:41 UTC
*** Bug 94808 has been marked as a duplicate of this bug. ***
Comment 21 Robinson Tryon (qubit) 2015-12-17 08:34:52 UTC Comment hidden (obsolete)