On 5 Jun 2008, at 11:30 PM, Adam R. Maxwell wrote: > In article <[EMAIL PROTECTED]>, > Christiaan Hofman <[EMAIL PROTECTED]> wrote: > >> On 5 Jun 2008, at 8:20 PM, Adam R. Maxwell wrote: >> >>> I always wondered why the combo box in the add-field sheet allowed >>> invalid names like "Remote URL" when using the drop-down. I had a >>> hunch >>> that fixing bug #1984947 might break this, so I tried it in the >>> latest >>> nightly...and indeed "Remote URL" no longer works. >>> >>> So it appears that this worked because the formatters were >>> implemented >>> incorrectly, and validation only worked in a limited set of >>> circumstances. Oops. >>> >> >> Ah, yes, that was the reason it was never implemented to validate. I >> removed it and added a comment. > > Nope, it's just an ancient bug that I can blame on Mike. I'm guessing > that's also why I had problems with some of the format failure > delegate > methods in the editor, a long time ago. > > Anyway, I think it's wrong to implement that sometimes-allowing-spaces > logic in a formatter by having a broken primitive method, since it > makes > assumptions about which methods are called and when (and ties it to a > specific control and/or OS release). >
I've added a delegate method to get an array of known field names. Those will always be valid, and allows us to do full validity checking, including in getObjectValue:.... So it moves the custom stuff to the delegate, which is much more appropriate. It also allows completion of those special fields on Leopard. >>> Any ideas on improving the add-field sheet? Users are perpetually >>> confused by the inability to type e.g. "Remote URL" when told to add >>> it, >>> and it's not intuitive that you could choose it from the drop-down. >>> (I >>> had a couple of offlist back-and-forth sessions on this last week >>> that >>> prompted me to add step-by-step instructions to the wiki). >>> >>> Adding a popup of predefined "special" fields with a textfield for >>> direct entry might work, but it would also be confusing (didn't we >>> do >>> that at one point?). >> >> That would be even more confusing than the popup-like setup we have >> now, I think. > > Sadly, I don't have a better UI widget in mind, but I was hoping > someone > else might...maybe the users list would have an idea. > > Okay, before hitting Post I had an idea: the drop-down is too small > (IMO) to easily find fields anyway. What about having a two-column > tableview of fields and checkboxes, with the option to add an > additional > row for unknown fields? Then you could see all of the predefined > "Author" fields at a glance and so on, as well. For the organization > freaks, they could even be grouped by field type in an outline view > (Person, String, Boolean...). > That would make it impossible to just type and complete (which is what I always use and is very fast). Note that the possible fields are highly context sensitive. So a general organization by the suers would be pretty much impossible. And what would the check boxes be for? >>> I wonder how often you want to add a field that's not declared as a >>> standard/default/custom field in the type manager? That's the only >>> case >>> the formatter should be concerned with. >> >> But it's also often quicker to just type (and complete) instead of >> searching a long menu. And to have a sheet to enter a custom field >> attached to the sheet to choose a field: ouch. > > Having an additional sheet-on-a-sheet would be bad, for sure. But the > fact that you /can't/ type and complete "Remote Field" is another part > of what makes the present system a counterintuitive UI. The number of > times people on the users list have asked about this (and been told to > STFA/RTFM) bears that out! > > -- > adam That would now be much better, as completion now accepts such fields. BTW, this actually did work on Tiger, because it didn't validate the completion object (which was actually a bug). Christiaan ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Bibdesk-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
