Le 26 août 08 à 10:08, Eric Wasylishen a écrit : >> The compilation fails for me though, I got the following error: >> TLMusicFile.m: In function '-[TLMusicFile mp4ReadTagsForFile:]': >> TLMusicFile.m:70: error: too many arguments to function >> 'MP4GetMetadataCoverArt' >> TLMusicFile.m: In function '-[TLMusicFile cover]': >> TLMusicFile.m:185: error: too many arguments to function >> 'MP4GetMetadataCoverArt' >> >> May be you switched to a more recent version of the mp4 lib? Mine >> is >> <http://packages.ubuntu.com/search?suite=gutsy&searchon=names&keywords=libmp4 > > Hm.. I'm using Ubuntu 8.04 which has a newer version. That's annoying, > though. I'll have a look at the old version and see what should be > done.
ok, thanks. >> Not really related but I'd like to merge ETUTI implementation into >> EtoileFoundation, is this possible or not yet?… The last time I read >> ETUTI class, the code looked fine to me. iirc the only missing part >> was exposing ObjC type system as UTIs. > > It's fine with me. Great :) > As far as interacting with the ObjC type system, how about having a > method in ETUTI like +UTIWithObject: that generated a UTI by > concatenating the names of the superclass(es) and class of the object? > e.g., given an ETPlaylist instance it would produce: > org.etoile.NSObject.COObject.COGroup.ETPlaylist All classes are in the same namespace, so org.etoile.ETPlaylist would work. Superclasses and implemented protocols might also be changed at runtime with ObjC, so I think it's better not to harcode the class hierarchy in each UTI. Having a 'objc' component in these UTIs would also make clearer they belong to the ObjC type system. If we consider only two distinct namespaces exist in ObjC: protocols and classes, I would suggest something like that: org.etoile-project.objc.class.ETPlaylist org.etoile-project.objc.class.NSObject org.etoile-project.objc.protocol.NSObject > We could map these ObjC-UTI's to "system" UTIs, then something like: > - (BOOL) conformsTo: (ETUTI *)aUTI; > - (NSArray*) UTIs; > could be implemented as a category on NSObject. Sounds good. > If it's useful to specify UTI's per-ObjC-object rather than > per-ObjC-class, we could add an instance variable to COObject to store > the list of conforming ones, maybe. Eventually yes. Although I'm not really convinced we need this feature immediately or for COObject. Yet subtyping without subclassing could be interestingin some cases. For example, UTI could be used to specify roles attached to instances. It may also be interesting to change the type of a layout item when a late-bound aspect is attached to it. To put it shortly, the support of subtyping through delegation rather than only through subclassing. > Is that anything like what you had in mind? :) Mostly yes :-) EtoileUI and CoreObject are the two frameworks which are going to use UTIs I think. In CoreObject, the supercasting mechanism would mainly take care of: - mapping core object types to normal file types, in a way that allows to export core objects and import normal files (for example SVG data can be imported/exported as raw text, xml or vector image) - providing fine-grained editor and viewer roles for object and data types (for example SVG data can be edited as raw text, xml or vector image) iirc that's roughly what we had in mind. David, may be you want to comment on that? Our past discussions on the topic can probably be found in etoile-dev and silc archives. For EtoileUI, UTIs will be useful for the pick and drop: - specifying which object and data types are valid for copy/paste and drag/drop - passing objects currently on the pickboard to the pasteboard, by converting them into the appropriate pasteboard data format (and the reverse exposing pasteboard datas as pickboard objects)… this is tighly related to CoreObject supercasting in fact. For enabling and disabling pick and drop with certain object and data types, my plan is to extend EtoileUI API with methods such as - setPickingAllowedForUTIs: (NSArray *)utis and - setDroppingAllowedForUTIs: (NSArray *)utis. Here are two brief examples to give you a better idea of how that would work: - disabling the drag would be a matter of calling - setPickingAllowedForUTIs: with an empty array - enabling the drop of folders, playlist objects, music objects or files, would be achieved with -setDroppingAllowedForUTIs: (public.audio, objc.ETPlaylist, public.folder). This would mean: accept all object/data whose types matches the declared UTIs or any of their descendent UTIs (the subtypes that conform to public.audio, objc.ETPlaylist, public.folder). Because ETMusicFile would conform to 'public.audio', it would be implicitly accepted by the previous declaration. Dropping an COGroup instance would be rejected by being neither declared in the UTI array as 'org.etoile.objc.class.COGroup' or indirectly by another UTI whose COGroup is a subtype of. In this example, I made the assumption COGroups isn't a subtype of public.folder. What needs to be progressively worked out is the right mapping between the generic UTIs and the ObjC UTIs. To take the previous case as an example, 'public.folder '(or rather 'public.directory') should be a subtype of 'objc.protocol.COGroup', and 'objc.protocol.COGroup' could be mapped/aliased to 'org.etoile.group' which would be a subtype of 'public.item'. I don't think we can take the right to declare 'public.group' even if that would be nicer. To limit the complexity of the mapping as much as possible, I would suggest that creating new generic UTIs such as org.etoile.group should be reserved to ObjC types that appear as user tangible objects on screen. For example, a group is a collection of objects, but unlike a usual Foundation collection, it plays a meaningful role for the user when interacting with the UI. Hence, I doubt it's necessary to declare an UTI 'org.etoile.collection', make it a supertype of 'org.etoile.group', and finally map NSArray, NSDictionary, NSSet to it. If the protocol ETCollection appears as an UTI, it's probably enough I think. The last important point is that -conformsToUTI: would be used to handle the mapping of various generic UTIs to ObjC UTIs. Having this mapping stored in a property list, read by NSObject code, should do the trick. Some classes such as NSImage will probably need some custom code, since their UTIs will change at runtime depending on the image data (TIFF, PNG etc.) they embed. That's more or less what I have in mind. What do you think? Cheers, Quentin. _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
