ActiveBlog

Places and Projects in Komodo 6
by Troy Topnik

Troy Topnik, October 19, 2010

If you're new to Komodo, you probably won't know or care that the Project system has just undergone a huge change. The left sidebar now displays a file browser called Places that works pretty much like a regular file manager. Beneath it is a sub-pane called Projects, and with a little poking around you can quickly figure out how they work together.

Places Sidebar
  • Browsing the directory tree, copying/pasting, and dragging/dropping, all work as you would expect.
  • You can view remote directories via FTP, SFTP, FTPS and SCP.
  • There's a drop list for quickly jumping to higher-level root directories or recently visited ones.
  • You can limit which files and directories are shown by including or excluding patterns (e.g. file extensions) and save the setting as a "View".
  • If you're using Komodo IDE, you can see the source code control status of each file.

If you're used to using the old Komodo project system though, some of these things may come as a surprise. There are things you can do with the new system that you couldn't do with the old one, and vice versa. On balance we think it's much improved and definitely much more intuitive, but....

It just so happens that the things you can't do are exactly the things I told people to try back in January 2009.

For my sins, I've been asked to write a bit about how to use the new interface. First, let's look at the three things from my "Here's what I do instead" list. I've changed the order as two are related.

The old way...

"Add macros, templates, commands, etc. to a Tools folder"

This is now done for you. Project tools, formerly (and pedantically) referred to as "Toolbox/Project Components", are now stored as JSON files in a special '.komodotools' directory alongside the .komodoproject file. They appear in a special project-specific section of the Toolbox sidebar on the right, rather than mixed with the files and directories in the Projects sidebar.

This is much more intuitive for most people, but the implementation has a side-effect...

"Keep all my Komodo projects in one directory"

You probably shouldn't do this now. You could put all your projects in one directory, but theyl would end up sharing the same project toolbox. This is probably not what you want if you're actually using project-specific macros, snippets, and commands.

Saving the project file in the base directory of your project files, the usual use case for Komodo 5 "Live Projects", is now much more important. I could have titled this post "Live Projects and why I'm forced to use them", but I'm now used to this system and actually prefer it.

"Use multiple live folders at the top level"

This is a big one. You can't do this now. A project has one base directory which it shows in the Places pane. A lot of experienced Komodo users have let us know that this has really messed with their flow. I know I used this technique, but I didn't realize how many others did till the feedback started rolling in. If you're one of these people, please know:

We've heard you, and we're looking for ways to bring this functionality back with the Komodo 6 Places/Project system.

It might be in the form of a separate Projects sidebar that emulates the look and feel of the old Projects sidebar, or it might be linked/bookmarked project directories and file references displayed as nodes in the Places pane.

The new way...

In the meantime there are a few tricks and new features that can ease the pain:

  • Go to File (Fast Open): If you haven't used this feature yet, do so. Inspired by Firefox's "awesome bar" it's probably the quickest way to get to the files and directories you're interested in.
    1. Hit "Ctrl|Cmd+Shift+O" to bring up the Go to File dialog.
    2. Type a bit to filter the list.
    3. Select the file or directory you're looking for.
    4. Hit "Enter" to open a file in a tab or "Ctrl|Cmd+Enter" to open a file or directory in Places
    Go to File performs substring matches on a list of recently open files and files in the current project tree. You can also enter a filesystem path (with tab completion) if the file you want isn't in either of those lists.
  • Directory drop list: The top level directory in Places is displayed in the toolbar and is also a drop list. Click on it to see a list of the parent and recently visited directories.
  • Invoke Tool ("Ctrl|Cmd+K"): Another "awesome bar"-inspired interface, but for Tools rather than files. It searches the global toolbox, the project toolbox, and the shared toolbox (if you have that enabled) in the same substring-matching auto-completing way as Go to File. Invoke Tool sheet

So if you're having a hard time adjusting to the new project system, please do try these out. If you're new to Komodo, these features are gravy.

I'd be remiss if I didn't mention that Komodo IDE 6 is on sale through November 15, 2010.
  • New single licenses start at $245 (reg. $295)
  • Upgrades from Komodo IDE 5 start at $95 (reg. $145)

We now also offer an annual Upgrades and Support Plan for just $87.

Subscribe to ActiveState Blogs by Email

Share this post:

Category: komodo
About the Author: RSS

Troy Topnik is ActiveState's technical writer. After joining ActiveState in 2001 as a "Customer Relationship Representative" (AKA Tech Support), Troy went on to lead the PureMessage Enterprise Support team before moving on to a technical writing role in 2004. His talent for describing software for new users stems from his difficulty understanding things that developers find obvious. He has a Bachelor of Music from the University of Victoria.

Comments

11 comments for Places and Projects in Komodo 6
Permalink

Can you suggest any nice ways to manage multiple branches of the same project?

Our old way was to have a KPF file in version control, so that each branch had a project you could open to see it's files only. This worked reasonably well, because it was the only way to switch to a different view.

With the new method of switching to a different directory in places, it's much more fiddly to swap between projects. Because they're in version control all the projects have the same name, so using the projects panel to switch between them doesn't work so well either.

The reason i'd like to keep the active project synced is so that the fast-open window will offer the correct files.

Permalink

This is possible with the new system. The extension has changed from .kpf to .komodoproject, but you can name the project whatever you want (e.g. foo-trunk vs. foo-v3.2). Save the project file in the base directory of the branch rather than the root directory of the checkout.

You can check the project file (and the .komodotools directory if you're using a project toolbox) in to version control too if other people working on the project using Komodo. In the usual scenario, the base directory of the project is the directory the .komodoproject file is saved in, so the path will be correct for other who check this out.

If I understand the case correctly, this should actually be easier with the new interface because you're only ever looking at one branch at a time in Places. You double-click on the version-specific project names in the Projects pane to switch between branches, and make that branch current for Fast Open.

Permalink

I agree with all your points above - BUT why are the virtual Folders gone?

THIS is the main feature we are using in daily work: Create a project somewhere, create some virtual folders in it, drop the used files in the virtual folders and always have all needed files for this project in one place.

Our whole application consist of 1000+ files - but i always need just 20 of them in one project.

Please bring back virtual folders in Komodo6!

Best regards,

Dirk.

Permalink

Noted. If the top-level of the project (in the new bottom pane) was essentially a single virtual folder in which you could put directory and file links, would this suffice?

Permalink

If you mean: create symlinks in the filesystem (=project home) to the real files: hmm, maybe, but not really good. Subversion contrl has to work in IDE, so symlinks won't do that, i think.

If you mean a "virtual" link to the real files / directories, that would be ok.

We often use virtual folders to group the files (Development, Staging, Live) regardless of their real place in the filesystems. If this would be possible also: perfect! Otherwise, we could simmulate that by creating 3 projects and drop the corresponding files in there. So this would be no "No Go" ;-)

Permalink

Yes, these would be Komodo-specific virtual references, stored in the project file. Filesystem symlinks were ruled out, as Windows shortcuts don't really work like symlinks.

Permalink

I look foward to seeing the new changes for comparison.

Permalink

I consider v6's *new* places/projects design a major
modstep backwards compared to v5. Despite its new features, general usability has degraded because of this...

Permalink

As I said before: We've heard you, and we're looking for ways to bring this functionality back with the Komodo 6 Places/Project system.

For what it's worth, we've had feedback from a lot of new users who really like the simplified interface. Some of them are people who had given up on Komodo 5 because of the filesystem/virtual folder confusion mentioned in the older post about live projects.

If the new interface really doesn't work for you, and the suggestions mentioned above (Go to File and the directory drop list) don't help, feel free to stick with Komodo 5.2 for the moment. When 6.1 is out you can try the new new project interface to see if it will work for you.

Permalink

Sorry Guys - the new project handling in K6.0 sucks. I have gone back to Komodo 5.

I have multiple scripts in a single project, now I can
only execute one of them - the script args are not saved automatically which is incredibly annoying because during the course of development I might have up to 20 or more arguments.

I just don't have the time to mess around with this - not impressed, I think I have just wasted $95...

Mark

Permalink

This change is definitely not by design. There are bugs for this problem here:

http://bugs.activestate.com/show_bug.cgi?id=88287

http://bugs.activestate.com/show_bug.cgi?id=88368

The script arguments should of course be saved across sessions for the same file, or save-able as a named debugging configuration.