icon.library 46.4 test versions

[PeterK]

Hello AGS,
please try out my new attempt to make the direct drawing to accept the BORDERLESS option without changing the the behaviour of the WB drawing.

If it still shifts the images by one pixel then please use my supplied ColorFile.info instead of your File.info and send me a screenshot. Thx.

BTW, if you set BORDERLESS to TRUE then you don't need to set FRAMELESS anymore.

[AGS]

The shift is now gone, see shot, thank you. Btw, it has happened not only with my icons, but with any icon.

[PeterK]

Nice GUI

Stupid question: is it possible to drag the icon images away from their default position ? Or how do you avoid that ?

Please test the direct drawing mode also with DOpus Magellan. I can NOT make any changes there, because I will never get the info whether an icon is borderless or not.

[AGS]

I have no dopus magellan. Using GetDiskObject and DrawIconStateA is like reading and drawing an Image. These 'icons' cannot be moved.

ps: I use _LVOGetIconTagList, not GetDiskObject

[PeterK]

Alright, good to know that these images are locked.

Since you are using a lot of TagLists for generating your GUIs I would recommend to install my TagLiFE patch for the utility.library.

http://aminet.net/package/util/boot/TagLiFE

[Michael]

The current version 46.4.330 (or any recent ones) has a non standard behaviour.
Boot without start-up, LoadWB (no prefs or anything, default 4 colour mode)
All icons are missing borders. This is wrong. The default behaviour should be with borders.
And it should take into account icons that have the border off switch on, and display them without the border, and only them. Otherwise all classic and MWB icons are broken (they are supposed to be with borders)

On a fully loaded system the behaviour is correct.

One more question (Direct Drawing), is it supposed to write directly to screen ?
If so why in 15/16/24/32 bit screens we still suffer from free pens issues as if we are running in 256c mode ? Or I have missed something important?

[PeterK]

...All icons are missing borders. This is wrong. The default behaviour should be with borders.

There are two shell commands coming with the Aminet release in the c drawer: IconFramesON and IconFramesOFF. (I don't like these ugly frames to be enabled by default)

...why in 15/16/24/32 bit screens we still suffer from free pens ?

Because unfortunately, the colormapping is still required or some applications won't see any icon images.

[AGS]

I do not use utility.library for parsing tags at all. This is almost all what i use (and it is a bit customized for some tricks I do):

get_a_tag	move.l	(a2)+,d0
		beq.b	.rts
		move.l	(a2)+,d1
		cmp.l	#3,d0		; return anything that is bigger 3
		bgt.b	.rts

		; system tags

		cmp.l	#TAG_IGNORE,d0
		beq.b	get_a_tag
		cmp.l	#TAG_MORE,d0
		beq.b	.more
		cmp.l	#TAG_SKIP,d0
		beq.b	.skip
.rts		rts
.skip		lsl.l	#3,d1
		add.l	d1,a2
		bra.b	get_a_tag
.more		move.l	d1,a2
		bra.b	get_a_tag

[amigasith]

First of all, THANK YOU so much for your icon.library, PeterK It is really the best piece of speed-up software that I have applied to my lovely A1200. If the following is too OT for you, please tell me so and I will post my stuff wherever you point me to.

Recently, I have been playing around with the latest workbench.library (45.132, here: http://eab.abime.net/showthread.php?t=67560), since I was looking for a tool /OS hack that allows for smooth scrolling of a workbench windows's contents when dragging the slide bar at the bottom of the window. I am using OS 3.1 with NewIcons & FreshIcons and a bunch of patches (CardPatch, CMQ030, BlazeWCP, FBlit & FText, SetPatch 43.6b).

workbench.library 45.132 (probably also earlier 44+ versions) enables smooth scrolling, but I observed something that seems a bit odd to me - maybe it's just normal, I have no clue. You seem to be the right guy to know

After booting, my chip mem stays at almost 1900KB. However, as soon as I open a workbench window, chip mem drops down to around 1620KB and stays there. I think it doesn't have to do anything with your icon.library, since opening windows with loads of icons doesn't let the chip mem go down further - it stays at 1620KB. So this tells me that icon.library nicely makes use of fast ram. But why is there this huge drop in chip mem? If I use the 3.1 ROM built-in version of workbench.library, there is no drop. Chip mem stays solid at around 1900KB.

In order to have more chip mem available, I experimented with WBAllocFast, and it works nicely from a free chip mem perspective - chip mem stays solid at around 1900KB. However, I get corrupted icons as soon as I click on them De-selecting the garbled icon (for example by clicking in the background) returns the icon display back to normal.

What I'd like to have is workbench.library 45.132 with as much chip mem as possible (1900KB) and no garbled icons - do you have any idea how to achieve this?

Thanks for looking

[PeterK]

Originally Posted by amigasith

workbench.library 44+ versions enable smooth scrolling, but ...
After booting, my chip mem stays at almost 1900KB. However, as soon as I open a workbench window, chip mem drops down ...

However, I get corrupted icons as soon as I click on them ....

Ok, please copy this FBlit.cfg file into ENVARC: (it's for the wblib v44+) and copy IconsToFastMem into C: and call it before LoadWB.

[Michael]

Originally Posted by PeterK

There are two shell commands coming with the Aminet release in the c drawer: IconFramesON and IconFramesOFF. (I don't like these ugly frames to be enabled by default)

I know, and funny enough I don't use them, since WBprefs do it anyway.
My WB settings are set to large border size. All GlowIcons that need no borders have the flag set to remove borders.

And your lib follows this rules without problems, and I like it.

But when we boot without prefs, why you choose to have all icons without borders ? And you can't force the border on the icon.
This is doing the job non default way (system way).

And when you have the system loaded properly, there is no problem to set the settings in WBprefs as you prefer (without borders) without the use of external commands. So there is yours preferred defaults there.

So the problem is only default behaviour without prefs, it should be the same as system.

Please rethink it. Or maybe (really maybe, since I am not keen on this)
analyse the sys: prefs/envarc/workbench.prefs setting if iPrefs was not run.

PS: also think about the poor people with low powered machines,
they will be using classic icons like MWB with borders on.
And booting into WB without setting for quick fixes or running something in low mem situations.

[Don_Adan]

Originally Posted by AGS

I do not use utility.library for parsing tags at all. This is almost all what i use (and it is a bit customized for some tricks I do):

get_a_tag    move.l    (a2)+,d0
        beq.b    .rts
        move.l    (a2)+,d1
        cmp.l    #3,d0        ; return anything that is bigger 3
        bgt.b    .rts
 
        ; system tags
 
        cmp.l    #TAG_IGNORE,d0
        beq.b    get_a_tag
        cmp.l    #TAG_MORE,d0
        beq.b    .more
        cmp.l    #TAG_SKIP,d0
        beq.b    .skip
.rts        rts
.skip        lsl.l    #3,d1
        add.l    d1,a2
        bra.b    get_a_tag
.more        move.l    d1,a2
        bra.b    get_a_tag

A few (?) offtopic, but why you don't use subq.l, but you use 4 times cmp.l, after some modifications this loop will be much fastest, of course if d0 is scratch here. Similar one branch to move.l D1,A2 is enough, if you place .more after .skip label.

Something like this version:

TAG_DONE    EQU    0  ; terminates array of TagItems. ti_Data unused
TAG_IGNORE    EQU    1  ; ignore this item, not end of array
TAG_MORE    EQU    2  ; ti_Data is pointer to another array of TagItems
              ; note that this tag terminates the current array
TAG_SKIP    EQU    3  ; skip this and the next ti_Data items

; ----    user tag identification -----------------------
TAG_USER    EQU    $80000000  ; differentiates user tags from system tags

get_a_tag     ; for inline version
   subq.l    #4,A2
tag_ignore
   addq.l    #4,A2
get_a_tag     ; for bsr version
   move.l    (A2)+,D0
   beq.b    .rts
.loop
   subq.l    #3,D0
   bhi.b    .rts3
   bne.b    .notagskip
   move.l     (A2)+,D0
   lsl.l    #3,D0
   add.l    D0,A2
   move.l    (A2)+,D0
   bne.b    .loop
.rts
   rts

.rts3
    addq.l #3,D0
    rts

.notagskip
   addq.l    #1,D0
   bne.b    tag_ignore
   move.l  (A2),A2
   move.l    (A2)+,D0
   bne.b    .loop
   rts

[amigasith]

Thanks, PeterK, IT WORKS Awesome!

After having a close look at the FBlit.cfg you attached to this thread, I figured out that you basically applied the same changes you described here (http://eab.abime.net/showpost.php?p=...&postcount=602), plus a few more. I also found that the "Official AmigaOS 3.9 FAQ" suggests changing the same FBlit properties that you suggested in the above thread in order to save chip mem. I should have googled a bit better before

- Do you have an idea why those changes are required? I am just curious...

- In the FBlit.cfg that you attached to this thread, you did a few changes on top of the 3 mentioned in the above linked post (for example the "Chip Data Options" for FBltPattern from "Pass On Complex" to "Pass On"). Are those changes also for improving workbench.library chip mem consumption or are those for other fixes? Again, I am just trying to understand

Cheers

[PeterK]

Originally Posted by amigasith

Thanks, PeterK, IT WORKS Awesome!

... for example the "Chip Data Options" for FBltPattern from "Pass On Complex" to "Pass On". Are those changes also for improving workbench.library chip mem consumption or are those for other fixes?

Didn't even notice that there are changes like this one in my config.

Now, I made two new FBlit configs - as an example - by using the internal FBlit settings for the basic configuration. Therefore, I first deleted the FBlit.cfg files from ENVARC: and from ENV:, then started FBlitGUI and added the task "Workbench" to the include list. Such a config should be used for the WB v39 or v40.

In the second config I disabled AddBobPatch and RemIBobPatch and enable QBSBlitPatch instead for the WB v44+.

Please read the FBlit.guide, chapter "Usage" and "The Patches" for the correct settings.

No guarantee that the attached FBlit.cfg files are the best settings for your or any other system. Read the FBlit documentation, please.

[PeterK]

Originally Posted by Michael

I know, and funny enough I don't use them, since WBprefs do it anyway.
....And booting into WB without setting for quick fixes or running something in low mem situations.

How the h*ll are you booting into WB in such a situation ??
Booting without the startup-sequence just runs into the shell prompt.
And for low mem cases you would need a cold start in order to remove the resident libs from memory, but then your system will boot with WB v40. And that will use frames ON by default anyway.

However, you can still call IconFramesON after booting the WB, and then reset WB from tools menu.

Most important, the majority of the OS 3.5+ users don't want frames to be enabled by default.

[Michael]

Originally Posted by PeterK

How the h*ll are you booting into WB in such a situation ??
Booting without the startup-sequence just runs into the shell prompt.
And for low mem cases you would need a cold start in order to remove the resident libs from memory, but then your system will boot with WB v40. And that will use frames ON by default anyway.

However, you can still call IconFramesON after booting the WB, and then reset WB from tools menu.

Most important, the majority of the OS 3.5+ users don't want frames to be enabled by default.

Sometimes you have to boot without startup, and LoadWB from shell,
sine the complete system might have problems to boot properly.

Yes, OS3.5+ users will prefer frames off (but only for Glow/NewIcons), but it's an environment variable that they have to set just once and forget it.

"And that will use frames ON by default anyway." - well, that's what I am asking for! Because at the moment it does not, or does?! See next post

[Michael]

Here are 3 shots.
1. Loaded without anything, just LoadWB
I guess we fall back to the rom icon.lib, terrible!
But the borders are on everywhere, and OS3.5 icons are missing
AmigaOS4PPC icon I guess must have a classic icon encoded for 4c

2. SetPatch, Env: and LoadWB
All looks nice, but borders missing everywhere

3. Same as 2 + BorderON
All icons that should have borders get them.
This matches more the default system way.

Actually, I am lost now as to what is better for majority, maybe a pole ?

Also wondering now, can we have an option to replace the big dot
icon with a remapped 4c version of proper icon ?
eg. a command that disables default behaviour of stripping the classic image and placing the 4c version of the proper icon there. That will
make them a bit more useful on systems without icon.lib 46 ?

[gulliver]

Just to add my 2 cents to the subject:

I personally would prefer if this new icon.library follows the same behaviour as the old original one with borders on by default.

I agree with PeterK that on 3.5/3.9 borderless icons look better, but on the other side, I must admit that both MagicWB and standart 2.x/3.1 icons look better with borders, and that is default behaviour even on 3.9.

I feel that backwards compatibility regarding behaviour is important, but then it s just me

[PeterK]

Originally Posted by Michael

Here are 3 shots.
1. Loaded without anything, just LoadWB
I guess we fall back to the rom icon.lib, terrible!
But the borders are on everywhere, and OS3.5 icons are missing
AmigaOS4PPC icon I guess must have a classic icon encoded for 4c

2. SetPatch, Env: and LoadWB
All looks nice, but borders missing everywhere

Also wondering now, can we have .... a command that disables default behaviour of stripping the classic image and placing the 4c version of the proper icon there ?

Case 1.) Makes no sense at all.

Case 2.) Copy my attached Boot script into C: and start it without your s-s instead of typing several commands. Looks best IMO.

No sorry, generating 4c images would take too much time and needs a lot more space. Everybody can still do that with IconEdit (put the colored pixel into the lower right corner of the selected image to avoid the size trimming).

@gulliver
Thanks for your 2 cents, I appreciate your advice, but I don't need any money Did you have a problem yet?

[Bamiga2002]

Originally Posted by gulliver

Just to add my 2 cents to the subject:

I personally would prefer if this new icon.library follows the same behaviour as the old original one with borders on by default.

I agree with PeterK that on 3.5/3.9 borderless icons look better, but on the other side, I must admit that both MagicWB and standart 2.x/3.1 icons look better with borders, and that is default behaviour even on 3.9.

I feel that backwards compatibility regarding behaviour is important, but then it s just me

+1
keep the original behaviour as default