One of the features of the "standard" enterprise desktop that appears to be missing from all of the proposals I've seen is scriptability. It makes little difference what enterprise desktop environment you're comparing to - Lotus 1-2-3 and Borland's Quattro Pro for DOS were scriptable, and of course Visual Basic is pervasive in the Windows environment.
If KDE lacks in any area, it is the area of scriptability. A few KDE apps (Scribus) are Python scriptable; KDE-bindings doesn't even cover much of KDE yet (as far as I know); DCOP and/or QSA or JavaScript are not "user-friendly" scripting in my opinion. OpenOffice is Python scriptable and probably more Gnome than KDE apps (gnumeric, gnucash) are scriptable (although gnucash seems to use only scheme - not exactly as friendly as VB either). Python bindings exist for GTK and wxWindows, and are probably more popular because they're more easily cross-platform (Qt is expensive to use on Windows). The benefit of scriptability is that it allows users to extend and automate applications - similar in many ways to redirection and piping on the Unix command line, but also allowing things like dialog boxes, data validation, transfer and conversion - in short creating custom spreadsheets, mail clients, WP documents, or whatever using existing APIs but without having to write C++ code or modify the application itself. My personal bias on this subject stems from the fact that I maintain/develop PyKDE (based on Phil Thompson's sip and PyQt). PyKDE can already handle (in Python) virtually everything that kdelibs can do, including panel applets, KParts, IOSlaves, Control Center modules, and DCOP. Some of those still have some rough edges, but the basics are there. Similar techniques can be used to make KOffice and Kontact scriptable [1] In the past I've had Python scripting working for KSpread, for example, and could create "built-in" formulas in Python, as well as use Python to set-up, format and manipulate spreadsheets, and to do things KSpread can't presently do (load and operate on spreadsheets in the background, for example). Execution speed is not an issue, as bindings run largely in the C++-space anyway. There are also tools in development to make the generation of Python bindings simpler, including more documentation for the process of developing bindings. The major limiting factior in any of the above for PyKDE or similar approaches is time - there are only a few people working on this and a lot of work to do (although again, the basic "technology" isn't too difficult). Please also note that this is not an "invasive" add-on - it requires no changes to KDE to implement, doesn't force linking to any special libs, etc. (A few changes might make life a little easier, but it's not a big deal). Personally, I'd find Python to be the optimum alternative to something like Visual Basic Realistically, Perl is more widely used (although not as "newbie-friendly" or object oriented), and other languages like Ruby, TCL, etc. have their adherents. Regardless of which language or languages are supported, scripting is something I feel KDE needs to pay more attention to. I'm not sure what support to scriptability KDE can offer - at the very least it would be nice to see some recognition of the need for scripting and some emphasis on making it happen. I'd be happy to discuss this further with anyone interested. Jim Bublitz [EMAIL PROTECTED] [1] The approach I'd favor is writing a "thin" C++ wrapper and writing Python bindings against the wrapper - the resulting bindings can be more user-friendly than the underlying API. Implementation is as a plug-in, but with access to the entire API. _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
