Implement components with CustomTkinter UI-library based on Tkinter #31
Conversation
…al units' and 'Tile x crossbar outgoing links'
…tween 'Tile x functional units' and 'Tile x crossbar outgoing links' - link with commit [5da7c1d]
… 'crossbar outgoing links'
…date with customtkinter style
…ing links based on the number of rows.
TODO fix: kernelNameMenu
…button - change color
launchUI_custom.py
Outdated
There was a problem hiding this comment.
This serves as a standalone GUI or we wanna merge this into existing one?
There was a problem hiding this comment.
Can we just merge them two into one? By default, it launches as the light mode.
There was a problem hiding this comment.
need keep both tkinter and customtkinter version?
There was a problem hiding this comment.
Can the two be merged? We definitely don't want those click function or other functions be duplicated in two files. Can the customtkinter show the original light mode version?
There was a problem hiding this comment.
Ha, til, light mode != classic mode. We do want to keep our classic mode. Can we support 3 modes? Or the customtkinter cannot be co-exist with classic mode? This may require wrap some function with tkinter/customtkinter component as argument/parameter? Can you estimate the engineering effort and the ETA?
There was a problem hiding this comment.
Ah! You were talking about the original UI. Didn't consider for the coexistence of the two modes. They not only have different components, but also different methods and layouts. Can we do this by keeping both files and use parameters to control which mode to start?
There was a problem hiding this comment.
Different methods and layouts that are related to the tkinter/customtkinter, but the CGRA-related actions are always the same. Instead of keeping two files with many duplicated stuff, can we wrap the CGRA-related actions into another .py file? Then you can keep two tkinter-related .py files, serving like coarse-grained wrapper. WDYT?
There was a problem hiding this comment.
I tried several common methods and encountered several problems:
-
Many components are stored through
widgetsdict or accessed throughglobalvariables, and extracting methods requires significant code changes -
Different methods need to be used according to the different libraries, and the code will be more complex. For example, using
configin tkinter andconfigurein customtkinter; UsetestProgress ['value ']in tkinter andtestProgress. set (x)in customtkinter
My question is, do these two modes need to coexist for a long time? If not, we can temporarily tolerate the situation of redundant code. And provide a parameter that allows users to select mode at startup.
There was a problem hiding this comment.
Discussed offline, we will deprecate the classic mode soon or later.
README.md
Outdated
| root@2cd33efd97b3 WORK_REPO# export DISPLAY=192.168.3.38:0.0 # change to your own ipv4 address with 0.0 | ||
| root@2cd33efd97b3 WORK_REPO# source venv/bin/activate | ||
| (venv) root@2cd33efd97b3 WORK_REPO# cd CGRA-Flow/ | ||
| (venv) root@2cd33efd97b3 CGRA-Flow# python launchUI_custom.py |
There was a problem hiding this comment.
Should be mkdir build, then cd, then launch?
There was a problem hiding this comment.
ah, let me update this
|
LGTM, please submit another PR to pop up a dialogue for user to choose between dark and light. |
Added a new file [launchUI_custom.py] with CustomTkinter UI style.
Docker Image: yuqisun/cgra-flow-win