Hi,
since the 2.6 API docs on www.gtk.org seems to not be available
anymore, I put them on http://geany.uvena.de/manual/gtk/ for reference.
These docs are meant for people who want to write plugins for Geany or
want to modify Geany's source code.
Obviously you can also use the current API docs for these libraries.
But using the 2.6 docs of the GTK libs (including GLib, GDK and Pango)
has the advantages that you don't get confused by any newer API
additions and you don't have to take care about whether you can use
them or not.
This is because Geany depends on GTK 2.6. API symbols from newer
GTK/GLib versions should be avoided to keep the source code building
against GTK 2.6. Therefore the offer of the outdated docs.
Plugins authors doesn't have to keep their plugins compatible with GTK
2.6, but maybe they want to because Geany does.
To make a long story short:
if anyone wants to use GTK 2.6 docs, you can find them on
http://geany.uvena.de/manual/gtk/ ;-).
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.key
As mentioned in my previous posting, I have spent some time to try 0.13 new
project features. While starting to test, I've found to smaller glitches.
* vcdiff: if the CVS access uses SSH, the passphrase entry is invible. If I
call geany from the shell, I'm able to enter the passphrase there.
* enforce the extension of the project file. I've edit the filename first,
and forgot the extension. After this, ".geany" got lost.
* opening a project automatically closes all files from outside the
the project, if the file was loaded previously to the project. After
closing the project, these file got loaded again.
Now I load the project first, and than the "other file". After closing the
project, the "other file" is closed too. This is also the case, if Geany
is closed with the project and the "other file" open. After the new start,
all files are open. But again, closing the project will close the
"other file" too!
Is this a bug?
But now the notes on the project management.
* I need to switch between different projects. It would be
good to have a sidebar with all projects listed. The project properties
should have a checkbox to hide a (inactive) project in the sidebar. It
therefore must be visible in the "open project" dialog.
All files from outside these projects can be automatically added to an
"virtual" project 'unmanaged'. So the user can fast toggle between a
project and the "other" files.
* The tabs with the opened files and the "documents" sidebar allways shows
the loaded files of the current project. To make access even easier, the
"documents" sidebar could hold all of todays used projects as special entries
(i.e. as bold text). Maybe this highlighting could be used for the
"projects" sidebar to.
* The "projects sidebar" or the main toolbar should have a "drop down" box
with a list of "release flavours". The list can be fix or may be part of
the project properties. The handling of these "flavours" is done in the
makefile. To make the change of a flavour visible, Geany should remove
a flag file in the project director. This file should be defined in the
project properties. As default .build-stamp can be used. Without this file,
a "make clean & make" is performed (by the makefile) to force a rebuild.
The only thing Geany has to do: (1) if the project properties defines a
"stamp file", this file must be removed when switching the "flavour".
(2) The project properties must be extended to hold configurable list of
"flavour" stings. (3) The selected flavour must available as macro for
the make command (of the project). So it will be passed to make, which
will do all the work. This means there is no makefile generator.
I personally use the flavours "DEBUG", "BETA" and "FINAL". I pass them as
variable RELEASE to make (i.e. make RELEASE=DEBUG). This is handled inside
the Makefile.
* one last thing for now ;-) My old Laptop has a screen resolution of
1024x768. It would be great to have icons instead of text as lables for
the tabs of the sidebar.
hi all, I'm new to the list and somewhat new to geany. I'm a developer and
have recently moved from Windows + Editpad Pro for my editing to Linux +
Geany. The move has been somewhat rocky, mostly due to the slightly
different workflow, but there is one "feature" in Editpad that I really
found useful and I'd like to bring it to Geany.
Editpad has a sidebar file browser that is a mix of Geany's Documents
sidebar + the file browser plugin. That is, it only shows open documents,
but it reveals which directory each file is in, like so...
includes
pdf
- pdf.php
- file.php
- http.php
- index.php
- something.php
So if you're working on files in different directories, it gives you a
visual representation of that, rather than a flat list of open documents in
the Geany Documents sidebar. And it only shows files that are open.
Geany can be made to show the full path of files, but even if all the files
are in the same directory, it shows the entire path (/home/adam/.....) for
all files.
I was wondering if this functionality already exists in either Geany or in a
plugin. If so, I haven't been able to find it. If this functionality
doesn't already exist, would it be better for me to look into making a
plugin for it? I haven't actually opened up the geany code yet, so I don't
know much about what is going on internally. But I would appreciate some
steering in the correct direction as to the best way I could implement this.
Thanks all,
Adam
Hi
I guess it is time to release geanyprj plugin. Main goal of this release
is make "go to tag declaration/definition" work for all files in project
(not just currently opened ones).
Plugin webpage: http://users.cosmostv.by/yurand/geanyprj/
Download: http://users.cosmostv.by/yurand/geanyprj/geanyprj-0.2.tar.gz
Example of usage:
On Geany sources:
1. Download geany-0.13.tar.gz
(http://prdownloads.sourceforge.net/geany/geany-0.13.tar.gz?download)
2. Unpack it somewhere, for example in ~/src/geany-0.13
3. Open ~/src/geany-0.13/configure.in
4. Click "Tools->Project->New Project", and click "Create" button
This will create and save .geanyprj file in ~/src/geany-0.13.
From now, every time you open any file from ~/src/geany-0.13
directory or it's subdirs .geanyprj will be opened. So next time
you don't have to create or open project manually.
1. Open any geany source code code file
"go to tag declaration/definition" should work for any geany
function. (Not limited to opened files).
1. Now you open file that doesn't belong to Geany. For example
~/src/myprj/a.c Geany project will be closed. If
~/src/myprj/.geanyprj exists it will be opened as current
project.
2. Switching back to any Geany file will open Geany project again.
BUGS:
The plugin will work bad on Windows, since it assume filenames encoding
is utf8.
--
Best regards,
Yura Siamashka
Hi,
Here is another patch to improve a little bit the win32_spawn
functions. It adds:
- GError support for the win32 functions (thanks to Jeff for the link!)
- return code is now set on return
- begin of time out support (30sec for sync)
The timeout is set to 30 secondbut it is not really required right
now, the default behavior being to wait until that the process exists.
The upcoming async support will use it more intensively (still some
work, don't hold your breath :).
Cheers,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
Dear Devs,
Currently, the 'Files' sidebar sorts file alphabetically, but GTK's 'open'
dialog sorts the naturally.
Files tab:
File_1.ext
File_10.ext
File_100.ext
File_11.ext
File_2.ext
GTK Open dialog:
File_1.ext
File_2.ext
File_10.ext
File_11.ext
File_100.ext
I don't know if this would be an easy fix, but it would help me a lot!
Cheers!
-H-
I made a substantial update to my little set_geany_colors script (can
be found at http://www.milliwatt-software.com/jmg/notes/geany.html#Syntax%20highlighting
). If you were using the previous version, note that the colorscheme
file format has been updated: so, if you have any of your own
colorschemes, you'll want to back them up and possibly migrate them to
the updated format (only a few small changes).
The big change to the program is that now it's fully-configurable: the
user may, at their discretion, change which entities (names for things
you have a style set for, ex. "identifier_3") are used for which
filetype-specific style element (i.e. the keys in the filetypes
files). Details are in the set_geany_colors docs in the distribution.
I'm guessing most users will not bother with that though, and just use
the defaults for those mappings.
You can also now specify optional alternative background colors for
most entities. In your colorscheme file, it looks like:
word_2=green;light_green,bold
Enjoy, and please let me know if you find any problems with it or the
documentation. (Note, it's only been tested on GNU/Linux.).
---John
I normally build software with many warnings turned on, and also frequently
build on non-Linux Unix platforms. In the course of doing both with Geany,
I came across many warnings and portability issues that the attached patch
seeks to address.
Below is a walkthrough of the changes. I'll describe each sort of change
only once, the first time it occurs in the patch file, for brevity:
* (various files): Anytime you have a prototype/definition of a function
that doesn't take arguments, use (void) instead of (). This eliminates
the "function declaration isn't a prototype" warning.
* highlighting.c: Bitfields in structs should properly have a full integer
type.
* highlighting.c: Declaring these HighlightingStyle structures as "static"
gets rid of "initializer element is not computable at load time" when
they are used in the subsequent entries[] array.
* keybindings.c: Definition of keys[] moved here from keybindings.h. (See
below for explanation)
* keybindings.c: Replaced the floating-point bit with a bit of integer
math. This parameter is supposed to be an int, so you want to keep it an
int.
* highlighting.h: The "gboolean" type already indicates that these fields
are true-false flags, and GCC complains about portability if a bitfield
specifier is used.
* keybindings.h: Declare, don't define, the keys[] array here. Otherwise,
you'll have multiple definitions of keys[] floating around (one for every
.c file that uses this header), and the link step will break if you use
-fno-common (which you should!).
* sciwrappers.c: Argument 3 to SSM() is supposed to be unsigned, so stick
in a cast to make it clear that what's getting passed is *not* -1.
* encodings.c: Moved the definition of the encodings[] array here from
encodings.h.
* encodings.c: i is unsigned, so cast that -1. (Enrico, you may want to
have a closer look at the logic of this loop... it seems to assume that i
might be (guint)-1 going in, but that's impossible, because (guint)-1 is
not less than GEANY_ENCODINGS_MAX.)
* encodings.c: Use the handy-dandy printf specifier for gsize that GLib
provides for us.
* encodings.h: Declare, don't define, the encodings[] array here.
* prefs.c: No comma after that last entry.
* dialogs.c: Cast the int to gboolean. (gboolean is probably int anyway,
but an explicit cast makes things clearer.)
* msgwindow.c: Using the function parameters in the initializer gives a
"initializer element is not computable at load time" warning, so just
assign them to the fields afterward.
* keyfile.c: Compounds literals look cool, but they confuse older
compilers.
* prefix.c: Stick in a trivial bit of code to avoid an empty source file
when we're not building a relocatable binary.
* vte.c: Definition of vc moved here from vte.h.
* vte.h: Declare, don't define, the vc variable here.
* document.c: gchar is a signed type, so when you assign e.g. 0xef to it,
GCC complains that the literal value overflows the type. So cast
explicitly.
* plugins.c: The cast and extra parens in this conditional do not appear to
be necessary.
* editor.c: event->x and event->y are gdouble, but
sci_get_position_from_xy() wants gints, so cast appropriately.
* socket.c: Moved the definition of socket_info here from socket.h.
* socket.h: Declare, don't define, the socket_info struct here. Some extra
footwork is needed here since the struct structure is being defined as
well.
* tm_workspace.c: Got rid of a stray semicolon.
* c.c: The cpp conditional should first check whether DEBUG_C is actually
defined or not, before using it in a conditional expression. This change
gets rid of the warning, but what you might want to do instead is just
change the #if into an #ifdef. (I couldn't do that without knowing how
DEBUG_C is used, so I leave that to you.)
* sort.c: error() expects a formatted string + optional arguments, but
since we're just passing a single, variable string, GCC gets nervous
about not being able to check the format. Use a plain "%s" + string to
set it at ease.
The biggest portability issue, however, is one that a patch is not
well-suited to fix: the use of C++-style comments in C code. GCC allows
this, but will readily warn that "C++ style comments are not allowed in ISO
C90", and Unix compilers almost universally choke on them as a syntax
error.
--Daniel
--
NAME = Daniel Richard G. ## Remember, skunks _\|/_ meef?
EMAIL1 = skunk(a)iskunk.org ## don't smell bad--- (/o|o\) /
EMAIL2 = skunk(a)alum.mit.edu ## it's the people who < (^),>
WWW = http://www.******.org/ ## annoy them that do! / \
--
(****** = site not yet online)
Dear Geany devs,
I've got some little issues/requests:
* Closing tab 3 focuses tab 2 instead of the new third tab.
tab1 tab2 [tab3] tab4
*close tab 3*
tab1 [tab2] tab4
Firefox (and other apps) all focus the new third tab
tab1 tab2 [tab4]
* Ability to assign keybindings to "Edit -> insert comments"
* The last line in your(/a php) file doesn't behave correctly. For example:
autocomplete does not work
File browser plugin
* Use of '~' in the 'path' input
* Change the background of 'path' to red if the path you've entered doesn't
exist (just like the search bar does)
* Show a tooltip when hovering above an item that doesn't fit in the
sidebar's width
Maybe if one could find some time or just feels like fixing/adding these
requests, please do! ;)
Still loving Geany!
-H-
Hello,
I first would like to say that I am a happy user of Geany: it's not to heavy
requiring a lot of configuration and start-up time as compared with other IDEs
and it's interface is also not cluttered with too many functions. Therefore I
use it for coding sessions that exeeed the simple text editing. It is also the
only editor that shows also vaiables ant to only functions in the overview on
the left side.
I have one question though:
Does Geany support or will it support calltips for the following languages:
* python like for instance in Editra:
http://editra.org/images/preview/Windows/editra_pycomp.png
* xhtml
* CSS
This would be a perfect killer feature!
Thanks for your good work.
Timmie
