This makes it easier to define it consistently to what the compiler
and platform supports, and avoids having to include a special header
everywhere, which is some kind of a problem for separate libraries
like TagManager and especially Scintilla.
As we only use these macros from the source and not the headers, it
is fine for it to be defined to a configure-time check from the build
system.
Warning: Although Waf and Windows makefiles are updated they are not
tested an will probably required tuning.
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.
With the previous TMWorkspace API it was possible to make the workspace
inconsistent by e.g. removing source files and forgetting to update
workspace. This could lead to non-obvious and not immediately visible
crashes.
The new set of the public (but also Geany private) API calls always
updates the workspace accordingly and neither of the calls can lead
to an inconsistent state of the workspace.
In addition, perform some minor cleanups and simplifications - unify
parsing from buffer and from file, support "parsing" of 0-sized buffers
and improve documentation.
Avoid "utility" parameters like do_free for which we already have API calls
and which actually don't perform any free if the source file isn't
in TM. Clarify when to set the update_workspace parameter.
In addition, rename all functions, parameters, comments etc. mentioning
work_object and remove unnecessary parameters of various functions.
Delete dead code paths.
Also move common functions like tm_get_real_path() from tm_work_object to
tm_source_file.
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.
