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'm still working on proxy plugins, sorts of. I thought it would be
useful to give you an update. I first taken my proxy-plugin approach to
the final stages, and then went onto researching what we can do with
libpeas and gobject based approaches. Please feel free to discuss things
and/or contribute to my efforts.
In my last post I've followed the approach of proxy plugins, aka pluxys.
This approach is based on geanypy and implements a plugin API for
plugins to act as proxy. I have mostly finished that (including an
trivial example pluxy), and ported geanypy to this framework. The result
is that with this approach I was successfully able to load python
plugins with the core, including access to the plugin API, to the extend
that geanypy allows plus keybindings via a new (experimental) API call.
I think this should cover almost everything you would want for python
plugins.
Since with that work you can successfully load python plugins I consider
this approach workable. The code is on my github repo. The code is still
in a proof-of-concept state with rough edges but I invite you to try it
out. If you maintainers want to consider this for merging into geany
proper then let's get this done, I'm all for it.
Now that the pluxy approach is in the final stages I went onto toying
with libpeas.
Libpeas provides a nice interface for loadable plugins, both from the
core's and plugin's point of view. For the core, plugins written in
different language can be loaded through a unified interface. And
plugins can implement multiple plugin entry points for different
functionalities. Everything is based on gobject interfaces.
There are three areas of problems with libpeas before we can adapt it,
two of which I could already solve in a fork.
1) backward-compat: Libpeas is fundamentally based on describing plugin
metadata with a separate .ini-style file ($plugin.plugin). It cannot
load plain .so files on its own.
-> I solved this by extending the libpeas parser such that it can
parse the plugin description of Geany plugins, and generate a
PeasPluginInfo from it. This way we can load existing plugins before
they transitioned to the .plugin file.
2) backward-compat again: libpeas' existing C parser cannot load the C
plugins because they do not implement a gobject interface.
-> For this I wrote a trivial custom loader which instantiates a
"PeasGeany" interface instance (it has the traditional init(),
configure(), help(), cleanup() methods) on behalf of the existing plugins.
with 1 and 2 i have successfully loaded existing plugins with libpeas.
3) access to Geany's plugin API for non-C plugins (aka bindings).
-> This problem also applies to the plugin-proxy approach, except that
for that it is mostly solved for python with geanypy. Anyway
gobject-introspection provides a nice path to autogenerate language
bindings. However, geany's API currently isn't introspectible.
3) is the problem I'm currently stuck at. I think Matthew already had an
idea how we could possibly make it introspectible with little effort,
with the help of vala. If anyone has other ideas or comments please
speak up!
So, I do plan to make libpeas fully work as 3) would ultimately also
help with the pluxy approach so it's a good idea regardless. Then we can
have a look which of the approaches we want to merge for geany (if any (?)).
Best regards.
Hi,
lately, I started building a new Windows installer which includes a
recent GTK 2.24 runtime for Windows which need for future releases.
While most things went fine I noticed one problem:
GTK, in detail Glib, changed the way g_get_user_data_dir() works on Windows:
in older releases, something GLib 2.28 or 2.26 and older,
g_get_user_data_dir() returned c:\users\<username>\AppData\Roaming, in
newer GLib versions it returns c:\users\<username>\AppData\Local.
This affects users who already have a config directory located in
<...>\Roaming and Geany would look in <...>\Local now.
This is the change I'm talking about:
https://git.gnome.org/browse/glib/commit/glib/gutils.c?id=9d80c361418f94c60…
How do we want to handle this?
- continue using the <...>\Roaming directory (and so not using
g_get_user_data_dir() anymore)
- leave the code as it is, resulting in a new complete config for users
- add some code to check if a config in <...>\Roaming exists and if so,
move it to <...>\Local
I'd implement the last choice if there are no objections. This is not
nice because we implement again some magic "config directory move" code
but at least the user won't notice that GLib change.
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
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 everyone,
I was building the docs and I found the documented procedures
<http://www.geany.org/manual/current/index.html#id234> don't work for
me. The doco says to do "make docs" to generate the docs, but I found
that there is no target for "docs" and I just had to go to the docs
directory and do "make".
I was writing up a patch to change the doco when it occurred to me that
this might be a platform issue. I'm using Fedora 20 with GNU Make
3.82. Can anyone shed some light on this?
Thanks,
James
Hi everyone,
To introduce myself, my name is James, I use Geany as a developer and
I'm getting involved in the documentation. I've never been involved as
a contributor to any open source project before, and I apologise if I
break any established protocols :)
As my first contribution I added some clarification to the section about
Projects. I generated a patch file as per the instructions in the doco,
and attached it to this email. I hope this is the normal procedure.
There is mention of using a pull request, so do people also push their
commits to the server?
Thanks,
James
Hi,
I haven't built Geany for some time. I remember there was some
refactoring of headers, and now build.c errors because
win32_expand_environment_variables is not declared. Adding the win32.h
include fixes it, but I can't work out how other files like dialogs.c
include win32.h, it doesn't seem to be manually included anywhere.
What's the correct fix?
Regards,
Nick
