Re: [E-devel] [RFC] background panning when changing desks

[Carsten H. (T. R. <ra...@ra...>]

On Thu, 30 Apr 2009 23:13:28 +0200 Viktor Kojouharov <vko...@gm...>
said:

> On Thu, 2009-04-30 at 17:32 -0300, Gustavo Sverzut Barbieri wrote:
> > On Wed, Apr 29, 2009 at 7:18 PM, Viktor Kojouharov
> > <vko...@gm...> wrote:
> > > On Wed, 2009-04-29 at 18:58 -0300, Rafael Antognolli wrote:
> > >> On Wed, Apr 29, 2009 at 4:31 PM, Viktor Kojouharov
> > >> <vko...@gm...> wrote:
> > >> > Hi,
> > >> >
> > >> > I've been playing around with the making the bg_object pan on desk
> > >> > switch, instead of using transitions. To illustrate what I'm talking
> > >> > about, I made a rather crappy screencast (istanbul only seems to make
> > >> > 10fps screencasts, anyone have an alternative program?):
> > >> >
> > >> > http://www.youtube.com/watch?v=glYLH3GSikE
> > >> >
> > >> > The idea is that the background slides depending on its size relative
> > >> > to the geometry of all desks, as well as a user specified factor.
> > >> > E.g.: if you have 2 horizontal desks of size 640x480, and a bg of size
> > >> > 1280x480, the background will slide at most by a half of its size. If
> > >> > the user specifies a factor below 1.0, the offset of the bg is
> > >> > smaller, creating a parallax effect. If the bg size is smaller, the
> > >> > total offset will be smaller, thus not causing the bg to scroll off
> > >> > boundary.
> > >> >
> > >> > I've currently implemented it with this patch. It is toggable by an
> > >> > option in the virtual desks settings dialog, which will override any
> > >> > preselected transition (since it doesn't use the same function). Speed
> > >> > is not blazing fast, but I'm not sure if it can be faster with just
> > >> > using the software engine (using the gl engine for the container is
> > >> > flicker free though).
> > >> >
> > >> > So what do you guys think of this idea?
> > >>
> > >> Wow, very nice effect!
> > >>
> > >> Now I'm thinking if it would be possible to have a wallpaper with many
> > >> layers, and some of them scroll more than others. This way you would
> > >> have an effect as if the near mountains move faster than the far ones
> > >> (giving an idea of depth)...
> > >>
> > > If there's any way to communicate the direction, duration and distance
> > > to edje, then maybe it could be possible. Not sure how much info one
> > > could give with an edje signal. And the performance might degrade.
> > 
> > just use edje messages instead of signals, you can give it an array of
> > floats. As for performance, yeah, it will suck with slower machines.
> > 
> 
> Actually, another idea which might work even easier (though it would be
> a bit more restricting), is to get all groups matching the
> 'e/desktop/background/*' glob. these groups can represent additional
> background elements, and they could have a data item, which specifies
> the speed coefficient, relative to the 'e/desktop/background' element.
> 
>  E.g.: I could have an 'e/desktop/background/sun' group, which would
> show a sun. It would have a data item 'data.item: "relative_speed_x"
> "0.1" # (0.0 - inf). Then the sun would be offset by 0.1 of the
> background offset in the X direction. This is easier for implementation
> and easier for the themers to do, but it only offers movement relative
> to the main background object (but it will achieve what Rafael is
> suggestion, so I don't know whether more freedom is needed).

take a look at e_fwin.c:_e_fwin_pan_scroll_update() in the fileman module... it
does all of this already. for an example of edje that does it...
http://www.rasterman.com/files/Custom-Background-etc..tar.gz

untar it - open it in fileman. scroll around. resize it up and down to test
horizontal scrolling too :) it's been doing this for quite some time now. anice
hidden feature in efm that lets you have custom background AND even overlays
per directory using magic files - meant to allow customising of your data
when browsing it. this means you can let the designer of the bg now choose how
to scroll, how to scroll, how many layers, where they are positioned depth-wise
etc. etc.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...