however the Flood Fill is hard to implement right now. Notice that the program is used for precise painting of small pictograms so flood fill is not that neccessary!
Sure, but old one have it, so just to make fully 100% replacement without any single loose, will be not bad to have flood fill and filled ellipse :)
Btw, after i play with editor, i think that "bubble-help" can help a lot for all the newbes. As far as i remember its should be easy to add (like one more TAG to the created object, and char "there is bublehelptext" ). So users who dont like to read readmes/guides (90% of all the users:) ) , will understand what do that and that button. There is not so many buttons in general, about 20 in summ, but you will see yourself how cool it when you have bubbles : you just move cursor on it, and you know already what its do (if for example, by image user not understand for what need it that and that button, and lazy to read guides).
But not big deal of course. Its already fine enough, just to make everything "very good" :)
--- From readme.txt --- The program writes the configuration of windows and palette to configuration file "S:IconEditor.config". --------------------------- While some older programs did write their config files in S:, this practice has never been encouraged. The S: directory is meant for scripts (hence the name, S:). I'd recommend storing your config in PROGDIR: or, alternatively, ENV(ARC):
Anyway, the program really looks good and is very stable. I hope more people will join in and send their donations too.
> ctrl+z (still its rokz and intuitive after all other oses)
Yes, so now we have RAmiga-C for Copy and CTRL-Z for Undo. How intuitive is that? Seriously: if we want to imitate another OS, like Windows, let's do this consistently.
> can load any type of other images
I've just noticed that PNG transparency is not supported yet - this would be a very welcome addition!
> will be cool to have ability to make active any window from all of them > Just because sometime working window are placed over the project > one, or paletter one, or toolbar one, and while i see part of those > windowses, and want to make them active, i cant , and i should > move /resize main window, to make them visibly
Robert apparently uses the new WA_ToolBox tag. Windows defined with this tag cannot be activated, which can be an advantage in a multi-window GUI (like IconEditor's) because you don't need to handle access to the main menu. Traditionally, the program's main window has a menu strip attached to it. By activating another window (eg. a toolbox) you lose access to the main menu, and either the user has to re-click on the main window (which is annoying), or you have to employ programming tricks to share the main menu among all the windows. WA_ToolBox spares you from this.
But I understand what you mean. Although the problem here is not that the windows cannot be activated but rather that they cannot be brought to front by clicking on their title bar.
If you miss flood fill I've got a solution. I can introduce filled polygons because I can implement it using standard graphics.library area fill functions. Flood() apart from that it doesn't work on 32-bit bitmaps doesn't make much sense on them because of the variety of colours used.
So filled polygons would be the solution. Of course filled ellipse would be done the same way Is it OK for you?
So filled polygons would be the solution. Of course filled ellipse would be done the same way
So then for user it will just works like the same old flood-fill and filled eclispe ? (just a bit different from code site, right ?)
Quote:
Is it OK for you?
For me all is ok even as you have it already :) I just about making "perfect replacement" :)
@Trixie Quote:
But I understand what you mean. Although the problem here is not that the windows cannot be activated but rather that they cannot be brought to front by clicking on their title bar.
Yeah, exactly. Let's it be not activated , just should bring on front when use dbl-click on it.
I fixed the loading of images with alpha mask for example PNGs. Thanks for the report.
@Kas1e
I introduced Filled Polygon tool to the program. It works like in common Paint programs - you select points of the polygon by mouse and they are connected by lines then when you select the first point once again the filled polygon is created.
This patch (v1.5) available shortly on OS4Depot. It also fixes some noticed bugs and the configuration is now saved to the directory of the program.
@Robert Tested new verison: filled polygons works and its nice to have :) hope you can make the same for flood fiil and for filled eclispe. While filled polygons can be "nice to have", still its not so necessary as flood fill (flood fill imho the most usable tool in all the editors, because by it you can do deleting, filling, and all the other nasty stuff).
btw, found 2 bugs with filled-poligons :
1. try to do something with it, and then press on any tool-button : all what you do with filled-polygons will be erased.
2. try to choice 20 points with filled poligons, and when you will press 20st time, all will be reacts like flood-fill.
Btw, maybe will be not bad idea to "high-light" first point somehow (so user will see where need to press at end, to fill the area.
Anyway, are you sure that you see no way to introduce normal-classic-flood fill and filled eclipse ? Maybe just with usage of your filled-polygon function, make a wrapper which will for end user just do flood-fill and filled eclispe ?
As you probably heard the bounty is complete and the sources under MPL license are uploaded to OpenAmiga SVN repository. I'd like to thank to all the donators! Thanks for your support. I hope I made the product that satisfies your needs. If something is missing then don't worry - I'll try to upgrade the program in the near future.
I'd like to hear how's with the product? Is it working OK and is it good enough to create some simple icon sets?
P.S.
If someone is interested in the sources here's my page related to the project!
For 2 days of testing i have no single crash or stability issues, all works fine. For me it still looks a bit unfinished, and imho, for making it ready to shiping with the OS, still need:
-- Design previews window well (at last centred and splitted those 2 parts).
-- Palette limited to 32 pens (if you do not want to add for now all those tooltypes, the just make 64 by default)
-- No flood fill and filled eclipse :) For my imho it can't be called "full replacement" while there is no one of necessary tools: flood fiil.
-- Mouse wheel support for main window.
-- Window mode (yeah, i know you say there is prolbems, but they for sure can be fixed somehow or workorounds can be made).
-- Making toolbox/project/palette windowses jumps on front when you click on them.
-- Highlight first point when you use filled-poligons
And so on ..
Its the programm which can be shipped with OS, so it should looks cool, reacts cool, and designed cool in every aspect. Its very stable, and almost done, but imho still need some tweaks there and there to make it perfect and ready for.
Dunno, for me its was a bit early to say "bounty complited" , but its anyway pretty good already. No need anymore to use any of those converters, i can just load png icons to it and make aos4 native ones :)
- Some tooltips that explain the functionality of the various buttons, long Amiga users may know all buttons thanks to experience but not all Amigans know well such type of programs (almost not me) it's a bit difficult to understand the effects and the various functionality of all that buttons, some bubblehelps (tooltips) can be a lot helpfull here
- Add a VERSION support or almost an about window to recognize the revision version or the program, ok not so important but still nice ...
- Some cosmetics here and there ... well a better interface in general would be nice altrough of course this could be purely subjective ...
Aniway it was a nice job for sure, bravo
Edited by samo79 on 2011/4/12 10:18:11 Edited by samo79 on 2011/4/12 10:19:19
I am really impressed and satisfied with your work on the Icon Editor. It is a perfect example of a successful bounty project. If only more OpenAmiga projects had this much steam!
My only minor compaint (sorry for repeating myself, I am NOT obsessed by it - just presenting a point of view) would be the Undo solution. Edit operations (Undo, Redo, Cut, Copy, Paste) should really have the same qualifier key, otherwise you create a mess.
As for your explanation that RAmiga combinations activate menu commands: yes, that's right, and I do think you should put Undo and Redo to the menu. For what I can see, the Icon editor has at least three edit operations (Undo, Redo and Copy Image), which justifies the existence of an "Edit" menu in the strip. On the other hand I would do away with the "Images" menu: Copy is an edit operation, and Load Image might be happier in the Project menu.
I consider the bounty complete but hope Robert considers the points Trixie and Kas1e made for future updates.
As Trixie says this OpenAmiga/amigabounty project has been done in an almost perfect way with great communication from the developer and valuable input from testers/users (thanks to Robert, Kas1e and others).
I've been playing with the editor and managed to create my first simple icon in it. It looks like hand-made icon but is very colorful. I found that the division on several windows is good because sometimes I wanted the preview be placed to the left of edit window. I made also use of the multi-color palette.
I found also that the program is working fine, but to make it working 100% fine (and to make it professional paint program) I'm thinking about :
- implementing layers to the program, i.e. the picture is divided on several layers and blitting is done to the one layer, so you can make templates and it enables many new possibilities, - implementing real alpha level on which the pencil draws new pixels to the image, so the pixels and the active layer are mixed together, - implementing brush handling, - implementing saving to the image format (for example PNG).
All this should be done in v2.0.
@Kas1e
Window mode - fine, but I think that I can just merge together Project, Edit and Toolbar, the Preview and Palette should remain as separate windows. I agree that Preview Window needs some correction, I will provide this window sizeable for example. If it comes to color wheels then it's no problem to add such support. As for highlighting the first point of filled polygon I was thinking about closing the polygon with a key like space bar.
As for number of colors in the palette let me cite the documentation: PALETTE STYLE The usability of a palette gadget decreases as the number of colours it is displaying increases.
So I think that 32 entries are just fine.
@Samo79
Bubblehelp seems to be very easy to add so I will consider adding them in a next release. Version displaying will be added too.
@Trixie
All right, I will bind the RAmiga + Z to undo and RAmiga + Y to redo. As for making some suggested fixes to the menu I will make them in next release.
Good to know about TODO, but what is strange is that:
Quote:
PALETTE STYLE The usability of a palette gadget decreases as the number of colours it is displaying increases.
Dunno what all of this mean about increasing/descreasing and limiting to 32 cols in palette. But lodepaint, AmiFIG, Grafx or any other painter never limited to 32 cols , and they works in window-fullscreen modes, without any limits about decreasing/increasing and you can use as many colors as you wish.
Imho will be cool just have ability to use 32/64/128 cols palettes. 64 cols palette will looks by default just good, and not so limited and "old" like 32 bit one. Your first versions of icon-editor use 64palettes , so why not add them again ? Its looks nasty, more good fitted to design, banks are smallers and looks more nicer.
In end you can add tooltype you say before, so user can choice how much banks have in palette, but imho , remember as it was with first versions, 64 cols palette are good enough.