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 as sb # 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
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 as sb # 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