| Commit message (Collapse) | Author | Age | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently weltschmerz prefers working directory information obtained
from OSC 7 to that from procfs. If a user has not configured their shell
to emit OSC 7 escapes, the OSC 7 path may be out of date. Additionally
some users want only their shell to change the terminal's conception of
working directory, which is a behaviour better matched by the procfs
based working directory detection.
This change allows OSC 7 based working directory detection to be turned
off. The default remains to check OSC 7 first and then fall back to
procfs if there is not valid local path set with OSC 7.
The reason for turning OSC 7 off entirely instead of inverting the order
procfs and OSC 7 are checked in is that procfs based detection should
never fail under normal usage on systems that support it.
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently the configuration object is located in the function level
scope of load_config() and deleted once the function exits. Any flags
that control the program behaviour must therefore be copied into
separate variables, which pollutes the the upper level namespace.
This change keeps the configuration object around after load_config()
exits and makes it accessible by other functions from the shared
namespace. An upcoming change needs this access.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Opening a terminal or file manager window requires weltschmerz to know
the current working directory. At the moment weltschmerz relies on the
application being run in the terminal to generate OSC 7 codes that
specify the path. However, OSC 7 is not yet widely supported by default,
and the VTE terminal emulation layer, which manages the OSC 7 path state
for weltschmerz, will overwrite local paths with ones that point to a
remote computer if an OSC 7 enabled application is run under ssh.
This change adds a fallback that uses the symlink to current working
directory located at /proc/<child pid>/cwd. On Linux this method should
always work and was how these features were implemented before adoption
of OSC 7. The procfs method is used as a fallback instead of the primary
method since it can only see the working directory changes of the direct
child process.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to alert the user to any potential errors in the configuration
files, we keep track of configuration entries that we have not accessed
and print them out. These might include misspellings or otherwise
malformed strings.
To collect those unparsed configuration entries, we remove the ones that
have been successfully parsed from our in-memory KeyFile. The remaining
keys are the offending ones. Unfortunately, because KeyFile.remove_key()
removes only one matching key, we might also be left with any duplicates
that would otherwise be valid entries.
So, if the entry misc.font is specified twice, we currently warn about
an "unknown" key, the second misc.font entry. This could potentially be
misleading to the user.
Since it is too expensive to fix this issue in the code, make sure we
warn instead about "unknown or duplicate" keys. This way we say the
correct thing without incurring a big complexity cost.
|
| |
|
|
|
|
|
|
| |
Both xgettext(1) and msgmerge(1) break messages by default. Since we
currently do not have particularly long strings marked for translation,
turn this particular behaviour off by passing --no-wrap. It would
otherwise lead to spurious breaks in the PO and POT files that are not
particularly nice.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We currently consider periods, commas, colons, semicolons, exclamation
points and question marks following a URL as part of it. While ending a
URL with these characters is technically speaking valid, more commonly
they are a result of people ending a clause with a URL. Let's ignore
such characters if they are present at the very end of a URL.
Make sure to still match them, however, if any non-punctuation
characters follow. This way, almost all actual usage of punctuation
within URLs is unaffected.
|
| |
|
|
|
| |
Describe the "Open with…" feature here as well and make sure to update
the sample configuration file with the new section.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This commit adds a new section, open-with, to the configuration file.
The options specified there will be added as "Open with …" menu items in
the URI context menu. This is to make it easier to perform other actions
on the URI than opening it in the system default browser; a user might
for example add another browser, media player, or a script that
preprocesses the URI before opening it.
|
| |
|
|
|
|
|
| |
Currently po/update-pot.sh assumes English strings and translator
comments cannot contain characters outside of ASCII, and throws an error
upon encountering any. Since we are actually using UTF-8 and not ASCII,
tell xgettext so.
|
| |
|
|
|
|
| |
The upcoming "Open with …" feature will need to spawn subprocesses in
very similar way as open_terminal(). Moving process creation to its own
function allows the same logic to be reused.
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently weltschmerz has separate context menus for the two types of
URIs one can interact with, even though they contain the same option
with only a little different phrasing. This makes both use the same
context menu, and standardizes terminology to "URI".
This unification is in preparation for an upcoming "Open with …" feature
which will programmatically add items to context menu for URIs. Without
this, we would need to duplicate logic for each of the separate menus.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
With at least one manual now fully translated, we need to install it to
the right place in both the Makefile and meson.build.
For the former use a similar loop as is in use for the MO files. For the
latter we sadly need to place the manual manually using install_data()
because meson only supports localized manuals natively starting at
0.58.0, a version that is only about two months old.
|
| | |
|
| |
|
|
|
|
| |
GTK's decision to make overlay scrolling the default seems to be quite
controversial. It also brings with it added complexity in both behaviour
and configuration and should therefore be mentioned in the manual.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Currently the weltschmerz URL regex does not match URLs with quotes or
parentheses, considering the URL to end when one is encountered. On the
other hand, if a URL is surrounded by angle brackets it includes the
closing '>' in the URL match. Additionally, the regex allows URL to
contain a space if and only if it is the second character of the host
component of the URL.
Most of this appears to be down to bugs in the regex as it is currently
written. This rewrites the regex to be cleaner and easier to read, while
maintaining the intended logic of the original.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The proposed OSC 7 specification mandates [1] that the file:// URI
includes the hostname, so that the terminal emulator can ignore remotely
used programs' attempts to set the current working directory. However,
VTE does not check the hostname component, and neither does
launch_default_for_uri. Thus currently if one tries to open directory
after running a remote program that used OSC 7, weltschmerz tries to
open a file manager pointing at corresponding path on the local
computer.
weltschmerz already contains a function that checks the URI kept by VTE
and returns the path only if it is on the local computer. This commit
changes open_directory() to first use that, and then create a new local
file:// URI based on it, unifying the behaviour of 'Open directory' and
'Open terminal'.
[1] https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/20#note_294252
|
| |
|
|
|
|
|
|
| |
This commit enables 'errexit' for both shell scripts in po/, ensuring
that no further action is taken should one of the commands fail.
init-po.sh now tests for the presence of a language code and refuses to
continue if none is given.
|
| |
|
|
|
| |
No effective functional change. Make sure that rules are anchored to the
top level.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
meson's tooling for gettext introduces a couple of issues. Firstly, it
is currently not possible [1] to specify per-language keywords. We need
this in order to ignore the 'Name' record in the desktop file.
Secondly, every invocation of 'update-po' also updates the pot file [2],
inadvertently recording the updated creation date in all translations.
Since we recommended the use of 'update-po' to translators in TRANSLATE,
this will lead to lots of unrelated changes every time a new translation
is added, even if no msgids change.
Thirdly, people who do not have meson installed are currently not able
to use the tooling it provides.
To fix these issues, this commit adds custom tooling around gettext: The
'update-pot.sh' script updates the pot and po files using xgettext(1)
and msgmerge(1), and 'init-po.sh' makes the necessary changes to LINGUAS
whilst also creating the relevant po file(s) with msginit(1).
We no longer need to refer to meson at all in TRANSLATE. Make sure to
mention the new scripts as well.
[1] https://github.com/mesonbuild/meson/issues/1739
[2] https://github.com/mesonbuild/meson/blob/a9e9b7c7501a3c8a5984a93879d1f309bf8c72aa/mesonbuild/scripts/gettext.py#L112
|
| | |
|
| |
|
|
|
| |
Translators may not be familiar with the code base or translation
process. This commit adds a small guide detailing common steps.
|
| |
|
|
|
|
|
|
|
| |
Currently weltschmerz's make-based build system relies on GNU make
extensions. Change it to only use POSIX and other nearly universally
implemented features.
A small downside to this patch is that .po files must be listed in the
Makefile manually.
|
| |
|
|
|
|
|
|
|
| |
Currently these localization files are only built when the user executes
`make install`. Since `make install` is often run as root, this leaves
files with root as their owner in the source directory. There are also
security implications to running compilers as root. This patch adds a
target `all` to the Makefile which depends on the localization files, so
that they are built as the user.
|
| | |
|
| |
|
|
|
| |
Since the default setting of ASCII-only could potentially bite us in the
long run, make sure to have xgettext interpret files as UTF-8.
|
| |
|
|
|
|
|
| |
This is the mail .pot file that all future translations will use as a
base. Since the header is supposed to be filled out by translators in
the .po file, we can leave it as-is. This also makes subsequent updates
to this file easier, since it is generated by a tool.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the translation infrastructure now in place, make sure to mark
every user-bound message for translation. All but one of the strings in
terminal.ui are already marked. This commit marks all remaining messages
in the Vala code as well as the missing one from terminal.ui.
One of the messages in terminal.ui is a sample error message for the
infobar label. Since this message will never be visible to the user (the
code overrides the label's contents with any relevant warning messages),
we do not need to keep it marked.
Finally, give translators ample context for what they will have to
translate and fix a small inconsistency with the capitalization of
warning messages in configreader.vala.
|
| |
|
|
|
|
|
|
|
| |
For some translatable strings we need to provide more context to the
translators. Conveniently, xgettext [1] provides the '-c[tag]' flag for
this. Make sure to pass along any comment containing "TRANSLATORS"
preceding a gettext call to the .pot file.
[1] https://www.gnu.org/software/gettext/manual/html_node/xgettext-Invocation.html
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
weltschmerz currently does not allow for translation and exists in
English only. This is a serious defect for people who do not speak that
language. The following series of commits aims to remedy this by adding
the necessary infrastructure and build steps to enable easy translation.
To do this we use GNU gettext[1]; its tooling is widely supported and a
de-facto standard. Since we need to tell gettext where to find the
compiled .mo translation files, have both the Makefile and meson pass
the locale directory to weltschmerz in form of a LOCALEDIR macro. The
translation domain will be "weltschmerz".
Not only will any strings in the Vala code have to be translated, we
need to make sure to translate terminal.ui and weltschmerz.desktop as
well. The former will be taken care of through POTFILES only, but for
the latter we have to define an intermediary build step. To ensure
compatibility with the Makefile, we suffix the desktop file with '.in'.
For now, LINGUAS and POTFILES remain empty. A future commit will
document all files needing translation. LINGUAS will be updated as
translations are completed.
[1] https://www.gnu.org/software/gettext
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add ability to open a new weltschmerz terminal, either from context menu or
with a key combination. The new terminal is opened in the directory
indicated with OSC 7, allowing quickly opening additional terminals while
working.
Preferably this would launch the user's preferred terminal, as defined
in per-user settings, but this is not possible with glib[1]. For this
reason the option always launches another weltschmerz.
weltschmerz is launched using bare Process.spawn_async() on the name of the
program as defined in weltschmerz.vala. We considered using the AppInfo
database to retrieve the name of executable instead, but as there is no way
to query the database for terminal emulators we would have to go through
every single program installed on the computer and try to find one called
weltschmerz. As the change would merely replace the requirement of having
weltschmerz in PATH with the requirement of having a .desktop file with the
name in one of the standardized locations, this would not be worth it.
[1] https://gitlab.gnome.org/GNOME/glib/-/issues/338
|
| |
|
|
|
|
|
|
|
| |
Currently, weltschmerz only copies URLs to GTK's default clipboard. This
is defined to be CLIPBOARD, leaving the PRIMARY selection unchanged.
Since all other normal copy/paste operations start with making a
selection and therefore set PRIMARY, make sure to also set the PRIMARY
selection when copying a URL. This brings weltschmerz in line with how
other GTK apps behave.
|
| |
|
|
|
|
| |
No functional change, since vte_copy() defaults to false here. This
seems to be a remnant of when vte_copy() required specifying the 'html'
argument.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, in commit c49fbfb (Set minimum width and height in window
geometry, 2021-06-17), we set the minimum size of the window to one
cell. We do not yet include our fixes from 89f8571 (Calculate base_width
dynamically, 2021-06-18) and so do not account for the scrollbar when
setting the minimum size hints.
A minimum size of one cell can lead to issues like [1] when resizing
aggressively. A fix for this has been committed in [2], but not yet
merged to any release branch. Setting the minimum size to larger values
seems to work around this problem.
Therefore, define a minimum window size of 28 x 3 cells - just big
enough to still fit the search overlay. Make sure to include base_height
and base_width so that the right size will be reported to the window
manager.
[1] https://gitlab.gnome.org/GNOME/vte/-/issues/340
[2] https://gitlab.gnome.org/GNOME/vte/-/commit/b333d66879963637099dc0bc5a702f50f34da67e
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The Environment.get_variable() method returns an unowned value. Make
sure to mark it as such in our code. Whilst we're here, add a missing
space to the subsequent if branch.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
weltschmerz sets window geometry hints to indicate how the terminal
window is to be sized and resized. New sizes are always kept at a
multiple of the character width and height. Effectively, this ensures
that terminal windows never have "negative space" that is not used for
any terminal output.
In order to account for padding and non-terminal widgets, one may
specify base_height and base_width. These values indicate how much space
to add in a final step, after the character width and heights have been
multiplied with the amount of columns and rows respectively. For
example, allowed window widths are always:
(char_width * N) + base_width
Currently, we always use a base_width of 2 * 2. This is to account for
the padding of 2 pixels as specified in terminal.css.
weltschmerz uses GtkScrolledWindow and overlay scrolling by default.
With overlay_scrolling enabled, the scrollbar does not take up any extra
space. The previous commit works around a problem with GtkScrolledWindow
and sets PolicyType.ALWAYS when overlay scrolling is turned off. This
means that we now also have to account for the size of that scrollbar.
Since we cannot simply query the size of the scrollbar, we have to be a
bit more creative. Use the full window width and subtract the width of
the terminal at startup (we know it is always 80 columns) to get the
amount of space taken up by "anything else". This includes VTE padding
and the scrollbar size.
Importantly, this needs only be done once and is completely agnostic to
any further changes to the terminal or font size (which affects the cell
width and height). We only assume that both the size of the scrollbar
and the amount of padding is constant, which we feel to be a reasonable
trade-off.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
weltschmerz uses GtkScrolledWindow to provide a vertical scrollbar to
the user. By default, this widget enables overlay scrolling. This means
that the scrollbar is painted "inside" the terminal, as if overlaid.
There's no configuration switch to turn this behaviour off, since we are
convinced that overlay scrolling is the right thing to do for terminals.
However, GTK allows users to turn off overlay scrolling in a global
setting [1] or by using the 'GTK_OVERLAY_SCROLLING' environment
variable. Some distributions turn overlay scrolling off by default.
When overlay scrolling is disabled, GtkScrolledWindow falls back to
rendering the scrollbar normally. Since our scrollbar policy is set to
AUTOMATIC, it is only drawn on demand. This means that it is initially
not be visible but can suddenly take up effective window space once it
appears.
When this happens, depending on what is going on in the terminal, one
can be left with a terminal that is scrolling down infinitely as the
reported column width flaps between two values: one accounting for the
size of the scrollbar and the other one ignoring it. Each time the
column width flaps, VTE sends SIGWINCH, possibly getting caught in an
infinite loop of internal resizes.
Since upstream declares GtkScrolledWindow incompatible with VTE [2] [3],
we have not attempted further investigation on this issue, but may
report an issue in the future.
We definitely want to keep using GtkScrolledWindow even with this
incompatibility - it is the most elegant and visually pleasing solution.
The alternative would be to use a GtkBox and supply our own scrollbar.
This scrollbar would either always be visible (even if there is nothing
to scroll) or entirely hidden. An implementation of this may be found in
the box-scroll branch. Note, however, that we do not guarantee that
branch to be up to date with the latest developments.
To work around this problem, detect when overlay scrolling is turned off
and fall back to PolicyType.ALWAYS. This ensures that the scrollbar is
always visible, mitigating the infinite resize loop. Crucially, compared
to the alternative solution, this will still enable users to enjoy
overlay scrolling if they (or their distribution) do not turn it off.
[1] https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-overlay-scrolling
[2] https://gitlab.gnome.org/GNOME/vte/-/issues/11#note_264921
[3] https://bugzilla.gnome.org/show_bug.cgi?id=733210#c2
|
| |
|
|
|
| |
Even though PolicyType.AUTOMATIC should always keep it hidden, be
explicit about our wish to show it under no circumstances.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Commit c49fbfb (Set minimum width and height in window geometry,
2021-06-17) introduced a trailing comma to make subsequent changes to
the initializer less of a hassle.
However, Vala only accepts trailing commas starting with 0.52.3 [1]. It
would be petty to require this version, especially since older versions
of Vala can still compile weltschmerz without problems.
[1] https://gitlab.gnome.org/GNOME/vala/-/commit/20fcf9ce42dca52c707b96ddf7457931d6ee96f5
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
GTK 3.24 is the last release for the GTK 3 series [1]. New development
now only happens on GTK 4 and above. Therefore it is reasonable to
require this long-term stable version of GTK 3 instead of an older
candidate.
Since 3.24 deprecates the 'window-placement-set' property, remove it
fully as well.
[1] https://blog.gtk.org/2018/06/23/a-gtk-3-update
|
