Line 3: |
Line 3: |
| === Usage === | | === Usage === |
| A learner will: | | A learner will: |
− | *review and run an included example module, observing code and behaviour, | + | *review and run an included example module, observing code and behaviour, <font color="#008000">(exists)</font>, |
− | *modify an included example module, and run the modified version, observing changed behaviour, | + | *modify an included example module, and run the modified version, observing changed behaviour, <font color="#008000">(exists)</font>, |
− | *write a fresh module, creating new behaviour, | + | *write a fresh module, creating new behaviour, <font color="#008000">(exists)</font>, |
− | *write a fresh module that imports an included example module unchanged, deriving behaviour from existing behaviour, | + | *write a fresh module that imports an included example module unchanged, deriving behaviour from existing behaviour, <font color="#c00000">(new)</font>, |
− | *write a fresh module that imports a modified example module, | + | *write a fresh module that imports a modified example module, <font color="#c00000">(new)</font>, |
− | *write two fresh modules one of which imports the other, | + | *write two fresh modules one of which imports the other, <font color="#c00000">(new)</font>, |
− | *derive more complex code using modules created by teachers or other learners, with or without changing the contributed module. | + | *derive more complex code using modules created by teachers or other learners, with or without changing the contributed module, <font color="#c00000">(new)</font>. |
| | | |
| A group of learners will do the above, but also: | | A group of learners will do the above, but also: |
− | *collaborate on a set of modules included in the shared activity instance, | + | *collaborate on a set of modules included in the shared activity instance, <font color="#c00000">(new)</font>, |
− | *run modules locally on each laptop. | + | *run modules locally on each laptop, <font color="#008000">(exists)</font>. |
| | | |
| A pair of learners may: | | A pair of learners may: |
− | *create one subordinate module each, and concentrate on it, | + | *create one subordinate module each, and concentrate on it, <font color="#c00000">(new)</font>, |
− | *create one master module that imports the two subordinate modules, | + | *create one master module that imports the two subordinate modules, <font color="#c00000">(new)</font>, |
− | *write unit tests in each subordinate module and run them locally on each laptop, | + | *write unit tests in each subordinate module and run them locally on each laptop, <font color="#c00000">(new)</font>, |
− | *integrate by running the master module. | + | *integrate by running the master module, <font color="#c00000">(new)</font>. |
| | | |
| === Purpose === | | === Purpose === |
Line 29: |
Line 29: |
| A running Pippy instance will contain the following data: | | A running Pippy instance will contain the following data: |
| *zero or more modules, | | *zero or more modules, |
− | **(either pure python modules, packages, or distutil source distributions, though not a sugar bundle), | + | **(either pure python modules, packages, or distutils source distributions, though not a sugar bundle), |
− | *each module will include zero, one (pure python modules) or more (packages or distutil source distributions) source files, | + | *each module will include zero, one (pure python modules) or more (packages or distutils source distributions) source files, |
− | *each module will include a source file setup.py capable of creating the python distutil source distribution output, but unless the user has asked to edit the setup.py, it will not be shown, instead a default will be used, created and maintained by Pippy, | + | *each module will include a source file setup.py capable of creating the python distutils source distribution output, but unless the user has asked to edit the setup.py, it will not be shown, instead a default will be used, created and maintained by Pippy, |
| | | |
| A shared Pippy will contain the same data as above on each laptop. | | A shared Pippy will contain the same data as above on each laptop. |
Line 40: |
Line 40: |
| *a module in the journal, (which may have come from a teacher, another learner, or a server), using the object chooser, | | *a module in the journal, (which may have come from a teacher, another learner, or a server), using the object chooser, |
| **in pure python module form, as a single source file, | | **in pure python module form, as a single source file, |
− | **in distutil source distribution form, as multiple source files inside a tar or zip container, | + | **in distutils source distribution form, as multiple source files inside a tar or zip container, |
| *pristine example modules included with Pippy, using a button and an example chooser. | | *pristine example modules included with Pippy, using a button and an example chooser. |
| | | |
Line 57: |
Line 57: |
| *a pure python module or package module, which will start the Pippy activity in an execution only mode that behaves in the same way as the "run" button, displaying a VTE (only if stdout is written to, or stdin is read from), and if not exiting immediately, without creating a journal entry. | | *a pure python module or package module, which will start the Pippy activity in an execution only mode that behaves in the same way as the "run" button, displaying a VTE (only if stdout is written to, or stdin is read from), and if not exiting immediately, without creating a journal entry. |
| | | |
− | === Display === | + | === Display - Editing === |
| Display will contain: | | Display will contain: |
| *toolbar, | | *toolbar, |
Line 66: |
Line 66: |
| (the series of tabs encapsulated in another series of tabs is potentially difficult for a learner to comprehend, but an alternative tree view is thought inappropriate because of the horizontal space consumed, and because use of a module should be constrained to the public API of the module). | | (the series of tabs encapsulated in another series of tabs is potentially difficult for a learner to comprehend, but an alternative tree view is thought inappropriate because of the horizontal space consumed, and because use of a module should be constrained to the public API of the module). |
| | | |
− | === Process === | + | Activity canvas GTK+ widget hierarchy, assuming two modules open, modules "main" and "test", of which "main" has a file "file.py", and "test" has a file "test.py": |
| + | |
| + | *gtk.Notebook (tab labels "main", "test", "+") |
| + | **notebook page label "main", a gtk.Notebook (tab labels "__doc__", "file.py", "setup.py", "+") |
| + | ***notebook page label "__doc__", a GtkSourceView in read-only mode, hidden if __doc__ is empty, |
| + | ***notebook page label "file", a GtkSourceView for "file.py", |
| + | ***notebook page label "setup", a GtkSourceView for "setup.py", hidden if not yet edited by learner, |
| + | ***notebook page label "+", creates a new file, prompts for file name, defaults to .py, |
| + | **notebook page label "test", a gtk.Notebook (tab labels "__doc__", "test.py", "setup.py", "+") |
| + | ***notebook page label "__doc__", a GtkSourceView in read-only mode, hidden if __doc__ is empty, |
| + | ***notebook page label "test", a GtkSourceView for "test.py", |
| + | ***notebook page label "setup", a GtkSourceView for "setup.py", hidden if not yet edited by learner, |
| + | ***notebook page label "+", creates a new file, prompts for file name, defaults to .py, |
| + | **notebook page label "+", creates a new module, prompts for module name. |
| + | |
| + | (if the page "+" technique does not work, then toolbar buttons will be required to create a new module, create a new file in a module, or import an example module). |
| + | |
| + | === Display - Running === |
| When run is pressed, display will contain: | | When run is pressed, display will contain: |
| *toolbar, | | *toolbar, |
| *stdout stdin vte, (only if stdout is written to, or stdin is read from), | | *stdout stdin vte, (only if stdout is written to, or stdin is read from), |
| *a stop button. | | *a stop button. |
| + | |
| + | Activity canvas GTK+ widget hierarchy: |
| + | *gtk.Container |
| + | **gtk.VBox |
| + | ***gtk.HBox |
| + | ****gtk.VScrollbar |
| + | ****vte.Terminal |
| + | ***gtk.Button Stop |
| | | |
| === Changes === | | === Changes === |
| Partial list of changes to bring Pippy existing source to a state consistent with the design above: | | Partial list of changes to bring Pippy existing source to a state consistent with the design above: |
− | *remove the examples widget from the main screen, provide it only as an "open an example bundle" function, | + | *remove the examples tree widget from the main screen, provide it only as an "open an example bundle" function, this will permit the GtkSourceView widget to be full screen width, |
− | *remove the output window from the main screen, provide it only when a program is run, and only if the program generates stdout or reads from stdin, | + | *remove the output window from the main screen, provide it only when a program is run, and only if the program generates stdout or reads from stdin, this will permit the GtkSourceView widget to be nearly the full height available, |
− | *enlarge the program text entry widget to be nearly full screen,
| + | *provide multiple GtkSourceView widgets, once for each file in each module, within gtk.Notebook within gtk.Notebook, |
− | *encapsulate the program text entry widget in tabs for files in a zip bundle, | + | **the outermost tabs will be module names, |
− | *encapsulate the bundle in tabs for zip bundles loaded into pippy instance, | + | **the innermost tabs will be file names within each module, |
− | *on standard sugar save, save all zip bundles and files in a sugar journal entry, | + | *on toolbar save button, save all modules and files in a journal entry, |
− | *provide an export zip bundle button that creates a sugar journal entry of type zip bundle, for sharing, | + | *when a module is selected, provide an export button that creates a sugar journal entry for a distutils source distribution package, for sharing, |
− | *provide a way to import zip bundles from journal into the current pippy instance, using the object chooser, | + | *provide a way to import pure python module or distutils source distribution package from journal into the current Pippy instance, using the object chooser, successful import will add to the modules displayed, |
− | *on execution of a bundle, allow access to all other currently loaded bundles via import, and access to system bundles via import, | + | *on execution of a module, allow import of all other currently displayed modules, modules included with Pippy (such as the existing pippy module), and system modules, |
| + | *convert the examples to either pure python module or package form. |
| | | |
| === Alternative === | | === Alternative === |