List lswitcher-dev@2rosenthals.com Arkiverade meddelande #182

Från:	"Alfredo Fernández Díaz" <lswitcher-dev@2rosenthals.com>	Meddelandehuvud Oavkodat meddelande
Ämne:	Saving settings and undo stuff (Was: lSwitcher-2-93-0-RC_4.wpi)
Datum:	Wed, 16 Dec 2020 01:53:58 +0100
Till:	lSwitcher Developers Mailing List <lswitcher-dev@2rosenthals.com>

Hi yet again, On 20/12/13 21:20, Gregg Young wrote: Hi Attached is lSwitcher 2.93 RC 4. It hopefully fixes all of the font, menu and layout issues identified by Alfred. Still to do/decide on. 1. ï¿½Adding undo to the settings? Let me be clear on this: I don't mind what mechanism is used in the end to save settings, as long as it is functional, reasonably intuitive (pretty much boils down to using the right labels for controls), and is matched by the documentation -- so you know what to expect by simply reading the manual, and/or or fiddling around. As I said, saving everything on close makes "Save" buttons misleading (what does it save exactly, then, that is not saved otherwise? why have it if everything is saved? etc.), and leaves the UI self-inconsistent. A. make the hide button work as described in the help (ie only save non-settings stuff to the ini on close? This is how it worked until you changed it without notice to saving everything. I only noticed when stuff that I was 'just trying out' started to stick between restarts -- I never tried to have non-settings stuff saved. I was used to this, and it shouldn't be hard to bring back. B. Implement a full undo? This is from an earlier email: The hardest to implement, but we have a ton of documented examples to look at, and we got no other programs inserting their own tabs or other secondary dialogs, so fully controllable in theory. a. What do we intend for "undo" to actually do? Should it undo all the changes on every page or just the current page? Should it close the dialog or leave it open for additional changes? I find it most intuitive what the WPS does (except on tabs inserted and thus controlled by Peer, DragText, DSS, etc...). It also follows the CUA guidelines (I can look up the exact passages later on): -All changes are applied immediately, but are only saved on closing the notebook. The idea above is, you keep trying out stuff as you play with controls -- it doesn't get any more direct. Once you are satisfied, just close (and thus save the settings) and move on. Before closing, you get rid of any and all changes made in the last session (Undo), or simply restore system defaults. -Undo sets all controls *on the current tab* to the values set when the notebook was opened. -Default sets all controls *on the current tab* to the "factory" values. -Neither button closes the notebook, to avoid saving involuntarily. The idea above is to let you keep whatever you have done in other tabs since you opened the notebook, and focus on what you are doing with the currently selected one. You can always open any other tab and press Undo or Default there before closing to save all. The only problem with it all is, sometimes the notebook just gets in the way. In that case, a hide/minimize button must also be present, so you can get rid of the notebook without saving, and get it back and close+save when ready. b. How do we handle exclude lists do I undo the last entry added/removed or do I need to determine all the entries made in this session for removal or adding back perhaps some of each kind. Lists, as atomic controls holding a value (an array), should have a defined default (empty, or with a few entries we like, like f.e. "*XCenter*"), and that's it. Pressing Default, a list should be set to its own default as defined. Unless you close to save them, pressing Undo should restore whatever entries were listed before/when the notebook was opened, so you're safe. c. Significant changes of this kind add complexity and as such more opportunity for defects. Is having what will probably be a little used option worth this? Depends on your take. I would have tried to make it all work like the WPS from the get go, but I wasn't there back then. I can live with the other ways to save settings, so I would probably not change it over if I were doing the coding now. d. This must account for the differences between the taskbar and the widget. (2 sets of code to get out of sync) As long as you keep two alternative taskbars you will have two sets of code to get out of sync, whether dealing with settings or whatever else. C. Remove the hide button and change Save to Ok. This is the quickest and safest, even if a bit ugly or odd with only one functional button at the bottom. Keep Help down there :) However, in this case you probably mean remove the Save button (you are saving everything on the go / on close anyway), and (maybe) change "Hide" to "Close" (little to no difference if always saving). D. Fix the help to match the choice made if needed. The only way to not need this is to go A like before. 2. Add "close" to xCenter context menu for the Taskbar Sorry I started a more in-depth discussion in my other email re: 2.93 rc4. 3. Determine the effect of the codepage and font changes for Russian etc when lSwitcher is run on a Russian etc system. Will be checking tomorrow, now that I am at it for a while. Thank you, Alfred.

Prenumerera: Sändning, Uppsamling, Index.
Stoppa prenumeration
Meddelande till ListMaster