On 4 May 2004, Sven Neumann wrote:
> Nathan Carl Summers <[EMAIL PROTECTED]> 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.


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.


Gimp-developer mailing list

Reply via email to