From 267c6f2ac71f92999e969232431ba04678e7437e Mon Sep 17 00:00:00 2001
From: Daniel Baumann
+ What kind of URLs a frame accepts in the calls to XDispatchProvider::queryDispatch(),
+ and how the returned dispatcher handles dispatches is completely implementation dependent
+ (though of course the restrictions of XDispatchProvider must be met).
+ Frame implementations may (optionally) support special targets in the call to
+ XDispatchProvider::queryDispatch().
+ Such special targets are passed as target frame name. They may, in addition,
+ require special frame search flags (see FrameSearchFlag), or,
+ in opposite, limit the set of allowed flags.
+ Common special targets include:
+
+
+
is used to create a new frame when dispatching the URL.
is used to recycle empty or create a new frame when dispatching the URL.
forces the frame to dispatch the URL into itself. ("" means the same)
dispatches the URL into the parent frame.
dispatches the URL into the top level frame, the frame where this is invoked belongs to.
+ Registered objects can intercept, suppress or reroute dispatched URLs. + If they support another interface too (XInterceptorInfo) + it's possible to perform it by directly calling of right interceptor without + using list of all registered ones. +
+ */ + interface XDispatchProviderInterception; + + /** provides access to sub frames within this frame + */ + interface XFramesSupplier; + + /** regulate life time of desktop environment and support high level + access to components of sub frame tree + */ + interface XDesktop; + + /** supports simple API for loading components into the frame environment + */ + interface XComponentLoader; +}; + + +}; }; }; }; + +/* vim:set shiftwidth=4 softtabstop=4 expandtab: */ -- cgit v1.2.3