TKinter in Python - advanced notions - ok

2023-06-24 Thread Dan Kolis via Python-list
Well, its kind of obvious to make a skeleton, copy it in for some basic 
functionality and modularly ( is that a word ? ) manage each piece.

That ( like your example ) is fine stuff.  

As a side note, I am sure large, large highly generalised programs are pretty 
hard to make.

One thing I do is make each file have a null class like:

# Empty object maker ( M T ) ... get it say it !
class MT():
pass

# Hook point for this module generally
mod = MT()  

Then, a category of symbols ( mostly 'variables ), grow under mod.(Whatever)

# This window gets to exist, and it's exit via op sys clicks
mod.ws = sb.make_Tk_Window( "seqdecodeshow" + str( a_Num ), gi.kCONFIGWIN ) 

This basic notion is that self.(stuff) is not quite multi class enough, yet 
'global' is unpopular as a notation, due to name pollution.


IN A BIG PROGRAM NOT A LITTLE WEENEY One YOU SCRATCH ON A BLACKBOARD SOMEPLACE 
!!

Generally, The way I proceed is to try to avoid CLASSes in each module, but 
only a little. If you need it, you sure do. So early on ( like < 100 lines, if 
you avoided a class, roll back and add it ).

Then, mod.(anything) is 'sort of' like self to class, but its politics is the 
filename that made it alone.

If mod. is not used exactly in a class, roll it back to self. If its way more 
abstractley used, upgrade it to your concept of really global, which generally 
should be somewhat sparely used.

All my TK calls are wrapped in a custom layer, it reduces the line count to 
1/3. like so:

   sb.checkableBoole(cFrmL, 0, 0, gi.us, e_Txt, 
 setting_ClickCb )
sb.textCmdLine( cFrmL, 1, 0, gi.us, 'Apply',
applyThoseSelects )
sb.textCmdLine( cFrmL, 1, 1, gi.us, 'Reset',
resetSelects )
sb.textCmdLine( cFrmL, 1, 2, gi.us, 'Select 
all',   cbSelectAll )

cFrmL is the TK thing that contains these few text lines, with all the bg 
colors, whitepace, fonts, managed inside


This calls 'grid' of course for placement. But all colors, and callbacks for 
changes are entirely in called pieces, which have been tested like 150% crazy. 
sb is 

import screenBuilder1 assb  # Screen maker for TKinter and TKinter ++ 
windows

If you want to use my 'screenbuilder'... talk to me, I suppose. this is a 
biology IDE, the screen part is just a little piece of a huge initiative. 
Obviously, the human being's ideas in there head matter so the TK stuff is 
important, to say the least

Regs,
Daniel B. Kolis

my ref: 24 Jun 2023, https://groups.google.com/g/comp.lang.python/

-- 
https://mail.python.org/mailman/listinfo/python-list


Re: TKinter in Python - advanced notions

2023-06-24 Thread Chris Angelico via Python-list
On Sat, 24 Jun 2023 at 15:57, Thomas Passin via Python-list
 wrote:
> As a general comment (and I have not done anything tricky or complex
> with Tk), MVC or the other approaches in a similar vein, though good,
> can lead you into more complexity than you need, because of the extra
> abstractions involved.  Yes, for sure the GUI should not be doing domain
> or business logic. Yes, it's good to keep database access separate from
> the other parts of your program. But you may not need all the classes
> and layers that you think you might.  It all depends on what you need to
> do, of course.
>
> Another useful design thought is to try to keep as much of the GUI logic
> separate from Tk itself as possible.  Basically, you would write a more
> abstract (and simpler) GUI API, and then write an adapter that knows how
> to make Tk do those things.  One advantage is that this approach makes
> it easier to change to another GUI toolkit later (say PyQt, for
> example).  Another is that it helps you avoid getting sucked into too
> many Tk details that aren't needed for the program concept.

I'd agree, although what I would call this is a GUI *skeleton*. It's
not usually worth trying to isolate that from the actual GUI once you
reach production, but it's a great first step as you're building.

MVC and other such design patterns are excellent tools for learning
and conceptualizing, but I agree, it's not something you have to feel
locked into. When talking with students, I'll ask them to show me
whether something is part of the model, the view, or the controller,
but only to make sure they know what their code is doing. It's not
like I would ask them to make three separate files (usually - maybe
I'd pitch that to a struggling student as a teaching tool, but not in
prod).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: TKinter in Python - advanced notions

2023-06-23 Thread Thomas Passin via Python-list

On 6/23/2023 4:16 AM, Andreas Heckel via Python-list wrote:

Hi,

Apologies for potentially mis-using this thread. But I have been struggling 
recently making exactly this leap from simple GUI examples to a more elaborate 
MVVM concept. Mainly I have been struggling finding nice example python code 
bases, that allow some understanding to the beginner, which I certainly still 
am, but also show enough complexity to see the concept in action.
Any hints / links to github or similar highly welcome. If the list is not the 
appropriate place, I am happy if you email me directly.

Cheers,
Andreas


-Original Message-
From: Python-list
On Behalf Of Diego Souza via Python-list
Sent: Friday, June 23, 2023 4:14 AM
To: aapost
Cc: python-list
Subject: Re: TKinter in Python - advanced notions

Have you considered improving the architecture itself, not your GUI library
skills?

I recommend you look at the Model View ViewModel (MVVM) concept and
implement something similar (this is largely used in the Android framework
nowadays). This would separate your program logic from the rendering and
visualization. It would also make your program more reactive, decoupled,
and easier to maintain. When you mentioned threads I immediately thought of
this because it is much easier to implement parallel jobs and present
results back in the GUI, as everything becomes reactive. This is overkill
for a small project such as the code you showed, but I recommend it for
larger projects.


As a general comment (and I have not done anything tricky or complex 
with Tk), MVC or the other approaches in a similar vein, though good, 
can lead you into more complexity than you need, because of the extra 
abstractions involved.  Yes, for sure the GUI should not be doing domain 
or business logic. Yes, it's good to keep database access separate from 
the other parts of your program. But you may not need all the classes 
and layers that you think you might.  It all depends on what you need to 
do, of course.


Another useful design thought is to try to keep as much of the GUI logic 
separate from Tk itself as possible.  Basically, you would write a more 
abstract (and simpler) GUI API, and then write an adapter that knows how 
to make Tk do those things.  One advantage is that this approach makes 
it easier to change to another GUI toolkit later (say PyQt, for 
example).  Another is that it helps you avoid getting sucked into too 
many Tk details that aren't needed for the program concept.


Here is a simple (or simple-minded :) ) example:

class AbstractApi:
"""An abstract class for standardizing access to a display widget."""
def __init__(self, parent):
self.parent = parent
self.client = None

def registerClient(self, client):
self.client = client

def loadPanel(self, panel_name, html):
"""Load html into display panel."""
pass

def focusPanel(self, panel_name):
"""Select a named display panel."""
pass

def handleSearchText(self):
pass

def writeStatusBar(self, msg):
pass

def handleLinkClicked(self, uri, source):
"""Handle a link clicked in the "source" display panel."""
pass

These (let us say for the purposes of illustration) are the only things 
you need from the GUI.  You can write a Tk-specific version of this, and 
the rest of your program doesn't need to know that Tk is even involved. 
If you want to change to say GTK, this class is the only thing that 
would need to change.


Even if this approach turns out to be too simple for a really 
complicated UI, the closer you can come to realizing it the better.




On Wed, Jun 21, 2023 at 7:20 PM aapost via Python-list <
python-list@python.org> wrote:


On 6/21/23 09:47, Dan Kolis wrote:

I've write a huge biotech program ( an IDE for synthetic biology ), and

am slowly outgrowing TKINTER.


Has anybody out there merged a little bit of TCL direct calls from

Python 3.X to get more freedom then TKINTER for just some Windows ?


I wish it looked better, but its 'ok'. I believe X11 IO is considerably

superior for serious work the HTML.  I mean 'serious' work. with lots of
multi media windows. I am not talking about fb "Oh ! There is a window it
opened inthe corner !"... trivial functionality.


I don't know if it would help, but you can extend/add tcl/tk packages

I don't remember the full instructions right off, but quickly reverse
engineering my old stuff I think you just need to drop them in
/usr/share/tcltk/ or equivalent.

(I needed to do that to replace the terrible looking default file dialog
for unix/linux with fsdialog.)

then running something like the following from your Tk object

self.eval('package require fsdialog')

(reverse engineering the python tkinter source you can likely find other
ways of doing more tcl direct

Re: TKinter in Python - advanced notions - reactive

2023-06-23 Thread Dan Kolis via Python-list


I am not specifically having any problems implementing what I want to make work.

Callbacks etc make it fairly easy to make TKinter react to things without any 
specific fancy plan for it.

Add callbacks for real time changes early in any new notion, after it looks 
right go to the IO part make it react.

Regards, thanks,
Dan
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: TKinter in Python - advanced notions

2023-06-23 Thread Dan Kolis via Python-list
If you have a problem,. ask a super specific question, here. If I can help, I 
will, but TKINTER knowledge is pretty spread around. Many others migth jump in, 
too.

Its works, its slightly quirky, has no licencing hangups.

X11 makes fine fine programs !
Keep hacking,Dan
-- 
https://mail.python.org/mailman/listinfo/python-list


RE: TKinter in Python - advanced notions

2023-06-23 Thread Andreas Heckel via Python-list
Hi,

Apologies for potentially mis-using this thread. But I have been struggling 
recently making exactly this leap from simple GUI examples to a more elaborate 
MVVM concept. Mainly I have been struggling finding nice example python code 
bases, that allow some understanding to the beginner, which I certainly still 
am, but also show enough complexity to see the concept in action.
Any hints / links to github or similar highly welcome. If the list is not the 
appropriate place, I am happy if you email me directly.

Cheers,
Andreas

> -Original Message-
> From: Python-list 
> On Behalf Of Diego Souza via Python-list
> Sent: Friday, June 23, 2023 4:14 AM
> To: aapost 
> Cc: python-list
> Subject: Re: TKinter in Python - advanced notions
> 
> Have you considered improving the architecture itself, not your GUI library
> skills?
> 
> I recommend you look at the Model View ViewModel (MVVM) concept and
> implement something similar (this is largely used in the Android framework
> nowadays). This would separate your program logic from the rendering and
> visualization. It would also make your program more reactive, decoupled,
> and easier to maintain. When you mentioned threads I immediately thought of
> this because it is much easier to implement parallel jobs and present
> results back in the GUI, as everything becomes reactive. This is overkill
> for a small project such as the code you showed, but I recommend it for
> larger projects.
> 
> 
> 
> 
> 
> On Wed, Jun 21, 2023 at 7:20 PM aapost via Python-list <
> python-list@python.org> wrote:
> 
> > On 6/21/23 09:47, Dan Kolis wrote:
> > > I've write a huge biotech program ( an IDE for synthetic biology ), and
> > am slowly outgrowing TKINTER.
> > >
> > > Has anybody out there merged a little bit of TCL direct calls from
> > Python 3.X to get more freedom then TKINTER for just some Windows ?
> >
> > > I wish it looked better, but its 'ok'. I believe X11 IO is considerably
> > superior for serious work the HTML.  I mean 'serious' work. with lots of
> > multi media windows. I am not talking about fb "Oh ! There is a window it
> > opened inthe corner !"... trivial functionality.
> >
> >
> > I don't know if it would help, but you can extend/add tcl/tk packages
> >
> > I don't remember the full instructions right off, but quickly reverse
> > engineering my old stuff I think you just need to drop them in
> > /usr/share/tcltk/ or equivalent.
> >
> > (I needed to do that to replace the terrible looking default file dialog
> > for unix/linux with fsdialog.)
> >
> > then running something like the following from your Tk object
> >
> > self.eval('package require fsdialog')
> >
> > (reverse engineering the python tkinter source you can likely find other
> > ways of doing more tcl direct stuff)
> >
> > I have not researched if there are some better, more featured
> > (non-buggy) Text widgets implemented in tcl that can be dropped in, (I
> > know several of the tcl drop in widgets I tried were lacking in
> > refinement).
> >
> >  From what I can tell, once upon a time there were better, more
> > interesting projects and tutorials on extending tkinter, such as WCK
> > (tkinter3000), but the only remnants of those remain publicly available
> > are outdated unmaintained archives.
> >
> > You might also consider looking at the Grail browser source for research
> > purposes, as it does some interesting things with some of the widgets,
> > (parsing html and such), even though it is 20 years old now (and written
> > in python 1).
> > The update attempts from 10+ years ago have disappeared. (it's license
> > is considered questionable from what I understand, so not sure if that
> > is an aspect of it, the other being one of it's main features, python
> > applets, is unsafe and was not easily fixable)
> >
> > You might already be beyond some of these things though.
> >
> > I know what you mean as far is feeling like the little bit extra you
> > need pushes beyond what tkinter can do / makes you feel like you have
> > outgrown the module.
> >
> > (I had to take a break from one of my projects and send it to
> > development hell until my UI knowledge/skills improve after I found
> > myself considering using xml schema appinfo annotations to store json
> > formatted widget specific information, lol.)
> >
> > I have felt that sense of lack with most of the UI modules I have tried
> > though.
> >
> > I don't know of a clear better python-only solution though that fits my
> > personal needs.
>

Re: TKinter in Python - advanced notions

2023-06-22 Thread Diego Souza via Python-list
Have you considered improving the architecture itself, not your GUI library
skills?

I recommend you look at the Model View ViewModel (MVVM) concept and
implement something similar (this is largely used in the Android framework
nowadays). This would separate your program logic from the rendering and
visualization. It would also make your program more reactive, decoupled,
and easier to maintain. When you mentioned threads I immediately thought of
this because it is much easier to implement parallel jobs and present
results back in the GUI, as everything becomes reactive. This is overkill
for a small project such as the code you showed, but I recommend it for
larger projects.





On Wed, Jun 21, 2023 at 7:20 PM aapost via Python-list <
python-list@python.org> wrote:

> On 6/21/23 09:47, Dan Kolis wrote:
> > I've write a huge biotech program ( an IDE for synthetic biology ), and
> am slowly outgrowing TKINTER.
> >
> > Has anybody out there merged a little bit of TCL direct calls from
> Python 3.X to get more freedom then TKINTER for just some Windows ?
>
> > I wish it looked better, but its 'ok'. I believe X11 IO is considerably
> superior for serious work the HTML.  I mean 'serious' work. with lots of
> multi media windows. I am not talking about fb "Oh ! There is a window it
> opened inthe corner !"... trivial functionality.
>
>
> I don't know if it would help, but you can extend/add tcl/tk packages
>
> I don't remember the full instructions right off, but quickly reverse
> engineering my old stuff I think you just need to drop them in
> /usr/share/tcltk/ or equivalent.
>
> (I needed to do that to replace the terrible looking default file dialog
> for unix/linux with fsdialog.)
>
> then running something like the following from your Tk object
>
> self.eval('package require fsdialog')
>
> (reverse engineering the python tkinter source you can likely find other
> ways of doing more tcl direct stuff)
>
> I have not researched if there are some better, more featured
> (non-buggy) Text widgets implemented in tcl that can be dropped in, (I
> know several of the tcl drop in widgets I tried were lacking in
> refinement).
>
>  From what I can tell, once upon a time there were better, more
> interesting projects and tutorials on extending tkinter, such as WCK
> (tkinter3000), but the only remnants of those remain publicly available
> are outdated unmaintained archives.
>
> You might also consider looking at the Grail browser source for research
> purposes, as it does some interesting things with some of the widgets,
> (parsing html and such), even though it is 20 years old now (and written
> in python 1).
> The update attempts from 10+ years ago have disappeared. (it's license
> is considered questionable from what I understand, so not sure if that
> is an aspect of it, the other being one of it's main features, python
> applets, is unsafe and was not easily fixable)
>
> You might already be beyond some of these things though.
>
> I know what you mean as far is feeling like the little bit extra you
> need pushes beyond what tkinter can do / makes you feel like you have
> outgrown the module.
>
> (I had to take a break from one of my projects and send it to
> development hell until my UI knowledge/skills improve after I found
> myself considering using xml schema appinfo annotations to store json
> formatted widget specific information, lol.)
>
> I have felt that sense of lack with most of the UI modules I have tried
> though.
>
> I don't know of a clear better python-only solution though that fits my
> personal needs.
>
> So I have to lean toward improving my tcl / C in hopes that it might
> help steer me toward that extra (which seems to be in the spirit of what
> tcl/tk's intent is to begin with). That will be a while for me though if
> I get there.
>
>
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
Diego Souza
Wespa Intelligent Systems
Rio de Janeiro - Brasil
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: TKinter in Python - advanced notions

2023-06-21 Thread aapost via Python-list

On 6/21/23 09:47, Dan Kolis wrote:

I've write a huge biotech program ( an IDE for synthetic biology ), and am 
slowly outgrowing TKINTER.

Has anybody out there merged a little bit of TCL direct calls from Python 3.X 
to get more freedom then TKINTER for just some Windows ?



I wish it looked better, but its 'ok'. I believe X11 IO is considerably superior for 
serious work the HTML.  I mean 'serious' work. with lots of multi media windows. I am not 
talking about fb "Oh ! There is a window it opened inthe corner !"... trivial 
functionality.



I don't know if it would help, but you can extend/add tcl/tk packages

I don't remember the full instructions right off, but quickly reverse 
engineering my old stuff I think you just need to drop them in 
/usr/share/tcltk/ or equivalent.


(I needed to do that to replace the terrible looking default file dialog 
for unix/linux with fsdialog.)


then running something like the following from your Tk object

self.eval('package require fsdialog')

(reverse engineering the python tkinter source you can likely find other 
ways of doing more tcl direct stuff)


I have not researched if there are some better, more featured 
(non-buggy) Text widgets implemented in tcl that can be dropped in, (I 
know several of the tcl drop in widgets I tried were lacking in refinement).


From what I can tell, once upon a time there were better, more 
interesting projects and tutorials on extending tkinter, such as WCK 
(tkinter3000), but the only remnants of those remain publicly available 
are outdated unmaintained archives.


You might also consider looking at the Grail browser source for research 
purposes, as it does some interesting things with some of the widgets, 
(parsing html and such), even though it is 20 years old now (and written 
in python 1).
The update attempts from 10+ years ago have disappeared. (it's license 
is considered questionable from what I understand, so not sure if that 
is an aspect of it, the other being one of it's main features, python 
applets, is unsafe and was not easily fixable)


You might already be beyond some of these things though.

I know what you mean as far is feeling like the little bit extra you 
need pushes beyond what tkinter can do / makes you feel like you have 
outgrown the module.


(I had to take a break from one of my projects and send it to 
development hell until my UI knowledge/skills improve after I found 
myself considering using xml schema appinfo annotations to store json 
formatted widget specific information, lol.)


I have felt that sense of lack with most of the UI modules I have tried 
though.


I don't know of a clear better python-only solution though that fits my 
personal needs.


So I have to lean toward improving my tcl / C in hopes that it might 
help steer me toward that extra (which seems to be in the spirit of what 
tcl/tk's intent is to begin with). That will be a while for me though if 
I get there.





--
https://mail.python.org/mailman/listinfo/python-list


TKinter in Python - advanced notions

2023-06-21 Thread Dan Kolis via Python-list
Hi,

I've write a huge biotech program ( an IDE for synthetic biology ), and am 
slowly outgrowing TKINTER.

Has anybody out there merged a little bit of TCL direct calls from Python 3.X 
to get more freedom then TKINTER for just some Windows ?

How about bold stories of successes ( yours, not mine ) on porting to stupid MS 
Windows from linux ?

Adding threading makes TKinter hard ( but not impossible ) to manage. Also, a 
little bit here and there obviously exceeds TKINTERs goals.

I wish it looked better, but its 'ok'. I believe X11 IO is considerably 
superior for serious work the HTML.  I mean 'serious' work. with lots of multi 
media windows. I am not talking about fb "Oh ! There is a window it opened 
inthe corner !"... trivial functionality.

Must be a uber expert out there. Is it you ?

As attached. and little code. Coloring text makes me realise; some of this is 
pretty indirect, though this is quite well thought out, like all of TKINTER.

Regards,
Daniel B. Kolis


"""
An important worked example of text color and other look dynamic changes.
This is the righ way to do this for fast changes ! 
20 Jun 2023 22:11
"""

import tkinter as tk
from tkinter.font import Font

class Pad(  tk.Frame  ):

def __init__( self, parent, *args, **kwargs ):
tk.Frame.__init__(  self, parent, *args, **kwargs  )

self.toolbar = tk.Frame( self, bg="#eee" )
self.toolbar.pack( side="top", fill="x" )

self.bold_btn = tk.Button( self.toolbar, text="CHANGE highlighted", 
command=self.make_Change_Highlighted )
self.bold_btn.pack( side="left" )

self.bold_btn = tk.Button( self.toolbar, text="CHANGE H.B.", 
command=self.make_Change_Hb )
self.bold_btn.pack( side="left" )

self.bold_btn = tk.Button( self.toolbar, text="Delete a char", 
command=self.make_Change_Delete )
self.bold_btn.pack( side="left" )

self.clear_btn = tk.Button( self.toolbar, text="Clear", 
command=self.clear_Some )
self.clear_btn.pack( side="left" )

# Applies this font
self.bold_font = Font( family="Helvetica", size=14, weight="bold" )

self.da_Text = tk.Text( self )
self.da_Text.insert( "end", "Selectable parts of text is fun.\nSo is a 
happy birthday, right ?"  )
self.da_Text.focus(  )
self.da_Text.pack( fill="both", expand=True )

# configuring a tag called dingo-something
self.da_Text.tag_configure( "reddingo",  font=self.bold_font, 
foreground = "Red"  )
self.da_Text.tag_configure( "bluedingo", font=self.bold_font, 
background = "Yellow", foreground = "Blue"  )


# Button CB
def make_Change_Delete( self ):

self.da_Text.delete( '1.0', '1.1' )


# Button CB
def make_Change_Highlighted( self ):

# tk.TclError exception is raised if not text is selected
try:
   self.da_Text.tag_add( "reddingo", "sel.first", "sel.last" )

except tk.TclError:
   tt = 569


# Button CB
def make_Change_Hb( self ):

try:
lin_Idx = 2; col_Idx = 8
self.da_Text.tag_add( "bluedingo", f"{ lin_Idx }.{ col_Idx }", 
   f"{ lin_Idx }.{ col_Idx + len(  
'happy birthday'  ) }"  )
except:
gg = 457

# Button CB
def clear_Some( self ):
   self.da_Text.tag_remove( "reddingo",  "1.0", 'end' )
   self.da_Text.tag_remove( "bluedingo",  "1.0", 'end' )


# Main body really
def is_Main():
root = tk.Tk()
Pad( root ).pack( expand=1, fill="both" )
root.mainloop()

# Go
if __name__ == "__main__":
is_Main()


Document end

my ref: 21 Jun 2023, https://groups.google.com/g/comp.lang.python, Daniel B. 
Kolis, nafl




-- 
https://mail.python.org/mailman/listinfo/python-list