Re: Multiple front-ends in project

On 27/06/2023 17:46, trent shipley wrote:

> 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?

One of the problems with MVC is that there are now many variants so
anything I say can be contradicted in some specific implementation.
However, in classic MVC(as per Smalltalk80) the model is the set of
objects implementing the core logic and data. The views(multiple)
represent the visual UI which presents the model to the user. The
controller interacts with the user by receiving input events and
converting them into messages to the model or view as appropriate.
[Some designers favour a single controller for each "principal
screen or dialog", others like to have one per use-case. I'm in
the former camp but I've seen both approaches work.)

So, when you press a button on a view the button press is received
by the controller. That then decides if the button action requires
the model to do something(fetch new data, perform calculations etc)
or whether it's merely a view update(reordering a list for example).
If the model is chosen the model will perform the action then
broadcast an update to all of its registered views(*) so that they
can update the display if necessary.

(*)Some MVC implementations make the controller the "view register"
so that the model only has to talk to the controller, which knows
which views are interested in which model objects. One of the areas
of divergence in different MVC implementations. In either case the
idea is that when a view is instantiated it registers itself against
the relevant models. The framework must ensure that when a model
changes all associated views are notified of the change.

> 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, 

Injection attacks are possible on any OS but certainly the web
is much more of a risk.

If you use a cross platform GUI toolkit then packaging should
be pretty straightforward in terms of creating the app files etc.
Creating an installer to put the files where you want them and
so forth is much more tricky and will require OS specific solutions.
To be honest its so long since I deployed a desktop GUI for more
than some personal friends/colleagues that I can't be specific.
I'm pretty sure my experience(late 90s early 00s!) will be out
of date nowadays!

Hopefully, someone else on the list will have experience to share.
Failing that I'd try the user fora for whichever GUI toolkit you
choose.


>> 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.
Tkinter is best for Python friendliness but has least functionality
and is least pretty(even using the new ttk widgets). wxPython looks
much better and is fairly easy to pick up. pyQt/Side is most powerful
but also the biggest learning curve. Qt also had some licensing issues
which I think have been solved(especially if using Side) but i don;t
know the details - I'm not a Qt user.

-- 
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  -  [email protected]
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor