Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5
On 28/03/12 12:26, Tor Lillqvist wrote: MARKER: These services are not intended to be instantiated via their service names. How is it in general with service names, if one browses services.rdb (either of them), one doesn't have to look long to notice components that have identical service names (but different implementation names). What does this mean? That they are not supposed to be instantiated via service names but via implementation names? Sorry if this is a very fundamental question, but I guess I never fully have understood UNO... indeed i've also noticed that; in many cases there are actually multiple implementations for a given service. sometimes, these are for generic things like e.g. enumerations that are only available via some getter or property from another service, and in that case an implementation name may or may not exist; but in other cases, the service is actually instantiated via a factory, and the implementation name is necessary; the first example that comes to mind is the import/export filter service, which is implemented once per application per file format, and of course you want to be using the specific one for the format the user selected. Hmm, I now see that the first such duplicated service name I come across just visually browsing is css.frame.ContentHandler, which you indeed mark with MARKER in your message. (And there's unfortunately lots of these, needlessly obscuring things in many ways.) Indeed. Is there any point at all in cluttering services.rdb (and other configuration files?) with these components if they aren't looked for from there at run-time anyway? hmm... good question... perhaps they are necessary for runtime introspection, i.e. services implement a getSupportedServiceNames method that returns these and then some introspection thing can look up metadata from the RDB, like what interfaces and properties may be available. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5
On 28/03/12 12:11, Stephan Bergmann wrote: * CTORS accessible.AccessBridge: This service being of interface type XInitialization looks strange. (XInitialization is more of an internal interface, so that instances of such a service can obtain arguments when being constructed. Explicit constructors of new-style services internally call it.) i wonder, this XInitialization always seemed to be like some backward compatibility kludge, would it be possible to get rid of this for LO4 and pass the arguments to the C++ ctor of the implementing class directly or at least a static factory method or something like that, or is there some reason why that wouldn't work? * MODULE: These services are not intended to be instantiated at the global component context/service manager, but rather via document-specific factories. (Some that I labelled MODULE might actually be MARKER -- I did not look too close.) but it would actually be possible use a hypothetical document-specific component context to construct these. which currently does not exist for any application, so maybe it doesn't make sense to expose such constructors just yet :) ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5
On Mon, 2012-04-02 at 16:15 +0200, Michael Stahl wrote: would it be possible to get rid of this for LO4 and pass the arguments to the C++ ctor of the implementing class I guess one potential gotcha is that you can't call virtual methods on your in-construction object in a C++ ctor while ::initialize happens after construction so it can. C. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5
On 04/02/2012 04:15 PM, Michael Stahl wrote: i wonder, this XInitialization always seemed to be like some backward compatibility kludge, would it be possible to get rid of this for LO4 and pass the arguments to the C++ ctor of the implementing class directly or at least a static factory method or something like that, or is there some reason why that wouldn't work? Simplifying the way UNO service instances are created (there should be better ways than the current nested multi/single service factories, IMO), there should be no reason that XInitialization is still needed for it. (Virtual methods is a red herring here, btw.) Also, that would finally make it possible to have different constructors for a UNO service with similar parameter lists. Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5
On 03/28/2012 12:26 PM, Tor Lillqvist wrote: MARKER: These services are not intended to be instantiated via their service names. How is it in general with service names, if one browses services.rdb (either of them), one doesn't have to look long to notice components that have identical service names (but different implementation names). What does this mean? That they are not supposed to be instantiated via service names but via implementation names? Sorry if this is a very fundamental question, but I guess I never fully have understood UNO... Slide 8 (Services of the Past) of http://www.openoffice.org/marketing/ooocon2004/presentations/friday/shinyhappyuno.pdf tried to explain that. (And there's unfortunately lots of these, needlessly obscuring things in many ways.) Indeed. Is there any point at all in cluttering services.rdb (and other configuration files?) with these components if they aren't looked for from there at run-time anyway? At least theoretically, applications could read that information at runtime. (And it is really only .rdb files where this information is preserved at runtime. For example, neither cppumaker nor javamaker generate output for old-style services.) Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5
On 03/27/2012 11:03 AM, Noel Grandin wrote:
OK, so I went ahead anyway, at the risk of having to redo stuff :-)
This is the next 4 commits.
It updates the IDL files in the OFFAPI module.
Looking at those 112 converted services, I'm afraid most of them should
not be converted after all. :( I classified the according to the below
list.
* 30 look good. :)
* CTORS accessible.AccessBridge: This service being of interface type
XInitialization looks strange. (XInitialization is more of an internal
interface, so that instances of such a service can obtain arguments when
being constructed. Explicit constructors of new-style services
internally call it.) Looking at the usage of that service
(vcl/source/app/svdata.cxx, vcl/source/app/svmain.cxx), it looks more
sensible change this UNO service to
service AccessBridge: XComponent {
create([in] XExtendedToolkit toolkit);
};
(and change the type of mxAccessBridge accordingly).
* MARKER: These services are not intended to be instantiated via their
service names. Rather, they describe characteristics of certain UNO
objects. (And there's unfortunately lots of these, needlessly obscuring
things in many ways.)
* MODULE: These services are not intended to be instantiated at the
global component context/service manager, but rather via
document-specific factories. (Some that I labelled MODULE might
actually be MARKER -- I did not look too close.)
* SINGLE util.OfficeInstallationDirectories: While there is a
(superfluous) service definition for this, there is also a singleton
definition (in the same file) that appears to be used exclusively by
client code. I would keep the service old-style, mark it as deprecated
(pointing to the singleton for actual use), move the singleton into an
.idl file of its own, and convert the singleton to new-style.
* UNUSED: These services look completely unused. Would probably be
better to mark them as @deprecated.
Noel, can you adapt your patches?
Thanks again for your patience and good work,
Stephan
awt.MenuBar
awt.PopupMenu
awt.TabController
document.OleEmbeddedServerRegistration
embed.FileSystemStorageFactory
embed.StorageFactory
frame.DispatchHelper
frame.DispatchRecorderSupplier
frame.DocumentTemplates
frame.MediaTypeDetectionHelper
graphic.GraphicProvider
mozilla.MozillaBootstrap
plugin.PluginManager
scanner.ScannerManager
sheet.RecentFunctions
task.JobExecutor
text.DefaultNumberingProvider
ucb.AnyCompareFactory
ucb.CachedContentResultSetFactory
ucb.CachedContentResultSetStubFactory
ucb.CachedDynamicResultSetFactory
ucb.CachedDynamicResultSetStubFactory
ucb.ContentProviderProxyFactory
ucb.PropertiesManager
ucb.SimpleFileAccess
ucb.SortedDynamicResultSetFactory
ucb.Store
util.PathSubstitution
util.TextSearch
util.URLTransformer
CTORS accessibility.AccessBridge
MARKER accessibility.Accessible
UNUSED auth.SSOManagerFactory
UNUSED auth.SSOPasswordCache
MARKER chart.ChartData
UNUSED configuration.backend.HierarchyBrowser
UNUSED configuration.bootstrap.BootstrapContext
MARKER document.Events
MARKER document.ExtendedTypeDetection
UNUSED document.FilterAdapter
MARKER document.LinkTargets
MODULE drawing.BitmapTable
MODULE drawing.DashTable
MODULE drawing.GradientTable
MODULE drawing.HatchTable
MODULE drawing.MarkerTable
MODULE drawing.MasterPages
MODULE drawing.Shapes
MODULE drawing.TransparencyGradientTable
MARKER frame.Components
MARKER frame.ContentHandler
MARKER frame.FramesContainer
MARKER i18n.TextConversion
MARKER mozilla.MenuProxy
MARKER mozilla.MenuProxyListener
MARKER packages.PackageFolderEnumeration
MARKER sdbc.Driver
MODULE sheet.CellAnnotationsEnumeration
MODULE sheet.CellAreaLinksEnumeration
MODULE sheet.CellFormatRangesEnumeration
MODULE sheet.Cells
MODULE sheet.CellsEnumeration
MODULE sheet.ConsolidationDescriptor
MODULE sheet.DatabaseRangesEnumeration
MODULE sheet.DataPilotFieldGroupItem
MODULE sheet.DataPilotFieldsEnumeration
MODULE sheet.DataPilotSourceDimensions
MODULE sheet.DataPilotSourceHierarchies
MODULE sheet.DataPilotSourceLevels
MODULE sheet.DataPilotSourceMembers
MODULE sheet.DataPilotTablesEnumeration
MODULE sheet.DDELinksEnumeration
MODULE sheet.FunctionDescriptionEnumeration
MODULE sheet.HeaderFooterContent
MODULE sheet.LabelRangesEnumeration
MODULE sheet.LabelRange
MODULE sheet.NamedRangesEnumeration
MODULE sheet.ScenariosEnumeration
MODULE sheet.SheetCellRangesEnumeration
MODULE sheet.SheetLinksEnumeration
MODULE sheet.SpreadsheetsEnumeration
MODULE sheet.SpreadsheetViewPanesEnumeration
MODULE sheet.SubTotalFieldsEnumeration
MODULE sheet.SubTotalField
MODULE sheet.TableAutoFormatEnumeration
MODULE sheet.TableAutoFormatsEnumeration
MODULE
Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5
MARKER: These services are not intended to be instantiated via their service names. How is it in general with service names, if one browses services.rdb (either of them), one doesn't have to look long to notice components that have identical service names (but different implementation names). What does this mean? That they are not supposed to be instantiated via service names but via implementation names? Sorry if this is a very fundamental question, but I guess I never fully have understood UNO... Hmm, I now see that the first such duplicated service name I come across just visually browsing is css.frame.ContentHandler, which you indeed mark with MARKER in your message. (And there's unfortunately lots of these, needlessly obscuring things in many ways.) Indeed. Is there any point at all in cluttering services.rdb (and other configuration files?) with these components if they aren't looked for from there at run-time anyway? --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [PATCH] EasyHack, fdo#46808, Adapt UNO services to new style, Parts 2 through 5
Cool, I'll spin a new patch in a couple of days.
On 2012-03-28 12:11, Stephan Bergmann wrote:
On 03/27/2012 11:03 AM, Noel Grandin wrote:
OK, so I went ahead anyway, at the risk of having to redo stuff :-)
This is the next 4 commits.
It updates the IDL files in the OFFAPI module.
Looking at those 112 converted services, I'm afraid most of them
should not be converted after all. :( I classified the according to
the below list.
* 30 look good. :)
* CTORS accessible.AccessBridge: This service being of interface type
XInitialization looks strange. (XInitialization is more of an
internal interface, so that instances of such a service can obtain
arguments when being constructed. Explicit constructors of new-style
services internally call it.) Looking at the usage of that service
(vcl/source/app/svdata.cxx, vcl/source/app/svmain.cxx), it looks more
sensible change this UNO service to
service AccessBridge: XComponent {
create([in] XExtendedToolkit toolkit);
};
(and change the type of mxAccessBridge accordingly).
* MARKER: These services are not intended to be instantiated via
their service names. Rather, they describe characteristics of certain
UNO objects. (And there's unfortunately lots of these, needlessly
obscuring things in many ways.)
* MODULE: These services are not intended to be instantiated at the
global component context/service manager, but rather via
document-specific factories. (Some that I labelled MODULE might
actually be MARKER -- I did not look too close.)
* SINGLE util.OfficeInstallationDirectories: While there is a
(superfluous) service definition for this, there is also a singleton
definition (in the same file) that appears to be used exclusively by
client code. I would keep the service old-style, mark it as
deprecated (pointing to the singleton for actual use), move the
singleton into an .idl file of its own, and convert the singleton to
new-style.
* UNUSED: These services look completely unused. Would probably be
better to mark them as @deprecated.
Noel, can you adapt your patches?
Thanks again for your patience and good work,
Stephan
awt.MenuBar
awt.PopupMenu
awt.TabController
document.OleEmbeddedServerRegistration
embed.FileSystemStorageFactory
embed.StorageFactory
frame.DispatchHelper
frame.DispatchRecorderSupplier
frame.DocumentTemplates
frame.MediaTypeDetectionHelper
graphic.GraphicProvider
mozilla.MozillaBootstrap
plugin.PluginManager
scanner.ScannerManager
sheet.RecentFunctions
task.JobExecutor
text.DefaultNumberingProvider
ucb.AnyCompareFactory
ucb.CachedContentResultSetFactory
ucb.CachedContentResultSetStubFactory
ucb.CachedDynamicResultSetFactory
ucb.CachedDynamicResultSetStubFactory
ucb.ContentProviderProxyFactory
ucb.PropertiesManager
ucb.SimpleFileAccess
ucb.SortedDynamicResultSetFactory
ucb.Store
util.PathSubstitution
util.TextSearch
util.URLTransformer
CTORS accessibility.AccessBridge
MARKER accessibility.Accessible
UNUSED auth.SSOManagerFactory
UNUSED auth.SSOPasswordCache
MARKER chart.ChartData
UNUSED configuration.backend.HierarchyBrowser
UNUSED configuration.bootstrap.BootstrapContext
MARKER document.Events
MARKER document.ExtendedTypeDetection
UNUSED document.FilterAdapter
MARKER document.LinkTargets
MODULE drawing.BitmapTable
MODULE drawing.DashTable
MODULE drawing.GradientTable
MODULE drawing.HatchTable
MODULE drawing.MarkerTable
MODULE drawing.MasterPages
MODULE drawing.Shapes
MODULE drawing.TransparencyGradientTable
MARKER frame.Components
MARKER frame.ContentHandler
MARKER frame.FramesContainer
MARKER i18n.TextConversion
MARKER mozilla.MenuProxy
MARKER mozilla.MenuProxyListener
MARKER packages.PackageFolderEnumeration
MARKER sdbc.Driver
MODULE sheet.CellAnnotationsEnumeration
MODULE sheet.CellAreaLinksEnumeration
MODULE sheet.CellFormatRangesEnumeration
MODULE sheet.Cells
MODULE sheet.CellsEnumeration
MODULE sheet.ConsolidationDescriptor
MODULE sheet.DatabaseRangesEnumeration
MODULE sheet.DataPilotFieldGroupItem
MODULE sheet.DataPilotFieldsEnumeration
MODULE sheet.DataPilotSourceDimensions
MODULE sheet.DataPilotSourceHierarchies
MODULE sheet.DataPilotSourceLevels
MODULE sheet.DataPilotSourceMembers
MODULE sheet.DataPilotTablesEnumeration
MODULE sheet.DDELinksEnumeration
MODULE sheet.FunctionDescriptionEnumeration
MODULE sheet.HeaderFooterContent
MODULE sheet.LabelRangesEnumeration
MODULE sheet.LabelRange
MODULE sheet.NamedRangesEnumeration
MODULE sheet.ScenariosEnumeration
MODULE sheet.SheetCellRangesEnumeration
MODULE sheet.SheetLinksEnumeration
MODULE sheet.SpreadsheetsEnumeration
MODULE sheet.SpreadsheetViewPanesEnumeration
MODULE sheet.SubTotalFieldsEnumeration
MODULE sheet.SubTotalField
MODULE
