<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src/interface-gtk/Makefile.am, 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>refactored GTK implementation of teco_view_t into its own file</title>
<updated>2025-03-02T00:52:37+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-02T00:38:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=20f530f7e8acc2b658aa63f90f96b6ddbc4430d3'/>
<id>20f530f7e8acc2b658aa63f90f96b6ddbc4430d3</id>
<content type='text'>
Also makes sense since all other GObject classes are in separate files.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Also makes sense since all other GObject classes are in separate files.
</pre>
</div>
</content>
</entry>
<entry>
<title>the SciTECO data installation path is now configurable via --with-scitecodatadir</title>
<updated>2023-06-19T17:45:16+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-06-19T17:45:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=60a09132b62c3cae86f5e832830a4490ba5bf712'/>
<id>60a09132b62c3cae86f5e832830a4490ba5bf712</id>
<content type='text'>
* This is also the base of $SCITECOPATH.
* Changing it is useful for packaging where it is not possible to factor out the common
  files between Curses and Gtk builds into a "sciteco-common" package.
  As an alternative, you can now create disjunct sciteco-curses and sciteco-gtk packages.
* You will most likely want to use this for Gtk builds as in:
  --with-interface=gtk --program-prefix=g --with-scitecodatadir=/usr/local/share/gsciteco.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This is also the base of $SCITECOPATH.
* Changing it is useful for packaging where it is not possible to factor out the common
  files between Curses and Gtk builds into a "sciteco-common" package.
  As an alternative, you can now create disjunct sciteco-curses and sciteco-gtk packages.
* You will most likely want to use this for Gtk builds as in:
  --with-interface=gtk --program-prefix=g --with-scitecodatadir=/usr/local/share/gsciteco.
</pre>
</div>
</content>
</entry>
<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>THE GREAT CEEIFICATION EVENT</title>
<updated>2021-05-30T01:12:56+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-05-30T00:38:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=432ad24e382681f1c13b07e8486e91063dd96e2e'/>
<id>432ad24e382681f1c13b07e8486e91063dd96e2e</id>
<content type='text'>
This is a total conversion of SciTECO to plain C (GNU C11).
The chance was taken to improve a lot of internal datastructures,
fix fundamental bugs and lay the foundations of future features.
The GTK user interface is now in an useable state!
All changes have been squashed together.

The language itself has almost not changed at all, except for:

* Detection of string terminators (usually Escape) now takes
  the string building characters into account.
  A string is only terminated outside of string building characters.
  In other words, you can now for instance write
  I^EQ[Hello$world]$
  This removes one of the last bits of shellisms which is out of
  place in SciTECO where no tokenization/lexing is performed.
  Consequently, the current termination character can also be
  escaped using ^Q/^R.
  This is used by auto completions to make sure that strings
  are inserted verbatim and without unwanted sideeffects.
* All strings can now safely contain null-characters
  (see also: 8-bit cleanliness).
  The null-character itself (^@) is not (yet) a valid SciTECO
  command, though.

An incomplete list of changes:

* We got rid of the BSD headers for RB trees and lists/queues.
  The problem with them was that they used a form of metaprogramming
  only to gain a bit of type safety. It also resulted in less
  readble code. This was a C++ desease.
  The new code avoids metaprogramming only to gain type safety.
  The BSD tree.h has been replaced by rb3ptr by Jens Stimpfle
  (https://github.com/jstimpfle/rb3ptr).
  This implementation is also more memory efficient than BSD's.
  The BSD list.h and queue.h has been replaced with a custom
  src/list.h.
* Fixed crashes, performance issues and compatibility issues with
  the Gtk 3 User Interface.
  It is now more or less ready for general use.
  The GDK lock is no longer used to avoid using deprecated functions.
  On the downside, the new implementation (driving the Gtk event loop
  stepwise) is even slower than the old one.
  A few glitches remain (see TODO), but it is hoped that they will
  be resolved by the Scintilla update which will be performed soon.
* A lot of program units have been split up, so they are shorter
  and easier to maintain: core-commands.c, qreg-commands.c,
  goto-commands.c, file-utils.h.
* Parser states are simply structs of callbacks now.
  They still use a kind of polymorphy using a preprocessor trick.
  TECO_DEFINE_STATE() takes an initializer list that will be
  merged with the default list of field initializers.
  To "subclass" states, you can simply define new macros that add
  initializers to existing macros.
* Parsers no longer have a "transitions" table but the input_cb()
  may use switch-case statements.
  There are also teco_machine_main_transition_t now which can
  be used to implement simple transitions. Additionally, you
  can specify functions to execute during transitions.
  This largely avoids long switch-case-statements.
* Parsers are embeddable/reusable now, at least in parse-only mode.
  This does not currently bring any advantages but may later
  be used to write a Scintilla lexer for TECO syntax highlighting.
  Once parsers are fully embeddable, it will also be possible
  to run TECO macros in a kind of coroutine which would allow
  them to process string arguments in real time.
* undo.[ch] still uses metaprogramming extensively but via
  the C preprocessor of course. On the downside, most undo
  token generators must be initiated explicitly (theoretically
  we could have used embedded functions / trampolines to
  instantiate automatically but this has turned out to be
  dangereous).
  There is a TECO_DEFINE_UNDO_CALL() to generate closures for
  arbitrary functions now (ie. to call an arbitrary function
  at undo-time). This simplified a lot of code and is much
  shorter than manually pushing undo tokens in many cases.
* Instead of the ridiculous C++ Curiously Recurring Template
  Pattern to achieve static polymorphy for user interface
  implementations, we now simply declare all functions to
  implement in interface.h and link in the implementations.
  This is possible since we no longer hace to define
  interface subclasses (all state is static variables in
  the interface's *.c files).
* Headers are now significantly shorter than in C++ since
  we can often hide more of our "class" implementations.
* Memory counting is based on dlmalloc for most platforms now.
  Unfortunately, there is no malloc implementation that
  provides an efficient constant-time memory counter that
  is guaranteed to decrease when freeing memory.
  But since we use a defined malloc implementation now,
  malloc_usable_size() can be used safely for tracking memory use.
  malloc() replacement is very tricky on Windows, so we
  use a poll thread on Windows. This can also be enabled
  on other supported platforms using --disable-malloc-replacement.
  All in all, I'm still not pleased with the state of memory
  limiting. It is a mess.
* Error handling uses GError now. This has the advantage that
  the GError codes can be reused once we support error catching
  in the SciTECO language.
* Added a few more test suite cases.
* Haiku is no longer supported as builds are instable and
  I did not manage to debug them - quite possibly Haiku bugs
  were responsible.
* Glib v2.44 or later are now required.
  The GTK UI requires Gtk+ v3.12 or later now.
  The GtkFlowBox fallback and sciteco-wrapper workaround are
  no longer required.
* We now extensively use the GCC/Clang-specific g_auto
  feature (automatic deallocations when leaving the current
  code block).
* Updated copyright to 2021.
  SciTECO has been in continuous development, even though there
  have been no commits since 2018.
* Since these changes are so significant, the target release has
  been set to v2.0.
  It is planned that beginning with v3.0, the language will be
  kept stable.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a total conversion of SciTECO to plain C (GNU C11).
The chance was taken to improve a lot of internal datastructures,
fix fundamental bugs and lay the foundations of future features.
The GTK user interface is now in an useable state!
All changes have been squashed together.

The language itself has almost not changed at all, except for:

* Detection of string terminators (usually Escape) now takes
  the string building characters into account.
  A string is only terminated outside of string building characters.
  In other words, you can now for instance write
  I^EQ[Hello$world]$
  This removes one of the last bits of shellisms which is out of
  place in SciTECO where no tokenization/lexing is performed.
  Consequently, the current termination character can also be
  escaped using ^Q/^R.
  This is used by auto completions to make sure that strings
  are inserted verbatim and without unwanted sideeffects.
* All strings can now safely contain null-characters
  (see also: 8-bit cleanliness).
  The null-character itself (^@) is not (yet) a valid SciTECO
  command, though.

An incomplete list of changes:

* We got rid of the BSD headers for RB trees and lists/queues.
  The problem with them was that they used a form of metaprogramming
  only to gain a bit of type safety. It also resulted in less
  readble code. This was a C++ desease.
  The new code avoids metaprogramming only to gain type safety.
  The BSD tree.h has been replaced by rb3ptr by Jens Stimpfle
  (https://github.com/jstimpfle/rb3ptr).
  This implementation is also more memory efficient than BSD's.
  The BSD list.h and queue.h has been replaced with a custom
  src/list.h.
* Fixed crashes, performance issues and compatibility issues with
  the Gtk 3 User Interface.
  It is now more or less ready for general use.
  The GDK lock is no longer used to avoid using deprecated functions.
  On the downside, the new implementation (driving the Gtk event loop
  stepwise) is even slower than the old one.
  A few glitches remain (see TODO), but it is hoped that they will
  be resolved by the Scintilla update which will be performed soon.
* A lot of program units have been split up, so they are shorter
  and easier to maintain: core-commands.c, qreg-commands.c,
  goto-commands.c, file-utils.h.
* Parser states are simply structs of callbacks now.
  They still use a kind of polymorphy using a preprocessor trick.
  TECO_DEFINE_STATE() takes an initializer list that will be
  merged with the default list of field initializers.
  To "subclass" states, you can simply define new macros that add
  initializers to existing macros.
* Parsers no longer have a "transitions" table but the input_cb()
  may use switch-case statements.
  There are also teco_machine_main_transition_t now which can
  be used to implement simple transitions. Additionally, you
  can specify functions to execute during transitions.
  This largely avoids long switch-case-statements.
* Parsers are embeddable/reusable now, at least in parse-only mode.
  This does not currently bring any advantages but may later
  be used to write a Scintilla lexer for TECO syntax highlighting.
  Once parsers are fully embeddable, it will also be possible
  to run TECO macros in a kind of coroutine which would allow
  them to process string arguments in real time.
* undo.[ch] still uses metaprogramming extensively but via
  the C preprocessor of course. On the downside, most undo
  token generators must be initiated explicitly (theoretically
  we could have used embedded functions / trampolines to
  instantiate automatically but this has turned out to be
  dangereous).
  There is a TECO_DEFINE_UNDO_CALL() to generate closures for
  arbitrary functions now (ie. to call an arbitrary function
  at undo-time). This simplified a lot of code and is much
  shorter than manually pushing undo tokens in many cases.
* Instead of the ridiculous C++ Curiously Recurring Template
  Pattern to achieve static polymorphy for user interface
  implementations, we now simply declare all functions to
  implement in interface.h and link in the implementations.
  This is possible since we no longer hace to define
  interface subclasses (all state is static variables in
  the interface's *.c files).
* Headers are now significantly shorter than in C++ since
  we can often hide more of our "class" implementations.
* Memory counting is based on dlmalloc for most platforms now.
  Unfortunately, there is no malloc implementation that
  provides an efficient constant-time memory counter that
  is guaranteed to decrease when freeing memory.
  But since we use a defined malloc implementation now,
  malloc_usable_size() can be used safely for tracking memory use.
  malloc() replacement is very tricky on Windows, so we
  use a poll thread on Windows. This can also be enabled
  on other supported platforms using --disable-malloc-replacement.
  All in all, I'm still not pleased with the state of memory
  limiting. It is a mess.
* Error handling uses GError now. This has the advantage that
  the GError codes can be reused once we support error catching
  in the SciTECO language.
* Added a few more test suite cases.
* Haiku is no longer supported as builds are instable and
  I did not manage to debug them - quite possibly Haiku bugs
  were responsible.
* Glib v2.44 or later are now required.
  The GTK UI requires Gtk+ v3.12 or later now.
  The GtkFlowBox fallback and sciteco-wrapper workaround are
  no longer required.
* We now extensively use the GCC/Clang-specific g_auto
  feature (automatic deallocations when leaving the current
  code block).
* Updated copyright to 2021.
  SciTECO has been in continuous development, even though there
  have been no commits since 2018.
* Since these changes are so significant, the target release has
  been set to v2.0.
  It is planned that beginning with v3.0, the language will be
  kept stable.
</pre>
</div>
</content>
</entry>
<entry>
<title>removed CLANG and HAVE_SIZED_DEALLOCATION conditionals</title>
<updated>2017-04-30T02:25:22+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-04-30T02:25:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=1d689ebfec51613fcb1fe286294c85dcbb9d8574'/>
<id>1d689ebfec51613fcb1fe286294c85dcbb9d8574</id>
<content type='text'>
Automakefiles could be simplified by updating CXXFLAGS
in configure.ac instead.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Automakefiles could be simplified by updating CXXFLAGS
in configure.ac instead.
</pre>
</div>
</content>
</entry>
<entry>
<title>yet another revision of memory limiting: the glibc mallinfo() approach has been shown to be unacceptably broken, so the fallback implementation has been improved</title>
<updated>2017-03-08T11:55:06+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-03-08T11:00:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=152397e641e9d1e6a11f80e24f562c4cf2472a2f'/>
<id>152397e641e9d1e6a11f80e24f562c4cf2472a2f</id>
<content type='text'>
 * mallinfo() is not only broken on 64-bit systems but slows things
   down linearilly to the memory size of the process.
   E.g. after 500000&lt;%A&gt;, SciTECO will act sluggish! Shutting down
   afterwards can take minutes...
   mallinfo() was thus finally discarded as a memory measurement
   technique.
 * Evaluating /proc/self/statm? has also been evaluated and discarded
   because doing this frequently is even slower.
 * Instead, the fallback implementation has been drastically improved:
   * If possible use C++14 global sized deallocators, allowing memory measurements
     across the entire C++ code base with minimal runtime overhead.
     Since we only depend on C++11, a lengthy Autoconf check had to be introduced.
   * Use malloc_usable_size() with global non-sized deallocators to
     measure the approx. memory usage of the entire process (at least
     the ones done via C++).
     The cheaper C++11 sized deallocators implemented via SciTECO::Object still
     have precedence, so this affects Scintilla code only.
 * With both improvements the test case
   sciteco -e '&lt;@EU[X^E\a]"^E\a"%a&gt;'
   is handled sufficiently well now on glibc and performance is much better
   now.
 * The jemalloc-specific technique has been removed since it no longer
   brings any benefits compared to the improved fallback technique.
   Even the case of using malloc_usable_size() in strict C++ mode is
   up to 3 times faster.
 * The new fallback implementation might actually be good enough for
   Windows as well if some MSVCRT-specific support is added, like
   using _msize() instead of malloc_usable_size().
   This must be tested and benchmarked, so we keep the Windows-specific
   implementation for the time being.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * mallinfo() is not only broken on 64-bit systems but slows things
   down linearilly to the memory size of the process.
   E.g. after 500000&lt;%A&gt;, SciTECO will act sluggish! Shutting down
   afterwards can take minutes...
   mallinfo() was thus finally discarded as a memory measurement
   technique.
 * Evaluating /proc/self/statm? has also been evaluated and discarded
   because doing this frequently is even slower.
 * Instead, the fallback implementation has been drastically improved:
   * If possible use C++14 global sized deallocators, allowing memory measurements
     across the entire C++ code base with minimal runtime overhead.
     Since we only depend on C++11, a lengthy Autoconf check had to be introduced.
   * Use malloc_usable_size() with global non-sized deallocators to
     measure the approx. memory usage of the entire process (at least
     the ones done via C++).
     The cheaper C++11 sized deallocators implemented via SciTECO::Object still
     have precedence, so this affects Scintilla code only.
 * With both improvements the test case
   sciteco -e '&lt;@EU[X^E\a]"^E\a"%a&gt;'
   is handled sufficiently well now on glibc and performance is much better
   now.
 * The jemalloc-specific technique has been removed since it no longer
   brings any benefits compared to the improved fallback technique.
   Even the case of using malloc_usable_size() in strict C++ mode is
   up to 3 times faster.
 * The new fallback implementation might actually be good enough for
   Windows as well if some MSVCRT-specific support is added, like
   using _msize() instead of malloc_usable_size().
   This must be tested and benchmarked, so we keep the Windows-specific
   implementation for the time being.
</pre>
</div>
</content>
</entry>
<entry>
<title>avoid unnecessary undo token allocations in batch mode: greatly speeds up batch mode</title>
<updated>2016-02-10T14:46:17+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-02-10T14:08:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=1da5bdeb986657c5cfd83d495d15b7f2308d3b5b'/>
<id>1da5bdeb986657c5cfd83d495d15b7f2308d3b5b</id>
<content type='text'>
 * by using variadic templates, UndoStack::push() is now responsible
   for allocating undo tokens. This is avoided in batch mode.
 * The old UndoStack::push(UndoToken *) method has been made private
   to avoid confusion around UndoStack's API.
   The old UndoStack::push() no longer needs to handle !undo.enabled,
   but at least asserts on it.
 * C++11 support is now required, so variadic templates can be used.
   This could have also been done using manual undo.enabled checks;
   or using multiple versions of the template with different numbers
   of template arguments.
   The latter could be done if we one day have to support a non-C++11
   compiler.
   However since we're depending on GCC 4.4, variadic template use should
   be OK.
   Clang supports it since v2.9.
 * Sometimes, undo token pushing passed ownership of some memory
   to the undo token. The old behaviour was relied on to reclaim the
   memory even in batch mode -- the undo token was always deleted.
   To avoid leaks or repeated manual undo.enabled checking,
   another method UndoStack::push_own() had to be
   introduced that makes sure that an undo token is always created.
   In batch mode (!undo.enabled), this will however create the object
   on the stack which is much cheaper than using `new`.
 * Having to know which kind of undo token is to be pushed (taking ownership
   or not) is inconvenient. It may be better to add static methods to
   the UndoToken classes that can take care of reclaiming memory.
 * Benchmarking certain SciTECO scripts have shown 50% (!!!) speed increases
   at the highest possible optimization level (-O3 -mtune=native -march=native).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * by using variadic templates, UndoStack::push() is now responsible
   for allocating undo tokens. This is avoided in batch mode.
 * The old UndoStack::push(UndoToken *) method has been made private
   to avoid confusion around UndoStack's API.
   The old UndoStack::push() no longer needs to handle !undo.enabled,
   but at least asserts on it.
 * C++11 support is now required, so variadic templates can be used.
   This could have also been done using manual undo.enabled checks;
   or using multiple versions of the template with different numbers
   of template arguments.
   The latter could be done if we one day have to support a non-C++11
   compiler.
   However since we're depending on GCC 4.4, variadic template use should
   be OK.
   Clang supports it since v2.9.
 * Sometimes, undo token pushing passed ownership of some memory
   to the undo token. The old behaviour was relied on to reclaim the
   memory even in batch mode -- the undo token was always deleted.
   To avoid leaks or repeated manual undo.enabled checking,
   another method UndoStack::push_own() had to be
   introduced that makes sure that an undo token is always created.
   In batch mode (!undo.enabled), this will however create the object
   on the stack which is much cheaper than using `new`.
 * Having to know which kind of undo token is to be pushed (taking ownership
   or not) is inconvenient. It may be better to add static methods to
   the UndoToken classes that can take care of reclaiming memory.
 * Benchmarking certain SciTECO scripts have shown 50% (!!!) speed increases
   at the highest possible optimization level (-O3 -mtune=native -march=native).
</pre>
</div>
</content>
</entry>
<entry>
<title>added GtkCanonicalizedLabel: a label for displaying SciTECO strings</title>
<updated>2016-02-07T07:12:37+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-02-07T07:12:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=dadb20b9ba159043a892ac7050695a8a1fb04e3b'/>
<id>dadb20b9ba159043a892ac7050695a8a1fb04e3b</id>
<content type='text'>
 * those strings can contain control characters
 * the canonicalized label will automatically escape the non-printable
   characters according to the same mapping used elsewhere and shows
   them in "reverse" video.
 * reverse video is hard to achieve in Gtk, esp. for Pango versions
   that don't support transparent foregrounds
 * the current implementation does not need dedicated styling for
   reverse video characters; but this may be an option in order to
   get it right even on older Gtk versions
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * those strings can contain control characters
 * the canonicalized label will automatically escape the non-printable
   characters according to the same mapping used elsewhere and shows
   them in "reverse" video.
 * reverse video is hard to achieve in Gtk, esp. for Pango versions
   that don't support transparent foregrounds
 * the current implementation does not need dedicated styling for
   reverse video characters; but this may be an option in order to
   get it right even on older Gtk versions
</pre>
</div>
</content>
</entry>
<entry>
<title>Gtk UI: full color scheme support</title>
<updated>2016-02-02T16:49:42+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-02-02T13:42:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e768487fe3ef9ec8f94cea11ad6587c49c32422a'/>
<id>e768487fe3ef9ec8f94cea11ad6587c49c32422a</id>
<content type='text'>
 * implemented by exporting the most important Scintilla STYLEs
   as CSS variables and defining named widgets for the main UI
   components.
 * ~/.teco_css will then apply the Scintilla styles to the
   Gtk UI.
   This file is also for additional tweaks, e.g. enabling
   translucency.
 * A fallback.css is provided which does just that and is able
   to apply the terminal.tes and solarized.tes color schemes.
 * Other important aspects of theming like font sizes and names
   have not yet been dealt with.
   (We may want to apply the corresponding Scintilla settings
   to some widgets...)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * implemented by exporting the most important Scintilla STYLEs
   as CSS variables and defining named widgets for the main UI
   components.
 * ~/.teco_css will then apply the Scintilla styles to the
   Gtk UI.
   This file is also for additional tweaks, e.g. enabling
   translucency.
 * A fallback.css is provided which does just that and is able
   to apply the terminal.tes and solarized.tes color schemes.
 * Other important aspects of theming like font sizes and names
   have not yet been dealt with.
   (We may want to apply the corresponding Scintilla settings
   to some widgets...)
</pre>
</div>
</content>
</entry>
<entry>
<title>interfaces have their own automake subdirectories and convenience libraries now</title>
<updated>2016-01-31T04:04:50+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-01-31T04:04:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ea0179e342343f5fbefb265bde4dea0d475f0781'/>
<id>ea0179e342343f5fbefb265bde4dea0d475f0781</id>
<content type='text'>
 * use libtool convenience libraries as much as possible
   (for all static libraries except Scintilla)
 * improves separation of language and user interface implementations
   (e.g. the Gtk widgets are not interesting for the rest of SciTECO)
 * the Curses popup widget can now be factored out of interface-curses.cpp
 * some common CPPFLAGS are now defined by ./configure via AM_CPPFLAGS,
   so they don't have to be repeated in each submodule.
 * fixed building the Curses UI: GTK_FLOW_BOX_FALLBACK conditional
   must always be defined.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * use libtool convenience libraries as much as possible
   (for all static libraries except Scintilla)
 * improves separation of language and user interface implementations
   (e.g. the Gtk widgets are not interesting for the rest of SciTECO)
 * the Curses popup widget can now be factored out of interface-curses.cpp
 * some common CPPFLAGS are now defined by ./configure via AM_CPPFLAGS,
   so they don't have to be repeated in each submodule.
 * fixed building the Curses UI: GTK_FLOW_BOX_FALLBACK conditional
   must always be defined.
</pre>
</div>
</content>
</entry>
</feed>
