next »

[Chman]

Just thought I'd add my 2 cents... If you want to minimise mouse movements and not clutter the interface with lots and lots of buttons and ugly toolbars, use Pie Menus. This is the perfect solution for people asking for mouse gestures and/or fast access to tools.

[Xion]

shift+click should result in drawing in 45-degree angles.

45, 90, and lines with a 1:2px ratio (don't know the degreeage)! It is something I have desired but never encountered.

And yes, I agree with agj about the key+mouse and expandable buttons.

I've never used pie menus but it seems like it could be very useful.

[Gold Cray]

lines with a 1:2px ratio (don't know the degreeage)

That's n*pi/4 +/- .322 radians, which is n*45 +/- 18.43 in degrees. n is an odd integer.

I like the 1:2px idea and wonder how well if would work if extended to other integer ratios (1:3, 1:4).

[sereneworx]

The pie menu thing looks pretty cool. It would be even better if you could just access it with the scroll wheel, so that you could change tools by scrolling, sort of like in shooters.

[medieval]

The pie menu thing looks pretty cool. It would be even better if you could just access it with the scroll wheel, so that you could change tools by scrolling, sort of like in shooters.

Yeah, although it'd be best to make that key+scroll

[Zaratustra]

scroll wheel is zoom. Do not change that.

[Chman]

A zoom following the current cursor position, of course.

Some people also like to use the scroll wheel as a fast way to scroll the image (it's even better with a multi-directional wheel, like the Apple's Mighty Mouse).

Either way, their should be a way to customize keyboard/mouse/tablet bindings, so that everyone's happy.

[FoxBlitzz]

Need Shift + Click necessarily be limited to 1:1 or 1:2 stepping ratios? What about 1:3 or 1:4? Or even further stepping (potentially up to 1:8)? After 1:8, it could automatically snap to horizontal or vertical. Also, there should be an easy way to enable or disable the automatic ratio snapping, in case the user just wants to draw a line as he/she desires.

Would it be possible to add an option that would allow for swapping the binding of the zoom and scroll controls? One method is easy for conventional users, while another conforms to the Mighty Mouse more nicely.

[Corpus]

It'd be way too fiddly. With horizontal, 45º and the 1:2 lines, you already have 12 lines in 360º from the start point. Any more will be needlessly complicated. Sometimes you just need to do it yourself.

[godsavant]

scroll wheel is zoom. Do not change that.

In that case, customization is all the more necessary; it's really frustrating to have the scroll wheel zoom in/out when its function is for scrolling in almost every other application.

Would it be possible to add an option that would allow for swapping the binding of the zoom and scroll controls? One method is easy for conventional users, while another conforms to the Mighty Mouse more nicely.

It had better be; the Mighty Mouse's scroll wheel is notorious for seizing after some use, with dirt and grime logging up the sensors and only letting it scroll directly upwards (or, in this case, inwards). I think that's why I so set against scrolling as a means of zooming  : I can't zoom back out in the same manner.

[Gold Cray]

I think it would work well up through 1:3.

[Corpus]

Nah, it looks too fiddly to me, I still think. You'd spend ages trying to hit the sweet spot for each line type.

[FoxBlitzz]

Actually, here's a better idea. How about you begin a line with a certain stepping, and when you press and hold Shift, it will lock to the stepping you're using, so you can specify the length without having to worry about the angle shifting? When you are at the origin point of the line, pressing Shift could switch to the horizontal/vertical snapping, somewhat like what Pro Motion uses, except that it draws as a line instead of pencil.

[Michael Buckley]

Alright, given the suggestions so far, if I were to sit down and design/code this out, here is how I would do it.

Language: Python. It's a cross-platform scripting language that has a vibrant development community and a lot of libraries, including wx. C++ would also be a good choice, but I feel that Python has the advantage of requiring less development time. For a project that no one has volunteered to program, I think that's a definite plus. I think Python is certainly fast enough to handle the needs of this project.

Version: 2.6, to make sure that it is as ready as possible to port to python 3.0 when the required libraries are available for 3.0.

GUI Library: wxWidgets. This is a great cross-platform library with a mostly native look on all systems. Care should be taken, however, to ensure that the GUI classes could be rewritten to work under any GUI library. That way, if wxWidgets does not work out for a certain platform, the GUI classes can be rewritten for that platform. The biggest risk I currently see is OS X. The GUI classes might need to be rewritten for OS X using PyObjc, so the project should hold off on transitioning to Python 3.0 until PyObjc is availiable for Python 3.0.

Canvas Library: PyOpenGL. This is partially because I'm so used to programming in OpenGL, but all this library will be used for is displaying pixels on the screen. It won't be used for creating the image or saving it to different filetypes. Again, the canvas class should be written so that this can be replaced by a different library if need be, but OpenGL should work on any platform, even on systems that provide OpenGL through software emulation.

Development steps (In rough order. Some could be done in parallel):

• Canvas, first version: Create a canvas class that can be any (reasonable) size. The canvas must have a method to color any specific pixel with any RGBA color, meaning that a Color class will also be required. The canvas must also have a method to register objects to notify when it is updated, though notification isn't necessary at this point, and an accessor method which returns a 2D array of color objects representing how the canvas should appear onscreen or in an image.
• Image Import/Export API: Create an API for developers to load/save images to/from the canvas. Pretty straightforward, so I don't think I have to belabor it. Including individual file formats will be up to the GUI.
• Canvas, second version: Create an extensible hierarchy of operation classes which can be used to draw on the canvas. Start with a few simple operations such as line, rectangle, circle, etc. Operations work by calling the method to color a pixel. Id the color of the operation is at least partially transparent, it will need to take the current color of the canvas's pixel into account and perform blending, so there should be a method to get the blended color given the current color and thee new color. Modify the canvas to take a list of these operations, and apply them in order to produce the final result. We now have a one-layer canvas which supports undo/redo, by removing or adding the last operation from the list.
• Layers: Create a layer class which holds a list of operations, and modify the canvas to take a list of layers instead of a list of operations. Now we have a multi-layer canvas, with each layer supporting undo/redo. Ensure that layers can be easily duplicated
• Keyframes: Modify layers to contain keyframes. A keyframe has a frame number and a list of operations. When a layer changes keyframes it signals the canvas to redraw the layer.
• Indexed Colors: Extend the Color class to allow for indexed colors
• Window class: Create a window class which can set the menu bar items and the toolbar items, and which can be resized. The window will be responsible for drawing the canvas, and thus is responsible for any scrolling or zooming required. On OS X, this window should be hidden on startup, but since it contains the menu bar on other system
• Grid: Implement a grid that can be set to any color and any size, and can be toggled on/off.

• Opening/Saving: Implement the Open/Save menu/toolbar actions. For now, they can open/save any format you'd care to use for testing. Test them by opening an image and re-saving it under a different name
• Tool Palette: Implement a tool palette, which is a small window that holds tools, and can snap to the sides, top or bottom of the window. The tool palettes can hold tools, which track the movement and state of the mouse and keyboard, and update the canvas accordingly. Tools first ask the canvas for the current layer to draw in. If the grid is activated, and set to a size different than 1x1, the tool only receives events when the mouse moves between grids, and is notified that the mouse is in the center of the grid.
• Color Palette: Similar to the tool palette, allows for color selection and color palette assignment.
• Input Management: A customizable class which accepts mouse and keyboard events and translates them into commands to the program. Extensible and customizable, so users can have many presets for different modes.

Of course, I glossed over some of the stuff, but that's the general direction I'd go. At this point, I'd re-evaluate the need for things like animation (with onion skinning) pie menus, etc.[/list][/list]

[Akhel]

My favorite logo so far is agj's:

I think Saker's looks a bit too agressive.

[Gold Cray]

It looks like it's finally time to learn Python. Once I've done that I ought to be able to at least help with some of the functions.

[Michael Buckley]

Keep in mind that I'm only suggesting a plan of action there. I have no intention of following it through on my own. Obviously, it would be up to whoever implements the bulk of this to choose the language. I'm just recommending Python. There are some things that I personally hate about Python, and other things that I love.

Also, Python 3.0 is not backwards compatible with current versions of Python, So just remember that you might have to unlearn some of the things you've learned when Python 3.0 becomes mainstream.

Having said that, the first few steps in the plan I laid out could probably be done pretty quickly and easily by someone learning the language.

[Bad Sector]

I'd use Java instead of Python, mostly because its much faster (the HotSpot VM has one of the best JIT compilers), type safe and -above all- comes with Swing, which in my opinion is the best designed GUI toolkit (although not always the easiest) and this project needs a strong GUI foundation. Also Java has a shitload of extremely good programming environments, such as NetBeans and Eclipse (personally i prefer NetBeans for Java, but others might prefer Eclipse).

[Michael Buckley]

I'd use Java instead of Python, mostly because its much faster (the HotSpot VM has one of the best JIT compilers), type safe and -above all- comes with Swing, which in my opinion is the best designed GUI toolkit (although not always the easiest) and this project needs a strong GUI foundation. Also Java has a shitload of extremely good programming environments, such as NetBeans and Eclipse (personally i prefer NetBeans for Java, but others might prefer Eclipse).

And the downside to java is that it runs like molasses going up a hill, is usually a version behind, and has an odd Swing implementation on OS X. Sun doesn't handle the VM on OS X, Apple does. Apple has let it languish for years, and made it obvious that they don't want Java development on their platform by cutting off its bridge to Objective-C. Python, on the other hand, has a bridge to Objective-C that Apple recently included with the operating system.

I personally prefer to program in Java. My recommendation was based on the principle that Tixel should be cross-platform. If you're looking to have cross-platform code that works on OS X, C++ and Python are really your best bets.

Eclipse also does have a plugin to allow Python development. Dunno about NetBeans.

[Bad Sector]

Actually Sun does the port to OS X and Apple takes care of the details. Or at least some of the key Java people are involved in the port, since James Gosling had a blog entry about his experience in porting Java to back-then new x86-based OS X.

Also currently Mac OS X has the latest release of Java available (1.6), introduced in the last update of Mac OS X. Although, the major difference between 1.5 and 1.6 is in the API and if you are careful enough, your program can run in 1.5 machines with no problem (1.6 includes scripting support via JavaScript though, which is a nice feature - although you can always put a scripting engine in your 1.5 program).

I never heard about the speed difference before. Can you point me to some source for that? I'm be interested about what and how is slower in Java on Mac OS X, since i'm working on a Java-based 3D game engine and world editor and i would like to know what to watch out for.

EDIT: btw i doubt Java is slower than Python in Mac OS X though. Python is an interpreted language after all and even if there is a JIT out there that is up to date with the latest Python version, i highly doubt that is as efficient as HotSpot.