[sip-comm-dev] GUI Skin


#1

Hi,

I want to create my own skin for SIP Communcator as a plugin, so that it
will be easy to use. Are there any possibilities to do that? I found
only the tutorial about creating GUI plugins, such as dialogs etc. But I
want realy my own skin.

Thanks </preklad/anglicko-slovensky/?q=possibility>

Adam Netoc(n�


#2

Hello,

I am a senior programmer at the same corporation as Mr. Netocny, and I
in fact gave him the task to study SIP Communicator from the GUI
skin-ability point of view. We definitely want to make some contribution
there, which will be useful both for SIP Communicator project, and for us.

Is there anyone who would help Mr. Netocny getting oriented in the GUI
for that purpose?

Best regards

Marian Kechlibar

···

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


#3

Hey Adam,

На 21.07.10 14:17, Adam Netocny написа:

Hi,

I want to create my own skin for SIP Communcator as a plugin, so that it
will be easy to use. Are there any possibilities to do that? I found
only the tutorial about creating GUI plugins, such as dialogs etc. But I
want realy my own skin.

Unfortunately SIP Communicator does not support skinning at this time.
If you want to modify the way SIP Communicator looks, you would need to
delve in to the UI bundle and modify the existing Swing code.

Cheers,
Emil

···

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


#4

Hey Marian,

На 23.07.10 08:22, Marian Kechlibar написа:

Hello,

I am a senior programmer at the same corporation as Mr. Netocny, and I
in fact gave him the task to study SIP Communicator from the GUI
skin-ability point of view. We definitely want to make some contribution
there,

That's good to hear! Just so I understand better, are you saying you are
interested in making SIP Communicator skinnable? If yes then this would
really be a very welcome contribution, especially given the amount of
work it implies.

Cheers,
Emil

···

which will be useful both for SIP Communicator project, and for us.

Is there anyone who would help Mr. Netocny getting oriented in the GUI
for that purpose?

Best regards

Marian Kechlibar

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


#5

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable. I am not sure how easy is to do that, because I
am not a Java expert myself (well, sort of, in J2ME, but not in Swing),
that is why I asked Mr. Netocny to delve into it. He would definitely
appreciate any comments and suggestions from the actual author of the
current GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post them here in a few days.

Best regards

Marian

Emil Ivov napsal(a):

···

Hey Marian,

На 23.07.10 08:22, Marian Kechlibar написа:
  

Hello,

I am a senior programmer at the same corporation as Mr. Netocny, and I
in fact gave him the task to study SIP Communicator from the GUI
skin-ability point of view. We definitely want to make some contribution
there,
    
That's good to hear! Just so I understand better, are you saying you are
interested in making SIP Communicator skinnable? If yes then this would
really be a very welcome contribution, especially given the amount of
work it implies.

Cheers,
Emil

which will be useful both for SIP Communicator project, and for us.

Is there anyone who would help Mr. Netocny getting oriented in the GUI
for that purpose?

Best regards

Marian Kechlibar
    
---------------------------------------------------------------------
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


#6

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.

Great, looking forward to seeing them!

Emil

···

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


#7

Hi,
this is the first draft of design of the skinning functionality. I can
send RTF version if necessary. Please take a look at it and send your
comments.

Best regards

Adam Netočný
Fel ČVUT
Login: netocada

SIP Communicator Skin Support.pdf (135 KB)

···

On 07/25/2010 10:11 AM, Emil Ivov wrote:

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:
  

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.
    

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.
    

Great, looking forward to seeing them!

Emil

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


#8

Hi Adam,

I've had a look at your document and what you're proposing seems very good plan to me! In order to completely understand the idea, I have a few questions and thoughts though.

- Could you please explain in details this part (2.1. net.java.sip.communicator.impl.gui):

The idea
is to split design and functional code to three packages. The implementation code
package(net.java.sip.communicator.util.swing) common to all classes, the design
package(net.java.sip.communicator.impl.skin) and the implementation package.

- I'm not sure to understand, when you say that "all classes(not only inside net.java.sip.communicator.impl.gui) with swing components must be changed to be using the new set" (2.1. net.java.sip.communicator.impl.gui). I'm may be missing something, but If the actual gui already uses the util.swing package components, then if we make the util.swing package components support skins, the gui should automatically support skins, without any changes, no? I mean, for example when you talk about SIPCommSkinFrame, couldn't we make the SIPCommFrame extend the SIPCommSkinFrame, instead of vice versa ?

- When you talk about the package "net.java.sip.communicator.impl.skin.swing", you don't mention what would be the "net.java.sip.communicator.service.skin.swing". If we don't need the service package, we should may be think more of a plugin package, which would load a skin into the util.swing components, as you proposed. WDYT?

- Couldn't we use the current ResourceManagementService instead of the ImageFactory in "net.java.sip.communicator.impl.skin.swing.resources" ?

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).

I think that's all for now. Excuse me if I'm missing something.

Best regards,
Yana

···

On Jul 27, 2010, at 1:05 PM, Adam Netocny wrote:

Hi,
this is the first draft of design of the skinning functionality. I can
send RTF version if necessary. Please take a look at it and send your
comments.

Best regards

Adam Netočný
Fel ČVUT
Login: netocada

On 07/25/2010 10:11 AM, Emil Ivov wrote:

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.

Great, looking forward to seeing them!

Emil

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

<SIP Communicator Skin Support.pdf>---------------------------------------------------------------------
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


#9

Does it mean that the current "blue theme" will be turned into a skin
and the "no skin" mode will allow me to run with its Swing look
without the "blue theme"? I'd personally like to be able to not run
the "blue theme" on my Ubuntu and to have the native Gnome look (as
much as Swing supports it).

···

On Fri, Jul 30, 2010 at 1:26 PM, Yana Stamcheva <yana@sip-communicator.org> wrote:

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).

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


#10

Hi Yana,

Hi Adam,

I've had a look at your document and what you're proposing seems very good plan to me! In order to completely understand the idea, I have a few questions and thoughts though.

- Could you please explain in details this part (2.1. net.java.sip.communicator.impl.gui):

The idea
is to split design and functional code to three packages. The implementation code
package(net.java.sip.communicator.util.swing) common to all classes, the design
package(net.java.sip.communicator.impl.skin) and the implementation package.
    

This was meant very simply. In the util.swing package there should
remain all the functional code such as, size loading or observer
patterns implementation. The design implementation should be located in
the impl.skin.swing package which will extend classes from util swing
package. The component specific code should be then located in existent
gui classes. This classes will then extend the skin.swing package.

- I'm not sure to understand, when you say that "all classes(not only inside net.java.sip.communicator.impl.gui) with swing components must be changed to be using the new set" (2.1. net.java.sip.communicator.impl.gui). I'm may be missing something, but If the actual gui already uses the util.swing package components, then if we make the util.swing package components support skins, the gui should automatically support skins, without any changes, no? I mean, for example when you talk about SIPCommSkinFrame, couldn't we make the SIPCommFrame extend the SIPCommSkinFrame, instead of vice versa ?
  

The main idea is to allow users to change almost everything, including
layout. Of course your idea is good, but when I want to change the
layout of one component e. g. main frame, then I need a concrete main
frame implementation and not only the SkinFrame implementation. It
really depends on the level of the customization.

- When you talk about the package "net.java.sip.communicator.impl.skin.swing", you don't mention what would be the "net.java.sip.communicator.service.skin.swing". If we don't need the service package, we should may be think more of a plugin package, which would load a skin into the util.swing components, as you proposed. WDYT?
  

I'm quite new to OSGi frameworks, but I thing there is no need to create
an service for skin.swing, because all classes in this package are only
design implementations of util.swing classes. Only the
SkinComponetsRepainter class can be considered as service class for
dynamical components repaint. We can make a service from this class, if
necessary.

- Couldn't we use the current ResourceManagementService instead of the ImageFactory in "net.java.sip.communicator.impl.skin.swing.resources" ?
  

Of course we can use the ResourceManagementService, but it must be able
to load files splitted around the file system and provide them in a
suitable form. I haven't seen the implementation of
ResourceManagementService yet, so I can be more exact.

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).
  

"No skin" is a skin too. I suggest to make the "blue skin" as a separate
skin in themes/ directory and "no skin" also as a separate skin, but
only with skin information and without style changes.

I think that's all for now. Excuse me if I'm missing something.

Best regards,
Yana

Best regards,

Adam Netočný
Fel ČVUT
Login: netocada

···

On 07/30/2010 12:26 PM, Yana Stamcheva wrote:

On Jul 27, 2010, at 1:05 PM, Adam Netocny wrote:

Hi,
this is the first draft of design of the skinning functionality. I can
send RTF version if necessary. Please take a look at it and send your
comments.

Best regards

Adam Netočný
Fel ČVUT
Login: netocada

On 07/25/2010 10:11 AM, Emil Ivov wrote:
    

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.

Great, looking forward to seeing them!

Emil

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

<SIP Communicator Skin Support.pdf>---------------------------------------------------------------------
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


#11

Hi Yana,

Hi Adam,

I've had a look at your document and what you're proposing seems very good plan to me! In order to completely understand the idea, I have a few questions and thoughts though.

- Could you please explain in details this part (2.1. net.java.sip.communicator.impl.gui):

The idea
is to split design and functional code to three packages. The implementation code
package(net.java.sip.communicator.util.swing) common to all classes, the design
package(net.java.sip.communicator.impl.skin) and the implementation package.
    

- I'm not sure to understand, when you say that "all classes(not only inside net.java.sip.communicator.impl.gui) with swing components must be changed to be using the new set" (2.1. net.java.sip.communicator.impl.gui). I'm may be missing something, but If the actual gui already uses the util.swing package components, then if we make the util.swing package components support skins, the gui should automatically support skins, without any changes, no? I mean, for example when you talk about SIPCommSkinFrame, couldn't we make the SIPCommFrame extend the SIPCommSkinFrame, instead of vice versa ?

- When you talk about the package "net.java.sip.communicator.impl.skin.swing", you don't mention what would be the "net.java.sip.communicator.service.skin.swing". If we don't need the service package, we should may be think more of a plugin package, which would load a skin into the util.swing components, as you proposed. WDYT?
  

I've made a small study and I think that we should introduce the
net.java.sip.communicator.service.skin.swing package into our concept.
We need the service which will be the interface for SkinManager. This
service will take care for loading of themes and design update.

Best regards,

Adam Netočný
Fel ČVUT
Login: netocada

···

On 07/30/2010 12:26 PM, Yana Stamcheva wrote:

- Couldn't we use the current ResourceManagementService instead of the ImageFactory in "net.java.sip.communicator.impl.skin.swing.resources" ?

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).

I think that's all for now. Excuse me if I'm missing something.

Best regards,
Yana

On Jul 27, 2010, at 1:05 PM, Adam Netocny wrote:

Hi,
this is the first draft of design of the skinning functionality. I can
send RTF version if necessary. Please take a look at it and send your
comments.

Best regards

Adam Netočný
Fel ČVUT
Login: netocada

On 07/25/2010 10:11 AM, Emil Ivov wrote:
    

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.

Great, looking forward to seeing them!

Emil

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

<SIP Communicator Skin Support.pdf>---------------------------------------------------------------------
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

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


#12

Hi Lubo,

That's the idea, yes. I meant that we should continue using our extended components, in the sense that we introduce there new functionality that is not related to the look&feel.

Cheers,
Yana

···

On Jul 30, 2010, at 1:40 PM, Lubomir Marinov wrote:

On Fri, Jul 30, 2010 at 1:26 PM, Yana Stamcheva > <yana@sip-communicator.org> wrote:

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).

Does it mean that the current "blue theme" will be turned into a skin
and the "no skin" mode will allow me to run with its Swing look
without the "blue theme"? I'd personally like to be able to not run
the "blue theme" on my Ubuntu and to have the native Gnome look (as
much as Swing supports it).

---------------------------------------------------------------------
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


#13

Hi Adam,

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.

Could you please elaborate on this one. What exactly do you mean by concrete main frame implementation? Would this be an implementation generated based on the xml theme ?

In your example of an xml theme you have specified just the background property and I wonder what would the whole theme look like (e.g. layout specifications for every contained component, etc). Does your idea involve that all the gui part should be written in xml ?

In our current implementation, we're able to load different color, image and sound themes through the ResourcesManagementService (the modification is not runtime though). We have also the plugin management mechanism, which allows plugins to be added in different places in the gui (which are predefined). This is not as powerful as a full skin theme, but I was thinking if extending this mechanism isn't a better choice in our case. I'm thinking of the effort needed in order to make the current gui use the skin service and if we want to support layouts, we should support mappings to component actions, make current gui plugins use the same skin mechanism, etc. Maybe I'm wrong, but somehow I think that in this kind of application apart from the images and colors, most of the people would like to change just the place of a few components, like the call button, search field, etc. and the effort needed to write a whole new skin would be so big that no one would do it. Again, I may be wrong :slight_smile:

Cheers,
Yana

···

On Jul 30, 2010, at 2:06 PM, Adam Netocny wrote:

Hi Yana,

On 07/30/2010 12:26 PM, Yana Stamcheva wrote:

Hi Adam,

I've had a look at your document and what you're proposing seems very good plan to me! In order to completely understand the idea, I have a few questions and thoughts though.

- Could you please explain in details this part (2.1. net.java.sip.communicator.impl.gui):

The idea
is to split design and functional code to three packages. The implementation code
package(net.java.sip.communicator.util.swing) common to all classes, the design
package(net.java.sip.communicator.impl.skin) and the implementation package.
    

This was meant very simply. In the util.swing package there should remain all the functional code such as, size loading or observer patterns implementation. The design implementation should be located in the impl.skin.swing package which will extend classes from util swing package. The component specific code should be then located in existent gui classes. This classes will then extend the skin.swing package.

- I'm not sure to understand, when you say that "all classes(not only inside net.java.sip.communicator.impl.gui) with swing components must be changed to be using the new set" (2.1. net.java.sip.communicator.impl.gui). I'm may be missing something, but If the actual gui already uses the util.swing package components, then if we make the util.swing package components support skins, the gui should automatically support skins, without any changes, no? I mean, for example when you talk about SIPCommSkinFrame, couldn't we make the SIPCommFrame extend the SIPCommSkinFrame, instead of vice versa ?
  

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.

- When you talk about the package "net.java.sip.communicator.impl.skin.swing", you don't mention what would be the "net.java.sip.communicator.service.skin.swing". If we don't need the service package, we should may be think more of a plugin package, which would load a skin into the util.swing components, as you proposed. WDYT?
  

I'm quite new to OSGi frameworks, but I thing there is no need to create an service for skin.swing, because all classes in this package are only design implementations of util.swing classes. Only the SkinComponetsRepainter class can be considered as service class for dynamical components repaint. We can make a service from this class, if necessary.

- Couldn't we use the current ResourceManagementService instead of the ImageFactory in "net.java.sip.communicator.impl.skin.swing.resources" ?
  

Of course we can use the ResourceManagementService, but it must be able to load files splitted around the file system and provide them in a suitable form. I haven't seen the implementation of ResourceManagementService yet, so I can be more exact.

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).
  

"No skin" is a skin too. I suggest to make the "blue skin" as a separate skin in themes/ directory and "no skin" also as a separate skin, but only with skin information and without style changes.

I think that's all for now. Excuse me if I'm missing something.

Best regards,
Yana

Best regards,

Adam Netočný
Fel ČVUT
Login: netocada

On Jul 27, 2010, at 1:05 PM, Adam Netocny wrote:

Hi,
this is the first draft of design of the skinning functionality. I can
send RTF version if necessary. Please take a look at it and send your
comments.

Best regards

Adam Netočný
Fel ČVUT
Login: netocada

On 07/25/2010 10:11 AM, Emil Ivov wrote:
    

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.

Great, looking forward to seeing them!

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net

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

<SIP Communicator Skin Support.pdf>---------------------------------------------------------------------
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

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


#14

Hi Yana.

Hi Adam,

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.
    

Could you please elaborate on this one. What exactly do you mean by concrete main frame implementation? Would this be an implementation generated based on the xml theme ?
  

Yes that is correct. But only the design. Actions etc. will be defined
in existent classes.

In your example of an xml theme you have specified just the background property and I wonder what would the whole theme look like (e.g. layout specifications for every contained component, etc). Does your idea involve that all the gui part should be written in xml?

Of course not the whole gui part should be written in XML. I have
prepared the first skin servis implementation, probably it helps you to
better understand the concept. Tomorrow I will send you the complete
implementation, cause we must complete all tests before. It contains
also some XML Schema definitions(the schema will be from time to time
extended).

In our current implementation, we're able to load different color, image and sound themes through the ResourcesManagementService (the modification is not runtime though). We have also the plugin management mechanism, which allows plugins to be added in different places in the gui (which are predefined). This is not as powerful as a full skin theme, but I was thinking if extending this mechanism isn't a better choice in our case. I'm thinking of the effort needed in order to make the current gui use the skin service and if we want to support layouts, we should support mappings to component actions, make current gui plugins use the same skin mechanism, etc. Maybe I'm wrong, but somehow I think that in this kind of application apart from the images and colors, most of the people would like to change just the place of a few components, like the call button, search field, etc. and the effort needed to write a whole new skin would be so big that no one would do it. Again, I may be wrong :slight_smile:

Themes can also extend old themes. So you can take old theme and change
only some properties. GUI plug-ins are basically GUI extensions. We will
write the code so the hardest part will be ours. :slight_smile:

Cheers,
Yana

Cheers,

Adam Netočný
Fel ČVUT
Login: netocada

···

On 08/05/2010 04:16 PM, Yana Stamcheva wrote:

On Jul 30, 2010, at 2:06 PM, Adam Netocny wrote:

Hi Yana,

On 07/30/2010 12:26 PM, Yana Stamcheva wrote:
    

Hi Adam,

I've had a look at your document and what you're proposing seems very good plan to me! In order to completely understand the idea, I have a few questions and thoughts though.

- Could you please explain in details this part (2.1. net.java.sip.communicator.impl.gui):

The idea
is to split design and functional code to three packages. The implementation code
package(net.java.sip.communicator.util.swing) common to all classes, the design
package(net.java.sip.communicator.impl.skin) and the implementation package.
    

This was meant very simply. In the util.swing package there should remain all the functional code such as, size loading or observer patterns implementation. The design implementation should be located in the impl.skin.swing package which will extend classes from util swing package. The component specific code should be then located in existent gui classes. This classes will then extend the skin.swing package.
    

- I'm not sure to understand, when you say that "all classes(not only inside net.java.sip.communicator.impl.gui) with swing components must be changed to be using the new set" (2.1. net.java.sip.communicator.impl.gui). I'm may be missing something, but If the actual gui already uses the util.swing package components, then if we make the util.swing package components support skins, the gui should automatically support skins, without any changes, no? I mean, for example when you talk about SIPCommSkinFrame, couldn't we make the SIPCommFrame extend the SIPCommSkinFrame, instead of vice versa ?
  

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.
    

- When you talk about the package "net.java.sip.communicator.impl.skin.swing", you don't mention what would be the "net.java.sip.communicator.service.skin.swing". If we don't need the service package, we should may be think more of a plugin package, which would load a skin into the util.swing components, as you proposed. WDYT?
  

I'm quite new to OSGi frameworks, but I thing there is no need to create an service for skin.swing, because all classes in this package are only design implementations of util.swing classes. Only the SkinComponetsRepainter class can be considered as service class for dynamical components repaint. We can make a service from this class, if necessary.
    

- Couldn't we use the current ResourceManagementService instead of the ImageFactory in "net.java.sip.communicator.impl.skin.swing.resources" ?
  

Of course we can use the ResourceManagementService, but it must be able to load files splitted around the file system and provide them in a suitable form. I haven't seen the implementation of ResourceManagementService yet, so I can be more exact.
    

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).
  

"No skin" is a skin too. I suggest to make the "blue skin" as a separate skin in themes/ directory and "no skin" also as a separate skin, but only with skin information and without style changes.
    

I think that's all for now. Excuse me if I'm missing something.

Best regards,
Yana

Best regards,

Adam Netočný
Fel ČVUT
Login: netocada
    

On Jul 27, 2010, at 1:05 PM, Adam Netocny wrote:

Hi,
this is the first draft of design of the skinning functionality. I can
send RTF version if necessary. Please take a look at it and send your
comments.

Best regards

Adam Netočný
Fel ČVUT
Login: netocada

On 07/25/2010 10:11 AM, Emil Ivov wrote:
    

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.

Great, looking forward to seeing them!

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net

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

<SIP Communicator Skin Support.pdf>---------------------------------------------------------------------
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

---------------------------------------------------------------------
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


#15

Hi Yana,

so I'm sending you the first implementation version. The zip file
contains the implementation in src folder and also tests in the test
folder. The tests have been designed to cover as much code as possible.
The Theme directory contains XML Schema files and is necessary for
tests, because the parser is looking for definitions in this folder.

Cheers,

Adam Netočný
Fel ČVUT
Login: netocada

skin.zip (41.9 KB)

···

On 08/05/2010 04:16 PM, Yana Stamcheva wrote:

Hi Adam,

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.
    

Could you please elaborate on this one. What exactly do you mean by concrete main frame implementation? Would this be an implementation generated based on the xml theme ?

In your example of an xml theme you have specified just the background property and I wonder what would the whole theme look like (e.g. layout specifications for every contained component, etc). Does your idea involve that all the gui part should be written in xml ?

In our current implementation, we're able to load different color, image and sound themes through the ResourcesManagementService (the modification is not runtime though). We have also the plugin management mechanism, which allows plugins to be added in different places in the gui (which are predefined). This is not as powerful as a full skin theme, but I was thinking if extending this mechanism isn't a better choice in our case. I'm thinking of the effort needed in order to make the current gui use the skin service and if we want to support layouts, we should support mappings to component actions, make current gui plugins use the same skin mechanism, etc. Maybe I'm wrong, but somehow I think that in this kind of application apart from the images and colors, most of the people would like to change just the place of a few components, like the call button, search field, etc. and the effort needed to write a whole new skin would be so big that no one would do it. Again, I may be wrong :slight_smile:

Cheers,
Yana

On Jul 30, 2010, at 2:06 PM, Adam Netocny wrote:

Hi Yana,

On 07/30/2010 12:26 PM, Yana Stamcheva wrote:
    

Hi Adam,

I've had a look at your document and what you're proposing seems very good plan to me! In order to completely understand the idea, I have a few questions and thoughts though.

- Could you please explain in details this part (2.1. net.java.sip.communicator.impl.gui):

The idea
is to split design and functional code to three packages. The implementation code
package(net.java.sip.communicator.util.swing) common to all classes, the design
package(net.java.sip.communicator.impl.skin) and the implementation package.
    

This was meant very simply. In the util.swing package there should remain all the functional code such as, size loading or observer patterns implementation. The design implementation should be located in the impl.skin.swing package which will extend classes from util swing package. The component specific code should be then located in existent gui classes. This classes will then extend the skin.swing package.
    

- I'm not sure to understand, when you say that "all classes(not only inside net.java.sip.communicator.impl.gui) with swing components must be changed to be using the new set" (2.1. net.java.sip.communicator.impl.gui). I'm may be missing something, but If the actual gui already uses the util.swing package components, then if we make the util.swing package components support skins, the gui should automatically support skins, without any changes, no? I mean, for example when you talk about SIPCommSkinFrame, couldn't we make the SIPCommFrame extend the SIPCommSkinFrame, instead of vice versa ?
  

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.
    

- When you talk about the package "net.java.sip.communicator.impl.skin.swing", you don't mention what would be the "net.java.sip.communicator.service.skin.swing". If we don't need the service package, we should may be think more of a plugin package, which would load a skin into the util.swing components, as you proposed. WDYT?
  

I'm quite new to OSGi frameworks, but I thing there is no need to create an service for skin.swing, because all classes in this package are only design implementations of util.swing classes. Only the SkinComponetsRepainter class can be considered as service class for dynamical components repaint. We can make a service from this class, if necessary.
    

- Couldn't we use the current ResourceManagementService instead of the ImageFactory in "net.java.sip.communicator.impl.skin.swing.resources" ?
  

Of course we can use the ResourceManagementService, but it must be able to load files splitted around the file system and provide them in a suitable form. I haven't seen the implementation of ResourceManagementService yet, so I can be more exact.
    

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).
  

"No skin" is a skin too. I suggest to make the "blue skin" as a separate skin in themes/ directory and "no skin" also as a separate skin, but only with skin information and without style changes.
    

I think that's all for now. Excuse me if I'm missing something.

Best regards,
Yana

Best regards,

Adam Netočný
Fel ČVUT
Login: netocada
    

On Jul 27, 2010, at 1:05 PM, Adam Netocny wrote:

Hi,
this is the first draft of design of the skinning functionality. I can
send RTF version if necessary. Please take a look at it and send your
comments.

Best regards

Adam Netočný
Fel ČVUT
Login: netocada

On 07/25/2010 10:11 AM, Emil Ivov wrote:
    

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.

Great, looking forward to seeing them!

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net

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

<SIP Communicator Skin Support.pdf>---------------------------------------------------------------------
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

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


#16

Hi Adam,

Thanks for this first version! It looks quite complete and clarifies a lot of my initial questions. I'm now looking at the code and will come back to you later today with some more comments and questions.

Cheers,
Yana

···

On Aug 6, 2010, at 1:52 PM, Adam Netocny wrote:

Hi Yana,

so I'm sending you the first implementation version. The zip file
contains the implementation in src folder and also tests in the test
folder. The tests have been designed to cover as much code as possible.
The Theme directory contains XML Schema files and is necessary for
tests, because the parser is looking for definitions in this folder.

Cheers,

Adam Netočný
Fel ČVUT
Login: netocada

On 08/05/2010 04:16 PM, Yana Stamcheva wrote:

Hi Adam,

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.

Could you please elaborate on this one. What exactly do you mean by concrete main frame implementation? Would this be an implementation generated based on the xml theme ?

In your example of an xml theme you have specified just the background property and I wonder what would the whole theme look like (e.g. layout specifications for every contained component, etc). Does your idea involve that all the gui part should be written in xml ?

In our current implementation, we're able to load different color, image and sound themes through the ResourcesManagementService (the modification is not runtime though). We have also the plugin management mechanism, which allows plugins to be added in different places in the gui (which are predefined). This is not as powerful as a full skin theme, but I was thinking if extending this mechanism isn't a better choice in our case. I'm thinking of the effort needed in order to make the current gui use the skin service and if we want to support layouts, we should support mappings to component actions, make current gui plugins use the same skin mechanism, etc. Maybe I'm wrong, but somehow I think that in this kind of application apart from the images and colors, most of the people would like to change just the place of a few components, like the call button, search field, etc. and the effort needed to write a whole new skin would be so big that no one would do it. Again, I may be wrong :slight_smile:

Cheers,
Yana

On Jul 30, 2010, at 2:06 PM, Adam Netocny wrote:

Hi Yana,

On 07/30/2010 12:26 PM, Yana Stamcheva wrote:

Hi Adam,

I've had a look at your document and what you're proposing seems very good plan to me! In order to completely understand the idea, I have a few questions and thoughts though.

- Could you please explain in details this part (2.1. net.java.sip.communicator.impl.gui):

The idea
is to split design and functional code to three packages. The implementation code
package(net.java.sip.communicator.util.swing) common to all classes, the design
package(net.java.sip.communicator.impl.skin) and the implementation package.

This was meant very simply. In the util.swing package there should remain all the functional code such as, size loading or observer patterns implementation. The design implementation should be located in the impl.skin.swing package which will extend classes from util swing package. The component specific code should be then located in existent gui classes. This classes will then extend the skin.swing package.

- I'm not sure to understand, when you say that "all classes(not only inside net.java.sip.communicator.impl.gui) with swing components must be changed to be using the new set" (2.1. net.java.sip.communicator.impl.gui). I'm may be missing something, but If the actual gui already uses the util.swing package components, then if we make the util.swing package components support skins, the gui should automatically support skins, without any changes, no? I mean, for example when you talk about SIPCommSkinFrame, couldn't we make the SIPCommFrame extend the SIPCommSkinFrame, instead of vice versa ?

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.

- When you talk about the package "net.java.sip.communicator.impl.skin.swing", you don't mention what would be the "net.java.sip.communicator.service.skin.swing". If we don't need the service package, we should may be think more of a plugin package, which would load a skin into the util.swing components, as you proposed. WDYT?

I'm quite new to OSGi frameworks, but I thing there is no need to create an service for skin.swing, because all classes in this package are only design implementations of util.swing classes. Only the SkinComponetsRepainter class can be considered as service class for dynamical components repaint. We can make a service from this class, if necessary.

- Couldn't we use the current ResourceManagementService instead of the ImageFactory in "net.java.sip.communicator.impl.skin.swing.resources" ?

Of course we can use the ResourceManagementService, but it must be able to load files splitted around the file system and provide them in a suitable form. I haven't seen the implementation of ResourceManagementService yet, so I can be more exact.

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).

"No skin" is a skin too. I suggest to make the "blue skin" as a separate skin in themes/ directory and "no skin" also as a separate skin, but only with skin information and without style changes.

I think that's all for now. Excuse me if I'm missing something.

Best regards,
Yana

Best regards,

Adam Netočný
Fel ČVUT
Login: netocada

On Jul 27, 2010, at 1:05 PM, Adam Netocny wrote:

Hi,
this is the first draft of design of the skinning functionality. I can
send RTF version if necessary. Please take a look at it and send your
comments.

Best regards

Adam Netočný
Fel ČVUT
Login: netocada

On 07/25/2010 10:11 AM, Emil Ivov wrote:

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.

Great, looking forward to seeing them!

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net

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

<SIP Communicator Skin Support.pdf>---------------------------------------------------------------------
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

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

<skin.zip>---------------------------------------------------------------------
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


#17

Hey Adam,

I like your concept and find the skin reload mechanism very useful.

I'm afraid however that the skin manager is quite redundant with what we have right now. Our ResourcesManagementService actually plays the same role, by loading all kind of resources, like images, colors, sizes, etc. located in properties files, defined for specific component id-s. It is now used by all look&feel related classes and all gui components. Could you please have a look at it and tell me how do you think we could relate the skin manager with this resource service? Do you think it's possible to implement the reload skin mechanism with the existing resource management service?

Btw, have you thought of some way, that would allow us to reuse the swing's already integrated look&feel reload mechanism? This is something that already exist in swing, so we should consider reusing it if it could fit in our case. WDYT?

If I understand well you propose that each "skinnable" component would implement the SkinRepaintable interface. In case of repaint it would obtain its properties through the "public Property getPropertyForComponentId(String id, String property)" method. Is that right? In this case, have you already thought of a way allowing us to define look&feel properties or properties that are defined for a class of components, like all JFrames or all JButtons, etc.?

Cheers,
Yana

···

On Aug 9, 2010, at 12:23 PM, Yana Stamcheva wrote:

Hi Adam,

Thanks for this first version! It looks quite complete and clarifies a lot of my initial questions. I'm now looking at the code and will come back to you later today with some more comments and questions.

Cheers,
Yana

On Aug 6, 2010, at 1:52 PM, Adam Netocny wrote:

Hi Yana,

so I'm sending you the first implementation version. The zip file
contains the implementation in src folder and also tests in the test
folder. The tests have been designed to cover as much code as possible.
The Theme directory contains XML Schema files and is necessary for
tests, because the parser is looking for definitions in this folder.

Cheers,

Adam Netočný
Fel ČVUT
Login: netocada

On 08/05/2010 04:16 PM, Yana Stamcheva wrote:

Hi Adam,

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.

Could you please elaborate on this one. What exactly do you mean by concrete main frame implementation? Would this be an implementation generated based on the xml theme ?

In your example of an xml theme you have specified just the background property and I wonder what would the whole theme look like (e.g. layout specifications for every contained component, etc). Does your idea involve that all the gui part should be written in xml ?

In our current implementation, we're able to load different color, image and sound themes through the ResourcesManagementService (the modification is not runtime though). We have also the plugin management mechanism, which allows plugins to be added in different places in the gui (which are predefined). This is not as powerful as a full skin theme, but I was thinking if extending this mechanism isn't a better choice in our case. I'm thinking of the effort needed in order to make the current gui use the skin service and if we want to support layouts, we should support mappings to component actions, make current gui plugins use the same skin mechanism, etc. Maybe I'm wrong, but somehow I think that in this kind of application apart from the images and colors, most of the people would like to change just the place of a few components, like the call button, search field, etc. and the effort needed to write a whole new skin would be so big that no one would do it. Again, I may be wrong :slight_smile:

Cheers,
Yana

On Jul 30, 2010, at 2:06 PM, Adam Netocny wrote:

Hi Yana,

On 07/30/2010 12:26 PM, Yana Stamcheva wrote:

Hi Adam,

I've had a look at your document and what you're proposing seems very good plan to me! In order to completely understand the idea, I have a few questions and thoughts though.

- Could you please explain in details this part (2.1. net.java.sip.communicator.impl.gui):

The idea
is to split design and functional code to three packages. The implementation code
package(net.java.sip.communicator.util.swing) common to all classes, the design
package(net.java.sip.communicator.impl.skin) and the implementation package.

This was meant very simply. In the util.swing package there should remain all the functional code such as, size loading or observer patterns implementation. The design implementation should be located in the impl.skin.swing package which will extend classes from util swing package. The component specific code should be then located in existent gui classes. This classes will then extend the skin.swing package.

- I'm not sure to understand, when you say that "all classes(not only inside net.java.sip.communicator.impl.gui) with swing components must be changed to be using the new set" (2.1. net.java.sip.communicator.impl.gui). I'm may be missing something, but If the actual gui already uses the util.swing package components, then if we make the util.swing package components support skins, the gui should automatically support skins, without any changes, no? I mean, for example when you talk about SIPCommSkinFrame, couldn't we make the SIPCommFrame extend the SIPCommSkinFrame, instead of vice versa ?

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.

- When you talk about the package "net.java.sip.communicator.impl.skin.swing", you don't mention what would be the "net.java.sip.communicator.service.skin.swing". If we don't need the service package, we should may be think more of a plugin package, which would load a skin into the util.swing components, as you proposed. WDYT?

I'm quite new to OSGi frameworks, but I thing there is no need to create an service for skin.swing, because all classes in this package are only design implementations of util.swing classes. Only the SkinComponetsRepainter class can be considered as service class for dynamical components repaint. We can make a service from this class, if necessary.

- Couldn't we use the current ResourceManagementService instead of the ImageFactory in "net.java.sip.communicator.impl.skin.swing.resources" ?

Of course we can use the ResourceManagementService, but it must be able to load files splitted around the file system and provide them in a suitable form. I haven't seen the implementation of ResourceManagementService yet, so I can be more exact.

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).

"No skin" is a skin too. I suggest to make the "blue skin" as a separate skin in themes/ directory and "no skin" also as a separate skin, but only with skin information and without style changes.

I think that's all for now. Excuse me if I'm missing something.

Best regards,
Yana

Best regards,

Adam Netočný
Fel ČVUT
Login: netocada

On Jul 27, 2010, at 1:05 PM, Adam Netocny wrote:

Hi,
this is the first draft of design of the skinning functionality. I can
send RTF version if necessary. Please take a look at it and send your
comments.

Best regards

Adam Netočný
Fel ČVUT
Login: netocada

On 07/25/2010 10:11 AM, Emil Ivov wrote:

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.

Great, looking forward to seeing them!

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net

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

<SIP Communicator Skin Support.pdf>---------------------------------------------------------------------
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

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

<skin.zip>---------------------------------------------------------------------
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

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


#18

Hi Yana,

Hey Adam,

I like your concept and find the skin reload mechanism very useful.

I'm afraid however that the skin manager is quite redundant with what we have right now. Our ResourcesManagementService actually plays the same role, by loading all kind of resources, like images, colors, sizes, etc. located in properties files, defined for specific component id-s. It is now used by all look&feel related classes and all gui components. Could you please have a look at it and tell me how do you think we could relate the skin manager with this resource service? Do you think it's possible to implement the reload skin mechanism with the existing resource management service?
  

I think that the ResourcesManagementService plays the same role, but if
we want to make SIP communicator real skinable we cannot use resources
packed in a jar file. The problem is that users MUST NOT be programmers
and if they want to make their own skin nowadays, they are forced to
change a jar file. Our idea is to create a separate interface for skins
in a suitable form(XML is more readable as properties files). Of course
the RecoursesManagementService can be used for loading all necessary
resources, but if the skinability should be real "user friendly"
resources must be located in directories and not jar files. And on the
other hand our SkinManager reckons with more features then the
ResourcesManagerService(layout, "no-skin", etc.).

We can consider a compromise that the style information will be located
in the XML structure and resources will be managed and loaded with the
ResourcesManagementService, because it contains a large amount of useful
methods. :wink:

Btw, have you thought of some way, that would allow us to reuse the swing's already integrated look&feel reload mechanism? This is something that already exist in swing, so we should consider reusing it if it could fit in our case. WDYT?
  

I don't really know what you mean with a "swing's already integrated
look&feel reload mechanism". Can you explain it, please?

If I understand well you propose that each "skinnable" component would implement the SkinRepaintable interface. In case of repaint it would obtain its properties through the "public Property getPropertyForComponentId(String id, String property)" method. Is that right? In this case, have you already thought of a way allowing us to define look&feel properties or properties that are defined for a class of components, like all JFrames or all JButtons, etc.?
  

Yes thats right. For a class of components we only create a specific id.
Eg. JFrame: id="frame", implementation example: see attachment. The
implementation example only extends existent SIPCommFrame class.

Cheers,

Adam Netočný
Fel ČVUT
Login: netocada

SIPCommSkinFrame.java (2.5 KB)

SkinMainContentPane.java (4.97 KB)

···

On 08/09/2010 06:34 PM, Yana Stamcheva wrote:

Cheers,
Yana

On Aug 9, 2010, at 12:23 PM, Yana Stamcheva wrote:

Hi Adam,

Thanks for this first version! It looks quite complete and clarifies a lot of my initial questions. I'm now looking at the code and will come back to you later today with some more comments and questions.

Cheers,
Yana

On Aug 6, 2010, at 1:52 PM, Adam Netocny wrote:

Hi Yana,

so I'm sending you the first implementation version. The zip file
contains the implementation in src folder and also tests in the test
folder. The tests have been designed to cover as much code as possible.
The Theme directory contains XML Schema files and is necessary for
tests, because the parser is looking for definitions in this folder.

Cheers,

Adam Netočný
Fel ČVUT
Login: netocada

On 08/05/2010 04:16 PM, Yana Stamcheva wrote:
      

Hi Adam,

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.

Could you please elaborate on this one. What exactly do you mean by concrete main frame implementation? Would this be an implementation generated based on the xml theme ?

In your example of an xml theme you have specified just the background property and I wonder what would the whole theme look like (e.g. layout specifications for every contained component, etc). Does your idea involve that all the gui part should be written in xml ?

In our current implementation, we're able to load different color, image and sound themes through the ResourcesManagementService (the modification is not runtime though). We have also the plugin management mechanism, which allows plugins to be added in different places in the gui (which are predefined). This is not as powerful as a full skin theme, but I was thinking if extending this mechanism isn't a better choice in our case. I'm thinking of the effort needed in order to make the current gui use the skin service and if we want to support layouts, we should support mappings to component actions, make current gui plugins use the same skin mechanism, etc. Maybe I'm wrong, but somehow I think that in this kind of application apart from the images and colors, most of the people would like to change just the place of a few components, like the call button, search field, etc. and the effort needed to write a whole new skin would be so big that no one would do it. Again, I may be wrong :slight_smile:

Cheers,
Yana

On Jul 30, 2010, at 2:06 PM, Adam Netocny wrote:

Hi Yana,

On 07/30/2010 12:26 PM, Yana Stamcheva wrote:

Hi Adam,

I've had a look at your document and what you're proposing seems very good plan to me! In order to completely understand the idea, I have a few questions and thoughts though.

- Could you please explain in details this part (2.1. net.java.sip.communicator.impl.gui):

The idea
is to split design and functional code to three packages. The implementation code
package(net.java.sip.communicator.util.swing) common to all classes, the design
package(net.java.sip.communicator.impl.skin) and the implementation package.

This was meant very simply. In the util.swing package there should remain all the functional code such as, size loading or observer patterns implementation. The design implementation should be located in the impl.skin.swing package which will extend classes from util swing package. The component specific code should be then located in existent gui classes. This classes will then extend the skin.swing package.

- I'm not sure to understand, when you say that "all classes(not only inside net.java.sip.communicator.impl.gui) with swing components must be changed to be using the new set" (2.1. net.java.sip.communicator.impl.gui). I'm may be missing something, but If the actual gui already uses the util.swing package components, then if we make the util.swing package components support skins, the gui should automatically support skins, without any changes, no? I mean, for example when you talk about SIPCommSkinFrame, couldn't we make the SIPCommFrame extend the SIPCommSkinFrame, instead of vice versa ?

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.

- When you talk about the package "net.java.sip.communicator.impl.skin.swing", you don't mention what would be the "net.java.sip.communicator.service.skin.swing". If we don't need the service package, we should may be think more of a plugin package, which would load a skin into the util.swing components, as you proposed. WDYT?

I'm quite new to OSGi frameworks, but I thing there is no need to create an service for skin.swing, because all classes in this package are only design implementations of util.swing classes. Only the SkinComponetsRepainter class can be considered as service class for dynamical components repaint. We can make a service from this class, if necessary.

- Couldn't we use the current ResourceManagementService instead of the ImageFactory in "net.java.sip.communicator.impl.skin.swing.resources" ?

Of course we can use the ResourceManagementService, but it must be able to load files splitted around the file system and provide them in a suitable form. I haven't seen the implementation of ResourceManagementService yet, so I can be more exact.

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).

"No skin" is a skin too. I suggest to make the "blue skin" as a separate skin in themes/ directory and "no skin" also as a separate skin, but only with skin information and without style changes.

I think that's all for now. Excuse me if I'm missing something.

Best regards,
Yana

Best regards,

Adam Netočný
Fel ČVUT
Login: netocada

On Jul 27, 2010, at 1:05 PM, Adam Netocny wrote:

Hi,
this is the first draft of design of the skinning functionality. I can
send RTF version if necessary. Please take a look at it and send your
comments.

Best regards

Adam Netočný
Fel ČVUT
Login: netocada

On 07/25/2010 10:11 AM, Emil Ivov wrote:

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.

Great, looking forward to seeing them!

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net

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

<SIP Communicator Skin Support.pdf>---------------------------------------------------------------------
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

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

<skin.zip>---------------------------------------------------------------------
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

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


#19

Hi Yana,

in the attachment is a simple theme for the example I've send you just a
moment ago. (screenshot included)

Cheers,

Adam Netočný
Fel ČVUT
Login: netocada

Themes.zip (33 KB)

···

On 08/09/2010 06:34 PM, Yana Stamcheva wrote:

Hey Adam,

I like your concept and find the skin reload mechanism very useful.

I'm afraid however that the skin manager is quite redundant with what we have right now. Our ResourcesManagementService actually plays the same role, by loading all kind of resources, like images, colors, sizes, etc. located in properties files, defined for specific component id-s. It is now used by all look&feel related classes and all gui components. Could you please have a look at it and tell me how do you think we could relate the skin manager with this resource service? Do you think it's possible to implement the reload skin mechanism with the existing resource management service?

Btw, have you thought of some way, that would allow us to reuse the swing's already integrated look&feel reload mechanism? This is something that already exist in swing, so we should consider reusing it if it could fit in our case. WDYT?

If I understand well you propose that each "skinnable" component would implement the SkinRepaintable interface. In case of repaint it would obtain its properties through the "public Property getPropertyForComponentId(String id, String property)" method. Is that right? In this case, have you already thought of a way allowing us to define look&feel properties or properties that are defined for a class of components, like all JFrames or all JButtons, etc.?

Cheers,
Yana

On Aug 9, 2010, at 12:23 PM, Yana Stamcheva wrote:

Hi Adam,

Thanks for this first version! It looks quite complete and clarifies a lot of my initial questions. I'm now looking at the code and will come back to you later today with some more comments and questions.

Cheers,
Yana

On Aug 6, 2010, at 1:52 PM, Adam Netocny wrote:

Hi Yana,

so I'm sending you the first implementation version. The zip file
contains the implementation in src folder and also tests in the test
folder. The tests have been designed to cover as much code as possible.
The Theme directory contains XML Schema files and is necessary for
tests, because the parser is looking for definitions in this folder.

Cheers,

Adam Netočný
Fel ČVUT
Login: netocada

On 08/05/2010 04:16 PM, Yana Stamcheva wrote:
      

Hi Adam,

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.

Could you please elaborate on this one. What exactly do you mean by concrete main frame implementation? Would this be an implementation generated based on the xml theme ?

In your example of an xml theme you have specified just the background property and I wonder what would the whole theme look like (e.g. layout specifications for every contained component, etc). Does your idea involve that all the gui part should be written in xml ?

In our current implementation, we're able to load different color, image and sound themes through the ResourcesManagementService (the modification is not runtime though). We have also the plugin management mechanism, which allows plugins to be added in different places in the gui (which are predefined). This is not as powerful as a full skin theme, but I was thinking if extending this mechanism isn't a better choice in our case. I'm thinking of the effort needed in order to make the current gui use the skin service and if we want to support layouts, we should support mappings to component actions, make current gui plugins use the same skin mechanism, etc. Maybe I'm wrong, but somehow I think that in this kind of application apart from the images and colors, most of the people would like to change just the place of a few components, like the call button, search field, etc. and the effort needed to write a whole new skin would be so big that no one would do it. Again, I may be wrong :slight_smile:

Cheers,
Yana

On Jul 30, 2010, at 2:06 PM, Adam Netocny wrote:

Hi Yana,

On 07/30/2010 12:26 PM, Yana Stamcheva wrote:

Hi Adam,

I've had a look at your document and what you're proposing seems very good plan to me! In order to completely understand the idea, I have a few questions and thoughts though.

- Could you please explain in details this part (2.1. net.java.sip.communicator.impl.gui):

The idea
is to split design and functional code to three packages. The implementation code
package(net.java.sip.communicator.util.swing) common to all classes, the design
package(net.java.sip.communicator.impl.skin) and the implementation package.

This was meant very simply. In the util.swing package there should remain all the functional code such as, size loading or observer patterns implementation. The design implementation should be located in the impl.skin.swing package which will extend classes from util swing package. The component specific code should be then located in existent gui classes. This classes will then extend the skin.swing package.

- I'm not sure to understand, when you say that "all classes(not only inside net.java.sip.communicator.impl.gui) with swing components must be changed to be using the new set" (2.1. net.java.sip.communicator.impl.gui). I'm may be missing something, but If the actual gui already uses the util.swing package components, then if we make the util.swing package components support skins, the gui should automatically support skins, without any changes, no? I mean, for example when you talk about SIPCommSkinFrame, couldn't we make the SIPCommFrame extend the SIPCommSkinFrame, instead of vice versa ?

The main idea is to allow users to change almost everything, including layout. Of course your idea is good, but when I want to change the layout of one component e. g. main frame, then I need a concrete main frame implementation and not only the SkinFrame implementation. It really depends on the level of the customization.

- When you talk about the package "net.java.sip.communicator.impl.skin.swing", you don't mention what would be the "net.java.sip.communicator.service.skin.swing". If we don't need the service package, we should may be think more of a plugin package, which would load a skin into the util.swing components, as you proposed. WDYT?

I'm quite new to OSGi frameworks, but I thing there is no need to create an service for skin.swing, because all classes in this package are only design implementations of util.swing classes. Only the SkinComponetsRepainter class can be considered as service class for dynamical components repaint. We can make a service from this class, if necessary.

- Couldn't we use the current ResourceManagementService instead of the ImageFactory in "net.java.sip.communicator.impl.skin.swing.resources" ?

Of course we can use the ResourceManagementService, but it must be able to load files splitted around the file system and provide them in a suitable form. I haven't seen the implementation of ResourceManagementService yet, so I can be more exact.

I think it's worth mentioning that during the implementation we should keep in mind that the user could choose to use the application in "no skin" mode. In this case however, we should keep the use of our extended components (currently located in util.swing package).

"No skin" is a skin too. I suggest to make the "blue skin" as a separate skin in themes/ directory and "no skin" also as a separate skin, but only with skin information and without style changes.

I think that's all for now. Excuse me if I'm missing something.

Best regards,
Yana

Best regards,

Adam Netočný
Fel ČVUT
Login: netocada

On Jul 27, 2010, at 1:05 PM, Adam Netocny wrote:

Hi,
this is the first draft of design of the skinning functionality. I can
send RTF version if necessary. Please take a look at it and send your
comments.

Best regards

Adam Netočný
Fel ČVUT
Login: netocada

On 07/25/2010 10:11 AM, Emil Ivov wrote:

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to make SIP
Communicator skinnable.

Well that depends on the level of customization that you'd like to allow
with skins. Changing icons and colours would be fairly trivial since
they are all isolated in our resource bundle.

Having a skin modify the layout on the other hand would be a completely
different story.

I am not sure how easy is to do that, because I am not a Java expert
myself (well, sort of, in J2ME, but not in Swing), that is why I
asked Mr. Netocny to delve into it. He would definitely appreciate
any comments and suggestions from the actual author of the current
GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary designs and post
them here in a few days.

Great, looking forward to seeing them!

Emil

---------------------------------------------------------------------
To unsubscribe, e-mail:
dev-unsubscribe@sip-communicator.dev.java.net

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

<SIP Communicator Skin Support.pdf>---------------------------------------------------------------------
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

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

<skin.zip>---------------------------------------------------------------------
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

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


#20

Hey Adam,

Yana is the real expert here so I guess she'll probably have further
comments but I wanted to ask a few myself.

(inline)

На 09.08.10 19:45, Adam Netocny написа:

Hi Yana,

Hey Adam,

I like your concept and find the skin reload mechanism very
useful.

I'm afraid however that the skin manager is quite redundant with
what we have right now. Our ResourcesManagementService actually
plays the same role, by loading all kind of resources, like images,
colors, sizes, etc. located in properties files, defined for
specific component id-s. It is now used by all look&feel related
classes and all gui components. Could you please have a look at it
and tell me how do you think we could relate the skin manager with
this resource service? Do you think it's possible to implement the
reload skin mechanism with the existing resource management
service?

I think that the ResourcesManagementService plays the same role, but
if we want to make SIP communicator real skinable we cannot use
resources packed in a jar file. The problem is that users MUST NOT be
programmers and if they want to make their own skin nowadays, they
are forced to change a jar file.

So how are you planning on packing all the images together? I agree
jar-s might look unfriendly to some users but we'll still need to
archive the content of the skin so that it would be easily
transportable. The ResourcesManagementService could very easily be
adapted to use zip files if we decide that this is the way we'd like to go.

Our idea is to create a separate
interface for skins in a suitable form(XML is more readable as
properties files). Of course the RecoursesManagementService can be
used for loading all necessary resources, but if the skinability
should be real "user friendly" resources must be located in
directories and not jar files.

For the record, the ResourcesManagementService is simply loading images
from the classpath so it could just as well pick them up from
directories ... as a user however I'd find this quite inconvenient.
How would I make my skins available for download and move them around?
Would I need to be dealing with a bunch of folders all the time?
Wouldn't it be better if I could just zip them up and handle them as a
single file?

And on the other hand our SkinManager
reckons with more features then the ResourcesManagerService(layout,
"no-skin", etc.).

The ResourcesManagerService could indeed be extended to also allow
customization of more advanced features such as the layouts for example.
Still, that's hardly enough of a reason to rewrite it entirely.

We can consider a compromise that the style information will be
located in the XML structure and resources will be managed and loaded
with the ResourcesManagementService, because it contains a large
amount of useful methods. :wink:

Ideally, the best way to go would be to start by extending the
ResourcesManagerService so that it would have the features we are
currently missing: like for example triggering an interface refresh,
reloading from a zip file, etc.

Btw, have you thought of some way, that would allow us to reuse the
swing's already integrated look&feel reload mechanism? This is
something that already exist in swing, so we should consider
reusing it if it could fit in our case. WDYT?

I don't really know what you mean with a "swing's already integrated
look&feel reload mechanism". Can you explain it, please?

Yana will correct me if I am wrong but I believe she was referring to
swing's ability to reload a look and feel during runtime as an
alternative to the skin repaint mechanism that you are suggesting.

The point is that if there's already such a mechanism in place there,
then we should have really good reasons for not using it and for writing
our own thing.

Having a skinning mechanism is something that's been on our todo list
for quite a while and we're really happy you are putting effort into
this. It's a feature that's probably going to be important for many
though and we should definitely make sure we get it right, so please
bear with us along the way :).

Cheers,
Emil

If I understand well you propose that each "skinnable" component
would implement the SkinRepaintable interface. In case of repaint
it would obtain its properties through the "public Property
getPropertyForComponentId(String id, String property)" method. Is
that right? In this case, have you already thought of a way
allowing us to define look&feel properties or properties that are
defined for a class of components, like all JFrames or all
JButtons, etc.?

Yes thats right. For a class of components we only create a specific
id. Eg. JFrame: id="frame", implementation example: see attachment.
The implementation example only extends existent SIPCommFrame class.

Cheers,

Adam Netočný Fel ČVUT Login: netocada

Cheers, Yana

Hi Adam,

Thanks for this first version! It looks quite complete and
clarifies a lot of my initial questions. I'm now looking at the
code and will come back to you later today with some more
comments and questions.

Cheers, Yana

Hi Yana,

so I'm sending you the first implementation version. The zip
file contains the implementation in src folder and also tests
in the test folder. The tests have been designed to cover as
much code as possible. The Theme directory contains XML Schema
files and is necessary for tests, because the parser is looking
for definitions in this folder.

Cheers,

Adam Netočný Fel ČVUT Login: netocada

Hi Adam,

The main idea is to allow users to change almost
everything, including layout. Of course your idea is good,
but when I want to change the layout of one component e. g.
main frame, then I need a concrete main frame
implementation and not only the SkinFrame implementation.
It really depends on the level of the customization.

Could you please elaborate on this one. What exactly do you
mean by concrete main frame implementation? Would this be an
implementation generated based on the xml theme ?

In your example of an xml theme you have specified just the
background property and I wonder what would the whole theme
look like (e.g. layout specifications for every contained
component, etc). Does your idea involve that all the gui part
should be written in xml ?

In our current implementation, we're able to load different
color, image and sound themes through the
ResourcesManagementService (the modification is not runtime
though). We have also the plugin management mechanism, which
allows plugins to be added in different places in the gui
(which are predefined). This is not as powerful as a full
skin theme, but I was thinking if extending this mechanism
isn't a better choice in our case. I'm thinking of the effort
needed in order to make the current gui use the skin service
and if we want to support layouts, we should support mappings
to component actions, make current gui plugins use the same
skin mechanism, etc. Maybe I'm wrong, but somehow I think
that in this kind of application apart from the images and
colors, most of the people would like to change just the
place of a few components, like the call button, search
field, etc. and the effort needed to write a whole new skin
would be so big that no one would do it. Again, I may be
wrong :slight_smile:

Cheers, Yana

Hi Yana,

Hi Adam,

I've had a look at your document and what you're
proposing seems very good plan to me! In order to
completely understand the idea, I have a few questions
and thoughts though.

- Could you please explain in details this part (2.1.
net.java.sip.communicator.impl.gui):

The idea is to split design and functional code to
three packages. The implementation code
package(net.java.sip.communicator.util.swing) common to
all classes, the design
package(net.java.sip.communicator.impl.skin) and the
implementation package.

This was meant very simply. In the util.swing package there
should remain all the functional code such as, size loading
or observer patterns implementation. The design
implementation should be located in the impl.skin.swing
package which will extend classes from util swing package.
The component specific code should be then located in
existent gui classes. This classes will then extend the
skin.swing package.

- I'm not sure to understand, when you say that "all
classes(not only inside
net.java.sip.communicator.impl.gui) with swing components
must be changed to be using the new set" (2.1.
net.java.sip.communicator.impl.gui). I'm may be missing
something, but If the actual gui already uses the
util.swing package components, then if we make the
util.swing package components support skins, the gui
should automatically support skins, without any changes,
no? I mean, for example when you talk about
SIPCommSkinFrame, couldn't we make the SIPCommFrame
extend the SIPCommSkinFrame, instead of vice versa ?

The main idea is to allow users to change almost
everything, including layout. Of course your idea is good,
but when I want to change the layout of one component e. g.
main frame, then I need a concrete main frame
implementation and not only the SkinFrame implementation.
It really depends on the level of the customization.

- When you talk about the package
"net.java.sip.communicator.impl.skin.swing", you don't
mention what would be the
"net.java.sip.communicator.service.skin.swing". If we
don't need the service package, we should may be think
more of a plugin package, which would load a skin into
the util.swing components, as you proposed. WDYT?

I'm quite new to OSGi frameworks, but I thing there is no
need to create an service for skin.swing, because all
classes in this package are only design implementations of
util.swing classes. Only the SkinComponetsRepainter class
can be considered as service class for dynamical components
repaint. We can make a service from this class, if
necessary.

- Couldn't we use the current ResourceManagementService
instead of the ImageFactory in
"net.java.sip.communicator.impl.skin.swing.resources" ?

Of course we can use the ResourceManagementService, but it
must be able to load files splitted around the file system
and provide them in a suitable form. I haven't seen the
implementation of ResourceManagementService yet, so I can
be more exact.

I think it's worth mentioning that during the
implementation we should keep in mind that the user could
choose to use the application in "no skin" mode. In this
case however, we should keep the use of our extended
components (currently located in util.swing package).

"No skin" is a skin too. I suggest to make the "blue skin"
as a separate skin in themes/ directory and "no skin" also
as a separate skin, but only with skin information and
without style changes.

I think that's all for now. Excuse me if I'm missing
something.

Best regards, Yana

Best regards,

Adam Netočný Fel ČVUT Login: netocada

Hi, this is the first draft of design of the skinning
functionality. I can send RTF version if necessary.
Please take a look at it and send your comments.

Best regards

Adam Netočný Fel ČVUT Login: netocada

Hey Marian,

На 23.07.10 11:43, Marian Kechlibar написа:

Hello,

yes, that is correct, we're looking for ways how to
make SIP Communicator skinnable.

Well that depends on the level of customization that
you'd like to allow with skins. Changing icons and
colours would be fairly trivial since they are all
isolated in our resource bundle.

Having a skin modify the layout on the other hand
would be a completely different story.

I am not sure how easy is to do that, because I am
not a Java expert myself (well, sort of, in J2ME,
but not in Swing), that is why I asked Mr. Netocny
to delve into it. He would definitely appreciate
any comments and suggestions from the actual author
of the current GUI :slight_smile:

Mr. Netocny is going to prepare some preliminary
designs and post them here in a few days.

Great, looking forward to seeing them!

Emil

---------------------------------------------------------------------

To unsubscribe, e-mail:

dev-unsubscribe@sip-communicator.dev.java.net

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

<SIP Communicator Skin
Support.pdf>---------------------------------------------------------------------

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

---------------------------------------------------------------------

To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net

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

<skin.zip>---------------------------------------------------------------------

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

---------------------------------------------------------------------

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

···

On 08/09/2010 06:34 PM, Yana Stamcheva wrote:

On Aug 9, 2010, at 12:23 PM, Yana Stamcheva wrote:

On Aug 6, 2010, at 1:52 PM, Adam Netocny wrote:

On 08/05/2010 04:16 PM, Yana Stamcheva wrote:

On Jul 30, 2010, at 2:06 PM, Adam Netocny wrote:

On 07/30/2010 12:26 PM, Yana Stamcheva wrote:

On Jul 27, 2010, at 1:05 PM, Adam Netocny wrote:

On 07/25/2010 10:11 AM, Emil Ivov wrote:

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

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
SIP Communicator
emcho@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

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