[Touch Diamond, MDA Compact IV General] low.flying.pigs:
In brief response to matters arising:

Many applications split options between basic and advanced, so that the features considered more advanced are not shown unless desired. This inherrently solves any ease of use issue a non advanced user may experiance. It also addresses startup delay, as options considered advanced, unless selected by the advanced options option, do not affect startup time when implemented correctly. A flexible variation of this is where the user selects what options they want ordinarily available to them.

Startup delay per option has been previously stated as 0.1~0.2 seconds (100~200 milliseconds). However, if that were true of all devices, with the options already therein, GCC should take longer than it actually does to start up. Furthermore, once started, there is no issue on any device and in any event, this would realistically go unnoticed and / or cause no genuine inconvenience to any ordinary user. In fact, start would be quicker than now with advanced options option(s) unselected.

Some of the existing option pages may be filling up, but that can be addressed, and further pages added as required, which can just link from existing pages as required.

A topical example of both application size, and usage of the .dll technique for best use of device resources detailed in post 2191, is the browser Opera Mobile 10, see here. When installed, it can be observed the .dll contains most of the functional parts that would otherwise be in the .exe file, as per screen grab 1 attached.

Further, the overall size of Opera Mobile 10 is an example that GCC is a lightweight application with minimal footprint and would have to increase in size many times over to not be. It is also an example of why browsers other than those that would natively be on a device, if any, should not, and are not now, used or relied upon.

Coding assistance, now requested, will follow in due course. This had not been previously requested. Instead of now issuing without cogent reason what can be perceived as insult and abuse, you could have requested coding assistance in the first instance. If there are any differences between devices, this does not necessitate any option be provided. Operating System is detectable as is Device. The correct commands can therefore be used correctly based on that. GCC already includes OS detection for display handling. There is no reason it cannot be used for other functions.

Whilst the issues persist of objection without cogent reason, and general conduct that disuades users from participation, it will continue to be necessary to repeatedly counter it.

The fact some features are standard elsewhere, and proposals do not adversely affect any existing user or functionality at all, when dealing with ordinary rational people ought to be sufficient. Unfortunately, we are not dealing with ordinary rational people, but specifically, primarily a single individual of the type that users have speculated about, that speculation supported by overwhelming and compelling evidence that continues to mount. It can be observed the wisdom 'rarely if ever do such individuals actually change' was absolutely accurate:

As the above is so extraordinarily and relentlessly absurd, it cannot be addressed in any way other than to break it down it to its individual asinine parts:

Wrong. On screen device shutdown functionality used correctly is not dangerous in any way at all. Even used incorrectly it is not dangerous in any way at all. Users that do not require the function do not select the option for it, as with any other option. The function can be switched by the existing option 'Show 'Exit' after stop'. Press exits GCC upon finger up. Press and hold shuts down the device. Whatever is necessary to implement this will be done. GCC can warn when exiting or shutdown before acting if necessary. This warning can be switched using the existing 'Confirm 'Pause' and 'Stop'' renamed as 'Confirm 'Pause' 'Stop' and 'Exit''. Upon selecting either Exit or Shutdown, this warning is displayed, the action being carried out automatically if not cancelled within a short time period. A user would not be any more likely to accidentally select Exit or Shutdown any more than accidentally anything else to which furthermore there are mostly no safeguards. Furthermore the Exit and Shutdown button is not available on Main Screen until logging has been stopped. No additional options are necessary at all. This functionality is not dangerous in any way at all. It is in fact safer than most functions with multiple safeguards against inadvertent use rendering inadvertent use virtually impossible for ordinary normal users. As has all been previously documented.

There are only three dangerous issues: Firstly, not implementing this, and the needless wear and tear upon devices occurring rendering them beyond repair. Secondly, not implementing this, preventing GCC becoming a standalone GPS Cycle Computer as detailed below. Thirdly, you and your misguided, relentless and tireless crusade to damage the project.

Another example of objection without cogent reason, based literally upon ignorance.

Objection without cogent reason, based litterly upon ignorance, is absolute nonsense.

Many such applications exist, and many manufacturers provide such applications on devices, therefore many users of those devices have them. Few if any users have become absurd and irrational over this, according to apparently you alone, dangerous functionality, that in reality is not in any way dangerous at all to anyone.

And when implemented, users that require to do so will be able to switch of the device the even easier way of on screen in application without unnecessary resort to hardware buttons and unnecessary wear and tear thereon, hardware buttons incidentally required to be used nowhere else in GCC, a touch screen application.

This in much the same way manufacturers felt the necessity to provide ability to shutdown on screen, and other applications have implemented also.

There is no new option. There is a new feature switched by an existing option. As with any feature it is there for users that require it. This particular feature is also there to enable GPS Cycle Computer to become a standalone application that is not dependent on external programs, or external hardware buttons, and to enable GPS Cycle Computer running on a device to actually allow that device to become a dedicated GPS Cycle Computer, the underlying Operating System unseen to the end user if booting straight in to GPS Cycle Computer, or via application selection menu. As with any other dedicated device. It is also useful to users generally.

'And you have to tap again' is the same reason buttons should not be auto hidden as at present, but auto hide after a short interval, after first accessing map screen. If a user is unable to await auto hide after 10 seconds after first accessing map screen or last usage of buttons, tap elsewhere removes from display as at present.

This should be left as is, as addresed below.

Thus the issue reported is resolved using software engineering standard practice.

Nontheless:

As these necessary options provide seperate functionality for users that require them, they should remain.

As this necessary option allows users to select whether they wish their buttons to auto hide, it should remain and not auto hide.

As that is the entire purpose of the functionality for users that require it, it should remain.

Ability to select any waypoint and remove it would be useful. Whilst on the subject of waypoints, presumably a user adding a waypoint wants a visible waypoint instead of an invisible waypoint, thus interlock of 'add waypoint to t2f' with 'show waypoints' if not selected could be implemented, so the waypoint added can actually be seen. If such a user exists that does not want to see the waypoints they are creating, and will not be able to select for removal as they are invisible, they can switch waypoint display off.

Definitely. Data sets already take this in to account, as should similarly this functionality.

My view is that it is most pleasing indeed WolWer has raised T2F issues when not logging, and that in turn has highlighted the other data set update issues when not logging. As these all look set to be addressed, this can now be crossed of the list. It is one less needless battle against objection without cogent reason to be endured had I proposed it. WolWer clearly has this in hand, so with thanks, unless anything further is needed, over to you WolWer with regards to any implementation, testing and remedial work aspects.

I look forward to your future feedback with interest, as with that of all users that take the time to positively contribute.

Further information to be added.

low.flying.pigs