Hello - > We have almosts all the features requested in libabiword for this. The > only one currently missing is rotating the image, but this should not be > too hard to implement.
Another note on the image: the rightmost icon in the image toolbar is a "toggle caption" button. I don't know if this is already supported or not. It should auto-format the image with the appropriate padding and provide an area beneath it for adding caption text, automatically placing the cursor in the caption area. Optionally, the rollover for this button could have a checkbox for "treat as figure" or something, automatically numbering the figures in a document. > What is the time frame for implementing this? We're working on getting an API together for the controls in the near future as well. It would be better if development ran parallel to the creation of the necessary controls so that work doesn't need to be redone to incorporate the proper widgets later. It also depends heavily on an API for tabbed toolbars, which isn't yet available. > I notice that undo/redo is only available for text, whereas all the > manipulations shown in the mockups can be undone/redone. Does it make > sense to provide undo/redo for all toolbars or even on the menu bar? Actually, the undo/redo buttons reside inside the "Edit" toolbar, which isn't specific to text at all. They should map to anything at all that sits in your changeRecord stack. > Do you intend that different toolbars are automatically changed upon > context? For example, if a user clicks on an image, does the toolbar > change to "image" automatically? Absolutely. This is one of the key ideas behind this toolbar design, which hopes to virtually eliminate the need to switch editing contexts via the tabs themselves. Clicking on an image, table, or within text should automatically select the corresponding toolbar. Selecting text inside a table cell, or inside a caption should likewise select the text toolbar. > Regarding "insertTable", I think our little inserttable widget which lets > the user interactively size the dimensions is easier and more intuative > than selecting x and y dimensions. The numbers here represent the number of rows and columns in the inserted table, not the dimensions of the table itself. I'm not familiar with your current functionality, though, so it would be great to see that. Also, these dimensions would be set to some default (like 3x3) and only appear on secondary rollover. They wouldn't be required; clicking on the button directly would insert a table with the default (or last set) number of rows and cols. > Regarding the table toolbar, there are two entries shown with "100" and > "24", which appear to be size in percent of the width of the page of the > horizontal and vertical dimensions. Is that correct? I wonder if these are > neccessary? It seems a rather esoteric idea to young children. The width > an heights of the columns can be adjusted by dragging the column and row > seperators on screen. This is true; It's not strictly necessary. The general idea behind these controls is that I might want every row to be twice as tall as the default, and there's no good way through direct interaction to tell a bunch of rows to be the same size. > In there place you might want to provide buttons to merge and split cells > horizontally and vertically. Interesting point. I hadn't really considered merging and splitting necessary for most use cases, but perhaps people use that more than I. I'm open to this if people agree that this is a needed feature. > Regarding the page margins, could you clarify how you would like this to > be displayed on screen? Currently we suppress the top, bottom, right and > left margins to get the maximum amount of text on screen. To show margins > we go into what we call "print view" which is what the text will look like > once printed. Given this, do you intend for write documents to be printed? > If so should we enable printing for Write? Well, we're certainly not designing with printing in mind. We expect that most content with be both created and consumed digitally. For that reason alone, even if we have such a preview we should certainly not use "print preview" to describe it. It could be the case that we don't need margins at all, though the format bar certainly has the room for it, and I personally see margins as a design tool just as relevant for digital content as for printed material. Since the view toolbar provides a way to zoom in and out, if we keep margins perhaps a specific zoom level could be something to the effect of "tight fit" without margins... > Thanks very much, it is an interesting design and it's nice to a get a > direction. Glad you like it; sorry for the delays. We've been spending considerable time on nailing down the look of the controls and the toolbar interface itself. Please feel free to critique it, offer suggestions for a slightly altered feature set, etc. It can certainly evolve from here. Finally, here are a few issues that aren't addressed in this design that we may need to add later: 1) Annotations. We hope to provide an annotation system for crossmark documents so kids and teachers can write notes "in the margins" of the pages. It would be ideal if both read and write had consistent implementations for this in the UI. The general idea at present is to have a small (45 px wide) gutter in the left margin of the activity which contains a heat map of sorts for each block of text, indicating how many annotations it has. Clicking in the gutter could reveal the annotations and allow for editing or creation of new ones. 2) Headers. Since everything is digital, the crossmark spec focuses on headers - just like wikis - instead of pages as the primary means of navigation. Since the reader will support dynamic TOC generation and navigation, it seems only natural that the write activity provide a means of creating (and navigating by) these headers. 3) Crossmark editing. Since the goal is to use crossmark as the underlying format, it would be nice to be able to expose the crossmark source for a document, perhaps with a toggle button under the view toolbar. Additionally, one should be able to input crossmark directly. There are two interesting ways we could make this work across the views. We could have a crossmark interpreter of sorts which would take a string of text typed with asterisks as in *bold* and automatically render it as bold when in formatted view. Also, when in crossmark view, it would be great if all of the tools (insert table, insert image, add row, etc) still worked, but worked by inserting the proper crossmark markup directly. - Eben _______________________________________________ Sugar mailing list [EMAIL PROTECTED] http://mailman.laptop.org/mailman/listinfo/sugar
