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
Hi,
Just wanted to let everyone know, I deleted my Source Forge account
after like 20 times of losing my comments. This final time it was a
detailed C++ explanation on Scintilla's bug tracker that took a lot of
thought and effort to write, which as usual I lost due to forgetting how
crappy Source Forge login and bug tracking software is.
I'm sure nobody really cares, but if there's some Geany
bug/feature/patch posted there that anyone thinks I should look at,
you'll have to forward me the details. I won't ever use SF.net again
(actually blocked whole domain in my /etc/hosts), and won't be
contributing anything to any project's bug trackers there.
In the meantime, Geany's Github bug tracker is active since a while
(though not for Geany-Plugins), so I'll be sure to continue monitoring
and contributing to that tracker, and of course the mailing lists.
Cheers,
Matthew Brush
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,
Since Debian is leaning more and more towards systemd, especially with
gvfs installed, and since systemd-init breaks my system, I finally sat
on my back and migrated to Windows. It's not a good system either, but
gets the job done.
Now, Geany under Win~1 has some deficiencies, due to gtk+, so I'll
probably use it as a debugger only, and limit myself to the official
releases. But if somebody decides to apply the spawning fix, or parsing
the columns in compiler messages, or the small patch that adds virtual
column to the status bar, I will be glad to help.
Also, if Scope has any problems building with or running under gtk+3,
I'll fix them (some Linux programs are not replaceable, so I kept a
small Debian system in dual boot). But there will be no gtk+4 support,
at least not from me.
--
E-gards: Jimmy
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 all
As threatened two weeks ago, I now created a patch to geany to enable
line_wrapping on a per-project basis. Seems to be working fine, I put
the checkbox to enable it on the Editor tab of the project properties.
I hope I did everything right:
- git clone git://github.com/geany/geany.git geany
- Made my changes
- Did a fresh git pull
- git commit -a
- git format-patch HEAD^
I attach the resulting patch to the email, please tell when you need it
in another way.
Kind regards
Tim
--
decentral.ch - IT Stuff
Tim Tassonis
Dennlerstasse 36
8047 Zürich
stuff(a)decentral.ch
+41 79 229 36 17
Hi all
Thanks first everybody involved for geany, have been using it now for
several years for all my programming work and never, ever even thought
about looking back.
Since I want to start to do some text writing with geany as well, I'd
like to toggle line wrapping on a project basis, which currently does
not seem to be possible.
My question is: Would you take a patch to enable this or is there a good
reason not to implement it?
Kind regards
Tim
