[PyKDE] Enterprise Desktop - Scripting

[Jim Bublitz]

On Tuesday December 16 2003 22:05, Kaleb Pederson wrote:

[replied to PyKDE list only]

> On Tuesday 16 December 2003 12:21 am, Jim Bublitz wrote:
> > 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.

> As this has been an annoyance of mine for a couple of years, I
> would definitely have to agree.  I was hoping that as QSA
> became more stable we would start to see pervasive scripting
> capabilities.  An example, although non-kde, would be the
> ability in gimp to make a selection, then record the different
> steps that you wanted applied to any selection.  Similarly, in
> KSpread, the ability to select a bunch of cells, and then
> record a bunch of actions.  These, although extremely simple,
> would help a lot for many different situations that I run into
> frequently - and I doubt that I'm alone in this area.

Macro-recording is definitely a nice feature - I don't believe 
OpenOffice has that ability either (just checked and couldn't 
find it).  That requires modifying the API as opposed to a 
scripting plugin that "knows" the API - it would probably be 
easier if done in C++ but if the Python interface was 
sufficiently integrated, it could probably be written in Python 
too. It requires grabbing kbd and mouse events. Some extension 
of the "activated()" signal from KAction might be all that's 
needed (activated() itself might be sufficient if you can 
identify the sender adequetely).

Once you have the recording capability though, if the Python 
plugin wrapper has all of the menu/kbd/mouse actions available 
(which is basically how I did it), it should be possible to dump 
the macro as a Python script, which can then be run or edited.

That's beyond what I've done with KSpread, and I'm not sure where 
the hooks would best be to accomplish this, but conceptually it 
doesn't seem that hard to do.

> I haven't done any kde programming (strictly qt so far), so I
> can't say whether or not DCOP is going to be easily scriptable
> or not, but I would think that we could use the command design
> pattern to grab actions.  If everything were done using
> signals, we could have a manager of a sort that keeps a
> history of all the actions and "records" them or something of
> that sort.  This is quite simplistic, but recording and
> playing back would be a large improvement over nothing. 
> Obviously, we would still want to make part of the API public
> and allow the users to make their own choice to support strong
> scriptability.

I'm not as familiar with DCOP as I should be to criticize it, but 
it seems to me to be a programmer's interface rather than a 
user's interface. For example, I would bet that to select a 
cell, you need it's integer row and column co-ordinates, while 
what the user sees is a letter column and numeric row 
co-ordinate. I would want to select cell "AQ34" and not have to 
compute the column for "AQ" (or do things like "A1:B6" to 
select/operate on a group of cells, or "A:" or "3:" for an 
entire column or row). The hack I did for an older version of 
KSpread did that. Similarly, it's nice to have relative 
addressing in some cases.

The one DCOP example I've played with (setting volume level in 
noatun) requires you to figure out that the volume setting is an 
integer between 0 and 100 - not real hard to do, but also not 
documented anywhere. DCOP also presents problems with both 
constructing and/or marshalling arguments from Python/PyKDE.

What I'd want to be able to do is:

sheet = KSpread ("somepath")
sheet.moveto ("A1")
sheet.select ("A1:B6")
sheet.copy ()
sheet.moveTo ("D17")  [or down (16); right (3)]
sheet.paste ()
x = sheet.cell ("C3").value ()

which isn't difficult to accomplish, including setting cell 
values, formatting, etc. I'd think DCOP would be able to do 
this, but probably not as clearly/easily.

> > 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]
>
> There are many choices here.  I would love to see support for
> Python as the KDE scripting language as it is powerful and
> could well represent the current structure of the KDE project
> (aside from multiple inheritance of Qt based classes, which
> probably isn't extensively used?), but I'm probably biased as
> I have done quite a bit of PyQt development.  We could use
> QSA, or something similar, but I'm currently in no position to
> comment on its pros or cons.  We could create our own language
> (why)?

On one level, I'd just like to see scriptability, even if it's in 
some godawful language I don't know like Scheme or Haskell 
(although QSA, Perl, Ruby, Python seem the more logical 
choices). On another level, there are  a lot of advantages to 
Perl and Python because of the extensive libraries, frameworks 
and apps they make available. And of course ultimately my 
opinion is that Python wins for readability, ease of learning, 
and other "newbie-friendly" reasons.

> > 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 think KDE definitely needs to pay attention to scriptability
> in the future, and this already may be slated as I haven't yet
> checked.  Whatever the future holds, I would hope that it is a
> language much more capable than VB up to version 6 anyway.

I'm not an expert on the politics of all of this, but it seems to 
me that UserLinux, RH, and Novell (who owns Ximian and just 
bought SuSE) all lean towards Gnome, while Sun is pushing OO.o 
and their Java Desktop, which leaves Mandrake as the distro 
really supporting KDE (Debian, Gentoo, Slackware, etc seem 
relatively neutral). It seems to me KDE needs to become more 
clearly compelling, and one answer to that problem is to have a 
pervasive full-blown VB alternative.

> So where do you, the kde developers, place scriptability? 
> What would you like to see happen?  What will it take to make
> it happen?

That's my question too, and I think it needs some kind of visible 
support from KDE itself to really "happen".  At a bare minimum, 
it needs to be "blessed" by KDE and integrated into KDE releases 
somehow. To happen soon, it's also going to require resources 
and project mgmt/leadership.

Jim