[kde-edu]: [Step] Suggestions

[Vladimir]

Hello,

Thanks a lot for all your suggestion, I'm surely going to implement many of 
them !

On Thursday 14 February 2008 00:55:54 Hans Chen wrote:
> Hi,
>
> Ever since hearing about Step, I've wanted to try it. But somehow I forgot
> about the physical simulator - until today, that is. While browsing the
> web, I saw a screenshot of the application and decided to try it out. Using
> the kdesvn-build script, it was build with a breeze.
>
> I had high expectations for this application, but this... Wow! Step is
> going to be one of my favorite applications for sure. I'm really impressed!
I'm really glad to hear it !

> Needless to say, not everything worked as expected. Here are some
> suggestions that, in my opinion, would make Step even better. Any comments
> are welcomed.
>
> *1. Palette
> *This is where all the "tools" are, a central part of the application.
>
> 1.1 Have you ever tried to have the content of the box left aligned? The
> different widths of the "buttons" (Pointer, Particle etc.) make it awkward
> to click, especially when middle aligned. And, as a used, I'm simply used
> to left aligned tool boxes.
> 1.2 Ah yes, the buttons should have the same width. (The "invisible" part,
> at least; like Qt4 Designer).
Actually the buttons used to have the same width until it was broken by some 
version of Qt: now QToolButtons don't respect QSizePolicy settings. Probably 
anyone has some suggestions how to fix it ? Anyway I'll look at this issue.

> 1.3 If the box' height is too small, it should show a scrollbar. (I'm a
> little bit unsure about this, but once again, see Designer).
Good idea, I'll implement it.

> 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 ?

> 1.5 Make it respect top/bottom placement, or don't allow it to dock there.
For now I've disallowed docking, in the future I'll make it respect top/bottom 
placement.

> 1.6 A "simplified" mode, where only the icons are shown (think Photoshop
> toolbox<http://z.about.com/d/graphicssoft/1/0/7/P/1/cs2-workspace-4toolbox.
>gif>). This would save space for someone who's used to the application.
Currently Step has not so many tools as photoshop. Probably icon-only mode 
will be sufficient.

> 1.7 Make it possible to assign shortcuts to the different "tools".
Good idea.

> 1.8 A new way to add objects to the scene: (I'm not sure this would be more
> efficient, feel free to discuss)
> If you click on a "button" it works the same way as now, except that it
> doesn't change back to the "pointer". This way you can easily add multiple
> objects.
> If you just want one object, you can drag a "button" to the scene. Similar
> to Designer, you drag the object to the scene. This causes a problem: this
> way, you can't connect springs etc.. Maybe this could be solved somehow, or
> you simply have to connect them after dropping the object?
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.

>
> *2. Simulate
> *This was probably the most confusing. I ended up clicking Simulate -> Stop
> -> Undo -> Simulate...
>
> 2.1 To solve this problem, I suggest to rename Stop to "Pause".
> 2.2 Add a new "Stop" action that resets everything to how it was before you
> pressed "Simulate". A little bit like "Reset", but I think it would make
> sense with "Stop". Think of an audio player. This is probably my most
> wanted feature.
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 ?

> 2.3 A small annoyance: the Simulate/Stop toolbar button changes size when
> the string is changed. Irritating, but I don't know if there's a solution
> (except hiding the text).
>
> *3. To create a experiment vs playing with it
> *I'm not really used to these kind of simulators, I can already say it has
> a great potential (no puns intended). The simulators I'm used to is of the
> kind "Here is a particle on a spring, set some properties and see how it
> move".
> With that said, that's one of the areas where I think Step needs lots of
> love. Explanation below.
>
> The ability to create a new "World" in Step is truly great. But sometimes
> you want to play with a simple experiment - I found some nice ones in
> "Examples", for example the double pendulum. However, I didn't find a way
> to "play" with it without destroying the actual setup. In this case, here
> are the differences:
>
> The setup is the objects, how they're connected and are supposed to
> interact.
> When I want to "play" I just want to change some properties: masses, the
> length of the pendulum, the angle between them etc. I don't want to remove
> a particle, not disconnect it. It would be great with some kind of "locked"
> mode where I can play with this experiment without destroying the setup.
>
> It's easy to say, but I realize that it's much harder in practice. What
> should be consider as "locked" and what should be freely adjustable? I
> don't know. But I wanted to express this wish, maybe you can find a
> solution?
>
> With this, Step would just be perfect. You could introduce a "Step
> Player/Viewer", which opens the .step files in locked mode without the
> advanced options.
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.

> **
> *4. Small things
> *
> 4.1 I found a little bit hard to connect things (like springs) after
> they've been placed on the scene, but maybe that's just me.
Several other people have complained about this so I'll try to fix it.

> 4.2 The application crashed sometimes, for example when clicking on
> "Particle" and then "Pointer". (In the future, I'm going to post bug
> reports about such crashes).
Yes, bugreports will be very usefull.

> 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.

> 4.4. In the "Configure graph" dialog, I didn't really understand what the
> third combobox after X: and Y: means (you can choose between 0 and 1).
For a vector property this means an index of a component of the vector. For 
example when you choice property position and index 1 it means y component of 
position.

> 4.5. Same dialog: I miss momentum as a choice as X/Y.
Fixed in SVN.

> 4.6 It would be neat if you could set a "trail" after a particle.
Just attach a "tracer" to it ;-)

> 4.7 I would like to see a "History" box (among Palette, World, Properties
> and Context info). It would simply display your latest actions and lets you
> undo things. This is not very important though.
Implemented in SVN.

> 4.8 Better organized "World" box. Maybe clearer sorted by "type". Or give
> the user the possibility to create "groups".
Grouping is implemented in the library, I just need to think about UI for it.

> 4.9 Same box. Do you think small icons in that box would look good?
Implemented in SVN.

>
> *- - -*
>
> I think that's enough for this time. As said, I'm really impressed by your
> work.
> I wish I could contribute to this great project, but unfortunately neither
> my C++/Qt skills nor physics knowledge is good enough. However, I'm
> studying physics at the university, and when I have some free time I'll try
> to learn C++/Qt. Just wait, maybe for Step 3.0... ;)
What you are doing now (testing and reporting bugs/ideas) is already great !  
Thanks again for very detailed and usefull report !

-- 
      Best Regards,
        Vladimir