Hi,
Here's again without tabs.
Pedro Aguilar
> Hi Pedro,
>
> I am interested in the drawing that you attached. It attached as *.txt
> file when viewed it with VI it does not seem to line up right. What
> tool is needed to view the file?
>
> Thank you,
> -Pandit
>
> ----- Original Message ----
> From: Pedro Aguilar <[EMAIL PROTECTED]>
> To: Mike Emmel <[EMAIL PROTECTED]>
> Cc: [email protected]; "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Sent: Thursday, January 18, 2007 1:15:06 PM
> Subject: Re: [directfb-dev] Want To Help: Window Manager
>
> Hi Mike,
>
> I've been reading doc and code, too.
> There are still things not completely clear, but I think I could
> start doing something useful.
>
> As you said, we can start with the CoreDrawable.
> After reading your previous emails and other doc (like xcb) I got a better
> idea of your proposal, but I still have several questions.
> I start with the what I understand (see attached diagram), that if it's
> correct could be useful for others.
> You have much more experience in this subject, so please correct me if I'm
> wrong and don't get upset if you read awful things :)
>
> (1) DirectFB with the CoreDrawable
> As you said, this is DirectFB plus this Core that only does a couple of
> things:
> - List of z-ordered regions: circular double-linked list? It could be
> useful for ordering the regions in a fast way.
> - List of instructions for drawing a region: normal DFB rects for now.
>
> DirectFB should remain without a wm, since the later would be a shared
> library.
> Thus, when a new window is added (through a request done by X11, a DFB WM
> or directly from a DFB app), a DFBWindow would be created on top of the
> CoreDrawable that will handle how this DFBWindow is drawn and it's
> z-order. This should be done having in mind backwards compatibility with
> current
> DFB apps.
>
> (2) The communication between a DFB WM or an X11 server with the
> CoreDrawable would be that the CoreDrawable:
> - sends input events and msgs (such as windows id and properties)
> - receives drawing requests and msgs.
> This is similar to xcb, does the CoreDrawable need to send/receive
> something else?
>
> For all the X11-based apps and wm, the kdrive could be used, at least
> initially, as a hook for passing the real drawing work to DirectFB.
>
> (3) The DFB wm decides what to do with the windows. The chain of
> primitives for drawing (that could include cairo) could be created here,
> although the real drawing is passed to the CoreDrawable. Is this correct?
>
> (4) Could you explain a bit more about the interoperability in cases like
> an X11 wm running DFB windows or the other way around? (my simple diagram
> doesn't show it)and the XML programmable desktop?
>
> Thanks and sorry the list of questions.
>
> I will start playing with Fusion!
>
> Pedro Aguilar
>
>> On 1/18/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> Hi Mike
>>>
>>> I think I have a least a conceptual understanding of how WM's
>>> traditionally work, what we need to do, and of how you propose to do
>>> it.
>>>
>>> I suggest that at least in the beginning you could delegate the work to
>>> me
>>> and others, since you seem to have the best overview. I tried checking
>>> out
>>> the "mike_surface" branch but that did not compile.
>>>
>> I went off the deep end a bit on that one :)
>> Consider it notes.
>>
>>> The work you have allready done! Is that in cvs, in a branch or not ?
>>> I suppose we would need to create a branch at least untill we have
>>> factored out the WM so it loads a a module.
>>>
>> Correct I asked on the list about moving away from cvs and svn seemed to
>> be
>> acceptable I'd like to see us use svn for this type of work.
>>
>> Dennis any chance of a move to SVN in the near future ?
>>
>> If not I'll make another branch in CVS.
>>
>>> So if you could take charge at least here in the beginning and give me
>>> something to work on. If there is a not too complex and lengthy thing
>>> we
>>> need done that would probably be the best!
>>>
>>
>> Great. The first step is to create a new core data type like
>> CoreWindow and CoreLayer
>> that will represent our Z ordered surface. For now it can just draw a
>> rectangle as its opp.
>>
>> I have to give a demo on Wed but after that I'll have some free time
>> to start working a little.
>> If you have not done any internal dfb programing the first thing you
>> need to do is work through how the fusion calls work between the
>> interface and the core object.
>>
>> So your homework is to play with fusion a bit so you see how it works
>> in multi and single mode. Probably it would be best to create our own
>> Fusion world for this also.
>> The best approach I think is to set up your own master slave sample
>> server you can use the one in DirectFB/tests as a example.
>>
>>
>> I can add the base data type after Wed on a branch. I think I'll call
>> the new data type CoreDrawable since thats easier to spell than
>> CoreComposite and its main purpose in life is a place to draw. The
>> constructor takes a surface and we need to have the ability to change
>> the surface to a new one. The software cursor will become a sprite
>> CoreDrawable so the first real test would be to show we have a cursor
>> working correctly. This means we probably need to support z order
>> layer conceptual grouping in the CoreDrawable so its easier to keep
>> groups above and below other groups.
>>
>> Initially it will be a z ordered tree of rectangles with only a fill
>> rect supported.
>>
>> The WM will attach to the screen get events and is full responsible
>> for user events.
>> First of course we have it just drag windows around and click to raise
>> lower.
>>
>>
>> To finish I hope to get some feedback from Dennis on this and I'll cut
>> a branch off after next Wed and add the new CoreDrawable data type and
>> we can then work on filling in the details.
>> You play with fusion for a few days until your comfortable with it
>> thats the only part of directfb that is different once you grok fusion
>> its basically regular C programming.
>>
>> The first goal is a z ordered list of drawable that support fill rect
>> operator and a soft cursor
>> along with a simple wm using CoreDrawable.
>>
>> The next goal will be to add Surface blit/flip support as a operator
>> from CoreWindow and add more drawing operators.
>>
>> At this point we can look at splitting CoreWindow between the new WM
>> module and CoreDrawable. This means need one more new datatype
>> interface DFBWindowManager.
>>
>>
>>
>>
>>
>>
>>
>>
>>> -Martin L
>>>
>>> > I guess I should say where I'm at on this project.
>>> >
>>> > On the X11 side I've written a kdrive based directfb X11 server that
>>> > runs full screen
>>> > on the display layer. So we have X11 now in full control of the
>>> screen.
>>> >
>>> > The next step is to rip the WM or probably more correct ignore the
>>> > current Directfb wm code
>>> > and write the simple region manager with a basic drawing list. This
>>> > can reuse a good bit of the current wm code and simply have the
>>> > structures renamed I call them CoreComposite right now since we have
>>> > used all the good words ( I'm open to suggestions )
>>> >
>>> > Then we need to move back to X11 and hook the creation functions to
>>> > defer back to the dfb composite manager the rootless and composite
>>> > api's can be used to guide how to preform this hook.
>>> >
>>> > Then back to directfb you can now rip the remaining CoreWindow code
>>> > out and let it defer to our CoreComposite manager. Done correctly
>>> when
>>> > a DFBWindow is added it adds a CoreComposite the X11 WM picks up this
>>> > request and wraps it in the X11 api creating a X11 window that can
>>> now
>>> > be hooked by current X11 wm's. Yes this means that X11 is running on
>>> > directfb and directfb windows are emulated under X11 but thats by
>>> > design honest :)
>>> >
>>> > Once we have good directfb wm's the reverse would be true with the
>>> X11
>>> > wm api rerouted to and simulated by directfb via a compatibility
>>> > library.
>>> >
>>> > This is a lot of work but now DFB can be running on the desktop and
>>> it
>>> > works via integration with the existing X11 code base we have plenty
>>> > of time to develop new cool desktops DFB core can be adopted and
>>> > deployed using the existing technology via the above hooks.
>>> > When compelling "pure" DFB desktop are available that support
>>> > applications expecting a X11 WM the X wm can be replaced.
>>> >
>>> > My opinion is that we can offer a saner and easier api for WM
>>> > development from directfb so I think that in time people will prefer
>>> > the DFB api if its widely deployed. The migration route solves this
>>> > problem. The WM/App interaction can then be hidden via a wrapper
>>> > programming interface so your not doing X programming directly. In
>>> any
>>> > case the options for evolution/revolution are open so it really up to
>>> > what gets adopted technically there are no limitations. Overtime I
>>> > think that direct X11 programming will fade and a agnostic api will
>>> > develop. This is already common with libraries like Gdk/QT but they
>>> > add a lot of other junk to the wraps. I'm talking about a saner
>>> > Xlib/DFB style simple api that hides the window impl without adding a
>>> > widget toolkit.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On 1/17/07, Mike Emmel <[EMAIL PROTECTED]> wrote:
>>> >> On 1/17/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> >> > I am still reading up on WMs. Just tried to compile and run
>>> metacity
>>> >> in an
>>> >> > Xnest, and reading their HACKING document.
>>> >> >
>>> >> > Still a lot of questions and things I need to get familiar with,
>>> but
>>> >> for
>>> >> > now just one question:
>>> >> > What exactly do you mean by:
>>> >> > "open the directfb api to allow X11 to work well i.e allow X11 wm
>>> etc
>>> >> to
>>> >> > function and manage all windows including dfb windows."
>>> >> >
>>> >> > Do you wan't existing X Window Managers to actually compile "out
>>> of
>>> >> the
>>> >> > box" under DirectFB.
>>> >> >
>>> >> > Perhaps it's just me which still havent figured out how exactly th
>>> WM
>>> >> > interacts between the server and the client program showing
>>> windows.
>>> >> By
>>> >> > messages? Or by hooking in directly on Xserver functions?
>>> >> >
>>> >> > Hope these questions are not too stupid :-) .. but's the only way
>>> to
>>> >> learn...
>>> >> >
>>> >> > -Martin
>>> >> >
>>> >>
>>> >> No these are fine questions you would need to know the guts of a wm
>>> to
>>> >> understand.
>>> >>
>>> >> All wm work by capturing events and drawing commands and
>>> configuration
>>> >> changes
>>> >> such as resizes and re-directing them through the wm for
>>> pre-processing.
>>> >>
>>> >> Directfb default and running X11 with no wm ( really the internal
>>> one)
>>> >> are the simplest.
>>> >> They draw no borders and process events as documented in the
>>> application
>>> >> api.
>>> >>
>>> >> Anything more than this and you need a shadow window or a way to
>>> draw
>>> >> a border and capture events in this border for resize etc. And of
>>> >> course other events like creation need to be captured to allow the
>>> wm
>>> >> to create the right border for the window. I think your finding that
>>> >> wm are actually fairly complex.
>>> >>
>>> >> What I mean by opening up the directfb API is that both X11 and
>>> >> Directfb assume a certain design for the wm built in. What people
>>> >> generally consider WM are actually privileged applications that hook
>>> >> various wm functions and redirect them to do further processing
>>> before
>>> >> generally calling back into the real wm and preforming the default
>>> >> action.
>>> >>
>>> >> The core design is written in stone so to speak in both however the
>>> >> hooks exported are fixed. For X11 this resulted in a new manager the
>>> >> composite manager which adds additional hooks to support alpha
>>> >> blending of window on screen. DFB by design already allows the wm to
>>> >> control compositing. My point is not who has the better design (
>>> DFB
>>> >> :) but that maybe the whole concept needs to be rethought. Why do
>>> we
>>> >> have too fix the design of the wm in the core architecture there are
>>> a
>>> >> lot of ways to build wm and design tradeoffs etc esp when your
>>> looking
>>> >> at embedded devices.
>>> >>
>>> >> X11's composite manager shows in a sense that you can go with a more
>>> >> primitive public api in the core and move most of what is hardcoded
>>> >> now in both X11 and directfb out as a variable design. What you
>>> >> really need at the core is actually quite simple.
>>> >>
>>> >> 1.) A unified list of all z order regions
>>> >> 2.) A hook when compositing is needed to callback to show these
>>> regions.
>>> >> 3.) A way to specify how these regions are drawn so the composite
>>> can
>>> >> happen without blocking on another process.
>>> >>
>>> >> Directfb is actually pretty close to right but it exports these z
>>> >> ordered regions as a application accesible api DFBWindows and it
>>> >> assumes all top level windows are buffered.
>>> >>
>>> >> So the changes on the directfb side are to recognize two things.
>>> >>
>>> >> 1.) All you need in the core is a unified list of these z ordered
>>> >> regions to run you composite
>>> >> manager. This is required.
>>> >> 2.) The composite manager really just needs a list of instructions
>>> for
>>> >> drawing a region when
>>> >> it composites blitting a buffer is simply one operation thats really
>>> a
>>> >> subset of a list of graphics primitives that could be performed in
>>> the
>>> >> simplest case you could have either fill rect or blit etc. The key
>>> is
>>> >> that at composite time the drawing instructions are fixed but they
>>> can
>>> >> be a complex list.
>>> >>
>>> >> Event handling is simply forwarded to the wm and no events are
>>> >> generated in the core.
>>> >> We don't even need to do hit detection in the core although helper
>>> >> routines can be provided see below.
>>> >>
>>> >> With this design how a wm works is no longer defined all that is
>>> >> defined the shared list of regions and a way to specify draw ops
>>> when
>>> >> you run the real composite algorithm.
>>> >>
>>> >> The WM also intercepts all request to create a "real" window and
>>> >> provides the hook for this.
>>> >>
>>> >>
>>> >> Now with all these changes the reason that its possible to embedded
>>> >> the wm in the core in the first place is generally you have a
>>> limited
>>> >> way to actually write a real wm so all this code can be moved out
>>> into
>>> >> a optional helper library or toolkit library for someone who wants
>>> to
>>> >> write a wm. This library in the case of directfb could create a
>>> >> default implementation of a DFBWindow and could have hooks to allow
>>> a
>>> >> alternative WM to wrap the default
>>> >> or of course the wm can do a custom version and simply reuse the
>>> code
>>> >> it needs from the library since its open source.
>>> >>
>>> >> With this design and some small changes to the X11 server which can
>>> >> now run full screen
>>> >> existing X11 wm can be used to manage directfb apps and new dfb
>>> >> centric wm can be developed that manage X11 windows. Since we have a
>>> >> wealth of X11 wm getting dfb embedded in the traditional desktop
>>> >> cleanly is my first priority.
>>> >>
>>> >> What this means is that on the X11 side you need to divert the hooks
>>> >> created for the composite manager extension to run back into dfb to
>>> >> create these regions.
>>> >>
>>> >> And if your creating a native dfb window it needs to defer to the
>>> X11
>>> >> server/wm to allow X11 to create a X window proxy for each region.
>>> >>
>>> >> You can see that by moving the wm implementation out of the core and
>>> >> just leaving the bare minimum you can now write a wm using any api
>>> you
>>> >> want and if you have the hooks any other api works as a "child" or
>>> >> slave wm to your chosen one. The interaction is cooperative between
>>> >> the supporting api's with the core providing the base level of
>>> >> cooperation which is the z order list and a way to declare the
>>> drawing
>>> >> commands.
>>> >>
>>> >> The ability of one wm to emulate another say the X11 wm api can in
>>> >> time probably be extracted as a simple library with a basic backside
>>> >> api. So if I write a pure dfb wm I should not have to do that much
>>> >> work to allow it to pose as a X11 wm. The directfb api is simple
>>> >> enough that the reverse allowing current X11 wm to create dfb
>>> windows
>>> >> is fairly easy.
>>> >> But again this can be moved into a support library. The exciting
>>> thing
>>> >> is this opens the door for custom embedded wm that export their own
>>> >> windowing api and support whatever current api they choose. A open
>>> gl
>>> >> dfb/desktop need only support managing these 2D z ordered surfaces
>>> for
>>> >> example and provide its own window api while still allowing DFB and
>>> >> X111 windows to function. In this case all of these 2D windows would
>>> >> be embedded in OpenGL surfaces.
>>> >>
>>> >> I'm interested for example in making all the windows part of a
>>> browser
>>> >> running full screen so in my case all windows would also show as
>>> tags
>>> >> in a dynamic full screen document.
>>> >>
>>> >> Thus the sky is the limit on how you actually write the WM and what
>>> it
>>> >> capabilities are and you have access eventually to simple libraries
>>> >> that allow existing apis such as X11 and DFB and others to run on
>>> your
>>> >> new "cool" desktop. All we need to do is make some small changes to
>>> >> directfb to remove some assumptions and expose basically the
>>> >> CoreWindow api to the WM and let it create the DFBWindow interface.
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> >
>>> >> > > On 1/16/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> >> > >> Seems you know more about the DirectFB architecture than I.
>>> >> > >> I will try to read up on that, if I can find any documentation.
>>> >> > >> Today I have tried to look a bit on other Window Managers and
>>> also
>>> >> found
>>> >> > >> and read the "Extended Window Manager Hints" specs, which both
>>> >> > >> KWin(KDE),
>>> >> > >> Metacity(Gnome), AfterStep and a lot of other WM's more or less
>>> >> adhere
>>> >> > >> to.
>>> >> > >>
>>> >> > >> It also helped me understanding where the line is between the
>>> WM
>>> >> and eg.
>>> >> > >> the Desktop. So perhaps we need to make a Desktop also? The WM
>>> in
>>> >> itself
>>> >> > >> seems to be more of a base on which to build a desktop.
>>> >> > >>
>>> >> > > The line is quite blurry generally the last part of a wm that
>>> makes
>>> >> > > the desktop is
>>> >> > > a plugin framework for applets that run on the desktop or root
>>> >> window.
>>> >> > > Most modern X11 wm seem to be basically full desktops outside of
>>> >> these
>>> >> > > applets.
>>> >> > >
>>> >> > >> I will continue to read about the existing WM's and looking a
>>> their
>>> >> code
>>> >> > >> in order to see if it would be possible to use any of them as a
>>> >> base,
>>> >> > >> converting all X-related functions to DirectFB calls. Ofcourse
>>> if
>>> >> we
>>> >> > >> want
>>> >> > >> to use an existing I suppose we better stick to those using
>>> LGPL
>>> or
>>> >> less
>>> >> > >> restrictive licences....
>>> >> > >>
>>> >> > >
>>> >> > > I went down this path already with metacity my conclusion is we
>>> >> needed
>>> >> > > to open up
>>> >> > > the design of directfb to create the wm foundation toolkit I've
>>> >> > > described to handle pretty much any wm design.
>>> >> > >
>>> >> > > My current approach is to first open the directfb api to allow
>>> X11
>>> >> to
>>> >> > > work well i.e allow X11 wm etc to function and manage all
>>> windows
>>> >> > > including dfb windows.
>>> >> > > For a non X11 wm I'd like to instead take a different approach
>>> and
>>> >> > > make WebKit the wm.
>>> >> > >
>>> >> > > The cool thing would be the whole desktop would be xml
>>> programmable.
>>> >> > > Its basically one
>>> >> > > big web page/ xul app. So directfb have a cooler desktop than
>>> anyone
>>> >> else
>>> >> > > :)
>>> >> > > A shared XML doc makes it much easier to do the detailed
>>> >> > > interoperability needed to pose as a X11 wm.
>>> >> > >
>>> >> > >
>>> >> > >> -Martin L
>>> >> > >>
>>> >> > >> > On 1/15/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> >> > >> >> Hi again
>>> >> > >> >>
>>> >> > >> >> Sounds like very reasonable and good considerations.
>>> >> > >> >> I actually started making a window manager which to some
>>> extend
>>> >> was
>>> >> > >> >> intendedn to be platform independent, but really in the
>>> first
>>> >> shot
>>> >> > >> was
>>> >> > >> >> intended for SDL (and perhaps then later make a OpenGL
>>> backend).
>>> >> > >> >>
>>> >> > >> >> However SDL does not have a Window concept and neither a
>>> multi
>>> >> app
>>> >> > >> >> possiblitity, so when I started to look into the latter I
>>> >> checked how
>>> >> > >> >> DirectFB was doing it and concluded that DirectFB would be a
>>> >> better
>>> >> > >> >> choice.
>>> >> > >> >>
>>> >> > >> >> The only thing I have programmed for DirectFB is trying to
>>> make
>>> >> an
>>> >> > >> X11
>>> >> > >> >> system, but it's only partly working. But making a WM for
>>> >> DirectFB
>>> >> > >> seems
>>> >> > >> >> like a real good project.
>>> >> > >> >>
>>> >> > >> >> Would it make sense to try to refine the design goals and
>>> after
>>> >> that
>>> >> > >> >> perhaps firsk make all header files and definitions before
>>> >> moving
>>> >> > >> onto
>>> >> > >> >> actual implementation?
>>> >> > >> >>
>>> >> > >> >
>>> >> > >> > My plan was to extract the current directfb wm out of the
>>> core
>>> >> and
>>> >> > >> > make it load as a plugin module.
>>> >> > >> >
>>> >> > >> > Currently the directfb wm is semi embedded in the core and
>>> half
>>> >> > >> > plugin. The problem is this means a lot of design decisions
>>> on
>>> >> the WM
>>> >> > >> > side are present in the core library.
>>> >> > >> >
>>> >> > >> > Instead the core should only be a composite manager
>>> responsible
>>> >> for
>>> >> > >> > showing the windows when needed.
>>> >> > >> >
>>> >> > >> > Right now the windows draw routine would be hooked to the
>>> buffer
>>> >> > >> > flipping but after the first set of changes is in it could be
>>> >> made
>>> >> > >> > into a generic draw list handler.
>>> >> > >> >
>>> >> > >> > On the interface side directfb exposes locking a assumed
>>> backing
>>> >> store
>>> >> > >> > for direct drawing but this is already a bit broken for sub
>>> >> windows
>>> >> > >> > since they can lock a parent buffer and draw through any
>>> sibling
>>> >> > >> > subwindows that overlap and of course it hands back the
>>> buffer
>>> >> pointer
>>> >> > >> > for the main window forcing you to figure out where you are
>>> on
>>> >> the
>>> >> > >> > root before you can draw.
>>> >> > >> >
>>> >> > >> > In anycase the window interface for directfb in my opinion
>>> needs
>>> >> more
>>> >> > >> > work and needs to be made more flexible but we can address
>>> this
>>> >> when
>>> >> > >> > we get to it.
>>> >> > >> >
>>> >> > >> > But the first steps are to simplify the core and ensure that
>>> the
>>> >> > >> > current api is supported as a module.
>>> >> > >> >
>>> >> > >> > My next step would be to alter my kdrive X11 server to be
>>> both
>>> >> full
>>> >> > >> > screen and defer to this new core composite manager when
>>> creating
>>> >> > >> > windows so that I can prove the new api can handle a
>>> alternative
>>> >> > >> > approach. Right now I plan to do this by building in the X11
>>> >> composite
>>> >> > >> > manager and making it defer to directfb or at least the guts
>>> of
>>> >> one.
>>> >> > >> > This would mean of course for X11 under directfb you can't
>>> use
>>> >> any X11
>>> >> > >> > composite manager but this should be the only difference
>>> between
>>> >> > >> > standard X11 and X11/directfb.
>>> >> > >> >
>>> >> > >> > The above is useful of course but more important it shows
>>> that
>>> we
>>> >> have
>>> >> > >> > created the right core composite manager support to run any
>>> >> windowing
>>> >> > >> > api on directfb with a good simple core api.
>>> >> > >> >
>>> >> > >> > The fun part is building out directfb window mangers
>>> customized
>>> >> to
>>> >> > >> > different types of devices
>>> >> > >> > and desktop styles. Done correctly any window management
>>> design
>>> >> should
>>> >> > >> > work.
>>> >> > >> >
>>> >> > >> > I did check in a branch that explored these concepts and more
>>> but
>>> >> its
>>> >> > >> > not useful more of a R&D project on my part to make sure its
>>> >> possible.
>>> >> > >> > On that branch I refactored a lot of code to show that its
>>> >> possible to
>>> >> > >> > rip various parts of the current core into libraries. I went
>>> way
>>> >> to
>>> >> > >> > far but I'm comfortable that we can do what we need to do.
>>> >> > >> >
>>> >> > >> > From that experience my suggestion is we start with the
>>> screen
>>> >> layer
>>> >> > >> > and add a new type that represents this composited object
>>> backing
>>> >> the
>>> >> > >> > window managers.
>>> >> > >> >
>>> >> > >> > We have used most of the english concept words such as layer
>>> and
>>> >> > >> > window for other stuff so the best I have now is
>>> CoreComposite.
>>> >> > >> > Other names for this are welcome. We may need to save
>>> CoreWindow
>>> >> for
>>> >> > >> > advanced wm interaction so we should keep the concept of this
>>> z
>>> >> > >> > ordered composited drawing area different.
>>> >> > >> >
>>> >> > >> > It should have the following.
>>> >> > >> >
>>> >> > >> > Z order position.
>>> >> > >> > A draw routine thats replaceable i.e accessed via a function
>>> >> pointer.
>>> >> > >> >
>>> >> > >> > The concept of bounds this could be complex i.e non
>>> rectangular
>>> >> or a
>>> >> > >> > alpha image along with a rectangular bounding box. So we
>>> probably
>>> >> need
>>> >> > >> > a new CoreBounds object that represents the region owned by
>>> the
>>> >> > >> > Composite. The composite manager just needs to know the
>>> >> rectangular
>>> >> > >> > bounds and if the composite is opaque for optimizing the
>>> >> rendering but
>>> >> > >> > we I think should store a complex object that can be provided
>>> by
>>> >> the
>>> >> > >> > wm along with a good default implementation.
>>> >> > >> >
>>> >> > >> >
>>> >> > >> > A mouse hit test routine that replaceable or better generic
>>> >> event
>>> >> > >> > handler concept.
>>> >> > >> > I'd like to defer as much event handling to the wm as
>>> possible
>>> >> but the
>>> >> > >> > core system should
>>> >> > >> > be able to find out who has focus etc. The important part is
>>> you
>>> >> > >> > should be able to find out which composite is active and also
>>> get
>>> >> > >> > enter/leave events from each composite.
>>> >> > >> >
>>> >> > >> >
>>> >> > >> > My plan for doing this was to introduce the CoreComposite and
>>> >> just
>>> >> > >> > default the rendering to fill a rectangle for testing. Also
>>> >> > >> > CoreComposites should nest without changes to the api or
>>> >> programming
>>> >> > >> > model. The drawlist concept could and I think should be built
>>> >> into the
>>> >> > >> > core as the default drawing routine with fillrect and the
>>> current
>>> >> > >> > buffer flipping as the basic routines supported in general
>>> all
>>> >> the
>>> >> > >> > core graphics ops could then be added.
>>> >> > >> >
>>> >> > >> >
>>> >> > >> > Then move the current CoreWindow api out into a module on top
>>> of
>>> >> the
>>> >> > >> > new CoreComposite.
>>> >> > >> > It would then simply register the buffer flipping as its
>>> drawing
>>> >> op
>>> >> > >> > and its current event handling as the event handler. At this
>>> >> point the
>>> >> > >> > current directfb api should be fully supported.
>>> >> > >> >
>>> >> > >> >
>>> >> > >> >
>>> >> > >> > So the core composite built into directfb would handle most
>>> >> programing
>>> >> > >> > styles for wm's and it is pluggable to allow the wm to
>>> replace
>>> >> objects
>>> >> > >> > and api's and still keep the correct CoreComposite api.
>>> >> > >> >
>>> >> > >> >
>>> >> > >> >> -Martin L
>>> >> > >> >>
>>> >> > >> >>
>>> >> > >> >> > Hi,
>>> >> > >> >> >
>>> >> > >> >> > I'm not a DirectFB hacker neither, but I would be
>>> interested
>>> >> too.
>>> >> > >> >> There
>>> >> > >> >> > have been some emails during November/December discussing
>>> this
>>> >> > >> issue.
>>> >> > >> >> >
>>> >> > >> >> > I think starting from scracth could be a good idea.
>>> "Unique"
>>> >> could
>>> >> > >> be
>>> >> > >> >> > useful just for having some ideas at the beginning of
>>> >> development.
>>> >> > >> >> >
>>> >> > >> >> > I think that a good starting point could be having a kind
>>> of
>>> >> > >> wish-list
>>> >> > >> >> of
>>> >> > >> >> > the things we want the DFB WM to do and how it will do it.
>>> >> > >> >> >
>>> >> > >> >> > A first draft could be the this list (points 4 and 5 were
>>> >> taken
>>> >> > >> from
>>> >> > >> >> Mike
>>> >> > >> >> > Emmel emails).
>>> >> > >> >> > These are only some fuzzy ideas that need a lot of work to
>>> >> make
>>> >> > >> them
>>> >> > >> >> real:
>>> >> > >> >> >
>>> >> > >> >> > 1. Provide a light, fast and reliable windowing system for
>>> >> > >> DirectFB.
>>> >> > >> >> >
>>> >> > >> >> > 2. Provide transparently the benefits of DirectFB
>>> >> > >> >> > - It's fast
>>> >> > >> >> > - It's light
>>> >> > >> >> > - It's stable
>>> >> > >> >> > - It has a small size
>>> >> > >> >> >
>>> >> > >> >> > 3. Capable to be used in embedded devices:
>>> >> > >> >> > - Reduced resources usage, specially memory and
>>> >> processor
>>> >> > >> >> > - Small foot-print
>>> >> > >> >> > - Support of small resolutions
>>> >> > >> >> > - Support of a full-screen windowing system
>>> >> > >> >> >
>>> >> > >> >> > 4. Refactor the code so all of the current wm is loaded as
>>> a
>>> >> shared
>>> >> > >> >> > library. Once this is done its up to the WM to provide the
>>> >> > >> DFBWindow
>>> >> > >> >> > interface implementation.
>>> >> > >> >> >
>>> >> > >> >> > 5. Consider expanding the concept of a window to be two
>>> parts:
>>> >> > >> >> > First a region for events.
>>> >> > >> >> > Next consider the current back buffer flip only one
>>> operation
>>> >> that
>>> >> > >> can
>>> >> > >> >> > be performed to show a window.
>>> >> > >> >> > The operator is a chain of primitives that is executed to
>>> show
>>> >> a
>>> >> > >> >> window.
>>> >> > >> >> > The default operator is to flip a back buffer but other
>>> >> operations
>>> >> > >> are
>>> >> > >> >> > possbile. The only restriction is that any needed
>>> resources
>>> >> such as
>>> >> > >> >> images
>>> >> > >> >> > would need to allocated in shared memory. The base set of
>>> >> operators
>>> >> > >> >> would
>>> >> > >> >> > be all the core drawing ops of directfb.
>>> >> > >> >> >
>>> >> > >> >> > For "secure" apps one operator would be a custom callback
>>> that
>>> >> > >> exists
>>> >> > >> >> > in a shared library loaded into the root process.
>>> >> > >> >> >
>>> >> > >> >> > Libraries like cairo could be used to generate advanced
>>> >> > >> >> drawing/blitting
>>> >> > >> >> > chains.
>>> >> > >> >> >
>>> >> > >> >> > 6. Support for GTK+
>>> >> > >> >> > If Cairo is the graphics rendering engine and the other
>>> >> GTK+
>>> >> > >> libs
>>> >> > >> >> > are available (Glib, ATK, ...) support can be provided
>>> for
>>> >> GTK+
>>> >> > >> >> > taskbars, statusbar, panels, icons and potentially
>>> Gnome
>>> >> apps
>>> >> > >> >> >
>>> >> > >> >> > 7. Support of virtual desktops
>>> >> > >> >> > In embedded devices it could become a full-screen
>>> windowing
>>> >> > >> system
>>> >> > >> >> >
>>> >> > >> >> >
>>> >> > >> >> > I hope in the following days to start working on it (as
>>> time
>>> >> and my
>>> >> > >> >> > real-job allow).
>>> >> > >> >> >
>>> >> > >> >> > Pedro Aguilar
>>> >> > >> >> >
>>> >> > >> >> >> Hi
>>> >> > >> >> >>
>>> >> > >> >> >> I would like to give a WindowManager for DirectFB a shot.
>>> >> > >> >> >> Could anyone give me a few pointers or things I should be
>>> >> aware
>>> >> > >> of.
>>> >> > >> >> >> Have a little experience with DirectFB, but not too much.
>>> >> > >> >> >> Should I use the "default" or "unique" WM as stating
>>> point
>>> or
>>> >> > >> none?
>>> >> > >> >> >>
>>> >> > >> >> >> How does DirectFB select a WM?
>>> >> > >> >> >> What kind of functions/API must the WM facilitate ?
>>> >> > >> >> >>
>>> >> > >> >> >> Regards Martin L�tken
>>> >> > >> >> >>
>>> >> > >> >> >>
>>> >> > >> >> >>
>>> >> > >> >> >> _______________________________________________
>>> >> > >> >> >> directfb-dev mailing list
>>> >> > >> >> >> [email protected]
>>> >> > >> >> >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
>>> >> > >> >> >>
>>> >> > >> >> >>
>>> >> > >> >> >
>>> >> > >> >> >
>>> >> > >> >> >
>>> >> > >> >>
>>> >> > >> >>
>>> >> > >> >> _______________________________________________
>>> >> > >> >> directfb-dev mailing list
>>> >> > >> >> [email protected]
>>> >> > >> >> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
>>> >> > >> >>
>>> >> > >> >
>>> >> > >>
>>> >> > >>
>>> >> > >
>>> >> >
>>> >> >
>>> >>
>>> > _______________________________________________
>>> > directfb-dev mailing list
>>> > [email protected]
>>> > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
>>> >
>>>
>>>
>> _______________________________________________
>> directfb-dev mailing list
>> [email protected]
>> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
>>
>>
>
>
>
> |-->
> Xlib
> -->
>
>
>
> WM
> (2) |-------------> X11 --|
> input | |----------- (kdrive) |
> event | |
> |--> xcb --+--> GTK+ apps (for X11)
> & msg | |
> |--> Qt apps (for X11)
> | | draw request
> | |
> | v (2)
> (1) DirectFB <----------------| draw
> (4)
> w/ CoreDrawable ---------------| | request
> ^ | input | |
> | | event v |
> | v & msg DirectFB ---+--> GTK+ apps
> (for DFB)
> mouse screen WM |--> Qt apps
> (for DFB)
> keyboard (3)
>
> _______________________________________________
> directfb-dev mailing list
> [email protected]
> http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
>
>
>
>
>
>
>
>
> ____________________________________________________________________________________
> Finding fabulous fares is fun.
> Let Yahoo! FareChase search your favorite travel sites to find flight and
> hotel bargains.
> http://farechase.yahoo.com/promo-generic-14795097
|--> Xlib --> WM
(2) |-------------> X11 --|
input | |----------- (kdrive) |
event | | |--> xcb --+--> GTK+ apps (for X11)
& msg | | |--> Qt apps (for DFB)
| | draw request
| |
| v (2)
(1) DirectFB <----------------| draw (4)
w/ CoreDrawable ---------------| | request
^ | input | |
| | event v |
| v & msg DirectFB ---+--> GTK+ apps (for DFB)
mouse screen WM |--> Qt apps (for DFB)
keyboard (3)
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
