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 All, and especially build system maintainers :)
I have made a pull request[0] to cleanup the symbol exports of Geany.
The PR description pretty much covers the details. If I merge this, it's
going to break the makefile.win32 files, Waf and possibly the Win32
Nightly builds.
I can probably fix-up the makefile.win32 files if nobody else will as
it's just plain GNU make and should be similar changes as the Autotools.
It will require a couple more *nix utilities, namely `sed`, `sort`, and
`uniq` (or a `sort` that supports the `-u` option). A quick search finds
sed[1] and coreutils[2] which contains `sort` (probably with -u option)
and `uniq`. I assume MSYS also includes these common utils.
I don't really know enough about Waf to fix it. Since it needs Python
anyway, we could just use one of its XML libraries to grab the names
from the GtkBuilder file, and do the replacements using its
text-handling functions. It wouldn't require sed/sort utils. I
originally had a Python script[3] doing this, but I'm just not sure how
to integrate that code into Waf.
If the Win32 Nightlies break it will most likely be trivial changes to
the Makefile.ams. I don't have an environment like it uses to test.
Geany-Plugins Autotools should be fine since it will pickup the new
library from the pkg-config flags. There's a couple bugs in some (of my)
plugins where it misses the needed linker flags which are trivial to
fix. I don't know if Waf uses pkg-config or what, but if not, it will
need to add the equivalent of something like `-L/geanys/lib/dir -lgeany`
to be able to find and link to the new library.
Is everyone OK if this PR was merged to master and we had to fix up some
build system stuff? Alternatively, I could also add anyone for push
rights on my geany fork or push it to a branch on main geany repo if we
wanted to sort-out the integration issues before merging to the main
master branch.
Cheers,
Matthew Brush
[0]: https://github.com/geany/geany/pull/358
[1]: http://gnuwin32.sourceforge.net/packages/sed.htm
[2]: http://gnuwin32.sourceforge.net/packages/coreutils.htm
[3]:
https://raw.githubusercontent.com/codebrainz/geany/74d21da4570c777a4a112b74…
Hi,
I've built new Windows installers from current GIT master against a GTK
2.24 development environment and the GTK 2.24 runtime environment is
also included in the full installer.
This is a preparation step for future releases which should be shipped
with a recent GTK runtime on Windows.
Downloads can be found here:
http://download.geany.org/snapshots/
Please note that these are test builds from the current development
version, don't expect release quality.
You have been warned :).
But after you installed the snapshots, you can also use the nightly
builds again on Windows (i.e. copy the archive contents over the
installation).
I noticed two issues so far which I have not yet debugged yet:
- auto completion popup is rendered incorrectly
- some icons are missing/not displayed correctly
Screenshots for both issues are attached.
The icon problem seems to be somewhat related to g_themed_icon_new() but
I'm not yet sure. I just had a quick look at the code.
@Lex: somewhere you said you used Geany with the GTK 2.24 runtime in the
past. Did you notice the icon problem?
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
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
Dear all,
I "forked" geany-plugin git repository in bitbucket to work on geanyprj
plugin and add it filtering capability in the project file listing. As an
example, with this contribution one is able to fast-find unit-test makefile
by typing "unit test make" in a new filter input box or directly when file
listing is focused.
I appears that github does not offers to create pull requests from such
forks. Which procedure do you like contributors to follow in such case?
Should I create a github account and push on it?
Note: my fork is available through this link:
https://bitbucket.org/Thannoy/fork-geany-plugins
Best regards.
Anthony Loiseau
Hello,
I try to debug a simple c program and geany crashes all together when I
press the run button.
Also there are no icons on the buttons in the debug panel
I'm using geany 1.24.1 on ubuntu 14.10 64bit
with the latest source of geany-plugins from github.
Is there something I'm doing wrong? How can I fix this?
The program I'm trying to debug is:
#include<stdio.h>
/* demo.c: */
int main(int argc, char **argv)
{
printf("hello world\n");
return 0;
}
and I can build it and debug it with gdb
the target specified in geany is the executable as generated with
gcc -g tect.cpp
The message I get in the console is:
(geany:1151): GLib-CRITICAL **: g_string_free: assertion 'string !=
NULL' failed
(geany:1151): GLib-CRITICAL **: g_string_free: assertion 'string !=
NULL' failed
(geany:1151): GLib-CRITICAL **: g_string_free: assertion 'string !=
NULL' failed
(geany:1151): GLib-CRITICAL **: g_string_free: assertion 'string !=
NULL' failed
(geany:1151): GLib-CRITICAL **: g_string_free: assertion 'string !=
NULL' failed
(geany:1151): GLib-CRITICAL **: g_string_free: assertion 'string !=
NULL' failed
(geany:1151): GLib-CRITICAL **: g_string_free: assertion 'string !=
NULL' failed
(geany:1151): GLib-CRITICAL **: g_string_free: assertion 'string !=
NULL' failed
(geany:1151): GLib-CRITICAL **: g_string_free: assertion 'string !=
NULL' failed
(geany:1151): GLib-CRITICAL **: Source ID 787 was not found when
attempting to remove it
I hope this is the appropriate list for such discussion, and I apologize
if it is not.
thank you very much for the great work you 've done.
best regards
Alexis Panagiotopoulos
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,
while adding the ctags parser for go here
https://github.com/geany/geany/pull/373
I noticed that it's necessary to change the tag types (the GoKinds[]
array in the case of go) to match the supported types in the tag
manager and Geany. This has to be done for every parser because the
tag types aren't standardized in any way in ctags and can be more or
less arbitrary.
In my opinion, doing this in the parser itself is a bit unfortunate -
when updating a parser from the ctags repository, these have to be
changed. Worse, if ever something like ctags shared library happens
and all the parser support is moved there, these will have to be
always changed in every parser after updating to new ctags version.
I think it would be better to keep the tag types inside the individual
parsers as they are and have a separate table in the tag manager which
will map the ctags type to the type used by Geany.
The only disadvantage of this approach I can think of is that the type
names might change in ctags and we could easily miss this change and
not update the mapping. For this reason it would be good to add some
"integrity check" function which goes through all the kinds in ctags
for every language and checks whether they are mapped to Geany's tag
types and vice versa. But I think this can be done quite easily so it
isn't a real problem.
What do you think?
Cheers,
Jiri
