August 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Layout support + widget fixes 24 years, 8 months

Jan Vroonhof

Andy Piper <andyp(a)san-jose.beasys.com> writes: > For customize we definitely want to use layouts, but then I think the > customize output needs completely redoing for native widgets as it is very > text-oriented......any volunteers? :) Customize would be the Big Test for > this stuff. > > i.e. for customize a lot of the text can disappear and the rest go in labels. That is exactly what I am "afraid" of. The current "text in buffers" metaphor may produce ugly interface but is consistent. It will work on TTY's and on window systems. I like the fact that you can just C-s a long file list in XEmacs, you can C-s for text in a customize buffer etc. I am prepared to loose some of this as part of interfaces with real gui elements, but I would like to try to loose at little of it as buffer. Therefore I am wary of a shift of information from buffers to glyph data. It is all-right if the glyphs are just markup, but now you can do much more than that. Jan

2 participants
1 comments

Re: Suggested addition to README.packages 24 years, 8 months

Jan Vroonhof

rpluim(a)bigfoot.com writes: > Could we add something like the following? That is OK with me, but _first_ the provide info needs to be up to date. Jan

2 participants
1 comments

web site access mechanisms (was _real_ long subject) 24 years, 8 months

john s jacobs anderson

[I tried to send to the list last night and mistakenly sent it only to Stephen. So, here it is for the list; follow-ups trimmed down. 8^)= Also, with his permission, I'll be bouncing Stephen's reply to me back to the list. The next message from me is actually from him. jsja.] "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > >>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > We're not talking about making the Web site publically writable. I > think a reasonable thing to do would be to include the Webmaster on > the Review Board, add general responsibility for documentation to his > portfolio, and help him find volunteers to do those parts of the > documentation he didn't volunteer to do. (The reason for doing this > is to have somebody who will yell about changes to the docs that screw > his stuff up.) And he can add a couple of team members as he likes as > Web staff (who would not be review board members). Is there somewhere this 'Review Board' business is explained? I've seen it referred to a couple of times and I gather it's basically the XEmacs Cabal (there is no cabal). Is this correct? I do think a Minister of Information-Dissemination type position is a good idea. That is, a person _ultimately_ (but not necessarily _personally_) responsible for the FAQ, coordinating the documentation versions and formats, announcing releases to Freshmeat and the newsgroups, evangelism and proselytizing, etc., etc. It seems like having someone do this type of stuff would be another step towards getting more developer time towards development. Or maybe the developer-type people prefer to handle this themselves? > And maybe the "last patch wins" rule should be removed for the Web > site ;-) Definitely a good idea, IMHO. 8^)= > Yes, I wonder about whether it will cause drag on design operations. > Remember, XEmacs's directory structure changes only slowly, but we can > expect that the Web site's directory structure will change fairly > often, at least for a while. Actually, the directory structure is going to change as little as I can help it, (from what it is right now). I've seen ump-teen links to www.xemacs.org during my link gathering expeditions, which was why the old mess of content is still there -- so those links don't break. > Jan> Yes, but our current problem is (or better was) one of > Jan> content, I can write all the READMEs , installation notes, > Jan> little items telling people there is know problem with > Jan> version so-and-so of the mule-base package but I have no way > Jan> of getting it to the site. > > That's true for review board members; but the rest of us will still be > limited to xemacs-patches (or something equivalent? > webmaster(a)xemacs.org?), I presume. Yes, that's a good place to send stuff that needs to go up. I plan on 24 to 48 hour turnaround for any and all submissions; just send it. Don't worry about HTML if you don't want to, I can do that easily too. Of course, if you've got access, feel free to do it yourself, also. Send me a note and let me know, or at least modify the comments in the page header. (Add another <META type="author"> tag.) > One of the points of CVS is that if you (as Webmaster) do move a file, > CVS will tell other authorized users, mostly the Review Board, that > you have moved the file. A CVS wizard could set it up so that nobody > but the Web maintainer could move files, I believe. Only the Web > maintainer should be allowed to do that kind of thing, of course. I'm not sure why this is a Good Thing. Files aren't going to move. Files might get added, content might get changed, but files won't move, because then URLs break and that's Bad. I guess the Review Board would get updates for file adds and file mods, too, but do they care? > Jan> Well, I respect your opinion and I promise to leave you alone > Jan> while you do your work. However when your work has stabilized > Jan> I would like you to consider a solution that allows multiple > Jan> people to work on the website, if need be[1]. A solution that > Jan> no longer makes the maintenance[2] of the website dependent > Jan> on one (or a few) persons time. For me such a solution is > Jan> CVS, it isn't perfect but we already have the infra structure > Jan> in place. > I would go the opposite direction. Under normal circumstances, > everybody with CVS commit access to the sources should have equivalent > access to the Web site. Eg, someone who maintains packaged Lisp > should have check-in access to a set of pages (possibly a > subdirectory, depending on how tight artistic control the Webmaster > wants to maintain) devoted to the package they maintain. Maintainers > of binary kits might also have their own pages. I respect what Jan is asking for. I also admit up front that my practical knowledge of CVS is zero (read: never used it). However, I don't see how doing what sounds like a reasonably complicated amount of work to set up CVS buys. As Stephen says, public write access, or wide-spread write access isn't all that desirable, so you're going to need some kind of submission/confirmation system, much like the current patch list. We've already got the submission/confirmation part (mail webmaster(a)xemacs.org stuff, I (or somebody else) posts it, we tell you it's posted). The only advantage to CVS would be (1) maintaining a local 'source' tree for the web site and (2) making sure two people weren't editing the file at the same time. Is that worth the effort, or is there something I'm missing? > Jan> [2] Note: That is maintenance, _not_ design. I think we are > Jan> disciplined enough to keep a make minor (but possibly crucial > Jan> information wise) changes in accordance with your style > Jan> guides if you are on that round the world trip. I don't know if I'm on 'that round the world trip', as I'm not sure what that is. I do know that if you're going to spend time laying out an intelligent and workable (IMNSHO) design, it's important to use that as consistently as possible, across the whole site. Otherwise, you end up confusing and frustrating your users. It seems as if a working solution might lie with the use of extensive SSI in the next version of the template. That way, the design, such as it is, isn't really accessible from the template, and it becomes much easier to add content, and make it apparent who the author is, etc., etc. The template can even be made publicly available for download, so that people who want to add stuff can grab it, fill it out, and send it in. Conceivably, a web interface to this could be setup which would auto-mail stuff to webmaster(a)xemacs.org. (Ohhh...that's an idea to remember, I think...) CVS-guru's: Can the CVS system check to make sure a particular feature exists in a file before it's accepted for check-in? That is, if an Author: type field is defined, can check-ins of files lacking that field be blocked? Anyway, that's about it for now, I think. Changes sent to me today didn't get made, but will be made no later than 2400 MST/1700 UTC tomorrow. Good night, john. -- ------------------------------------------------------------------------ John S Jacobs Anderson Apprentice Geek jacobs(a)azstarnet.com Journeyman Molecular Biologist <URL:http://www.treefort.org/~jacobs/> <- GeneHack:bioinfo*linux*opinion

1 participants
0 comments

Re: Layout support + widget fixes 24 years, 8 months

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > I think layouts are not the right thing for this anyway - I think you want > to use current-pixel-column to align text properly. I am not so sure about that. To give another example: Have you considered what a customize buffer would look like when it starts to use real widgets? Jan

2 participants
1 comments

Re: [SITE] make over finished(?) 24 years, 8 months

Didier Verna

Andy Piper <andyp(a)san-jose.beasys.com> wrote: > I would disagree. For MS-Windows 21.0: > Kirill wrote a *lot* of code. Ah, ok. I'm completely disconnected from the windows side. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: [SITE] make over finished(?) 24 years, 8 months

Didier Verna

Kyle Jones <kyle_jones(a)wonderworks.com> wrote: > Jonathan Harris is also missing. I think he made significant > contributions to the Windows port; he was invited onto the review > board for this reason. I'm also surprised to see Kirill in the list. IIRC, he's done pretty good hackery and was a very competent guy, but I don't think that his contributions compete with the other people's listed there. Most important though, he completely disapeared long ago. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

2 participants
1 comments

Re: XEmacs has just (more than) doubled in size 24 years, 8 months

SL Baur

Andy Piper <andy(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: > At 02:26 PM 8/20/99 +0900, SL Baur wrote: >> I've only been running the new version a few minutes, but the gutter >> is _greatly_ improved over a few days ago. I still don't understand >> why some displayed buffers get a button and others don't though. The strangeness has returned as I've been running for awhile. > All buffers should have a button. Please tell me ones that don't In the *Group* buffer I saw only one button named `*sent wide reply to Ge...'. I entered my xemacs-beta group and saw a single button named `*sent wide reply to Ja...'. I am now in a message buffer with a single button named `*sent wide reply to St...'. Here is what the output of C-x C-b currently looks like: MR Buffer Size Mode File -- ------ ---- ---- ---- .* "*wide reply to Andy Piper on xemacs-beta(a)xemacs.org*" /usr/users/steve/News/drafts/drafts/72 *%"*Summary nnml:xemacs-beta*" 16298 Summary *%"*Article nnml:xemacs-beta*" 2602 MIME-View % *Group* 5290 Group *scratch* 197 Lisp Interaction 21.2-setup.el 786 Emacs-Lisp /usr/users/steve/21.2-setup.el "*sent wide reply to Andy Piper on xemacs-beta(a)xemacs.org*" /usr/users/steve/News/drafts/drafts/66 "*sent wide reply to Stephen Tse*" 1 /usr/users/steve/News/drafts/drafts/67 "*sent wide reply to Stephen J. Turnbull*" /usr/users/steve/News/drafts/drafts/68 "*sent wide reply to Jan Vroonhof*" /usr/users/steve/News/drafts/drafts/70 "*sent wide reply to Gerald Gutierrez on xemacs-beta(a)xemacs.org*" /usr/users/steve/News/drafts/drafts/71 .dgnusrc-newshost-dribble 0 Fundame /usr/users/steve/.dgnusrc-newshost-dribble * "*Buffer List*" 979 Fundamental I would expect `*Summary nnml:xemacs-beta*', `*Article nnml:xemacs-beta*', `*Group', `21.2-setup.el', `*scratch*', and `*Buffer List*' to have buttons.

4 participants
9 comments

Re: package-get.el : package-get-user-package-location 24 years, 8 months

Jan Vroonhof

sperber(a)Informatik.Uni-Tuebingen.De (Michael Sperber [Mr. Preprocessor]) writes: > No, this one should not go into a package hierarchy at all. The > package index transcends package hierarchies, doesn't it? It is a data file. It should be locatable like any other data file. I have my copy in $prefix/lib/xemacs/site-packages/etc and I want it to be able to find it. > Jan> Ok, the problem here is that the directories in data-directory-list > Jan> can magically appear. > > I don't understand this. `data-directory-list' is set at startup. > Nobody is supposed to mess with it afterwards. Yes, but it is _dynamically_ set up at startup. If I save a file (in 21.1) to ~/.xemacs/etc, locate-data-file will pick it up after a restart even if ~/.xemacs/etc wasn't there before. I think part of the problem is that ~/.xemacs/etc $prefix/lib/xemacs/site-packages/etc are not really package directories (since they are not part of any packages), but they are still the canonical place to stick data and it is the package startup code that finds them. I think that is part of what you were saying here > It is only currently "necessary" because there's no clear > organizational coherence between search paths and installation > directories. I tried to clean up the pre-21 mess as best as I could > without breaking backwards compatibility. This problem really needs a > general solution sufficiently factored to package-get can simply *use* > it. Jan

1 participants
0 comments

M-x find-function and dumped lisp 24 years, 8 months

Jan Vroonhof

> /root/xemacs-21.1.4/lisp/files.elc > > What's the problem ? > Error in configure ? No. The problem is that files.elc is dumped in. M-x find-function looks at load-history to see where the file came from. However for dumped lisp the load-history contains the path at the dump time! Thanks for spotting this bug. Jan

1 participants
0 comments

Re: XEmacs has just (more than) doubled in size 24 years, 8 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > In X11, an unmapped window can't receive events at all because it's > invisible. Except for the fact that various event queues can create race condition where this the case. The crash I have been helping Ulrich with is exactly that. Jan

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta August 1999