i've finished the skin manager configuration form and have corrected
some issues from the last version I've send. In the attachment is the
new patch, src.zip with new files and empty template skin which can be
installed in the config form.
after longer conversation with Emil we have considered to do it in this
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
Emil: In the attachment is the patch which change the
ResourcesManagementService and few new classes.
Dňa 12.8.2010, o 14:36, Emil Ivov <email@example.com> napísal:
На 11.08.10 16:14, Adam Netocny написа:
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 <firstname.lastname@example.org> napísal:
На 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
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,
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.
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?
ResourceManagementService.patch (15.6 KB)
skin.zip (861 Bytes)
src.zip (19.5 KB)
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.