Also, the widgets from the 'Palette' cannot be selected and placed on
say a window with the keyboard. 

I have had a look at what happens for some of the widgets in the
Widget notebook page.

When focus is on the GtkEntry which is the Name widget, Ctrl+PageDown
is dealt with by the GtkScrolledWindow which is between the
GtkNotebook and the GtkEntry so the keystroke never reaches the
GtkNotebook.

The GtkScrolledWindow binds Ctrl+PageDown to page down on the
horizontal scrollbar.

If the focus is on the GtkSpinButton which is the border width widget
Ctrl+PageDown is dealt with by the GtkSpinButton as it binds
Ctrl+PageDown to scroll to start.

If focus is on the GtkEntry for Title a beep is heard when
Ctrl+PageDown is typed. This is because the GtkEntry is inside a
GtkNotebook which does not have visible tabs. This GtkNotebook deals
with the Ctrl+PageDown so it does not reach the visible GtkNotebook.

It seems that we have two clasees of problems:

Ctrl+PageDown being dealt with by widgets inside the notebook and 
a GtkNotebook being inside a GtkNotebook.

Perhaps, Calum would like to comment.

Horrible stuff indeed :/  There's also a third problem: when you tab
focus to a control that isn't currently visible, the ScrolledWindow
doesn't auto-scroll to show the control that now has focus.

To be honest I don't see many obvious things we can do to improve
things here; tabbed dialogs that scroll are just a usability disaster
and shouldn't ever be used anyway!  A couple of suggestions might be:

- if a notebook has invisible tabs, its Ctrl+PgUp/PgDn keybindings
should be ignored and passed through to the next widget that's
listening for them, rather than swallowing them up and beeping.

- the original keynav proposal suggested that Ctrl+Up arrow should
move the focus from any control on a tab to the tab itself (unless the
control needed Ctrl+up arrow itself).  This would make it slightly
easier to get focus to a different tab in situations like this, but it
looks like this was never implemented... either that or it just
doesn't work here for some reason.

I did some interception of keypresses so now Ctrl-PgUp/Down should work
in the property editor, unless the widgets grab the keys, like spinbutton.
(Ctrl-PgUp/Down should work in the palette as well.)

Regarding adding widgets to the interface using the keyboard, that
would be quite a bit of work, as we don't have keynav within the windows
being designed. So I doubt I would get around to adding that.

Can you confirm when this change went in?  Don't see a ChangeLog entry
for it, just trying to work out whether we need to produce a sun-patch
for it or not...

I guess we should file the 'can't layout controls using keyboard'
issue as an enhancement request, it's completely unrelated to the
original bug.

Damon, I assume your fix just solves the problem for this dialog?  If
so, can we please re-assign this bug to gtk to have the problem fixed
at source?

It was this:

2002-10-16  Damon Chaplin  <damon@ximian.com>

        ...

	* glade/glade_palette.c (on_notebook_switch_page): make sure the
	button corresponding to the new page is depressed, in case accel
	keys are used to switch pages.
	(new_section): rearranged a little so the deprecated page is always
	the last notebook page, so using accel keys to step through pages
	steps through in correct order.

	* glade/property.c (propagate_key_press_to_main_notebook): new
	function used to propagate Ctrl+PgDn/Up keypresses to the main
	notebook to switch pages. Fixes part of bug #90938.

That didn't fix everything, though.

Moving to GTK+ and changing subject.
The GTK+ issue is that some widgets use Ctrl+PgUp/PgDn so it makes
it awkward to switch tabs in notebooks which also use these keys.

See bug 97860 for the fix that recently went into both branches:
also accept C-A-PgUp 
and C-A-PgDn in the notebook.

*** This bug has been marked as a duplicate of 97860 ***