[sip-comm-dev] Re: [sc1.0-cvs] CVS update: /sip-communicator-1-0-draft/src/net/java/sip/communicator/impl/gui/main/


#1

Hey Yana,

Just saw the new icons and love them! Great work, really!

I've got a question though. How are we going to treat resources? I noticed that Yana (and most of us actually) are currently loading from a prespecified package specific location like:

+ public static final Image QUICK_MENU_SEARCH_ICON = LookAndFeelConstants
+ .loadImage("../resources/buttons/searchIcon.png");

It might be a good idea to agree on a convention about storing such binary data needed during runtime. The first thing that comes to mind is the FileAccessService. Alex, WDYT?

- mainFrame.setTitle("SIP Communicator");

OK, since it's not me writing the GUI, it's very easy to say that:
Ahem ... shouldn't we think about internationalization?

Now seriously, what do you think would be the best way to get strings like this one? Do we build an OSGI service or do we use some static container?

+ //In order to have the same icon when using option panes
+ JOptionPane.getRootFrame()
+ .setIconImage(LookAndFeelConstants.SIP_LOGO);

Hey this is a really nifty trick. I didn't know you could do that! Cool.

Emil

···

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


#2

Hi everyone,

I've not finished the documentation for the
FileAccessService, for which I appologize.. For this
service I was thinking more as a way to access the
file system - that is create/read/write/delete
temporary or persistent files. Maybe even a generic
"Open Files" dialog (for this it will have to work in
conjunction with the GUI). I think that resources are
a little bit out of the scope of this service. I agree
that there should be a (maybe a dedicated) service
addressing the issue with the resources -
ResourceSharingService, or ResourceService, or
ResourceManagementService..

On the internationalization - I think that generally
each bundle should handle his own strings. One can
think of an improvement - maybe an addition to the
Resource*Service which could provide
internationalization for some "popular" texts, like
"Hello World", "Two beers or not two beers", etc..

Regards,
Alex

···

--- Emil Ivov <emil_ivov@yahoo.com> wrote:

Hey Yana,

Just saw the new icons and love them! Great work,
really!

I've got a question though. How are we going to
treat resources? I
noticed that Yana (and most of us actually) are
currently loading from a
prespecified package specific location like:

> + public static final Image QUICK_MENU_SEARCH_ICON
= LookAndFeelConstants
> +
.loadImage("../resources/buttons/searchIcon.png");

It might be a good idea to agree on a convention
about storing such
binary data needed during runtime. The first thing
that comes to mind is
the FileAccessService. Alex, WDYT?

> - mainFrame.setTitle("SIP Communicator");

OK, since it's not me writing the GUI, it's very
easy to say that:
Ahem ... shouldn't we think about
internationalization?

Now seriously, what do you think would be the best
way to get strings
like this one? Do we build an OSGI service or do we
use some static
container?

> + //In order to have the same icon when using
option panes
> + JOptionPane.getRootFrame()
> +
.setIconImage(LookAndFeelConstants.SIP_LOGO);

Hey this is a really nifty trick. I didn't know you
could do that! Cool.

Emil

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

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

For this service I was thinking more as a way to access the file
system - that is create/read/write/delete temporary or persistent
files. I think that resources are a little bit out of the scope of this
service.

OK I see what you mean and I agree.

I agree that there should be a (maybe a dedicated) service addressing
the issue with the resources - ResourceSharingService, or
ResourceService, or ResourceManagementService..

24 hours after my original post I am beginning to actually doubt that :). In 90% of the cases a bundle would come with its own resources (icons, bitmaps or whatever ) and would be the only one using it. In order to get them through a ResourceService it would first have to register them ther and to do so it would have to access them ... So I wonder what good it would do.

There is, however, the case of a bundle that would need to export resources in order to make them accessible for others so the ResourceSharingService you mention is a good idea. We'd need some concrete use cases before (and if) we decide to go further with this one.

On the internationalization - I think that generally each bundle
should handle his own strings.

Agreed.

One can think of an improvement -
maybe an addition to the Resource*Service which could provide internationalization for some "popular" texts, like "Hello World",
"Two beers or not two beers", etc..

I was thinking about something that's more of a Locale manager. A bundle may come in with its own sets of strings but it would need a centralized way of determining which one to use. Yet maybe the simplest way to deal with that would be to do it the standard Java way. I've never really used it so I really have no idea how well it would fit our environment. WDYT?

I've written a small document describing the
functionality of the HistoryService along with a
simple example. It is not directly linked with the
protocols but will be used from the CallHistoryService
and MessageHistoryService to log call events and chat
messages.

Any comments on the design, the quality, the naming..
on everything are highly appreciated

I really like the way you've done it. I find the documentation a bit too abstract though. It would be great to add a few use case examples. I know that you are using the history service in the implementations of the call and message history services. Maybe you could add a paragraph or two explaining how you do it. Is that making any sense to you?

Cheers
Emil


#4

The following message was returned to me for I don't know what reason. I
am posting it back to the list so that we have it for the record.

···

========================================================================

For this service I was thinking more as a way to access the file
system - that is create/read/write/delete temporary or persistent
files. I think that resources are a little bit out of the scope of this
service.

OK I see what you mean and I agree.

I agree that there should be a (maybe a dedicated) service addressing
the issue with the resources - ResourceSharingService, or
ResourceService, or ResourceManagementService..

24 hours after my original post I am beginning to actually doubt that
:). In 90% of the cases a bundle would come with its own resources
(icons, bitmaps or whatever ) and would be the only one using it. In
order to get them through a ResourceService it would first have to
register them ther and to do so it would have to access them ... So I
wonder what good it would do.

There is, however, the case of a bundle that would need to export
resources in order to make them accessible for others so the
ResourceSharingService you mention is a good idea. We'd need some
concrete use cases before (and if) we decide to go further with this one.

On the internationalization - I think that generally each bundle
should handle his own strings.

Agreed.

One can think of an improvement -
maybe an addition to the Resource*Service which could provide internationalization for some "popular" texts, like "Hello World",
"Two beers or not two beers", etc..

I was thinking about something that's more of a Locale manager. A bundle
may come in with its own sets of strings but it would need a centralized
way of determining which one to use. Yet maybe the simplest way to deal
with that would be to do it the standard Java way. I've never really
used it so I really have no idea how well it would fit our environment.
   WDYT?

I've written a small document describing the
functionality of the HistoryService along with a
simple example. It is not directly linked with the
protocols but will be used from the CallHistoryService
and MessageHistoryService to log call events and chat
messages.

Any comments on the design, the quality, the naming..
on everything are highly appreciated

I really like the way you've done it. I find the documentation a bit too
abstract though. It would be great to add a few use case examples. I
know that you are using the history service in the implementations of
the call and message history services. Maybe you could add a paragraph
or two explaining how you do it. Is that making any sense to you?

Cheers
Emil

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