Hello !
It seems that some users are using Grafx2

So feel free to ask for help on it or share techniques here. If you write something interesting we may borrow it and add it to our wiki, too.

You can use shift+F6 at any time to bring up the stencil setup window where you can select colors.
What else would you need ? Adding the current foreground color ? something similar to the color grabber ?

Also note if you don't like a key shortcut, you can click on it in the helpscreen to change it.

Edited by PulkoMandy - 31 July 2009 at 1:16pm

I think it's meant to be GraFX2 (as in "graphic effects"). But I tend to miss the shift key :)

For the WIP build, you'd have to ask Yves for that as I'm running linux. But right now he's quite busy working on the layer system.

The mac version is broken on leopard. We have one for Tiger and one for Snow Leopard but none for Leopard. We are trying to find someone to build it. Unfortunately Apple does not seem very attached to keep compatibility across the versions of their OS.

Cool! Thanks. I'm keen to test the new shift-locks-to-vertical-or-horizontal-movement thing.

Also: any chance of (partial) PNG-24 support in the near future? I'm guessing the problem is alpha transparency, but I figure it could just accept those files with no alpha. Like, if the image has only fully opaque and fully transparent pixels, and nothing in between, just convert to PNG-8 and load. Continue to reject PNG-24s with real alpha. Of course I have no idea how much of a pain this is to check for.

It's just that I do a lot of edits and such on this forum, and it's tedious to have to convert to gif/png-8 all the time, especially when the png-24s are fully opaque.

I was using the latest WIP build today and I realized that every time I encounter a text entry field, my "flow" comes to a grinding halt. They really ought to behave like a normal OS text field widget: don't disable the mouse, tab to next field, etc. It's really hurting usability.

EDIT: Just realized this may have been partially fixed already. I'm getting my builds mixed up. I'll have to mess with it some more when I get home.

Edited by Hatch - 07 August 2009 at 10:43am

*forehead slap*

Sorry, got a bit mixed up.
Anyhow, it's a minor thing, but would it be possible to allow for tabbing to other fields?

EDIT: Also, I understand implementing text selection and copy/paste and all that jazz would be waaaaay more trouble than it's worth, but that leaves no obvious way to quickly clear a field. I recently learned of right-click by accident, but I'm thinking a double-click would be more intuitive, since that's how you select all text in a regular text field widget in preparation to delete. Just kinda throwing ideas out there, I'll open a ticket if you want.

Edited by Hatch - 07 August 2009 at 3:17pm

Tabbing is quite tricky. If we use it only for text fields I think it can be done. But you will not have access to other widgets (button, sliders) with it. Would that be enough for you ?

Basically the big problem I see with switching to the next field when you press tab is to decide which field is the next one. As our code is not done for that, the fields are put in the window not in the order you see them, but more in the order we added them to the code.

And then, the keyboard reading function is locked inside a field and has no access to the rest of the things, so we have to ask the open window to see if there is another field, close the editing in the current one, and open the new one. Programming works like that, many steps, but really really small ones.

On the other hand, png 24bit was not that hard to add because we use libpng, which does almost all the work for us. (still, Yves is amazingly fast :p)

Yes, I think we'll make the OS dialogs available for this in some way. But I can't do it as on linux there is no default thing for that.
The idea is to keep our own in linux, and use the system one where it makes sense: amiga, windows, beos, osX.
Now for example in win98 (the one Yves is still running) the fileselctor won't allow you to preview pictures...

Gnome and KDE have standard dialogs of course, but using them would mean you must have one of them installed on your linux system, and I don't. Also the gp2x port is linux-based and there is no gnome nor kde available. This is the problem with linux, you can't know what the user will have available, and I don't want to add hundred of different codes to display all the possible file loading dialogs under linux. It'd also mean distros (debian, ubuntu) would have to choose one of them when building their packages, and this will only give problems.

You just found another bug in the palette reduction algorithm.
I think it's because it's a 24bit image but with less than 256 colors used, making the color reduction system go wrong in some way.

[edit]
ok, fixed it in r996. I had already fixed the very same bug in another part of the code 10 lines below. I should have fixed this one too. Sorry.
Note the palette should also be sorted more correctly when you load a 24bit image now.

Edited by PulkoMandy - 17 August 2009 at 12:49pm

There is another problem. I hate the GTK+ API. So I won't ever write this code. And actually I'm quite happy with the current internal fileselector myself.
I plan on adding an external fileselector on amiga, jsut because they have a great fileselector system that is actually better than our internal one. This is a good reason to add a dependancy.
Requiring GTK+ under linux to get a not-so-good fileselector, that may or may not work in fulscreen mode, does not seem a really good idea, however.

Note we don't have any ./configure script in grafx2. Everything is done from the makefile, making optional things quite complicated to manage. On amiga, the fileselector is always available so it makes sense to use it. Under linux there is no way to be sure, even if it's quite usual to have gtk+ installed you may not have the development files to build things for it. Right, it's not complex, we just run a test -f on some gtk+ header and include it if found. But all we get is a fileselector that don't feel more standard for Qt users, and that may not even please gnome guys as I think gnome provide another fileselector system on top of the gtk one. I think linux just will bring us more headaches.

On amiga, if you have a compiler, you necesarily have the OS headers so we can provide the native fileselector without looking if the header is here.

We do have a system to find path quickly, jsut type some letters to jump to the dir/file with a name that look like it.

Internationalization makes no sense if the other parts of the program are all in english, right ?

Drag n drop is not possible in any simple way with SDL. Each OS has its own interpretation of how it should work. And, using SDL makes it a little difficult to access the OS things.

So, I won't write the gtk fileselector things because I have no use for it and feel it will bring me more headaches than ease of use. But feel free to submit a patch and I'll apply it :)

(yes, that's how opensource software works. I do things for my own use and share them with you. If you give me an idea I think is food, I'll code it for free. If you want a bad idea to be done, do it yourself or pay me (or someone else) to do it.)

Is there a reason you guys don't want to use a configure script?

I'm dipping into an area I know very little about, so please understand that this is an honest question, not a challenge.

The so-called configure script started as a bad hack to make software autodetect configuration and build on first try.
In the old unix days, people would provide just the sourcecode and a makefile as it worked for them, letting other make changes to the software to get it working on some other machine.
Then the idea came to create scripts, traditionally called "configure", that would do some tests and edit the makefile (and eventually the sourcecode) automatically. As this is quite complicated to do, A tool to generate such a script was written. It's called "autotool". You provide autotool a set of config file where you list all the stuff you need, all your sourcefiles and so on. And autotool generates itself the ./configure script. then the script generate the makefile. The makefile is again listing your sourcefiles, and dependancies. So you are not even a step further in the compilation work. And the files you have to write to make autotool work are less clear and usually longer than our makefile. The generated makefile is also very complicated and unreadable.

The autotool guys also fail to keep compatibility between version of their tools, meaning some project need a very new version of it to build, and some need a somewhat old one. Also, autotool is an unix only thing. It can be made to work under windows with some tricks, but it will be a lot more annoying for amiga, for example.

I tried to use it on another project: we ended up with more lines of autotool mess than actual lines of code !
So, our makefile is simple and works everywhere. Yes, it is less configurable, so all GrafX2 builds are made equal and have the same features. But this mean a lot less work for us : less compile-scripts to mess with, less bugs that only occur when you use some specific combination of options, easier to reproduce and to fix.

There are quite good alternatives to the autotool mess, for example there is jam and cmake. Both work quite well and are now quite common under linux, but again, not-so-common on some of the other platforms we support. So I prefer a simple makefile that works everywhere. And I think you will find the same spirit in all the sourcecode : solutions that are not universal, but works for what we do.

Finding layers extremely difficult to work with in the absence of a visual indicator telling me what layer I'm on and what layers I have. I cannot access the layers menu for some reason (I press the hotkey and absolutely nothing happens).

Why does it require Lua to build now?

Oh, I see, left-click the "HIDE" button. Well, cool, looks great! Perfect for the tiles/mockup I'm working on at the moment.

When I try to save a layered image as a gif, it segfaults. Not familiar with all of the image formats. Which support layers?

EDIT: Also, is there a simple way to have two grafx2 installs in the /usr/local prefix on linux? Like, launch one with "grafx2" and the other with "grafx2-unstable"?


Edited by Hatch - 23 November 2009 at 5:54pm

Filed a bug report with useful (hopefully) debugging info.