jimf@SABER.COM (06/27/90)
Some email just reminded me of two more wish items for R5. Currently there is no way to allocate a shareable colormap cell only if it already exists. I would love to see an XGetAllocatedColor function. This function would fail if there was not already a colormap cell with the given color value, even if there were free colormap cells available. I would also appreciate some way to convert read/write (private) colormap cells to read-only (shareable) cells. This way an application can allocate as many colors as it can, set them to values which won't be changed, make them shareable, then other applications can share those colors. These two functions are very desireable if your application needs to allocate a lot of colors and wants to help keep technicolor effects to a minimum. Image processing and display programs fall into this category. jim frost saber software jimf@saber.com
rhoward@msd.gatech.edu (Robert L. Howard) (06/28/90)
How about this for a trivial wish item. In my man pages (SunOS) games and demos are placed in Section 6. I'd like to see a place where you can install man pages for games and demos in their proper place. This would no doubt require another variable in Project.tmpl (say GameManSuffix) but you could default it to the same as ManSuffix. Just a nit. (I like *lots* of structure.) Robert | Robert L. Howard | Georgia Tech Research Institute | | rhoward@msd.gatech.edu | STL / MSD | | (404) 528-7165 | Atlanta, Georgia 30332 | | UUCP: ...!{allegra,amd,hplabs,ut-ngp}!gatech!msd!rhoward |
leconte@irisa.fr (Thierry Leconte) (06/28/90)
In X, windows have a border color, a border width and a border pixmap but these features are not use by 3d looking widget sets because they need 2 colors border and 2 colors pixmap. One for the top shadow and one for the bottom shadow. So it will be nice to add these attributes directly to the windows. With this extension : - it will be easy to extend the athena widgets to 3d looking - all 3d looking widget sets will not have to send drawing orders to the server for their borders each time their are exposed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Thierry LECONTE | , ,--- ,--- | | INRIA/IRISA | / / /--- | | Campus de Beaulieu | (___ (___ (___ | | 35042 RENNES CEDEX | | | FRANCE | GOTHIC project (INRIA/BULL) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | Tel: 99 36 20 00 e-mail: Thierry.Leconte@irisa.fr | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
caf@omen.UUCP (WA7KGX) (06/29/90)
How about a terminfo/X library that would allow one to creat an application that would run as an X client if a server were available and use terminfo/curses technology otherwise?
geof@aurora.com (Geoffrey H. Cooper) (07/12/90)
My guess is that this is ingrained deep inside the X structure, so it isn't easily fixed, but from the point of view of being a USER of X: Make the focus under TWM be synchronous with the mouse movements, so that type-ahead ends up in the right window. Currently, you can move your mouse over into a swapped-out application that takes a few seconds to get swapped in and take the keyboard focus. If you type during that time, the keystrokes will often get put in the previous application (which is usually an editor and screws up your buffer -- good thing Emacs has UNDO). [maybe the problem is TWM itself getting swapped out] - Geof -- geof@aurora.com / aurora!geof@decwrl.dec.com / geof%aurora.com@decwrl.dec.com
envbvs@epb2.lbl.gov (Brian V. Smith) (07/12/90)
In article <1990Jul11.191122.29222@aurora.com> geof@aurora.UUCP (Geoffrey H. Cooper) writes:
<
< My guess is that this is ingrained deep inside the X structure, so it
< isn't easily fixed, but from the point of view of being a USER of X:
<
< Make the focus under TWM be synchronous with the mouse movements, so
< that type-ahead ends up in the right window. Currently, you can move
< your mouse over into a swapped-out application that takes a few
< seconds to get swapped in and take the keyboard focus. If you type
< during that time, the keystrokes will often get put in the previous
< application (which is usually an editor and screws up your buffer --
< good thing Emacs has UNDO). [maybe the problem is TWM itself getting
< swapped out]
Set 'NoTitleFocus' in your .twmrc. For some reason, when you allow keyboard
focus in the titlebar, there is a delay of focus even in the window part
when you move the mouse from window to window.
--
_____________________________________
Brian V. Smith (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.lowe@cs.ubc.ca (David Lowe) (08/13/90)
Re: wish list for R5 As someone who has just gone through the process of learning X as a user and programmer, I believe one of the areas of X that most needs cleaning up is the way that resources are handled. I've taken a stab at suggesting a better mechanism below. 1) From the user's point of view (which should of course be given the top priority in design), the current resource mechanism is a total mess. They are expected to know about the widget structure of an application and the internal widget names, they are supposed to be able to imagine the global implications of wildcarded resource specifications, there is no feedback given when a typo is made, 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. The solution seems quite obvious. The application programmer should be able to specify a set of external configuration parameters (with names chosen to reflect the application). There should be one standard mechanism by which these parameters are given names, default values, valid ranges, documentation, command line arguments, and any values loaded from a user configuration file. This would provide the information needed for a standard graphical interface for the user to edit these parameters. There is no need for the vast majority of resource specifications that can currently be made for each application, many of which would break an application. Instead of being able to modify the color of every trivial component, it would be much more useful to allow modification of the color of a few semantically related interface components. 2) Most of the introductory books on X suggest that all resources be specified in an application defaults file. This seems like a total loss. The O'Reilly book on Intrinsics programming suggests that this file be placed in /usr/lib/X11/app-defaults, and gives no other way of loading it! Where does that leave the 99% of users with no root access? I know that there is an environment variable that can be set to point at another app-defaults directory, but this means that anyone else who wants to run my program is now going to have to first set an environment variable to point to my directory. Putting resource specifications in the application defaults file makes it far more difficult to understand someone else's program, as you must now try to match up the widget specifications in the code with closely related specifications scattered around in a separate file (the opposite of object-oriented programming?). In fact, most of the sample code distributed with X seems to have been written by people who understand these problems and they have avoided using application defaults files. Its mostly the unfortunate new user who gets lead down this path. The argument that different sites could install different application defaults is asking for trouble -- this means that the poor user will have no idea whether the application conforms to standard documentation and will face unknown behavior every time he or she remotely uses a client on a different machine. There is almost nothing about a "site" (i.e., NFS file system) that makes it the appropriate unit for customization. 3) The code is far easier to understand and write when all the resources are specified where the widget is created using the new varargs interface. Configurability could be supported by inserting values at this point that depend on the external configuration parameters described above. Currently, the manuals describe at least 4 or 5 different ways to set resources, indicating that none of them is really satisfactory (but the varargs is the closest). Success will have been achieved when the introductory manuals on X have only a couple of pages on how to set resources instead of several chapters. 4) These changes would allow a new name to be given to this capbility for program configuration (e.g., "configuration files"). The word "resource" makes no sense in this context and is already being used for totally different mechanisms in X. In summary, the current "resource" system should be replaced by a set of programmer-specified configuration parameters. A standard graphical interface could then be written to allow the user to edit them. -- David Lowe Computer Science Dept. Univ. of British Columbia lowe@cs.ubc.ca
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (08/13/90)
David Lowe takes a stab at suggesting a cleanup mechanism for the current mess of resource specifications. > As someone who has just gone through the process of learning X as a > user and programmer, I believe one of the areas of X that most needs > cleaning up is the way that resources are handled. I've taken a stab > at suggesting a better mechanism below. For the most part, his suggestions sound good to me. However (now how did you guess that was coming? :-), I have a couple of comments.... First is that > In summary, the current "resource" system should be replaced by a set > of programmer-specified configuration parameters. A standard > graphical interface could then be written to allow the user to edit > them. The current "resource" system *is* a set of programmer-specified configuration parameters. There is absolutely nothing wrong with the current mechanism as an internal mechanism; the problems are all due to the lack of a good user interface to it. In fact, the current mechanism has a nice property that would be difficult to achieve with a system based on each application having some configurable parameters which are kept in a file somewhere, that being that it is possible to specify something for all applications for which it makes sense. For example, my .Xdefaults has lines *Foreground: white *Background: black Someone else on xpert (rws, I think it was) gave another example, something like *shapeStyle: oval I would find having to separately customize the same changes into each application I want to use extremely irritating. The current mechanism automatically gives me white-on-black for applications which draw stuff without causing errors from applications which don't. (Yes, there are such - xwd, for example.) I would also offer a plea for the preservation of the current system (or something like it) as the internal mechanism because I would rather edit a file than use a customization tool that's someone else's idea of "user-friendly" - and I'm sure I'm not the only one (though I daresay we're probably a minority). [on the problems with app-defaults files] > In fact, most of the sample code distributed with X seems to have > been written by people who understand these problems and they have > avoided using application defaults files. More likely, IMO, is that the code you're thinking of dates from before there were app-defaults files. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
harp@cadillac.Berkeley.EDU (Christopher North-Keys) (08/13/90)
This is a minor detail (ah, well) relating to the X authority interface.
According to my interpretation of the man page, and the evidence presented
by direct experimentation, there is a basic tool missing from the xauth
program.
Group Talisman had little difficulty working out the usage of the
MIT-MAGIC-COOKIE-1 mechanism, and indeed are using it now between the
Uni.Tx@Austin, MCC, and MIT. However, in order to avoid using
script ftp sessions between MCC(secured vs. rsh and rlogin) and MIT, it became
necessary to add new cookies *ONLY* in the event they did not already
exist. This usage of fixed cookies (now that sounds strange...) seemed
like an obvious thing to do, but it's here that the problems arose.
I already knew there was a simple operation to override existing entries,
now what I needed was either a command which only overrode *missing* entries,
or a way to test for the existance of an entry.
The first didn't exists. Oh, well, I figured, "sure", the second would be
there. No need to run ``grep $DISPLAY $XAUTHORITY'' (Nasty! Yechh! Bad!)
or anything like that. Surely...
Bad news. ``xauth list $DISPLAY'' returns success even if the display in
question has no existing cookie.
Now I'm using (C-Shell):
set xkey = 2004`date +%j%m%d%y%H%M%S`0feedface
xauth add unix:0.0 . $xkey
if ( 0 == `xauth list $DISPLAY | wc -l` ) xauth add $DISPLAY . $xkey
This is *ugly*. I figured the third line *should* be something like:
xauth list $DISPLAY || xauth add $DISPLAY . $xkey
or even better (add-if-missing):
xauth verify $DISPLAY . $xkey
Which would allow:
set xkey = 2004`date +%j%m%d%y%H%M%S`0feedface
cat <<... | xauth >>& /dev/null
add unix:0.0 . $xkey
verify $DISPLAY . $xkey
...
But both if these approaches drew double-nulls.
Now, if the idea it that the cookies should *always* be dynamic, it's already
suffering, because there's no decent way to reload cookies during a session
with xrdb or the like just now...but if it was expected they might be static:
Could someone please fix it? Please? We *have* to use it, but fixing it
ourselves it rather hard in places where the words ``in my copious spare
time'' have become a running joke...
Of course, if we just missed something: yell at us (rather, me), eh?
______________________________________________________________________________
Christopher North-Keys Assoc. Systems Analyst
Group Talisman Harp[@Mcc.Com]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~rjc@uk.ac.ed.cstr (Richard Caley) (08/14/90)
In article <9008130225.AA21698@shamash.McRCIM.McGill.EDU> mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) writes:
Someone else on xpert (rws, I think it was) gave another example,
something like
*shapeStyle: oval
I would find having to separately customize the same changes into each
application I want to use extremely irritating.
First I'd like to suport this pela that should anything be done to the
defaults mechanism it should loose none of is present power. Being
able to make all my comand buttons look the same no matter what the
whims of the person who wrote it is wonderful.
Secondly would it be possible to have a blitz on the clients for R5 to
make them all use resources nicely? I realise that most of the worst
offenders are contributed clients ( xcalender caused me no end of
pain... ) but, for instance, the xman title and icon label seems to
have been glued in with epoxy, it took me ages to manage to change it.
As the manual says, TWM is another one.
Thirdly, as a piece of pure fantasy, it would be wonderful if some way
could be found of allowing resources to specify extra buttons and menu
items as well as changing the labels and effects of ones which exist.
For instance I might wish to move an action from being on a menu
behind a button to being on a button of its own. Always assuming that
there is not some way to do this already which has escaped my
notice...
I would also offer a plea for the preservation of the current system
(or something like it) as the internal mechanism because I would rather
edit a file than use a customization tool that's someone else's idea of
"user-friendly" - and I'm sure I'm not the only one (though I daresay
we're probably a minority).
Your not the only one...
--
rjc@uk.ac.ed.cstr pjs@aristotle.JPL.NASA.gov (Peter Scott) (08/15/90)
In article <RJC.90Aug13234401@brodie.uk.ac.ed.cstr>, rjc@uk.ac.ed.cstr (Richard Caley) writes: > Thirdly, as a piece of pure fantasy, it would be wonderful if some way > could be found of allowing resources to specify extra buttons and menu > items as well as changing the labels and effects of ones which exist. > For instance I might wish to move an action from being on a menu > behind a button to being on a button of its own. Always assuming that > there is not some way to do this already which has escaped my > notice... If an application has been coded using Dave Smyth's Widget Creation Library, it is often possible to achieve exactly this by changing the resource file alone. Probably not as easily as the method you have in mind, tho'... -- This is news. This is your | Peter Scott, NASA/JPL/Caltech brain on news. Any questions? | (pjs@aristotle.jpl.nasa.gov)
randy@erik.UUCP (Randy Brown) (08/15/90)
rjc@uk.ac.ed.cstr writes (he probably drives on the left side of the road, so we'll excuse his address as well :-)): .Thirdly, as a piece of pure fantasy, it would be wonderful if some way .could be found of allowing resources to specify extra buttons and menu .items as well as changing the labels and effects of ones which exist. .For instance I might wish to move an action from being on a menu .behind a button to being on a button of its own. Always assuming that .there is not some way to do this already which has escaped my .notice... This isn't fantasy. See Widget Creation Library (WCL). It's reported to be on expo, or contact david@devvax.jpl.nasa.gov (should I say david@gov.nasa.jpl.devvax? Consult your local gateway...)
klee@wsl.dec.com (Ken Lee) (08/15/90)
In article <RJC.90Aug13234401@brodie.uk.ac.ed.cstr>, rjc@uk.ac.ed.cstr (Richard Caley) writes: |> Thirdly, as a piece of pure fantasy, it would be wonderful if some way |> could be found of allowing resources to specify extra buttons and menu |> items as well as changing the labels and effects of ones which exist. |> For instance I might wish to move an action from being on a menu |> behind a button to being on a button of its own. You can do this with Motif UIL. Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
treese@crl.dec.com (Win Treese) (08/15/90)
In article <RJC.90Aug13234401@brodie.uk.ac.ed.cstr> rjc@uk.ac.ed.cstr (Richard Caley) writes: > Thirdly, as a piece of pure fantasy, it would be wonderful if some way > could be found of allowing resources to specify extra buttons and menu > items as well as changing the labels and effects of ones which exist. > For instance I might wish to move an action from being on a menu > behind a button to being on a button of its own. Always assuming that > there is not some way to do this already which has escaped my > notice... The R4 xmh supports adding new buttons with actions. It works reasonably well, though it's a little awkward. I don't think you can alter the menus, but you could certainly do something in the same style. It's not too hard to code it that way, either. Win Treese Cambridge Research Lab treese@crl.dec.com Digital Equipment Corp.
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (08/15/90)
In article <1990Aug14.174606.1137@elroy.jpl.nasa.gov> pjs@aristotle.jpl.nasa.gov writes: @In article <RJC.90Aug13234401@brodie.uk.ac.ed.cstr>, rjc@uk.ac.ed.cstr @(Richard Caley) writes: @> Thirdly, as a piece of pure fantasy, it would be wonderful if some way @> could be found of allowing resources to specify extra buttons andmenu @> items as well as changing the labels and effects of ones which exist. @> For instance I might wish to move an action from being on a menu @> behind a button to being on a button of its own. Always assuming that @> there is not some way to do this already which has escaped my @> notice... @ @If an application has been coded using Dave Smyth's Widget Creation @Library, it is often possible to achieve exactly this by changing the @resource file alone. Probably not as easily as the method you have @in mind, tho'... Yes, you could do this modulo any application-state based changes on the user-interface -- for example, if certain menu entries grey out to prevent the user from selecting the wrong thing given a certain app-state, then you need to transmit that state information to the user-defined buttons as well. Things can also get zorched if you are moving an action that would normally be called from a dialog box onto the "main window" of a program -- the application expects to be in a state of dialog, and allah-the-sudden you've popped it into doing a callback while it is in the wrong state. Both of the aforementioned problems require more than a static description of a widget hierarchy and resources as provided by UIL or WCL. By the way, An existing example of doing such resource-based customization of buttons, menus and their associated actions can be found in the r4 xmh mailer. ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (08/16/90)
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. :-)lowe@cs.ubc.ca (David Lowe) (08/16/90)
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. There are a lot of issues that need to be addressed, such as parsing the current user resource file, handling and updating wildcarded entries, somehow specifying which resources are available for editing, determining the valid range of entries, and so on. 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. What does the user's resource file look like after using this interface? Maybe all that is needed is some good sample code, and this would become a defacto standard. 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. 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. -- David Lowe
randy@erik.UUCP (Randy Brown) (08/17/90)
>Both of the aforementioned problems require more than a static description >of a widget hierarchy and resources as provided by UIL or WCL. Since WCL includes not only a string-to-widget converter but a string-to- callback converter, it's perhaps not quite as static as you might think, though I'm sure Niels has a point--there's a limit somewhere.
mayer@hplabsz.HPL.HP.COM (Niels Mayer) (08/18/90)
In article <9008161931.AA21572@erik.uucp> randy@erik.UUCP (Randy Brown) writes: >>Both of the aforementioned problems require more than a static description >>of a widget hierarchy and resources as provided by UIL or WCL. > >Since WCL includes not only a string-to-widget converter but a string-to- >callback converter, it's perhaps not quite as static as you might think, >though I'm sure Niels has a point--there's a limit somewhere. My point was that a UI prototyping/extension language requires more than static layout, and static bindings to application code in order to handle the dynamic aspects of user interfaces (e.g. the examples I gave of (1) desensitizing UI components if input to them is not valid at a particular application-state, and (2) handling the interactions between dialog and presentation). Having string-to-widget or string-to-callback converters is very useful indeed, but it will not handle the things I'm thinking of. Basically, you need a way of getting application state represented in the user-interface language, and you need a way of sending messages relating application state changes to widgets expressed in the UI prototyping/extension language. Now, if all widgets in WCL or UIL could have a "constraint changed" callback, then the string-to-callback mechanism might become useful for handling UI dynamics. As far as I know, such constraint mechanisms only exist in languages found in User-Interface Management Systems (UIMS) such as Serpent or Open Dialog, and can also be implemented via a more traditional extension-language mechanism in the UI prototyping/extension language, WINTERP (see expo.lcs.mit.edu:contrib/winterp/winterp-<latestversion>.tar.Z) ------------------------------------------------------------------------------- Niels Mayer -- hplabs!mayer -- mayer@hplabs.hp.com Human-Computer Interaction Department Hewlett-Packard Laboratories Palo Alto, CA. *
rlh2@ukc.ac.uk (Richard Hesketh) (08/19/90)
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
marbru@auto-trol.UUCP (Martin Brunecky) (08/21/90)
In article <9008161931.AA21572@erik.uucp> randy@erik.UUCP (Randy Brown) writes: >>Both of the aforementioned problems require more than a static description >>of a widget hierarchy and resources as provided by UIL or WCL. > >Since WCL includes not only a string-to-widget converter but a string-to- >callback converter, it's perhaps not quite as static as you might think, >though I'm sure Niels has a point--there's a limit somewhere. ... plus on systems which support dynamic (runtime) binding such as Apollo or (with some tweaking) VMS, your string-to-callback convertor can be upgraded to load your new code when needed. But, I agree that Niels has a point. We can enhance WCL to destroy/recreate things on fly (assuming Xt intrinsics will improve to make it aceptable), we can provide callbacks that will reconfigure any portions of widget tree, but we still need more. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404