You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(29) |
Jun
(24) |
Jul
(17) |
Aug
(39) |
Sep
(6) |
Oct
(11) |
Nov
(14) |
Dec
(21) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(28) |
Feb
(21) |
Mar
(30) |
Apr
(53) |
May
(90) |
Jun
(49) |
Jul
(181) |
Aug
(35) |
Sep
(18) |
Oct
(30) |
Nov
(34) |
Dec
(106) |
2010 |
Jan
(69) |
Feb
(107) |
Mar
(248) |
Apr
(189) |
May
(62) |
Jun
(109) |
Jul
(53) |
Aug
(108) |
Sep
(61) |
Oct
(44) |
Nov
(16) |
Dec
(22) |
2011 |
Jan
(50) |
Feb
(41) |
Mar
(30) |
Apr
(48) |
May
(24) |
Jun
|
Jul
|
Aug
(45) |
Sep
(43) |
Oct
(59) |
Nov
(60) |
Dec
(43) |
2012 |
Jan
(59) |
Feb
(30) |
Mar
(82) |
Apr
(53) |
May
(93) |
Jun
(101) |
Jul
(79) |
Aug
(87) |
Sep
(51) |
Oct
(66) |
Nov
(120) |
Dec
(30) |
2013 |
Jan
(20) |
Feb
(53) |
Mar
(19) |
Apr
(111) |
May
(63) |
Jun
(20) |
Jul
(156) |
Aug
(177) |
Sep
(68) |
Oct
(162) |
Nov
(300) |
Dec
(96) |
2014 |
Jan
(58) |
Feb
(44) |
Mar
(68) |
Apr
(138) |
May
(270) |
Jun
(63) |
Jul
(126) |
Aug
(78) |
Sep
(85) |
Oct
(182) |
Nov
(69) |
Dec
(54) |
2015 |
Jan
(77) |
Feb
(97) |
Mar
(44) |
Apr
(31) |
May
(20) |
Jun
(72) |
Jul
(31) |
Aug
(9) |
Sep
(19) |
Oct
(22) |
Nov
(53) |
Dec
(16) |
2016 |
Jan
(20) |
Feb
(26) |
Mar
(34) |
Apr
(22) |
May
(14) |
Jun
(27) |
Jul
(17) |
Aug
(9) |
Sep
(65) |
Oct
(20) |
Nov
(25) |
Dec
(36) |
2017 |
Jan
(18) |
Feb
(1) |
Mar
(20) |
Apr
(3) |
May
(23) |
Jun
(4) |
Jul
(18) |
Aug
(1) |
Sep
(15) |
Oct
(4) |
Nov
(3) |
Dec
(2) |
2018 |
Jan
(6) |
Feb
(5) |
Mar
(4) |
Apr
|
May
(3) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
(32) |
Oct
(2) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(5) |
Jun
|
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
(6) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
(7) |
Jul
(9) |
Aug
(5) |
Sep
(2) |
Oct
(6) |
Nov
(9) |
Dec
|
2021 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
(1) |
May
(6) |
Jun
|
Jul
(25) |
Aug
|
Sep
(3) |
Oct
(14) |
Nov
|
Dec
|
2023 |
Jan
|
Feb
(12) |
Mar
(6) |
Apr
|
May
(5) |
Jun
(1) |
Jul
(23) |
Aug
(10) |
Sep
(12) |
Oct
|
Nov
(3) |
Dec
(11) |
2024 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(2) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Martin B. / b. <br...@bs...> - 2009-07-27 11:19:57
|
Hi! Just a update about the LXPanel transaltion progress. 20 languages are noted as 100% translated totalling 1.6 million native speakers. French and Greece are jsut outside 100% range with 2 and 10 fuzzy strings. This is relly good progress. Release at will =) lc Done Fuzzy To do Ratio ar 299 0 0 100% da 299 0 0 100% de 299 0 0 100% es 299 0 0 100% hu 299 0 0 100% id 299 0 0 100% it 299 0 0 100% ja 299 0 0 100% nl 299 0 0 100% nn 299 0 0 100% pl 299 0 0 100% pt 299 0 0 100% pt_BR 299 0 0 100% sk 299 0 0 100% sv 299 0 0 100% uk 299 0 0 100% ur 299 0 0 100% ur_PK 299 0 0 100% zh_TW 299 0 0 100% fr 297 2 0 99% el 289 10 0 97% ms 262 27 10 88% sl 259 36 4 87% hr 247 37 15 83% eu 246 36 17 82% af 237 34 28 79% ru 232 53 14 78% fi 224 36 39 75% cs 184 44 71 62% zh_CN 165 55 79 55% et 161 54 84 54% bn_IN 65 5 229 22% ko 58 44 197 19% bg 0 0 299 0% fa 0 0 299 0% gl 0 0 299 0% lt 0 0 299 0% ml 0 0 299 0% nb 0 0 299 0% ps 0 0 299 0% tr 0 0 299 0% vi 0 0 299 0% (as usual ratio is calculated on done divided by total) -- brother |
From: Martin B. / b. <ma...@ba...> - 2009-07-27 11:19:09
|
Hi! Just a update about the LXPanel transaltion progress. 20 languages are noted as 100% translated totalling 1.6 million native speakers. French and Greece are jsut outside 100% range with 2 and 10 fuzzy strings. This is relly good progress. Release at will =) lc Done Fuzzy To do Ratio ar 299 0 0 100% da 299 0 0 100% de 299 0 0 100% es 299 0 0 100% hu 299 0 0 100% id 299 0 0 100% it 299 0 0 100% ja 299 0 0 100% nl 299 0 0 100% nn 299 0 0 100% pl 299 0 0 100% pt 299 0 0 100% pt_BR 299 0 0 100% sk 299 0 0 100% sv 299 0 0 100% uk 299 0 0 100% ur 299 0 0 100% ur_PK 299 0 0 100% zh_TW 299 0 0 100% fr 297 2 0 99% el 289 10 0 97% ms 262 27 10 88% sl 259 36 4 87% hr 247 37 15 83% eu 246 36 17 82% af 237 34 28 79% ru 232 53 14 78% fi 224 36 39 75% cs 184 44 71 62% zh_CN 165 55 79 55% et 161 54 84 54% bn_IN 65 5 229 22% ko 58 44 197 19% bg 0 0 299 0% fa 0 0 299 0% gl 0 0 299 0% lt 0 0 299 0% ml 0 0 299 0% nb 0 0 299 0% ps 0 0 299 0% tr 0 0 299 0% vi 0 0 299 0% (as usual ratio is calculated on done divided by total) |
From: 魏藥/Medical-Wei <med...@gm...> - 2009-07-27 08:27:17
|
Hi all, So, the consequence is: there's no legal way unless we try to let most (or all?) the authors in the wiki agree to convert the license or use the dual-license. Thus, we can ignore the deadline of converting wiki license to CC-By-SA 3.0 from GFDL 1.3 - It doesn't apply to us. Is that right? -- Medical-Wei/魏藥 ---- Please avoid sending me Word or PowerPoint attachments. See: http://www.gnu.org/philosophy/no-word-attachments.html 請儘可能不要寄給我 Microsoft Word 或是 PowerPoint 的附件,我會打不開~>"<。 參照:http://blog.ofset.org/ckhung/index.php?post/081-nodocx |
From: PCMan <pcm...@gm...> - 2009-07-25 04:31:37
|
2009/7/25 Chris Watkins <chr...@ap...>: > > > On Sat, Jul 25, 2009 at 09:28, PCMan <pcm...@gm...> wrote: >> >> The problem is, we don't have the rights to relicense others' work. >> However, it's impossible to contact all the people who had ever edited our >> wiki. >> So how to do it legally? > > Actually, the FSF has solved this problem. The licenses (GFDL as well as CC) > specify that content can be reused under that license or a compatible one. > > Usually they are not compatible, but in this case they are, because after > long negotiations between FSF, CC and the Wikimedia Foundation, FSF released > GFDL 1.3 which has a special provision (section 11 of the license) allowing > work on a wiki it to be relicensed as CC-BY-SA 3.0, as long as it is done by > the end of July. > > This section specifies that the site operator can do it. So, just as you can > upgrade from GFDL 1.2 to 1.3, you can also relicense as CC-BY-SA 3.0 (under > these terms, before this time limit is up). > > Chris Not really. Quote GFDL 1.2: Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. You can choose other versions of the license if the Document specifies that a particular numbered version of this License "or any later version". However, we only specifeid GFDL 1.2 in our wiki, not "1.2 or later version". So, application of GFDL 1.3 is not a legal option. Hence migration to CC-by-SA is impossible. |
From: Chris W. <chr...@ap...> - 2009-07-25 03:53:47
|
On Sat, Jul 25, 2009 at 09:28, PCMan <pcm...@gm...> wrote: > The problem is, we don't have the rights to relicense others' work. > However, it's impossible to contact all the people who had ever edited our > wiki. > So how to do it legally? Actually, the FSF has solved this problem. The licenses (GFDL as well as CC) specify that content can be reused under that license or a compatible one. Usually they are not compatible, but in this case they are, because after long negotiations between FSF, CC and the Wikimedia Foundation, FSF released GFDL 1.3 which has a special provision (section 11 of the license) allowing work on a wiki it to be relicensed as CC-BY-SA 3.0, as long as it is done by the end of July. This section specifies that the site operator can do it. So, just as you can upgrade from GFDL 1.2 to 1.3, you can also relicense as CC-BY-SA 3.0 (under these terms, before this time limit is up). Chris > > > 2009/7/25 Chris Watkins <chr...@ap...>: > > > > 2009/7/22 魏藥/Medical-Wei <med...@gm...> > >> > >> Hi all, > >> Recently, I received some messages about converting the wiki license > >> to CC-By-SA 3.0. However, are there any reason that we must do this? > > > > Most wikis now use CC-BY-SA, including most of the Linux wikis I've > looked > > at. CC-BY-SA is the more standard license for written content. I think > it's > > a good idea to change - but actually the Wikimedia dual-license model is > > even better: > > > > The dual-licensing option used by Wikimedia is probably the best option > for > > a Linux wiki, where there is still some interest in GFDL. It's a little > > complex to explain - see > > http://en.wikipedia.org/wiki/Wikipedia:Licensing_update > > > > In Wikimedia's case, this means that the end-user can choose either > license, > > *except* where someone has added CC-BY-SA-only content to a page, which > > makes that page single licensed. It is the end-user's responsibility to > > check. > > > > In theory GFDL could be chosen instead, so GFDL content could be added, > but > > CC-BY-SA content could not be. As I've said, though, CC-BY-SA is the more > > common license, so I'd suggest this as the default. > > > > So, my suggestion is to use the same variation of a dual-license as > > Wikimedia. > > > > > > In case anyone is wondering, the operator of the wiki can make the > decision > > to change license, until the end-of-July deadline. See > > http://www.gnu.org/copyleft/fdl.html#section11 for this and any other > > details. > > > > If there's any uncertainty about this, with the deadline coming up for > the > > license transition (end of July), then there is a solution to give more > > time: switch to a simple dual license. This means all content is licensed > > under both GFDL and the CC-BY-SA licenses - but we can't add material > from > > other sources (if it's only under one of the licenses). Then when a > decision > > has been made to go with a particular option, it can be switched. > > > > Let me know if anything is unclear. > > > >> > >> About DFSG, documents licensed with GFDL without invariant sections > >> are DFSG-free. > >> > http://wiki.debian.org/DFSGLicenses#GNUFreeDocumentationLicense.28GFDL.29 > >> > >> Thanks, > >> -- > >> Medical-Wei/魏藥 > >> p.s. Chris, We've met in Ecole Cafe :D > > > > I remember you - playing the African drum :-) > > > > > > > > -- > > Chris Watkins > > > > Appropedia.org - Sharing knowledge to build rich, sustainable lives. > > > > identi.ca/appropedia / twitter.com/appropedia > > blogs.appropedia.org > > > > I like this: five.sentenc.es > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Lxde-list mailing list > > Lxd...@li... > > https://lists.sourceforge.net/lists/listinfo/lxde-list > > > > > -- Chris Watkins Appropedia.org - Sharing knowledge to build rich, sustainable lives. identi.ca/appropedia / twitter.com/appropedia blogs.appropedia.org I like this: five.sentenc.es |
From: PCMan <pcm...@gm...> - 2009-07-25 01:28:34
|
The problem is, we don't have the rights to relicense others' work. However, it's impossible to contact all the people who had ever edited our wiki. So how to do it legally? 2009/7/25 Chris Watkins <chr...@ap...>: > > 2009/7/22 魏藥/Medical-Wei <med...@gm...> >> >> Hi all, >> Recently, I received some messages about converting the wiki license >> to CC-By-SA 3.0. However, are there any reason that we must do this? > > Most wikis now use CC-BY-SA, including most of the Linux wikis I've looked > at. CC-BY-SA is the more standard license for written content. I think it's > a good idea to change - but actually the Wikimedia dual-license model is > even better: > > The dual-licensing option used by Wikimedia is probably the best option for > a Linux wiki, where there is still some interest in GFDL. It's a little > complex to explain - see > http://en.wikipedia.org/wiki/Wikipedia:Licensing_update > > In Wikimedia's case, this means that the end-user can choose either license, > *except* where someone has added CC-BY-SA-only content to a page, which > makes that page single licensed. It is the end-user's responsibility to > check. > > In theory GFDL could be chosen instead, so GFDL content could be added, but > CC-BY-SA content could not be. As I've said, though, CC-BY-SA is the more > common license, so I'd suggest this as the default. > > So, my suggestion is to use the same variation of a dual-license as > Wikimedia. > > > In case anyone is wondering, the operator of the wiki can make the decision > to change license, until the end-of-July deadline. See > http://www.gnu.org/copyleft/fdl.html#section11 for this and any other > details. > > If there's any uncertainty about this, with the deadline coming up for the > license transition (end of July), then there is a solution to give more > time: switch to a simple dual license. This means all content is licensed > under both GFDL and the CC-BY-SA licenses - but we can't add material from > other sources (if it's only under one of the licenses). Then when a decision > has been made to go with a particular option, it can be switched. > > Let me know if anything is unclear. > >> >> About DFSG, documents licensed with GFDL without invariant sections >> are DFSG-free. >> http://wiki.debian.org/DFSGLicenses#GNUFreeDocumentationLicense.28GFDL.29 >> >> Thanks, >> -- >> Medical-Wei/魏藥 >> p.s. Chris, We've met in Ecole Cafe :D > > I remember you - playing the African drum :-) > > > > -- > Chris Watkins > > Appropedia.org - Sharing knowledge to build rich, sustainable lives. > > identi.ca/appropedia / twitter.com/appropedia > blogs.appropedia.org > > I like this: five.sentenc.es > > ------------------------------------------------------------------------------ > > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > > |
From: Chris W. <chr...@ap...> - 2009-07-24 20:09:22
|
2009/7/22 魏藥/Medical-Wei <med...@gm...> > Hi all, > Recently, I received some messages about converting the wiki license > to CC-By-SA 3.0. However, are there any reason that we must do this? > Most wikis now use CC-BY-SA, including most of the Linux wikis I've looked at. CC-BY-SA is the more standard license for written content. I think it's a good idea to change - but actually the Wikimedia dual-license model is even better: The dual-licensing option used by Wikimedia is probably the best option for a Linux wiki, where there is still some interest in GFDL. It's a little complex to explain - see http://en.wikipedia.org/wiki/Wikipedia:Licensing_update In Wikimedia's case, this means that the end-user can choose either license, *except* where someone has added CC-BY-SA-only content to a page, which makes that page single licensed. It is the end-user's responsibility to check. In theory GFDL could be chosen instead, so GFDL content could be added, but CC-BY-SA content could not be. As I've said, though, CC-BY-SA is the more common license, so I'd suggest this as the default. So, my suggestion is to use the same variation of a dual-license as Wikimedia. In case anyone is wondering, the operator of the wiki can make the decision to change license, until the end-of-July deadline. See http://www.gnu.org/copyleft/fdl.html#section11 for this and any other details. If there's any uncertainty about this, with the deadline coming up for the license transition (end of July), then there is a solution to give more time: switch to a simple dual license. This means all content is licensed under both GFDL and the CC-BY-SA licenses - but we can't add material from other sources (if it's only under one of the licenses). Then when a decision has been made to go with a particular option, it can be switched. Let me know if anything is unclear. > About DFSG, documents licensed with GFDL without invariant sections > are DFSG-free. > http://wiki.debian.org/DFSGLicenses#GNUFreeDocumentationLicense.28GFDL.29 > > Thanks, > -- > Medical-Wei/魏藥 > p.s. Chris, We've met in Ecole Cafe :D I remember you - playing the African drum :-) -- Chris Watkins Appropedia.org - Sharing knowledge to build rich, sustainable lives. identi.ca/appropedia / twitter.com/appropedia blogs.appropedia.org I like this: five.sentenc.es |
From: Marty J. <mar...@co...> - 2009-07-24 15:48:27
|
I've checked in some changes that fix the systray, or at least they do for me. See the SVN log for the details. There is one little artifact on vertical panels with background image where the background of the tray icon is not properly aligned. This can be fixed after we make sure the changes I just made are stable. I fixed one thing where tray icons for Qt applications were being lost on a 90 degree reorient by using the new GtkOrientation code in 2.16. This happened because the outermost widget was being destroyed and the Qt applications weren't trying to reconnect. GTK applications were reconnecting. For now I've made the new code conditional on 2.16 so it amounts to a known bug on older GTK versions. I would like some input from our distros on whether we should go ahead and increase the GTK requirement to 2.16. |
From: 魏藥/Medical-Wei <med...@gm...> - 2009-07-22 05:43:14
|
Hi all, Recently, I received some messages about converting the wiki license to CC-By-SA 3.0. However, are there any reason that we must do this? About DFSG, documents licensed with GFDL without invariant sections are DFSG-free. http://wiki.debian.org/DFSGLicenses#GNUFreeDocumentationLicense.28GFDL.29 Thanks, -- Medical-Wei/魏藥 p.s. Chris, We've met in Ecole Cafe :D ---- Please avoid sending me Word or PowerPoint attachments. See: http://www.gnu.org/philosophy/no-word-attachments.html 請儘可能不要寄給我 Microsoft Word 或是 PowerPoint 的附件,我會打不開~>"<。 參照:http://blog.ofset.org/ckhung/index.php?post/081-nodocx |
From: Jürgen H. <ju...@ar...> - 2009-07-21 20:26:40
|
On Tue, Jul 21, 2009 at 03:45:52PM -0400, Marty Jack wrote: > If the tray icon is removed 5 ms after being installed, GTK fails to > deliver a "plug-removed" event and we never delete the space it is > taking. Everythin g works reliably at 10 ms. Working on a fix. Damn good bug hunt Marty: I can confirm the timing issue! Jürgen |
From: Marty J. <mar...@co...> - 2009-07-21 19:46:03
|
If the tray icon is removed 5 ms after being installed, GTK fails to deliver a "plug-removed" event and we never delete the space it is taking. Everything works reliably at 10 ms. Working on a fix. Marty Jack wrote: > Something went in and didn't disappear. I know for a fact that gnome-mplayer puts a tray icon there and takes it away immediately. A stress tester sounds like a very good idea. So much for skipping beta. > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Alessandro P. <al...@am...> - 2009-07-21 09:11:09
|
Il giorno lun, 20/07/2009 alle 15.24 -0400, Marty Jack ha scritto: > I am down to nothing I can work on. We have two open issues reported by PCMan: 2821771 where his taskbar icons are clipped, and sporadic system tray damage. No one else has reported anything similar, and I am not experiencing the problems. I don't know how many people on the list or forum are running SVN, so I don't know how widespread the issue might be. I would encourage PCMan to debug these a little or possibly characterize in more detail when the tray icon damage happens. I would like to add that sometimes I get a similar behaviour in gnome-panel. I am not able to reproduce it programmatically, but it seems like an icon in the systray leaves about 100 pixels "empty" when removed (even if the icon only measures 24 pixels). Could it be a particular gtk version bug? I have 2.16.1 installed. Bye. -- Alessandro Pellizzari |
From: admin <dla...@gm...> - 2009-07-21 06:10:38
|
On 7/21/09, PCMan <pcm...@gm...> wrote: > Thank you for the great work! > Is it possible to replace regex.h with GRegEx provided by glib? Since > glib already includes pcre, there is no need to use yet another regex > lib. Ok, I changed it, the new patch is in the attachment, I'll post it too to its page in the patches section. > > On Tue, Jul 21, 2009 at 2:57 AM, admin<dla...@gm...> wrote: >> Hi, I made a small patch for LXTask adding a system information dialog to >> it. >> >> What I wanted to do here was to ask you to test and evaluate the patch >> (link : >> https://sourceforge.net/tracker/?func=detail&atid=894871&aid=2824236&group_id=180858, >> or the attachment). >> >> If something doesn't work correctly, please also post your >> /proc/cpuinfo, /proc/sys/kernel/osrelease, and >> /proc/sys/kernel/ostype. >> >> Thanks! >> >> Regards, >> Jan >> >> ------------------------------------------------------------------------------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in prizes! For a limited time, >> vendors submitting new applications to BlackBerry App World(TM) will have >> the opportunity to enter the BlackBerry Developer Challenge. See full >> prize >> details at: http://p.sf.net/sfu/Challenge >> _______________________________________________ >> Lxde-list mailing list >> Lxd...@li... >> https://lists.sourceforge.net/lists/listinfo/lxde-list >> >> > -- http://houbysoft.com/ - please visit my website and download some programs! ;) http://open-notes.net/ - a free notebook online! |
From: Marty J. <mar...@co...> - 2009-07-21 05:30:09
|
Something went in and didn't disappear. I know for a fact that gnome-mplayer puts a tray icon there and takes it away immediately. A stress tester sounds like a very good idea. So much for skipping beta. |
From: PCMan <pcm...@gm...> - 2009-07-21 02:36:43
|
Thank you for the great work! Is it possible to replace regex.h with GRegEx provided by glib? Since glib already includes pcre, there is no need to use yet another regex lib. On Tue, Jul 21, 2009 at 2:57 AM, admin<dla...@gm...> wrote: > Hi, I made a small patch for LXTask adding a system information dialog to it. > > What I wanted to do here was to ask you to test and evaluate the patch > (link : https://sourceforge.net/tracker/?func=detail&atid=894871&aid=2824236&group_id=180858, > or the attachment). > > If something doesn't work correctly, please also post your > /proc/cpuinfo, /proc/sys/kernel/osrelease, and > /proc/sys/kernel/ostype. > > Thanks! > > Regards, > Jan > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > > |
From: Marty J. <mar...@co...> - 2009-07-20 19:24:34
|
That is really nice work on the translation. It should be noted that the remaining above-the-line are one or two fuzzy messages. I am down to nothing I can work on. We have two open issues reported by PCMan: 2821771 where his taskbar icons are clipped, and sporadic system tray damage. No one else has reported anything similar, and I am not experiencing the problems. I don't know how many people on the list or forum are running SVN, so I don't know how widespread the issue might be. I would encourage PCMan to debug these a little or possibly characterize in more detail when the tray icon damage happens. We need to discuss whether a beta is warranted and if so how long and who we expect will run the beta who has not been willing to run SVN. We have at least a few very happy users of SVN at this point who have been speaking up in the forum. The release notes are written http://forum.lxde.org/viewtopic.php?f=21&t=521 and would only need to be reformatted a little into a blog post when the release happens. |
From: Martin B. <br...@bs...> - 2009-07-20 18:59:47
|
On Sat, 18 Jul 2009, Martin Bagge wrote: Good work! And by adding the usual number of speakers for each language we cover 1.476 million native speakers (that includes English). One could only dream about the number for secondary languages! If we an get some updates from thos in close range it would add another 250 million speakers. Idonesian (id) Portugese (pt) Urdu (ur, ur_PK) French (fr) (added in CC for alert) If someone reading this are willing to do updates in the languages below 90% done (there is an empty line just before) please drop a note to the ML telling us so, as we are approaching a release it would be sad to release just before a update was put in the archive. > As of today (1440 CEST (UTC+2)) the numbers are these. This reflects r1860. 20:41 CEST. lc done fuzzy not started Ratio ar 299 0 0 100,00% da 299 0 0 100,00% de 299 0 0 100,00% es 299 0 0 100,00% hu 299 0 0 100,00% it 299 0 0 100,00% ja 299 0 0 100,00% nl 299 0 0 100,00% pl 299 0 0 100,00% pt_BR 299 0 0 100,00% sk 299 0 0 100,00% sv 299 0 0 100,00% uk 299 0 0 100,00% zh_TW 299 0 0 100,00% id 298 1 0 99,67% pt 298 1 0 99,67% ur 298 1 0 99,67% ur_PK 298 1 0 99,67% fr 297 2 0 99,33% ms 262 27 10 87,63% el 260 19 20 86,96% sl 259 36 4 86,62% hr 247 37 15 82,61% eu 246 36 17 82,27% af 237 34 28 79,26% ru 232 53 14 77,59% fi 224 36 39 74,92% cs 184 44 71 61,54% zh_CN 165 55 79 55,18% et 161 54 84 53,85% ko 58 44 197 19,40% bn_IN 20 4 275 6,69% bg 0 0 299 0,00% fa 0 0 299 0,00% gl 0 0 299 0,00% lt 0 0 299 0,00% ml 0 0 299 0,00% nb 0 0 299 0,00% nn 0 0 299 0,00% ps 0 0 299 0,00% tr 0 0 299 0,00% vi 0 0 299 0,00% (ratio column is done divided by total) -- /brother http://frakalendern.se Bruce Schneier can slam a logic gate. |
From: admin <dla...@gm...> - 2009-07-20 18:57:06
|
Hi, I made a small patch for LXTask adding a system information dialog to it. What I wanted to do here was to ask you to test and evaluate the patch (link : https://sourceforge.net/tracker/?func=detail&atid=894871&aid=2824236&group_id=180858, or the attachment). If something doesn't work correctly, please also post your /proc/cpuinfo, /proc/sys/kernel/osrelease, and /proc/sys/kernel/ostype. Thanks! Regards, Jan |
From: Andrew L. <an...@li...> - 2009-07-19 16:57:21
|
Hi, For my opinion, this platform sounds cool for authors to by pass distros maintainer and directly to users. But in debian we need someone responsible for the packaging, so we will repackage anyway for officially use for debian. If you want to provide debian support, please use directory name other than debian/. Cause it would cause more work for me as I would have to remove that while I am packaging. :) Thanks, -Andrew Christoph Wickert wrote: > Hi, > > apologies for the late reply. > > Am Donnerstag, den 16.07.2009, 14:12 +0200 schrieb Andrea Florio: >> Christoph Wickert ha scritto: >> >>> OBS is good for developers to provide packages for different >>> distributions without to much hassle. However the quality of these >>> packages is not really good in most cases IMO. >> The package quality is due to packager to to OBS itsealf, > ^^^ > I guess the words "and not" are missing here, right? It depends on the > packager, not on OBS. That's exactly what I said: People focus on a > particular distro and it's impossible to know the guidelines and > oddities of each and every other Linux. > >> obs just >> provide a chroot enviroment where build you packages plus some post >> build, quality checks on the package (spec file for example) and code, >> like the gcc lint i post or checks on .desktop and init scripts and so on. > > Yes, and these things are also distribution specific. They depend on the > versions of gcc and desktop-file-utils. What causes an error on SUSE may > be perfectly fine for Fedora - and contrariwise. > >>> People focus on their favorite distribution, but don't really care about others. For example I >>> focus on rpm and it's been a while since I last build a deb. So I have >>> no idea if/how Debian's packaging guidelines have changed in the >>> meantime. >> You can just write the spec file for your own distribution, following >> you distro guidelines, (really we can use distro specific obs macros, >> and create a multidistro spec file, for example: >> >> %if 0%{?fedora_version} == 11 >> fedora 11 stuffs here >> %endif >> >> %if 0%{?suse_version} == 1110 >> suse 11.1 stuffs here >> %endif ) > > This still is based on the assumption that a packager knows all the > different guidelines from all distributions. I doubt that this is > possible. > >> more infos here: >> >> http://en.opensuse.org/Build_Service/cross_distribution_package_how_to > > I know how to use macros, but since I'm not using SUSE I hardly don't > know anything about the distro itself, so I'm not a good SUSE packager. > And I have no SUSE here, so I have no idea what these macros resolve to. > > Let me give you some more examples: > * package names and naming guidelines > * License tag: On SUSE it's ok to use "GPL" for the License tag. > On Fedora we are much stricter about licenses, because differen > versions of licenses are not compatible. So we devide into > GPLv2, GPLv2+, GPLv3 and GPLv3+. > * Tags in genereal, e.g. "Group": Fedora and SUSE use different > values for them. > * Categories for menu entries and and the whole menu structure > * Scriptlets: In Fedora we use a lot of scriptlets not used in > SUSE, for example for desktop-file-install. On SUSE this is not > needed, because SUSE has %suse_update_desktop_file. > > If you take all these differences into account, you will end up with a > spec with lots of conditionals, which is way harder to maintain than a > distribution specific spec/rules. What's the worth of a cross-distro > spec file if we already have people working on the different > distributions? > >>> We are in the lucky position to have dedicated package maintainers for >>> all distributions you mentioned, so packages are available in the >>> distributions itself and users don't need to add another package >>> repository of unknown quality. >> I agree (in part), if lxde is provided into MAIN repos like mandriva, >> than you can skip it, but if you are any way supposed to add a specific >> repo, i think instead, that if all packagers works together, they >> (including me) will have a greate chance to improve packages and use >> other distro patches (if valid). > > Then these patches are no longer distro-specific and should be > upstreamed into LXDE. > >> In other words, The packagers are still >> the same, then the packages quality is still the same, > > No, because a packager may be an excellent on Debian but lousy on > Mandriva. > >> but because all >> packagers works together all of them can help each others and improve >> all packages. > > What should this look like? If we had 5 people working on a spec file > for all rpm-based distributions, these people need to agree on all the > changes. Changes need to be discussed first, which requires knowledge > about every single distro and slows down the whole process dramatically. > Too many cooks spoil the broth. > > Regarding quality: What kind of QA does OBS offer? Is there an testing > repository for users to test? Is there a way for users to give feedback. > >>> To summ it up: OSM is a good tool, but LXDE is happy to not really need >>> it at the current point. >>> >> OSM? can you explain it better? what's that? > > A typo. :( I meant OSB. I don't see what additional benefit OSB offers > to LXDE. If we were looking for maintainers, I would agree with you, but > LXDE already is available in most distros. Please tell me which one is > missing in your opinion. > > I know for example RHEL is missing, but this is mostly due to the GTK > version, so there is nothing OSB could do about it. > > Please don't get me wrong: I value your interest and your suggestion and > I think that OSB is a good tool for some use cases but I doubt it is for > LXDE. > > Regards, > Christoph > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list |
From: Christoph W. <chr...@go...> - 2009-07-19 14:09:41
|
Hi, apologies for the late reply. Am Donnerstag, den 16.07.2009, 14:12 +0200 schrieb Andrea Florio: > Christoph Wickert ha scritto: > > > OBS is good for developers to provide packages for different > > distributions without to much hassle. However the quality of these > > packages is not really good in most cases IMO. > > The package quality is due to packager to to OBS itsealf, ^^^ I guess the words "and not" are missing here, right? It depends on the packager, not on OBS. That's exactly what I said: People focus on a particular distro and it's impossible to know the guidelines and oddities of each and every other Linux. > obs just > provide a chroot enviroment where build you packages plus some post > build, quality checks on the package (spec file for example) and code, > like the gcc lint i post or checks on .desktop and init scripts and so on. Yes, and these things are also distribution specific. They depend on the versions of gcc and desktop-file-utils. What causes an error on SUSE may be perfectly fine for Fedora - and contrariwise. > > People focus on their favorite distribution, but don't really care about others. For example I > > focus on rpm and it's been a while since I last build a deb. So I have > > no idea if/how Debian's packaging guidelines have changed in the > > meantime. > > You can just write the spec file for your own distribution, following > you distro guidelines, (really we can use distro specific obs macros, > and create a multidistro spec file, for example: > > %if 0%{?fedora_version} == 11 > fedora 11 stuffs here > %endif > > %if 0%{?suse_version} == 1110 > suse 11.1 stuffs here > %endif ) This still is based on the assumption that a packager knows all the different guidelines from all distributions. I doubt that this is possible. > more infos here: > > http://en.opensuse.org/Build_Service/cross_distribution_package_how_to I know how to use macros, but since I'm not using SUSE I hardly don't know anything about the distro itself, so I'm not a good SUSE packager. And I have no SUSE here, so I have no idea what these macros resolve to. Let me give you some more examples: * package names and naming guidelines * License tag: On SUSE it's ok to use "GPL" for the License tag. On Fedora we are much stricter about licenses, because differen versions of licenses are not compatible. So we devide into GPLv2, GPLv2+, GPLv3 and GPLv3+. * Tags in genereal, e.g. "Group": Fedora and SUSE use different values for them. * Categories for menu entries and and the whole menu structure * Scriptlets: In Fedora we use a lot of scriptlets not used in SUSE, for example for desktop-file-install. On SUSE this is not needed, because SUSE has %suse_update_desktop_file. If you take all these differences into account, you will end up with a spec with lots of conditionals, which is way harder to maintain than a distribution specific spec/rules. What's the worth of a cross-distro spec file if we already have people working on the different distributions? > > We are in the lucky position to have dedicated package maintainers for > > all distributions you mentioned, so packages are available in the > > distributions itself and users don't need to add another package > > repository of unknown quality. > > I agree (in part), if lxde is provided into MAIN repos like mandriva, > than you can skip it, but if you are any way supposed to add a specific > repo, i think instead, that if all packagers works together, they > (including me) will have a greate chance to improve packages and use > other distro patches (if valid). Then these patches are no longer distro-specific and should be upstreamed into LXDE. > In other words, The packagers are still > the same, then the packages quality is still the same, No, because a packager may be an excellent on Debian but lousy on Mandriva. > but because all > packagers works together all of them can help each others and improve > all packages. What should this look like? If we had 5 people working on a spec file for all rpm-based distributions, these people need to agree on all the changes. Changes need to be discussed first, which requires knowledge about every single distro and slows down the whole process dramatically. Too many cooks spoil the broth. Regarding quality: What kind of QA does OBS offer? Is there an testing repository for users to test? Is there a way for users to give feedback. > > To summ it up: OSM is a good tool, but LXDE is happy to not really need > > it at the current point. > > > > OSM? can you explain it better? what's that? A typo. :( I meant OSB. I don't see what additional benefit OSB offers to LXDE. If we were looking for maintainers, I would agree with you, but LXDE already is available in most distros. Please tell me which one is missing in your opinion. I know for example RHEL is missing, but this is mostly due to the GTK version, so there is nothing OSB could do about it. Please don't get me wrong: I value your interest and your suggestion and I think that OSB is a good tool for some use cases but I doubt it is for LXDE. Regards, Christoph |
From: Alessandro P. <al...@am...> - 2009-07-19 05:06:26
|
Il giorno ven, 17/07/2009 alle 16.35 +0200, Cilyan Olowen ha scritto: > - Font size is dependent on the resolution used. This is (at first > glance) a problem in the configuration of X (something like > "DisplaySize") not LXDE. Of course GNOME has a fix for that, but keep > in mind that it is a workaround that works only for itself. I think the workaround is in gtk, and I also think that managing fonts should be a desktop manager work, so lxde should have a font manager. But I would put this in "low priority". > - ACPI already has a bunch of scripts that are read to react to > events. They are often run as root, but many actions related on events > imply the whole system (close lid => switch off screen or suspend, > power button => reboot, special buttons for flat panel that often > deals system wide with the graphic card, volume up/down that affect > the whole audio system...). Probably LXDE could provide a tool for > other special buttons that trigger actions in user space only, but I > know such tools already exists. So maybe just a little lifting has to > be done to them. On the other hand, application itself should do a big > job in this issue, such as lxmusic that should react on multimedia > buttons (I don't know if it does already). Thos actions should be configurable from the desktop manager, too. Maybe a system-level daemon but controllable from the GUI, through dbus, or something similar. I think it is a lot of work, so this too could be low priority. > - Evolution is a great project, but it's big and full of extra > features that many won't ever need. You may want to use a calendar out > of a mail reader, or a mail reader without calendar. LXDE tries to > keep lightweight so it can't integrate well out of the box with heavy > projects that require huge libraries. Of course, plugins are here to > answer this kind of issues. What Ogley says is integrating in a panel applet the calendar notifications of evolution. You don't need to depend on the full evolution for this, but only on evolution-data-server. I remember pimlico is already interfacing to it, and using only e-d-s eith lightweight applications (todo, calendar, etc.), and a new lightweight software is being written to use only mail. There could be a "third party applet" to do that. > - Automount is IMHO not the task of a desktop environment. pmount, hal > and udev are designed for this kind of task. I don't agree. The desktop file manager should react and inform the user that a new device has been attached. I think the gnome-volume-manager has nearly perfect support for this. I love to be able to configure every operation for every type of hotplug device. This (together with gvfs) should be high priority, because, IMHO, keeps a lot of people away from LXDE (me included... :/ ) Just my 2 cents... :) Bye. |
From: Alessandro P. <al...@am...> - 2009-07-19 05:06:09
|
Il giorno sab, 18/07/2009 alle 08.53 -0400, Marty Jack ha scritto: > Does it count as a string change that upsets your work if I reuse a string that is already there? It should be "transparent", but beware that some languages use different words based on context, where english sometimes uses the same word with slightly different meaning (think of "get"... ). As for me, just let us know when the strings DB is "complete" and give us some days before release to finish translations. Bye. |
From: admin <dla...@gm...> - 2009-07-18 21:26:45
|
Hi everyone, I am new to this list so I hope I am sending the patch to the place I should. If not please feel free to redirect me somewhere :) Now about the patch: it's a very small patch for lxtask, allowing users to set the refresh rate at runtime, not only in the compile-time REFRESH_INTERVAL. I think it can be quite useful, especially when LXDE is aimed at older PCs, which don't necesserily have the possibility to update the tasks every second as is the default. For example on my old laptop it ran a lot smoother if I set the refresh rate to say 3-4 seconds. In the .tar.gz I attached are files main.c, functions.c, and interface.c which I edited and should go to /lxtask/src/. I hope you'll like it and include it in the next version :) Regards and thanks for the great work so far, Jan Dlabal |
From: Arne B. <ar...@ke...> - 2009-07-18 14:45:04
|
I also think that using a small decent overlay would be the ideal solution. That way we inform people about a problem but dont break the worflow with a popup message he cant even to something about. Arne PCMan schrieb: > Maybe a notification sent to notification daemon or systray balloon > popup can do it? > Anyways popup error dialogs is not a good idea. A transient error > message displayed over the image like an OSD for several seconds might > be good, I think. > > On Sat, Jul 18, 2009 at 8:53 PM, Martin Bagge<br...@bs...> wrote: > >> On Sat, 18 Jul 2009, Marty Jack wrote: >> >> >>> Do the other viewers you mentioned put up that info box or do they silently ignore the file? >>> >> iirc they just skip. My usability principles are a bit rusty but I think >> it's better to let the user know that a file was skipped if we can do >> that. Opening a directory with the intension to view all files and just >> one shows could be a bit awkward. I am not sure what path would be the >> best here, as long as it's not the ugly error box we have now I think we >> are close =) >> >> -- >> /brother >> http://frakalendern.se >> Bruce Schneier's tears can burn holes through an OpenBSD firewall. Lucky for us, Bruce Schneier never cries. >> >> ------------------------------------------------------------------------------ >> Enter the BlackBerry Developer Challenge >> This is your chance to win up to $100,000 in prizes! For a limited time, >> vendors submitting new applications to BlackBerry App World(TM) will have >> the opportunity to enter the BlackBerry Developer Challenge. See full prize >> details at: http://p.sf.net/sfu/Challenge >> _______________________________________________ >> Lxde-list mailing list >> Lxd...@li... >> https://lists.sourceforge.net/lists/listinfo/lxde-list >> >> > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Alessandro P. <ale...@gm...> - 2009-07-18 13:17:08
|
Il giorno sab, 18/07/2009 alle 08.53 -0400, Marty Jack ha scritto: > Does it count as a string change that upsets your work if I reuse a string that is already there? It should be "transparent", but beware that some languages use different words based on context, where english sometimes uses the same word with slightly different meaning (think of "get"... ). As for me, just let us know when the strings DB is "complete" and give us some days before release to finish translations. Bye. |