The first UML diagramms
Alex Gabriel
http://polynox.info/mayanna.jpeg
http://polynox.info/mayanna.dia
Seif Lotfy
1) ItemSet contains several Items
however what does pluginset contain? plugins?
2) ItemSet, Item, Mayanna, PluginManager are somehow the base
classes !!! can we back them in one package.
3) What is the difference between the pluginmanager and service system ?
4) what is the "in german schnittstelle" between the gui and mayanna
thats all for now
other than that
gr8 work
looking forward to start implementing on the weekend
cheers
Seif
Correct me if i am wrong. The main classes would be.
Alex Gabriel
ad1: Sure it does. *Set are custom wrappers around the list object
giving us the option to define extra functionality.
ad2: I started converting the UML to a directory+file structure that
will give things some order. As to the dia feel free to do so.
ad3: a plugin is a wrapper around a python module. In other words it's
a set of things you can add to mayanna by loading the plugin. A
service is such a thing. It is a part of a plugin and offers a service
to mayanna. Like facebook integration or a view or whatever comes to
your mind.
ad4: interface? as of now there is no gui and therefore no interface
as well. the thing you see is a part of a first idea. Your (and
everybody else's) input is requested here.
Seif Lotfy
didn't understand the comment about the SettingsSystem
However here are some further ideas......
Back when we were playing in the in the gimmie-dev sandbox
Alex Gabriel implemented the categories option.
It might sound normal but i found the way he did it was very cool.
Usually one has a hierarchy of categories and each category knows what
data providers feed it with data as in items.
Thus categories are usually set manually and are fed with data.
Alex somehow turned the whole thing around (I was impressed maybe others
know this scheme but i didn't)
so while data providers generate their ItemSources, the ItemSources in
our new case ItemSets can actually list categories they want to belong
to. If a category isn't already created it gets created and is filled up
with the items.
so searching through items somehow seem very simple. instead looking for
a category. why not ask all the ItemSets or items what categories they
belong to. I think its a good way of creating MetaData.
I will try to explain my idea when i somehow get over the excitement.
Cheers
Seif
Seif Lotfy
@Alex: what about helper classes, e.g: iconfactory or item manager ( if some items are duplicated etc )
cheers
Seif
Seif Lotfy
@Alex what about service sets
example a set of google services...
do we consider it one plugin with several itemsets
or a pluginset
or a service set
cheers
Seif
p.s:
send me the code
On Tue, 2008-05-27 at 14:14 -0700, Alex Gabriel wrote:
Alex Gabriel
I told you about the settingsystem via jabber. you have an interface
to mayanna where modules can save and load whatever they want using a
source identifier, a name (for the setting) and the value itself. On
the other side you have a slot for a backend, the backend does the
actual saving. Backends present a general interface to the
settingsystem and perform the saving and loading from the various
destinations (files, gconf, databases, webservices, ...)
The itemsource, itemcategory thingy is somehow different now and the
active parts in it are services. You have datasource services and
datasink services. The datasink services can be though of as the
former ItemCategories, datasource services provide ItemSets and
signals, datasink services can listen to the signals and access the
ItemSets. This will be arranged in the Servicesystem. A datasource or
datasink can list datasinks/datasources it is interested in and the
Servicesystem will make sure the connection get's established when
both are available. However, the user gets a gui to change these
connections and add other connections.
helperclasses: we will surely need an iconfactory, i'm not sure about
an itemmanager. What should that do and what would be the benefit?
a plugin is merely a container to deliver install and uninstall stuff.
A *set is at first only a means to group things together. A set of
google services would be a bunch of services, you could put them all
in one plugin or in seperate plugins. I'm not sure if it makes sense
to couple services to close together. there are about 3 cases i can
think of:
a) two services have no connection whatsoever -> obviously we don't
need them coupled
b) two services can work together in some way -> it may be possible
to switch one of the services so it could be encouraged to create a
general interface and don't lock others out
c) two services must work together specifically with each other ->
why not make one service out of them then?
what do you think about that?
Seif Lotfy
their data to, or does the datasink choose which dataservices its
going to subscribe to ?
I think the three cases u listed are more or less dependable on this
question.
It would be cool if datasinks were generated dynamically....
thus if to services share the same datasink then they must have
somethign in common and should be somehow handled together....
cheers
Seif
Alex Gabriel
> do the datasource services determine which datasink they will push
> their data to, or does the datasink choose which dataservices its
> going to subscribe to ?
each datasink lists preferred datasources
each datasource lists preferred datasinks
when you install a new service, the servicesystem will look at it's
preferred services and hook it up with all that are available. then it
will look at each loaded service and if the new service appears in one
of their preferred services lists it will get connected as well. the
new connections can then be marked in some connection showing gui and
the user can connect or disconnect whatever he wants.
> I think the three cases u listed are more or less dependable on this
> question.
> It would be cool if datasinks were generated dynamically....
> thus if to services share the same datasink then they must have
> somethign in common and should be somehow handled together....
if to datasources share the same (and different) datasinks, their
items (and signals about changes) will get to this datasink. i think
each itemclass should define its own methods to manipulate the item.
the itemsink will just provide a popupmenu (or not even that if you
only want to display stuff) and trigger the default manipulating
method on doubleclick....
we'll have to think about this some more i guess..