<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/debian, branch v2.2.0</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>Debian/Ubuntu, FreeBSD and website updates for v2.1.1 release</title>
<updated>2024-11-17T22:39:17+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-11-17T22:39:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=02ab80c1f94ef89f5cf247a6d8baa7e612e51f25'/>
<id>02ab80c1f94ef89f5cf247a6d8baa7e612e51f25</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>fully support relocatable binaries, improving AppImages</title>
<updated>2024-11-05T09:32:04+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-11-04T22:29:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=9cce7d263ea3f2984a619cdfcb54d264c6a4c51d'/>
<id>9cce7d263ea3f2984a619cdfcb54d264c6a4c51d</id>
<content type='text'>
* You can now specify `--with-scitecodatadir` as a relative path,
  that will be interpreted relative to the binary's location.
* Win32 binaries already were relocatable, but this was a Windows-specific
  hack. Win32 binaries are now built with `--with-scitecodatadir=.`
  since everything is in a single directory.
* Ubuntu packages are now also built `--with-scitecodatadir=../share/sciteco`.
  This is not crucial for ordinary installations, but is meant for AppImage creation.
* Since AppImages are now built from relocatable packages,
  we no longer need the unionfs-workaround from pkg2appimage.
  This should fix the strange root contents when autocompleting in
  AppImage builds.
* This might also fix the appimage.github.io CI issues.
  I assume that because I could reproduce the issue on FreeBSD's
  Linuxulator in dependence of pkg2appimage's "union"-setting.
  See https://github.com/AppImage/appimage.github.io/pull/3402
* Determining the binary location actually turned out be hard and
  very platform-dependant. There are now implementations for Windows
  (which could also read argv[0]), Linux and generic UNIX (which
  works on FreeBSD, but I am not sure about the others).
  I believe this could also be useful on Mac OS to create app bundles,
  but this needs to be tested - currently the Mac OS binaries are
  installed into fixed locations and don't use relocation.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* You can now specify `--with-scitecodatadir` as a relative path,
  that will be interpreted relative to the binary's location.
* Win32 binaries already were relocatable, but this was a Windows-specific
  hack. Win32 binaries are now built with `--with-scitecodatadir=.`
  since everything is in a single directory.
* Ubuntu packages are now also built `--with-scitecodatadir=../share/sciteco`.
  This is not crucial for ordinary installations, but is meant for AppImage creation.
* Since AppImages are now built from relocatable packages,
  we no longer need the unionfs-workaround from pkg2appimage.
  This should fix the strange root contents when autocompleting in
  AppImage builds.
* This might also fix the appimage.github.io CI issues.
  I assume that because I could reproduce the issue on FreeBSD's
  Linuxulator in dependence of pkg2appimage's "union"-setting.
  See https://github.com/AppImage/appimage.github.io/pull/3402
* Determining the binary location actually turned out be hard and
  very platform-dependant. There are now implementations for Windows
  (which could also read argv[0]), Linux and generic UNIX (which
  works on FreeBSD, but I am not sure about the others).
  I believe this could also be useful on Mac OS to create app bundles,
  but this needs to be tested - currently the Mac OS binaries are
  installed into fixed locations and don't use relocation.
</pre>
</div>
</content>
</entry>
<entry>
<title>updated ChangeLog, FreeBSD and Debian packages for v2.1.0 release</title>
<updated>2024-10-16T15:31:53+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-10-16T15:31:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=90d8e66fee5ecaba6f3bddd497a41390629a1b9e'/>
<id>90d8e66fee5ecaba6f3bddd497a41390629a1b9e</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>prefer libncursesw (widechar variant) (refs #5)</title>
<updated>2024-09-09T16:17:03+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-08-28T12:03:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=f79a6f65acde9753ea65887e0e0d4bc7f76ff52b'/>
<id>f79a6f65acde9753ea65887e0e0d4bc7f76ff52b</id>
<content type='text'>
* Some platforms like Ubuntu actually ship widechar and non-widechar versions
  of ncurses with different pkg-config files.
  Other platforms like FreeBSD will ship an "ncursesw" and "ncurses" pkg-config file
  but both point to the same wide-char library anyway.
* Currently we are not using wide-char APIs to ensure maximum compatibility even with
  embedded systems where ncurses might be built without widechar support.
  But in order to handle Unicode correctly, we still need to link against the widechar version
  of ncurses (if available).
* Compilation on platforms without a widechar ncurses is now handled by the common
  AC_CHECK_LIB() fallback (which might actually find a widechar version anyway if it just
  didn't install the pkg-config file).
  If necessary, we could also check for the "ncurses" package if "ncursesw" is not found.
* This fixes Unicode display and input on Ubuntu.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Some platforms like Ubuntu actually ship widechar and non-widechar versions
  of ncurses with different pkg-config files.
  Other platforms like FreeBSD will ship an "ncursesw" and "ncurses" pkg-config file
  but both point to the same wide-char library anyway.
* Currently we are not using wide-char APIs to ensure maximum compatibility even with
  embedded systems where ncurses might be built without widechar support.
  But in order to handle Unicode correctly, we still need to link against the widechar version
  of ncurses (if available).
* Compilation on platforms without a widechar ncurses is now handled by the common
  AC_CHECK_LIB() fallback (which might actually find a widechar version anyway if it just
  didn't install the pkg-config file).
  If necessary, we could also check for the "ncurses" package if "ncursesw" is not found.
* This fixes Unicode display and input on Ubuntu.
</pre>
</div>
</content>
</entry>
<entry>
<title>debian package: updated copyright to 2024</title>
<updated>2024-08-23T03:04:06+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-08-23T03:04:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=1e696506e8bae811ba42253da2391380f921a4c3'/>
<id>1e696506e8bae811ba42253da2391380f921a4c3</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>fully support out of tree builds</title>
<updated>2024-08-23T02:51:55+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-08-23T02:13:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ee9cf43587d5fef3a0f6d97ef50b8cf848945bcb'/>
<id>ee9cf43587d5fef3a0f6d97ef50b8cf848945bcb</id>
<content type='text'>
* You no longer have to copy contrib/scintilla, contrib/scinterm and contrib/lexilla
  manually to the build directory.
* It turns out, that Scintilla/Lexilla was supporting this since 2016.
  Scintilla allows pointing to a source directory (srdir) and Lexilla to a binary directory (DIR_O).
* For Scinterm I opened a pull request in order to add srcdir/basedir variables:
  https://github.com/orbitalquark/scinterm/pull/21
* `make distcheck` is therefore now also fixed.
* The FreeBSD package is now allowed to build out of source.
  I haven't tested it yet.
* See also https://github.com/ScintillaOrg/lexilla/issues/266
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* You no longer have to copy contrib/scintilla, contrib/scinterm and contrib/lexilla
  manually to the build directory.
* It turns out, that Scintilla/Lexilla was supporting this since 2016.
  Scintilla allows pointing to a source directory (srdir) and Lexilla to a binary directory (DIR_O).
* For Scinterm I opened a pull request in order to add srcdir/basedir variables:
  https://github.com/orbitalquark/scinterm/pull/21
* `make distcheck` is therefore now also fixed.
* The FreeBSD package is now allowed to build out of source.
  I haven't tested it yet.
* See also https://github.com/ScintillaOrg/lexilla/issues/266
</pre>
</div>
</content>
</entry>
<entry>
<title>Debian: fixed rules (build and binary targets)</title>
<updated>2023-06-20T14:40:54+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-06-20T03:07:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=b709f27a4cdbb60ed99f09f8a66c1541bd6c888a'/>
<id>b709f27a4cdbb60ed99f09f8a66c1541bd6c888a</id>
<content type='text'>
* dh_testdir would sometimes cause problems on the PPA servers,
  so we replaced it with an empty rule.
* We need to define the binary-arch and binary-indep targets
  in order to recurse into the correct subdirectories.
  I do not understand why this always worked on the Github runner
  and sometimes even on the PPA servers.
  Unfortunately, we cannot just call `dh binary-arch -B... -p...`
  since that would call `dh_install -a` which overrides any `-p` (package),
  thus trying to install the curses binaries from the Gtk build directory
  and vice versa.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* dh_testdir would sometimes cause problems on the PPA servers,
  so we replaced it with an empty rule.
* We need to define the binary-arch and binary-indep targets
  in order to recurse into the correct subdirectories.
  I do not understand why this always worked on the Github runner
  and sometimes even on the PPA servers.
  Unfortunately, we cannot just call `dh binary-arch -B... -p...`
  since that would call `dh_install -a` which overrides any `-p` (package),
  thus trying to install the curses binaries from the Gtk build directory
  and vice versa.
</pre>
</div>
</content>
</entry>
<entry>
<title>Debian: updated/modernized config files</title>
<updated>2023-06-20T14:40:54+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-06-20T03:03:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=fe9e438e3302b4078e18f1591eb81296da104d1a'/>
<id>fe9e438e3302b4078e18f1591eb81296da104d1a</id>
<content type='text'>
* This resolves must lintian warnings and errors.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This resolves must lintian warnings and errors.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixup 75533443ecae81d6861bdc1402a0e4b271838979: fixes sciteco-gtk Debian packages</title>
<updated>2023-06-19T23:51:49+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-06-19T23:51:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=5c49ea422a8dc29a44f24ce579d88496e7bf8d66'/>
<id>5c49ea422a8dc29a44f24ce579d88496e7bf8d66</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>distribute sciteco.desktop</title>
<updated>2023-06-19T18:20:13+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-06-19T18:20:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=75533443ecae81d6861bdc1402a0e4b271838979'/>
<id>75533443ecae81d6861bdc1402a0e4b271838979</id>
<content type='text'>
* Useful for packaging on platforms where we can only build from tarballs (FreeBSD)
* I don't know whether it's always safe and correct to install this file into $DATADIR/applications,
  so the file is only distributed but not installed yet.
* It contains a hardcoded binary name "gsciteco". This could actually differ
  depending on the concrete --program-prefix and it would be good to include the exact
  installation path.
  This however is not possible as long as we do not install this file.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Useful for packaging on platforms where we can only build from tarballs (FreeBSD)
* I don't know whether it's always safe and correct to install this file into $DATADIR/applications,
  so the file is only distributed but not installed yet.
* It contains a hardcoded binary name "gsciteco". This could actually differ
  depending on the concrete --program-prefix and it would be good to include the exact
  installation path.
  This however is not possible as long as we do not install this file.
</pre>
</div>
</content>
</entry>
</feed>
