From 5ea990e259460b313ac56f4c848bfb6196c5aa8e Mon Sep 17 00:00:00 2001 From: Adam Fedor Date: Mon, 6 Oct 2003 03:28:34 +0000 Subject: [PATCH] Fix documentation install git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/back/trunk@17781 72102866-910b-0410-8b05-ffd578937521 --- ChangeLog | 7 + Documentation/Back/Back.html | 31 ---- Documentation/Back/GNUmakefile | 2 +- Documentation/Back/WindowFocus.html | 259 ---------------------------- Documentation/GNUmakefile | 3 + Source/x11/raster.c | 37 ---- 6 files changed, 11 insertions(+), 328 deletions(-) delete mode 100644 Documentation/Back/Back.html delete mode 100644 Documentation/Back/WindowFocus.html diff --git a/ChangeLog b/ChangeLog index c09b22b..e3f2906 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2003-10-05 Adam Fedor + + * Documentation/GNUmakefile: Make Back documentation + * Documentation/Back/GNUmakefile: Set DocumentationDirectory. + + * Source/x11/raster.c (RMakeCenteredImage): Remove (unused). + 2003-10-04 14:27 Alexander Malmberg * Source/art/path.m (-DPSrectclip::::): Move the call to -DPSnewpath diff --git a/Documentation/Back/Back.html b/Documentation/Back/Back.html deleted file mode 100644 index 56d3e03..0000000 --- a/Documentation/Back/Back.html +++ /dev/null @@ -1,31 +0,0 @@ - - - - Back - - -
-

Back

-

Authors

-
-
Adam Fedor()
-
-
-
-

Version: $Revision$

-

Date: $Date$

- - -

Back

-

- - Documentation for understanding and writting GUI backends. -

- -
- - diff --git a/Documentation/Back/GNUmakefile b/Documentation/Back/GNUmakefile index 2f82cce..2de9e52 100644 --- a/Documentation/Back/GNUmakefile +++ b/Documentation/Back/GNUmakefile @@ -34,7 +34,7 @@ Back_AGSDOC_FILES = \ WindowFocus.gsdoc Back_AGSDOC_FLAGS = \ - -DocumentationDirectory . \ + -DocumentationDirectory Back \ -Up Back Back_DOC_INSTALL_DIR = Developer/Back/Reference diff --git a/Documentation/Back/WindowFocus.html b/Documentation/Back/WindowFocus.html deleted file mode 100644 index 3713e1b..0000000 --- a/Documentation/Back/WindowFocus.html +++ /dev/null @@ -1,259 +0,0 @@ - - - - Window Focus Procedures - - -
-

Window Focus Procedures

-

Authors

-
-
Adam Fedor()
-
-
-
-

Version: $Revision$

-

Date: $Date$

- - -

Window Focus

-

- - This document describes how various events and user actions - affect window focus of GNUstep applications. This document for - the most part describes focus changes that occur outside of - application control, since application window focus changes - are well described in the class documentation. -

- -

Application Focus

-

- - The application can get focus in several ways: -

-
    -
  • - Launch from the command line or another app -
    • -
  • - Another app looses focus (e.g. by terminating) -
    • -
  • - The user switches screens to the one the app is - displayed on -
    • -
  • - Double-click on the application icon -
    • -
-

- - The first case does not directly affect window focus (because - there are no windows at startup). However, as the application - begins to create and order front windows (including the main - menu) there will likely be a cascade of focus events generated - by the window manager for each window ordered in. -

-

- - In the second and third case, the window manager will likely try - to give focus to the window that previously had it or perhaps to - some random window based on some internal window manager - code. GNUstep may ignore this request and try to give focus to - another window, typically the application's idea of the current - key window. -

-

- - The last case is handled in the GUI front-end. -

- -

KeyboardFocus

-

- - The Key window is the window that has keyboard focus and has - keyboard events sent to it. When an application receives focus, - the window manager will typically ask one window to take - keyboard focus (see above, Application Focus). -

-

- - When an application is launched, in many cases, only the application - icon and main menu may be displayed. In the OpenStep interface, - neither of these is really supposed to be a key window, and in - fact, many window managers control the application icon so this - cannot be made key anyway. In X-Windows, however, there is no - other way for an application to receive keyboard events unless a - visible window has been made key. This leaves the main menu. -

-

- - When an application receives focus, or if all the windows in an - application are closed (see the private method - [NSWindow-_lossOfKeyOrMainWindow]), then the main menu will request - keyboard focus (see below). -

-

- - The GUI font-end may function differently to accomadate - different window manager behavior. Below is a list of the - changes the front-end makes for different managers and windowing - systems: -

-
-
WindowMaker
-
- - -

- - WindowMaker controls the application icon so it cannot - receive keyboard events. The main menu is made key if there is - no other window capable of becoming key. -

- - -
-
- -

Requesting Keyboard Focus

-

- - A window may request to get keyboard focus in serveral - instances. The window requests keyboard focus through the server - method -setinputfocus:: -

-
    -
  • - If the window asks or is asked to become - key, through the [NSWindow-becomeKeyWindow] method -
    • -
  • - If the window is ordered front and the window is the key - window. - -
    • -
  • - If during _lossOfKeyOrMainWindow, only the main menu is able to - become key (for window systems where this is required). - -
    • -
- -

Window Focus In/Out

-

- - The GUI front-end receives two types of focus events from the - back-end (through an NSEvent object). Both of these are subsets - of the NSAppKitDefined event: GSAppKitWindowFocusIn and - GSAppKitWindowFocusOut. A FocusIn event can be received for - several reasons: -

-
    -
  • - The window manager deminiaturized the window. The WM - should really tell the application to do this itself, but many - WMs don't. In this case the window just posts a notification - that it happened. -
    • -
  • - The application is in the process of hidding. As each - window is ordered out, the WM may send a focus message - (spuriously) to the next window in line. In this case the - message is just ignored. -
    • -
  • - If the previous cases do not apply, the window checks if it - can become key or main and activates the application if it is - not active. -
    • -
  • - If this window is the main menu, it looks for another - window to become the key window, if possible, through the - _lossOfKeyOrMainWindow mechanism -
    • -
-

- - The back-end should keep track of the last window that requested - to become key. This can be important in determining whether the - back-end should send a FocusIn event to a window when it - receives a signal from the window manager or windowing system. - Sending a FocusIn event to a window that already requested it, - msy cause focus confusion in the GUI. -

-

- - The front-end does nothing for FocusOut messages. -

- -

X-Windows messages

-

- - This section describes messages that X-Windows servers and the WM - generally send to the application. Other window servers may send - similar messages. -

-
-
Take Focus
-
- - -

- - A message from the WM telling a window it should take keyboard - focus. If the app is not active, the back-end should send a - FocusIn event. Otherwise, the back-end should only send a - FocusIn event to the front end if the message is due to a user - action, such as a click on the title bar (i.e. the target - window is not the current key window or the last window that - requested key status). The back-end may - also send an event if the window has just been mapped, - although this is not typically necessary, unless it's due to a - screen change. -

- - -

- - In other cases, the back-end should do what is necessary to - make sure that the last window to request key status receives - it instead of the one the WM thinks should receive it. -

- - -
-
Focus In
-
- - -

- - A message from the server telling the application that - keyboard focus has been set for a window. The back-end - should not send an event to the front-end in this - case. However, the back-end should use this information to - determine when to send a message in other cases (e.g. from a - Take Focus message). -

- - -
-
Focus Out
-
- - -

- - A message from the server telling the application that focus - has left a window. If the focus has gone to a window that is - not part of the application, the back-end should tell the - NSApp to deactivate. Otherwise it should do nothing. -

- - -
-
-
- - diff --git a/Documentation/GNUmakefile b/Documentation/GNUmakefile index 733fc7a..698426d 100644 --- a/Documentation/GNUmakefile +++ b/Documentation/GNUmakefile @@ -31,6 +31,8 @@ include ../Version # The documents to be generated DOCUMENT_NAME = +SUBPROJECTS = Back + # The text documents to be generated DOCUMENT_TEXT_NAME = \ INSTALL NEWS README ANNOUNCE @@ -58,6 +60,7 @@ ANNOUNCE_DOC_INSTALL_DIR = Developer/Back/ReleaseNotes/$(VERSION) -include GNUmakefile.local include $(GNUSTEP_MAKEFILES)/documentation.make +include $(GNUSTEP_MAKEFILES)/aggregate.make -include Makefile.postamble diff --git a/Source/x11/raster.c b/Source/x11/raster.c index f40562f..01b02b8 100644 --- a/Source/x11/raster.c +++ b/Source/x11/raster.c @@ -537,40 +537,3 @@ RMakeTiledImage(RImage *tile, unsigned width, unsigned height) } return image; } - - -RImage* -RMakeCenteredImage(RImage *image, unsigned width, unsigned height, RColor *color) -{ - int x, y, w, h, sx, sy; - RImage *tmp; - - tmp = RCreateImage(width, height, False); - if (!tmp) { - return NULL; - } - - RClearImage(tmp, color); - - if (image->height < height) { - h = image->height; - y = (height - h)/2; - sy = 0; - } else { - sy = (image->height - height)/2; - y = 0; - h = height; - } - if (image->width < width) { - w = image->width; - x = (width - w)/2; - sx = 0; - } else { - sx = (image->width - width)/2; - x = 0; - w = width; - } - RCombineArea(tmp, image, sx, sy, w, h, x, y); - - return tmp; -}