Oh no! Where's the JavaScript?
Your Web browser does not have JavaScript enabled or does not support JavaScript. Please enable JavaScript on your Web browser to properly view this Web site, or upgrade to a Web browser that does support JavaScript.

Icon Tools

Last updated on 7 days ago
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 11 months ago
Nothing has changed, now even the folders are not replaced, see attached video.

Perhaps this is a problem that only affects DualPNGs?
M
miker1264Software Dev
Posted 11 months ago
AMIGASYSTEM

In your first video you said that the def icons weren't displaying correctly. That was fixed.

Now the second video shows the icon images aren't changing which is a different problem. But you say nothing has changed. It's good that you included the second video because I would still be trying to guess what you mean by nothing has changed. I'll correct the icon exchange also.
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 11 months ago
Thank you miker and sorry to pester you with my reports!
M
miker1264Software Dev
Posted 11 months ago
AMIGASYSTEM

It's no problem. It's good that you provide the videos because otherwise I wouldn't understand the issues. Pfft

Try this newer version of IconDrop v1.02
Hopefully this one works better. Does it work with the newest C library system files that deadwood provided for testing recently?
miker1264 attached the following file:
icondrop_12-28-23i386-aros.zip [67.41kB / 150 Downloads]
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 11 months ago
Now the problem is below the base, see screenshot, strange yesterday with the new core the previous version worked be, now again the problem, what causes it?
AMIGASYSTEM attached the following image:
icondrop.jpg
M
miker1264Software Dev
Posted 11 months ago
It's caused by the coordinates for EraseRectangle being a few pixels off in the y axis because the height of the window titlebar varies. I could shorten the height of rectangle. That way it won't erase the entire display area. There will be a margin of a few pixels on top and bottom. That will keep it from erasing the border.

The coordinates for GadTools gadgets are a major pain. For example if you want to describe an x-y coordinate for the top left corner of a box it would look like this: x = (winwidth - leftoffset -winrightborder - deltasize - 2). Y= ( wintopborder - topoffset - winbottomborder -6) / 2. That's just craziness! No wonder MUI/Zune forgoes coords.
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 11 months ago
Sorry miker, why don't you remove the small box (see screenshot) it shouldn't be ugly, so I think it solves all the problems
Praticamente ho eliminato il riquadro piccolo e centrato la linea !

With the drawing programme, it was easy Smile
AMIGASYSTEM attached the following image:
icondrop_1.jpg
M
miker1264Software Dev
Posted 11 months ago
AMIGASYSTEM

Although removing the two smaller display areas might be an elegant solution to the display issue it isn't that easy. The display areas are both Raised Bevel Boxes that also represent the bounding rectangles of the Drop Zones. We could replace them with simple black boxes but the top or bottom would still get erased. We need to find a better solution for this problem.
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 11 months ago
OK, thanks for the information, there is always something to learn.
M
miker1264Software Dev
Posted 11 months ago
The bounding rectangles for the Display Areas aka Drop Zones correspond to two other functions called InRectangleLeft & InRectangleRight. The entire window is a Drop Zones. You can do a drag-n-drop anywhere in theory. But how do we distinguish between left and right? How do we know if the user dropped a "normal" image or "selected" image?

The InRectangle functions use the x,y mouse coords during the drop operation to calculate if the drop falls inside or outside the bounding box. The border around the Display Areas are only a visual reference for the user to drop files within the correct Drop Zones. Removing the borders of the Display Areas would cause issues with drag-n-drop operations. We don't want that. Smile

So I came up with a better solution. I was using the Graphics Library function "EraseRectangle" which uses complex coordinates to replace a specified rectangle in the rasterport with colors of the background which essentially erases it. We have to Erase Rectangle before Display Image or there may be artifacts left from the previous image.

I wanted to use Display_Blank function to generate a new blank image filled with (255,153,153,153) background color. Then I could draw that in each Display Area before Display Image. It had some issues but it works now. I tested it with several different themes and so far it works great. I realized it needed to be 78x78 instead of the same size as a real image. So I changed the function name to Erase_Rectangle. Pfft
M
miker1264Software Dev
Posted 11 months ago
AMIGASYSTEM

Here is the newest IconDrop binary and source code. It has the new Erase_Rectangle function. I tested it with several different images and using several different window themes of different sizes as far as height of window titlebar.

I also attached some screenshots of IconDrop. This one is a new version 1.02 so if it works well it will replace version 1.01 on AROS Archives. This is the release candidate.

I noticed some display issues with the Ice Theme. But IconDrop isn't the only one. Some Zune Applications also have display issues with the Ice Theme. Maybe Ice Theme needs fixed?

The WaterColor Cubic Themes and WaterColor Diagonal Themes work fine at Screen Text Sizes 13,15,16. VMWaros4 and OS41 Themes are also working well with IconDrop. Or rather IconDrop works well with these themes.
Edited by miker1264 on 29-12-2023 13:02, 11 months ago
miker1264 attached the following file:
icondrop_testing.zip [771.16kB / 134 Downloads]
icondrop_12-28-23_x86-aros.zip [67.33kB / 150 Downloads]
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 11 months ago
I'll keep my fingers crossed and test, both on AROS One 2.3 and AROS One 2.4 (C Library) Smile
The ICE Theme seems to work fine for me, some of my themes are derived from ICE, on which Zune application have you experienced problems
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 11 months ago
Done the test, now it works perfectly with all "your Themes", with the ICE Theme and all the ones I created based on it have a problem on the left side, I think the themes found on Aros archive also have the same problem, on many of them I created my own themes.

I need to check what's different

Made a screenshot showing the problem, to see it well I used Palette Prefs to lighten the background of the grey GUIs !
AMIGASYSTEM attached the following image:
test_4.jpg
M
miker1264Software Dev
Posted 11 months ago

AMIGASYSTEM wrote:

@AMIGASYSTEM - Done the test, now it works perfectly with all "your Themes", with the ICE Theme and all the ones I created based on it have a problem on the left side, I think the themes found on Aros archive also have the same problem, on many of them I created my own themes.

I need to check what's different

Made a screenshot showing the problem, to see it well I used Palette Prefs to lighten the background of the grey GUIs !


Thanks for testing. Did you test it on AROS One 2.3 and 2.4 (C lib) ? Or just 2.3. I'd like to know if it works with the newest system files for 2.4.

I've identified the scaling issue with the Ice and it's derived themes. The issue happens when the window border thickness is more than 5. Such as with the Ice Theme it's actually 10. I'm working on a solution by recalculating all the offsets.

The scaling issue is a problem with the IcoDrop display coordinates not a problem with themes.
Edited by miker1264 on 29-12-2023 15:58, 11 months ago
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 11 months ago
Yes I have tested with both 2.3 and 2.4, the results are the same, the screenshot I did with 2.4 (C lib)
M
miker1264Software Dev
Posted 11 months ago
After doing some further testing with the Ice Theme and those derived from it with window border thickness of 10 I noticed a few things.

For whatever reason if the window border has a thickness greater than five there are distortions both vertical and horizontal. This graphics issue seems to be an internal AROS issue maybe with the Window Decoration?

In the screenshot you can see the original distorted IconDrop user interface at the top. After I added some correction factors the enhanced IconDrop user interface in on the bottom left. Notice also the bottom button of ScreenGrabber.
The Zune user interface is also distorted.

I'm not sure why this is happening. For example if my IconDrop window while using Ice Theme with screen font Arial 16 is supposed to be 231 it is actually drawn as 227. So it is 4 pixels short. Something similar happens to window height. It is drawn shorter than it really is. When you query Window width in this case it reports width = 231.

This window layout issue that corrupts the graphics for the right side and bottom side may be related to the window theme scroller gadgets on the right and bottom that are drawn wrong.
Edited by miker1264 on 30-12-2023 19:02, 11 months ago
miker1264 attached the following image:
icondrop_ice_theme3_sm.png
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 11 months ago
In fact, it seems that by increasing the window border by 10, instead of growing and advancing outwards, it does so inwards, but only from the left side!

I don't know if this is a clue, Amiga OS 3.1 seems to have border 5, whereas OS 3.9 has a much larger border!

At the moment it can be solved by correcting all configurations and fixing the border at 5 (even just the left border)
M
miker1264Software Dev
Posted 11 months ago

AMIGASYSTEM wrote:

@AMIGASYSTEM - In fact, it seems that by increasing the window border by 10, instead of growing and advancing outwards, it does so inwards, but only from the left side!

I don't know if this is a clue, Amiga OS 3.1 seems to have border 5, whereas OS 3.9 has a much larger border!

At the moment it can be solved by correcting all configurations and fixing the border at 5 (even just the left border)


I'm not sure how the increased border thickness affects other programs but for IconDrop and other icon tools I have an easy workaround. If border thickness > 5 then factor = (thickness / 2) and if factor > 0 then winw += factor. I have to also apply the correction factor to the x-offsets for the display areas to center the icon images.

I don't mind using workarounds in the short run but eventually the correct solution should be to identify and fix the issue(s) in Intuition Library. You shouldn't need to change any window themes if it doesn't affect other programs. The newest version of IconDrop will be posted.
Edited by miker1264 on 31-12-2023 13:14, 11 months ago
M
miker1264Software Dev
Posted 11 months ago
After much testing I concluded that the windows were being drawn correctly depending on which theme is currently being used. My program offsets needed to be adjusted to display correctly.

The program now works as expected with window themes with different border thickness.

Here is the revised IconDrop program and source code. The code is still a bit messy.
miker1264 attached the following file:
icondropx86_12-30-23.zip [67.89kB / 144 Downloads]
miker1264 attached the following image:
icondrop_window_offsets2_sm.png
AMIGASYSTEMAMIGASYSTEMDistro Maintainer
Posted 11 months ago
Perfect miker, IconDrop works very well, the New Year has started well Smile
AMIGASYSTEM attached the following image:
icondrop_2.jpg
You can view all discussion threads in this forum.
You cannot start a new discussion thread in this forum.
You cannot reply in this discussion thread.
You cannot start on a poll in this forum.
You cannot upload attachments in this forum.
You can download attachments in this forum.
Moderator: Administrator
Users who participated in discussion: amigamia, deadwood, AMIGASYSTEM, pixie, Amiwell79, miker1264, OlafSch, mattson62
Sign In
Not a member yet? Click here to register.
Forgot Password?
Users Online Now
Guests Online 4
Members Online 0

Total Members: 268
Newest Member: ajfa
Member Polls
Should AROSWorld continue with AROS-Exec files (SMF based)?
Yes44 %
44% [12 Votes]
No26 %
26% [7 Votes]
Not sure30 %
30% [8 Votes]