Posted by cvioletti on 2010-07-16 05:56

Komodo IDE 6.0 beta 2

Can no longer have multiple projects open?

ActiveState Staff
Fri, 2010-07-16 10:39

You can use multiple windows, and have one project open
in each window.

- Eric

xrmb | Tue, 2010-07-20 10:17

Now I've to have 10 komodo "instances" open...? that's no fun at all! Is there a reason why this was changed. I mean the projects doesn't even deserve its name anymore...

At least put some cool features in like a check box in open project "open in new window", or when holding shift down in recent projects to open it in a new window.

I still can't believe that happened...

Edit: Old post, figured it out...
when I noticed that I immediately stopped testing the beta of version 6. For me thats a deal breaker, I work on at least 10 projects at a time.

Also what do you mean by having multiple windows open? I can not figure out a way to have more than one project open. If I open another one the open one gets closed. And multiple instances of komodo are not working as well.

Enlighten me, please :)

ActiveState Staff
Tue, 2010-07-20 12:12

As for your selections, yes, we are going to make it much
easier to launch a project in a new window.

I think once we get all these wrinkles taken care of,
you'll like the end result much better than the
current state of Komodo.

Thanks for not walking away in total frustration.

- Eric

cngann | Fri, 2010-07-23 07:56

Please don't thank me for doing something I didn't do.

I didn't not walk away from this new version in total frustration. Just what I need, more open windows, more desktop clutter, and more crap everywhere.

Are you trying to create a distraction from the other lingering issues in Komodo?

That's just my .02. I've really enjoyed using Komodo to this point (with the exception of the ridiculous battery-draining CPU usage on Mac OS X) and am disappointed by this turn of events with the interface. To me, this would have been best suited to a user preference, not a forced workflow change.

Good luck!

pulchry | Wed, 2010-09-15 20:46

I quote the same; "I didn't not walk away from this new version in total frustration. Just what I need, more open windows, more desktop clutter, and more crap everywhere."

I must say I loooooove the new Komodo and how fast it is :).

A few things about the "New Project Management":
Honestly this is the whole reason I left Dreamweaver, Coda, and all the others. The very functional and useful projects tab. This is one of the features that makes "Komodo". . ."Komodo". We really miss the projects window.

I understand that it has the "recent projects" Tab, but what If I want to open projects that are not recent? Now I must go back to finder and search through my harddrive with multiple web projects, and use up project time that must be billed to the client. . .5.2.4 was way more efficient IMHO in how projects where managed. That was smooth, and clean. Can just have everything right there.

Is there reasoning for this new way of managing projects? If there is a logical reason I can understand, but it's really hard for me to see this as efficient in web designing. The whole purpose of improving is to remove unnecessary thinking that we have to do. And this creates more thinking.

"Feels like were going backwards."

ActiveState Staff
Thu, 2010-09-16 14:33

On the use case of opening projects you had a open a long time ago: Suggest that you increase the limit on the number of "recent projects" in the "Appearance" preferences panel.

Also, perhaps we could get the "Fast open" dialog to list recent projects as well. That would make it quick to track down old projects.

obs | Wed, 2010-07-21 18:44

Ok can someone tell me if it is possible in komodo edit 6 beta 2 to open projects in multiple windows, and if so, how? I'm on a mac.

ActiveState Staff
Thu, 2010-07-22 09:45

Use the menu item [Window|New Window]

We need to make multi-window handling smarter about
projects. In particular, but for now this will get you going.

- Eric

obs | Thu, 2010-07-22 14:00

Ok well that works but it's really inconvenient to have to switch windows for multiple projects, what was wrong with having one project under another on the left hand side?

ActiveState Staff
Thu, 2010-07-22 14:06

We're tying each Komodo window closer to a directory location,
so you can easily see the files and folders most closely
associated with that window, and have access to a true file manager,
and we've been hearing requests for a true file manager almost
since day 1.

The problem with projects in general was that they served as
a file manager, a source for preferences, a virtual file system,
and a container for specific tools. If you've followed bugzilla,
you're aware that there were plenty of bugs in the project system.
True, we could have fixed those bugs, and gone on with the status
quo, but there were aspects in the existing project system that were
standing in the way of where we wanted to take Komodo.

I believe we can find some constructive solutions, where we can
meet the needs of those of you who've learned to love projects,
and, understandably, don't want to change your work habits, while
continuing to improve Komodo. Please continue to let us know.

- Eric

johnzabroski | Wed, 2010-10-06 11:52

It seems like this is poor PR. You shouldn't redesign a flagship application without justifying it to your community first. You should also set some internal QA guidelines for the development team, so that they know what performance is expected out of them: The new design must fix the problems with the previous design, absolutely.

I would like URLs to Bugzilla items that demonstrate problems associated with projects.

> and, understandably, don't want to change
> your work habits, while continuing to
> improve Komodo.

This is weakly worded. It should say:

"We will not change your work habits, and will continue to improve Komodo. You may be asked to use a Conversion Wizard to convert your projects from Komodo 5 to 6, and 6.0 projects will not be loadable in 5.x IDEs" This is the only "constructive solution" that makes sense.

The most basic thing Komodo 6 could have done was separate out user preferences from the project file to a separate file, and also recommend users not commit the preferences file in version control. The IDE should automatically set-up new, version controlled projects where the preferences file is blacklisted from the VCS's file management list, so that users can't ever select it and commit it.

I would recommend Joel Spolsky's article "Painless Functional Specifications - Part 1: Why Bother?" in this situation.

ActiveState Staff
Wed, 2010-10-06 12:03

That was that tools were embedded inside projects, and this created the following problems:

1. You had to bundle tools in a .kpz file just to share them, or move them to another project.

2. You couldn't maintain them under version control.

3. When writing a new macro that might hang, you had to remember to save the project before running the macro. Otherwise you'd have to quit Komodo externally, and the macro would be history.

4. When a project was loaded, all of its tools had to be parsed and loaded as well, whether they were used or not. This slowed startup time.

5. Searching for tools was relatively slow, as we used a custom data structure based on the XML format of projects.

6. Sometimes you couldn't save changes to a macro, due to an internal corruption in the tool's project. The only solution was to save your changes in a separate buffer, reload the project, and try editing and saving the changes again.

- Eric

johnzabroski | Wed, 2010-10-06 14:00

1 & 2. Things like macros and code snippets in most IDEs are stored separate from the project, thereby eliminating the problems of sharing them across projects and maintaining them in version control.

3. Then the simplest fix is to automatically backup the macro before executing it. Optionally, you could also backup the whole project.

4. This should be dealt with by simply separating the project data from the tool data, into separate files. No impact to the UI needs to be had.

5. Once the tools are in a separate file, you can load that data into whatever data structure (e.g., index for search) you like

6. When internal corruption is possible, the standard approach is to provide a semi-automated recovery model in terms of integrity checks, backups and transaction logging.

All these issues do not appear to be related to the UI, yet many of the complaints in this thread and elsewhere appear to be related to the UI. This is probably an indication that the UI is tightly coupled to the persistence of the project file. Otherwise there is no reason to change the UI in order to fix all of these issues. Simply create a conversion wizard.

Let's move on to Issue #2

obs | Thu, 2010-07-22 17:09

One of the most useful features of projects I find is the ability to have multiple projects open in a single window on the side bar, then if I want to copy from one file in project A to another file in project B I can open both files in the same window in separate tabs then just copy and paste the section I want.

With the new system the only way to do that is to copy from window to window which means using the operating system navigation to switch. I can't just have two tabs next to each other and flick between the two.

To overcome the issue I'd have to open the file thats in another project using the file > open file option.

Can't you keep it so that you can have multiple projects in the project pane, and/or multiple windows? I've not seen any changes in projects in beta2 that warrant projects being restricted to separate windows.

buckthron | Mon, 2010-08-02 11:53

I agree with the sentiments voiced by obs, and I understand the ActiveStates folks' wanting to improve how Komodo handles projects. But at the same time, I want to put in a word for the usefulness of having multiple document windows open for a single project. While working on a web project, I really like having several windows open -- a css file, a php/html file, perhaps a multi-file window containing several controllers, and another window containing a few models. I don't want to be constrained to single window (window-splitting is not enough) while working on a project.

rne | Mon, 2010-08-02 14:06

No need to repeat what others said.
One-project-per-window limitation is a serious step back in usability.

ominian | Thu, 2010-08-05 12:31

As a compromise, would it be possible to set each IDE window to {Project Name} - {name/path of current file} to make it easier to navigate?

pulchry | Wed, 2010-09-15 20:58

"One-project-per-window limitation is a serious step back in usability." That seems like a feature you would find in komodo 4 or something. And Komodo 5 put it all in one. Now it feels like were going backwards?

nedbatchelder | Wed, 2010-08-04 17:50

I've just tried 6.0.0 Beta 3, and am also concerned about the state of projects. I don't mind the idea of multiple windows, I think that could be a step forward. But the current implementation seems half-baked.

For example, in the title bar (I'm on Win 7), the project name appears in curly braces. But if I have three windows open, each with its own project, the last project I opened appears in all three windows' title bars! The display of the project still bolds one of the projects while the other two remain unbolded, as if one of them is the active project. And the "Make Active Project" menu item is still on the right-click menu, but disabled, while it remains enabled on the menu bar.

Lastly, the project pane still shows the project itself as collapsible, though with only one project possible, this seems pointless.

Perhaps I just don't understand all the complexity, but I don't see any reason here that you can't continue to open more than one project in the same window.

ActiveState Staff
Thu, 2010-08-05 14:49

It *is* still half-baked. The projects/places stuff is still mid-implementation, which sucks and is confusing, I agree. The window title stuff is also obviously a bug.

obs | Wed, 2010-08-04 18:12

I've downloaded beta 3..I see no improvements in projects over beta 2.

ActiveState Staff
Wed, 2010-08-04 18:23

Many of the project-related bugs identified in beta2 didn't get
fixed in time for beta3, but I'm working on them this week.

- Eric

obs | Wed, 2010-08-04 18:24

Good to know eric, is there going to be a beta4 or are is the next release going to be a RC?

machine | Mon, 2010-08-09 13:03

You mean, ONE PROJECT - ONE APPLICATION WINDOW?!!!!! Are you serious?!

It's like IE6 ! Wow, maybe in IE9 Microsoft will remove tabbed browsing, since you've discovered new, better UI. It's ridiculous. I hope that it's only temporary.

I don't think REMOVING working features from Komodo is a way to go.

ActiveState Staff
Mon, 2010-08-09 15:20

@machine: Also like xcode, textmate and visual studio. Your browser analogy is wrong. Perhaps you are misunderstanding the discussion above to mean that Komodo 6 will only allow one *file* open per Window (as was how IE6 worked: one URL per top-level window). That is not the case: you can have as many open file tabs as you like in a Komodo window.

The limitation to one project per Komodo window helps:
- Clarifies how project preferences are applied to open files in that Komodo window: With multiple open projects it was ambiguous. Which project's prefs should be a applied to a file that is opened? If the file is under the base dir of the non-active project? If it is in the base dir of more than one open projects? With one project per window it is clear. This will help alleviate a common Komodo bug/support request about things like Debugger invocation prefs and others.
- Can have lighter and clearer UI for showing the current project.
- Can cleanly integrate file browsing without having to have separate "Files" and "Projects" sidebars, which in practice makes it a pain to use both.
- If indeed one does have two projects on the go, it is clearer to have two separate open Komodo windows. It means that "Find in Files" to search in the current project will "just work" for each window without having to awkwardly switch to the "Projects" sidebar and set "Make this project Active". Granted this workflow is an adjustment. Also this change in workflow is unfairly annoying right now because (as noted above) we haven't finished the move so it is hard to open a new project in a new window. We'll have that fixed for the next Komodo 6 release.

Single project per window can hinder for a couple use cases:
- Being able to see the file hierarchy for two (or more, but usually two) different directories. In K5 you could open two projects, one for each base dir. Not sure how great of a limitation this is in practice. We're working on a starring system for "Places" that hopefully will be useful for this use case.
- Others?

machine | Mon, 2010-08-09 16:16

It makes sense. I tried to work with 2 windows for a while. It's new experience for me, if I could suggest something: it would be very useful if those windows would differ more. Now I have 2 blue icons and I'm sometimes a little confused. I sometimes work with two versions of the same thing, they are very similar. I look at the old code, sometimes copy good features, and rewrite buggy ones. If the windows had for example numbers as first character in their title, it would be perfect. Now the current edited file name is used. It's confusing for me, since in lots of projects I have files with the same names. And if you have old version and new version with the same names - it's sometimes hard to tell which is which without taking some time to find the details.

cvioletti | Mon, 2010-08-09 16:23

Not being able to have more than one project open per window is lame. I'm usually working on multiple things at once, copying and pasting code, etc. and it's nice to be able to do it all in one window.

pulchry | Wed, 2010-09-15 21:16

Would be nice to combine 5.2.4 project management with the new faster 6.0

ActiveState Staff
Tue, 2010-08-10 10:14

@machine: That's a good idea. We should provide the option to tweak the Komodo window title somewhat (including the option to put the window number in there). I've added for this.

mwyer | Thu, 2010-08-12 06:41

I generally have about 6 projects loaded all the time, which allows me to rapidly switch between development and support tasks within a single window.

It was a major shock when I tried to open a second project in beta 3, when both the import/upgrade failed, and the previously-opened project disappeared (leaving its opened files still loaded).

If I have to open a separate window for each project, how will I know where a file opened via ko.exe has ended up?

If I have to alt-tab through 6 or 7 komodo windows to find it, that would suck. If the target window pops-up to the top-level, I would still need to find the intended window (while remembering the target window title), put it side-by-side with the target window, drag the tab over, then move the intended window back to its original location. Ouch.

I'm used to the idea that files opened via a project use that project's settings, and other files use the global settings. I don't need multiple windows to keep that straight.

On a multiple-monitor setup, I have a single window dedicated to komodo and the start menu. That window won't maximise correctly (due to Start Menu settings that I want to keep), so it needs to be resized manually. I really don't want to do that for multiple windows. As the monitors are different sizes and orientations, the side-by-side tab-move operation isn't always practical.

One major advantage of Komodo over other editors and IDEs is that you can do so much so quickly and easily in a single window, yet multiple windows are there when you need them.

While I can see the advantages for one-project-per-window in some circumstances, for multiple tiny projects it's a disaster. It's good that the dev team are thinking big, but please don't abandon the little guy in the process.

pulchry | Wed, 2010-09-15 21:04

Very true. This is not efficient. I have a ton of windows outside of Komodo already open. Safari, Firefox, multiple Photoshop documents. Plus it's so smooth to just go to your side panel and just click it. . .rather than switching between 6 web projects? The issue comes in when I want to open a project that I worked on last month that has code I like. Now I must go to Apple Finder and scrub through my hard drive to find a Komodo Project file. Sadly Im unable to see the efficiency in this. Can someone help me see the efficiency in having a ton of windows open? Or not having the ability to list all my projects instead of the most recent projects?

cvioletti | Tue, 2010-08-24 18:14

Can I open files from another project or projects via Places in the same window? This would be cool.

ActiveState Staff
Wed, 2010-08-25 10:33

You can open files from multiple projects, from the places sidebar
or any other source.

- Eric

mykes | Thu, 2010-09-09 08:13

I just bought the IDE.

Downloaded the beta, tried it, switched back to 5.2.

I work on at least two closely related projects and I REALLY want the project functionality to work like in 5.2 - more than one open project at a time in the projects side bar.

In fact, I'd love to be able to have 20 projects there, with 19 of them "closed" so the IDE doesn't have to do its scanning of files in those projects.

I want one BIG editor window, not lots of little ones. Not two or more big ones, etc.

I do have some ideas about projects that are unrelated, which I'll suggest in a follow up post here.

mykes | Thu, 2010-09-09 08:28

Specific to projects.

On a per project basis, I'd like to be able to configure a URL to launch when I click on the "Go/Continue Debugging" button on the top (debug) toolbar. It should automatically append the query string to start debugging. There should be another button that launches my browser with that URL without the query string (e.g. run without debugging).

In fact, it might be good to be able to set up multiple URLs to debug or run without debugging, per project.

This is closely related to the Mapped URIs feature

The add item to current project button was disabled no matter what project I opened in the beta.

I would like to be able to exclude URLs from debugging. One of my applications has JavaScript that polls the server via XHR, and even though I have "stop at first line" unchecked, it opens a debug tab in the bottom pane once a second (each time the browser polls). I do need to debug the server side script executed when the poll occurs, so I would want to be able to turn this on and off quickly - meaning not by opening a dialog and searching for the preference and having to manipulate some form to do it.

To clarify something in my previous post...

I have two projects, one in PHP and one in Java. My task is to migrate from one language to the other. I want to have both projects open and a file from one open and the corresponding file from the other open, one in the top tab group and one in the other. It's really easy for me to compare the logic in the top window with the bottom. I don't AT ALL want to have to view them in two instances of the editor, which would typically overlap due to screen real estate.

And I don't want to have to bypass the really neat project tree by having to open files from a dialog (File -> Open... -> File CTRL-O). If I'm able to use the projects interface, I can ctrl+click on a class or function in the top window and go to the definition. I can do likewise with the bottom window (the other language/project).

ActiveState Staff
Thu, 2010-09-09 09:58

@mykes: Have you seen the "Projects" subpane in the Places sidebar in recent Komodo 6 builds?

That helps to switch between projects in the current window quickly. Note that you can work with files from Project A while you have Project B open in Komodo 6 just fine. The only main limitation is that you can't have two tree file views in the same Komodo "Places" sidebar.

mykes | Fri, 2010-09-10 06:38

Two trees, please.

Like I said, I'm porting a 15,000 file/250,000+ lines of code project, and just navigating to find things is going to be tough without being able to see the projects as trees AND ideally, to be able to link the editor to the tree.

By linking the editor to the tree, I mean if I have foo/bar/baz.php open and the active window, the tree should be open with foo/bar/baz.php highlighted.

obs | Fri, 2010-09-10 16:56

I've tested RC1 and it's a darn sight better than beta3, however I don't really find it an improvement on version 5, the new places bar on the left side makes it about equal with version 5. One enhancement I'd like is to have tabs on the places bar for fast switching of projects.

veryvito | Sun, 2010-09-12 11:04

I was perfectly happy with the way projects worked in the 6.0 betas, but I Just downloaded rc1, and suddenly I can't figure out what the projects pane even does anymore -- I now have a Places and a Projects pane, and while clicking on a project highlights its name within the pane, I can't use it to access any of the files WITHIN the project?? The places panel shows only the directory in which the PROJECT file is (I use a separate dir to store projects, rather than including the project file within the working dir), but not the files that make up the project.

Can anybody explain how to work with this new system (and what a "project" even means any more)?

ActiveState Staff
Sun, 2010-09-12 13:49

The project directory used does not need to match the ".komodoproject" file location. You can change the imported project directed through the project settings (right-click on the activated project).

My guess is that the project ".kpf" upgrade did not work correctly, i.e. it didn't detect the right directory setting. It would be useful to know what type of project you had, i.e. some of the following:

  • was it a live project (i.e. did it have live import turned on)?
  • did it have additional live folders defined (in the case of the project live import being disabled)?


veryvito | Tue, 2010-09-14 08:06

Thanks for the reply, Todd. The issue seems to occur with both "new" (.komodoproject) and older projects (.kpf), and even projects I create new (OS X 10.6.4 w/ Komofo 6.0rc1).

Projects of all sorts seem to be affected, too. I've uploaded a video showing the current behavior, which simply can't be right...

Perhaps this is a bug? Or am I just missing something?

veryvito | Wed, 2010-09-15 13:16

Went back to beta 3, just to make sure I wasn't crazy, and everything's working as expected again. I'll keep an eye out for the next release, but as I'm fighting a few deadlines, I couldn't keep fiddling with RC1's Projects handling (Yeah, I know, I shouldn't be using betas for real work, anyway ;)

cyborgii | Mon, 2010-09-13 04:07

Given my dual screen setup I'm working for almost two years with two windows.
Therefore the limitation one project per window will not change my workflow.
However I fully understand the two window approach works only neat and fast if the there are two screens.
Otherwise switching between windows consumes a lot of development time.

Although I'm working with two windows the change in the project handling also reduced my working speed.
I can't open the same project in a second window, and the search ability within the project has been removed.
The current find dialog has no possibility to just find files by name as the search box within projects did before.
Hence I'm forced to navigate by clicking through the tree to my file.

dyoung522 | Mon, 2010-09-13 14:25

Hmmm... to add my .02 to this thread;

I store all my .komodoproject files in a single "Projects" folder. After upgrading to rc1 I noticed that my projects no longer took me to the associated "import_dirname" and instead took me to my "Projects" folder.

I finally figured out that if I manually set "import_live" to 0 in a .komodoproject file, it works as intended (opens the actual project folder in the places tree). However, there is no option in the project properties to change this anymore so I have to edit the files manually.

Even if I create a new project under rc1 it adds the "import_live" as 1 to the .komodoproject file and I'm forced to manually edit the file in order to correct this behavior.

Am I doing something wrong or is this a bug? I would think a project should go to it's associated import directory by default, no?

ActiveState Staff
Mon, 2010-09-13 14:36

It sounds like you're describing the beta 3 behavior, which was wrong.

- Eric

dyoung522 | Mon, 2010-09-13 14:45

Here's the about info... I just did all this "troubleshooting" today.

Komodo IDE, version 6.0.0-rc1, build 56031, platform linux-libcpp6-x86. Built on Sat Sep 4 16:36:36 2010.

dyoung522 | Mon, 2010-09-13 14:51

Oh, I also noticed odd behavior with the Project pane. If you rename (or delete) a project from within Komodo, it keeps the old project name in the list even though it's no longer valid. I would think this should auto-update itself. :-)

I had to edit prefs.xml to remove bad entries from the project listings.

ActiveState Staff
Mon, 2010-09-13 15:10

But yes, the project subpane should probably be watching
for deleted files. I didn't implement it because it seemed
like a low-frequency activity.

- Eric

pinpointzero | Tue, 2010-09-14 01:39

I've been a proud user since 2004 of Komodo IDE.

I now however fins myself lost. Gone has the intuitive nature I so enjoyed in the previous incarnations of the product.

Sorry - I want multiple projects back in one window please, or there's no way on Earth I'll be purchasing the upgrade this time.
I want, now that beta3 and RC have seen fit to 'upgrade' my lovely .kpf files, to *still* be able to access my remote files.

Gone is the virtual container model (which I eventually grew to enjoy), and now in it's place is something which only seems to work with local files.

Please tell me how I can get my remote files back in to my open project. They were there before, and I need them.


ActiveState Staff
Tue, 2010-09-14 09:55

You can now use live remote folders in Komodo 6 Places pane, though you cannot set a project to import from a remote path (yet). I've logged the following bug for the remote project path: