On Fri, Sep 21, 2001 at 06:15:06PM +0100, Tom Insam wrote:
> I suspect it's the feebleness of the machine I'm developing on - it quite
> often fails to redraw the b/g after I've moved windows, etc, where the more
> powerful computer I have at home has no problems here. I haven't tried this
> on a powerful computer yet - something to do over the weekend...
There is some bug with the redrawing code... sometimes, if you kill a
terminal with the keyboard (ie don't move the mouse) the background
never redraws.
I looked into it for a while and couldn't figure anything out.
I suspect it's related to the evas not handling the expose event that
should happen when a window closes.
And yeah, the moving stuff is weird too. I very likely have a bug
somewhere, but it'll be a bitch to track down.
> It'll be a while before it's anything other than a more amusing launcher.
> I'm hoping to include a taskbar as well, and have started programs have a
> bouncing icon... :-) Not wonderfully useful, but further is just too pretty
> for me not to play with.
Taskbar, like the switcher?
I could factor some of the window-managing code out of that into a
library if you need.
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...
Ideally, though, it should be configurable enough to support everyone's
needs. By factoring enough code (see below) plugins should be simple
combinations of further concepts such as fading, sliding, or zooming.
> > It's particularly difficult to get all of the timing code right.
> > See furtherp_fade_full in plugin.c; that's my fifth attempt at it, and
> > it's that complicated because it needs to be.
>
> I can appreciate your problems - I'm on my third way of zooming icons around
> now...
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
running.
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.
For fading, it's a bit more complicated, because I don't want to force
each plugin to track the fade state. Instead, I use evas's system of
attributing data to the object to tie a "fade" struct to it, and update
that accordingly. (Thankfully, because this is all running as one
process, there aren't any locking issues.)
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?
--
Evan Martin
evan@livejournal.com
http://neugierig.org
This archive was generated by hypermail 2.1.2 : Sun Nov 11 2001 - 14:16:15 PST