|
2007-07-28 21:22
|
text-tab.png (40,570 bytes) |
|
|
I don't know, I can resize it here so it's only as wide as the widgets need. (1.3.4 win32) |
|
|
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) |
|
|
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. |
|
|
Nice job. |
|
|
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 :) |
|
|
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. |
|
|
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. |
|
|
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! |
|
|
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. |
|
|
Right. |
|
|
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 ;-) |
|
|
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. |
|
|
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. |
|
|
@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) |
|
|
I like the proposed shape tab. Also add an "edit contour" button as proposed in 0010409 |
- Anonymous
