I wish I could post my full analysis and history of GTK here in one post, but it's far too long for that -- it's an 11-page behemoth and the character limit here is 32,000 characters per post. I hope you can stand the breaking up of the essay into two parts. Here it is in full:
Gordon Squash on the Projected Future of GTK
Extrapolating to GTK 4 and Beyond
In a previous essay I provided my frank review of GTK 4, or the latest
unstable version of said toolkit: 3.99.0. I concluded that it's a step
in the direction that GNOME has been taking for about eight years now.
In this installment of my messages, I'd like to shed light on what I
think is the direction GTK will take -- not just now, but years into
the future of the project.
To do so I will use history as my guide: the past history of GTK --
looking over not just 10 years, but over more than 20 years of history
to find out what the next 10 years and one major release may bring us.
DISCLAIMER: Please note that I do not posess any form of crystal
ball, so my projection may be entirely wrong. Only time will tell.
Where are we today?
GTK is in a situation today which it has never experienced before. For
every other major move the GTK community makes, there are between 1 and
10 nasty remarks about the major move from other members of the
community. Some say that the GTK team makes unilateral decisions based
solely on their priorities, without consulting any other section of the
community first. Others claim that many of their explanations for why
they changed something are totally unbased and that their explanations
are mere excuses in disguise. Few open-source projects have ever been
so fervently detracted in the same manner that GTK and GNOME have been.
As of this writing, even Linus Torvalds continues to disfavor GNOME due
to its strikingly "unappealing" interface.
Futhermore, many continue to pine for days gone by when "GTK" meant
"GTK+ 2". These advocates for GTK+ 2 were satisfied with GTK as it
stood in the months before GTK+ 3 was released. Or were they?
Over the next few sections I'd like to show you why I think it's largely
invalid -- though not totally invalid -- to group favored and disfavored
versions of GTK together into major number distinctions such as "GTK+ 2"
or "GTK+ 3". However, I will warn you that this article is extremely
long and detailed, so if you already know about any of this content you
may consider skipping paragraphs or even pages of information.
A brief history of GTK in "prehistoric" times
Perhaps many of us have heard that GTK is a direct descendant of the
image editing program the GIMP. The fact is, the GTK as we know it today
is not the GTK that was the "Gimp ToolKit" (that's where it got its name)
in very many ways at all.
In fact, initially the GIMP didn't use GTK at all. When Spencer Kimball
and Peter Mattis began writing the GIMP as a class project while studying
at the University of California Berkeley, they initially used the popular
and then-closed-source Motif graphical toolkit. It was proprietary and
purchasing a license for the software could be costly; however they used
the version of Motif licensed to the school.
Motif was capable of creating workable user interfaces with relatively
little code (prior to Motif and other widget toolkits, it was often
necessary to write hundreds or even thousands of lines of code just to
draw a button onscreen). However, Motif had several shortcomings which
made it difficult to write an image manipulation program with it. In
response to Motif's shortcomings, Mattis and Kimball proceeded to
distance themselves from Motif and instead started writing a widget
toolkit better adapted to graphics manipulation. Since Motif was closed
source, Mattis and Kimball could not base their toolkit in any way on
real Motif source code. However, they did base some of the application
programming interface, or mechanism for using the toolkit in programs,
on the application programming interface of Motif. They also designed
their widget toolkit so that it looked roughly similar to Motif, complete
with the pseudo-3D look of the widgets. They called their widget toolkit
"GTK", for "Gimp ToolKit".
But when their class project was turned in and they completed their exam,
they had no idea initially what to do with their labor which they called
the "General Image Manipulation Program", or the GIMP, and the GTK.
Seeing that they had spent a lot of time on these programs, they
open-sourced the GIMP and by extension the GTK, licensing both under the
open-source GNU GPL license. They open-sourced the program so that at
least others could reap the benefits of their work.
But this was a game changer in multiple respects: For one, an image
manipulation program, albeit only a moderately sophisticated one at the
time, had just been open-sourced. This meant that other people could
contribute code to the GIMP and see their changes integrated into the
next release of the GIMP. Another aspect of the open sourcing was the
fact that now there was a widget toolkit which was fully open sourced.
At the time, another widget toolkit called Qt had recently been making
tidal waves, but it too was largely closed source, maintained by a
Norwegian company known as Trolltech. As previously stated, Motif was
the industry-standard toolkit of the time, but was also closed source,
as was another increasingly popular toolkit of the time, Sun's OpenLooks.
Now there was one contender in the toolkit race which was open source and
freely available. Like the GIMP, the GTK was increasingly embraced by
the community.
As time went on, it became clear that many toolkits -- including Motif
and, at the time, GTK -- contained a lot of unnecessary code duplication.
A widget for a toggle button (a special type of button which alternates
between one of two states when clicked) might contain a lot of duplicate
code carried over from the widget for a plain button. With object-oriented
programming being a hot topic in programming and academic circles at the
time, the focus was on being as wasteless as possible when writing code for
the GTK. Thus Mattis et al. set to work converting the GTK to code that
was somewhat more object-oriented in spirit, and the GTK+, or GTK Improved,
was formed. The name has stuck up to -- but not including -- the present
day.
At about the same time that the GTK was being updated to the GTK+,
shockwaves hit the community: In 1996, Martin Gräßlin announced that he
was working on an attractive desktop environment for UNIX-like systems.
His message was generally greeted with applause. However, devoted free
software advocates disagreed with his choice to use the then-proprietary
Qt toolkit as a base for his project. Sensing that the KDE could have
inadvertently led to a licensing nightmare on otherwise open-source UNIX-
like operating systems, a few months later the GNU project announced that
it would begin development of a competing desktop environment known as
GNOME. GNOME would be based on GTK+ and would thus be fully open source.
This was the first time that GTK+ was used for anything other than for
the GIMP. At that time, the GNU project was also working on an
open-source Motif clone, wittily named LessTif. However, LessTif and
Motif both lacked several key features required by a desktop environment;
hence, the GNOME project chose to use GTK+. Simultaneously, Mattis and
Kimball were losing interest in the GIMP and GTK+ and were also on to
other projects, so they were looking for a group to take care of both.
The GNU eventually picked up development of both projects and renamed
the GIMP to the "GNU Image Manipulation Program", which happened to also
spell GIMP.
By the time GTK+ 1.0.0 was released by the GNU project in April 1998,
Mattis had not contributed since September of the previous year. By
this point, the GIMP team had evidently passed control of the GTK on
to the GNU project finally. Thus the GTK, or the GTK+ more accurately,
ceased to exist as the product of the GIMP team.
The early modern era: GTK+ 1.0.0 through GTK+ 1.2
Despite the GIMP team not contributing much to GTK+ after 1.0.0 was
released, GTK+ continued to be called "GTK+", not "GTK+ 1" or "the GNOME
toolkit". (In error, some people called the GTK+ "the GNOME toolkit" or
"the GIMP toolkit", but in reality it already meant nothing more than the
letters themselves.) The GIMP continued to use GTK+, and in the first
few years GTK+ quite a bit resembled the original GIMP product.
Though it brought some changes, GTK+ 1.2 was not a particularly sweeping
change relative to GTK+ 1.0. The chief differences were minor, mostly
technical programming nuances rather than user interface changes. But
already some could sense a change coming: For one thing, though the
default look and feel still resembled Motif, Red Hat introduced a new
theme called Raleigh which looked more modern. Red Hat embraced Raleigh
whenever they packaged GTK+, and around this version they started
investing large pools of resources into perfecting GTK+ and GNOME in
general.
Red Hat became so invested in GNOME and GTK+ that they started to leave
the other major desktop environment, KDE, behind. Contemporary rumors
indicate Red Hat may have criticized KDE by referring to it using a word
inappropriate to bring up in this article. What matters though is that
by the time GTK+ 1.2 was released, Red Hat had a vested interest in GTK+
and GNOME, and the GNU project's interest progressively faded over a
period of years.
The start of the peak: GTK+ 2.0.0 to GTK+ 2.8
After GTK+ 1.2's release in 1999, work began on a major version of GTK+,
one which some still pine for today: GTK+ 2. Called 1.3 while still in
development, it was ultimately released in March 2002. Though it was a
very major change from a programmer's perspective and it took a long time
for programmers to convert their programs to use GTK+ 2, on the user
interface GTK+ 2 was not much different initially from GTK+ 1.2 -- or
even GTK+ 1.0 for that matter. One of the most striking differences was
the use of the Raleigh theme by default, replacing the old-fashioned
looking (even by then) Motif-esque theme. Again, this change was
courtesy of Red Hat -- and I personally am in favor of the change because
it improved the appearance of applications. Another welcome and visible
change was the upgrade to slightly more modern icons. All in all, once
applications were ported to use GTK+ 2 and users actually got a chance to
see the improvements made by GTK+ 2, it was greeted with much fanfare.
Then the sweeping changes began. Version 2.4 introduced several new
features, among them a brand new, modern-looking file chooser. GTK+ 2.8
was special in that the changes it brought were mainly visible only to
the eagle-eyed observer -- instead of rendering onscreen elements using a
classical method which produced less-than-smooth results, GTK+ switched
to mostly using Cairo, a new graphics library with support for several
important graphics features. One of these features was antialiasing --
the practice of "fuzzing" the picture very slightly to reduce the grainy
"pixellation" which used to plague graphics software; the other main
feature was media independence -- the ability for the same code to
draw the same shape whether the ultimate destination for the image was a
printer, a normal computer monitor, a plotter, an image file... you name
it; Cairo could support it.
The adoptance of Cairo excited programmers considerably, since now the
printing architecture could be greatly simplified. Previously, the
printing mechanism was very complicated and involved using code unlike
that for drawing onscreen; after Cairo was adopted, printing could be
accomplished with only a slight amount of code on top of what was
already being used to draw onscreen.
The peak: GTK+ 2.10 through GTK+ 2.18
By the time GTK+ 2.10 was released, Cairo was used by GTK+ for practically
all rendering, whether onscreen or in print form. New Linux distributions
(the name given to distributions of the Linux kernel plus other open-source
software including GNU) had been popping up long before GTK+ 2.10 was
released in late August 2006. Red Hat had long been the champion in the
Linux distribution field. However, few distributions had gained popularity
as quickly as Ubuntu, whose first release was announced in October 2004.
By the end of 2006 Ubuntu had gained a significant following due to its
ease of use -- and the GNOME desktop used by the distribution, GNOME still
being based on the GTK+ (but this time version 2), was at the center of
the usability improvements. By this time, most distributions had removed
GTK+ 1.2 and 1.0 from their repositories of software, leaving only GTK+ 2.
Even Debian, long known to be conservative and careful about including
only software that was well-tested, started preparing for the eventual
elimination of GTK+ 1.2, the elimination finally taking place in very late
2007.
As GNOME progressively became the most popular desktop environment on
UNIX-like operating systems, GTK+ 2's populartity came with GNOME's.
By this point in time, hundreds of people had contributed to both projects
and new features were implemented in each new release, sometimes as many
as 20 in jam-packed releases. What's more, more projects than just GNOME
and the GIMP were utilizing GTK+ by now -- entire other desktop
environments such as XFCE had been using GTK+ since about 2000, while
entirely new desktop environments such as LXDE used GTK+ from the start.
Application developers were writing their programs using GTK+ to get
widespread adoptance of their applications -- at one point it seemed the
GNOME project had too many applications, since the number of applications
in the project was starting to dwarf the number of KDE applications. (And
that is saying a lot: At the time, the bar for the quality of new KDE
applications was, quite frankly, set extremely low.)
Despite it not seeming like an especially important point, theme developers
also enjoyed GNOME. Theme developers had at their disposal a number of
so-called "theme engines" -- libraries of code which could be used to
produce a working theme, as long as the theme designer provided a list of
stylistic parameters to the theme engine such as what colors to use in the
theme. Because theme designers did not necessarily need to write any
actual code to produce a working theme, theme designers jumped on GNOME and
produced dozens if not hundreds of themes for GNOME. By extension, other
desktop environments could use the same themes that were used primarily
for GNOME, because the themes were really nothing more than GTK+ themes.
Eventually, developers from all of the major desktop environment
development teams were writing themes, theme engines, and even code for
GTK+ -- and seeing their changes become part of GTK+ and, sometimes, part
of the GNOME theme collection. This was the peak of GTK+'s popularity.
The long-anticipated successor: GTK+ 3 is on the way
Shortly after GTK+ 2 was first released in 2002, the GTK+ documentation
included a section on porting applications to use GTK+ 2 when they had
formerly been using GTK+ 1.2 or even 1.0:
GTK+ changed fairly substantially from version 1.2 to 2.0, much
more so than from 1.0 to 1.2. Subsequent updates (possibilities
are 2.0 to 2.2, 2.2 to 2.4, then to 3.0) will almost certainly
be much, much smaller.
In reality, GTK+ 3.0 would take many more years to materialize than the
GTK+ developers thought it would. If GTK+ 3.0 had appeared when they
originally figured it would, then GTK+ 3.0 would have been released
circa December 2004. In reality it would be released more than six years
after that proposed date.
By 2007, conversation among the GTK+ community about GTK+ 3 resurfaced.
Initially, the general consensus was that GTK+ 3 would not be much
different from GTK+ 2 from the developer's perspective. However, by
2008 it became clear that the World Wide Web was becoming far more
graphical than it had once been. At one time, the Web served solely to
provide textual information and maybe a few images and, at the very most,
video and animation with audio. Despite the adoptance of multimedia on
Web pages, it took until consumer computers became more powerful before
the multimedia could be plastered everywhere on the Web pages --
literally, from one perspective. By 2008 Web pages were becoming so
fancy and colorful that some people recognized that the Web pages were
starting to look less like drab black text on a white background, and
more like the user's main desktop environment.
The technology which permitted such flexible styling of Web pages was
CSS. On one level, CSS is nothing more than a textual means of
expressing style information. But the genius is in the way the style
information is inherited: In HTML, the language used to lay out Web
pages, a Web page is hierarchical; a block of bold text may be enclosed
in a paragraph of otherwise unstyled text, for example. CSS gives the
Web page designer the ability to style entire blocks of Web pages and
all of its "children" blocks too. Or CSS can be used to just style
one or two elements. The inheritance properties of CSS make it ideal
for styling Web pages, where there may be tens of thousands of these
blocks, or "elements", all on one page and many of them share style
properties in common, such as the color of the text or the alignment of
the elements themselves.
As we found out earlier, GTK+ is also very hierarchical. A window may
contain container widgets, special widgets which can be used to size
and dimension other widgets onscreen, even effectively hiding some from
view. A window itself is a container widget; a widget dimensioned by
a parent container widget is said to be contained in that container
widget. At this, one GTK+ developer thought (maybe it was an original
thought, perhaps not -- we may never know): Why not style widgets using
CSS?
The idea attracted enough attention that a new theme engine for GTK+ 2
was written -- this time based around CSS styling, however. It did not
become successful, however, because most themes were already written
in the traditional form and not using CSS. Additionally, GTK+ provided
even more styling flexibility than what CSS could afford at the time.
Ultimately, only a few themes were written for GTK+ 2 using CSS, most of
which were written by the author of the CSS theme engine.
Meanwhile, as more details of the upcoming GTK+ 3 became known, it was
eventually revealed that GTK+ 3 would most likely be styled using CSS --
except not merely as a theme engine, but integrated into GTK+ 3 itself.
Additionally, extensions would be made to the CSS parser in GTK+ 3 to
ensure that sufficient styling capabilities were available to themes and
applications alike. Though some already felt uneasy about the coming
change, many at the time felt it was a change for the better.
Additionally, it was planned to continue supporting traditional themes
and theme engines too.
Closing in: GTK+ 3 in the later months of development
By 2011, GTK+ 2 was the most widely used graphical toolkit on UNIX-like
operating systems. Its popularity seemingly could not be greater. But
it had been nine years since a new major release had been produced, and
many believed that some former release of GTK+ 2, possibly GTK+ 2.8,
should have been named "GTK+ 3" due to its dissimilarity to previous
versions. But by 2011 it was too late to rename any version of GTK+ 2
to a new major version, because GTK+ 3 was supposedly around the corner.
Or was it?
On the last day of January 2011, another version of GTK+ 2 was released,
seemingly in a slight panic: GTK+ 2.24. In many ways this release was
never meant to exist: GTK+ 3 was supposed to have been released by
December 2010. And yet GTK+ 3 had not been released even by the end of
January 2011, much less December 2010. What was going on?
Among the many problems the GTK+ team faced, they realized that the CSS
styling infrastructure did not integrate well with the old theme engine
system. After much discussion, the package of popular GTK+ theme engines
maintained by the GTK+ team for GTK+ 3 was dropped. In addition, the
default theme, long known as Raleigh by this time, was hurriedly
rewritten for GTK+ 3 in CSS. The hurried nature of the operation,
combined with the fact that the theme was supposed to look "more modern",
lead to a less-than-perfect default appearance for GTK+ 3. But this was
not a significant problem for GNOME, because in parallel they were
working on a theme written from the ground up to look modern. The theme
was originally called GNOME3, but was soon renamed Adwaita.
A few days later, on February 10, 2011, GTK+ 3.0.0 was finally released.
But before GTK+ 3.0 was finally released, the third major release of
GNOME, dubbed GNOME 3, was produced. It was specially optimized to have
a "more modern" user interface -- one adapted properly to touchscreens,
becoming ever more popular at that time. In a strange twist which few
people realize, the first few versions of GNOME 3 actually used GTK+ 2,
because GTK+ 3 was not yet stable enough for production use. So for a
time it was entirely possible to run a GNOME 3 system with classic
GTK+ 2 themes, most notably Clearlooks, which had become the default
GNOME 2 theme years earlier. But the rest of the user interface was
clearly not intended to be used in a more traditional setup. Initially
GNOME 3 sold itself as being more "keyboard-oriented" than most desktop
environments; eventually it became clear that it was only more
touchscreen-friendly.
What was all the hype about anyway: GTK+ 3.0 through GTK+ 3.8
While GNOME 3 continued to disappoint users and Linux distributors alike,
GTK+ 3 was just as disappointing to many application developers. Besides
the removal of features deprecated in GTK+ 2 (including the old-style,
non-Cairo drawing system, and the "ruler" widget which was used chiefly
by the GIMP by this point), and additionally the addition of CSS styling,
GTK+ 3 seemed to many people just to be much ado about nothing. Many
GTK+-based projects did not immediately embrace GTK+ 3 because it seemed
to have flopped -- whereas GTK+ 2 was not expected to have been much,
GTK+ 3 had been promoted for years and it had not lived up to its name.
Despite this hurdle, one of the first users of GTK+ 3 besides GNOME was
Mozilla, which began work on a GTK+ 3 port of its applications by late
March 2011. But like most other projects which jumped into the game
early, no Mozilla applications were officially built with GTK+ 3 for
years to come.
In addition, the fact that only GNOME was actually seriously being ported
to GTK+ 3 at the time led many to believe that GTK+ 3 was the mere product
of GNOME developers -- and even at that time, the skeptics were correct.
Furthermore as GNOME 2 users failed to upgrade to GNOME 3, the user base
of GTK+ 3 was limited solely to users and developers in favor of GNOME 3,
as if there were any outsiders present from the start of GTK+ 3's release.
Because of this, the GTK+ 3 team believed that they could do whatever they
wanted to do in GTK+ 3 -- making it more GNOME-centric and forgetting
about the rest of the community, for example. If it's just us using this
GTK+ 3 toolkit, then why not adapt it to us and us solely?
Even theme designers (for the most part) did not like the CSS styling:
Writing a new theme no longer required just supplying some parameters to
one or more pre-made theme engines; it required copying all the CSS code
from one theme, often hundreds of kilobytes of it, and rewriting the CSS
code slightly. CSS files could not be shared, unlike theme engines which
could be shared between one theme and another. In addition, oftentimes
a GTK+ 3 theme would require a number of image files, since some widgets
were complicated enough that they did not adapt well to pure CSS. Some
theme developers were lazy and took screenshots of parts of old widgets
drawn using their old theme engines; others took the time to recreate
their widgets in scalable image form as SVGs. The former had the
disadvantage that widgets looked fine when rendered normally, but when
accidentally rendered too large or too small, even the tiniest amounts
by applications like Mozilla, they would look blurry and their exact
meaning would be unclear. SVGs looked good even scaled up or down, but
they had the disadvantage that they too were often created shabbily, and
even when properly drawn they could cumulatively consume hundreds of
kilobytes of disk space. On the one hand, disk space was not a major
concern anymore; but on the other hand themes could easily add up to
noticeably increase the size of the GTK+ library if built in. All in
all, the built-in themes in a modern version of GTK+ 3 total up to 2 MB
themselves -- while the size of the library itself, including the
themes embedded within, is 8 MB. So these themes effectively increase
the size of the library by 33% -- a sizeable factor considering that the
default theme used by GTK+ 2 amounted to 120 KB of compiled code, which
is just 2.4% of the 5 MB GTK+ 2 library.