Welcome, Guest. Please login or register.

Author Topic: Os 3.2 development preview  (Read 135017 times)

Description:

0 Members and 2 Guests are viewing this topic.

Offline wiser3

  • Jr. Member
  • **
  • Join Date: Jan 2007
  • Posts: 84
    • Show only replies by wiser3
    • http://www.trep4.com/
Re: Os 3.2 development preview
« Reply #59 on: August 31, 2019, 04:20:01 PM »
@Matt_H
So it is a long road ahead. But I am sure we can probably solve this quite easily (and this is my own speculation here), just by installing as default, gadtools based prefs, tools and utilities and ask in the Installer script if the user wants to ReActionize its installation, with all that it implies and if agreed then overwrite existing prefs, tools and utilities with ReAction based counterparts.

Having two systems = BLOAT. Not the Amiga way of doing things. Stick with GadTools/BOOPSI.
 

Online kolla

Re: Os 3.2 development preview
« Reply #60 on: August 31, 2019, 04:42:47 PM »
Stick with GadTools/BOOPSI.

You still haven't grasped that Reaction is little more than a bundle of BOOPSI classes, and exactly what you say you want?
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Online kolla

Re: Os 3.2 development preview
« Reply #61 on: August 31, 2019, 05:03:35 PM »
Well, the choice is simple in the transitional OS release between the two GUI Toolkits.
Why limit it to two - everyone got preferences, and it should be easy to "plug in" GUIs from any Toolkit.

Quote
After that, we will surely need to find a comfortable maintenance strategy that either implies dropping support for one GUI Toolkit or creating a common code base upon which we could easily maintain both simultaneously (which is certainly not the easiest path to follow).
It could be, if it was implemented differently. Remember Miami? It had ClassAct/Reaction GUI, it had MUI GUI, it had GadTools GUI (gtlayout), and it was also quite possible to run it without any GUI. The way to do this is to abstract the GUI away from the actual functionality of the program, and instead create clean and simple to use APIs that GUI writers can use to make a GUI using whatever toolkit they wish.
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline Matt_H

Re: Os 3.2 development preview
« Reply #62 on: August 31, 2019, 06:21:49 PM »
Stick with GadTools/BOOPSI.

You still haven't grasped that Reaction is little more than a bundle of BOOPSI classes, and exactly what you say you want?

I'm learning that for the first time in this thread, but I think there is still a bit of a difference between bundling classes with the OS to make them available for developers/users of other applications, and switching over the system utilities to require them (if the concern I raised in a previous post can't be addressed).

But it seems like the team is aware of the complexity of the situation, so I'm glad they're giving it some thought.
 

Offline TribbleSmasher

Re: Os 3.2 development preview
« Reply #63 on: August 31, 2019, 06:26:04 PM »
I think the GUI should be usable with ROM-only toolkits. Prefs can always be made later with Reaction/MUI/Feelin or else, as long as informations on the filetypes used are provided. It is IFF after all, and interchangability requires knowledge of the format, obviously.
 

Offline kamelito

Re: Os 3.2 development preview
« Reply #64 on: August 31, 2019, 09:07:09 PM »
Are you following the directions taken by CBM for the OS? any performances improvements in the pipe? I guess that since the 89/90 better algorithms exist that can be applied a bit like what you’ve done with intuition but I think also about gfx lib and exec.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #65 on: August 31, 2019, 11:05:11 PM »
Are you following the directions taken by CBM for the OS?
Had CBM directions? There were probably multiple plans by multiple persons.... RTG was a plan, but it didn't went quite far. Instead, external developments became popular. Will any of that go into the kickstart? I don't know, but not too soon because that is a lot of work.

any performances improvements in the pipe?
Not much. Dos buffered I/O should have improved a lot (FRead,FWrite), and it is used by the icon.library, so there are possibly some performance improvements in that respect. Whether it is measurable i do not know. Dos is the next dragon I'm slaying (after graphics), refactoring System-Startup out of dos was one of the results, also writing shells became simpler (we had like 3 methods how a shell could be launched before, see "shell internals" on aminet. It's down to one now).


I guess that since the 89/90 better algorithms exist that can be applied a bit like what you’ve done with intuition but I think also about gfx lib and exec.
Exec doesn't have much. There are memory pools that could benefit from improvement. Unfortunately, there are programs that expect exactly the layout they have today, so no chance. There could be a memory scratch list for small allocations, but as graphics became smarter, memory fragmentation lowered as well, so the problem is not as high as it used to be. There is nothing major for graphics in the pipeline. Maybe some improvements are coming for intuition, but this is still too early to say what else goes into it. The problem is that we cannot really make too much dependent on intuition as CGfx is entangled with intuition V40 in an unfortunate way.


 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #66 on: August 31, 2019, 11:06:35 PM »
Having two systems = BLOAT. Not the Amiga way of doing things. Stick with GadTools/BOOPSI.
All of this is open at this point, really. There is no hidden agenda. We will see how we move along, and decide on the man power available.
 

Online kolla

Re: Os 3.2 development preview
« Reply #67 on: September 01, 2019, 05:08:21 AM »
I think the GUI should be usable with ROM-only toolkits.
If content of SYS:Classes was moved to SYS:Libs, I bet you wouldn't even know...
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC
---
A3000/060CSPPC+CVPPC/128MB + 256MB BigRAM/Deneb USB
A4000/CS060/Mediator4000Di/Voodoo5/128MB
A1200/Blz1260/IndyAGA/192MB
A1200/Blz1260/64MB
A1200/Blz1230III/32MB
A1200/ACA1221
A600/V600v2/Subway USB
A600/Apollo630/32MB
A600/A6095
CD32/SX32/32MB/Plipbox
CD32/TF328
A500/V500v2
A500/MTec520
CDTV
MiSTer, MiST, FleaFPGAs and original Minimig
Peg1, SAM440 and Mac minis with MorphOS
 

Offline bubbob42

Re: Os 3.2 development preview
« Reply #68 on: September 01, 2019, 07:43:12 AM »
Hm, if the pic shows the real preferences, than it looks like one can add own 'variables/numbers' to the WB screen title, as the 'update' suggests...  ???

I would just use some static text and set the update frequency to "0".
Please have "0" effectively shut the system off and save resources.

That’s a good suggestion; I‘ll consider it. Note that you‘ll lose display of available memory, if you activate such an option. It‘ll also become a challenge regarding the WorkbenchPrefs, since I‘ll have to make it very clear for the user that any wildcards embedded in the current custom Workbench title will cease working, then. D‘oh.
 

guest11527

  • Guest
Re: Os 3.2 development preview
« Reply #69 on: September 01, 2019, 07:51:04 AM »
I would just use some static text and set the update frequency to "0".
Please have "0" effectively shut the system off and save resources.

That’s a good suggestion; I‘ll consider it. Note that you‘ll lose display of available memory, if you activate such an option. It‘ll also become a challenge regarding the WorkbenchPrefs, since I‘ll have to make it very clear for the user that any wildcards embedded in the current custom Workbench title will cease working, then. D‘oh.
That doesn't really save much. The workbench title update is part of the same logic that regularly polls the drives for disk changes, by default every 5 seconds. The title update is traditionally made along with the drive update, and the title update is quite minor compared to the latter.
 

Offline bubbob42

Re: Os 3.2 development preview
« Reply #70 on: September 01, 2019, 08:15:31 AM »
True, but the title parser has become quite large in the meantime. That’s why I’m moving „once per boot“-stuff like version wildcards into workbench‘s initialisation code right now. The title parser was originally written with PPCs in mind, not 7MHz 68k.
 

Offline kamelito

Re: Os 3.2 development preview
« Reply #71 on: September 01, 2019, 09:22:50 AM »
@Thomas Richter
I din’t Think it is a good idea to have intuition limitated b/c CGX is not evolving anymore. CGX users should use an old intuition and P96 should move forward. I guess you do not have time to see how CGX work to feed it with what it  expect to make it work. Any pointers so someone else can have a look?
 

Offline bubbob42

Re: Os 3.2 development preview
« Reply #72 on: September 01, 2019, 10:04:58 AM »
silently pressing the hotkey with the label “ask Frank Mariak”   ;)
 

Offline kamelito

Re: Os 3.2 development preview
« Reply #73 on: September 01, 2019, 10:55:29 AM »
I think it was stated in another thread by Gulliver that Frank will not help.
 

Offline bubbob42

Re: Os 3.2 development preview
« Reply #74 from previous page: September 01, 2019, 12:05:11 PM »
I think it was stated in another thread by Gulliver that Frank will not help.

Maybe he will if enough CGX users would ask him politely.