What is a project?

Posted by sgeard on 2010-09-28 15:51

In K5 it was clear what a project was and how it should be used as part of my work-flow. It provided a logical collection of related code in the same way as Visual Studio still does. As such I could create a project, define its contents, add files and tools to it and remove them from it - I could even delete a project if I wanted to.

In K6 this fundamental idea of a project has gone. I have tried RC1 for the last 3 weeks but just can't see the point of it and have had to move back to K5 in order to get some work done. What I'd like is if someone could explain what a project is and how it fits into the work-flow of development. What were the aspects of the version 5 project concept that were wrong and how does the current design improve them?

I know that there is another thread about projects but that discussion is about fine detail. I don't want to know about whether I can have 1 or 1000 projects or files open, or that I couldn't do 'x' in K5 but I can in K6 - I want to know about the concept of a project. The current K6 has the feel of something that's been created simply to get round some of the limitations and idiosyncrasies of the K5 project and the whole design intent of the original project concept forgotten.

ActiveState Staff
Tue, 2010-09-28 16:14

Komodo Projects are collections of settings and preferences that help you work with a particular set of files. These settings include:

  • the base directory to display in Places
  • previously opened files
  • debugger preferences
  • test plans
  • language library paths (code intelligence)
  • mapped URIs

The project settings only apply when the project is open, and is applies to all opened editor files.


sgeard | Wed, 2010-09-29 02:21

The description you give is fairly close to the idea of a project in K5, but in K6 the implementation seem to make it very hard to achieve this.
In particular it isn't possible to define which files are in a project, and without that ability it is very hard to get anywhere with them.

  • the base directory to display in Places how does this implement the design requirement? Particularly poor is the appearance of '.komodotools' as a directory. This is confusing the filesystem with the structure of the project - they are two entirely different things. Worse than that is the appearance of intermediate and object files automatically in the project. I run a tool 'make' and a load of .obj and .mod files automatically appear in the project, why? This is a real killer. For projects to have any use you have to be able to define which files belong to them. Can I define the files in the project to be just those under revision control in a particular directory and sub-directories? Automatically adding files might be nice and convenient for some users (not that I've ever met any) but it completely destroys the ability to have any sort of control over a project, and in this respect it completely fails to implement the design you stated in you first sentence.
  • previously opened files again how does this support the design?
  • debugger preferences good
  • test plans I need to investigate these as I'm not sure what these are or when I'd use them
  • language library paths (code intelligence) good
  • mapped URIs as for test plans

What I am trying to do here is understand what projects have become so that I can get the best out of them. Are you planning to provide rc for the Help? I would be very useful if detailed a description of a project, what it is and why you would use it, could be included in the Help.

Ultimately I think that automatically doing 'x' when I've asked K6 to do 'y' is poor design. It might be nice and convenient for some users in some cases and therefore could be a configuration option, but to make it the default is wrong.



ActiveState Staff
Wed, 2010-09-29 10:48

Hi Simon,

The fundamentals of the project has not changed at all between Komodo 5 and Komodo 6, what has changed is how files are viewed in the associated tree viewer.

For the tree viewer, Komodo 6 always uses the real filesystem for what it displays (anchored to one particular folder), whereas in Komodo 5 you could have a mix of virtual files and real files (which was a big confusion point in Komodo 5).

Note, the ".komodotools" folder is a real folder on the filesystem, yes it is special to Komodo and it will be hidden by default in the tree view for Komodo 6 final.

As Komodo's tree viewer is now a real representation of the filesystem, any files in that filesystem may also be show in the tree viewer. You can decide on what files you want to have shown in the tree viewer (filtering) by customizing the "Views" in Places, or by defining the includes/excludes on the project.

I'm not sure what you mean by "previously opened files - again how does this support the design", this is a feature of Komodo projects (the same as it was in Komodo 5), any files that you have opened in Komodo that are relational to the project base directory will be used for the project save/restore operations.


sgeard | Thu, 2010-09-30 02:32

Thanks for that clarification. Please don't get the idea that I think that everything in K5 was wonderful and K6 is a large step backwards. I want K6 to be a success and so need to understand how best to use projects.

I still think that the fundamentals of a project have changed between K5 and K6. With a live view you never have a concise definition of what is in the project; in fact it's no longer possible to define what's in and what's out and if that isn't fundamental I don't know what is. The places mechanism in which eveything is in unless it matches a filter is far too coarse. Suppose my program creates a large number of temporary files that are named abc1, abc2,... These files will automatically be included in the project and it isn't possible to define a filter to exclude them. The only way to do it would be to make sure that these files were either a) created somewhere else or b) named differently so that I can use the filtering mechanism. Neither of these solutions are right. Are you suggesting that I change the output of my application to suit Komodo?

What you need is a way of defining the files in a project by inclusion rather than exclusion (subject to the same restriction of the file being part of the local filesystem). The simplest options here are

  • turn off 'live folders' and allow the user to select files in the current directory for inclusion (no files from elsewhere)
  • provide a mechanism by which only those files that are under revision control are deemed to be in the project (e.g. from svn ls -R)

If I have a directory in my project and some process creates some files in that directory are those files immediately added to the project or only when I navigate?

Filter bug:

on WinXP the filter string


doesn't exclude .mod or .exe files - works ok on Linux

Project Settings bug:

on WinXP if I change the language in the 'Debug Session Startup' from the default (Perl) to Tcl I get an error dialogue

'The Debug Configuration "Project" won't be saved because no script was specified'

- works ok on Linux.

Enhancement suggestion:

Allow a default language to be specified so that all projects can be setup automatically for that language (Tcl in my case).



sgeard | Sat, 2010-10-02 02:38

Just to add to my previous comment. On both WinXP and Linux K6 crashes almost every time I type 'make' in another window. I've sent in the reports as K6 requests so hopefully you'll have some idea of what the cause is, but to me it seems that the most likely cause is the live folders implementation.

The more I think about it the more the current structure seems wrong. The 'ActiveState knows best' philosophy that K6 promulgates is following the worst of the Microsoft route. It might be nice in some cases (examples?) for everything to be slurped into a project but to tell developers that is the way they have to work is, at best, short sighted. Komodo IDE should be a tool that supports developers in their work and thereby aids their productivity - the only reason to use it in a professional environment. Part of that task is to help them think clearly and with K6 you seem to have lost sight of that objective completely.

I could be wrong about this of course. My concept of a project could be completely orthogonal to the K6 idea of a project; to understand that was why I started this discussion. However you stated at the outset that there was no conceptual difference between projects in K5 and K6, but given how different they are to use this can't be true.

My expectation could be misplaced, after all K6 is just a developer tool and only a cog in the wheel of development. The difficulty here is that I like to be in control of my work: if I have an IDE I want it to do what I tell it when I tell it - not update itself when I do something else. I already have this problem with Visual Studio 2008 and its TFS integration. Bells and whistles are nice and can make the difference between 'ordinary' and 'great', but not at the expense of the basics. At the moment I will use K6 because of the improved tcl support, but if K5 had those improvements I would regard K6 as a backward step.

My expectation could also be misplaced in respect of your plans. I have been assuming that K6 represents Active State's 'Brave New World' of development but that could be completely wrong. K6 could be the start of the journey and you have plans for 6.1 that, for example, would allow project definition by inclusion.