On 22 January 2013 10:04, vadim kochan vadim4j@gmail.com wrote:

It is just a "demonstrative" code. So, I just wanted to share my changes, may be someone will be interested in them, nothing more :-)

Ok, in that case you probably need to provide more of a use-case for it. Whats wrong with the current system? And how does your proposal address that. So far all I could see was that you don't like the current system. That may be a reason to change it. :) But to convince others that it should be in core you probably need more reasoning. Like I said I don't see the point of it?

Actually, meanwhile I dont see it as a plugin-like functionality, but rather like main functionality which can be turned on/off from "settings" box.

Shouldn't make any difference if its plugin or core. Plugins are optional functionality, not second class citizens. We don't want to keep inflating core with more and more options, Geany should remain light and fast. But that will depend on the response to the suggestion.

Cheers Lex

On Tue, Jan 22, 2013 at 12:42 AM, Lex Trotman elextr@gmail.com wrote:

...

On 22 January 2013 09:08, vadim kochan vadim4j@gmail.com wrote:

...

Hi all, May be someone will be interested in this.

I find useless that file is removed from session when I close it from tab, and decided to make changes for this.Not sure if the changes are good, this is first working version.

Something like this should be in a plugin rather than changing the behaviour of the Geany default projects. The default project functionality (really just named sessions) provides a very lightweight and simple paradigm which should not be changed. Making your version a plugin will allow the current system to remain as the default. There are also the two existing project plugins which provide different project features, so why not another?

...

I think that tabs can be more usefull when allows switching only between selected documents but not between all.

Here are the changes https://github.com/vkochan/geany/commits/close_tab_not_file . Will be glade to have any response.

Here are some notes:

1. All "close" actions anywhere in IDE now means to close document tab

page.

2. Opened tabs are saved into session file for future restoring them

after opening the project.

3. To remove document from project it is possible only by using "Remove"

menu item on sidebar panel.

4. Plugins should receive "document-close" event in case when document

removed from project.Not sure if its correct. With these changes should be 2 different events: document-close & document-remove.

Personally I don't see the use-case for your paradigm, the project session remembers all files opened unless they are manually removed? But that is up to you.

...

The feature can be turned on only after defining a macro in cflags before the build: -DGEANY_CLOSE_TAB_NOT_FILE

As I said above, it should be a plugin, not a change to the core behaviour. Then a user can enable it at runtime if they want to. Also a compile time selection is not acceptable, distributions can only select one option, and having differing project functionality in different distros is going to be very confusing for users, so it is unlikely to be accepted into Geany.

Cheers Lex

PS if your plugin needs extra hooks into the core please discuss it here *before* you code anything, that will save you from possibly having to make big changes.

...

I tested it only a little bit, not all cases, so there can be some surprises.

---

Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel

---

Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel

---

Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel

On 22 January 2013 10:32, vadim kochan vadim4j@gmail.com wrote:

I like current system, but I dont like to keep all loaded files in tabs,

You mean you want to keep the file loaded in Geany, but with no GUI presence? If so, thats a significant change to the way tabs operate, and different to most other applications. The normal practice is for tab closing to unload the file, but if it doesn't then users could be surprised by the growing memory usage as files stayed in memory.

Why do you want to do this? You haven't explained that yet, so nobody can suggest possible alternate mechanisms.

so for me it's more usefull when I can select some target documents into tabs & fast switch between them.

Sure, thats the point of tabs, but not sure why you want the other files loaded?

Thanks for suggestions, going to re-think how to move it into a plugin, but I feel it will be complicated)

Ok, but do try to answer the questions above, that way we can help you produce a solution that solves your problem and others problems too. If you have a problem then others are likely to have a similar issue too, so lets understand the problem and then look for a common, and *simple* :) solution.

Cheers Lex

Hi,

Le 22/01/2013 01:19, vadim kochan a écrit :

Thanks for trying understand me.

Ok, so when I use any IDE I expect & actually want it, that I can group files into project (yeah Geany supports it by term "session").

After that I can select some files into tab & work with them, if I dont need some file I can exclude it from tab, but not from project bcouse it means that I dont want this file currently but this file should stay included into project. For example when I load Geany related files from project file I see all tabs are open and for me its difficult to navigation between them. It would be much usefull for me if I can select into tabs files which I need dynamically.

IIUC, you just want to have a few files open from a larger set (called "project" generally) but keep a list of all files in that set. OK, fair enough, I can understand that. And other people already did, and wrote plugins for this: GProject and GeanyPrj does this (and more) AFAIK.

And if those plugins don't please you, you probably could easily write a new one that just keeps a list of files in the set (project), just like the "Documents" sidebar lists the currently open files.

I look on tabs like fast navigation between needed files for some short period. In next time when I load same project I can select another files into tabs, but I want that rest of files which belongs to this project stay here.

May be the missunderstanding comes from different terms which we use:

• I use the term "project" and by this I mean that files which I loaded into

sidebar will stay here (most of them) for a some long time.

• You use the term "session", and probably it means you want use loaded

files for some short time?

Actually this "tab" behaviour is standart for most of the IDE I has been used.

Yes, what Geany calls a "project" is basically only a set of files to open, plus a few settings. Mostly like a "session", e.g. it allows to reopen the files you want.

This may or may not be what you wish for, but it's simple and as said, there already are plugins that extends this project feature to behave more like other IDE's "projects" (and I think, more like you wish it behaved). If you want one of these plugins, they are here for you. If you don't want them, don't install/enable them, that's as simple as it gets; it's flexible and everybody can be happy.

Even, you see there are already 2 different project plugins, which means you can chose the one you prefer. Or even write a new one if they don't fit your needs.

Regards, Colomban

Hi all,

One thing that's different from Geany from other IDEs I've used is that it doesn't have "files in the project" but rather just stores "where are the project's files" (ie. base path).

Right. Speaking for myself, and the build setup I'm working with right now, this actually suits me very well.

Essentially, the set of files for a 'project' for me is defined as 'all the source files under a specified root directory'. And this then fits in well with the way Geany works, because I can add new source files just by creating files, or copying and renaming existing files, and so on, without any additional 'add to project' action required.

(And from various posts I've seen, I have a feeling that quite a lot of people have some kind of similar project setup now.)

One thing that _doesn't_ fit in so well with the geany (core) paradigm is the 'go to tag definition' feature (which is included in Geany core).

I have a build setup on Windows, also, with MSVC, and for comparison in that case I actually need to run a script to update visual studio project files after adding a new object, and depend on visual studio detecting this and offering to reload the project.

But then, after it reloads the project file, it then knows about all of the relevant source code and can do this properly (if you give it a bit of time to update it's source code indexing in the background).

In Geany, however, in order for the 'go to tag definition' feature to work you actually need to make sure you have the source code file that defines the tag loaded. So, for this to actually be useful in the general case, you _do_ actually need to have your whole set of project files loaded.

So, this is actually completely inconsistent with the whole simple 'list of open files is a session and there is no list of files in project' paradigm being discussed, I think, and is then also confusing and misleading for people starting to use Geany, as well as complicating the core source code and dependencies. So, I suggest that this whole 'tag' based code analysis thing should actually be _removed_ from Geany core (and perhaps moved into one of the project management plugins)!

(As an aside, for myself, I'm managed to hack something up that uses libClang to lookup references, that doesn't need know about the whole set of project files in order to work. It actually just executes the corresponding compile command within libClang each time you click 'lookup reference', and so fits in quite nicely with the 'no list of files in project' paradigm..)

Best regards,

Thomas

On 22/01/13 02:58, Matthew Brush wrote:

On 13-01-21 04:19 PM, vadim kochan wrote:

...

May be the missunderstanding comes from different terms which we use:

• I use the term "project" and by this I mean that files which I

loaded into sidebar will stay here (most of them) for a some long time.

• You use the term "session", and probably it means you want use loaded

files for some short time?

Actually this "tab" behaviour is standart for most of the IDE I has been used.

One thing that's different from Geany from other IDEs I've used is that it doesn't have "files in the project" but rather just stores "where are the project's files" (ie. base path). For example in XCode or VS, you have to "add files to the project" because they do all kinds of nice stuff like compiling everything together for release/debug/etc, precompiled headers, on-the-fly "smart" completion, debugging, semantic highlighting, inter-project/solution dependencies, refactorings, etc. Most of this kind of fancy stuff needs to actually know all of the files because it needs to be able to always build the project's target(s).

Geany's core is not this advanced (on purpose), so it's just basically when you set a project path, you tell Geany the default location of the file chooser dialog box for opening files and stuff, and as a bonus, it remembers which files you had open separately from those you had open without a project loaded.

As mentioned by others, it sounds like you're wanting the Tree Browser plugin since it can show all your project's files and allow you to rapidly access them without keeping their tabs open, somewhat similar to like you'd have in XCode, VS or Eclipse.

Cheers, Matthew Brush

Thanks All for response, At present I am trying to play with existing Geany "project" plugins )

On Tue, Jan 22, 2013 at 10:49 AM, Lex Trotman elextr@gmail.com wrote:

On 22 January 2013 19:15, Thomas Young thomasyoung@free.fr wrote:

...

Hi all,

...

One thing that's different from Geany from other IDEs I've used is that it doesn't have "files in the project" but rather just stores "where are the project's files" (ie. base path).

Right. Speaking for myself, and the build setup I'm working with right now, this actually suits me very well.

Essentially, the set of files for a 'project' for me is defined as 'all

the

...

source files under a specified root directory'. And this then fits in well with the way Geany works, because I can add

new

...

source files just by creating files, or copying and renaming existing

files,

...

and so on, without any additional 'add to project' action required.

(And from various posts I've seen, I have a feeling that quite a lot of people have some kind of similar project setup now.)

One thing that _doesn't_ fit in so well with the geany (core) paradigm is the 'go to tag definition' feature (which is included in Geany core).

I have a build setup on Windows, also, with MSVC, and for comparison in

that

...

case I actually need to run a script to update visual studio project

files

...

after adding a new object, and depend on visual studio detecting this and offering to reload the project.

But then, after it reloads the project file, it then knows about all of

the

...

relevant source code and can do this properly (if you give it a bit of

time

...

to update it's source code indexing in the background).

In Geany, however, in order for the 'go to tag definition' feature to

work

...

you actually need to make sure you have the source code file that defines the tag loaded. So, for this to actually be useful in the general case, you _do_ actually need to have your whole set of project files loaded.

Hi Thomas,

Or you can load tags files instead, so long as the symbols are in memory, and I am told (I don't use them myself) that the project plugins (there are two with slightly differing behaviour) will arrange for this to happen for you, rather like the msvc system.

...

So, this is actually completely inconsistent with the whole simple 'list

of

...

open files is a session and there is no list of files in project'

paradigm

...

being discussed, I think, and is then also confusing and misleading for people starting to use Geany, as well as complicating the core source

code

...

and dependencies.

Thats why the project plugins are plugins, they significantly change the paradigm.

...

So, I suggest that this whole 'tag' based code analysis thing should actually be _removed_ from Geany core (and perhaps moved into one of the project management plugins)!

No, it still works within the files that are open, we don't want to force people to use the full project paradigm of the plugins just to look for definitions in one or a few files.

...

(As an aside, for myself, I'm managed to hack something up that uses libClang to lookup references, that doesn't need know about the whole

set of

...

project files in order to work. It actually just executes the

corresponding

...

compile command within libClang each time you click 'lookup reference',

and

...

so fits in quite nicely with the 'no list of files in project'

paradigm..)

That sounds interesting, are you going to make a plugin from it? Maybe you could load the symbols info into Geany and then not have to run clang again and again. Matthew was also looking at something similar I think.

Cheers Lex

...

Best regards,

Thomas

[...]

---

Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel

On 13-01-22 12:15 AM, Thomas Young wrote:

(As an aside, for myself, I'm managed to hack something up that uses libClang to lookup references, that doesn't need know about the whole set of project files in order to work. It actually just executes the corresponding compile command within libClang each time you click 'lookup reference', and so fits in quite nicely with the 'no list of files in project' paradigm..)

Sure, if you only want to lookup references in the same translation unit or any included header files that happen to be in the search path, but to really make full use, LibClang essentially needs a "project" to support it (include paths, defines, other translation units/files, etc).

Cheers, Matthew Brush

Am 22.01.2013 09:15, schrieb Thomas Young:

Hi all,

...

One thing that's different from Geany from other IDEs I've used is that it doesn't have "files in the project" but rather just stores "where

are

...

the project's files" (ie. base path).

Right. Speaking for myself, and the build setup I'm working with right now, this actually suits me very well.

Essentially, the set of files for a 'project' for me is defined as 'all the source files under a specified root directory'. And this then fits in well with the way Geany works, because I can add new source files just by creating files, or copying and renaming existing files, and so on, without any additional 'add to project' action required.

(And from various posts I've seen, I have a feeling that quite a lot of people have some kind of similar project setup now.)

One thing that _doesn't_ fit in so well with the geany (core) paradigm is the 'go to tag definition' feature (which is included in Geany core).

I have a build setup on Windows, also, with MSVC, and for comparison in that case I actually need to run a script to update visual studio project files after adding a new object, and depend on visual studio detecting this and offering to reload the project.

But then, after it reloads the project file, it then knows about all of the relevant source code and can do this properly (if you give it a bit of time to update it's source code indexing in the background).

In Geany, however, in order for the 'go to tag definition' feature to work you actually need to make sure you have the source code file that defines the tag loaded. So, for this to actually be useful in the general case, you _do_ actually need to have your whole set of project files loaded.

The gproject/geanyprj plugins allow generate tag files based on the project files (as in project files, not session files) so that go-to-tag works without having the files open.

So, this is actually completely inconsistent with the whole simple 'list of open files is a session and there is no list of files in project' paradigm being discussed, I think, and is then also confusing and misleading for people starting to use Geany, as well as complicating the core source code and dependencies. So, I suggest that this whole 'tag' based code analysis thing should actually be _removed_ from Geany core (and perhaps moved into one of the project management plugins)!

The confusion comes from Geany (mis-)using the term project when it actually means session. I understand that this is very confusing for newcomers.

Best regards.