Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#45 closed enhancement (fixed)

File lists with icons

Reported by: Mikhail Malyshev Owned by: Thore Böckelmann
Priority: normal Milestone: 3.9-2014R2
Component: Dirlist.mui Version: 3.9-2014R1
Severity: minor Keywords:
Cc: OS Platform: AmigaOS3
Blocked By: Blocking:
Release Notes:

Description

Should the icons have a transparent background ?

Attachments (7)

MUI-1-transparent-icons.png (69.4 KB) - added by Mikhail Malyshev 6 years ago.
def_drawer.info (1.8 KB) - added by Mikhail Malyshev 6 years ago.
example icon (OS3.5+ format)
MUI39N-images.png (84.0 KB) - added by Mikhail Malyshev 6 years ago.
Background fill problems
mui-log.txt (45.5 KB) - added by Mikhail Malyshev 6 years ago.
debug log
Dirlist_dbg.lha (33.3 KB) - added by Thore Böckelmann 6 years ago.
debug version of Dirlist.mui
mui-log2.txt (5.9 KB) - added by Mikhail Malyshev 6 years ago.
new log
lister-24bit.png (51.6 KB) - added by Mikhail Malyshev 6 years ago.

Download all attachments as: .zip

Change History (40)

Changed 6 years ago by Mikhail Malyshev

Attachment: MUI-1-transparent-icons.png added

comment:1 Changed 6 years ago by Thore Böckelmann

Component: undefinedDirlist.mui
Milestone: MUI 3.9-2014R2
Priority: undecidednormal
Status: newaccepted

Please provide one of these icons for testing purposes. If the images don't define a transparent area themself then there is nothing that could be done against that.

Changed 6 years ago by Mikhail Malyshev

Attachment: def_drawer.info added

example icon (OS3.5+ format)

comment:2 Changed 6 years ago by Mikhail Malyshev

Icon added

comment:3 Changed 6 years ago by Thore Böckelmann

For me the icon is displayed as a tiny black square. Usually my AmiKit installation can display all kinds of icons.

comment:4 Changed 6 years ago by Mikhail Malyshev

I guess you do not have 3.5+ icon support enabled, so you get the fallback dot image.

Install this ultimate OS 3.x icon library
http://aminet.net/util/libs/IconLib_46.4.lha

comment:5 Changed 6 years ago by Thore Böckelmann

In 3622:

  • Dirlist.c: merged some changes from MUI4. This refs #45.

comment:6 Changed 6 years ago by Thore Böckelmann

What kind of screenmode are you using? 8bit or 24bit?

comment:7 Changed 6 years ago by Mikhail Malyshev

Usually 16-bit

comment:8 Changed 6 years ago by Thore Böckelmann

Hm, I tried that icon.library myself and disabled all patches from AfA and for me the icon is shown properly with correct transparency. Did you try the latest nightly build already?

comment:9 Changed 6 years ago by Mikhail Malyshev

Yes, same story. But got some more ideas!
It looks like the transparent colour of the icon is not filtered.
Because icons with different transparent/background colour have different backgrounds. Image attached.

Changed 6 years ago by Mikhail Malyshev

Attachment: MUI39N-images.png added

Background fill problems

comment:10 Changed 6 years ago by Mikhail Malyshev

Small update….
No icons displayed in 256c or less modes!
Only 16/24/32 bit screens partially work (without transparency).

comment:11 Changed 6 years ago by Thore Böckelmann

Please try the debug version of Dirlist.mui. Set ENV:muidebug to "image" before starting the very first MUI application and then try to reproduce the wrong background. Finally attach the captured debug log to this ticket. This will reveal how the icons are loaded.

Changed 6 years ago by Mikhail Malyshev

Attachment: mui-log.txt added

debug log

comment:12 Changed 6 years ago by Thore Böckelmann

In 3640:

  • Dirlist.c: added some more debug output. This refs #45.

comment:13 Changed 6 years ago by Thore Böckelmann

From the debug log I can only see that Dirlist.mui preloaded some standard icons. But the indiviual icons from your screenshot (i.e. Tools, Trashcan) are never loaded. Did you really let Dirlist.mui load that directory?

Changed 6 years ago by Thore Böckelmann

Attachment: Dirlist_dbg.lha added

debug version of Dirlist.mui

Changed 6 years ago by Mikhail Malyshev

Attachment: mui-log2.txt added

new log

comment:14 Changed 6 years ago by Mikhail Malyshev

This one has even less details (IMHO)

comment:15 Changed 6 years ago by Thore Böckelmann

Obviously all your icons are PNG icons, because datatypes.library is able to load them successfully before icon.library even gets a chance, or you have a datatype for icons installed. And also very obviously your PNG datatype does not handle transparency or the alpha channel correctly. This is a quite common problem with AmigaOS3.

comment:16 Changed 6 years ago by Mikhail Malyshev

No PNG, and you have a sample, it's 3.5+ format.
Datatype for icons installed. TRUE
What PNG datatypes work then?
And obviously it should not effect the icons, since none are in PNG format.

comment:17 Changed 6 years ago by Thore Böckelmann

Then you have a datatype for icons installed. Otherwise this output would be impossible:

24	Dirlist.mui  CreateThumbnail  : trying to load 'C.info' by datatypes.library
25	Dirlist.mui  CreateThumbnail  : successfully loaded 'C.info' by datatypes.library
26	Dirlist.mui  CreateThumbnail  : trying to load 'Classes.info' by datatypes.library
27	Dirlist.mui  CreateThumbnail  : successfully loaded 'Classes.info' by datatypes.library
28	Dirlist.mui  CreateThumbnail  : trying to load 'Devs.info' by datatypes.library
29	Dirlist.mui  CreateThumbnail  : successfully loaded 'Devs.info' by datatypes.library
30	Dirlist.mui  CreateThumbnail  : trying to load 'Docs.info' by datatypes.library
31	Dirlist.mui  CreateThumbnail  : successfully loaded 'Docs.info' by datatypes.library

comment:18 Changed 6 years ago by Mikhail Malyshev

Nuked icon.datatype out of interest, and indeed the icons are displayed correct then.
This means that the loading mechanism has wrong priority, since it starts from datatypes and not direct icon.lib loading.
The previous log showed that icons were somewhat way connected to icon.lib, but in the update, only dataypes.lib is used.

Tried some png files, if you add .info to them they are transparent, otherwise they have purple backgounds.
So what's the secret in PNG, which DT works?

comment:19 in reply to:  18 Changed 6 years ago by Thore Böckelmann

Owner: set to Thore Böckelmann
Status: acceptedassigned

Replying to Michael:

Nuked icon.datatype out of interest, and indeed the icons are displayed correct then.

Well, I told you…

This means that the loading mechanism has wrong priority, since it starts from datatypes and not direct icon.lib loading.

No it is not wrong. The icon datatype does its work correctly, but it fails to provide a mask bitmap to make the icon image transparent. Even worse, it fills the background with an arbitrary color.

On the other hand there are PNG icons which can be loaded by a suitable PNG datatype and with full 8bit transparency instead of just a 1bit mask. That's why these icons should be handled directly by the datatypes system instead of icon.library.

Tried some png files, if you add .info to them they are transparent, otherwise they have purple backgounds.

That's the typical issue with AmigaOS3's picture.datatype which is not able to return the alpha channel data to an application.

So what's the secret in PNG, which DT works?

I am using the akPNG datatype together with the enhanced picture.datatype of AfAOS which is able to return the alpha channel to the application.

I will add a workaround to Dirlist.mui to skip loading of icons by datatypes.library if a certain ENV variable is set. Please note that the transparency will not be exactly what you might expect due to the 1bit transparency mask that icon.library will set up for you.

comment:20 Changed 6 years ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed

In 3652:

  • Dirlist.c: added a workaround for systems which have a datatype for icons installed. In case the icon.datatype loads the icon ahead of icon.library then the thumbnail icons will have no transparent background due to the way how icon.datatype renders the bitmap. Set ENV:MUI/Dirlist-Dirlist-NoIconDT to 1 to skip icon loading by datatypes.library. Please note that this will also disable direct loading of PNG icons by datatypes.library because these cannot be told apart ahead of loading them. This closes #45 again.

comment:21 Changed 6 years ago by Mikhail Malyshev

Nice, something for the yet empty FAQ page ;-)

Then again that brought me an idea of adding an extra prefs items (at the bottom of the list) to MUI prefs. Something like Tweaks. And there we can have all the odd options to tick, like icon handling functions, and maybe an option for selecting the type of image browser, colour selection windows (new style, or old style) This will improve compatibility and close a few issues. Obviously if someone enables the old 3.8/3.9(2005) style requesters they can be limited in function compared to the modern ones. But that's the user option, and MUI was always keen on options and configuration ;) So please give it a thought.

comment:22 in reply to:  21 Changed 6 years ago by Thore Böckelmann

Replying to Michael:

Then again that brought me an idea of adding an extra prefs items (at the bottom of the list) to MUI prefs. Something like Tweaks. And there we can have all the odd options to tick,

That sounds like a reasonable idea. Perhaps you should open an enhancement request for this. But please keep in mind that certain workaround are just there for an absolute minority of users. Usually the workarounds should not be required. And don't expect anything to happen immediately or very soon.

like icon handling functions, and maybe an option for selecting the type of image browser, colour selection windows (new style, or old style) This will improve compatibility and close a few issues. Obviously if someone enables the old 3.8/3.9(2005) style requesters they can be limited in function compared to the modern ones. But that's the user option, and MUI was always keen on options and configuration ;) So please give it a thought.

There will be no "old" color selection window. Face it. It is 2014 by now, not 1988. There is no reason to go backward. Time moves in one direction only. Classic machines with ⇐8bit screenmodes are a dying species. The future belongs to truecolor displays.

comment:23 Changed 6 years ago by Thore Böckelmann

In 3711:

  • mastertext.c: added dithering of ARGB images when drawing texts on 8bit screens. This refs #45.

Changed 6 years ago by Mikhail Malyshev

Attachment: lister-24bit.png added

comment:24 Changed 6 years ago by Mikhail Malyshev


This one is not giving up yet too.

It seems to work without icon.datatype, but in 8 and 15/16 bit modes.
But here we have 24/32 bit mode and the def.drawer.icons get a black hole ;-)

comment:25 Changed 6 years ago by Mikhail Malyshev

Resolution: fixed
Status: closedreopened

comment:26 Changed 6 years ago by Jens Maus

Stop reopening bugs on your own. This is the task of a developer and not of you.

comment:27 Changed 6 years ago by Thore Böckelmann

Resolution: fixed
Status: reopenedclosed

From the application's point of view there is no difference between screens with 15, 16, 24 or 32. If one depth is working the others must be working, too. The technical differences are handled internally by CyberGraphics or Picasso96.

Bottom line is I can do nothing against this.

comment:28 Changed 6 years ago by Mikhail Malyshev

Update: Actually it looks like something recently moded by you made this effect.
Since it is now on all 15/16/24/32 bit screens.
When it was first fixed, it worked ok.

comment:29 Changed 6 years ago by Mikhail Malyshev

Performance issues…
What is it doing during directory browsing ?
eg. enter SYS:
enter Prefs/ (around 100 icons)
enter any further subdir and the response is slow (looking at memory usage there is a lot of things going on, before the memory is finally freed) and new directory is loaded.

Can something be done here?

Also why some items in the list (date, comments, size) are split into two lines ?
This makes the hole alignment of items in the list a bit out of line.
Comments are really odd, since they are wrapped on first space (eg: comment 123)
will split it into comment and 123 on second line, while other comment like long urls are all on one line in same directory list

Requires some settable prefs or some design tweaks…

comment:30 in reply to:  29 Changed 6 years ago by Thore Böckelmann

Replying to Michael:

Performance issues…
What is it doing during directory browsing ?
eg. enter SYS:
enter Prefs/ (around 100 icons)
enter any further subdir and the response is slow (looking at memory usage there is a lot of things going on, before the memory is finally freed) and new directory is loaded.

Icons are loaded and thumbnails are created.

Can something be done here?

No.

Also why some items in the list (date, comments, size) are split into two lines ?

That depends on the current display mode. Click on the first column title to toggle through the possible modes (none, tiny, thumbnail, icon).

This makes the hole alignment of items in the list a bit out of line.
Comments are really odd, since they are wrapped on first space (eg: comment 123)
will split it into comment and 123 on second line, while other comment like long urls are all on one line in same directory list

The comment is split into two lines at most. If it consists of a single word only (i.e. a download URL) then there is nothing to split. Otherwise Dirlist.mui will do split at the space which occurs left or right of the middle with the smallest distance. This might look odd for two word comments with very different word lengths, but it looks good for single word comments and comments with lots of words.

comment:31 Changed 6 years ago by Mikhail Malyshev

Version comments look odd, since they are mostly a word + number, and the number is split of. Maybe it's good to limit the split to a minimum string length ?
Like the classic 32 chars ?

In that case we will have nice single line entries for most objects.

Also, why does it list .info files when we browse for files or skin images ?
And there is no option to disable/enable this. (By default .info files should be hidden)

comment:32 in reply to:  31 Changed 6 years ago by Thore Böckelmann

Replying to Michael:

Version comments look odd, since they are mostly a word + number, and the number is split of. Maybe it's good to limit the split to a minimum string length ?
Like the classic 32 chars ?

First of all, where is the connection to the topic of this ticket? You are mixing up different things again.

Second, comments are exactly this: comments, arbitrary text consisting of words. If these words represent a version information, pitty, then the version information is wrapped. For all other kinds of arbitrary text the wrapping is ok. And furthermore an arbitrary text may have arbitrary length, even the file name in a version string may be longer. There are no restrictions.

Also, why does it list .info files when we browse for files or skin images ?
And there is no option to disable/enable this. (By default .info files should be hidden)

You fail to provide the necessary information again. Of course icons can be rejected if that is requested by the application. So which application are you referring to? If you are referring to the image browser then the display of icons is perfectly valid, because icons are images, if you like it or not.

Even for asl.library ASLFR_RejectIcons defaults to FALSE and all other pattern attributes default to something which accepts all files. Keep in mind that Dirlist.mui is a class to show the contents of a directory and that it needs to be told how to filter these contents. If nothing is told the defaults will be applied and these are "show everything".

Last edited 6 years ago by Thore Böckelmann (previous) (diff)

comment:33 Changed 6 years ago by Thore Böckelmann

Milestone: MUI 3.9-2014R23.9-2014R2

Milestone renamed

Note: See TracTickets for help on using tickets.