Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-swt-dev] GTK2 Stream: Rules of the Game

Dear SWT Developers:
 
This post is for those who intend to contribute to the SWT/GTK2 codebase.  If you are not one of those, I apologize for the lengthy noise.  If you consider committing to SWT/GTK, or are otherwise interested, here is the plan.
 
Background:
The current SWT/GTK code base (today's HEAD stream) assumes GTK1.2.  The 1.2 API is not adequate for proper implementation of SWT: certain SWT APIs can be implemented only approximately right, and even that is only possible with the use of GTK-private details (knowing exactly how GTK memory is laid out, what the numeric constants are, etc.)
Given this, we decided to concentrate our GTK effort on switching to GTK2, and put the main focus on making it "more real" than SWT/GTK1.  We also want the GTK2 stream to become HEAD as soon as possible.
 
It is important that everyone contributing to SWT/GTK2, keeps in mind the following basic principles:
 
1. Focus on being real.  All new code must be quality code.  If you see a hack that's partially working, don't "enhance" the hack to be working.  Remove it and put the real code in.  Don't delay the switch to real code "til later".  Also: anything that is not rightly engineered, is a hack; anything that you know should be done differently in the GA version, is a hack.
 
This concentration on final quality means paying very close attention to little details in every widget, rather then the big picture; and leads to the next principle:
 
2. You own what you touch.  If you fix a problem with a widget, it means you are working on that widget.  E.g., if you fix a bug in List, please also examine List very carefully and make sure everything is *exactly* right with it.  Don't walk away until you are happy with the code.  In other words: try to port  SWT, not Eclipse.  We've had enought of this "approximately right" and "right enough to not break Eclipse" nightmare.
 
3. Do not assume binary compatibility.  If you don't know what I mean, come see me.  (But here are two simple examples: don't copy numeric values for constants, from the GTk source; don't assume you know the sizes for all GTK structs in bytes).
 
4. Leave GTK bugs to GTK.  Don't build workarounds that assume the buggy behavior.  Or at least, workaround at the GTk level or near GTK.  (grep -c "Bug in GTK" *.java should always be 0).
 
 
I hope these work principles will create more synergy in SWT/GTK development. 

Back to the top