date:20100609

On Wed, Jun 9, 2010 at 03:40, Lex Trotman ele...@gmail.com wrote:
Hi again,

Note I wasn't criticising your plugin, but wanted to make sure you
knew about some potential upcoming capabilities that might also be
useful in combination.

I absolutely understand. In fact, I prefer critical voices - it makes
no sense to say each other how good we are (we know that already,
don't we ;-). So please take also my comments in this sense.

OK, I understand. Still in certain situations it's better to have
several different projects (here I mean project in the sense I
understand it) opened in the single instance. Won't remove this
feature ;-)

Oh sure, I wasn't suggesting you should.

Was rather joke from my side. On the other hand removing features
was the way I developed the plugin - originally I planned many more
features but then ended with a minimal consistent set of features that
play well with the rest of geany.

* you can specify patterns for source and header files separately -
there is a swap header/source functionality that finds the
corresponding header/source to the currently opened document (same
base name matching header/source pattern)

Nice, I'd like to add that to the filetype config to have it available
in the base Geany, sometime :).

Should be pretty easy.

Coding is easy, time is hard

Very true.

(But the coding part applies for reasonably small and simple projects
like geany, not multithreaded, multiprocess, multiserver projects
communicating using CORBA consisting of thousands of source files,
which is something I have to work with at work).

Ah, OK, didn't know it was so close. On the other hand these are
really just few-liners so might be worth considering. These are the
requirements for gproject to work:

http://gitorious.org/~techy/geany/techys-geany/commit/6806f193b475e24dee649dfad854731342b30ebd

http://gitorious.org/~techy/geany/techys-geany/commit/0b25a1225a7425ab7d726c80a93476694dee230b

http://gitorious.org/~techy/geany/techys-geany/commit/f11ab5f59cf4201d08f04fef8cba40b54843625f

And this fix should definitely go to 0.19:

http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c55f853f529efde223f

I think I didn't properly describe this one in the commit log - there
is a 600ms interval in which the panel displaying the current file
name isn't displayed. If you switch tabs with a keybinding and do it
too quickly (press it twice in the 600ms period), the wrong file is
put on top of the stack. The patch could be smaller but I found the
code a little confusing so I tried to make it clearer a bit.

Ok, up to the guys if they have time.

Sure.

The few more patches are trivial ones. The changebar patch is meant
just for testing and not for integration to 0.19.

I'd like to suggest you tag commits you are going to refer to, not
leave them as hashes, which of the links above is this one?

None ;-). Instead of tags I created different branches (described in
my original mail) - if you want to quickly see what's in the branches,
just click the branch name here:

http://gitorious.org/~techy/geany/techys-geany

(branches: changebar fixes gproject-deps all) The first three links
are from the gproject-deps branch and the last one from the fixes
branch. The changebar is, not surprisingly, in the changebar branch.

Again, unless contradicted, you should submit your changes as
individual patches, one per change with explanation, so they can be
reviewed one at a time. Having to grab them all from your repository
makes the job too big and less likely to happen.

Huh, really? What makes the job too big exactly? The reason why I
submitted the patches this way is just the opposite - to make them
easier to merge. You just git pull and that's it. As I said, as a
maintainer of an open source project I prefer patches submitted this
way but it's no problem for me to submit them in the traditional way
(after all, anyone can do that by runing git format-patch after
cloning the repository - I still don't see your point).

The point is you are forcing people to clone your repo to get the patch.

Then, which commits are meant to be individual patches?

The master branch is equivalent to geany mainline, the branches
contain my patches (quite a standard way how to submit patches with
git). My repo is a clone of the geany project I've created here:

http://gitorious.org/geany

It would be best if this was taken over by the geany developers and
kept up to date with the current mainline.

Since as I said above, treating the whole set as one change is less
acceptable than smaller individual patches, harder to review. Thats
what I meant by too big.

Well, there is no whole set there - the individual patches are in
the form of commits.

Sure its easier if everyone is using git, but ATM this is an SVN project.

It's true that I've used the workflow typical for a git project - from
geany web page, which offers both git and SVN repository

[Geany-devel] linear time tag manager - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Mon, 7 Jun 2010 23:38:19 +0200
Jiří Techet tec...@gmail.com wrote:

 * for big projects I'd like to create some basic ctags support. The
 tag manager used by geany is totally unusable for big projects because
 building the object hierarchy has quadratic to exponential complexity.
 I need a simple tag support that works in linear time.

Wouldn't it be better to fix tagmanager (if possible) to work faster -
what is the cause of the non-linear behaviour - is it resorting?

Regards,
Nick
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Git - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Wed, 9 Jun 2010 13:06:45 +0200
Jiří Techet tec...@gmail.com wrote:

  Sure its easier if everyone is using git, but ATM this is an SVN project.
 
 
 It's true that I've used the workflow typical for a git project - from
 geany web page, which offers both git and SVN repository I assumed
 that I can chose either of them. If git is not supposed to be used,
 then it should be removed from there because this makes things
 confusing (or at least there should be a warning saying: Don't use
 the following git repository).

It's pretty clear from the GIT page that it's a read-only mirror. We
don't have a writable GIT repo.

 
 Anyway, no problem for me to provide the changes in the form of
 individual patches. I'll just wait for the main developer's opinion on
 this before spamming with additional emails.

Individual patches are better. That saves us time. Just looking
through a Git repository isn't a good way to explain changes.

Regards,
Nick
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] switch dialog bug - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Wed, Jun 9, 2010 at 14:56, Nick Treleaven
nick.trelea...@btinternet.com wrote:
On Tue, 8 Jun 2010 18:59:35 +0200
Jiří Techet tec...@gmail.com wrote:

And this fix should definitely go to 0.19:

http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c55f853f529efde223f

Thanks for finding fixing the bug. However, I'm not sure we should
put this in the release as the bug isn't too important and the fix
changes quite a bit of code.

Sure, as you wish. On the other hand I've been using geany with this
modification for 2 months without any problem (and I find this feature
quite important as I work with lots of files and want to be able to
switch between them reliably) while before the tab switching just
didn't work for me.

BTW, why do you destroy the dialog instead of hiding it?

It's just that I can write

if (switch_dialog)

instead of

if (switch_dialog GTK_WIDGET_VISIBLE(switch_dialog))

but I can change that if your preference is different.

Regards,

Jiri
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin

On 9 June 2010 21:06, Jiří Techet tec...@gmail.com wrote:
On Wed, Jun 9, 2010 at 03:40, Lex Trotman ele...@gmail.com wrote:
Hi again,

Note I wasn't criticising your plugin, but wanted to make sure you
knew about some potential upcoming capabilities that might also be
useful in combination.

I absolutely understand. In fact, I prefer critical voices - it makes
no sense to say each other how good we are (we know that already,
don't we ;-). So please take also my comments in this sense.

Oh sure, I wasn't suggesting you should.

Nice, I'd like to add that to the filetype config to have it available
in the base Geany, sometime :).

Should be pretty easy.

Coding is easy, time is hard

Very true.

Ah, OK, didn't know it was so close. On the other hand these are
really just few-liners so might be worth considering. These are the
requirements for gproject to work:

http://gitorious.org/~techy/geany/techys-geany/commit/6806f193b475e24dee649dfad854731342b30ebd

http://gitorious.org/~techy/geany/techys-geany/commit/0b25a1225a7425ab7d726c80a93476694dee230b

http://gitorious.org/~techy/geany/techys-geany/commit/f11ab5f59cf4201d08f04fef8cba40b54843625f

And this fix should definitely go to 0.19:

http://gitorious.org/~techy/geany/techys-geany/commit/62deb4ec5c2b8de4d0979c55f853f529efde223f

Ok, up to the guys if they have time.

Sure.

The few more patches are trivial ones. The changebar patch is meant
just for testing and not for integration to 0.19.

I'd like to suggest you tag commits you are going to refer to, not
leave them as hashes, which of the links above is this one?

None ;-). Instead of tags I created different branches (described in
my original mail) - if you want to quickly see what's in the branches,
just click the branch name here:

My misunderstanding

http://gitorious.org/~techy/geany/techys-geany

That seems a bit confusing, maybe we should call them all Bruce (Monty
Python reference :)

The point is you are forcing people to clone your repo to get the patch.

Then, which commits are meant to be individual patches?

The master branch is equivalent to geany mainline, the branches
contain my patches (quite a standard way how to submit patches with
git). My repo is a clone of the geany project I've created here:

http://gitorious.org/geany

It would be best if this was taken over by the geany developers and
kept up to date with the current mainline.

Since as I said above, treating the whole set as one change is less
acceptable than smaller individual patches, harder to review. Thats
what I meant by too big.

Well, there is no whole set there - the individual patches are in
the form of commits.

Re: [Geany-devel] linear time tag manager - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Wed, Jun 9, 2010 at 14:58, Nick Treleaven
nick.trelea...@btinternet.com wrote:
 On Mon, 7 Jun 2010 23:38:19 +0200
 Jiří Techet tec...@gmail.com wrote:

 * for big projects I'd like to create some basic ctags support. The
 tag manager used by geany is totally unusable for big projects because
 building the object hierarchy has quadratic to exponential complexity.
 I need a simple tag support that works in linear time.

 Wouldn't it be better to fix tagmanager (if possible) to work faster -
 what is the cause of the non-linear behaviour - is it resorting?


Well, I had a very brief look at the tag manager so the following may
be wrong. From what I have seen the tag manager maintains a hierarchy
of say N objects. If you e.g. remove a file with M objects, for each
of the M objects you have to scan the N objects and remove the
reference to it. This makes N*M loop iterations (OK, I was wrong about
the exponential time if it really works this way, but again, I would
have to study the sources more carefully).

API-wise, the slow functions are

tm_workspace_add_object()
tm_workspace_remove_object()

I'm not sure if this is fixable - tag manager is definitely more
powerful than ctags that just scans the files sequentially without
creating any hierarchy. I'm not sure what's all the functionality you
use and if ctags' flat structure is enough for you.

Regards,

Jiri
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Git - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Wed, Jun 9, 2010 at 15:06, Nick Treleaven
nick.trelea...@btinternet.com wrote:
 On Wed, 9 Jun 2010 13:06:45 +0200
 Jiří Techet tec...@gmail.com wrote:

  Sure its easier if everyone is using git, but ATM this is an SVN project.
 

 It's true that I've used the workflow typical for a git project - from
 geany web page, which offers both git and SVN repository I assumed
 that I can chose either of them. If git is not supposed to be used,
 then it should be removed from there because this makes things
 confusing (or at least there should be a warning saying: Don't use
 the following git repository).

 It's pretty clear from the GIT page that it's a read-only mirror. We
 don't have a writable GIT repo.


OK, I've just noticed:

Read-only mirrors of the SVN repositories, updated shortly after real
commits in the SVN repository.

But then I don't see the point of providing it if you cannot pull
other people's clones of your repo.


 Anyway, no problem for me to provide the changes in the form of
 individual patches. I'll just wait for the main developer's opinion on
 this before spamming with additional emails.

 Individual patches are better. That saves us time. Just looking
 through a Git repository isn't a good way to explain changes.


OK, will send them later today

Regards,

Jiri
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin


Am 09.06.2010 03:40, schrieb Lex Trotman:

Sure its easier if everyone is using git, but ATM this is an SVN project.
   


Although most, if not all, geany developers use git, don't they?
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin


Am 09.06.2010 13:06, schrieb Jiří Techet:

It's true that I've used the workflow typical for a git project - from
geany web page, which offers both git and SVN repository I assumed
that I can chose either of them. If git is not supposed to be used,
then it should be removed from there because this makes things
confusing (or at least there should be a warning saying: Don't use
the following git repository).
   



Doesn't it clearly say that the git repo is a read-only mirror? And you 
can pull from it like normal, you just cannot push to it. I don't see 
why it shouldn't be used.

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Broken plugin autofools (Was: [ANNOUNCE] gproject - yet another geany project plugin)

2010-06-09 Thread Chow Loong Jin

On Wed, 9 Jun 2010 23:22:51 +1000
Lex Trotman ele...@gmail.com wrote:

 Sigh, this isn't your fault, but I have problems with installing
 unknown software to system directories and plugins autofools is broken
 WRT installing to a non-standard prefix, waf build works if your
 plugin had a wscript.

Please explain in further detail, so that it can be fixed. Thanks.

-- 
Kind regards,
Chow Loong Jin


signature.asc
Description: PGP signature
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin

Hi,

 http://gitorious.org/~techy/geany/techys-geany

 (branches: changebar fixes gproject-deps all) The first three links
 are from the gproject-deps branch and the last one from the fixes
 branch. The changebar is, not surprisingly, in the changebar branch.

 That seems a bit confusing, maybe we should call them all Bruce (Monty
 Python reference :)

NI !


 It's true that I've used the workflow typical for a git project - from
 geany web page, which offers both git and SVN repository I assumed
 that I can chose either of them. If git is not supposed to be used,
 then it should be removed from there because this makes things
 confusing (or at least there should be a warning saying: Don't use
 the following git repository).

 It does say read only, I'd take that as meaning you can't push to this.


Of course I can't push to it but the project maintainers could pull
from me and push by themselves (for git projects typically only one
person has push rights, the others just ask the maintainer for pulling
from their tree and if he likes the patches, he pushes them to the
main repository).

But you are right, I've overlooked that this is just a SVN mirror.


 Anyway, no problem for me to provide the changes in the form of
 individual patches. I'll just wait for the main developer's opinion on
 this before spamming with additional emails.


 Good idea.

 I can see that there are people here not so much familiar with git, so
 I'll just describe in more detail how to get the modified geany and
 the plugin (the following gets the all branch that contains all the
 patches):

 For geany, do the following:

 git clone g...@gitorious.org:~techy/geany/techys-geany.git
 cd to the downloaded directory
 git checkout remotes/origin/all -b all
 build and install geany

 For the plugin do the following:

 git clone g...@gitorious.org:gproject/mainline.git
 cd to the downloaded directory
 ./autogen.sh; make; sudo make install


 Sigh, this isn't your fault, but I have problems with installing
 unknown software to system directories and plugins autofools is broken
 WRT installing to a non-standard prefix, waf build works if your
 plugin had a wscript.


And I dislike using non-standard solutions (as standard I consider
autotools, despite all its drawbacks), so we have a nice deadlock here
:-).

 Well, what I dislike is that there is _any_ build dialog like this in
 geany. The only thing that should be possible is to:

 1. run a user provided command
 2. in the user provided (base) directory

 (And this is basically what geany used to do before 0.19) Plugins
 should be allowed to change these two depending on their needs (not
 possible now).

 As I said coming, patience :-)

  Period. Nothing more. For more complex projects you
 should use makefiles so the user provided command will be make
 executed in the base directory of the project.


 In another post on this thread you complain about IDEs that limit how
 projects work (agree completely BTW), but you would restrict Geany to
 only one build tool? ;-)

Not only one, but only _the_ one the user provides. The dialog should
look this way:

Build command: edit_box
Base directory: edit_box

so if I provide something like

Build command: make
Base directory: /home/techet/projects/geany

it would run:

cd /home/techet/projects/geany
make

(+ there should be a possibility to use the variables like %e, %f, ...)


 The update to the build system is to support running any commands,
 make,nmake,  waf, scons, cmake, ant, bjam, my_favourite_shell_script

But the current build system (and the one present in 0.18) already
_can_ do that, see above. And yes, at work I use my own script that
based on the current file detects the current subsystem, runs other
necessary scripts and starts the build of the subsystem. Why do we
need the special cases as above?

 etc so the Non-filetype commands can't be called make commands
 anymore, and unfortunately the name Build has been appropriated for
 link, other suggestions welcome though, but there aren't many commonly
 understood terms about.

 It is also to allow the commands to be configured differently for
 different projects, since, if you use software from lots of sources,
 you get lots of build systems.

For this I would suggest just a list of build_command/base_directory
pairs that the user can save, load and delete.


 The most important thing is that geany stops accessing GeanyProject
 struct directly. It should be the project that requests e.g. setting
 the base directory, not geany reading it from the project's data
 structures.

 I'm not quite sure what you mean, sure your plugin needs to be able to
 set the project base directory and API is needed for that.  So you
 will be requesting a change to the setting.  That anything in Geany
 that uses this info reads it from a structure called a GeanyProject
 seems irrelevant, it has to be somewhere :).

Well, I find the way things work now pretty hacky. Geany is interested
in only about two or

Re: [Geany-devel] Broken plugin autofools (Was: [ANNOUNCE] gproject - yet another geany project plugin)

On Wed, Jun 9, 2010 at 16:56, Chow Loong Jin hyper...@gmail.com wrote:
 On Wed, 9 Jun 2010 23:22:51 +1000
 Lex Trotman ele...@gmail.com wrote:

 Sigh, this isn't your fault, but I have problems with installing
 unknown software to system directories and plugins autofools is broken
 WRT installing to a non-standard prefix, waf build works if your
 plugin had a wscript.


Ah, I think I just misread this paragraph - there were really many
strange things in the geanyprj configure.ac (e.g. make distcheck
didn't work because of the hardcoded plugin directory) - that's why I
modified it quite heavily and installing to arbitrary prefix should
work (at least make distcheck, which tests this, works now).

Regards,

Jiri

 Please explain in further detail, so that it can be fixed. Thanks.

 --
 Kind regards,
 Chow Loong Jin

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin

On Wed, Jun 9, 2010 at 15:16, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
 Am 09.06.2010 13:06, schrieb Jiří Techet:

 It's true that I've used the workflow typical for a git project - from
 geany web page, which offers both git and SVN repository I assumed
 that I can chose either of them. If git is not supposed to be used,
 then it should be removed from there because this makes things
 confusing (or at least there should be a warning saying: Don't use
 the following git repository).



 Doesn't it clearly say that the git repo is a read-only mirror? And you can
 pull from it like normal, you just cannot push to it. I don't see why it
 shouldn't be used.

Yes, my fault. I should read more carefully before posting a rant.
Please forget my comments regarding git. (Switching to git would be
really nice though).

Jiri

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Git - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Wed, 9 Jun 2010 15:36:32 +0200
Jiří Techet tec...@gmail.com wrote:

  It's pretty clear from the GIT page that it's a read-only mirror. We
  don't have a writable GIT repo.
 
 
 OK, I've just noticed:
 
 Read-only mirrors of the SVN repositories, updated shortly after real
 commits in the SVN repository.
 
 But then I don't see the point of providing it if you cannot pull
 other people's clones of your repo.

So people can commit locally.

Regards,
Nick
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Non-filetype commands - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Wed, 9 Jun 2010 23:22:51 +1000
Lex Trotman ele...@gmail.com wrote:

 The update to the build system is to support running any commands,
 make,nmake,  waf, scons, cmake, ant, bjam, my_favourite_shell_script
 etc so the Non-filetype commands can't be called make commands
 anymore, and unfortunately the name Build has been appropriated for
 link, other suggestions welcome though, but there aren't many commonly
 understood terms about.

I agree that Non-filetype commands is not a great term. I would prefer
Global or General commands, even if less specific, it's fairly
clear and less tortuous.

Regards,
Nick
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] git - Re: [ANNOUNCE] gproject - yet another geany project plugin


Am 09.06.2010 18:09, schrieb Nick Treleaven:

On Wed, 09 Jun 2010 15:11:48 +0200
Thomas Martitzthomas.mart...@student.htw-berlin.de  wrote:

   

Am 09.06.2010 03:40, schrieb Lex Trotman:
 

Sure its easier if everyone is using git, but ATM this is an SVN project.

   

Although most, if not all, geany developers use git, don't they?
 

Do you mean git-svn? The Git repo is not writable.
   


Yes, to me it looks like the vast majority of contributors use git (and 
git svn to commit to the geany/geany-plugins svn). My perception may not 
be very accurate though.



I don't use Git for Geany, but wouldn't mind if everyone else wants to
switch to it.

   


Maybe it would be a good time to consider it in a serious manner. I 
would very much appreciate a switch to git :) OTOH my opinion doesn't 
matter very much, I guess.



Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] project build dialog - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Tue, 8 Jun 2010 18:59:35 +0200
Jiří Techet tec...@gmail.com wrote:

 To be honest, I find the new build dialog in 0.19 (and how it
 interacts with the session-project) pretty confusing - when you use it
 for the first time, you have no idea what it does (I had to look at
 the sources to be sure).

I assume you mean the 'Set Build Commands' dialog when you have a
project open. I think that may be a bug - IMO the Project Properties
Build tab should be shown instead. It is confusing ATM.

Regards,
Nick
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] switch dialog bug - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Wed, Jun 9, 2010 at 18:17, Nick Treleaven
nick.trelea...@btinternet.com wrote:
 On Wed, 9 Jun 2010 15:10:22 +0200
 Jiří Techet tec...@gmail.com wrote:

  BTW, why do you destroy the dialog instead of hiding it?

 It's just that I can write

 if (switch_dialog)

 instead of

 if (switch_dialog  GTK_WIDGET_VISIBLE(switch_dialog))

 but I can change that if your preference is different.

 When I wrote the code I assumed it would be faster to keep the dialog
 than reconstruct it each time, but I didn't do any benchmarking.

Optimizations like this would make sense only if you were trying to
open the window 1000-times per second, otherwise the performance
difference is absolutely unimportant.


 Another general issue is that doing more than one change in a
 'patch' makes it harder to review.

I wanted to make the code a bit more readable, that's why there are
more changes. For instance I renamed

switch_dialog_cancelled

to

switch_in_progress

(and inverted the boolean value) because the name was a bit confusing
(switch_dialog_cancelled is set to FALSE [read uncancelled, which is
a bit ugly] 600ms before the switch dialog actually appears). If you
wish, I can try to split it into more patches, I'm just afraid I
introduce some extra bugs on the way.

I've also noticed that I mix spaces and tabs for indents - I'll fix that.

Regards,

Jiri



 Regards,
 Nick
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] switch dialog bug - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Wed, 9 Jun 2010 18:48:51 +0200
Jiří Techet tec...@gmail.com wrote:

   BTW, why do you destroy the dialog instead of hiding it?
 
  It's just that I can write
 
  if (switch_dialog)
 
  instead of
 
  if (switch_dialog  GTK_WIDGET_VISIBLE(switch_dialog))
 
  but I can change that if your preference is different.
 
  When I wrote the code I assumed it would be faster to keep the dialog
  than reconstruct it each time, but I didn't do any benchmarking.
 
 Optimizations like this would make sense only if you were trying to
 open the window 1000-times per second, otherwise the performance
 difference is absolutely unimportant.

I suppose so in this case. For the Open dialog it may be important as
that can be slow to populate.

 
 
  Another general issue is that doing more than one change in a
  'patch' makes it harder to review.
 
 I wanted to make the code a bit more readable, that's why there are
 more changes. For instance I renamed
 
 switch_dialog_cancelled
 
 to
 
 switch_in_progress
 
 (and inverted the boolean value) because the name was a bit confusing
 (switch_dialog_cancelled is set to FALSE [read uncancelled, which is
 a bit ugly] 600ms before the switch dialog actually appears). If you
 wish, I can try to split it into more patches, I'm just afraid I
 introduce some extra bugs on the way.

OK, don't bother.

 
 I've also noticed that I mix spaces and tabs for indents - I'll fix that.

Regards,
Nick
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] [PATCH 1/3] Fix tab history switching

There is a 600ms interval in which the panel displaying the current file
name isn't displayed. If you switch tabs with a keybinding and do it
too quickly (press it twice in the 600ms period), the wrong file is
put on top of the stack. This patch fixes the problem

Signed-off-by: Jiří Techet tec...@gmail.com
---
 src/keybindings.c |   65 +++-
 1 files changed, 39 insertions(+), 26 deletions(-)

diff --git a/src/keybindings.c b/src/keybindings.c
index 8347cc1..c297589 100644
--- a/src/keybindings.c
+++ b/src/keybindings.c
@@ -71,7 +71,7 @@ const gsize MAX_MRU_DOCS = 20;
 static GQueue *mru_docs = NULL;
 static guint mru_pos = 0;
 
-static gboolean switch_dialog_cancelled = TRUE;
+static gboolean switch_in_progress = FALSE;
 static GtkWidget *switch_dialog = NULL;
 static GtkWidget *switch_dialog_label = NULL;
 
@@ -576,7 +576,7 @@ static void on_notebook_switch_page(void)
 
/* when closing current doc, old is NULL.
 * Don't add to the mru list when switch dialog is visible. */
-   if (old  switch_dialog_cancelled)
+   if (old  !switch_in_progress)
{
g_queue_remove(mru_docs, old);
g_queue_push_head(mru_docs, old);
@@ -879,7 +879,7 @@ static GtkWidget *create_dialog(void)
gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column);
 
text_renderer = gtk_cell_renderer_text_new();
-column = gtk_tree_view_column_new_with_attributes(NULL, text_renderer, 
text, 1, NULL);
+   column = gtk_tree_view_column_new_with_attributes(NULL, text_renderer, 
text, 1, NULL);
gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column);
 
fill_shortcut_labels_treeview(tree);
@@ -1751,12 +1751,15 @@ static void cb_func_switch_tabright(G_GNUC_UNUSED guint 
key_id)
 static gboolean on_key_release_event(GtkWidget *widget, GdkEventKey *ev, 
gpointer user_data)
 {
/* user may have rebound keybinding to a different modifier than Ctrl, 
so check all */
-   if (!switch_dialog_cancelled  is_modifier_key(ev-keyval))
+   if (switch_in_progress  is_modifier_key(ev-keyval))
{
-   switch_dialog_cancelled = TRUE;
+   switch_in_progress = FALSE;
 
-   if (switch_dialog  GTK_WIDGET_VISIBLE(switch_dialog))
-   gtk_widget_hide(switch_dialog);
+   if (switch_dialog)
+   {
+   gtk_widget_destroy(switch_dialog);
+   switch_dialog = NULL;
+   }
 
mru_pos = 0;
}
@@ -1809,23 +1812,27 @@ static GtkWidget *create_switch_dialog(void)
 }
 
 
-static gboolean on_switch_timeout(G_GNUC_UNUSED gpointer data)
+static void update_filename_label()
 {
-   if (switch_dialog_cancelled)
+   if (!switch_dialog)
{
-   return FALSE;
-   }
-   if (! switch_dialog || !GTK_WIDGET_VISIBLE(switch_dialog))
-   mru_pos = 2;/* skip past the previous document */
-   else
-   mru_pos += 1;
-
-   if (! switch_dialog)
switch_dialog = create_switch_dialog();
+   gtk_widget_show_all(switch_dialog);
+   }
 
geany_wrap_label_set_text(GTK_LABEL(switch_dialog_label),
DOC_FILENAME(document_get_current()));
-   gtk_widget_show_all(switch_dialog);
+}
+
+
+static gboolean on_switch_timeout(G_GNUC_UNUSED gpointer data)
+{
+   if (!switch_in_progress || switch_dialog)
+   {
+   return FALSE;
+   }
+
+   update_filename_label();
return FALSE;
 }
 
@@ -1848,19 +1855,25 @@ static void cb_func_switch_tablastused(G_GNUC_UNUSED 
guint key_id)
 
/* if there's a modifier key, we can switch back in MRU order each time 
unless
 * the key is released */
-   if (! switch_dialog_cancelled)
+   if (!switch_in_progress)
{
-   on_switch_timeout(NULL);/* update filename label */
-   }
-   else
-   if (keybindings_lookup_item(GEANY_KEY_GROUP_NOTEBOOK,
-   GEANY_KEYS_NOTEBOOK_SWITCHTABLASTUSED)-mods)
-   {
-   switch_dialog_cancelled = FALSE;
+   switch_in_progress = TRUE;
+
+   /* because switch_in_progress was not set when we called
+* gtk_notebook_set_current_page() above, this function 
inserted last_doc
+* into the queue = on mru_pos = 0 there is last_doc, on 
mru_pos = 1
+* there is the currently displayed doc, so we want to continue 
from 2
+* next time this function is called */
+   mru_pos = 2;
 
/* delay showing dialog to give user time to let go of any 
modifier keys */
g_timeout_add(600, on_switch_timeout, NULL);
}
+   else
+   {
+   update_filename_label();/* update filename label */
+   mru_pos += 1;
+   }
 }
 
 
-- 
1.7.0.4

[Geany-devel] Various geany fixes

The following patches fix some problems in geany. More details can be 
found in the description of the individual patches:

[PATCH 1/3] Fix tab history switching
[PATCH 2/3] Prevent -Wmissing-prototypes report warning when compiling a plugin
[PATCH 3/3] Add .gitignore

Regards,

Jiri
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] [PATCH 1/3] Add a signal that is emitted before build starts

Signed-off-by: Jiří Techet tec...@gmail.com
---
 doc/plugins.dox   |   12 
 src/build.c   |2 ++
 src/geanyobject.c |8 
 src/geanyobject.h |2 ++
 4 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/doc/plugins.dox b/doc/plugins.dox
index df156eb..ba3128a 100644
--- a/doc/plugins.dox
+++ b/doc/plugins.dox
@@ -253,6 +253,18 @@ PluginCallback plugin_callbacks[] =
  *  @param user_data user data.
  *  @endsignaldef
  *
+ *  @signaldef build-notify
+ *  @signalproto
+ *  void user_function(GObject *obj, gpointer user_data);
+ *  @endsignalproto
+ *  @signaldesc
+ *  Sent before build is started. Plugins can use this signal e.g. to save the 
opened documents
+ *  before the build starts.
+ *
+ *  @param obj a GeanyObject instance, should be ignored.
+ *  @param user_data user data.
+ *  @endsignaldef
+ *
  *  @signaldef update-editor-menu
  *  @signalproto
  *  void user_function(GObject *obj, const gchar *word, gint pos, 
GeanyDocument *doc,
diff --git a/src/build.c b/src/build.c
index 2baa035..66cb52c 100644
--- a/src/build.c
+++ b/src/build.c
@@ -1243,6 +1243,8 @@ static void on_build_menu_item(GtkWidget *w, gpointer 
user_data)
gint grp = GPOINTER_TO_GRP(user_data);
gint cmd = GPOINTER_TO_CMD(user_data);
 
+   g_signal_emit_by_name(geany_object, build-notify);
+
if (doc  doc-changed)
document_save_file(doc, FALSE);
if (grp == GEANY_GBG_NON_FT  cmd == GBO_TO_CMD(GEANY_GBO_CUSTOM))
diff --git a/src/geanyobject.c b/src/geanyobject.c
index 6e4d36e..41e6e16 100644
--- a/src/geanyobject.c
+++ b/src/geanyobject.c
@@ -292,6 +292,14 @@ static void create_signals(GObjectClass *g_object_class)
NULL, NULL,
g_cclosure_marshal_VOID__VOID,
G_TYPE_NONE, 0);
+   geany_object_signals[GCB_BUILD_NOTIFY] = g_signal_new (
+   build-notify,
+   G_OBJECT_CLASS_TYPE  (g_object_class),
+   G_SIGNAL_RUN_FIRST,
+   G_STRUCT_OFFSET (GeanyObjectClass, build_notify),
+   NULL, NULL,
+   g_cclosure_marshal_VOID__VOID,
+   G_TYPE_NONE, 0);
 
/* Core-only signals */
geany_object_signals[GCB_SAVE_SETTINGS] = g_signal_new (
diff --git a/src/geanyobject.h b/src/geanyobject.h
index 1bfc70f..aa04613 100644
--- a/src/geanyobject.h
+++ b/src/geanyobject.h
@@ -45,6 +45,7 @@ typedef enum
GCB_UPDATE_EDITOR_MENU,
GCB_EDITOR_NOTIFY,
GCB_GEANY_STARTUP_COMPLETE,
+   GCB_BUILD_NOTIFY,
GCB_SAVE_SETTINGS,
GCB_LOAD_SETTINGS,
GCB_MAX
@@ -90,6 +91,7 @@ struct _GeanyObjectClass
void (*update_editor_menu)(const gchar *word, gint click_pos, 
GeanyDocument *doc);
gboolean (*editor_notify)(GeanyEditor *editor, gpointer scnt);
void (*geany_startup_complete)(void);
+   void (*build_notify)(void);
void (*save_settings)(GKeyFile *keyfile);
void (*load_settings)(GKeyFile *keyfile);
 };
-- 
1.7.0.4

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] [PATCH 3/3] Open files from msgwindow even if find_in_files_dir is not set

It should be possible to open files from the msgwindow even if
find_in_files_dir is not set (when providing full path)

Signed-off-by: Jiří Techet tec...@gmail.com
---
 src/msgwindow.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/msgwindow.c b/src/msgwindow.c
index 302c82a..3b460ce 100644
--- a/src/msgwindow.c
+++ b/src/msgwindow.c
@@ -1042,7 +1042,7 @@ static void msgwin_parse_grep_line(const gchar *string, 
gchar **filename, gint *
*filename = NULL;
*line = -1;
 
-   if (string == NULL || msgwindow.find_in_files_dir == NULL)
+   if (string == NULL)
return;
 
/* conflict:3:conflicting types for `foo' */
@@ -1053,7 +1053,9 @@ static void msgwin_parse_grep_line(const gchar *string, 
gchar **filename, gint *
data.file_idx = 0;
 
parse_file_line(data, filename, line);
-   make_absolute(filename, msgwindow.find_in_files_dir);
+
+   if (msgwindow.find_in_files_dir != NULL)
+   make_absolute(filename, msgwindow.find_in_files_dir);
 }
 
 
-- 
1.7.0.4

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] [PATCH] Changebar port from codeblocks

This patch enables experimental scintilla changebar for geany. For testing only.

Signed-off-by: Jiří Techet tec...@gmail.com
---
 scintilla/CellBuffer.cxx  |  366 ++---
 scintilla/CellBuffer.h|   94 +-
 scintilla/Document.cxx|   48 +-
 scintilla/Document.h  |   13 ++-
 scintilla/Editor.cxx  |   76 -
 scintilla/RunStyles.cxx   |   42 +
 scintilla/RunStyles.h |6 +
 scintilla/include/Scintilla.h |   15 ++-
 scintilla/include/Scintilla.iface |9 +-
 src/editor.c  |2 +-
 src/highlighting.c|   21 ++-
 src/sciwrappers.c |   10 +-
 12 files changed, 649 insertions(+), 53 deletions(-)

diff --git a/scintilla/CellBuffer.cxx b/scintilla/CellBuffer.cxx
index 064ef1a..0a47249 100644
--- a/scintilla/CellBuffer.cxx
+++ b/scintilla/CellBuffer.cxx
@@ -21,6 +21,88 @@
 using namespace Scintilla;
 #endif
 
+/* CHANGEBAR begin */
+LineChanges::LineChanges() : collecting(0), edition(0) {
+}
+
+LineChanges::~LineChanges() {
+}
+
+void LineChanges::AdvanceEdition() {
+edition = (edition + 1) % 0x4000;
+}
+
+int LineChanges::GetEdition() const {
+return edition;
+}
+
+char *LineChanges::PersistantForm() const {
+if (collecting)
+return state.PersistantForm();
+else
+return 0;
+}
+
+void LineChanges::SetChanges(const char *changesState) {
+if (collecting  changesState) {
+state.FromPersistant(changesState);
+AdvanceEdition();
+}
+}
+
+void LineChanges::InsertText(int line, int edition, bool undoing) {
+if (collecting  !undoing) {
+int position = line;
+int fillLength = 1;
+if (state.FillRange(position, edition, fillLength)) {
+if (fillLength  0) {
+AdvanceEdition();
+}
+}
+}
+}
+
+void LineChanges::InsertLine(int line, int edition, bool undoing) {
+if (collecting  !undoing) {
+state.InsertSpace(line, 1);
+int linePosition = line;
+int fillLength = 1;
+if (state.FillRange(linePosition, edition, fillLength))
+AdvanceEdition();
+}
+}
+
+void LineChanges::RemoveLine(int line, bool undoing) {
+if (collecting  !undoing) {
+state.DeleteRange(line, 1);
+AdvanceEdition();
+}
+}
+
+void LineChanges::EnableChangeCollection(bool collecting_, int lines) {
+collecting = collecting_;
+if (collecting) {
+state.InsertSpace(0, lines);
+}
+}
+
+void LineChanges::ClearChanged() {
+if (collecting) {
+int position = 0;
+int length = state.Length();
+if (state.FillRange(position, 0, length))
+AdvanceEdition();
+}
+}
+
+int LineChanges::GetChanged(int line) const {
+if (collecting) {
+return state.ValueAt(line);
+}
+return 0;
+}
+/* CHANGEBAR end */
+
 LineVector::LineVector() : starts(256), perLine(0) {
Init();
 }
@@ -40,33 +122,78 @@ void LineVector::SetPerLine(PerLine *pl) {
perLine = pl;
 }
 
-void LineVector::InsertText(int line, int delta) {
+/* CHANGEBAR begin */
+void LineVector::InsertText(int line, int delta, int edition, bool undoing) {
+/* CHANGEBAR end */
starts.InsertText(line, delta);
+/* CHANGEBAR begin */
+changes.InsertText(line, edition, undoing);
+/* CHANGEBAR end */
 }
 
-void LineVector::InsertLine(int line, int position, bool lineStart) {
+/* CHANGEBAR begin */
+void LineVector::InsertLine(int line, int position, bool lineStart, int 
edition, bool undoing) {
+/* CHANGEBAR end */
starts.InsertPartition(line, position);
if (perLine) {
if ((line  0)  lineStart)
line--;
perLine-InsertLine(line);
}
+/* CHANGEBAR begin */
+changes.InsertLine(line, edition, undoing);
+/* CHANGEBAR end */
 }
 
 void LineVector::SetLineStart(int line, int position) {
starts.SetPartitionStartPosition(line, position);
 }
 
-void LineVector::RemoveLine(int line) {
+/* CHANGEBAR begin */
+void LineVector::RemoveLine(int line, bool undoing) {
+/* CHANGEBAR end */
starts.RemovePartition(line);
if (perLine) {
perLine-RemoveLine(line);
}
+/* CHANGEBAR begin */
+changes.RemoveLine(line, undoing);
+/* CHANGEBAR end */
 }
 
 int LineVector::LineFromPosition(int pos) const {
return starts.PartitionFromPosition(pos);
 }
+/* CHANGEBAR begin */
+void LineVector::EnableChangeCollection(bool changesCollecting_) {
+DeleteChangeCollection();
+changes.EnableChangeCollection(changesCollecting_, Lines());
+}
+
+void LineVector::DeleteChangeCollection() {
+changes.ClearChanged();
+}
+
+int LineVector::GetChanged(int line) const {
+return changes.GetChanged(line);
+}
+
+int LineVector::GetChangesEdition() const {
+return changes.GetEdition();
+}
+
+void LineVector::SetSavePoint() {
+

Re: [Geany-devel] project build dialog - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Wed, Jun 9, 2010 at 18:15, Nick Treleaven
nick.trelea...@btinternet.com wrote:
 On Tue, 8 Jun 2010 18:59:35 +0200
 Jiří Techet tec...@gmail.com wrote:

 To be honest, I find the new build dialog in 0.19 (and how it
 interacts with the session-project) pretty confusing - when you use it
 for the first time, you have no idea what it does (I had to look at
 the sources to be sure).

 I assume you mean the 'Set Build Commands' dialog when you have a
 project open. I think that may be a bug - IMO the Project Properties
 Build tab should be shown instead. It is confusing ATM.


There are several confusing things:

1. The first section in the dialog (filetype commands) depends on
the currently opened document. This wasn't clear to me at all. First I
thought that this was static. Then I noticed that it changes but I was
wondering how you set the file type. I would prefer if there was a
combo box where the item gets automatically selected based on the
current file, but which you can also manually change. This will give
people some indication that the first group is dynamic.

2. What you say - when the project is open, it's not clear whether you
are editing global options or project ones. IMO by build-set build
commands you should always set the global options and in project
properties the project options. Things get confusing when you start
changing semantics of menu items based on whether the project is open
or not.

3. The popup dialog for make custom target should be more flexible,
not hardcoded for item 2. I think there should be a new variable, e.g.
%t, which, when found inside command, causes that the window appears
and then substitutes %t with what the user specifies. This will make
it usable for other commands too.

4. non-filetype commands deserves a better name - I quite like your
general commands (global could be confused in the context of
setting global/per-project options). And I would also put them first
in the dialog - starting from general options to more specific options
(which means that execute command should come second). I had a problem
that somehow automatically I started editing the commands in the first
group (filetype) even though I wanted to edit the second group
(non-filetype).

OK, I wanted to write more things I dislike but after spending one
hour looking at the dialog I think I start understanding what's behind
it. There really needs to be a clear indication that the first group
is dynamic and I think the combobox is a good way to do that.

Regards,

Jiri
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] multiple instance save-settings - Re: Race condition when saving geany.conf


Am 04.06.2010 03:27, schrieb Lex Trotman:

Yep, and I wasn't interested in multi instance either until I realised
that it allows me to have Geany on multiple screens, I do  lot of
switching back and forth between .hpp and .cpp files so showing them
both would be a*big*  help.


How about a proper split edit plugin then? :)

Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] multiple instance save-settings - Re: Race condition when saving geany.conf

On 10 June 2010 07:50, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
 Am 04.06.2010 03:27, schrieb Lex Trotman:

 Yep, and I wasn't interested in multi instance either until I realised
 that it allows me to have Geany on multiple screens, I do  lot of
 switching back and forth between .hpp and .cpp files so showing them
 both would be a *big* help.

 How about a proper split edit plugin then? :)

Multi window editing is the right way to do it, but...

Unfortunately scintilla doesn't have a model view paradigm so you have
to replay all changes if the same file is visible in two windows.
Recent scintilla discussions were not encouraging on the effort
required.

Also most of Geany isn't reentrant (eg much of it depends on a global
view of current document, project, etc) so there will need to be
changes to fix that and to support multiple projects.

 But of course don't let that stop you :)

Cheers
Lex

 Best regards.

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] project build dialog - Re: [ANNOUNCE] gproject - yet another geany project plugin

On 10 June 2010 02:15, Nick Treleaven nick.trelea...@btinternet.com wrote:
 On Tue, 8 Jun 2010 18:59:35 +0200
 Jiří Techet tec...@gmail.com wrote:

 To be honest, I find the new build dialog in 0.19 (and how it
 interacts with the session-project) pretty confusing - when you use it
 for the first time, you have no idea what it does (I had to look at
 the sources to be sure).

 I assume you mean the 'Set Build Commands' dialog when you have a
 project open. I think that may be a bug - IMO the Project Properties
 Build tab should be shown instead. It is confusing ATM.

No it shouldn't open the project tab, the project menu does that.  If
you have a project open there are *two* places where the commands are
edited, one for those defined in the project and one for those not
defined in the project which still get used if no project command
overrides them.

When you create a project you don't have to copy all the commands into
the project, you still get the normal ones until you define one in the
project which overrides the normal one.

Yes I realised a while ago it can be confusing, thats part of why I
want to combine both dialogs into one in v2.0.

Cheers
Lex


 Regards,
 Nick
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] project build dialog - Re: [ANNOUNCE] gproject - yet another geany project plugin

On 10 June 2010 07:02, Jiří Techet tec...@gmail.com wrote:
 On Wed, Jun 9, 2010 at 18:15, Nick Treleaven
 nick.trelea...@btinternet.com wrote:
 On Tue, 8 Jun 2010 18:59:35 +0200
 Jiří Techet tec...@gmail.com wrote:

 To be honest, I find the new build dialog in 0.19 (and how it
 interacts with the session-project) pretty confusing - when you use it
 for the first time, you have no idea what it does (I had to look at
 the sources to be sure).

Any suggestions on how the manual could be improved, it should be
RTFM, not RTFS :)


 I assume you mean the 'Set Build Commands' dialog when you have a
 project open. I think that may be a bug - IMO the Project Properties
 Build tab should be shown instead. It is confusing ATM.


 There are several confusing things:

 1. The first section in the dialog (filetype commands) depends on
 the currently opened document. This wasn't clear to me at all. First I
 thought that this was static. Then I noticed that it changes but I was
 wondering how you set the file type. I would prefer if there was a
 combo box where the item gets automatically selected based on the
 current file, but which you can also manually change. This will give
 people some indication that the first group is dynamic.

 Its how Geany has already worked, the commands changed with current filetype.

Well it does actually say filetype xxx commands, but your idea isn't
impossible either, but see questions below.


 2. What you say - when the project is open, it's not clear whether you
 are editing global options or project ones. IMO by build-set build
 commands you should always set the global options and in project
 properties the project options.

Thats what should happen, if you think it isn't its a bug, let me know

 Things get confusing when you start
 changing semantics of menu items based on whether the project is open
 or not.

 3. The popup dialog for make custom target should be more flexible,
 not hardcoded for item 2. I think there should be a new variable, e.g.
 %t, which, when found inside command, causes that the window appears
 and then substitutes %t with what the user specifies. This will make
 it usable for other commands too.

Agreed, already planned to be added for v2, %c{message to show on
popup} gets substituted by user input (I used c for custom not t for
target :)


 4. non-filetype commands deserves a better name - I quite like your
 general commands (global could be confused in the context of
 setting global/per-project options). And I would also put them first
 in the dialog - starting from general options to more specific options
 (which means that execute command should come second). I had a problem
 that somehow automatically I started editing the commands in the first
 group (filetype) even though I wanted to edit the second group
 (non-filetype).

Well the order has the 0.18 items first for backward compatibility,
but I agree that the order isn't optimal so I planned to make it
configurable (I actually want some more groups) but I havn't got a
good solution for the headings (other than fixed strings, which would
let you change non-filetype to whatever you want :)  Personally I
think general is a bit too, well, general, to be meaningful


 OK, I wanted to write more things I dislike but after spending one
 hour looking at the dialog I think I start understanding what's behind
 it. There really needs to be a clear indication that the first group
 is dynamic and I think the combobox is a good way to do that.

But what do you do if the user changes the filetype?  Do you forget
any changes so far? Or you have to save them in temporary storage
until the user selects apply or cancel and hope that the user meant to
change both filetypes rather than starting to change one, discovering
that they had the wrong type (because of the wrong current doc) and
changed to the one they want.  Thats why both dialogs are modal, so
the current document can't be changed, so this section doesn't change.

Cheers
Lex

 Regards,

 Jiri
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] project build dialog - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Thu, Jun 10, 2010 at 00:52, Lex Trotman ele...@gmail.com wrote:
 On 10 June 2010 02:15, Nick Treleaven nick.trelea...@btinternet.com wrote:
 On Tue, 8 Jun 2010 18:59:35 +0200
 Jiří Techet tec...@gmail.com wrote:

 To be honest, I find the new build dialog in 0.19 (and how it
 interacts with the session-project) pretty confusing - when you use it
 for the first time, you have no idea what it does (I had to look at
 the sources to be sure).

 I assume you mean the 'Set Build Commands' dialog when you have a
 project open. I think that may be a bug - IMO the Project Properties
 Build tab should be shown instead. It is confusing ATM.

 No it shouldn't open the project tab, the project menu does that.  If
 you have a project open there are *two* places where the commands are
 edited, one for those defined in the project and one for those not
 defined in the project which still get used if no project command
 overrides them.

 When you create a project you don't have to copy all the commands into
 the project, you still get the normal ones until you define one in the
 project which overrides the normal one.

 Yes I realised a while ago it can be confusing, thats part of why I
 want to combine both dialogs into one in v2.0.


Yes, it's pretty confusing. Once you create a project you don't expect
that what you see in the build tab changes based on what change you
make in the global settings (until you modify the commands in the
project for the first time). This makes the project totally unportable
because it depends on the global settings of the current instance of
geany. So if I move the project from my home computer to work, things
just can stop working because I have different global settings there.

What I would suggest is that upon project creation you make a complete
copy of the global settings and since then the two are edited
independently. Otherwise all the settings is a total mess.

Cheers,

Jiri

 Cheers
 Lex


 Regards,
 Nick
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [PATCH] Changebar port from codeblocks

Hi Jiri,

I'd recommend that you send your patches as attachments, putting them
in the mail body can get them wrapped.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] project build dialog - Re: [ANNOUNCE] gproject - yet another geany project plugin

On Thu, Jun 10, 2010 at 01:25, Lex Trotman ele...@gmail.com wrote:
 On 10 June 2010 07:02, Jiří Techet tec...@gmail.com wrote:
 On Wed, Jun 9, 2010 at 18:15, Nick Treleaven
 nick.trelea...@btinternet.com wrote:
 On Tue, 8 Jun 2010 18:59:35 +0200
 Jiří Techet tec...@gmail.com wrote:

 To be honest, I find the new build dialog in 0.19 (and how it
 interacts with the session-project) pretty confusing - when you use it
 for the first time, you have no idea what it does (I had to look at
 the sources to be sure).

 Any suggestions on how the manual could be improved, it should be
 RTFM, not RTFS :)


 I assume you mean the 'Set Build Commands' dialog when you have a
 project open. I think that may be a bug - IMO the Project Properties
 Build tab should be shown instead. It is confusing ATM.


 There are several confusing things:

 1. The first section in the dialog (filetype commands) depends on
 the currently opened document. This wasn't clear to me at all. First I
 thought that this was static. Then I noticed that it changes but I was
 wondering how you set the file type. I would prefer if there was a
 combo box where the item gets automatically selected based on the
 current file, but which you can also manually change. This will give
 people some indication that the first group is dynamic.

  Its how Geany has already worked, the commands changed with current filetype.

 Well it does actually say filetype xxx commands, but your idea isn't
 impossible either, but see questions below.

I know, but it's not clear it's dynamic. Also if you want to change
the commands for N file types you have to locate N times the file with
the right extension and then open the dialog - not much fun.



 2. What you say - when the project is open, it's not clear whether you
 are editing global options or project ones. IMO by build-set build
 commands you should always set the global options and in project
 properties the project options.

 Thats what should happen, if you think it isn't its a bug, let me know

Well, that's what I was talking about in the other email - if you
don't override a command in the project, it appears as if you were
editing both the global options and the project options simultaneously
- that's really way too confusing.


  Things get confusing when you start
 changing semantics of menu items based on whether the project is open
 or not.

 3. The popup dialog for make custom target should be more flexible,
 not hardcoded for item 2. I think there should be a new variable, e.g.
 %t, which, when found inside command, causes that the window appears
 and then substitutes %t with what the user specifies. This will make
 it usable for other commands too.

 Agreed, already planned to be added for v2, %c{message to show on
 popup} gets substituted by user input (I used c for custom not t for
 target :)


 4. non-filetype commands deserves a better name - I quite like your
 general commands (global could be confused in the context of
 setting global/per-project options). And I would also put them first
 in the dialog - starting from general options to more specific options
 (which means that execute command should come second). I had a problem
 that somehow automatically I started editing the commands in the first
 group (filetype) even though I wanted to edit the second group
 (non-filetype).

 Well the order has the 0.18 items first for backward compatibility,
 but I agree that the order isn't optimal so I planned to make it
 configurable (I actually want some more groups) but I havn't got a
 good solution for the headings (other than fixed strings, which would
 let you change non-filetype to whatever you want :)  Personally I
 think general is a bit too, well, general, to be meaningful

If I can ask for something, then please don't add any extra options to
the dialog. It's already confusing enough ;-).

I know general is too general but non-filetype is so specific that
nobody can imagine anything concrete under it. Unfortunately I'm
pretty bad at naming things in a good way so I won't help much here.



 OK, I wanted to write more things I dislike but after spending one
 hour looking at the dialog I think I start understanding what's behind
 it. There really needs to be a clear indication that the first group
 is dynamic and I think the combobox is a good way to do that.

 But what do you do if the user changes the filetype?  Do you forget
 any changes so far? Or you have to save them in temporary storage
 until the user selects apply or cancel and hope that the user meant to
 change both filetypes rather than starting to change one, discovering
 that they had the wrong type (because of the wrong current doc) and
 changed to the one they want.  Thats why both dialogs are modal, so
 the current document can't be changed, so this section doesn't change.

Good point. I would probably pop up a question dialog asking whether
the changed settings should be saved when the user switches between
filetypes and makes

Re: [Geany-devel] git - Re: [ANNOUNCE] gproject - yet another geany project plugin

On 10 June 2010 02:57, Chow Loong Jin hyper...@gmail.com wrote:
 On Wed, 09 Jun 2010 18:15:02 +0200
 Thomas Martitz thomas.mart...@student.htw-berlin.de wrote:

 Am 09.06.2010 18:09, schrieb Nick Treleaven:
  On Wed, 09 Jun 2010 15:11:48 +0200
  Thomas Martitzthomas.mart...@student.htw-berlin.de  wrote:
 
      Am 09.06.2010 03:40, schrieb Lex Trotman:
        Sure its easier if everyone is using git, but ATM this is an SVN
        project.
 
          Although most, if not all, geany developers use git, don't 
  they?
        Do you mean git-svn? The Git repo is not writable.
     Yes, to me it looks like the vast majority of contributors use git (and
  git svn to commit to the geany/geany-plugins svn). My perception may not be
  very accurate though.

  I don't use Git for Geany, but wouldn't mind if everyone else wants to
  switch to it.
 
     Maybe it would be a good time to consider it in a serious manner. I
  would very much appreciate a switch to git :) OTOH my opinion doesn't
  matter very much, I guess.

 If Geany switches, I'd love for geany-plugins to switch as well.


The switch to a dvcs would be useful since local version control would
then be integrated with the main vcs (if you wanted it to be).

If Geany switches then the process needs to be decided and promulgated first.

Can personal branches be hosted on your host or only branches created
by you, allows sm, the new unstable and bs to operate mostly like now,
separate but globally visible. Who is your host?

Who has permissions to do what, Git can have very fine control over
who can do what.

What workflow are you going to follow?  eg stable branch only releases
are committed to, unstable that reviewed changes and patches are
committed to? or what?

Having both SVN and Git committable is difficult so everyone would
have to switch.

As usual the problems are non-technical ones :)

Cheers
Lex


 --
 Kind regards,
 Chow Loong Jin

 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Non-filetype commands - Re: [ANNOUNCE] gproject - yet another geany project plugin

On 10 June 2010 02:04, Nick Treleaven nick.trelea...@btinternet.com wrote:
 On Wed, 9 Jun 2010 23:22:51 +1000
 Lex Trotman ele...@gmail.com wrote:

 The update to the build system is to support running any commands,
 make,nmake,  waf, scons, cmake, ant, bjam, my_favourite_shell_script
 etc so the Non-filetype commands can't be called make commands
 anymore, and unfortunately the name Build has been appropriated for
 link, other suggestions welcome though, but there aren't many commonly
 understood terms about.

 I agree that Non-filetype commands is not a great term. I would prefer
 Global or General commands, even if less specific, it's fairly
 clear and less tortuous.

Well global, to me, means the system files, which it does not change.
I thought General was too general, but if most agree that it makes
sense I am happy to change it.

Cheers
Lex


 Regards,
 Nick
 ___
 Geany-devel mailing list
 Geany-devel@uvena.de
 http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin

Hi again,

snip

 Sigh, this isn't your fault, but I have problems with installing
 unknown software to system directories and plugins autofools is broken
 WRT installing to a non-standard prefix, waf build works if your
 plugin had a wscript.


 And I dislike using non-standard solutions (as standard I consider
 autotools, despite all its drawbacks), so we have a nice deadlock here
 :-).

Your prerogative, but it means that I won't test your plugin.



 In another post on this thread you complain about IDEs that limit how
 projects work (agree completely BTW), but you would restrict Geany to
 only one build tool? ;-)

 Not only one, but only _the_ one the user provides. The dialog should
 look this way:

 Build command: edit_box
 Base directory: edit_box

U, thats what the command and working directory columns are


 so if I provide something like

 Build command: make
 Base directory: /home/techet/projects/geany

 it would run:

 cd /home/techet/projects/geany

Unix only, not portable, thats why the working directory isn't done that way.

 make

So you don't want make object or make target???

If you do have them then you need to be able to define where the
arguments and options go on each of these build commands.

Builders other than make require options and arguments in different
orders, thats what started the whole build system update in the first
place, the arguments Geany 0.18 pasted didn't work for some builders.

So the dialog allows the whole command to be configured, and since you
are not running make any more, it allows the menu label to be changed
to say what you are doing.


 (+ there should be a possibility to use the variables like %e, %f, ...)


 The update to the build system is to support running any commands,
 make,nmake,  waf, scons, cmake, ant, bjam, my_favourite_shell_script

 But the current build system (and the one present in 0.18) already
 _can_ do that, see above. And yes, at work I use my own script that
 based on the current file detects the current subsystem, runs other
 necessary scripts and starts the build of the subsystem. Why do we
 need the special cases as above?

See above.


 etc so the Non-filetype commands can't be called make commands
 anymore, and unfortunately the name Build has been appropriated for
 link, other suggestions welcome though, but there aren't many commonly
 understood terms about.

 It is also to allow the commands to be configured differently for
 different projects, since, if you use software from lots of sources,
 you get lots of build systems.

 For this I would suggest just a list of build_command/base_directory
 pairs that the user can save, load and delete.


Thats exactly what the project preferences build tab is.


 At university I was using SciTE as
 the editor for everything and it was just fine (yes, and SciTE calls
 the thing session ;-). But for projects with thousands of source
 files and hundreds of directories it's just no fun, believe me.

 I can believe its not good at this. Is anything?

 geany + gproject ;-)

As we say here, this has been a paid political advertisement :-)


 What you need is to be able to quickly navigate between the files. For
 this reason I had to fix the tab switching bug and introduced
 header/source swapping.

 You need to be able to filter out as many extra files as possible
 (that's why only the files that match the pattern you provide are
 included in the project).

 You need fast searches in files. grep is pretty fast when you restrict
 it only to the source files. So the plugin uses the patterns you
 provide as a definition of the files belonging to the project and
 automatically adds the restrictions as an extra potion in the find in
 files dialog; e.g.

 --include=*.c --include=*.h

 The first search is always slow, because the project files have to be
 read from the disk. But the subsequent searches are pretty fast
 because the files are already cached by the OS. So searching for
 torvalds in the whole linux tree (only *.c and *.h files) takes just
 about 3 seconds.

 Then you need to be able to quickly find a file by name. In my plugin
 you can use an arbitrary glob pattern for that (the leading and
 trailing * are inserted for you so you just need to type a part of the
 file name).

 Also building the file tree should be as fast as possible. Again, this
 is relatively slow when you open the project for the first time, but
 any subsequent project opening is very fast (2 seconds for linux
 kernel, from this only about 0.5 second creating the file tree).

 Also there is also a feature that the selected file in the file tree
 automatically follows the currently opened file - so the tree
 automatically expands and locates the current file for you - this
 simplifies locating the current subsystem.

 And most importantly, the editor should be relatively sane and not to
 try to reparse the whole project every time you edit or save something
 - 100pct CPU usage is guaranteed all the time in this

Re: [Geany-devel] project build dialog - Re: [ANNOUNCE] gproject - yet another geany project plugin

Hi,

Note to self, read the whole thread before replying to any :-) see my
other reply plus below.


 Yes I realised a while ago it can be confusing, thats part of why I
 want to combine both dialogs into one in v2.0.


 Yes, it's pretty confusing. Once you create a project you don't expect
 that what you see in the build tab changes based on what change you
 make in the global settings (until you modify the commands in the
 project for the first time). This makes the project totally unportable
 because it depends on the global settings of the current instance of
 geany. So if I move the project from my home computer to work, things
 just can stop working because I have different global settings there.

 What I would suggest is that upon project creation you make a complete
 copy

Thats just what I didn't want to do, remember there are filetype
commands and execute commands too makes each project copy big.

 of the global settings and since then the two are edited
 independently. Otherwise all the settings is a total mess.

And you program in C++ !! I'd have thought overriding some entries
only would be easy to understand :-)

Seriously, yes the whole thing should be in one dialog so that you can
see what overrides what and edit the one you want, thats part of v2.0.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Broken plugin autofools (Was: [ANNOUNCE] gproject - yet another geany project plugin)