grafx2 - Project Hosting on Google Code

Last 7 days Dec 09, 2009 issue 153 (Unsafe fileselectors) Status changed by yrizoud - In progress. Giant change of all loadsave, fileformats, miscfileformats, filesel. I'm in global variables hell. Status: Started In progress. Giant change of all loadsave, fileformats, miscfileformats, filesel. I'm in global variables hell. Status: Started Dec 08, 2009 issue 275 (Mouse starts moving by itself) commented on by pulkomandy - This (acceleration) definitely looks like the joystick input going mad. This (acceleration) definitely looks like the joystick input going mad. Dec 08, 2009 issue 275 (Mouse starts moving by itself) commented on by anibiqme - Yes, mouse movement continues after grafx2 gets focus back. Just recently I witnessed that it can go to leftward too. I have never seen it go downwards, but I suspect that's also possible. Movement starts slow, then accelerates up to certain (rather fast) speed. Using mouse moves pointer on screen, but the overall effect is like having another mouse (joystick?) constantly moving to one direction. (even hitting the quit button on controls panel becomes a kind of sport at that point :P) Unfortunately I don't have a joystick I could test with this machine. Yes, mouse movement continues after grafx2 gets focus back. Just recently I witnessed that it can go to leftward too. I have never seen it go downwards, but I suspect that's also possible. Movement starts slow, then accelerates up to certain (rather fast) speed. Using mouse moves pointer on screen, but the overall effect is like having another mouse (joystick?) constantly moving to one direction. (even hitting the quit button on controls panel becomes a kind of sport at that point :P) Unfortunately I don't have a joystick I could test with this machine. Dec 08, 2009 issue 277 (Color reduction to a preset palette) reported by yrizoud - On loading a 24bit picture, I suggest GrafX2 would open a panel where the user chooses which palette to use: - new adaptive palette (current behavior) - adapt to current palette - maybe, propose a "web-safe" 332 RGB palette as well (I mention it because it has extremely fast conversion, we use it for preview) The 2nd choice is new. It would keep the current palette before the loading, and color-reduce the image to it. This would be very useful to convert several images, initially in RGB, to the same, fixed palette. First you would create a significant sample of graphics, using the Gimp for example. Then you could load it in Grafx2 with adaptive method to generate the common palette. Reorder the palette as needed, then you can use the new function to load-convert any RGB file to this palette. Optionally, the conversion could take into account the "tag colors to exclude" settings: Excluded colors would not be obtained by the color reduction. It can be useful if you have a few color indices in the palette that you use for special effects and don't want the conversion to pick them. This part is really not mandatory, because you can always use the color-replacer tool after conversion to change some colors globally. Or before converting many files, load a variant of the palette where the colors to exclude have some improbable RGB values that shouldn't be auto-picked, like neon pink. On loading a 24bit picture, I suggest GrafX2 would open a panel where the user chooses which palette to use: - new adaptive palette (current behavior) - adapt to current palette - maybe, propose a "web-safe" 332 RGB palette as well (I mention it because it has extremely fast conversion, we use it for preview) The 2nd choice is new. It would keep the current palette before the loading, and color-reduce the image to it. This would be very useful to convert several images, initially in RGB, to the same, fixed palette. First you would create a significant sample of graphics, using the Gimp for example. Then you could load it in Grafx2 with adaptive method to generate the common palette. Reorder the palette as needed, then you can use the new function to load-convert any RGB file to this palette. Optionally, the conversion could take into account the "tag colors to exclude" settings: Excluded colors would not be obtained by the color reduction. It can be useful if you have a few color indices in the palette that you use for special effects and don't want the conversion to pick them. This part is really not mandatory, because you can always use the color-replacer tool after conversion to change some colors globally. Or before converting many files, load a variant of the palette where the colors to exclude have some improbable RGB values that shouldn't be auto-picked, like neon pink. Dec 07, 2009 r1237 (Implemented back the Mask mode. Fixed a historical bug of me...) committed by yrizoud - Implemented back the Mask mode. Fixed a historical bug of memory violation if you used Mask with images of different sizes (would crash all platforms except DOS) Implemented back the Mask mode. Fixed a historical bug of memory violation if you used Mask with images of different sizes (would crash all platforms except DOS) Dec 07, 2009 issue 275 (Mouse starts moving by itself) commented on by pulkomandy - Actually, there seem to be mouse drift for some other people, under linux it can be easily caused by having a joystick port with nothing plugged in as then you don't calibrate the empty port and the joystick will always report unuseable values. So yes, it seems a good idea to disable it except for gp2x. Actually, there seem to be mouse drift for some other people, under linux it can be easily caused by having a joystick port with nothing plugged in as then you don't calibrate the empty port and the joystick will always report unuseable values. So yes, it seems a good idea to disable it except for gp2x. Dec 07, 2009 issue 275 (Mouse starts moving by itself) Labels changed by yrizoud - Does the abnormal movement start again when GrafX2 has focus again ? (If it does, the program is unusable and it's a fatal problem on this platform) I suspect it's caused by Grafx2 detecting a permanent joystick movement, and moving the cursor accordingly. I've had related issue, but it was subtly different: mouse cursor "quivering" at random moments, moving by a few pixels as if held by a shaking hand. It was caused by my 2$ joystick plugged in and reporting random noise near its center point. The effect was much less severe, and I could disable the joystick in Windows settings. Even with no joystick actually plugged in, a few electric interferences on the game port can be enough to report a position change. We made some compilation option to disable joystick, but I guess we should make a setting for it, and disable it by default on all platforms except GP2X. Labels: −OpSys- Does the abnormal movement start again when GrafX2 has focus again ? (If it does, the program is unusable and it's a fatal problem on this platform) I suspect it's caused by Grafx2 detecting a permanent joystick movement, and moving the cursor accordingly. I've had related issue, but it was subtly different: mouse cursor "quivering" at random moments, moving by a few pixels as if held by a shaking hand. It was caused by my 2$ joystick plugged in and reporting random noise near its center point. The effect was much less severe, and I could disable the joystick in Windows settings. Even with no joystick actually plugged in, a few electric interferences on the game port can be enough to report a position change. We made some compilation option to disable joystick, but I guess we should make a setting for it, and disable it by default on all platforms except GP2X. Labels: −OpSys- Dec 07, 2009 issue 171 (toggleable tile grid) commented on by yrizoud - I can only guess this version which was compiled from a work-in-progress 2.1, before the grid was implemented. You can see the exact svn number in the Statistics screen (right-click the Help icon). I started on the grid on r1007. I can only guess this version which was compiled from a work-in-progress 2.1, before the grid was implemented. You can see the exact svn number in the Statistics screen (right-click the Help icon). I started on the grid on r1007. Dec 07, 2009 issue 276 (Can't open this png) commented on by cameron...@comcast.net - Whoops! Just saw the fix for r1236. I'll check it out when I get home. I'm sure that'll fix it. Sorry! Whoops! Just saw the fix for r1236. I'll check it out when I get home. I'm sure that'll fix it. Sorry! Dec 07, 2009 issue 276 (Can't open this png) reported by cameron...@comcast.net - Attached. I think I'm using r1234. I get a red screen, almost like an error, and it loads for a second. When it's done, I get a solid red canvas that seems to be the correct size for the image. Attached. I think I'm using r1234. I get a red screen, almost like an error, and it loads for a second. When it's done, I get a solid red canvas that seems to be the correct size for the image. Dec 06, 2009 issue 275 (Mouse starts moving by itself) reported by anibiqme - When I start the program, the mouse starts to move by itself either up or right. If I change the active program, movement stops. Sometimes (especially if starting the program first time after booting) this does not occur. I'm using Karmic Koala with repository-installed grafx2. Computer is HP Mini 5101, and I also use Logitech MX510 usb mouse. Having the mouse plugged in at grafx2 startup or computer boot does not seem to make any effect. Milestone-2.0 OpSys-UbuntuKarmicKoala When I start the program, the mouse starts to move by itself either up or right. If I change the active program, movement stops. Sometimes (especially if starting the program first time after booting) this does not occur. I'm using Karmic Koala with repository-installed grafx2. Computer is HP Mini 5101, and I also use Logitech MX510 usb mouse. Having the mouse plugged in at grafx2 startup or computer boot does not seem to make any effect. Milestone-2.0 OpSys-UbuntuKarmicKoala Dec 05, 2009 issue 171 (toggleable tile grid) commented on by tomasz.mielnik - I use 2.1 version (downloaded one from other thread here). I try to compile 2.2 on Mac but no success yet (I reported problems that I've found on other thread aswell) And again, in the general help window there's Grid menu: Grid mode: but no Grid view I use 2.1 version (downloaded one from other thread here). I try to compile 2.2 on Mac but no success yet (I reported problems that I've found on other thread aswell) And again, in the general help window there's Grid menu: Grid mode: but no Grid view Dec 05, 2009 issue 171 (toggleable tile grid) commented on by pulkomandy - Which version are you using ? I'm not sure the full grid mode functionality made it into 2.1 version... Which version are you using ? I'm not sure the full grid mode functionality made it into 2.1 version... Dec 05, 2009 issue 171 (toggleable tile grid) commented on by yrizoud - Not in help? It should be present both in the general Help index (about at 2/5th, called "Grid view") and also in the Grid menu's help screen (scroll down a little) If it appears, maybe it's a combination that isn't usable on MacOSX. You can check by changing any shortcut to Alt+Shift+G. If the program ignores your attempt, it means it can't "see" this combination. Not in help? It should be present both in the general Help index (about at 2/5th, called "Grid view") and also in the Grid menu's help screen (scroll down a little) If it appears, maybe it's a combination that isn't usable on MacOSX. You can check by changing any shortcut to Alt+Shift+G. If the program ignores your attempt, it means it can't "see" this combination. Dec 05, 2009 issue 171 (toggleable tile grid) commented on by tomasz.mielnik - nope.. its not the case I guess. the shortcut for viewing the grid which on windows is ALT+SHIFT+G doesn't seams to be implemented. there's no information about it in help (F1) and the shortcut doesn't work either. it does on windows and on mac it's weird but it doesn't. nope.. its not the case I guess. the shortcut for viewing the grid which on windows is ALT+SHIFT+G doesn't seams to be implemented. there's no information about it in help (F1) and the shortcut doesn't work either. it does on windows and on mac it's weird but it doesn't. Dec 05, 2009 issue 171 (toggleable tile grid) commented on by yrizoud - Grid is only displayed in the zoomed view (Magnified) Or maybe your palette appears to have same colors at 0 and 255, 1 and 254 etc. Grid is only displayed in the zoomed view (Magnified) Or maybe your palette appears to have same colors at 0 and 255, 1 and 254 etc. Dec 05, 2009 issue 171 (toggleable tile grid) commented on by tomasz.mielnik - Grid view mode seams not working on Mac OS X? I can't set the grid visible on mac... is there any rationale behind this or is it me who cant make it visible? Grid view mode seams not working on Mac OS X? I can't set the grid visible on mac... is there any rationale behind this or is it me who cant make it visible? Dec 05, 2009 issue 188 (XCode project doesn't work) commented on by tomasz.mielnik - The whole .app bundle is build correctly (see the attached and zipped .app) The build process of Xcode creates all bundle by itself and it's plaved in build/Debug dir which is all correct. one thing might be thet i copied a grafx.cfg file from some other build (downloaded from this site). Xcode was complaining about this file beeing missing (btw make tool with Makefile can't finish also because there's no grafx2.cfg) I attach my build - so please anyone try it and say if it wotks for you. I'll prepare files for svn tommorow. The whole .app bundle is build correctly (see the attached and zipped .app) The build process of Xcode creates all bundle by itself and it's plaved in build/Debug dir which is all correct. one thing might be thet i copied a grafx.cfg file from some other build (downloaded from this site). Xcode was complaining about this file beeing missing (btw make tool with Makefile can't finish also because there's no grafx2.cfg) I attach my build - so please anyone try it and say if it wotks for you. I'll prepare files for svn tommorow. Dec 05, 2009 issue 188 (XCode project doesn't work) commented on by yrizoud - Thanks for the report. I'm not a Mac user and have much trouble determining what works for who. The data (like the "skins" directory) is searched in the "Contents/Resources/" directory, relative to the place where the executable is (built). It's a directory tree for a bundle, but I don't know if you have to place files manually, or if there's a script to do it automatically. If you can provide the files where you did the modifications (Grafx2.xcodeproj complete directory, Grafx2_prefix.pch, .DS_Store), I'll update the svn. Any help making the MacOSX version work is welcome. Thanks for the report. I'm not a Mac user and have much trouble determining what works for who. The data (like the "skins" directory) is searched in the "Contents/Resources/" directory, relative to the place where the executable is (built). It's a directory tree for a bundle, but I don't know if you have to place files manually, or if there's a script to do it automatically. If you can provide the files where you did the modifications (Grafx2.xcodeproj complete directory, Grafx2_prefix.pch, .DS_Store), I'll update the svn. Any help making the MacOSX version work is welcome. Dec 05, 2009 issue 188 (XCode project doesn't work) commented on by tomasz.mielnik - I had the same problem with Xcode as described in first post. The thing is that you have to add paths to png includes nd png library itself. in my environment it in /usr/X11/lib and /usr/X11/include. The next problem that shows up after that (and it took me a bit longer to figure out). Files like: fileformats.c, miscfileformats.c libraw2crt.c./.h brush_ops.c are not added to Xcode project file so the compiler/linker cant find them. Final thing which still doesn't work for me is that after successfull compiling and linking the app can't run and it says on console that the gui file (i guess one of the themes form .png files) cant be found. I've checked and everything is inplace. any ideas? I'm talking about latest trunk from svn of course. I don't have a write access to svn so please someone fix things that i described above. Besides I'm a graphician and i just want to use grafx2 ;) I had the same problem with Xcode as described in first post. The thing is that you have to add paths to png includes nd png library itself. in my environment it in /usr/X11/lib and /usr/X11/include. The next problem that shows up after that (and it took me a bit longer to figure out). Files like: fileformats.c, miscfileformats.c libraw2crt.c./.h brush_ops.c are not added to Xcode project file so the compiler/linker cant find them. Final thing which still doesn't work for me is that after successfull compiling and linking the app can't run and it says on console that the gui file (i guess one of the themes form .png files) cant be found. I've checked and everything is inplace. any ideas? I'm talking about latest trunk from svn of course. I don't have a write access to svn so please someone fix things that i described above. Besides I'm a graphician and i just want to use grafx2 ;) Last 30 days Dec 03, 2009 issue 274 (Symmetry function like in Deluxe Paint) commented on by yrizoud - I remember it. The flower-like symmetry is a fun toy, and fun is good. I remember it. The flower-like symmetry is a fun toy, and fun is good. Dec 03, 2009 issue 274 (Symmetry function like in Deluxe Paint) changed by pulkomandy - Ok, then it would be linked (somewhat) to tile mode. Status: Accepted Labels: OpSys-All Milestone-2.3 Ok, then it would be linked (somewhat) to tile mode. Status: Accepted Labels: OpSys-All Milestone-2.3 Dec 03, 2009 issue 274 (Symmetry function like in Deluxe Paint) commented on by eh...@gmx.de - In Deluxe Paint, you had a feature where you tell the program to use symetry while drawing.So that instead of one 1-pixel-brush you had a second "on the otehr side" that did what you did and thus you were able to draw one side of a characters face and the other side was drawn along with it. You had some options like tile symmetry, mirror symmetry and a number x of symmetry "parts" if you will. In Deluxe Paint, you had a feature where you tell the program to use symetry while drawing.So that instead of one 1-pixel-brush you had a second "on the otehr side" that did what you did and thus you were able to draw one side of a characters face and the other side was drawn along with it. You had some options like tile symmetry, mirror symmetry and a number x of symmetry "parts" if you will. Dec 03, 2009 issue 274 (Symmetry function like in Deluxe Paint) commented on by pulkomandy - We have a symetry function in the "brush fx" and another one in "picture fx" to mirror the picture. Is that what you mean ? if not, then please be more precise about the feature :) We have a symetry function in the "brush fx" and another one in "picture fx" to mirror the picture. Is that what you mean ? if not, then please be more precise about the feature :) Dec 03, 2009 issue 274 (Symmetry function like in Deluxe Paint) reported by eh...@gmx.de - A symmetry function would be nice for painting up front faces (StrikeCommander, Privateer and the like...)... A symmetry function would be nice for painting up front faces (StrikeCommander, Privateer and the like...)... Dec 03, 2009 issue 272 (Vector icon (attached!)) commented on by cameron...@comcast.net - That was kinda by design. I felt it created a nice contrast, but of course anyone is welcome to change it. That was kinda by design. I felt it created a nice contrast, but of course anyone is welcome to change it. Dec 03, 2009 issue 273 (Enhanced safety backup) commented on by cameron...@comcast.net - I think that design makes sense. I'd be completely happy with that. I think that design makes sense. I'd be completely happy with that. Dec 03, 2009 issue 273 (Enhanced safety backup) commented on by yrizoud - Ilkke has again lost some work, so I want to solve this case in priority, no matter what design is finally chosen for issue 100. When both issues are done, of course they will share a lot of code. Ilkke has again lost some work, so I want to solve this case in priority, no matter what design is finally chosen for issue 100. When both issues are done, of course they will share a lot of code. Dec 03, 2009 issue 273 (Enhanced safety backup) commented on by pulkomandy - This is basically the same as issue 100, actually. This is basically the same as issue 100, actually. Dec 03, 2009 issue 273 (Enhanced safety backup) reported by yrizoud - There is currently a safety backup that occurs on program abnormal termination. But, on Windows at least, it cannot be triggered when the program is killed by the user. So, if there is any problem that causes an endless loop (program is frozen), unsaved changes are lost for the user. --> We can make an automatic preemptive backup at regular intervals, and if the user quits the program normally, delete it on exit. (see issue 100 for ideas about how to save during drawing) If the backup file is present when Grafx2 starts, the program can propose it for recovery. Multiple backups : sometimes, the crash or automatic save can happen at inconvenient moments, where the image is unusable. (floodfill accident, etc.) So the program should keep several backups, and let the user compare them, and choose which one he wants to save. I think ALL users will agree to sacrifice the disk space for 4 copies of their image, for incremental backups. In terms of user interface, the difficulty is that Grafx2 doesn't have multi-document interface to open all files at once, and it's not easy to compare images without layer control, for example... So I propose that Grafx2 re-loads the saved steps in the history of the current image. The message on startup would say that GrafX2 has reloaded N versions of the current image, reminding to use Undo/Redo to browse them. For example, 3 versions could be recovered. The user would first see an image with warped colors if for example the palette was damaged during the crash. He would click Undo, and it would show the preemptive backup from 2 minutes before. 1 more Undo and it would be the earlier preemptive backup: Too early, he clicks Redo, and he's back to his latest usable version. He saves it back at the right location, and he can continue working. Any comments are welcome (I don't think we say it often enough) There is currently a safety backup that occurs on program abnormal termination. But, on Windows at least, it cannot be triggered when the program is killed by the user. So, if there is any problem that causes an endless loop (program is frozen), unsaved changes are lost for the user. --> We can make an automatic preemptive backup at regular intervals, and if the user quits the program normally, delete it on exit. (see issue 100 for ideas about how to save during drawing) If the backup file is present when Grafx2 starts, the program can propose it for recovery. Multiple backups : sometimes, the crash or automatic save can happen at inconvenient moments, where the image is unusable. (floodfill accident, etc.) So the program should keep several backups, and let the user compare them, and choose which one he wants to save. I think ALL users will agree to sacrifice the disk space for 4 copies of their image, for incremental backups. In terms of user interface, the difficulty is that Grafx2 doesn't have multi-document interface to open all files at once, and it's not easy to compare images without layer control, for example... So I propose that Grafx2 re-loads the saved steps in the history of the current image. The message on startup would say that GrafX2 has reloaded N versions of the current image, reminding to use Undo/Redo to browse them. For example, 3 versions could be recovered. The user would first see an image with warped colors if for example the palette was damaged during the crash. He would click Undo, and it would show the preemptive backup from 2 minutes before. 1 more Undo and it would be the earlier preemptive backup: Too early, he clicks Redo, and he's back to his latest usable version. He saves it back at the right location, and he can continue working. Any comments are welcome (I don't think we say it often enough) Dec 03, 2009 issue 271 (Color reduction produces black images) Status changed by yrizoud - Fixed in r1236. Color reduction was simply not working at all with the new layer system. Oops! Status: Fixed Fixed in r1236. Color reduction was simply not working at all with the new layer system. Oops! Status: Fixed Dec 03, 2009 issue 272 (Vector icon (attached!)) Status changed by yrizoud - Lovely! The pixeling in the top left is very nice idea. My only critic is that the letters don't have the same proportions, the R A F seem compressed between the wider G and X. Status: Accepted Lovely! The pixeling in the top left is very nice idea. My only critic is that the letters don't have the same proportions, the R A F seem compressed between the wider G and X. Status: Accepted Dec 03, 2009 issue 272 (Vector icon (attached!)) commented on by pulkomandy - I made some changes, most notably added a shade to the highlights and tuned the "pixels" in the top-left so they look merged with the border. But overall, I like it, and we definitely need something like that. I made some changes, most notably added a shade to the highlights and tuned the "pixels" in the top-left so they look merged with the border. But overall, I like it, and we definitely need something like that. Dec 02, 2009 issue 272 (Vector icon (attached!)) reported by cameron...@comcast.net - Wasn't sure where else to post this. Whipped up a quick vector icon for those OSes that support them (svg format of course). No hard feelings if you don't want to use it, for whatever reason. Wasn't sure where else to post this. Whipped up a quick vector icon for those OSes that support them (svg format of course). No hard feelings if you don't want to use it, for whatever reason. Dec 02, 2009 r1236 (Fix issue 271: Loading 16/24/32bit images wasn't working sin...) committed by yrizoud - Fix issue 271 : Loading 16/24/32bit images wasn't working since the layers. oops. Fix issue 271 : Loading 16/24/32bit images wasn't working since the layers. oops. Dec 02, 2009 issue 271 (Color reduction produces black images) reported by yrizoud - What steps will reproduce the problem? 1. Load the attached image 2. Image is monochrome of color 0 The previewing is fine and there's some logic in the produced palette, so I suppose it happens during the color reduction after that. Reported by iw2evk for jpgs, but I already had noticed this 24-bit png was not loadable. I've just tested and none of the 24bit images from pic-samples work any more. Tested on Windows and DOS. What steps will reproduce the problem? 1. Load the attached image 2. Image is monochrome of color 0 The previewing is fine and there's some logic in the produced palette, so I suppose it happens during the color reduction after that. Reported by iw2evk for jpgs, but I already had noticed this 24-bit png was not loadable. I've just tested and none of the 24bit images from pic-samples work any more. Tested on Windows and DOS. Dec 02, 2009 r1235 (Fixed missing include and const in brush factory. ) committed by pulkomandy - Fixed missing include and const in brush factory. Fixed missing include and const in brush factory. Dec 01, 2009 issue 270 (Remapping the spare doesn't make a valid undo/redo step) reported by yrizoud - This is about the functions 'Copy to spare / Palette and remap' When used, the operation is done on top of the latest undo/redo step, it cannot be separated from it. It's a limitation from original DOS version, and probably why the program asks "Spare page was modified. Proceed?". It wasn't too bad back then, but this has some very bad consequences if the image is layered, due to our smart memory-saving techniques : The remap is applied retroactively on all layers that haven't changed for some time. If you undo, you see the remap (and the last thing you drew on current layer) disappear, but it stays applied on all other layers. bad! This is about the functions 'Copy to spare / Palette and remap' When used, the operation is done on top of the latest undo/redo step, it cannot be separated from it. It's a limitation from original DOS version, and probably why the program asks "Spare page was modified. Proceed?". It wasn't too bad back then, but this has some very bad consequences if the image is layered, due to our smart memory-saving techniques : The remap is applied retroactively on all layers that haven't changed for some time. If you undo, you see the remap (and the last thing you drew on current layer) disappear, but it stays applied on all other layers. bad! Dec 01, 2009 issue 262 (Problem with X-Swap) changed by yrizoud - Yep, I didn't complete this part. This is not even linked to Undo: After an X-swap, swap to spare and back, or change the active layer (2 things that don't modify the image's history), and you'll the remap is already forgotten. (internal notes: X-Swap doesn't remap the layers, only the visible buffer. Need to test all palette operations when this is done, because the history may not be handled well anyway. Normal behavior should be as follows : First backup saves 'no layers' because normally only the palette is going to be changed. If there's any remap (and only the first time), it should first do a full backup - and even replace the original, so it will appear as a single atomic Undo/Redo step. Also, on Cancel, the current backup should be rolled back so it's not in the Undo/Redo chain.) Summary: Problem with X-Swap Status: Accepted Labels: OpSys-All −OpSys- Yep, I didn't complete this part. This is not even linked to Undo: After an X-swap, swap to spare and back, or change the active layer (2 things that don't modify the image's history), and you'll the remap is already forgotten. (internal notes: X-Swap doesn't remap the layers, only the visible buffer. Need to test all palette operations when this is done, because the history may not be handled well anyway. Normal behavior should be as follows : First backup saves 'no layers' because normally only the palette is going to be changed. If there's any remap (and only the first time), it should first do a full backup - and even replace the original, so it will appear as a single atomic Undo/Redo step. Also, on Cancel, the current backup should be rolled back so it's not in the Undo/Redo chain.) Summary: Problem with X-Swap Status: Accepted Labels: OpSys-All −OpSys- Dec 01, 2009 grafx2-2.2wip1234-src.tgz (Work-in-progress 2.2 version with layers. Left-click the bot...) file uploaded by yrizoud - Labels: Type-Source OpSys-Linux Labels: Type-Source OpSys-Linux Dec 01, 2009 grafx2-2.2wip1234-win32.zip (Work-in-progress 2.2 version with layers. Left-click the bot...) file uploaded by yrizoud - Labels: Type-Executable OpSys-Windows Labels: Type-Executable OpSys-Windows Dec 01, 2009 r1234 (Temporarily disabled Mask which is not implmented (it would ...) committed by yrizoud - Temporarily disabled Mask which is not implmented (it would crash on each use). Fixed instant crash in 'Copy to spare / Palette and remap' by doing actual layer-aware implementation Temporarily disabled Mask which is not implmented (it would crash on each use). Fixed instant crash in 'Copy to spare / Palette and remap' by doing actual layer-aware implementation Dec 01, 2009 issue 258 (Segfault when saving layered gif) changed by yrizoud - Status: Fixed Labels: OpSys-All −OpSys-Linux Status: Fixed Labels: OpSys-All −OpSys-Linux Dec 01, 2009 issue 264 (Killing current page can leave no active layers) changed by yrizoud - Thanks. I had thought of Undo and Redo, but forgot about Kill. And even for Undo and Redo, I forgot to force the active layer to be visible. Fixed in r1233. Status: Fixed Labels: Priority-Critical OpSys-All −Priority-Medium −OpSys- Thanks. I had thought of Undo and Redo, but forgot about Kill. And even for Undo and Redo, I forgot to force the active layer to be visible. Fixed in r1233. Status: Fixed Labels: Priority-Critical OpSys-All −Priority-Medium −OpSys- Dec 01, 2009 r1233 (Fix issue 264: Undo/Redo/kill can leave no active or visible...) committed by yrizoud - Fix issue 264 : Undo/Redo/kill can leave no active or visible layer Fix issue 264 : Undo/Redo/kill can leave no active or visible layer Dec 01, 2009 issue 259 (Layer visibility not retained when switching pages) changed by yrizoud - Status: Fixed Labels: Priority-Critical OpSys-All −Priority-Medium −OpSys- Status: Fixed Labels: Priority-Critical OpSys-All −Priority-Medium −OpSys- Dec 01, 2009 issue 259 (Layer visibility not retained when switching pages) commented on by yrizoud - Thanks, it's been hellish to track this down, as it required many precise steps to reproduce. There was a bug in the page swap itself, where the internal layered image was redrawn before the swap was complete. So when switching, it redrew the spare-which-was-becoming-main using the current layer number and visibility flags of the main-which-was-becoming-spare. Additional chaos happened, because it also made an erroneous depth buffer, so you could draw above the top layers and under the bottom layers. Fixed in r1232 Thanks, it's been hellish to track this down, as it required many precise steps to reproduce. There was a bug in the page swap itself, where the internal layered image was redrawn before the swap was complete. So when switching, it redrew the spare-which-was-becoming-main using the current layer number and visibility flags of the main-which-was-becoming-spare. Additional chaos happened, because it also made an erroneous depth buffer, so you could draw above the top layers and under the bottom layers. Fixed in r1232 Dec 01, 2009 r1232 (Fix weird mixing of layers from main and spare pages (Issue ...) committed by yrizoud - Fix weird mixing of layers from main and spare pages ( Issue 259 ) Fix weird mixing of layers from main and spare pages ( Issue 259 ) Nov 30, 2009 issue 267 (Program froze after editing ranges) commented on by ilija.melentijevic - Ok, I found a way to eliminate the problem, but I don't really know how it came to be. Fortunately I have my settings backed up because I tend to test betas and whatnot, so I just overwrote the current setting with those I backed-up earlier. Now the colorpicker-freeze is gone. (Had nothing to do with keyboard shortcuts) Perhaps the settings stored by one version are not 100% compatible with the other, but funny thing is that both stable and beta versions were freezing? I noticed that for some reason range-settings are not shared between versions. Ok, I found a way to eliminate the problem, but I don't really know how it came to be. Fortunately I have my settings backed up because I tend to test betas and whatnot, so I just overwrote the current setting with those I backed-up earlier. Now the colorpicker-freeze is gone. (Had nothing to do with keyboard shortcuts) Perhaps the settings stored by one version are not 100% compatible with the other, but funny thing is that both stable and beta versions were freezing? I noticed that for some reason range-settings are not shared between versions. Nov 30, 2009 Compiling (Some notes about the build system.) Wiki page edited by pulkomandy - Revision r1231 Edited wiki page through web user interface. Revision r1231 Edited wiki page through web user interface.

issue 273 (Enhanced safety backup) reported by yrizoud - There is currently a safety backup that occurs on program abnormal termination. But, on Windows at least, it cannot be triggered when the program is killed by the user. So, if there is any problem that causes an endless loop (program is frozen), unsaved changes are lost for the user. --> We can make an automatic preemptive backup at regular intervals, and *if* the user quits the program normally, delete it on exit. (see issue 100 for ideas about how to save during drawing) If the backup file is present when Grafx2 starts, the program can propose it for recovery. Multiple backups : sometimes, the crash or automatic save can happen at inconvenient moments, where the image is unusable. (floodfill accident, etc.) So the program should keep several backups, and let the user compare them, and choose which one he wants to save. I think ALL users will agree to sacrifice the disk space for 4 copies of their image, for incremental backups. In terms of user interface, the difficulty is that Grafx2 doesn't have multi-document interface to open all files at once, and it's not easy to compare images without layer control, for example... So I propose that Grafx2 re-loads the saved steps in the history of the current image. The message on startup would say that GrafX2 has reloaded N versions of the current image, reminding to use Undo/Redo to browse them. For example, 3 versions could be recovered. The user would first see an image with warped colors if for example the palette was damaged during the crash. He would click Undo, and it would show the preemptive backup from 2 minutes before. 1 more Undo and it would be the earlier preemptive backup: Too early, he clicks Redo, and he's back to his latest usable version. He saves it back at the right location, and he can continue working. Any comments are welcome (I don't think we say it often enough)

There is currently a safety backup that occurs on program abnormal termination. But, on Windows at least, it cannot be triggered when the program is killed by the user. So, if there is any problem that causes an endless loop (program is frozen), unsaved changes are lost for the user. --> We can make an automatic preemptive backup at regular intervals, and *if* the user quits the program normally, delete it on exit. (see issue 100 for ideas about how to save during drawing) If the backup file is present when Grafx2 starts, the program can propose it for recovery. Multiple backups : sometimes, the crash or automatic save can happen at inconvenient moments, where the image is unusable. (floodfill accident, etc.) So the program should keep several backups, and let the user compare them, and choose which one he wants to save. I think ALL users will agree to sacrifice the disk space for 4 copies of their image, for incremental backups. In terms of user interface, the difficulty is that Grafx2 doesn't have multi-document interface to open all files at once, and it's not easy to compare images without layer control, for example... So I propose that Grafx2 re-loads the saved steps in the history of the current image. The message on startup would say that GrafX2 has reloaded N versions of the current image, reminding to use Undo/Redo to browse them. For example, 3 versions could be recovered. The user would first see an image with warped colors if for example the palette was damaged during the crash. He would click Undo, and it would show the preemptive backup from 2 minutes before. 1 more Undo and it would be the earlier preemptive backup: Too early, he clicks Redo, and he's back to his latest usable version. He saves it back at the right location, and he can continue working. Any comments are welcome (I don't think we say it often enough)

Last 7 days

Last 30 days