[sip-comm-dev] GUI Skin

Emil Ivov emcho at sip-communicator.org
Mon Aug 9 21:52:40 CEST 2010


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,
> 
> 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?
>
> 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. ;)

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
>> 
>> 
>> 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 :)
>>>>> 
>>>>> 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  :-)
>>>>>>>>>> 
>>>>>>>>>> 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 at sip-communicator.dev.java.net
>>>>>>>>> 
>>>>>>>>> For additional commands, e-mail: 
>>>>>>>>> dev-help at sip-communicator.dev.java.net
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> <SIP Communicator Skin
>>>>>>>> Support.pdf>---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> 
To unsubscribe, e-mail:
>>>>>>>> dev-unsubscribe at sip-communicator.dev.java.net
>>>>>>>> 
>>>>>>>> For additional commands, e-mail: 
>>>>>>>> dev-help at sip-communicator.dev.java.net
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> 
To unsubscribe, e-mail:
>>>>>>> dev-unsubscribe at sip-communicator.dev.java.net
>>>>>>> 
>>>>>>> For additional commands, e-mail: 
>>>>>>> dev-help at sip-communicator.dev.java.net
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> 
To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>>>> For additional commands, e-mail:
>>>>> dev-help at sip-communicator.dev.java.net
>>>>> 
>>>>> 
>>>>> 
>>>> <skin.zip>---------------------------------------------------------------------
>>>>
>>>> 
To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>>> For additional commands, e-mail:
>>>> dev-help at sip-communicator.dev.java.net
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>>
>>> 
To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>>> For additional commands, e-mail:
>>> dev-help at sip-communicator.dev.java.net
>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>>
>> 
To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
>> For additional commands, e-mail:
>> dev-help at sip-communicator.dev.java.net
>> 
>> 
> 
> 
> ---------------------------------------------------------------------
>
> 
To unsubscribe, e-mail: dev-unsubscribe at sip-communicator.dev.java.net
> For additional commands, e-mail:
> dev-help at sip-communicator.dev.java.net

-- 
Emil Ivov, Ph.D.                               67000 Strasbourg,
Project Lead                                   France
SIP Communicator
emcho at 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 at sip-communicator.dev.java.net
For additional commands, e-mail: dev-help at sip-communicator.dev.java.net





More information about the dev mailing list