Re: [orion-dev] Making the Editor easier to reuse

[Boris Bokowski <bokowski@xxxxxxxxx>]

Mihai,

>> My gut feeling is that the ability to animate (or not) would be best moved
>> into textView.js, instead of trying to implement it at a higher layer.
>> This
>> would make it much easier to ensure consistency. What do you think?
>
> I would consider animations as higher level, rather than something at
> TextView level. Maybe it's just me.

I hope it's just you :-)

My argument would be that consistency is important, and that there
needs to be support for this at the textView layer to achieve
consistency. I am thinking about a hook that would allow code at a
higher level to plug in animation, i.e. the default would be to not
animate if you use textView.js, but there would be a hook in
_scrollView to add animation. Obviously, one would need to be able to
distinguish between calls to _scrollView that are caused by the scroll
bar/a scroll gesture vs. calls that come from the places that handle
line up/down, go to start/end etc.

> My reasoning is that the text view widget should provide all capabilities
> for the widget itself. For "fancy" features, one would take the editor.

I view (subtle and fast) animation as a core feature. Makes the editor
so much more pleasant to use. I wish I knew how I can sway more people
to join my side... ;-)

> One argument I would use for "why no animations?" is because any native
> editor I've used lacks animations (eg. gedit, gvim, ultraedit and others).
> The disorienting factor is probably why animations don't necessarily fit.

You may have misunderstood me. I tried to argue that *not animating*
causes disorientation. If you animate a page down operation, rather
than just doing a hard jump, you give your eyes a chance to understand
what's going on, and a way to transition between the old picture and
the new that makes sense (e.g. fading between the two states wouldn't
make sense).

I used (and loved) a native editor that did smooth scrolling, and
animations instead of hard jumps. This was Cygnus Ed on the Amiga,
which could rely on hardware support for making this possible. The
other editors you list couldn't rely on hardware support, and were
written at a time when text rendering just wasn't fast enough to
support smooth scrolling or animations. Now that we do have fast
enough text rendering, we shouldn't let ourselves be held back by past
constraints.

Boris