The 32x32 size can be created by downsampling the 48x48
icon by gtk at runtime but the result will be worse than
doing the same directly from the svg icon (48->32
conversion means downsampling by 1.5 which can introduce
some moire artifacts and loss of information). Since
32x32 are quite commonly used, it makes sense to ship
this icon size with Geany.
The png files have been optimized by pngoptim to remove
metadata and compress the icon better.
The handle of the lamp icon looks strange. While
the image of the lamp itself is taken from top,
the handle looks it's taken from bottom.
Fix this by moving the wide part of the handle
down and moving the "shine" line to copy the
outer edge. Also adjust the handle curves a bit
to connect the lamp in a more natural way.
The Light sublayer of the Lamp layer covers the lamp border
partly so it appears cut off. In addition, the Shine sublayer
doesn't follow the border properly. Adjust the curves in both
of these sublayers to fix the problem.
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.
The flags in this variables are used to tune the linker behavior on the
final libgeany (currently set the version information), so should only
used on really linked libraries, not Libtool helper libraries.
They are connected inside the library now rather than using GModule to
find the symbols. Mark local callback handlers as static since they
aren't global or exported anymore, they should be static. Since they're
static now, all of the forward-declarations of the functions local to
callbacks.c are pointless, so just remove them.
This prevents having to export those callbacks and put them in the
global namespace. Also, use inline shell script in Makefile.am instead
of a Python script which should be more portable (by default) and gets
rid of the helper script.
Checks if the compiler supports -fvisibility and the linker supports
-dynamic-list arguments and use them instead of hardcoding. The new
geany-lib.m4 also accomodates future use of Libtool versioning.
This will allow plugins to link against the core when accessing API
functions, now that the macro/struct/funcptr stuff is gone.
Also convert the helper libraries into Libtool helper libraries as
linking a shared library against static libraries is (apparently) not
portable.
Add rest of headers needed for declarations of all public API
functions. Add HAVE_PLUGINS define to geanyplugins.h since some headers
need this and it should always be valid for this header.
geanyfunctions.h left for source-level backwards compatibility for
plugins which might `#include` this header directly. I don't know why
they do it, but some Geany-Plugins do this.
Adds a new header `pluginexport.h` to put the macros in, could be
moved into an existing header (support.h?) by I didn't want to drag
a bunch of existing stuff into the source files for this one macro.
TagManager has relative include, this could be fixed by changing the
include directories for it if it's a problem. Mark the Scintilla
functions exported by re-declaring them in sciwrappers.c with the
attribute to avoid changing upstream Scintilla code.
Uses a Python script to generate a listing used by the linker to
determine which symbols to dynamically export. This provides finer
grained control of which symbols are dynamically exported, limiting
only to the ones needed for GtkBuilder signal connections.
The build system integration could probably be done a little cleaner.
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.
