-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have lately seen a lot of duplication of effort in Sugar. I think this is bad. The success of Sugar demands discipline and careful planning from its developers.
In particular, I am arguing that supporting Qt or Webkit would be a terrible idea, and that neither should be permitted to be a dependency of the Sugar platform. However, my argument is certainly more general. 1. Bloat is bad. Efficiency is one of the main goals of Sugar. Sugar was created to fulfill a vision of the original Hundred Dollar Laptop Project: "We will get the fat out of the system. Today's laptops have become obese. Two-thirds of their software is used to manage the other third, which mostly does the same functions nine different ways." [1] It's true. 99.99% of all deployed computers running Sugar are XO-1's, and will soon be XO-1.5's. These are strongly resource-constrained machines, and they cannot tolerate inefficiency in the use of disk, CPU, or RAM. Outside of OLPC, we continue to target low-end hardware where efficiency is key. If we allow Read to depend on Webkit, but Browse uses Gecko, then to use them both, the operating system must load two entirely separate rendering engines into memory. On an XO-1 this may be impossible; it will certainly lower the threshold for OOM behavior. Similarly, loading both the Qt and GTK libraries into memory at once dramatically increases memory usage, and wastes valuable disk space. Don't do it. 2. Technological uniformity is an educational decision. Sugar, and its activities, are written using a uniform set of technologies, centered around pygtk. This is deliberate. The goal is to crush the barrier to entry, so that a student who learns how to modify python activities immediately has enough knowledge to modify Sugar itself. This is the incarnation of "low floor, no ceiling". It is what enables the culture of end-user engineering that we strive to create. Adding more supported technologies for writing Activities raises new barriers to entry. A student who learns how to modify a Qt-based activity does not gain knowledge that will help to modify Sugar itself. A user who has learned pygtk still does not have enough knowledge to modify one written in Qt. We risk creating a Tower of Babel, with components written in countless frameworks, all different. One argument made in favor of supporting Qt is to gain access to existing KDE applications. I don't believe this for a second. Our entire system is built with technologies drawn from the Gnome stack, and yet we have almost no Activities that consist of wrapped Gnome desktop applications. The barriers to compatibility with KDE are considerably higher, and I cannot think of a single application from KDE-space whose functionality we do not have, or could not get more easily from GTK-land. Another argument is that it will help to gain support from developers already familiar with Qt. I think this is quite irrelevant. When I started writing Sugar code, I had never seen a single line of gtk (I was familiar with Swing). I read the docs. It was easy. Anyone can learn gtk, especially if they are already familiar with another toolkit. More importantly, there just aren't that many Qt developers. I am willing to accept an argument of this type for improving support for activities written in javascript+HTML, because there are certainly orders of magnitude more developers of javascript and HTML than of python, or any other language we might choose to support. Qt and PyQt, on the other hand, are in a niche even smaller than pygtk's. The many costs of supporting Qt greatly exceed any theoretical value. Don't do it. - --Ben [1] http://web.archive.org/web/20050324163700/http://laptop.media.mit.edu/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkpt5iEACgkQUJT6e6HFtqQzTgCfTWiSLfg1QBGnxKck8zZul3MJ d80AnAnTeT4zIccEPs6kNoiHYkEBjBc8 =ayiC -----END PGP SIGNATURE----- _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel