Fwd: Re: [sip-comm-dev] GUI Skin

Adam Netocny netocny at gmail.com
Thu Aug 26 20:50:50 CEST 2010


Hi everyone,

after longer conversation with Emil we have considered to do it in this
way:
We will integrate the skin loading and unloading into the
ResourcesManagementService. Each skin will be a standalone
bundle(ResourcePack service). The loaded "SkinPack" will replace any
subset of properties defined in defaultresources.jar. To be
user-friendly users will have the chance to install zip files containing
skin date. The installer assistant will build the jar file from a
template class and these compressed files so the sip communicator will
be able to install it in OSGi.
For now we stay by properties files. After first results we will switch
to XML.

Emil: In the attachment is the patch which change the
ResourcesManagementService and few new classes.

Cheers,
Adam

Hi Emil,

Dňa 12.8.2010, o 14:36, Emil Ivov <emcho at sip-communicator.org> napísal:

> Hey Adam,
> 
> На 11.08.10 16:14, Adam Netocny написа:
>> Hi Emil,
>> 
>> sorry for a late response, but gmail has some problems today.
> 
> No worries, I've been travelling myself and have sporadic access to mail.
> 
>> Dňa 11.8.2010, o 13:34, Emil Ivov <emcho at sip-communicator.org> napísal:
>> 
>>> Hey Adam,
>>> 
>>> На 11.08.10 10:56, Adam Netocny написа:
>>>>> 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?
>>>>> 
>>>>> 
>>>> Our SkinManager has a SkinInstaller class which handles all new themes
>>>> as single zip file. So if I want to make the skin available for download
>>>> I only have to pack it into single zip 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 don't want to rewrite it entirely. Skin is a package with style
>>>> information, images, etc. The ResourcesManagerService handles all these
>>>> data but also config files, sounds etc. Our SkinManager handles for now
>>>> only style information stored as XML and the next task will be to write
>>>> a kind of resources management. In this case it would be great if we can
>>>> integrate the Res...Service into our code. And I think I've also
>>>> answered the next note.
>>> 
>>> I am having a doubt here and I was wondering whether you could clear it
>>> out for me before we continue.
>>> 
>>> I was wondering what the purpose of this discussion was. I was under the
>>> impression that you wanted our feedback as to what would be the approach
>>> that would best fit our architecture when designing a skinning
>>> mechanism. I was also thinking that you'd be interested in having that
>>> mechanism integrated in the project, which is something we are also very
>>> interested in. In that sense what I was trying to explain is that SIP
>>> Communicator has a resource management service and any skinning
>>> mechanism would obviously need to be based on that service rather than
>>> start from scratch. This is essential.
>> 
>> Yes that is right. Our company want to contribute on this project 
> 
> OK, this is great.
> 
>> and in
>> that way that we make the sip communicator real skinable. So lets
>> clarify what we want to do:
>> 
>> There is ResourcesManagementService. It is able to load resources from
>> defaultresources.jar. So if we want to make it skinable, we need a
>> little bit newer implementation based on ResourcesManagementService.
> 
> Great again. Then could you please send to dev a patch that modifies the
> resources management service without introducing the extra layer of
> resource management that your skin manager represents? If we are
> integrating skin management then it HAS TO be reusing the resource
> management service and the resource pack notions.
> 
Yes, I'm working on that. I was traveling last days so sorry for that late response. I try to implement it as soon as possible. One more question:
I want to change the default structure of the resources dir so that old resources will be located in a default dir e.g. /images/default and the new one in dirs related to the skin name. Then if I want to load a picture the resources service will be looking in dirs for selected skin and if it will not be found it will take the default one. So is this idea good or do you have any other ideas?
And one last question: If we take that idea are there any possibilities to "upload" files(dirs) into defaultresources.jar?

Cheers,

Adam
> We can either send you more detailed design guidelines in the following
> days, or you and I can have a chat on the phone to speed things up. What
> do you prefer?
> 
> Note that I completely see how it is easier for you to come up with your
> own design but we cannot duplicate or replace existing modules of SIP
> Communicator, for that sole reason. Hope you understand this and I very
> much appreciate your effort.
> 
> Cheers,
> Emil
> 
> 
> -- 
> 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ResourceManagementService.patch
Type: text/x-patch
Size: 6061 bytes
Desc: not available
URL: <http://lists.jitsi.org/pipermail/dev/attachments/20100826/5cbbb143/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new_classes.zip
Type: application/zip
Size: 6918 bytes
Desc: not available
URL: <http://lists.jitsi.org/pipermail/dev/attachments/20100826/5cbbb143/attachment.zip>
-------------- next part --------------
---------------------------------------------------------------------
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