On 2/17/07, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > Mike Emmel schrieb: > > Final release I am assuming that there will be one more RC release > > from the latest email traffic. Hopefully after that we should be able > > to call a final release ? > > Yes, if anyone is interested in committing all pending patches... :) > > We can make RC5 today, but it will take a few hours til I get to the > patch and release work. > > > Not that I have the time yet to work on my Drawable idea. But I'm > > hoping to start doing a few thing in the next few weeks. > > :) > > > Also for the DirectFB 2.x series I think that it might be good to > > think about moving a few directories around at some point. I have some > > ideas but in any case it would be nice to have the option. > > What about 1.0.x, 1.1.x and pre-2.0.x lines? The latter would be open > for everything up to a rewrite :) > :) The reason I say 2.x is I'd like to see some changes that are incompatible. For example right now when you lock a subsurface the pointer starts at the root of the parent surface. I'd like to change this so you get back the pointer already adjusted int non trivial for nested sub surfaces that may be larger than the parent surface. In anycase if we do the declarative stuff I want to do we need to provide more information when we lock. Also for security we may need to consider a copy on right type locking where the child gets a temporary surface.
I think that once we get a stable 1.x release having a 2.x or experimental branch should entice people to contribute new ideas that might not fit exactly with the 1.x api. At the same time we can clean up a few things in our current api. For example configuration is a bit messy we have a slew of constants for config that are not quite consistent. I'd like to see a real cursor with hardware support in full screen mode and we might need a cursor object. It would be nice also on the driver side to work towards a agnostic driver api if possible the could hopefully lead to a standard accelerated driver api linux. I'm not saying go crazy here like ggi did they failed but I think if we worked toward this it would be a good goal. I worked on kdrive quite a bit lately and the differences are not that large between directfb's driver design and kdrives. If we achieved a shared driver api it would be good for everyone. Once 1.0 is final we should set up a wiki page with ideas and suggestions. > > For this a move from CVS to either SVN or git will make it a lot > > easier to restructure directories if we wish. Also it both would make > > it a bit easier to create branches. > > We should move to git. Anyone having experience with setting it up on > server side? > > > I'd like to see if we want to move post 1.0 I think its a great time > > to make a transition if desired. > > It's really time for leaving the 1.0.x series and head for new eras :) > > > My vote is for git but anything but CVS is better these days :) > > Agree. > > -- > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
