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

List:       kde-devel
Subject:    Re: RFC: Parallel execution paths in WorKflow
From:       "John Tapsell" <johnflux () gmail ! com>
Date:       2006-06-29 1:28:19
Message-ID: 43d8ce650606281828n749abea2o54af483a97e6d027 () mail ! gmail ! com
[Download RAW message or body]

Hi,

  More important (for me) than branching, is parallelism.

  When you have "get files" does it get all the files first, then
proceed to the next step, or does it start modifying the images as it
gets each file, thus it can be getting some files while modifying the
ones it already has so far.

  Also I'd really like to be able to watch a directory.

  Here's some use cases that I have a personal need for:

1) Watch a particular smb folder for .ps file.  Download the .ps file,
convert it to .pdf, then upload with the new pdf to the smb folder,
keeping the filename the same except .pdf instead of .ps.

2) Watch a folder for .png files (which I generate in blender).  Do
fancy cropping of the files.  Save the changed files in a different
folder.

Hmm I can't think of anything else for now.

On 29/06/06, Thomas Kadauke <tkadauke@gmx.de> wrote:
> 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 <<
>
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]