Some UI nitpicks

[John Califf]

Bart Szyszka wrote:
> 
> > > space that I might want to use for reference. I made an example image
> > > in Photoshop:
> > > http://www195.pair.com/gigabee/extras/photoshop-screenspace.png
> > Your screenshot shows the classic MDI paradigm. KDE is actively discouraging
> > MDI for usability reasons. Instead of mini-windows within the main window,
> > everything is supposed to be docked along an edge as a panel or toolbar.
> > There are no current screenshots up at the website,  so I slapped one up on
> > mine real quick: http://www.usermode.org/krayon.png, for a limited time.
> But then how do you account for the wasted space that'll be there when the
> panels don't fill the right edge of the screen? Like in my example. I was able
> to make the Photoshop panels ("palettes") compact enough so that I could
> fit something in below them.
> 
> As far as your screenshot goes, is that what tabs look like with your particular
> KDE2 theme or are those actually just toggled buttons? And will I be able to
> drag a tab/button from one row of them into the other row like I'm able to do in
> Photoshop? Also, would people be able to arrange the panels horizontaly? I
> know a lot of people who do that with the Photoshop palettes. What about being
> able to have multiple images on the screen at the same time? That's absolutely
> essential. Is each image going to have to have its own set of toolbars and panels
> surrounding it (which would seem to fit the non-MDI way)? I could see that working
> for Kword, but not with Krayon where, again, screen space is a top priority.
> 
> - Bart
> 

This is a general reply (not directed at David) to several issues David
and Bart have written on in which the discussion has drifted away from
the original topic of the gradient dialogs.  I have tried commenting
earlier but evidently these went to the wrong thread.

The panels and the image tabs allowing multiple images per document or
main window work fine, and you can also split the view either
horizontally or vertically.  There was a bug regarding closing a split
view which I have just fixed.  Each image does not have a separate set
of toolbars and a separate sidebar, etc.  Each view of the entire
document does have its own, though.  A document can contain multiple
images in a single view.
I will put some more screenshots up on the webpage at
koffice.org/krayon/ for some examples of all this, but you really have
to use krayon to get a feel for what I'm talking about.

Artists need to be able to work with multiple images and layers without
opening up more and more windows cluttering up the desktop. We seem to
be in agreement on that. This works well in krayon and I have no plans
to change it.  It works well as an embedded part also within koffice
generally, and I've just tested krayon as a part in koshell. Kspread
also allows multiple tabs for multiple tables per document in a similar
way.  

The sidebar can now be hidden giving you all the space you need.  You
can open as many views as you want or new instances of krayon if you
prefer to emulate the sdi approach.  Krayon's interface is much nicer
than Gimp - there is no comparison, and trying to mimic Gimp's wasteful
and confusing sdi interface would be a disaster. You can't drag the tabs
(they are just buttons)into a new group but you can rearrange buttons or
items on toolbars to accomplish something similar.  So, we will probably
change the "tab butttons" in the sidebar to toolbars in the sidebar, but
keep the tabs for flipping between different images in the main
workspace area like they now are.

Only two things in krayon use tabs:  the multiple images in the main
workspace, and some items in the sidebar.  Everything else will use
toolbars.  Changing the tabs in the sidebar to toolbars parented by the
sidebar might be a good idea.  But not the main workspace with the
images. Tabs here are great.  We are trying to avoid lots of toolbars
clutering up the workspace and for some things tabs (using buttons) are
better.  Using toolbars within the sidebar is a great way to allow
maximum flexibility without clutter and with easy access to the very
useful sidebar when so desired (by keeping these toolbars confied within
the sidebar, which can be hidden or unhidden as a whole).

Nothing is set in stone, and Krayon is always open to change.  The
engine is rock solid and well encapsulated and independent of the
interface.     I think the mixture of toolbars (krayon also uses
toolbars) and tabbed views is very superior, as is the sidebar.  It uses
space much better and is much more intuitive than lots of toolbars, or
pure sdi, and can be convieniently hidden and unhidden.  We absolutely
must have the ability to access multiple images in the same main window,
and using toolbars to do this really is inferior to the tabs allowing
you to flip from one image to another within the main workspace, where
the user actually paints with the tools.  It's like a sheaf of drawing
papers or canvases. It also uses less space.

So far as I am concerned the debate over sdi/mdi and tabs vs. docked
toolbars is closed for the time being.  What we have works and works
well. I will probably get around to changing the tabs in the sidebar to
toolbars because that seems better but it is not a high priority.  As I
am the only person doing much coding on krayon right now I have other
priorities than making a religion of sdi and toolbars and breaking
something that works well in the name of that religion.  Things like the
drawing tools, selections, and color modes have a higher priority.  We
can alway go to the docked toolbar approach later for SOME things
although it would be a terrible dis-service to users in the name of the
sdi religion to do that uniformily.  Sdi is not superior, and not
desirable in every situation.

David - please document what we have.  The gradient dialogs need some
work and really belong under a "tools" menu, not under "view".  You are
right about that.  The gradient tool is probably the last one I will get
to and don't expect it to do much for a while.  Both the dialogs really
should be combined into one allowing you to set the gradient type and
view what it looks like with different colors at the same time.  All the
tools will eventually have properties dialogs and the "gradient" dialog
should really be considered the properties dialog for the gradient
tool.   Does this make sense? Generally, we will access the properties
dialogs for each tool with a right click on the tool icon for it in the
toolbar, and there should also be a menu item under "tools" for each
tool and a properties or settings dialog for the tools that need them in
the "tools" menu.  I will add the "tools" menu today.

John