minowicz
May 23rd, 2007, 11:32 PM
In an earlier thread I suggested that someone look at the possibility of a 3D cube implementation of the gnome MDI. That got me thinking.
So this is a bit raw as an idea at the moment, so forgive me if I fail to be clear. I could imagine CompComm as a provider of general transformations, animations, effects, and so on for arbitrary X windows. This could decouple the effect from the rest of a plugin and allow it to be assigned to not just all windows, or a given class of windows, but also to a widget, or even a particular widget instance in a particular application. I'm not sure exactly which direction control of this should work... perhaps the application or the desktop environment framework, or the widget toolkit would have to be made aware of the availability of compcomm effects that were available, or perhaps compcomm would simply be able to swoop in and do its thing by being aware of the windows/widget/etc (something akin to the "Window Specific Settings" plugin.
One example would be the 3D cube as applied to the gnome MDI. Rather than desktops on the cube, there are documents, one to a face. In perhaps something like xrdb fashion you'd be able to drill down and say that MDI widgets in a particular application should use the 3D cube page flip on the MDI switch from doc to doc.
I expect that it would mostly require the application-side stuff to do the thinking... first, test to see if compcomm is available, then check to see which effects are available, then use the configured effect if it is available, or fallback to some other behaviour if it is not. The thing is, if you provide the framework for this, then it becomes simpler for say, Gnome, to start building apps that are compcomm aware, or for GTK+ to support certain sorts of compcomm capabilities without breaking compatibility of losing its cookies if the composite manager goes away unexpectedly.
I dunno... partially formed thoughts are something I normally keep to myself. I like to present fully baked thoughts instead, but I figure I'll throw this one out there and see what happens.
So this is a bit raw as an idea at the moment, so forgive me if I fail to be clear. I could imagine CompComm as a provider of general transformations, animations, effects, and so on for arbitrary X windows. This could decouple the effect from the rest of a plugin and allow it to be assigned to not just all windows, or a given class of windows, but also to a widget, or even a particular widget instance in a particular application. I'm not sure exactly which direction control of this should work... perhaps the application or the desktop environment framework, or the widget toolkit would have to be made aware of the availability of compcomm effects that were available, or perhaps compcomm would simply be able to swoop in and do its thing by being aware of the windows/widget/etc (something akin to the "Window Specific Settings" plugin.
One example would be the 3D cube as applied to the gnome MDI. Rather than desktops on the cube, there are documents, one to a face. In perhaps something like xrdb fashion you'd be able to drill down and say that MDI widgets in a particular application should use the 3D cube page flip on the MDI switch from doc to doc.
I expect that it would mostly require the application-side stuff to do the thinking... first, test to see if compcomm is available, then check to see which effects are available, then use the configured effect if it is available, or fallback to some other behaviour if it is not. The thing is, if you provide the framework for this, then it becomes simpler for say, Gnome, to start building apps that are compcomm aware, or for GTK+ to support certain sorts of compcomm capabilities without breaking compatibility of losing its cookies if the composite manager goes away unexpectedly.
I dunno... partially formed thoughts are something I normally keep to myself. I like to present fully baked thoughts instead, but I figure I'll throw this one out there and see what happens.