-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathchangelog.txt
155 lines (116 loc) · 6.99 KB
/
changelog.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
$$$$$$$$$$$$$$$$$$$$$$ CURSEDB UI CODE CHANGELOG $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
$$$$$$$$$$$$$$$$$$$$$ SCROLL DOWN FOR OLD UPDATES $$$$$$$$$$$$$$$$$$$$$$$$$$$$$
06AUG15------------------------------------------------------------------------
1. User input: can enter up to 64 characters (up from 18) since a mysql
database name can be that long. The input strip scrolls accordingly.
2. Deactivated the account page :(
3. Added direct link to user main page
4. Added "nested" item scrolling; i.e. you can scroll through a second list
from an item in a first list- see the user main page for an example.
Tab/back tab are used as the secondary scroll buttons. You can only perform
secondary scrolling when you're on the item that has the nested list.
04AUG15, UPDATE 2--------------------------------------------------------------
1. Started on "user main" screen. Press "u" to jump to that page, since
normally the only way to get there is to actually log in and we haven't
implemented that yet.
04AUG15, UPDATE 1 -------------------------------------------------------------
General Info:
UI_documentation updated!
1. "User Strips": The green strips at the top of every screen have a use now.
They're called "user strips" and will have the user's name and maybe one
or two other things up there. Every time the screen loads, that information
is updated. I wanted to have something like the current time shown up there
but that will be down the road. Right now I'm using it to show the user's
log in name, after they've "logged in" via the log in screen. The user
name is drawn from global_storage and not given to the user strip directly
on the login page, demonstrating that the global_storage is working.
2. Account Screen and Login screen are completely finished except for
code that redirects after account/login validation.
3. Probably a few more things I missed here and there...
03AUG15, UPDATE 1.1------------------------------------------------------------
Important Info:
Account Creation:
Some of the account creation code on my side is complete. So far:
The user enters their name and password, the input is validated for length
and character type requirements and if they pass the strings are stored in:
curse_container.
screens["account_screen"].
panels["acct_scr_mid_panel"].
panel_storage["account_name"]
and
curse_container.
screens["account_screen"].
panels["acct_scr_mid_panel"].
panel_storage["account_pw"]
The user then hits the "submit" button to execute code that will check
the server if a user account of that name exists already. If the name is
gravy, then the user gets forwarded to the login screen for logging in.
<needs to be written by someone> <-------------------------------------------
The code to check if an account name exists in a database.
I will pass:
a string that has the username
a string that has the password
<needs to be written by me>:
The login page forwarding code if the account is OK. This should be easy
to do since there is already a function that does this
(curseDB.py.changeScreen()) but I'm working on the login code first.
General Code info:
1. CurseScreens, CursePanels, and CurseItems each have their own storage
dictionaries now for future purposes. They are CurseScreen.screen_storage,
CursePanel.panel_storage, and CurseItem.item_storage.
These storage dicts can be used as an interface between the core UI code
and periphial database code. For example, storing the user account
name/password in the login screen's screen_storage dictionary makes it
easily accessible for other code.
2. Speaking of storage, there is also a global level of storage called
"global_storage" that the main curse components (CurseScreens, CursePanels,
and CurseItems) have references to.
3. Added code for giving curse components instance specific methods. This code
is in the init_funcs() method of curseInit.py after init_act_msg_maps().
Before, a curse component (specifically curseItems) could have
individualized behavior by calling component specific "messages" when
select() was called on it. This message contained instructions for itself
or another component to execute a certain function, but did not actually
allow specific functions to be tailored to that item.
Now, if an item needs to call a specialized function, instead of putting
it in the class.py file, it is put in the in the init_funcs() method
and assigned to that component there. Note that it is still necessary to
use the message system to call this specialized function when its parent
calls select() on it- just send the message using the "self" recv_layer
This will help solve the issue of either having to cram all the functions
needed for the entire program into a class file, even though most of the
instantiated class objects will not need those functions. Only code that
is needed by several instances of that object will get put in the class
.py file
4. Added load() functions to CurseScreens, CursePanels, CurseItems, and
CurseTextboxes. These functions are only called when changing screens,
right before the new screen is loaded and after the old screen is unloaded.
Code for resetting default states can be put here.
4a. TODO: add unload() functionality if needed
5. Decoupled error message output and user string input. The new error message
output method for string input is CurseItem.showErrorMsg(). Character
validation should be working for name/password input...
6. Key-Action-Message system and overview of user input processing:
Single key user input is detected at the main loop in curseDB.py This input
character is passed to the active screen.
The active screen uses its key-action map (CurseScreen.key_action_map)
to convert this input character to an "action string". The purpose of the
"action string" is to make further input processing based on what key was
entered more readable. Now, instead of have an else/if conditional checking
"ord("a")" it checks "prev", which gives someone a better idea of what that
key is intended for.
Action strings are used as keys in "action-message" maps (see next item) to
generate a "message" if the action string is in the CurseScreen. If the
screen does not have that action in its action-message map, it gives
the action string to the active panel. The panel checks its action map for
anything and if there is no entry for that action, the input is ignored.
*** NOTE **** I'll fill in the documentation for the messages themselves
later.
7. Added "action-message" maps. CurseScreens and CursePanels now have
"action-message" map attributes: act_msg_maps. Action-message maps allow
CurseScreens and CursePanels to have customized behavior in response to
certain "action" input. For instance, when the "back" action is input, one
screen can go back to the previous screen, and another screen can have a
different response (currently there is a special key for moving back a
screen that all screens share). The above is true for panels as well,
where this ability may be more useful.