[sip-comm-dev] GUI Skin


#1

Hi,
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.

Cheers,
Adam Netočný

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

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.

Cheers,
Emil

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


#2

Hi Adam,

It's looking very good and it works great! Thanks! It's committed (revision: 7659) and ack-ed on our contributor's page.

While reviewing the patch, I've noticed that in the skin manager plugin you needed the same interface as the plugin manager, which is perfectly ok, however this made me thinking that we probably should export the plugin manager interface in some way, as we made with the sip account registration wizard for example. This way you won't need to copy all of the gui classes and could just provide the logic, when install button is pressed for example. Could you please give me an idea of the changes you've made over the original plugin manager classes?

Otherwise, I've tried to make a new skin, based on the one you provided, just by adding two colors in it and I keep getting the following message:

"Zip file doesn't contain all necessary files and folders."

I'm not getting an Exception, just the message. Do you have an idea?

Cheers,
Yana

···

On Aug 28, 2010, at 4:01 PM, Adam Netocny wrote:

Hi,
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.

Cheers,
Adam Netočný

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@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@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@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

<ResourceManagementService.patch><skin.zip><src.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


#3

Hi Yana,

Hi Adam,

It's looking very good and it works great! Thanks! It's committed (revision: 7659) and ack-ed on our contributor's page.

While reviewing the patch, I've noticed that in the skin manager plugin you needed the same interface as the plugin manager, which is perfectly ok, however this made me thinking that we probably should export the plugin manager interface in some way, as we made with the sip account registration wizard for example. This way you won't need to copy all of the gui classes and could just provide the logic, when install button is pressed for example. Could you please give me an idea of the changes you've made over the original plugin manager classes?
  

So here is a list of changes:
1. In the plug-in manager i've removed all bundles with
net.java.sip.communicator.plugin.skinresourcepack.SkinResourcesPack
activator.

2. In the skin manager:
    - Activate button: deactivate all other bundles and activate the
selected one.
    - Deactivate button: the same behavior as in the plug-in manager.
    - Uninstall button: the same behavior as in the plug-in manager.
    - New button: also the same behavior but there are some changes in
the dialog(Filter for zip files, Bundle creation, etc.).
    - Cell rendering: It retrieves information from info.properties file
and if this is not found then from manifest.
    - Show system bundles: removed.

That should be all.

Otherwise, I've tried to make a new skin, based on the one you provided, just by adding two colors in it and I keep getting the following message:

"Zip file doesn't contain all necessary files and folders."
  

The patch in the attachment should repair it. It is because
SkinJarBuilder checks the files/folders structure of the zip before it
continues and throws an exception when not all files are found. With
this patch in the zip file must be located the info.properties file and
at least one of these three files(colors/colors.properties,
images/images.properties, styles/styles.properties).

I'm not getting an Exception, just the message. Do you have an idea?

Cheers,
Yana

Cheers,
Adam

ResourceManagementService.patch (3.59 KB)

···

On 09/03/2010 01:12 AM, Yana Stamcheva wrote:

On Aug 28, 2010, at 4:01 PM, Adam Netocny wrote:

Hi,
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.

Cheers,
Adam Netočný

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@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@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@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

<ResourceManagementService.patch><skin.zip><src.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


#4

Hi Adam,

Hi Yana,

Hi Adam,

It's looking very good and it works great! Thanks! It's committed (revision: 7659) and ack-ed on our contributor's page.

While reviewing the patch, I've noticed that in the skin manager plugin you needed the same interface as the plugin manager, which is perfectly ok, however this made me thinking that we probably should export the plugin manager interface in some way, as we made with the sip account registration wizard for example. This way you won't need to copy all of the gui classes and could just provide the logic, when install button is pressed for example. Could you please give me an idea of the changes you've made over the original plugin manager classes?

So here is a list of changes:
1. In the plug-in manager i've removed all bundles with
net.java.sip.communicator.plugin.skinresourcepack.SkinResourcesPack
activator.

2. In the skin manager:
   - Activate button: deactivate all other bundles and activate the
selected one.
   - Deactivate button: the same behavior as in the plug-in manager.
   - Uninstall button: the same behavior as in the plug-in manager.
   - New button: also the same behavior but there are some changes in
the dialog(Filter for zip files, Bundle creation, etc.).
   - Cell rendering: It retrieves information from info.properties file
and if this is not found then from manifest.
   - Show system bundles: removed.

That should be all.

Thanks! I'll see how we could reuse the code and will come back to you with a suggestion:)

Otherwise, I've tried to make a new skin, based on the one you provided, just by adding two colors in it and I keep getting the following message:

"Zip file doesn't contain all necessary files and folders."

The patch in the attachment should repair it. It is because
SkinJarBuilder checks the files/folders structure of the zip before it
continues and throws an exception when not all files are found. With
this patch in the zip file must be located the info.properties file and
at least one of these three files(colors/colors.properties,
images/images.properties, styles/styles.properties).

Patch was committed in revision 7665.

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.

Otherwise I've noticed that the skinresources.jar isn't added in felix.client.run.properties, is this intentional?

Cheers,
Yana

···

On Sep 3, 2010, at 11:49 AM, Adam Netocny wrote:

On 09/03/2010 01:12 AM, Yana Stamcheva wrote:

I'm not getting an Exception, just the message. Do you have an idea?

Cheers,
Yana

Cheers,
Adam

On Aug 28, 2010, at 4:01 PM, Adam Netocny wrote:

Hi,
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.

Cheers,
Adam Netočný

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@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@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@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

<ResourceManagementService.patch><skin.zip><src.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

<ResourceManagementService.patch>---------------------------------------------------------------------
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


#5

Hi Yana,

Hi Adam,

Hi Yana,
    

Hi Adam,

It's looking very good and it works great! Thanks! It's committed (revision: 7659) and ack-ed on our contributor's page.

While reviewing the patch, I've noticed that in the skin manager plugin you needed the same interface as the plugin manager, which is perfectly ok, however this made me thinking that we probably should export the plugin manager interface in some way, as we made with the sip account registration wizard for example. This way you won't need to copy all of the gui classes and could just provide the logic, when install button is pressed for example. Could you please give me an idea of the changes you've made over the original plugin manager classes?

So here is a list of changes:
1. In the plug-in manager i've removed all bundles with
net.java.sip.communicator.plugin.skinresourcepack.SkinResourcesPack
activator.

2. In the skin manager:
   - Activate button: deactivate all other bundles and activate the
selected one.
   - Deactivate button: the same behavior as in the plug-in manager.
   - Uninstall button: the same behavior as in the plug-in manager.
   - New button: also the same behavior but there are some changes in
the dialog(Filter for zip files, Bundle creation, etc.).
   - Cell rendering: It retrieves information from info.properties file
and if this is not found then from manifest.
   - Show system bundles: removed.

That should be all.
    

Thanks! I'll see how we could reuse the code and will come back to you with a suggestion:)
  

Ok.

  

Otherwise, I've tried to make a new skin, based on the one you provided, just by adding two colors in it and I keep getting the following message:

"Zip file doesn't contain all necessary files and folders."

The patch in the attachment should repair it. It is because
SkinJarBuilder checks the files/folders structure of the zip before it
continues and throws an exception when not all files are found. With
this patch in the zip file must be located the info.properties file and
at least one of these three files(colors/colors.properties,
images/images.properties, styles/styles.properties).
    

Patch was committed in revision 7665.

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.
  

Working on it...

Otherwise I've noticed that the skinresources.jar isn't added in felix.client.run.properties, is this intentional?
  

Yes, cause it is only a template used by SkinJarBuilder class. It make a
copy and fill the new jar with resources from zip files ;).

Cheers,
Adam

···

On 09/03/2010 05:15 PM, Yana Stamcheva wrote:

On Sep 3, 2010, at 11:49 AM, Adam Netocny wrote:

On 09/03/2010 01:12 AM, Yana Stamcheva wrote:

Cheers,
Yana

I'm not getting an Exception, just the message. Do you have an idea?

Cheers,
Yana

Cheers,
Adam
    

On Aug 28, 2010, at 4:01 PM, Adam Netocny wrote:

Hi,
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.

Cheers,
Adam Netočný

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@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@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@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

<ResourceManagementService.patch><skin.zip><src.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

<ResourceManagementService.patch>---------------------------------------------------------------------
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


#6

Hi Yana,

Hi Adam,

Hi Yana,
    

Hi Adam,

It's looking very good and it works great! Thanks! It's committed (revision: 7659) and ack-ed on our contributor's page.

While reviewing the patch, I've noticed that in the skin manager plugin you needed the same interface as the plugin manager, which is perfectly ok, however this made me thinking that we probably should export the plugin manager interface in some way, as we made with the sip account registration wizard for example. This way you won't need to copy all of the gui classes and could just provide the logic, when install button is pressed for example. Could you please give me an idea of the changes you've made over the original plugin manager classes?

So here is a list of changes:
1. In the plug-in manager i've removed all bundles with
net.java.sip.communicator.plugin.skinresourcepack.SkinResourcesPack
activator.

2. In the skin manager:
   - Activate button: deactivate all other bundles and activate the
selected one.
   - Deactivate button: the same behavior as in the plug-in manager.
   - Uninstall button: the same behavior as in the plug-in manager.
   - New button: also the same behavior but there are some changes in
the dialog(Filter for zip files, Bundle creation, etc.).
   - Cell rendering: It retrieves information from info.properties file
and if this is not found then from manifest.
   - Show system bundles: removed.

That should be all.
    

Thanks! I'll see how we could reuse the code and will come back to you with a suggestion:)

Otherwise, I've tried to make a new skin, based on the one you provided, just by adding two colors in it and I keep getting the following message:

"Zip file doesn't contain all necessary files and folders."

The patch in the attachment should repair it. It is because
SkinJarBuilder checks the files/folders structure of the zip before it
continues and throws an exception when not all files are found. With
this patch in the zip file must be located the info.properties file and
at least one of these three files(colors/colors.properties,
images/images.properties, styles/styles.properties).
    

Patch was committed in revision 7665.

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.
  

So here is the patch for it.

Cheers,
Adam

ResourceManagementService.patch (3.17 KB)

···

On 09/03/2010 05:15 PM, Yana Stamcheva wrote:

On Sep 3, 2010, at 11:49 AM, Adam Netocny wrote:

On 09/03/2010 01:12 AM, Yana Stamcheva wrote:

Otherwise I've noticed that the skinresources.jar isn't added in felix.client.run.properties, is this intentional?

Cheers,
Yana

I'm not getting an Exception, just the message. Do you have an idea?

Cheers,
Yana

Cheers,
Adam
    

On Aug 28, 2010, at 4:01 PM, Adam Netocny wrote:

Hi,
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.

Cheers,
Adam Netočný

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@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@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@sip-communicator.org PHONE: +33.1.77.62.43.30
http://sip-communicator.org FAX: +33.1.77.62.47.31

<ResourceManagementService.patch><skin.zip><src.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

<ResourceManagementService.patch>---------------------------------------------------------------------
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


#7

Hi Adam,

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.

So here is the patch for it.

Cheers,
Adam

I applied the patch, however it didn't work for me. Actually when you call unzipIntoTmp(zip) it returns a tmp dir "zip7372711102709500921.tmp" and then in findBase, when you call tmpDir.listFiles(), the only file there would be the main skin directory (in my case "myskin") and not the info.properties. Is the unzipIntoTmp() method returning a directory with the name of the main dir for you?

Cheers,
Yana

···

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

Hi Adam,

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.

So here is the patch for it.

Cheers,
Adam
    

I applied the patch, however it didn't work for me. Actually when you call unzipIntoTmp(zip) it returns a tmp dir "zip7372711102709500921.tmp" and then in findBase, when you call tmpDir.listFiles(), the only file there would be the main skin directory (in my case "myskin") and not the info.properties. Is the unzipIntoTmp() method returning a directory with the name of the main dir for you?
  

For me in findBase it looks for info.properties and if it is not found
it moves to the main skin directory and return this one(as File). It
works for me, cause the call unzipIntoTmp(zip) creates something like this
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/myskin/
/tmp/zip1321123...445.tmp/myskin/info.properties
/tmp/zip1321123...445.tmp/myskin/...
or
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/info.properties
/tmp/zip1321123...445.tmp/...

findBase:
In the second case it finds the info.properties file and do nothing.
In the first cast the info.properties file is not found so it moves to
the myskin folder. Probably you have other directories in the
zip1232...13212.tmp dir which is not a valid skin structure.

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam

···

On 09/06/2010 12:38 PM, Yana Stamcheva wrote:

Cheers,
Yana

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

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


#9

Hi Adam,

Hi Yana,

Hi Adam,

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.

So here is the patch for it.

Cheers,
Adam

I applied the patch, however it didn't work for me. Actually when you call unzipIntoTmp(zip) it returns a tmp dir "zip7372711102709500921.tmp" and then in findBase, when you call tmpDir.listFiles(), the only file there would be the main skin directory (in my case "myskin") and not the info.properties. Is the unzipIntoTmp() method returning a directory with the name of the main dir for you?

For me in findBase it looks for info.properties and if it is not found
it moves to the main skin directory and return this one(as File). It
works for me, cause the call unzipIntoTmp(zip) creates something like this
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/myskin/
/tmp/zip1321123...445.tmp/myskin/info.properties
/tmp/zip1321123...445.tmp/myskin/...
or
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/info.properties
/tmp/zip1321123...445.tmp/...

findBase:
In the second case it finds the info.properties file and do nothing.
In the first cast the info.properties file is not found so it moves to
the myskin folder. Probably you have other directories in the
zip1232...13212.tmp dir which is not a valid skin structure.

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!

I've committed the patch in revision 7670.

Cheers,
Yana

···

On Sep 6, 2010, at 12:54 PM, Adam Netocny wrote:

On 09/06/2010 12:38 PM, Yana Stamcheva wrote:

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam

Cheers,
Yana

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

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

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

i've got 2 more questions:
Which repaint mechanism will you use for the skin repaint?
Do you already have any suggestions related to the skinmanager plug-in?

Cheers,
Adam

···

On 09/06/2010 01:20 PM, Yana Stamcheva wrote:

Hi Adam,

On Sep 6, 2010, at 12:54 PM, Adam Netocny wrote:

Hi Yana,

On 09/06/2010 12:38 PM, Yana Stamcheva wrote:
    

Hi Adam,

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.

So here is the patch for it.

Cheers,
Adam

I applied the patch, however it didn't work for me. Actually when you call unzipIntoTmp(zip) it returns a tmp dir "zip7372711102709500921.tmp" and then in findBase, when you call tmpDir.listFiles(), the only file there would be the main skin directory (in my case "myskin") and not the info.properties. Is the unzipIntoTmp() method returning a directory with the name of the main dir for you?

For me in findBase it looks for info.properties and if it is not found
it moves to the main skin directory and return this one(as File). It
works for me, cause the call unzipIntoTmp(zip) creates something like this
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/myskin/
/tmp/zip1321123...445.tmp/myskin/info.properties
/tmp/zip1321123...445.tmp/myskin/...
or
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/info.properties
/tmp/zip1321123...445.tmp/...

findBase:
In the second case it finds the info.properties file and do nothing.
In the first cast the info.properties file is not found so it moves to
the myskin folder. Probably you have other directories in the
zip1232...13212.tmp dir which is not a valid skin structure.
    

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!

I've committed the patch in revision 7670.

Cheers,
Yana

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam
    

Cheers,
Yana

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

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

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

Hey folks,

Hi Adam,

Hi Yana,

Hi Adam,

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.

So here is the patch for it.

Cheers,
Adam

I applied the patch, however it didn't work for me. Actually when you call unzipIntoTmp(zip) it returns a tmp dir "zip7372711102709500921.tmp" and then in findBase, when you call tmpDir.listFiles(), the only file there would be the main skin directory (in my case "myskin") and not the info.properties. Is the unzipIntoTmp() method returning a directory with the name of the main dir for you?

For me in findBase it looks for info.properties and if it is not found
it moves to the main skin directory and return this one(as File). It
works for me, cause the call unzipIntoTmp(zip) creates something like this
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/myskin/
/tmp/zip1321123...445.tmp/myskin/info.properties
/tmp/zip1321123...445.tmp/myskin/...
or
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/info.properties
/tmp/zip1321123...445.tmp/...

findBase:
In the second case it finds the info.properties file and do nothing.
In the first cast the info.properties file is not found so it moves to
the myskin folder. Probably you have other directories in the
zip1232...13212.tmp dir which is not a valid skin structure.
      

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!
    

I haven't been looking into the implementation so I am not really sure what the issue is, but doesn't this sound like something that we'd like to be handling more gracefully? It seems that users would easily end up in the same situation.
  

Alright i'll try to handle it.

Cheers,
Adam

···

On 09/06/2010 02:32 PM, Emil Ivov wrote:

On 6 sept. 2010, at 14:20, Yana Stamcheva <yana@sip-communicator.org> wrote:

On Sep 6, 2010, at 12:54 PM, Adam Netocny wrote:

On 09/06/2010 12:38 PM, Yana Stamcheva wrote:

Cheers,
Emil

--sent from my mobile
  

I've committed the patch in revision 7670.

Cheers,
Yana

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam
      

Cheers,
Yana

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

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

---------------------------------------------------------------------
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 Emil, Yana,

Hey folks,

Hi Adam,

Hi Yana,

Hi Adam,

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.

So here is the patch for it.

Cheers,
Adam

I applied the patch, however it didn't work for me. Actually when you call unzipIntoTmp(zip) it returns a tmp dir "zip7372711102709500921.tmp" and then in findBase, when you call tmpDir.listFiles(), the only file there would be the main skin directory (in my case "myskin") and not the info.properties. Is the unzipIntoTmp() method returning a directory with the name of the main dir for you?

For me in findBase it looks for info.properties and if it is not found
it moves to the main skin directory and return this one(as File). It
works for me, cause the call unzipIntoTmp(zip) creates something like this
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/myskin/
/tmp/zip1321123...445.tmp/myskin/info.properties
/tmp/zip1321123...445.tmp/myskin/...
or
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/info.properties
/tmp/zip1321123...445.tmp/...

findBase:
In the second case it finds the info.properties file and do nothing.
In the first cast the info.properties file is not found so it moves to
the myskin folder. Probably you have other directories in the
zip1232...13212.tmp dir which is not a valid skin structure.
      

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!
    

I haven't been looking into the implementation so I am not really sure what the issue is, but doesn't this sound like something that we'd like to be handling more gracefully? It seems that users would easily end up in the same situation.

Here is the patch for it. It handles both situations:
/tmp/zip45645...4565/myskin/myskin/myskin/.../info.properties

and

/tmp/zip45645...4565/myskin/
e.g.
/tmp/zip45645...4565/.DS_Store
/tmp/zip45645...4565/myskin/info.properties

Now it is searching for info.properties and moves to its parent dir.

+ JavaDoc correction.

Cheers,
Adam

ResourceManagementService.patch (6.29 KB)

···

On 09/06/2010 02:32 PM, Emil Ivov wrote:

On 6 sept. 2010, at 14:20, Yana Stamcheva <yana@sip-communicator.org> wrote:

On Sep 6, 2010, at 12:54 PM, Adam Netocny wrote:

On 09/06/2010 12:38 PM, Yana Stamcheva wrote:

Cheers,
Emil

--sent from my mobile
  

I've committed the patch in revision 7670.

Cheers,
Yana

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam
      

Cheers,
Yana

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

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

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

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!

I haven't been looking into the implementation so I am not really sure what the issue is, but doesn't this sound like something that we'd like to be handling more gracefully? It seems that users would easily end up in the same situation.

Here is the patch for it. It handles both situations:
/tmp/zip45645...4565/myskin/myskin/myskin/.../info.properties

and

/tmp/zip45645...4565/myskin/
e.g.
/tmp/zip45645...4565/.DS_Store
/tmp/zip45645...4565/myskin/info.properties

Now it is searching for info.properties and moves to its parent dir.

+ JavaDoc correction.

Thanks for the quick response! It's committed in revision 7671.

I've tested the patch and it solves the issue with many nested directories. However mine issue was coming from the fact, that I have a non-expected file in the zip (the .DS_Store file) and the test method would fail, because it's neither of the listed possible files. I think we should just skip unknown files, instead of returning false.

Something off topic, could you please change the SkinResourcesPack name to SkinResourcePack, just to be conform with other resource pack names.

Thanks!
Yana

···

Cheers,
Adam

Cheers,
Emil

--sent from my mobile

I've committed the patch in revision 7670.

Cheers,
Yana

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam

Cheers,
Yana

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

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

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

<ResourceManagementService.patch>---------------------------------------------------------------------
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

Hey Adam, Emil,

Hi Yana,

i've got 2 more questions:
Which repaint mechanism will you use for the skin repaint?

I'm also curious if we could use an existing repaint mechanism, as Emil suggested.

Do you already have any suggestions related to the skinmanager plug-in?

First I was thinking in the direction of exporting a plugin manager component, but then I realized that we don't really need the same user interface for the skin management. It's true that we'd use the install/uninstall bundle behind the scenes, but I think the user should have another vision of this.

One of the possibilities for the config interface is a list of skins (just thumbnail and name) and two buttons : Add and Remove. When selected we can show a preview of the skin and we can also have some additional configurations in the future. We can put a radio button, which would determine which skin should be used.

Another possibility is to have a combo box, with a last item "Add new skin...". Initially the combo box would contain only this item and when a skin is installed it would appear there. The selected skin would be the one to use and we could have a "Default skin" item for the default skin. In this case when selected the skin would be directly applied, so we won't need a preview here, but we could still have the additional configurations in the future.

In both cases, we won't need the Install dialog any more, we could directly show the file chooser on "Add".

So, WDYT?

Cheers,
Yana

···

On Sep 6, 2010, at 2:17 PM, Adam Netocny wrote:

Cheers,
Adam

On 09/06/2010 01:20 PM, Yana Stamcheva wrote:

Hi Adam,

On Sep 6, 2010, at 12:54 PM, Adam Netocny wrote:

Hi Yana,

On 09/06/2010 12:38 PM, Yana Stamcheva wrote:

Hi Adam,

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.

So here is the patch for it.

Cheers,
Adam

I applied the patch, however it didn't work for me. Actually when you call unzipIntoTmp(zip) it returns a tmp dir "zip7372711102709500921.tmp" and then in findBase, when you call tmpDir.listFiles(), the only file there would be the main skin directory (in my case "myskin") and not the info.properties. Is the unzipIntoTmp() method returning a directory with the name of the main dir for you?

For me in findBase it looks for info.properties and if it is not found
it moves to the main skin directory and return this one(as File). It
works for me, cause the call unzipIntoTmp(zip) creates something like this
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/myskin/
/tmp/zip1321123...445.tmp/myskin/info.properties
/tmp/zip1321123...445.tmp/myskin/...
or
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/info.properties
/tmp/zip1321123...445.tmp/...

findBase:
In the second case it finds the info.properties file and do nothing.
In the first cast the info.properties file is not found so it moves to
the myskin folder. Probably you have other directories in the
zip1232...13212.tmp dir which is not a valid skin structure.

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!

I've committed the patch in revision 7670.

Cheers,
Yana

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam

Cheers,
Yana

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

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

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

Hi Adam,

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!

I haven't been looking into the implementation so I am not really sure what the issue is, but doesn't this sound like something that we'd like to be handling more gracefully? It seems that users would easily end up in the same situation.

Here is the patch for it. It handles both situations:
/tmp/zip45645...4565/myskin/myskin/myskin/.../info.properties

and

/tmp/zip45645...4565/myskin/
e.g.
/tmp/zip45645...4565/.DS_Store
/tmp/zip45645...4565/myskin/info.properties

Now it is searching for info.properties and moves to its parent dir.

+ JavaDoc correction.
    

Thanks for the quick response! It's committed in revision 7671.

I've tested the patch and it solves the issue with many nested directories. However mine issue was coming from the fact, that I have a non-expected file in the zip (the .DS_Store file) and the test method would fail, because it's neither of the listed possible files. I think we should just skip unknown files, instead of returning false.
  

Ok, i'll do that.

Something off topic, could you please change the SkinResourcesPack name to SkinResourcePack, just to be conform with other resource pack names.
  

Right.

Cheers,
Adam

···

On 09/07/2010 02:08 PM, Yana Stamcheva wrote:

Thanks!
Yana

Cheers,
Adam
    

Cheers,
Emil

--sent from my mobile

I've committed the patch in revision 7670.

Cheers,
Yana

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam

Cheers,
Yana

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

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

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

<ResourceManagementService.patch>---------------------------------------------------------------------
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 Yana,

Hey Adam, Emil,

Hi Yana,

i've got 2 more questions:
Which repaint mechanism will you use for the skin repaint?
    

I'm also curious if we could use an existing repaint mechanism, as Emil suggested.

Indeed, already working on it with Emil.

Do you already have any suggestions related to the skinmanager plug-in?
    

First I was thinking in the direction of exporting a plugin manager component, but then I realized that we don't really need the same user interface for the skin management. It's true that we'd use the install/uninstall bundle behind the scenes, but I think the user should have another vision of this.

One of the possibilities for the config interface is a list of skins (just thumbnail and name) and two buttons : Add and Remove. When selected we can show a preview of the skin and we can also have some additional configurations in the future. We can put a radio button, which would determine which skin should be used.

Another possibility is to have a combo box, with a last item "Add new skin...". Initially the combo box would contain only this item and when a skin is installed it would appear there. The selected skin would be the one to use and we could have a "Default skin" item for the default skin. In this case when selected the skin would be directly applied, so we won't need a preview here, but we could still have the additional configurations in the future.

In both cases, we won't need the Install dialog any more, we could directly show the file chooser on "Add".

So, WDYT?

Cheers,
Yana

I thing that the second one is better. Previews will be time consuming
for both, us and users. And better is to show the skin on UI and not in
preview. But: Do you want to show the bundles as system bundles in
plugin manager? If yes then they should be all active and then we need a
new loading mechanism. If not then how will they be activated. Or am I
wrong?

Cheers,
Adam

···

On 09/07/2010 02:40 PM, Yana Stamcheva wrote:

On Sep 6, 2010, at 2:17 PM, Adam Netocny wrote:

Cheers,
Adam

On 09/06/2010 01:20 PM, Yana Stamcheva wrote:
    

Hi Adam,

On Sep 6, 2010, at 12:54 PM, Adam Netocny wrote:

Hi Yana,

On 09/06/2010 12:38 PM, Yana Stamcheva wrote:

Hi Adam,

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.

So here is the patch for it.

Cheers,
Adam

I applied the patch, however it didn't work for me. Actually when you call unzipIntoTmp(zip) it returns a tmp dir "zip7372711102709500921.tmp" and then in findBase, when you call tmpDir.listFiles(), the only file there would be the main skin directory (in my case "myskin") and not the info.properties. Is the unzipIntoTmp() method returning a directory with the name of the main dir for you?

For me in findBase it looks for info.properties and if it is not found
it moves to the main skin directory and return this one(as File). It
works for me, cause the call unzipIntoTmp(zip) creates something like this
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/myskin/
/tmp/zip1321123...445.tmp/myskin/info.properties
/tmp/zip1321123...445.tmp/myskin/...
or
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/info.properties
/tmp/zip1321123...445.tmp/...

findBase:
In the second case it finds the info.properties file and do nothing.
In the first cast the info.properties file is not found so it moves to
the myskin folder. Probably you have other directories in the
zip1232...13212.tmp dir which is not a valid skin structure.

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!

I've committed the patch in revision 7670.

Cheers,
Yana

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam

Cheers,
Yana

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

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

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


#17

Hi Yana,

Hey Adam, Emil,

Hi Yana,

i've got 2 more questions:
Which repaint mechanism will you use for the skin repaint?

I'm also curious if we could use an existing repaint mechanism, as Emil suggested.

Indeed, already working on it with Emil.

Ah, great! Good luck then:)

Do you already have any suggestions related to the skinmanager plug-in?

First I was thinking in the direction of exporting a plugin manager component, but then I realized that we don't really need the same user interface for the skin management. It's true that we'd use the install/uninstall bundle behind the scenes, but I think the user should have another vision of this.

One of the possibilities for the config interface is a list of skins (just thumbnail and name) and two buttons : Add and Remove. When selected we can show a preview of the skin and we can also have some additional configurations in the future. We can put a radio button, which would determine which skin should be used.

Another possibility is to have a combo box, with a last item "Add new skin...". Initially the combo box would contain only this item and when a skin is installed it would appear there. The selected skin would be the one to use and we could have a "Default skin" item for the default skin. In this case when selected the skin would be directly applied, so we won't need a preview here, but we could still have the additional configurations in the future.

In both cases, we won't need the Install dialog any more, we could directly show the file chooser on "Add".

So, WDYT?

Cheers,
Yana

I thing that the second one is better. Previews will be time consuming
for both, us and users. And better is to show the skin on UI and not in
preview. But: Do you want to show the bundles as system bundles in
plugin manager? If yes then they should be all active and then we need a
new loading mechanism. If not then how will they be activated. Or am I
wrong?

I have some preferences for the second too:)

Otherwise, yes, I would prefer that they're visible in the plugin manager. If we say that each time we install a new skin it becomes the one applied, then when installed we could deactivate all other skins. If user would like to change to an existing skin, then on user select we would deactivate the current one and activate the newly selected one. We should of course have a BundleListener in order to be notified for changes made through the plugin manager. WDYT?

Cheers,
Yana

···

On Sep 7, 2010, at 5:48 PM, Adam Netocny wrote:

On 09/07/2010 02:40 PM, Yana Stamcheva wrote:

On Sep 6, 2010, at 2:17 PM, Adam Netocny wrote:

Cheers,
Adam

Cheers,
Adam

On 09/06/2010 01:20 PM, Yana Stamcheva wrote:

Hi Adam,

On Sep 6, 2010, at 12:54 PM, Adam Netocny wrote:

Hi Yana,

On 09/06/2010 12:38 PM, Yana Stamcheva wrote:

Hi Adam,

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.

So here is the patch for it.

Cheers,
Adam

I applied the patch, however it didn't work for me. Actually when you call unzipIntoTmp(zip) it returns a tmp dir "zip7372711102709500921.tmp" and then in findBase, when you call tmpDir.listFiles(), the only file there would be the main skin directory (in my case "myskin") and not the info.properties. Is the unzipIntoTmp() method returning a directory with the name of the main dir for you?

For me in findBase it looks for info.properties and if it is not found
it moves to the main skin directory and return this one(as File). It
works for me, cause the call unzipIntoTmp(zip) creates something like this
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/myskin/
/tmp/zip1321123...445.tmp/myskin/info.properties
/tmp/zip1321123...445.tmp/myskin/...
or
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/info.properties
/tmp/zip1321123...445.tmp/...

findBase:
In the second case it finds the info.properties file and do nothing.
In the first cast the info.properties file is not found so it moves to
the myskin folder. Probably you have other directories in the
zip1232...13212.tmp dir which is not a valid skin structure.

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!

I've committed the patch in revision 7670.

Cheers,
Yana

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam

Cheers,
Yana

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

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

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

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

Hi Yana,
  

Hi Adam,

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!

I haven't been looking into the implementation so I am not really sure what the issue is, but doesn't this sound like something that we'd like to be handling more gracefully? It seems that users would easily end up in the same situation.

Here is the patch for it. It handles both situations:
/tmp/zip45645...4565/myskin/myskin/myskin/.../info.properties

and

/tmp/zip45645...4565/myskin/
e.g.
/tmp/zip45645...4565/.DS_Store
/tmp/zip45645...4565/myskin/info.properties

Now it is searching for info.properties and moves to its parent dir.

+ JavaDoc correction.
    

Thanks for the quick response! It's committed in revision 7671.

I've tested the patch and it solves the issue with many nested directories. However mine issue was coming from the fact, that I have a non-expected file in the zip (the .DS_Store file) and the test method would fail, because it's neither of the listed possible files. I think we should just skip unknown files, instead of returning false.
  

Ok, i'll do that.
  

Something off topic, could you please change the SkinResourcesPack name to SkinResourcePack, just to be conform with other resource pack names.
  

Right.
  

I've prepared a bigger patch with many changes:
1. Firstly it removes all described problems in these thread(Repaint
mechanism, renames SkinResourcesPack, non-expected file in the zip).
2. It also implements changes described in the thread "skinresources.jar
as a resource (or not)". Files form skinresources.jar are added into
defaultresources.jar and are loaded into new jar files. In that case I
had to manually format the manifest file, but it is working well (nr. 4.).
3. It also removes the filter from plug-in manager.

The repaint mechanism is using a changed implementation of
SwingUtilities.updateComponentTreeUI(Component c) for now, because there
are some issues i have to discuss with Emil.

Cheers,
Adam

ResourceManagementService.patch (19.3 KB)

src.zip (3.21 KB)

···

On 09/07/2010 02:13 PM, Adam Netocny wrote:

On 09/07/2010 02:08 PM, Yana Stamcheva wrote:
Cheers,
Adam
  

Thanks!
Yana

Cheers,
Adam
    

Cheers,
Emil

--sent from my mobile

I've committed the patch in revision 7670.

Cheers,
Yana

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam

Cheers,
Yana

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

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

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

<ResourceManagementService.patch>---------------------------------------------------------------------
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,

Hi Yana,
    

Hey Adam, Emil,

Hi Yana,

i've got 2 more questions:
Which repaint mechanism will you use for the skin repaint?

I'm also curious if we could use an existing repaint mechanism, as Emil suggested.

Indeed, already working on it with Emil.
    

Ah, great! Good luck then:)

Do you already have any suggestions related to the skinmanager plug-in?

First I was thinking in the direction of exporting a plugin manager component, but then I realized that we don't really need the same user interface for the skin management. It's true that we'd use the install/uninstall bundle behind the scenes, but I think the user should have another vision of this.

One of the possibilities for the config interface is a list of skins (just thumbnail and name) and two buttons : Add and Remove. When selected we can show a preview of the skin and we can also have some additional configurations in the future. We can put a radio button, which would determine which skin should be used.

Another possibility is to have a combo box, with a last item "Add new skin...". Initially the combo box would contain only this item and when a skin is installed it would appear there. The selected skin would be the one to use and we could have a "Default skin" item for the default skin. In this case when selected the skin would be directly applied, so we won't need a preview here, but we could still have the additional configurations in the future.

In both cases, we won't need the Install dialog any more, we could directly show the file chooser on "Add".

So, WDYT?

Cheers,
Yana

I thing that the second one is better. Previews will be time consuming
for both, us and users. And better is to show the skin on UI and not in
preview. But: Do you want to show the bundles as system bundles in
plugin manager? If yes then they should be all active and then we need a
new loading mechanism. If not then how will they be activated. Or am I
wrong?
    

I have some preferences for the second too:)

Otherwise, yes, I would prefer that they're visible in the plugin manager. If we say that each time we install a new skin it becomes the one applied, then when installed we could deactivate all other skins. If user would like to change to an existing skin, then on user select we would deactivate the current one and activate the newly selected one. We should of course have a BundleListener in order to be notified for changes made through the plugin manager. WDYT?

Cheers,
Yana

I've send you a patch minutes ago. It handles all problems except this
one. :wink:

So I agree, but can you explain for me what you mean under "We should of
course have a BundleListener in order to be notified". Were should it be
located? How can it protect us from selecting multiple skins? etc...

Thanks.

Cheers,
Adam

···

On 09/07/2010 06:33 PM, Yana Stamcheva wrote:

On Sep 7, 2010, at 5:48 PM, Adam Netocny wrote:

On 09/07/2010 02:40 PM, Yana Stamcheva wrote:

On Sep 6, 2010, at 2:17 PM, Adam Netocny wrote:

Cheers,
Adam
    

Cheers,
Adam

On 09/06/2010 01:20 PM, Yana Stamcheva wrote:

Hi Adam,

On Sep 6, 2010, at 12:54 PM, Adam Netocny wrote:

Hi Yana,

On 09/06/2010 12:38 PM, Yana Stamcheva wrote:

Hi Adam,

After applying the patch, the problem was persisting on my side and after some debugging I found that the issue was caused by me including the parent directory in the zip. My fault, I'm wondering though if we shouldn't handle this case too.

So here is the patch for it.

Cheers,
Adam

I applied the patch, however it didn't work for me. Actually when you call unzipIntoTmp(zip) it returns a tmp dir "zip7372711102709500921.tmp" and then in findBase, when you call tmpDir.listFiles(), the only file there would be the main skin directory (in my case "myskin") and not the info.properties. Is the unzipIntoTmp() method returning a directory with the name of the main dir for you?

For me in findBase it looks for info.properties and if it is not found
it moves to the main skin directory and return this one(as File). It
works for me, cause the call unzipIntoTmp(zip) creates something like this
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/myskin/
/tmp/zip1321123...445.tmp/myskin/info.properties
/tmp/zip1321123...445.tmp/myskin/...
or
/tmp/zip1321123...445.tmp/
/tmp/zip1321123...445.tmp/info.properties
/tmp/zip1321123...445.tmp/...

findBase:
In the second case it finds the info.properties file and do nothing.
In the first cast the info.properties file is not found so it moves to
the myskin folder. Probably you have other directories in the
zip1232...13212.tmp dir which is not a valid skin structure.

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!

I've committed the patch in revision 7670.

Cheers,
Yana

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam

Cheers,
Yana

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

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

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

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

Hi Adam,

I've applied locally your patch, but I've noticed a java6 dependency in UIServiceImpl, that we should get rid of, before committing. In repaintUITree you're calling:

Window.getWindows()

which is defined in java 6 for the first time. We're still trying to be java 1.5 compatible, so we should try to replace this one by its java 5 analog. I see we had Frame.getFrames(), but it won't return Dialogs. Otherwise, I've had a look to the implementation of getWindows() method and it appears that it just obtains the Window.class references from the application context. It still uses some private methods though, so this would require further investigation.

Cheers,
Yana

···

On Sep 8, 2010, at 4:26 PM, Adam Netocny wrote:

Hi Yana,
On 09/07/2010 02:13 PM, Adam Netocny wrote:

Hi Yana,
On 09/07/2010 02:08 PM, Yana Stamcheva wrote:

Hi Adam,

Yep, I had a .DS_Store file, which was probably added by MacOSX, when unzipping the initial skin. It works now after removing it. Thanks!

I haven't been looking into the implementation so I am not really sure what the issue is, but doesn't this sound like something that we'd like to be handling more gracefully? It seems that users would easily end up in the same situation.

Here is the patch for it. It handles both situations:
/tmp/zip45645...4565/myskin/myskin/myskin/.../info.properties

and

/tmp/zip45645...4565/myskin/
e.g.
/tmp/zip45645...4565/.DS_Store
/tmp/zip45645...4565/myskin/info.properties

Now it is searching for info.properties and moves to its parent dir.

+ JavaDoc correction.

Thanks for the quick response! It's committed in revision 7671.

I've tested the patch and it solves the issue with many nested directories. However mine issue was coming from the fact, that I have a non-expected file in the zip (the .DS_Store file) and the test method would fail, because it's neither of the listed possible files. I think we should just skip unknown files, instead of returning false.

Ok, i'll do that.

Something off topic, could you please change the SkinResourcesPack name to SkinResourcePack, just to be conform with other resource pack names.

Right.

I've prepared a bigger patch with many changes:
1. Firstly it removes all described problems in these thread(Repaint
mechanism, renames SkinResourcesPack, non-expected file in the zip).
2. It also implements changes described in the thread "skinresources.jar
as a resource (or not)". Files form skinresources.jar are added into
defaultresources.jar and are loaded into new jar files. In that case I
had to manually format the manifest file, but it is working well (nr. 4.).
3. It also removes the filter from plug-in manager.

The repaint mechanism is using a changed implementation of
SwingUtilities.updateComponentTreeUI(Component c) for now, because there
are some issues i have to discuss with Emil.

Cheers,
Adam

Cheers,
Adam

Thanks!
Yana

Cheers,
Adam

Cheers,
Emil

--sent from my mobile

I've committed the patch in revision 7670.

Cheers,
Yana

P.S. I'm on Ubuntu Linux x86_x64 10.04 Lucid...

Cheers,
Adam

Cheers,
Yana

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

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

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

<ResourceManagementService.patch>---------------------------------------------------------------------
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

<ResourceManagementService.patch><src.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