On Thu, 2004-07-01 at 23:50, Vincent Danen wrote:
>  On Jul 2, 2004, at 9:26 PM, beer wrote:
>  
>  > Tested Komodo professional, version 3.0.0-beta4, build 104847.
>  > On Mandrake 10 with Gnome Desktop and KDE installed.
>  >
>  > It's working fine, though it's slower with mouse and keyboard input 
>  > than
>  > KDevelop3's new php editor (which has code complete and intellisense on
>  > php projects now). It's noticibly slower than A normal text editor like
>  > Gedit UI editor or vi as well.
>  >
>  > Right now I'd say it's too slow to actually use. I'm running Mandrake
>  > 10.0 on a 1 Ghz Celeron with 256 MgRam. I hope to see this product
>  > improve in performance in the near future because Komodo 2.5 would not
>  > run on Mandrake at all.
>  
>  You're kidding, right?  I use Komodo 2.5 on Mandrake 10 and 9.2.  It 
>  most definitely runs.

Here is my bug complaint and stdout, stderr terminal dump as an
attachment. Komodo 2.5 does not work correctly with mandrake 10.0 on my
box. KDevelop however is super fast and works perfect, so for now I'm
going to stick with that for linux/php dev. It has everything Komodo
seems to have except for the regex dialog. It has the intellisense and
code completion for all php functions just like komodo, except it's much
faster.

As I said I like Komodo, but right now It's not usable. I'll key in
input code and about 5 seconds after I key it in, it shows up on the
screen. None of my other text editors lag this way. I'm using evolution
mailer to type this message and everything is in realtime. Komodo is
type now, see text 5 seconds later. I wouldn't call that usable, but
whatever. I can't wait to see a new build of this project. 

As for it being proprietary, MySQL has a proprietary version and yet
remains open so you can compile it on your machine for maximum
performance. Linux isn't exactly windows with the registry and people
doing all sorts of hoop jumps to keep people from copying programs. I
say just let people pay for the code and let them compile it. If they
really wanted to ripp it off badly, they'd just grab it on NNTP where
people have put up comprimised versions. Telling yourself you can
protect software against these people is putting on a facade anyway. Esp
on linux.

>  
>  > Could the speed problem be handled by just making most of the app with 
>  > C
>  > and GLib then tarring the source and letting us compile on our target
>  > machines with ./configure, make and make install?
>  
>  I don't think you'll ever see this... =)  Kinda defeats the purpose of 
>  it being a closed source proprietary product.  (Although I would not 
>  complain if they did give us the source because then I could compile it 
>  on my mac and use it there as well!)
>  
>  > It seems like a sensible solution to me if there's not too much UI to
>  > rewrite. GTK+ widgets are pretty fast, and C runs well under Linux. You
>  > could save alot of abstraction time on mouse and keyboard interupts
>  > maybe,
>  >
>  > At any rate, when the product is ready for realtime use, I will give it
>  > another go. Keep up the good work please.
>  
>  I've noticed it's a little slow, but not unuseable slow.  I would 
>  suspect more it's debugging code being active during the betas than 
>  anything else, although I could be wrong.