Enhancer Software OS3

[wawa]

i dont recall that the problems with netsurf were reaction based last time i tried. rather it still didnt render correctly the pages and was crashy. a mui g ui woild be better choice anyway, as it would be easily portable between the amigaoid systems.

[matthey]

Originally Posted by wawa

i dont recall that the problems with netsurf were reaction based last time i tried. rather it still didnt render correctly the pages and was crashy.

Chris was forced to make changes for the AmigaOS 3 because of the frbuttonclass not rendering in the bottom border with GA_RelBottom (probably a bug in a parent class which is in the intuition.library). Datatypes are also BOOPSI objects (part of the GUI) and the inadequacies of the picture.datatype have forced him to make major changes to the code. Instead of using AmigaOS components we end up with 3rd party components which add dependencies and have their own bugs to deal with. I may be able to debug his "crashy" problems and optimize NetSurf as well but do we end up with anything worthwhile in the end? The 68k AmigaOS and Reaction are dead end without development and support. Other people force us to waste our development time and add multiple levels of difficulty to our development. As with my bogus amiga.org ban by an NG zealot, where I am not wanted I leave and find other people and places where I am not blocked but free to develop and state my mind.

Originally Posted by wawa

a mui gui would be better choice anyway, as it would be easily portable between the amigaoid systems.

Portability is not so much the problem as most Amiga flavors have basic BOOPSI support which provides the upper object classes. Perhaps Reaction would have problems on little endian systems but it takes very careful programming to support both big and little endian without reducing performance. It is the lack of source code and control which would make it unacceptable to most flavors.

The GUI choice and elements should be evaluated based on the goals. From A-EON's perspective, Reaction is available to them and they want to encourage AmigaOS 4 software development. It would not be easy nor is it wise to switch the standard GUI without good reason. MUI 3 is more mature than the AmigaOS 3 Reaction which is missing important functionality and classes which AmigaOS 4 has added. MUI is easier to develop for and has nice features but this adds more overhead which may not be wanted, especially on low end or embedded systems. Perhaps the GUI should even be evaluated for how well a cell phone or tablet could be supported. The 68k is a different market that can be scaled down very small while CISC provides good performance (can be stronger per core than ARM). IMO, it has great potential in the embedded market where business partners could help reduce hardware costs for the Amiga. When I was looking for embedded interest with the Apollo core, I was asked "What about the OS?". What can I say? The AmigaOS is a legal nightmare and the owners don't want to sell it? Only the Amiga makes it impossible .

[kolla]

Originally Posted by matthey

MUI is prevalent enough that porting Zune back to AmigaOS and including it with the AmigaOS could be good.

I am pretty confident that Zune was already running on AmigaOS, was it not part of the AfA package or something?

[Michael]

As far as my memory serves me right, OS 3.5/9 ReAction sources were not available to developers of OS4, so mot work was done from scratch or based on older ClassAction.
Even more interesting is the fact that newer ReAction classes were available in 68k forms and work fine on the classic systems, so backporting is not a BIG question, if it was a goal, it could be done fairly quickly imho. Sadly it was not before, maybe that's exactly what it is happening now. But definitely, reinventing things every few years is a big disappointment and humbles progress. But I would support it anyway, it is still progress and we need it.

[wawa]

Originally Posted by kolla

I am pretty confident that Zune was already running on AmigaOS, was it not part of the AfA package or something?

yes, it was. although it was a much, much earlier version, from well before 68k platform became maintained and zune could be crosstested with genuinee 68k appc. the current one should be much more compatible. especially the genuinely available third party classes binariess are compatible with it. however there are apps that will still refuse to work. one of them is ibrowse, it actually runs fine and the gui is working, but it doest display pages.

[matthey]

Originally Posted by Michael

As far as my memory serves me right, OS 3.5/9 ReAction sources were not available to developers of OS4, so mot work was done from scratch or based on older ClassAction.

Right. Matthew of amigakit.com verified this earlier in the thread.

Originally Posted by amigakit.com

ReAction/ClassAct on OS3 is no longer developed, the source code is not available and has fallen behind a long way from the OS4 ReAction. So from that perspective, the OS3 ReAction it is a dead-end.

AmigaOS 4 used the same API so I don't understand why the same code base can't be synced up and used. Start with the AmigaOS 4 code base, carefully remove features and functionality which doesn't work in AmigaOS 3 (with #if most likely) but ignore methods which can't be supported yet and add the missing features and functionality from AmigaOS 3.9. The #if statements are ugly but at least there are only 2 variations and then work to add the missing functionality to AmigaOS 3 (mostly intuition.library and input.device from a quick glance). The best sync of the code base would require 68k AmigaOS development. It is possible to have high level code like this have few differences between the PPC AmigaOS 4 version and the 68k AmigaOS 3 version. It is not clear whether A-EON is doing a quick and dirty port of their software to AmigaOS 3 or laying a foundation and planning for a future on the 68k AmigaOS. The visible GUI can look fine (which it does) while the source code and design is a disaster.

[wawa]

Originally Posted by matthey

AmigaOS 4 used the same API so I don't understand why the same code base can't be synced up and used.

because the "company" behind os4 doesnt want to share their code to support amiga. as if you wouldnt know.. aeon has likely no influence on it. it also doesnt look like they are going to fill in that gap. they are simply developing their own third party software which takes advantage of their own third party classes. so far i dont see that much from them that would be interesting to acquire. and im out of my adolescence age just to support some effort based on promises.

[matthey]

Originally Posted by wawa

because the "company" behind os4 doesnt want to share their code to support amiga. as if you wouldnt know.. aeon has likely no influence on it.

A-EON likely has some influence, if they exert it, but that is not the same as control (which they may have). Hyperion would be wise to listen to their sugar daddy A-EON. I doubt Hyperion's cash burn rate has changed much since their financial issues and most of the bailout money likely went to debt. They introduced AmigaOS 4 FE at a big discount from previous versions but the small niche market requires high prices for profitability. Even if AmigaOS 4 came out with 100% compatible SMP, >8GB of memory supported and MP tomorrow, the sales would likely remain in the low thousands with the expectation of a cheaper price like AmigaOS 4 FE. Most 68k customers aren't going to upgrade to PPC because of the high prices of hardware and these features are not priorities for most 68k users. The marketing philosophy and market dynamics have not changed so I don't why anyone would expect a different result. Hyperion will likely continue to require cash infusions to stay alive but the situation looks hopeless to me without major change. Maybe A-EON will take more control the next time Hyperion needs money.

One business partner writes code which would improve the other business partner's product with new classes for Reaction in AmigaOS 4. The other business partner has the source code for Reaction which the first business partner needs for a product in a market the first business partner chooses not to compete. I don't understand why AmigaOS 4 doesn't end up with the new Reaction classes in AmigaOS 4 and A-EON with the AmigaOS 4 Reaction source code for AmigaOS 3? If Hyperion is still blocking other Amiga markets including from the hand that feeds them when their own market is unsustainable, how trustworthy of a business partner are they? Are they also being trusted to deliver AmigaOS 4 with 100% compatible SMP, >8GB of memory support and MP to attempt to save both partners?

[amigakit.com]

I am pleased to announce that the new tickbox gadget is now ported to OS3 from OS4 and a few cosmetic adjustments have been made for OS3. Tickbox gadget class will feature on the forthcoming Enhancer Software for OS3.

In the screen shots below you can see the tickbox.gadget in action with the old OS3.9 checkbox gadget also shown for reference:



InfoWindowClass has now been updated to no longer use checkbox but use the new tickbox gadget class:

[Pyromania]

Nice updates.

[Cylon]

I don't like the new check mark very much. It misses the curvy 'swing'.

[wawa]

something like this should be skinable with some reasonable default. usually a reasonable replacement would exactly default to whats being replaced, except it being somehow legally reserved, which in case of a checkmark image isnt very likely.

personally i dont care one way or another. i dont have any particular preference on this issue either. this remark is just meant as a proposal, not any kind of demand or request.

[amigakit.com]

The main thing was to ensure it was working - including when disabled and with hotkey support and left/right text label justification.

All of this is working and we can refine the actual tick image so that it is scalable too.

Themeing and antialiasing is something that is important but the latter needs to have special consideration for low colour screenmodes found on Classic systems.

[wawa]

my impression was that reaction supports themeing. also the themeing format is rather similar to one employed by aros, at least when it comes to basics, like windows and screen bar. from my experience with aros, you can use low color iff images as well as full color pngs. when using one, two or three plane skin iffs the penalty shouldnt be considerable even on amiga chipset display. the problem begins, when people expect some blurred full color imagery to be equivalent of graphical quality.

[kolla]

So what functional advantage does "tickbox" have over "checkbox"? Will this become yet another thing people desperately will attempt to hack&patch in the quest for consistant look

[ExiE]

Originally Posted by kolla

So what functional advantage does "tickbox" have over "checkbox"? Will this become yet another thing people desperately will attempt to hack&patch in the quest for consistant look

maybe you can also tickle new box not just check it

[amigakit.com]

Another update this weekend to the OS3 version of tickbox.gadget

The tick image has been reworked and also a new tag has been added TICKBOX_Cross for developers who want to display a cross in the gadget box for their applications.



@kolla

I think the new tickbox gadget looks a lot better than the original OS3.9 version and it has functionally new X cross feature. As the OS4 version of tickbox.gadget develops, so can the OS3 version at the same pace.

[ExiE]

Originally Posted by amigakit.com

The tick image has been reworked and also a new tag has been added TICKBOX_Cross for developers who want to display a cross in the gadget box for their applications.

I think the new tickbox gadget looks a lot better than the original OS3.9 version and it has functionally new X cross feature. As the OS4 version of tickbox.gadget develops, so can the OS3 version at the same pace.

?

[amigakit.com]

New Select Gadget work nearly completed for Enhancer Software OS3:

[amigakit.com]

I am pleased to report that the new skinnable Clock utility from the latest Enhancer Software v1.1 on OS4.1 has now been ported to AmigaOS 3.9 for inclusion in the forthcoming Enhancer Software OS3 release. It uses the new clock.gadget which has also been ported.

Here are some pics of it running on my Amiga 1200: