[kde-edu]: [Step] Suggestions

[Vladimir]

Hello,

On Saturday 16 February 2008 15:17:05 Hans Chen wrote:
> Hi Vladimir,
>
> > Implemented in SVN.
>
> Sorry for asking, but are you human? That was fast!
Unfortunately I'm really just a human ;-) and unfortunately currently I have 
not very much free time. You mail have arrived at a point where I have 
slightly more time than usual ;-)

>
> > > 1.4 Make the box resizable (nice if you have several boxes stacked on
>
> each
>
> > > other, for example).
> >
> > I don't really understand what you mean here. Could you explain in more
> > details ?
>
> The Palette dock window is not resizable (you can't change its width), but
> the other dock windows are (for example World). The problem is, when you
> dock both Palette and World to the left or right, neither are resizable.
> The width is fixed to Palette's befault width, which could be troublesome
> if you want an alternative layout.
>
> The same problem occurs when you dock World on Palette (drop the dock
> window on Palette -> you can switch between them with a tabbar).
>
> To solve this, simply make the Palette dock window resizable. For the sake
> of alternative placements.
Very good observation, I would never find this issue myself ! 

>
> > Currently Step has not so many tools as photoshop. Probably icon-only
> > mode will be sufficient.
>
> Yeah, I was only interested in the icon-only mode (not the "one button is
> many buttons" feature that Photoshop's toolbox has).
> It would be neat if this icon-only mode would change columns* depending on
> the Palette's width.
> (* I hope you understand what I mean with columns. The Photoshop toolbox I
> linked to had two columns, for example).
Done in SVN. Now the Palette is resizable, has scrollbar when its too small 
and you can turn icon-only mode (with dynamic column count) by right-clicking 
on it.

>
> > Another idea is to allow "fixing" current tool. For example if you
> > double-click on a tool button it changes its color and won't switch back
>
> to
>
> > the "pointer" until you explicitly click on it. The only problem is how
> > to tell users about this feature.
>
> I can't think of another application with this "fixing" feature, and that
> makes me a little hesitant. On the other hand, as I mentioned, there are
> problems with the drag and drop interface too.
>
> An idea for "fix current tool" would be a small icon to the right of every
> button. Normally it is invinsible, but when you hover over a button it'll
> fade in smoothly (and fade out once you've moved you mouse away).
>
> Now, if you click the icon, it won't disappear. The tool is "fixed". Click
> on any other button or on the icon to "defix" it.
> The Pointer tool is always fixed when activate.
I like this scheme. Moreover it looks somehow similar to the new dolphin 
selection system so it will be known to the users.

>
> Still, as said, I'm not sure this is the "right" solution. As most tools
> are object, I still think
> 1. Fixed by default and
> 2. Allow drag and drop
> feels more natural. Maybe that's just me.
>
> > There is one problem with it: suppose that user starts simulation, then
>
> stops
>
> > it, then changes something, that starts and stops simulation again. So
>
> what
>
> > should "reset" button do after it: return the scene to the initial state
>
> and
>
> > destroy modifications or return the scene to the state after
> > modifications
>
> ?
>
> I would say the initial state. With the History box it should be easy to go
> back to the modifications if you want. I can't speak for everyone, but
> personally I'm often only interested in results given different initial
> conditions.
I see a problem here: what should be defined as initial state if user creates 
the experiment from the scratch ? What if the user wants to switch to 
different "initial state" ? How intuitive would it be ?

> By the way, I've changed my mind about the "Stop" button. It should really
> be named "Reset", as that is what it does.
>
> > But what should be considered as advanced options ? What about
> > disallowing
>
> all
>
> > modifications except explicitly allowed by controllers on the scene ? I
>
> could
>
> > introduce "viewer mode" which can be switched by a button on a toolbar.
>
> Yeah, that's the hard part. I think your suggestion sounds good, although
> it could be troublesome with many properties.
> I was thinking about a dialog where you could choose which modification you
> can make in "viewer mode". But I don't think it would be very intuitive.
For now I've added this item to the TODO list of Step.

>
> > > 4.3 Maybe the ability to display a grid in the scene?
> >
> > Will there be any use of it ? Anyway it's quite easy to do so I could
>
> enable
>
> > it as an option.
>
> Personally I like grids (with "snapping"), but I'm not very sure it be very
> useful in Step. Maybe you can wait with this one and see if other users
> request this feature.
I've added this into TODO. It will be easier to implement after rewrite of the 
drawing code which I'm planing to do.

>
> > Just attach a "tracer" to it ;-)
>
> Do'h! (And here I was thinking that it was a "hard to implant" feature. You
> guys never stop to impress me).
;-)

>
> > Thanks again for very detailed and usefull report !
>
> And thanks for your answer. It's these kind of responses that motivates me
> to give reports. And the end results too, of course - can't wait to see how
> Step develops. :)
;-)

-- 
      Best Regards,
        Vladimir