EXENE TODO LIST: Overall concentrations: ----------------------- - Improve concurrency, and establish deadlock-avoidance conventions - asynchronous communication with child widgets - no cycles in DG of communicating events - ClientMessage events - handle deletion events - handle input focus events - X resources - improve documentation of that completed - review that completed for sanity - error checking - X authentication/authorization - fix xauth lookup issues - verify compliance with defacto standards (xlib) - Input focus - notification by ClientMessage events - ICCC compliance for X selections - ... Apr 01 2005: ------------ ? - Widget.styleFromXRDB root should return an empty style if RESOURCE_MANAGER isn't a property on the server Apr 05 - still pending; cannot duplicate on home workstation; will attempt to verify at KSU. Mar 30 2005: ------------ x - root as argument to parseCommand ? - $DISPLAY=:0.0 on cis linux machines doesn't work with xauth Apr 01 - still pending; cannot duplicate on home workstation (but verified at KSU) _ - stringsFromStyle has errors: in particular, fully qualified have initial dot. _ - ml-doc: mkdoc not compiling? _ - expansion to handle ClientMessage events _ - X selections ICCC compliance x - remove build-eXene from eXene/ x - is list of option values in right order? justification? x - parseCommand should use same error-checking as raises BadSpec? perhaps not; we could still have BadSpec raised in styleFromStrings or stylefromXRDb because of bad resource specifications _ - "goodbye*font" in resource doesn't set the font of a button - why? x - see if we can include the string of the bad resource spec in BadSpec instead of just line number _ - structure of arg list passed to widgets: do we have subcomponents of name "aFont" and "bFont", but then that doesn't match "goodbye*font". do we need arg list to be as ([a,font],...) instead? findAttribute might then take a list, even singleton. shouldn't be too hard. _ - default optiondatabase with the documented x options in it _ - high level "do it all" function (auto process ie -name) _ - perhaps send J. Reppy a note about mkdoc? _ - call for papers due Jun 10 on conference _ - should make this priority next few months; Dr. Schmidt and Dr. Banerjee should be around most of the summer Dr. Stoughton thinks. Notes to myself: ---------------- - XinternAtom definition - returns atom w/ given name and creates if not exists - Deadlock : p 250, Silbershatz: * mutual exclusion * hold and wait * no preemption * circular wait - Selections : p 610 , p 98 of Scheifler, Gettys * XGetSelectionOwner * XSetSelectionOwner * XConverSelection - Input focus : p 264 of Scheifler, Gettys; p 327 * XsetInputFocus * XgetInputFocus Mar 16 2005: ------------ x - ICCM manual - window manager notified of WM_DELETE_WINDOW protocol. ? - bitgravity for redrawing. redrawing issues solved by stable version of fvwm. ? - resizing basicwin doesn't redraw. _ - research bit gravity Mar 9 2005: ------------ _ - disable widgets, flush queue? _ - button-bar concept from crypto assignment _ - ml-doc tool ? - post instructions for building standalone library. _ - ICCM compliance in selections: target types required in ICCM _ - selections over multiple widgets? May 2004: -----Original Message----- From: Allen Stoughton [mailto:allen@cis.ksu.edu] Sent: Wednesday, May 26, 2004 11:04 AM To: ddeboer@cis.ksu.edu Subject: list of eXene goals EXene Library Improvements (1) eXene's implementations of selections isn't ICCC-compliant, and the interface isn't very clear. Perhaps add the simplified kind of interface that I wrote for pretty-printing? E.g., the required target types aren't all handled, support for COMPOUND_TEXT. (2) Should there be GNOME/KDE support? What does it mean to support desktop environments? (3) Make args list two dimensional? How should aliases in style-views be used, if at all? Related to classes versus names. Sorting out semantics of merging. Dynamic attributes? (4) Keyboard grabbing/focus handling needs to be available for applications. See ICCC manual. (5) A call like this should raise exception if it fails: val background = A.getColor(attrs attr_background) Instead, can lead, asynchronously, to Error on request #15: <> (6) DELETE_WINDOW protocol and focus: > Looking in the ICCM manual, in Section 4.2.8, the protocol for window > deletion is described. It turns out that a client is passed a > ClientMessage X-event with a field saying WM_DELETE_WINDOW. This > actually comes via the X server; the window manager sends a request to > the X server to get this to happen. > > The client message is handled correctly by eXene at the lowest level. > But, if you look in lib/windows/toplevel-win.sml, the code > > | routeXEvt (_, ClientMessageXEvt{...}) = () > > is commented out, and doesn't do anything anyways. Thus, a > shell/application doesn't get told when it is supposed to cleanly > delete. > > So, eventually, this event will have to be handled. Part of what is > returned when a top-level window is created should be a channel on > which a message corresponding to this event should be received. As I > explained before, I don't think this should be part of the input > environment, since it only pertains to top-level windows. This > channel, or simply a unit event, perhaps, should be one of the values > that one can get, via a function, from a shell, letting an application > know when the user asked that a shell be deleted, cleanly. (7) Timestamps on keyboard messages. (8) Error messages should be suppressible. There's the issue about errors due to drawing on drawables that no longer exist. (9) Make eXene support X authentication. Integrating with command line processing. (10) Support for offscreen multiple-bit drawing. THESIS TODO: Thesis Outline: Enhancements to the eXene Library and eXene Widgets (??) 1 Introduction 1.1 Problem Statement Issues with the current implementation with respect to: • Widget deadlock, and the lack of deadlock-avoidance conventions • Resource-management mechanisms • Selection management • Focus management • Other issues, such as deletion signalling and X authentication Goal: build eXene into a robust, mature library for implementing X Windows applications. 1.2 Literature Review 1.3 Description of Remainder of Chapters 2 Methods 2.1 Requirements and Specifications 2.2 Algorithms 3 Description ofWork: Deadlock Avoidance Conventions Some work done here... 4 Description of Work: Resource-Management Mechanisms Some work done here... 1 5 Description of Work: Selection Management Mechanisms Much much work to be done here... 6 Description ofWork: Focus Management Mechanisms More work to be done here... 7 Description of Work: more... 8 Conclusion 8.1 Results Effectiveness of deadlock prevention conventions; usefulness of resource-management mechanisms; usefulness of selection-management mechanisms; effectiveness of focus management mechanisms; effectiveness of deletion signalling and X authentication fixes. Evaluation of progress toward overall goal of robust, mature eXene library. Distribution information. 8.2 Unresolved Issues Any limitations to deadlock prevention conventions; any shortfalls in progress toward robust, mature eXene. Future work possibilities. 9 Appendices... 9.1 Updated eXene+Widgets Manual? 9.2 Selected Source Code? Including references to: • Reppy, John H., and Emden R. Gansner. The eXene Library Manual. February 1993. AT&T Bell Labs. • Scheifler, Robert W. X Window System Protocol, X Version 11 Release 6. 1994. X Consortium. 2 • Hoare, C.A.R. Communicating Sequential Processes. August 1978. Communications of the ACM. • Gajewska, Hania, Mark S. Manasse, and Joel McCormack. Why X is Not Our Ideal Window System. ... ACM? **look up** • Pucella, Riccardo. Higher-Order Concurrent Win32 Programming. 1999. Proceedings of the 3rd USENIX Windows NT Symposium. • Haahr, Paul. Montage: Breaking Windows into Small Pieces. 1990. USENIX Summer Conference 1990. • Rosenthal, David, and Stuart W. Marks. Inter-Client Communications Conventions Manual, X Version 11 Release 6. 1994. X Consortium. • Pike, Rob. A Concurrent Window System. ACM? **look up** • X Window System, Version 11, Release 6.6. X Consortium. • eXene. John Reppy. • Nye, A. Xlib Programming Manual, Volume One. O’Reilly & Associates, 1990. • Nye, A. Xlib Programming Manual, Volume Two. O’Reilly & Associates, 1988. • Uehara, Minoru, Chisato Numaoka, Yasuhiko Yokote and Mario Tokoro. Sarek: A Window System Interface for Object-Oriented Concurrent Programming Languages. **look up publisher** Great Papers in Computer Science: Cooperating Sequential processes (conditions necessary for deadlock) X Window System, Scheifler and Gettys 3