On 4 May 2004, Sven Neumann wrote: > Nathan Carl Summers <rock@xxxxxxxx> writes: > > > > PS: See http://sven.gimp.org/gimp-new-image-dialog.png for an almost > > > HIG compliant file-new dialog. This is a screenshot from the HEAD > > > branch. > > > > Looks fantastic! I really like the "hideaway" Image Comment section. > > > > Here are just a few minor suggestions that I think would improve the > > dialog: > > > > * The "extra title bar" seems to take up a lot more space than it needs. > > This dialog is a GimpTemplateEditor packed into a GimpViewableDialog. > It's GimpViewableDialog that creates the title and the extra space is > in other GimpViewableDialogs used to display the name of the viewable > (which could for example be an image or a layer). We could of course > change GimpViewableDialog to show a smaller title when no name is set > but I think consistency makes more sense here. Not sure though, what > do others think? It looks seems a little awkward the way it currently is here. There are probably several ways to make it look nicer. Maybe one of the graphic artists could give more productive suggestions. > > * Center "Create a New Image" vertically (perhaps horizontally as well) > > This also needs to be reviewed with respect to other dialogs using the > same viewable-dialog widget. See my comment above about graphic artists. > > * Put the size in bytes either flushed right to or directly under the > > "Image Size" label. Flushed right will probably look better. > > I am afraid the HIG disagrees with this. But perhaps it needs to be > seen on a mockup. I think the memory size is rather well placed, but > let's see how this would look like. My concern is that currently the image size is visually associated most closely with the portrait/landscape control. Perhaps the best solution is to have a "Memory Required" outdent at either the top or the bottom, and have the size after that. > > * Move the portrait/landscape controls to the right of the template > > dropdown. Grey them out when no template is selected. > > But they also make sense when no template is selected and allow you to > easily flip width and height. Why bind them to the template selection? I thought that they didn't work without templates, but it turns out that I just tested them on a square image. :) OK, they are useful for non-templated images, so instead, I suggest that we keep them where they are, and grey them out if the image is square. > > * Merge the two Width and Height entries, or make the second one > > hideaway. If you make the second one hideaway, make the top one have a > > dropdown units menu, so that you don't have to use the hideaway to > > specify image size in units other than pixel. > > * Consider making Resolution hideaway as well. > > * Resolution should have its own outdent, just like Image Size does. > > IMHO resolution and the second size group belong together. I could > imagine having "Pixel Size" at the top and "Print Size" below. The > "Print Size" group would contain size and resolution. This makes a whole lot of sense. Make "print size" and "print resolution" be one hideaway group. > > * The units dropdowns should be centered vertically between the two entry > > boxes to which they apply. (It would be better if they were aligned > > horizontally as well, but the presence of the link control in the > > resolution area makes that impractical.) > > /me shudders OK, so alignment isn't plausable, but the units still should be centered between the width (or x) and height (or y) entry boxes so that it is more clear that it applies to both of them. > > * Consider putting a GtkVSeparator between the "Image Type" and "Fill > > Type" combo box lists. > > The idea was to make the dialog HIG compliant. The HIG clearly > suggests not to use any separators and I agree that spacing is a > better choice since it adds less visual noise. The HIG guidelines suggest that "[b]efore you add a frame with a visible border or separator to any window, consider carefully if you really need it. It is usually better to do without, if the groups can be separated by space alone. Do not use frames and separators to compensate for poor control layout or alignnment." It's not an ironclad prohibition. (http://developer.gnome.org/projects/gup/hig/1.0/controls.html#controls-frames) I refer to my reply to sjburges for my rationale in this suggestion, but I'll point out here that it's not because of poor control layout or alignment. I'll also say that I can't think of any way to re-arrainge the controls that would be better. > I like the idea of making more use of GtkExpander in our dialogs. As > you suggested, we could hide more controls in this dialog (and > others). However for this to be really convenient, the dialog would > have to remember the expanded/collapsed state of the frames. Agreed. Is the session-state stuff we have now a good candidate? > Everything expect the most important settings could be collapsed by > default. That would make GIMP much more accessible to newbies. The > default state of the dialog could even be dependant on a level of user > expertise that can be choosen. GIMP for newbies would by default only > show the simple things while GIMP for experts would always come up > with the full dialog expanded. While the user explores the GIMP world, > she can expand more of the dialogs. Whenever a frame is left expanded, > GIMP should remember that and the dialog come up like this the next > time. I tend to dislike "newbie modes." I think that having dialogs come up unexpanded the first time, and then remembering the current state would be pretty much the same as your suggestion in practicality. Rockwalrus
