AmigaOS 3.2 released!

[Tigerskunk]

Anyone who knows a good online tutorial for reaction UI coding?

[gulliver]

For those who are looking for an easy to follow C programming tutorial whith some ReAction examples go to:

http://www.pjhutchison.org/tutorial/amiga_c.html

[falken]

Will a digital version purchase option be planned?

[Magic]

Originally Posted by gulliver

For those who are looking for an easy to follow C programming tutorial whith some ReAction examples go to:

http://www.pjhutchison.org/tutorial/amiga_c.html

Thank you for taking the time to post this.

[Tigerskunk]

Originally Posted by gulliver

For those who are looking for an easy to follow C programming tutorial whith some ReAction examples go to:

http://www.pjhutchison.org/tutorial/amiga_c.html

Nice, thanks...

Will see if I can get something going in Reaction, when 3.2 arrives...

[walkero]

I would like to invite you all on a live presentation of AmigaOS 3.2 this Saturday 22nd of May, at 6pm CET (5pm GMT+1) on https://www.twitch.tv/walkerogr/schedule . On my aid, Mr. Ignacio Gully will co-host, who is part of the development team which gave us AmigaOS 3.2.

Together we will show you the new awesome features of AmigaOS 3.2, the installation process and will answer your questions. Come join us and let’s celebrate this new release.

[Pyromania]

This sounds like a nice event.

[Predseda]

Great, looking forward!

[boemann]

Originally Posted by saimo

Q5 - Context-sensitive pointer
If one changes/removes Pointer.prefs to disable the dynamic changing of the pointer, does Intuition keep on checking what the pointer is hovering on?

Not if you change pointer.prefs no, but there is a checkbox in icontrol prefs that allows you to turn off the checking. This affects both scroll wheel and pointer dynamically changing, as well as tooltips

However even 3.1 would check what is hovered, and the code have been optimized, so it doesn't spend needless cycles checking if you are not moving the mouse or moving it fast It is in on average more efficient than 3.1

Originally Posted by saimo

Q8 - DefIcons
Has the core engine been improved and how?

Q10 - icon.library
Is icon.library new and how does it compare to this replacement library?

These two tie together as icon.library now has a tag so you can ask the filetype of a file. The actual detection is served by deficons.

And as far as i know PeterKs icon lib already implements these new tags too

[saimo]

Originally Posted by boemann

Not if you change pointer.prefs no, but there is a checkbox in icontrol prefs that allows you to turn off the checking. This affects both scroll wheel and pointer dynamically changing, as well as tooltips

However even 3.1 would check what is hovered, and the code have been optimized, so it doesn't spend needless cycles checking if you are not moving the mouse or moving it fast It is in on average more efficient than 3.1

Thank you for the explanation!

These two tie together as icon.library now has a tag so you can ask the filetype of a file. The actual detection is served by deficons.
And as far as i know PeterKs icon lib already implements these new tags too

How does it work, exactly? Something like this, perhaps?
1. A program wants to know the type of a file;
2. the program opens the file icon with icon.library;
3. the program asks icon.library to check the type;
4. icon.library asks DefIcons;
5. icon.library provides the answer.

Or this?
1. A program wants to know the type of a file;
2. the program opens the file icon with icon.library;
3. icon.library asks DefIcons;
4. icon.library provides the answer through the diskobject structure.

Or some other way?

[boemann]

Originally Posted by saimo

How does it work, exactly? Something like this, perhaps?

program calls like this:

buf[0] = 0;
GetIconTags(filename,
ICONGETA_IdentifyOnly, TRUE,
ICONGETA_IdentifyBuffer, buf, TAG_DONE);


iconlib forwards it to deficons, which answers back and iconlib returns

[saimo]

Originally Posted by boemann

program calls like this:

buf[0] = 0;
GetIconTags(filename,
ICONGETA_IdentifyOnly, TRUE,
ICONGETA_IdentifyBuffer, buf, TAG_DONE);


iconlib forwards it to deficons, which answers back and iconlib returns

OK, so that's conceptually the same as my first guess, but (thankfully) done in a more comfortable way.
However, I wonder: why going through icon.library at all? The type of a file is not relative to its icon (if it even exists). Is DefIcons' API public, so that it can be used directly, instead of going through icon.library? Unless there are reasons I'm missing, file type detection code doesn't belong to icon.library.

[boemann]

Originally Posted by saimo

OK, so that's conceptually the same as my first guess, but (thankfully) done in a more comfortable way.
However, I wonder: why going through icon.library at all? The type of a file is not relative to its icon (if it even exists). Is DefIcons' API public, so that it can be used directly, instead of going through icon.library? Unless there are reasons I'm missing, file type detection code doesn't belong to icon.library.

I don't think we have made it public no.

Anyway the reason is that this is the way OS4 does it, and if at all possible we try to be api compatible

[saimo]

Originally Posted by boemann

I don't think we have made it public no.

Anyway the reason is that this is the way OS4 does it, and if at all possible we try to be api compatible

Your choice is fully understandable and commendable.

EDIT: It's a pity that what seems a bad design choice needs to be followed, though. The way I see it (but then again, I don't have the full picture, so I might be missing something here), the engine that recognizes the file types should be external to both DefIcons and icon.library, and DefIcons and any other applications should rely on it, while icon.library shouldn't know anything about file types.

[boemann]

Originally Posted by saimo

Your choice is fully understandable and commendable.

EDIT: It's a pity that what seems a bad design choice needs to be followed, though. The way I see it (but then again, I don't have the full picture, so I might be missing something here), the engine that recognizes the file types should be external to both DefIcons and icon.library, and DefIcons and any other applications should rely on it, while icon.library shouldn't know anything about file types.

Deficons is that engine - it is all it does - it provides the type. When icon lib finds a default icon it asks deficons for the type and the loads the corresponding icon from envarc:sys

So it is actually rather logical that only getting the type without actually loading the icon goes through the same code. And it allows us to reimplement deficon which we actually might do in the future. We didn't reimplement it this time around but have a wish to make a somewhat simpler system in the future. Here it comes in handy that the engine is shielded behind icon.library api

[saimo]

@boemann

Let me clarify that I'm aswering just for the sake of abstract conversation and, why not, providing food for thought, not because I want to force any change.

Originally Posted by boemann

Deficons is that engine - it is all it does - it provides the type. When icon lib finds a default icon it asks deficons for the type and the loads the corresponding icon from envarc:sys

Can you see the mix-up in your own words? The purpose of DefIcons is providing the default icons (hence its name), as you you say in the second part, not providing the file types, as you say in the first part.

DefIcons was born as a tool that identifies the type of files that don't come with icons and assigns them virtual icons according to its findings and to the relevant default icons. It was a great extension to the Workbench and still today does its job nicely. When it was born (and, as far as I know, still today), there was no file type recognition engine, so DefIcons implemented its own (so, congratulations to its author). This worked and still works well, but I'm underlying a design problem: one thing is recognizing the file types, another is assigning iconless files virtual icons. Design-wise, asking a component that assigns virtual icons about the type of files is "misusing" the component itself; it's done only because, due to necessity, the component happens to implement the file recognition logic; going through yet another component that is unrelated to file types makes the design even worse.
More simply, this is what we have today:

applications <-> icon.library <-> DefIcons <-> files

A theoretical clean design would be:

applications <-> engine <-> DefIcons
                   |
                   V
                 files

So it is actually rather logical that only getting the type without actually loading the icon goes through the same code.

I absolutely agree that it should be possible to get the file type without having to fiddle with icons (that's why I'm saying icon.library shouldn't be involved at all). And, yes, it's logical to go through the same code - see above

And it allows us to reimplement deficon which we actually might do in the future. We didn't reimplement it this time around but have a wish to make a somewhat simpler system in the future. Here it comes in handy that the engine is shielded behind icon.library api

I'm glad to hear you're thinking of working on these aspects on the OS. I hope the idea of providing an API external to the icon.library will be taken into consideration, to avoid that icon.library bloats over time to carry out a task that doesn't belong to it (and, yes, I do understand that the current design is due to AmigaOS 4.0).

[boemann]

Originally Posted by saimo

@boemann
Can you see the mix-up in your own words? The purpose of DefIcons is providing the default icons (hence its name), as you you say in the second part, not providing the file types, as you say in the first part.

You are misunderstang what deficons does - it does provide the type as a string

It is icon.library that then opens the corresponding icon.

Yes the name deficons might suggest it returns the actual icon but it doesn't

it does however know what icon files are available, and if the type doesn't have an icon it returns the name of the parent type (recursively), but it is still only a type name

[PeterK]

Originally Posted by boemann

Deficons is that engine - it is all it does - it provides the type. When icon lib finds a default icon it asks deficons for the type and the loads the corresponding icon from envarc:sys

There is a "GlobalIdentifyHook" for icon.library as defined in the autodocs under IconControlA(). In the past this hook function was called by icon.library whenever it could not find an icon for a file and a tag "ICONGETA_FailIfUnavailable"=FALSE was supplied by the calling task.

On the other side, this hook is used by DefIcons and Eastern, which are trying to identify the file and then return a ready to use DiskObject structure to icon.library. No, - at this point - icon.library has not to load an icon from ENV:sys anymore.

Usually, DefIcons identifies the type of a file and makes another call to icon.library for the corresponding icon in Envarc:sys already before it returns the result to the hook.

Eastern tries to identify pictures only, generates thumbnail images for new empty DiskObjects, and sends both for assembly to icon.library also before it returns the picture preview icons back to the hook.

The new "IdentifyBuffer" and "IdentifyOnly" tags can be forwarded now by icon.library to the hook, no matter whether the file already has an icon or not. Icon.library never returns any strings. The "IdentifyBuffer" for the string is created by the calling task, forwarded to the hook and filled by DefIcons.

But unlike the new DefIcons tool the old Eastern has no support for these tags yet. Eastern must examine the file first to identify pictures and supply preview icons instead of deficons. Thus, it only passes the hook data to DefIcons for other files than pictures, and it won't forward these two new tags otherwise. (Maybe, I will try to write a fix for Eastern ?)

Edit: I didn't read the posts #237 and #238 before starting to write my comment. Yes, I also think that passing the file type identification through icon.library is not the optimal solution, but I'm no OS developer, don't want to criticize or decide that. I'm just trying to support these new features.

I don't own OS 3.2 yet, but I've written a small test program to check this new file type identification:

[khayoz]

Let's pirate copy the f**k out of this release and send an envelope(snailmail)
with money to Thomas and Olaf(so they can split out the money to all the devs!)
instead of feeding more ca$h into court bills!

Don't forget where the money's at! Right here AMIGA community!

[BippyM]

Don't be so ridiculous.

Originally Posted by khayoz

Let's pirate copy the f**k out of this release and send an envelope(snailmail)
with money to Thomas and Olaf(so they can split out the money to all the devs!)
instead of feeding more ca$h into court bills!

Don't forget where the money's at! Right here AMIGA community!