Re: Show of hands

[Note: I exclude myself from the collective term `shell authors', as,
at this point, I'm more of a parasite than anything.  Also, it's 8AM
and I haven't finished my _first_ cup of coffee.]

On 8/16/07, qwilk <[email protected]> wrote:

> be. In other words, the question is what our shells have in common, because
> apart from the "alternative shell" brand name, they're all quite different
> beasts with quite different goals.

As you yourelf have enumerated below, our shells have enough in common
to warrant at least a cursory attempt at closer collaboration.

> all, in the year 2007, is there really that much to complain about for any of
> our shells? If there is, please enlighten me! ;)

Naw, not on the outside (except for siaynoq; damn thing needs a lot of
work).  The way our efforts are spread so thinly, though...  Well,
_perhaps_.

And what I have is not really a complaint, merely an observation that
there's way that would _possibly_ yield better results (less work,
faster development, etc.).  I'm not saying that shell authors haven't
done enough, and that more work is required.  And I'm not trying to
sell you snake oil or a silver bullet.  (More below).

> to bring to the table and the possible implications thereof. Neil says that
> siaynoq currently does not contain any unique code (he does not make any
> predictions for the future),

(Well nothing unique that just anyone else could use, unless they're
also doing a tiling shell rep. :D_

> asses off on fixes that might also be of interest to the rest of us. Will that
> currently varying level of commitment to such "common" issues change if we try
> to combine our efforts? How do we avoid ending up with simplex
<snip>
> the changes.txt's and source code of others as long as the rule of "credit where
> credit is due" is followed.

I understand, of course, that for established shells, the question of
`What's in it for me?' will be tricky.  After all, what I'm proposing
will almost definitely require possibly extensive changes,
structure-wise.  I realize that shell authors probably groaned when
they read my... memo (I like Mike's term. :D).  After all, we as
programmers are so used to being asked to buy into miracle solutions
that will magically make us more productive, or reduce the number of
bugs in our code, or any other incredulous claims, that we've
(rightly!) developed a tendency to roll our eyes and shirk away from
offers that sound remotely like a sales pitch for a newfangled
development style.

But, as I've mentioned earlier, what I have in mind is a not a silver
bullet that would solve all our problems in one fell swoop.  I'm not
saying shell authors should change the way they write their shells
overnight.  And I'm definitely not proposing that we abandon something
that has proven itself time and time again (passing bug fixes and
feature enhancements mostly by word of mouth, or checking out another
shell and stealing code).

A clarification, first:  As mentioned in earlier emails, mine is a
half-baked idea on a well-trodden (but empty path).  When I sent out
my first message, I had no inkling what to do next, except for the
fact that, whatever it is, it should not be dumb nor stupid.  The past
few days, I've been thinking about what exactly I'm going to propose.

Here's what I've come up with, so far: As several others have noted
(including you, qwilk), there _are_ things most (if not all) the
shells have in common, all of them basic functionalities.  Looking at
the list you've included in your message, only one strikes me as would
be needing some injection of anything shell-specific: code for the
notification area.  That is, handling the icons in the notification
area (drawing, mostly) should be shell-specific.  Everything else we
can stuff into one library we could all link with our respective
projects.  I guess one could call it a standard library for shells.

As a standard library, it should contain the most basic parts of a
shell.  If this sounds like the next version of Raptor or WinShellEx,
I apologize: that's not my intention.  What I'm thinking of is just a
library.  A DLL, or an object file, that could each link to.  Just a
collection of functions we're all writing on our own, anyway.  That
is, instead of each of us tinkering solo with our versions of
LoadShellServiceObject(), let's just put it into one file we could all
tinker with.

In a way, it's almost the same as how we've doing stuff all along.
Except, of course, that a few of our files would come from a separate
repository, with different version numbers from the rest of the
project.  But what's a few niggling details between friends, right? :D

This would even work with both modular (LS, BB, emerge, sharpE) and
monolithic (siaynoq) shells.  We're not changing anything else, we're
not requiring a new set of applications be used by the end-user.
We're not even mandating you use this implementation of that
particular feature, either.  Being merely a library, you can use or
not use specific functions as you wish.

As for the `What's in it for us?' question for shell authors...  Well,
this would enable other developers (not necessarily from the same
team) work on improvements, bug fixes, etc. we couldn't or haven't
figured out on our own.  This would let other people learn from our
code, and use it where they will.

<flamebait>We might even encourage a few VB6 programmers to switch to
*real* programming languages. :D</flamebait>

Isn't that what free software is for?
-- 
Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

__________________________________________________
Subscription options and archive:
http://www.freelists.org/list/shell-coding