Re: [Geany-devel] Git switch

2010-06-14 Thread Frank Lanitz
On Sun, 13 Jun 2010 23:47:37 +0200, Jiří Techet tec...@gmail.com
wrote:
 On Sun, Jun 13, 2010 at 17:38, Chow Loong Jin hyper...@gmail.com wrote:
 Bandwidth issues. If your connection to your git host sucks
 (sourceforge.net particularly sucks from Asian countries) then you want
 
 Sourceforge tends to have bad days here too (Czech Republic) - I
 suspect it's a global problem. 

Yepp, its well known that sf is not always the fastest plattform.
Unfortunately. 

Cheers, 
Frank 

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


Re: [Geany-devel] Git switch

2010-06-14 Thread Lex Trotman
On 14 June 2010 15:41, Thomas Martitz
thomas.mart...@student.htw-berlin.de wrote:
 Am 14.06.2010 03:58, schrieb Lex Trotman:

 I guess we should also consider that no matter how easy we think it
 will be there will probably be some disruption during the changeover
 so it should be now (immediately after a release) or not until the
 next release, which I think is probably better so that the hosting and
 workflow issues can be worked through some more.  Jiri, hold that
 Gitorious project to keep out cyber squatters.



 0.19 is just out, why wait for the next release? 0.19 is so recent, waiting
 for the next release will have no advantage (because we are in the same
 situation then as today). Can you elaborate that please?

Hi Thomas,

Sure, multi part answer.

1. Yes you are right, it doesn't have to be *immediately* after a
release, just before the heavy activity approaching a release.

2. What might be better if there is some delay?

Because I don't think we have got a good handle on host, bug tracker
etc.  The responses were far from unanimous for a switch to Git,
though no one was heavily against it.

As far as I can tell Jiri is the only one who has responded who has
actual experience running a Git project and that is only on Gitoroius.
 So I'd ask:

* Does anyone else run a Git project, which host and whats the experience?
* How many people contribute to one, and what hosting service do they
use and what is the experience, is performance consistent and better
than Sourceforge SVN, all around the world?
* And does anyone have experience using any other DVCS and hosting
service that would make them recommend it, or recommend against it?
* should the bug tracker be moved?  Can it be done without losing anything?

There are rather a lot of options listed here:
https://git.wiki.kernel.org/index.php/GitHosting  Has anyone used any?

The important things we need to know about a hosting service are:
* likely stability, some have gone offline during the GFC, but this is
hard to judge
* performance for a good range of users in a good range of locations
* reliability, low downtime
* features, hosting clones, bug tracking ?

My answer is that I only run Git locally, so I cannot add any information.

Who can?  I'm happy to collate the replies.

So far, Jiri I take it you are happy with Gitorious, it has the
features, but some don't like its style, does anyone have performance
problems with it? Whats its reliability like?

For Github, some really don't like its style :-)

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] Git switch

2010-06-14 Thread Thomas Martitz
I cannot answer any of the questions because I also have no experience 
in running a git project.


But what I know is that we are actually less depending on a hoster. 
Because of git's DVCS nature, everyone has the complete repo locally and 
can work offline with it. Git hosting is something for convinience (i.e. 
web interface for source browsing). We wouldn't actually *need* a hoster 
at all, but of course it would be nice (with hosting, cloning other 
people's repos is simplified extremely).


This is one of the strong points of git. Even if the hoster is not very 
dependable, since the actual repo is on everyone's system, the hoster 
could be dead for a few days or we could switch the hoster easily 
without losing anything.


Best regards.

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


Re: [Geany-devel] Git switch

2010-06-14 Thread Chow Loong Jin
On Mon, 14 Jun 2010 17:47:57 +1000
Lex Trotman ele...@gmail.com wrote:

 On 14 June 2010 15:41, Thomas Martitz
 thomas.mart...@student.htw-berlin.de wrote:
  Am 14.06.2010 03:58, schrieb Lex Trotman:
 
  I guess we should also consider that no matter how easy we think it
  will be there will probably be some disruption during the
  changeover so it should be now (immediately after a release) or
  not until the next release, which I think is probably better so
  that the hosting and workflow issues can be worked through some
  more.  Jiri, hold that Gitorious project to keep out cyber
  squatters.
 
 
 
  0.19 is just out, why wait for the next release? 0.19 is so recent,
  waiting for the next release will have no advantage (because we are
  in the same situation then as today). Can you elaborate that please?
 
 Hi Thomas,
 
 Sure, multi part answer.
 
 1. Yes you are right, it doesn't have to be *immediately* after a
 release, just before the heavy activity approaching a release.
 
 2. What might be better if there is some delay?
 
 Because I don't think we have got a good handle on host, bug tracker
 etc.  The responses were far from unanimous for a switch to Git,
 though no one was heavily against it.
 
 As far as I can tell Jiri is the only one who has responded who has
 actual experience running a Git project and that is only on Gitoroius.
  So I'd ask:
 
 * Does anyone else run a Git project, which host and whats the
 experience?

I run a git project on github.com and gitorious.org, but since it's a
single-man project that isn't ready for public consumption, it's just a
backup of my git repository in the event that all my local copies of my
git repository disappear at the same time.

I have push access to http://gitorious.org/banshee-community-extensions
and I have nothing bad to say about it. I don't use the web interface
much, honestly speaking, except for linking the commit hash of a
certain bugfix to a bug report. I just mostly fetch, pull, and push.

I think something that might be worth noting is that we should pick a
host that has support http:// fetching, and even better, smart http://.

 * How many people contribute to one, and what hosting service do they
 use and what is the experience, is performance consistent and better
 than Sourceforge SVN, all around the world?

In Singapore and Malaysia, gitorious.org and github.com have been
extremely stable and fast, unlike sourceforge.net.

 * And does anyone have experience using any other DVCS and hosting
 service that would make them recommend it, or recommend against it?

I've used bzr before, But I would recommend against it, as bzr still
seems to have the occasional repository format migration which, if
things go wrong, can cause your repositories to suddenly become
unmergeable. Also, it's one branch per repository, which leads to as
many copies of the project as you have branches (i.e. not so cheap
branching).

 * should the bug tracker be moved?  Can it be done without losing
 anything?

I'm against any bug tracker that lacks either a read/writeable web
interface or a read/writeable e-mail interface. (I like
launchpad.net's bug tracker, but that's just me.)

 
 There are rather a lot of options listed here:
 https://git.wiki.kernel.org/index.php/GitHosting  Has anyone used any?
 
 The important things we need to know about a hosting service are:
 * likely stability, some have gone offline during the GFC, but this is
 hard to judge
 * performance for a good range of users in a good range of locations
 * reliability, low downtime
 * features, hosting clones, bug tracking ?
 
 My answer is that I only run Git locally, so I cannot add any
 information.
 
 Who can?  I'm happy to collate the replies.
 
 So far, Jiri I take it you are happy with Gitorious, it has the
 features, but some don't like its style, does anyone have performance
 problems with it? Whats its reliability like?
 
 For Github, some really don't like its style :-)

I don't really care about whichever hosting service we use, as long as
it has:
 * A good and stable internet connection to various places around the
   world (I particularly care about Malaysia and Singapore).
 * A fairly usable web interface that supports showing logs, browsing
   the tree, showing diffs for commits. (github.com and gitorious.org
   satisfy me in this aspect).
 * git:// read-only access, git+ssh:// push access, http:// read-only
   access. http:// push access would be a plus, though.


P.S. What's GFC?

-- 
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] Git switch

2010-06-14 Thread Lex Trotman
 I think something that might be worth noting is that we should pick a
 host that has support http:// fetching, and even better, smart http://.


Good point

 * How many people contribute to one, and what hosting service do they
 use and what is the experience, is performance consistent and better
 than Sourceforge SVN, all around the world?

 In Singapore and Malaysia, gitorious.org and github.com have been
 extremely stable and fast, unlike sourceforge.net.

 * And does anyone have experience using any other DVCS and hosting
 service that would make them recommend it, or recommend against it?

 I've used bzr before, But I would recommend against it, as bzr still
 seems to have the occasional repository format migration which, if
 things go wrong, can cause your repositories to suddenly become
 unmergeable. Also, it's one branch per repository, which leads to as
 many copies of the project as you have branches (i.e. not so cheap
 branching).

 * should the bug tracker be moved?  Can it be done without losing
 anything?

 I'm against any bug tracker that lacks either a read/writeable web
 interface or a read/writeable e-mail interface. (I like
 launchpad.net's bug tracker, but that's just me.)


 There are rather a lot of options listed here:
 https://git.wiki.kernel.org/index.php/GitHosting  Has anyone used any?

 The important things we need to know about a hosting service are:
 * likely stability, some have gone offline during the GFC, but this is
 hard to judge
 * performance for a good range of users in a good range of locations
 * reliability, low downtime
 * features, hosting clones, bug tracking ?

 My answer is that I only run Git locally, so I cannot add any
 information.

 Who can?  I'm happy to collate the replies.

 So far, Jiri I take it you are happy with Gitorious, it has the
 features, but some don't like its style, does anyone have performance
 problems with it? Whats its reliability like?

 For Github, some really don't like its style :-)

 I don't really care about whichever hosting service we use, as long as
 it has:
  * A good and stable internet connection to various places around the
   world (I particularly care about Malaysia and Singapore).
  * A fairly usable web interface that supports showing logs, browsing
   the tree, showing diffs for commits. (github.com and gitorious.org
   satisfy me in this aspect).
  * git:// read-only access, git+ssh:// push access, http:// read-only
   access. http:// push access would be a plus, though.


 P.S. What's GFC?

Oops sorry, non-computer acronym, global financial crisis


 --
 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] Git switch

2010-06-14 Thread Jiří Techet
On Mon, Jun 14, 2010 at 09:47, Lex Trotman ele...@gmail.com wrote:
 On 14 June 2010 15:41, Thomas Martitz
 thomas.mart...@student.htw-berlin.de wrote:
 Am 14.06.2010 03:58, schrieb Lex Trotman:

 I guess we should also consider that no matter how easy we think it
 will be there will probably be some disruption during the changeover
 so it should be now (immediately after a release) or not until the
 next release, which I think is probably better so that the hosting and
 workflow issues can be worked through some more.  Jiri, hold that
 Gitorious project to keep out cyber squatters.



 0.19 is just out, why wait for the next release? 0.19 is so recent, waiting
 for the next release will have no advantage (because we are in the same
 situation then as today). Can you elaborate that please?

 Hi Thomas,

 Sure, multi part answer.

 1. Yes you are right, it doesn't have to be *immediately* after a
 release, just before the heavy activity approaching a release.

 2. What might be better if there is some delay?

 Because I don't think we have got a good handle on host, bug tracker
 etc.  The responses were far from unanimous for a switch to Git,
 though no one was heavily against it.

 As far as I can tell Jiri is the only one who has responded who has
 actual experience running a Git project and that is only on Gitoroius.
  So I'd ask:

 * Does anyone else run a Git project, which host and whats the experience?
 * How many people contribute to one, and what hosting service do they
 use and what is the experience, is performance consistent and better
 than Sourceforge SVN, all around the world?
 * And does anyone have experience using any other DVCS and hosting
 service that would make them recommend it, or recommend against it?
 * should the bug tracker be moved?  Can it be done without losing anything?

 There are rather a lot of options listed here:
 https://git.wiki.kernel.org/index.php/GitHosting  Has anyone used any?

 The important things we need to know about a hosting service are:
 * likely stability, some have gone offline during the GFC, but this is
 hard to judge
 * performance for a good range of users in a good range of locations
 * reliability, low downtime
 * features, hosting clones, bug tracking ?

In fact, it is a much less critical decision which host to chose than
it may seem. After creating the repository, the main developers don't
have to visit the web pages of the host any more. The only thing they
have to do is to push the changes to all the git hosts geany will use
(it could be sourceforge, github and gitorious in parallel - it will
be up to the contributors which one they'll chose [probably github or
gitorious because these can host their own clones]). This can even be
automated if the push is made on your own server and  then propagated
by some script to all the mirrors. The web pages of the host will be
visited only by the contributors who want to create their own clone
(and from this point they can also forget about the web interface).
There are features like merge request at gitorious that notify the
maintainter about the merge from a contributor, but this can be
disabled so the only way the contributor will ask for merging his work
will be through the mailing list and publishing url of his repository
(wherever it is located).

Git is a distributed VCS - it doesn't matter where the user pulls from
- whether it's some host like gitorious, the official repository, or a
local clone on your machine - the mirrors should just be kept up to
date. And for instance if github is not officially supported and there
is some github lover, nobody prevents him from pulling from the
official repository and pushing to a github clone so he keeps it more
or less up to date (I did the same with the current geany gitorious
repository [I just don't keep it up to date, but I could of course] -
there will be no difference for people if they pull from there or your
official git mirror). And if you dislike one host and want to move to
another one, you'll just move the repository there - all the user's
local clones will be still valid, they'll just have to start pulling
from a different url.

So the question should rather be WHETHER to move and not WHERE to move
- the latter is much less important at this point. The only thing I'd
like to see is that one of the repositories makes it possible to
create personal clones for external developers.

Cheers,

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


Re: [Geany-devel] Git switch

2010-06-14 Thread Daniel Marjamäki
I believe I have some relevant info about github. I have a repository
at github. http://www.github.com/danmar/cppcheck
I used sourceforge+svn when I started cppcheck. But then I moved the
code repository to github.

For the code hosting I think github is really good. The code review
features are really useful. It is simple to make forks.
The biggest disadvantages with github is that its bug tracker is not
good enough and there is no release management.

 * How many people contribute to one, and what hosting service do they
 use and what is the experience, is performance consistent and better
 than Sourceforge SVN, all around the world?

30 people have contributed to cppcheck according to ohloh. Most of
those contributors only provide a few patches and nothing more.

I would say that github has consistently better performance than
sourceforge. Not just the repository but also the webpages. It has
happened that github has been down but in my feeling it has just been
temporary technical problems.

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


Re: [Geany-devel] Git switch

2010-06-14 Thread Jason Oster

Sorry for any noise this post might add!  Long response follows.

TL;DR:  Use Gitorious and Trac.


On 06/14/2010 12:47 AM, Lex Trotman wrote:

As far as I can tell Jiri is the only one who has responded who has
actual experience running a Git project and that is only on Gitoroius.
  So I'd ask:

* Does anyone else run a Git project, which host and whats the experience?
* How many people contribute to one, and what hosting service do they
use and what is the experience, is performance consistent and better
than Sourceforge SVN, all around the world?
* And does anyone have experience using any other DVCS and hosting
service that would make them recommend it, or recommend against it?
* should the bug tracker be moved?  Can it be done without losing anything?


I have experience with Mercurial (I manage a public repo containing 
several of my personal projects, and also a private repo for internal 
projects at work.)  And while the hosting is all 'self-contained' (e.g. 
the public repo is hosted directly out of Apache with hgweb.cgi, and the 
private repo is the built-in hgweb daemon) I've grown to love the 
minimalism of Mercurial's gitweb style.


I've also recently launched a new project on GoogleCode's hosting 
platform.  I cannot yet comment on how well their service works.  It 
seems it's not possible to simply clone hosted repos like with 
gitorious, for example.



There are rather a lot of options listed here:
https://git.wiki.kernel.org/index.php/GitHosting  Has anyone used any?

The important things we need to know about a hosting service are:
* likely stability, some have gone offline during the GFC, but this is
hard to judge
* performance for a good range of users in a good range of locations
* reliability, low downtime
* features, hosting clones, bug tracking ?


In that list, I've heard of only a few of them.  I would suggest 
avoiding github (total personal opinion, here; awful web interface, and 
the network graph visualizer requires Flash, which is purely 
ridiculous).  Both Gitorious and Savannah look great.


Gitorious maintains a fairly barebones service for git hosting, and its 
web interface looks ok.  Its shortcoming is that it doesn't integrate a 
tracker, so it can be difficult to link bugs with their relevant 
revisions in the repo (of course, you can always do that 'by hand' like 
you are now, but then that's one advantage of project hosting that 
you're missing out on!)


Savannah's main interface is really weird, but they do offer *gitweb[2] 
directly!  It also includes issue trackers, mailing lists, and other 
features that you can ignore if you don't need them.  I'm not sure how 
well these features integrate with each other.


It's worth noting that I don't have any actual experience with any of 
these services.  This is just from research I've done in the past while 
evaluating potential VCSs/hosting services.  (I ended up with Mercurial, 
and GoogleCode.)


That said, I only want to pose the following suggestion: Pick a hosting 
service that encourages development.  After revisiting some of these 
services, that only seems to be Gitorious.  That clone repository 
button is just too good to pass up, and the merge requests feature 
should come in handy, as well.


After a hosting service is settled on, you'll also wanta better issue 
tracker.  (I hate the SourceForge tracker.)  My suggestion here is 
Trac[2] with GitPlugin.  If it's possible to host Trac on geany.org, 
you'll be set; Trac includes a sourceforge2trac.py script to import 
the tickets from SF.


It seems reasonable to offer the source on a hosting platform like 
Gitorious, and hosting your own tracker that integrates with it directly.



* However, gitweb does pose some troubles when it does its 
generating... spin for a few seconds before giving the information 
asked for.  Pretty typical when browsing the web interface between 
commit logs and patches.



[1] http://git.savannah.gnu.org/gitweb/
[2] http://trac.edgewall.org/
attachment: jason_oster.vcf___
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

2010-06-14 Thread Jiří Techet
On Mon, Jun 14, 2010 at 03:26, Lex Trotman ele...@gmail.com wrote:
 On 14 June 2010 10:04, Jiří Techet tec...@gmail.com wrote:
 On Sat, Jun 12, 2010 at 02:59, Lex Trotman ele...@gmail.com wrote:
 (snip)

 See my talk with Dimitar (I know you did, thanks for the hint, I've
 completely overlooked that you get GKeyFile as the parameter) - my
 thinking about how to integrate my project management to geany has
 changed a bit. With GKeyFile of the settings available, which I
 thought was the most serious missing thing in the interface, I could
 actually start changing the implementatiton and see what else is
 missing on the way (there is already some missing API mentioned in the
 reply to Dimitar - unless I overlook some more functions and data
 structures).

 Sorry, maybe I'm going blind, all I can see is the settings question.

 Ah, one more post based on what I thought I had seen or written. OK,
 what I think is missing unless I overlook something is the ability to
 add a new tab to the project options dialog to avoid project options
 scattered over several places.

 Sounds sensible to me, is a function you pass a notebook tab to add
 and one to request its removal enough?  Or do Nick or Enrico have
 better ideas?

It would be enough if you make the GtkNotebook of the dialog
accessible through GeanyMainWidgets or the GeanyProject structure (I
do something similar when adding the new tab to the sidebar through
sidebar_notebook in GeanyMainWidgets). But then the dialog should be
created when the user opens a project (and hidden) and already be
available when the project-open signal is emitted. The dialog should
also be only hidden when it is closed. I haven't checked the sources
so I don't know whether geany already does it this way or not.

Cheers,

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


Re: [Geany-devel] Build config dialog change

2010-06-14 Thread Jiří Techet
On Mon, Jun 14, 2010 at 03:20, Lex Trotman ele...@gmail.com wrote:
 Of course, I don't have this version in mind when posting my comments.
 Your current version is alright for 0.19.1.


 Ok thanks, as you probably can tell I'd rather move on than try to
 tart up what I consider to be a fundamentally bad UI.

 And as I explained I'm don't like UIs that
 save hidden changes, as will happen if you make changes to several
 filetypes, and having a reminder dialog all the time is annoying.

 Well, having the reminder is less annoying than having to close the
 dialog, find the file with the extension whose commands you want to
 edit and open the dialog again. It means no extra annoyance if you use
 it the same way you do now.


 see below for another suggestion.


 2. Grouping execute and build commands together so it's clear that
 they are per-filetype (now I have an idea for name substitution for
 non-filetype - maybe filetype-independent could be clearer)


 Not changing for 0.19, string freeze was weeks ago.

 Of course, I don't expect this for 0.19.


 And I have one more idea - wouldn't it be better to put the contents
 of the set build commands dialog as a new tab in the preferences
 dialog? This would mean that there are only two settings dialogs - the
 preferences dialog for global options and project properties for the
 project ones.


 This won't change for 0.19 and as I keep saying the intention for the
 next version is to have a combined dialog

 I should have pointed out that there is no reason for the combined
 dialog to not be openable from several places, project, prefs, build
 menu.  Personally I like that it can be accessed quickly from the
 build menu, rather than having to dig through the prefs, but as I say
 activating the combined dialog from multiple points is no problem.


 OK, here comes the idea how to make the combined dialog in a slightly
 different way - I find the way you propose it a bit too complicated.
 The key idea is that the dialog will consist of 2 tabs - one for
 global commands (I call the ones you call global as superglobal
 :-)

 You should use the proper terminology, you are editing the user's
 configuration files in ~/.config or -c , so they are called user
 configuration, they override the system configuration files in
 --prefix which would require root to edit and are overwritten when
 Geany is upgraded so there is no dialog to edit them.

 No global or ...  super global ?!  :-)

  and one for project commands. If no project is open, only the
 global tab appears (or no tab is displayed at all) - the contents of
 the tab will be the same as the current set build commands dialog.
 If a project is open, then there will be both tabs. In addition, after
 the opening the active tab will be the tab with project build commands
 (including the graying out for global commands). So when the user
 opens the dialog, he will always see the commands that are currently
 used. I think that in this case the overridden global commands don't
 have to be disabled - the user will have to click the global
 commands tab before so he'll know what he is editing.

 What do you think about this option?

 I'm not sure what we gain by separating the project and user settings.

(using the correct terminology)

From what I understand how the dialog will look like it will only
display the currently used commands, correct? If so, then I expect it
won't be possible to edit the user commands that have been overridden
by the project commands. This will be a bit unfriendly to the user. If
he decides he wants to edit the user commands, he'll have to close the
project, edit the commands, and reopen the project again (if he wants
to continue in his work on the project). I think the two-mode
operation (no project open, project open) will be a bit confusing - in
one mode you'll edit the user commands only, in the other mode you'll
half edit the user commands and half the project commands, depending
on what has been overridden. And the mode depends on something
external from the dialog itself and it won't be apparent to the user,
what it is. The two-tabs dialog would eliminate the confusion.

  Remember the idea with the new dialog is to have two levels, the
 first level simply shows a table with what the menu *does now*, that
 is for the current file, for each menu item in order of the menu it
 has:

 * the label,
 * the command,
 * the working directory,
 * where the command comes from
 * an edit details button which

 pops up a subdialog with apply, cancel, ok buttons, and fields for the
 things you can edit (which is where the plugin configurator and the
 built in one differ see below), but only for the one menu item.  This
 makes it easy for inexperienced users to see what will happen, and
 they won't even have to think about filetypes

 Your filetype combo box would be on that subdialog and if you change
 the filetype whilst there are changed settings that haven't been
 applied you get a prompt to apply 

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

2010-06-14 Thread Jiří Techet
On Sun, Jun 13, 2010 at 14:07, Dimitar Zhekov dimitar.zhe...@gmail.com wrote:
 On Sat, 12 Jun 2010 01:06:34 +0200
 Jiří Techet tec...@gmail.com wrote:

 On Fri, Jun 11, 2010 at 19:30, Dimitar Zhekov dimitar.zhe...@gmail.com 
 wrote:
  On Fri, 11 Jun 2010 00:17:13 +0200
  Yes, it displays the matching files in the Messages, and the number
  after the file name is... The current line if the file is open? No,
  there are 0s for some open files, and 1s for some unopen files... huh.
 

 Huh here too, that should work. For unopen files it should be 1 and
 for open files it should be the current line (this is a kind of ugly
 workaround to make geany to keep the current line and not to jump to
 the beginning of the file). Could you tell me how to reproduce the
 problem? It appears to work correctly here.

 A zero is displayed for a file open via gproject, which you never
 navigated into. Once you click inside the editor, use the arrows or
 something, that becomes non-zero. Not an issue.

Aha, interesting, I wonder if this is a scintilla bug or an expected
behaviour. I can add if 0 then 1 or something like that.


 
  Bookmarks with commonly used directories, for example src.

 I'm just not sure where to put them. I also don't think it's so much
 needed - first you have to expand the necessary directories, that's
 true, but when you continue working with the project, you see your
 favorites in the form of the expanded tree. I'll think about it a
 bit, but it's not at the top of the list of features I'd like to add.

 I prefer to have bookmarks, for example src and include, and avoid the
 entire tree as much as possible. And have an idea about them below.

Apparently you find one of the best features of the plugin to be its
drawback ;-)


 ---

  You are probably aware of that, but... Unless you want to really work
  (compile and make) with 2+ projects, [...]

 Ah, I forgot to start with the main ideological change (there was only
 a hint unless you really need 2+ projects). So then:

 Instead of multi-project, make gproject single-project, multi path
 (with the base path from Geany project). Then the base and additional
 paths will be displayed like the current paths for 2+ projects.

 With this, you'll will be able to have a /home/.../geany-testing as
 base project path, and several other geany trees as additonal for
 browsing and searching. Or a project with several main paths (Yura's),
 as long as there is a single build command - that's the limitation.

 As of the additional paths being absolute or relative, we woudn't really
 know if they are part of the project, and even if so, whether they are
 moved together with the project base path. The absolute paths look like
 a safe bet...

 But what if APs _inside_ the project tree are used as directory
 bookmarks? :) Obviously, they'll be relative - and so the simplest
 solution seems the best: let the user enter the APs as absolute or
 relative, and save/use them as entered.

Just to make sure, do I understand correctly that the bookmarks should
be subtrees of the project tree copied and put somewhere behind the
project root at the top level? I think this could be done but to be
able to quickly distinguish between project/external project/bookmark
the sidebar should be somehow divided into three parts (e.g using
separators or different color for icons or something like that).
Clearly it has to be made sure that the bookmarks are not scanned for
tags because the files are already scanned within the project.


 there could be ignored dirs for tag generation patterns

 Yes, having directories excluded from tag scan will be much better
 than any per-project or per-path options. Perpaps a check menu item in
 the directory right click menu? It'll be good to store these as relative

I don't like the clicking idea much - for complex trees the ignored
dirs would be hiding somewhere in the tree and it would be a nasty
clicking exercise to find them.

 to their path, but that will require a real list of APs, not a single
 string of space-or-whatever separated entries.

Well, looking at it it would be best not to have external projects -
everything would get clear then - and this is probably how I'll
implement it. The external dirs idea already doesn't fulfill my needs
- I really need to switch between several projects each of which has
the same rights as the remaining ones (header/source swapping,
searching in project files and so on). But I think that your idea will
integrate much better to geany's project management (only a single
project open). For more open projects one should probably have more
geany instances running (well, tag sharing won't be possible, I know).

Unfortunately I'll have very little time to spend on implementing that
in the next two months (even though the implementation looks like only
one week of evening coding). But I'll definitely implement that once I
have some free time left.

Thanks for your ideas!

Jiri

[Geany-devel] ANN: Geany Plugins 0.19 released

2010-06-14 Thread Chow Loong Jin
Hi all,

We are happy to announce the release of Geany Plugins 0.19, which is
targeted to work with Geany 0.19. Tarballs, the Windows setup file, and
their corresponding GPG signatures can be found at
http://plugins.geany.org/geany-plugins

A comprehensive list of changes can be found at
http://plugins.geany.org/geany-plugins/geany-plugins-0.19.NEWS

Happy updating! :-)

-- 
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