On Apr 30, 2005, at 21:03, Adam R. Maxwell wrote:
> On Apr 30, 2005, at 06:38, Christiaan Hofman wrote:
>> (This is a reaction to another thread, seems better to start a new
>> one on it).
>> It seems clear, and I agree, it's much better to go for a tableview
>> for the fields in the editor (embedded in the main window or not).
>> Now for editing macros... we could use the macrotextfieldwindow for
>> that, after some modifications.
>> However I think it would work even better if we create a
>> textfieldcell subclass and use that for complex string values. Would
>> that work? Maybe we also need to use a subclass for the field editor
>> to make this work. This has the advantage that we keep everything in
>> the window, even the table, so we don't have all the peculiarities we
>> now have from the fact that the macrotextfieldwindow is another
>> window floating above the editor.
> I'm afraid I haven't looked at the macrotextfieldwindow enough to know
> how this works
It is basically a window that floats above the editor, and is placed
such that the textfield covers exactly the 'textfield' in the formcell.
> presently. If you used a custom cell, would it displace the other
> rows in the tableview,
I am not sure what custom cell you would think of. With the present
implementation (but with a tableview) I could only think of basically
the same thing: have the macrotextfieldwindow float above the tableview
such that it covers exactly the cell you want to edit. This would be
easy to implement with what we have now, eg in the TextImport sheet.
> or float above them? With a single cell, you'd have to be sure it
> didn't wrap, I suppose.
The idea is to replace the cell, returning the custom cell in
tableView:willDisplayCell:... when it is edited as raw bibtex.
> Do you envision the same appearance we have now?
The appearance would be somewhat different, as it doesn't float above
it. It is just a cell with a higher width, which contains several
textFieldCells obaove eachother, one of which is editable and one which
displays the expanded value. So there is also no shadow, and it does
not cover the other cells. It should expand its rowheight, I think that
can be done automatically by implementing the appropriate methods (at
least image cells can do it).
> Further, should we do this for 1.0? It sounds like it might be
> reusable for 2.0 (although we may want to use bindings there), which
> would probably make backporting changes to BibEditor 1.x easier.
I don 't think we should do this for 1.0, as I think we should keep 1.0
basically as we have it now. Changing the editor to use a tableview
might involve too much work to be worth changing now for 1.0. My
remarks are just a trial balloon for 2.0.