On 1/18/07, nitram lutken.dk <nitramlutken.dk> 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 <mike.emmelgmail.com> wrote:
> >> On 1/17/07, nitramlutken.dk <nitramlutken.dk> 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, nitramlutken.dk
<nitramlutken.dk> 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, nitramlutken.dk
<nitramlutken.dk> 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
> >> > >> >> >>
directfb-devdirectfb.org
> >> > >> >> >> http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev
> >> > >> >> >>
> >> > >> >> >>
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >>
> >> > >> >>
> >> > >> >>
_______________________________________________
> >> > >> >> directfb-dev mailing
list
> >> > >> >> directfb-devdirectfb.org
> >> > >> >> http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev
> >> > >> >>
> >> > >> >
> >> > >>
> >> > >>
> >> > >
> >> >
> >> >
> >>
> > _______________________________________________
> > directfb-dev mailing list
> > directfb-devdirectfb.org
> > http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev
> >
>
>
_______________________________________________
directfb-dev mailing list
directfb-devdirectfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev
|