> a couple of months ago, we had a quite emotional discussion
> about the current state and future of the ggi project. One thing
> everybody seemed to agree on was that the project needs to provide
> more feedback.
YEEES ! And I am glad someone else mentions it. I didn't feel like whining
about it again, but
YOU ARE RIGHT ! WE LACK FEEDBACK !
> I'v repeatedly asked for features I'd like to see. Most of the time,
> there was no response or only a vague 'this could be an interesting idea'.
Yeah - sorry. I don't have the time to implement most of this stuff, but
I always gave directions on how it could be done, IIRC.
I would have liked to see that someone actually _DOES_ it.
I am pretty busy with my studies, running a business and several other
more or less important projects.
But: If you desperately need some feature, and can't get it done yourself,
just write me PM. I will try my best, then.
> I do understand that everybody here is pretty busy with other mandatory
> stuff, I'm not complaining that you don't investigate more time.
> However, I think there are a couple of things which can be improved without
> too much work. What about a task manager / todo list ?
I wonder if that would improve much. I have _POSTED_ a status report and
TODO for my schedule for a final release. I have not received _a_single_
answer ...
> http://www.ggi-project.org/who.html
Uh - that's probably outdated as hell.
> and it appears it hasn't been updated for years. I remember someone offering
> to work on the web site not so long ago. It seems the general silence
> discouraged the generous offer.
Yes. I would like to know where that disappeared as well.
> I'd take on one task or the other myself, as I need them.
That would be good. Sorry folks ... I am a bit disappointed with the support
here on the list lately ...
> However, I'd very much appreciate at least some feedback, i.e. your
Yes. Same for me. And if just for motivation. I have tried to provide
feedback to all people that showed up here and had done something.
But I can't do that for all - especially not for myself ...
> comments about whether the changes will indeed end up in the GGI code or
> not, etc.
I'll always give feedback on such things. I think I did as well for your
suggestions.
> Again, please don't get me wrong. I wish the GGI project all the best, its
> well being is in berlin's highest interest. However, its stumbling is at
> times quite discouraging.
I agree ...
O.K. - let's get something done - below is my last "TODO" I posted.
I'd really like to see some work getting done _now_.
PLEASE !
CU, Andy
Date: Thu, 28 Sep 2000 00:25:15 +0200
From: Andreas Beck <[EMAIL PROTECTED]>
To: mailing list GGI <[EMAIL PROTECTED]>
Subject: Some convenience changes.
Hi folks,
as we recently discovered that we need a new release, I finally managed to
free up a whole evening (!) to add a few convenience changes I wanted to be
in before we scare away new users by seemingly nonworking things.
Here is what I did and a few suggestions what you all could do, apart from
checking that my changes don't break anything. I'm about to commit them -
should be in CVS in a few hours.
O.K. - the changes and suggestions:
> > What we should do though is to sit down and simply test
> > as much of targets and functionality we can.
> O.K. - I'll try a complete recompile/reinstall ASAP.
+++ Works for me.
??? List: Please also check complete reinstall.
> > The structs, checkmode, consistency and findleaks programs are a good start.
--- Haven't done much on that yet. List: Please check that on all systems
--- and targets you can get a hold of. Please report any inconsistencies.
> >> * Remove _ggi_malloc and friends, use true error handling.
> > Too much work to do before release.
> Probably. A quick grep shows, that it isn't used much in the core, but quite
> some in the targets.
--- Pending. If someone with insight into the LibGGI internals has some free
--- time - get at it.
> >> * Fix the LibGGI internals so that error messages are only printed for
> >> > required sublibs.
> > Error messages for completely optional sublibs like
> > default/fbdev/kgi/genkgi.so are confusing and annoying to users. Also
> > we have some cases where a sublib probes for both devfs and old-school
> > device nodes and only mentions the devfs-style name in the error
> > message, which is also confusing.
> Yes.
+++ Fixed the devfs-style name stuff for fbdev target. Errors come in the
+++ wrong order compared to the probe, but I didn't want to risk fprintf
+++ changing the errno variable.
??? Folks: Please check that it works and doesn't cause more confusion.
--- Haven't touched the other issues yet. Anyone ? BTW: Don't remove them -
--- just make them DEBUG instead.
> >> * Make input-linux-mouse parse /etc/XF86Config.
> > This should be done, as most people have X configured properly,
> > while few have a properly configured SVGAlib.
> O.K. - I can take a stab at that one. However note, that it can be in quite
> some places. RedHat puts it in /etc/X11/XF86Config, and seemingly SuSe even
> reads ~/XF86Config or ./XF86Config - at least for root (GRRR !).
+++ O.K. - done. Hope that works right. On my XGGI setup,
+++ XF86Config is just "decoration".
??? Please test that it works. Note, that it doesn't get used, if the
??? device can be guessed by looking at /dev/mouse ...
??? I now look in /etc/X11/XF86Config and /etc/XF86Config. Anyplace else I
??? need to look for ? Just want to know about cases that aren't symlinked
??? to one of the already mentioned files.
> >> * Make input-linux-mouse ignore config files with only comments.
> > Shouldn't be too hard, and would make it possible to install an
> > example config file.
> I could take care of that while I'm at it.
+++ Done. Files will be ignored, as long as they don't sepcify a
+++ protocol.
??? Please Test
--- Someone please add a template for $(prefix)/etc/ggi/input/linux-mouse
--- with only explanatory comments in there and add it to the make install
--- stage. The file should be ignored until it is edited to reflect the
--- configuration.
> >> * Make input-mouse print a warning when too many packets are bogus.
> > Might be useful, but no showstopper.
> Yes. Just to be friendly to lusers ...
--- pending. Anyone ?
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
