AROS Exec

Distros => Icaros Desktop => Topic started by: miker1264 on August 25, 2019, 10:15:10 PM

Title: Not-so-poor Icon processor
Post by: miker1264 on August 25, 2019, 10:15:10 PM
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;
}


Title: Re: Not-so-poor Icon processor
Post by: miker1264 on August 26, 2019, 01:53:31 AM
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!
Title: Re: Not-so-poor Icon processor
Post by: salvatore on August 26, 2019, 03:48:38 AM
I don't know, maybe you should talk to Paolone
Title: Re: Not-so-poor Icon processor
Post by: paolone on August 26, 2019, 11:40:52 PM
Here is the article to refer to:
http://vmwaros.blogspot.com/2019/08/not-so-poor-icon-processor.html (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.

Title: Re: Not-so-poor Icon processor
Post by: miker1264 on August 27, 2019, 12:27:09 AM
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.
Title: Re: Not-so-poor Icon processor
Post by: paolone on August 27, 2019, 09:14:40 AM
Maybe you missed the sequel to my first post about Iconposer:


http://vmwaros.blogspot.com/2019/08/inconposer-now-working-as-intended.html (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).
Title: Re: Not-so-poor Icon processor
Post by: paolone on August 27, 2019, 04:44:58 PM
Update.


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




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



Title: Re: Not-so-poor Icon processor
Post by: miker1264 on August 27, 2019, 05:14:40 PM
Maybe you missed the sequel to my first post about Iconposer:


http://vmwaros.blogspot.com/2019/08/inconposer-now-working-as-intended.html (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.

Title: Re: Not-so-poor Icon processor
Post by: salvatore on August 27, 2019, 05:39:08 PM
great guy's
Title: Re: Not-so-poor Icon processor
Post by: miker1264 on August 27, 2019, 07:30:21 PM
Update.


IconPoser 1.0 has been released
http://vmwaros.blogspot.com/2019/08/iconposer-10-first-release.html (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.
Title: Re: Not-so-poor Icon processor
Post by: paolone on August 28, 2019, 12:26:55 PM
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.
Title: Re: Not-so-poor Icon processor
Post by: Ball000 on August 28, 2019, 01:32:31 PM
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 (http://aminet.net/package/util/cli/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.
Title: Re: Not-so-poor Icon processor
Post by: paolone on September 11, 2019, 10:05:06 PM

Yet another way would be to try and port ViewT (http://aminet.net/package/util/cli/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. :-(
Title: Re: Not-so-poor Icon processor
Post by: miker1264 on September 11, 2019, 10:30:03 PM

Yet another way would be to try and port ViewT (http://aminet.net/package/util/cli/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?
Title: Re: Not-so-poor Icon processor
Post by: paolone on September 11, 2019, 11:08:35 PM
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).
Title: Re: Not-so-poor Icon processor
Post by: mmartinka on September 12, 2019, 01:17:54 AM

Yet another way would be to try and port ViewT (http://aminet.net/package/util/cli/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. :-(
[/quote]

Paolone you test this file https://drive.google.com/file/d/1LR4OBHFSYklRJIkY0I9j_2aJulSw3W_b/view?usp=sharing (https://drive.google.com/file/d/1LR4OBHFSYklRJIkY0I9j_2aJulSw3W_b/view?usp=sharing) I did small changes...
Title: Re: Not-so-poor Icon processor
Post by: paolone on September 12, 2019, 09:10:29 AM
Hi mmartinka! Many thanks.


Is the .c source provided in your archive already modified? Have you used any flag while compiling?
Title: Re: Not-so-poor Icon processor
Post by: mmartinka on September 12, 2019, 10:21:25 AM
Hi mmartinka! Many thanks.

Is the .c source provided in your archive already modified?
Yes

Quote
Have you used any flag while compiling?
No
Title: Re: Not-so-poor Icon processor
Post by: paolone on September 12, 2019, 01:44:47 PM
@mmartinka


Thanks. It works very well on 32bit AROS. I could compile it also on AROS 64, although the resulting executable is not 64bit-friendly at all: it crashes hosted AROS very hard, as soon as you invoke it. BTH, too many warnings and notices produced while building meant something... :-/



Title: Re: Not-so-poor Icon processor
Post by: mmartinka on September 12, 2019, 04:06:27 PM
@mmartinka


Thanks. It works very well on 32bit AROS. I could compile it also on AROS 64, although the resulting executable is not 64bit-friendly at all: it crashes hosted AROS very hard, as soon as you invoke it. BTH, too many warnings and notices produced while building meant something... :-/

I try it look into more...
Title: Re: Not-so-poor Icon processor
Post by: paolone on September 12, 2019, 04:28:09 PM
@Martinka


Don't worry: no need to waste your time, unless you'd find it useful for something else :-)
Title: Re: Not-so-poor Icon processor
Post by: mmartinka on September 12, 2019, 08:57:18 PM
update  :)
I tested under AROS host and it work now...
https://drive.google.com/file/d/1rsU-lrFE4K3d933rRkOXwgc6CMIQMRCm/view?usp=sharing (https://drive.google.com/file/d/1rsU-lrFE4K3d933rRkOXwgc6CMIQMRCm/view?usp=sharing)
Title: Re: Not-so-poor Icon processor
Post by: paolone on September 13, 2019, 10:09:13 AM
update  :)
I tested under AROS host and it work now...
https://drive.google.com/file/d/1rsU-lrFE4K3d933rRkOXwgc6CMIQMRCm/view?usp=sharing (https://drive.google.com/file/d/1rsU-lrFE4K3d933rRkOXwgc6CMIQMRCm/view?usp=sharing)


I wish to tell a big thank you! :-)

Since it's now working OK, I added the x64 version and re-packaged everything in a new archive, adding also a README file with all credits. I just uploaded it into the Archives.

Title: Re: Not-so-poor Icon processor
Post by: mmartinka on September 14, 2019, 01:47:52 AM
Excelent  8)
Title: Re: Not-so-poor Icon processor
Post by: Mysha on September 14, 2019, 02:00:37 PM
Missed most of this one, apparently. I guess we all have a tool like this, each shaped to meet our own needs. Can we do something with that knowledge, apart from having a look at those parts that are open source and maybe free as well?

                                                                                         Mysha
Title: Re: Not-so-poor Icon processor
Post by: miker1264 on October 22, 2019, 08:40:56 PM
Has anyone tested IconPoser on Icaros 64bit Hosted on Linux? It freezes when I try to select picture files. Can anyone verify that it works?
Title: Re: Not-so-poor Icon processor
Post by: wawa on October 22, 2019, 09:40:28 PM
any actual source or binary if i have to test it let alone try to debug?
Title: Re: Not-so-poor Icon processor
Post by: miker1264 on October 22, 2019, 09:54:04 PM
any actual source or binary if i have to test it let alone try to debug?

paolone posted a link at the beginning of this thread to IconPoser.
Title: Re: Not-so-poor Icon processor
Post by: wawa on October 22, 2019, 10:21:00 PM
 just see id have to download the whole icaros. :(
Title: Re: Not-so-poor Icon processor
Post by: miker1264 on October 22, 2019, 11:48:10 PM
just see id have to download the whole icaros. :(

Try this.
http://vmwaros.blogspot.com/p/iconposer.html?m=1
Title: Re: Not-so-poor Icon processor
Post by: wawa on October 23, 2019, 03:15:48 AM
file is not executable. ah it is a script. it needs lua?
Title: Re: Not-so-poor Icon processor
Post by: wawa on October 23, 2019, 03:30:49 AM
compiled aros lua. it is in extras/developer/lua. changed default tool accordingly. it crashes:
Code: [Select]
*** Logged alert:
Program failed
Task : 0x0000000042BD8930 - lua
Error: 0x80000002 - Hardware bus fault/address error
PC   : 0x0000000042128290
Module stdc.library Segment 1 .text (0x00000000420F4360) Offset 0x0000000000033F30
Function strlen (0x0000000042128290) Offset 0x0000000000000000
CPU context:
RAX=0000000042C025B0  RBX=0000000042C226F0  RCX=0000000042BC0C58  RDX=000000000000001D
RSI=0000000000000005  RDI=0000000000000005  RSP=0000000042C97698  RBP=0000000042C976B0
R8 =00000000000000CD  R9 =0000000000000000  R10=0000000000000004  R11=0000000042BDBE30
R12=0000000000000005  R13=0000000042C226F0  R14=0000000042BC0C58  R15=0000000042BC0C40
RIP=0000000042128290  RSP=0000000042C97698  RFLAGS=0000000000010246
Stack trace:
0x0000000042BDF39B Lua Function lua_pushstring + 0x000000000000002B
0x0000000042BDE4A5 Lua Segment 1 .text + 0x0000000000001195
0x0000000042BE40E2 Lua Function luaD_precall + 0x00000000000002E2
0x0000000042BE450C Lua Function luaD_call + 0x000000000000004C
0x0000000042BE39A6 Lua Function luaD_rawrunprotected + 0x0000000000000076
0x0000000042BE482C Lua Function luaD_pcall + 0x000000000000003C
0x0000000042BE003F Lua Function lua_pcallk + 0x000000000000007F
0x0000000042C03C1C Lua Function main + 0x000000000000008C
0x0000000042BDD46D Lua Segment 1 .text + 0x000000000000015D
0x0000000042C02785 Lua Segment 1 .text + 0x0000000000025475

Title: Re: Not-so-poor Icon processor
Post by: wawa on October 23, 2019, 03:32:26 AM
might be as well some problem with lua port under 64bit. ill try to see how it works on other targets.
Title: Re: Not-so-poor Icon processor
Post by: wawa on October 23, 2019, 06:16:29 AM
Quote
might be as well some problem with lua port under 64bit.

no, its not. same thing on i386:

Code: [Select]
[KRN] Trap signal 11, SysBase f40de1e0, KernelBase f40df184
    SP=f49de558  FP=f49de558  PC=f424ef38
    R0=00000005  R1=00000005  R2=00000002  R3=00000005
    R4=f49a0068  R5=00000005
*** Logged alert:
Program failed
Task : 0xF4A25570 - lua
Error: 0x80000002 - Hardware bus fault/address error
PC   : 0xF424EF38
Module stdc.library Segment 1 .text (0xF42287A0) Offset 0x00026798
Function strlen (0xF424EF30) Offset 0x00000008
CPU context:
EAX=0x00000005  EBX=0x00000005  ECX=0x00000002  EDX=0x00000005
ESI=0x00000005  EDI=0xF49A0068  ESP=0xF49DE558  EBP=0xF49DE558
EIP=0xF424EF38  ESP=0xF49DE558  EFLAGS=0x00010282
Stack trace:
0xF495F990 Lua Function luaS_new + 0x00000010
0xF4952C03 Lua Function lua_pushstring + 0x00000023
0xF4951C2C Lua Segment 1 .text + 0x00000D6C
0xF49570B5 Lua Function luaD_precall + 0x00000235
0xF4957441 Lua Function luaD_call + 0x00000041
0xF4951EBB Lua Segment 1 .text + 0x00000FFB
0xF4956A68 Lua Function luaD_rawrunprotected + 0x00000048
0xF49576B2 Lua Function luaD_pcall + 0x00000032
0xF49536A8 Lua Function lua_pcallk + 0x00000058
0xF49702AA Lua Function main + 0x0000005A
Title: Re: Not-so-poor Icon processor
Post by: Yannick on October 23, 2019, 09:20:40 AM
The tool certainly needs amilua, not lua alone.
I didn't try iconposer but my other lua scripts are working with lua:amilua under hosted 64bit

I've only compiled AROS, contrib and ports (ports are certainly not required)

/Yannick
Title: Re: Not-so-poor Icon processor
Post by: wawa on October 23, 2019, 11:13:08 AM
ah, because of intuition implementation, i though it may just be another lua port. perhaps both should be unified and maintained in contribs?
Title: Re: Not-so-poor Icon processor
Post by: wawa on October 23, 2019, 01:05:41 PM
has anyone already a mmakefile for amilua? i wrote one but somehow it deosnt work. weird. wouldnt mind not to duplicate done work.
Title: Re: Not-so-poor Icon processor
Post by: Yannick on October 23, 2019, 02:42:31 PM
It's part on contrib, in contrib/development/compilers/lua

There's nothing to do it exists and compiles for x64 without any issues

Title: Re: Not-so-poor Icon processor
Post by: paolone on October 23, 2019, 05:06:19 PM
I guess I have verbosely explained what's needed to IconPoser to work. It's a very-Icaros-dependent tool which needs some other utilities to work correctly. Both Icaros 32 and 64 provide all necessary stuff. Unluckily, some of them might not be as stable on both architectures and issues need to be addressed.


But IconPoser itself on Icaros 64 is absolutely working.
Title: Re: Not-so-poor Icon processor
Post by: wawa on October 23, 2019, 05:13:01 PM
Fine. I was under impression i need to test it.
Title: Re: Not-so-poor Icon processor
Post by: miker1264 on October 23, 2019, 06:04:48 PM
Ok. If everything needed is present in 64bit then it should work as expected. I'll work with it for now.