Re: [dev] How to keep users away from Base
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 ... ... implementation_A_n ... implementation_B_1 ... 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]
Re: [dev] How to keep users away from Base
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 ... ... implementation_A_n ... implementation_B_1 ... 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. > 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 -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
On 7/21/05, Frank Schönheit - Sun Microsystems Germa ny <[EMAIL PROTECTED]> wrote: > Hi Matthias, > > >>One could manually de-register certain UNO services, so that certain > >>functionality becomes unavailable. > > > > How do I do that? > > The following snippet exemplarily disables the query design, but > de-registering the service which implements it: This is cool. Thank you. I think this will be very useful, especially since we can write programs that enable or disable the functionality on request. 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? 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? 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 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. 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. Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
> The following snippet exemplarily disables the query design, but > de-registering the service which implements it: s/but/by/ Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Matthias,
>>One could manually de-register certain UNO services, so that certain
>>functionality becomes unavailable.
>
> How do I do that?
The following snippet exemplarily disables the query design, but
de-registering the service which implements it:
Dim oPathSubst as Object
oPathSubst = createUnoService( "com.sun.star.util.PathSubstitution" )
Dim sRegistryLocation As String
sRegistryLocation = oPathSubst.substituteVariables( _
"$(prog)/services.rdb", true )
Dim oRegistry as Object
oRegistry = createUnoService( "com.sun.star.registry.SimpleRegistry" )
oRegistry.open( sRegistryLocation, false, false )
Dim oKey as Object
oKey = oRegistry.getRootKey()
oKey.deleteKey("/SERVICES/com.sun.star.sdb.QueryDesign")
oKey.deleteKey("/IMPLEMENTATIONS/org.openoffice.comp.dbu.OQueryDesign")
oRegistry.close()
After this, clicking onto the "Create Query in Design View..." task does
nothing - which isn't really what I would call good usability, but since
this is kind of an unsupported workaround only, the best I can offer ...
The above should work equally well for the table/relation design, and
for the usual wizards (table/query/form/report). However, disabling the
dialogs for changing the database properties is not possible this way.
But the DispatchInterceptors mentioned elsewhere in the thread should
allow you to disable the respective menu items.
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Database http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Frank, Frank Schönheit - Sun Microsystems Germany wrote: Hi Sophie, Huh? Sorry, what tables do you want to drag'n'drop in this dialog? Not in the new tools>options>base dialog, but we are not able any more to copy a table from one db to another by a simple drag'n drop in the DSB, or is it a bug ? Issue 39146, targeted for 2.0.1 :) Thanks, Frank, happy to see that it's a bug and not a feature ;) You can still do this in the application windows, but that's admittedly not remotely as convinient as in the DSB. yes. Kind regards Sophie -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.1/51 - Release Date: 18/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Sophie, >>Huh? Sorry, what tables do you want to drag'n'drop in this dialog? > > Not in the new tools>options>base dialog, but we are not able any more > to copy a table from one db to another by a simple drag'n drop in the > DSB, or is it a bug ? Issue 39146, targeted for 2.0.1 :) You can still do this in the application windows, but that's admittedly not remotely as convinient as in the DSB. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Matthias, > I've just tested m118 without Base and I like the feature set. I > especially like the reduced Base dialog that allows the user to edit > existing databases and to use existing queries but does not allow > saving to another file, creating new tables or queries etc. > From the POV of our policy this seems even more useful than having no > Base UI at all, because that way users can still work with existing > databases provided by the admin but can not create their own. > ... > Well, in m118 you can open them with File/Open, but there's not filter > for odb files, you have to use "All Files". Uhoh. The fact that you can still open databases by simply using a more generic filter in the dialog is a bug which I did not dare to mention :-\ So, be prepared that this will change some time (or at least users will be given control over it at installation time). However, regarding this particular bug, and also the "Future Tasks" in the specification, be assured that it's *most* unlikely that anything will change 'til 2.0. The changes we would need to do for this are simply not important enough for 2.0 anymore, so this is definately an 2.x issue, at most. Thus, in all conscience: You can rely on the current state being the same in 2.0. > I also like that the Mail Merge wizard still exists and the > Insert/Fields/Other.../Database tab still works. If those are ever to be removed when Base is disabled, then I would definately make this a separate option, independent from the main Base GUI. Something like "also do not install application integration". > In m118 the DSB can still be invoked programmtically with the code you > helped me write recently. So we can provide our own macro and button > to open it and it's not really a problem that it's gone. Yes, only the UI to access it is removed. >>>Any other ideas how I can make life more difficult for users who want >>>to use the Base GUI? >> >>One could manually de-register certain UNO services, so that certain >>functionality becomes unavailable. > > How do I do that? Which concrete functionality do you want to disable? The basic idea is that a lot of functionality exists and is invoked as UNO service. Registered services are managed in the "services.rdb" in the program directory (which implies everything you do applies to all users of an installation, which probably is what you want). AFAIK, you can remove services from the services.rdb programmatically, but I would have to look up or ask myself. Something in the com.sun.star.registry module - I know I once did it, but lost the code ... Will try. So depending on which functionality you want to remove, we need to find the respective service name, and revoke it from the registry. > Well it looks like the way implemented in m118 would be enough to > solve my problem, although I will have to discuss this with my > superiors before I can be sure. The thing I'm worrying about is how > stable the m118 feature set is. Reading [1] gives me the impression > that it is not stable, that disabling Base at installation time will > remove more functionality in future. As said: It's most unlikely that anything will change for 2.0, and for later changes, I hope we will do it right and allow fine-grained control at installation time. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Matthias, there are some new API features available in 2.0 and one of them would certainly be of great benefit to you: programmatic GUI-control, meaning full control over menu items and toolbars. Recently there were some talks on [EMAIL PROTECTED] about those new things, as you can check when searching through the archives. Currently the api project webpage does not reflect oo 2.0 beta status, thus you need to get the newest sdk available to read yourself through provided documentation on that area, I believe the newest sdk is m113 right now. The ones of interest for you would be css::ui::XUIConfigurationManagerSupplier and related objects, as well as css::frame::XLaoutManager . In principal you could easily disable, hide or delete certain menu entries or toolbar icons, thus giving the user no way to easily open up a new database document for example. And if you don't want to go this way, there is even the chance of registering your own component integrating a DispatchInterceptor which actually can receive every single ui dispatch possible, which would give you even more control about what happens when a user clicks this or that button (dispatch slot ids can be found on http://api.openoffice.org). Let me know if you need some start, I have got some examples of code in Starbasic. 2005/7/20, Matthias Benkmann <[EMAIL PROTECTED]>: > Hallo Frank, > > > For now, this basically only implies that the "New database" entries are > > removed from various places, including the ones you mentioned. > > Additionally, the data source browser (F4) is removed, > > I've just tested m118 without Base and I like the feature set. I > especially like the reduced Base dialog that allows the user to edit > existing databases and to use existing queries but does not allow > saving to another file, creating new tables or queries etc. > From the POV of our policy this seems even more useful than having no > Base UI at all, because that way users can still work with existing > databases provided by the admin but can not create their own. > I also like that the Mail Merge wizard still exists and the > Insert/Fields/Other.../Database tab still works. > > > and you cannot > > open DB files from the File|Open dialog. See [1] for details. > > Well, in m118 you can open them with File/Open, but there's not filter > for odb files, you have to use "All Files". > > > > If you only want to remove the menu entries, but not the DSB - Hmm. Not > > sure if this is possible, other people might know more about it. > > In m118 the DSB can still be invoked programmtically with the code you > helped me write recently. So we can provide our own macro and button > to open it and it's not really a problem that it's gone. > > > Removing things like the database registration (Tools|Options|Databases) > > is not possible ATM. > > That was just an idea. As long as users are more or less prevented > from creating their own databases, it doesn't hurt if they have UI to > register them. > > > > And maybe there's a way to disable the Base GUI completely? > > > > None except disabling it in the setup, with exactly the consequences > > described in [1]. > > As I've said above, I believe that the reduced Base GUI from m118 is > even better than no GUI. > > > > Any other ideas how I can make life more difficult for users who want > > > to use the Base GUI? > > > > One could manually de-register certain UNO services, so that certain > > functionality becomes unavailable. > > How do I do that? > > > This could include at least all > > services which are necessary for the UI. If the above doesn't fit your > > needs, this would be the way to go. > > Well it looks like the way implemented in m118 would be enough to > solve my problem, although I will have to discuss this with my > superiors before I can be sure. The thing I'm worrying about is how > stable the m118 feature set is. Reading [1] gives me the impression > that it is not stable, that disabling Base at installation time will > remove more functionality in future. > > And if for instance the Mail Merge Wizard disappears completely or > registering databases via UNO stops working, then installing without > Base will no longer be an option for us and we'll be in the same fix > as we're now, only worse, because by that time we'll probably have > established a policy that mandates disabling Base at install time, > that would have to be overturned (which is difficult). To make this > more clear, it won't be a problem for us if there remains a set of > install options to get back the m118 feature set, but if OO.o 2.0 > Final ships with only the option to enable or disable Base completely > and disabling removes a crucial feature, then we'll be in big trouble > if we establish a policy now based on the m118 feature set. > > Matthias > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PRO
Re: [dev] How to keep users away from Base
Hi Frank , Frank Schönheit - Sun Microsystems Germany wrote: Hello Sophie-who-is-never-happy ;-) :) The fact that in usual installations, the DSB contains less registered data sources than in OOo 1.x, can be worked around by, well, Tools|Options|Databases (and note that if you create a .odb file, the wizard usually automatically registeres it for you, if you do not explicitly uncheck the respective option). oh yes, I completly miss this new dialog, sorry (I read the specs really to quickly, if fact only read your feature description :( That was mostly what I was speaking about. Is it new since m118 or sooner ? Ehm, no, it's quite old already :). There's an RFE requesting that it can be invoked from the DSB, and your reaction again shows me that it's really a pity we couldn't do this for 2.0 anymore. well, no matter the time if it's going to happen ;) That was those one that you access bys right clicking on a table. But the dialog under tool>option simplify all the process to register db, it's great :) Only copy with drag and drop from one table to another is not possible (Sophie who is never happy ;) Huh? Sorry, what tables do you want to drag'n'drop in this dialog? Not in the new tools>options>base dialog, but we are not able any more to copy a table from one db to another by a simple drag'n drop in the DSB, or is it a bug ? Kind regards Sophie -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.1/51 - Release Date: 18/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hallo Frank, > For now, this basically only implies that the "New database" entries are > removed from various places, including the ones you mentioned. > Additionally, the data source browser (F4) is removed, I've just tested m118 without Base and I like the feature set. I especially like the reduced Base dialog that allows the user to edit existing databases and to use existing queries but does not allow saving to another file, creating new tables or queries etc. >From the POV of our policy this seems even more useful than having no Base UI at all, because that way users can still work with existing databases provided by the admin but can not create their own. I also like that the Mail Merge wizard still exists and the Insert/Fields/Other.../Database tab still works. > and you cannot > open DB files from the File|Open dialog. See [1] for details. Well, in m118 you can open them with File/Open, but there's not filter for odb files, you have to use "All Files". > If you only want to remove the menu entries, but not the DSB - Hmm. Not > sure if this is possible, other people might know more about it. In m118 the DSB can still be invoked programmtically with the code you helped me write recently. So we can provide our own macro and button to open it and it's not really a problem that it's gone. > Removing things like the database registration (Tools|Options|Databases) > is not possible ATM. That was just an idea. As long as users are more or less prevented from creating their own databases, it doesn't hurt if they have UI to register them. > > And maybe there's a way to disable the Base GUI completely? > > None except disabling it in the setup, with exactly the consequences > described in [1]. As I've said above, I believe that the reduced Base GUI from m118 is even better than no GUI. > > Any other ideas how I can make life more difficult for users who want > > to use the Base GUI? > > One could manually de-register certain UNO services, so that certain > functionality becomes unavailable. How do I do that? > This could include at least all > services which are necessary for the UI. If the above doesn't fit your > needs, this would be the way to go. Well it looks like the way implemented in m118 would be enough to solve my problem, although I will have to discuss this with my superiors before I can be sure. The thing I'm worrying about is how stable the m118 feature set is. Reading [1] gives me the impression that it is not stable, that disabling Base at installation time will remove more functionality in future. And if for instance the Mail Merge Wizard disappears completely or registering databases via UNO stops working, then installing without Base will no longer be an option for us and we'll be in the same fix as we're now, only worse, because by that time we'll probably have established a policy that mandates disabling Base at install time, that would have to be overturned (which is difficult). To make this more clear, it won't be a problem for us if there remains a set of install options to get back the m118 feature set, but if OO.o 2.0 Final ships with only the option to enable or disable Base completely and disabling removes a crucial feature, then we'll be in big trouble if we establish a policy now based on the m118 feature set. Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hello Sophie-who-is-never-happy ;-) >>The fact that in usual installations, the DSB contains less registered >>data sources than in OOo 1.x, can be worked around by, well, >>Tools|Options|Databases (and note that if you create a .odb file, the >>wizard usually automatically registeres it for you, if you do not >>explicitly uncheck the respective option). > > oh yes, I completly miss this new dialog, sorry (I read the specs really > to quickly, if fact only read your feature description :( That was > mostly what I was speaking about. Is it new since m118 or sooner ? Ehm, no, it's quite old already :). There's an RFE requesting that it can be invoked from the DSB, and your reaction again shows me that it's really a pity we couldn't do this for 2.0 anymore. > That was those one that you access bys right clicking on a table. But > the dialog under tool>option simplify all the process to register db, > it's great :) Only copy with drag and drop from one table to another is > not possible (Sophie who is never happy ;) Huh? Sorry, what tables do you want to drag'n'drop in this dialog? Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Frank, Frank Schönheit - Sun Microsystems Germany wrote: Hi Sophie, What should be gone then? The application UI? The integrated engine? The integration into other application? The integration into Writer only, or into Calc only? Well, from the feedback I had (from only one community I agree) is the fact they have to deal any time with Base (the application) when they have to edit a db or do a mailing, etc. is time consuming. One thing I would love to see, but where we need to evangelize the other applications: Currently, there are a lot of places in the applications which integrate "database functionality" of some kind: Mail Merge, Labels, Database Ranges, Database Fields, etc. All of those can work with registered databases (Tools|Options|Databases). Some of those places can additionally work with .odb files directly, but again some only let the user choose an .odb file, automatically register it, and continue with the registered database. What I think those places should ideally look like is the following: Whenever it comes to "I want to have some relational data in my non-Base application", users should be prompted where this data resides (probably some kind of wizard), and the application should continue to work with this information, *without* an .odb file, and even better *without* a registration name. That is, currently the applications understand "data from a database" as ".odb file" or "registration name", but in real it should be "all information necessary to access this database data". There's quite some work to do 'til then, and some conceptual problems to solve, but IMO this would give the best user experience (still leaving other users with the Base application, of course). Thanks for this description, imho, it would be a be a great feature, I would love to see it too :) [...] What are "the F4 functionalities"? The fact that "data to fields" (or was it "data to text"?) does not trigger the "old" mail merge dialog anymore, but the full-blown wizard, is a bug, IMO. The wizard should at least respect the selection previously made in the data source browser (DSB). ok, this bug is being worked. The fact that in usual installations, the DSB contains less registered data sources than in OOo 1.x, can be worked around by, well, Tools|Options|Databases (and note that if you create a .odb file, the wizard usually automatically registeres it for you, if you do not explicitly uncheck the respective option). oh yes, I completly miss this new dialog, sorry (I read the specs really to quickly, if fact only read your feature description :( That was mostly what I was speaking about. Is it new since m118 or sooner ? "Editing a dBase file" is possible with the DSB, too - open it, display it, and start editing :). The very same as in 1.x. So, what are "the F4 functionalities" you're missing? That was those one that you access bys right clicking on a table. But the dialog under tool>option simplify all the process to register db, it's great :) Only copy with drag and drop from one table to another is not possible (Sophie who is never happy ;) Kind regards Sophie -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.1/51 - Release Date: 18/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Sophie, >>What should be gone then? The application UI? The integrated engine? The >>integration into other application? The integration into Writer only, or >>into Calc only? > > Well, from the feedback I had (from only one community I agree) is the > fact they have to deal any time with Base (the application) when they > have to edit a db or do a mailing, etc. is time consuming. One thing I would love to see, but where we need to evangelize the other applications: Currently, there are a lot of places in the applications which integrate "database functionality" of some kind: Mail Merge, Labels, Database Ranges, Database Fields, etc. All of those can work with registered databases (Tools|Options|Databases). Some of those places can additionally work with .odb files directly, but again some only let the user choose an .odb file, automatically register it, and continue with the registered database. What I think those places should ideally look like is the following: Whenever it comes to "I want to have some relational data in my non-Base application", users should be prompted where this data resides (probably some kind of wizard), and the application should continue to work with this information, *without* an .odb file, and even better *without* a registration name. That is, currently the applications understand "data from a database" as ".odb file" or "registration name", but in real it should be "all information necessary to access this database data". There's quite some work to do 'til then, and some conceptual problems to solve, but IMO this would give the best user experience (still leaving other users with the Base application, of course). > Imho, I think that most of the new OOo users will evaluate Base (and > it's 3 meanings) as the tool that deals with database, like Writer deals > with texts. Yes. > But previous users currently see it as the tool that deals with the self > contained database document and really miss the F4 functionalities. It's > quicker to do a mailing without the wizard, it's quicker to edit a dBase > file without opening the Base application. What are "the F4 functionalities"? The fact that "data to fields" (or was it "data to text"?) does not trigger the "old" mail merge dialog anymore, but the full-blown wizard, is a bug, IMO. The wizard should at least respect the selection previously made in the data source browser (DSB). The fact that in usual installations, the DSB contains less registered data sources than in OOo 1.x, can be worked around by, well, Tools|Options|Databases (and note that if you create a .odb file, the wizard usually automatically registeres it for you, if you do not explicitly uncheck the respective option). "Editing a dBase file" is possible with the DSB, too - open it, display it, and start editing :). The very same as in 1.x. So, what are "the F4 functionalities" you're missing? >>*Whether* and *When* the other use cases will be addressed is not clear >>(to me) at the moment. It probably depends on how many users/customers >>think it's necessary :) > > Of course :) ok, so let us bring you a large feedback on this ;) :) Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Frank, Frank Schönheit - Sun Microsystems Germany wrote: Hi Sophie, As I understand it, not every body will want to use Base (HSQLDB integration) but still want to access their external database (like MySQL/SQLite/etc.) without using Base (the database environment). Am I right in using the same word ? Ehm, well. Terminology is in fact not clear here. Well I agree with you and I feel that clearing it will help users to address what they would like :) There are at least three things: - "Base" is the application, that is, at least the UI for editing database documents (no matter whether they connect to "external" or "internal" databases) - HSQLDB is the engine used when the user asks "Base" to create a self-contained database document. - There's quite some database-related functionality in the other applications. See the "Future Tasks" section in the specification I linked to, to get an idea - it's really more one would expect in the first run :) Whether this particular functionality is part of "Base" or not is debatable. For the data source browser, we decided it *is*. Ok I understand it. The problem with the "optional Base" feature (which closed in on very short notice only) is that it's in no way clear what a user expects if she disables "Base" in the setup. What should be gone then? The application UI? The integrated engine? The integration into other application? The integration into Writer only, or into Calc only? Well, from the feedback I had (from only one community I agree) is the fact they have to deal any time with Base (the application) when they have to edit a db or do a mailing, etc. is time consuming. Caring for *all* potential needs here requires much more fine-grained control during setup than the current "Base on/off" option. As you can see in the "Future tasks" capter, we're at least aware of this :). yes, I understand how difficult it could be :) Imho, I think that most of the new OOo users will evaluate Base (and it's 3 meanings) as the tool that deals with database, like Writer deals with texts. But previous users currently see it as the tool that deals with the self contained database document and really miss the F4 functionalities. It's quicker to do a mailing without the wizard, it's quicker to edit a dBase file without opening the Base application. Am I right or do I miss something or will it be possible in the future ? No, you're right, there are different use cases, while the current option addresses only one (namely installations where the users should not be able to create/modify database documents of any kind, but only use the ones provided by other parties, and still should have all application-integration). ok *Whether* and *When* the other use cases will be addressed is not clear (to me) at the moment. It probably depends on how many users/customers think it's necessary :) Of course :) ok, so let us bring you a large feedback on this ;) Thanks for your answer Kind regards Sophie -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.1/51 - Release Date: 18/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Sophie, > As I understand it, not every body will want to use Base (HSQLDB > integration) but still want to access their external database (like > MySQL/SQLite/etc.) without using Base (the database environment). > Am I right in using the same word ? Ehm, well. Terminology is in fact not clear here. There are at least three things: - "Base" is the application, that is, at least the UI for editing database documents (no matter whether they connect to "external" or "internal" databases) - HSQLDB is the engine used when the user asks "Base" to create a self-contained database document. - There's quite some database-related functionality in the other applications. See the "Future Tasks" section in the specification I linked to, to get an idea - it's really more one would expect in the first run :) Whether this particular functionality is part of "Base" or not is debatable. For the data source browser, we decided it *is*. The problem with the "optional Base" feature (which closed in on very short notice only) is that it's in no way clear what a user expects if she disables "Base" in the setup. What should be gone then? The application UI? The integrated engine? The integration into other application? The integration into Writer only, or into Calc only? Caring for *all* potential needs here requires much more fine-grained control during setup than the current "Base on/off" option. As you can see in the "Future tasks" capter, we're at least aware of this :). > Am I right or do I miss something or will it be possible in the future ? No, you're right, there are different use cases, while the current option addresses only one (namely installations where the users should not be able to create/modify database documents of any kind, but only use the ones provided by other parties, and still should have all application-integration). *Whether* and *When* the other use cases will be addressed is not clear (to me) at the moment. It probably depends on how many users/customers think it's necessary :) Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Frank, all, Frank Schönheit - Sun Microsystems Germany wrote: Hi Matthias, For instance, it would be a good start to remove "Database" from the quickstarter pop-up and the File/New dialog. How would I do that? Latest builds have a possibility to remove "Base" from the installation during setup, just as you can do with the other applications. For now, this basically only implies that the "New database" entries are removed from various places, including the ones you mentioned. Additionally, the data source browser (F4) is removed, and you cannot open DB files from the File|Open dialog. See [1] for details. As I understand it, not every body will want to use Base (HSQLDB integration) but still want to access their external database (like MySQL/SQLite/etc.) without using Base (the database environment). Am I right in using the same word ? Testing the 'with' and 'without' Base option lead us to 2 reflections: - not activating Base during install process don't let you know that you won't access to any of your external database any more (we have tested it during an event last week and users were pretty confused) - we lack a great fonctionnality (yes again ;) that was in the spirit of 1.x branch : the ability to deal with external database under F4 whatever the module you use. Am I right or do I miss something or will it be possible in the future ? Kind regards Sophie -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.1/51 - Release Date: 18/07/2005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
> See [1] for details. And here comes the missing footnote [1] http://specs.openoffice.org/installation/optional_base_module.odt Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to keep users away from Base
Hi Matthias, > For instance, it would be a good start to remove "Database" from the > quickstarter pop-up and the File/New dialog. How would I do that? Latest builds have a possibility to remove "Base" from the installation during setup, just as you can do with the other applications. For now, this basically only implies that the "New database" entries are removed from various places, including the ones you mentioned. Additionally, the data source browser (F4) is removed, and you cannot open DB files from the File|Open dialog. See [1] for details. If you only want to remove the menu entries, but not the DSB - Hmm. Not sure if this is possible, other people might know more about it. Removing things like the database registration (Tools|Options|Databases) is not possible ATM. (Completely removing it would not really be an option, since the other applications currently in parts rely on registered databases to work on, instead of database documents.) > And maybe there's a way to disable the Base GUI completely? None except disabling it in the setup, with exactly the consequences described in [1]. > Any other ideas how I can make life more difficult for users who want > to use the Base GUI? One could manually de-register certain UNO services, so that certain functionality becomes unavailable. This could include at least all services which are necessary for the UI. If the above doesn't fit your needs, this would be the way to go. However, since this is not really a supported way, there might remain artifacts in the UI. For instance, users maybe can do File|New|Database, and then be confronted with an error message only. Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] How to keep users away from Base
I'd like to rephrase my question from yesterday regarding local databases: Where I work we have a policy that says users are not supposed to keep their own databases. Sophisticated users will, of course, always find a way, but we'd like to at least remove all the obvious GUI ways to use local databases. I'd appreciate any ideas on how to discourage users from creating/registering Base databases. For instance, it would be a good start to remove "Database" from the quickstarter pop-up and the File/New dialog. How would I do that? And maybe there's a way to disable the Base GUI completely? Any other ideas how I can make life more difficult for users who want to use the Base GUI? Matthias Benkmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
