Re: multi head porting

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
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 ()


*** 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

	* 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

	* 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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]