even more KProcess (Re: Ouch?)

[Marc Mutz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 20 February 2004 04:05, Oswald Buddenhagen wrote:
<snip>
> you can. but i plan to nuke NoRead in kde4 anyway and replace it with
> something proper (that does not try to circumvent the design rule of
> slots not returning anything). that needs some thought; i'm not sure
> a proper callback (that is, a virtual) does not cause too much
> inconvenience.

You just outed yourself as a KProcess-knowledgable person, thank you. Do 
you mind having a look at
  kdepim/certmanager/lib/backends/qgpgme/gnupgprocessbase.{h,cpp}
and tell me if I've done everything right? The API docs of KProcess are 
- - well - sparse.

> btw, i'm pondering with the idea of merging KProcIO into KProcess and
> adding a Buffered flag to disable it. given the repeated questions on
> the lists, this looks like a natural step to me.

Speaking as one who just spent a few hours with KProcess: It's API is 
seriously overloaded with convenience stuff that someone hacked into it 
(PTY, anyone?) and that would be better placed in a subclass. The 
points to extend the class via subclassing are there, you just need to 
find them (commSetupDone{P,C}(), setupCommunication(), which makes a 
good point for using the "virtual" keyword only for methods explicitly 
meant to be reimplemented, and not for all methods, Java-style, BTW). 
Instead of putting yet more stuff into poor KProcess, I'd suggest 
introducing _more_ subclasses to let the base API stand out more.

And a hook into start() before argument processing would be nice. As it 
stands, start() needs to be reimplemented too often, breaking the 
otherwise nice Template Method pattern.

Just because a subclass can be merged into the base class by introducing 
a few if()'s or switches, it doesn't mean it's a good idea. You can 
_always_ do that. I think that merging KShellProcess into KProcess was 
an error design/API-wise. Renaming KProcIO into KIOBufferedProcess 
would go a longer way to make these classes easier to use than merging 
them, IMHO.

I understand that combining the funtionality of these subclasses so they 
can be used together is the driving force here, but creating a monster 
API a la KListView should be avoided. Perhaps by using an 
aspect-oriented approach. Carsten? Or by classic Decorators.

Marc

- -- 
"Similia similibus curentur"
           -- Bush's new motto in fighting terrorism.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.4 (GNU/Linux)

iD8DBQFANd5I3oWD+L2/6DgRAveqAJ9T1pOCD28tiqxVHz6b4CCUnT9vpgCglkfy
4FfuWiLnw2iK4LuDCjtrhMQ=
=Eg6t
-----END PGP SIGNATURE-----