[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    RFC: Parallel execution paths in WorKflow
From:       Thomas Kadauke <tkadauke () gmx ! de>
Date:       2006-06-29 0:44:45
Message-ID: 200606290338.57286.tkadauke () gmx ! de
[Download RAW message or body]

Hello everyone,

As some of you might know, I'm the developer of the WorKflow SoC project:

http://vophercel.homelinux.org/~tkadauke/workflow.txt

(Please read this first, if you haven't done so yet.) I need to make an 
important decision, and for that I need as much input as possible. I have to 
decide between simplicity (and user-friendliness/usability) and 
feature-richness. Right now, it is not possible to actually run workflows 
yet, but the infrastructure is there.

When I started the project, I thought it was a good idea to have multiple 
paths of a workflow running in parallel, eventually meeting again to complete 
some task. The problem is, I haven't really found any good use-cases except 
that, say, you want to send 100 files to 100 different people (each one 
getting a different file). Then, it might be useful to have one path of the 
workflow figure out and edit the files, and a second path getting the e-mail 
addresses of the people. Eventually, the paths would meet at a "Send E-mail" 
command.

I see several problems with this approach:

- first, having multiple paths in parallel looks ugly in the workflow window 
(it might be possible to make that prettier, but I don't know how):

http://vophercel.homelinux.org/~tkadauke/shot08.png

- though it is not implemented yet, it will definitely look ugly when a 
command is connected to two (or more) parallel commands (in the screenshot 
the "Copy Files" command would be connected to "Rotate Images" and "Convert 
Images"). Then connections couldn't be visualized by straight arrows anymore, 
which looks bad (and the arrows could even cross each other, which looks 
plain stupid).

- Commands can have several input and output "streams", which are typed (e.g. 
file, image file, number, boolean, etc.) Two such streams can only be 
connected if the types match (or if there is a conversion between the types) 
and if the connection doesn't form a loop. It is way more complicated to 
"type-check" commands, if multiple execution paths are allowed.

- Mac OS X Automator (http://www.apple.com/macosx/features/automator), after 
which WorKflow is designed, only supports a single execution path, and seems 
to be very successful with that. Unfortunately, I don't have a Mac, so I 
can't try Automator.

To get to the point: I would like you to tell me about your daily (or 
not-so-daily) workflows you have to face on your KDE desktop. That way, I can 
figure out if it's worth to have multiple execution paths. Additionally, I 
can identify popular commands and implement them in the SoC timeframe. Please 
be as specific as possible in your reply.

Thanks in advance,
--Thomas
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]