Loading ...
Sorry, an error occurred while loading the content.

RE: [aprsisce] Multiple Settings Profiles

Expand Messages
  • Fred Hillhouse
    I was thinking mainly along the lines of what might be simple and therefore might might be added at some point. If it is complicated then it possibly falls
    Message 1 of 34 , Jan 29, 2013
      I was thinking mainly along the lines of what might be simple and therefore might might be added at some point. If it is complicated then it possibly falls lower (maybe to the bottom) in the queue of the To-Do list providing there is enough reasoning to justify it.
      Working with the XML is already something Lynn does. Switching them out is more of an extension of current activity rather than a whole new process, such as macros. As a total noob programmer, saving a file is simple, adding macro stuff is not. Lynn certainly isn't a noob so he may already have something up his sleeve.
      Now Lynn has been suggesting that a LUA interface of sorts will be added. This may be along the lines of what you are thinking of. As I understand it, it would require the user to understand a programming language to some extent. That will keep a fair number of users away. The XML is almost simple enough for users not interested in LUA to implement.
      A example of profiles is on the OpenTrackers I own. There are two profiles available. There is a button to copy one to the other. I always do that first, then I modify one of the profiles for whatever I need. While they are running, the profile can be changed on the fly. Scott has added some scripting ability as well which is along the lines of the LUA interface above.
      Regardless of how profiles might be implemented, it is operator beware. The current default or multiples of it don't really change that. And, of course the support may be onerous, but we are all here to help. :)
      I suspect those that are interested in profiles will spend the time to organize them. But, maybe not a lot of time given that most users seem to set APRS up with a lot of help and never touch it again or learn more about it. I have a few tile sets, okay, way more than a few. To manage the tiles has become an interesting task but I think I have got it under control finally. I don't see the profile management as much different except that rather than lots of tile sets, I'll have only a few profiles.
      Best regards,
      Fred, N7FMH

      From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Greg D
      Sent: Monday, January 28, 2013 22:32
      To: aprsisce@yahoogroups.com
      Subject: Re: [aprsisce] Multiple Settings Profiles


      Let me throw out an idea...  Instead of trying to organize a set of complete profiles, how about recording the steps to transform one into the other?  A Macro. 

      This has been done by many applications over time.  Add a menu item to go into a record mode, where all menu selections and key strokes are recorded.  Turn off the recording and save the result (ideally in an XML or other editable form).  Have a menu item to execute a Macro, choosing among a set of files.  The responsibility for organizing what gets done to each state to turn it into the next state is up to the administrator.  Commands that don't make sense - for example if you executed the wrong macro for the state you're in - either get ignored or an error printed and the execution stopped.  Operator beware.  Keep it simple.

      Would that work?

      Greg  KO6TH

      Fred Hillhouse wrote:


      I don't see "adding profiles" as which settings to retain or not retain. Currently, I think of different profiles as different XML files. That is simply because, if I currently want a different profile, I have to create a new XML and start an instance pointing to it. I consider a profile change basically a restart but with all received packets retained. Of course, the new profile may display more or less stations as required based on filters, etc.
      Given that is the way I am thinking, it seems simple enough that if someone wanted a different profile, changes could be made as needed, then saved as a new XML with the profile name as part of the file name, such as APRSIS32-ProfileName.XML. A change in profile, while operating, is basically a close of the current XML and loading a new XML. Saving a new profile is the interesting part. Since the XML is currently saved at shutdown capturing any changes, saving a new profile basically negates the writing of the previous XML but the change. Changes have been made and they only apply to the new profile. This method is of course simplistic.
      As for a keystroke to move between profiles, well, currently we use the menus for most changes. In the beginning it could be stuffed in one of the menus. I would probably stuff it in the Enables menu since one profile or another is enabled. There will always be at least one enabled.
      Startup presents an interesting case. Which profile is selected? Always load the default, check the enable flags and switch profile if needed.
      Any future change to a profile does not need to propagate through all profiles. That is the concept of a profile. Each profile is different. Besides, what I want to keep across all will be different from someone else. Why should that be on the developer to make each setting ALL or EACH? It is on the user to add or delete settings in each of their profiles.
      My hope is the ability to switch between profiles without affecting the current display, unless the profile calls for it. The instance in theory runs forever while the profiles might change.
      As an example of my possible use, I am sitting inside with my internet only connection WebDT360. I pick it up and put it in the vehicle. I select my mobile profile.
          The minimum imagined changes are:
          Turn on serial ports, TNC and GPS.
          Turn off internet and APRS-IS.
          Open server port for the FT857-CAT application.
      When I get back home, I reverse the process.
      Currently, this takes a multiple number of screen taps. Not a biggie but I seem to miss one or two on occasion. My current method is actually start new with a different instance and XML.
      Of course, I would rather see more APRS functionality than profiles but at some point it would be nice if is isn't difficult.
      Best regards,
      Fred, N7FMH

      From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Lynn W Deffenbaugh (Mr)
      Sent: Monday, January 28, 2013 00:32
      To: aprsisce@yahoogroups.com
      Subject: Re: [aprsisce] Multiple Settings Profiles


      And can you describe the settings that a given profile would retain and
      which would be overridden? Some folks would want -IS and/or RF ports to
      come and go. Others will want the Beacon settings to be changed, but
      everything else to be preserved. Yet others would want everything
      retained but a different set of nicknames to come into force.

      I really can't get my mind around just what you want switched and what
      you want retained, so for the time being, it's an all or nothing choice
      between instances with the included lack of continuity.

      If you all can detail use cases whereby profiles would be switched that
      would benefit from consistency rather than a different instance, I would
      entertain the discussion. And with those details, you'll need to state
      just which settings are retained and which are switched, both current
      settings and all future settings that may be added to the program that
      will need to be retained or switched between profiles, a daunting task,
      wouldn't you agree?

      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

      On 1/27/2013 11:21 PM, James Ewen wrote:
      > On Sun, Jan 27, 2013 at 7:26 PM, Rob Giuliano kb8rco@...> wrote:
      >> Yes we have, and the conclusion for switching settings for different uses
      >> (like sailing vs motoring vs set station on a single device) was as simple
      >> as:
      >> 1. ONE SINGLE Install of the executable file
      >> 2. ONE set of maps
      >> 3. Multiple directories with an XML file in it
      >> ALL XML fiels point to the same maps directories
      >> 4. use multiple shortcuts with start in paths to the directories with XML
      >> files.
      > The biggest problem there is the lack of continuity. You basically
      > shut down one instance and start up a brand new instance.
      > You'd have to use something like Auto Hot Key to record a series of
      > mouse clicks and keystrokes that would be needed to change all the
      > desired settings while the program is still running.
      > Lynn has indicated that making changes while the program is running
      > could lead to problems, yet that's what the user is doing when
      > interacting with the program. We can't edit the XML file while the
      > program is running, but when making changes via the menus, that's more
      > or less what it happening.
      > A profile concept would simply be making a number of changes as if the
      > user were making them, or if an external program was playing back a
      > series of mouse clicks and keystrokes.
      > --
      > James
      > VE6SRV
      > ------------------------------------
      > Yahoo! Groups Links

    • Lynn W Deffenbaugh (Mr)
      ... Yep, that would do it as the general release is nearly always lagging being the development version. I just wanted to make sure that the reversion
      Message 34 of 34 , Jan 30, 2013
        On 1/30/2013 6:59 AM, Colin XSD wrote:
        > On 30/01/2013 02:15, Lynn W Deffenbaugh (Mr) wrote:
        >> Has anyone ever gotten the startup warning that the configuration was
        >> saved by a later version of APRSISCE/32 and warned that it might not be
        >> reliable to go backwards in versions?
        > Yes Lynn, many times, I just ignored it:S. It has never caused me any
        > concern.
        > I think I normally see that warning when I cut & paste bits into a new
        > xml file but forget to change the 'Dev' flag.

        Yep, that would do it as the general release is nearly always lagging
        being the development version. I just wanted to make sure that the
        reversion detection code was actually working in light of the recent
        discussion of multiple configurations and XML files and preserved
        settings. I attempt to do backward compatibility by
        migrating/converting/upgraded XML settings in the new versions. But
        sometimes that conversion is one-way and if you take an upgraded XML and
        load it into a back-level version, those settings may revert to default
        values. Hence the warning. Nothing particularly "bad" will happen, but
        your settings may not be as you expect.

        Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
      Your message has been successfully submitted and would be delivered to recipients shortly.