Re: Quick question... Is this project dead?!

On Mon, Jan 17, 2005 at 10:25:33PM +0000, Phil wrote:
> I agree with everythig you said.  I don't actually want to manage this 
> project -- I have a problem with people bossing me around in my spare 
> time, and I am not yet hypocritical enough to boss others around in theirs.

I would say the same thing more formally: as an anarchist and
Discordian, I do not believe in heirarchial authority structures as
viable, sensible, efficient, worthwhile, or anything but a determined
attempt to control society. Free software projects certainly don't
need them; I have never heard of a successful project with one.

> I think the worst things to happen so far were the slashdottings, as 
> they seem to have implied that Y was ready for end-users or application 
> developers when that is not the case.

And, to make it doubly bad, the sort of people who slashdot collects
are the sort of people who believe what they read on slashdot. Useful
people invariably know better than that.

> In the interests of improving communication I'm putting my Y-windows 
> to-do list on Teh IntarWeb:
> 
> http://willerz.org/articles/Y-todo.art

 Extend/replace back-end rendering functionality to have 8- 16- and
 32- bits/channel/pixel renderers instead of the current 8-bpcpp-only
 system. The backend will look at the elements to be composited onto
 any given pixel and use the fastest bpcpp renderer with a depth >=
 the largest depth element.

That code probably needs tearing down and rewriting anyway, it's
mostly still the prototype stuff.

 An application (and supporting backend code) to display JPEG and
 Canon RAW format images. This includes resizing/resampling the images
 so that they fit on the physical screen.

I'd suck in libMagick (from imagemagick) and let that do all the grunt
work. It should support any still image formats you can shake a stick
at, and it has all the interesting transformations already. Not sure
offhand whether to load it server- or client-side. Maybe it would be
worthwhile to construct a widget that does *both*, and lets user-level
server configuration pick which way to use (I have some plans for how
this part will work; it's needed for just about everything and will
probably be critical in the long run); I can think of scenarios where
both forms would be useful.

> In particular, if you think that doing somehting else first will 
> make one or more of those tasks simpler/easier/better I would like to 
> hear about it.

None of these significantly touch any of the chunks of core
architecture on my list. Everything behind the rendering API *should*
be fairly stable by now - that was the focus of the prototype, after
all.

Don't bother spending much time on updating the theme layer though,
beyond hacking it to fit the API changes. It will probably have to be
scrapped and redone from scratch.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFB7Ns+lpK98RSteX8RArntAJ9xLde7PLge8RmRDb+yX6gKObvzmgCfZm9O
Fj0yDuevhSHuRmK0moxtfsk=
=URO8
-----END PGP SIGNATURE-----