Re: [dev] paths configuration in v2.0.4
Allen Pulsifer schrieb: I'm looking over the new Path's configuration and it seems to me the implementation is awkward and does not follow the usually configuration paradigm. In OpenOffice.org v2.0.3 and prior, paths were configured via org.openoffice.Office.Common/Path/Default and org.openoffice.Office.Common/Path/Current. This mechanism followed the usual paradigm of key-value pairs, where the key would tell you what information you were looking for, and the value would tell you the setting. So for example, if you wanted to know (or set) the default value for the template's path, you would look at org.openoffice.Office.Common/Path/Default and retrieve (or set) the value of the key Template. The Current/Default distinction in that place was misguided. That should really be achieved via layering. This system had several advantages: (a) If you want to know or set the value for a particular key, you can access it by key name. (b) The value for a key could be overridden by a short fragment of XML, at any configuration layer. Yes, getting and setting these values is much easier this way. The point of the change (apparently, I wasn't involved in this) is: - (Many/all) the affected settings are multi-valued (i.e. lists of pathes) and were realized as string-lists. - A string-list really is treated as a simple value by the configuration. Layer merging replaces the entire list rather than attempting to merge it. (Yes there are reasons for that.) - Some of the pathes need to be there for builtin features to work, if they are taken out of the list those features break. - Some of these 'internal' are determined at install time and so should be added to the lists by the layer merge. - Among the list, at most one path is special in that it is used for writing user changes. Determining which one that is from its position in a string-list that users can change arbitrarily is very fragile. (c) The key-value pairs could be stored in a database, in a traditional way. The new configuration mechanism for v2.0.4, as documented in http://specs.openoffice.org/appwide/options_settings/OOoPaths.odt, replaces the usually key-value pairs with the following: The configuration settings were moved to org.openoffice.Office.Paths. Within this tree, there is a node for each path (Template, Dictionary, Basic, etc.). For each path: a. There are two key-value pairs, UserPaths and WritePaths, that work as expected. The separation addresses the last point above. b. There is a third subtree, InternalPaths, that contains a set of what could be considered keys. These keys work completely differently. For the keys in the InternalPaths tree, the key is the value and the value is completely ignored. There are other places in OOo where dynamically created keys have such significance. This is the only way to get mergeable lists of strings. For example, for the Template path, InternalPaths contains a key named $(insturl)/share/template/$(vlang). (I've simplified it slightly by calling this a key; its actually not even a key, it's a group of type MultiPath that's named $(insturl)/share/template/$(vlang) and forms another subtree that contains a single key Unused that is completely ignored. Thus the name of the group or subtree is what serves as the value, and both the key within this group and its value are ignored). That is slightly more complex than needed, because the project team didn't notice that the configuration supports 'extensible' groups, which act as sets of simple values. Or else it would have been possible to make groups with no members work. This has more than a few disadvantages. First, as far as I can see (but please correct me if I am wrong) it is not possible to write a short fragment of XML that overrides the value of this setting, therefore making true layered configuration impossible. That is the intent - these keys are required so it shouldn't be easy to clobber them. OTOH adding to or deleting from that list with a fragment of XML is now possible (and wasn't before). There even is a feature of the XML format that would allow completely replacing the contents of that set - but the implementation of that in OOo is somewhat incomplete and not active (oor:op='clear'). And you could easily replace the entire 'Templates' node, if it didn't have an attribute (mandatory='true') that is explicitly meant to prevent this. Second, it is not possible to look this value up or set the value by name, instead, to look the value up, or set the value, you have to already know the value, i.e., the value is looked up or set by value and has no independent name. OOo does not have a raw key-value pair API for its configuration. Instead you can navigate the hierarchy as objects. The object for the config node /org.openoffice.Office.Paths/Pathes/Path['Template']/InternalPath (yes, that is the correct and complete spelling of the key!) has a method getElementNames(), which
Re: [dev] configmgr patch more data ...
Hi Michael, Michael Meeks schrieb: On Wed, 2006-09-13 at 12:22 +0200, Joerg Barfurth wrote: Looks good. I fixed your issues; thanks for the feedback, I attach the improved patch. I also expanded the cache to some more fields that are broadly constant, and split it into 1 cache per re-usable field. It saves some more memory. Yes, there are some patterns at the various levels which you can exploit that way. Looks fine at a cursory glance. I'm also looking at the Subtree set usage: http://go-oo.org/~michael/sortedsizes.ods My concern here is the 16bytes per RBTree node (used in the set), at least allocation here shows up on the profile. Does that matter so much? I think SubTree instances should be shortlived (they are built while loading the data, but discarded when the data is flattened into the cache). But cutting down on the allocations used (and maybe improving data locality) would be nice. It seems that 90% of these sorted sets are 8 items or less, and thus (I suspect) rather fast to search, well, at least indistinguishable from the order of the Set. The RBTree overhead for these = 8 sets is ~250k (malloc), overall 500k. I'm sure we can do better. It might be worth checking what ends up cheaper: building a sorted array and using binary search for lookups or going unsorted and using linear search. The former might be worthwhile, because we would get the lists out of the binary cache presorted. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] RestrictedPath working under Windows?
Hi, Frank Schönheit - Sun Microsystems Germany schrieb: I would also be interested in changing RestrictedPath from an environmental variable to a configuration (.xcs/.xcu) setting. Is there a specific reason an environment variable was chosen over a configuration setting? The idea was to have a feature which prevents users from changing the respective setting. Nowadays, where the configuration supports locking settings into readonly state, probably nothing is to say against making this a configuration setting. So how was that supposed to be used? I assume that would be by editing the soffice script to set that variable before invoking soffice.bin? (Otherwise a user could always overwrite an environment variable just as easily.) Not well suited for Windows use then, where there is no existing script How could changing to a configuration setting be done without adversely affecting existing users -- use the configuration value if it is set, otherwise look to the environment variable? The order probably doesn't matter, but something like this, yes. The most correct would be to use a configuration value with no default, which means you get a NIL value (a VOID Any in UNO) when reading. Then you could have VOID - look at environment Non NIL - Use the value If the setting is a list of pathes or URLs, the best value type would be string-list (Sequence String in UNO) . Note that an empty string-list is distinct from NIL. The one thing this doesn't permit, is using an empty string-list to signify NO allowed folders. HTH, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] finalized configuration and security
Allen Pulsifer schrieb: A node in the OOo registry can be marked finalized, in order to prevent its value from being changed by users. See http://util.openoffice.org/common/configuration/oor-document-format.html#Acc ess_Control Question: is finalized intended to imply a security assurance that a user cannot actually override the value? No. See below for more detail. It occurs to me that a user would likely be able to override a finalized value by editing the binary .dat files in $(user)\registry\cache\ Yes, that would in fact be possible, if tedious: you need to parse the binary format, find the place(s) to change, patch those values and whenever the cache is regenerated you have to redo this and then restart the office. There are simpler ways to circumvent lockdown (see below). To prevent the user from manipulating the cache, you can switch off use of that binary cache - of course at the cost of slower application startup. To switch off the binary cache, you can edit $officeinstall/program/configmgrrc (configmgr.ini on Windows) and change the CFG_CacheURL entry to be empty ['CFG_CacheURL=']. Alas, that still doesn't give you a security assurance :-o ++ The primary means to circumvent this kind of lockdown, is this: The file configmgrrc/configmgr.ini (see above) contains the 'bootstrap' configuration for the configuration service. It describes which things to merge, etc. This is bootstrap configuration as described in [1],[2]. That means the value from the rc/ini-file can be overridden on the command line. Thus a user can create a private copy of the shared configuration, edit it freely and then use 'soffice -env:CFG_Strata=...' to start the office on his private copy. Instead of maintaining a full private copy, the user could also add a layer of his own that forces only selected entries. By using 'soffice -env:BaseInstallation=...' this mechanism can even be exploited to replace things beyond the configuration database. ++ General comment: IMHO you generally can't do desktop application lockdown with strong security. A purposeful, skilled and malicious user can get around those things. Lockdown can only prevent users from doing disallowed things without skill and criminal energy. In most contexts it should be sufficient accompany lockdown with policy that threatens suitable consequences for circumventing the restrictions. But a security strategy should assume that users can do anything their system privileges allow within their own environment. - Jörg References: [1] UNO Micro Deployment http://udk.openoffice.org/common/man/concept/micro_deployment.html [2] Uno Bootstrap Specification http://udk.openoffice.org/common/man/concept/default_bootstrapping.html -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] how to create your own configuration reader in OpenOffice.org (configmgrrc)
Hi Christian, Christian Andersson schrieb: Hi there, I have some questions regarding the configuration system within openoffice. (as you will se from below I'm not that good with how OOo works internally, nor c++) I think I partly understand that basics about what it does (reading configuration files from different places, etc) and what can be done using this, but I have come to a situation where I need to read the configuration from a server using http/soap/etc instead of local files. today I have it working so that it can read these files using com.sun.star.comp.configuration.backend.LocalStratum but that can only read from file:// and not from http:// from what I understand this stuff can only be done in c++ right now, not java. Not so. The backends are accessed as UNO services and can be written in any language suitable for writing UNO components. This includes Java and even Python. The only premise is that the UNO language binding does not access the configuration database for its own startup configuration. IIRC that used to be a problem with Java in OOo 1.1.x, but shouldn't be the case any more in OOo 2. so my questions will be.. how can I create my own version com.sun.star.comp.configuration.backend.LocalStratum that instead of reading from the harddrive it reads over http.. We did create a modified version of the Configuration chapter in the developer's guide that explains the services and interfaces involved in this. Unfortunately it seems to have not made it into the OOo 2.0 version of the guide. I'll check if I can find it somewhere and get it up onto the website. The short summary is: You need to create a UNO service that implements one of the abstract services com.sun.star.configuration.backend.SingleLayerStratum [1] or com.sun.star.configuration.backend.MultiLayerStratum [2]. This essentially amounts to implementing the methods of the XSingleLayerStratum or XMultiLayerStratum interface to return a Layer object whose XLayer::readData method reads and parses from your data store. If you store your data in the 'xcu' XML format, you can use the existing com.sun.star.configuration.backend.xml.LayerParser service to implement the Layer object. All you need to do is provide an XInputStream to read the data. If I manage to write my own configurationreader can this then be installed using unopkg? or do I have to compile it within my own version of OpenOffice.org? You can install such a backend using unopkg add --shared. That will not automatically enable its use for the standard configuration stack though. To activate it for that purpose, you need to add it to the CFG_Strata entry in $officeinstall/program/bootstrap. Alternatively you can have your SingleLayerStratum register itself as an instance of service com.sun.star.configuration.backend.PlatformBackend. In that case it will be used automatically through the special 'SystemIntegration' backend service. Warning: this service is still declared 'unpublished' and thus is subject to change in a future version. (I do think that is unlikely, though and changes will be announced using the interface-announce mailing list.) I have read the Developers manual, but I still have a hard time figuring out how to do this, is there any other documentation for this then the developerguide? As I mentioned this should be in the dev guide, but isn't :-( HTH - Jörg References: [1] Reference documentation for SingleLayerStratum service http://api.openoffice.org/docs/common/ref/com/sun/star/configuration/backend/SingleLayerStratum.html [2] Reference documentation for MultiLayerStratum service http://api.openoffice.org/docs/common/ref/com/sun/star/configuration/backend/MultiLayerStratum.html -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Arbitrary file from within a UNO package
Hi, Manuel Odesser wrote: Hi all, I'd like to thank everyone I had answer from ! A problem remains : I cannot find a practical sample to create a simple .xsd and its .xcu counterpart. Here are my guess, could someone tell me if I cannot access my values because of the xml or the java code ? The code. But I have some comments on your XML as well. See inline comments for more: myaddon.xsd : ?xml version=1.0 encoding=UTF-8? oor:component-schema oor:name=Settings oor:package=org.mycomp.mypackage xsi:schemaLocation=http://openoffice.org/2001/registry component-schema.xsd xmlns:xs=http://www.w3.org/2001/XMLSchema; xmlns:oor=http://openoffice.org/2001/registry; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xml:lang='en-US' import oor:component=org.openoffice.Office.Common/ You don't need that import. You don't use any templates from that component. templates group oor:name=URLs prop oor:name=dataPath oor:type=xs:string/ /group /templates You also don't need the entire templates part, as you don't use that feature in your data below. oor:component group oor:name=URLs prop oor:name=dataPath oor:type=oor:string value%config%/data/terminologie_fr_FR.dat/value Is that really a fundamental, never-to-be-changed, default for this item? Otherwise you should omit the value here. Please note that the 'origin' substitution offered by unopkg doesn't work with values in a schema. /prop /group /oor:component /oor:component-schema myaddon.xcu : ?xml version=1.0 encoding=UTF-8? oor:component-data xmlns:oor=http://openoffice.org/2001/registry; xmlns:xs=http://www.w3.org/2001/XMLSchema; oor:name=Settings oor:package=org.mycomp.mypackage node oor:name=URLs prop oor:name=dataPath oor:type=xs:string value%config%/data/terminologie_fr_FR.dat/value If your value here is identical to the default in the schema - in case you didn't follow my advice above and if you don't need 'origin' substitution -, then you don't need this prop (actually you don't need the xcu at all in that case). As a side note: the type=xs:string isn't needed here, as that is known from the schema. /prop /node /oor:component-data Now to the code the code : PropertyValue properties[] = new PropertyValue[1]; PropertyValue property = new PropertyValue(); property.Name = nodepath; property.Value = /org.mycomp.mypackage/Settings; Should be /org.mycomp.mypackage.Settings/URLs. The full component name is composed as package.component-name. And you forgot the extra 'URLs' level you introduce in your schema. properties[0] = property; XInterface xViewRoot = (XInterface)xConfigProvider.createInstanceWithArguments( com.sun.star.configuration.ConfigurationAccess, properties); XPropertySet xPropertySet = (XPropertySet)UnoRuntime.queryInterface( XPropertySet.class, xViewRoot ); dataPath = (String)xPropertySet.getPropertyValue(dataPath); HTH - Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] Thin Client Software - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] warnings01: Windows C4355 'this' : used in base member initializer list
Mathias Bauer schrieb: Nikolai Pretzell wrote: I'd however like to establish a rule that classes/functions taking a pointer to (possibly) not fully constructed classes have a comment that explicitely allows that - assuming that everywhere else it is a bug. Is a cast to the base class when passing this enough? Something like A cast isn't really a comment. And Nikolai meant that the *recipient* of the argument must be commented, telling in its header documentation (e.g. the autodoc stuff that should be there) that this use is valid. By commenting callers you don't prevent maintenance changes from breaking the callers' assumptions. aControllElement((Window*)this, MyRedId ) instead of the current aControllElement(this, MyRedId ) though I consider this to be superfluous in case of VCL Windows because *they work this way*. Why commenting something that works as designed? Using a cast where an implicit version would do is rarely a good idea, but if it does add information, it should be a static cast. A C-style cast is the worst choice here. For example if the class of *this were changed to not be derived from Window any more, the C-style cast would silently become a reinterpret_cast and the now invalid code would still compile. Additionally I don't see how using a cast here can be construed to be a comment that unambiguously states that the constructor of aControllElement allows passing a not fully constructed object? Here I would see it from the other side: the ctor implementation of aControlElement had a serious bug if it would call any virtual methods on the parent pointer it gets passed in. That is the case, if this restriction is part of the semantics of that constructor. I assume you mean that any VCL Window/Control class is required to offer this kind of semantics!? In that case there should be documentation somewhere (an appropriate common base class?) that states this, and Nikolai's suggestion is that the header for the class of aControllElement should reiterate that it implements that self-restriction. - Jörg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] warnings01: Windows C4355 'this' : used in base member initializer list
lingers. I think we have two possible ways to solve this problem. - Turn of the warning for every occurrence in the code. - Switch of C4355 for Windows globally. I'd suggest to take the warning serious and to re-look on each occurrence about this way: 1. Can the construction be re-worked so no self-reference is necessary? Sometimes this is easy by clarifying a hierarchy that could be a directed graph but currently is a non-directed one. If yes, do so. 2. If not, is the use of this safe including maintainenance in later times? If yes, see X. 3. If no, make sure there is a comment at all places, using the partly-initialized instance that it may be only partly initialized! Then goto X. X. See, if moving this from initialization section into c'tor body does any harm. (In case of dialogues, the painting takes so much time, that one could assume, the minor performance drawback of moving the initialisation into the body is negligible - but I don't know that code, so it's just an assumption.) I don't know about dialogs, but in general the ability to move this into the c'tor body requires a redesign of the classes used. For example a reference meber may need to become a pointer and suddenly you have to check for NULL on all uses. If yes, do so. If no, disable the warning locally. I find this ugly. And if we go this we we should look for a way to use a platform independent, readable way to disable it inline with the code (e.g. a SAFE_USE_OF_THIS_IN_CTOR_BEGIN macro) instead of sprinkling platform-specific stuff all over the code (or makefiles). If we just generally disable the warning, we may overlook occurrences where the use indeed is questionable. As mentioned before, I don't think this case is special enough to warrant all this overhead when equally dangerous, similar cases are left without warning. There can be a coding/code review rule about self-referentiality and use of 'this' in a constructor context and maybe another one about one- vs. two-stage (de)initialization. But as the warning cannot check the entire rule, it may even be detrimental, because it creates a false sense of security (the compiler detects violations of this, so I don't need to check myself). -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] Thin Client Software - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] No TypeDetection.xml in Ooo 2.0?
Hi, Gautham Kasinath wrote: I was wondering if the TypeDetection.xml is still available for the Ooo2.0? In the documentation it is mentioned that TypeDetection.xml is present in: OfficePath\share\config\registry\instance\org\openoffice\Office\TypeDetec tion.xml However, there is no such tree on my installation. Any pointers? You are looking at very old documentation. The old *.xml configuration existed only in OOo 1.0.x Since OOo 1.1 there is a new system based on a different XML-based format marked by the .xcu extension. These xcu files are located under officepath/share/registry, but the UNO package manager has support for adding specific settings for add-on packages. In OOo 1.1.x the filter settings were stored in TypeDetection.xcu files, but in OOo 2.0 these have been replaced by several xcu files under a TypeDetection prefix. (AFAIK OOo 2.0 still honors 1.1-style TypeDetection.xcu files for compatibility, if they are installed by your package). Do I need to edit TypeDetection.xml for Import Filters too? Yes. The Developer's Guide (there are versions for OOo 1.1.x and OOo 2) should contain documentation how to create Typedetection configuration for your filter. HTH, Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] Thin Client Software - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to compile OpenOffice ?
sebastian schrieb: Build instructions: http://tools.openoffice.org/dev_docs/build_linux.html That was the hint I needed, thank you verry much Rene. OK. all works fine. But I get an error at compiling this package (OOo_2.0.1rc5_src.tar.gz). ... Try another version of bison. And report back which version was broken for you, if the above link doesn't already tell you so. BTW: The most topical list for build issues is [EMAIL PROTECTED],org Ciao, Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to remove a xcu-file from userspace
Hi mathias, Mathias Bauer wrote: Unfortunately there is no API to control the finalized attribute (and some other similar node attributes), so you have to do this by editing the configuration file directly. I wouldn't call this unfortunate. Without an API you can make *sure* that the value is not changed by a macro, Add-On or something else. IMHO this is important to make the finalizing feature useable. It is stored in a file and a macro, etc. could simply manipulate the relevant file and then force a reload of the configuration. It gets just more tedious. But that is unfortunate as it also disallows building administration tools upon our UNO services. Instead such tools have to manipulate the XML directly which is more prone to producing files our services can't read. *If* we had such an API we would at least need an access control to it (or an API that is disabled inside OOo and is only accessible if the configuration service is used in another environment that supports some authentication etc.). It is the same as for the shared default values themselves. Currently we don't have explicit access controls for them. Instead we rely on the backend to limit access. E.g. for the standard file-based configuration backend the file system access controls apply. The result is automatically consistent with control (or lack thereof) of direct access to the files. On file systems that support this we install shared files with access rights that prohibit ordinary users from manipulating them. That would also prevent these users from removing finalization. Users that do have sufficient access to the backend can use the ConfigurationAdministrationProvider to change the default values - even finalized ones. But they can't remove (or add) the finalized state itself. To me that is an unfortunate inconsistency. unfortunate. Ciao, Jörg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] How to remove a xcu-file from userspace
Hi Christoph, Christoph Lutz wrote: Hi, I would like to remove the xcu-file my_applicationdata\OpenOffice.org2\user\registry\data\org\openoffice\Office\Commands.xcu in a programmatic way to ensure, that no user-configuration overwrites the shared Commands.xcu. Does UNO provide an API to to remove a configuration ressource from user-space? The configuration API Objects in many locations support interface com.sun.star.beans.XPropertyState (and com.sun.star.beans.XMultiPropertyState). You can use these to reset configuration setting to their default values, which amounts to removing overrides from the user layer of the configuration. Currently these interfaces don't work recursively on entire trees (although that would be covered by the service specification), so resetting data for an entire component isn't easy (you need to walk the hierarchy and reset locally everywhere). But if you only want to prevent overrides of your shared Commands settings, there is an easier way: In the shared Commands.xcu add an attribute 'oor.finalized=true' to the root of the part(s) you want to protect from being overridden. The range covered can be anything from a single prop ..., to the entire oor:node ... that defines the component. As a result these settings (and any settings done on layers preceding the one where you add the attribute) will be protected from being overridden by subsequent layers including the user layer. In the API these settings will appear as read-only now. If there are existing overrides in the user layer they will be ignored. Unfortunately there is no API to control the finalized attribute (and some other similar node attributes), so you have to do this by editing the configuration file directly. Ciao, Jörg BTW: Sun has a configuration manager for StarOffice that allows doing this through a web-based interface. -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] warnings01: reftotemp
Hi,
Stephan Bergmann wrote:
C().doSomething();
produces a
Warning, reftotemp: should not initialize a non-const reference
with a temporary.
[..]
[Some sort of personally biased rationale for switching that warning
off: For a start, I never quite understood the rationale behind
forbidding passing a temporary to a function via non-const
reference---C++ is generally a shoot yourself in the foot if you feel
like it language, and the safety-measure installed by this error does
not really fit that philosophy.
The problem here are unintended/unforeseen implicit conversions.
Combined with overloading this can cause code to compile in surprising,
erroneous ways. The simple example would be:
void inc(int val) { val++; }
void inc(long val) { val++; }
void inc(double val) { val++; }
void inc(std::string val) { val.append(+1); }
short s = 0;
unsigned int u = 0;
float f = 0;
const char * t = 0;
void inc_all()
{
inc(s);
inc(u);
inc(f);
inc(s);
}
This would compile flawlessly, but without the expected side effects.
But that argument doesn't apply when calling a member of a temporary,
because implicit conversions aren't applied to the operands of a member
access operator. I don't think that warning is useful (in almost all cases).
So, if there are no objections, I would switch off the reftotemp warning
globally for all unxsol platforms.
+1
Ciao, Jörg
--
Joerg Barfurth Sun Microsystems - Desktop - Hamburg
using std::disclaimer
Software Engineer [EMAIL PROTECTED]
OpenOffice.org Configuration http://util.openoffice.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Question about installing only a single module
Hi, G. Roderick Singleton wrote: The setup guide needs to address the situation where a user wishes only to install a single module, say writer. I know that the steps should be: 1. Install core 2. install module That should be sufficient. Everything else is optional - but provides potentially useful functionality. but what about openoffice.org-gnome-integration-2.0.0-3.i586.rpm, Needed to get OOo to behave as a nice desktop citizen on gnome (respect some system preferences, etc). So installing this is still recommended unless you never want to run gnome. openoffice.org-javafilter-2.0.0-3.i586.rpm, Some import-/export filters for file formats used on some PDAs (e.g. PocketWord) - optional. openoffice.org-pyuno-2.0.0-3.i586.rpm, Support for add-ons and scripts written in python - optional. openoffice.org-spellcheck-2.0.0-3.i586.rpm, Without this, your writer won't do spell-checking. Recommended openoffice.org-graphicfilter-2.0.0-3.i586.rpm, Some filters for additional graphics file formats (e.g. flash svg export) - optional (and probably only relevant for draw or impress). openoffice.org-testtool-2.0.0-3.i586.rpm and Needed only if you want to do qa - optional openoffice.org-xsltfilter-2.0.0-3.i586.rpm More filters for xml file formats (xhtml, docbook), that showcase the xslt capabilities - optional Are these optional or what and, if not, which are required to get a functioning writer? A functioning writer should not need any of these. For a full-featured writer installing spellcheck, gnome-integration and pyuno is still recommended. Ciao, Jörg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Getting started - make troubles
Hi Billy, Billy Charlton schrieb: I'm getting started with contributing code to OOo. I've followed the guide at go-oo.org for setting up my development environment but have run into a problem with make. You should look at go-oo.org, if they have a mailing list to support the ooo-build environment (there is a #go-ooo - or similar - channel on irc.freenode.net). The ooo-build build environement is different from the one used by the openoffice.org project proper, which is what people on this mailing list (or on dev@tools.openoffice.org for build issues) are familiar with. Ciao, Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Example of use of the configuration
Hi Michele, Michele Zarri wrote: Thanks Andrew, took a look at your examples, but I am not sure anymore if the configuration service is really what I want... I guess that what I want is similar to creating a registry entry under windows XP. The configuration is the OOo equivalent of the Windows registry. Like the registry it is a hierarchical database. It differs from the Windows registry in that we require keeping track of what entries can go where by means of a schema. You can't simply create a value of any type anywhere within the hierarchy; instead you need to have a schema that describes your value, its data type and possibly default value (or a container where you can put arbitrary values). When OOo is opened (ideally already with the quick start) a string (i.e. the path to the file I want to open) is made available to the macros. (How/where the macros will read it will be the subject of a subsequent email :) ) Unless you can accomodate you data within an existing OOo configuration schema, you need to install a configuration schema of your own with your macro (you can deploy configuration schemas as part of UNO packages). When the schema is installed, you can have your macro read or write the data at any time. The data is loaded when it is first read and then kept in memory (unless it isn't referenced in 15 minutes, in which case it may get unloaded). HTH, Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Where does com.sun.star.script.BasicIDE come from?
Hi Matthias, Matthias Benkmann wrote: On 9/22/05, Stephan Bergmann [EMAIL PROTECTED] wrote: Unfortunately, services.rdb and service descriptions in UNOIDL have little in common: Interesting. Could you give me a little background information on how services.rdb is generated during the build of OOo? I was under the (apparently mistaken) impression that it's compiled from the *.idl files. If that's not the case, how does e.g. com.sun.star.script.BasicIDE get into services.rdb? Which commands/source files put it there? Every UNO component has an entry point to register itself into a registry. For C++ components, this is the component_writeInfo() function that each UNO component must export. There is a similar mechanism (iirc a registration class identified in the manifest) for Java JAR components. The services.rdb is populated by having every UNO component in OOo register itself into it. This doesn't happen as part of the build (in the strict sense). In OOo 1.x the services.rdb is built during installation by the setup program. There is a setup_services.rdb that is generated during the build (using regcomp) that provides the UNO services that the setup itself uses (e.g. the service that allows registering implementations into an rdb ..). In OOo 2.0 the creation of services.rdb is part of the packaging process (or rather the 'install' process that prepares the files for being packaged). All UNO componenents listed in the setup script are registered into services.rdb by invoking 'regcomp' for them. So the code that registers the BasicIDE service is part of the implementing component itself (i.e. the basctl library). The registration is done by regcomp in module instsetoo_native [*] (2.0) or in module setup2 (1.1). [*] The (perl) code for this is in module solenv. HTH Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] compiler warnings: STLport; doubunder; OSL_VERIFY
Hi, Eike Rathke wrote: Hi Stephan, On Wed, Aug 31, 2005 at 10:04:47 +0200, Stephan Bergmann wrote: Sorry for the (may be stupid) question, but why not just change OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect that only weird code would relay on the evaluation in case of a zero debug level. And these case can probably easily be changed to something with assert (or ensure). No, the code I saw was of the form OSL_VERIFY(close(f) = 0); Well, to me that _is_ weird code. The programmer tried to save a variable and an assignment of the return value to the variable, but trades that in for not detecting an unsuccessfull close() in an OSL_DEBUG_LEVEL == 0 build, and not reacting on it. That's not only bad style, that's ugly, and maybe even wrong code. If the file that is being closed was written to, this is almost certainly a bug. If the file was opened read-only, then ignoring the result of close() is generally OK. In that case the programmer may have added this assertion to catch cases where the close fails due to an invalid file descriptor (e.g. a double close), which would indicate a logic error, or simply to document their (erroneous) assumption that close() can't fail after reading a file. So for a read-only file this might be acceptable, but as it is of very limited utility even in that case, the assertion should better be dropped. Leaving statements of debug macros in a product version most times leads to unnecessary code being executed, instead nasty uses such as above should be detected and eliminated and then OSL_VERIFY() set to empty for OSL_DEBUG_LEVEL == 0. As stated elsewhere: It is the one and only purpose of OSL_VERIFY to provide a construct that allows asserting on a expression that must be evaluated every time, including in the product version. All uses of that macro should contain expressions with a side effect. Your proposal is to make OSL_VERIFY identical to OSL_ASSERT (in which case it should be dropped completely). The nastyness in the above example is not that code with side effects is embedded in a debug macro (that is as intended). The nastiness is that an assertion is used in place of proper handling of runtime errors. But that is not specific to OSL_VERIFY. There are loads of places in the office where error return codes or caught exceptions are 'reported' by an OSL_ASSERT or OSL_ENSURE - and then ignored. BTW: In my experience the usual debug macros have the potential for much more serious errors, when code with side effects is used in an assertion. In that case they may cause necessary code to not be executed in product versions or they may change the entire flow of control, leading to hard to debug problems. Btw, since when would a close() return a value 0 ?!? Apparently this is inverting the common logic of checking if (close(f) 0) handle_error(); But I agree that it looks unusual and ==0 should be used to check success. Ciao, Jörg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OSL_VERIFY and other diagnostics
Hi Philipp, Philipp Lohmann - Sun Germany wrote: I definately think that OSL_VERIFY( callSomeFooWhichSignalsSuccess( bar ) ); is the better (non-weird) alternative here. That case is weird, because you choose to ignore the return value. In that you create a possibly not easy to find error. Ignoring return values is just bad code. Now there certainly are case in which the return value can be ignored safely, but then an OSL_VERIFY wouldn't be necessary either. If the return value can be ignored safely, that may be because you really don't care, or because you fulfilled the preconditions to get a well-known return value (e.g. success) every time. In this latter case it is good practice to document this for maintenance programmers by using an assertion. An assertion is better than a mere comment here, because it will tell you when the assumption fails at runtime (due to incorrect reasoning or maintenance changes). The concise notation to do that without cluttering the code with temporary variables for results you don't really use or extraneous control structures is OSL_VERIFY. Actually i think we should remove OSL_VERIFY for good. I disagree. Of course if there are cases like simple OSL_VERIFY(a==b), that indicates that developers need to be better educated about our debug macros and their meaning (and yes, consolidating the macro zoo should help here). Ciao, Jörg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] compiler warnings: STLport; doubunder; OSL_VERIFY
Stephan Bergmann wrote:
3 OSL_VERIFY
On unxsoli4 and unxsols4 PRODUCT builds, OSL_VERIFY(a == b) causes a
spurious warning The result of a comparison is unused (because the
argument of OSL_VERIFY is always executed, even for OSL_DEBUG_LEVEL ==
0). Instead of disabling the corresponding unxsoli4 and unxsols4
warning, I would vote to change code
OSL_VERIFY(e);
to
if (!e) {
OSL_ASSERT(false);
}
I disagree. Cluttering the code with extraneous control structures
and/or temporary variables for debug output makes the code less readable
and is easier to get wrong during maintenance.
I also hope that eventually, when our assertion macros are overhauled,
we make use of the capabilities of the preprocessor to include the
failed condition in the assertion output (like most implementations of C
assert() do). When we do that, using a meaningful condition in the
argument to the diagnostic macro instead of 'false' will produce more
meaningful diagnostic output. (For existing instances of
OSL_ASSERT(false), you won't get worse than the current null message
anyhow).
offtopic
BTW: IMHO if there are many instances of OSL_ASSERT(false), that
indicates to me that we need a OSL_ASSERT_ALWAYS() or OSL_ERROR().
/offtopic
(and thus work around the warning) on the ground that OSL_VERIFY is
dangerous and confusing---unlike the other OSL diagnose functions, it
*does* evaluate its argument for OSL_DEBUG_LEVEL == 0. In the interest
of the least surprise principle, we IMO should deprecate OSL_VERIFY
and replace all its occurrences as described above.
Why is it confusing, if a macro that has the very purpose of always
evaluating the expression it contains (and asserts about) does its job.
AFAIK that is the one differentiator to OSL_ASSERT/ENSURE.
If people use it for expressions without side effects that is an
education problem.
If there is a range of different diagnostic macros available I'd expect
them to have different semantics. And before using one of them a
developer should know what it does.
Ciao, Jörg
--
Joerg Barfurth Sun Microsystems - Desktop - Hamburg
using std::disclaimer
Software Engineer [EMAIL PROTECTED]
OpenOffice.org Configuration http://util.openoffice.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] compiler warnings: STLport; doubunder; OSL_VERIFY
Hi, Kay Ramme - Sun Germany - Hamburg wrote: Joerg Barfurth wrote: It is the very purpose of OSL_VERIFY to evaluate the expression regardless of debug level. For expressions without side effect OSL_ASSERT/OSL_ENSURE should be used instead. It is used to avoid cluttering the code with extraneous temporary variables and control structures for assertions about values that are not used otherwise. Return values signaling the success or failure of a function call are typically ideal candidates to be promoted further, up the call stack. I agree. If they signal runtime conditions that prevent normal operations, they can be converted to exceptions, otherwise they should be dealt with or propagated as approriate. (I think in most cases where errors are propagated repeatedly up the call stack an exception would be better, though). Assertions are not intended to be used for runtime conditions. They document and cast in executable code invariant assumptions or conditions that must hold every time the code is executed[*]. There are cases where it is valid to ignore the return value of a function - whether it is a success/failure code or some other data - because the expected value is known in advance and is (or should be) independent of runtime conditions. For example you don't have to check whether a 'sqrt' function fails, if you have made sure that the argument you pass is a positive number. Or you don't have to check that inserting something into a map succeeds, if you know that you have a unique key for the new entry. [*] There may be other uses for debugging macros, but for assertions that is the defined meaning. But the following reasoning also holds for other legitimate uses of assertion macros. Only in very very rare situations this has to be asserted. I don't think these situations are that rare. And they are definitely distinct from the cases where error propagation is in order. An assertion that triggers is always a bug. That is not true for an arbitrary runtime failure in some module. So, such an OSL_VERFIY, which only logs something in case of OSL_DEBUG_LEVEL 0, really _displaces_ error detection and handling!! OSL_VERIFY shouldn't log, but assert (i.e. check) a condition. It is true that our code has places where proper error handling is displaced by (abuse of) assertions. It is also true that this is Evil(TM). But I don't think this abuse should be used against the vaild uses of assertions. They are a powerful helper during development and maintenance. 'Always-on' assertions could also be used to diagnose bugs that occur on customer sites. OSL_VERIFY is just a convenience syntax for OSL_ASSERT and I don't agree that it is abused more often or more prone to abuse than OSL_ASSERT. So I don't see a reason to discard OSL_VERIFY, without also discarding OSL_ASSERT. Unless you think that all assertions should be replaced by fully propagated runtime checks, I see no argument to get rid of OSL_VERIFY. Ciao, Jörg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Can 2.0 use response files?
Hi, G. Roderick Singleton wrote: Please excuse the cross postiing. I am not certain which team can answer. Now my question. Since installing 1.1.x with response files is and was an option, the use of native installers with 2.0 appears to preclude this option/ Is it still available? If not then what option(s) is available to duplicate this functionality? General answer, see: http://installation.openoffice.org/servlets/ReadMsg?listName=devmsgNo=825 More detail about Windows/MSI: http://installation.openoffice.org/servlets/ReadMsg?listName=devmsgNo=829 HTH, Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] re: protocol handler is not being called
Hi James, James Black wrote: I have System.out.println statements at the beginning of the methods, and am running swriter.exe from within the windows command shell, but none of my print statements are showing up. Try printing to a file instead of System.out. If there still is no output, your code really isn't being called. Otherwise you may have run into the following snag: On windows, GUI applications don't have their standard output connected to the command shell, so afaict you won't see anything from System.out.println even if your code is executed. If you have access to a from-source build of openoffice.org, there is a remedy: The build produces a binary 'guistdio.com', which acts as a wrapper for gui application to connect their stdio to the console. To use it, copy it to officeinstall\program\soffice.com. If you now invoke officeinstall\program\soffice, the system will invoke soffice.com, which will in turn invoke soffice.exe with stdio connected to the command shell. (swriter is only a wrapper that invokes soffice) HTH, Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] remove .xcu files [using configimport?]
Aditya Pandey wrote: Hi I have been able to use configimport command for creating/installing a schema I have created for my addin to OpenOffice. You don't need configimport to install a schema (xcs) or xcu file. unopkg installs them in a private location. When I try to uninstall the addin, the .xcs (schema) file is removed by unopkg utility, but the data file (.xcu) file and cache file (.dat) files are still there. unopkg can remove only the installed files from the private location managed by unopkg. The files under $(userdata)/user/registry are created by the office when the configuration data you installed is accessed (cache/*.dat) or when configuration settings are modified by (or for) the user (*.xcu under data/). unopkg doesn't know about these files and if you install your package as shared package (using the --shared option to unopkg), then there could be an instance of them for every user - potentially an unlimited number. Because of this these files can't be uninstalled. But they should do no harm (other than consume disk space). You can't access the data through OOo configuration intrefaces. And when the package is installed again, the user will find their personal settings from last time. I tried configimport options to remove these files, but could not do it? Am I missing something? Configimport can't possibly do that. The only possibility would be writing a configcleanup program that removes xcu and dat files for which there is no corresponding schema.Then every user would have to run that program. But that program hasn't even been written yet. You can file an RFE, but it won't get a high priority atm. Ciao, Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Open Office Development
Hi, BTW: You should subscribe to mailing lists you post to. Many replies go only to the lists. Michael Kramer wrote: Hi - I could be interested in contributing to Open Office. Is there a way that I could see the code base first so that I can know what sort of an operation I am getting into? Couldn't find any links for downloading source code on the web site. You should find all the links you need starting from http://development.openoffice.org/ and http://contributing.openoffice.org/ You can get source via anonymous cvs or download source tarballs for various releases. You can even view source for each of our projects online in your browser. At http://www.go-ooo.org there also is a LXR browser to explore the codebase. Ciao, Jörg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Trimming down OpenOffice distribution
Hi, Zorb Live wrote: I'm using OpenOffice in a Java-based program on Linux via the API to convert .ppt files to raster images. It's working great, and is tremendously useful--hats off! Now that it's working, I'd like to somewhat reduce the size of the OpenOffice distribution that I'm shipping--for the above task, can I get rid of the dependency on X11, and also drop unneeded modules and files within OpenOffice? How would I go about doing this? You can't get rid of the dependency on X11. The OOo core code is still tied to the UI code very much, so you can't run one without the other. The recommended solution is to use a virtual X server, like Xvfb, and run OpenOffice.org with the -headless flag. Are you using OOo 1.x? In that case you can experiment with the 'custom installation' options to figure out a trimmed down configuration. You may try to install only the Impress application and deselect other packages you don't need. Unfortunately there is no simple way to create a reduced installer package you can ship. You either have to build OOo yourself and then do some hacking of 'scp'-Files (or setup description languge) or you can try to manually identify files to remove and otherwise manipulate the full installation set, which is a rather tedious task. In either case you could ask on the dev@installation.openoffice.org list for more help. Things get better in OOo 2.0: There the installer is split into several rpms and you can easily select those you need. You could try, if installing all the 'core' packages plus the impress package does the job for you. I didn't see anything relevant in the documentation on this, but I've been known to be blind in the past. Did you check if the installation project http://installation.openoffice.org has relevant documentation? Ciao, Joerg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] More than one interface inside a .idl file
Hi, Ary Junior wrote: Hi, im trying to registry two interfaces inside the same .idl file... This isn't relevant. What is relevant is that you have two implementation classes in your jar file. BTW: You should register services or implementations, not interfaces. these interfaces are implemented with Java to be used as add-in functions with Calc... My problem is with the manifest file inside the .jar... How can i define my two class (one for each interface)? If i define the manifest likes this: RegistrationClassName: root.mymodule.NewInterface RegistrationClassName: root.mymodule.MyInterface I don't know the details of Java-UNO registration, but afaik there can be only one 'RegistrationClass' in a jar. That class is called upon to register the services this jar implements. It can easily register more than one implementation and it need not be identical to any one of the implementation classes. Reusing the implementation class to also serve as registration class really makes sense only if it is the only service implementation in that jar. For the full story, see http://api.openoffice.org/docs/DevelopersGuide/Components/Components.htm#1+5+8+2+Multiple+Implementations+per+Component+File Only the methods of the last interface appear in the insert function wizard of Calc... Maybe you should submit a bug (that the system should throw an exception when it finds multiple RegistrationClass entries :-o ) Ciao, Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] error on head
Hi Ken, Ken Foskey wrote: Has anyone seen this error and have anything to fix it? ... languages ENUS ... ** ERROR: ERROR: Missing files in function: remove_Files_Without_Sourcedirectory ** [...] Fri Apr 29 09:18:55 2005 (00:03 min.) dmake: Error code 255, while making 'openoffice_ENUS' '---* tg_merge.mk *---' Looks like wrong configuration. What was your configure line? Are you accidentally using a configure from 1.1.x? Ciao, Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Restricting portions of config to admins only?
Hi Brian, Brian Raymond wrote: I wanted to see if anyone had any input on this. I've seen some good data on how to make a custom schema for configuration data for my component but no way to restrict access to it. There is no way to do this in the schema. I'm implementing some custom configuration properties for my component that should only be changed by administrators. At the file level this could be enforced if the configuration was managed as separate files outside of OOo but if I extend the standard configuration through the API and store my own settings I haven't seen anything on how I could restrict access. Does anyone know how I can restrict access within the API or if a file on disk could be isolated and protected at the file system level? You can restrict access to individual settings by providing a configuration data (.xcu) file and using the protection attributes (oor:finalized and oor:mandatory) in that file to mark individual settings or entire subtrees as protected from further (e.g. user) modification. If you deploy your component with its configuration data as a shared UNO package, this data is imported into the basic OOo installation structure and should generally end up in a file that is not user-writable. You can't currently manipulate the access control attributes via the API. Manipulating protected data via the administrative API should leave the protection in place. HTH, Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Re: Re: Failure for build of langpack
Hi, Shkumbin Saneja wrote: Done: cd scp2; rm -r $INPATH; build; deliver ; but, still the same (error) result. This should have rebuilt all of scp2 and (amongst others) delivered a setup_osl.ins file to the solver. You mean that gid_Dir_User_Autotext_Language one? Can you look into the setup_osl.ins file that was delivered from scp2 and show us the entry you have for gid_Dir_User_Autotext_Language (and if it has a line defining the HostName(sq)=...? ...If you built without your languge configured first, ... Do you mean for: ./configure --with-lang=sq ? or some other configuration for my language ? Yes. IIRC this error occured, if you first ./configure --with-lang=some language(s), but not sq (or simply ./configure without any --with-lang) and then later ./configure --with-lang=sq without cleaning (at least) the scp2 output directory. HTH, Joerg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Error in m73, building: moduldl2.obj
Please submit an issue (if there isn't one already). This is another instance of the longstanding gcc parser bug (which is only fixed in gcc 3.4). To fix this, change line 824 of source file basctl/source/basicide/moduldl2.cxx from ::rtl::OUString aTitle( ::rtl::OUString( IDEResId( RID_STR_BASIC ) ) ); to ::rtl::OUString aTitle = ::rtl::OUString( IDEResId( RID_STR_BASIC ) ); HTH, Joerg Shqip OOo wrote: In SRC680-m73, after ~10 hrs of build, have hit the following error: (Suse 9.1, gcc 3.3.3) _ Making: ../../unxlngi4.pro/slo/moduldl2.obj g++ -Wuninitialized -fmessage-length=0 -c -I. -I. -I../inc -I../../inc -I../../unx/inc -I../. ./unxlngi4.pro/inc -I. -I/usr/src/m73/solver/680/unxlngi4.pro/inc/stl -I/usr/src/m73/solver/68 0/unxlngi4.pro/inc/external -I/usr/src/m73/solver/680/unxlngi4.pro/inc -I/usr/src/m73/solenv/u nxlngi4/inc -I/usr/src/m73/solenv/inc -I/usr/src/m73/res -I/usr/src/m73/solver/680/unxlngi4.pr o/inc/stl -I/usr/src/m73/solenv/inc/Xp31 -I/usr/lib/java/include -I/usr/lib/java/include/linux -I/usr/lib/java/include/native_threads/include -I/usr/X11R6/include -I. -I../../res -I. - O1 -pipe -mcpu=pentiumpro -Wno-ctor-dtor-privacy -include preinclude.h -fexceptions -fno-enf orce-eh-specs -fpic -DLINUX -DUNX -DVCL -DGCC -DC300 -DINTEL -DGXX_INCLUDE_PATH=/usr/include /g++ -DCVER=C300 -D_USE_NAMESPACE -DGLIBC=2 -DX86 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_ NAMESPACE=1 -DSTLPORT_VERSION=400 -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DSUPD=680 -DPRODUCT -DNDEB UG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DEXCEPTIONS_ON -DCUI -DSOLAR_JAVA -DSRC680 -DSHAREDLIB -D_DLL_ -DMULTITHREAD -o ../../unxlngi4.pro/slo/moduldl2.o /usr/src/m73/basctl/ source/basicide/moduldl2.cxx /usr/src/m73/basctl/source/basicide/moduldl2.cxx: In member function `void LibPage::InsertLib( )': /usr/src/m73/basctl/source/basicide/moduldl2.cxx:824: error: variable declaration is not allow ed here /usr/src/m73/basctl/source/basicide/moduldl2.cxx:838: error: no matching function for call to `com::sun::star::ui::dialogs::XFilterManager::appendFilter(rtl::OUString ()(), rtl::OUString )' /usr/src/m73/solver/680/unxlngi4.pro/inc/com/sun/star/ui/dialogs/XFilterManager.hdl:38: error: candidates are: virtual void com::sun::star::ui::dialogs::XFilterManager::appendFilter(const rtl::OUString, const rtl::OUString) /usr/src/m73/solver/680/unxlngi4.pro/inc/svtools/sbxvar.hxx: At global scope: /usr/src/m73/solver/680/unxlngi4.pro/inc/svtools/sbxvar.hxx:476: warning: inline function `Sbx InfoRef SbxInfoRef::operator=(SbxInfo*)' used but never defined /usr/src/m73/solver/680/unxlngi4.pro/inc/svtools/sbxvar.hxx:471: warning: inline function `Sbx ArrayRef SbxArrayRef::operator=(SbxArray*)' used but never defined dmake: Error code 1, while making '../../unxlngi4.pro/slo/moduldl2.obj' '---* tg_merge.mk *---' dmake: Error code 255, while making 'do_it_exceptions' '---* tg_merge.mk *---' ERROR: Error 65280 occurred while making /usr/src/m73/basctl/source/basicide dmake: Error code 1, while making 'build_all' '---* tg_merge.mk *---' Regards. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
