Discussion:
[gui-dev] Wishlist item: Console tab
Tero Parviainen
2005-06-08 15:14:03 UTC
Permalink
Hello,

I'm interested in implementing the Console tab feature
on your wish list. I have a few years of experience in
Java development, but that is 100% J2EE, so I've never
really done anything on the client side. I've also
never participated in an open source project. I've got
a copy of the Limewire source tree and it looks like a
good project to start with, as it seems to be
structured and documented quite well. I've also been a
user of the program for years now. This task would be
great to get me started as I'm well experienced with
log4j.

A few questions:
- Firstly, a general issue: How do you usually handle
wishlist items, should I just create a patch and post
it in JIRA, or maybe mail it to ***@limewire.org
?
About the actual implementation:
- By "Console tab" do you mean just a normal tab like
connections, monitor etc? Should this tab be visible
by default?
- I think the most straightforward way to get to the
data would be to just implement a log4j Appender and
plug that into the log4j Logger repository. How does
this approach sound to you?
- What kind of features should the console view have
UI-wise? I'm thinking of at least having a possibility
to change the output treshold and manually clear the
log.

Thank you,

Tero Parviainen

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Sam Berlin
2005-06-08 15:25:02 UTC
Permalink
Hi Tero,

I believe that the Console Tab is being worked on by Ryan Keppel. I'm
not sure of his current progress on it. You may want to contact him at
rkeppel -at- usa -dot- net.

The easiest way for us to handle patches is to send them to
***@limewire.org. As far as the implementation goes... Yes, the
tab would be a normal tab like 'connections', 'monitor', etc... It
would not be visible by default. No shipping version of LimeWire
contains log4j (we stub out the logger using common's logging's
NoOpLog). It might be better to implement the logging as a different
commons logging logger, offering its own set of options. However,
using log4j might be best in the case where log4j _is_ present.

For the UI, the two most important things are the ability to pick which
loggers are currently logging & the threshold they're logging at (both
changeable at runtime).

Thanks,
Sam
Post by Tero Parviainen
Hello,
I'm interested in implementing the Console tab feature
on your wish list. I have a few years of experience in
Java development, but that is 100% J2EE, so I've never
really done anything on the client side. I've also
never participated in an open source project. I've got
a copy of the Limewire source tree and it looks like a
good project to start with, as it seems to be
structured and documented quite well. I've also been a
user of the program for years now. This task would be
great to get me started as I'm well experienced with
log4j.
- Firstly, a general issue: How do you usually handle
wishlist items, should I just create a patch and post
?
- By "Console tab" do you mean just a normal tab like
connections, monitor etc? Should this tab be visible
by default?
- I think the most straightforward way to get to the
data would be to just implement a log4j Appender and
plug that into the log4j Logger repository. How does
this approach sound to you?
- What kind of features should the console view have
UI-wise? I'm thinking of at least having a possibility
to change the output treshold and manually clear the
log.
Thank you,
Tero Parviainen
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
Philippe VERDY
2005-06-08 20:51:28 UTC
Permalink
The console tab, like the Connection tabs, is probably not vital to most Limewire users that don't care about the tricky details.
It's probably true as well of the probably less needed search monitor.
So why not merging the log view with one of these two? If we want to keep the interface simple, we should avoid multiplying the number of tabs, and so use the same merged layout as used in the combined Search/Downloads tab.
Further improvements (and interface complications) however are most probably needed for the Library tab.
Message du 08/06/05 17:25
Objet : Re: [gui-dev] Wishlist item: Console tab
Hi Tero,
I believe that the Console Tab is being worked on by Ryan Keppel. I'm
not sure of his current progress on it. You may want to contact him at
rkeppel -at- usa -dot- net.
The easiest way for us to handle patches is to send them to
tab would be a normal tab like 'connections', 'monitor', etc... It
would not be visible by default. No shipping version of LimeWire
contains log4j (we stub out the logger using common's logging's
NoOpLog). It might be better to implement the logging as a different
commons logging logger, offering its own set of options. However,
using log4j might be best in the case where log4j _is_ present.
For the UI, the two most important things are the ability to pick which
loggers are currently logging & the threshold they're logging at (both
changeable at runtime).
Thanks,
Sam
Post by Tero Parviainen
Hello,
I'm interested in implementing the Console tab feature
on your wish list. I have a few years of experience in
Java development, but that is 100% J2EE, so I've never
really done anything on the client side. I've also
never participated in an open source project. I've got
a copy of the Limewire source tree and it looks like a
good project to start with, as it seems to be
structured and documented quite well. I've also been a
user of the program for years now. This task would be
great to get me started as I'm well experienced with
log4j.
- Firstly, a general issue: How do you usually handle
wishlist items, should I just create a patch and post
?
- By "Console tab" do you mean just a normal tab like
connections, monitor etc? Should this tab be visible
by default?
- I think the most straightforward way to get to the
data would be to just implement a log4j Appender and
plug that into the log4j Logger repository. How does
this approach sound to you?
- What kind of features should the console view have
UI-wise? I'm thinking of at least having a possibility
to change the output treshold and manually clear the
log.
Thank you,
Tero Parviainen
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
Justin Schmidt
2005-06-08 21:03:47 UTC
Permalink
Since the Console tab will not be shown by default, it is not critical
for it to be combined with anything else. No need to cross that bridge
before we come to it!

The Library tab has been undergoing massive renovations for the next
release. (See the "savelocation" branches.) They're a little unstable
right now, but the current mainline has many of these fixes already.

Justin
Post by Philippe VERDY
The console tab, like the Connection tabs, is probably not vital to
most Limewire users that don't care about the tricky details.
It's probably true as well of the probably less needed search monitor.
So why not merging the log view with one of these two? If we want to
keep the interface simple, we should avoid multiplying the number of
tabs, and so use the same merged layout as used in the combined
Search/Downloads tab.
Further improvements (and interface complications) however are most
probably needed for the Library tab.
Message du 08/06/05 17:25
Objet : Re: [gui-dev] Wishlist item: Console tab
Hi Tero,
I believe that the Console Tab is being worked on by Ryan Keppel. I'm
not sure of his current progress on it. You may want to contact him at
rkeppel -at- usa -dot- net.
The easiest way for us to handle patches is to send them to
tab would be a normal tab like 'connections', 'monitor', etc... It
would not be visible by default. No shipping version of LimeWire
contains log4j (we stub out the logger using common's logging's
NoOpLog). It might be better to implement the logging as a different
commons logging logger, offering its own set of options. However,
using log4j might be best in the case where log4j _is_ present.
For the UI, the two most important things are the ability to pick which
loggers are currently logging & the threshold they're logging at (both
changeable at runtime).
Thanks,
Sam
Post by Tero Parviainen
Hello,
I'm interested in implementing the Console tab feature
on your wish list. I have a few years of experience in
Java development, but that is 100% J2EE, so I've never
really done anything on the client side. I've also
never participated in an open source project. I've got
a copy of the Limewire source tree and it looks like a
good project to start with, as it seems to be
structured and documented quite well. I've also been a
user of the program for years now. This task would be
great to get me started as I'm well experienced with
log4j.
- Firstly, a general issue: How do you usually handle
wishlist items, should I just create a patch and post
?
- By "Console tab" do you mean just a normal tab like
connections, monitor etc? Should this tab be visible
by default?
- I think the most straightforward way to get to the
data would be to just implement a log4j Appender and
plug that into the log4j Logger repository. How does
this approach sound to you?
- What kind of features should the console view have
UI-wise? I'm thinking of at least having a possibility
to change the output treshold and manually clear the
log.
Thank you,
Tero Parviainen
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
Philippe Verdy
2005-06-09 16:22:43 UTC
Permalink
Warning: with the recent additions in the messages bundle, a significant
number of languages are now under the existing release threshold of 65%.

This may affect the following languages which were bundled until now:
Catalan (64.52%), Hungarian (62.35%), Icelandic (62.85%), Polish (61.85%),
Simplified Chinese (63.27%).

Some new resources may be translated nearly automatically from other
existing translated resources because they are obvious (sometimes this is a
minor change of format for a specific message). But I don't have the time to
review them for now and reincrease their level.

Note also that Portuguese (65.11%) and Traditional Chinese (65.03%) are just
a little bit above the current threshold and may also be affected very soon.

The recent Serbian-Latin (51.50%) contribution was still not at the release
threshold.

If Limewire estimates that these additions are not much critical for most
users, the solution will be to decrease the current release threshold from
65% to 60% (but the Polish translation at 61.85% will still need updates
soon).

So there should be new calls to contributors in the support forums, and on
the home page... And some incitations given to significant contributors that
will produce more than about 15% of progress for a wanted language).

Thanks.

Philippe.
Ryan Keppel
2005-06-09 16:51:57 UTC
Permalink
65% seems a bit arbitrary. Certainly there are more important messages that
could be weighted higher. But that would get quite complex.

------ Original Message ------
Received: Thu, 09 Jun 2005 09:23:35 AM PDT
From: "Philippe Verdy" <***@wanadoo.fr>
To: "Justin Schmidt" <***@limewire.com>, <***@gui.limewire.org>Cc:
Subject: [gui-dev] Locales Warning
Post by Philippe Verdy
Warning: with the recent additions in the messages bundle, a significant
number of languages are now under the existing release threshold of 65%.
Catalan (64.52%), Hungarian (62.35%), Icelandic (62.85%), Polish (61.85%),
Simplified Chinese (63.27%).
Some new resources may be translated nearly automatically from other
existing translated resources because they are obvious (sometimes this is a
minor change of format for a specific message). But I don't have the time to
review them for now and reincrease their level.
Note also that Portuguese (65.11%) and Traditional Chinese (65.03%) are just
a little bit above the current threshold and may also be affected very
soon.
Post by Philippe Verdy
The recent Serbian-Latin (51.50%) contribution was still not at the release
threshold.
If Limewire estimates that these additions are not much critical for most
users, the solution will be to decrease the current release threshold from
65% to 60% (but the Polish translation at 61.85% will still need updates
soon).
So there should be new calls to contributors in the support forums, and on
the home page... And some incitations given to significant contributors that
will produce more than about 15% of progress for a wanted language).
Thanks.
Philippe.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
-From Ryan.
Justin Schmidt
2005-06-09 16:57:16 UTC
Permalink
If this is the case, perhaps 50% is a better threshold than 2/3.
Post by Ryan Keppel
65% seems a bit arbitrary. Certainly there are more important messages that
could be weighted higher. But that would get quite complex.
------ Original Message ------
Received: Thu, 09 Jun 2005 09:23:35 AM PDT
Subject: [gui-dev] Locales Warning
Post by Philippe Verdy
Warning: with the recent additions in the messages bundle, a
significant
number of languages are now under the existing release threshold of 65%.
Catalan (64.52%), Hungarian (62.35%), Icelandic (62.85%), Polish (61.85%),
Simplified Chinese (63.27%).
Some new resources may be translated nearly automatically from other
existing translated resources because they are obvious (sometimes this is a
minor change of format for a specific message). But I don't have the time to
review them for now and reincrease their level.
Note also that Portuguese (65.11%) and Traditional Chinese (65.03%) are just
a little bit above the current threshold and may also be affected very
soon.
Post by Philippe Verdy
The recent Serbian-Latin (51.50%) contribution was still not at the release
threshold.
If Limewire estimates that these additions are not much critical for most
users, the solution will be to decrease the current release threshold from
65% to 60% (but the Polish translation at 61.85% will still need updates
soon).
So there should be new calls to contributors in the support forums, and on
the home page... And some incitations given to significant
contributors that
will produce more than about 15% of progress for a wanted language).
Thanks.
Philippe.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
-From Ryan.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
Greg Bildson
2005-06-09 17:40:14 UTC
Permalink
If we could deprioritize some of the Statistics page translations, that
would be useful. The average user will never look at those.

Thanks
-greg
-----Original Message-----
Sent: Thursday, June 09, 2005 12:57 PM
Subject: Re: [gui-dev] Locales Warning
If this is the case, perhaps 50% is a better threshold than 2/3.
Post by Ryan Keppel
65% seems a bit arbitrary. Certainly there are more important messages that
could be weighted higher. But that would get quite complex.
------ Original Message ------
Received: Thu, 09 Jun 2005 09:23:35 AM PDT
Subject: [gui-dev] Locales Warning
Post by Philippe Verdy
Warning: with the recent additions in the messages bundle, a
significant
number of languages are now under the existing release threshold of 65%.
Catalan (64.52%), Hungarian (62.35%), Icelandic (62.85%), Polish (61.85%),
Simplified Chinese (63.27%).
Some new resources may be translated nearly automatically from other
existing translated resources because they are obvious (sometimes this is a
minor change of format for a specific message). But I don't have the time to
review them for now and reincrease their level.
Note also that Portuguese (65.11%) and Traditional Chinese (65.03%) are just
a little bit above the current threshold and may also be affected very
soon.
Post by Philippe Verdy
The recent Serbian-Latin (51.50%) contribution was still not at the release
threshold.
If Limewire estimates that these additions are not much critical for most
users, the solution will be to decrease the current release threshold from
65% to 60% (but the Polish translation at 61.85% will still need updates
soon).
So there should be new calls to contributors in the support forums, and on
the home page... And some incitations given to significant
contributors that
will produce more than about 15% of progress for a wanted language).
Thanks.
Philippe.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
-From Ryan.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
Sam Berlin
2005-06-09 18:14:20 UTC
Permalink
All of the statistics translations are ignored when calculating the
percentage.

Thanks,
Sam
Post by Greg Bildson
If we could deprioritize some of the Statistics page translations, that
would be useful. The average user will never look at those.
Thanks
-greg
-----Original Message-----
Sent: Thursday, June 09, 2005 12:57 PM
Subject: Re: [gui-dev] Locales Warning
If this is the case, perhaps 50% is a better threshold than 2/3.
Post by Ryan Keppel
65% seems a bit arbitrary. Certainly there are more important
messages
that
could be weighted higher. But that would get quite complex.
------ Original Message ------
Received: Thu, 09 Jun 2005 09:23:35 AM PDT
Subject: [gui-dev] Locales Warning
Post by Philippe Verdy
Warning: with the recent additions in the messages bundle, a
significant
number of languages are now under the existing release threshold of 65%.
Catalan (64.52%), Hungarian (62.35%), Icelandic (62.85%), Polish (61.85%),
Simplified Chinese (63.27%).
Some new resources may be translated nearly automatically from other
existing translated resources because they are obvious (sometimes this is a
minor change of format for a specific message). But I don't have the time to
review them for now and reincrease their level.
Note also that Portuguese (65.11%) and Traditional Chinese (65.03%) are just
a little bit above the current threshold and may also be affected very
soon.
Post by Philippe Verdy
The recent Serbian-Latin (51.50%) contribution was still not at the release
threshold.
If Limewire estimates that these additions are not much critical for most
users, the solution will be to decrease the current release
threshold
from
65% to 60% (but the Polish translation at 61.85% will still need updates
soon).
So there should be new calls to contributors in the support forums, and on
the home page... And some incitations given to significant
contributors that
will produce more than about 15% of progress for a wanted language).
Thanks.
Philippe.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
-From Ryan.
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
_______________________________________________
gui-dev mailing list
http://www.limewire.org/mailman/listinfo/gui-dev
Marcin Okraszewski
2005-06-12 22:33:26 UTC
Permalink
Post by Philippe Verdy
65% to 60% (but the Polish translation at 61.85% will still need updates
soon).
I've done some Polish translation. Just a quick one. If I have more time
I'll translate more. I've made the translation only based on the English
version, so I skipped any I wasn't sure of context.

Regards,
Marcin Okraszewski

Loading...