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.
Inspiration, isolation and alienation: GTK+ 3.10 to GTK+ 3.14
With almost nobody actually using GTK+ 3 other than GNOME, the GTK+ /
GNOME developers realized they were alienated. At first, after releasing
GTK+ 3.0.0 they patiently waited for anybody to dare port their software.
Almost nobody dared. Mozilla was working on the GTK+ 3 backend early on,
but failed to officially support GTK+ 3 in their prebuilt versions. The
reason? Mozilla knew that many Linux systems (by this time other
UNIX-like operating system users were in the minority) lacked an installed
version of GTK+ 3, or at least they were not comfortable releasing a GTK+
3 version of their applications before GTK+ 2 desktops started to disappear.
By 2015 Mozilla had started releasing GTK+ 3-based versions of their
applications.
Ubuntu's Unity desktop environment also ported to GTK+ 3 fairly early on.
Though initially it used GTK+ 2, certainly by 2012 it required GTK+ 3.
But Unity was not much of an endorsement: Some people believed it was
better than GNOME 3, sure. But many others believed it was nothing more
than GNOME 3 in disguise. With developers so slowly coming out with
GTK+ 3 versions of their applications, it seemed like nobody would ever
port to GTK+ 3. Years before, when GTK+ 2 was still relatively new,
only a minority of applications still used GTK+ 1 -- most were ported
quickly to GTK+ 2. Yet by this time application developers were dragging
their feet because they felt duped by the excitement surrounding GTK+ 3 --
and they saw what was coming after that disappointing release.
By 2013, the GNOME team hardly saw any reason to keep very much of the
interface traditional, since only GNOME and a few other software packages
used it yet -- the truly big names such as the GIMP, Inkscape and VMWare
were yet to come. Because of this sticky situation, they decided to add
and remove features as they saw fit without asking the rest of the
community first. (Notification is one thing; participation in the
decision-making process is another completely different matter.) One of
the first products of their GNOME-ization was the header bar, a widget
which remotely resembled a window title bar but was taller and had enough
space to include other widgets. It also replaced the ordinary title bar,
replicating the Close button and other window controls on the side of the
widget. Sometimes, especially in dialogs, the Close button would not
even be present, and the buttons that used to be at the bottom of the
dialog would be moved to the top of the header bar instead. This worked
well for touchscreen users -- larger onscreen elements make it easier to
tap on the correct one -- but was disfavorable to everyone else, who was
used to mouse muscle memory.
Furthermore, several settings and even entire objects and widgets were
deprecated in subsequent versions. One of these was the GtkStatusIcon,
which could be used to display an icon in the status bar provided by
most operating systems. It was removed in version 3.14 without published
grounds. Also in version 3.10, a setting to alter the size of icons in
buttons, menu items, and the like was removed, and unconfigurable values
were hard-coded into GTK+. This may not have been such a bad thing, but
the GTK+ developers chose to use microscopic icon sizes for buttons and
menus, which led to complaints from people who are marginally visually
impaired but they don't like to wear glasses all the time. Over half a
dozen settings were deprecated and promptly ignored by GTK+ 3.10, including
gtk-auto-mnemonics, gtk-button-images, gtk-can-change-accels,
gtk-color-palette, gtk-color-scheme, gtk-enable-mnemonics, and
gtk-menu-images. Respectively, these settings were formerly used for:
gtk-auto-mnemonics: Whether keyboard shortcut mnemonics should be
automatically underlined when the user presses the shortcut key,
typically Alt.
gtk-button-images: Whether images should be shown on buttons.
gtk-can-change-accels: Whether the user can edit the keyboard
shortcut for a menu item simply by typing the new shortcut while
the mouse pointer is hovering over the menu item.
gtk-color-palette: The set of colors shown by default in the color
selector. Note that the more modern color selector does not use this
property.
gtk-color-scheme: The set of colors used by the theme. Used to
produce color variants of a theme. This option was actually removed
in version 3.8.
gtk-enable-mnemonics: Whether keyboard shortcut mnemonics should
be underlined at all times.
gtk-menu-images: Whether images should be shown on menu items.
The sudden contention for only the GNOME developers themselves was not
only quixotic, it served to further distance GTK+ 3 from other projects!
If the GNOME developers believed it was only rightful that they optimize
the GTK+ for themselves, then why should anybody else get on board with
GTK+ 3?
Red Hat turns the tables: GTK+ 3.16 through GTK+ 3.20
So, if GTK+ 3 flopped, how are we where we are today, with GTK+ 3 suddenly
being forced down our throats? It turns out it was probably started by
Red Hat. By 2015, Red Hat was already indicating that it was planning on
removing GTK+ 2 from its repositories and, by extension, its technical
support repertoire. So Red Hat basically said that they would no longer
offer companies who paid for technical support any support for GTK+ 2.
Needless to say, this started a panic. Many developers realized that they
needed to get their act in gear and port to GTK+ 3 if they wanted to be
taken seriously. This was about the time that Inkscape and VMWare ported
to GTK+ 3. It was also when Mozilla began offering official builds of
their applications built with GTK+ 3. A large enough corporate entity
can control all of us if it wants to.
But some projects remained stubborn. Most notably, the GIMP did not
produce a GTK+ 3 version; they were fairly anti-GTK+ 3 even from the
very start. Even today, the GIMP still has not provided a stable
release built with GTK+ 3, although work progresses on a port as we
speak.
GTK+ 3 continued to develop into a more and more touchscreen-friendly
interface, mandating more and more rules from the GNOME Human Interface
Guidelines on all GTK+ 3 applications. One of the watershed moments of
GTK+ 3 was when the scrolling system was redesigned. Though it meant
that touchscreen (and later touchpad) users could scroll up and down
a page of text smoothly (a mechanism known as "kinetic scrolling"), many
other aspects of the scrolling system were inadvertently broken. For
one, the scrollbar steppers ceased to scroll by reasonable amounts at
a time; they only scrolled by single pixels at a time, though this change
was likely unnoticed because Adwaita, the default GTK+ theme by this time,
did not display any scrollbar steppers. Initially, when any part of the
scrollbar was clicked on, the slider would immediately jump to that
exact location on the page; this change was later reverted (actually, a
setting was instead put in place) when a protest by the community
threatened to become a virtual riot. And the scrolling behavior brought
with it the unfortunate truth that scrolling became painfully slow on
older hardware.
The death of GTK+ 2 and the conception of GTK+ 4: GTK+ 3.22 & 3.24
By 2016, already there was discussion about what GTK+ 4 would bring.
Very early on, it was realized even by the GTK+ developers that GTK+ 3
was kind of slow. Hence, to counteract the sluggishness of GTK+ 3,
version 4 would take more advantage of the graphics hardware in the
host computer -- while leaving old graphics hardware behind. The plans
were drawn up and GTK+ 4 development began.
At some point, a GTK+ developer realized that the plus sign on the GTK+
name was too hard to type, so the historic decision was finally made to
drop the plus sign from a later development version of GTK+ 4. Hence
GTK 4 is the new name for the up-and-coming graphical toolkit.
At about the same time GTK+ 4 was announced, a new version of GTK+ 3 came
out: GTK+ 3.22. This was staged to be the last version of GTK+ 3. In
reality, like in 2011 with GTK+ 2.24, GTK 4 needed more time to mature
and thus GTK+ 3.24 was released eventually.
It's also important to note that GTK+ 2 is not alive and well anymore.
In 2018, the last release of GTK+ 2 was produced: GTK+ 2.24.32. It was
announced that GTK+ 2 would never be released again. By 2020, the present
year as I write this, some distributions had actually, finally, started
dropping GTK+ 2 from their repositories. Fedora, being Red Hat-sponsored,
was one of the first to do so. Finally, GTK+ 2 had been beaten in an
18-year-long battle.
What does this all mean for the future?
First of all, I am proud of you if you managed to get all the way to here
without passing out first. That was a lot of material about history, and
I could forgive you if you didn't read everything. That said, I'll be
using history as my prediction system, so if you don't understand
something that I'm saying, just look back up at the history list.
That said, I think we should look at where GTK 4 will be in a few years
from now, perhaps around version 4.10. As I already said, a lot changed
in GTK+ 2 from its beginning until its end, and a lot has changed with
GTK+ 3 from the time of GTK+ 3.0.0 through the time of 3.14. As I already
mentioned, GTK+ 3.0.0 was actually still pretty conservative; it took
until version 3.8 or so before things really started going haywire, so to
speak.
Taking GTK+ 3 as an example, I think many features of GTK 4 that were not
removed initially, such as the toolbars (albeit in a crude form now) and
the menu bars (excuse me -- popover menu bars), will be deprecated by
GTK 4.10 or whereabouts. Sure, when a feature is deprecated, it is not
removed immediately; you can theoretically continue using the feature.
But when GTK 5 comes out, the feature is gone for good (at least from GTK
5). Plus, some deprecated features of GTK+ 3 no longer work anyway: All
of the settings which I quoted above as being "removed" were just
deprecated, but they have effectively been removed because GTK+ will not
react to any value set in any of those settings. Furthermore, take a look
at this deprecated style property for menu items with a checkbox next to
them: The indicator-size property for years would contain the actual
width of the checkbox itself in pixels. A typical value was 16, but the
value for my GTK+ 3 theme that I'm using right now (TraditionalOk) is 14.
Now, why does this matter? Well, Mozilla applications rely on the value
of this property to know how large to draw the checkbox in the menu.
Prior to GTK+ 3.20, this indicator-size property had a meaningful
value. By GTK+ 3.20, the property had been deprecated and no longer was
a source of useful information; it always reflected that the checkbox
width was 16 pixels, even if it was actually 14! Why does this all make
any difference, besides having slightly big checkboxes? Well, the theme
I'm using does not use vector graphics very much; the checkbox image is
a standard, unscalable raster image, so if a Mozilla application is duped
into drawing this indicator 16 pixels wide (which they are duped), then
the indicator is scaled up and looks fuzzy, and the result is I can't
always tell what state a checkbox is in anymore. That's the significance.
Come to think of it, deprecating and then immediately (intentionally)
breaking a feature is thoughtless. There is almost no point to
deprecating the feature as opposed to simply eliminating it. But I
digress.
So my thought is that the (already meager) toolbar and popover menu
support that we do have will probably be broken in some way by GTK+ 4.10.
It's really not hard to imagine that -- as I already mentioned in my
previous article, even the GTK 4 demo application does not use the new
"toolbar style class". And the error actually appeared in two demo
applications, not just one. It's not hard to add the style class to the
applications; at most it's three lines of code added to each application.
Futhermore, we are heading into an era of changes being made without
formal announcements of any kind. Think of the scrollbar steppers having
gone missing without any obvious documentation about that. In fact, the
documentation even misleadingly still documents the steppers. On the
other hand, maybe it will get documented when GTK 4.0.0 actually comes
out later this year, perhaps September 25th or whereabouts.
Now you may be thinking, "Well, we've got years to go on this issue; why
are you so worried about GTK 4 as of yet?" Well, by the time GTK 4.0.0
actually does come out, the latest version of GTK+ 3 will probably be
3.24.23. As for the significance of that version number, few versions of
GTK have ever had a micro version number that high. (The micro version
of a release is the rightmost of the three digits in the version number.)
GTK+ 2.24 wound up reaching micro version 32, but that was a very special
exception; previously it was rare to go above 15. And unlike GTK+ 2.24,
GTK+ 3.24 was not released almost in tandem with GTK 4.0.0; in fact, the
first release of GTK+ 3.24 was in early 2019, by now a year and a half
ago. Furthermore, GTK+ 3.24 has not been getting very many bug fixes or
changes applied to it lately; each release brings relatively minor
changes, even by micro version standards. And last but not least, I think
GTK 4 is roughly what the GTK team wanted GTK+ 3 to be like all along.
So no, I do not think that GTK+ 3 will continue much longer.
And you may now be thinking, "Maintenance schmaintenance! Who cares if
it's actively maintained?" But if you're asking this question, I direct
you to immediately try to compile GTK+ 3.0.0 on a modern operating system.
Chances are the compilation process will not work. It's because GTK+
3.0.0 depends on a feature in GDK-PixBuf (basically, the GTK image
handling library) which was not deprecated back in 2011 but is deprecated
now. To use the feature now requires a little extra code to ensure some
deprecated features are enabled. So point number 1 is that the code you
save up today may not work for you in a few years. (I tend to think of
software as being like money, and the progress of software development as
being inflation. In such a system, software is okay to use as long as
you don't attempt to hold onto it; if you do, it decreases in value until
it eventually becomes nearly worthless.)
The other problem with unmaintained software is that you basically are
committing yourself to putting up with the same bugs in the same software
for years to come -- without any likelihood that the bugs will be ironed
out in the next release, or the release after that. I have far too much
experience with this issue, and thus I have a slight sour taste in my
mouth about doing it all over again. You wouldn't have guessed how
infuriating GNOME 2 could be if you had to put up with the same bugs
over and over again... So point number 2 is that the software may drive
you nuts over time and you might be another reluctant adopter of GTK 4
eventually.
And as for the future concerning Wayland: I suspect the GNOME developers
are frustrated that X is still used today despite it being more than 35
years old. Very obviously, GNOME has launched a campaign to make the
GNOME experience better on Wayland than on X. (I've used the most modern
versions of GNOME to an extent. The Wayland version is much faster and
generally smoother than the version for X.) GTK 4 is not as smooth
sailing on X as it is on Wayland; there are numerous flaws, and based on
how GNOME bug reports have gone in the past, either the developers are
interested in patching the flaw or they're not. And if they're not, then
the bug report will stay open until the bug is not an issue -- perhaps
because by then they've decided the X backend is buggy enough -- sorry,
I mean too buggy -- that nobody uses it anymore and they therefore have
no need to continue "maintaining" it. I suspect by GTK 4.16 (if it ever
gets to that high a version number) that the X backend will be deprecated
or even removed already, and almost certainly will be removed by GTK 5.
Think of when support for Mir (Ubuntu's windowing system similar to
Wayland) was dropped in 2019 -- that was not in a major release, that was
in the (relatively) minor release of GTK+ 3.24. Sure, almost nobody
still used Mir, since it went out of vogue when Ubuntu dropped their own
Unity desktop years earlier; but my prediction is that like Mir, X will
also become obsolete by 2030 or whereabouts, at least to the GNOME
community who only need to run GNOME applications.
In conclusion
I envision a time from now, maybe around 2030, when GTK 4 has all
non-GNOME-centric features deprecated and GTK 5 is the final major version
of GTK. At that point, the only thing to maintain in GTK 5 is bug fixes,
platform changes, et cetera, not any feature changes. I have reason to
believe that by 2030, GTK will have so few users left (because everyone
else has deserted for Qt or something) that the only users it will have
left are those who actually use GNOME. My ultimate prediction is that
within about three years after GTK 5 is released, touchscreens will go
out of vogue and GTK and GNOME will collapse. At that point, anyone left
in the sinking boat will be astonished that such a great piece of software
could meet such a terrible end. In the end though, the rest of us will
realize that software -- and any product for that matter -- is not great
because of its history:
Software is great because of its content and, ultimately, because of
its management.
Suppose you have a company with a good reputation. All that your
customers can think of is how great the company is. Then you sell your
company off to an apparently well-intentioned investor, and it turns out
that the investor is only interested in reaping the profits from the
company and turns the company into a disaster. This is not a good
company anymore; it was a good company, but your nostalgia is not going
to buy you anything, not even one of their products. And it certainly is
not going to buy you anything when the company files for bankruptcy due
to mismanagement. A company is defined by who the people are -- not by
who the people were -- at least in the modern world.
Thank you. You have now made it to the end of the article. Congratulations!
I'm very surprised anybody managed to read this thing the whole way through. It's over 44,000 characters of run-on diatribe about GTK.
Envoyé par DarkNihilius
?
.
Noël Malware in CPC HS33 - Spécial années 2000
Répondre avec citation
Règles de messages