first interactive app

[castironpi at gmail.com]

On Mar 26, 5:11 pm, Miki <miki.teb... at gmail.com> wrote:
> Hello Tim,
>
>
>
>
>
> > I want to write a tiny interactive app for the following situation:
> > I have books of many chapters that must be split into volumes before going
> > to the printer.
> > A volume can have up to 600 pages. We obviously break the book into volumes
> > only at chapter breaks. Since some chapters make a natural grouping, we want
> > some human interaction for where the volume breaks occur.
>
> > Not having experience with interactive apps, I'm asking for advice about how
> > to go about it. The data I start with is just a dictionary with chapter name
> > = ending page number. I figured I would first show where the volumes would
> > break with no human interaction, with the begin and ending chapter
> > names/pagenumbers for each volume.
>
> > From here I thought about having a slider for each volume, but the number of
> > volumes could change during the session.
> > Or maybe I should just ask 'enter the ending chapter for the first volume'
> > and recalculate, etc until all volumes are defined.
>
> > Any ideas on a simple interface for this?
>
> How about something like:
>
> Chapter 1 (001-200 200)
> Chapter 2 (200-300 100)
> ------ 001-300 300 ----
> Chapter 3 (300-450 150)
> Chapter 4 (450-500 50)
> ------ 300-450 250 ----
> Chapter 5 (500-600 100)
> ------ 500-600 100 ----
>
> Where the user can move the divider up and down to create new volume,
> they can also add and delete dividers.
>
> The program will not allow to drag the divider above the 600 page
> limit.

If you're a WISIWIG editor, you can select text by
 - typing STRNG
 - editor overlays IDs on every occurence
 - repeat or select number

I'm looking at debugging, and you do get:

>>> pdb.run( 'f()' )
> <string>(1)<module>()->None
(Pdb) s
--Call--
> <stdin>(1)f()
(Pdb) s
> <stdin>(5)f()
(Pdb) s
--Call--
> c:\programs\python\lib\io.py(1235)write()
-> def write(self, s: str):
(Pdb) l
1230            return self.buffer.fileno()
1231
1232        def isatty(self):
1233            return self.buffer.isatty()
1234
1235 ->     def write(self, s: str):
1236            if self.closed:
1237                [snip]
1238            if not isinstance(s, str):
1239                [snip]
1240                [snip]

allowing you to see what you want, adjust, and keep a mind's-eye
representation of the program.

Are you complaining that the mouse is too slow?  That the GUI is too
distant?  Closest lexical: 'editor sucks' and 'console sucks'.

I think a SmartConsole would take A.I.  I want a multi-column console.

I'm not sure how generally you can harness today's GI on a keyboard,
but tomorrow's certainly can.  (scrollbar2 up>up>up), and I think
you'd get console gi primitives pretty quickly.  (graphical/spatial
interface.)

You're thinking of mimetic/conceptual zoom.  How does this look?

>>> open
Chapter 1 (001-200 200)
Chapter 2 (200-300 100)
------ 001-300 300 ----
Chapter 3 (300-450 150)
Chapter 4 (450-500 50)
------ 300-450 250 ----
Chapter 5 (500-600 100)
------ 500-600 100 ----
>>> move up
Chapter 1 (001-200 200)
------ 001-200 200 ----
Chapter 2 (200-300 100)
Chapter 3 (300-450 150)
Chapter 4 (450-500 50)
------ 300-450 150 ----
Chapter 5 (500-600 100)
------ 500-600 100 ----
>>> move up
Chapter 1 (001-200 200)
------ 001-200 200 ----
Chapter 2 (200-300 100)
Chapter 3 (300-450 150)
------ 200-450 250 ----
Chapter 4 (450-500 50)
Chapter 5 (500-600 100)
------ 450-600 150 ----

But us mortal humans, temporal beings, get confused quickly with what
section is where, so we'll mis-specify eventually.  ("No, the -other-
up!")

Did everyone know that the graphics blits in BASIC were 'get' and
'put'?

You could probably pick a recommended contextmanager out of the box;
it could learn what you wanted by when you said 'no'.  You'll want a:

>>> notify me when a volume's page length > 600

which isn't clear at all how to translate into CS in a rigorous way,
and its varying meanings for different structures.

>>> Upon( page length.volume > 600 for volume in book, print )

And each page length change notifies 'Upon', cf. Observer.

I feel like the way from point A you mention and the actual
implementation would be useful.  Python shows promise for 'rollback'
potential too.

>>> UponAny( page length.volume > 600 for volume in book, raise )
>>> Upon( any( sum( volume ) > 600 for volume in book ), raise )

Somehow, your data are still around during console session-- exception
doesn't kill a console.  This one generates a console of a dictionary
and lets you assign to it.

--> a= 2
--> print( a )
2
-->

def con():
    while 1:
        try:
            yield input( '--> ' )
        except:
            print( 'exception.' )

glos, locs= {}, {}
for inp in con():
    exec( inp, glos, locs )

We might have to mark our objects live / "on the air", to notify
generators of change in conditions, rerun at every step.  I think you
need live primitives.