Not-so-poor Icon processor

[miker1264]

I saw the post about the "Not-so-poor Icon processor" built in LUA and I'm very impressed by that concept.

I have been working on something similar called "Icon Factory" that only works on one png icon at a time.
If the Icon Processor can create multiple icons from icon images that is a win-win for Icaros Desktop.

I already have c code for combining image1 and image2. It's very simplistic based on two small functions.
So here it is:


//Save image1
//Simply Copy first Icon Image to new filename.
copy_file("Ram Disk:Im1.dat", fileName);
                               
//Save image2
//Simply append image2 on top of image1.
copy_file_append("Ram Disk:Im2.dat", fileName); 
//Substitute the name of your image1 & image2 for the ones above.
//In this case "fileName" is the .info file to save images to.
//Note that the original images must be in png image format.

                               
int copy_file(char *old_filename, char  *new_filename)
{
      FILE  *ptr_old, *ptr_new;
      int  a;

      ptr_old = fopen(old_filename, "rb");
      ptr_new = fopen(new_filename, "wb");

      while(1)
      {
         a  =  fgetc(ptr_old);
         if(!feof(ptr_old))
            fputc(a, ptr_new);
         else
            break;
      }

      fclose(ptr_new);
      fclose(ptr_old);
      return  0;
}

int copy_file_append(char *old_filename, char  *new_filename)
{
      FILE  *ptr_old, *ptr_new;
      int  a;

      ptr_old = fopen(old_filename, "rb");
      ptr_new = fopen(new_filename, "a");

      while(1)
      {
         a  =  fgetc(ptr_old);
         if(!feof(ptr_old))
            fputc(a, ptr_new);
         else
            break;
      }

      fclose(ptr_new);
      fclose(ptr_old);
      return  0;
}

[miker1264]

Here is the article to refer to:
http://vmwaros.blogspot.com/2019/08/not-so-poor-icon-processor.html

I like the gui layout to the left, but I think I'm most impressed by the Picture Requester on the right side.
Is that available in Icaros Desktop now? I'd like to use that in some of my programs. That's a nice feature!

[salvatore]

I don't know, maybe you should talk to Paolone

[paolone]

Here is the article to refer to:
http://vmwaros.blogspot.com/2019/08/not-so-poor-icon-processor.html

I like the gui layout to the left, but I think I'm most impressed by the Picture Requester on the right side.
Is that available in Icaros Desktop now? I'd like to use that in some of my programs. That's a nice feature!

Yes. That's the great PictureReq from Yannick Erb. You can find it in /C.

Syntax is
picturereq PATH PATTERN
for instance, to open PNG files only in Home:
picturereq home: #?.png
ask yannick for the complete documentation, or look at the code, is open-source.

[miker1264]

paolone,
Thank you for the information.

I really like the idea of the Iconposer App.
If you add a couple of buttons for "Create" and
"Assign" just above "Cancel" it would be very
efficient and very useful.

Create will simply create the icon but Assign
would use a file requester to assign the icon to a file. If the file already has an icon associated it becomes an icon exchage operation.

Then adding "Create Icon" to the Magellan Menu
Could make it a very useful icon creation tool.

Just some ideas. Very good work so far.

[paolone]

Maybe you missed the sequel to my first post about Iconposer:


http://vmwaros.blogspot.com/2019/08/inconposer-now-working-as-intended.html




You actually described what Iconposer is meant to do. Once you have composed a icon, you can save it and/or associate it to a file. Iconposer is smart enough to inherit tooltypse from a pre-existing icon when overwriting it, and some information in the interface is ignored when pointless. If you have entered a default tool, for instance, your icon will be saved as a project one, no matter if you have chosen the 'tool' type. Tooltypes are not managed by Iconposer (after all, the system already gives you all that you need to add some), but they can be copied from another icon used as template.


I'm happy that Iconposer is getting this attention.


I am actually using it and I already found many quirks that would need more love. For instance, if you use PictureReq, you'll discover it does not remember what the latest directory was, so you'd really prefer it opening there. I will try to work around this dynamically changing the variable that currently sets the initial directory for the requester (this also means I will eliminate user's chance to change this).

[paolone]

Update.


IconPoser 1.0 has been released
http://vmwaros.blogspot.com/2019/08/iconposer-10-first-release.html




Official page for the program:
http://vmwaros.blogspot.com/p/iconposer.html

[miker1264]

Maybe you missed the sequel to my first post about Iconposer:


http://vmwaros.blogspot.com/2019/08/inconposer-now-working-as-intended.html




You actually described what Iconposer is meant to do. Once you have composed a icon, you can save it and/or associate it to a file. Iconposer is smart enough to inherit tooltypse from a pre-existing icon when overwriting it, and some information in the interface is ignored when pointless. If you have entered a default tool, for instance, your icon will be saved as a project one, no matter if you have chosen the 'tool' type. Tooltypes are not managed by Iconposer (after all, the system already gives you all that you need to add some), but they can be copied from another icon used as template.


I'm happy that Iconposer is getting this attention.


I am actually using it and I already found many quirks that would need more love. For instance, if you use PictureReq, you'll discover it does not remember what the latest directory was, so you'd really prefer it opening there. I will try to work around this dynamically changing the variable that currently sets the initial directory for the requester (this also means I will eliminate user's chance to change this).

I look forward to using IconPoser as well. I'm also pleased it's getting well deserved attention. It seems to be a useful icon utility. It also gives me a chance to compare to one of my own icon utilities "Icon Factory".

Mine isn't finished yet and it still has some small quirks to be worked out. It is currently part of the icon functions in "ShowPicture" which hasn't been released yet. Once complete I'll spin off the functions into Icon Factory as a standalone icon utility.

It is designed to be a point-and-click icon interface. The concept is that when an icon is displayed in a window clicking in the window changes the icon image. There is also a menu attached to the icon display window.

Up till now for the standalone program I needed a way to open an existing icon or to create a new one. The simplicity of your IconPoser dialog box (user interface) has inspired me to complete my own icon utility.

On first opening the program I'll use an EasyRequester with a message and three options (buttons) - Open Icon, Create Icon, Cancel All. Once open the icon menu takes over. For Create Icon I'd like to use a simple icon dialog like yours with two image display areas with two buttons for normal and selected which are actually browse buttons. Below those two buttons will be two more buttons - Apply and Cancel. For importing r exporting images from the icon I'll use the same dialog that is modified slightly. The Apply button becomes Save and clicking in an image display draws a red border to indicate the selection.

Eventually I'd like for Icon Factory to work with New Icons (GlowIcons) and PNG Icons.

[salvatore]

great guy's

[miker1264]

Update.


IconPoser 1.0 has been released
http://vmwaros.blogspot.com/2019/08/iconposer-10-first-release.html




Official page for the program:
http://vmwaros.blogspot.com/p/iconposer.html

Fantastic! I look forward to using it to make a few new icons.

Although I like the new drsign layout I prefer the simplistic look of the initial dialog layout.

Thank you for all your efforts. It's appreciated.

[paolone]

Older dialog layout wasn't "simple", it was "incomplete" (some options were still to be added). It's a pity I don't know:

1. how to read tooltypes from a icon and paste it into a text file (and vice versa)2. how to use the texteditor class in LUA. I would like to add a text field on the right and allow people edit tooltypes straight within IconPoser
but for now I can be satisfied with what I got. Not bad for someone who just has a vague idea of what the code is doing.

[Ball000]

1.

Code: [Select]

ProcessIcon SYS:Tools/Commodities/ClickToFront VIEWshows a number of informations about the .info file, but especially at the end:
  TT: (YES)
  NUMCLICKS=1
  DONOTWAIT

So you should be able to parse what follows "TT: (YES)" if it is found (if not it says "TT: (NO)" and it stops there).
But this doesn't provide a way to write back the tooltypes.


Another way is to use the CTT=COPYTOOLTYPES switch of ProcessIcon, which allows to copy tooltypes across (original and newly created) icons.
I guess that's probably what you already do.


Yet another way would be to try and port ViewT or a similar tool ;-)


2.

A poor-man's solution would be to put a button which calls the Wanderer's Info tool by calling for example:

Code: [Select]

WBRun SYS:System/Wanderer/Tools/Info SYS:Tools/Commodities/ClickToFront
Here the tooltypes can be edited.

[paolone]

Yet another way would be to try and port ViewT or a similar tool ;-)

well, I tried. Unluckily, the command
gcc -o ViewT_AROS ViewT.c

gives the following results:
ViewT.c:73:20: warning: 'struct DOSBase' declared inside parameter list [enabled by default]
ViewT.c:73:20: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
ViewT.c:75:15: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'mymain'
ViewT.c:179:20: warning: 'struct DOSBase' declared inside parameter list [enabled by default]
ViewT.c:179:6: error: conflicting types for 'PRintf'
ViewT.c:73:6: note: previous declaration of 'PRintf' was here
ViewT.c: In function 'PRintf':
ViewT.c:184:7: warning: passing argument 2 of '__inline_Dos_VPrintf' from incompatible pointer type [enabled by default]
/AROS/Development/bin/../../Development/include/inline/dos.h:2498:20: note: expected 'RAWARG' but argument is of type 'long int *'
I'm sure anyone knowing C could fix this, it's a pity I don't. :-(

[miker1264]

Yet another way would be to try and port ViewT or a similar tool ;-)

well, I tried. Unluckily, the command
gcc -o ViewT_AROS ViewT.c

gives the following results:
ViewT.c:73:20: warning: 'struct DOSBase' declared inside parameter list [enabled by default]
ViewT.c:73:20: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
ViewT.c:75:15: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'mymain'
ViewT.c:179:20: warning: 'struct DOSBase' declared inside parameter list [enabled by default]
ViewT.c:179:6: error: conflicting types for 'PRintf'
ViewT.c:73:6: note: previous declaration of 'PRintf' was here
ViewT.c: In function 'PRintf':
ViewT.c:184:7: warning: passing argument 2 of '__inline_Dos_VPrintf' from incompatible pointer type [enabled by default]
/AROS/Development/bin/../../Development/include/inline/dos.h:2498:20: note: expected 'RAWARG' but argument is of type 'long int *'
I'm sure anyone knowing C could fix this, it's a pity I don't. :-(

Serious errors. Maybe missing libraries.

I agree with a previous post that Icon Information in Magellan can be used to set Tooltypes.

Also when a new png icon is saved and first used an Ic0n chunk is written to the file and default Tooltypes are assigned.

The only time Tooltypes are of concern is for an Icon Exchange Operation, in my opinion.

Is your IconPoser 64bit or 32bit?

[paolone]

Is your IconPoser 64bit or 32bit?

Both. It's a LUA script, which is an interpreted language. You can run it on 32 or 64 bit indifferently. The real issue here is having all programs IconPoser needs to work properly: gsar, processicon, picturerreq. I have compiled all them to 64bit (with the help from O1i, Yannick and others).