[kde-edu]: [Step] Suggestions
ks.vladimir at gmail.com
Thu Feb 21 09:45:57 CET 2008
On Monday 18 February 2008 20:59:59 Hans Chen wrote:
> Hi again,
> First I just have to say that it's amazing to get such fast and kind
> responses, and on top of it, to already be able to see the result in
And its really cool to have a tester willing to test my work and provide
> > 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.
> Very nice, almost exact how I wanted it. The only "flaw" is the
> minimum width for icon-only mode - I want to be able to shrink it to
> one column (at the moment the minimum is three columns). Would this be
> Wait. While writing this, I played around with Step (multitasking with
> two screens is nice ;-), and this is quite strange: after moving the
> Palette to the right (with the other dock windows), I can make it wide
> enough to only show one column (there's some space for a scrollbar
> too). After dragging it back to the left, I can still freely resize it
> (not restricted to minimum 3 columns). Bug?
Very strange, on my desktop I can make it slightly wider than one column in
both left and right positions. This probably also depends on the widgets
style since the dock header (label "Palette" and buttons near it) also
restricts minimal dock width. I've tried the most obvious methods to remove
this restrictions by it didn't work. For now I've removed close button from
the dock to save some space (closing it is probably bad idea anyway). Later
I'll think more on how to fix it.
> Now, the only request I have is to get rid of the unused space (where
> the scrollbar would appear). I'm not sure how this would work if you
> resize your window (reducing its height until the scrollbar is shown),
> but maybe you can figure something out.
> If what I said above was confusing (I'm sure it was), try it yourself:
> set the Palette to icon-only mode and try to make it show one column.
> (Think: space efficient). If it's still unclear, I can send some
> > I like this scheme. Moreover it looks somehow similar to the new dolphin
> > selection system so it will be known to the users.
> After thinking for awhile, I've come to the conclusion that my first
> suggestion (auto-fix + drag and drop) isn't very good. The scheme
> described above, + possible modifier key (ctrl + left mouse button?)
> could work pretty good. You wouldn't be able to see the icon in
> icon-only mode (right?), but I don't think that is a big problem with
> a modifier key. However, you'll probably have to introduce a new*
> pressed mode for the buttons when they're "fixed".
I like this scheme. So for now It's on my TODO list, I'm going to implement it
in my next frame of free time.
> (* new as in "visually different", for example another color. Maybe
> the "icon" I described in the last mail shouldn't stay visible at
> > 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 ?
> I feel that I've reached my limit regarding this question, as I'm not
> experienced with this kind of application. But maybe I can give you
> some ideas (whether they're good or not is up to you to decide).
> "Reset" could go back to t = 0. Yes, this is what we called the
> initial state. However, the point is: you're free to choose your
> initial state. If you start a simulation, realize that something is
> wrong and make some modifications, you'll be able to set t = 0 for the
> new state (you can of course always undo this). This way, "Reset" goes
> back to your new initial state.
> I don't really know how time works in Step (haven't found a way to
> manipulate it other than with Simulate), but this could be a reason to
> introduce a "reset time" (with other words, set t = 0) feature. Not
> sure how this should be done though (a button in the toolbar?). It
> would probably lead to some changes to the application (GUI-wise), for
> example it should be more obvious what the time is at the moment.
Currently the user is able to freely set current time in the properties of
world (just click on empy point in the scene or select World in "World" dock
and then you'll see its properties in "Properties" dock). Changing the time
by editing this property (unlike simulating) don't change anything on the
The idea about t=0 as "reset time" is good by we need to somehow educate the
users about it. For the near future I'll probably implement something like
Simulate/Pause/Stop buttons where Pause will do what Stop now does and Stop
will do what Stop+Undo now does. I'll think more about resetting to zero and
probably will implement it later.
> A more advanced Simulation Toolbar with a timeline popped up in my
> head, but I don't know if it would be any good.
> Too good I'm not the maintainer: I would bloat Step to Oblivion. ;)
> Finally, I have two questions (hopefully not too hard to answer):
> 1. What is the statusbar supposed to show?
Currently nothing ;-) May be you have suggestions for it ? If not I'll just
remove it for now.
> 2. I've had some draw issues with Step lately. Is it because of the
> upgrade to Qt 4.4?
Yes, there are some strange issues with Step and Qt 4.4. I hope I'll fix them
> Looking forward to your comments.
> With best regards,
> Hans Chen
> kde-edu mailing list
> kde-edu at mail.kde.org
More information about the kde-edu