I just made a test build of Geany Plugins 1.22 for Windows.
A little surprisingly for me, it all worked fine on the first attempt :).
I only had problems loading the Geany-Lua plugin with some strange error
message which I didn't investigate yet:
The error message occurs on plugin loading. I'm not sure whether it is
caused by my system or something else.
If anyone wants to test it, any feedback is appreciated.
... requires an existing Geany 1.22 installation.
Get my GPG key from http://www.uvena.de/pub.asc
I want to say, that it would be nice, if a DocumentMap/MiniMap would be added to Geany. Please add it to the Wishlist on your side.
Notepad++ have something called "Document Map":
Sublime Text have something called "MiniMap":
Since some time, Kate have a MiniMap, too:
All three have a line, where with very small fonts a bigger part of the document is shown and the current visible part of the Textarea have a colored background in the map.
But they differ in additional functionality of it.
Where Sublime Text only shows the MiniMap, Kate on the other side, can replace the scrollbar with it. And on Notepad++ it is a mix between the two. The scrollbar is still there, but you can click in parts of the Document Map, to jump to that position.
An additional point I want to mention, is a bug in your Webside-software.
As I wanted to add this wish to the wishlist, I clicked at the bottom of the page on "edit this page" of the line "(If you have another idea/wish which should be listed here, edit this page)".
Then it asks for a username and password. Because I don't have an account for it, and I find no place to register, I have somewhat input. After that it shows be an empty page and Geany.org was no longer available.
I thought, it would be an coincidental/hazard/fortuity/hap, that that happens.
But now there was again Geany.org reachable, then I tried it again. And again the Geany-side was after that down. :-(
So please update your Geany homepage software. Or it is really a very big coincidental/hazard/fortuity/hap, that in two times the Geany side goes in that time down, I tried to login there.
I want to let you knows know that glade upstream just merged my
backports for the "topological sorting algorithm" into glade-3-8 branch.
This means that we can now use upstream glade for our geany.glade as the
major outstanding deficiency is fixed: it now sorts the generated xml in
a predictable and stable manner, suitable for diff-review and probably
git merges too.
The backports should appear in 3.8.5 if you'd like to wait for a realease.
based up on Matthew's fine GtkActions branch  I think we could
realistically rewrite keybindings.c use GtkAction/accelerators properly.
Currently it re-implements lots of gtk stuff, such as the actual looping
through the known keybindings for the callback when a keybinding
pressed. When this would be rewritten keybindings.c could probably be
half as large (in LOC terms).
The advantage of doing so would be that plugins could register
keybindings simply by providing a GtkAction instance (and optionally a
GtkMenuItem) instead of a plain callback. This would enable to handle
keybindings in a more natural (from a glib/gtk POV) form through
signals. This is especially interesting for non-C plugins because it
easier to support/implement a gobject-based API then a
function-pointer-based one. This is the major reason I'm interested in this.
I think it is possible to do this without breaking the API or at least
without actual damage because plugins don't use the fields of
GeanyKeyGroup and GeanyKeyBinding so we can change these structs.
Is such a rewrite desirable, and would it have a realistic chance of
getting merged? I'm asking because I don't want to spend time on this
and never get it merged. Otherwise I would volunteer to do this.
Taking point from "[Geany-Users] I can't see highlighted item in menu",
here are some results of compiling and running Geany under Windows
with the official gtk+3.6.4 binary:
1. Compiles and install normally (waf build system).
2. On start, if at least 1 file was open, crashes with:
Program received signal SIGSEGV, Segmentation fault.
0x006e4340 in gdk_window_has_impl () from c:\tmp\scp\gtk+\bin
\libgdk-3-0.dll (gdb) bt
#0 0x006e4340 in gdk_window_has_impl ()
#1 0x006e4388 in _gdk_window_has_impl ()
#2 0x0071898e in gdk_win32_window_get_handle ()
#3 0x0045e998 in win32_get_shortcut_target ()
#4 0x00428992 in document_open_file_full ()
#5 0x00408758 in open_session_file ()
#6 0x00408886 in configuration_open_files ()
#7 0x0045ff75 in load_startup_files ()
#8 0x0046047f in main ()
The problem is in GDK_WINDOW_HWND(gtk_widget_get_window
(main_widgets.window)), used to compute HWND to serve as parent
window when resolving a link, if this happens to require UI. On link
target missing, Win~1 searches for "similar" files, displaying a small
dialog, and sometimes asks whether file X is the missing link.
I coudn't get a proper HWND for Geany main window. Using
but the link UI may (or may not?) be displayed below the Geany
window, looking as if we blocked.
A possible solution would be to use some Windows API directly, for
3. The items under cursor are not always highlighted. For example,
when I open Edit and move the mouse, the menu items are highlighted
fine, except for Preferences, which may or may not be highlighted.
4. The second and especially the third tab in the About dialog cause
100% CPU load and blocking.
5. The waf build of geany plugins does not currently support gtk+3.
Wikipedia calls gtk+3.4 "the first version of GTK+ 3 that works well
on Windows", but that seems to be an overstatement. Maybe 3.10+ with
the changed event loop and drawing will be better. Or worse...
For now, we'd better stick to gtk+2 under Windows.
I am currently modifying the autoclose-feature in the following way: if
you type the closing character right behind the opening one, the
completion should be undone: ()) -> ()
I find this useful e.g. if you've got a non-argument function and type
the brackets (), or just an empty string "". IMO it's much faster to
type the closing character manually than pressing the "right-arrow"-key.
My question is whether you consider this sensible and thus if it is
worth creating a pull request when I am content with my changes.
As part of working on cleaning up the exposed API to plugins I got to
thinking about where our comments are located. While it's nice to keep
the API-documentation-comments right at the definitions of the functions
in their respective .c source files, since we only install the headers
as a public reference (not even the plugin API docs IIUC), should we not
move the API-documentation-comments, that we already diligently ensure
exist and are fairly complete, into the headers where they are
accessible to plugin developers?
If we moved to having public headers that just included actual public
symbols, I think it would be advantageous to have those headers totally
commented/documented rather than requiring the user to download Geany's
source code and cross-reference functions in it to access the
comments/docs, or getting hold of the generated Doxygen API documentation.
Does anyone feel really strongly about this?
While attempting to compile the latest Geany snapshot, I received a
compiler warning and then a linked error:
src\document.c.5.o:document.c: (.text +0x5b97): undefined reference to
g_signal_handlers_disconnect_by_data() is since glib 2.32.
Our current requirements are for glib 2.20 or later.
The official windows binaries for gtk+2.24 include glib 2.28.8.