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

List:       kde-core-devel
Subject:    [Fwd: Suggestion about KDE printing.]
From:       Michael Goffioul <goffioul () imec ! be>
Date:       2001-08-28 13:50:58
[Download RAW message or body]

As I understood it (but I may be wrong), this is not only kdeprint-related,
so I'm forwarding it here for comments. The idea behind this is to create
an abstraction layer corresponding to a kind of "super media storage", which 
can be objects as different as a printer or a database.

I guess this implies a large rewrite of the input/output mechanism for
applications.

Michael.

"G.Richard Raab" wrote:
> 
> Howdy Michael,
>         Like your current work, but, IMHO,  it does not go far enough.
> If I could suggest again, the input and output to apps really needs to
> change. In particular, the data could be somewhat summarized as being one of
> 3 main types.
> 1) streams      - ascii files, mpeg, mpg, XML, etc
> 2) record       - database, xml, etc.
> 3) page         - png, tiff, and for the most part, printer, etc.
> 
> By coming up with an api that reflects these three types, an application
> writer could simply create three types (either using standards or their own)
> and then use filters to convert.
> You should note that the file menu would pretty much be gone. Instead a menu
> like the following might be better:
> 
> New
> ---------
> (GF)
> ---------
> (ST)
> ---------
> Get From...
> Send To...
> ---------
> Close Window
> Exit
> 
> GF and ST would be shortcut(s) that app design could initialy create, but
> then later the user could update, with more heavily used.
> At this point if Get From... or Send To... are used, then pop up a dialog
> with tabs which are actually Plugins and Filters.
> Imagine, easily sending record(s) of a CookBook to someone via e-mail, or
> perhaps easily publishing to web server. Or sending to a fax, or a printer.
> When you get right down to it, saving to a file OR to a printer, which than
> rescans the info is about the same thing. (yeah, i do know which is easier).
> 
> With this approach, you could have filters -> filter and also use new plugins.
> 
> I apologize that I do not have the time to help, but I am trying to help.
> Hopefully today or tommorow, i will have first iteration of kio_snmp. Am also
> doing a bit of playing with kwintv and ffmpeg.
> 
> > >         First off, I would like to say that I have not had the chance to
> > > look over your kde printing system however, I have been following the
> > > postings( working on start-up and gutenberg/kde project).  One of the
> > > problems with Printing and Files is that they are treated as different
> > > entities. If I could suggest instead createing a bit more abstraction so
> > > that we have stream/record/page oriented outputs. Combine this with your
> > > plugins. It is now possible to do easy Combinations/Filtering from one
> > > type to another. Also, this would allow for greater flexibilty with
> > > System design.
> > >
> > > With this fexibilty, it makes it possible to do a Send-To/Receive-From
> > > approach similar to piping.

-- 
------------------------------------------------------------------
Michael Goffioul		IMEC-DESICS-MIRA
e-mail: goffioul@imec.be	(Mixed-Signal and RF Applications)
Tel:    +32/16/28-8510		Kapeldreef, 75
Fax:    +32/16/28-1515		3001 HEVERLEE, BELGIUM
------------------------------------------------------------------

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