Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial refactor and tests of the text_box class (and derived classes) #202

Open
wants to merge 23 commits into
base: master
Choose a base branch
from

Conversation

zadacka
Copy link
Collaborator

@zadacka zadacka commented Apr 24, 2022

First of a series of proposed commits to simplify, reduce duplication, and add testing to box classes

@zadacka
Copy link
Collaborator Author

zadacka commented Apr 24, 2022

A few things to discuss here, I think.

Proposing to move many of the 'demo' functions to a demo class so that the code files can be pure implementation.
Proposing to settle on Tk as the windowing tool, and strip out the UI intermediate layer - we are pretty settled on Tk...

If this looks good, I've got some (local) commits to do a similar refactor for other box classes.

The imports and usage of the methods should all be staying the same here: due to the way that we set the easygui.__init__.py __all__ we should still be able to import textbox, codebox, and exceptionbox in the same way as before.

@zadacka zadacka force-pushed the feature/refactor_and_test_text_box branch from d03e623 to bd3afcb Compare April 26, 2022 22:33
Removes Python 2.7 compatibility!

(re)add the mouse click behaviour that the refactor had removed
(re) add docstrings for the text_box and derived methods (used by sphinx)

Move Al's test_easygui.py integration tests to the 'tests' folder for consistency

use 1x README.rst instead of (duplicate) .txt and .md README files
tweak conda meta.yaml so that bld.bat and build.sh aren't needed

rename 'test_cases' -> 'demos'
change mose_click_handlers -> MouseClickHandler class
remove test_travis.py since we now have enough *real* tests, and Travis is working nicely
remove duplicate 'parse_hotkey' method
remove 'developer information'
remove unused methods (exception_format, uniquify_list_of_strings, getFileDialogTitle, to_string)
remove unused constant definitions
remove tk 8.0+ warning since it looks like it is now bundled for all 'current' python (v3.7+)

Tests will live in the 'tests' directory
Demos will live in the 'demos' folder

Remove some 'about' files to de-clutter the project.
Aim: have more functional files, and less 'print this' type files everywhere.
In order to do this, move the 'version' information to __init__.py
* use it from the demo boxes *and* from setup.py

Moving things from easygui.boxes.__init__ to easygui.boxes.utils
... in preparation of getting rid of boxes directory entirely.
I want to keep the easygui.__init__ for import control, and move utilites to 'utils'

add more interesting things to the button_box.py default parameter values
@zadacka zadacka force-pushed the feature/refactor_and_test_text_box branch from f398047 to df92528 Compare April 27, 2022 22:38
zadacka added 22 commits April 28, 2022 21:34
main change the preselect changing list -> tuple (because mutable arguments bad)
…-> monospace

mixed feelings about the parameter rename (breaking change!) but otherwise reasonable tidy-up
Without a .protocol() binding for this the root.destroy() can get called twice causing errors
 * expose the message (for future updates, if needed)
 * pull the button setting up to the AbstractBox
requires pulling out msg setting so that we can (for this box) put
  an image at the top and set msg underneath, which is hard to do if the
  msg setting happens in the super().__init__() method
@zadacka
Copy link
Collaborator Author

zadacka commented May 5, 2022

I think that is the main refactor done. Most boxes now inherit from an AbstractBox which allows for a good amount of code re-use.

Things that I'd like to do pre-merge:

  1. go through each type of box and compare before-and-after screenshots (padding changes etc might be nasty)
  2. list the breaking changes (there are a handful of them ... which I think are worthwhile ... but should be clear and explicit(
  3. test out the demos to confirm that I've not broken any sensible use cases
    ... and then merge this to master.

Once the refactor lands, then I think that we can do some tidying up of the docs and finally make some headway on the open issues / bugs / feature requests that have been stacking up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant