In particular, if the child is executed successfully, and did not emit
anything to stderr, an empty output is considered valid. The original
tried to check, and leave the selection unchanged on empty output, but
it did not always work.
ixed a small memory leak (argv_prefix) introduced with the spawning
change. Simplified the utf8_dir handling, there's no reason to re-
convert it to utf-8. Restored the original grep command display in
Messages (as entered in Tools vs. found by g_find_program_in_path),
but fixed the re-utf8-izing of the command and extra options.
Grouped in one commit, since these changes affect the same lines,
and are actually small.
In particular, changed the default printcmd not to "single quote paths
on Win32 for g_spawn_command_line_async", but use the native double
quotes. Also fixed it not to g_strconcat(NULL, ...) if lpr is missing
under Unix. It works, but glib says the first string must not be NULL,
and the command becomes wrong anyway.
The tools (from Edit -> Format -> Send Selection to) are now spawned
synchronously, which guarantees that both the document and it's
selection will be unchanged when the tool completes.
Also enabled the Grep tool setting to be used as a command line,
instead of an executable name only, and fixed a small bug where the
search text displayed in Messages was re-utf8-ed.
The wrong and misleading "Failed to change the working directory" is
changed to a generic "Invalid working directory".
Under Windows, the build commands are run directly as command lines,
while under Unix, /bin/sh is used - for compatibility, and because
that's probably what a *nix user expects.
The run script is always run as a command line, since it contains it's
own shell, and because that lets us specify %c under Windows. In fact,
%c (or "%c") should probably be the default, since CreateProcess()
runs batch files with the default shell, instead of some our value.
Also changed build_spawn_cmd() and build_run_cmd() to void, since
their return values are not used anywhere.
g_spawn_async_with_pipes() under Windows has various drawbacks:
- There is no g_shell_parse_argv() for windows. It's not hard to write
one, but the command line recreated by mscvrt may be wrong.
- GLib converts the argument vector to UNICODE. For non-UTF8 arguments,
the result is often "Invalid string in argument vector at %d: %s:
Invalid byte sequence in conversion input" (YMMV). Our tools (make,
grep, gcc, ...) are "ANSI", so converting to UNICODE and then back
only causes problems.
- For various reasons, GLib uses an intermediate program to start
children (see gspawn-win32.c), with the side effect that the
grandchildren output (such as make -> gcc) is not captured.
- With non-blocking pipes, the g_io_add_watch() callbacks are never
invoked, while with blocking pipes, g_io_channel_read_line() blocks.
- Some smaller problems, explained in spawn.c as inline comments.
The spawn module tries to fix these problems, and to provide easier
APIs, which guarantee that the callbacks will synchronized as expected,
and g_io_channel_read_line() will not be required, since even under
Unix, it may buffer lines of unlimited length.
This initial commit only adds the module source and header files, and
includes it in the various build systems.
You can see PR 274 for a long discussion about the module.
Also remove extra padding around the button's image to reduce its size
and try and avoid it expanding the tab's height.
This at least fixes the editor tabs height on Adwaita theme, where they
were 1px taller than normal.
The "rules hint" property is used to tell the theme for which TreeView
even/odd rows should have a different color. This is typically used for
long rows or rows which need to be visually separated for some reason.
Currently the Documents sidebar view uses it which doesn't make much
sense because the row is short and neither of the other tabs in the sidebar
use it.
This does not change anything in practice because static variables are
initialized implicitly as we need them anyway, but this makes things
clearer and more explicit.
At the moment when geany project is loaded from commandline using
e.g. "geany myproject.geany", the relative path is used by geany
so e.g. Project->Recent Projects shows the relative path instead of
the absolute one (also if the project is already in the list with an absolute
path, additional entry with relative path is created).
Use main_get_argv_filename(), which is already used for ordinary files,
also for opening .geany files.
The current implementation uses single menu for the toolbar and
menubar and reparents it when file menu is shown/hidden.
Connectiong "show"/"hide" signals doesn't work for menu items
on OS X (and I suppose Ubuntu either) so the template submenu is
never shown in the File menu.
The easiest fix seems to be having two identical menus the same
way we have them for recent files.
The expose-event/draw signals were used to reenable the menu
after it has been disabled when VTE overrides the given keybinding.
This doesn't work on OS X where GtkMenuBar isn't displayed
(there may be a similar problem with the global menubar on
Ubuntu).
The reason why these signals were used was probably slight
flickering of the menubar when using ordinary g_idle_add() to
reenable the menu (the dimmed menu gets drawn after which
it gets reenabled and redrawn non-dimmed). It is however possible
to use idle function with higher than redraw priority in which case
the menu is enabled before the redraw so the dimmed menu
isn't drawn at all.
Fixes https://sourceforge.net/p/geany/bugs/1081/
Normal clicking the launcher icon just brings the application to
the foreground so there must be a way users can create a new
instance of Geany.
Add an entry "New Window" to the context menu which is shown
when right-clicking the Geany icon in the launcher (most applications
have the "New Window" entry there).
In addition, fix "Open in new window" when using app bundle.
Since both of these functionalities create a new Geany instance,
factor-out the instance creation code into a new utility function
and use it in both cases.
NSApplicationBlockTermination signal is emitted when clicking
the Quit menu to check whether the application permits
quitting - react accordingly.
---
NSApplicationOpenFile signal is emitted when
* file is dragged on the application icon
* application is selected from "Open with" menu after right-clicking
the file
* when double-clicking a file for which the application is default
editor/viewer
* when file is opened from command-line
When the application isn't running, it is first started and then this
signal is emitted.
Use the signal to open files. In addition, when the opened file
has the ".geany" suffix, open it (but only if the project isn't already
open). The project has to be opened in idle function because blocking
the signal handler for a long time by the project-close confirmation
dialog causes problems.
We have to disable quartz accelerator handling because otherwise
accelerators are performed also from other windows than the main
Geany editor (e.g. Ctrl+V with find dialog open performs the keybinding
Ctrl+V and inserts the text to the editor).
OS X applications have an extra menu entry to the left of the File menu -
an "application menu". This menu usually contains About, Preferences,
Quit. Many users, however, may be used to Geany from other platforms
and expect Preferences to be under the Edit menu so leave them there.
Quit and About are rarely used and the application menu is the place where
they are supposed to be - move these entries from other Geany menus there
and hide them in the affected menus (the quit entry is inserted automatically,
we just need to hide it from File).
Also tell OS X the Help menu is dedicated to help (we get search in
menu entries by name for free thanks to this).
The global menu should refresh automatically based on user actions.
Unfortunately this is not the case when gtk_menu_reorder_child()
is used because it does not emit any signals so the gtk-mac-integration
library doesn't see this call. Refresh the menu manually after calling
this function.
This patch adds the gtk-mac-integration library and uses it to
adjust various paths in Geany to point it inside the app bundle
if Geany runs from inside the bundle.
It adds the utils_resource_dir() utility function to return
correct directories for various kinds of resources for all supported
operating systems. Using this function the patch adjusts all Geany
resource, plugin, icon, doc, and locale paths.
Under some conditions, geany_run_script.sh is not deleted and we
have no means to detect this in Geany (e.g. when the terminal emulator
is started correctly but it fails to execute the script for some reason).
In this case it is better to keep the garbage in /tmp than the working
directory. Apart from that, it eliminates potential transfer of the run script
over a NFS and eliminates the visibility of the script in working directory
on Windows.
Apart from that this patch fixes some locale/utf8 conversion problems
and other subtle problems with the previous implementation.
Most of our tree view tooltips were set from plain text values but
parsed as markup by GTK, which sometimes lead to markup errors, when
the tooltip value contained markup control characters.
This also adds ui_tree_view_set_tooltip_text_column() to the plugin
API so plugins can easily set plain text tooltips from tree views
columns.
Fixes https://sourceforge.net/p/geany/bugs/1091/
setup_paths() sets app->datadir to $prefix/win32. With mingw-via-autotools,
it installed data to $prefix/share/geany (like on Linux). With this change
data is installed to $prefix/data ($datarootdir is not changed).
This fixes geany startup after make install with autotools.
Linux:
pkgdatadir = ${datarootdir}/geany
GEANY_DATA_DIR = /path/to/prefix/share/geany
Win32:
pkgdatadir = ${prefix}/data
GEANY_DATA_DIR = /path/to/prefix/data
