Subject: Re: lists stuff
From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Mon Dec 04 2000 - 05:57:58 CST
On Sun, 3 Dec 2000, Mike Nordell wrote:
>
> Does this "1.1" imply that you think that a List is connected to the
> numbering of Headings? If that's the case, I'd say it's a serious design
> mistake. A List is a List. A Heading is a Heading. Headings are frequently
> used for e.g. TOC (Table Of Contents), while I've never seen a List entry
> participate in a TOC.
I'm confused. We can use our list infrastructure to do a lot of things.
One thing it can do is provide a list label to a paragraph followed by
paragraphs with no list labels, the the next list in the series.
It would actually be rather easy to define some styles with list labels
associated with them such that the list label does not get propagated to
the next paragraph. Call these numbered headings styles. When you want the
next heading you choose the a numbered heading style again. We could
implement numbered scetions and heading rather easly this way. If someone
could explicitly define the semantics of what should happen with these
numbered heading styles we could implement it rather quickly I think.
So much to do.
Anyway back to the point...
>
> [...]
> > Every time I press return I get the next label in the list.
>
> Just to make 100% sure that I understand you. I nterpreted that as "every
> time I've written something (non-whitespace anyone?) in a list entry and
> press return I get a new list entry".
>
Yes. Try it. You'll see.
> OT: I just got a reason for calling them list entries. A List could actually
> have a label (e.g. "List of Entries"). This lables should probably not be
> displayed most of the time, but it could have a flag telling the list if it
> should display its Label. That label should probably be its own paragraph,
> containing forn, formatting and such. For statistics (or other useful
> purposes) they could then be included in e.g. a "List Index". Wierd?
>
I'm not sure I see why this is useful.
> > I press
> > "back space" to delete the label. For label 1.1 however I have to fire up
> > the dialog and press start "sub list". Then each paragraph gets 1.2 , 1.3
> > , 1.4 etc. Each of those labels has to be deleted however.
> >
> > Then how to a get the 2.? I press "stop list" and 1.4 turns into 2 and the
> > text gets the indentation associated with 2. If the dialog was modeless
> > you don't have to go through the start dialog/stop dialog business while
> > manipulating the list.
>
> OK. This sounds reasonable, except that the semantics of "Stop List" would
> be to stop the list. In this case it "backs up" to the previous
> "list/nesting level". Could it be solved in a more intuitive way? (I don't
> know, I ask to get either some insight by someone with experience, or some
> brainstorming)
Yes I see what you mean. It actually does something more like "reduce List
level by 1". I'm not sure how to succintly say this in English (or any
other language.)
>
> > However there is one additional benefit we could give but is presently not
> > in place. Right now if you delete a list label, the text indention changes
> > to the same level as the following paragraph. The assumption is that most
> > likely if you delete a list label you have finished with the list.
>
> Deleting a list label? Is this the operation of selecting all text for one
> list entry and deleting it, or is it the operation of pressing backspace
> when no text is present for a list entry, or is it the operation of pressing
> return when given a new list entry to end the list? Is it perhaps something
> I didn't even list here?
>
It is pressing "backspace" right before the list label. The way it works
is
<press return>
(Next list label appears)
5. |
<press "backspace">
(label dissappears)
|
> Could it perhaps be fitted in the same semantics that pressing enter on an
> empty list entry terminates the list? Perssing enter on an empty sub-list
> entry "backs up" the list? Don't taki it as a suggestion, I'm just trying to
> find a possibly more intuitive solution.
>
Yes I have implemented both of these. Try it.
> [...]
> > If the dialog is active however we could make the assumption that deleting
> > a list label does mean you've finished with the list and so we would
> > keep the indentation at the current position even after deleting the list
> > label.
>
> ???
> How do you propose we delete a "list label" with the dialog active? Wouldn't
> the Frame Window have to be active to perform this operation? I'm sorry if
> I'm splitting hairs here, I could easily have assumed that you intended "the
> Lists Dialog is visible", but since assumption is the mother of all fsck
> ups... :-)
>
Since the dialog is modeless you can happily keep typing in your frame of
choice. Then in the secanrio I described above:
<press return>
(Next list label appears)
5. |
<press "backspace">
(label disappears)
|
The text maintains the indentation of the list. When you want the next
list label you just press "resume List" on the Modeless dialog.
> > We can also use the "resume list" feature to attach a paragraph to the
> > previous list matching the indentation of the current paragraph.
>
> This makes sense even to me. :-)
> But, could it possibly be even more clear by "Attach paragraph to list"?
> Just brainstorming again.
>
Yes attach paragraph to list is a closer description of what actually
happens.
> > Being
> > modeles would also make it easier to fiddle with the indentation of
> > paragraphs to make them match the paragraphs with list labels.
>
> Thou speaketh wise words. Without modeless a user would easily go insane by
> dismissing the dialog by pressing "OK" just to find out the indention was
> *slightly* wrong.
>
> But on the other hand, this could equally easy (or maybe even easier) be
> handled by messing with the indent-marks on the top ruler. (I'm not opposing
> it, just trying to find something close to "the truth")
I'm not sure if the indent marks on the top ruler function in a Modal
dialog. I suspect they aren't. <trys it> No definately not. You need a
modeless dialog to fiddle with the top ruler while the dialog is active.
>
> > I must admit however that I don't have a particular desire to actually
> > implement a Word Style dialog for Lists. I personally would rather move on
> > to other things. If you Joaquin want to implement I modal MS Word Dialog
> > I'll gracefully bow out of the list dialog business except to provide help
> > if you need it, provided that Thomas and Mike also agree that this is the
> > way to go.
>
> I think we go on to create the one we're currently working on. If/when we
> later decide to create pictures of the symbols instead of their names the
> Lists Dialog framework should already be in place, making that change almost
> trivial.
>
I agree. I don't see why we can't have a modeless dialog with the MS Word
pretty pictures in Notebook style dialog. Clicking "advanced" gets you
straight to the dialog we've been working on. But the pretty pictures are
in "basic" view which is the initial default. A user can click their way
through to select their list and if they need to they can finish in the
dialog we're working on (with their previous selections in place of
course). Or if they're happy with selection of defaults Joaquin provides
they can press "new list" or "modify" or "sub list" at any time.
Here is how I envision the next generation of dialog looking. (See
attached screen shots whipped up in glade.) Notice I've
changed the MX radio buttons to reflect that either the dialog shows the
current list state at the cursor or the list modifications made by the
user. Instead of two activation buttons we now have 5. These will be
activated or not depending on the list state at the cursor.
A modification to the list in the dialog changes the list state from
reflecting the current list to the modified list. The current state can be
shown at any time by pressing the "Show Current List" radio button. You
can flip between current state and "Modified state list" by selecting
either radio buttons.
With Mike and Thomas's view addressable list parameter storage we can
maintain as many different list settings as we have views.
I think this UI has a lot to recommend it. BTW I've also attached the
gzipped glade XML file that builds this dialog for peoples convience.
(At least those with glade :-)
OK that was another long email but I have been thinking about this a lot
too.
Cheers
Martin
This archive was generated by hypermail 2b25 : Mon Dec 04 2000 - 06:23:38 CST
