Re: Running a free software project
also on xemacs-beta now.
Andy Piper wrote:
At 05:14 AM 8/3/00 -0700, Ben Wing wrote:
>1. it looks like the internal sizing code is good, but what needs to be
>fixed is
>communication between frame and widget. the frame should automatically resize
>to the root widget's size, and when the root widget later on resizes, the
>frame
>should follow. currently in `make-search-dialog' you have a bunch of kludgy
>sizes in because of this problem.
So we require explicit root sizing right now - XEmacs has a whole bunch of
similar limits
for example? xemacs explicit policy is not to have these.
and we are already doing better than default windows layout
IIRC. So I agree this is a feature that should be added at some point but
disagree that this is a 21.2 + dialogs showstopper.
this is important to fix because it is hard to create dialogs that are portable
on x and windows if you have to put arbitrary sizes in.
>2. there is no :initial-focus keyword. actually, i added this in my
>about-to-be-integrated changes, but it doesn't do anything. what it should do
>is specify the widget that gets the focus when the dialog first starts
>up. When
>no widget has this keyword, currently none have the focus, and the keys
>actually
>go to the frame below [where they get doubled!]. instead, if no widget has
>:initial-focus, then some widget should get it.
what about this? this is the single biggest missing feature making dialogs not
usable currently. i do hope you will make it a priority. i tried to look into
it myself but i am still extremely unclear on how widget
instantiation/layout/property setting works. if you could take a few hours and
write some docs on just this section, it would really really help me.
you need to add a "focusable"
>property to each widget class indicating whether it can get the focus.
Sounds reasonable. Is this the same as :active?
no. this is a per-class thing; i guess mostly it just needs to exclude static
text/images.
btw is :active implemented?
>3. keyboard accelerator specs don't work quite right. it seems that the X
>version of the widgets does accept %_ and munge in the button strings, but the
>MSW code does nothing -- you have to put &'s in to get anything. I also
>notice
Surely you mean the other way round, the X code doesn't display
accelerators but rather %_ instead. I thought you were fixing this?
i did fix it in x. but the windows code has never handled this properly.
>you have an `accelerator' keyword, which I'm not sure what it does. This
>needs
>to be cleaned up and made consistent, so that all and anything can get an
Not my keyword, its inherited from the menubar code. I don't do anything
with it IIRC. But yes this should be fixed.
>accelerator spec in it [including static text -- frequently, static text
>contains the accelerator that corresponds to the edit field or whatever that's
>next to it]. now, with some recent changes i made [calling
>IsDialogMessage[] in
>strategic places], you CAN traverse between widgets using TAB, up/down, etc.
>[although perhaps not completely correctly according to the way things work
>standardly, because there are GROUP and TABSTOP and such attributes which you
>give no control over] so it's possible that if you just get the accelerator
>munging code consistent so that the
>nice underlines get displayed, accelerators with alt will just work. but
>maybe
>not; it might require more work.
I thought that the windows implementation of these was pretty primitive -
isn't it just the order they are created. Should tab control be merged with
focus?
i don't understand what you mean.
>4. hitting ESC doesn't kill a dialog box, like it should.
Ok.
>By the way, Andy, ultimately I'd like to see us moving towards a new object
>called a glyph-instantiator. i don't know what docs i've written up and
>sent to
>you; you probably haven't gotten them, and i'll try to locate them. but the
I haven't received anything.
[glyph-instantiator stuff deleted]
This sounds reasonable but I strongly recommend that we do not do it for
21.2. The update stuff you talk about is already implemented
hmm, i do see now that you removed set-image-instance-property. that looks
good.
does it handle progress-glyph update efficiently?
so, as always,
I would like to stabilize the code and do a release rather than a rewrite.
At the very most we [you] should write the external representation
converting to vectors internally.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
--
Ben
In order to save my hands, I am cutting back on my mail. I also write
as succinctly as possible -- please don't be offended. If you send me
mail, you _will_ get a response, but please be patient, especially for
XEmacs-related mail. If you need an immediate response and it is not
apparent in your message, please say so. Thanks for your understanding.
See also http://www.666.com/ben/chronic-pain/