Items
How Items will be handled on the Do side of things:
-------
Since all items will be IPC bus object, do core will need wrapper classes to proxy them into internal Do items that are easier to manage, provide caching, and save us calls over the bus when we don't need them.
Essentially these will look like
Do.Universe.
and in our IPC backends we will have something like
interface Ipcitem : IItem, which is what will actually get passed into the ItemProxy constructor.
Universe manager will have collections of ItemProxy, and these are what will be searched.
==== I'm rethinking this. I'm not sure how this will be done yet. Comments and suggestions welcomed. ====
In the past we've had a the concept of ItemSources, and we're going to modify them a little bit.
It will simply be the thing that fires ItemsAdded, ItemsRemoved, and has ChildrenOfItem. ItemSources should also be Items, so they will have name, desc, icon. A meta-item will be made from these, and it's ChildrenOf will be all other items.
====
i18n will be handled on the plugin side of things, the strings we get passed over ipc bus should be already translated.
Instead of an icon+name+desc hash for UID, ipc object name will be used. The expectation will be that items will maintain the same object path in different runnings of the plugin.
How Items will be handled on the plugin side of things:
-------
Plugins will have a single ItemSource object, as stated in the previous section. If a plugin would like to simulate multiple sources, the way to do this will be to have meta-items whose children are the items in that source.
Items must have the same object path across instances. Items must have the same object paths when running the plugin one day, shutting down, and starting back up. These paths will be used as the UID for the object, and used in calculating relevancy and so forth. This should enable us to do more with TextItem relevancy (I hope).
TODO: Figure out item types.
Solution 1: Dictionary of types:
ItemProxy would have an indexer on type, so to access the Text property of an ITextItem part of an item you would do
proxy [typeof (ITextItem)].Text
The same for any other implementations. Checking that the value is not null would essentially be checking if that proxy was of that type. This collection would be passed to an Actions "supports item" and a dict lookup would be done to see if it supports that item type. This should be relatively quick since it would be done with the Action's proxy and would if many cases never have to go over d-bus.
Blueprint information
- Status:
- Started
- Approver:
- Do Core Team
- Priority:
- Essential
- Drafter:
- Alex Launi
- Direction:
- Needs approval
- Assignee:
- Do Core Team
- Definition:
- Discussion
- Series goal:
- Accepted for rewrite
- Implementation:
-
Started
- Milestone target:
-
0.99.0
- Started by
- Alex Launi
- Completed by
Whiteboard
RAOF's class-based dbus items, explained.
Requiring each item to have an object on the bus seems like a lot of effort, and I don't think it's quite flexible enough for live-search plugins.
The idea is similar to how objects work in Python, where foo.method () is just syntactic sugar for foo_class.method (foo). In this scheme an Item is registered as a (UUID, class-path) tuple¹, where UUID is the globally unique item identifier², and class-path is the object path of the class methods.
A sample DBus interface would be an object with an interface something like
org.Do.Item:
string GetName (string UUID)
something GetIcon (string UUID)
string GetDescription (string UUID)
string[] GetSupportedInt
(uuid, class-object-path) GetChildren (string UUID)
1: A trivial round-trip optimisation is to send name, description, icon, etc when registering.
2: It's not obvious what the best way of generating UUIDs is, nor how to make it easy for plugins to do so.
( I think a possible solution to this is for plugins to have whatever scheme they like, and then core have a mapping from plugin uuid to core uuid which are globally unique. Core would have a Dict<string, string> of (core-uuid -> plugin-uuid) and when a plugin made a call into core with a uuid, core would translate it into the core-uuid. Most likely they would be prefixed as soon as the call came in with a caller identifier to make them unique. This would also allow core to do special things with special item types without plugins being aware. Example) Google.com bookmarks' relevance from both chrome and firefox could be increased when launched rather than just one or the other. ) -- Alex
