On Sun, Jul 06, 2003 at 02:12:54PM +0200, [EMAIL PROTECTED] wrote: > On Sun, Jul 06, 2003 at 07:24:33AM +0200, Olivier Chapuis wrote: > > On Sat, Jul 05, 2003 at 10:15:25PM +0200, [EMAIL PROTECTED] wrote: > > > I have mostly completed and applied the patch. Still missing: > > > > > > * The window styles (although the members of the window_style > > > structure are already defined). > > > * Handling changes in update.c. > > > * Write man page. > > > > I can do that if you want ... as I have also write down a patch > > (partial) too! > > I'm already on the job - I'm getting nervous with a half finished > patch in cvs :-) > > > > * Check for _NET_WM_PID. > > > > Seems you do that. > > Actually, I have difficulties to understand the design of the > ewmh_...c files. I understand there are properties that are > > * set once on the root window at fvwm startup > * set on the root window but updated regularly > * set by fvwm on application windows (?) > * set by once applications on their windows when mapped > * set by apps on their window and updated later (?) > * client messages from apps to fvwm > * client messages from fvwm to client windows. > > Where is this all located in the code and how does it correspond > to the nine atom lists in ewmh.c?
The logic in the lists splitting is a bit different. There are comments which explain this logic where there are defined. Basically, atoms in a given list are handled in the same way by the code. The code is maybe a bit difficult to understand at first reading but it is easy to add new EWMH stuff as a lot of things are done automatically: _basically_ add an atom in a list with a function handler and you have done. Note that the signification of an atom can depends on how it is used. For, example the atoms in the EWMH_ATOM_LIST_WM_STATE can be received by fvwm as a client message (send by any application) to ask a state change. Secondly, the wm must set the _NET_WM_STATE on an application window with the atoms of the EWMH_ATOM_LIST_WM_STATE accordingly with the state of the window. Finally, a window can map with a _NET_WM_STATE set on it to indicate a desired mapping state. It is useful to have such a list for automatic handling of these 3 situations via the functions handler of the list. These functions should handle 3 different situations: - Client msg (ev != NULL && style == NULL) - Initial Mapping with the state set (ev == NULL && style != NULL). Note the additional arg "any" (== has_hint) for recapture and restarting. - Query of the state (ev == NULL && style == NULL) > What is the idea behind these > lists and how are they handled. E.g., are the atoms in the lists > detected automatically? > Yes. For example to add a _NET_WM_STATE add it to the EWMH_ATOM_LIST_WM_STATE list (in alphabetic order) and write down the function handler (all the other stuff is done automatically: client msg detection, initial mapping checking, state query for _NET_WM_STATE, addition in the list of supported _NET stuff). I will add more comment in ewmh code, but the list name and the functions handler name can be used to know where a given EWMH property is handled. > > > * Test the patch. I have only tried Mozilla yet. > > > > Make some test with Tk it is ok. > > I have written a small testing app and found a lot of bugs that > are all fixed now. Can you check with Tk, please? If anything > strange happens give instructions to reproduce and post the > console output. > Ok. > The seven detection methods are: > > > - _NET_WM_PID (dould not find an application that sets it) > - full screen detection (icccm) > - full screen detection (traditional) > - moving window adjacent to a border (icccm) > - moving window adjacent to a border (traditional) > - moving window by the border width/height (icccm) while it > would stay in the same placew with the traditional method. > - same for traditional > > I did not test the _NET_WM_PID detection yet. > It seems to work as mozilla set it and the good algo is choosen. (All KDE >= 2 and GNOME2 apps set this prop). > > By the way, should we implement _NET_WM_STATE_FULLSCREEN? > > Yes. I'd like to do it myself to gather some experience with the > ewmh code. > It seems that this start to work. But what about a FullScreen command which removes the decoration, MoveResize the window to the size of the screen and possibly put the window in a given layer: FullScreen [bool] [StayOnTop|layer x y] [size_hint_override] then we define defaults fvwm func: AddToFunc EWMHFullScreenOn I FullScreen On AddToFunc EWMHFullScreenOff I FullScreen Off which are called when needed by the ewmh code. > > Also you just wrote all the code for _NET_MOVERESIZE_WINDOW but > > the trivial stuff in fvwm/ewmh* > > Yes, I think so. The logic in the __cr_get_grav_position() > function should return the requested frame position. It needs > some work on the interface, though. > What about building a ConfigureRequest event and send it to the "events code" with an override_gravity arg (which forces icccm motion algo and use the override_gravity gravity in the place of the app gravity)? Regards, Olivier -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
