Quote:Original post by Servant of the Lord
Bugs:

1) Drawing a line of pixels, using the Pencil tool, off the edge of the image, shuts down or crashes the program. (A very smooth/silent crash)

I can't reproduce this one. Is it every time you move the mouse outside the image while drawing? Or only in a special circumstance?

Ok, I'm investigating it... It doesn't happen for me, and there are various checks in both the buffer you're drawing on (it's an OpenGL texture instead of an SDL_Surface!) and the undo buffer against accessing values outside of the range, so there must be going on something more subtle somewhere. Hard to tackle bug, this one!

If the size of the painting is a power of two, then the size of the image is exactly the size of the buffer. If the size of the painting isn't a power of two, then the buffer is larger in memory (mapped to a power of two buffer, for OpenGL). So possibly it might crash more for you on an image of 256*256 pixels, than an image of 257*257 pixels for example... But for me it doesn't, but I'll find it!

EDIT: Fixed it. The fix will be in the next release. The cause was a call to "glTexSubImage2D" with out of range parameters. Apparently some video cards like this better than others :)

[Edited by - Lode on March 15, 2010 7:27:31 PM]

The crash bug should be fixed! Could you check if it doesn't crash anymore? (when painting with brush and moving outside the painting while drawing).

Some of the reported bugs were fixed (like the X buttons now work, some input fields behave a bit better, ...).

And there's support for opening multiple images now (but not yet copying data between them, that's for the future).

The newest version is here: https://sourceforge.net/projects/lodepaint/

Quote:Original post by lightbringer

Quote:Original post by szecs
Is it elegant to do like this, or is it more elegant to use the win32 windowing in case of a windowed program, or it doesn't matter?

It's not elegant at all. Native applications should use the native windowing (that users are already familiar with) for best look & feel. Don't make users learn the quirks of a new windowing toolkit if you don't have to.

For LodePaint it was this custom GUI, or GTK+. I chose the custom GUI.

But szecs is making a game, for a game it most certainly is elegant imho.

Don't use me as an example. My GUI is still broken...(the minesweeper)

But one thing is truth: an editor type application should have the most features the native GUI has, in your case keyboard navigation and short cuts (but I know it's a work-in-progress project).
I don't know if I will implement it, because most of the time my users will be clicking on the field. But your users need to be able to switch between tools an features very frequently.

And I suggest to include the shift+ellipse/rectangle feature: with shift pushed you can draw circle/square.

And an other thing: if user uses a tool, then presses a tool hotkey while drawing, an other tool will be switched on, but if the user switches back to the first one, the firstly used feature continues (even if (s)he drew with the other tool). So the features/tools should be canceled and switched of completely, when selecting an other tool.

And a thing that bothers me about Photoshop, and I like in Paint, that the opposite button click cancels the drawing.

Is it possible to make the polygon tool place points only when left button is clicked, but not when it is held down? Or is it intended to work like that?

I hope that's clear what I'm saying, I'm not sure.

[Edited by - szecs on March 22, 2010 10:18:48 AM]

Sorry for the separate posts.

Edit box:
The caret blinking should be reset (show the caret and reset timer) on events (click, keyboard events)
And if a portion of the text is selected, pressing "Home/End" should turn off selection.
Because now the caret will be placed at the beginning/end of the whole text, but writing will be placed in selection.

Quote:Original post by lightbringer

Quote:Original post by Lode
For LodePaint it was this custom GUI, or GTK+. I chose the custom GUI.

IMHO that was a big mistake. At least, I have no interest in using your program based on this fact alone :)

Do you have some examples of big things missing in this custom GUI that make this a problem?

Simply "because it's custom" doesnt really help much. GTK, Qt and Java are also custom in some ways for example. So is the "GUI" of web-based applications such as the Gamedev.net forum... And many movie / mp3 players for PC.

What kind of things could users be expecting from a GUI that doesn't behave properly here?

I know there are some things that can be improved, such as the edit boxes, using tab to navigate to other fields, mnemonics for menus, etc..., and these things are possible and will be done, but knowing the most annoying / important ones is interesting to know where to put the priorities.