AROS World Exec
Distros => Icaros Desktop => Topic started by: miker1264 on December 14, 2021, 08:48:33 AM
-
Any ideas or feature requests?
Separate application or Wanderer Built-in function?
-
It would be useful to have the two methods, then it depends on how many icons you need to convert, if you have a lot of icons is very convenient a small GUI where you can drag and drop the files, but if you need to change only one icon or its type then it would be good to integrate info Icons on Wander, in practice what happens with OS 3.9
-
It would be useful to have the two methods, then it depends on how many icons you need to convert, if you have a lot of icons is very convenient a small GUI where you can drag and drop the files, but if you need to change only one icon or its type then it would be good to integrate info Icons on Wander, in practice what happens with OS 3.9
I like the way it is solved in Magellan... you open "informations" and simply drag & drop the new icon in it
-
If for example you need to swap images to 100 icons it would take a long time, with apps like IconCopy it takes a few minutes.
Also, with apps like IconCopy, you can transfer only the image, only the position on the Workbench, only the Tooltypes and much more, with your method you would have to set it by hand each time and it would take a long time and you might miss some ticks.
Moreover, not all people use Dopus5, Dopus Magellan totally replaces Wanderer and has its merits and flaws.
-
If for example you need to swap images to 100 icons it would take a long time, with apps like IconCopy it takes a few minutes.
Also, with apps like IconCopy, you can transfer only the image, only the position on the Workbench, only the Tooltypes and much more, with your method you would have to set it by hand each time and it would take a long time and you might miss some ticks.
Moreover, not all people use Dopus5, Dopus Magellan totally replaces Wanderer and has its merits and flaws.
which flaws?
It is a modern and highly configurable desktop. I would never return to Wanderer.
Yes that option is certainly not best if you want to exchange 100 icons but when does a user do that?
-
I agree.
I prefer both. A quick Icon Exchange in Wanderer Information. And also a standalone CopyIcon or IconCopy type application.
It would be a simple drag-n-drop using GadTools with options for ToolTypes like Magellan?
Maybe instead of using Wanderer Information simply make a new module dedicated to Icon Exchange?
Maybe a commandline IconCopy that accepts parameters would be useful as well for example to set up Dopus4 buttons?
I'll do some research on various Icon Exchange methods to use.
-
It's great that CopyIcon and IconCopy work on AROS 68k but we need something designed specifically for use with AROS.
Without source code for either it's difficult to say why they aren't working to display icons on AROS 68k. Are sources available?
-
It's great that CopyIcon and IconCopy work on AROS 68k but we need something designed specifically for use with AROS.
Without source code for either it's difficult to say why they aren't working to display icons on AROS 68k. Are sources available?
one of the apollo team is interested in your updated multiview and datatypes
where are the current ones? I do not find it in forum
-
It's great that CopyIcon and IconCopy work on AROS 68k but we need something designed specifically for use with AROS.
Without source code for either it's difficult to say why they aren't working to display icons on AROS 68k. Are sources available?
one of the apollo team is interested in your updated multiview and datatypes
where are the current ones? I do not find it in forum
Later today I will post MultiView 68k and updated datatypes for 68k. I'll most likely put them on AROS Archives also with a link.
Within a day or two I will put together a version for AROS x86_64. And by the weekend I may have an x86 version. No promises. I have to set up my build system for x86. That takes some time.
Here is the MultiView PDF explaining new features and updates. I will gather the updated datatypes, latest DTConvertGUI and MultiView 1.8 and post them in a few hours.
-
It's great that CopyIcon and IconCopy work on AROS 68k but we need something designed specifically for use with AROS.
Without source code for either it's difficult to say why they aren't working to display icons on AROS 68k. Are sources available?
one of the apollo team is interested in your updated multiview and datatypes
where are the current ones? I do not find it in forum
Later today I will post MultiView 68k and updated datatypes for 68k. I'll most likely put them on Archives.
thanks
-
It's great that CopyIcon and IconCopy work on AROS 68k but we need something designed specifically for use with AROS.
Without source code for either it's difficult to say why they aren't working to display icons on AROS 68k. Are sources available?
Yes as I said CopyIcon and IconCopy, Iconcopier are very good tools, but with AROS icon.library they don't work with DualPNG icons, in the screenshot you can see how these programs and Dupus4 show correctly DualPNG icons
-
It's great that CopyIcon and IconCopy work on AROS 68k but we need something designed specifically for use with AROS.
Without source code for either it's difficult to say why they aren't working to display icons on AROS 68k. Are sources available?
Yes as I said CopyIcon and IconCopy, Iconcopier are very good tools, but with AROS icon.library they don't work with DualPNG icons, in the screenshot you can see how these programs and Dupus4 show correctly DualPNG icons
I have some working code in my Icon Library for Icon Alias that copies images and ToolTypes from icon to icon. That's how Icon Alias works. It replaces icon images. I'll look at how portable it is. Maybe an AROS version of Icon Exchange will happen soon.
-
Yes thanks, a simple GUI is enough for changing te immage on Icons, Wanderer is the best place, with Dopu4 it would be complicated.
Regarding the change of type of icons, on AROS One 68k I use IconType, very simple, just drag the icon, choose the type and click on Convert, also convenient for when you have to operate on many icons, IconType also works well with Dopus4 (other app), see screenshot.
IconType is another tool that is missing on AROS x86 and it would be nice to have it with your new GUI.
-
Yes thanks, a simple GUI is enough for changing te immage on Icons, Wanderer is the best place, with Dopu4 it would be complicated.
Regarding the change of type of icons, on AROS One 68k I use IconType, very simple, just drag the icon, choose the type and click on Convert, also convenient for when you have to operate on many icons, IconType also works well with Dopus4 (other app), see screenshot.
IconType is another tool that is missing on AROS x86 and it would be nice to have it with your new GUI.
Many good ideas. I like the layout of IconCopier.
I'll start a new project called "IconClone" for Icon Exchange.
I'll look into a simple Icon Exchange for Wanderer as well using drag-n-drop. For the simple exchange only the images change.
The standalone GUI will have many options for Icon Exchange.
-
Thanks in the meantime on Aminet I found the source of seticontype that I compiled with Murks on AROS One x86, the compilation was successful.
Tried the seticontype executable and it works perfectly, it converts the icon type to all icons including OS4, but it doesn't recognize and works only with DualPNG :(
http://aminet.net/package/util/wb/seticontype
-
Another surprise, on AROS x86 I used "processicon" to change the icon type and also this program behaved the same as "seticontype", practically works with all icons except DualPNG.
Now comes the surprise, I tried to create the DualPNG icons on OS 4.1 with the same program "IconEditor" that I normally use on OS3 and AROS 68k, well, the DualPNG icons created on OS 4.1 is possible to change the type to the icons with both "processicon" and "seticontype" that I had compiled.
So on OS3 the DualPNG are generated differently than on OS4 even if all OS see them perfectly.
There is an answer to all this, the developer of "IconEditor" when he compiled the 68k version of "IconEditor" told me that on OS3 something was missing to be like the OS4 and MOS version, "now I don't remember what".
-
Another surprise, on AROS x86 I used "processicon" to change the icon type and also this program behaved the same as "seticontype", practically works with all icons except DualPNG.
Now comes the surprise, I tried to create the DualPNG icons on OS 4.1 with the same program "IconEditor" that I normally use on OS3 and AROS 68k, well, the DualPNG icons created on OS 4.1 is possible to change the type to the icons with both "processicon" and "seticontype" that I had compiled.
So on OS3 the DualPNG are generated differently than on OS4 even if all OS see them perfectly.
There is an answer to all this, the developer of "IconEditor" when he compiled the 68k version of "IconEditor" told me that on OS3 something was missing to be like the OS4 and MOS version, "now I don't remember what".
That's very interesting. If you post a zip file of sample DualPNG Icons from OS4.1 & OS3/AROS 68k then I can compare with a Hex Editor to tell what the differences are with them.
I analyzed an OS4.1 PowerIcon in my favorite Hex Editor. It is a Classic Amiga Icon with a "fake" OS3.5 IFF structure with two ARGB Data Chunks.
So processicon and seticontype would treat them as Classic Icons. A Hybrid AROS 68k Icon such as the one attached here might also work with processicon and seticontype.
-
It's great that CopyIcon and IconCopy work on AROS 68k but we need something designed specifically for use with AROS.
Without source code for either it's difficult to say why they aren't working to display icons on AROS 68k. Are sources available?
one of the apollo team is interested in your updated multiview and datatypes
where are the current ones? I do not find it in forum
I posted everything for MultiView & the updated 68k datatypes on the thread "Newest MultiView". You may download from there.
I hope Apollo Team is pleased with the new features and updated features that have been added to MultiView.
-
Apollo team Must be more than satisfied, on the apollo forum on one of my threads I had announced your developments.
I attach two icons created with the same image, same program, same steps but then the two Dual-PNG icons are different.
The tools I used on AROS x86 to OS3 icons can not change the icon type, on OS3 instead from the Workbench on these icons you can change the icon type.
-
Apollo team Must be more than satisfied, on the apollo forum on one of my threads I had announced your developments.
I attach two icons created with the same image, same program, same steps but then the two Dual-PNG icons are different.
The tools I used on AROS x86 to OS3 icons can not change the icon type, on OS3 instead from the Workbench on these icons you can change the icon type.
I examined them both.
The OS3 Icon is simply DualPNG like AROS uses.
The OS4 Icon however is a PowerIcon as I mentioned earlier. It isn't DualPNG. It has ARGB Data Chuncks.
-
Yes this I imagined, the strange thing is that I used the same program and the same options, probably the developer made me a version adapted to OS3.
The OS3 and AROS version of IconEditor is not distributed, although the AROS x86 version can be found on IcarOS and on aros archive.
I have to try the AROS version of IconEditor, but I think it will behave the same as on OS3.
-
Confirmed, the icons created with IconEditor on AROS x86 have the same characteristics of those created on OS3
-
At the moment on AROS One 68k I have restored the icon.library of Peterk, unfortunately with the icon.library AROS 68k I cannot modify anything on the DualPNG icons that I use in all the Distro.
-
At the moment on AROS One 68k I have restored the icon.library of Peterk, unfortunately with the icon.library AROS 68k I cannot modify anything on the DualPNG icons that I use in all the Distro.
How do you modify them? What does PeterK's Icon Library allow you to do that AROS Icon Library doesn't?
-
Of course I'm talking "only" about DualPNG icons used on AROS One which I can't give up, the tools you see in the screenshot don't work with DualPNG icons anymore.
- Change icon type, Drawer, Tool, Disk etc....
- Replace icon image
- Display DualPNG icons correctly with Dopus
-
Of course I'm talking "only" about DualPNG icons used on AROS One which I can't give up, the tools you see in the screenshot don't work with DualPNG icons anymore.
- Change icon type, Drawer, Tool, Disk etc....
- Replace icon image
- Display DualPNG icons correctly with Dopus
I understand. Whatever fits your needs. Those things will be fixed eventually.
-
Yes, that's why I said momentarily, those tools now speed up my work.
-
Yes, that's why I said momentarily, those tools now speed up my work.
How do I get Dopus4 to read an icon? There is no button for it.
-
To get the icon info on Dopus4 is very simple, if you need to configure the button in "Filetype Class" choose the internal command "IconInfo", see screenshot.
If you need to configure also the double click, in "File Configuration" you have to add the voice "AmigaDOS Icon", choose in "Filetype Class" always the internal command "icon Info", and in "Edit Class" you have to add the MatchName *.info
-
AMIGASYSTEM
I could just use your config for Dopus.
How do I advance the button bank? Right click or something?
-
AMIGASYSTEM
I could just use your config for Dopus.
I attach my config, if you need I can send you my complete Dopus4 and files and datatypes so that all keys are functional
How do I advance the button bank? Right click or something?
If I understand correctly the banks once added you can manage them from a Slide, you will also see it on the Drive pusants where you can click on the default paths of the system.
-
Thanks. I will check out icon display for Dopus4 Icon Information. I'll match that to the source code to find out why it's not working correctly.
Here's my idea about Wanderer Icon Information. Wanderer is MUI based. It uses Zune. Icon Information is a small tool associated with Wanderer that is also MUI based.
In order to change the behavior of the Icon Data GUI I would need to set "MUIA_Window_Appwindow, TRUE," then set up an AppMsgHook for the IconImageObject. Whenever the user drags an icon over the icon image in the top left corner it sends a message to the AppMsgFunc which reads the alt icon filename. It then sets the IconImageObject value to the new filename. It also sets BOOL image_changed = TRUE for future.
Once the icon image changes that indicates an "Icon Exchange" operation is pending. When the user selects "Save" if image_changed = TRUE then instead of Save_Icon we use Save_Alt_Icon to copy the attributes from the original icon to the alternate icon then rename them so alternate becomes original.
Then the Icon Exchange is complete. :)
It sounds good. But will it work as planned? We'll see.
-
It would be ideal to have these features on Wanderer, then maybe in the future also a small tool for quick icon exchange when there are many to exchange, as said CopyIcon44 works well with the icon.library AROS 68k, the only problem is that it does not show the icon in the GUI, if you want you can try it, you can find it here:
http://aminet.net/package/util/wb/CopyIcon44
-
After only a few hours I was able to drop an icon on the Wanderer Icon Information window and get a filename using an MUI Callback Hook for the dragndrop operation on the image.
Next I'll try to change the icon image in the top left based on the new filename with an MUI Set Method. These two things are the most difficult and the most important part of the icon exchange. The rest is rather straightforward copying the icon attributes.
-
Congratulations, the hardest thing is that it does all this with DualPNG icons as well.
-
Congratulations, the hardest thing is that it does all this with DualPNG icons as well.
It simply works with filenames. :)
I set the information window to be an appwindow so that it accepts icon drag-n-drop operations. Then I setup a MUI Callback Hook (AROS Hook) for the IconImageObject. It sends an AppMessage to the Callback Function when an icon is dropped on the IconImageObject in the top left corner.
When the message is received we obtain the new icon filename then decide what to do with it. We will do two things. Change the image displayed in the IconImageObject by supplying the new filename in an MUI Set fuction to set the new value of MUI_IconImage_File. MUI then displays the image hopefully. Then we set a TRUE/FALSE BOOL image_changed in this case it's TRUE. The value is used at Save time to decide to use Save_Icon or our new function Save_Alt_Icon to Exchange.
The difficult part is the Dragndrop Callback Hook and that's almost done. The rest is just changing the icon image, setting a value and providing a new save method to copy icon attributes.
Seems easy enough.
-
Congratulations again, Wanderer must improve and surpass our old beloved Workbench !
-
How is this idea for an MUI based Name View for Wanderer?
I like the clean simplicity and look and feel of MUI/Zune Apps.
It's part of a user interface I'm working on. Whereas FileMaster that has been around for a while is based on BGUI. It would be nice to have a Simple MUI based File Manger for use with AROS.
This FM is based on the concept of simplicity & portability. The small button at bottom right is the "return to parent" button.
It's just a concept at the moment. In an experimental version of Wanderer I will put this together when my MUI skills improve.
I know many people have contributed to Wanderer over the years. I would consult top developers before anything official. Same thing for Icon Exchange. I would consult about it also. AROS is a collaboration so we must work together at times.
I'm allowed to experiment at least. That's the fun of it. ;)
-
nice miker :)
-
Yes beautiful it is an style old /standard MUI !
-
Maybe move the statusbar to the bottom like Wanderer Icon View and move the addressbar to the top and try to use the blue parent button to be more consistent. I'll paint another concept.
The Workbench Tab simply lists the volumes on Wanderer's Workbench Screen for easy access. The Volumes Tab lists all volumes. And Directories is the Main Tab for directory search.
When I say "MUI" in reference to AROS it's actually just "Zune".
This is all conceptual done in PaintDotNet. It's not real yet. 8)
-
I said old style because in the MUI package there is a nice PatchASL that makes a MUI window more modern like the MOS one, I would say even more beautiful, but very heavy for OS3, maybe it can inspire you, watch this video of mine.
https://drive.google.com/file/d/1KPGMXBubAidqy2UxV1USsGWz4w4iKqbG/view?usp=sharing
-
Name View Concept number three.
All actions in Name View are menu-driven. But there will be more menu items available in Name View with more options.
When Icon View Window Closes and Name View Window Opens a new menu is attached. On the Main Menu "Icon" becomes "File" which contains basic operations for Name View such as File Copy, File Move, File Delete, Rename, Clear All, Select All.
File Copy and File Move will pop up a File Requester to select destination. The Directory Listview will be set to Multi-Select.
Name View will handle the basic file operations we need from time to time. So we won't have to resort to Dopus4 or the shell.
The Name View Window will be accompanied by a Full MUI based File Manager (hence the window title). It will be very similar with two listviews and a memu system. It may have optional buttonbars at the bottom for those who like buttons. The Full File Manager will be capable of many more options and as far as its location the Tools Directory seems appropriate. Maybe a Wanderer menu item opens the File Manager directly.
Up till now I had been working on FileMaster that Toni Wilen had started long ago. I had hoped it would fill the gap on AROS x86-64 and for those who choose not to use Magellan. But it seems rather than BGUI that MUI/Zune would be a better way to go.
Unlike Dopus4 and Magellan both Wanderer Name View & the Full File Manager will be designed for All Flavors of AROS.
This is also just a concept. But it seems very plausible. 8)
-
After some experimentation I've concluded that the Icon Information window is not the best place for Icon Exchange.
Rather I would propose a new Icon Exchange Module to exchange icon images. The new icon can then be opened in Icon Information to change ToolTypes, etc.
-
Great, if there is also the possibility of dragging the icons would be even more functional, thanks for what you do
-
nice Miker :)
-
After some experimentation I've concluded that the Icon Information window is not the best place for Icon Exchange.
Rather I would propose a new Icon Exchange Module to exchange icon images. The new icon can then be opened in Icon Information to change ToolTypes, etc.
Drag icon on the information window under os4 is quite easy and functional. I like it.
-
Drag icon on the information window under os4 is quite easy and functional. I like it.
The information window under os4 OS4.1 is the same as that of OS 3.5/9, OS 3.1.4/3.2, but also OS 3.1 if you use an external program.
This mode is good if you have to change an icon every now and then, if you have to change many icons you need a small utility where dragging allows you to change many icons in a few seconds, i enclose video exhaustive
https://drive.google.com/file/d/1k8pOKVu4-Azuqx-AneGgbe2SfFWFEjai/view?usp=sharing
-
I've began writing an Icon Exchange App based on GadTools.
I may decide to leave Icon Information alone. It just needs a way to change Icon Type. But if it isn't broken. Don't try to fix it. ;)
This app is called "IconClone". It's a very simple design much like CopyIcon. The image on the left is "old icon". The image on right is "new icon". Select icon files with the two '?' Selector Buttons. The Double-Arrow Button performs the Icon Exchange.
Maybe in the future IconClone may have a small menu system. You may expect several more of these small icon applications.
Hopefully it will also allow Drag-n-Drop for quick selection and processing if you have several icons to process at a time. 8)
GadTools is much easier for me than trying to learn MUI/Zune.
-
Great, if you've watched the whole of the attached above video, at the end of the video it shows the little App to change the Drawer, Poject, Tool etc. icon type on the fly.
-
Great, if you've watched the whole of the attached above video, at the end of the video it shows the little App to change the Drawer, Poject, Tool etc. icon type on the fly.
Interesting. So for simplicity we don't need "Save" & "Exit" Buttons. Save is "Exchange = <->" and Exit is the Close Gadget. Nice.
So the image on the left is "Source" and we drop or select the image on the right ("Desitination") then choose "Exchange".
Once you drop or select the source icon it becomes a two-step conversion process. Drop or select destination then choose "<->" to exchange. Then repeat...
-
Yes, unfortunately also the two Icontype OS3 versions don't work with the native AROS x86 icon.library.
As said it's good to have these tools also on Wanderer, the Apps as shown in the video are for multiple changes on a number of icons.
-
Yes, unfortunately also the two Icontype OS3 versions don't work with the native AROS x86 icon.library.
As said it's good to have these tools also on Wanderer, the Apps as shown in the video are for multiple changes on a number of icons.
I will continue to work with Icon Exchange in Wanderer Icon Information because it's convenient to do it there for exchanging images.
Send me samples of the OS3 icons that don't work or post them here. I''ll investigate.
Meanwhile, the IconClone Project GUI is going from Concept to Real Application. :)
I must first center the three buttons in the middle of the window which involves adjusting origin & coordinates. Then I must draw three Bevel Boxes.The Bevel Boxes are simply three dimensional "frames" which are drawn on the RasterPort. The outer "group box" is a "sunken" Bevel Box". The two inner Raised Panels for Icon Image display are "Raised" Bevel Boxes. The four corners of each Raised Panel represents the drop zone coordinates.
After drawing the Bevel Boxes I can remove the Save & Exit buttons that are just place hoders at the moment. Then the GUI design is complete! :)
-
great Miker :D
-
Send me samples of the OS3 icons that don't work or post them here. I''ll investigate.
Miker are the normal DualPNG icons that I use on AROS One x86/68k, CopyIcon and IconType "do not work" on AROS 68k only if I use the native "AROS Icon.library".
If I use PeterK Icon.library no problem, all CopyIcon and IconType apps work perfectly.
-
Here is the actual IconClone application in action. 8)
Currently we have to use the requester buttons [ '?' ]. But in the near future we can use Drag-n-Drop!
It's the AROS equivalent of CopyIcon but only better because we can use IconClone on all AROS flavors.
This GUI only has three buttons! Notice the Bevel Boxes, sunken & raised, which are drawn on the RasterPort.
-
Each Raised Panel for Icon Image Display is 80x80 pixels.
Some fancy code to center the icon images since image size can vary.
BOOL retval = FALSE;
UWORD srce_x,srce_y;
UWORD center_x,center_y;
int width,height,depth;
RGBImage *in_pic = NULL;
struct BitMapHeader *bmhd;
Printf ("ReadBmhd_by_datatype");
bmhd = readbmhd_by_datatype(srcename);
width = bmhd->bmh_Width;
height = bmhd->bmh_Height;
depth = bmhd->bmh_Depth;
/* Centered = width,height/2 */
center_x = ((80-width)/2);
center_y = ((80-height)/2);
/* Get RasterPort coordinates */
if(stricmp(position,"left") == 0)
{
/* Top left of First Raised Panel */
srce_x = 26 + center_x;
srce_y = 25 + topoffset + center_y;
}
if(stricmp(position,"right") == 0)
{
/* Top left of Second Raised Panel */
srce_x = 151 + center_x;
srce_y = 25 + topoffset + center_y;
}
-
Great miker, on AROS x86 will be fantastic since there are no similar programs
-
Yes great miker :)
-
Each Raised Panel for Icon Image Display is 80x80 pixels.
Some fancy code to center the icon images since image size can vary.
BOOL retval = FALSE;
UWORD srce_x,srce_y;
UWORD center_x,center_y;
int width,height,depth;
RGBImage *in_pic = NULL;
struct BitMapHeader *bmhd;
Printf ("ReadBmhd_by_datatype");
bmhd = readbmhd_by_datatype(srcename);
width = bmhd->bmh_Width;
height = bmhd->bmh_Height;
depth = bmhd->bmh_Depth;
/* Centered = width,height/2 */
center_x = ((80-width)/2);
center_y = ((80-height)/2);
/* Get RasterPort coordinates */
if(stricmp(position,"left") == 0)
{
/* Top left of First Raised Panel */
srce_x = 26 + center_x;
srce_y = 25 + topoffset + center_y;
}
if(stricmp(position,"right") == 0)
{
/* Top left of Second Raised Panel */
srce_x = 151 + center_x;
srce_y = 25 + topoffset + center_y;
}
A few suggestions about the above code:
1) add spaces after the comma, when there's a list of variables. For example:
UWORD srce_x, srce_y;
it makes the code more readable.
2) don't hard-code values on things that might change (e.g.: icons/regions dimensions). Better to define constants for such values;
3) the second if could be better optimized adding an else in front:
else if(stricmp(position,"right") == 0)
this avoids checking again the string when it was already sure that it was left.
-
cdimauro
It's all good. This is the rough code to get things working.I should also be mindful about tab spacing and indentation.
I also add constraints and error checking at the end. But it would be better to do much of that at the time of writing not at the end.
I usually go back and edit to make it look better and to make it more efficient. I should get in the habit of doing it right the first time though. It makes things easier at the end. ;)
The application itself is doing what it is supposed to do. There were a few ways to go about replacing the icon images. I'm having some difficulty copying icon attributes such as default tool, icontype and tooltypes array from DiskObject to DiskObject.
I also have to implement Drag-n-Drop. The difficulty is that there are two Drop Zones so I have to set bounding boxes and compare drop coordinates. During experimentation it gets ugly! Many thanks to deadwood for offering some solutions. I'll probably need more help before it's finished though. :)
-
For the IconClone app I could have simply tried to replace the images but then I would have to split the PNG Icons into two images to manipulate the data. But I would have to worry about preserving the icOn chunk data as well so I'm doing it differently.
Even if I used IconControlA to get the icon images I would still have to remake the icon file to infuse the new images and I would need to preserve the original icon attributes along with it. But the method I choose must work for PNG and IFF icon files.
I copy the source icon that has the proper images to a temp file in Ram Disk. I treat it as a complete file without splitting it. I must also consider the easiest way to deal with OS3.5 Icons. Treating them as complete files makes things much easier.
But then I must get two DiskObjects and copy all attributes from destination (original icon) to the temp icon. After the cloning process is complete I set filesize of destination icon to zero before writing binary to avoid extra IEND chunks when image sizes differ. I write temp icon directly to replace destination icon. The last part of the process is to delete the temp file and redisplay the new destination icon which now has new images.
Once everything is working correctly and after some cleanup I'll release the binaries and source code for everyone to enjoy. ;)
I'm planning another small icon app called "IconColor" which also has double icon image displays.It will feature HSL Color Conversion to change icon color as @paolone says "on the fly".
The IconClone Application is contained in one code module so it can be easily compiled for AROS 68k or x86 or x86_64 as well.
-
thank you Miker :)
-
thank you Miker :)
There is another GUI based icon app I'm planning called "IconProcess" which is designed for Kens Icons. It allows batch processing large numbers of new colored icons from two baseimages, original images and icon image masks.
Within minutes using two colored baseimages and selecting directories for originals and image masks and output directory it's possible to produce thousands of new icons. See samples.
Of course I would get Kens permission before posting them. :)
But it is possible to use IconProcess with any set of PNG Icons.It will also copy ToolTypes, etc to the new icons. I've also made a green glow border & neon blue glow border for icons.
The new colored icons can be used with colored window borders and background images to make colored themes.
A while ago @paolone asked about a way to replace the system icons with colored icons for Icaros Live DVD. The colored iconsets would either be zipped or in their own directory. So I will make another small GUI based app called "ReplaceIcons". It will be based on "Icon Alis" List Processing using an IconsList & NewIconsList. It will have an option to backup existing icons.
-
great!
-
It's nice when things work the way they are supposed to.
Copying icon attributes including icon type, default tool, stack size, and tooltypes array works now.
It's a few days away from a working version.
-
Indispensable tool for AROS 68k but especially for AROS x86 where there is nothing that can do this.
... By the way also AROS ABI-v1 does not support DualPNG icons, probably there will be the same problem with the png.datatypes
-
Indispensable tool for AROS 68k but especially for AROS x86 where there is nothing that can do this.
... By the way also AROS ABI-v1 does not support DualPNG icons, probably there will be the same problem with the png.datatypes
What about ABIv1 ? AROS 68k and AROS x86_64 are based on that. But you already know about PNG Datatype 42.1 vs 42.0
The current Nightly AROS 68k has an issue with PNG Datatype. But IcarosDesktop x86_64 is based on older files so it doesn't.
-
What about ABIv1 ? AROS 68k and AROS x86_64 are based on that. But you already know about PNG Datatype 42.1 vs 42.0
Yes indeed the problem is always the same, PNG Datatype that does not work well.
The current Nightly AROS 68k has an issue with PNG Datatype.
I tried the latest Nightly Build "20211220" and for the DualPNG icons you have to replace the PNG Datatype, then everything works fine
But IcarosDesktop x86_64 is based on older files so it doesn't.
I haven't tried IcarosDesktop x86_64, if it uses Dopus Magellan, it's likely that Dopus Magellan handles PNG icons, try Icaros deactivating Dopus and setting Wanderer !
-
What about ABIv1 ? AROS 68k and AROS x86_64 are based on that. But you already know about PNG Datatype 42.1 vs 42.0
Yes indeed the problem is always the same, PNG Datatype that does not work well.
The current Nightly AROS 68k has an issue with PNG Datatype.
I tried the latest Nightly Build "20211220" and for the DualPNG icons you have to replace the PNG Datatype, then everything works fine
But IcarosDesktop x86_64 is based on older files so it doesn't.
I haven't tried IcarosDesktop x86_64, if it uses Dopus Magellan, it's likely that Dopus Magellan handles PNG icons, try Icaros deactivating Dopus and setting Wanderer !
Or just check the version of PMG Datatype in MultiView.
Anyhow the issue will be resolved. deadwood is looking into it.
-
Congratulations! AROS has a new Icon Exchange App.
I will make the release files today for all flavors of AROS.
-
Fantastic ! miker
-
yes nice :)
-
Fantastic ! miker
It's nothing fancy! It's beautiful in it's simplicity. ;)
-
Special because until today on AROS One x86 "Wanderer" you couldn't change the icons and you couldn't change the type of icons, AROS One 68k and AROS x86 don't use Dopus Magellan by choice :)
-
Special because until today on AROS One x86 "Wanderer" you couldn't change the icons and you couldn't change the type of icons, AROS One 68k and AROS x86 don't use Dopus Magellan by choice :)
AMIGASYSTEM
Would you like to test this 68k app with some of your DualPNG 32bit Icons? The x86 and x86_64 versions will be available soon.
The top requester ['?'] is for the source icon. The bottom requester is for the dest icon. Copy from source to dest.
The arrow button in the middle is "Exchange". The application will copy images from source to dest while preserving tooltypes, etc from the dest.
It does not feature Drag-n-Drop. Just a simple icon exchange. But I'm working on another app "IconDrop" that WILL have Drag-n-Drop to load icons.
-
Perfect miker first step has been done, IconClone works well on AROS One 68k, I have created DualPNG icons in AROS One and IcarOS style, I attach archive.
With IconDrop will be even more convenient in the presence of many icons, the exchange type of Icon if I understand correctly we will have it on Wanderer?
I have to investigate the Arial font because the size "16" gives problems even to IconClone :-\ with the "13" is perfect :)
-
It's working correctly on x68_64 now and x86.
See screenshot.
-
Perfect, I notice in your screenshot a problem with the box that hosts the icon, that is due to the large font !
Have you downloaded my icons created for IconClone?
-
Perfect, I notice in your screenshot a problem with the box that hosts the icon, that is due to the large font !
Have you downloaded my icons created for IconClone?
I noticed that problem also. At first I thought my coordinates for "EraseRectangle" to erase a portion of the RasterPort was wrong. But I realized that these coordinates were correct on AROS 68k and x86. But on x86_64 where the screenshot was from there's a problem with GadTools Layout. Nor sure why.
I will look into that at some point for GadTools Layout on xi6_64. It seems the values for WinBorderTop & WinBorderBottom are correct. But WinBorderLeft & WinBorderRight has issues. But only on 64bit. M68k and 32bit are ok. The display GadTools ok.
I haven't seen your icons for IconClone.
-
The icons are attached in the "post above" click here:
https://ae.amigalife.org/index.php?action=dlattach;topic=814.0;attach=2051
This morning I did some tests and I've ascertained that the problem is caused by the usual Arial font above "13".
To confirm I tried another version of Font Arial found on the Web and the problem has decreased, only the back side, if you use Font Arial "16" native AROS then all sides of the square are involved, see screenshot !
-
That's the same problem as on x86_64. But it is ok on 68k & x86.
GadTools can't calculate the correct layout based on font size above a certain range? Interesting problem. Maybe there's a solution somewhere that will fix all these issues? We'll see.
Maybe a possible solution is to use "struct TextAttr *ng_TextAttr" to set a font for the gadget to use independent of screen font.
I downloaded the icons. I like the blue one size 48. It's similar to one I'm using now.
-
AMIGASYSTEM
I believe I solved part of the mystery...it doesn't depend on the screen font size!
I noticed that the shifted GUI affects the Bevel Boxes but the Buttons are correct.
The Bevel Boxes use Absolute Coordinates from the outer left corner of the window frame. Notice the difference between
the frame thickness for x86_64 on the left & x86 on the right. In pixel values the difference is 4 pixels for x86_64 vs. 9 pixels for x86.
So using basic math if the outer group box is at 15 pixels from the outer edge that means it is 15-9=6 vs 15-4=11 which is 5 pixels
too much. So with a window border thickness of 4 the Bevel Boxes are shifted right by 5 pixels causing the visual distortion.
So GadTools is doing the Layout correctly. But to correct the offset I must now use leftoffset = scr->WBorLeft + 4. That means
instead of DrawBevelBox(win->RPort, 26... I must use DrawBevelBox(win->RPort, leftoffset + 13... which will place it in the correct
offset from the inside left window border. Then the offsets will all look correct. But it also affects my coordinated for EraseRect.
-
So this would also solve the problem on DTConvertGUI !
-
So this would also solve the problem on DTConvertGUI !
Most likely. I will look at that next and make adjustments for the GUI.
I must first correct the coordinates for EraseRectangle that I use to "erase" part of the RasterPort for
each Raised Panel used for Icon Image Display. I must erase after each display in case an image is larger.
Notice the white lines to the left side of each Raised Panel on the bottom image. Notice the lines on top.
In the top image you can see that the left side of each Raised Panel has been "Erased" by bad coordinates.
-
Ok. After making several adjustments the new version is working on AROS m68k & AROS x86 & AROS x86_64.
Here are all the release versions in one zip file. See screenshot for Before & After Corrections on AROS One x86.
The top view is before making corrections to the GUI Offsets. The bottom view is after the GUI Offset corrections.
-
thank you very much Miker
-
Perfect miker, it works well even on AROS One x86, finally you can replace the icons on Wanderer x86, remains the problem Fonts "Ariel", with value 13 perfect no problem, with 15 problem on one side, with value 16 problem on two sides.
N.B. the Blue icons are folder icons of the new version of AROS One, I see that you use a very old version of AROS One :)
-
is the final release miker
-
is the final release miker
Yes. This is the final release.
-
Perfect miker, it works well even on AROS One x86, finally you can replace the icons on Wanderer x86, remains the problem Fonts "Ariel", with value 13 perfect no problem, with 15 problem on one side, with value 16 problem on two sides.
N.B. the Blue icons are folder icons of the new version of AROS One, I see that you use a very old version of AROS One :)
AMIGASYSTEM
Show me the font issue. Screenshots?
Describe the circumstances. AROS One 68k or x86 or both?
Is anyone else having a problem with GUI offsets when you change screen font to Arial 16? I tried it but don't see an issue.
Also in AROS One x86 older version Arial 16 isn't a problem.
-
I experience the same problem for both AROS One 68k and AROS One x86, the greater the size of the font, the greater the misalignment.
I attach 4 tests, with Arial 13 (perfect), 15, 16 and 20
-
is the final release miker
Yes. This is the final release.
ok thank you Miker :)
-
I experience the same problem for both AROS One 68k and AROS One x86, the greater the size of the phon, the greater the misalignment.
I attach 4 tests, with Ariel 13 (perfect), 15, 16 and 20
Thank you. That helps to narrow down the issue.
Please do the same comparison for DTConvertGUI.
I'll try my alternate method by using struct TextAttr to assign a specific font to the gadgets independent of the screen font size.
-
I attach 4 tests DTConvertGUI, with Arial 13 (perfect), 15 (perfect), 16 and 20
-
I attach 4 tests DTConvertGUI, with Arial 13 (perfect), 15 (perfect), 16 and 20
I have another idea. Instead of using fixed offsets I can use proportional offsets based on "ng_Width & ng_Height" of buttons. So then GadTools will provide scaling & offsets.
I believe I have the proportional offsets corrected for DTConvertGUI. It's the easier of the two. IconClone has GUI offsets as well as EraseRectangle coordinates to consider.
Now the gadget offsets are proportional to the screen font rather than fixed. In sequence from top: Arial 13, Arial 16, Arial 20. Someone will be pleased. I like Arial 16 now. :D
New binaries to follow soon...
-
AMIGASYSTEM
Here is the x86 version of IconClone if you'd like to try it.
It uses proportional offsets based on screen font rather than fixed offsets.
I tested it with Arial 13, Arial 16, and Arial 20. This is the Christmas Edition. ;)
-
A masterpiece, you made a nice Christmas present to AROS users who use Wanderer.
To the version with the drag and drop option you should add the ability to swap icons even for files that don't have an icon, this feature is present on all icon swapping programs.
-
AMIGASYSTEM
Here is a new version just for you. I added a new function called Copy_Icon.
Now when you select the Destination it can be either an Icon or Unassociated File with no Icon.
If the file has no icon a temporary default icon will be copied to that location (def_Picture.info).
Then when you press the Exchange Button the new file with new images will be assigned to that file.
-
I tested this version of IconClone but when I load a file without icon iconClone crashes, maybe I'm doing something wrong.
Probably CopyIcon uses another technique, from what I can guess it could be that CopyIcon copies the def_icon of the file without icon, I made a small video demonstration with CopyIcon
https://drive.google.com/file/d/1zZ2_v1l62_b0Cq6iiPaJu4YUFVlTJLxi/view?usp=sharing
-
Big thank you, miker1264!
This is the tool I needed for a long time. In fact, I even started to code my own icon copier, but unfortunately haven't finished it. :(
Anyway... I tested your tool and everything seems to be fine except two things:
- lack of drag'n'drop (this is easy, check this https://eab.abime.net/showthread.php?t=101478)
- no support for classic icons (MagicWB, Newicons, etc.)
-
Big thank you, miker1264!
This is the tool I needed for a long time. In fact, I even started to code my own icon copier, but unfortunately haven't finished it. :(
Anyway... I tested your tool and everything seems to be fine except two things:
- lack of drag'n'drop (this is easy, check this https://eab.abime.net/showthread.php?t=101478)
- no support for classic icons (MagicWB, Newicons, etc.)
Those two items are on my ToDo List. ;)
Did you get Drag-n-Drop to work on your icon copier?
I'm working on those two items. I'll release the source code also.
-
Nice, good luck! :)
-
Nice, good luck! :)
How far did you get with the icon copier?
Mine is setup for OS3.5 Icons also but I haven't implemented the code to display the images. I will likely use INFO Datatype for it.
-
I tested this version of IconClone but when I load a file without icon iconClone crashes, maybe I'm doing something wrong.
Probably CopyIcon uses another technique, from what I can guess it could be that CopyIcon copies the def_icon of the file without icon, I made a small video demonstration with CopyIcon
https://drive.google.com/file/d/1zZ2_v1l62_b0Cq6iiPaJu4YUFVlTJLxi/view?usp=sharing
Could you make a short video showing what you did to make it crash exactly so I can compare results & make adjustments?
-
How far did you get with the icon copier?
Just an empty appwindow with drop zones, image handling was missing. I lost my source anyway... :P
-
How far did you get with the icon copier?
Just an empty appwindow with drop zones, image handling was missing. I lost my source anyway... :P
So you used drop zones? I setup the appwindow and msgport to generate an appmessage. But I didn't use drop zones. I intended to get the filename & mouse coordinates from the appmessage.
But after a drag-n-drop it doesn't produce an appmessage. :(
Here is the current source code. It's a bit messy! The drag-n-drop code is in main( ). I suspect something is wrong with the AppWindow or the MsgPort for the AppWindow.
-
Here is the small video with file without icon made with IconClone on AROS One x86
https://drive.google.com/file/d/1mIyVp7YMDtyNb-NIvjqZu5uuysEdjv1Q/view?usp=sharing
-
Here is the small video with file without icon made with IconClone on AROS One x86
https://drive.google.com/file/d/1mIyVp7YMDtyNb-NIvjqZu5uuysEdjv1Q/view?usp=sharing
It can't find the default icon (def_Picture.info).
It's looking for this:
srcefile = "SYS:Prefs/Env-Archive/SYS/def_Picture.info";
We can use any default icon (def_icon). I just randomly chose one. It may change. :)
-
Perfect now it works fine IconClone on AROS One x86, i had deleted the "def_Picture.info" because all graphics formats have their own custom def_icon, I attach new small video that shows how it works.
https://drive.google.com/file/d/1uaV_pTepINDNEcLJhtkzZSlLiqSZHQfK/view?usp=sharing
miker if it can serve you on aminet I found SetIconType (http://aminet.net/package/util/wb/seticontype), i compiled it with GCC on AROS One x86 and it works perfectly from Shell, now i'm configuring it also on Dopus4.
The only problem is that SetIconType recognizes only the old Amiga icons and AROS "Nightly Build" icons, it does not support Glow icons and DualPNG icons.
-
With this update of IconClone you have also solved another problem that you may have missed, now your IconClone can replace any icon including old Amiga icons ;D
-
But after a drag-n-drop it doesn't produce an appmessage. :(
Here is the current source code. It's a bit messy! The drag-n-drop code is in main( ). I suspect something is wrong with the AppWindow or the MsgPort for the AppWindow.
Put all code that belongs to sigs = Wait(winmask | msgmask); after if (sigs & winmask)
Also, cleanup code is missing
RemoveAppWindow(app_winow);
and
while(amsg = (struct AppMessage *)GetMsg(app_port))
ReplyMsg((struct Message *)amsg);
DeleteMsgPort(app_port);
Look at appwindow.c example from here: http://aminet.net/package/dev/src/RKRM_Libs_prgs
-
@new123
Amazingly the AppWindow works when I set it up correctly! ;)
Working out the mouse coordinates for the drop zones was easier than I thought it would be.
The last bit to do is to EraseRectangle before displaying the icon image in the correct drop zone.
Thanks for the hints and the link to the sample code. Icon drag-n-drop works great. :)
-
AMIGASYSTEM
Try the new drag-n-drop icon feature.
Sorry about the Print Messages. They will be removed.
-
Thanks miker, Icon drag-n-drop works great but in this mode images are not exchanged.
-
Sorry miker but I found again a problem on IconClone.
If you replace an image to a "Pogetto" Icon, the Project icon loses the tool set, for example if on a "TXT" test file icon the tool "Multiview" is set, after the conversion "Multiview" is deleted and the tab remains empty.
This would not be serious, but unfortunately to write "Multiview" again you have to restart the system because the icon does not allow writing after conversion (write protection) which cannot be disabled.
-
It's good to find the issues and address them rather than have someone else find them later. ;)
If I understand the problem correctly not all icon attributes especially the Protection Bits & tools are being preserved from the original icon.
Specifically the default tool set to MultiView. I should fix it. I will examine all the attributes to make sure they are correct after the exchange.
BTW after drag-n-drop the exchange does work. I accidentally uploaded the wrong version! Ooops. ;)
-
The latest correct version of IconClone where can I download it ? I created a script to run IconClone so that I don't have the Shell open.
Did you have a look at the SetIconType source attached above, do you think something can be added so that it can work with DualPNG icons too ?
-
The latest correct version of IconClone where can I download it ? I created a script to run IconClone so that I don't have the Shell open.
Did you have a look at the SetIconType source attached above, do you think something can be added so that it can work with DualPNG icons too ?
Yes. I looked at the SetIconType. It merely allows you to choose a number corresponding to the Icon Type which then gets set in the attributes.
I'm planning to add a small menu system. One item will be to change type. It will likely use a numerical requester to choose the icon type.
I will upload the latest version which will work as long as you use it from a script rather than drag-n-drop. I have issues with string pointers!
-
ìI'm planning to add a small menu system. One item will be to change type. It will likely use a numerical requester to choose the icon type.
Excellent
I will upload the latest version which will work as long as you use it from a script rather than drag-n-drop. I have issues with string pointers!
Here my English I think was not understood, the script I created to delete the message in the CLI, (CON: added .... Drag Icon into AppWindow)
P.S. IconClone you attached is the same as the one posted above, where the image change doesn't work
-
ìI'm planning to add a small menu system. One item will be to change type. It will likely use a numerical requester to choose the icon type.
Excellent
I will upload the latest version which will work as long as you use it from a script rather than drag-n-drop. I have issues with string pointers!
Here my English I think was not understood, the script I created to delete the message in the CLI, (CON: added .... Drag Icon into AppWindow)
P.S. IconClone you attached is the same as the one posted above, where the image change doesn't work
If you mean the version where drag-n-drop works correctly with exchange you will have to wait a while till I fix string pointer issues. I turned off the print messages. It's only for testing.
The string pointer issue is this: When you use the Requester Buttons each buttons calls GetSourceFilename or GetDestination. String pointer for srcename points to the source file and string pointer for destination points to destname.
But the problem with drag-n-drop is there's only one filename. Both srcename & destname point to the same filename. So I have to reorganize it and fix that part. But I don't have time till later today. Using the requesters works. Drag-n-drop not yet.
-
Ok, I will wait for the new version, no rush, I had misunderstood me ;)
As I said above I discovered that even the old Amiga icons can be replaced with your IconClone, to do this instead of loading the .info you have to load directly the file :)
-
Ok, I will wait for the new version, no rush, I had misunderstood me ;)
As I said above I discovered that even the old Amiga icons can be replaced with your IconClone, to do this instead of loading the .info you have to load directly the file :)
The older OS3.5 Icons can be used with IconClone to exchange images. But displaying the OS3.5 images is not yet implemented. That will be in the next updated binary hopefully.
I will need to rewrite some of the internal code to deal with the string pointers issue. One solution is to convert filename directly to disk object - srcedobj & destdobj to perform the exchange.
As far as getting a default icon image it has to find it using "SYS:". My system drive is "AROS1" but it still finds the default icon. You must have the def_Picture icon or the icon specified or it can't load the image.
-
Back to my original plan. Because supporting drag-n-drop and using file requesters will cause a major re-write. I will split it into two projects - IconClone and IconDrop.
So IconClone will only use file requesters but no drag-n-drop. While IconDrop will only use drag-n-drop but no file requesters.
IconClone will have a small menu attached to decide what attributes to keep and to allow changing the icon type. It will also allow opening an unassociated file to assign an icon file.
IconDrop will be very simple. Drop the two icons then exchange.
I'm still undecided at this point. Maybe IconDrop will be experimental until I figure out how to make drag-n-drop work along with file requesters.
-
Alright two is better than one :)
miker I don't know if you have ever noticed, on AROS with the icons happens a very strange thing that on Amiga doesn't exist, the icons change type automatically according to the file, example:
- Suppose we have a text file called "foo" with icon "Project" and the multiview tool, if we add that same icon to another file called "foo" but executable, the icon will automatically change to icon "Tool".
If we then add the same icon to a text file again, the icon will change back to a "Project" icon and the "multiview" tool setting will return.
This transformation also happens for Drawer Icon, Disk Icon etc..
If my English is not understandable I can create an exhaustive video
-
Alright two is better than one :)
miker I don't know if you have ever noticed, on AROS with the icons happens a very strange thing that on Amiga doesn't exist, the icons change type automatically according to the file, example:
- Suppose we have a text file called "foo" with icon "Project" and the multiview tool, if we add that same icon to another file called "foo" but executable, the icon will automatically change to icon "Tool".
If we then add the same icon to a text file again, the icon will change back to a "Project" icon and the "multiview" tool setting will return.
This transformation also happens for Drawer Icon, Disk Icon etc..
If my English is not understandable I can create an exhaustive video
This may be due to defaults set in AROS Icon Library. An executable is automatically a "tool" and default tool (MultiView) is ignored. It may be the protection bits. I'm not sure. I'll check.
-
Splitting of IconClone is a nonsense. You have a bug somewhere that need to be fixed! Put source code in GitHub or something, in my spare time I'll try to help. :)
-
Splitting of IconClone is a nonsense. You have a bug somewhere that need to be fixed! Put source code in GitHub or something, in my spare time I'll try to help. :)
I agree. I'm trying to fix it now.
The problem is that I'm using STRPTR srcename & destname which works well with File Requesters. But when the user drops an icon there's only one filename. My solution is to go directly to GetDiskObject. I'm working on that part now.
-
That worked. IconClone Drag-n-Drop is fixed.
Now it converts the filename directly to Disk Object whether it comes from drag-n-drop or file requester. Its fully functional. :)
Next step is to add a small menu system to the user interface.
I hope we aren't having problems with ReqTools. I added an rtLong Requester to get "newicontype" by selecting menu item. The other menu items will be menu toggles for icon attributes.
I'm also adding support to display OS3.5 classic icon images. IconClone can Exchange OS3.5 Images as well as DualPNG.
-
Thanks, as already said it will be an indispensable tool to love using Wanderer on AROS !
-
Thanks, as already said it will be an indispensable tool to love using Wanderer on AROS !
For those who use Magellan they can already do Icon Exchange.
But for those of us who use Wanderer for AROS x86 & x86_64 there aren't many choices. But now we have a new icon tool. :)
-
As already said several times I have never used Magellan if not for testing, I like to stay in an Amiga environment, Dopus Magellan in my opinion is too dispersive and difficult to configure if you are not experienced users.
Recently on EAB has been opened a discussion Dopus4 vs Dopus5 where it is inferred that Dopus5 is not very appreciated by amigans.
https://eab.abime.net/showthread.php?p=1503647
-
The drag-n-drop feature is working now as well as the file requesters.
Also when selecting the dest file that is an unassociated file with no icon it gets a real def icon.
-
Ok drag-n-drop works fine with files, but it doesn't work with folder icons, the image swap works if you load the info file through the request.
I should add that a folder without an icon cannot have its image changed, probably because it does not use def_Drawer.info
Also found a very strange thing, after you have done a conversion with IconClone, if you click to activate an icon after a few seconds it automatically deactivates!
-
Ok drag-n-drop works fine with files, but it doesn't work with folder icons, the image swap works if you load the info file through the request.
I should add that a folder without an icon cannot have its image changed, probably because it does not use def_Drawer.info
Also found a very strange thing, after you have done a conversion with IconClone, if you click to activate an icon after a few seconds it automatically deactivates!
These issues seem to be AROS One related.
It works well on IcarosDesktop 64bit and 32bit. I'll investigate.
I noticed that when dragging a folder icon from the filesystem that is associated with a folder it won't drop correctly.
But if you copy that same icon by itself into a test directory it will work with drag-n-drop just fine. Maybe it's a limitation of Wanderer?
Or perhaps Wanderer is trying to drop the file itself onto IconClone? I will do some more testing to find out for sure.
Hmmm...It seems to be an AROS 32bit limitation. You can't drag an associated icon using Magellan in IcarosDesktop 32bit either. It won't work.
But dragging an associated icon in IcarosDesktop 64bit works just fine. The mystery is getting deeper. :)
P.S. - It seems that on AROS 32bit a trailing '/' is appended to the folder name whereas on AROS 64bit I assume there is no '/' just a file name. So I need to test for '/' and adjust my code.
Now we have to investigate what happens to real "def icons" on AROS 32bit. Maybe something similar is happening there. They don't work with the file requesters but they work on AROS 64bit.
-
With Magellan, things are more complicated because Dopus5 gets in the way and can confuse things even more. It has the same problems as Wanderer, after swapping images, the icon deactivates as soon as you right-click mouse.
Folders can't be swapped, plus Magellan doesn't store the saved icon position, Wanderer is ahead here with automatic positioning
AROS One that you are using includes the old Core, it doesn't change much but some old problems may have been fixed on Wanderer.
-
With Magellan, things are more complicated because Dopus5 gets in the way and can confuse things even more. It has the same problems as Wanderer, after swapping images, the icon deactivates as soon as you right-click mouse.
Folders can't be swapped, plus Magellan doesn't store the saved icon position, Wanderer is ahead here with automatic positioning
AROS One that you are using includes the old Core, it doesn't change much but some old problems may have been fixed on Wanderer.
As I mentioned AROS 32bit appends a '/' to the end of associated folder names but IconClone expects just a filename without .info extension. So I have to allow for that then it works. I will revise the code to look for '/' and remove it then add ".info".
There seems to be something odd about the defPicture.info file on AROS One. When I replace it with the one from IcarosDesktop then it works as expected. Custom icons can be an issue also.
Post a sample icon that you say "deactivates" after a given time so I can test it to find out why that may happen.
-
Made a small video with the "AROS-20180415-2-pc-i386" and the same thing happens as with AROS One x86, after a change of icon the icon once activated turns off deactivates alone, as if the left mouse button pressed by itself, this also happens with Magellan although more rarely, later I will try other Mouse just to verify.
Here is the video:
https://drive.google.com/file/d/14DdnnCQtSno7BsB44wJ46-_7L_Vy2ZRJ/view
-
Made a small video with the "AROS-20180415-2-pc-i386" and the same thing happens as with AROS One x86, after a change of icon the icon once activated turns off deactivates alone, as if the left mouse button pressed by itself, this also happens with Magellan although more rarely, later I will try other Mouse just to verify.
Here is the video:
https://drive.google.com/file/d/14DdnnCQtSno7BsB44wJ46-_7L_Vy2ZRJ/view
You have the window open when exchanging icons. After the exchange you must close it and re-open it. Or go up one to parent then back down again to refresh the icon display. That's the same on AROS x86_64. You have to refresh the icons.
-
Yes on the hardisk you solve in that way, if instead the icons are found in the RAM also to close the window the problem remains
-
Regarding the Hardisk you solve totally the problem increasing the stack in the Tooltype Icon
-
Regarding the Hardisk you solve totally the problem increasing the stack in the Tooltype Icon
The DualPNG Icon that is produced is exactly the same as the source icon except the 'icOn' chunk. But the attributes in the chunk should be copied over as well from the destination icon.
I don't have icon display problems on my end. Increase stacksize in destination icon and make sure it copies correctly.
-
No, I increased the stack on the Icon of IconClone with the value 12000 the problem automatic deactivation is solved if the icons are on HD, if the icons to swap are in RAM the problem remains.
-
No, I increased the stack on the Icon of IconClone with the value 12000 the problem automatic deactivation is solved if the icons are on HD, if the icons to swap are in RAM the problem remains.
Is this on AROS 68k or AROS x86 or something else? Amiga?
IconClone is not recommended for AROS 68k. There are other tools available to exchange icons on AROS 68k. Not needed.
-
With AROS One 68k it doesn't happen on HD, it only happens on RAM !
-
I've tested "IconClony" on AROS One 68k and I haven't found any problem both on HD and RAM.
-
With AROS One 68k it doesn't happen on HD, it only happens on RAM !
I'll try to duplicate the problem.
In the meantime I have solved the problem of drag-n-drop folders. There is the trailing slash '/' that must be removed. Then there are two types of "drawers" - one with an actual icon and the other with "no icon". The latter is represented by a "def drawer". The def icon doesn't exist but you can drag-n-drop it.
So if the drawer doesn't exist how can we display it or copy it? Just like we do when we use a file requester to open an unassociated file that gets assigned a "def icon" we do the same. Instead of "GetDiskObject" we use "GetDiskObjectNew" which works like this. If the icon exists we will use it. If not we get a default icon instead but that's just a Disk Object. What about the icon file. Now we test for the icon. Remember if it exists we used it. So it may be there or not. If we are using a def icon the icon file does not exist. For display purposes we use PutDiskObject to write the def icon to disk as our filename.
Now the default drawer icon exists and we can display it. ;)
-
Now that IconClone can handle standard icons as well as def icons including def tools and def drawers what would allow it to earn a reputation as best icon copier for high quality icons?
If we could simply drop an OS4.1 PowerIcon or an AROS Hybrid Icon on the source display area and have them immediately converted to PNG Icons from which to clone images that would be quite nice! The ability to clone OS4.1 icons into PNG icons.
I'm working on that as well as displaying & cloning OS3.5 icons.
-
Ok thanks miker, about the problem icon on/off I think it depends on the fact that the icon remains in use by IconClone, in fact the swapped icons can not be deleted "file in use".
-
Ok thanks miker, about the problem icon on/off I think it depends on the fact that the icon remains in use by IconClone, in fact the swapped icons can not be deleted "file in use".
That seems plausible.
Here is the revised version which allows drag-n-drop of folders. It was tested and is working with IcarosDesktop 32bit.
I had some problems with AROS One x86 v1.6 icon.library. It didn't like "GetDiskObjectNew" for some odd reason. So I replaced it with icon.library for IcarosDesktop. Now it works.
Please test this with dropping folders on AROS One x86. Let me know if it works.
-
Tested and it works fine with the icon.library of AROS One 1.6, I compared the two libraries (Aros One and Icaros) and they are of the same version, only the file size changes, my icon.library is the one included in the last deadwood distro "AROS-20180415-2".
It remains the problem of icons on/off if the icons are in RAM, on HD no problem
The CLI window opened "CON:" I think is only for testing purposes
On Wanderer there is a Bug that I had reported in the past, where on is not possible to delete single icons (without file or associated folder), these icons can be deleted only with Dopus4, these icons can't even be copied or moved!
-
AMIGASYSTEM
It's good to hear it is working on AROS One x86.
The icons in Ram: don't seem to be a major issue as long as they display & behave properly on disk.
The issue with Wanderer not copying, moving, deleting or renaming unassociated icons has been fixed in newer versions of Wanderer. Not sure if the latest Wanderer has been backported to AROS x86 yet. We might compare versions.
-
miker if it helps I found "Iconverter + sources" to convert many types of icons.
I tried to compile Iconverter on AROS One x86 and it seems to work fine !
https://www.morphos-storage.net/dl.php?id=1661783
-
miker if it helps I found "Iconverter + sources" to convert many types of icons.
I tried to compile Iconverter on AROS One x86 and it seems to work fine !
https://www.morphos-storage.net/dl.php?id=1661783
What? You don't like "IconClone"? :P
It seems to deal mostly with Old Icon Formats. The only Old Format I'm interested in is OS3.5 Icons.
I'm having fun with IFFParse Library reading the IFF Chunks from the OS3.5 Icon Files. It should work with PowerIcons also.
Then I will need to find out how to display the "ARGB Data Chunks" when they are present or just display OS3.5 Icon Images as ARGB. ;)
-
I'll use IconClone all my life :D
Iconverter does not serve AROS, I posted the source in case there is some useful information to add to IconClone
-
Anyone have experience working with IFFParse Library?
I have some code that isn't working but I don't know why. It is reading an OS3.5 Icon File but it can't find the chunks!
Do I need to open IFFParse.Library? I'm trying Sift.c in RKRM.
There is a working version of IconClone that I will finish up and I'll release it soon. I'm also working on an experimental version.
-
No if you are talking about IFFParse.Library code, if you are referring to the use of alloa applications yes!
Experimental version, what news we will find ?
-
No if you are talking about IFFParse.Library code, if you are referring to the use of alloa applications yes!
Experimental version, what news we will find ?
The experimental version has some advanced features such as dropping OS4.1 PowerIcons & AROS Hybrid Icons & Displaying them & Converting them to PNG Icons.
But I'm having difficulty with the IFFParse code to verify the ARGB Data Chunks. I attached Check_IFFType.c & a Hybrid OS3.5 Icon Sample.
I compiled "Sift.c" IFFParse sample program. When I ran it from CLI on my OS3.5 Icon File it reported an error:
"File Scan Aborted, error -10: Not an IFF file."
Hmmm...because there is old icon data preceding the IFF data it can't parse the file. So I will set file pointer to the IFF Data.
-
ParseIFF is working correctly now after some effort.
What I had to do is difficult to explain. It's a custom Hook Parser with a Custom Stream Handler.
The ParseIFF function reads the OS3.5 Icon File to determine if there are ARGB Data Chunks or just OS3.5 Image Data.
I wrote another function to read all the OldIcon data to get the correct offset to the beginning of the IFF OS3.5 Icon Data.
Then I can use IconControl to read the image data or ARGB data to display the images. It's a long process to display these icons. ;)
-
@miker1264
This is a great 'lil utility, thank for making it!
I spent some time using it today, and a lot longer time trying to find where the icons were buried within aros prefs! :)
I have two requests...
Can you tell me where the 'special' drawer icons hide (ie the drawer icons for prefs, system, tools, utilities etc) and also I have found (in aros x86, wanderer) that icons are named def-icons or end with .info. Are there others?
Lastly, it would be nice to have IconClone promoted a bit more, perhaps with a new announcement thread, or at the very least editing the first post with a preamble about it and the download itself. It was very much under the radar for me to find it as a newbie.
Thank you for your time
-
.
Can you tell me where the 'special' drawer icons hide (ie the drawer icons for prefs, system, tools, utilities etc) and also I have found (in aros x86, wanderer) that icons are named def-icons or end with .info. Are there others?
Wander works like Amiga OS3, if a file does not have its own real icon, the operating system will assign a default one.
System default icons called def_name type.info can be found in AROS:Prefs\Env-Archive\SYS.
The recognition of the file type and the association of the icon to a file "without icon" is defined by the Datatype/Descriptors.
It is possible to create/add new Def icons to the system, but in this case it would be necessary to new install Datatype/Descriptors as well.
On my AROS One for example, for each image, a specific icon is assigned, by default Wander assigns an identical icon for all image, but also for sounds, archives et....
-
That's great information, thank you! :)
-
@Glinx:
Besides what AMIGASYSTEM already wrote, you can also use XIcon/IconX and/or similar tools to modify behaviour to your liking (not depending on default icons and file type descriptors).
See aminet for those kind of tools.
For AROS ABIv0 i386 i wrote a tool named wbXli (see aros archives) that, in case you add a project icon for your file, can execute any tool for you provided that this tool accepts a file parameter in order to pass the name of the file to the program you wish to associate it with. I wrote wbXcli because it is easier to manage than tools like XIcon/iconX as they require a script to accomplish the same task.
-
Although other Icon Exchange Apps are available many users may prefer the simplicity of just using Wanderer.
So I have started a new module for Wanderer called "Exchange" to perform an icon image exchange from Wanderer. There will be a new menu item as well.
Icon Exchange will be very similar to using Icon Information and in fact both use the same basic Zune user interface.
Although I have limited experience writing Zunified Applications this will be my first major Zune module. The Tools directory in Wanderer is where these modules are located. The module "Info" is already there. Maybe after some research & lots of trial & error I can get Zune drag-n-drop to work correctly. ;)
The "Exchange" module interface will consist of the icon display area on top left just like Icon Information. Then at the top right is the Edit Box for source Icon with a small Browse Button on the right of the box. Below that is the Edit Box for destination icon with the same type of Browse Button. At the very bottom are the standard Zune buttons "Save" & "Cancel".
Of course this is experimental at the moment to see if it works.
-
Hmmm...
In the screenshot you can see that i added a menu item to Wanderer.
I haven't enabled it yet because I have to first link in to call the "Exchange" module.
The new menu item is located just above "Information" on the Icon menu.
-
Hmmm...
In the screenshot you can see that i added a menu item to Wanderer.
I haven't enabled it yet because I have to first link in to call the "Exchange" module.
The new menu item is located just above "Information" on the Icon menu.
(https://ae.amigalife.org/index.php?action=dlattach;topic=814.0;attach=4193;image)
Great, to add an entry in the Menu did you use any app/editors?
-
Hmmm...
In the screenshot you can see that i added a menu item to Wanderer.
I haven't enabled it yet because I have to first link in to call the "Exchange" module.
The new menu item is located just above "Information" on the Icon menu.
(https://ae.amigalife.org/index.php?action=dlattach;topic=814.0;attach=4193;image)
Great, to add an entry in the Menu did you use any app/editors?
Sure. :P
I used VSCode Editor to edit the Wanderer source code in several locations including the catalog file for menu items.
Adding menu items in Zune applications is not a simple matter.
-
Wanderer menu item has been enabled. 8)
But I still have to link it to call the Exchange module.
Then the fun begins writing the new functions. It seems easier to make a new module and add just a new menu item to Wanderer without changing much else.
Maybe after I figure out how Wanderer works I can add a few other items later. I'd like to update and extend the functionality of Name View (details). At the moment it doesn't look good (too small) and it doesn't do much.
There are a few changes in the works for Wanderer that are coming from backports from ABIv1 including changes that allow to move or copy items depending on which volume. Also I believe changes were made after that to allow moving, copying, renaming, deleting unassociated icons in Wanderer. I've also noticed that Edit Tooltypes in Icon Information doesn't work at times because of the internal text editor.
Additionally I'd like to add a green button near the Titlebar opposite the blue "Parent" button. The green button is for "Volume Root". When we navigate deep into perhaps System: instead of pressing Parent repeatedly just use the green button. We'll see how well that works. Just an idea.
Not sure if anyone else wants to make changes to Wanderer but this is just experimental and unofficial. If it all works well and if there is popular approval and if deadwood approves then I will submit the changes.
This time I'm making detailed notes. I lost my project notes for the updated MultiView but I still have the modified code. So I have to re-create all my changes then submit them.
-
Wanderer menu item has been enabled. 8)
Additionally I'd like to add a green button near the Titlebar opposite the blue "Parent" button. The green button is for "Volume Root". When we navigate deep into perhaps System: instead of pressing Parent repeatedly just use the green button. We'll see how well that works. Just an idea.
It would be very convenient to have some tools on the Window bar like the one in ScalOS or MOS, see small flooded video
Menu MOS
https://drive.google.com/file/d/1m7NLrJmZh93m1-YgojKrrwRO3JwBE61L/view?usp=share_link
-
Wanderer menu item has been enabled. 8)
Additionally I'd like to add a green button near the Titlebar opposite the blue "Parent" button. The green button is for "Volume Root". When we navigate deep into perhaps System: instead of pressing Parent repeatedly just use the green button. We'll see how well that works. Just an idea.
It would be very convenient to have some tools on the Window bar like the one in ScalOS or MOS, see small flooded video
Menu MOS
https://drive.google.com/file/d/1m7NLrJmZh93m1-YgojKrrwRO3JwBE61L/view?usp=share_link
I can't view the video file on my phone.
Do you have a screenshot?
The idea with Wanderer is to keep it super simple and clean.
In my opinion part of the elegance of Wanderer is simplicity.
Perhaps you mean the small icons (glyphs) that appear on the screen title bar on the right side by the screen depth gadget? That was another idea I had to look into. Not buttons just glyphs that indicate what processes are running or active.
-
Strange, I saved the video in a Standard mp4 for cell phone !
Taking a screenshot of the Menus on QEmu is a bit complicated, I have uploaded the video to Youtube, I hope you can see it:
https://youtu.be/JgT5Y_Di9YY
-
Strange, I saved the video in a Standard mp4 for cell phone !
Taking a screenshot of the Menus on QEmu is a bit complicated, I have uploaded the video to Youtube, I hope you can see it:
https://youtu.be/JgT5Y_Di9YY
I was able to see that one.
Wanderer already has a menu system and navigation is quite easy. Maybe the extra buttons work well in MOS.
-
Yes they are very convenient, Wanderer has two modes, one is to automatically sort the Icons, the other is the old OS3 method where the user has to memorize the positions of the icons "to all windows".
However if you change the view from Icons to Detail, this is stored for all windows, and each time you have to right click Mouse which is more inconvenient than the menu which you do it on the fly with one click
Also in the Menu of MOS there is a Thumbnail option, which is very convenient when you have to examine many images in a window.
Another thing that is missing on Wandere is opening the windows of a Volume, which will then inherit all the other windows opened on the same Volume.
Initially I had this problem when I was creating the ISO, then I solved it by saving to all Def_Icons, position and window opening size, In fact you may have noticed on AROS One DVD that all volumes open a window of the same size with the icons all sorted.
-
Another thing that is missing on Wanderer is opening the windows of a Volume, which will then inherit all the other windows opened on the same Volume.
Initially I had this problem when I was creating the ISO, then I solved it by saving to all Def_Icons, position and window opening size, In fact you may have noticed on AROS One DVD that all volumes open a window of the same size with the icons all sorted.
I haven't checked that out yet but that's good to know.
Also it doesn't seem necessary to have the current location in two places. It seems redundant. It is in the Locations Box (Address Box) & in the Window Title. So I would change the Window Title to simply "Wanderer".
It seems like we should have a method to type a new location and then go there. The Locations Box at top should be an edit box. We don't need a "Go" button just press the Enter Key. Whatever path is showing in the text box Wanderer should just go there to make navigation easier.
We should try to make it more useful & more user-friendly.
The Icon Exchange menu item is working. Now I have to work on the WBExchange module and the user interface.
-
There are a few changes in the works for Wanderer that are coming from backports from ABIv1 including changes that allow to move or copy items depending on which volume. Also I believe changes were made after that to allow moving, copying, renaming, deleting unassociated icons in Wanderer. I've also noticed that Edit Tooltypes in Icon Information doesn't work at times because of the internal text editor.
These functions are already present on the latest Build D14, and are already part of the upcoming AROS One v2.0
-
There are a few changes in the works for Wanderer that are coming from backports from ABIv1 including changes that allow to move or copy items depending on which volume. Also I believe changes were made after that to allow moving, copying, renaming, deleting unassociated icons in Wanderer. I've also noticed that Edit Tooltypes in Icon Information doesn't work at times because of the internal text editor.
These functions are already present on the latest Build D14, and are already part of the upcoming AROS One v2.0
Thanks. I will probably use that version of Wanderer as the base code for development & testing.
This is what I would like the Wanderer Icon Exchange GUI to look like. I made this mockup in a paint program. I do that for all my AROS GUI projects. It makes it easier to take measurements when making the actual user interface.
Now I must research MUI/Zune user interface setup to figure out how to make the mockup into a real program module. Of course the "Dest icon" label on top should be "Srce icon". I missed that little detail. :)
It's much easier at the beginning when I have a clear goal.
-
Yes it happens to me too, you finish something and only later you realize that something is not perfect, then you consume more time to improve it than to create it :)
-
I fixed the artwork. The labels are correct now. 8)
I'm still working on the MUI/Zune user interface. It's a work in progress. I may rename the 'Save' button as 'Change'. When pressed the images of Dest icon will visually change.
Only the filenames will appear in the Edit Boxes for simplicity.
As far as the problem I'm having with icon exchange at the command line there is no problem when started from Workbench. Since Wanderer is Workbench it should work.
As far as Wanderer behavior when we select View> ALL Files for example then that should apply to all directories in the volume until it is changed or until the volume is closed and re-opened, Then it should reset itself to VIew> Icons only as standard. Seems to be the predicted behavior. Need to test.
We should keep an eye on the drag border when dragging icons to make sure there is no distortion.
When icon images change for example the changes are immediate. That is a very nice feature.
I wonder if we exchange icon images of an icon while it is being displayed in Icon Information will that image also change immediately? The changes to Wanderer icons are immediate.
We need an MUI/Zune user interface designer like Visual Studio Designer. Within 30 min you could setup & fine-tune a beautiful user interface then output the window code. 8)
-
Here's an amusing story, well it is to me!
I was very satisfied with the new menu item in Wanderer and the WBExchange (Icon Exchange) module that should have worked. But I was using IcarosDesktop x86-64 to test the changes. But every time I right-clicked a test icon and selected Exchange on the Wanderer Icon menu it crashed.
I thought "Wow! I must have really messed up!" But then I realized why that was happening. I'm using an older version of Wanderer. This problem has since been fixed.
The test icon was an unassociated icon. There was no file or directory associated with the icon. Once I realized that I simply chose an icon associated with a real drawer and the menu item worked and the Exchange user interface popped up.
Whew! ;)
-
Thanks in the meantime on Aminet I found the source of seticontype that I compiled with Murks on AROS One x86, the compilation was successful.
Tried the seticontype executable and it works perfectly, it converts the icon type to all icons including OS4, but it doesn't recognize and works only with DualPNG :(
http://aminet.net/package/util/wb/seticontype
It will work with Classic Amiga Icons but not PNG icons. For PNG most likely there is no "type' defined in the icon chunk. Icon Library guesses based on criteria what the type is.
But the type can be defined with a tag ID in the icon chunk. But it isn't as easy as changing the type. If you change a drawer to a project you still have drawer data & no default tool.
-
Ooops! The icon picture is in the wrong place and it's the wrong icon.
Well I guess my MUI/Zune coding for user interface making needs a little work. ;)
But that solves one major issue. I was confused why including IconImageObject caused the code to refuse to compile.
I realized though by looking at MUI classes online that IconImageObject was missing. So it must be a custom class.
After I added the <zune/iconimage.h> include file it worked, well kinda.
Also the image change for IconImageObject is not automatic so I will have to make it re-display somehow. Getting drag-n-drop to work is another issue.
-
The real MUI/Zune user interface is complete. 8)
Now the buttons need some more code to make them work.
it seems that Zune programming is more interesting than GadTools or just a simple window.
Maybe it's more satisfying when it works because it takes much more effort to make it work correctly.
-
Nice !
-
It looks good so far but I still need to add the Browse Buttons at the end of the Edit Boxes. Not too difficult.
I will give myself 4 weeks to come up with a working Icon Exchange module for Wanderer. That's my current goal.
But I've reached my first hurdle that I need to overcome. In order for it to work properly I need to re-display the Dest Icon Image on the bottom after the exchange.
But the IconImageObject is a custom class that only goes One Way. We supply a filename then open the window & the image is drawn. I don't see any way to force a redraw unless I use an Image object. So I have some more research to do.
-
AMIGASYSTEM
What is the rename error that you reported earlier?
It has gotten lost in all the messages. :-*
-
On Wanderer you cannot Rename a File from Lower Case to Upper Case and vice versa, you cannot even rename a single letter from Lower Case to Upper Case.
No problem from Dopus4, where you can rename !
-
On Wanderer you cannot Rename a File from Lower Case to Upper Case and vice versa, you cannot even rename a single letter from Lower Case to Upper Case.
No problem from Dopus4, where you can rename !
Since I'm already working with the Wanderer source code I can take a look to identify the problem.
The Rename module in Wanderer/Tools is very basic. The end result is that after the user enters the new name it calls Rename(old name, new name); So the actual DOS Library Rename function may have an issue. Not sure yet but I will look. Does it still happen with deadwood's newest Wanderer? Maybe that has been fixed already.
What happens if you try to rename in the shell to all uppercase or all lowercase? Just curious if it's a Wanderer problem or much deeper than that.
-
Since you are working on Wanderer's code, it would be useful to assign a function key to -> Menu - Icon - Delete, for example the "Delete" key would be fine.
This would be very convenient when you want to delete one or more icons, this is a function that exists on all OSes.
Also it would be nice to have a Comado Refresch from Wanderer as well, we have already talked about this.
-
Since you are working on Wanderer's code, it would be useful to assign a function key to -> Menu - Icon - Delete, for example the "Delete" key would be fine.
This would be very convenient when you want to delete one or more icons, this is a function that exists on all OSes.
Also it would be nice to have a Comado Refresch from Wanderer as well, we have already talked about this.
The first one sounds reasonable with the shortcut key for delete. But what is Comado Refresch ? Is that Italian? ;-)
-
I made a mistake I meant to write "refresh," in Italian it translates to "rinfrescare", though it would be more correct to say Update, translated Italian "Aggiornare"
-
Maybe you mean a Window "Refresh..." To redraw the icons in the window. Isn't that what Window->View->Cleanup does? I will look into that.
BTW I narrowed down the rename problem.
On IcarosDesktop 64bit I was able to rename a file & it's icon from mixed case to all uppercase to all lowercase in the shell. The Rename command had no issues and it was perfectly case sensitive.
However in Wanderer I selected an icon then Rename from the menu. When I tried to rename to all uppercase for example there was an error. "File already exists.". The problem is that the WBRename module isn't case sensitive so "HDToolBox" = "hdtoolbox" = "HDTOOLBOX". These are all the same to Wanderer.
So the Rename module may need to be updated.
-
On IcarosDesktop 64bit I was able to rename a file & it's icon from mixed case to all uppercase to all lowercase in the shell. The Rename command had no issues and it was perfectly case sensitive.
Yes it is normal that IcarOS with Dopus Magellan has no problem, also Dopus4 has no problem renaming, because these Filemanagers use "Rename" "Internal" command, also AROS Shell works great and you can rename in all ways :D
So the Rename module may need to be updated.
It would also suffice if he used the Rename command
-
Wanderer Icon Exchange development is coming along slowly.
Thanks to assistance from deadwood it may be possible to get the icon images to display and re-display correctly.
As for the icon image exchange code, it's already working.
This is my first MUI/Zune application so the assistance is greatly appreciated.
-
This is the StrDup correction for MUI/Zune window titles. Thanks to Mazze for finding this. 8)
/* the window class doesn't copy the title so we must
create a copy by ourselves to avoid corrupt window title */
tmpfilename = StrDup(filename);
set ( globalActiveWindow->win, MUIA_Window_Title, tmpfilename );
set ( globalActiveWindow->projName, MUIA_String_Contents, tmpfilename );