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
Matthew Brush <notifications(a)github.com> wrote:
> @elextr FWIW, the files `makefile.win32` and `win32env.mk` (and geanypy.nsis for the installer and README.win32 for the instructions) are needed for `src/makefile.win32` to be useful.
>
> @eht16 Any chance you could get some time to try getting the Waf build system working so it can be built on Windows?
Taking cause from Geanypy, there are 2 small problems with $subject:
- no header fiels are installed, or maybe they are copied somewhere
outside the $prefix. Copying the headers manually is OK.
- geany.pc contains paths with single backslashes, and plugins build
fails with "c:path1path2...: no such file or directory". Replacing
with forward slashes works. All other .pc files I've checked under
win32 use forward slashes.
I haven't tried the latest git though.
--
E-gards: Jimmy
Hi Enrico,
We have had a report on IRC that running geany on the windows command
line will only open files in the Geany install directory unless you
use the full path.
eg C:\somepath> geany somefile.txt
will open installpath\somefile.txt not somepath\somefile.txt.
And with the "Open new documents from the command line" option set it
creates somefile.txt in the install dir since it doesn't exist there.
Suspicion is falling on
https://github.com/geany/geany/commit/775ef628688c69de34640e12666aed5762a80…
As the most experienced windowser (and the committer of that change)
could you look at it please?
Cheers
Lex
Hi All,
Recently there have been a number of proposals for significant changes in
Geany, different languages, GObjectification and other various changes.
As good or bad as the individual suggestions may be, they have made it
clear to me that there is no plan for the future of Geany that allows them
to be evaluated effectively.
So I am starting this thread to try to get ideas on where Geany should be
headed.
To start the ball rolling, here are some of the things I see Geany should
aspire to:
1. An architecture that allows multi-threading to be used for non-GUI
tasks. The most obvious of course is parsing. At the moment none of the
parsers support symbols in anything other than the global scope, and adding
them would significantly increase the parsing effort, but doing it in a
background thread would make the performance hit less obvious. But there
needs to be a careful design of the passing of data from the edit buffer to
the parser and back to the symbol tables to minimise overhead, latency and
ensure its non blocking. With such an architecture other complex
functionality can then also happen in the background without impacting
Geany's responsive feel.
2. Language specific assistance, such as indentation, or dynamic error
marking and intelligent autocompletes. I consider that these hang off the
previous capability of better parsing/analysis of the program. Matthew has
demonstrated a prototype that provides some of these facilities using
libclang (for the clang languages only C, C++, Obj-c). But the current
Geany architecture does not support plugging such things in easily, and
with the number of languages that Geany supports, I would suggest that its
small, light and fast tag would be severely threatened if assistance for
all languages were plugged in at once.
3. Proper portability. At the moment Geany is really a Linux application
that has some limited (and buggy) support for Windows. The main editing
widget that Geany uses is available for many platforms and toolkits. If
Geany had an architecture that separated the target specific parts into a
"backend" the way Scintilla does, then it would be possible to support
multiple targets more easily, making Geany less at the mercy of one
toolkit's direction (that means you deprecating GTK) and better able to
support different platforms like OSX and Windows. Work such as that
Dimitar is doing for spawning on Windows naturally then falls into such a
backend.
4. Multiple top level windows. As monitors are cheaper, being able to
spread views of files to optimally utilise the screen space available adds
to the users effectiveness. Most languages support multiple modules in
different files and many use multiple files for related parts, such as
C/C++ header and body. Looking at and editing several places/files at once
has many uses. As useful as splitwindows one and two are (especially
together) they still assume a single rectangular top level is available for
subdivision. But different desktop menu layouts or having other
applications visible at the same time can limit the contiguous rectangular
space available. Multiple top levels can make better use of
non-rectangular space.
These are all big changes that don't fall into the current Geany mode of
"light maintenance and extra features as someone implements them". For big
changes like those above however, a clear design and a planned process is
needed to ensure that the big changes don't clash with each other and that
they are not derailed by interim smaller changes.
I would suggest the process to be:
1. gather other major ideas for capabilities that Geany should plan to
support
2. develop a design that supports these (or at least the most useful ones)
3. look at how that design can be implemented, can the existing design be
mutated to it, or is it a clean framework that large parts of the existing
functionality can plug into, or is it a whole clean implementation. This
also includes issues like languages to use (C, C++, Vala, Haskell etc).
4. depending on the outcome from 3. use a new repository organisation or at
least a new branch in the existing Geany repo to ensure that the existing
Geany is not destabilised by major changes as they take place.
This is something very different to the way Geany is currently operating,
and I don't know if the community wants to consider such a more structured
approach. If its felt that its worthwhile then I suggest that steps one
and two are best achieved using the wiki and I will volunteer to set up and
maintain page(s) for those phases at least.
So to summarise, what capabilities should Geany aspire to support, and what
is the process to develop the best software architecture to support those
capabilities.
Cheers
Lex
Hi All,
Its about that time of year when we have our annual discussion on
separating session data from config/project data :)
By session data I mean the list of currently open files and MRU list.
The advantages (that I can see):
1. Save config/project as its changed and not rushed at quit time (and
the quit save doesn't happen in the absence of a working, portable,
session management capability)
2. Save session data periodically, or as it changes, or whenever,
without touching the config/project files. So the config isn't at
risk if the session save goes wrong.
The only disadvantage for user config (that I can see) is that it adds
one file, say geany.session.conf alongside geany.conf
For project sessions just using another file in the same place as the
project file is more of a problem since project files can be in the
project tree and some people like to save them in VCS. So users would
have to make sure that their git.ignore (or whatever the other VCSes
use) is edited each time so that the session file isn't saved in the
VCS.
A better option, especially since sessions are inherently user
related, is to store them in the user config location (or subdirectory
thereof). But how to link these files to the project files?
The proposal is that each project gets a UUID generated when it is
created (or when its opened without one) which is saved in the project
file. This uuid is the name of the session file in the
${GEANY_CONFIG}/sessions directory. That way, when a project is
opened, it is easy to uniquely find the session file if it exists.
Using things like filenames, project names etc will always have
clashes. Libuuid is used by GTK so it will always be available on all
platforms we use and so making the UUID is one call. (Pity GTK doesn't
expose it though)
The number of session files can be left to grow like weeds, or can be
trimmed to a (configurable) maximum number deleting the oldest when
needed.
This proposal isn't about a proper session management capability,
there isn't one that works on enough platforms to be worth including.
Any thoughts welcome.
Cheers
Lex
Hello,
is gtk3 port still supported? It doesn't work now.
It writes to me:
**
Gtk:ERROR:gtkstylecontext.c:1019:style_data_lookup: assertion failed:
(priv->widget != NULL || priv->widget_path != NULL)
Aborted (core dumped)
Thanks for answer
Hi,
The attached archive contains:
- spawn.[ch] - spawning functions and tests, not Geany-dependent
- Makefile - to compile the spawning tests under *nix/win~1
- emit.c - a useful program to spawn
- spawn.rsp - as in "./spawn < spawn.rsp"
- respawn.diff - patch for Makefile.am, build.c and tools.c
I can patch search.c as well, if we agree on "grep --exclude-dir"
for the non-recursive searches instead of finding and passing the
file names manually, as explained in the "Improving FiF" thread. If
we don't, or start some endless discussion, feel free to replace
the current mess with a smaller one.
tools.c should probably use spawn_sync(..., gchar *stdout, gchar
*stderr, gint *exit_status), but I haven't written one yet.
If the spawned program emits mixed stdout and stderr messages fast,
like emit.c, they will be grouped, depending on the size of your pipe
buffers. Doesn't seem a problem in practice - the tons of messages
from making Geany with -Wall -WExtra are OK, and running ./autogen.sh
is fine too.
Note that there is no conversion to UNICODE under win~1. Using the
"ANSI" functions is OK AFAICT, make/grep/gcc are all "ANSI" programs,
and the only thing an ansi -> unicode -> ansi conversion does is to
produce errors such as "Create process failed, unable to encode byte
at offset xyz" (win~1 FiF with non-UFT-8 fails regularily).
--
E-gards: Jimmy
Hi all,
I'm new in Geany Plugin Dev. I'm try to follow the step of this gude:
http://www.geany.org/manual/reference/howto.html
When I create the plugin.so file I don't know where this file must be moved.
My system is an Ubuntu 12.10 with Geany installed from repository,
Can you help me, please?
