On 7/14/06, Claudio Ciccani <[EMAIL PROTECTED]> wrote:
> Mike Emmel wrote:
> > On 7/13/06, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
> >> Mike Emmel wrote:
> >>> I added a call to GetVisibleRect which gives basically the visible
> >>> region of the main surface in the subsurface coordinates seems to work
> >>> but I'm thinking when you lock the surface
> >>> one of the params should be a rectangle that is the visible rect ?
> >> If someone's using sub surfaces, that one should be aware of the offset
> >> and query the visible region - if needed - itself.
> >>
> >> What about having something like Read() and Write() in IDirectFBSurface
> >> to read/write blocks of data from/to the buffer with automatic locking,
> >> offsets, clipping and *maybe* format conversion?
> >
> > Hmm yeah something like that maybe in a lot of ways subsurfaces are
> > not a good idea in the
> > sense that a subsurface is not a real surface.
> >
> > Let me get some other stuff checked in then I'm going to add get/set
> > Prop on the core object
> > and send the patch to the list.
> >
> > After that I'm convinced that we need to create a region based
> > abstraction layer on top of core surfaces
> > these regions can share the real surface with there parent or not.
> >
> > Windows should be built on top of that and created by the wm not in the
> > core.
> >
> > Probably this requires a real design to show what I'm talking about.
> > Anyway the point is windows become abstract we have now have
> > collections of regions on top. The window api stays but is really just
> > a wrapper for a region of a surface.
> > Event handling except to designate the region under a mouse event is no
> > longer
> > handled in core at all but in the WM.
> >
> > So the addition would be a region can be buffered or use its parent
> > its up to it.
> > Do you see a problem with that ?
> >
> > Agian its really similar to what you already do in unique but we flip
> > the region stuff into the core and the window/wm stuff out and I'm
> > adding optional buffering or sharing.
> >
> > Mike
> >
>
> According to me, the regions stuff should remain to the wm.
> Moving it to DirectFB itself may result in a loss flexibility because
> different window managers may need to implement regions in different
> ways. Take a 3D window manager for example.
> Instead we could move the StReT stuff out of unique, reimplementing it
> as a library or a set of utility functions for window managers.
>
>
My point is that Windows should move into the wm with just the header left
int directfb with the regions used by the wm to implement windows.
The only real tie right now that prevents windows from being pulled
out of directfb
is the fact that the cursor is implemented as a window. So we need to
either do a custom
solution for the cursor or my plan was to use the StReT code and make
the cursor a region.
Which is closer to what it is.
I'm fine with region support being a library it makes core even
smaller which is a good thing.
1.) Agree/Disagree on letting the wm create and fully manage the windows ?
2.) I think StRet can stand alone now on top of dfb surfaces without
the wm if done
correctly useful for both wm and application programmers thay
don't want full blown windows.
3.) What do we do about the cursor ?
Mike
>
> --
> Regards,
> Claudio Ciccani
>
> [EMAIL PROTECTED]
> http://directfb.org
> http://sf.net/projects/php-directfb
>
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
