| 1 | |
| 2 | =head1 NAME |
| 3 | |
| 4 | Tk::Xrm - X Resource/Defaults/Options routines that obey the rules. |
| 5 | |
| 6 | =for pm Tk/Xrm.pm |
| 7 | |
| 8 | =for category Creating and Configuring Widgets |
| 9 | |
| 10 | =head1 SYNOPSIS |
| 11 | |
| 12 | use Tk; |
| 13 | use Tk::Xrm; |
| 14 | |
| 15 | =head1 DESCRIPTION |
| 16 | |
| 17 | Using this modules causes Tk's Option code to be replaced by versions |
| 18 | which use routines from <X11/Xresource.h> - i.e. same ones every other |
| 19 | X toolkit uses. |
| 20 | |
| 21 | Result is that "matching" of name/Class with the options database follows |
| 22 | the same rules as other X toolkits. This makes it more predictable, |
| 23 | and makes it easier to have a single ~/.Xdefaults file which gives sensible |
| 24 | results for both Tk and (say) Motif applications. |
| 25 | |
| 26 | =head1 BUGS |
| 27 | |
| 28 | Currently B<optionAdd>(I<key> =E<gt> I<value>?, I<priority>?) ignores optional |
| 29 | priority completely and just does XrmPutStringResource(). |
| 30 | Perhaps it should be more subtle and do XrmMergeDatabases() or |
| 31 | XrmCombineDatabase(). |
| 32 | |
| 33 | This version is a little slower than Tk's re-invention but there is |
| 34 | more optimization that can be done. |
| 35 | |
| 36 | =head1 SEE ALSO |
| 37 | |
| 38 | L<Tk::option|Tk::option> |
| 39 | |
| 40 | =head1 KEYWORDS |
| 41 | |
| 42 | database, option, priority, retrieve |
| 43 | |
| 44 | =cut |
| 45 | |