Thanks. Yes, GDK is just the wrapper of the lower libs say xlib and DFB. And I think the lower libs are just different, both in working principle and applying, though I don't know clearly the internal mechanism of DFB. So is it necessary to add the api to support X11 features? Or maybe I misunderstand your mean, if you just mean to add some APIs to support the "subwindows", it can't be too great. As for the "system" APIs on DFB referred, I don't have so many ideas for I'm not familiar with DFB. It seems that I should dive into the DFB to get out the working mechanism. Anyway, I want to find out why the pango layout text can't move smoothly on DFB.
-----Original Message----- From: Mike Emmel [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 4:07 PM To: ?? Cc: directfb-dev@directfb.org; directfb-users@directfb.org Subject: Re: [directfb-dev] Why expose event is triggered after gdk_window_move Yep this is probably true. One day when I get the time prob this spring I'll start working on how to add some hooks to directfb to support X11 concepts " Don't get exicted people" Not as a public api but as a internal api for supporting toolkits like GDK that are really just xlib wrappers. I think DirectFB has most things right except for subwindows. But it would make it a lot easier for porting these toolkit if we cleaned up and exposed the internal api some and at the same time added a few thing to the internal api to support porting X11 toolkits. Once I basically had the directfb-gdk working I came to the conclusion that trying to port a X11 centric api to DirectFB's public api is not a good idea internally it has basically everthing you need to do a good job and clean port of gdk with like I said a few additions. I also ran into the same problems working on the X11 directfb server surprise surprise :) And porting the meta-city wm to directfb. I did do a big experimental refactoring and it seems that with a bit of work its possible to create a good "system" api for libraries on directfb. Here is the general api I have in mine. 1.) Create a shared buffer manager that handles vram and the screen and whats in memory. 2.) Add a composite manager that gets called when a buffer wan'ts to flip. 3.) Allow arbitrary rendering to a shared offscreen buffer for stuff like window borders desktop icons etc. The composite manager can allow these rendering routines to hook regions. This buffer is generally the second buffer for the screen. 4.) Send up simple global input events Thats about all the support we need to support things like the X11 server and with a bit more GDK. This would make the X11 server the native directfb api's and gdk basically peer api's on top of this core library api. DirectFB windows could be implemented easily enough but would allow you to say have a library that support both "native" X11 window and the directfb api if you wanted. Finally with the XCB port of gdk avialable the simplest port is to support XCB native. http://xcb.freedesktop.org/wiki/ Since they have xlib on xcb this gives you a x application api with no xserver. And we can just use the gdk xcb port. A stripped xcb x11 lib is 90K since I'd be right in the core of directfb supporting the api directly would mean a even smaller library say 60k max. Considering the size of even gdk. this little bit of glue code is worth the price IMHO. Anyway figured I'd give you my thoughts. Mike On 11/21/06, ?? <[EMAIL PROTECTED]> wrote: > Thanks for response. > If DirectFB doesn't send "expose" notification, then the "expose" must be > triggered in Gtk. > And, the key point is, the text drawn with pango layout seems stay still > when its window moves on DirectFB. > Have found this, we just know more about why the menu can't scroll on > DirectFB. But we still have no idea how to fix it. > > > > -----Original Message----- > From: Mike Emmel [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 22, 2006 3:01 AM > To: ?? > Cc: directfb-dev@directfb.org; directfb-users@directfb.org > Subject: Re: [directfb-dev] Why expose event is triggered after > gdk_window_move > > Its simulated from the move event. Probably incorrectly since it > should just trigger on a resize not a move. DirectFB does not have the > concept of expose so its a bit of a hack to support it. Probably what > needs to be added is when a surface is new i.e just created/resized or > changes its opacity DirectFB should send a event to redraw the > surface. > I don't think we get this sort of notification now. > > > > On 11/13/06, ?? <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Hello, everyone, > > > > > > > > Based on DirectFB, when calling gdk_window_move in > > gtk_menu_scroll_to in gtkmenu.c, the expose event is triggered on menu. > Who > > does it? > > > > Is it the gdk_directfb_window_send_crossing_events > > function in gdk_window_move in gdkwindow-directfb.c. > > > > Thanx in advance. > > > > > > > > > > --------------------------------------- > > > > Best Wishes! > > > > > > > > Zhang Hui > > > > Email: [EMAIL PROTECTED] > > > > Phone: 86-25-58748787-8215 > > > > Samsung Electronics(China) R&D Center > > > > --------------------------------------- > > > > > > _______________________________________________ > > directfb-dev mailing list > > directfb-dev@directfb.org > > http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev > > > > > > > > > _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
