Re: [sugar] Write Activity.

Hi Eben,
       I've finished coding up the the keybindings plugin. Programmers can
now define their own mouse and key bindings for libabiword by
editting a straight forward comma seperated text file. This is
needed for OLPC and other applications.

I have time to move onto other jobs now. From the discussion below it
appears that the most useful thing to do next is to define GtkSignals for
"text","table" and "image" contexts. It's not clear that we can guess if
the users to use the "edit", "format" or "activity" tabs from what
they're doing in write though.

Cheers

Martin

>> > 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.
>> >
>>
>> We don't have this feature in libabiword. It will be some work to
>> implement it but I'm pretty sure I can do it.
>
> I think it would be a really nice feature. It's not a priority
> though, so if we need to hold off on that detail in order to get the
> whole activity up to the overall design spec that's OK.
>

OK, thanks for the feedback. Will leave this for now.

>> >> 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.
>> >
>>
>> OK, I certainly like this. We can provide signals to switch toolbars if
>> the mouse hovers over images/tables etc. Do you want this or a change
>> only if the user clicks on a table?
>
> I think the context switch should only happen relative to the current
> selection, so to answer your question I believe it should only occur
> on a click. If a rollover were capable of initiating a context
> switch, you could become quite frustrated by rolling over an image or
> table while trying to get the mouse up to the text editing tools at
> the top of the screen.
>
> In the case of multiple selections, we'll have to think of a sane
> default. It could be that we rank contexts, with text being of
> highest rank in a text editing application, and always show the
> context with the highest rank. Alternatively, we could switch to the
> "edit" context, which allows copy, paste, etc. since those controls
> apply to all selections. We'll have to see what makes the most sense
> in practice.
>

>> > 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.
>>
>> To see it in action, find a desktop linux distro near you. Install
>> AbiWord. Goto View->Toolbars->select table.
>> The table toolbar appears. Click on the table button (the left-most).
>
> OK, I'll have to try that out early next week.
>
>> > 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.
>> >
>>
>> Yes, I can see what you want. I can;t think of a better way to do it
>> yet.
>> We have a dialog that allow you to set the row heights and column
>> widths.
>
> Right. We could alternatively make a single palette button (like a
> menu button) and have the steppers embedded inside that, to free up
> some space/hide them a bit more. In Sugar, that's basically the
> equivalent of making it a popup dialog.
>
>> > 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...
>> >
>>
>> I can see what you want here, but in some cases the scale metaphor
>> doesn;t
>> work. Forst example we supress the top and bottom margins entirely and
>> put
>> pages together. I guess one click out of zoom could get you to a full
>> page
>> view showing all the margins. Further clicks out leave you in full page
>> view but at smaller zoom. Zooming in to normal default view could
>> supress
>> the margins. Further zooms in leave the margins supressed.
>
> Right, I suppose that's along the lines I was thinking about. I also
> realize now that we don't actually have "page breaks." We have
> *virtual* page breaks, but that's not at all the same thing. As such,
> we don't even have an idea of top and bottom margins at all. Perhaps
> we only specify left and right, or perhaps we omit margins entirely.
>
>> > 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.
>> >
>>
>> We have a Google Summer of Code student to work on annotations over the
>> summer. If you need them by mid year, I'll have to step in and do the
>> work.
>
> We'll have to see how this integrates with the other activities as
> well. We need to create a consistent meaning and format for
> annotations across activities.
>
>> > 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.
>> >
>>
>> We have a very sophisticated TOC facility in AbiWord as well as
>> hyperlinks
>> and bookmarks. I'm not quite sure what you mean by headers in the this
>> context. Do you mean navigation through documents via bookmakrs and
>> hyperlinks? Does this include external documents?
>
> From the crossmark spec:
>
> 264 The first two levels of headings are written like so:
> 265
> 266 First-level heading
> 267 ===================
> 268
> 269 Second-level heading
> 270 --------------------
> 271
> 272 The third- and fourth- level headings are written like so:
> 273
> 274 === Third-level heading ===
> 275 ==== Fourth-level heading ====
>
> In lieu of pages, the read activity will use these headings to
> dynamically generate a TOC for a document and allow navigation by
> section (eg. 7.3.5 instead of page 32). If this is the primary means
> for breaking documents into chapters and sections for reading, then
> our write activity should support generation of documents in that
> format.
>
> Bookmarks, by the way, will be integrated with the annotation format
> (they are really a special kind of annotation). We would like to
> support basic navigation by headings, bookmarks, and annotations...
>
>> > 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.
>> >
>>
>> Importing cross mark mark up into AbiWord be straight forward once we
>> have
>> a cross mark importer.
>
> This is a good way to get things working for now. However, I was
> under the impression that the Write activity generated crossmark
> formatted documents, in which case no importer is necessary. This is
> really the aim, even if we don't have fully integrated editing
> capabilities in the first round. It's important that this core format
> for the laptops be supported by both Read and Write. It's also the
> best way to make a powerful annotation system work well.
>
>> Marc Maurer has done quite a lot of work with syntax highlighting for
>> programming languages already. I'm pretty sure this could be extended to
>> cross mark mark up.
>>
>> However the full feature you request, directly composing cross mark in
>> AbiWord is significantly more challenging. We need a new set of views to
>> interpret changeRecord and output Cross Mark into a viewable document.
>> Marc has also done something similar when he made an experimental
>> "reveal
>> codes" feature for AbiWord. This is very doable but is a substantial
>> amount of work.
>>
>> I have one final thought for a feature. How about a "presentations
>> view"?
>> In this mode each page is displayed over a full screen. With a bit of
>> work
>> AbiCollab could be expanded to allow connected computers to be updated
>> synchronously with the presenter. This way a teacher could give a class
>> to
>> group of remote students.
>>
>> In the first pass we would not have animations of text or graphics. We
>> could arrange to make these appear as needed like a simple powerpoint
>> presentation.
>>
>> Later we could implement animations via plugins if needed.
>
> Actually, I think this kind of functionality is much better reserved
> for the read activity, which focuses more on neat and clean
> presentation of text and image data. Perhaps instead we should enable
> "Read this document" and "Write this document" buttons within Write
> and Read respectively, which open the current text object in the
> complimenting activity...
>
> - Eben
>
Received on Fri Apr 20 14:09:38 2007