Hi,
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Matthias,
I've just deregistered
/IMPLEMENTATIONS/org.openoffice.comp.dbu.OApplicationController
and that seems to get rid of the complete Base UI. Can you think of
any bad side effects this may have? Is this controller used for any
other services we might need?
Nope.
BTW, is there a reason why you deregister the abstract service and the
implementation in your example instead of just the implementation? Is
there a service I should be deregistering in addition to
/IMPLEMENTATIONS/org.openoffice.comp.dbu.OApplicationController?
It was a minimal attempt to keep the registry consistent, even if slight
inconsistencies don't cause real harm.
Normally, the structure is as follows:
SERVICES
service_A
implementation_A_1
...
implementation_A_n
service_B
implementation_B_1
...
IMPLEMENTATIONS
implementation_A_1
<how_to_obtain_that_implementation>
...
...
implementation_A_n
<how_to_obtain_that_implementation>
...
implementation_B_1
<how_to_obtain_that_implementation>
...
By removing IMPLEMENTATIONS/implementation_X_Y, you completely get rid
of one implementation (Y) for one service (X), however, the
SERVICES/service_X node is causing an inconsistency then.
By removing the complete SERVICES/service_X node, you get rid of *all*
implementations for this particular service, though the
IMPLEMENTATIONS/ipmlementation_X_* nodes cause inconsistencies then.
For a service which, as we know, has exactly one implementation,
deleting both SERVICES/service_X and IMPLEMENTATIONS/implementation_X_1
gets rid of the concrete implementation, and leaves the registry consistent.
To make it clear, this will be a hack and no official recommended way to
do that. How these services and implementations entires are managed
internally is an implementation detail and you should not expect that it
will not change.
Juergen
I conclude that the following would probably be a good course of
action to enforce our policy:
- install with Base enabled (to make sure we have the DSB and other
stuff we need)
- de-register some services (probably just dbu.OApplicationController)
- de-register .odb extension
- remove "Database" from all Popups and the File Filters
De-registering the filter is done somewhere in the configuration, and
should automatically remove the respective entries in the file-open
dialog. But don't ask me *where* exactly, the filter configuration is a
closed book to me :)
That should achieve the restrictions we want without the risk that
some stuff we need will disappear in the future as the "Install
without Base" feature progresses.
Well, be aware of the fact that especially de-registering the services
is not an officially supported way. It works, and most probably will
continue to work, but there is a chance that it won't for all time
(however, it *will* for 2.0).
At least, you should go the safe way and search all implementation_X_*
for a service_X, and remove all of those from the IMPLEMENTATIONS node.
This way, your macro needs to know the service name only, and this one
is fixed - as opposed to the implementation name, which is an
implementation detail and can change without any notice.
Do you see a way for us to achieve the last part, i.e. removing
"Database" everywhere for a standard installation with Base enabled?
Christian Junker mentioned the programmatic access to the toolbar
icons, but I guess that this won't allow us to remove "Database" from
the quickstarter popup.
The only way I know to achieve this is by removing "Base" from the
installation. However, it might be that the dispatch interception
mechanism overrules this, so perhaps you can leave "Base" intact, and
still disable the entries with dispatch interceptors. Not sure.
However, since the only thing which disabling "Base" does is removing
the DSB, there might be another way:
- disable Base. This will remove the "New database" entries from
everywhere, and the filter from the file-open dialog
- create a dispatch interceptor for the DSB slot which properly opens it
(and properly handles the state). This will overrule the built-in
behaviour of disabling the slot when Base is not installed
- disable the GUI with de-registering the services as needed.
Not sure how laborious the second item would be, admittedly.
Ciao
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
