Re: Running a free software project
At 02:21 AM 8/9/00 -0700, Ben Wing wrote:
> 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.
FI popup width and height are hardcoded in frame-msw.c, you can only change
them through explicit sizing.
> 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.
Don't get me wrong - I'm not saying this isn't desirable I just don't see
how its any worse than, say the current frame sizing we have under X and
mswindows. And moreover the widget code and frame size all work in
character sizes (although pixel sizes are possible) so I don't think the
portability issue is such a big deal.
>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.
My comment indicated agreement with this also - I just didn't communicate
it effectively.
> 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.
How would you specify per-class things?
btw is :active implemented?
Mostly under mswindows, not sure about X.
i did fix it in x. but the windows code has never handled this
properly.
Oh, ok.
> 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.
I though tab grouping under mswindows is simply a matter of putting the
TABSTOP property in and creating the widgets in the right order - you can't
explicitly add widgets to a particular group, you would have instead to
give them a common parent.
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?
You judge - the progress gauge is using it right now. I don't think it
flickers under mswindows although the flicker under X is down to the X
widget implementation itself I believe. There are optimizations to only
update what has changed if that's what you mean - yes.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd