Hi,
I am in.
I have collected all the information that I could lay my hands on, in
this regard on DFB discussion groups.
Please find it attached.
Regards,
Nitin Sharma
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pedro Aguilar
Sent: Friday, December 01, 2006 2:29 PM
To: Arvind Ayyangar
Cc: [email protected]
Subject: Re: [directfb-dev] window mnager for directfb
Hi,
If you try to port any X based Window Manager you will find a lot of
problems because the way X works is completely different to DFB. They
were designed with different paradigms in mind.
I had a look at different WM, the ones that I think were more suitable
for being ported: WindowMaker, Blackbox, Openbox and Matchbox. Since
Matchbox was designed for PDAs it seemed the better choice, but at the
end all of them have the problem of being designed for X.
Mike Emmel had a similar problem with Metacity:
http://mail.directfb.org/pipermail/directfb-dev/2006-November/002455.htm
l
DFB has a windowing system that could be a good starting point for a WM.
I'm interested in giving it a try.
Regards,
Pedro Aguilar
> hi,
> i am trying to port the matchbox window manager which is designed
> specifically for the embedded environment and ran int a lot of
> conceptual issues. As I posted earlier, i tried to send these event
> through a socket and then tried to use the current dfb api's to manage
> windows. But the problem is that both the default window manager and
> my WM are handling the events and after a period of time I find either
> more than one window in focus or no window in focus at all.
> Can someone plz throw some light on this?
>
> also, si it possible to disable the default WM in DFB?
> any recommendation/tip?
>
>
>
>
> Regards
> ARviND AyyangaR
> _______________________________________________
> 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
=============================================================
CURRENT WINDOW MANAGEMENT FUNCTIONALITY IN DEFAULT WINDOW MANAGER
AS PER THE RELEASE NOTES
=============================================================
Since DirectFB lacks a real window manager, we added a hack to the
window stack to allow for basic window management. While pressing
the (or Windows) key or alternatively you can do
the following:
- Drag your mouse to move the focused window.
- Drag and press to resize the focused window.
- Drag and press to change the opacity of the focused window.
- Press C to close the focused window.
- Press A to lower the focused window to the bottom.
- Press X to cycle the focus through the windows.
- Press S to raise the lowest window to the top.
- Press P to enable and show the mouse cursor.
- Press E to focus the window currently under the mouse cursor,
useful in conjunction with 'X'.
- Press Escape to return from fullscreen mode to the desktop.
(currently not advisable if the fullscreen app is still flipping)
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-January/001318.html
=============================================================
I'd like to se unique broken into two parts first a reparenting window manager
that allows for window decorations then a implemenation that has
certian decorations and controls.
The implementation could then manage the windows how it sees fit.
The reparenting is even useful on something as small as a cell phone where
you want to almost always show a system keybar at the bottom and
signal strength. So I used a similar concept even on pretty small
devices.
Mike
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2005-December/001230.html
=============================================================
Mike Emmel wrote:
> On 12/29/05, Alex Lau <alex at avengergear.com> wrote:
>> Dear all
>> long time no see
>> and wonderful work with the GTK2.8!! :)
>> I get vte and scim running on top of it displaying and inputing
>> chinese and everything.
>>
>> Since gtk is working I'm also trying out the unique with gtk and of
>> course :) I will try to see I can submit some upgrade on the window
>> manager but there are couple questions I would like to ask here ...
>>
>> Will unique going to be a full features wm?
>> Or back porting gnome desktop? and let gnome take care of it?
>>
> Gnome won't supply the window manager it uses the X11 window manager
> so you still need a directfb window manager.
> I'd suggest that you branch the unique window manager and make your
> own that fits your needs. I'm not sure what platform your targeting.
> You could consider the metacity window manager
> http://ftp.gnome.org/pub/gnome/sources/metacity/2.4/
> You would need to port it to directfb.
>
I'm new to the window manager concept, any thing I can read from?
If I'm going to port metacity do I need to extend unique first?
if I'm going to extend unique .... do I still need metacity?
Thanks I'm a little unclear about the relationship, please forgive me.
>> Then is a more important issue to me :)
>> I'm also trying put scim (a input method) into directfb/gtk since there
>> isn't any default wm layer for me to put in the input, I can only do
>> some kind of hack for it but that will break the directfb api or limit
>> the scim ability. However if unique is availible then we can add a
>> plugins to the input layer.
>> Then I can really run directfb app with chinese input :)
>>
>
> There is a root window.
> In gdkwindow-directfb.c see the _gdk_parent_root variable
> its set in the function _gdk_windowing_window_init
>
> You should get it from the public api.
> gdk_get_default_root_window
>
> Then you need the headers right now and the following code snippet
>
> GdkWindowObject *private;
> GdkWindowImplDirectFB *impl;
>
> g_return_if_fail (GDK_IS_WINDOW (window));
>
> private = GDK_WINDOW_OBJECT (window);
> impl = GDK_WINDOW_IMPL_DIRECTFB (private->impl);
>
> impl->window
>
> Is the DirectFB window.
> I did not find a exported function to get to the window but
> we can add one if needed just let me know if this suites your needs
> and you can add a function to gdkwindow-directfb.c or I can.
>
>
Actually I can run scim directly with gtk app on directfb now by using
gtk im module directly.
except I can't test it on console, it crash all the time :)
but in SDL it seem to be a bit more stable
Another funny thing is when I start the input panel first with directfb
then start the gtk app ( even on X or directfb ) I can get the input
panel display correctly ( pretty much ), however if I start the gtk
directfb app directly ( immodule will start the input panel if it is
not started ), the input panel will not draw correctly ... right hand
side of the panel will be corrupted.
I'm not sure exactly why :)
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-January/001231.html
=============================================================
On 12/31/05, Alex Lau <alex at avengergear.com> wrote:
> Dear all
> Happy New Year !!
>
> Mike Emmel wrote:
> > On 12/29/05, Alex Lau <alex at avengergear.com> wrote:
> >> Dear all
> >> long time no see
> >> and wonderful work with the GTK2.8!! :)
> >> I get vte and scim running on top of it displaying and inputing
> >> chinese and everything.
> >>
> >> Since gtk is working I'm also trying out the unique with gtk and of
> >> course :) I will try to see I can submit some upgrade on the window
> >> manager but there are couple questions I would like to ask here ...
> >>
> >> Will unique going to be a full features wm?
> >> Or back porting gnome desktop? and let gnome take care of it?
> >>
> > Gnome won't supply the window manager it uses the X11 window manager
> > so you still need a directfb window manager.
> > I'd suggest that you branch the unique window manager and make your
> > own that fits your needs. I'm not sure what platform your targeting.
> > You could consider the metacity window manager
> > http://ftp.gnome.org/pub/gnome/sources/metacity/2.4/
> > You would need to port it to directfb.
> >
> I'm new to the window manager concept, any thing I can read from?
> If I'm going to port metacity do I need to extend unique first?
> if I'm going to extend unique .... do I still need metacity?
> Thanks I'm a little unclear about the relationship, please forgive me.
>
On any multi windowed platform there is a need to manage the windows.
In the simplest case there needs to be a single list some where to
manage the stacking order.
Window Managers do a few things.
1.) Maintain a list of all the windows open for all apps.
2.) Dispatch key and mouse events to the active window plus manage the
active window
3.) Some also manage drawing the decoration around the active window
this is generally done by actually adding a new window that the
application window is a child of.
4.) Window managers generally only manage whats called the top level
windows these can be defined as windows that can overlap or cover the
windows of another application and that have as there parent the root
window or a window manager provided decoration window.
Unique is a good one to study since directfb really simplifies wm
design. Another is twm most X11 window managers are derivatives of twm.
My sugesttion to port meta city is to simply use the theme handling
with a deriviative of unique not the internals of a X11 window manager.
I looked at meta-city its pretty simple for a X11 window manager.
I'd say the key method your intrested in is
meta_frames_manage_window in frames.c
Thats where you would want to start porting everything below here is
pretty x11 specific
and above should be okay.
The key call is
gdk_window_foreign_new
In our case that would be a native DirectFB window.
> >> Then is a more important issue to me :)
> >> I'm also trying put scim (a input method) into directfb/gtk since there
> >> isn't any default wm layer for me to put in the input, I can only do
> >> some kind of hack for it but that will break the directfb api or limit
> >> the scim ability. However if unique is availible then we can add a
> >> plugins to the input layer.
> >> Then I can really run directfb app with chinese input :)
> >>
> >
> > There is a root window.
> > In gdkwindow-directfb.c see the _gdk_parent_root variable
> > its set in the function _gdk_windowing_window_init
> >
> > You should get it from the public api.
> > gdk_get_default_root_window
> >
> > Then you need the headers right now and the following code snippet
> >
> > GdkWindowObject *private;
> > GdkWindowImplDirectFB *impl;
> >
> > g_return_if_fail (GDK_IS_WINDOW (window));
> >
> > private = GDK_WINDOW_OBJECT (window);
> > impl = GDK_WINDOW_IMPL_DIRECTFB (private->impl);
> >
> > impl->window
> >
> > Is the DirectFB window.
> > I did not find a exported function to get to the window but
> > we can add one if needed just let me know if this suites your needs
> > and you can add a function to gdkwindow-directfb.c or I can.
> >
> >
> Actually I can run scim directly with gtk app on directfb now by using
> gtk im module directly.
> except I can't test it on console, it crash all the time :)
> but in SDL it seem to be a bit more stable
>
> Another funny thing is when I start the input panel first with directfb
> then start the gtk app ( even on X or directfb ) I can get the input
> panel display correctly ( pretty much ), however if I start the gtk
> directfb app directly ( immodule will start the input panel if it is
> not started ), the input panel will not draw correctly ... right hand
> side of the panel will be corrupted.
> I'm not sure exactly why :)
>
I'm seeing that too right now it seems to be caused by apps that use
the older clist and ctree
widgets not the newer tree widgets. I'm working on it.
Also you may want to read the cvs log email I'm doing a lot of work on
gtk over the next few weeks hopefully I can fix any bugs that cause
you problems.
In any case if you start on the project I'm willing to help. My time
is limited but I once wrote a X11 window manager in java :) And I've
written numerous embbeded window managers.
Mike
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-January/001299.html
=============================================================
I'm not sure this is a right fix but some how in the gtkfb
the unique will create a decorate window as big as screen
and not visible, so when you click on the foo it will call
the grab window and the pointer input channel will be switch
to a invisible layer, so I put a test of the window->opacity
before the switch
--- window.orig 2006-01-06 00:39:21.000000000 +0800
+++ window.c 2006-01-06 00:38:41.000000000 +0800
@@ -492,8 +492,13 @@
UDCI_KEYBOARD,
window->channel );
case CWMGT_POINTER:
+ if( window->opacity )
return unique_input_switch_set( context->input_switch,
UDCI_POINTER,
window->channel );
+ else {
+ //printf("Alex say this is not good so don't set!\n");
+ return DFB_OK;
+ }
case CWMGT_KEY: {
DFBResult ret;
Alex Lau wrote:
> I find out the id of the window and the decorator is two different thing
> and when I click on the decorator the decorator window seem to get all
> the input and not able to give it back to the window.
> how should I handle that?
>
> I put some function in unique/window.c, I'm not sure it is correct.
> e.g. move windows and change opacity
>
>
> Thanks
> Alex
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-January/001311.html
=============================================================
Well, the default WM also allows pointer grabbing by invisible windows...
The real problem seems to be that gtk doesn't cope with the event
outside of its window and redirects it to the root window :-(
But the foo stuff in Unique is not finished, it's a placeholder
or at least experimental. It's too concrete as Unique should be
the framework for all different kinds of decorations, implemented
outside of or at least as a plugin for Unique.
In the end, the events of the decorations shouldn't go to the
window's input channel, but to a dedicated input channel for
the decoration implementation.
Parts of the decoration code will be run in the master, other
parts in the slave (owner of the window). For example, moving
should be done in the master, while resizing should be done by
each slave itself, to preserve the nice synchronous resize/repaint
that you have e.g. with LiTE today.
If the master resizes the window and the slave receives the event
and repaints the window, you will see a lot of flashing and other
artifacts when there is a new resize before the old one got handled.
Synchronization would be very complicated and drag the performance
down. It's better to send only resize requests to the slave and have
it resize/repaint itself.
--
Best regards,
Denis Oliver Kropp
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-January/001320.html
=============================================================
I don't think I have enough information from GTK to know if a widget
has consumed and event during a grab or if it should be handled by
the system. Generally when a grab is on if the mouse has activated a
system widget then it still gets events.
As you mentioned in the rest of the post the system needs to manager
its own system focus. I'd be happy to see if there is something we
could do to fix this just not sure its possible. I don't like grabs as
far as I know any window system that allows grabs also opens up cases
where the app can lock up the window system.
Mike
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-January/001321.html
=============================================================
Until you press <Meta>-P to force a release of the grab :)
It also shows the cursor if it's hidden, but it doesn't set
a shape. So an empty shape might still make you crazy...
--
Best regards,
Denis Oliver Kropp
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-January/001330.html
=============================================================
Dear Denis
After I look more carefully with the unique and compare with default,
I think I have done it all wrong in unique/window.c
instead I should handle all the input process in unique.c
wm_process_input<-- now it is empty
I'm wondering you are doing that for a reason, are you not wanted to
process the input the way you wanted like default? And use some kind
of plugable way to handle all the event and make it more configurable?
I'm still trying to hand improving the unique, but I understand too
little about it.
Thanks
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-January/001335.html
=============================================================
While your at it :)
Gdk has two methods called
gdk_window_set_keep_above
gdk_window_set_keep_below
What there for is to prevent a dialog or important window from being hidden
by its parent window. The semantics are different from the concept of
windows in multiple layers so if we really want to support this
correctly it needs to be done in the window manager. The other issue
is drag and drop.
Maybe Denis can comment on these issues ?
Just wanted to bring this up since it looks like your going to be
mucking around quite a bit with unique.
Next I got the gtk-webcore to compile under using the gdk-directfb
libs while taking a break from gtk bugs. I'm going to go ahead and see
what I can get hooked up tomorrow then try to check it in to the
directfb cvs as a new project so others can bang on it. If I don't get
it in tomorrow then I won't be able to do anything till next thursday
I'm going to be traveling for a few days giving the mailing list a
break :)
Mike
On 1/7/06, Denis Oliver Kropp <dok at directfb.org> wrote:
> Alex Lau wrote:
> > Dear Denis
> >
> > After I look more carefully with the unique and compare with default,
> > I think I have done it all wrong in unique/window.c
> > instead I should handle all the input process in unique.c
> > wm_process_input<-- now it is empty
>
> wm_process_input() was the old way to pump input events to the wm.
>
> >
> > I'm wondering you are doing that for a reason, are you not wanted to
> > process the input the way you wanted like default? And use some kind
> > of plugable way to handle all the event and make it more configurable?
> > I'm still trying to hand improving the unique, but I understand too
> > little about it.
>
> Indeed, in Unique I wanted a plugable way for input devices.
>
> I'm happy that you want to join Unique development :)
>
> I will provide you with more info, e.g. answer the other questions on
> the mailing list, but for now, did you read the documents in the source
> directory of unique?
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-January/001337.html
=============================================================
agree in both regards I think there is a strong case for a WM api if
one is present.
These are two use cases. Also if you remember are talk about inter app ipc.
I'm not agianst it being part of the WM api since I can't see running
two apps without at least a basic window manager ???
Since you would like a concept of all of a apps windows and other similar stuff.
Am I correct that right now if you use windowing you have to have one
of the window managers running. I.e it does not work without one.
Mike
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-January/001340.html
=============================================================
Denis Oliver Kropp wrote:
> Alex Lau wrote:
>> Dear Denis
>>
>> After I look more carefully with the unique and compare with default,
>> I think I have done it all wrong in unique/window.c
>> instead I should handle all the input process in unique.c
>> wm_process_input<-- now it is empty
>
> wm_process_input() was the old way to pump input events to the wm.
>
>>
>> I'm wondering you are doing that for a reason, are you not wanted to
>> process the input the way you wanted like default? And use some kind
>> of plugable way to handle all the event and make it more configurable?
>> I'm still trying to hand improving the unique, but I understand too
>> little about it.
>
> Indeed, in Unique I wanted a plugable way for input devices.
>
Good :) , do you want to implement a complete ldopen type library for
plugins or directrc type script environment update?
> I'm happy that you want to join Unique development :)
>
> I will provide you with more info, e.g. answer the other questions on
> the mailing list, but for now, did you read the documents in the source
> directory of unique?
>
Yes I think I did, beside FLOW IDEAS and STRET are there any?
Maybe I'm not too familar with the terms :) A lot of pieces I still
don't understand. But that is why I started to implement the move and
resize in window.c because in IDEAS you talk about UniqueWindow being
handle those min/mix etc. Let me know if there is more doc I can read it
from. Thanks :)
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-January/001325.html
=============================================================
Thanks for the reply,
I guess the real fix should be within gdkdfb and I will take a
look at it.
Then next question come to the handling the window moving,
should I handle the foo input inside the class/foo.c
and then dispatch the input as normal ( right now I handle
all the widget moving and resizing in the window.c
And when you saying send the resizing to the slave window
does it mean e.g. send resize window to the gdk? (in my case )
I see the foo get input channel also, and when you say decoration
input channel.. are they the same thing you are talking about?
Final question what is the use of the unique_window_notify?
Also the unique_window_dispatch function seem to be empty! :)
and it case seg fault and not exit normally with unique enable.
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-May/001822.html
=============================================================
Mike Emmel wrote:
> In working on the Xserver and finally starting on my own window
> manager I found that it looks like it would be really useful to add a
> SetVisible method to window this would allow the window manager to
> hook setting the opacity so it could for example fade in and out the
> window or perform some other transition like OSX does a 3D crumple. I
> also noticed were missing minimize.
>
> So I propose we add
>
> SetVisible
>
> Not sure for minimize/maximize/fullscreen ?
>
>
> maybe a SetWindowState ( mask )
>
> In fact we could simple add just SetWindowState that takes a mask it would
> have
>
> NORMAL
> MINIMIZED
> MAXIMIZED
>
> HIDDEN
> SHOWN
These multiple choices shouldn't be in a mask or even in one.
They're two enums. It would become awkward to change one item.
You also have to ensure only one flag is set in each group.
> And probably more but if we add the SetWindowState function with a mask we can
> add more as needed.
Instead of one mask we should provide an array of attributes
which can be ints, enums or whatever. Still one single function
to set an attribute identified by its id (index).
Attributes could be introduced at runtime, maybe by the wm.
--
Best regards,
Denis Oliver Kropp
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-June/001900.html
=============================================================
Hi all I've been working on a new window manager for directfb based on metacity.
And also looked deeply at the current implementation. My conclusion
was that we needed to
add the concept of insets to make it easy to support borders. This
approach seems far simpler
to the current ones. Also in the case that the wm does not want to use
insets it has little impact on the implementation.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dfbwm.patch
Type: text/x-patch
Size: 13147 bytes
Desc: not available
Url :
http://mail.directfb.org/pipermail/directfb-dev/attachments/20060609/8c03a550/attachment.bin
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-June/thread.html
=============================================================
> Denis Oliver Kropp wrote:
> > Mike Emmel wrote:
> >> Agian please give me some feedback in the inset approach.
> >
> > Yes, it's a nice tiny extension with a great benefit.
> >
> > Is it transparent to the application, i.e. does a GetSurface()
> > on the window return a sub surface instead of including the insets?
>
> Just had a look at the patch again, it's transparent :)
>
I prefer to say it has a alpha value of zero but hey maybe I've
done too much graphics programing :)
Okay I'll land today.
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-July/002127.html
=============================================================
My point is its very wrong to have subsurfaces that don't have backing stores.
The problem is we can't handle overlap of subsurfaces correctlly.
The reality is there badly broken.
Allowing buffering of subsurfaces is one part of fixing there use.
Next buffered or not when you flip a subsurface you need to allow
a compisite strategy to deal with sibling surfaces that overlap even
if your subsurface is not buffered.
I'm adding two things.
1.) Allow a subsurface to be a first class surface and set its own
buffering desc.
We can work on api and how different a subsuface is from its parent.
Basically a subsurface is simply a surface that has a position on a parent and
can share its parent surface or not.
2.) Overlap is now allowed for subsurfaces and can be correctly
handled it was not before.
This is done by introducing a composite manager.
With work we can handle all cases from only a single front buffer not
double buffering
your classic drawing mode. Classic unbuffered drawing is not quite supported
since you have to wrap all graphics calls and generate exposes. I feel
right now the
classic case does not need to be supported directly since this is
really the province
of a window manager and outside the scope of surfaces execept to record the
surface overlap information thus the wm would handle clipping and
exposes if your
completely unbuffered.
On 7/23/06, Claudio Ciccani <kl
=============================================================
http://mail.directfb.org/pipermail/directfb-dev/2006-July/002135.html
=============================================================
Composition in DirectFB is already done by the window manager, we don't
> need an additional manager. If you want to allow the user to specify
> composition rules (shadows and co.), simply write a window manager that
> supports user's rules. That's all.
>
Overlapping subsurfaces are possible today with our current api.
And there handled incorrectly.
Maybe I should say WindowManager writer instead of user.
----------- Can't support Painter's algorithm -----------
=============================================================
http://www.directfb.org/index.php/mailinglists/directfb-dev/2002/11-2002/msg00107.html
=============================================================
[directfb-dev] Re: Proposal: a native DirectFB window manager
* To: [email protected]
* Subject: [directfb-dev] Re: Proposal: a native DirectFB window manager
* From: Hallvar Helleseth <[EMAIL PROTECTED]>
* Date: Tue, 19 Nov 2002 14:00:31 +0100
* Content-disposition: inline
* Content-type: text/plain; charset=us-ascii
* In-reply-to: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Tue, Nov 19,
2002 at 01:51:54AM +0000
* References: <[EMAIL PROTECTED]>
* Sender: [EMAIL PROTECTED]
* User-agent: Mutt/1.2.5.1i
Quoting Pokey the Penguin <[EMAIL PROTECTED]>:
> I'm interested in putting together a "native" universal DirectFB window
> manager that's capable of managing native DirectFB windows (including
> Gtk+-DirectFB windows) in addition to XDirectFB windows.
So am I :) when I get the time... :(
> I'd like to make sure that this new window manager is fully configurable
> from the get-go using XML configuration files, in a similar vein to
> Metacity, and perhaps supporting SVG for vector window decorations in
> addition to PNG. Hopefully, DirectFB (as a desktop UI) would never need
> more than One True Window Manager.
Wouldn't SVG Image provider work? (I don't know too much about SVG)
> Is anyone working on a similar project? If so, it's best to avoid
> duplication. Also, do you have any suggestions for the implementation?
> Are there hooks in place to cater for a DirectFB native window manager,
> and if so, where are they? Should I try to separate this package from
> the core DirectFB source package?
I've been playing around quite a bit trying to make a window manager (and also
more desktop things like root menu, panel, clock, cpu/mem monitor, etc...).
I've sort of packed them together in one program - everything is a plugin, the
WM too.
So far I've got a fairly nice IMHO themeable windowdecoration code. (Uses Edb
(easy&fast loading), maybe XML is better?). But DirectFB doesn't have the
necessary features to make it usefull as a universal window manager. DirectFB
needs to have a more complete window description (title, border-type, max/min
size, etc). Also it lacks code too let the WM know about the windows DirectFB
has... (If you know what I mean?). And as discussed on this list a few weeks
ago there needs to be a better way to decorate a window (haveing seperate
surfaces attached to the window, instead of creating border-windows around the
window).
I'm usually a bit unclear but I hope you get the picture.
You're probably interested in the code... I'd love to share it and maybe we
could make a joint effort? (I don't have much spare time ATM though...)
Since the code currently is on a my home computer, without an Internet
connection I can't promise I can send the code anytime too soon, sorry! but
I'll see what I can do.
Hallvar Helleseth
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
=============================================================
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
