What's the difference between the paid version & the freeware version?

@ChrisH
Quote:
In this release (now SDK Browser v2.1.1.0) the only real difference between the
FREEWARE version and the Registered version is that the Registered version has additional
menu actions for, and closer interaction with AVD's other components (should they be
present), and you also get a personalized version, with your name and email displayed
in the "About" and version output.

Other than that, the FREEWARE version contains all of the same primary features
as the registered version to date.

Going forward however, that is where they part ways:

* All newly registered owners (or upgraded existing owners), will continue to
receive additional features and enhancements to the existing functionality
through to v3.0.0.0, as free updates.

* The SDK Browser v2.1.x.x FREEWARE version will maintain the features it
has today, and only receive maintenance updates (bug fixes or OS API
updates to stay current with new releases of AmigaOS4).

So basically, registered owners will shortly be getting new features, while
the FREEWARE release will remain available "as is" for general use.

Best Regards,
Jamie Krueger
BITbyBIT Software Group LLC

@JamieKrueger

Quote:
The AVD menus take up quite a lot of screen estate: I can't help feeling that GUI clarity is sacrificed here in favour of program integration. I suggest that the AVD menus only get displayed if AVD is actually installed and present. For sure there will be people who prefer running the SDK Browser alongside another development suite such as CodeBench: in such a case, there's no point in cluttering the menu strip with greyed-out blocks that won't be used at all.

The PUBSCREEN shell argument and PUBSCREEN tooltype don't work. Is this intentional or is it a bug? The sdkbrowser program isn't very useful if I can't open it on my programming screen.

EDIT: DISREGARD the above complaint.
Sorry. I forgot that sdkbrowser is a commodity and was already running when I tried a different PUBSCREEN tooltype/argument.

@Trixie,
Quote:
Hi Trixie,

Yes, I agree with exactly what you are talking about here.
In fact I was trying to figure out exactly how to dynamically
hide those menus when the other AVD components are not present,
or even not running (in time for the release), but decided not
to risk adding that before the v2.1.0.0 release.

I can easily make a build for Registered owners that
hide the "unused" menus permanently, allowing it to
run more like the Stand Alone version. However, the
actual solution is to allow the menus to be there
when needed (or wanted), and not when not needed.

This will take a little bit more work, but can be done.
I will add it to the list for the v2.2.0.0 release
(to registered owners only), which should be too long.

In the mean time, if you want a "stand alone" version
of the registered users, which drops those "unused"
menu actions, I can make that available as a parallel
download fairly quickly. Just let me know.

Best Regards,

Jamie Krueger
BITbyBIT Software Group LLC

@xenic,
Quote:
No problem,

I designed the SDK Browser to "hide" itself by default, rather than actually
quit; so that it would be available instantly and avoid having to rescan the
SDK each time you start it.

Therefore, the SDK Browser will "hide" when the Close Window button is hit,
you hit the "ESC" key (by default), or use the Commodity exchange to ask it
to hide the interface.

Equally it will bring up the already loaded copy, when you hit the "F1" key
(by default), use the Commodity exchange to ask the interface to show itself,
and even try to launch the program again from the icon.

The SDK Browser is only unloaded from memory (so that a new copy can be run),
when you use the "Quit SDK BROWSER" menu action. This can be a little confusing
at first, and I have caught myself doing the same thing before. I have changed
the Tooltypes on the Icon, ran it again without realizing it was already loaded,
and wondered why it did not pick up the change.

However, once you understand that the SDK Browser is working to save you time
by staying in memory, I believe the benefits far out weight any initial confusion.

Now, as an addition tip that may help you, you can also set the screen that
the SDK Browser will attempt to open up on when started, by using the "Move to public
screen" menu action under the "View" menu. This will bring up a selection window,
for you to pick the screen to move to right away. Then, once it has made the
move, you can use "Save settings" to have it remember the change.

Saved settings (as loaded from ENVARC:BITbyBIT/...) act as the "defaults" to be
used when the program is opened, and the Tooltypes are considered the same as
active command line options, and should take priority over those settings.

This means that setting the public screen value via the saved preference file,
can still be over written by the PUBSCREEN option in the Tooltypes or when
supplied on the command line.

Best Regards,
Jamie Krueger
BITbyBIT Software Group LLC