Icon Wunschkonzert - AISS Edition

@Mason

Yes, I got it, thanks.
I am working on a AISS enabled version of HD-Rec. Thanks for the Icons!

@Mason

I am currently creating a new GUI Toolkit. While doing some test GUIs, I found many problems with the AISS images (or mabye I am using them in a wrong way?).
I know it is hard to satisfy all people, but...
But you sorted the images accordings usage, e.g. File Management. If you really use the images like you suggest, the result might be the following:



Look at the toolbar at the bottom. All copy, copyas, move, move as, rename etc. look almost identical for the user. They should disriminate among each other much more.

Would you be willing to change some images, if I point out where the problems are like in this example?

@Wanderer

I have to agree, the images look identical. I will try to change them with the next release!

If possible, please send me a list.

BTW This new app looks great!!!

@Mason

Mason I reopen this thread to tell you to paint a "find into files" image please

@Mason

I really want to suggest you once more to re-think over the AISS concept.
To me, your work appears to be too precious to be doomed to stay forever 21x21 (or similar low res)

I want to make following suggestion that could really improve AISS and make it future proof:

1) Draw the images at higher resolution. I suggest 256x256 or 128x128. That provides enough flexibelity for

- high-density screens (e.g. same physical size but double resolution)
- user customizable sizes of the images (e.g. the images should be oriented at the used font)
- add post-processing effects like glow (and leave 1 pixel more border, so the border of the glow is not out-of-bitmap)
- use the images in different situations at different sizes (Icons, Toolbar images large/small, Listviews, Menus, Emblems etc.)

2) Think of a way how to merge this with Icons. Technically, it is all the same.

What I can offer is to write the tools to determine sizes, effects etc, during installation time, or even install the large images and make a prefs program that re-renders the images.

The posibilities are only limited by imagination.
E.g. in case of icons, it would be easily possible to auto-create drawer by taking the application icons and stamp it onto a blank folder icon. You could then easily excange the folder icon, without a lot of work.
You could have toolbar images with or without glow.
You could select a greyish effetc, e.g. half-transparent, embross, greyed, low-constat etc.

Downscaling of images can be really high quality.
If you are willing to do so,I would like to try an example,
e,g, you draw 1 application Icon and one drawer, and I create different variantions and sizes from it, so everybody, including you can judge the result.

@Wanderer

A bit offtopic, but did you release that FileManager somethere which you shown on that 2 years old screenshot ? Will be pretty interesting to try.

@Wanderer

> 1) Draw the images at higher resolution. I suggest 256x256 or 128x128.

... and then scale them down to 24x24 or 16x16?

You forgot that painting a small toolbar icon is quite differnt than painting a normal icon! Patterns, highlightnings or shaddows have to be added in different ways. Even operating systems like Windows and OS X dont just scale down the icons, because it will look ugly.

> 2) Think of a way how to merge this with Icons. Technically, it is all the same.

Nice idea, but imho that's a task for the developers of AmigaOS to implement it - I am just painting the icons.

@Mason

Ok, here we go: (sorry for the size)



The original images are 48x48, as they appear as the last scaled version. The last image is from AISS, and originally 60x60.
To me, they appear almost perfect at any scale, especially if you consider the very "problematic" scaling factors of 48:47 or something.
You are also much more critical when you have the chance to compare one of the sclaed versions with its neighbours. After you watch one of them isolated, without comparism, they look pretty decend.

I understand that you cannot use the same image for every purpose, but I think scaling with the above algorithm is reasonalbe enough to allow the user to select the size in a certain range, same as the user sets the font size.
Fonts are also not "dictated" as 16pt or something.
Some have large screens, some small, some sit very close, others further, some have good eyes, some bad, some use an app that needs to squeeze a lot on the screen etc.

I found when implementing NTUI GUI Toolkit, that scaled images give a much more harmonic overall appearence when going along with font sizes.
As soon as screen with very different DPI come out, this will also become an issue.

After some experiments I think 256x256 is not needed, but e.g. 64x64 or 96x96 would be nice.
See it as the raw data, were the user can create its real size, same as the vector deinitions in TT Fonts.

Some configurability would also be nice, e.g. to set a style how the different states of an image should behave.

In case of icons, I think about the idea to use a tool that e.g. scanns your workbench drive, and replaces the folder icons with a template and then stamp the applications icon that is found inside the folder on it, in a smaller scale. This is more or less the same you do manually, but this tim can be saved I think.

About the File Manager from above:
This is no application. This is just a GUI mock-up to test NTUI.
See here what I mean. If they would both share the same images sizes of 21x21, the smaller one would look really blown up.
21x21 looks good on the first image. But what if I want a 32px font? The problem is, that you can always downscale, but upscaling looks really ugly.

@Wanderer

Offtopic: Reminds me of my beloved ClassAction file manager...

@cha05e90

This GUI is indeed inspired by the ClassAction Filemanager.
Probably I will write sooner or later a simple, but intuitve Filemanger to show the NTUI Toolkit.

@Mason

What do you think about this:

The AISS come as, lets say 48px instead of 21px.
When installing, the 48px are installed in something like "TBImages/Storage". They don't necessarily need to contain an active or disabled version, only if they are truly different from the shown image, not only the post processing.

Then, you have a little config tool that lets the user select the size, effect(s) for selected, disabled (and maybe focus and mouse-over?). Then, the real images in TBImages: are generated.
The user may change this whenever he wants.

I can easily provide such a tool for 68K. AROS users may need to download the pre-scaled images, or someone writes this tool for AROS. My Tool is open source, so everybody can use the algorithms.

Users of existing Apps that use a Toolkit that cannot do rescaling, can at least select a general size that fits to their usual Font size, and they can choose among post-processing effects like the often requested Glow-effect.

Apps that use e.g. NTUI can benefit from loading the original images and rescale them dynamically, if available.

@Wanderer

Hmm. Could this be combined with Roberts effort?

-> aisscache.library (http://os4depot.net/index.php?functio ... aphics/aiss/aisscache.lha)

@Wanderer

Your scaling algoritm makes the icons look great even with every downscaled icon.

@Wanderer

I also tried various times to persuade Mason to use higher resoluted images. There are a lot of reasons for using different sizes of images: fitting to different font sizes, usage in media center applications where you want to see bigger buttons, or just think of handicapped people who would be happy to use bigger than just tiny images for orientation. As long as we have no vector icons on our desktops the only reasonable method is to draw bigger images and rescale them on the fly for own needs. To that respect, the result of your algorithm is simply convincing. Very good quality plus the option to overlay images by various effects saves a lot of time. Only one instead of three images needs to be designed for every state.

The aisscache.library would be the right place to add on-the-fly rescaling and postprocessing support.

The problem is, not all progs use this, and it must be available to OS3, MOS and AROS too.

I also thought about the problem with too large scaling.

What about this directory structure:

TBImages:

Here are the default images in 21x21 (or what the uses sets during install/prefs) this is for backward compatibelity, programs that dont use aisscache or dont care.

TBImages:<size_in_px>/

Here are the images in various sizes, if any variations needed that cannot be obtained by scaling.
The folder name reflects the pixel size, just like bitmap fonts.

If you want to do a different (not obtained by scaling) image for 16x16, you store it here:

TBImages:48/myimage
TBImages:16/myimage

If the aiss.library gets the request to access the image "myimage", it would transprently choose the best-fit. Because we would allow only down-scaling, that would be the 48px image for 17-48, and the 16px image for 1-16.

You can also store _s and _g variants, but if they do not exist, the aisscache.library could create them on-the-fly by applying the effects that the user has set in prefs.

This is very similar how I implemented this already in NTUI.
In the NTUI Toolkit you dont set pixel sizes. You set logical sizes.

E.g. you have the sizes
NTUISIZE_INLINE
NTUISIZE_NATIVE
NTUISIZE_TOOLBAR
NTUISIZE_PIXELS

"inline" would return an image that is scaled so that it fits into floating text, like you can see in the listview in the Filemanager Mock-Up.

"native" would return the actual size the image file has.

"toolbar" would return the size that is set for toolbar images in NTUI Prefs.

"pixels" would return a size corresponding to the acutal given pixels.

etc. there are some more sizes of course.

E.g. you want a smily for a chat-application.
Then you would request "inline". Whatever you current font is, you would get the "native" image scaled to your font size. Just one big smily image would be enough then. No need for a "listview" version etc. what Mason currently has.

Such a concept would be really good for other GUI Toolkits too, and Mason has to paint less images.
Also think about that an active and a disabled version is not really enough. In NTUI, I have also the states "focused" and "mouse-over".

Now, what I suggest is that we make a small "proof" of concept.
If Mason would paint a hand full of images at large size, say 48 or something, and I will rescale them and post-process them, I can also do 5 states instead of 3.

Then we can compare them to their original AISS counterparts and see if we can match the quality, or maybe even exceed it.
@Mason
What do you think?

I know the topic is complex, the above is just some brainstorming, not a ready-brewn concept.

Hi @Mason

1) Please have a look at the docs if the icon already exists
2) Three icon requests per member

I didn't find '7z' or '7zip' archive icons.
What would truly be ' Wunschkonzert ' would be a SDLBasic drawer icon! But, since nobody uses it just forget it! :-O

@Snuffy

Quote:

Do you mean a 7z def_icon? I'm not sure now, but wasn't it already part of OS4.1update1 ENVARC:Sys?

Quote:

Maybe I can help you here, if you provide me your e-mail adress (through PM)...

@Wanderer

I vote for "go for the proof-of-concept"!!!
All in all it seems a good idea to me, but besides that I've never heard anything about NTUI besides in this thread.. :-O

@Amigo1

NTUI is the GUI Toolkit I am working on, it is not yet released. It has on-the-fly image rescaling build-in.
The screenshots above of the filemanager are made with NTUI. I wanted to demonstrate how useful scaling of images is. Those screenshots are impossible with any other toolkit on the Amiga AFAIK. All other Toolkits would use the 21x21px images, which would look very bad and waste a lot of space in this example.

So having this functionality via aisscache.library would be very handy for other Toolkits, unfortunately only for those which are still developed and would make use of it.
Because of this, it would be at least handy to be able to adjust globally the size to your Workbench Font/Screen resolution/DPI.

@Wanderer

I like it! IMHO a good successor for RA..

Isn't it in the talk to overhaul the OS GUI toolkit after all? I know it's up to Hyperion, but well, the sooner this area is addressed...

@all

Sorry if I repeat the following concept, but it's an important one.

Any image processing function (scaling, shadowing, rotation, glow, you-name-it) should go in a specific library that is oriented precisely and exclusively to image processing - let's call it imageprocessing.library. Then, any GUI toolkit, icon.library, game, application, whatever, can simply use the services offered by such library.
Such library should be evaluated together with the OS development team, since the whole graphical subsystem is being / will be reworked. Same goes for any GUI toolkit: we already have too many and we already know that the OS does and will provide an official toolkit (whichever it will be), so the best thing to do is checking with the OS developers.

I don't mean to discourage initiatives by enthusiast developers, but avoiding wastage of energies and potential splits, and possibly contributing to a clean, system-rooted, unified solution is highly recommendable.

EDIT: just as a practical example, let's consider scaling: the OS already has that function somewhere - why would one want to duplicate that functionality anywhere else? And if it's only because the already existing functionality isn't exposed as a general-purpose service, then, well, the right solution is not re-implementing the functionality, but moving the existing one to the right place.