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
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.
Colomban mentioned this recently, it's got quite a lot of updates over
the original ctags AFAICT:
https://github.com/fishman/ctags
Just thought I'd share here. They have a Go parser, should any Go people
wish to add it to Geany.
Hi All,
Since there's some discussion about infobar behaviour, I thought I'd
mention a couple things I've noticed using it in my day-to-day workflow.
When you delete a file from disk, and then assuming the infobar kicked
in (see below), it pops up the infobar as expected. The problem is that
there's no quick way to say "Ya, ya, I deleted that on purpose, just
close the file". IMO, there should be a "Close" button on the infobar
that allows you to bypass the redundant dialog that pops up when trying
to close a document that you've been notified about, for example:
-----------------------------------------------------------------
File "foo.txt" was not found on disk [Resave][Dismiss][Close]
<Some different message here>
-----------------------------------------------------------------
Clicking the proposed [Close] button would have the same effect as what
currently requires two steps; clicking the tab close button or Close
menu item and then clicking the "Don't Save" button in the dialog that
pops up.
Does that sound reasonable?
The other thing I wondered is, should we not do a "disk check" on a file
that hasn't been switched to when it's being closed? I mean we do the
check and show the infobar on tab-switch (due to lacking proper/usable
inotify support), but if the user doesn't actually switch to the tab,
then we just close the file without any warning that the buffer in that
document has no disk file anymore and closing it will lose those
contents forever.
Thoughts?
Cheers,
Matthew Brush
Hi,
this is about commit ab7a0018b2518793f26af2fe20a06a8a1886e031 and the
message reads "
Don't prompt for reload from infobar when there are no unsaved changes".
What does that mean? I do absolutely want to be asked before reloading
even if the file has no changes or saved ones.
Best regards
Hi,
I spent some time on the nightly builds and now:
- the buildbox was upgraded from Debian Squeeze (oldstable) to Debian
Wheezy (stable)
- Debian builds work again (they were partly broken for some time for
various reasons)
- GTK compatibility checks are enabled again, now against GTK 2.24.10
(the GTK2 version in Debian Stable)
- Win32 and GTK2 test builds are executed in RAM disk and also use
ccache which speeds up the compilation time heavily and reduces disk I/O
a lot.
The last point won't help much most people but will enable us to enable
a future step: building Win32 and GTK2 compatibility check as a
commit/push hook to get instant check results.
This is not yet implemented but I will do this at some point soon, as
time permits.
Results can be found on http://nightly.geany.org/.
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
