Issue 80244 - Testtool: Enhance Display HID dialog to become a three pane window
Summary: Testtool: Enhance Display HID dialog to become a three pane window
Status: CONFIRMED
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: current
Hardware: All All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-01 09:16 UTC by joerg.skottke
Modified: 2017-05-20 10:55 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
A freehand draft spec for the Display HID dialog to enhance userfriendlyness (789.37 KB, image/png)
2007-08-01 10:01 UTC, joerg.skottke
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description joerg.skottke 2007-08-01 09:16:37 UTC
Currently the Display HID output window has two panes - one for the controls and
one for the slots.

As the content of the controls window can be quite cluttered if some controls
are undeclared my suggestion is to introduce a third pane so declared and
undeclared controls can be displayed separately

Pane 1: Declared Controls
Pane 2: Undeclared controls
Pane 3: Slots
Comment 1 joerg.skottke 2007-08-01 09:17:35 UTC
set enhancement
Comment 2 joerg.skottke 2007-08-01 10:01:32 UTC
Created attachment 47239 [details]
A freehand draft spec for the Display HID dialog to enhance userfriendlyness
Comment 3 joerg.skottke 2007-08-01 10:02:39 UTC
Discussed another option with GH and added a fourth view option.
Comment 4 joerg.skottke 2007-08-01 10:08:42 UTC
So now we have a listbox with four options and two buttons at the top of the dialog.

The options for the listbox are:
1) Classic view (default)
2) Undeclared only
3) Declared only
4) Slots only

Usually i would suggest to make 2) the default if undeclared controls exist and
3) if all controls are declared, but this would change a known behavior and is
considered a little risky.

The classic view displays both controls and slots at the same time whereas the
other options only display one item.

The advantages are:
1) Undeclared controls can easier be copied by "Select All" as they are no
longer mixed with already declared ones
2) If somebody wants to just use an already declared dialog the invalid options
can be filtered out.
3) the slots are only rarely used, so they are moved out of sight leaving more
room for dialogs with a huge number of controls.
Comment 5 joerg.skottke 2007-08-01 10:12:19 UTC
Another advantage: The buttons can - with the new design - be enlarged that
there actually is room enough for strings like "Select all" (which is currently
cut off and reads nothing more than "lect a" on some displays ;-)
Comment 6 joerg.skottke 2007-08-01 10:21:26 UTC
Just as another idea:

One could remove the "Copy" button and change the "Select all" button to "Copy all".

With the listbox set to "Undeclared only" one would be forced to copy all items
in one go, encouraging to declare an entire dialog instead of just the one item
that is currently need (which probably few people do but those who do usually
cause some confusion). But this suggestion might go a little too far.
Comment 7 gregor.hartmann 2007-08-01 10:39:21 UTC
I would suggest to have the buttons at the bottom of the dialog as thats (or the
right side) is the usual position for buttons.

renaming the select all to copy all is ok but Id like to keep the copy button as
there are also people who want to copy only one (declared) item to use it in a
script.

I also would like to keep the slots there always. Its possible to change their
size if they are in the way.
Comment 8 joerg.skottke 2007-08-01 10:51:10 UTC
I agree on the point with the "Copy" button. 

Keeping the slots visible at all times is ok, though i'm not very fond of the
idea. I've never used the slots info in the five years in automation, so i
simply guess others haven't either.

To the location of the buttons i do not agree.
Reason: The listbox changes the appearance of the dialog. If a control changes
the appearance of a dialog this is always grouped in a way that the changing
content is below the control. Otherwise it would be hard to understand the
relation. 
Additionally if someone moves the dialog it might easily hide the buttons
outside the viewable area. Putting them close to the titlebar minimizes the risk
for this to happen. So i strongly vote for the upper border.
Putting them at the side is no good option at all, see my comment about the cut
off strings.
Comment 9 gregor.hartmann 2007-11-30 12:20:57 UTC
moved to 3.x
Comment 10 Marcus 2017-05-20 10:55:56 UTC
Reset assigne to the default "issues@openoffice.apache.org".