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.
The ::document-activate signal was not emitted when opening the first
tab of the notebook, e.g. when the tab count changed from 0 to 1.
This is because the ::document-activate signal is emitted in response
to the GtkNotebook::switch-page signal, which is emitted whenever the
currently displayed page changes. When there already is a current page
(when there is one or more pages), adding a new page does not trigger
the signal, as this new page doesn't become the current one (we will
switch to it later). However, when there are none, the newly added one
becomes current, and so the signal is emitted right away.
This is problematic because when we add the page to the notebook, the
document associated with it is not yet ready (only partly initialized),
and so we can't emit the signal on a valid document, and we discard it.
Not emitting this signal leads to inconsistent behavior introducing
subtle bugs in plugins relying on it.
To work this around, only show the page widget (the child added to the
notebook) after we finished initializing everything. This is the
simplest fix, because a lot of the code around document creation and
opening depend on the fact the page is already added, so while delaying
the page addition sounds like the more sensible fix, it has non-trivial
consequences that would require a large amount of work to overcome.
Note that interestingly, in addition to our problem, GtkNotebook seems
to have a bug as it emits the ::switch-page right when adding the first
page even if that page is not visible. However, it properly emits it
again when the child becomes visible, so we just still discard the
first emission like we used to.
On OS X the Command key is used for common keybindings instead
of Ctrl. Introduce a new macro, GEANY_PRIMARY_MOD_MASK that
represents the Command key on OS X and Ctrl on other platforms.
For some events, such as mouse key press, GDK_MOD2_MASK is returned
for the Command key by GTK instead of GDK_META_MASK (which is returned
when Command is pressed together with some other key). To hide this
behavior from users, introduce keybindings_get_modifiers() which can be
used instead of gtk_accelerator_get_default_mod_mask() and which
inserts GDK_META_MASK when GDK_MOD2_MASK is found in the mask
on OS X.
Directly use the GeanyDocument rather than pass the notebook page
widget and get the document from that. This makes the code more future
proof and less weird.
Since infobars notebook_tab_close_clicked_cb() wants a GeanyDocument as userdata.
show_tab_bar_popup_menu() on the other hand wants the actual GtkNotebook child.
This is to allow stacking widgets such as GtkInfoBar above the Scintilla
widget in each tab.
notebook.c need to be changed because the document isn't the direct widget
anymore which was assumed for tab closing.
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
When switching between MRU documents, Geany pops up a dialog about
document change even for the intermediate non-final documents.
This leads to both reload dialog and document switch dialog displayed
at the same time and termination of document switching because the
newly displayed dialog takes focus.
This patch disables reload checks for the intermediate documents and
forces reload check for the final document.
This is a pretty frequent work pattern of mine:
1. Editing file A
2. Searching for function and opening file B
3. Closing file B because I just wanted to look at the function definition
4. Without this patch I get to the file following the B's tab (which
is just a random file) but my brain expects that I get to A
I know it's possible to kind of simulate the behaviour I want with
the "next to current" placement option but I really don't see a single
advantage of having tabs closed in sequential order. This is also
why I didn't make this behaviour optional. But maybe I miss some
use case of tabs being closed sequentially - just tell me.
Signed-off-by: Jiří Techet <techet@gmail.com>
Instead we should use that tab which is under mouse cursor where the user clicked (this might be a
different one than the current document). To be able to do so, we need to handle the right-click signal
per tab not on the GtkNotebook tab area to identify the tab under the mouse cursor.
* 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.
