apply in the abi directory via
gunzip -c patch.gz | patch -p1
As of this writing, everything should compile under unix/gtk on the most
recent CVS version.
I've not checked it against the Windows verion, but I do have all (or atleast
most) of the functions stubbed.
New Features
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
unix/ut_dialogHelper
createAcceleratorLabels ( GtkWidget * ) - scans a window and turns all &'s
into underscores and assign accelerators to that control.
- currently only works for buttons and checkboxes
Options Dialog
- Spelling tab
Enable/Disable AutoSpellCheck
Ignore capitalized words works both for autocheck and vie the
spell dialog
- Defaults button
PrefsListener
API is created and used by fl_DocLayout to turn on/off spell checking
options
WP Preferences
added the following preference keys/values
SpellCheckCaps="1"
SpellCheckInternet="1"
SpellCheckNumbers="1"
Files Changed
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
A wp/ap/beos/ap_BeOSDialog_Options.h
A wp/ap/beos/ap_BeOSDialog_Options.cpp
A wp/ap/unix/ap_UnixDialog_Options.h
A wp/ap/unix/ap_UnixDialog_Options.cpp
A wp/ap/win/ap_Win32Dialog_Options.h
A wp/ap/win/ap_Win32Dialog_Options.cpp
A wp/ap/xp/ap_Dialog_Options.h
A wp/ap/xp/ap_Dialog_Options.cpp
M af/util/unix/ut_dialogHelper.cpp
M af/util/unix/ut_dialogHelper.h
M af/xap/xp/xap_Prefs.cpp
M af/xap/xp/xap_Prefs.h
M text/fmt/xp/fl_BlockLayout.cpp
M text/fmt/xp/fl_BlockLayout.h
M text/fmt/xp/fl_DocLayout.cpp
M text/fmt/xp/fl_DocLayout.h
M wp/ap/Makefile
M wp/ap/unix/Makefile
M wp/ap/unix/ap_UnixDialog_All.h
M wp/ap/win/Makefile
M wp/ap/win/ap_Win32Dialog_All.h
M wp/ap/xp/Makefile
M wp/ap/xp/ap_Dialog_Id.h
M wp/ap/xp/ap_Dialog_Spell.cpp
M wp/ap/xp/ap_EditMethods.cpp
M wp/ap/xp/ap_Prefs.cpp
M wp/ap/xp/ap_Prefs_SchemeIds.h
The status of the different points is listed below.
On Tue, Oct 19, 1999 at 11:04:38AM -0500, Jeff Hostetler wrote:
> cool dialog !! before we check it in, i'd like to get you to
> fix a few things first, if that's ok:
>
> [1] remove all the #if 0'd code from the dialog that was cloned
> (the #if 0'd debug blocks are cool and should be kept)
done
> [2] add strings to the string table for each of the dialog static
> text fields (see abi/src/wp/ap/xp/ap_String_Id.h) and then
> reference them in the various window_title and button_label calls
> (this will let us internationalize them quickly)
> (see one of the other dialogs for code snippets)
Not started. Reason behind this is that I've been focusing on functionality
initially. Once the dialog gets into CVS, patchs would be much simpler.
> [3] update calls to prefs to use new Bool methods :-)
done
> [4] down with the OK and Cancel buttons, I'd like to have a
> "restore factory settings" button -- which would set the
> current scheme back to _builtin_ and nuke any other schemes
> in memory.
The button is there and works as expected. (although, it does not nuke any
'other' scheme in memory)
> [5] you made the options dialog inherit from non-persistent
> rather than app-persistent -- i'm wondering if there it would
> be better to do app-persistent -- for example, this would let
> it be able to come up the second time on the same tab as was
> up when the user closed it the first time....
I wanted to get a functional dialog before making some of the major changes.
Should not be too hard though.
> longer term, i'd also like to have a "save settings" button next
> to those 3 buttons -- which would write the current settings to
> disk, but i don't know how that would interact with the way we
> write the file on exit and the auto-save bit that we carry
> around -- this whole area probably needs to be re-thought, so
> let's wait not try to do it now....
no change in my current AutoSave implementation - save. tbd
> (paul will veto this one, i'm sure :-) much longer term, i'd like
> to see an 'advanced' tab which would let me pick a name for the
> 'custom' scheme and have a combo box of all the schemes defined.
> this way, i could keep track of several schemes -- say, one for
> english, one for german, and one for weird testing... and easily
> switch between them (like i do now by editing the file).
currently have some of the controls in place, but disabled.
> ===================================================================
>
> w/r/t PrefsListener API, i'd vote for simplifying it some -- it's
> a very low frequency event (like when the user hits OK on the
> new dialog or toggles something from the menu), so i don't think
> we need the complicated pattern matching stuff.
> i'd suggest a simple "tell me when anything changes" listener
> and put the responsibility on the actual listener to query
> the values it cares about and do the right thing. that way, the
> pref code can just send one message to each listener. and each
> listener can be rather simple. [one could probably use the same
> words in the last 2 sentences to describe the proposed method :-)
> but my assertion is that simpler is better and each listener
> should have already internalized the value(s) of the pref keys
> that it's interested in and can quickly and easily re-fetch and
> compare them and quickly return if there's nothing for it to do.]
>
> we may need to have some kind of suspend-/resume-notifications
> method in the prefs, so that the options dialog can set a bunch
> of values in a batch and then have one notification go out --
> incase setting them individually after the dialog goes down
> causes too much flashing.... but we can wait on that.
currently, a hash table of changed keys is update, but not used.
There is a suspend and resume function pair.
> ===================================================================
>
> w/r/t the code to change win32 "&" into gtk "_" on dialogs,
> yes it is unfortunate that the class hierarchy goes:
> (generic-dialog-->specific-dialog-->specific-platform-dialog)
> and not:
> (generic-dialog-->generic-platform-dialog-->specific-platform-dialog)
> [rather it's unfortunate that we can't inherit both ways at the
> same time, because we really need the inheritance the way i have it.]
> because this does cause problems for unix which needs to hang
> extra (platform-specific but generic) helper functions on each dialog.
> shaw has been collecting them in abi/src/af/util/unix/ut_dialogHelper.*
> can your new routines be folded into there ??
It's in and works.