View Issue Details

IDProjectCategoryView StatusLast Update
0006044ScribusProperties Palettepublic2024-12-08 11:41
Reporteralexandre Assigned Tonitramr  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.3.5svn 
Target Version1.5.4Fixed in Version1.7.0.svn 
Summary0006044: Properties Palette could use far less screen estate
DescriptionCurrently Properties Palette takes a lot of screen space, much more that it really should and could. Attached are several mockups to show how users life could be made easier ;-)
Tagsindigodock
Patch

Relationships

related to 0010409 assignedale [PATCH] Improve access to contour editing 
related to 0017180 assignednitramr Indigo UI: Properties Palette Redesign 
child of 0002464 acknowledged Metabug: GUI appearance 

Activities

2007-07-28 21:22

 

text-tab.png (40,570 bytes)   
text-tab.png (40,570 bytes)   

jegHegy

2007-07-29 12:44

reporter   ~0016898

I don't know, I can resize it here so it's only as wide as the widgets need. (1.3.4 win32)

gpittman

2007-07-29 13:37

developer   ~0016900

What I see as a way of saving space is to do away with the vertically-arranged tabs, making them horizontal, something like the tabs in browsers. In essence, wherever there is blank space there is wasted space.

I'll try to generate a prototype to see how feasible it is.

2007-07-29 14:12

 

properties_horiztabs.png (20,512 bytes)   
properties_horiztabs.png (20,512 bytes)   

gpittman

2007-07-29 14:16

developer   ~0016901

here is an altered Properties palette (properties_horiztabs.png) that shows that laying out the categories tabs horizontally saves quite a bit of vertical space. I had thought that some tabs might need much more vertical space than others, but it's not actually true.

louisdesjardins

2007-07-29 14:50

developer   ~0016902

Nice job.

alexandre

2007-07-29 20:08

developer   ~0016904

Gregory, I'm sorry but I'm not fan of this approach. While I'm talking about width of the palette and trying to reduce it, you make it even wider :)

gpittman

2007-07-29 23:53

developer   ~0016910

Actually, I didn't make it any wider than it was by default when I opened it. It may look wider since it's not as tall, and at any rate, you can widen or narrow as you like.
One problem as I look at the different tabs is that it's going to be hard to fit everything in where the Text tab is concerned if you tried to reduce width.
With other tabs there is room to narrow.

gpittman

2007-07-29 23:57

developer   ~0016911

Something they were talking about at LGM2 (in Gimp, I think) was making requester boxes semi-transparent to reduce the sense of taking up too much space.

louisdesjardins

2007-07-30 13:16

developer   ~0016912

The PP tab presentation needs work. What is wrong in its actual form is they are a moving target, they depend on what's selected and they move up and down while they should remain still, keeping their place. This is an issue we have to solve. This slows downs productivity.

The suggested layout by Greg has at least the benefit of solving this part of the problem. The drawback will be that in some languages the name of the tabs can be quite long. We could then think of a way of implementing this with icons (we could use the ones that already exists for tools, for instance) and then let the users the choice of what they want to be displayed: words or icons. Icons, by the way, could be letters as well, such as XYZ.

At the same time, trimming the right-side of the palette as shown in the text-tab.png image cannot do much wrong!

gpittman

2007-07-30 13:36

developer   ~0016913

The problem with text-tab.png is that it's a misrepresentation of reality. Mine doesn't look like that. Once you shrink or stretch the palette window, it stays that way till you change it again -- so change it back.
I find that I need different widths/lengths in different computers, depending on display resolution. You can reduce the necessary size to some extent by reducing the size of fonts in palettes in Document Setup.

louisdesjardins

2007-07-30 13:40

developer   ~0016914

Right.

alexandre

2007-07-30 14:46

developer   ~0016915

Gregory, this is _not_ a misinterpretation of reality. Please take a closer look at actual changes before you judge:

1) Length of colors comboboxes is shrinked and shading combobox is thus moved to the left -- take a look at actual text tab and you'll see that those two rows are _unreasonably_ long, longest is the whole tab and, from what I see, in the whole palette.

2) Paragraph/Symbol Style labels are substituted with icons to a) shrink used space and b) match visual style of the whole tab.

3) Tracking/Glyph Extension options are placed closer to each other for same reason -- to shrink horizontal space in use.

Which one of the above falls under "misinterpretation of the reality", I wonder? :)))

FYI, font size for palettes is already set to 7pt. How much smaller does it have to be to your mind? :)

And I'm not fan of the transparent palettes idea either. Let me tell you why :)

The reason I'm constructively bitch^Hcomplaining about size of palette is not because I don't see things that are closed by current palette, but mostly because I can't _reach_ them. Seing is not reaching.

The current PP in 1.3.5 takes 0000008:0000001/4 of my 1280x800 home lapiop's display and 1/3 of my 1024x768 display at work. This is plain crazy. No other DTP software I know is same display space hungry. Shouldn't be a problem for those with 21" displays, of course, if you want all of your users to buy such displays.

The approach I'm suggesting shrinks width of PP from ~340px to 235px which adequates to 0000008:0000001/6 of my laptop's display and 0000008:0000001/4 of my work's display. Big difference.

Now, let's take a look at the XYZ tab you suggested.

Is there any good reason to keep each option in a separate row? If you make it look like

X-Pos: [ ] Width: [ ] |_
Y-Pos: [ ] Height: [ ] |
Rotation: [ ]

you more or less keep same width but save height of the group to 2/5. Big difference, again. This applies to other tabs as well.

I agree with Louis that icons might help, but this will become a matter of amount of efforts put to create a temporary solition, since, if I undesrtood Craig (MrB) correctly, Inkscape-like context sensitive toolbars are planned for the future.

See, providing further mockups is not a problem for me, but I want to make sure that my intentions are clear to you (and not taken as misinterpretation or something). Otherwise raising the issue makes no sense ;-)

gpittman

2007-07-30 15:21

developer   ~0016916

Well, here is my reality: I'm looking at the Properties palette for 1.3.4, in which case the necessary width is determined by the little broom icons to the right of the Paragraph and Character Style rows, and these little icons only extend about half their width beyond the above row of special character icons (ending with reverse character).
The entire width of the line and fill color + shading buttons is less than the width of the above spinboxes.

So, if anything, there may be a display bug in some versions. The space saved with icons for the Styles and Optical Margins buttons is offset by the uncertainty about what those icons mean. One might do as well or better to shorten 'Paragraph Style' to 'Paragraph', 'Character Style' to 'Character' and 'Optical Margins' to 'Optical' then rely on tooltips for clarification.

My example was only a crude mockup of switching from vertically-oriented tabs to horizontal, since if anything, my problem on some displays is the overall height of the Properties palette more than its width.

louisdesjardins

2007-07-30 16:08

developer   ~0016917

I understand there must be a display bug that can be related to all sorts of external parameters.

When I talk about icons, it's for tab naming and to avoid word length issue in some localisation if we settle on Greg's idea. As an example we could use for each of the 7 tabs the following icons:

XYZ = no icon, just YXZ
Shape = [sorry, I have no brilliant idea for this one!]
Group = [could be an icon of 2 frames bound together?! Plus I wonder why does this tab exist as it duplicates part of other tabs]
Text = The Text frame icon from the Tools
Image = The Image frame icoon from the Tools
Line = The Line icon from the Tools
Colors = The square with 4 colors we use in the color dialog

While we are at PP look and feel, I think the way tabs work now is hard to justify.

alexandre

2007-09-27 13:59

developer   ~0017408

@gpittman, so, in fact, we need to take care of both vertical and horizonta; screen space used. I agree here with you.

What do you think abiout GIMP-like approach with icons, tabs + Inkscape-like docking (as of Inkscape/SVN, see http://farm2.static.flickr.com/1437/1425078889_682ba191ed_o.png for example)?

In the mean time attached is layout fix proposal for another "tab" in 1.3.5.

2007-09-27 13:59

 

shape-tab-fix.png (43,376 bytes)   
shape-tab-fix.png (43,376 bytes)   

JLuc

2014-08-01 09:32

updater   ~0033122

Last edited: 2014-08-01 09:32

I like the proposed shape tab.
Also add an "edit contour" button as proposed in 0010409

Issue History

Date Modified Username Field Change
2007-07-28 21:22 alexandre New Issue
2007-07-28 21:22 alexandre File Added: text-tab.png
2007-07-29 12:44 jegHegy Note Added: 0016898
2007-07-29 13:37 gpittman Note Added: 0016900
2007-07-29 14:12 gpittman File Added: properties_horiztabs.png
2007-07-29 14:16 gpittman Note Added: 0016901
2007-07-29 14:50 louisdesjardins Note Added: 0016902
2007-07-29 20:08 alexandre Note Added: 0016904
2007-07-29 23:53 gpittman Note Added: 0016910
2007-07-29 23:57 gpittman Note Added: 0016911
2007-07-30 13:16 louisdesjardins Note Added: 0016912
2007-07-30 13:36 gpittman Note Added: 0016913
2007-07-30 13:40 louisdesjardins Note Added: 0016914
2007-07-30 14:46 alexandre Note Added: 0016915
2007-07-30 15:21 gpittman Note Added: 0016916
2007-07-30 16:08 louisdesjardins Note Added: 0016917
2007-09-27 13:59 alexandre Note Added: 0017408
2007-09-27 13:59 alexandre File Added: shape-tab-fix.png
2014-07-21 02:15 FirasH Status new => acknowledged
2014-07-30 22:26 Kunda Category User Interface => Properties Palette
2014-08-01 09:32 JLuc Note Added: 0033122
2014-08-01 09:32 JLuc Note Edited: 0033122
2014-08-01 09:33 JLuc Relationship added related to 0010409
2014-08-01 09:36 JLuc Relationship added child of 0002464
2016-04-26 01:01 Kunda Tag Attached: indigodock
2016-12-09 06:17 cbradney Target Version => 1.5.4
2024-03-23 22:31 nitramr Relationship added related to 0017180
2024-11-11 19:54 cbradney Assigned To => nitramr
2024-11-11 19:54 cbradney Status acknowledged => resolved
2024-11-11 19:54 cbradney Resolution open => fixed
2024-11-11 19:54 cbradney Fixed in Version => 1.7.0.svn
2024-12-08 11:41 cbradney Status resolved => closed