<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/m4/gob2.m4, branch v2.5.2</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>get rid of the GObject Builder (GOB2): converted teco-gtk-info-popup.gob and teco-gtk-label.gob to plain C</title>
<updated>2021-06-08T16:48:16+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-06-07T15:58:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=073f5f28b835d3bda5e8771383c26d78d9740768'/>
<id>073f5f28b835d3bda5e8771383c26d78d9740768</id>
<content type='text'>
* Using modern GObject idioms and macros greatly reduces the necessary boilerplate code.
* The plain C versions of our GObject classes are now "final" (cannot be derived)
  This means we can hide the instance structures from the headers and avoid using
  explicit private fields.
* Avoids some deprecation warnings when building the Gtk UI.
* GOB2 is apparently no longer maintained, so this seems like a good idea in the long run.
* The most important reason however is that there is no precompiled GOB2 for Windows
  which prevents compilation on native Windows hosts, eg. during nightly builds.
  This is even more important as Gtk+3 is distributed on Windows practically
  exclusively via MSYS.
  (ArchLinux contains MinGW gtk3 packages as well, so cross-compiling from ArchLinux
  would have been an alternative.)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Using modern GObject idioms and macros greatly reduces the necessary boilerplate code.
* The plain C versions of our GObject classes are now "final" (cannot be derived)
  This means we can hide the instance structures from the headers and avoid using
  explicit private fields.
* Avoids some deprecation warnings when building the Gtk UI.
* GOB2 is apparently no longer maintained, so this seems like a good idea in the long run.
* The most important reason however is that there is no precompiled GOB2 for Windows
  which prevents compilation on native Windows hosts, eg. during nightly builds.
  This is even more important as Gtk+3 is distributed on Windows practically
  exclusively via MSYS.
  (ArchLinux contains MinGW gtk3 packages as well, so cross-compiling from ArchLinux
  would have been an alternative.)
</pre>
</div>
</content>
</entry>
<entry>
<title>replace custom Gob2 check with GOB2_CHECK() from gob2.m4</title>
<updated>2016-02-18T16:41:25+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-02-18T16:41:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=58a395c9ad73720a6b65e7c1d2769978cc2c23c6'/>
<id>58a395c9ad73720a6b65e7c1d2769978cc2c23c6</id>
<content type='text'>
 * Allows us to check for the Gob2 version at ./configure time
 * this file ships with Gob2 installations, so in most cases
   it could be found without shipping it with SciTECO.
 * Autoconf is built such that source distributions will contain
   all additional external macros compiled in aclocal.m4.
 * However if somebody builds from Git, he/she would still
   expect the ./configure checks to produce meaningful results
   even if not all dependencies are installed properly.
   It therefore seems to be good practice to include all
   external M4 macros (gob2.m4) as a fallback with the source tree.
 * /usr/share/aclocal contains many more useful m4 macros.
   However since we can depend on pkg-config e.g. for finding
   Gtk+ and Glib, I won't use those macros as else I would
   have to bundle them to achieve the same kind of ./configure
   robustness.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * Allows us to check for the Gob2 version at ./configure time
 * this file ships with Gob2 installations, so in most cases
   it could be found without shipping it with SciTECO.
 * Autoconf is built such that source distributions will contain
   all additional external macros compiled in aclocal.m4.
 * However if somebody builds from Git, he/she would still
   expect the ./configure checks to produce meaningful results
   even if not all dependencies are installed properly.
   It therefore seems to be good practice to include all
   external M4 macros (gob2.m4) as a fallback with the source tree.
 * /usr/share/aclocal contains many more useful m4 macros.
   However since we can depend on pkg-config e.g. for finding
   Gtk+ and Glib, I won't use those macros as else I would
   have to bundle them to achieve the same kind of ./configure
   robustness.
</pre>
</div>
</content>
</entry>
</feed>
