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

List:       kde-core-devel
Subject:    Re: [Kde-pim] Commandline tools (was Re:  kabcclient in kdereview)
From:       Mark Bucciarelli <mark () easymailings ! com>
Date:       2006-08-15 16:26:08
Message-ID: 20060815162607.GA3284 () rabbit
[Download RAW message or body]

On Mon, Aug 14, 2006 at 11:20:57PM +0200, Kevin Krammer wrote:
> On Monday 14 August 2006 22:12, Mark Bucciarelli wrote:
> >
> > also wasn't that one main piece of feedback from the isv's at
> > that meeting in portland?
> 
> The Portland task for addressbook access is not very detailed,
> though I think kabcclient could handle it in any case :)
> 

IIRC, the ISV's at Portland said more command-line apps is good.
Which I a bit odd, maybe Aaron will see this and chime in.

> > can the the konsole apps be structured so they depend only on
> > qt-core?  for example, will akondi rely on anything above qtcore?
> > from qtcore, it's probably a small step to qtembedded.  ;)
> 
> :)
> 
> Sounds like a good idea.
> 
> IMHO we should make our shell access tools more consistent, ideally finding a 
> set of recommendations which can be applied to commandline-only tools in the 
> core modules as well.
> 
> Some ideas:
> - unless an indivual name is very descriptive (for example like 
> konsolekalendar) it should be prefixed with kde4, 

From the perspective of someone just using command-line tools, I
object to longer names for that case.  :P

Rather than changing executable names, I would suggest a
command-line arg that all console apps must support; say
"--konsole" (not a particularly good one) or "--theK" [1] or
probably best: "--console".  Then the gui and command-line tool
have the same name.

> maybe having a second name part according to the module, e.g.
> kde4-io-client (instead if kfmclient), maybe using
> kde4-io-copy/move/trash as convenience shortcuts

I don't have enough knowledge to comment here.  In general I
would lean toward same names for gui and console versions.

Maybe the approach Linus took with git is relevant?  I believe he
used a few executables coupled with shell scripts to, for
example, provide both "git diff and git-diff".

> - if it understand more than one command, it should have the
> suffix "-client"
> 
> - if it is such a "client", it should have an option to list
> all available commands
> 
> - it should have a man page (its similar to requiring API dox
> for libraries)
> 

+1 on man page.

> What do you think?

It would be nice to have a cmake target so I can build and run
these apps without X.

More generally, I think having suite of console apps will support
good API design, as it will create another "angle" to use the
apps from.  It will also be easier to write unit tests, and more
unit test writing will also help with API design.

m

[1] When I was booth sitter at LinuxWorld Boston, one person
continually referred to KDE as "the K."  That was pretty good for
branding--we now own the letter "K" in his head for computer
stuff.  :)
[prev in list] [next in list] [prev in thread] [next in thread]