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
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.
This allows to re-use the icon more easily since it's not rendered at
a particular size but simply an icon description. It also allows for
implicit icon updating when the theme changes if the display code
implements it (and GTK widgets does).
GtkFontButton uses GtkFontChooserDialog on GTK 3.2 so the UI is more
consistent if we use it explicitly too, and GtkFontSelectionDialog
is somewhat broken on 3.4.
Use the GtkComboBoxText API and the GtkComboBoxEntry replacement API
and map those to the old equivalents if not available.
This changes the type exposed by ui_combo_box_add_to_history() from
GtkComboBoxEntry to either GtkComboBox (under GTK2) or GtkComboBoxText
(under GTK3). This should not be too much of an issue since
GtkComboBoxEntry and GtkComboBoxtext are subclasses of GtkComboBox,
but this will still emit warnings when when the calling code passes
a GtkComboBoxEntry pointer to ui_combo_box_add_to_history().
However, this requires the calling code to use the same mapping as we
do (GtkComboBoxText = GtkComboBox on GTK2, even on 2.24), or things
will blow and it'll be hard to understand why. This wouldn't be an
issue if the calling code includes our gtkcompat.h header everywhere
it deals with combo boxes, which will be the case if it includes the
Geany headers everywhere but probably won't otherwise. Oh dear.
A possible kind of workaround may be for ui_combo_box_add_to_history()
to do type-checking on its argument and use the actually correct API
for that type.
Previously, choosing another font and then pressing cancel would keep
the font selected rather than resetting it to the current editor font
because the dialog is not destroyed between showings.
Most noteworthy change is that all build commands IDs and groups are
now unsigned everywhere negative values aren't explicitly handled with
a special meaning. This should not change anything in behavior, only
makes clear the index won't underflow.
Works around the issue discussed in commit 1e54fb6 by using the file
chooser's property accessor function.
Rename on_file_notify() to better explain its purpose.
Uninitialised GValue does not always work, but is an opaque type so
structure of initialiser isn't known. Glib 2.30 on has G_VALUE_INIT
to use as initial value. Fix so if not defined give it the previous literal
value { 0 }, although this leaves the warning, so it is not initialising
the GValue correctly but enough to work.
Fix warnings that appeared with GCC 4.6
js.c:1067:10: warning: variable ‘is_prototype’ set but not used
dialogs.c:173:2: warning: missing initializer
dialogs.c:173:2: warning: (near initialization for ‘value.data’)
sidebar.c:534:17: warning: unused variable ‘doc’
Previously an error message was shown if doc->file_name is NULL.
The Save As dialog is now shown if the document does not have an
absolute path. This is because the user should confirm where to save
the document in this case.
Although this changes plugin API behaviour, it seems the best way to
ensure the Save As dialog is always shown when needed so the user
knows where the document has been saved.
* Processed with rstrip-whitespace.py script added to scripts/ directory.
* Script run on all .c and .h files in src/ and plugins/ directories.
* Also remove more than one newline at the end of files.
- tagmanager/php.c:
Fix parsing keyword-qualified functions strictly, e.g. don't
parse 'staticfunction' or 'fatfunction'.
- src/utils.c, src/utils.h, src/editor.c:
Use GRegex for snippet indentation replacement - fixes wrong
behaviour with Mac line endings.
- tagmanager/lregex.c, TODO:
Use GRegex for CTags instead of POSIX regex - GRegex is more
powerful. This also fixes a (HTML) performance issue on Windows.
Geany will now print a debug warning when using the "b" CTags
regex flag option for non-extended syntax. This is not currently
used by Geany's parsers.
Note: GNU regex can't be removed yet as it's still used elsewhere
by Geany.
- src/build.c, doc/pluginsignals.c:
When saving on build, prompt for a filename if necessary.
Emit the "build-start" signal only if saving succeeds.
- src/build.c:
Use #ifdef SYNC_SPAWN instead of G_OS_WIN32 for easier testing with
glib's asynchronous spawning (which doesn't work on Windows).
- src/win32.c, src/win32.h, src/dialogs.c:
Use GTK unsaved file dialog on Windows too because the button names
should be specific.
git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@5987 ea778897-0a13-0410-b9d1-a72fbfd435f5
Most notably, utils_get_line_endings() and document_open_file_list()
don't support -1 as the size anymore. If the size should be computed
from null-terminated data, the caller code must take care of doing so.
git-svn-id: https://geany.svn.sourceforge.net/svnroot/geany/trunk@5855 ea778897-0a13-0410-b9d1-a72fbfd435f5