SV: Re: Show of hands

--0-952620055-1187093571=:71445
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Sounds good to me.

Neil Santos <[email protected]> skrev:  On 8/14/07, Mike Novia wrote:

> After re-reading that memo, sounds like a really good plan to build
> an SDK/Engine for shell coding? Im not the greatest coder, so
> handling all the hard parts are hard for me. I have more fun working
> on themeing engines, and the fun details. If anyone is interesting
> in building a project, I would love to help!

Honestly, I didn't have any specific plans when I sent that in. All I
knew at the time is that it seemed like a good idea to bring together
all the active dev teams (there being so few) and poll our resources
together to work on new stuff, and make it easier to share code for
old stuff.

For example, Chris is trying to get emerge and Vista to play nicely
with each other. I'm sure it's pretty likely that sharpE and LiteStep
are running into the same problems emerge is on Vista. That's a lot
of duplicated effort.

It's alleviated somewhat by everyone stealing code from everyone else.
But that makes the cycle a bit too long, and design decisions that
could make the code cleaner/more efficient/faster/whatever, had there
been a bigger pool of talents working together, take much longer to
get into other shells.

I've heard tell that Jaykul is working on a Vista-only shell. I'm
sure all shell dev teams can benefit from anything Jaykul comes across
in trying to do that, and vice versa. I've no interest in Vista
myself, but from what I read in emerge's forums, there're some pretty
nice problems to be dealt with on that platform (hooks and DDE support
being broken, among others).

Traditionally, here's how the whole I-steal-your-code-you-steal-mine
scenario works: dev team for shell A gets some problem on platform X
fixed. Dev team for shell B, having been working on the same problem
for some time now, sees the fix in shell A and steals it. In the
process, they incorporate changes that make that particular piece of
code cleaner/faster/more efficient. Shell A's dev team, having been
continuously working on said code snippet since the last commit, comes
up with something almost the same as what shell B's dev team has come
up with.

Duplicated effort.

What's the turnaround on a scenario like this? A couple of weeks?
Maybe a month?

I guess what I have in mind is sort of a supercharged amalgam of
shell-coding and WinShellEx. WinShellEx is a pretty good idea, but it
failed to take off. Part of it may be the fact that there are so few
shell reps available today (I remember when I routinely developed
headaches just trying to figure out which shell to try out in a
particular week). Maybe it's the NIH syndrome at work.

Personally, I haven't touched (or even looked at) WinShellEx (even
supposing its code is available) because it's a separate application.
One of my intended selling points for siaynoq is the fact that it's
small (needs about a megabyte to run) and light; having an old PC with
less RAM than most of the newer video cards, that characteristic is
important for me to preserve.

I guess I'm aiming for a sort of common repository for code used in
all the extant shells. Notification area, startup items, DDE, maybe a
VWM. It should be in the form of a library, with anyone able to join
in its development. So, the scenario becomes: shell A's dev team
fixes a problem with the notification area under platform X; they then
commit it to the common repo. Shell B's dev team takes the code,
makes it better, and commits. Shell A will have it the next time its
dev team integrates the changes.

I'm sure it won't be as easy as that the first time around. It'll
require possibly extensive changes on the each shell's development
cycle. That's why I've opened this discussion first, to flesh out
details, instead of starting work on it and then expect others to use
it immediately.

But I think it'll be worth it. If it'll cut the time we each spend on
worrying out mundane details, enabling us to work more on actually
interesting stuff (like, maybe, Mike's idea of a common theming engine
for skinnable shells), then it'll prove to be worth the effort.

We each steal code from each other (well, maybe not from me; I'm a
leech. :D) and then integrating it into our respective shells, anyway.
Why not make it easier to collaborate and get better quality code?

What do you guys think?

(I've got to stop writing stuff like this on my first cup of coffee,
and right after I wake up, at that.)
--=20
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



      =20
---------------------------------
S=F6k efter k=E4rleken!=20
Hitta din tvillingsj=E4l p=E5 Yahoo! Dejting: http://se.meetic.yahoo.net
--0-952620055-1187093571=:71445
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Sounds good to me.<BR><BR><B><I>Neil Santos &lt;[email protected]&gt;</=
I></B> skrev:  <BLOCKQUOTE class=3Dreplbq style=3D"PADDING-LEFT: 5px; MAR=
GIN-LEFT: 5px; BORDER-LEFT: #1010ff 2px solid">On 8/14/07, Mike Novia <MI=
[email protected]>wrote:<BR><BR>&gt; After re-reading that memo, soun=
ds like a really good plan to build<BR>&gt; an SDK/Engine for shell codin=
g? Im not the greatest coder, so<BR>&gt; handling all the hard parts are =
hard for me. I have more fun working<BR>&gt; on themeing engines, and the=
 fun details. If anyone is interesting<BR>&gt; in building a project, I w=
ould love to help!<BR><BR>Honestly, I didn't have any specific plans when=
 I sent that in. All I<BR>knew at the time is that it seemed like a good =
idea to bring together<BR>all the active dev teams (there being so few) a=
nd poll our resources<BR>together to work on new stuff, and make it easie=
r to share code for<BR>old stuff.<BR><BR>For example, Chris is trying to =
get emerge and Vista to play nicely<BR>with
 each other. I'm sure it's pretty likely that sharpE and LiteStep<BR>are =
running into the same problems emerge is on Vista. That's a lot<BR>of dup=
licated effort.<BR><BR>It's alleviated somewhat by everyone stealing code=
 from everyone else.<BR>But that makes the cycle a bit too long, and desi=
gn decisions that<BR>could make the code cleaner/more efficient/faster/wh=
atever, had there<BR>been a bigger pool of talents working together, take=
 much longer to<BR>get into other shells.<BR><BR>I've heard tell that Jay=
kul is working on a Vista-only shell. I'm<BR>sure all shell dev teams can=
 benefit from anything Jaykul comes across<BR>in trying to do that, and v=
ice versa. I've no interest in Vista<BR>myself, but from what I read in e=
merge's forums, there're some pretty<BR>nice problems to be dealt with on=
 that platform (hooks and DDE support<BR>being broken, among others).<BR>=
<BR>Traditionally, here's how the whole I-steal-your-code-you-steal-mine<=
BR>scenario works: dev team for shell A
 gets some problem on platform X<BR>fixed. Dev team for shell B, having b=
een working on the same problem<BR>for some time now, sees the fix in she=
ll A and steals it. In the<BR>process, they incorporate changes that make=
 that particular piece of<BR>code cleaner/faster/more efficient. Shell A'=
s dev team, having been<BR>continuously working on said code snippet sinc=
e the last commit, comes<BR>up with something almost the same as what she=
ll B's dev team has come<BR>up with.<BR><BR>Duplicated effort.<BR><BR>Wha=
t's the turnaround on a scenario like this? A couple of weeks?<BR>Maybe a=
 month?<BR><BR>I guess what I have in mind is sort of a supercharged amal=
gam of<BR>shell-coding and WinShellEx. WinShellEx is a pretty good idea, =
but it<BR>failed to take off. Part of it may be the fact that there are s=
o few<BR>shell reps available today (I remember when I routinely develope=
d<BR>headaches just trying to figure out which shell to try out in a<BR>p=
articular week). Maybe it's the NIH
 syndrome at work.<BR><BR>Personally, I haven't touched (or even looked a=
t) WinShellEx (even<BR>supposing its code is available) because it's a se=
parate application.<BR>One of my intended selling points for siaynoq is t=
he fact that it's<BR>small (needs about a megabyte to run) and light; hav=
ing an old PC with<BR>less RAM than most of the newer video cards, that c=
haracteristic is<BR>important for me to preserve.<BR><BR>I guess I'm aimi=
ng for a sort of common repository for code used in<BR>all the extant she=
lls. Notification area, startup items, DDE, maybe a<BR>VWM. It should be =
in the form of a library, with anyone able to join<BR>in its development.=
 So, the scenario becomes: shell A's dev team<BR>fixes a problem with the=
 notification area under platform X; they then<BR>commit it to the common=
 repo. Shell B's dev team takes the code,<BR>makes it better, and commits=
. Shell A will have it the next time its<BR>dev team integrates the chang=
es.<BR><BR>I'm sure it won't be as easy
 as that the first time around. It'll<BR>require possibly extensive chang=
es on the each shell's development<BR>cycle. That's why I've opened this =
discussion first, to flesh out<BR>details, instead of starting work on it=
 and then expect others to use<BR>it immediately.<BR><BR>But I think it'l=
l be worth it. If it'll cut the time we each spend on<BR>worrying out mun=
dane details, enabling us to work more on actually<BR>interesting stuff (=
like, maybe, Mike's idea of a common theming engine<BR>for skinnable shel=
ls), then it'll prove to be worth the effort.<BR><BR>We each steal code f=
rom each other (well, maybe not from me; I'm a<BR>leech. :D) and then int=
egrating it into our respective shells, anyway.<BR>Why not make it easier=
 to collaborate and get better quality code?<BR><BR>What do you guys thin=
k?<BR><BR>(I've got to stop writing stuff like this on my first cup of co=
ffee,<BR>and right after I wake up, at that.)<BR>-- <BR>Reclaim your digi=
tal rights, eliminate DRM, learn more
 at<BR>http://www.defectivebydesign.org/what_is_drm<BR><BR>______________=
____________________________________<BR>Subscription options and archive:=
<BR>http://www.freelists.org/list/shell-coding<BR><BR></BLOCKQUOTE><BR><p=
>&#32;


      <hr size=3D1><table><tr><td>S=F6k efter k=E4rleken! <br>Hitta din t=
villingsj=E4l p=E5 Yahoo! Dejting: <a href=3D"http://se.meetic.yahoo.net"=
>http://se.meetic.yahoo.net</a></td></tr></table>
--0-952620055-1187093571=:71445--

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