search

Spade-Editor / Spade

Cross-platform raster graphics editor inspired by Paint.NET
GNU General Public License v3.0
41 stars 10 forks source link

Separation of GUI and logic #109

Open SuperDisk opened 9 years ago

SuperDisk commented 9 years ago

Right now the GUI is tightly coupled to the logic of the program; Swapping out WebLaF for the standard Java stuff proves to be a nightmare when it's scattered all over the place (including in the non spade.gui packages!)

HeroesGrave commented 9 years ago

To be honest, the benefits are too small compared to the amount of work required to do it.

For the sake of actually getting things done, I'm trying to avoid massive refactorings unless it becomes a major issue.

If it becomes an issue, we'll solve it then.

SuperDisk commented 9 years ago

Fair enough. I just really dislike WebLaF because I think it makes an otherwise native looking program look like one of those GTK+ abominations that has no home on any platform.

HeroesGrave commented 9 years ago

It's not perfect but it's well ahead of the standard Java LAF.

Longor1996 commented 9 years ago

If Spade was ever to be rewritten from scratch, it should be split up into 3 projects:

That way, the GUI could very well be implemented with either Swing, JavaFX, Qt or even LWJGL. This could solve a whole bunch of problems... but possibly creatue new problems.

BurntPizza commented 9 years ago

For the record, this is one of the primary reasons I rarely have motivation to work on this project. The mental gymnastics required is quickly tiring.

I don't think 3 whole projects are required, but at least separation via 3 root packages should be something to strive for.

Longor1996 commented 9 years ago

Note: The thing I meant to say with my previous comment was to make use of the "Dependency Inversion Principle": http://en.wikipedia.org/wiki/Dependency_inversion_principle

HeroesGrave commented 9 years ago

The problem is that several important optimisations in the actual logic are based on the fact that we were using Java2D and Swing (the most significant is writing/reading directly from the pixel data of a BufferedImage)

It would be nice to separate everything, but until there's actually a real need for it I don't think I'm up for it. In reality it's simply too much work for very little gain.

And besides, once the main codebase is stable enough, it hopefully won't have to be touched very often as we will be able to do most things through plugins.

SuperDisk commented 9 years ago

I don't see much of a problem just sticking to one GUI toolkit, but for the sake of sanity I just think it makes sense to not have the GUI displaying code in, for instance, the Core plugin and any Effect that you might want to add. For instance, Paint.NET functions so that plugins just depend on the Paint.NET base and it takes care of creating the dialogs; In Spade, whenever a dialog or etc. is needed, the code is just right there.

It's really not that big of a deal at the moment, and I think it's a bit of an ivory tower goal when, to be frank, the program doesn't even have a brush.

BurntPizza commented 9 years ago

the most significant is writing/reading directly from the pixel data of a BufferedImage

We already have this almost completely abstracted as RawImage, just move remaining references of BufferedImage to a pluggable utility provider, and presto.

HeroesGrave commented 9 years ago

Hmm. Maybe.

Blendmodes are still dependent on Java2D, but switching those to OpenGL would be reasonably simple.

I blame Swing for the current mess of GUI and logic code, and this leads onto the primary concern of separating the GUI out and potentially moving to OpenGL: GUI Libraries.

If we could go as far as to abstract a GUI library completely over Swing and an OpenGL solution, that would be the best solution. (and wouldn't be too nasty as we'd have to write an OpenGL UI library from scratch regardless).

The only limit is time. I'll do a bit of experimenting over the next week or so while I'm away from the internet.

SuperDisk commented 9 years ago

Instead of OpenGL there's OpenVG (Which is a standardized 2d rendering API). Here's an implementation that sits on top of OpenGL: https://github.com/ileben/ShivaVG

Really though; This is putting the cart before the horse. Spade is marginally functional as is; Swapping out graphics APIs in such an early phase for the sake of performance seems nonsensical.

Longor1996 commented 9 years ago

Oh God what discussion did I spawn now... I did not ask to replace the engine or the GUI!

What I actually wanted to ask for: It would be (much) better if Spade is split into three root packages, of wich one is in a separate project (The Core-Plugin), while the other two are in one project which has the root-packages engine and swinggui (The Spade-Editor), both separated by interfaces (and POJO's). Then if ever necessary we can split the engine and the GUI into separate projects without jumping off a cliff.

If someone then wants to create a OpenGL GUI, he can do it with much less hassle. Or if someone wants to swap out the engine with one that uses OpenCL, he could just do that. Also, it makes the code look better in the long run (its one layer of indirection/abstraction).

And if that is not enough abstraction, we could separate everything out into plugins (Hello, overkill!). So we would have Spade-Core (A plugin loader and some important base-classes/interfaces) and a bunch of plugins like: AWTEngine, SwingGUI, OpenGLGUI, OpenCLEngine, QtGUI ... etc. etc.