[Tutor] Multiple front-ends in project

trent shipley trent.shipley at gmail.com
Tue Jun 27 12:46:45 EDT 2023


On Fri, Jun 23, 2023 at 5:51 PM Alan Gauld via Tutor <tutor at python.org>
wrote:

> On 23/06/2023 18:11, trent shipley wrote:
> > I have written the simple core logic for a dice rolling program.  It is
> In
> > ./app/core.  I am planning to add more complex helper classes in
> > separate files to do more complex things like rolling different kinds of
> > dice in one throw, or exploding dice.
> >
> > I plan four interfaces, two CLI, and two GUI.
>
> When you say "interfaces" I assume you mean user interfaces?
> Or do you include an API so that other programmers can use
> your code too?
>
>
I mean four user interfaces are planned, in addition to direct access to
the dice rolling logic itself as a python module or package.



> If we restrict ourselves to user interfaces, did you design
> your code to follow the MVC pattern? If so, it should be easy
> to implement VC classes for each type of UI, and also Web
> or network interfaces if needed later.
>
> If you didn't use an MVC architecture then you should probably
> rework the core code to be a model that can speak to views and
> controllers. It will make life much easier for everyone.
>
>
If the math logic of the program is the model and the UI is the view, then
I thought the role of the controller was to put a dependent abstraction
between the model and the view?



> >    1. A pretty simple CLI with just the basic core functionality.
> >    2. A small DSL for rolling dice, with support for complexities like
> >    using pre-provisioned numpy probability functions and using in one
> throw,
> >    re-rolls if a result is in a certain range and so on.
> >    3. A GUI meeting common requirements for role-playing games.
> >    4. A "Scientific GUI" with some, but not all, of the power of the
> >    command line and scriptable DSL.
>
> That is a combination of vague waffle and domain specific gobbledegook.
> We can't possibly guess what that means.
>
> > *Buried Lead:*
> > I am now working on #1 the Simple CLI.  ** How do I arrange things so I
> can
> > run ./app/cli/simple_cli/simple_hdroll_cli_main.py as "$
> > python3 shdroll kwargs"? **
>
> Create an alias on your OS?
>

That might work.  I think I'll just rename the source code file I want to
run to 'shdroll'.

>
> > Looking to the future, how do I package and distribute my project so it
> can
> > be used conveniently on all three OSes per my design intent.
>
> Which three OS? There are many more than 3 OS in the world.
> Which OS do you have in mind?
>

I was thinking of  the program as running on consumer 'desktop' OSes, so
Windows, Mac, and some Linux families which are popular for desktop use,
but not Chrome.  The design is really vulnerable to injection attacks, so
providing a web interface "might not be a good idea".   As for Android and
iOS, I'm not even thinking of that now.

>
> I'll take a guess at Windows and MacOS Cocoa as two?
> The third could be web(and thee are several options there?!),
> CLI, Posix, Unix/CDE, Linux(which desktop>?), MVS, VMS, etc, etc.
>
>  (The command
> > line interfaces work like command line commands, The DSL can interpret
> and
> > run scripts, and the GUIs act like native GUI programs for all three
> OSes.
> >  (I am developing on Linux Mint.))
>
> Even stating Linux Mint still leaves us guessing over desktop
>  - Cinnamon, Mate, LXDE, etc?
>

Cinnamon.

>
> User interfaces are very specific things. You can't even just say
> GUI. There are many GUI frameworks and they are all quite different.
> Are you using Tkinter, wxPython, pyGTK, Side, or the native toolkits
> for each OS - Windows MFC(via pythonwin) or the .NET framework -
> possibly via IronPython?! Or Cocoa on MacOS?
> Or Java Swing using jython - that would be cross OS, and work on
> much more than 3 OS.
>
>
> I have not gotten as far as selecting a Python friendly GUI framework.  I
used tkInter once in a 100 level class.  I'd like to stay with an 'all
Python' design so that the package is "easy" for other Python programmers
to modify.


> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
> http://www.amazon.com/author/alan_gauld
> Follow my photo-blog on Flickr at:
> http://www.flickr.com/photos/alangauldphotos
>
>
>
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> https://mail.python.org/mailman/listinfo/tutor
>


More information about the Tutor mailing list