* If GETTEXT_PACKAGE is not defined (ex. by build system/user) then
define it to NULL. Most GLib gettext-functions allow passing NULL
to use the domain set with textdomain().
* Improve the ngettext() wrapper macro.
* Improve/fix bind_textdomain_codeset() wrapper macro.
* Fix argument in bindtextdomain()
* Cast bind*textdomain*() results with (void) to get rid of compiler
warnings when building without GETTEXT_PACKAGE defined.
This is a mega-commit - because most of it had to be done in one go
otherwise some commits would fail to compile - that attempts to fix a
few problems with Geany's includes as well as various other related
cleanups. After this change it's easier to use includes and there's
little worry about which order things are included in or who includes
what.
Overview of changes:
* Include config.h at the start of each source file if HAVE_CONFIG_H
is defined (and never in headers).
* Go through each source file and make the includes section generally
like this:
- Always config.h first as above
- Then if the file has a header with the same name, include that
- Then include in alphabetical order each other internal/geany header.
- Then include standard headers
- Then include non-standard system headers
- Then include GLib/GTK+ related stuff
* Doing as above makes it easier to find implicit header include
dependencies and it exposed quite a few weird problems with includes
or forward declarations, fix those.
* Make geany.h contain not much besides some defines.
- Add a little header file "app.h" for GeanyApp and move it there
- Move "app" global to new "app.h" file
- Move "ignore_callback" global to "callbacks.h"
- Move "geany_object" global to "geanyobject.h"
* Add an include in "geany.h" for "app.h" since GeanyApp used to be
defined there and some plugins included this header to access
GeanyApp.
* Include "gtkcompat.h" everywhere instead of gtk/gtk.h so that
everywhere sees the same definitions (not a problem in practice AFAIK
so this could be changed back if better that way.
* Remove forward declarations from previous commits as some people
apparently consider this bad style, despite that it reduces inter-
header dependencies.
TODO:
* As always, to test on win32
* As always, to test with not Autotools
* Test plugins better, both builtin and geany-plugins, likely API/ABI bump
* Test with various defines/flags that may change what is included
* win32.[ch] not really touched since I couldn't test
* Always define GEANY_FOO_H to 1 in the header guards
* Always put a G_BEGIN_DECLS/G_END_DECLS guard in every header for
consistency, even private ones where it doesn't matter.
* Always include either <glib.h>, <gtk/gtk.h> or some other header
that will provide G_BEGIN_DECLS before using it. In a lot of headers
that use glib.h and gtk/gtk.h stuff anyway, this resolves an implicit
dependency they had on them being included before that header.
* Always put a comment at the #endif part of the guard so it's
easier to see what it applies to.
* Always use an underscore between the header guard identifier's words
even though the filename doesn't have one.
This is for work on making the files scannable by GObject-Introspection
but is still useful otherwise (even fixes a FIXME in the comments). I
made this by using a simple GNU Make file and trying to compile the
sources each on their own without all the build system infrastructure.
* Add keybindingsprivate.h file to hold private GeanyKeyGroup structure
and remove it from the GEANY_PRIVATE guard in keybindings.h.
* Move private members that were guarded by GEANY_PRIVATE from
GeanyFiletypes to GeanyFiletypesPrivate and remove guarded build.h
include.
* Move private members that were guarded by GEANY_PRIVATE from
GeanyProject to GeanyProjectPrivate.
Fix modulo zero error resulting in floating point exception, and then
crash. This was introduced in fd6ce2da11e9f2d20cb96236753662c23feaecb4.
Closes#265.
Using the exact same string avoids duplicate translation, and here only
mnemonic changes were introduced with commit
95306ac8db4fc38ad7ba7e172328cef5117efaf0.
When loading a project and focusing the last document, the UI wouldn't
get properly updated for the displayed file -- because for performance
reasons we disable notebook page switch handlers when loading session
files. Fix this by synthesizing a notebook page switch event when done
loading.
We don't actually detect from file extension only, and other references
of the feature always use "Detect from file", so use it also in the
open dialog.
The "View" button string is the same as the View menu one, but one is
an action (verb) and the other a noun, and as such might need to be
translated differently.
Display the filetypes in the Open dialog filetype combo box grouped,
as they are in the filetypes menu.
This makes it easier to select a filetype, because they are better
sorted and follows the filetypes menu layout.
Make all encoding combo box display a list with encodings grouped by
categories into sub-menus, making it easier to find the appropriate
encoding than in a big single-level list.
This is what was used in the Open dialog, but not in the Preferences
dialog or the Find in Files dialog. This also makes the encoding
combo boxes behave more like the encoding menus.
Watch the lifetime of objects referenced in plugin->signal_ids and
remove our references to them if they get destroyed. This avoids
possibly trying to disconnect signals on destroyed objects when the
plugin is unloaded.
Supporting this case is safer, and is useful for objects that may or
may not outlive the plugin (like ScintillaObjects), because in such
cases plugin_signal_connect() is handy to make sure the signals are
disconnected if the object is still alive, but used to crash if the
object was destroyed.
When quitting, we still have to destroy the Scintilla widget to avoid
any possibility for us to receive signals from it after we destroyed
the associated editor and/or document (used in signal handlers).
I myself don't suffer from the issue, but it is theoretically possible
for Scintilla to emit signals anytime before it is destroyed, so it is
safer like this anyway. And an user on IRC suffered from crashes on
quit because of this issue, so it seems to actually happen in some
situations.
On Windows we need to change the working directory on startup to not
lock the directory Geany was started from (bug #2626124).
However we can't change the directory to late in the startup process
otherwise plugins maybe unable to load resources from the installation
directory.
Though we also can't change it too early otherwise opening files given
with relative paths in Geany from the command line won't work anymore
(bug #3613096).
This change should fix both issues by changing the working directory after
command line file handling happened and before plugins will be loaded.
We used to assume that if the selected text started with "0x" when
inserting a color, we had to replace exactly 6 bytes after the "0x"
prefix. Although this is generally the case as most color formats use
6 hexadecimal digits, it still would erase either too many or too few
characters if actually replacing something shorter (i.e. "0xfff") or
longer (i.e. "0xffffffffffff").
It could even partially override multi-byte characters if the 8th byte
after the selection start was in the middle of a character, as the
length was in bytes and not characters.
Fix this by honoring the actual selection end.
As suggested by a preprocessor warning from winsock2.h
(i686-w64-mingw32/include/winsock2.h:15:2: warning: #warning Please
include winsock2.h before windows.h).
