On Fri, Sep 21, 2001 at 01:54:15PM -0700, Evan Martin wrote:
> Taskbar, like the switcher?
> I could factor some of the window-managing code out of that into a
> library if you need.
Seems a little pointless - how many switchers is the typical desktop going
to need? I stole all the code out the current switcher anyway..
> Though I admit one of my design goals for further was to get away from
> having a taskbar-- but that's just because I'm difficult. :)
> One of my actual original goals, when I was first writing this, was to
> not have a laucher; the website had "(to be removed)" written by the
> launcher plugin up until a few days ago. Instead, right-clicking on the
> desktop would lauch a terminal, which is all you Really Need.
> I was looking for some sort of beauty through simplicity...
Actually, I like the minimalist outlook as well, but I'm suddenly given a
desktop environment that lets me do all this silly stuff /far/ to easily,
and I couldn't resist the temptation...
I'd prefer clicks to fall through to, say, deskmenu, so that further stays
as a nice simple 'information display on the desktop' deal.
> I think a generalized system is in order here.
> Let me think if I can describe it...
> Basically, you want to have some sort of action on an evas object that
> takes time. I've done fading [everywhere] and sliding [switcher], and
> you want zooming. In all of these cases, the action can be cancelled or
> even reversed, and you need to be able to retarget the action while it's
> For the switcher, it's pretty simple: I track the "destination y" as
> part of each task, then in the timer I move each task towards its
> destination y. So if a task is sliding down because it was just
> created, and then you close another task, the destination y changes and
> it slides in reverse.
Yah, I stole all that code too..:-) The main difference is that I needed
everything to move in lockstep - for most simple operations (ie, that don't
involve changes in direction) I need everything to get where it's going at
the same time, and for all the icons to stay touching each other. The
switcher doesn't really have this problem.
I could have done something similar to the fading you have, but that looked
hard to adapt to changing direction. In the end, I have
l->zoom += (l->zoomdest - l->zoom)/2;
(and similar things for the x,y coordinates of the icon). That way
everything moves in sync, and you get a much nicer feeling movement, slowing
down at the end.
There's a bit of mess right at the end of the movement, but using ints for
everything and then catching the 'very nearly there' state rescues it. I had
a lot of event overflows for a while, though...
> It seems I could take this "tie a struct to an object and update it as
> a process runs" code and pull it out of the fading, allowing you to do
> zooming and sliding in much the same way.
> Thoughts? Would this be helpful?
a) As above, there are different ways you might want to move things around,
simple sliding, halving the distance each tick, spiralling into the middle,
b) The easier it is for people to make tacky flying icons....
-- The rest of the day pass uneventfuly. I teech them about Apache (WHOOP! WHOOP! PALEFACE THINKS UMS CAN RUN UM WEB SWERVER!! WHOOP! WHOOP! SCALP UP PALEFACE WEBMASTER THEN MAKE WAR DANCE!!!) -- molesworth the Teecher, Charlie Stross
This archive was generated by hypermail 2.1.2 : Sun Nov 11 2001 - 14:16:15 PST