* Sebastian Freundt <hroptatyr@xxxxxxxxxxx> writes:
> Steve Youngs <steve@xxxxxxxxxxx> writes:
>> * Sebastian Freundt <hroptatyr@xxxxxxxxxxx> writes:
>>
>> > Steve Youngs <steve@xxxxxxxxxxx> writes:
>> >> o All of the Texinfo docs (including the FAQ) available online at
>> >> www.sxemacs.org
>>
>> > Hm, neat idea, though what do you want to see there?
>>
>> Um, HTML versions of everything you see in ./info/ of course. :-)
> Erm, PDF for example ;P
Pfft! I laugh in the face of your stinkin PDF! :-P
> [snip]
>> What I need (I think) would be:
>>
>> 1) Add a "html" target to man/Makefile to build html versions of the
>> info docs.
>>
>> 2) Add a "html-install" target to man/Makefile that allows me to
>> specify the base dir to install to.
>>
>> 3) Add some magic to my tla commit hooks to run `make html' and if
>> that rebuilds anything, run `make DIR=siteroot/docs html-install'.
>>
>> BTW, I'm talking about the tla commit hooks for my SXEmacs source
>> repo, and _NOT_ my SXEmacs web repo.
> Yeah, I've seen. You're talking about the Makefile in the man-directory.
Yep.
>> > Maybe we should come up with a tricky autoconf/automake combination to
>> > setup the website.
>> > This would be a great gift for all who planned to mirror www.sxemacs.org,
>> > too!
>>
>> Erm, why wouldn't these mirror sites simply rsync the site from me to
>> get it and keep it up to date?
> Because updating/star-merging a tla branch and doing:
> autoconf && automake -ac && ./configure && make
> is far easier _and_ would allow to have slightly different content (for
> example information about mirrors, and the like) (to be done via branches)
Ah OK, so you wish to make having tla a requirement of being a SXEmacs
web mirror? I'm sure they'll just wet themselves with excitement as
they jump at _that_.
And easier? Oh, c'mon! A simple crontab entry to run rsync each
night and it's done. Are you seriously suggesting that your
tla-automake-autoconf-configure-make is easier than that?
>> I'd be happy with `report-sxemacs-bug' doing...
>>
>> 1) Explain to the user that all bug reports must be submitted at
>> SXEmacs Issue Tracker and that `report-sxemacs-bug' will collect
>> info that they can attach to their report at the Tracker.
>>
>> 2) Collect info. stuff like Installation file, backtrace and gdb
>> buffers. And dump that into separate files in ~/.sxemacs/ (for
>> want of a better place).
> Hm, 1) and 2) do not seem that hard.
It's on my personal todo... should I mark it: "hrop's doing this"?
>> 3) Tell the user where the files are and direct them to
>> issues.sxemacs.org to finish.
> Erm, what does direct mean? Show the user a URL to go to, or use curl
> and upload a issue.sxemacs.org/cgi-bin?foo=bar&bug=12&text=kfjdkl98384
> stuff?
A neat idea, but I fear that if we do that, nobody will do the smart
thing and search for bugs before they submit. Yeah, I'm aware that
most won't do that anyway, but lets not make it any easier for them
not to. :-)
A simple "Go here: http://issues.sxemacs.org/"[1] should suffice.
>> It doesn't need to talk to our bug db at all or have any kind of
>> interface to it... yet. But, eventually it _SHOULD_.
>>
>> Eventually, users and admins, should be able to interact with our
>> Issue Tracker completely from within SXEmacs.
> Okay, maybe we should keep this in mind with every single line we
> change.
Indeed.
>> >> o A decent file/open dialog. The default is crap. It's
>> >> fucking horrible, and downright embarrassing. GTK/SXEmacs
>> >> has a half decent dialog box, surely we can code up
>> >> something nice for normal SXEmacs.
>> Is there any chance that this comment is referring also to "A
>> decent file/open dialog"? Pleeeeeeeeaaaaaaasssssee. :-)
> Nah, unfortunately not ... I've seen the file-open dialogue for
> the first time since eons when you talked about it :) I totally
> forgot how, erm, rustic this frame looks.
Hehe, now you see why I want it changed. :-)
Free beer to the person who gives us a decent dialog. You can pick up
your reward from my place any time after a SXEmacs is released with
your sexy dialog boxes. :-)
> [snip]
>> >> o Begin work on GTK2 to replace GTK 1.2
>>
>> > Hm, controversal topic. How about to just prepare for other toolkits. If
>> > we start coding to dedicatedly support GTK2, the code will look as ugly
as
>> > it does now for the various X toolkits (loads of switch()-{case}s, loads
>> > of #ifdefs).
>>
>> Good point. I agree. Although I wonder how you're going to cope with
>> multiple toolkits without using loads of switch()'s, #ifdef's and
>> friends?
> Hm, I've seen a good approach in the glyph code. There's a SXE-internal
> Übertype for glyph-images which can be easily converted to either
> gtk/gdk-pixbuf-data or XImage-data.
> Think, that'd be the way to go.
Hmm, OK. Sounds good.
> Furthermore, this guarantees that all toolkits support all features. It
> would be stupid, if we supported a toolkit which is not able to render
> a menubar, but which allows funkily-flashing-frameborder-animations.
Yes. Not supporting all features would only guarantee that the
toolkit doesn't get included.
>> > Personally I prefer to support Qt.
>>
>> Now I wonder about something... Qt generally means C++ doesn't it? At
>> least most Qt shit I've seen has been C++. Well, umm, we just dropped
>> supporting building SXEmacs with a C++ compiler.
> Erm, I dunno, I must admit :)
> I think that only the Qt parts have to be compiled with g++ and moc, the
> rest can be safely compiled with gcc and the linker does the rest.
>> There's no real problem here is there? Surely you can code Qt toolkit
>> crap in C, can't you?
> Nope, hynek says it does not work this way, it's always C++ stuff, but see
> my note above.
All I can say is that I'm not filled with confidence. :-(
>> > Possibly define a more generic wrapper around several RDBMS-APIs
>> > (sqlite, mysql, more?).
>>
>> I don't think that this is such a good idea. Lets have SXEmacs core
>> concentrate on PostgreSQL, and let some other bugger write XE lisp
>> packages for the others.
> Yeah, okay, supporting other libs is beyond my axioms here (I'm a
> mysql-hater). 't was just a test ;)
Did I pass the test? :-)
>> > And: Let's put the final version of our ToDos on the webpage. Personally,
>> > I love to that way to see projects' futures.
>>
>> I fear making promises and claims we don't live up to, especially if
>> we start predicting when these things will happen. But I do agree
>> with you, there should be something online that shows at least where
>> we'd like to go.
> Hm, having a ToDo-Pile is not even proximate to promises, in my eyes.
Unfortunately, not everyone has your eyes. :-)
Footnotes:
[1] with a `browse-url' attached extent maybe
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| I am Dyslexic of Borg. |
| Fusistance is retile. Your arse will be laminated. |
|------------------------------------<steve@xxxxxxxxxxx>---|
pgpMP9FNeJdNz.pgp
Description: PGP signature
|