Summary
Komodo IDE version 6 radically changed the design of one of the key aspects of what makes it an IDE, not just an editor - Projects. There have been a lot of unhappy comments from the user community. How much consultation should a company provide?
Advertisement
If you read the discussion forum thread on projects, you can see a number of people's complaints about the change. I'm not going to argue the merits of the change here but I'm intrigued by the thought of how much design should take place in public and if a community consultation is appropriate.
The Komodo v5 IDE allowed for multiple Projects to be open to provide tree browsing of selected files, within the one main IDE window. This feature was much appreciated by people like myself who tend to work across multiple projects, sharing files and using those project documents to organise subsets of work.
Just to give you a quick idea of the magnitude of the change: the redesign replaces projects with a filtered directory view called Places and only allows one Place to be be open per window. To see multiple Places, you have to create multiple IDE windows, visible on your taskbar and requiring more disruptive switching. The change is not as painful if you are using multiple screen computers, provided you're willing to give up the screen space to see things side-by-side
Remember that Komodo IDE is a commercial product. Does that give them more right to make large changes without consultation compared to having to woo an open source community? Would you encourage other vendors to publish mockups and other prototypes before committing to a redevelopment? Is it time for more consultative design or is that just a mudhole into which the project would sink?
One of the comments on the above forum from an ActiveState employee is interesting and I think informative of their attitude: 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.
Obviously, since they are using bugzilla, they are depressed programmers who enjoy mutilating themselves to relate to the daily pain of using such an awful tool.
> 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.
"Projects [as] a source for preferences" seems like a really poor design, if it is what I think it is.
They stored user preferences in the *.komodoproject file? If so, how does that work with version control? At work, we mandate that everyone blacklist their personal preference files from version control commits.
How are projects a container for specific tools? What kinds of tools?
A virtual file system?
File manager?
Another thread [1] seems to suggest that Komodo Projects also store debugging preferences? Gross.
Seems like at a minimum what they should have done was defined a way for users to upgrade from K5 projects to K6 projects, and that at a bare minimum K6 projects would no longer bundle debugging preferences and other preferences as part of the project file.
I am not sure what bugzilla issues Eric is referring to, either, but I searched out of curiosity and found bugs that did not seem at all related to how project files were stored. Most bugs appeared related to the GUI, such as [2] where Find/Replace creates an incorrect Context in which to perform some command. Sounds like bad design to me, and an indication of a need for refactoring - not junking the project abstraction.
Just .02. Would appreciate it if you could fill me in more Andy on what the bugs are.
> Obviously, since they are using bugzilla, they are > depressed programmers who enjoy mutilating themselves
Or, as I think is the case here, obsessive open-source purists. Bugzilla is like a red flag unless it's inflicted on you by hosting.
> Just .02. Would appreciate it if you could fill me in > more Andy on what the bugs are. Sorry, don't have the time or interest in their product. I hadn't noticed any particular bugs but had noticed quirks in the project implementation.
I've had this ongoing battle and been an amused observer over many years - it seems most IDE companies evolve through the stage of putting inappropriate local stuff in their project files at some point.
This is the first time I've heard of someone nuking the entire concept as a solution!
I provided some feedback in the discussion forum link you posted.
I was once a user of Komodo IDE (way back in college), back when (a) it was pretty much the only dynamic languages IDE (b) I programmed religiously in dynamic languages only.
The funny/sad thing about this is that a large part of their justification for not bother to ask about the change is that it is just like all the other IDEs.
They are now finding out the hard way that one of the things that some people particularly liked about Komodo was the way multiple projects worked.
Yeah, I guess some subset of computer nerds don't understand product differentiation. I remember when somebody filed a bug report for either SharpDevelop or CodeBlocks
You can track the interaction between me and an ActiveState rep here:
It seems like from a sampling of the Komodo Beta forums, users are still angry about the Beta. I am just hoping my feedback can bring help out a product I once used and endorsed (half a decade ago, probably over 50 people bought ActiveState products on my recommendation, when they had never even heard of ActiveState or Komodo before). It is the least I can do.
Meant to say some user of SharpDevelop or Code::Blocks (or similar C# IDE) submitted a bug report complaining about how the project model was not identical to Visual Studio's. It was kind of funny to see a user enforce their viewpoint on a design decision made very early in the history of the IDE. -- They basically wanted something they could use in place of Visual Studio without having to pay for it.
So it goes in both directions. Sometimes developers are wrong. Sometimes users are.