Path: utzoo!attcan!uunet!mcsun!ukc!harrier.ukc.ac.uk!rlh2 From: rlh2@ukc.ac.uk (Richard Hesketh) Newsgroups: comp.windows.x Subject: Re: Wish list for R5 (resources) Message-ID: <5319@harrier.ukc.ac.uk> Date: 19 Aug 90 11:55:44 GMT References: <9118@ubc-cs.UUCP> <9008152225.AA06107@expire.lcs.mit.edu> <9182@ubc-cs.UUCP> Reply-To: rlh2@ukc.ac.uk (Richard Hesketh) Organization: Computing Lab, University of Kent at Canterbury, UK. Lines: 153 Summary: Expires: Sender: Followup-To: In article <9182@ubc-cs.UUCP> lowe@cs.ubc.ca (David Lowe) writes: >In article <9008152225.AA06107@expire.lcs.mit.edu> rws@EXPO.LCS.MIT.EDU (Bob Scheifler) writes: >> >> and of most importance there is no standard graphical interface for >> editing resources and little chance that one could be developed >> from the current mechanisms. >> >>That's amusing to hear, since someone on my staff developed a graphical >>interface from the current mechanisms, without much trouble. But perhaps >>you just meant there is little chance of getting a standard one, as opposed >>to little chance of implementing one. :-) > >Maybe you could persuade whoever did this to post some information. I know what Bob is talking about but its up to him to "spill the beans". However I have done similar work and came to extremely similar conclusions. An external resource modifying interface can work via a defined message protocol between it and the clients. The resource editor asks for and receives a widget tree heirarchy of the client to be modified. The resource editor can then be used to examine individual resources (or sets of resources) of the client by sending remote Get and SetValues calls. The overhead for my implementation is that it needs the client to be linked against a small library containing the protocol routines (mine uses properties and client messages .. but others types of communication can be used; WINTERP uses sockets). Also as all messages are sent as strings then string-to-type and type-to-string converters are necessary, I have not found this to be a large overhead in practice though. A "clever, user-friendly" resource editor needs to know about all the "types" of the resources. It doesn't need to know about the widget classes or the resources themselves, it can get all these from the client very easily. These types could be hard-wired into the resource editor along with "methods" of displaying these in a user-friendly way or they could be "described" in a external file allowing for easy addition of new resource types. Infact in my UI builder which uses this "resource type display method" table I have found that I need only a dozen "methods" for over 90 resource types covering my widget set, the Athena widget set and the HP widget set (2D). I see no problems integrating Motif or other widget sets. A "display method" can be a toggle button for a Boolean resource or a set of radio buttons for an enumerated type etc. It can also be an editor such as a bitmap editor or translation table editor. >There are a lot of issues that need to be addressed, such as parsing >the current user resource file, Not too difficult, the resource editor builds up its knowledge from the running client so that parsing becomes straightforward. I have done this and the only problem comes with .. > handling and updating wildcarded entries, .. with the "handling" being a bit tricky. However by doing it for wildcard entries you can cover all the fully specified ones as well (very few of these really). Updating wildcard entries is again straightforward and also requires traversal of the widget tree to find matching widgets. Actually specifying wildcarded entries requires some thought on behalf of the resource editor designer. The mechanism is relatively simple compared to how you actually "present" it to the user. I am working on this one! I am developing a "graphical" specification/description of the wildcarded resources (including classes) instead of having to type the resource entries. >somehow specifying which resources are available for editing, This can be done in a table/database for resources in different classes and even class heirarchies .. e.g disallowing the modification of the fromVert and fromHoriz constraint of the scrollbars in a viewport widget could be disallowed in an "exceptions" Xrm database as: Viewport.horizontal*Widget: UNEDITABLE Viewport.vertical*Widget: UNEDITABLE or read-only such as: Core.depth: READ-ONLY This allows resources to be made exceptions on a per-class or per-instance basis. Remember, resource manager databases aren't just for resource value specifications! They are very useful for context help databases as well. > determining >the valid range of entries, and so on. This is built into the "resource type display methods". > I would be surprised if this >could be done without creating a separate specification of external >configuration parameters along the lines that I was suggesting. I suppose you might class the above databases as being external configuration parameters but these aren't set by the programmer but by the resource editor designer. If the application programmer wants to restrict which resources are editable he could do this by specifying it in a separate database file which is also read by the resource editor ... e.g. XEdit.custom However none of this is done in the program but externally so that they can be removed if required. > What >does the user's resource file look like after using this interface? Pass on this one; I haven't played with the program Bob is talking about but I see no reason why it has to be different from any hand-built resource file .. infact being machine generated it can be cleaned up and made more readable! My UI builder produces very readable resource files. >Maybe all that is needed is some good sample code, and this would become >a defacto standard. Interesting idea .. who will be first to publish I wonder??? > As far as I know, there are no clients in the >standard distribution that provide a graphical interface for changing the >program configuration. The resource mechanism could still be used for >systems-oriented configuration tasks, such as internationalization. Probably in R5 (?). >However, the resource mechanism has not yet shown its suitability for use >in a graphical user interface environment, which was the purpose of X >to begin with. The mechanism requires some internal updating (and is being) but I don't think that editing resources files by hand was ever really envisaged as being the only interface to customizing programs. X is supposed to be mechanism not policy of course 8-}. The resource editors that are coming along will make this mechanism very friendly indeed! >-- David Lowe While I have yet to fully develop a stand-alone resource editor (its in various bits at the moment) I have used the techniques I have described above in a UI builder. This builder uses the protocol (I call it ICRM or Inter-Client Resource Management) to attach to running programs and produce a reverse engineered user interface which can then be directly edited and extended. The resource editor is simply a different interface to the mechanism already developed for the builder (the mechanism was developed for the resource editor but the builder got built first! ... with itself of course 8-). As soon as the toolkit was developed (allowing interfaces to be inherently customizable) the cry was heard .. "we want friendly tools!!" Both to build interfaces and to customize them, these take time as we realize their full potential but they are just around the corner (honest). Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk : rlh2@ukc.ac.uk ..!mcsun!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 7620/3682