[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-developer
Subject:    Re: [gimp-devel] Here we go again with KDE
From:       Torsten Rahn <torsten () kde ! org>
Date:       1999-05-30 16:13:55
[Download RAW message or body]

On Sun, 30 May 1999, you wrote:
> On Sun, 30 May 1999, Torsten Rahn wrote:

> Ok, then I missed. Sorry. My point is I saw some screenshots of Kimp that
> had the toolbar embedded to the image windows, and I kinda freaked out..
> Would that make any sense? I think not. Every user has too little space on

On the other hand I find myself searching for one of these small option-
dialog-boxes freefloating anywhere on my big screen. Sometimes even the 
toolbar 'gets lost'  and I need a moment to find out where I put it or
where it reappeared between all that opened image-windows. This is the
disadvantage of the current solution.
The best solution IMO would be to give the user the choice what he likes 
best: You should be able to dock the freefloating toolbars/menubars,
option-windows, etc. to one of the borders of the active image-window
(horizontally at  the top of the window or vertically at the left or right). 
If you  switch to another window the toolbar vanishes in the previous 
image-window and reappears in your new current window. This way it 
wouldn't waste any additional space. (Yes -- Mac ...)
If you don't want to have the toolbar docked to one of the window-borders
you can simply tear it off. Then it freefloats again. If you switch 
to another image now the toolbar should stay at the same place (this would
imitate the current solution). 
The big advantage of this solution is that it includes the current 
solution but gives the user the choice to do it in another way if he
prefers (And I'm sure that many people would prefer the other way).

> the desktop. So windows and dialog should be as small as possible to give

But not smaller at the cost of additional menu-levels and inconsistent 
menus (which means that I still don't understand that you find 
'Dialogs' in 'Files').  :-(

> more screen space to the image windows. But I think it makes more sense
> doing a separate frontend to gimp than make a new Kimp from scratch. I

Right! Which doesn't mean that I wouldn't like to have an additional
different app based on ImageMagick or whatever ... :-)

> know it is a lot of work and probably that is one reason it has take a
> while although it has been discussed also before.
> >>    I just want to say that I like the current interface a LOT. And those
> >> who dont know me so well, I use Gimp for several hours almost daily.
> >Hmmm, I use it about two hours daily -- is that enough for you ?
> Heh, that was not my point. I was just saying that I use it a lot. Didnt
> mean it as a challenge to others. Mainly like 'if I stand that thing many
> hours a day it cant be that horrible' since I dont find the gui too bad.

And I use it two hours a day and still have my problems to get used to the
interface ... people are different!
 
> >>      One solution would be a 'Drag and Drop extra toolbar' for plugins so
> >> plugins would register an button with text/icon that you'd drag over the
> >> image. But I dont know.. 
> >Yes, much better than tear-off-menus. 
[...] 
> Well, we have talked about tear-offs once before and _lets not get into
> this again guys_, ok? ;) It is the problem that when you tear off a menu

:-)))

> from a window, you tear it off. You then dont know what window it belongs
> to, and it is kinda hard to know where to apply the menu functions..

That's why tear-off-menus won't be implemented in KDE 2.0  ...

> >Keep up the good work,
> You too! The new KDE icon stuff (easteregg2.jpg) looks nice!

Thanks -- but I still don't like it -- not really ... back to work ...
 
> Tuomas

Torsten who will now give GIMP 1.1.5 a try 
(I'm currently using 1.1.2 so if anything that I mentioned is out of date 
then you know why!)
 
> -- 
> tigert@gimp.org

[prev in list] [next in list] [prev in thread] [next in thread]