From: Michael M. <mic...@ma...> - 2004-12-27 04:20:41
|
Hi, I've made some large progress on the macro stuff. Unfortunately, it involved some serious time-sink dead ends (just as I expected). Unlike the version that's in the current macro branch, for the new version I made 'BDSKComplexString' objects that act like NSStrings. This let me avoid changing the rest of the code (unless you need to create strings that are macros - I had to write some parsing for that.) So the major remaining hurdle is UI. Here's how I've handled it for now - everywhere a bib is displayed, you see the expanded value of the macro, if it is defined. If it isn't, you see the macro itself, along with some way of showing that it's an undefined macro. Editing the bib still uses the NSForm. If the field is a macro, it shows the expanded version when you're not editing it. When you start editing a field, a small window with a text field pops up in the same place as the form cell. The window has a check box to choose whether or not you're editing the field as a macro. If the field is a macro already, when you edit it, the check box is checked and the window is a little larger, showing the expanded value. The editable field itself shows the macro. Maybe a movie would show it better: http://michael-mccracken.net/bdmacroeditmovie2.mov The question is, is this too intrusive for editing non-macros? There are some medium difficulty steps still to go to get it to work with the key-loop, to make it move and resize with the parent window, etc. A potential other solution would be to just support macros as a less common feature, and have the standard NSForm work as it does now, except for when you're editing a macro, in which case you just edit the raw macro. This works for reading in files, but we'd need some kind of way to specify that you want a new field to become a raw macro. I think this solution would be faster, and less of a change, but it's not quite as useful for people using macros... Another solution is like the previous alternative to not have a separate window, but to show the expanded version of a field until you edit it, then when you edit it you edit the raw macro - this I can do with formatters. Also, one way to handle how a user can make a field be interpreted as a macro is to give them something they can type that is interpreted as a macro. Something that would otherwise generate invalid bibtex is a good choice, like this: } macro which is actually really similar to the current trick to get BD to output 'macros': } # macro # { Comments? -mike |
From: Adam R. M. <ama...@ma...> - 2004-12-27 05:20:38
|
On Dec 26, 2004, at 20:20, Michael McCracken wrote: > Maybe a movie would show it better: > > http://michael-mccracken.net/bdmacroeditmovie2.mov > > The question is, is this too intrusive for editing non-macros? There > are some medium difficulty steps still to go to get it to work with > the key-loop, to make it move and resize with the parent window, etc. This looks way cool! I'm a bit concerned that it will be annoying for non-macro users, though. What about only popping that window up in response to a key sequence or something, sort of like hitting esc to get autocompletion? I like what you've done with showing the expanded version for display everywhere. The other solutions you mention are good, but they don't give you the preview while you're editing, which is the benefit of what you showed in the movie, correct? Also, can you elucidate the purpose of the "Edit Macro" button? -- Adam |
From: Michael M. <mic...@ma...> - 2004-12-27 06:01:47
|
On Dec 27, 2004, at 12:20 AM, Adam R. Maxwell wrote: > > On Dec 26, 2004, at 20:20, Michael McCracken wrote: > >> Maybe a movie would show it better: >> >> http://michael-mccracken.net/bdmacroeditmovie2.mov >> >> The question is, is this too intrusive for editing non-macros? There >> are some medium difficulty steps still to go to get it to work with >> the key-loop, to make it move and resize with the parent window, etc. > > This looks way cool! I'm a bit concerned that it will be annoying for > non-macro users, though. What about only popping that window up in > response to a key sequence or something, sort of like hitting esc to > get autocompletion? Excellent suggestion - So, I guess I should pop that window up if the field already is a macro, but otherwise, don't change the usual behavior unless we want to make the field a macro, then have a key command (maybe a menu item somewhere too, perhaps with the add field action menu?) > I like what you've done with showing the expanded version for display > everywhere. Yeah, it's a little halfbaked, in that the preview still has special-case code that it doesn't need anymore. What's going on behind the scenes is there's a BDSKComplexString class that (if it's complex, ie, has macros) has a list of nodes that are either strings or macros. When it's created, it expands those and stores the expanded value as an ivar. Thru the magic of ObjC, anytime it receives a message it doesn't understand, it tried to send it to the expanded value string ivar instead before giving up. So you can use it in almost every place you can use a real NSString. > The other solutions you mention are good, but they don't give you the > preview while you're editing, which is the benefit of what you showed > in the movie, correct? Yeah. In the simpler cases, you'd just have to keep the list of document macros open for reference, or just tab away from the field to see what it expanded to. > Also, can you elucidate the purpose of the "Edit Macro" button? I'm not sure about the wording. It might need to be "Edit Expansion" or "Edit String Constant". The idea is maybe you type 'mkp', which is the right abbreviation for "Morgan Kaufman Publishers" but you see that the @string() was wrong, and you need to edit that. It'd take you to the macros window (Which I didn't show, but it's there, just a simple editable tableview) and you could fix it. But then I need to send a notification that a macro changed and every complexstring needs to potentially update its expandedvalue. Ugh. -mike |
From: Adam R. M. <ama...@ma...> - 2004-12-27 06:19:04
|
On Dec 26, 2004, at 22:01, Michael McCracken wrote: > > On Dec 27, 2004, at 12:20 AM, Adam R. Maxwell wrote: > > Excellent suggestion - So, I guess I should pop that window up if the > field already is a macro, but otherwise, don't change the usual > behavior unless we want to make the field a macro, then have a key > command (maybe a menu item somewhere too, perhaps with the add field > action menu?) Yes, exactly; the action menu seems like a good place for it, too. [...] >> The other solutions you mention are good, but they don't give you the >> preview while you're editing, which is the benefit of what you showed >> in the movie, correct? > > Yeah. In the simpler cases, you'd just have to keep the list of > document macros open for reference, or just tab away from the field to > see what it expanded to. And that tabbing in and out would probably get old quickly, so I think your solution is better! > >> Also, can you elucidate the purpose of the "Edit Macro" button? > > I'm not sure about the wording. It might need to be "Edit Expansion" > or "Edit String Constant". > The idea is maybe you type 'mkp', which is the right abbreviation for > "Morgan Kaufman Publishers" but you see that the @string() was wrong, > and you need to edit that. It'd take you to the macros window (Which I > didn't show, but it's there, just a simple editable tableview) and you > could fix it. > > But then I need to send a notification that a macro changed and every > complexstring needs to potentially update its expandedvalue. Ugh. Ah, I figured it was something like that. Sounds like we might have some fun with Shark on this one ;). later, Adam |