Think of it like this...right now, the resource browser and image editor are two separate functions built into the core: /manager/media/browser for the MCPUK resource browser and /manager/media/ImageEditor for the image editor. The editor only takes its calls from the resource browser via an ’edit’ button. Now, as far as the MCPUK resource browser, it’s pretty simple and it works pretty well. But I do have some reservations about it...
While doing some work on the editor plugins, I have noticed a few things about the resource browser that erk me a bit. For starters, you’re forced to inserting a small piece of javascript to the parent page that made the call to the resource browser. Thus with certain editors we’re forced to have to hack up certain parts to get it to work right with the resource browser. Some alterations to the MCPUK resource browser would have to be made in order to do away with this and make it easier to plug it into any of the editors. The other thing about the resource browser is its use of frames and I’m sure there’s a way to modify it with DHTML to do away with the frames much in the same way we’re doing right now with the core of MODx.
Now, as far as the image editor is concerned...I think we can do better than this. Although it’s pretty simple and such...I just think your average user would get too damn confused by it. Take cropping for example...the problem with cropping is that you can’t start a cropped selection from outside the image area...it has to be within the image area itself. The second problem is that the crop marks themselves are black...thus you can’t see what you’re cropping too well sometimes. Plus, it’s not always clear on whether you are selecting the handles of the crop window or not. From a useability standpoint...it leaves a bit to be desired...that’s all.
What I’d really like is something that has the both of best worlds: an easy to use file manager that allows such things as renaming files, possibly the moving of files and folders from one spot to another, and the ability to see a preview of any image. Plus, simple image editing capabilities built-in: cropping, resizing, flipping, rotating...the basic stuff. More or less what we have now but something that is also much easier to configure as an addon/plugin to any of the RTE’s we’re using. To me, the iManager is a pretty big candidate for this since it was written to be a plugin for all the editors to begin with...thus it would be easier to start with it and modify it to meet our needs.
I can already tell from this thread that each person is going to look at these things differently. However, what I’m hoping to do is standardize the way calls are made to the resource browser. That way we could pull the resource browser from the core and treat it like a plugin. From there we can then create different ’resource browser’ plugins, thus allowing people to pick and choose which one they want to use much in the same way RTE’s are now. The trick is going to be in the standardization of it. Typical variables to target will likely be the location of the resource browser itself, what resource to use (images, flash, files, etc.), the name of the field to use, and possibly even the name of the parent window to target. And since each of the RTE’s deal with the use of a resource browser differently, it’ll take a little work to get it all to work across the board.

However, before I even start to think about developing this, I’ll need a few more system events added to the core, particularly some Resource Browser events: OnResBrowserInit and OnResBrowserRegister possibly? Just a thought.
In the meantime, I suppose what we could do is find a better replacement for the image editor in MCPUK. I’ll be playing with iManager to see what can be done with it as well.