icon.library 46.4 test versions

[midwan]

Originally Posted by pipper

[mention]midwan [/mention] I recently fixed a drag’n’drop issue with DOpus that would leave corrupted images behind:

https://github.com/mheyer32/dopus5al...b06d1212d01dd0

Maybe that’s what you’re experiencing

That sounds quite possible, thanks.

[PeterK]

Originally Posted by midwan

- If you drag an icon on top of an open Shell window, the icon image stays there forever afterwards. Is this a known issue?

Thanks for the feedback! Yes, I've noticed something similar already when I dragged an icon onto the window frame and partially over the border that some parts of the image stay remaining there after moving the icon back into the window ..., but that did also happen without my fix for the memory leak. Edit: Hmm, no this seems to depend on my fix; I can't reproduce this issue with the original 5.82 atm.

@pipper
That's good news to hear that you are still trying to improve DOpus5 for OS 3.x. I didn't know about your github project page. Maybe you can integrate my changes with AddVSprite() and RemVSprite() into your code and compile an update together with your own improvements.

Edit: The main problem with AddBob() for the custom dragging was the wrong usage of width (pixels per line) in the VSprite structure instead of words per row, as explained in the comment of the include files. Using width in AddBob() causes P96 to call AllocBitMap() and AllocVec() with a 16 times too large sizex value. And furthermore there was never a RemBob() or RemIBob() call for custom dragging from Dopus, so all these huge useless memblocks were lost. My first attempt to fix this bug was to reduce the value of width in the VSprite structure to words/row immediately before AddBob() and then set it back to width after the call, because Dopus wants to work with width (pixels). This already reduced the memory consumption by P96 to the correct value, but the RemBob() was still missing. Unfortunately, RemBob() has no effect without a following DrawGList(), which has never happened (never reported by LibSnooper). And everything I tried with RemIBob() just caused freezes, although I used the same parameters again as in AddBob() before. Maybe, you can find a better solution with Dopus using words/row instead of width for custom dragging.

[PeterK]

Removed 46.4.535: Dopus 5.83 still has some dragging bugs.

[pipper]

@PeterK Pull Requests are very welcome :-)

A quick search reveals, this is the only place where the sprite width is set:

https://github.com/mheyer32/dopus5al...routines.c#L99

drag->sprite.Width=(drag->flags&DRAGF_CUSTOM)?drag->width:word_width;

It makes a distinction between the custom drag routines and the regular ones. The regular dragging routines use word_width.

[PeterK]

Yes, I've seen that line in the code, and the usage of width is definitely a bug, but it's strange, because nothing goes wrong with CGX4, it only causes a problem with P96. The author already mentioned these problems with P96 in the list of changes or history of Dopus in a comment from 1997 (sorry, cant find it now).

And indeed, I also made a late mistake in my patched code in Dopus 5.83, which is responsible for the sticky images of the dragged icons now, as reported by midwan. I must have introduced that bug in one of the last hours and changes before I released 5.83 here, but I'm not in the right mood to fix it today, maybe tomorrow or the next days.

It seems that you are working on 5.9x code and not on 5.82 anymore like me, right?

[pipper]

I took the code from https://sourceforge.net/projects/dopus5allamigas/ and ported it into a git repository along with all history. So yeah, this is 5.9x based.

[PeterK]

Just found this on that sourceforce site:
https://sourceforge.net/p/dopus5allamigas/bugs/58/

The memory leak is fixed in my patch, but unfortunately I've added a new bug somewhere around RemVSprite() ...

[PeterK]

Uploaded 46.4.535 and a fixed Dopus 5.83 again:

The RemVSprite() call was done too early. Now, it's called after DrawDragList(), but immediately before FreeDragInfo() is executed. I hope that fixes the bug in my patched Dopus 5.83. Please don't hesitate to report any remaining issues. Thx! No changes in the icon.library code since build 535.

[pipper]

@PeterK where do you maintain your fork of DOpus? Maybe I can steal a patch or two from there :-)

[PeterK]

Where? At home ... ... no, in fact, I have never ever compiled the DOpus5 C source code, I don't like any dev kits. It's just an in-place assembler patch for two subroutines, but I've added some short comments in backdrop_drag.c where you have to change the code to insert AddVSprite() for the custom dragging instead of AddBob() and where RemVSprite(). And I've created my own new drag flag: DRAGF_CUSTOM_VSPRITE, bit 31.

[midwan]

@PeterK

This new version seems to be working as expected now! Great job, thanks!

It would be great if we could integrate these fixes in the v5.9x codebase as well.

[AMIGASYSTEM]

Originally Posted by PeterK

Sorry, didn't notice your Assign from ENV: back to ENVARC:, but not sure if that is a good idea under all circumstances.

Thanks for the xadmaster.library.

Peter if in the Videos you run from FFPlay you are bothered by the GUI, in the Toltype icon add the parameter:

GUI=0

All "Play, Pause, Forward, Back" commands are available from Keyboard

On AROS 68k the Arexx commands do not work from the Icon, also to activate start to "WB" or "CLI" you have to add them in the Tooltypes

[PeterK]

Originally Posted by midwan

It would be great if we could integrate these fixes in the v5.9x codebase as well.

I'm not sure what the latest development status of v5.9x is. It seems that nothing important has happened since the release of 5.91 for OS 3.x many years ago and I don't know who is maintaining the support now. Is there still somebody working on DOpus5?

The memory leak exists in 5.91 too, which I just downloaded, although I don't want to use it. Nevertheless, it should be no problem to patch also 5.91 in the same way as I did it for 5.82.

Maybe pipper can port my fix to the latest C source and compile that, because I don't want to install a C development environment for Dopus and bother with the compiler stuff.


@AMIGASYSTEM
Yeah, it would be great to see Arexx working on Aros 68k, but whenever I tried to start RexxMast it just crashes the system. Do you know any trick to let it work. Or does it need aros.hunk.gz to be installed?

[AMIGASYSTEM]

On Aros 68k only the Arexx scripts do not work from the icon, but the Arexx port works.

To make the Arexx Port work on AROS 69k you need these files:

- RexxMast OS3.x (They all seem to be the same as OS 2.1, 3.0, 3.1, 3.5 and 3.9, but 3.9 seems to work better)
- rexxsyslib_44.2.library (seems to be equal to rexxsyslib_44.1.library OS3.9)

[midwan]

@PeterK
I think I found one more, minor glitch. This one is unrelated to DOpus, but has to do with the latest library version only.

When using 51.4.535 (TC020) + DoNoColorMapping, the icons seem to lose the "shadow" effect they had. Switching back to 51.4.533 (TC020) (with or without DoNoColorMapping) resolves this.

I'm attaching a screenshot to better demonstrate what I mean.

[Weaselrama]

Originally Posted by midwan

@PeterK
I think I found one more, minor glitch. This one is unrelated to DOpus, but has to do with the latest library version only.

When using 51.4.535 (TC020) + DoNoColorMapping, the icons seem to lose the "shadow" effect they had. Switching back to 51.4.533 (TC020) (with or without DoNoColorMapping) resolves this.

I'm attaching a screenshot to better demonstrate what I mean.

Yeah - when I first used the new TC020 (.531? or was it .532?) it cleaned up all the Mason and Mason-like 4.1 iconsets I use. I probably didn't notice it was a shadow effect - but it worked miracles. The drawers in that series lost their jaggedness and I was able to display them against lighter or darker backgrounds. Looking forward to the new release, Peter.

[PeterK]

Originally Posted by midwan

@PeterK
I think I found one more, minor glitch. This one is unrelated to DOpus, but has to do with the latest library version only.

When using 51.4.535 (TC020) + DoNoColorMapping, the icons seem to lose the "shadow" effect they had. Switching back to 51.4.533 (TC020) (with or without DoNoColorMapping) resolves this.

I'm attaching a screenshot to better demonstrate what I mean.

Yes, I know that, it's a side-effect of the tighter image masking, which activates full transparency against the background already for Alpha values below 60 or even 75 with HoldTCbuffer1. This is done to cut off the ugly gray borders around the dragged icons in the custom dragging mode, which otherwise can be quite thick when the alpha channel blending is very soft. The custom dragging routines are not able to handle the alpha channel, but are simply masking the images based on the background color that would normally only exist for alpha values of zero. Drag some OS4 icons with 533 and the custom dragging and you will see what I mean.

If you don't use HoldTCbuffer1 as recommended then the unselected icons will be displayed with the shadow effect only when a drawer is opened and they are drawn from TCbuffer1 one-time. Any further redrawing is done by uncompressing the unselected images again without using that buffer. And on that way I've added the transparency masking for low alpha values, because the selected image can only use that way for DOnoColorMapping and the custom dragging routines. Unfortunately, I have no information in that piece of code whether it's the 1. or the 2. image. So I decided to make the masking not too tight as long as HoldTCbuffer1 is not used.

But when HoldTCbuffer1 is enabled the unselected images should always preserve their soft alpha blending shadows, because they don't pass the same code as the selected or dragged icon images. And HoldTCbuffer1 makes loading and dragging a bit faster, too.

Never use DOnoColorMapping without enabling the custom dragging routines in DOpus5, because this option is just doing what it pretends to do. You may just see nothing during the normal mode dragging.

@Weaselrama
I think you are talking about the difference between the 020 typical simple transparency and the support of real alpha channel blending with soft borders in the TC020 version, but that's not the effect that Midwan mentions, just the opposite.

[midwan]

Thanks for the detailed explanation!

[Weaselrama]

Originally Posted by PeterK

@Weaselrama
I think you are talking about the difference between the 020 typical simple transparency and the support of real alpha channel blending with soft borders in the TC020 version, but that's not the effect that Midwan mentions, just the opposite.

Ok, thanks for the info.

[pipper]

Originally Posted by PeterK

I'm not sure what the latest development status of v5.9x is. It seems that nothing important has happened since the release of 5.91 for OS 3.x many years ago and I don't know who is maintaining the support now. Is there still somebody working on DOpus5?

The memory leak exists in 5.91 too, which I just downloaded, although I don't want to use it. Nevertheless, it should be no problem to patch also 5.91 in the same way as I did it for 5.82.

Maybe pipper can port my fix to the latest C source and compile that, because I don't want to install a C development environment for Dopus and bother with the compiler stuff.


@AMIGASYSTEM
Yeah, it would be great to see Arexx working on Aros 68k, but whenever I tried to start RexxMast it just crashes the system. Do you know any trick to let it work. Or does it need aros.hunk.gz to be installed?

I would try that, but I don’t have a record of what your patches are (that’s why I asked about your repository).
WRT building DOpus: don’t be afraid. This is super easy, download Bebbo’s toolchain, let it build itself, download DOpus, let it built and off you go.