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

List:       koffice-devel
Subject:    Re: gSoC ideas?
From:       Sebastian Sauer <mail () dipe ! org>
Date:       2007-03-08 4:21:48
Message-ID: 200703080521.49079.mail () dipe ! org
[Download RAW message or body]

Robert Knight wrote:
> Sebastian, I think I may have missed some earlier discussion.  What
> does OO.org have to do with mono?

Ah, I guess you where talking about the OpenXML stuff that seems to be shiped 
just today. While I still miss the part at my fav news-portals that says, 
that the Novell OpenXML<=>OpenDoc impl does depend on Mono, it seems I 
missinterpreter your prev mail then :)

> What I had in mind was somewhat simpler:
> 
> 1.  User selects file in unsupported format.
> 2.  KOffice offers to use a 3rd party tool to produce an ODF document
> 3.  KOffice runs that tool in the background and loads the ODF
> document when finished.
> 
> Where "3rd party tool" is a simple command-line program with syntax such
> as:
> 
> ooconvert -i input.docx -o output.odf
> 
> All KOffice needs to know is:
> 1.  Name of the 3rd party tool
> 2.  What formats the tool is expected to be able to handle
> 3.  Syntax for running the tool ( probably a string in the format
> "%NAME% -i %INPUTFILE% -o %OUTPUTFILE%" for example )
> 4.  Name of the generated ODF file given the input filename.
> 
> The process for saving the document would be similar.  Save as ODF by
> default and provide easy access to 3rd party tool to do the conversion
> to a different format.
> 
> No linking with additional external libraries, no code dependencies on
> anything outside of KOffice.  Quite do-able in a couple of months I
> should think, IF (and this is a big IF) the 3rd party tools exist or
> are simple to create.

What sounds like a good idea but I would not agree about the timeframe cause 
to get such a thing written may need even with bunches of tests+documentation 
not more then 2 weeks im(h)o. On the other hand, the points above do not name 
anything related to the question how this could be configured (GUI) and I 
also ask myself what the second point may include (create a "whitelist" for 
tools + the needed args for them? and/or let the user configure it somehow as 
point 3 indicates?).

I guess it may need not long cause KDE ships with powerful possibilities to 
run processes already. While it's somewhat strange that nobody did wrote such 
a tool before - or maybe I just did miss it and it already exist somewhere? 
maybe it works already by using one of the commandline-apps? - I guess the 
code wouldn't be that much and only contain some basic functionality using 
KRun (or to whatever if was renamed in trunk if it was renamed at all), build 
upo the string that should be executed, moving files around / let e.g. KWord 
load the result.

But business as usual I may absolutly wrong here or still just didn't 
understood it correct. So, if you guess it's a good idea and that there exist 
the possibility to get approved, then go for it :)

-- 
Sebastian Sauer aka dipesh[sebsauer]
http://www.dipe.org/public_key.asc
Fingerprint: 8F1E 219B 16E6 4EC7 29CC F408 E193 65E2 9134 2221
Coder in http://www.koffice.org && http://www.kmldonkey.org
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]