[sip-comm-dev] UIService


#1

Hi Emil,

I've started working on the UIService. Initially it will provide some methods allowing to add plugin components in the UI. But even for such an apparently simple task some questions arose.

A brief introduction to the current implementation:
We have plugin components - like buttons, menu items, etc., let's call them plugins for short. They could be added at any place (container) of the UI that could host a plugin. Each "place" is identified by a String - a Constraint.
    - The available constraints could be obtained via getSupportedConstraints().
    - A new plugin could be added via addComponent(Object component, String conctraint).
All plugins are stored and no events are fired upon plugin addition. Each time a container is initialized, it takes all plugins added with its constraint and shows them.

In the current GUI implementation we could differentiate two types of containers that can accept plugins:
    - ones that are placed in the main program window
    - ones that are placed in other windows (chat window, ...).
We make this difference because:
    - the chat window is initialized when a user clicks on a contact. At this time it'll obtain and show all plugins that were registered for its constraint.
    - the main program window is initialized when the UIService is started. Thus it should be somehow notified and refreshed when a plugin is added.
This poses some problems. I could make a listener that would be added to all containers wanting to be notified when a plugin is added. When notified they could use revalidate() to refresh the interface. But I'm not so sure that this would work properly and what would be the case with other UI implementations (using frameworks other than swing).

Another idea is to have all plugins added before the initialization of the GUI. In order to achieve this we could split the ui bundle into two bundles:
    - a very simple bundle exporting UIPluginService, which would only provide getSupportedConstraints and addComponent (making it essentially a kind of "map"). It would be started before all other services (right after the ConfigurationService).
    - the bundle providing the actual GUI - which would be started last.
What do you think? Any other suggestions?

yana

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hello Yana,

Comments inline:

Yana Stamcheva wrote:

A brief introduction to the current implementation: We have plugin
components - like buttons, menu items, etc., let's call them plugins
for short. They could be added at any place (container) of the UI
that could host a plugin. Each "place" is identified by a String - a
Constraint. - The available constraints could be obtained via getSupportedConstraints().

Shouldn't that rather be sth like getSupportedForContainer() given that
constraints may change from one container to another?

- A new plugin could be added via addComponent(Object component, String conctraint).

Hmm, ok I now understant the getSuppConstraints method.

And how about having

getSupportedForContainer( ContainerID )
addComponent( ContainerID container, String constraint, Object component)

Where ContainerID is an interface (could be implemented by simply
wrapping a string) which must have been returned by the UI
implementation and directly corresponds to something like a toolbar, one
of the menus, the tabbed pane in the main window or that in the message
window.

The string constraint may remain and be used the same way as string
constraints in swing - non imposing indication of a preference as to
where the component should be added.

All plugins are stored and no events are fired upon plugin addition.
Each time a container is initialized, it takes all plugins added
with its constraint and shows them.

(As a side note, let's stick to "external components" as I tend to
associate plugin with a bundle and may get confused :slight_smile: )

In the current GUI implementation we could differentiate two types of
containers that can accept plugins: - ones that are placed in the
main program window - ones that are placed in other windows (chat
window, ...). We make this difference because: - the chat window is
initialized when a user clicks on a contact. At this time it'll
obtain and show all plugins that were registered for its constraint. - the main program window is initialized when the UIService is started. Thus it should be somehow notified and refreshed when a
plugin is added. This poses some problems. I could make a listener
that would be added to all containers wanting to be notified when a
plugin is added. When notified they could use revalidate() to refresh
the interface. But I'm not so sure that this would work properly and
what would be the case with other UI implementations (using
frameworks other than swing).

I don't think there would be a problem with the revalidation.

Another idea is to have all plugins added before the initialization
of the GUI. In order to achieve this we could split the ui bundle
into two bundles: - a very simple bundle exporting UIPluginService,
which would only provide getSupportedConstraints and addComponent
(making it essentially a kind of "map"). It would be started before
all other services (right after the ConfigurationService). - the
bundle providing the actual GUI - which would be started last. What
do you think? Any other suggestions?

Yes I like the idea but I don't see why you need to split the GUI
bundle in two in order to achieve it.

Otherwise I agree we'd need a map but only as a temporary buffer. It
would only store components for containers that are not yet initialized.
Whenever a container comes to life it would consult this map and
retrieve a list of pending components. Once the container in question is
created then newly registered components could be added straight into it.

Does that make sense ?

Cheers
Emil


#3

Hi Emil,

Sorry for the delay. Hope you haven't forgotten our discussion:)

Hello Yana,

Comments inline:

Yana Stamcheva wrote:

A brief introduction to the current implementation: We have plugin
components - like buttons, menu items, etc., let's call them plugins
for short. They could be added at any place (container) of the UI
that could host a plugin. Each "place" is identified by a String - a
Constraint. - The available constraints could be obtained via getSupportedConstraints().

Shouldn't that rather be sth like getSupportedForContainer() given that
constraints may change from one container to another?

I tried to define the methods in the UIService according to the existing methods and comments there. There the Constraint was meant to be a string directly pointing to a Container. Thus getSupportedConstraints was meant to return a set of string constants corresponding to containers supported by the current ui implementation. When adding an external component to a container no position was specified (TOP, BOTTOM, etc).

- A new plugin could be added via addComponent(Object component, String conctraint).

Hmm, ok I now understant the getSuppConstraints method.

And how about having

getSupportedForContainer( ContainerID )
addComponent( ContainerID container, String constraint, Object component)

Where ContainerID is an interface (could be implemented by simply
wrapping a string) which must have been returned by the UI
implementation and directly corresponds to something like a toolbar, one
of the menus, the tabbed pane in the main window or that in the message
window.

The string constraint may remain and be used the same way as string
constraints in swing - non imposing indication of a preference as to
where the component should be added.

I agree for the ContainerID. But I'm not sure the string constraint indicating exact position in the container would be very usefull. In most cases the external components will be added in menus, toolbars, etc. - containers that add their components in a consecutive way. If you agree we could keep the addComponent you specified and add a second one - addComponent(ContainerID containerID, Object component).

All plugins are stored and no events are fired upon plugin addition.
Each time a container is initialized, it takes all plugins added
with its constraint and shows them.

(As a side note, let's stick to "external components" as I tend to
associate plugin with a bundle and may get confused :slight_smile: )

In the current GUI implementation we could differentiate two types of
containers that can accept plugins: - ones that are placed in the
main program window - ones that are placed in other windows (chat
window, ...). We make this difference because: - the chat window is
initialized when a user clicks on a contact. At this time it'll
obtain and show all plugins that were registered for its constraint. - the main program window is initialized when the UIService is started. Thus it should be somehow notified and refreshed when a
plugin is added. This poses some problems. I could make a listener
that would be added to all containers wanting to be notified when a
plugin is added. When notified they could use revalidate() to refresh
the interface. But I'm not so sure that this would work properly and
what would be the case with other UI implementations (using
frameworks other than swing).

I don't think there would be a problem with the revalidation.

Another idea is to have all plugins added before the initialization
of the GUI. In order to achieve this we could split the ui bundle
into two bundles: - a very simple bundle exporting UIPluginService,
which would only provide getSupportedConstraints and addComponent
(making it essentially a kind of "map"). It would be started before
all other services (right after the ConfigurationService). - the
bundle providing the actual GUI - which would be started last. What
do you think? Any other suggestions?

Yes I like the idea but I don't see why you need to split the GUI
bundle in two in order to achieve it.

Otherwise I agree we'd need a map but only as a temporary buffer. It
would only store components for containers that are not yet initialized.
Whenever a container comes to life it would consult this map and
retrieve a list of pending components. Once the container in question is
created then newly registered components could be added straight into it.

Does that make sense ?

What you described here is exactly what I've done til now. The only question for me was whether the revalidation is a good solution. But if you say so :slight_smile:

Cheers
Emil

Yana

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Yana,

Yana Stamcheva wrote:

I tried to define the methods in the UIService according to the existing methods and comments there. There the Constraint was meant to be a string directly pointing to a Container. Thus getSupportedConstraints was meant to return a set of string constants
corresponding to containers supported by the current ui implementation. When adding an external component to a container no position was specified (TOP, BOTTOM, etc).

Oh .. you could completely ignore methods that are currently there. They
were just a first attempt to define a UIService which was never really
been thought upon.

I agree for the ContainerID. But I'm not sure the string constraint indicating exact position in the container would be very usefull. In
most cases the external components will be added in menus, toolbars,
etc. - containers that add their components in a consecutive way.

Yes exactly, and a developer should be able to specify whether the
button she adds to a tool bar or menu is to be placed in the beginning
or at the end. Right now the message window toolbar has several
different sections. Certain plugins might want to register components in
a specific section rather than just add them to the end. The same goes
for menus.

I believe that adding constraints is the simpliest level for achieving
this kind of flexibility.

WDYT?

Cheers
Emil

···

Yana

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net For additional commands, e-mail: dev-help@sip-communicator.dev.java.net