The "Toggle Rulers" feature should let the user turn
on and off the rulers in the document window. It can
be accessed from the "Rulers" item on the "View" menu.
The code is probably a bit fragile w/r/t turning rulers
on and off [guilty], but getting everything to work with
as much cross-platform code as possible was the primary
goal [no small task considering the vast differences in
the various windowing systems], so this task may [will]
air some dirty laundry -- be nice and don't rub my nose
in it too much :-)
besides, how better to start the first coding POW :-)
the gory details follow.
jeff
PS. please direct questions/problems to the list rather than
me personally (i'll be on the road for the next 2 weeks and
may not be able to check email that often).
========================================================
I'd probably do this task in 3 steps:
=====================================
[1] use the existing windows and etc and simply show/hide
the ruler windows and cause the neighboring windows
to resize themselves.
[2] actually destroy/create the ruler windows as necessary.
[3] hook into the preferences mechanism so that we startup
the right way.
step 1:
=======
[] in abi/src/wp/ap/xp/ap_Menu_ActionSet.cpp, menu item
AP_MENU_ID_VIEW_RULER is bound to editMethod "viewRuler"
and status function ap_GetState_View(). this probably
doesn't require any changes, but this where everything
starts.
[] editMethod "viewRuler" is a stubbed in function in
abi/src/wp/ap/xp/ap_EditMethods.cpp. this should be
changed to turn on or off the rulers.
[] ap_GetState_View() is in abi/src/wp/ap/xp/ap_Menu_Functions.cpp
and is another stubbed function. it should be changed to return
a flag telling whether the menu item is enabled/disabled/checked/etc.
[] add a state variable in the frame class to indicate the state
of the rulers in this window -- i'm thinking that ruler on/off
should be a per-window setting. [later, we will have the
default ruler state be loaded from the preferences file.]
[for now, this should default to 'on'.]
[] note that the widget hierarchy is implemented in 2 different parts:
[1] the application-independent portions (created in
abi/src/af/xap/<platform>/xap_<platform>Frame.cpp)
[2] the application-specific portions (created in
abi/src/wp/ap/<platform>/ap_<platform>Frame.cpp)
The TopLevelWindow hierarchy looks like this:
+--------------------+
| menu |
+--------------------+
| toolbars |
+--------------------+
| document container |
+--------------------+
| status bar |
+--------------------+
The DocumentContainer hierarchy looks like this:
+-----------------+---+
| top ruler | s |
+---+-------------| c |
| l | document | r |
| e | view | o |
| f | | l |
| t | | l |
+---+-------------+---+
| scroll | x |
+-----------------+---+
[] all of the code to create the various widets is in
abi/src/wp/ap/<platform>/ap_<platform>Frame.cpp in
the function _createDocumentWindow(). study this to
identify the various parts.
[] when the top-level window is resized, the document container
takes care of resizing it's children. this will need to be
tweaked. see AP_Win32Frame::_ContainerWndProc() on win32.
with GTK, much of the autosizing is done within GTK.
[] note that the length of the scrollbars is larger than
width/height of the view when the rulers are on. some
tinkering with scroll ranges may be necessary when they
are turned off -- or rather the range calculations may
have to know about this switching.
step 2:
=======
[] actually create/delete the widgets and classes.
[] fix all the null pointer references resulting :-(
step 3:
=======
[] in abi/src/wp/ap/xp/ap_Prefs_SchemeIds.h, add a "ShowRulers"
item with default value "1".
[] query this value in the _createDocumentWindow() code on
window creation to get the default value for the per-window
state variable.
step 4: [much later]
====================
we'll add code to save the current sessions settings into
the preferences file and/or have a preferences dialog to
set default values for things and will include the ruler
visibility settings in that.
==========================================================
==========================================================
for the adventurous, a future POW just might deal with
show/hide toobars and status bar -- unless someone beats
me too it....