Menu
▾
▴
jedit-devel
You can subscribe to this list here.
| 1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(32) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2000 |
Jan
(452) |
Feb
(435) |
Mar
(117) |
Apr
(265) |
May
(161) |
Jun
(276) |
Jul
(409) |
Aug
(522) |
Sep
(139) |
Oct
(306) |
Nov
(406) |
Dec
(217) |
| 2001 |
Jan
(237) |
Feb
(194) |
Mar
(266) |
Apr
(298) |
May
(266) |
Jun
(195) |
Jul
(427) |
Aug
(660) |
Sep
(808) |
Oct
(465) |
Nov
(260) |
Dec
(226) |
| 2002 |
Jan
(255) |
Feb
(322) |
Mar
(440) |
Apr
(327) |
May
(271) |
Jun
(263) |
Jul
(122) |
Aug
(346) |
Sep
(172) |
Oct
(282) |
Nov
(184) |
Dec
(166) |
| 2003 |
Jan
(325) |
Feb
(431) |
Mar
(431) |
Apr
(238) |
May
(320) |
Jun
(331) |
Jul
(289) |
Aug
(277) |
Sep
(223) |
Oct
(273) |
Nov
(218) |
Dec
(223) |
| 2004 |
Jan
(203) |
Feb
(321) |
Mar
(316) |
Apr
(18) |
May
(44) |
Jun
(149) |
Jul
(83) |
Aug
(216) |
Sep
(188) |
Oct
(136) |
Nov
(73) |
Dec
(117) |
| 2005 |
Jan
(101) |
Feb
(208) |
Mar
(153) |
Apr
(81) |
May
(85) |
Jun
(87) |
Jul
(100) |
Aug
(145) |
Sep
(57) |
Oct
(123) |
Nov
(73) |
Dec
(105) |
| 2006 |
Jan
(211) |
Feb
(134) |
Mar
(299) |
Apr
(223) |
May
(292) |
Jun
(426) |
Jul
(477) |
Aug
(415) |
Sep
(501) |
Oct
(460) |
Nov
(427) |
Dec
(302) |
| 2007 |
Jan
(467) |
Feb
(423) |
Mar
(356) |
Apr
(241) |
May
(357) |
Jun
(342) |
Jul
(373) |
Aug
(421) |
Sep
(491) |
Oct
(266) |
Nov
(236) |
Dec
(310) |
| 2008 |
Jan
(228) |
Feb
(344) |
Mar
(466) |
Apr
(410) |
May
(437) |
Jun
(303) |
Jul
(255) |
Aug
(451) |
Sep
(520) |
Oct
(379) |
Nov
(430) |
Dec
(261) |
| 2009 |
Jan
(352) |
Feb
(394) |
Mar
(279) |
Apr
(534) |
May
(245) |
Jun
(392) |
Jul
(510) |
Aug
(392) |
Sep
(237) |
Oct
(332) |
Nov
(302) |
Dec
(590) |
| 2010 |
Jan
(723) |
Feb
(650) |
Mar
(530) |
Apr
(307) |
May
(300) |
Jun
(450) |
Jul
(196) |
Aug
(233) |
Sep
(270) |
Oct
(288) |
Nov
(284) |
Dec
(331) |
| 2011 |
Jan
(336) |
Feb
(277) |
Mar
(133) |
Apr
(102) |
May
(50) |
Jun
(234) |
Jul
(174) |
Aug
(274) |
Sep
(355) |
Oct
(273) |
Nov
(895) |
Dec
(749) |
| 2012 |
Jan
(744) |
Feb
(498) |
Mar
(767) |
Apr
(412) |
May
(513) |
Jun
(596) |
Jul
(372) |
Aug
(515) |
Sep
(373) |
Oct
(246) |
Nov
(210) |
Dec
(232) |
| 2013 |
Jan
(162) |
Feb
(226) |
Mar
(209) |
Apr
(162) |
May
(84) |
Jun
(153) |
Jul
(91) |
Aug
(142) |
Sep
(151) |
Oct
(220) |
Nov
(176) |
Dec
(131) |
| 2014 |
Jan
(61) |
Feb
(83) |
Mar
(93) |
Apr
(274) |
May
(83) |
Jun
(46) |
Jul
(149) |
Aug
(61) |
Sep
(49) |
Oct
(93) |
Nov
(100) |
Dec
(164) |
| 2015 |
Jan
(93) |
Feb
(130) |
Mar
(44) |
Apr
(31) |
May
(85) |
Jun
(11) |
Jul
(47) |
Aug
(131) |
Sep
(117) |
Oct
(115) |
Nov
(73) |
Dec
(84) |
| 2016 |
Jan
(106) |
Feb
(88) |
Mar
(116) |
Apr
(160) |
May
(121) |
Jun
(74) |
Jul
(126) |
Aug
(141) |
Sep
(101) |
Oct
(38) |
Nov
(32) |
Dec
(6) |
| 2017 |
Jan
(33) |
Feb
(60) |
Mar
(112) |
Apr
(33) |
May
(24) |
Jun
(115) |
Jul
(24) |
Aug
|
Sep
(6) |
Oct
(147) |
Nov
(166) |
Dec
(118) |
| 2018 |
Jan
(53) |
Feb
(51) |
Mar
(4) |
Apr
(14) |
May
(28) |
Jun
(14) |
Jul
(18) |
Aug
(53) |
Sep
(27) |
Oct
(9) |
Nov
(2) |
Dec
(2) |
| 2019 |
Jan
(8) |
Feb
(7) |
Mar
(21) |
Apr
(17) |
May
(43) |
Jun
(45) |
Jul
(13) |
Aug
(32) |
Sep
(18) |
Oct
(41) |
Nov
(19) |
Dec
(60) |
| 2020 |
Jan
(9) |
Feb
(12) |
Mar
(26) |
Apr
(43) |
May
(67) |
Jun
(42) |
Jul
(4) |
Aug
(3) |
Sep
(73) |
Oct
(8) |
Nov
(19) |
Dec
(14) |
| 2021 |
Jan
(19) |
Feb
(9) |
Mar
(20) |
Apr
(25) |
May
(17) |
Jun
(9) |
Jul
(1) |
Aug
(21) |
Sep
(17) |
Oct
(12) |
Nov
(4) |
Dec
|
| 2022 |
Jan
(2) |
Feb
(1) |
Mar
(9) |
Apr
(5) |
May
(25) |
Jun
(9) |
Jul
(10) |
Aug
(3) |
Sep
(27) |
Oct
(6) |
Nov
(9) |
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(11) |
Apr
|
May
(13) |
Jun
(11) |
Jul
(11) |
Aug
(14) |
Sep
(17) |
Oct
(50) |
Nov
(5) |
Dec
(2) |
| 2024 |
Jan
(6) |
Feb
(20) |
Mar
(8) |
Apr
(15) |
May
(35) |
Jun
|
Jul
(7) |
Aug
(21) |
Sep
(13) |
Oct
(33) |
Nov
(7) |
Dec
(12) |
| 2025 |
Jan
(3) |
Feb
(26) |
Mar
(14) |
Apr
(9) |
May
(1) |
Jun
(9) |
Jul
(1) |
Aug
(5) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(26) |
2
(9) |
3
(6) |
|
4
(4) |
5
(16) |
6
(17) |
7
(17) |
8
(25) |
9
(29) |
10
(31) |
|
11
(42) |
12
(37) |
13
(44) |
14
(26) |
15
(27) |
16
(15) |
17
(6) |
|
18
(3) |
19
(13) |
20
(36) |
21
(5) |
22
(3) |
23
(23) |
24
(29) |
|
25
(22) |
26
(61) |
27
(34) |
28
(50) |
29
(70) |
30
(23) |
31
(18) |
|
From: Jojaba <jo...@gm...> - 2012-03-31 16:25:24
|
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I found a French page describing svn blame:
<a class="moz-txt-link-freetext" href="http://vrac.cofares.net/MirrorLebanon/svn-book-html-chunk/svn.ref.svn.c.blame.html">http://vrac.cofares.net/MirrorLebanon/svn-book-html-chunk/svn.ref.svn.c.blame.html</a><br>
Explanation in French: Affiche les informations de révisions et
d'auteur en plus du contenu pour les fichiers ou URL spécifiés<br>
Translation in english: Displays the revision and author infos in
addition of the content for the files and URLs specified<br>
In this same page, you find indeed the alternate words you gave
Dale. I'm really surpsrided that this 3 words means the same
command!<br>
It is often difficult to translate a technical word because skilled
users are used to read and understand it in english, if you provide
a translation in that case, you will probably disturb them. But I
try as much as possible to translate it anyway especially for
beginners. In the case of "Blame" I willl probably put a translation
but add the english version between brackets...<br>
Thanks for your help.<br>
<br>
Le 31/03/2012 16:52, Dale Anson a écrit :
<blockquote
cite="mid:CAH...@ma..."
type="cite">
<p>Alternate names are "praise" and "annotate".</p>
<div class="gmail_quote">On Mar 31, 2012 12:02 AM, "Alan Ezust"
<<a moz-do-not-send="true" href="mailto:ala...@gm...">ala...@gm...</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
It is the name of an actual svn command, so I am not sure if
it makes<br>
sense to translate it.<br>
But if you see a dictionary definition for that word, it is
probably<br>
the same word that "blame" is based on.<br>
<br>
Blame.<br>
1 : to find fault with : censure <the right to praise or
blame a literary work><br>
2 a : to hold responsible <they blame me for everything>
b : to place<br>
responsibility for <blames it on me><br>
<br>
It's definition #2. See who is responsible for each line in
the file.<br>
<br>
<br>
<br>
On Fri, Mar 30, 2012 at 10:50 PM, Jojaba <<a
moz-do-not-send="true" href="mailto:jo...@gm...">jo...@gm...</a>>
wrote:<br>
> Hello,<br>
><br>
> I'm translating the SVN Plugin and would like to know
what "Blame"<br>
> means. I never saw that string before in SVN and think
that it doesnt<br>
> mean the same then the current "Blame" word...<br>
> Thanks in advance :)<br>
><br>
>
------------------------------------------------------------------------------<br>
> This SF email is sponsosred by:<br>
> Try Windows Azure free for 90 days Click Here<br>
> <a moz-do-not-send="true"
href="http://p.sf.net/sfu/sfd2d-msazure" target="_blank">http://p.sf.net/sfu/sfd2d-msazure</a><br>
> --<br>
> -----------------------------------------------<br>
> jEdit Developers' List<br>
> <a moz-do-not-send="true"
href="mailto:jEd...@li...">jEd...@li...</a><br>
> <a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/jedit-devel"
target="_blank">https://lists.sourceforge.net/lists/listinfo/jedit-devel</a><br>
<br>
------------------------------------------------------------------------------<br>
This SF email is sponsosred by:<br>
Try Windows Azure free for 90 days Click Here<br>
<a moz-do-not-send="true"
href="http://p.sf.net/sfu/sfd2d-msazure" target="_blank">http://p.sf.net/sfu/sfd2d-msazure</a><br>
--<br>
-----------------------------------------------<br>
jEdit Developers' List<br>
<a moz-do-not-send="true"
href="mailto:jEd...@li...">jEd...@li...</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/jedit-devel"
target="_blank">https://lists.sourceforge.net/lists/listinfo/jedit-devel</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>
|
|
From: Jarek C. <jar...@po...> - 2012-03-31 15:44:18
|
Not on edt. Right, Dale. Sorry for being unable to read :) Jarek W dniu 03/31/2012 05:07 PM, Dale Anson pisze: > Yes, that's what I said: on jEdit startup, initPLAF is called just > once, and that call is not on EDT. > > That call is from main(), so we are in agreement. Note that there > isn't anything in initPLAF (with my patch) that needs to be on EDT > other than the call to updateComponentTreeUI. As it happens, that call > is only done on EDT. There should probably be a check to ensure it > only happens on EDT, but it seems to be fine as is. > > Dale > > > On Sat, Mar 31, 2012 at 12:38 AM, Jarek Czekalski > <jar...@po... <mailto:jar...@po...>> wrote: > > W dniu 03/30/2012 10:34 PM, Dale Anson pisze: > > So I went through the code again to refresh my mind how it > works. This > > is with my patch installed. > > > > 1) On jEdit startup, initPLAF is called just once, and that call is > > not on EDT. > Dale, there must be some misunderstanding between us. Please show the > stack of this call. Thread.dumpStack(). It's hard to deny that main > calls initPLAF and main is not edt. > > Jarek > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > <mailto:jEd...@li...> > https://lists.sourceforge.net/lists/listinfo/jedit-devel > > |
|
From: Jarek C. <jar...@po...> - 2012-03-31 15:42:43
|
My vote: tabsize 4, line limit to stay. There are still reasons to keep 80 chars. Details on stackoverflow: http://stackoverflow.com/questions/110928/is-there-a-valid-reason-for-enforcing-a-maximum-width-of-80-characters-in-a-code To shortly mention part of it: printing, pasting to emails, www, working with text terminals occasionally. If we change indentation to 4, we gain at least 8 chars. In case of an if inside a loop we gain 16 chars. This should be enough to code comfortably. So maybe let's make only a small step now, decreasing the tab size? Jarek W dniu 03/31/2012 05:14 PM, Dale Anson pisze: > That is historical and has been the standard for core code since > Slava. It's not my personal preference. I prefer to follow Sun's > standard -- tabs are 4 spaces, brackets attached rather than broken, > etc. The 80 character requirement is also historical and out of date. > I haven't seen a monitor that small in years. So if you're looking for > a vote, I'd vote for changing from 8 spaces to 4, and eliminate the 80 > character width limit. > > Dale > > > On Sat, Mar 31, 2012 at 4:04 AM, Jarek Czekalski > <jar...@po... <mailto:jar...@po...>> wrote: > > Tab size is set to 8. I found this idea unwise in connection with a > common requirement to fit in 80 chars total. > > So it seems logical to decrease the tab size. I know I can change it > while editing the file, but then what I'll see as fitting in 80 chars, > would not fit on other's settings. > > Raw svn diff output will be an issue, if tab size is decreased, but if > we all decide not to look at the console output, we could make our > lifes > easier. > > What are your suggestions? > > Jarek > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > <mailto:jEd...@li...> > https://lists.sourceforge.net/lists/listinfo/jedit-devel > > |
|
From: Matthieu C. <cho...@gm...> - 2012-03-31 15:41:41
|
Personally, I like our coding style a lot. I like having the braces on the next line for example like we do. About 8 chars tab size, it may be too much but I don't think changing that would be a good idea, plugins could choose other settings but I don't think jEdit should change. About the 80 columns limit I agree that we could change that and use 120 or 160 maybe instead. It would not cause any merge error so I have no objection about removing that constraint. 2012/3/31 Alan Ezust <ala...@gm...> > +1 on that. > > > On Sat, Mar 31, 2012 at 8:14 AM, Dale Anson <da...@gr...> wrote: > > That is historical and has been the standard for core code since Slava. > It's > > not my personal preference. I prefer to follow Sun's standard -- tabs > are 4 > > spaces, brackets attached rather than broken, etc. The 80 character > > requirement is also historical and out of date. I haven't seen a monitor > > that small in years. So if you're looking for a vote, I'd vote for > changing > > from 8 spaces to 4, and eliminate the 80 character width limit. > > > > Dale > > > > > > > > On Sat, Mar 31, 2012 at 4:04 AM, Jarek Czekalski < > jar...@po...> > > wrote: > >> > >> Tab size is set to 8. I found this idea unwise in connection with a > >> common requirement to fit in 80 chars total. > >> > >> So it seems logical to decrease the tab size. I know I can change it > >> while editing the file, but then what I'll see as fitting in 80 chars, > >> would not fit on other's settings. > >> > >> Raw svn diff output will be an issue, if tab size is decreased, but if > >> we all decide not to look at the console output, we could make our lifes > >> easier. > >> > >> What are your suggestions? > >> > >> Jarek > >> > >> > >> > ------------------------------------------------------------------------------ > >> This SF email is sponsosred by: > >> Try Windows Azure free for 90 days Click Here > >> http://p.sf.net/sfu/sfd2d-msazure > >> -- > >> ----------------------------------------------- > >> jEdit Developers' List > >> jEd...@li... > >> https://lists.sourceforge.net/lists/listinfo/jedit-devel > > > > > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > -- > > ----------------------------------------------- > > jEdit Developers' List > > jEd...@li... > > https://lists.sourceforge.net/lists/listinfo/jedit-devel > > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > |
|
From: Alan E. <ala...@gm...> - 2012-03-31 15:17:33
|
+1 on that. On Sat, Mar 31, 2012 at 8:14 AM, Dale Anson <da...@gr...> wrote: > That is historical and has been the standard for core code since Slava. It's > not my personal preference. I prefer to follow Sun's standard -- tabs are 4 > spaces, brackets attached rather than broken, etc. The 80 character > requirement is also historical and out of date. I haven't seen a monitor > that small in years. So if you're looking for a vote, I'd vote for changing > from 8 spaces to 4, and eliminate the 80 character width limit. > > Dale > > > > On Sat, Mar 31, 2012 at 4:04 AM, Jarek Czekalski <jar...@po...> > wrote: >> >> Tab size is set to 8. I found this idea unwise in connection with a >> common requirement to fit in 80 chars total. >> >> So it seems logical to decrease the tab size. I know I can change it >> while editing the file, but then what I'll see as fitting in 80 chars, >> would not fit on other's settings. >> >> Raw svn diff output will be an issue, if tab size is decreased, but if >> we all decide not to look at the console output, we could make our lifes >> easier. >> >> What are your suggestions? >> >> Jarek >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> -- >> ----------------------------------------------- >> jEdit Developers' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-devel > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > |
|
From: Dale A. <da...@gr...> - 2012-03-31 15:14:52
|
That is historical and has been the standard for core code since Slava. It's not my personal preference. I prefer to follow Sun's standard -- tabs are 4 spaces, brackets attached rather than broken, etc. The 80 character requirement is also historical and out of date. I haven't seen a monitor that small in years. So if you're looking for a vote, I'd vote for changing from 8 spaces to 4, and eliminate the 80 character width limit. Dale On Sat, Mar 31, 2012 at 4:04 AM, Jarek Czekalski <jar...@po...>wrote: > Tab size is set to 8. I found this idea unwise in connection with a > common requirement to fit in 80 chars total. > > So it seems logical to decrease the tab size. I know I can change it > while editing the file, but then what I'll see as fitting in 80 chars, > would not fit on other's settings. > > Raw svn diff output will be an issue, if tab size is decreased, but if > we all decide not to look at the console output, we could make our lifes > easier. > > What are your suggestions? > > Jarek > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > |
|
From: Dale A. <da...@gr...> - 2012-03-31 15:07:11
|
Yes, that's what I said: on jEdit startup, initPLAF is called just once, and that call is not on EDT. That call is from main(), so we are in agreement. Note that there isn't anything in initPLAF (with my patch) that needs to be on EDT other than the call to updateComponentTreeUI. As it happens, that call is only done on EDT. There should probably be a check to ensure it only happens on EDT, but it seems to be fine as is. Dale On Sat, Mar 31, 2012 at 12:38 AM, Jarek Czekalski <jar...@po...>wrote: > W dniu 03/30/2012 10:34 PM, Dale Anson pisze: > > So I went through the code again to refresh my mind how it works. This > > is with my patch installed. > > > > 1) On jEdit startup, initPLAF is called just once, and that call is > > not on EDT. > Dale, there must be some misunderstanding between us. Please show the > stack of this call. Thread.dumpStack(). It's hard to deny that main > calls initPLAF and main is not edt. > > Jarek > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > |
|
From: Dale A. <da...@gr...> - 2012-03-31 14:52:30
|
Alternate names are "praise" and "annotate". On Mar 31, 2012 12:02 AM, "Alan Ezust" <ala...@gm...> wrote: > It is the name of an actual svn command, so I am not sure if it makes > sense to translate it. > But if you see a dictionary definition for that word, it is probably > the same word that "blame" is based on. > > Blame. > 1 : to find fault with : censure <the right to praise or blame a literary > work> > 2 a : to hold responsible <they blame me for everything> b : to place > responsibility for <blames it on me> > > It's definition #2. See who is responsible for each line in the file. > > > > On Fri, Mar 30, 2012 at 10:50 PM, Jojaba <jo...@gm...> wrote: > > Hello, > > > > I'm translating the SVN Plugin and would like to know what "Blame" > > means. I never saw that string before in SVN and think that it doesnt > > mean the same then the current "Blame" word... > > Thanks in advance :) > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > -- > > ----------------------------------------------- > > jEdit Developers' List > > jEd...@li... > > https://lists.sourceforge.net/lists/listinfo/jedit-devel > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > |
|
From: SourceForge.net <no...@so...> - 2012-03-31 10:59:00
|
Plugin Bugs item #3512420, was opened at 2012-03-28 08:12 Message generated for change (Comment added) made by jarekczek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3512420&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Project Viewer Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: neckhaus (neckhaus) Assigned to: Jarek Czekalski (jarekczek) Summary: Cannot setup project in Project Viewer Initial Comment: I'm running Jedit 4.5, Project Viewer 3.4.2, on 64 bit Windows 7 Home Premium, with Java 6 Update 31. After Installing Project Viewer, I was able to create a Project Group. I launch Jedit, Click on Plugins -> Project Viewer -> Projects -> "ProjGroup1" -> New project here. I get the Create New Project dialog. I put a name (alpha only, no spaces) in Project Name, browse to the directory for the project, the Parent group has "ProjGroup1". I click OK, and nothing happens. I click Apply and nothing happens. I click on Cancel and the window closes. However, Jedit is now unuseable. Clicking in an open buffer does not insert the insertion point. Clicking on the Plugins menu, brings up the menu. Moving up and down the menu exposes and leaves side menus exposed. Minimizing Jedit, and then bringing it back gives me a black window under the title bar, which will show icons below the menu bar as I hover over them. The menu bar and the buffers are black. I also have BufferTabs, ErrorList, Hex Edit, HexTools, JDiff Plugin, Project Viewer, QuickNotepad, SideKick. ---------------------------------------------------------------------- >Comment By: Jarek Czekalski (jarekczek) Date: 2012-03-31 03:59 Message: Neckhaus, we were discussing a lot about the problem your reported. None of us is able to reproduce, but we would truly like to know, where does the problem come from. So I offer a deal :) http://jarekczek.users.sourceforge.net/jedit_45_debug_initplaf/jedit.jar This is jedit 451 that should fix your issue. At the same time it is much more verbose about the things that we suspect to cause your problems. Please replace your jedit.jar with this file and see what happens. I guess you'll be able to create a project and we will get a detailed log. Please send us the log of a single try of project creation. For our reference I attach the patch used to generate this jedit.jar from -r21425 of 4.5.x branch. ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2012-03-29 22:17 Message: It appears to be related to the look and feel code. I assume you are using "windows" look and feel? What if you change to simply "metal" look and feel, does it still reproduce? The activity log has lots of exceptions that look like this: 12:26:44 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: java.lang.NullPointerException 12:26:44 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: at javax.swing.plaf.basic.BasicTabbedPaneUI.scrollableTabLayoutEnabled(Unknown Source) 12:26:44 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: at javax.swing.plaf.basic.BasicTabbedPaneUI.access$400(Unknown Source) 12:26:44 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: at javax.swing.plaf.basic.BasicTabbedPaneUI$TabContainer.doLayout(Unknown Source) 12:26:44 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: at java.awt.Container.validateTree(Unknown Source) 12:26:44 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: at java.awt.Container.validateTree(Unknown Source) 12:26:44 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: at java.awt.Container.validate(Unknown Source) 12:26:44 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: at javax.swing.plaf.basic.BasicTabbedPaneUI.ensureCurrentLayout(Unknown Source) 12:26:44 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: at javax.swing.plaf.basic.BasicTabbedPaneUI.paint(Unknown Source) 12:26:44 PM [AWT-EventQueue-0] [error] AWT-EventQueue-0: at javax.swing.plaf.metal.MetalTabbedPaneUI.paint(Unknown Source) ---------------------------------------------------------------------- Comment By: Jarek Czekalski (jarekczek) Date: 2012-03-29 22:10 Message: So the first step to reproduce the error would be: - download pv using plugin manager ---------------------------------------------------------------------- Comment By: neckhaus (neckhaus) Date: 2012-03-29 18:29 Message: I get the same behavior when using the docked project viewer as I documented in the original bug report. The project group is there, but attempting to add a project fails, and I have to close jEdit to recover. Per Jarek's request, I launched jEdit from a command prompt (c:\Program Files\jEdit>jedit -settings=C:\Temp\settings-temp). When jEdit opened, none of my plugs in loaded. ---------------------------------------------------------------------- Comment By: Jarek Czekalski (jarekczek) Date: 2012-03-28 09:46 Message: I am able to notice an excepction if I create a new group using the menu and when the project viewer dockable is not yet active. I have however problems reproducing jedit hang. Please provide steps to reproduce starting from fresh jedit settings (use -settings switch to force a new directory). Then please pay attention to whether pv dockable is active or not. And whether you use the menu or some other means to create a group/project. I would like to fix both issues quickly. As a workaround I advice creating projects and groups from a tree in the dockable. It should not make problems as it was thoroughly tested. ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2012-03-28 08:25 Message: Please attach the activity log from reproducing these steps as an attachment to this ticket. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3512420&group_id=588 |
|
From: Jarek C. <jar...@po...> - 2012-03-31 10:05:59
|
Tab size is set to 8. I found this idea unwise in connection with a common requirement to fit in 80 chars total. So it seems logical to decrease the tab size. I know I can change it while editing the file, but then what I'll see as fitting in 80 chars, would not fit on other's settings. Raw svn diff output will be an issue, if tab size is decreased, but if we all decide not to look at the console output, we could make our lifes easier. What are your suggestions? Jarek |
|
From: SourceForge.net <no...@so...> - 2012-03-31 07:00:39
|
Plugin Feature Requests item #1621716, was opened at 2006-12-24 10:53 Message generated for change (Comment added) made by ezust You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=997936&aid=1621716&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Deleted >Resolution: Out of Date Priority: 5 Private: No Submitted By: Alan Ezust (ezust) Assigned to: Nobody/Anonymous (nobody) Summary: AntFarm/Console: Error Highlighting +Run in the same JVM Initial Comment: It seems as if the Console error output parsing is not happening to the output of AntFarm commands executed in the "Ant" console shell. ---------------------------------------------------------------------- >Comment By: Alan Ezust (ezust) Date: 2012-03-31 00:00 Message: I don't use antfarm anymore, but when I do it's always an external process. problem solved. ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2008-03-06 16:32 Message: Logged In: YES user_id=935841 Originator: YES Ok, perhaps this is how it always worked then. Error Highlighting on the system shell worked always, AntFarm can be used that way. AntFarm would need to be modified to support error highlighting for its internal process execution system. Moving this to plugin feature requests. ---------------------------------------------------------------------- Comment By: Björn Kautler (vampire0) Date: 2007-09-19 17:01 Message: Logged In: YES user_id=918212 Originator: NO I also still have the problem. I upgraded to newest plugins: AntFarm 1.5.4 AntPlugin 1.7.0 Console 4.3.3 jEdit 4.3pre10 ErrorList 1.5 If "Run Ant targets in the same JVM" is selected, the errors are not highlighted or added to the ErrorList, no matter if I type the command in the Ant Console or if I click in the AntFarm dockable. If "Run Ant targets using an external script/build file" is activated, the highlighting works both ways and the ErrorList is filled. ---------------------------------------------------------------------- Comment By: aberdeen61 (aberdeen61) Date: 2007-08-10 11:22 Message: Logged In: YES user_id=1864999 Originator: NO It's still a problem in Windows Using AntFarm 1.5.4 Console 4.3.3 jEdit 4.3pre9. ErrorList 1.5 ---------------------------------------------------------------------- Comment By: michael michaud (michaudm) Date: 2007-06-15 00:14 Message: Logged In: YES user_id=632630 Originator: NO On my windows box : - compiling with an ant task launched from the console (ant-mode) highlight errors well - but compiling the same file by double-clicking the ant task from the docked antfarm plugin does not highlight errors. seems the problem comes from antfarm Michael ---------------------------------------------------------------------- Comment By: Björn Kautler (vampire0) Date: 2007-06-14 23:47 Message: Logged In: YES user_id=918212 Originator: NO For me error highlighting with latest components doesn't work either ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2006-12-27 15:13 Message: Logged In: YES user_id=935841 Originator: YES Attempted to reproduce this problem, but was unable to. I get proper highlighting for errors generated indirectly from the AntFarm. Using AntFarm 1.5.4 Console 4.3.1 jEdit 4.3pre9. I think that whatever bug was causing this, is no longer present in current versions of related plugins. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=997936&aid=1621716&group_id=588 |
|
From: SourceForge.net <no...@so...> - 2012-03-31 06:59:26
|
Plugin Bugs item #3485639, was opened at 2012-02-08 01:16 Message generated for change (Settings changed) made by ezust You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3485639&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 2 Private: No Submitted By: Matthieu Casanova (kpouer) >Assigned to: Damien (kog13) Summary: Console plugin wrong color Initial Comment: When opening the console, the "console.beanshell.info" message is displayed, but it doesn't use a property for it's color so the color is black. If the console background is black the text is unreadable. Some other output are also without any color. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3485639&group_id=588 |
|
From: Jarek C. <jar...@po...> - 2012-03-31 06:56:15
|
Alan, what you said about javadocs and the first line looks suspicious to Matthieu and me. I was hoping you could support your words with a single live example. Jarek W dniu 03/31/2012 08:46 AM, Alan Ezust pisze: > My definition of a broken javadoc is one that has some text after the > /** but none of it appears in the package summary for the short > description. > > If you look at the package summary for any of jEdit's packages, such > as the "gui" package, > http://www.jedit.org/api/org/gjt/sp/jedit/gui/package-summary.html > you will see a lot of empty rectangles where there should be short descriptions. > Most of those you see online right now, are fixed because I made some > tweaking of the javadoc comments. > > You will also notice I did something similar to a lot of the > CommonControls classes. > > > On Fri, Mar 30, 2012 at 11:16 PM, Jarek Czekalski > <jar...@po...> wrote: >> Alan, could you show an example of invalid javadoc? >> >> Jarek >> >> W dniu 03/30/2012 06:58 PM, Alan Ezust pisze: >>> Interesting, I didn't need to touch that class, because it already >>> showed up in the package summary javadocs. I am not sure why that one >>> did but none of the ones I changed had short descriptions that >>> javadoc was able to find. >>> >>> If it ain't broke, don't fix it. >>> >>> There are other rules that javadoc can use to find the short >>> description, if it is easy >>> for javadoc to figure out. I suppose that class satisfies one of them. >>> >>> >>> On Fri, Mar 30, 2012 at 1:30 AM, Matthieu Casanova >>> <cho...@gm...> wrote: >>>> Hi, are you sure ? >>>> I just tried with common.gui.JMouseComboBox >>>> >>>> it's javadoc starts like this >>>> >>>> /** >>>> * This is a combo-box that allows listeners to be informed of mouse >>>> * entered and mouse exited events. >>>> * >>>> * Note that other mouse events besides MOUSE_ENTERED and MOUSE_EXITED still >>>> >>>> and >>>> This is a combo-box that allows listeners to be informed of mouse entered >>>> and mouse exited events. >>>> seems to be used as short description of the class when looking at the >>>> javadoc of common.gui package. >>>> >>>> The short description here stops at the first . >>>> If I remove the . after event the short description continues until the next >>>> dot. >>>> Or are you talking about another place ? >>>> >>>> Matthieu >>>> >>>> 2012/3/29 Alan Ezust<ala...@gm...> >>>>> Because it is the "short description" and is what is extracted in the >>>>> table summaries of the javadoc program. >>>>> If you look at the javadocs for CommonControls 1.3 versus what is in >>>>> the SVN trunk, you'll see that there were a lot of empty rectangles >>>>> before, and now there are not. >>>>> >>>>> That is because I put something into the first line immediately after the >>>>> /** >>>>> >>>>> /** Short Description >>>>> * >>>>> * Long Description Line1 >>>>> * Long Description Line2 >>>>> * Long Description Line3 >>>>> */ >>>>> class MyClass extends Blah1 implements Blah2 { >>>>> ... >>>>> } >>>>> >>>>> >>>>> Please, everyone, get into the habit of using it! Not just for core + >>>>> plugins, but for all your code. >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> This SF email is sponsosred by: >>>>> Try Windows Azure free for 90 days Click Here >>>>> http://p.sf.net/sfu/sfd2d-msazure >>>>> -- >>>>> ----------------------------------------------- >>>>> jEdit Developers' List >>>>> jEd...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/jedit-devel >>> ------------------------------------------------------------------------------ >>> This SF email is sponsosred by: >>> Try Windows Azure free for 90 days Click Here >>> http://p.sf.net/sfu/sfd2d-msazure >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> -- >> ----------------------------------------------- >> jEdit Developers' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-devel |
|
From: Alan E. <ala...@gm...> - 2012-03-31 06:46:47
|
My definition of a broken javadoc is one that has some text after the /** but none of it appears in the package summary for the short description. If you look at the package summary for any of jEdit's packages, such as the "gui" package, http://www.jedit.org/api/org/gjt/sp/jedit/gui/package-summary.html you will see a lot of empty rectangles where there should be short descriptions. Most of those you see online right now, are fixed because I made some tweaking of the javadoc comments. You will also notice I did something similar to a lot of the CommonControls classes. On Fri, Mar 30, 2012 at 11:16 PM, Jarek Czekalski <jar...@po...> wrote: > Alan, could you show an example of invalid javadoc? > > Jarek > > W dniu 03/30/2012 06:58 PM, Alan Ezust pisze: >> Interesting, I didn't need to touch that class, because it already >> showed up in the package summary javadocs. I am not sure why that one >> did but none of the ones I changed had short descriptions that >> javadoc was able to find. >> >> If it ain't broke, don't fix it. >> >> There are other rules that javadoc can use to find the short >> description, if it is easy >> for javadoc to figure out. I suppose that class satisfies one of them. >> >> >> On Fri, Mar 30, 2012 at 1:30 AM, Matthieu Casanova >> <cho...@gm...> wrote: >>> Hi, are you sure ? >>> I just tried with common.gui.JMouseComboBox >>> >>> it's javadoc starts like this >>> >>> /** >>> * This is a combo-box that allows listeners to be informed of mouse >>> * entered and mouse exited events. >>> * >>> * Note that other mouse events besides MOUSE_ENTERED and MOUSE_EXITED still >>> >>> and >>> This is a combo-box that allows listeners to be informed of mouse entered >>> and mouse exited events. >>> seems to be used as short description of the class when looking at the >>> javadoc of common.gui package. >>> >>> The short description here stops at the first . >>> If I remove the . after event the short description continues until the next >>> dot. >>> Or are you talking about another place ? >>> >>> Matthieu >>> >>> 2012/3/29 Alan Ezust<ala...@gm...> >>>> Because it is the "short description" and is what is extracted in the >>>> table summaries of the javadoc program. >>>> If you look at the javadocs for CommonControls 1.3 versus what is in >>>> the SVN trunk, you'll see that there were a lot of empty rectangles >>>> before, and now there are not. >>>> >>>> That is because I put something into the first line immediately after the >>>> /** >>>> >>>> /** Short Description >>>> * >>>> * Long Description Line1 >>>> * Long Description Line2 >>>> * Long Description Line3 >>>> */ >>>> class MyClass extends Blah1 implements Blah2 { >>>> ... >>>> } >>>> >>>> >>>> Please, everyone, get into the habit of using it! Not just for core + >>>> plugins, but for all your code. >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF email is sponsosred by: >>>> Try Windows Azure free for 90 days Click Here >>>> http://p.sf.net/sfu/sfd2d-msazure >>>> -- >>>> ----------------------------------------------- >>>> jEdit Developers' List >>>> jEd...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jedit-devel >>> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel |
|
From: Jarek C. <jar...@po...> - 2012-03-31 06:40:07
|
W dniu 03/30/2012 10:34 PM, Dale Anson pisze: > So I went through the code again to refresh my mind how it works. This > is with my patch installed. > > 1) On jEdit startup, initPLAF is called just once, and that call is > not on EDT. Dale, there must be some misunderstanding between us. Please show the stack of this call. Thread.dumpStack(). It's hard to deny that main calls initPLAF and main is not edt. Jarek |
|
From: Jarek C. <jar...@po...> - 2012-03-31 06:18:09
|
Alan, could you show an example of invalid javadoc?
Jarek
W dniu 03/30/2012 06:58 PM, Alan Ezust pisze:
> Interesting, I didn't need to touch that class, because it already
> showed up in the package summary javadocs. I am not sure why that one
> did but none of the ones I changed had short descriptions that
> javadoc was able to find.
>
> If it ain't broke, don't fix it.
>
> There are other rules that javadoc can use to find the short
> description, if it is easy
> for javadoc to figure out. I suppose that class satisfies one of them.
>
>
> On Fri, Mar 30, 2012 at 1:30 AM, Matthieu Casanova
> <cho...@gm...> wrote:
>> Hi, are you sure ?
>> I just tried with common.gui.JMouseComboBox
>>
>> it's javadoc starts like this
>>
>> /**
>> * This is a combo-box that allows listeners to be informed of mouse
>> * entered and mouse exited events.
>> *
>> * Note that other mouse events besides MOUSE_ENTERED and MOUSE_EXITED still
>>
>> and
>> This is a combo-box that allows listeners to be informed of mouse entered
>> and mouse exited events.
>> seems to be used as short description of the class when looking at the
>> javadoc of common.gui package.
>>
>> The short description here stops at the first .
>> If I remove the . after event the short description continues until the next
>> dot.
>> Or are you talking about another place ?
>>
>> Matthieu
>>
>> 2012/3/29 Alan Ezust<ala...@gm...>
>>> Because it is the "short description" and is what is extracted in the
>>> table summaries of the javadoc program.
>>> If you look at the javadocs for CommonControls 1.3 versus what is in
>>> the SVN trunk, you'll see that there were a lot of empty rectangles
>>> before, and now there are not.
>>>
>>> That is because I put something into the first line immediately after the
>>> /**
>>>
>>> /** Short Description
>>> *
>>> * Long Description Line1
>>> * Long Description Line2
>>> * Long Description Line3
>>> */
>>> class MyClass extends Blah1 implements Blah2 {
>>> ...
>>> }
>>>
>>>
>>> Please, everyone, get into the habit of using it! Not just for core +
>>> plugins, but for all your code.
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here
>>> http://p.sf.net/sfu/sfd2d-msazure
>>> --
>>> -----------------------------------------------
>>> jEdit Developers' List
>>> jEd...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
|
|
From: Alan E. <ala...@gm...> - 2012-03-31 06:02:11
|
It is the name of an actual svn command, so I am not sure if it makes sense to translate it. But if you see a dictionary definition for that word, it is probably the same word that "blame" is based on. Blame. 1 : to find fault with : censure <the right to praise or blame a literary work> 2 a : to hold responsible <they blame me for everything> b : to place responsibility for <blames it on me> It's definition #2. See who is responsible for each line in the file. On Fri, Mar 30, 2012 at 10:50 PM, Jojaba <jo...@gm...> wrote: > Hello, > > I'm translating the SVN Plugin and would like to know what "Blame" > means. I never saw that string before in SVN and think that it doesnt > mean the same then the current "Blame" word... > Thanks in advance :) > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel |
|
From: Jojaba <jo...@gm...> - 2012-03-31 05:51:03
|
Hello, I'm translating the SVN Plugin and would like to know what "Blame" means. I never saw that string before in SVN and think that it doesnt mean the same then the current "Blame" word... Thanks in advance :) |
|
From: Dale A. <da...@gr...> - 2012-03-30 20:34:40
|
So I went through the code again to refresh my mind how it works. This is with my patch installed. 1) On jEdit startup, initPLAF is called just once, and that call is not on EDT. 2) If LookAndFeel plugin is installed, initPLAF is called again after LookAndFeel plugin is loaded, again, not on EDT. 3) After jEdit is up and running, changing a property causes initPLAF to be called on EDT, but unless the look and feel property has changed, it returns without doing anything. 4) Changing the look and feel, either with global options/appearance or with LookAndFeel plugin, causes initPLAF to be called on the EDT, and the body of the method is executed. I can't tell if this fixes the problem that prompted this thread in the first place, but I think my patch is working as I expect anyway. Now that there have been a few more eyes on it, are there any objections to me applying the patch directly? Thanks, Dale On Fri, Mar 30, 2012 at 12:46 PM, Matthieu Casanova <cho...@gm...>wrote: > For information there are also the same kind of bugs when using Mydoggy > and changing look & feel. > > > 2012/3/30 Dale Anson <da...@gr...> > >> Let me review my patch again, it's been a couple of months since I went >> through that code. I think it is more often than just a call from main(), I >> recall initPLAF is also called on EditBus events (property changes, I >> think, but I need to review). I do recall initPLAF is called before the >> plugins are loaded, which is what caused the problems with the look and >> feel plugin not being able to properly set the look and feel. >> >> Dale >> >> >> >> On Fri, Mar 30, 2012 at 9:35 AM, Jarek Czekalski < >> jar...@po...> wrote: >> >>> Actually initPlaf is called straight from jEdit.main() which is non-edt >>> thread. So jedit is based on violating java thread safety principles, >>> because it calls many gui methods from main. With your patch applied, >>> Dale, setting of l&f is moved after all the initialization, probably >>> including initialization of plugins. Maybe that's the way it works for >>> the L&F plugin. >>> >>> Jarek >>> >>> W dniu 03/30/2012 04:47 PM, Jarek Czekalski pisze: >>> > Dale, thanks for the feedback. >>> > >>> > As I look at the bug report log, the problem seems to happen in EDT. >>> > Your patch takes care of a situation where initPLAF is called from >>> > non-EDT thread. So it seems unrelated. No code should call initPLAF >>> > from non-EDT thread. That's the theory. In practice I can't test it >>> > because we didn't manage to reproduce the issue. >>> > >>> > Jarek >>> > >>> > W dniu 2012-03-30 16:11, Dale Anson pisze: >>> >> Here is a bit more about this. Vampire introduced the change to fix >>> >> an issue where the tree controls were not updating when the look and >>> >> feel was changed from global options/appearance. This change also >>> >> causes problems with the look and feel plugin since the look and feel >>> >> was being initialized before the look and feel plugin was even >>> >> loaded. I submitted a patch a couple of months ago: >>> >> >>> >> >>> https://sourceforge.net/tracker/?func=detail&aid=3482818&group_id=588&atid=300588 >>> >> < >>> https://sourceforge.net/tracker/?func=detail&aid=3482818&group_id=588&atid=300588 >>> > >>> >> >>> >> I've been running this patch for quite a while and it takes care of >>> >> the issue with the look and feel plugin. I believe it would also fix >>> >> this issue. >>> >> >>> >> Dale >>> >> >>> >> >>> >> >>> >> On Fri, Mar 30, 2012 at 1:10 AM, Jarek Czekalski >>> >> <jar...@po... <mailto:jar...@po...>> wrote: >>> >> >>> >> In r19787: >>> >> >>> >> public static void propertiesChanged() >>> >> { >>> >> + initPLAF(); >>> >> + >>> >> initKeyBindings(); >>> >> >>> >> >>> >> This is introduced in 4.5. Seems like this is causing problems >>> >> that were >>> >> not happening in 4.4. >>> >> >>> >> Maybe checking for validity of "lookAndFeel" would solve the >>> >> problem. I >>> >> can make a patch and suggest to try the daily build. This bug may >>> be >>> >> unreproducible, kind of hazard. Even if I set my property to an >>> empty >>> >> string I still can't reproduce. >>> >> >>> >> I think I'll wait a few days until the reporter tries with clean >>> >> settings. >>> >> >>> >> Jarek >>> >> >>> >> W dniu 2012-03-30 08:36, Jarek Czekalski pisze: >>> >> > initPLAF will be repeated infinetely if "lf" is incorrect, for >>> >> example >>> >> > null. This fact is not reported but silently workarounded. >>> >> > >>> >> > String lf = getProperty("lookAndFeel"); >>> >> > >>> >> > ... >>> >> > >>> >> > if(lf != null&& lf.length() != 0) >>> >> > UIManager.setLookAndFeel(lf); >>> >> > else if(OperatingSystem.isMacOS()) >>> >> > >>> >> > ... >>> >> > >>> >> > This is code from 4.5.0. >>> >> > >>> >> > Jarek >>> >> > >>> >> > W dniu 2012-03-30 08:04, Alan Ezust pisze: >>> >> >> It seems initPLAF is being called many more times than it >>> >> needs to be >>> >> >> (like once, perhaps?). >>> >> >> I just added a Log message to tell me what PLAF is being >>> >> initialized >>> >> >> in the activity log and I can see it is happening 4 times at >>> >> startup >>> >> >> on linux. >>> >> >> >>> >> >> >>> >> >> On Thu, Mar 29, 2012 at 10:41 PM, Jarek Czekalski >>> >> >> <jar...@po... <mailto:jar...@po...>> >>> >> wrote: >>> >> >>> Guys, could you direct me to the cause of the problem? >>> >> >>> >>> >> >>> bug entry: >>> >> >>> >>> >> >>> https://sourceforge.net/tracker/index.php?func=detail&aid=3512420&group_id=588&atid=565475 >>> >> < >>> https://sourceforge.net/tracker/index.php?func=detail&aid=3512420&group_id=588&atid=565475 >>> > >>> >> >>> log file: >>> >> >>> >>> >> >>> https://sourceforge.net/tracker/download.php?group_id=588&atid=565475&file_id=439684&aid=3512420 >>> >> < >>> https://sourceforge.net/tracker/download.php?group_id=588&atid=565475&file_id=439684&aid=3512420 >>> > >>> >> >>> >>> >> >>> After analyzing the log I see that initPLAF is called. It >>> >> should return >>> >> >>> immediately: >>> >> >>> >>> >> >>> String lf = getProperty("lookAndFeel"); >>> >> >>> if (isStartupDone()&& >>> >> >>> UIManager.getLookAndFeel().getClass().getName().equals(lf)) >>> >> >>> { >>> >> >>> return; >>> >> >>> } >>> >> >>> >>> >> >>> because I guess look and feel is already set up propertly. >>> >> But it goes >>> >> >>> deeper and finally dives into java at line 3668 and ends up >>> in an >>> >> >>> exception. Is it normal that the p&f initialization happens >>> >> so late, >>> >> >>> when user presses ok in a properties pane? >>> >> >>> >>> >> >>> Jarek >>> >> >>> >>> >> >>> >>> >> >>> ------------------------------------------------------------------------------ >>> >> >>> This SF email is sponsosred by: >>> >> >>> Try Windows Azure free for 90 days Click Here >>> >> >>> http://p.sf.net/sfu/sfd2d-msazure >>> >> >>> -- >>> >> >>> ----------------------------------------------- >>> >> >>> jEdit Developers' List >>> >> >>> jEd...@li... >>> >> <mailto:jEd...@li...> >>> >> >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel >>> >> > >>> >> >>> ------------------------------------------------------------------------------ >>> >> > This SF email is sponsosred by: >>> >> > Try Windows Azure free for 90 days Click Here >>> >> > http://p.sf.net/sfu/sfd2d-msazure >>> >> >>> >> >>> ------------------------------------------------------------------------------ >>> >> This SF email is sponsosred by: >>> >> Try Windows Azure free for 90 days Click Here >>> >> http://p.sf.net/sfu/sfd2d-msazure >>> >> -- >>> >> ----------------------------------------------- >>> >> jEdit Developers' List >>> >> jEd...@li... >>> >> <mailto:jEd...@li...> >>> >> https://lists.sourceforge.net/lists/listinfo/jedit-devel >>> >> >>> >> >>> > >>> > >>> > >>> ------------------------------------------------------------------------------ >>> > This SF email is sponsosred by: >>> > Try Windows Azure free for 90 days Click Here >>> > http://p.sf.net/sfu/sfd2d-msazure >>> > >>> > >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF email is sponsosred by: >>> Try Windows Azure free for 90 days Click Here >>> http://p.sf.net/sfu/sfd2d-msazure >>> -- >>> ----------------------------------------------- >>> jEdit Developers' List >>> jEd...@li... >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel >>> >> >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> -- >> ----------------------------------------------- >> jEdit Developers' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-devel >> >> > |
|
From: Matthieu C. <cho...@gm...> - 2012-03-30 18:47:16
|
For information there are also the same kind of bugs when using Mydoggy and changing look & feel. 2012/3/30 Dale Anson <da...@gr...> > Let me review my patch again, it's been a couple of months since I went > through that code. I think it is more often than just a call from main(), I > recall initPLAF is also called on EditBus events (property changes, I > think, but I need to review). I do recall initPLAF is called before the > plugins are loaded, which is what caused the problems with the look and > feel plugin not being able to properly set the look and feel. > > Dale > > > > On Fri, Mar 30, 2012 at 9:35 AM, Jarek Czekalski <jar...@po... > > wrote: > >> Actually initPlaf is called straight from jEdit.main() which is non-edt >> thread. So jedit is based on violating java thread safety principles, >> because it calls many gui methods from main. With your patch applied, >> Dale, setting of l&f is moved after all the initialization, probably >> including initialization of plugins. Maybe that's the way it works for >> the L&F plugin. >> >> Jarek >> >> W dniu 03/30/2012 04:47 PM, Jarek Czekalski pisze: >> > Dale, thanks for the feedback. >> > >> > As I look at the bug report log, the problem seems to happen in EDT. >> > Your patch takes care of a situation where initPLAF is called from >> > non-EDT thread. So it seems unrelated. No code should call initPLAF >> > from non-EDT thread. That's the theory. In practice I can't test it >> > because we didn't manage to reproduce the issue. >> > >> > Jarek >> > >> > W dniu 2012-03-30 16:11, Dale Anson pisze: >> >> Here is a bit more about this. Vampire introduced the change to fix >> >> an issue where the tree controls were not updating when the look and >> >> feel was changed from global options/appearance. This change also >> >> causes problems with the look and feel plugin since the look and feel >> >> was being initialized before the look and feel plugin was even >> >> loaded. I submitted a patch a couple of months ago: >> >> >> >> >> https://sourceforge.net/tracker/?func=detail&aid=3482818&group_id=588&atid=300588 >> >> < >> https://sourceforge.net/tracker/?func=detail&aid=3482818&group_id=588&atid=300588 >> > >> >> >> >> I've been running this patch for quite a while and it takes care of >> >> the issue with the look and feel plugin. I believe it would also fix >> >> this issue. >> >> >> >> Dale >> >> >> >> >> >> >> >> On Fri, Mar 30, 2012 at 1:10 AM, Jarek Czekalski >> >> <jar...@po... <mailto:jar...@po...>> wrote: >> >> >> >> In r19787: >> >> >> >> public static void propertiesChanged() >> >> { >> >> + initPLAF(); >> >> + >> >> initKeyBindings(); >> >> >> >> >> >> This is introduced in 4.5. Seems like this is causing problems >> >> that were >> >> not happening in 4.4. >> >> >> >> Maybe checking for validity of "lookAndFeel" would solve the >> >> problem. I >> >> can make a patch and suggest to try the daily build. This bug may >> be >> >> unreproducible, kind of hazard. Even if I set my property to an >> empty >> >> string I still can't reproduce. >> >> >> >> I think I'll wait a few days until the reporter tries with clean >> >> settings. >> >> >> >> Jarek >> >> >> >> W dniu 2012-03-30 08:36, Jarek Czekalski pisze: >> >> > initPLAF will be repeated infinetely if "lf" is incorrect, for >> >> example >> >> > null. This fact is not reported but silently workarounded. >> >> > >> >> > String lf = getProperty("lookAndFeel"); >> >> > >> >> > ... >> >> > >> >> > if(lf != null&& lf.length() != 0) >> >> > UIManager.setLookAndFeel(lf); >> >> > else if(OperatingSystem.isMacOS()) >> >> > >> >> > ... >> >> > >> >> > This is code from 4.5.0. >> >> > >> >> > Jarek >> >> > >> >> > W dniu 2012-03-30 08:04, Alan Ezust pisze: >> >> >> It seems initPLAF is being called many more times than it >> >> needs to be >> >> >> (like once, perhaps?). >> >> >> I just added a Log message to tell me what PLAF is being >> >> initialized >> >> >> in the activity log and I can see it is happening 4 times at >> >> startup >> >> >> on linux. >> >> >> >> >> >> >> >> >> On Thu, Mar 29, 2012 at 10:41 PM, Jarek Czekalski >> >> >> <jar...@po... <mailto:jar...@po...>> >> >> wrote: >> >> >>> Guys, could you direct me to the cause of the problem? >> >> >>> >> >> >>> bug entry: >> >> >>> >> >> >> https://sourceforge.net/tracker/index.php?func=detail&aid=3512420&group_id=588&atid=565475 >> >> < >> https://sourceforge.net/tracker/index.php?func=detail&aid=3512420&group_id=588&atid=565475 >> > >> >> >>> log file: >> >> >>> >> >> >> https://sourceforge.net/tracker/download.php?group_id=588&atid=565475&file_id=439684&aid=3512420 >> >> < >> https://sourceforge.net/tracker/download.php?group_id=588&atid=565475&file_id=439684&aid=3512420 >> > >> >> >>> >> >> >>> After analyzing the log I see that initPLAF is called. It >> >> should return >> >> >>> immediately: >> >> >>> >> >> >>> String lf = getProperty("lookAndFeel"); >> >> >>> if (isStartupDone()&& >> >> >>> UIManager.getLookAndFeel().getClass().getName().equals(lf)) >> >> >>> { >> >> >>> return; >> >> >>> } >> >> >>> >> >> >>> because I guess look and feel is already set up propertly. >> >> But it goes >> >> >>> deeper and finally dives into java at line 3668 and ends up >> in an >> >> >>> exception. Is it normal that the p&f initialization happens >> >> so late, >> >> >>> when user presses ok in a properties pane? >> >> >>> >> >> >>> Jarek >> >> >>> >> >> >>> >> >> >> ------------------------------------------------------------------------------ >> >> >>> This SF email is sponsosred by: >> >> >>> Try Windows Azure free for 90 days Click Here >> >> >>> http://p.sf.net/sfu/sfd2d-msazure >> >> >>> -- >> >> >>> ----------------------------------------------- >> >> >>> jEdit Developers' List >> >> >>> jEd...@li... >> >> <mailto:jEd...@li...> >> >> >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel >> >> > >> >> >> ------------------------------------------------------------------------------ >> >> > This SF email is sponsosred by: >> >> > Try Windows Azure free for 90 days Click Here >> >> > http://p.sf.net/sfu/sfd2d-msazure >> >> >> >> >> ------------------------------------------------------------------------------ >> >> This SF email is sponsosred by: >> >> Try Windows Azure free for 90 days Click Here >> >> http://p.sf.net/sfu/sfd2d-msazure >> >> -- >> >> ----------------------------------------------- >> >> jEdit Developers' List >> >> jEd...@li... >> >> <mailto:jEd...@li...> >> >> https://lists.sourceforge.net/lists/listinfo/jedit-devel >> >> >> >> >> > >> > >> > >> ------------------------------------------------------------------------------ >> > This SF email is sponsosred by: >> > Try Windows Azure free for 90 days Click Here >> > http://p.sf.net/sfu/sfd2d-msazure >> > >> > >> >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> -- >> ----------------------------------------------- >> jEdit Developers' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-devel >> > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > > |
|
From: Alan E. <ala...@gm...> - 2012-03-30 16:58:10
|
Interesting, I didn't need to touch that class, because it already
showed up in the package summary javadocs. I am not sure why that one
did but none of the ones I changed had short descriptions that
javadoc was able to find.
If it ain't broke, don't fix it.
There are other rules that javadoc can use to find the short
description, if it is easy
for javadoc to figure out. I suppose that class satisfies one of them.
On Fri, Mar 30, 2012 at 1:30 AM, Matthieu Casanova
<cho...@gm...> wrote:
> Hi, are you sure ?
> I just tried with common.gui.JMouseComboBox
>
> it's javadoc starts like this
>
> /**
> * This is a combo-box that allows listeners to be informed of mouse
> * entered and mouse exited events.
> *
> * Note that other mouse events besides MOUSE_ENTERED and MOUSE_EXITED still
>
> and
> This is a combo-box that allows listeners to be informed of mouse entered
> and mouse exited events.
> seems to be used as short description of the class when looking at the
> javadoc of common.gui package.
>
> The short description here stops at the first .
> If I remove the . after event the short description continues until the next
> dot.
> Or are you talking about another place ?
>
> Matthieu
>
> 2012/3/29 Alan Ezust <ala...@gm...>
>>
>> Because it is the "short description" and is what is extracted in the
>> table summaries of the javadoc program.
>> If you look at the javadocs for CommonControls 1.3 versus what is in
>> the SVN trunk, you'll see that there were a lot of empty rectangles
>> before, and now there are not.
>>
>> That is because I put something into the first line immediately after the
>> /**
>>
>> /** Short Description
>> *
>> * Long Description Line1
>> * Long Description Line2
>> * Long Description Line3
>> */
>> class MyClass extends Blah1 implements Blah2 {
>> ...
>> }
>>
>>
>> Please, everyone, get into the habit of using it! Not just for core +
>> plugins, but for all your code.
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> --
>> -----------------------------------------------
>> jEdit Developers' List
>> jEd...@li...
>> https://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>
|
|
From: Dale A. <da...@gr...> - 2012-03-30 16:27:55
|
Let me review my patch again, it's been a couple of months since I went through that code. I think it is more often than just a call from main(), I recall initPLAF is also called on EditBus events (property changes, I think, but I need to review). I do recall initPLAF is called before the plugins are loaded, which is what caused the problems with the look and feel plugin not being able to properly set the look and feel. Dale On Fri, Mar 30, 2012 at 9:35 AM, Jarek Czekalski <jar...@po...>wrote: > Actually initPlaf is called straight from jEdit.main() which is non-edt > thread. So jedit is based on violating java thread safety principles, > because it calls many gui methods from main. With your patch applied, > Dale, setting of l&f is moved after all the initialization, probably > including initialization of plugins. Maybe that's the way it works for > the L&F plugin. > > Jarek > > W dniu 03/30/2012 04:47 PM, Jarek Czekalski pisze: > > Dale, thanks for the feedback. > > > > As I look at the bug report log, the problem seems to happen in EDT. > > Your patch takes care of a situation where initPLAF is called from > > non-EDT thread. So it seems unrelated. No code should call initPLAF > > from non-EDT thread. That's the theory. In practice I can't test it > > because we didn't manage to reproduce the issue. > > > > Jarek > > > > W dniu 2012-03-30 16:11, Dale Anson pisze: > >> Here is a bit more about this. Vampire introduced the change to fix > >> an issue where the tree controls were not updating when the look and > >> feel was changed from global options/appearance. This change also > >> causes problems with the look and feel plugin since the look and feel > >> was being initialized before the look and feel plugin was even > >> loaded. I submitted a patch a couple of months ago: > >> > >> > https://sourceforge.net/tracker/?func=detail&aid=3482818&group_id=588&atid=300588 > >> < > https://sourceforge.net/tracker/?func=detail&aid=3482818&group_id=588&atid=300588 > > > >> > >> I've been running this patch for quite a while and it takes care of > >> the issue with the look and feel plugin. I believe it would also fix > >> this issue. > >> > >> Dale > >> > >> > >> > >> On Fri, Mar 30, 2012 at 1:10 AM, Jarek Czekalski > >> <jar...@po... <mailto:jar...@po...>> wrote: > >> > >> In r19787: > >> > >> public static void propertiesChanged() > >> { > >> + initPLAF(); > >> + > >> initKeyBindings(); > >> > >> > >> This is introduced in 4.5. Seems like this is causing problems > >> that were > >> not happening in 4.4. > >> > >> Maybe checking for validity of "lookAndFeel" would solve the > >> problem. I > >> can make a patch and suggest to try the daily build. This bug may be > >> unreproducible, kind of hazard. Even if I set my property to an > empty > >> string I still can't reproduce. > >> > >> I think I'll wait a few days until the reporter tries with clean > >> settings. > >> > >> Jarek > >> > >> W dniu 2012-03-30 08:36, Jarek Czekalski pisze: > >> > initPLAF will be repeated infinetely if "lf" is incorrect, for > >> example > >> > null. This fact is not reported but silently workarounded. > >> > > >> > String lf = getProperty("lookAndFeel"); > >> > > >> > ... > >> > > >> > if(lf != null&& lf.length() != 0) > >> > UIManager.setLookAndFeel(lf); > >> > else if(OperatingSystem.isMacOS()) > >> > > >> > ... > >> > > >> > This is code from 4.5.0. > >> > > >> > Jarek > >> > > >> > W dniu 2012-03-30 08:04, Alan Ezust pisze: > >> >> It seems initPLAF is being called many more times than it > >> needs to be > >> >> (like once, perhaps?). > >> >> I just added a Log message to tell me what PLAF is being > >> initialized > >> >> in the activity log and I can see it is happening 4 times at > >> startup > >> >> on linux. > >> >> > >> >> > >> >> On Thu, Mar 29, 2012 at 10:41 PM, Jarek Czekalski > >> >> <jar...@po... <mailto:jar...@po...>> > >> wrote: > >> >>> Guys, could you direct me to the cause of the problem? > >> >>> > >> >>> bug entry: > >> >>> > >> > https://sourceforge.net/tracker/index.php?func=detail&aid=3512420&group_id=588&atid=565475 > >> < > https://sourceforge.net/tracker/index.php?func=detail&aid=3512420&group_id=588&atid=565475 > > > >> >>> log file: > >> >>> > >> > https://sourceforge.net/tracker/download.php?group_id=588&atid=565475&file_id=439684&aid=3512420 > >> < > https://sourceforge.net/tracker/download.php?group_id=588&atid=565475&file_id=439684&aid=3512420 > > > >> >>> > >> >>> After analyzing the log I see that initPLAF is called. It > >> should return > >> >>> immediately: > >> >>> > >> >>> String lf = getProperty("lookAndFeel"); > >> >>> if (isStartupDone()&& > >> >>> UIManager.getLookAndFeel().getClass().getName().equals(lf)) > >> >>> { > >> >>> return; > >> >>> } > >> >>> > >> >>> because I guess look and feel is already set up propertly. > >> But it goes > >> >>> deeper and finally dives into java at line 3668 and ends up in > an > >> >>> exception. Is it normal that the p&f initialization happens > >> so late, > >> >>> when user presses ok in a properties pane? > >> >>> > >> >>> Jarek > >> >>> > >> >>> > >> > ------------------------------------------------------------------------------ > >> >>> This SF email is sponsosred by: > >> >>> Try Windows Azure free for 90 days Click Here > >> >>> http://p.sf.net/sfu/sfd2d-msazure > >> >>> -- > >> >>> ----------------------------------------------- > >> >>> jEdit Developers' List > >> >>> jEd...@li... > >> <mailto:jEd...@li...> > >> >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel > >> > > >> > ------------------------------------------------------------------------------ > >> > This SF email is sponsosred by: > >> > Try Windows Azure free for 90 days Click Here > >> > http://p.sf.net/sfu/sfd2d-msazure > >> > >> > ------------------------------------------------------------------------------ > >> This SF email is sponsosred by: > >> Try Windows Azure free for 90 days Click Here > >> http://p.sf.net/sfu/sfd2d-msazure > >> -- > >> ----------------------------------------------- > >> jEdit Developers' List > >> jEd...@li... > >> <mailto:jEd...@li...> > >> https://lists.sourceforge.net/lists/listinfo/jedit-devel > >> > >> > > > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > > > > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > -- > ----------------------------------------------- > jEdit Developers' List > jEd...@li... > https://lists.sourceforge.net/lists/listinfo/jedit-devel > |
|
From: SourceForge.net <no...@so...> - 2012-03-30 15:42:16
|
Patches item #3482818, was opened at 2012-02-01 12:43 Message generated for change (Comment added) made by jarekczek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=3482818&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: general Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dale Anson (daleanson) Assigned to: Nobody/Anonymous (nobody) Summary: Initialization of look and feel Initial Comment: I'd like to get a second opinion on this patch before committing it directly. The issue is the look and feel as set by the look and feel plugin is not restored properly in jEdit 4.5 and 5.0. The main problem is that the look and feel for jEdit is set before the look and feel plugin is loaded, so when jEdit is restarted, the previous look and feel is not available until later, which can cause a long spew of errors in the Activity log. My testing shows the patch does not conflict with the look and feel if set in the Global Options - Appearance, but does allow the look and feel plugin to properly restore the previous look and feel when it is finally loaded. To see this patch work properly with the look and feel plugin, you'll need the look and feel plugin from revision 21042 or later. ---------------------------------------------------------------------- >Comment By: Jarek Czekalski (jarekczek) Date: 2012-03-30 08:42 Message: initPlaf is called from main(), that is from non-edt thread. With this patch a part of gui code is properly put into edt thread, but the rest remains in non-edt. What's worse, SwingUtilities.updateComponentTreeUI(window) loop is then moved in time before setLookAndFeel, while it should definitely come after that. So instead of this patch a more general consideration of usage of awt methods in main should be performed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300588&aid=3482818&group_id=588 |
|
From: Jarek C. <jar...@po...> - 2012-03-30 15:37:09
|
Actually initPlaf is called straight from jEdit.main() which is non-edt thread. So jedit is based on violating java thread safety principles, because it calls many gui methods from main. With your patch applied, Dale, setting of l&f is moved after all the initialization, probably including initialization of plugins. Maybe that's the way it works for the L&F plugin. Jarek W dniu 03/30/2012 04:47 PM, Jarek Czekalski pisze: > Dale, thanks for the feedback. > > As I look at the bug report log, the problem seems to happen in EDT. > Your patch takes care of a situation where initPLAF is called from > non-EDT thread. So it seems unrelated. No code should call initPLAF > from non-EDT thread. That's the theory. In practice I can't test it > because we didn't manage to reproduce the issue. > > Jarek > > W dniu 2012-03-30 16:11, Dale Anson pisze: >> Here is a bit more about this. Vampire introduced the change to fix >> an issue where the tree controls were not updating when the look and >> feel was changed from global options/appearance. This change also >> causes problems with the look and feel plugin since the look and feel >> was being initialized before the look and feel plugin was even >> loaded. I submitted a patch a couple of months ago: >> >> https://sourceforge.net/tracker/?func=detail&aid=3482818&group_id=588&atid=300588 >> <https://sourceforge.net/tracker/?func=detail&aid=3482818&group_id=588&atid=300588> >> >> I've been running this patch for quite a while and it takes care of >> the issue with the look and feel plugin. I believe it would also fix >> this issue. >> >> Dale >> >> >> >> On Fri, Mar 30, 2012 at 1:10 AM, Jarek Czekalski >> <jar...@po... <mailto:jar...@po...>> wrote: >> >> In r19787: >> >> public static void propertiesChanged() >> { >> + initPLAF(); >> + >> initKeyBindings(); >> >> >> This is introduced in 4.5. Seems like this is causing problems >> that were >> not happening in 4.4. >> >> Maybe checking for validity of "lookAndFeel" would solve the >> problem. I >> can make a patch and suggest to try the daily build. This bug may be >> unreproducible, kind of hazard. Even if I set my property to an empty >> string I still can't reproduce. >> >> I think I'll wait a few days until the reporter tries with clean >> settings. >> >> Jarek >> >> W dniu 2012-03-30 08:36, Jarek Czekalski pisze: >> > initPLAF will be repeated infinetely if "lf" is incorrect, for >> example >> > null. This fact is not reported but silently workarounded. >> > >> > String lf = getProperty("lookAndFeel"); >> > >> > ... >> > >> > if(lf != null&& lf.length() != 0) >> > UIManager.setLookAndFeel(lf); >> > else if(OperatingSystem.isMacOS()) >> > >> > ... >> > >> > This is code from 4.5.0. >> > >> > Jarek >> > >> > W dniu 2012-03-30 08:04, Alan Ezust pisze: >> >> It seems initPLAF is being called many more times than it >> needs to be >> >> (like once, perhaps?). >> >> I just added a Log message to tell me what PLAF is being >> initialized >> >> in the activity log and I can see it is happening 4 times at >> startup >> >> on linux. >> >> >> >> >> >> On Thu, Mar 29, 2012 at 10:41 PM, Jarek Czekalski >> >> <jar...@po... <mailto:jar...@po...>> >> wrote: >> >>> Guys, could you direct me to the cause of the problem? >> >>> >> >>> bug entry: >> >>> >> https://sourceforge.net/tracker/index.php?func=detail&aid=3512420&group_id=588&atid=565475 >> <https://sourceforge.net/tracker/index.php?func=detail&aid=3512420&group_id=588&atid=565475> >> >>> log file: >> >>> >> https://sourceforge.net/tracker/download.php?group_id=588&atid=565475&file_id=439684&aid=3512420 >> <https://sourceforge.net/tracker/download.php?group_id=588&atid=565475&file_id=439684&aid=3512420> >> >>> >> >>> After analyzing the log I see that initPLAF is called. It >> should return >> >>> immediately: >> >>> >> >>> String lf = getProperty("lookAndFeel"); >> >>> if (isStartupDone()&& >> >>> UIManager.getLookAndFeel().getClass().getName().equals(lf)) >> >>> { >> >>> return; >> >>> } >> >>> >> >>> because I guess look and feel is already set up propertly. >> But it goes >> >>> deeper and finally dives into java at line 3668 and ends up in an >> >>> exception. Is it normal that the p&f initialization happens >> so late, >> >>> when user presses ok in a properties pane? >> >>> >> >>> Jarek >> >>> >> >>> >> ------------------------------------------------------------------------------ >> >>> This SF email is sponsosred by: >> >>> Try Windows Azure free for 90 days Click Here >> >>> http://p.sf.net/sfu/sfd2d-msazure >> >>> -- >> >>> ----------------------------------------------- >> >>> jEdit Developers' List >> >>> jEd...@li... >> <mailto:jEd...@li...> >> >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel >> > >> ------------------------------------------------------------------------------ >> > This SF email is sponsosred by: >> > Try Windows Azure free for 90 days Click Here >> > http://p.sf.net/sfu/sfd2d-msazure >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> -- >> ----------------------------------------------- >> jEdit Developers' List >> jEd...@li... >> <mailto:jEd...@li...> >> https://lists.sourceforge.net/lists/listinfo/jedit-devel >> >> > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > > |
|
From: Dale A. <da...@gr...> - 2012-03-30 15:32:14
|
I looked at the bug report too and was not able to reproduce the problem. >From the trace in the activity log attached to the bug report, to me it looks like somehow the look and feel is not initialized, so basic things like making a button or a tab throw exceptions. It's hard to analyze without being able to reproduce. Dale On Fri, Mar 30, 2012 at 8:47 AM, Jarek Czekalski <jar...@po...>wrote: > Dale, thanks for the feedback. > > As I look at the bug report log, the problem seems to happen in EDT. Your > patch takes care of a situation where initPLAF is called from non-EDT > thread. So it seems unrelated. No code should call initPLAF from non-EDT > thread. That's the theory. In practice I can't test it because we didn't > manage to reproduce the issue. > > Jarek > > W dniu 2012-03-30 16:11, Dale Anson pisze: > > Here is a bit more about this. Vampire introduced the change to fix an > issue where the tree controls were not updating when the look and feel was > changed from global options/appearance. This change also causes problems > with the look and feel plugin since the look and feel was being initialized > before the look and feel plugin was even loaded. I submitted a patch a > couple of months ago: > > > https://sourceforge.net/tracker/?func=detail&aid=3482818&group_id=588&atid=300588 > > I've been running this patch for quite a while and it takes care of the > issue with the look and feel plugin. I believe it would also fix this issue. > > Dale > > > > On Fri, Mar 30, 2012 at 1:10 AM, Jarek Czekalski <jar...@po... > > wrote: > >> In r19787: >> >> public static void propertiesChanged() >> { >> + initPLAF(); >> + >> initKeyBindings(); >> >> >> This is introduced in 4.5. Seems like this is causing problems that were >> not happening in 4.4. >> >> Maybe checking for validity of "lookAndFeel" would solve the problem. I >> can make a patch and suggest to try the daily build. This bug may be >> unreproducible, kind of hazard. Even if I set my property to an empty >> string I still can't reproduce. >> >> I think I'll wait a few days until the reporter tries with clean settings. >> >> Jarek >> >> W dniu 2012-03-30 08:36, Jarek Czekalski pisze: >> > initPLAF will be repeated infinetely if "lf" is incorrect, for example >> > null. This fact is not reported but silently workarounded. >> > >> > String lf = getProperty("lookAndFeel"); >> > >> > ... >> > >> > if(lf != null&& lf.length() != 0) >> > UIManager.setLookAndFeel(lf); >> > else if(OperatingSystem.isMacOS()) >> > >> > ... >> > >> > This is code from 4.5.0. >> > >> > Jarek >> > >> > W dniu 2012-03-30 08:04, Alan Ezust pisze: >> >> It seems initPLAF is being called many more times than it needs to be >> >> (like once, perhaps?). >> >> I just added a Log message to tell me what PLAF is being initialized >> >> in the activity log and I can see it is happening 4 times at startup >> >> on linux. >> >> >> >> >> >> On Thu, Mar 29, 2012 at 10:41 PM, Jarek Czekalski >> >> <jar...@po...> wrote: >> >>> Guys, could you direct me to the cause of the problem? >> >>> >> >>> bug entry: >> >>> >> https://sourceforge.net/tracker/index.php?func=detail&aid=3512420&group_id=588&atid=565475 >> >>> log file: >> >>> >> https://sourceforge.net/tracker/download.php?group_id=588&atid=565475&file_id=439684&aid=3512420 >> >>> >> >>> After analyzing the log I see that initPLAF is called. It should >> return >> >>> immediately: >> >>> >> >>> String lf = getProperty("lookAndFeel"); >> >>> if (isStartupDone()&& >> >>> UIManager.getLookAndFeel().getClass().getName().equals(lf)) >> >>> { >> >>> return; >> >>> } >> >>> >> >>> because I guess look and feel is already set up propertly. But it goes >> >>> deeper and finally dives into java at line 3668 and ends up in an >> >>> exception. Is it normal that the p&f initialization happens so late, >> >>> when user presses ok in a properties pane? >> >>> >> >>> Jarek >> >>> >> >>> >> ------------------------------------------------------------------------------ >> >>> This SF email is sponsosred by: >> >>> Try Windows Azure free for 90 days Click Here >> >>> http://p.sf.net/sfu/sfd2d-msazure >> >>> -- >> >>> ----------------------------------------------- >> >>> jEdit Developers' List >> >>> jEd...@li... >> >>> https://lists.sourceforge.net/lists/listinfo/jedit-devel >> > >> ------------------------------------------------------------------------------ >> > This SF email is sponsosred by: >> > Try Windows Azure free for 90 days Click Here >> > http://p.sf.net/sfu/sfd2d-msazure >> >> >> ------------------------------------------------------------------------------ >> This SF email is sponsosred by: >> Try Windows Azure free for 90 days Click Here >> http://p.sf.net/sfu/sfd2d-msazure >> -- >> ----------------------------------------------- >> jEdit Developers' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-devel >> > > |
4 messages has been excluded from this view by a project administrator.