Hi all,
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:
http://pastebin.geany.org/EUmwJ/
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.
The installer...
http://www.uvena.de/tmp/geany-plugins-1.22_setup_testbuild.exe
... requires an existing Geany 1.22 installation.
Regards,
Enrico
--
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":
http://notepad-plus-plus.org/assets/images/docMap.png
Sublime Text have something called "MiniMap":
http://www.sublimetext.com/screenshots/new_theme_large.png
Since some time, Kate have a MiniMap, too:
http://kate-editor.org/2012/11/03/busy-katekdevelop-sprint-results-in-mini-…
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.
Greatings
theuserbl
Hello,
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.
Best regards
Hi,
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.
Cheers,
Johannes
Hi,
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?
Cheers,
Matthew Brush
Hi,
I tested $subject again with 1.24, and it's improved significantly.
Geany now installs geany.pc and the development headers properly, so
the plugins build without problems. The plugin installation, however,
creates a \lib directory on the installation drive, with all
lib<pluginname>.dll.a files, which is completely pointless. It was the
same with 1.23, but I forgot to mention it.
The prefix problem is workarounded. Since geany.pc is installed in
\geany\path\lib\pkgconfig now, win32 pkg-config automatically
uses /geany/path, replacing \ with / and ignoring the prefix setting.
If you move geany.pc into \geany\path\lib, as in 1.23, the setting
becomes used, and you'll quickly see "geanypathinclude: no such file
or directory" on build. Unfortunately, waf does the opposite of
pkg-config, replacing / with \, so --prefix=/geany/path does not help.
But the installation works, since it's done by waf, and the plugins
don't care (AFAIK) what slashes are used on runtime.
BTW, the paths to Python are with \\\\ :)
--
E-gards: Jimmy
Hi,
Does anyone know why the plugin API was designed to use a bunch of
structures containing function pointers, hidden behind macros in
geanyfunctions.h? I found the commit where this stuff was added
initially (ie. plugin ABI 2-3) but it doesn't mention why it was done
like this and I tried to search the mailing list archives but Gmane
won't let me search and the other mailing list archive doesn't go back
that far.
Somebody mentioned it might be because Windows doesn't export symbols by
default, but it still doesn't explain why this way chosen over
explicitly exporting the symbols using
__declspec(dllexport)/G_MODULE_EXPORT which, IIUC, does just this.
As mentioned in the "Proxy Plugins" thread I'm looking into making the
headers scanned by GObject-introspection to automate binding the plugin
API to non-C plugins, but with all of the private stuff and public stuff
mixed together in public headers, it will be hard to do this.
Assuming there isn't actually much of a reason for the chosen existing
function pointer/structure/macro mechanism, is anybody opposed to just
making the API available in the normal C way where the public functions
goes in one header that plugins (and core) can use, and one header where
the private stuff goes, that doesn't get installed?
Just to see the work involved, I tried to do this with the build,
document and editor functions. It makes the public/private more
explicit, removes lots of extra code, makes only one place to update
when adding new functions to the API, doesn't force plugins to import a
bunch of private stuff indirectly by #including <geanyplugin.h>, still
makes the symbols available/exported on Windows, and does it without
breaking the official (ie. doxygen-commented) parts of the API (but it
would need an ABI bump). The experimental changes to build, document,
and editor functions are here in my header-cleanup-private branch, based
ontop of my "header-cleanup" branch that I have an open PR for:
build.h/buildprivate.h
https://github.com/codebrainz/geany/commit/0b1221ce85905a066adfaae62fc73470…
document.h/documentprivate.h
https://github.com/codebrainz/geany/commit/f5e03bbee2c4edc8fe66c8e0762ef86e…
editor.h/editorprivate.h
https://github.com/codebrainz/geany/commit/1534f196d626494b57d408f780dfde02…
What we could do for commonly used existing private stuff:
https://github.com/codebrainz/geany/commit/ac02d5330af2bd2cfcff45609f0e5b02…
(Sorry, I just linked the relevant commits instead of the branch so
people don't have to figure out which specific ones I'm talking about
amidst all the other unrelated ones. It's mostly just to give an idea of
what I'm talking about.)
I think this would be a fairly big improvement overall and it would
finally allow us to sort out what's really private and what's really
public, which will make bindings generated by scanning the headers much
easier.
Some common stuff that wasn't public before (ie. doxygen-commented) but
that is still used in plugins could be added as "deprecated" to the
public header or if useful could be properly added with a doxygen
comment. This will avoid excessive breakage where plugins were using
private stuff.
Any opinions, suggestions, reasons about the original design welcome.
Cheers,
Matthew Brush
Hi,
Is it fair to say that any function that is not represented in
`geanyfunctions.h`/`plugindata.h` and any types that are not documented
with a `/**` or other Doxygen comment are to be considered "private"
with respect to the plugin API?
For example there are some types/enums in `build.h` that have comments
that start with `/* *` (note the space in-between asterisks). I presume
that's to keep them from being made "public" by not allowing Doxygen to
scan them. Is that accurate? If that's the case, how do we handle that
some of the public functions in `build.h` require these enums in order
to be useful (ie. use parameters of those types)?
Another example is `filetype_id` which is the enum type in `filetypes.h`
that holds the various filetype IDs (ex. GEANY_FILETYPES_C,
GEANY_FILETYPES_HTML, etc.). It's completely undocumented, but is used
(as gint type) in functions such as `filetypes_index()`. Is it fair to
say this whole enum is private, or should it rather be considered public
since it was exposed to plugins via the include of `filetypes.h` in
`geanyplugin.h`?
Along these lines, in `geanyplugin.h` there are includes of many common
headers, with a comment about only including headers that expose types,
not just functions. Having had these headers exposed to plugins (and
also being documented in Doxygen API docs), does that mean that every
symbol/function/type in these headers is part of the public API and
should not be hidden inside of private headers, for example (see other
thread about private headers). Is it a plugin bug if they used any
undocumented symbols/functions/signals/types?
FWIW, I noticed the plugin API docs says right on the main page:
> Warning
> Do not use any symbol not in the documentation - it may change.
And my final question: do we support individual includes of Geany's
headers that were available? For example, if someone, for some crazy
reason wanted to move `struct GeanyDocument` to `document-blah.h` (fake
example), is it a plugin bug if they directly included "document.h"
where this type was previously, or is it an API bug because we moved the
type to another file, even though we added an and include for the new
header inside the central include file `geanyplugin.h`?
Cheers,
Matthew Brush
Hi!
I just began to write a port of the Gedit plugin from Autovala as a
plugin for Geany and while setting up my fork of the geany-plugins
repository I had to change the text for the yourfancypluginname.m4 file
mentioned in the HACKING file from
>AC_DEFUN([GP_CHECK_YOURFANCYPLUGINNAME],
>[
> GP_ARG_DISABLE([yourfancypluginname], [auto])
> GP_STATUS_PLUGIN_ADD([yourfancypluginname],
[$enable_yourfancxpluginname])
> AC_CONFIG_FILES([
> yourplugin/Makefile
> yourplugin/src/Makefile
> ])
>])
to
>AC_DEFUN([GP_CHECK_YOURFANCYPLUGINNAME],
>[
> GP_ARG_DISABLE([yourfancypluginname], [auto])
> GP_COMMIT_PLUGIN_STATUS([yourfancypluginname])
> AC_CONFIG_FILES([
> yourplugin/Makefile
> yourplugin/src/Makefile
> ])
>])
in order to make autogen.sh work. Is this a bug/error in the HACKING
file or am I missing something?
Greetings,
Philipp.
