Eclipse.org http://www.eclipse.org/ SWT - Standard Widget Toolkit http://www.eclipse.org/swt/ Main issues: - gnome.org We need better stability, performance, and support for large-scale applications. - kde.org We need better compatibility with the GNOME stack. - cairographics.org We need better performance and printing support. - mozilla.org We need a consistent Linux embedding story. - red hat/fedora We need better ISV documentation. - novell/suse We need you to stop shipping the gtk-qt theme engine, or fix it. - ubuntu/debian We need to fix the "broken GTK+ 2.6.4 that isn't 2.6.4" issue - freedesktop.org We need more participation and progress. Linux distributions: - Eclipse is not just about the free IDE, it's about building cross-platform desktop applications based on the Eclipse platform and toolkit - Developers want one "Linux" download for many distributions - Cross-platform: often have Win32 developers building .zips that should run on Linux. SWT's shared libraries therefore need to just work, app developer's can't recompile: they just write Java code - Good examples: radrails, a Ruby-On-Rails IDE, just a "Linux" download http://www.radrails.org/ - Another example, some large IBM development app (RAD). - Another example, not an IDE, Lotus Workplace. Needs the sort of strong desktop integration that an IM client needs (TrayItem support, launching external apps, etc). Shows how we aren't just writing apps targeted at software developers. Distribution complexity: - There are far too many different versions of GNOME in current use, and growing: http://vektor.ca/gnome2-versions.html http://vektor.ca/gnome2-versions-commercial.html - Old distributions often have customers who must use them. Still have requests for problems on RH8/GTK+ 2.0.6 and lots on RH9 - Just during the development of 3.1, various Eclipse developers were using any of RH9, RHEL3, RHEL4, FC2, FC3, FC4, SUSE 9.1, 9.3, Gentoo, Mandrake, Debian (usually Debian unstable) - Uses complain about performance issues, but the performance characteristics of the full stack Eclipse+GTK version+X version+kernel can be quite different. Diversity makes it difficult to evaluate problem severity and reliably reproduce issues Example: - Windows user: Are you running XP? Is it SP2? Are you in "large fonts" mode? What Java VM? - Linux user: What GTK+ version? What GTK+ theme? What distribution? What fonts? What window manager? Is mozilla installed? What mozilla version? What Java VM? Are you sure, you're probably running with gcj and don't know it. Binary compatibility: - We currently compile SWT/x86 on a RH9 machine (GTK+ 2.2.1) and against the Mozilla 1.4 SDK - Is this sufficient? Is this guarenteed to work? Who can say, there is no documentation about best-practices, and barely any documented practices on how to build more compatible binaries - Compare with Win32 where we can build on Windows XP and produce binaries we know will work on Win98. Distributions don't help us! - GNOME from RH9 and RHEL3 required "liblinc", a dependency brought in by pkg-config. This library is no longer installed by default on RHEL4, and some old binaries failed to load. We had to modify our build to avoid linking to libraries we don't specifically require. Lesson: Don't remove libraries people depend on! https://bugs.eclipse.org/bugs/show_bug.cgi?id=68732 https://bugs.eclipse.org/bugs/show_bug.cgi?id=55917 - Once we accidentally compiled on a newer distro, brought in libc symbols that caused us to not run on older distributions https://bugs.eclipse.org/bugs/show_bug.cgi?id=87477 - Many distributions now have Mozilla built against libstdc++.so.6 (gcc4) while we link against libstdc++.so.5 (gcc3) but nowhere can we find any transition guidelines about what to do. Currently Mozilla embedding does not seem to work on some distributions because of this and we have no idea what the correct fix is. Where is the transition information or compatibility layer or anything? https://bugs.eclipse.org/bugs/show_bug.cgi?id=109888 Mozilla embedding: - We use the mozilla embedding API directly (not GtkMozEmbed). https://bugs.eclipse.org/bugs/show_bug.cgi?id=85836 - Stress that it is used for an embedded browser widget in the toolkit, no access to the DOM, and that it is only used on Linux/UNIX, use IE on Win32, Safari on Mac OS X. Important to clarify that we need the Mozilla engine to be *THE*BROWSER* under Linux. - Distributions need to ensure an embeddable browser is always present and discoverable. Should be as standard as GTK+ itself! - We use a "gre.conf" configuration file to find mozilla, but unfortunately: a) Only Red Hat provides this file! How can we find mozilla (libxpcom.so) on any other distribution??? b) Red Hat only provides it if you have mozilla installed, not the (default?) firefox c) Red Hat moved it from /etc/gre.conf to /etc/gre.d/gre.conf in a security release, breaking Eclipse! d) Red Hat calls it gre64.conf on 64-bit platforms, but did not coordinate this with mozilla.org, again breaking Eclipse! Clearly there are lines of communication which need to be better. Debian bug 328471 http://bugzilla.ubuntu.com/show_bug.cgi?id=13750 http://bugs.eclipse.org/bugs/show_bug.cgi?id=109253 - Currently disable HTTPS as the Mozilla profile API is not frozen!! This is a really important feature and we seem to be stuck. ? Other unfrozen APIs always difficult (file download, etc) - On only Debian (!!), embedded Mozilla uses the "Modern" chrome theme instead of the "Classic" theme and so browser widgets look out of place!!! This sort of weird distribution difference is a good example of how the complexity hurts us: http://bugs.eclipse.org/bugs/show_bug.cgi?id=108257 GTK+/GNOME stability: - Too many "stable" releases: 12 different "stable" releases just of GTK+ 2.6. Never clear which ones actually used "in the field" - Distributions backport fixes, which means these version numbers can become useless, further increasing complexity - Debian 2.6.4 example: 1. GTK+ 2.6.8 includes a fix for some low-level X focus issues. 2. This BADLY BROKE a workaround in SWT, in 3.1.1 we do "if GTK > 2.6.7 disable workaround" 3. Debian backported the fix to GTK+ 2.6.4 in their "stable" release. What can we do now?? We would need to test for "debian"?? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334534 GNOME-VFS API breakage: - Had an API for listing installed programs by extension/MIME-type - API completely deprecated after GNOME 2.2, all functions started returning NULL. This is BAD! https://bugs.eclipse.org/bugs/show_bug.cgi?id=79268#c7 - New API makes some of SWT Program unimplementable, when before we could. Ex: list all mime-types/extensions known by the system. - No version number exporting from GNOME-VFS, means we can't do version checks easily, forced to use libdl to query the library for certain functions. - Steve to give example of Win 3.1.1 16 bit to 32 bit porting as an example of "sensible" adding of new features. Keep old code the same, grow new APIs or augment old APIs as needed. GTK+/GNOME versus large, complex applications: - metacity has troubles with the stacking order of multiple modal dialogs, these bugs should be considered major - metacity focus-stealing prevention is harmful for applications that are "slow", dialogs from the same application considered as trying to steal focus. Bugs in Eclipse where dialogs appear without focus https://bugs.eclipse.org/bugs/show_bug.cgi?id=100231 http://bugzilla.gnome.org/show_bug.cgi?id=307875 - Many parts of the GNOME stack to not announce version numbers (libgnome-vfs, metacity, libgnomeprint, etc) - GTK+ theme system hurts widget creation time, need to do a lot of pattern matches against the theme database for every widget - GtkTreeView does not seem to scale well to huge lazy tables, causes lots of extra repaints. VIRTUAL uses fixed-height-mode but is a bit of a hack. Need CAREFUL bugfixing upstream. - Concerns about the new file chooser dialog seem slow to be addressed (hard to select directories, no text entry for selecting automounted directories, etc) http://eclipse-desudation.blogspot.com/2005/11/why-gtkfilechooserdialog-sucks.html Window management: - SWT windows need to be able to open at a particular size and location on demand. Lots of problems here between window managers - Window decorations difficult to manage - Typed window support has so far not been great. Can't use the splash screen window hint since older metacity made it always-on-top https://bugs.eclipse.org/bugs/show_bug.cgi?id=79944 Some window types don't map well to SWT's decorations API, people writing the spec don't seem to evaluate implementations. Maybe it's best to do the IETF thing and try for at least two interoperating implementations during the branding of the spec? - kwin centers dialogs on their parent, no way to make it stop - metacity has bugs and races with multiple modal dialogs, hard to track down https://bugs.eclipse.org/bugs/show_bug.cgi?id=102242 Printing: - GTK+ does not have native printing support - libgnomeprint not "real" until GNOME 2.8? Need to use a whole new GC implementation just for printing? - Hard to even find out information about what API we should be using, many developers say not to bother with libgnomeprint, and GTK+ printing support has been on the plan since winter 2003 - Why not support Xprint? Regarding KDE: - Need to support the same MIME system as GNOME. Confusing to have konqueror bring up one application when opening a .txt file and have Eclipse bring up something else. Where is support for the xdg-mime standard from freedesktop.org? - Tried supporting two APIs, but too hard to know whether you're running under KDE or GNOME, code was complex, crazy crashes due to C++ ABI issues, bugs in KMimeType, etc. - KDE users find it confusing to know what GTK+/GNOME theme they are using. In GNOME you can see it in the theme preferences, but this is not exposed to KDE users. - The KDE "apply KDE colours to GTK+ applications" checkbox is problematic. With it selected, it is hard to know which GtkTreeView has focus, as they all either have the same selection colour, or it disappears when they don't have focus. This shows how easy interoperability issues are not being addressed. - Suggestion: better KDE support for controlling GNOME themes - run an XSETTINGS server or control/communicate with gnome-settings-daemon. Accessibility support: - IBM and other companies need accessibility to be "real" - Should be like Win32, don't require programmers to code support everywhere, should work like magic - APIs are fine, issue seems to be lack of a11y support applications and problems in the core widgets Performance: - Care a lot about performance, string drawing and measuring is far too slow compared to Win32, even with uniscribe - Type system, theme system, and signal overhead must be reduced. Eclipse creates tons and tons of widgets and hooks hundreds and hundreds of signals across all of them - Performance is highly theme dependent, which means there needs to be a standard theme so applications can optimize for it Example: perspective switching 30% slower with BlueCurve on Red Hat 9 than with the built-in theme, what can we do? - Pixmap-background themes are unbelievably slow, for example "smokey blue". Why ship it? Drop it! Themes: - General lack of usability testing for themes, even ones that ship with distributions (inconsistent checkboxes anyone?). Poor themes should not be shipped!! - SuSE shipping gtk-qt theme as the default! This theme causes many reproducable crashes, search for "gtk-qt" in Eclipse bugzilla, see open bugs at bugs.freedesktop.org. It also causes custom widget colours to fail, causing parts of Eclipse to look terrible. SuSE keeps shipping this theme and does not seem responsive to these issues. Why? Can it be pulled or can someone address these issues? https://bugs.eclipse.org/bugs/show_bug.cgi?id=97145 https://bugs.eclipse.org/bugs/show_bug.cgi?id=99367 https://bugs.eclipse.org/bugs/show_bug.cgi?id=108550 https://bugs.eclipse.org/bugs/show_bug.cgi?id=112811 https://bugs.freedesktop.org/show_bug.cgi?id=4816 - Theme database lookups can take a long time during widget creation Documentation: - libgnomeui, libgnome-vfs documentation very poor, makes it almost impossible to use - libgnomeprint documentation is not online at developer.gnome.org. - libgnomeprint docuemntation does not have @since markup, no idea when features became available or what their requirements are (pango integration, for eaxmple) - Many GTK+ signals are not well documented, hard to know when we can depend on the ordering of signals - Where are the drag-and-drop formats for nautilus/konqueror documented? Are they stable?