When you say 'wacky' and 'bizarre logic' I'm inclined to think that you don't understand that the labelling was mainly to illustrate the concept of a virtual screen -- which is quite simple but you don't seem to understand it yet.
I'm sorry, but from the looks of it, what you've got there is a hack that tries to make up for an interface that's seriously lacking competently designed customization options. I'd have to see it in action to really get a feel for it, but from what I can see that set up would be un-intuitive and frustrating for me to use.
Mouse or tablet?
I would never use this UI setup with a mouse, but with a tablet I can generally whiz around and know that if I point to X spot on the tablet i will arrive at the color selector, or layers dialog, or.. without any keypresses or window-raising clicks.
My main beef with GIMP has always been it's floating palette design. Apparently they choose this road with the best intentions--to let the user design his or her own interface--but the problem is they divided the interface into islands. We both agree on not wanting to waste interface real estate with uneeded palettes, but I much prefer to set up my interface with dockable palettes that expand on mouse overs,
That's a nice idea (and would be a good idea for gimp -- I'm not sure how you'd make it play nice with the WM). In my screenshot, all of the palettes that are visible are things I'd like to see constantly, but your scheme might work well as long as the rollovers' position remained fixed
Oh, you do realize that gimp's palettes are dockable, have been for some time? (since 2.2+) -- If not, your comments may not have much relation to the current Gimp UI
The Gimp UI has changed a lot since 1.3 or even 2.0 (and it's fair to say it's almost uniformly improved)
I haven't used XSI, but Blender's UI seems remarkably similar to it; its only downfall is it operates on only one document (which is IMO unacceptable for image editing software like GIMP.) It keeps things both compact and accessible, at the cost of *requiring* pointer-based navigation (is this also true of XSI?)
and I especially want to have one unified main window that ties all the menu items together.
I see how XSI handles it, after a bit of googling. that could be good
If they'd have done a good job with the dial-a-style setup, I wouldn't have a problem with it, but in The GIMP's case, I'd say the project would have been much better off with a specific unified layout from the start.
Yes. Well, until somewhere in the universe, someone invents a kind of windowmanagement that's actually cooperative with that, we'll probably have to settle for either Single Document Interface, like XSI, or that dopey windows-in-windows thing (which is a specific implementation of Multiple Document Interface.)
XSI, for example, does a great job on cramming tons of palettes into the interface while still leaving room to work, even though it lacks a lot of customization options. They have a specific workflow that users should learn, and it works quite well, and works virtually the same on Windows or Linux.
Virtual screens may be useful to some, but gaining more workspace via higher native resolution is a better option. Running at higher resolutions like 1600x1200 are a much better fix to solve the "omg I have too many palettes" problem, but it's still just covering up the fact that it could be done much, much better. Yeah,
Why? You still have all those palettes on screen at all times. Virtual screen is not like a virtual desktop -- it's just like sliding a windowframe around on a larger piece of glass -- it scrolls smoothly rather than flipping.
In fact, it sounds fairly similar to the rollover idea in the way it basically works -- point to a particular area of the screen to see a dialog, point back to some other area to get back to the image.
This rollovers thing intrigues me, I must see if I can implement it.
having palettes pop up at coordinate X in virtual screen Y on hotkey Ctrl+Alt+Z works,
Well, in my case, no shortcuts are involved, unless I want the really rarely accessed stuff; every other dialog is accessible via the menus if it's not already on-top (note the windowmanager's tabs, and gimp's tabs inside those.), and any hidden dockables, as marked in the screenshot, are accessible by mouseover+scrollwheel.; nor are coordinates involved; the dockables simply are all there upon gimp startup, and are in the appropriate frames (which are fixed rather than floating -- think of the screen being made up of tiles of different sizes.)
but that's something that should be handled solely by the application, identically across all platforms; not by some app/wm/os dependant setup.
Well, I agree there; I think that the prevalence of the document-window-in-app-window idea reflects a shortcoming in Windows' window management. A flaw which is also present in most Linux WMs. They do not follow through on the idea that a windowing environment should leave the user alone with the app. I believe the 'tiled-frame' setup addresses this well, though it certainly requires some forethought. It isolates whatever app you are currently working in so that the only evidence of other apps is the tab bar (which can be hidden) -- or you can chuck them between frames freely if you need to work on two things at once, still you never run into window overlap annoyance or have to look at even a fractional bit of content of an irrelevant window.
Definitely, if I was using this just for GIMP, it would be going to undue lengths.
But it works pretty good for other things too:
(note all the apps tabbed in one frame. The weird words are not, in fact, a joke.)
With all that said, the color scheme and buttons are pretty cool looking...
Thanks
I made the theme myself, I called it AmigaPixel. The scrollbar needs work, I believe. Otherwise I'm pleased with it.
Poll