[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-edu-devel
Subject: Re: [kde-edu]: [Step] Suggestions
From: "Hans Chen" <hanswchen () gmail ! com>
Date: 2008-02-16 12:17:05
Message-ID: c59230380802160417w1df83a81i2cdf7df28fbe33aa () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Vladimir,
> Implemented in SVN.
Sorry for asking, but are you human? That was fast!
> > 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.
> 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).
> 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.
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.
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.
> > 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.
> 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,
Hans Chen
[Attachment #5 (text/html)]
Hi Vladimir,<br><br>> Implemented in SVN.<br><br>Sorry for asking, but are you \
human? That was fast!<br><br>> > 1.4 Make the box resizable (nice if you have \
several boxes stacked on each<br>> > other, for example).<br> > I don't \
really understand what you mean here. Could you explain in more<br>> details \
?<br><br>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.<br> <br>The same problem occurs when you dock World on Palette \
(drop the dock window on Palette -> you can switch between them with a \
tabbar).<br><br>To solve this, simply make the Palette dock window resizable. For the \
sake of alternative placements.<br> <br>> Currently Step has not so many tools as \
photoshop. Probably icon-only mode<br>> will be sufficient.<br><br>Yeah, I was \
only interested in the icon-only mode (not the "one button is many buttons" \
feature that Photoshop's toolbox has).<br> It would be neat if this icon-only \
mode would change columns* depending on the Palette's width.<br>(* I hope you \
understand what I mean with columns. The Photoshop toolbox I linked to had two \
columns, for example).<br> <br>> Another idea is to allow "fixing" \
current tool. For example if you<br>> double-click on a tool button it changes its \
color and won't switch back to<br>> the "pointer" until you \
explicitly click on it. The only problem is how to<br> > tell users about this \
feature.<br><br>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.<br> <br>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).<br> <br>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.<br>The Pointer tool is always \
fixed when activate.<br><br>Still, as said, I'm not sure this is the \
"right" solution. As most tools are object, I still think<br> 1. Fixed by \
default and<br>2. Allow drag and drop<br>feels more natural. Maybe that's just \
me.<br><br>> There is one problem with it: suppose that user starts simulation, \
then stops<br>> it, then changes something, that starts and stops simulation \
again. So what<br> > should "reset" button do after it: return the scene \
to the initial state and<br>> destroy modifications or return the scene to the \
state after modifications ?<br><br>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.<br> <br>By the way, I've changed my mind about the \
"Stop" button. It should really be named "Reset", as that is what \
it does.<br><br>> But what should be considered as advanced options ? What about \
disallowing all<br> > modifications except explicitly allowed by controllers on \
the scene ? I could<br>> introduce "viewer mode" which can be switched \
by a button on a toolbar.<br><br>Yeah, that's the hard part. I think your \
suggestion sounds good, although it could be troublesome with many properties.<br> 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.<br><br>> > 4.3 Maybe the ability to display a grid in the scene?<br> \
> Will there be any use of it ? Anyway it's quite easy to do so I could \
enable<br>> it as an option.<br><br>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.<br> <br>> Just \
attach a "tracer" to it ;-)<br><br>Do'h! (And here I was thinking that \
it was a "hard to implant" feature. You guys never stop to impress \
me).<br><br>> Thanks again for very detailed and usefull report !<br> <br>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. :)<br><br>Best regards,<br>Hans Chen<br>
_______________________________________________
kde-edu mailing list
kde-edu@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-edu
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic