Hi Bryan, thanks for taking a look :-) On 12/23/05, Bryan Baldus <[EMAIL PROTECTED]> wrote: > > I don't know how other catalogers feel, but based on experience using > other > programs (Bibliofile--DOS-based (a.k.a. BFC); ITS for Windows; OCLC; > RLIN), > I prefer having the subfields of a field in a line, rather than one > subfield > per line as done by as_formatted. Would having a format similar to > MARC::MARCMaker's (or LC's tagged display as seen at > < > http://www.loc.gov/cgi-bin/zgstart?ACTION=INIT&FORM_HOST_PORT=/prod/www/dat > a/z3950/locils.html,z3950.loc.gov,7090>) be difficult to implement?
That shouldn't be too difficult. I'll take a look at how MARC::MARCMaker's output looks. Should be able to add some kind of "-format => maker" when creating the widget... I'll hack on that over Christmas. For the leader, is it possible to shield the non-modifiable positions from > the user, since catalogers will only be interested in those bytes? In BFC > and ITS, at least, the leader is presented with bytes 5, 6, 7, 17, 18, 8, > 9, > and 19, (and 22, 23 as 00) editable--one can just position the cursor at > the > start of the leader and type "nam a" to get the desired bytes (new > language > material monograph full-level under AACR2). I am having trouble editing > the > leader in the current version of the program. At times I can change bytes, > but once one is changed, it changes colors and doesn't seem to want to be > modified again. Hmm. I'll take a look at that again - the intention was to display all leader fields, but only allow editing of the editable fields. You should be able to use the arrow keys to move between editable leader fields. An editor or description of the 008 (and 006 and 007) bytes would be > welcome, however. BFC had a display: > Fixed Data 008 030729s2003 caua 001 0 eng d > Entrd: 030729 Dat tp: s Dates: 2003, Ctry: cau Illus: a > Int lvl: Repr: Cont: Govt pub: Conf pub: 0 > Festschr: > 0 > Indx: 1 M/E: Fict: 0 Bio: Lang: eng Mod rec: Source: d > > So, the 008 appeared as it does in the MARC, but beneath it was a brief > description of each position. As one moves the cursor along the 008 field > string, the appropriate position highlights in the description lines. Yep, that's a great idea. Would it make sense to set those fields (006/7/8) up like the leader? Are the shift and control keys supposed to act as forward delete keys, or is > that a problem with my system? Nope, they shouldn't be doing that - but they are on mine, too. (I've probably failed to completely understand Tk bindings... have to do some more digging :-) Is it possible to have the tab move one among fields, subfields, and byte > positions, rather than having it enter a tab/space character? Excellent idea, and should be easy to implement. Buttons for saving the record to a file (is this the purpose of Dump MARC > and reload?) (and ability to specify what file) might be useful (though > that > is sort of covered by the Dump button, with output to the command line). I'll write a better example application :-) But the short answer is that if you create a button who's action calls $ed->Contents() (where $ed is the Tk::MARC_Editor widget), it will return you your record in MARC::Record format, and you can do whatever you want with it. A button to scrap changes and revert to the original version of the record > might be useful (at least until some of the problems mentioned above are > fixed). Yep. I'll add that to the sample app over Christmas. Please keep up the good work. Thank you, Heh - thank *you* (and Andy, and Ed) for building the tools in the first place! -David Christensen
