Replies: 30 comments 33 replies
-
|
Patrick, Wow, I can't tell you how good it feels to see a Preferences dialog taking shape! What you're proposing definitely works for me. I do have some thoughts on how other users might react, which is where the following comments are coming from.
~Les |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Installing a single copy of the code allows us to keep a single copy up to date. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe |
Beta Was this translation helpful? Give feedback.
-
|
If you want to work against the current config options, I can understand that. I just want to keep in mind what we have been discussing and don't seem like they will be too far off. I've had a few things that have taken priority, but I expect to be back focusing on this pretty soon (after the beginning of the year), so things like multiple configurations (maybe saved by 'Station' (by default)) and the RPi-GPIO interface are high on my list. |
Beta Was this translation helpful? Give feedback.
-
|
Concerning the requirement to allow multiple configuration profiles, I can imagine some kind of user interface that would allow the user to specify a profile name where the configuration is saved to or retrieved from. Maybe instead of a 'Configure System Defaults' checkbox it could be a dropdown menu with a list of user-specified profile names. But it might be simpler to just have a command line option, like |
Beta Was this translation helpful? Give feedback.
-
|
I think that a MKOB command line option to specify the profile to be used is exactly what is needed, I'm not sure we need the ability to save to a specific profile (though 'Save Profile As...' in the 'File' menu probably makes sense), but I do think we need an option to select the 'default' profile and to 'Open' (switch to) a profile while running. I relate this to me using Visual Studio Code. I have a number of workspaces for different projects. I can run multiple copies of VSC at once, each with a different workspace. I can start VSC with a specific workspace (via a shortcut that includes a command line option, or by alt-clicking on the workspace file and selecting 'Open with - VSC'). If I make and save changes while running they are saved to the current workspace. There are a few configuration settings that are global (they are identified within the configuration dialogs). |
Beta Was this translation helpful? Give feedback.
-
|
These are (mostly) separate from the actual functionality of the application. Unfortunately, they are things that current users of other applications have come to expect. Having multiple 'profiles' handles the requirements of the museum/other display use-cases, as well as development/test scenarios that I deal with, so I think it is quite useful. Again, I would rather work on this rather than support for people installing multiple copies of the application. |
Beta Was this translation helpful? Give feedback.
-
|
I like the drop-down menu idea. I am forever selecting different configurations and while it's not too bad in v2.5, in the version 4 stuff with the config file, it's a bit of a pain. |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, Thanks for the quick feedback! Let me see if I can respond more or less in order (including Chris' points on the KEY_SOUNDER / LOOP / KEYER interpretation thread, which seem to overlap with the config option discussion here):
There's also nothing that says we can't configure defaults for things in the main dialog, and let the main dialog take its course once MorseKOB is off and running? It's not necessarily a hard EITHER/OR between the main dialog and the prefs/config if that meaning is clear?
That would let multiple users run through different starting directories, or different user accounts altogether. Of course we could have a CLI option at startup to specify the “local” config file to override the system defaults with - that would make it especially trivial to run in multiple different configurations from a single account in a single directory. I agree forcing installation of multiple copies of MKOB should be overkill and undesirable from the update headaches it could introduce. I’d prefer to avoid explicitly introducing these multiple configurations into the user’s view. Yes, we could present a model where there’d be different “Profiles” and you could start MKOB with a given “Profile” and we could have a pop-up in the config dialog that controls the “Profile” being configured (including “System Default”, I suppose) but it’d be a lot simpler to have every running instance know only about the system defaults and the current instance’s defaults and configure only those two. That would also avoid “dueling profile updates” etc. from different instances trying to update the other instance’s settings etc. Instead, if there are 4 stations in a museum, each will simply have its own config file and can use it just as anyone would use MKOB? Taking into account the comments so far, how about this as an alternative layout?
|
Beta Was this translation helpful? Give feedback.
-
Actually, the current behavior (in MKOB 4.0 as well as 2.5) is to come up with the last wire that was used, not a 'default wire'. This is just a point of clarification, not necessarily my personal preference one way of the other.
Leaving an 'advanced' option for later seems like a good compromise. For now, it's important to have some kind of options dialog and let the details evolve as we get more experience and feedback.
I change my station ID quite often -- even in the middle of a session. For example, if I want show that I'm busy on the phone, I can append a short note to the end of my ID.
I'm kind of with Chris on this one. Maybe I could get used to it, but right now I'm uncomfortable having the same option on the main screen and the options dialog.
I'm not sure what a 'local' config is. Is it a set of options that's local to MKOB and doesn't affect other applications, like Clock or News or whatever? What exactly is a 'system default'? I get very confused whenever I think about this. |
Beta Was this translation helpful? Give feedback.
-
|
I prefer last wire used as the "default" wire. Yes, only one place to set a particular option - be it front panel or sub-menu depending on the option, but not both. |
Beta Was this translation helpful? Give feedback.
-
|
As I mentioned, I don't think of the things in the main GUI (the station name, the wire to connect to, and the speed) as something I want saved when I make changes to them (in the main GUI). I consider them as just what I'm currently using/doing. I would like these same configuration options in the 'Configuration/Profile' settings dialog for what is used when I start the application. However, I seem to be in the minority, so I can deal with it if those three values are saved for the next time I start the app. |
Beta Was this translation helpful? Give feedback.
-
|
@AESilky You may be in the minority, but I think I'm with you on this one. Despite my initial reaction, I'm starting to think changes made on the main KOB screen should be temporary and not saved for the next time the program is run. I realize this conflicts with the way MorseKOB 2.5 works, but with the option of having saved profiles I think it might make sense. In any case, I'd sure like to give it a try. |
Beta Was this translation helpful? Give feedback.
-
|
I would really like to give it a try (values in the main GUI not being persisted). In the configuration/profile you should be able to specify what you want the start up to be, but while running, if I change my station ID to indicate that I'm stepping away for 5 minutes to answer the door, or I change my speed to 30 (from 22) in order to follow a particularly fast sender, I don't want those to be saved as my new startup profile. |
Beta Was this translation helpful? Give feedback.
-
|
On Dec 28, 2020, at 12:53 PM, Les Kerr ***@***.***> wrote:
As for the "wire" option - I believe that's actually the "DEFAULT WIRE", the wire the UI should come up connected to. For some people that'd be wire 11, for others maybe one of the headline wires, or whatever. The current behavior is to start out on the configured default wire. Instead of that we could equally preserve the wire in the config file anytime it's changed so the GUI always comes up on the same wire you were on last time, in which case a separate config option would be superfluous. Thoughts?
Actually, the current behavior (in MKOB 4.0 as well as 2.5) is to come up with the last wire that was used, not a 'default wire'. This is just a point of clarification, not necessarily my personal preference one way of the other.
I’m fine with that model - so some configurations simply persist from one session to the next and are do not revert to some pre-chosen “initial value” at startup. In that case I agree there’s no need to have them in the config dialog, even as an “initial value” or “initial default” because the moment you change them in a session the configured default is irrelevant.
If session-to-session preservation (or “update configuration on change”) is the desired behavior, I’ll drop the “wire” from the config dialog.
I suppose all config options should be present in the GUI (so there’s never a need to resort to CLI use) but we could hide some of the more unusual ones behind an "Advanced" sub-option? For now, I'm inclined to do everything in a single panel first but I'm not opposed to leaving behind an issue to move some options out of sight in the future.
Leaving an 'advanced' option for later seems like a good compromise. For now, it's important to have some kind of options dialog and let the details evolve as we get more experience and feedback.
I'd have thought "Station ID" was pretty static - do people change it during use? In any case, we can label the current config option "Default station ID" or "Initial station ID" in that case, if "Station ID" is potentially confusing? Or, again, we can have the program come up with the last used station ID by default (by updating the config file anytime the station ID is changed)
I change my station ID quite often -- even in the middle of a session. For example, if I want show that I'm busy on the phone, I can append a short note to the end of my ID.
Gotcha - that makes sense. In this case, though, might you not want your station ID at startup to start with some fixed value, instead of “… (bathroom break)” as you might have had it when you quit last time? Here, it seems to me, an “Initial Station ID” might make sense?
There's also nothing that says we can't configure defaults for things in the main dialog, and let the main dialog take its course once MorseKOB is off and running? It's not necessarily a hard EITHER/OR between the main dialog and the prefs/config if that meaning is clear?
I'm kind of with Chris on this one. Maybe I could get used to it, but right now I'm uncomfortable having the same option on the main screen and the options dialog.
It should never be the same but we should be clear about the difference. Whatever’s in the main dialog is “live” that moment. Whatever’s in the config dialog is at most a “default” or “initial” setting of something, and changing it also doesn’t change the current setting in the main window, only how the main window would appear at the next startup.
As for multiple configurations: any reason not to look for the "local" config in the default directory, or in some succession of directories relative to the current user (e.g. initialize defaults to system-wide settings, then override with any config into in current directory or "Home" directory [whereever there is a config file])? And update only the local user config unless "Set System Default" is explicitly checked?
I'm not sure what a 'local' config is. Is it a set of options that's local to MKOB and doesn't affect other applications, like Clock or News or whatever? What exactly is a 'system default'? I get very confused whenever I think about this
By “local” config I mean the opposite of “system config”. It’s “local” from a file system perspective: the model in my mind is there are two sets of configurations: a “system config” that applies to all instances (perhaps stored with the application, or at least somewhere accessible by all running instances) and a “local config” that’s 100% under the control of the current user. That “local config” could be stored in a local directory or in the user’s home directory but it should be somewhere writable by the current user.
Ed’s already built in the notion of a "system configuration" stored globally and a "local configuration” (that overrides it). I believe the current code looks for the local config in the “current directory” the system maintains, and then the user’s home directory. I propose we add a “local configuration” option that explicitly directs the system where that local configuration is stored. That way, a museum could have a single account with a single copy of MKOB installed and start 4 instances, each with a different “Local config=“ option so each has its own configuration that can be changed independently.
I’ll send an updated drawing with the “Wire” option removed and some restructuring of the dialog to hopefully make it more clear.
One other consideration: we use “KEYER” to indicate separate dot/dash (on DSR/CTS) instead of a single “KEY” input (on DTR). I think that’s a bit of a misnomer: I thought a “keyer" was a device that independently generated dot/dash combinations (in sound). I thought “paddle” captured the idea of separate dot/dash inputs (vs. “key”) better and I’ve used that in the latest drawing. Let me know if that terminology is confusing in a telegraph context.
I’m also trying to use a common verb to make “Use computer sound” and “Use local sounder” parallel. I’m not thrilled with “Use” (or “Output on”) - I’m open to suggestions!
73, N6PWD
-Patrick.
… You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#213 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYKYKCHOHTHITTST7YALSXDV37ANCNFSM4VLNQFUQ>.
|
Beta Was this translation helpful? Give feedback.
-
|
Hi All, Well, as I see it the only need for a "default" config is with the initial installation of the code. 2.5 does this by having key/sounder enabled ("Normal") , no external sounder and computer sound turned on. I forget whether it comes up with a predefined WPM setting but that might be a good idea. Some initial station ID that says something just identifying the program (MKOB 4.0.XXX) other than just blanks which might prompt the user the change it. Once the program is run, that "instance" of it follows any changes to its configuration that follow and becomes the default for that configuration. I also change my station ID, sometimes during sessions but also if I'm doing a public display where I tend to try and find an office call related to where that display is set up. I use different station ID's at home and at my summer place, using real office calls for long gone nearby stations. If a single code copy is the approach we choose instead of multiple copies each in their own directory with their own local configuration file (which I still think is simpler and it allows for testing multiple versions on the same machine at the same time whereas if the code is always installed only once with multiple "instance" configuration files, how do we play around with different versions?) there still needs to a way for a user who is not computer savvy to select which "instance" or "instances" to run all at the same time. I've found having separate icons on the window each with their own name (I use wire1, wire2, ...) such that all that is necessary to do to start that instance is to click on it to be the most obvious way to do it. Maybe I'm missing something but both with key/sounder and loop configurations I also sometimes have computer sound enabled. This has become necessary when demonstrating 2.5 during Zoom meetings as for whatever reason the attendees, although they can hear me speaking, don't hear my real sounder clicking. With 2.5 I have generally found that there is no need for a separate robust museum version as someone suggested. The only thing I think I responded to a previous post was that a sticky configuration option on the configuration menu should be to automatically connect to the wire in the Wire window on the main screen if one is specified. Note, that said, I frequently just use MorseKOB in local mode, not connected to the wire number specified in the wire window. There's no need to be connected when I'm just showing someone how to send or sending their name so they can see it on the screen. Configuration options should be of two forms, sticky (wire number, station ID, WPM, mode, port, sound and maybe a few others) and ones that go back to a default which at least for those about which I am thinking should just be disabled (such as show packets in 2.5) in other words "diagnostic" functions. I agree that maybe automatically keeping a log during a session is a good idea but it should be deleted at the end of the session if the user does not want to see it and this should take a positive action on the part of the user to save it. I would not want to see a pop up menu when one exits the program asking whether to save it as that would confuse most folks who aren't interested or wouldn't know how to understand the file anyway. As to station ID if I forget to remove "bathroom break", I'm sure I would fix it the next time I turned the program on so again no need for any default except with the initial installation of the code. 73, Chris |
Beta Was this translation helpful? Give feedback.
-
|
Here's the latest drawing, with related options grouped together in sections:
Note that I've displayed the host address and port number, albeit disabled. Should we make that editable? Or ignore it altogether? I believe the values are currently hard-coded but I believe there've been requests to let users change it. Perhaps that's something we should drop for now altogether and save it for when a completely separate "Advanced Options" dialog is added? |
Beta Was this translation helpful? Give feedback.
-
|
Host name and port number are definitely options that we'll want to have sooner or later. No harm including them now as grayed out, inactive options until they're implemented. |
Beta Was this translation helpful? Give feedback.
-
|
What does the Configure System Defaults checkbox do? |
Beta Was this translation helpful? Give feedback.
-
|
Rather than 'Serial Connection' I suggest 'Instrument Connection' or 'Equipment Connection'. |
Beta Was this translation helpful? Give feedback.
-
Or 'Interface Type'. |
Beta Was this translation helpful? Give feedback.
-
|
On Dec 28, 2020, at 2:17 PM, J. Chris Hausler ***@***.***> wrote:
Hi All,
Well, as I see it the only need for a "default" config is with the initial installation of the code. 2.5 does this by having key/sounder enabled ("Normal") , no external sounder and computer sound turned on. I forget whether it comes up with a predefined WPM setting but that might be a good idea. Some initial station ID that says something just identifying the program (MKOB 4.0.XXX) other than just blanks which might prompt the user the change it. Once the program is run, that "instance" of it follows any changes to its configuration that follow and becomes the default for that configuration.
I agree that model (changing “config” when something’s changed in the main window) makes sense for wire # but perhaps not for station ID or “Connected” state. For that, I think a fixed “initial” setting applied when the program starts up seems better. I figured listing the config option as “Initial Station ID” should be clear but I’m open to suggestions.
I also change my station ID, sometimes during sessions but also if I'm doing a public display where I tend to try and find an office call related to where that display is set up. I use different station ID's at home and at my summer place, using real office calls for long gone nearby stations.
Got it - makes sense it should be in the main panel, easy to change as needed.
If a single code copy is the approach we choose instead of multiple copies each in their own directory with their own local configuration file (which I still think is simpler and it allows for testing multiple versions on the same machine at the same time whereas if the code is always installed only once with multiple "instance" configuration files, how do we play around with different versions?) there still needs to a way for a user who is not computer savvy to select which "instance" or "instances" to run all at the same time. I've found having separate icons on the window each with their own name (I use wire1, wire2, ...) such that all that is necessary to do to start that instance is to click on it to be the most obvious way to do it.
I think the worry is that having multiple copies, just to have separate config files, is inviting complications in maintaining a consistent version and would be better addressed by permitting different copies to run using different config files. I’d think, say, a set of four scripts, “Station A”, “Station B”, “Station C” etc., each of which specified a separate config file (“--local-config station-A-config”, “--local-config station-B-config” etc.) should get the desired effect?
Of course there’s nothing keeping you from having multiple different versions installed - it just shouldn’t be REQUIRED if you want >1 station with their own station ID, wire, etc.
Maybe I'm missing something but both with key/sounder and loop configurations I also sometimes have computer sound enabled. This has become necessary when demonstrating 2.5 during Zoom meetings as for whatever reason the attendees, although they can hear me speaking, don't hear my real sounder clicking.
Agreed - that’s why “Use computer sound” is its own independent checkbox, available regardless of hardware interface/serial interface type. It’s also convenient if you want to be able to use a headset late at night when the clicking of a sounder that’s connected may be too much. There should be nothing in the config that ties use of computer sound to any other option.
With 2.5 I have generally found that there is no need for a separate robust museum version as someone suggested. The only thing I think I responded to a previous post was that a sticky configuration option on the configuration menu should be to automatically connect to the wire in the Wire window on the main screen if one is specified. Note, that said, I frequently just use MorseKOB in local mode, not connected to the wire number specified in the wire window. There's no need to be connected when I'm just showing someone how to send or sending their name so they can see it on the screen.
Yep - I guess it makes complete sense to add a “None” option to “Local Interface” hardware options to reflect that. Still perfectly reasonable for local practice, or working with recordings.
Configuration options should be of two forms, sticky (wire number, station ID, WPM, mode, port, sound and maybe a few others) and ones that go back to a default which at least for those about which I am thinking should just be disabled (such as show packets in 2.5) in other words "diagnostic" functions.
I agree what you call “sticky” is a refinement on the effect of changes in the main window. We could drop any changes made in the main window, and go by some default configuration every time MKOB starts up. I agree for wire # the expectation may be that it starts up wherever you left it last time and I think in that case there’s no point showing it in the config option. I think some things SHOULD revert to some fixed (configurable) “initial” setting and then be allowed to change. What you can configure, in that case, is the “Initial” setting but you can change it (temporarily, just for the duration of that session) in the main window.
I’d propose:
* “sticky” from one session to the next (=reconfigured from main window): wire #
* Set to (configurable) “Initial value”: station ID, code speed, character rate
* Configurable only from “Preferences”/“Configuration” window: HW interface type, port #, computer sound, local echo
Let me know if anyone has different ideas?
I agree that maybe automatically keeping a log during a session is a good idea but it should be deleted at the end of the session if the user does not want to see it and this should take a positive action on the part of the user to save it. I would not want to see a pop up menu when one exits the program asking whether to save it as that would confuse most folks who aren't interested or wouldn't know how to understand the file anyway.
As to station ID if I forget to remove "bathroom break", I'm sure I would fix it the next time I turned the program on so again no need for any default except with the initial installation of the code.
You don’t expect to start a session with some fixed station ID of yours?
73, N6PWD
-Patrick.
… 73, Chris
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#213 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYK4G5E4B4FSLOPNEW5LSXD7YFANCNFSM4VLNQFUQ>.
|
Beta Was this translation helpful? Give feedback.
-
|
It makes the configuration you specify update the system-wide (“global”) defaults that are the starting point for every MKOB instance (instead of the “local” config that’s specific to every instance).
We expected that, for instance, serial port might be a globally-specified and system-wide setting, whereas wire # or WPM would be a per-instance setting. Checking that box would make the config code attempt to update whatever the system-wide settings are.
73, N6PWD
-Patrick.
… On Dec 28, 2020, at 4:16 PM, Les Kerr ***@***.***> wrote:
What does the Configure System Defaults checkbox do?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#213 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYK26FSPUEEHNBYPDQJ3SXENUNANCNFSM4VLNQFUQ>.
|
Beta Was this translation helpful? Give feedback.
-
|
I don't really understand why we make a distinction between 'system' and 'local' config settings. I understand 'system' to be global across all user accounts on a given computer, while 'local' settings are specific to a particular user account. In all the MorseKOB installations I've come across, the user has only had a single account on their computer, so I have a hard time putting this distinction into practical terms. Why not make all the settings local and be done with it? I find the extra complexity confusing, and it might be confusing to others as well. I guess it makes sense for some settings to be 'sticky' and some 'temporary' (lasting only for the duration of the session unless they're deliberately saved). And I guess that's something I could get used to. I'm not as concerned as Chris is about having a command line option to specify an alternate config file. All it would take would be a small change to our existing A user who wants to run a second instance of the program with its own profile would edit ~Les |
Beta Was this translation helpful? Give feedback.
-
|
And just for clarification, Chris and I and others like us want to have multiple instances of MKOB running under a single user account. This doesn't mean separately installed instances, but multiple instances of the same code running simultaneously but with using different config profiles. |
Beta Was this translation helpful? Give feedback.
-
|
On Dec 28, 2020, at 4:44 PM, Les Kerr ***@***.***> wrote:
I don't really understand why we make a distinction between 'system' and 'local' config settings. I understand 'system' to be global across all user accounts on a given computer, while 'local' settings are specific to a particular user account. In all the MorseKOB installations I've come across, the user has only had a single account on their computer, so I have a hard time putting this distinction into practical terms. Why not make all the settings local and be done with it? I find the extra complexity confusing, and it might be confusing to others as well.
FWIW, this is how the code is currently working: there’s an “app”-level config file (what I refer to as “global” or “system”) and a user-specific config file (what I refer to as “local”):
$ ls -l ~/.pykob/
total 32
-rw-r--r-- 1 patrick staff 183 Dec 28 15:00 config-patrick.ini
-rw-r--r-- 1 patrick staff 28 May 3 2020 config-patrick.ini.bak
-rw-r--r-- 1 patrick staff 41 Dec 28 15:00 config_app.ini
-rw-r--r-- 1 patrick staff 41 May 3 2020 config_app.ini.bak
I guess it makes sense for some settings to be 'sticky' and some 'temporary' (lasting only for the duration of the session unless they're deliberately saved). And I guess that's something I could get used to.
I'm not as concerned as Chris is about having a command line option to specify an alternate config file. All it would take would be a small change to our existing MKOB.cmd script, which would look something like this:
:: Run MKOB program
@echo off
py ../MKOB.pyw --config profile1.ini >mkob.log 2>&1
A user who wants to run a second instance of the program with its own profile would edit MKOB.cmd to change profile1.ini to profile2.ini (or any other name) and create a desktop shortcut to the new script to run the program with the alternate profile.
Makes sense. Note that inserting a system-wide set of defaults (another reason to have only one installed copy) does no harm - the only config file that should matter to the user is the “local” one.
And I fully agree the only difference between multiple copies running on a given machine should be the config file they’re pointed to on the command line, as you show above. I’m not advocating different copies of MKOB, different user accounts, or even separate directories for each instance. We should just add a “--config-profile” argument to the CLI to direct the choice of (“local”) config file to have the ultimate word on all options. Anything not specified there would come out of the system-wide/app-wide config file.
… ~Les
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#213 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYK3ZX2USJDUXLDT436TSXEQ75ANCNFSM4VLNQFUQ>.
|
Beta Was this translation helpful? Give feedback.
-
|
Patrick, This sounds great to me, as long as everything I change in the Preferences dialog gets saved to the 'local' config file specified by the (optional) command line argument. As I see it, the only time the 'global' config file will come into play for me is when I first install MKOB or when I specify a new profile on the command line. I doubt that I'll ever have occasion to change the 'global' defaults. Chris, are you OK with this? I think it does everything we want as far as multiple wires are concerned. Like you, I've spent a lot of time on the phone with computerphobic MorseKOB users, and I know how frustrating it can be. In this case, however, I'm convinced I can get on a TeamViewer session with a user that needs extra help and quickly set up the necessary command scripts and desktop shortcuts. ~Les |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone,
Even though the ‘config’ module currently processes two config files in turn, I suppose one way to simplify things would be to drop even the “Configure System Defaults” option from the Preferences window and make the configuration info always apply to the “local” user. We can retain the option in the CLI to control the system-wide info for “power users”. We could ultimately add it to the “Advanced” config options as well.
Any thoughts about changing the “Preferences” menu to apply only to the one “local” (or whatever file was specified as the profile data file at program startup) config file?
73, N6PWD
-Patrick.
… On Dec 28, 2020, at 6:09 PM, Patrick Dirks ***@***.***> wrote:
> On Dec 28, 2020, at 4:44 PM, Les Kerr ***@***.***> wrote:
>
>
> I don't really understand why we make a distinction between 'system' and 'local' config settings. I understand 'system' to be global across all user accounts on a given computer, while 'local' settings are specific to a particular user account. In all the MorseKOB installations I've come across, the user has only had a single account on their computer, so I have a hard time putting this distinction into practical terms. Why not make all the settings local and be done with it? I find the extra complexity confusing, and it might be confusing to others as well.
>
>
FWIW, this is how the code is currently working: there’s an “app”-level config file (what I refer to as “global” or “system”) and a user-specific config file (what I refer to as “local”):
$ ls -l ~/.pykob/
total 32
-rw-r--r-- 1 patrick staff 183 Dec 28 15:00 config-patrick.ini
-rw-r--r-- 1 patrick staff 28 May 3 2020 config-patrick.ini.bak
-rw-r--r-- 1 patrick staff 41 Dec 28 15:00 config_app.ini
-rw-r--r-- 1 patrick staff 41 May 3 2020 config_app.ini.bak
> I guess it makes sense for some settings to be 'sticky' and some 'temporary' (lasting only for the duration of the session unless they're deliberately saved). And I guess that's something I could get used to.
>
> I'm not as concerned as Chris is about having a command line option to specify an alternate config file. All it would take would be a small change to our existing MKOB.cmd script, which would look something like this:
>
> :: Run MKOB program
>
> @echo off
> py ../MKOB.pyw --config profile1.ini >mkob.log 2>&1
> A user who wants to run a second instance of the program with its own profile would edit MKOB.cmd to change profile1.ini to profile2.ini (or any other name) and create a desktop shortcut to the new script to run the program with the alternate profile.
>
>
Makes sense. Note that inserting a system-wide set of defaults (another reason to have only one installed copy) does no harm - the only config file that should matter to the user is the “local” one.
And I fully agree the only difference between multiple copies running on a given machine should be the config file they’re pointed to on the command line, as you show above. I’m not advocating different copies of MKOB, different user accounts, or even separate directories for each instance. We should just add a “--config-profile” argument to the CLI to direct the choice of (“local”) config file to have the ultimate word on all options. Anything not specified there would come out of the system-wide/app-wide config file.
> ~Les
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub <#213 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYK3ZX2USJDUXLDT436TSXEQ75ANCNFSM4VLNQFUQ>.
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#213 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYK6AEAXAVTBAC5OM6YLSXE24JANCNFSM4VLNQFUQ>.
|
Beta Was this translation helpful? Give feedback.
-
|
Sounds good to me! :-) ~Les |
Beta Was this translation helpful? Give feedback.
-
|
Wow, a lot transpired while I wasn't looking! I'm not going to comment on all of this, but I do have some info/input on a few things. Some of this is duplicating what has been said, but I'm going to say it anyway. I'm not going to reference the previous content/comment in order to save some time/space.
|
Beta Was this translation helpful? Give feedback.
-
|
Wow, I agree with everything you're proposing, @AESilky, with possible reservations on your last point (changes made on the main GUI to be not 'sticky'), and even there I can see myself coming around to your way of thinking. I'm certainly willing to try it your way and see how I like it and how quickly I get used to it. Even as I'm writing this I find myself warming up to the idea. Quite often when I start MKOB and connect to a wire, I discover too late that I made a temporary change to my station ID the last time I used the program. Just a side comment on your first point: It's not only the RPi interface that will support multiple wires. We could have multiple USB ports in use on a single computer. |
Beta Was this translation helpful? Give feedback.
-
|
First referencing Ed's items 1-4, I agree there only needs to be configuration data for each instance of the application. but I tend to think that asking the user to tell you where to put them may be too much for computer phobic individuals. Again for a given version of the application, the concept of instance numbers or something similar is a good idea each with its own configuration file or files but that the average user doesn't have to understand that as he sets all configuration data from the GUI and the application saves it in the file/folder associated with that instance. Item 5. Each instance of each version of the application should have its own unique configuration however that is done Item 6. I have no familiarity with VSC so I'm not sure whether you are referring to different versions of the code or just different instances of one version. As to different versions of the code what I've been doing is creating different folders in "Documents" named MKOB4A, MKOB4B, etc. and loading the application into those. For me at the moment that addresses the different version but not the different instances of one version. Both need to be supported. Item 7. Here I go again, I find it absolutely essential that things like wire number, station ID, WPM, mode (loop/Key-sounder/other), interface (serial/RPi pins), computer sound (on/off) as well as things like server address be sticky. If it is essential for you to not have them sticky another option which would have to be sticky would be whether to make these options sticky and the default should be sticky. From my perspective the only non sticky options for each instance of the application would be diagnostic options like "show packets". Without this I will find version 4 unusable for my applications. |
Beta Was this translation helpful? Give feedback.
-
|
@jchausler, although most users would not understand the contents of the file, I think that many might find it nice to be able to play back the session at some point. That is actually the main purpose of the file. The play feature uses that file to allow you to play/pause/back/forward/skip to different parts of the session. I do agree, that it should not be saved by default (as it currently is - it is commented in the code as a known issue), and also that they shouldn't be prompted on exit (that would be really annoying). What I plan in the near term is a 'File Menu' option to 'Save Recording...'. In the long run I want to add a VCR type panel at the bottom of the GUI with 'record', 'play', 'forward', 'back', and other controls. This is where you would save the recording if you wanted to. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Ed, I agree completely and your idea of a VCR type control is an interesting one. That said whether this VCR panel appears on the main GUI should be a sticky option as I think it would confuse the run of the mill user of the application. No need to put any more on the window than for basic Morse communications I think. And again like "show packets" in 2.5, having the decoded character displayed after the time sequence makes it so much easier to locate some odd occurrence in the record. An example of this is media player VLC which has a VCR set of buttons but they don't appear in the basic application unless you ask that they appear. 73, Chris |
Beta Was this translation helpful? Give feedback.
-
|
On Dec 29, 2020, at 10:27 AM, J. Chris Hausler ***@***.***> wrote:
First referencing Ed's items 1-4, I agree there only needs to be configuration data for each instance of the application. but I tend to think that asking the user to tell you where to put them may be too much for computer phobic individuals. Again for a given version of the application, the concept of instance numbers or something similar is a good idea each with its own configuration file or files but that the average user doesn't have to understand that as he sets all configuration data from the GUI and the application saves it in the file/folder associated with that instance.
Item 5. Each instance of each version of the application should have its own unique configuration however that is done
Item 6. I have no familiarity with VSC so I'm not sure whether you are referring to different versions of the code or just different instances of one version. As to different versions of the code what I've been doing is creating different folders in "Documents" named MKOB4A, MKOB4B, etc. and loading the application into those. For me at the moment that addresses the different version but not the different instances of one version. Both need to be supported.
Item 7. Here I go again, I find it absolutely essential that things like wire number, station ID, WPM, mode (loop/Key-sounder/other), interface (serial/RPi pins), computer sound (on/off) as well as things like server address be sticky. If it is essential for you to not have them sticky another option which would have to be sticky would be whether to make these options sticky and the default should be sticky. From my perspective the only non sticky options for each instance of the application would be diagnostic options like "show packets". Without this I will find version 4 unusable for my applications.
If instead of restarting with the wire # and station ID as they were when you last quit MKOB we offer a way to configure the “Initial wire #” and “Initial station ID” that MKOB starts up with, would that satisfy your requirements? Why do you find it “... absolutely essential that things like wire number, station ID, WPM, mode (loop/Key-sounder/other), interface (serial/RPi pins), computer sound (on/off) as well as things like server address be sticky”?
Is it fair to summarize your expectation to be that any change in the main window simultaneously persist that setting in the config file for use at the next start, with nothing changed from the way you left MKOB the last time?
Ed, Les - thoughts? What would you say most users expect or require?
73,
-Patrick.
… —
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#213 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYK3OZQEYW3VSMUPGVVTSXINRFANCNFSM4VLNQFUQ>.
|
Beta Was this translation helpful? Give feedback.
-
|
Hi Patrick, Well, the simple answer is that's how I've been using it both for my own use but also at the AWA museum. At various times I change all of the above expecting that the next docent (or me :-) who starts it next time will get whatever I last configured. Also even during sessions I sometime exit the program but want it to come back exactly where it was when I start it again. And again that is true here at home and at the AWA museum. So a separate way of setting up and having an "initial configuration", when to change the initial configuration for the next time I start the program can be done merely by setting the conditions on the current GUI screens and then exiting the program, is to me overkill. I'm all for keeping it simple and so first of all there should only be one way of doing anything (I spent much of my life designing user interfaces and I learned this truism early on) and since I can change the settings during a session this should be the only way to set them up. I would agree that at initial installation there should be a default configuration, I've spoken about what I think it should be before, but once the program is started, whatever the used enters into the GUI screen should stick until the next time he or she changes it which could be several times during the session, or months from now. And the next time the program is started whatever was last set up should return. So yes, your last statement in summary is my expectation. The only settings which should not be "sticky" should be debug options which one might turn on (and off) during a session. Once again, like "show packets" in 2.5. And once again of course, there should be a number of "profiles" (I was previously using "instance" to mean profile but Les and I have decided that "profile" is a better term for this) each independent of each other which contain the entire set of configuration options for a MorseKOB session and that multiple copies of the program be capable of being run simultaneously under one user each with separate profiles. Changing the settings within one of these copies should only change the profile from which that copy is running and have no effect on any other profiles and running copies. 73, Chris |
Beta Was this translation helpful? Give feedback.
-
|
Patrick, What users expect will depend on whether they're transitioning from MorseKOB 2.5 or if 4.0 is their first experience with MKOB. As long-time 2.5 users, Chris and I both expected that settings changed on the main KOB window (station ID, code speed, and wire number) would be saved and restored the next time the program is run. Having given it some thought, though, especially considering how I might set up alternate profiles with desktop shortcuts to run them, I'm starting to see the advantages of a different approach. My feeling now is that any changes made on the main screen should be 'temporary', and anything changed in the Preferences dialog (e.g., interface type, port number) should be 'permanent' (or 'sticky') and saved to the current profile as soon as the setting is changed. I'd like to give this approach a try. Of course, I might decide to retract my recommendation as a result, but that's how I feel right now. I agree with Chris that things need to be simple. At least this paradigm is simple to explain: if you want to change something temporarily, do it on the main KOB window; if you want the change to be more permanent (i.e., saved for the next time you run the program), change it in the Preferences dialog. The typical user doesn't need to be concerned with the concept of profiles, but some of us will use them extensively. ~Les |
Beta Was this translation helpful? Give feedback.
-
|
I already indicated my preference in my earlier comment #7. However, I seem to be in the minority, so I'll deal with it saving the station and wire values from the main GUI. |
Beta Was this translation helpful? Give feedback.
-
|
I currently have the need for five frequently used configuration settings (profiles):
It would be great if I could have these settings saved as five different named profiles. As for how the app starts, I could see either being able to select one as the default, or having it start with the last one I used. Either would make sense to me and I would get used to it being that way. Of course, it would be nice if the app was installed as a 1st class (proper) application, such that the profile type could be associated with the app so I could just double-click the profile file (or a shortcut icon) and have it start with that profile. If we can't/don't do that, then there should be a command parameter that lets me start it with a specific profile. That wouldn't be as nice, but would still allow me to create desktop shortcuts/icons that started a specific profile. I would also like to be able to switch profiles without having to exit and restart the app. I definitely don't want to have five copies of the code in order to have these five different profiles, since I'm typically running from my development code area (I have two copies, one that is always 'master' and one that is whatever branch I'm currently working on). I also don't want to have two copies of each of the profiles (one to be able to run with my 'master' branch copy and one to run with my current development copy). Once I get the Instructograph tapes recorded I probably wouldn't use that profile very much, but I could still see me using it if I wanted to show/demonstrate the Instructograph to someone, and having the named profile would be handy rather than me needing to remember the settings and set things that way to do the demo. Once I get all of the modem recordings transferred, I probably won't ever use that profile again - but there are LOTS of recordings to transfer. So it would still be very helpful to have the ability to easily use that profile. |
Beta Was this translation helpful? Give feedback.
-
|
I wrote all of this before I refreshed and saw @leskerr 's comment. I gave his comment a 'thumbs-up' because I completely agree. Please take my comment simply as input on how I would use different configurations (profiles) with the app. |
Beta Was this translation helpful? Give feedback.
-
|
OK, here's a monkey wrench. I would like to have a screen display similar to the display in the early versions of MorseKOB 4 (MorseMR). For use in unattended museum setups, it's really nice. It's also a nice display when I do the Santagrams at the museum. Many visitors record this screen and it helps to look nice. I don't have a screenshot handy or I'd attach it. Les knows what I'm referring to. This could be a special module that talks to the basic screen and gets it's configuration from that and then closes the standard screen or it could be done with a command line input. Either way would be fine since usually once that's set, it's not changed often, if at all. Or maybe a menu item that does something like "Run MorseMR" that reads the configuration from the standard window and lets the fancy display completely take over the screen. I use MorseMR because that's the application (WF Museum Road) that started Les down that path. It would need a more appropriate name in the end. I've used that screen display in at least 3 or 4 museums, each with a customized page header. |
Beta Was this translation helpful? Give feedback.
-
|
That is one of the reasons I wanted to reserve the SPI pins on the Raspberry Pi. I would like to output a very simple Reader screen in a large font to an attached screen through the SPI interface on a Pi. My assumption is that running a RPi (very inexpensive) for a display would be preferred, and having the ability to have a dedicated 'code' display would be preferred. Of course, that assumes 1 Pi per station/wire that you want to display, but given the price that seems like it could be better than trying to run a bunch of instanced on a single machine. |
Beta Was this translation helpful? Give feedback.
-
|
@wamorganjr I couldn't agree with you more. A simple, attractive display for museum exhibits is absolutely the way to go. My current thinking is that it would be a separate application from MKOB 4, just as MorseMR is separate from MorseKOB 2.5. It would launch automatically when the system is powered up and could run unattended. I'm planning to install a 'headless' RPi at the Foss museum in Tacoma, WA that'll have a monitor attached (but probably no keyboard or mouse) to work with a key and sounder for the telegraph exhibit. The screen would be something along the lines of what you've been using for the Santagrams. |
Beta Was this translation helpful? Give feedback.
-
|
For these things, I thing the RPi is the way to go. They are inexpensive, small, and easy to maintain. A separate app might make sense, but also outputting to a dedicated display (on the SPI interface) might be good as well. |
Beta Was this translation helpful? Give feedback.
-
|
Hi Ed,
Yes, that’s what I plan to implement first (main window changes are not saved; initial settings are from config info) but I’ll make sure the preferences are labeled “INITIAL station/wire #” to make it clear it’s not changing the current setting as the main window does. It’s easy to get rid of those initial settings, of course, and/or have the main window implicitly save the config anytime it’s changed to it’s the starting value when you restart.
Chris, I’m surprised you’re not in favor of having the main window’s changes be impermanent. I’d think if I had a few displays set up on different wires it’d be convenient to make sure that if you just power down the display and have it reboot it always comes back to a configuration that’s consistently configured for each station (this is once we have support for separate configurations, selectable when the main program is started)? Doesn’t that make it simpler to make sure the displays are properly configured every time?
73, N6PWD
-Patrick.
… On Jan 3, 2021, at 11:30 PM, Ed Silky ***@***.***> wrote:
I would really like to give it a try (values in the main GUI not being persisted).
In the configuration/profile you should be able to specify what you want the start up to be, but while running, if I change my station ID to indicate that I'm stepping away for 5 minutes to answer the door, or I change my speed to 30 (from 22) in order to follow a particularly fast sender, I don't want those to be saved as my new startup profile.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#213 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYK4OZEWLVXBACN75EXDSYFVCJANCNFSM4VLNQFUQ>.
|
Beta Was this translation helpful? Give feedback.
-
|
BTW - @leskerr and @AESilky recently created KOBServer instances on cloud (@leskerr on AWS and @AESilky on IBM). We did this to possibly replace a couple home located Raspberry Pi 'server' instances with more reliable server instances. As part of that, I added a configuration parameter for the (KOB)server URL. |
Beta Was this translation helpful? Give feedback.
-
|
That option exists in the 2.5 version. |
Beta Was this translation helpful? Give feedback.
-
|
I'm sorry but I'm completely against making the configuration items on the main display not sticky. I would find it difficult to use if that is the decision. If it really is a contention point, adding an item to the underlying config menu (the advanced configuration, down one from more frequently configured items) that selects whether the top level GUI items are sticky or not, is my suggested solution and I think the default should be sticky. I agree that a separate display showing only the code reader screen, whether done with a separate program or as an option for the regular program and whether done on a separate SPI screen from an RPi or the main screen on any platform is an interesting option at least for selected environments, in particular unmanned ones. The RPi 4 of course has two small (I forget whether its "mini" or "micro") HDMI interfaces which I assume will support two separate screens, another option possibly for a separate display with the main display on the other screen. I could see such a configuration at the AWA with the main screen in the office (so I can see it :-) and then a smaller screen out in the visitor area in front of the office with just the reader screen shown. That said I don't have an RPi 4 and in the short term don't plan on getting one, but such a configuration option might force me to invest in one ;-) However, I have found the screen showing all the persons (or things) connected to the selected wire to be informative to visitors to both the AWA office as well as at my individual displays as well. Visitors are fascinated that I'm chatting with folks all around the country and the display shows them that it's real and I'm not just feeding the bull :-) So for my purposes I will likely mostly stick to the 2.5 type display. 73, Chris |
Beta Was this translation helpful? Give feedback.
-
|
Let me understand better (I haven't seen one of these displays firsthand)... Would a screen that just had the Reader (decoded code) and the Station list be good for a display? That's what I think, but, again, I haven't seen one. What I think of on RPi is a second display that just shows those two, full screen, and in large print. It wouldn't have the lower parts of the display - the 'text/keyboard' sender, and the station, wire, speed, closer, etc. panels. |
Beta Was this translation helpful? Give feedback.
-
|
Ed, I'm thinking the monitor would only display the decoded text, in some attractive format (maybe with optional telegram-like header banners). I'm not so sure about a station list for unattended operation. It would be confusing to visitors and hard to explain. If a trained operator was present and maybe carrying on live conversations on the wire, then I'd expect them to use the normal MKOB 4 app. ~Les |
Beta Was this translation helpful? Give feedback.
-
|
That makes sense. I just mentioned the station list because I thought someone brought it up. My initial thought was just the text in a large enough font to easily see it from a distance. I like your idea of optionally including a telegram type header. |
Beta Was this translation helpful? Give feedback.
-
|
For a museum setting, the display will likely be a large monitor. Small multi line displays won't work.
…-------- Original Message --------
From: Ed Silky <[email protected]>
Sent: January 5, 2021 1:43:48 AM EST
To: MorseKOB/PyKOB <[email protected]>
Cc: ChipM <[email protected]>, Mention <[email protected]>
Subject: Re: [MorseKOB/PyKOB] Proposed design for "Preferences"/"Config" panel (#213)
That makes sense. I just mentioned the station list because I thought someone brought it up. My initial thought was just the text in a large enough font to easily see it from a distance. I like your idea of optionally including a telegram type header.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#213 (comment)
|
Beta Was this translation helpful? Give feedback.
-
|
Here's a screen shot of the display used at RR Museum of PA. The header is easily created with any graphics program and appears at the top of each new page scrolled up the display. This was displayed on an older computer monitor, not a newer high resolution display. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the image. That's fun, and help illustrate things that might help in a display. |
Beta Was this translation helpful? Give feedback.
-
|
Hi gang,
Right now, the preferences panel code in my local branch shows up the following (on a Mac - this is TkInter so it’ll look differently on different platforms):
All of these are being pulled from current config info at at initialization and saved as new config info on ’Save’.
I believe there are not currently any config options corresponding to an “Automatically connect at startup” setting or the “Hardware Interface” (None/GPIO/Serial port) setting? Ed, I believe that should be a straightforward expansion of the ‘config’ module and argument parsing - shall I file a separate issue for that?
73, N6PWD
-Patrick.
… On Jan 3, 2021, at 11:48 PM, Patrick Dirks ***@***.***> wrote:
Hi Ed,
Yes, that’s what I plan to implement first (main window changes are not saved; initial settings are from config info) but I’ll make sure the preferences are labeled “INITIAL station/wire #” to make it clear it’s not changing the current setting as the main window does. It’s easy to get rid of those initial settings, of course, and/or have the main window implicitly save the config anytime it’s changed to it’s the starting value when you restart.
Chris, I’m surprised you’re not in favor of having the main window’s changes be impermanent. I’d think if I had a few displays set up on different wires it’d be convenient to make sure that if you just power down the display and have it reboot it always comes back to a configuration that’s consistently configured for each station (this is once we have support for separate configurations, selectable when the main program is started)? Doesn’t that make it simpler to make sure the displays are properly configured every time?
73, N6PWD
-Patrick.
> On Jan 3, 2021, at 11:30 PM, Ed Silky ***@***.*** ***@***.***>> wrote:
>
>
> I would really like to give it a try (values in the main GUI not being persisted).
>
> In the configuration/profile you should be able to specify what you want the start up to be, but while running, if I change my station ID to indicate that I'm stepping away for 5 minutes to answer the door, or I change my speed to 30 (from 22) in order to follow a particularly fast sender, I don't want those to be saved as my new startup profile.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub <#213 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYK4OZEWLVXBACN75EXDSYFVCJANCNFSM4VLNQFUQ>.
>
|
Beta Was this translation helpful? Give feedback.
-
Patrick, I'm not seeing your embedded screenshot of the preferences panel. ~Les |
Beta Was this translation helpful? Give feedback.
-
|
Same here. |
Beta Was this translation helpful? Give feedback.
-
|
@pwdirks - yes, those would be easy to add. If you could, please create an issue and I can put those in. |
Beta Was this translation helpful? Give feedback.
-
|
I’ve created issue #223, "Need config options for “Automatically connect at startup” and “Hardware Interface”” to track the issue.
I’ll leave it unassigned for now; you’re welcome to take it but I’m also fine taking it up as part of the config/preferences dialog work. I think the pattern in ‘config.py’ is clear enough. Whoever gets to it first.
I guess Configure.py and the various default argument parsing should be updated, too. Maybe with “--auto-connect=ON/OFF”? We already have “-a” (for “audio”) and “-A” (for sounder) and “-c” (for “char. speed”); maybe “-C” for “Connect”? There’s no “-h” or “-H” defined (we’re rapidly approaching the single-letter command option density of “ls” :-)) so I’d propose “--hardware-interface” / “-h” for the “GPIO”/“SERIAL”/“None” argument? I’ll add that to the issue.
73, N6PWD
-Patrick.
… On Jan 6, 2021, at 11:30 PM, Ed Silky ***@***.***> wrote:
@pwdirks <https://github.com/pwdirks> - yes, those would be easy to add. If you could, please create an issue and I can put those in.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#213 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYK6UOEZZQZ7DJPMDUWDSYVPK5ANCNFSM4VLNQFUQ>.
|
Beta Was this translation helpful? Give feedback.
-
|
Right now, the preferences panel code in my local branch shows up the following (on a Mac - this is TkInter so it’ll look differently on different platforms): All of these are being pulled from current config info at at initialization and saved as new config info on ’Save’. There are not currently any config options corresponding to an “Automatically connect at startup” setting or the “Hardware Interface” (None/GPIO/Serial port) setting? I filed a separate issue #223 for that. |
Beta Was this translation helpful? Give feedback.
-
|
See also issue #169, "MKOB: Add 'config' menu item and dialog" for details, BTW. Let's move further discussion of the specific implementation there? |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone,
How frustrating the image got dropped. I just remembered the discussion on ‘Preferences’ was started as a discussion on GitHub, not as an ’issue’. I did just find the issue Ed created, #169 "MKOB: Add 'config' menu item and dialog” and I’ve put a copy of the screenshot there.
I propose we continue discussion of specifics of the config/options/preferences dialog there.
73, N6PWD
-Patrick.
… On Jan 6, 2021, at 11:29 PM, Ed Silky ***@***.***> wrote:
Same here.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#213 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALTAYK6TZ7NMVLWUSKFCK2DSYVPFLANCNFSM4VLNQFUQ>.
|
Beta Was this translation helpful? Give feedback.
-
Hi Guys,
I have no idea how this image will show up in your e-mail (feel free to visit this discussion on the GitHub site if it doesn't look right) but I thought a "Preferences" settings dialog might be helpful. I drew up the following as a starting point:
Any thoughts about content, layout, phrasing, etc? Am I missing anything? Don't worry too much about detailed cosmetics - this is just a sketch, and the actual color, control shape, etc. will be determined by the TkInter library elements.
All comments most welcome!
Thanks in advance,
-Patrick.
Beta Was this translation helpful? Give feedback.
All reactions