Hi Owen, it continously appears to me that I don't make myself clear. Hopefully the attached patch is enough in the spirit of Gtk+ that it finally will become acceptable. If this second try doesn't show up the right direction I'm afraid I won't be able to fix the gtk/win32 build myself. At 17:07 10.05.02 -0400, Owen Taylor wrote: >Hans Breuer <hans breuer org> writes: >> [...] > [...] > >The trouble is, a GDK backend just isn't a simple thing; >GDK is a complex library, with complex interactions wiht >GTK+. Someone has to really care about it. > Oh really. Never noticed this ... >A good portion of the difficulty does come about from the fact that >the GDK <=> GDK backend interface is an ugly mess. If I >was doing it again from scratch, I'd probably think about >changing things so that all shared function implementations >lived in GDK, and a backend author implemented: > > - gdk_open_display() > - A whole bunch of virtual functions in subclasses > of GdkDisplay, GdkScreen, GdkColormap, etc. > All these GdkDisplay, GdkScreen, GdkColormap, etc. [changes] were just added recently. I thought we were disussing how it could be improved with single head backends in mind. >But fixing this would be a huge job, and cause a lot of intermediate >pain, and just isn't worth it for the forseeable future. > See: Fowler, Refactoring >Even if we had a clean setup like that, I don't see trying >to freeze the GDK<=>backend API as being reasonable ... >the only way to do that would be not to add features to GDK. > This wasn't what I suggested or had in mind. But learning from one working port how to make it simpler for the next port seems to be the right goal (at least for me) >If you know of a single place where the GDK API/ABI broke, or >if the X11 backend doesn't compile for you, please file >a bug report. > Isn't changing the size of public structs like GdkVisual and GdkColormap an ABI breakage ? >The last thing that the GDK needs is more inconsistency between the >way different things are done. > >We are talking about a few dozen functions. I could do the fixups for >all three backends in a couple of hours of work. Compared to harmful >leaving excess duplication all over the code, this is a tiny amount of >work. > Wow. It took me some hours more to only get only the win32 backend back to work, which means you are at least three times faster than me. May I offer you a job in Munich ? :-) >> >> With this goal in mind there >> >> are some places where it could get huge improvements if the >> >> multi-head api isn't inscribed in stone yet : >> >> >> >> gdk_colormap_get_screen() >> >> Only the multi-head version needs to store a screen with >> >> every colormap. Single Head version would return the >> >> default screen. [The GdkScreen* field from the GdkColormap >> >> struct could be removed and the multi-head version would >> >> maintain it's own hashlist to remember the Colormap/Screen >> >> relations.] >> >> >> >> gdk_visual_get_screen() >> >> Same logic as for gdk_colormap_get_screen(), removing >> >> GdkScreen* from _GdkVisual struct, whiches content needs to be >> >> maintained by the backend. >> > >> >We could move the GdkScreen structure in to the X11 private >> >part ... I don't really see much of a difference though. >> > >> The point: Currently every backend needs to maintain information >> for the common case, which isn't at all relevant at single-head. >> See: gdk/win32/gdkcolor-win32.c gdk/win32/gdkvisual-win32.c > >The number of colormaps and visuals just isn't big enough to >worry about 4 bytes extra per object... might be a waste of >50 bytes for the app. > I wasn't worring about the size of these objects but about the ABI breakage and the clumsiness to manage information only required in the special case X11/multihead in every backend. >> [...] >I'm not going to say I care about the *least* possible impact >on backend author. I certainly do care about possible impact >in backend authors. But the priorization goes something like: > > * ABI and API compatibility > * Providing a nice clean API for app devlopers. > * Providing new features as needed > * Keeping the code clean and maintainable > * Minimizing code changes for backend authors > * ... > Sounds reasonable. >> If the above arguments still don't make my point clear do you >> think a patch implementing the goals (but possibly breaking >> the X11 backend) could help ? > >I don't want to come across here as being inflexible, but I'm not >sure I can avoid it ... I'm not going to accept a patch that doesn't >move gdk_beep() to gdk/ and make it a wrapper for gdk_display_beep(). > >Within that constraint, I'm happy to look at patches that break the >X11 backend, though I wouldn't want to commit one without having a >plan for getting X11 compiling again within a short period of time. > Patch attached. Remaining todo for function moving: gdk_flush, gdk_window_lookup, gdk_colormap_get_system_size, ... Missing implementations in the X11 backend: gdk_colormap_get_screen(), gdk_visual_get_screen () Hans *** ChangeLog entry *** 2002-05-09 Hans Breuer <hans breuer org> [allow to use gtk-multi-head with single-headed win32 backend. Also moving some generic functions to the gdk/* part] * gdk/gdk.def : updated externals * gdk/gdkcolor.c : add gdk_colormap_get_system() gdk/x11/gdkcolor-x11.c : removed here gdk/win32/gdkcolor-win32.c : changed to have gdk_screen_get_system_colormap () * gdk/gdkcolor.h : removed screen field from _GdkColormap added prototype gdk_colormap_get_screen() * gdk/gdkdisplay.c : adapted GdkDisplay base class to serve single head version. Also added some single head compatibility wrappers formerly spread over the backends * gdk/gdkevents.c : added gdk_setting_get() gdk/x11/gdkevents-x11.c : removed here gdk/win32/gdkproperty-win32.c : adapted implementation to be gdk_screen_get_setting () * gdk/gdkfont.c : added gdk_font_from_description() and gdk_font_load () * gdk/x11/gdkfont-x11.c : removed here * gdk/win32/gdkfont-win32.c : adapted to the variants taking a screen parameter * gdk/gdkimage.c : added gdk_image_new () gdk/x11/gdkimage-x11.c : removed here gdk/win32/gdkimage-win32.c : removed here. (_gdk_image_new_fror_depth) : added GdkScreen* parameter * gdk/gdkkeys.c : added gdk_keymap_get_default() gdk/x11/gdkkeys-x11.c : removed here gdk/win32/gdkkeys-win32.c : adapted to be *_for_display * gdk/gdkpixbuf-render.c gdk/gdkpixmap.c : use gdk_colormap_get_screen () * gdk/gdkrgb.c : use gdk_visual_get_screen () * gdk/gdkselection.c : (new file) for generic selection functions * gdk/gdkscreen.c : implement default behaviour (single head in base class). A little hackish cause it's using the old single head function for implementations. * gdk/gdkvisual.c : (new file) for generic visual functions * gdk/gdkvisual.h : remove screen field from GdkVisual add prototype for gdk_visual_get_screen() * gdk/gdkwindow.c : added gdk_window_foreign_new() gdk/x11/gdkwindow-x11.c : removed here gdk/win32/gdkwindow-win32.c : make the *_for_display variant * gdk/win32/gdkdrawable-win32.c : implement drawable.get_screen() member function * gdk/win32/gdkevents-win32.c gdk/win32/gdkinput-win32.c : gdk_event_*() added extra GdkDisplay* parameter * gdk/win32/gdkmain-win32.c : _gdk_windowing_init_check() doesn't take any parameters anymore * gdk/makefile.msc gdk/win32/makefile.msc : changed accordingly * gtk/gtk.def : updated externals * gtk/gtkgc.c gtk/gtkstyle.c gtk/gtkwidget.c : there is no ->screen on GdkColormap anymore use gdk_colormap_get_screen()
Attachment:
gtk+-2002-05-11-hb.zip
Description: Zip archive
-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert