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: dgod <dgo...@gm...> - 2010-06-11 01:27:38
|
don't worry about it, there are no relation with lxsession, the only thing that in the new lxdm is some function have a lxsession name prefix, they used to manage multiuser login and so on. 2010/6/11 Julien Lavergne <gi...@ub...> > Hi, > > I'll take the opportunity to add also 2 comments about lxdm. > > I saw that lxdm is now tied to lxsession for user management. It's > interesting for LXDE users, but for people using XFCE for example, it's > not really nice because XFCE have already a session manager. > If it's possible, I think it should be generic enough to work with all > session manager. > > I also met an Ubuntu developers which began to work on a lightweight > display manager. It's not finished, but I think some code could be > shared : https://code.edge.launchpad.net/~robert-ancell/lightdm/trunk<https://code.edge.launchpad.net/%7Erobert-ancell/lightdm/trunk> > > Regards, > Julien Lavergne > > Le jeudi 10 juin 2010 à 20:41 +0200, Guido Berhoerster a écrit : > > Hello, > > > > as discussed on IRC I'll list of issues found the current > > development version of lxdm. > > > > The most serious problem is the new signal handling code. > > Although it is somewhat an improvement over the previously > > completely broken approach of cleaning up from within the signal > > handler with lots of non-async safe code, it has several > > vulnerabilities primarily related to the usage of sockets for > > signal handling and communicating between the greeter and daemon. > > > > Firstly, the socket is created in /tmp with a well known name > > allowing for a simple DOS attack, any user can just mkdir > > /tmp/lxdm.sock and lxdm won't start any more. > > > > Secondly, it does try to unlink before binding the socket which > > leads to a race condition creating another possibility for DOS > > attacks. > > > > Thirdly, the socket is created world writable so any user can > > just delete it anyway. > > > > Avoiding this is Unix system programming 101 so my only > > suggestion (as I have stated before) is to use an anonymous pipe > > for signal handling (i.e. the self-pipe trick) and get rid of the > > socket altogether. For IPC there are better methods such as > > DBus. While I acknowledge that the code is under development, > > stuff like this should IMO never go into a public repository. > > > > The new signal handling code has also introduced a new problem > > with spawning the X server, I havent looked at it closely, but > > what happens is that when the Xserver fails, lxdm seems to get > > stuck in a infinite loop which cannot even be interrupted through > > a SIGTERM or SIGINT. > > > > Another rarther annoying problem is that lxdm currently does not > > redirect stderr/stdout so that spawned programs such a the X > > server spew their output to the console, such output should go to > > a separate logfile. > > > > Login/logut scripts are currently rather useless because they are > > called without USER/LOGNAME, HOME, and SHELL in the environment > > (as GDM/KDM do) it is thus impossible to do anything that > > requires kwnoledge of the user logging in or out such as > > adding/removing utmp from these scripts. Fixing this should be > > easy with the new session object. > > > > There is lots of generic code which can and should be replaced by > > glib functions, that e.g. includes logging (glib includes logging > > functionality allowing for different log levels and debug output) > > and the rather bizarre way of commandline option parsing. Some > > amount of code handling sockets (if this has to be kept) can also > > be replaced with GIO functionality. > > > > Most of the paths are hardcoded and should probably be replaced > > with proper macros making the life of packagers easier. > > > > That's all for now, there are probably other issues not in the > > above list. > > > > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Julien L. <gi...@ub...> - 2010-06-10 21:22:48
|
Hi, I'll take the opportunity to add also 2 comments about lxdm. I saw that lxdm is now tied to lxsession for user management. It's interesting for LXDE users, but for people using XFCE for example, it's not really nice because XFCE have already a session manager. If it's possible, I think it should be generic enough to work with all session manager. I also met an Ubuntu developers which began to work on a lightweight display manager. It's not finished, but I think some code could be shared : https://code.edge.launchpad.net/~robert-ancell/lightdm/trunk Regards, Julien Lavergne Le jeudi 10 juin 2010 à 20:41 +0200, Guido Berhoerster a écrit : > Hello, > > as discussed on IRC I'll list of issues found the current > development version of lxdm. > > The most serious problem is the new signal handling code. > Although it is somewhat an improvement over the previously > completely broken approach of cleaning up from within the signal > handler with lots of non-async safe code, it has several > vulnerabilities primarily related to the usage of sockets for > signal handling and communicating between the greeter and daemon. > > Firstly, the socket is created in /tmp with a well known name > allowing for a simple DOS attack, any user can just mkdir > /tmp/lxdm.sock and lxdm won't start any more. > > Secondly, it does try to unlink before binding the socket which > leads to a race condition creating another possibility for DOS > attacks. > > Thirdly, the socket is created world writable so any user can > just delete it anyway. > > Avoiding this is Unix system programming 101 so my only > suggestion (as I have stated before) is to use an anonymous pipe > for signal handling (i.e. the self-pipe trick) and get rid of the > socket altogether. For IPC there are better methods such as > DBus. While I acknowledge that the code is under development, > stuff like this should IMO never go into a public repository. > > The new signal handling code has also introduced a new problem > with spawning the X server, I havent looked at it closely, but > what happens is that when the Xserver fails, lxdm seems to get > stuck in a infinite loop which cannot even be interrupted through > a SIGTERM or SIGINT. > > Another rarther annoying problem is that lxdm currently does not > redirect stderr/stdout so that spawned programs such a the X > server spew their output to the console, such output should go to > a separate logfile. > > Login/logut scripts are currently rather useless because they are > called without USER/LOGNAME, HOME, and SHELL in the environment > (as GDM/KDM do) it is thus impossible to do anything that > requires kwnoledge of the user logging in or out such as > adding/removing utmp from these scripts. Fixing this should be > easy with the new session object. > > There is lots of generic code which can and should be replaced by > glib functions, that e.g. includes logging (glib includes logging > functionality allowing for different log levels and debug output) > and the rather bizarre way of commandline option parsing. Some > amount of code handling sockets (if this has to be kept) can also > be replaced with GIO functionality. > > Most of the paths are hardcoded and should probably be replaced > with proper macros making the life of packagers easier. > > That's all for now, there are probably other issues not in the > above list. > |
From: Julien L. <gi...@ub...> - 2010-06-10 21:13:50
|
Le jeudi 10 juin 2010 à 12:45 +0800, PCMan a écrit : > Any comments? I think it's important to release often. Even if it's not complete, release something will bring users, feedbacks, and maybe developers/patches. Waiting for pcmanfm to be complete may be long. No software is perfect, and I think for a rewrite, pcmanfm is quite in a good state. Also, you could branch actual git trunk to 1.0 and commit only bug fixes, and share patches with trunk, where development continue. Regards, Julien Lavergne |
From: Guido B. <gui...@be...> - 2010-06-10 18:39:52
|
Hello, as discussed on IRC I'll list of issues found the current development version of lxdm. The most serious problem is the new signal handling code. Although it is somewhat an improvement over the previously completely broken approach of cleaning up from within the signal handler with lots of non-async safe code, it has several vulnerabilities primarily related to the usage of sockets for signal handling and communicating between the greeter and daemon. Firstly, the socket is created in /tmp with a well known name allowing for a simple DOS attack, any user can just mkdir /tmp/lxdm.sock and lxdm won't start any more. Secondly, it does try to unlink before binding the socket which leads to a race condition creating another possibility for DOS attacks. Thirdly, the socket is created world writable so any user can just delete it anyway. Avoiding this is Unix system programming 101 so my only suggestion (as I have stated before) is to use an anonymous pipe for signal handling (i.e. the self-pipe trick) and get rid of the socket altogether. For IPC there are better methods such as DBus. While I acknowledge that the code is under development, stuff like this should IMO never go into a public repository. The new signal handling code has also introduced a new problem with spawning the X server, I havent looked at it closely, but what happens is that when the Xserver fails, lxdm seems to get stuck in a infinite loop which cannot even be interrupted through a SIGTERM or SIGINT. Another rarther annoying problem is that lxdm currently does not redirect stderr/stdout so that spawned programs such a the X server spew their output to the console, such output should go to a separate logfile. Login/logut scripts are currently rather useless because they are called without USER/LOGNAME, HOME, and SHELL in the environment (as GDM/KDM do) it is thus impossible to do anything that requires kwnoledge of the user logging in or out such as adding/removing utmp from these scripts. Fixing this should be easy with the new session object. There is lots of generic code which can and should be replaced by glib functions, that e.g. includes logging (glib includes logging functionality allowing for different log levels and debug output) and the rather bizarre way of commandline option parsing. Some amount of code handling sockets (if this has to be kept) can also be replaced with GIO functionality. Most of the paths are hardcoded and should probably be replaced with proper macros making the life of packagers easier. That's all for now, there are probably other issues not in the above list. -- Guido Berhoerster |
From: Josef R. <jre...@su...> - 2010-06-10 14:23:34
|
OK, I get test to work(attached - libfm really need better documentation!). Bad think is that it doesn't show where is problem with double slash, as it works in this test case. Could I push it? Josef Josef Reidinger write: > Hi, > tests is good idea. I try to create one based on glib testing framework. Patch is attached and if you have any question feel free to ask. Only think which I cannot solve and maybe you know is how to properly link it? (now it complain about _fm_path_init() not linked, which is quite strange for me). Also catching changes in code which cause relink of test doesn't work now (but it is not critical, just touch test file). > > Josef > > > > Actually that part is quite problematic and sometimes causes crashes. > > I'd like to create a unit test for fm_path_new_xxx but I don't really > > know how to do it correctly and make the test integrated with the > > building process. Any suggestions? > > > > 2010/6/10 Josef Reidinger <jre...@su...>: > > > Hi, > > > I check where is problem with bug 3012747 [1]. And found that implementation of libfm doesn't expect more then one beginning slash in its structure. I can fix it[attachment] with resolving it same as '/' , but I am not sure if it is correct as posix specify it as it can be implementation specific handling (that is reason why I am not commit it). Do you thing that it is expected behavior or on some posix systems is expected different behavior for path like //tmp ??? > > > > > > Josef > > > > > > [1] http://sourceforge.net/tracker/?func=detail&aid=3012747&group_id=156956&atid=801864 > > > -- > > > Josef Reidinger > > > YaST team > > > maintainer of perl-Bootloader, YaST2-Repair, parts of webyast > > > > > > ------------------------------------------------------------------------------ > > > ThinkGeek and WIRED's GeekDad team up for the Ultimate > > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > > > lucky parental unit. See the prize list and enter to win: > > > http://p.sf.net/sfu/thinkgeek-promo > > > _______________________________________________ > > > Lxde-list mailing list > > > Lxd...@li... > > > https://lists.sourceforge.net/lists/listinfo/lxde-list > > > > > > > > > > > -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, parts of webyast |
From: Josef R. <jre...@su...> - 2010-06-10 12:58:35
|
Hi, tests is good idea. I try to create one based on glib testing framework. Patch is attached and if you have any question feel free to ask. Only think which I cannot solve and maybe you know is how to properly link it? (now it complain about _fm_path_init() not linked, which is quite strange for me). Also catching changes in code which cause relink of test doesn't work now (but it is not critical, just touch test file). Josef > Actually that part is quite problematic and sometimes causes crashes. > I'd like to create a unit test for fm_path_new_xxx but I don't really > know how to do it correctly and make the test integrated with the > building process. Any suggestions? > > 2010/6/10 Josef Reidinger <jre...@su...>: > > Hi, > > I check where is problem with bug 3012747 [1]. And found that implementation of libfm doesn't expect more then one beginning slash in its structure. I can fix it[attachment] with resolving it same as '/' , but I am not sure if it is correct as posix specify it as it can be implementation specific handling (that is reason why I am not commit it). Do you thing that it is expected behavior or on some posix systems is expected different behavior for path like //tmp ??? > > > > Josef > > > > [1] http://sourceforge.net/tracker/?func=detail&aid=3012747&group_id=156956&atid=801864 > > -- > > Josef Reidinger > > YaST team > > maintainer of perl-Bootloader, YaST2-Repair, parts of webyast > > > > ------------------------------------------------------------------------------ > > ThinkGeek and WIRED's GeekDad team up for the Ultimate > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > > lucky parental unit. See the prize list and enter to win: > > http://p.sf.net/sfu/thinkgeek-promo > > _______________________________________________ > > Lxde-list mailing list > > Lxd...@li... > > https://lists.sourceforge.net/lists/listinfo/lxde-list > > > > > -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, parts of webyast |
From: Marty J. <mar...@co...> - 2010-06-10 12:22:10
|
The language in POSIX/SUS that makes two, but not more than two, slashes implementation defined is undoubtedly a political compromise with some system that at the time was commercially viable and did not implement it the normal way. It is easily confirmed that on Linux, any number of slashes is equivalent to one slash, so that is their implementation defined behavior, and that is consistent with the other Unix systems I am familiar with. Do whatever you like to fix whatever the problem is. I have spent all the time on this I am going to spend. On 06/10/2010 08:00 AM, Josef Reidinger wrote: > Marty Jack write: >> I believe some things are being confused here. >> >> The moment you mention Samba shares, you get into the realm of URIs. These are well defined and do have requirements about the early slashes. These are specified in RFC 3986 Section 3, where you have either one or two slashes as part of the syntax following the scheme name. Then, everything between there and the question mark or hash mark is scheme specific. >> >> This is separate from the question of what is a valid path that can be passed to open(2) or any of the other system calls that operate on paths. These take an arbitrary number of slashes as equivalent to one slash. For example you can do ls -l ///////////////// and get the same result as ls -l /. > > Yes, but it is not true for // see http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html quote: > "A pathname consisting of a single slash shall resolve to the root directory of the process. A null pathname shall not be successfully resolved. A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash." > >> >> And finally, if you invoke the file scheme with file:/ , as defined by RFC 1738 Section 3.10, the syntax after that is another slash, optional hostname, slash, path, so would fall under the above rule. This is easily tested if you open file:////////etc/////asound.conf in a browser. >> >> http://www.ietf.org/rfc/rfc3986.txt >> http://www.ietf.org/rfc/rfc1738.txt >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Lxde-list mailing list >> Lxd...@li... >> https://lists.sourceforge.net/lists/listinfo/lxde-list >> > |
From: Josef R. <jre...@su...> - 2010-06-10 12:00:36
|
Marty Jack write: > I believe some things are being confused here. > > The moment you mention Samba shares, you get into the realm of URIs. These are well defined and do have requirements about the early slashes. These are specified in RFC 3986 Section 3, where you have either one or two slashes as part of the syntax following the scheme name. Then, everything between there and the question mark or hash mark is scheme specific. > > This is separate from the question of what is a valid path that can be passed to open(2) or any of the other system calls that operate on paths. These take an arbitrary number of slashes as equivalent to one slash. For example you can do ls -l ///////////////// and get the same result as ls -l /. Yes, but it is not true for // see http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html quote: "A pathname consisting of a single slash shall resolve to the root directory of the process. A null pathname shall not be successfully resolved. A pathname that begins with two successive slashes may be interpreted in an implementation-defined manner, although more than two leading slashes shall be treated as a single slash." > > And finally, if you invoke the file scheme with file:/ , as defined by RFC 1738 Section 3.10, the syntax after that is another slash, optional hostname, slash, path, so would fall under the above rule. This is easily tested if you open file:////////etc/////asound.conf in a browser. > > http://www.ietf.org/rfc/rfc3986.txt > http://www.ietf.org/rfc/rfc1738.txt > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, parts of webyast |
From: PCMan <pcm...@gm...> - 2010-06-10 11:53:02
|
About paths beginning with two slashes: http://en.wikipedia.org/wiki/Path_(computing) quote: "A few Unix-like systems use a similar syntax.[2] POSIX allows treating a path beginning with two slashes in an implementation-defined manner,[3] though in other cases systems must treat multiple slashes as single slashes" Treating leading double slash differently is allowed in POSIX. http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11 About URIs, there is no confusion as RFC clearly has them documented. On Thu, Jun 10, 2010 at 7:32 PM, Marty Jack <mar...@co...> wrote: > I believe some things are being confused here. > > The moment you mention Samba shares, you get into the realm of URIs. These are well defined and do have requirements about the early slashes. These are specified in RFC 3986 Section 3, where you have either one or two slashes as part of the syntax following the scheme name. Then, everything between there and the question mark or hash mark is scheme specific. > > This is separate from the question of what is a valid path that can be passed to open(2) or any of the other system calls that operate on paths. These take an arbitrary number of slashes as equivalent to one slash. For example you can do ls -l ///////////////// and get the same result as ls -l /. > > And finally, if you invoke the file scheme with file:/ , as defined by RFC 1738 Section 3.10, the syntax after that is another slash, optional hostname, slash, path, so would fall under the above rule. This is easily tested if you open file:////////etc/////asound.conf in a browser. > > http://www.ietf.org/rfc/rfc3986.txt > http://www.ietf.org/rfc/rfc1738.txt > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Marty J. <mar...@co...> - 2010-06-10 11:33:03
|
I believe some things are being confused here. The moment you mention Samba shares, you get into the realm of URIs. These are well defined and do have requirements about the early slashes. These are specified in RFC 3986 Section 3, where you have either one or two slashes as part of the syntax following the scheme name. Then, everything between there and the question mark or hash mark is scheme specific. This is separate from the question of what is a valid path that can be passed to open(2) or any of the other system calls that operate on paths. These take an arbitrary number of slashes as equivalent to one slash. For example you can do ls -l ///////////////// and get the same result as ls -l /. And finally, if you invoke the file scheme with file:/ , as defined by RFC 1738 Section 3.10, the syntax after that is another slash, optional hostname, slash, path, so would fall under the above rule. This is easily tested if you open file:////////etc/////asound.conf in a browser. http://www.ietf.org/rfc/rfc3986.txt http://www.ietf.org/rfc/rfc1738.txt |
From: Bela M. <bm...@ha...> - 2010-06-10 08:22:19
|
Zsolt, Don't miss the point, that PCManFM is an essential component of LXDE! I'm not talking about it's stand-alone use. Choice is up to end users. Of course, rox is available in TC repository. On this list we don't have to talk about what is for TC or not. It is a PCManFM development list, not TC. Of course you are welcome at TC community. Regards... Béla 2010.06.10. 9:42 keltezéssel, Zsolt Peter Basak írta: > In my opinion, PCManFM is not for TinyCoreLinux. Rox filer does the > job there or something even more lightweight (mc? cp?). PCManFM is on > a bit higher level in my opinion where usability does matter. (Not > just speed.) > > On Thu, Jun 10, 2010 at 9:33 AM, PCMan<pcm...@gm...> wrote: > >> On Thu, Jun 10, 2010 at 2:42 PM, Bela Markus<bm...@ha...> wrote: >> >>> Hi, >>> >>> I'm maintaining LXDE/PCManFM on Tiny Core Linux (TC), www.tinycorelinux.com >>> which is a modular, low footprint system. Main goal is to have only really >>> necessary stuff used avoiding oversized giant softwares. LXDE is an ideal >>> fit and used by many users. >>> >> I'd like to know if there are any bug reports from your user >> community. The top one goal of pcmanfm 1.0 release is quality >> assurance. It must be stable enough for daily use. Otherwise there >> shouldn't be a stable release. I'll be strict this time. >> >> >>> 1) gvfs is not part of the base system. Its size is the same or more than >>> the complete system and do not add real benefits for average users. Loading >>> it just for PCManFM is a real pain. So I would appreciate not to have gvfs >>> just as an option when really needed. >>> >> The dependency on gvfs is optional and you don't need it if you don't want. >> However, without gvfs, you'll lose volume management + automount + >> trash + access to all remote filesystems. >> Access to all local files is still working, so only volume management >> is lost when compared with the old 0.5 series. >> Since HAL is now deprecated, 0.5 series will stop working later. So >> basically the new one is not worse. >> But losing volume management is not acceptable by modern desktops. >> So, I still want to add udisks support to 1.0 to make volume >> management work without gvfs. >> Is this exception acceptible for 1.0 release? Dir tree is left for >> next major release. >> Anyways, I'm going to do it in development branch first. >> >> For remote filesystem access, actually we already started working on a >> lighter gvfs replacement. It's now a work in progress being developed >> by a developer from SuSE community and me. Later, maybe in one to two >> months, we might have the first working version as a proof of concept. >> Stay tunned please. >> >> >>> 2) What most people are asking for is volume management, more precisely >>> automatic mounting of removable media. On TC it is available with Xfce4 with >>> HAL, but really I do not want to go on with at all. Do not have experience >>> with udisks, but it seems to be usable now, so it is welcome. >>> >> Yes, making this work is very important and this is one of the top >> FAQs. So I want to get this solved for 1.0. >> >> >>> 3) Tree view is nice to have, but not a real must >>> >> True, but many people missed it. >> >>> 4) Personally I do not use file search. There are many alternatives. As an >>> old fashioned developer, I'm using alway MC for such stuff :) >>> >> I myself use find and grep most of the time. lol >> >> >>> Regards... Béla >>> >>> 2010.06.10. 6:45 keltezéssel, PCMan írta: >>> >>>> Hi list, >>>> After observing the reaction of users to the new pcmanfm and gathering >>>> some feedback, I'm now thinking about the necessity to change goals >>>> for 1.0 release. >>>> The major problems encountered by most users seem to be: >>>> 1. They don't want gvfs, or if they use it outside gnome, it can be >>>> problematic sometimes. >>>> 2. Volume management doesn't work sometimes due to some unknown issue of >>>> gvfs. >>>> 3. Tree view in the side pane is not available. >>>> 4. File searching utility is gone. >>>> >>>> So, I'm considering if a revise for 1.0 plan is needed. It's stable in >>>> current status, but it's functionality doesn't match the older series. >>>> This make many people reluctant to upgrade. >>>> The proposed changes to 1.0 are: >>>> 1. To implement volume mounting wth udisks and don't completely rely >>>> on gvfs for this. >>>> This won't be too difficult and only requires some coding. This can >>>> make pcmanfm work well without gvfs, which solves #2 and partially >>>> solves #1. >>>> 2. Try to add support for tree view to side pane again. I already came >>>> up with a better way to implement it last week. So I'm confident that >>>> this can be done. >>>> 3. Leave search utility since it's a Google SoC project now and as the >>>> old one doesn't work correctly, leaving this won't affect much. >>>> 4. A developer from the community is trying to work on template >>>> support, so you can create new files based on some template files in >>>> the popup menu. It's still a work in progress, but since it's simple, >>>> can we include this in 1.0? >>>> >>>> I want to make an exception for the feature-freeze and add the missing >>>> features udisks and dir tree prior to 1.0. Then it's possible to >>>> totally replace the old pcmanfm with it. >>>> Of course we can do them in branch and leave 1.0 as it is now, but >>>> this may cause problems in promotion and since some old features are >>>> missing, replacing the old series can be more difficult. Missing >>>> features can give the new pcmanfm a bad name sometimes even its >>>> internal structure is much better than the old one. >>>> >>>> Any comments? >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate >>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >>>> lucky parental unit. See the prize list and enter to win: >>>> http://p.sf.net/sfu/thinkgeek-promo >>>> _______________________________________________ >>>> Pcmanfm-develop mailing list >>>> Pcm...@li... >>>> https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop >>>> >>>> >>> >>> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Lxde-list mailing list >> Lxd...@li... >> https://lists.sourceforge.net/lists/listinfo/lxde-list >> >> > |
From: Martin B. / b. <br...@bs...> - 2010-06-10 08:01:40
|
On 2010-06-10 07:32, PCMan wrote: > Another option might be release 1.0 with current feature set, but > create a branch for 1.5 and do the development in parellel, just like > what Firefox has done in the past. Then both the stable branch and the > development 1.5 branch can have releases. So users who requires new > features can ship the 1.5.x version. Maybe this is a better idea, and > this can be documented in the release note of 1.0. Do we have the man power enough to pull this off? I'll help with what ever I can in advocating and testing and stuff but if we haven't got developers enough to get two tracks rolling I do not think we should be in that situation. Think it through carefully. -- brother http://sis.bthstudent.se |
From: Zsolt P. B. <shi...@gm...> - 2010-06-10 07:42:36
|
In my opinion, PCManFM is not for TinyCoreLinux. Rox filer does the job there or something even more lightweight (mc? cp?). PCManFM is on a bit higher level in my opinion where usability does matter. (Not just speed.) On Thu, Jun 10, 2010 at 9:33 AM, PCMan <pcm...@gm...> wrote: > On Thu, Jun 10, 2010 at 2:42 PM, Bela Markus <bm...@ha...> wrote: >> Hi, >> >> I'm maintaining LXDE/PCManFM on Tiny Core Linux (TC), www.tinycorelinux.com >> which is a modular, low footprint system. Main goal is to have only really >> necessary stuff used avoiding oversized giant softwares. LXDE is an ideal >> fit and used by many users. > > I'd like to know if there are any bug reports from your user > community. The top one goal of pcmanfm 1.0 release is quality > assurance. It must be stable enough for daily use. Otherwise there > shouldn't be a stable release. I'll be strict this time. > >> 1) gvfs is not part of the base system. Its size is the same or more than >> the complete system and do not add real benefits for average users. Loading >> it just for PCManFM is a real pain. So I would appreciate not to have gvfs >> just as an option when really needed. > > The dependency on gvfs is optional and you don't need it if you don't want. > However, without gvfs, you'll lose volume management + automount + > trash + access to all remote filesystems. > Access to all local files is still working, so only volume management > is lost when compared with the old 0.5 series. > Since HAL is now deprecated, 0.5 series will stop working later. So > basically the new one is not worse. > But losing volume management is not acceptable by modern desktops. > So, I still want to add udisks support to 1.0 to make volume > management work without gvfs. > Is this exception acceptible for 1.0 release? Dir tree is left for > next major release. > Anyways, I'm going to do it in development branch first. > > For remote filesystem access, actually we already started working on a > lighter gvfs replacement. It's now a work in progress being developed > by a developer from SuSE community and me. Later, maybe in one to two > months, we might have the first working version as a proof of concept. > Stay tunned please. > >> 2) What most people are asking for is volume management, more precisely >> automatic mounting of removable media. On TC it is available with Xfce4 with >> HAL, but really I do not want to go on with at all. Do not have experience >> with udisks, but it seems to be usable now, so it is welcome. > Yes, making this work is very important and this is one of the top > FAQs. So I want to get this solved for 1.0. > >> 3) Tree view is nice to have, but not a real must > True, but many people missed it. >> >> 4) Personally I do not use file search. There are many alternatives. As an >> old fashioned developer, I'm using alway MC for such stuff :) > I myself use find and grep most of the time. lol > >> Regards... Béla >> >> 2010.06.10. 6:45 keltezéssel, PCMan írta: >>> >>> Hi list, >>> After observing the reaction of users to the new pcmanfm and gathering >>> some feedback, I'm now thinking about the necessity to change goals >>> for 1.0 release. >>> The major problems encountered by most users seem to be: >>> 1. They don't want gvfs, or if they use it outside gnome, it can be >>> problematic sometimes. >>> 2. Volume management doesn't work sometimes due to some unknown issue of >>> gvfs. >>> 3. Tree view in the side pane is not available. >>> 4. File searching utility is gone. >>> >>> So, I'm considering if a revise for 1.0 plan is needed. It's stable in >>> current status, but it's functionality doesn't match the older series. >>> This make many people reluctant to upgrade. >>> The proposed changes to 1.0 are: >>> 1. To implement volume mounting wth udisks and don't completely rely >>> on gvfs for this. >>> This won't be too difficult and only requires some coding. This can >>> make pcmanfm work well without gvfs, which solves #2 and partially >>> solves #1. >>> 2. Try to add support for tree view to side pane again. I already came >>> up with a better way to implement it last week. So I'm confident that >>> this can be done. >>> 3. Leave search utility since it's a Google SoC project now and as the >>> old one doesn't work correctly, leaving this won't affect much. >>> 4. A developer from the community is trying to work on template >>> support, so you can create new files based on some template files in >>> the popup menu. It's still a work in progress, but since it's simple, >>> can we include this in 1.0? >>> >>> I want to make an exception for the feature-freeze and add the missing >>> features udisks and dir tree prior to 1.0. Then it's possible to >>> totally replace the old pcmanfm with it. >>> Of course we can do them in branch and leave 1.0 as it is now, but >>> this may cause problems in promotion and since some old features are >>> missing, replacing the old series can be more difficult. Missing >>> features can give the new pcmanfm a bad name sometimes even its >>> internal structure is much better than the old one. >>> >>> Any comments? >>> >>> >>> ------------------------------------------------------------------------------ >>> ThinkGeek and WIRED's GeekDad team up for the Ultimate >>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >>> lucky parental unit. See the prize list and enter to win: >>> http://p.sf.net/sfu/thinkgeek-promo >>> _______________________________________________ >>> Pcmanfm-develop mailing list >>> Pcm...@li... >>> https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop >>> >> >> > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: PCMan <pcm...@gm...> - 2010-06-10 07:33:26
|
On Thu, Jun 10, 2010 at 2:42 PM, Bela Markus <bm...@ha...> wrote: > Hi, > > I'm maintaining LXDE/PCManFM on Tiny Core Linux (TC), www.tinycorelinux.com > which is a modular, low footprint system. Main goal is to have only really > necessary stuff used avoiding oversized giant softwares. LXDE is an ideal > fit and used by many users. I'd like to know if there are any bug reports from your user community. The top one goal of pcmanfm 1.0 release is quality assurance. It must be stable enough for daily use. Otherwise there shouldn't be a stable release. I'll be strict this time. > 1) gvfs is not part of the base system. Its size is the same or more than > the complete system and do not add real benefits for average users. Loading > it just for PCManFM is a real pain. So I would appreciate not to have gvfs > just as an option when really needed. The dependency on gvfs is optional and you don't need it if you don't want. However, without gvfs, you'll lose volume management + automount + trash + access to all remote filesystems. Access to all local files is still working, so only volume management is lost when compared with the old 0.5 series. Since HAL is now deprecated, 0.5 series will stop working later. So basically the new one is not worse. But losing volume management is not acceptable by modern desktops. So, I still want to add udisks support to 1.0 to make volume management work without gvfs. Is this exception acceptible for 1.0 release? Dir tree is left for next major release. Anyways, I'm going to do it in development branch first. For remote filesystem access, actually we already started working on a lighter gvfs replacement. It's now a work in progress being developed by a developer from SuSE community and me. Later, maybe in one to two months, we might have the first working version as a proof of concept. Stay tunned please. > 2) What most people are asking for is volume management, more precisely > automatic mounting of removable media. On TC it is available with Xfce4 with > HAL, but really I do not want to go on with at all. Do not have experience > with udisks, but it seems to be usable now, so it is welcome. Yes, making this work is very important and this is one of the top FAQs. So I want to get this solved for 1.0. > 3) Tree view is nice to have, but not a real must True, but many people missed it. > > 4) Personally I do not use file search. There are many alternatives. As an > old fashioned developer, I'm using alway MC for such stuff :) I myself use find and grep most of the time. lol > Regards... Béla > > 2010.06.10. 6:45 keltezéssel, PCMan írta: >> >> Hi list, >> After observing the reaction of users to the new pcmanfm and gathering >> some feedback, I'm now thinking about the necessity to change goals >> for 1.0 release. >> The major problems encountered by most users seem to be: >> 1. They don't want gvfs, or if they use it outside gnome, it can be >> problematic sometimes. >> 2. Volume management doesn't work sometimes due to some unknown issue of >> gvfs. >> 3. Tree view in the side pane is not available. >> 4. File searching utility is gone. >> >> So, I'm considering if a revise for 1.0 plan is needed. It's stable in >> current status, but it's functionality doesn't match the older series. >> This make many people reluctant to upgrade. >> The proposed changes to 1.0 are: >> 1. To implement volume mounting wth udisks and don't completely rely >> on gvfs for this. >> This won't be too difficult and only requires some coding. This can >> make pcmanfm work well without gvfs, which solves #2 and partially >> solves #1. >> 2. Try to add support for tree view to side pane again. I already came >> up with a better way to implement it last week. So I'm confident that >> this can be done. >> 3. Leave search utility since it's a Google SoC project now and as the >> old one doesn't work correctly, leaving this won't affect much. >> 4. A developer from the community is trying to work on template >> support, so you can create new files based on some template files in >> the popup menu. It's still a work in progress, but since it's simple, >> can we include this in 1.0? >> >> I want to make an exception for the feature-freeze and add the missing >> features udisks and dir tree prior to 1.0. Then it's possible to >> totally replace the old pcmanfm with it. >> Of course we can do them in branch and leave 1.0 as it is now, but >> this may cause problems in promotion and since some old features are >> missing, replacing the old series can be more difficult. Missing >> features can give the new pcmanfm a bad name sometimes even its >> internal structure is much better than the old one. >> >> Any comments? >> >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Pcmanfm-develop mailing list >> Pcm...@li... >> https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop >> > > |
From: Zsolt P. B. <shi...@gm...> - 2010-06-10 05:34:31
|
Yes this is a good idea, a nice way I guess. This way, you would keep the version tradition. On Thu, Jun 10, 2010 at 7:32 AM, PCMan <pcm...@gm...> wrote: > Another option might be release 1.0 with current feature set, but > create a branch for 1.5 and do the development in parellel, just like > what Firefox has done in the past. Then both the stable branch and the > development 1.5 branch can have releases. So users who requires new > features can ship the 1.5.x version. Maybe this is a better idea, and > this can be documented in the release note of 1.0. > > On Thu, Jun 10, 2010 at 1:17 PM, Zsolt Peter Basak > <shi...@gm...> wrote: >> Hello >> >> In my opinion you should release a stable one with the version of 1.0. >> If you always want to make a perfect software (in every aspect), the >> usual thing can happen when the software won't ever be done since you >> always want to change something, the users always want something. The >> current state is okay I guess, distros could already ship it. The >> change what you talk about is important, but not crucial. In my >> opinion it's all ok for a 1.1 version , but this is only my personal >> opinion. (Only some distro ships with rc version. Some still ships >> with the 0.5 .. oh my. Some only includes it if it gets a stable/final >> 'mark'. *I* say, the old 1.0 goals are totally ok.) >> >> ps.: Now... where should I send this message ? Sorry if reply to all >> list is not the correct way. >> Peter >> >> On Thu, Jun 10, 2010 at 6:45 AM, PCMan <pcm...@gm...> wrote: >>> Hi list, >>> After observing the reaction of users to the new pcmanfm and gathering >>> some feedback, I'm now thinking about the necessity to change goals >>> for 1.0 release. >>> The major problems encountered by most users seem to be: >>> 1. They don't want gvfs, or if they use it outside gnome, it can be >>> problematic sometimes. >>> 2. Volume management doesn't work sometimes due to some unknown issue of gvfs. >>> 3. Tree view in the side pane is not available. >>> 4. File searching utility is gone. >>> >>> So, I'm considering if a revise for 1.0 plan is needed. It's stable in >>> current status, but it's functionality doesn't match the older series. >>> This make many people reluctant to upgrade. >>> The proposed changes to 1.0 are: >>> 1. To implement volume mounting wth udisks and don't completely rely >>> on gvfs for this. >>> This won't be too difficult and only requires some coding. This can >>> make pcmanfm work well without gvfs, which solves #2 and partially >>> solves #1. >>> 2. Try to add support for tree view to side pane again. I already came >>> up with a better way to implement it last week. So I'm confident that >>> this can be done. >>> 3. Leave search utility since it's a Google SoC project now and as the >>> old one doesn't work correctly, leaving this won't affect much. >>> 4. A developer from the community is trying to work on template >>> support, so you can create new files based on some template files in >>> the popup menu. It's still a work in progress, but since it's simple, >>> can we include this in 1.0? >>> >>> I want to make an exception for the feature-freeze and add the missing >>> features udisks and dir tree prior to 1.0. Then it's possible to >>> totally replace the old pcmanfm with it. >>> Of course we can do them in branch and leave 1.0 as it is now, but >>> this may cause problems in promotion and since some old features are >>> missing, replacing the old series can be more difficult. Missing >>> features can give the new pcmanfm a bad name sometimes even its >>> internal structure is much better than the old one. >>> >>> Any comments? >>> >>> ------------------------------------------------------------------------------ >>> ThinkGeek and WIRED's GeekDad team up for the Ultimate >>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >>> lucky parental unit. See the prize list and enter to win: >>> http://p.sf.net/sfu/thinkgeek-promo >>> _______________________________________________ >>> Lxde-list mailing list >>> Lxd...@li... >>> https://lists.sourceforge.net/lists/listinfo/lxde-list >>> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~lubuntu-desktop >> Post to : lub...@li... >> Unsubscribe : https://launchpad.net/~lubuntu-desktop >> More help : https://help.launchpad.net/ListHelp >> > |
From: PCMan <pcm...@gm...> - 2010-06-10 05:32:30
|
Another option might be release 1.0 with current feature set, but create a branch for 1.5 and do the development in parellel, just like what Firefox has done in the past. Then both the stable branch and the development 1.5 branch can have releases. So users who requires new features can ship the 1.5.x version. Maybe this is a better idea, and this can be documented in the release note of 1.0. On Thu, Jun 10, 2010 at 1:17 PM, Zsolt Peter Basak <shi...@gm...> wrote: > Hello > > In my opinion you should release a stable one with the version of 1.0. > If you always want to make a perfect software (in every aspect), the > usual thing can happen when the software won't ever be done since you > always want to change something, the users always want something. The > current state is okay I guess, distros could already ship it. The > change what you talk about is important, but not crucial. In my > opinion it's all ok for a 1.1 version , but this is only my personal > opinion. (Only some distro ships with rc version. Some still ships > with the 0.5 .. oh my. Some only includes it if it gets a stable/final > 'mark'. *I* say, the old 1.0 goals are totally ok.) > > ps.: Now... where should I send this message ? Sorry if reply to all > list is not the correct way. > Peter > > On Thu, Jun 10, 2010 at 6:45 AM, PCMan <pcm...@gm...> wrote: >> Hi list, >> After observing the reaction of users to the new pcmanfm and gathering >> some feedback, I'm now thinking about the necessity to change goals >> for 1.0 release. >> The major problems encountered by most users seem to be: >> 1. They don't want gvfs, or if they use it outside gnome, it can be >> problematic sometimes. >> 2. Volume management doesn't work sometimes due to some unknown issue of gvfs. >> 3. Tree view in the side pane is not available. >> 4. File searching utility is gone. >> >> So, I'm considering if a revise for 1.0 plan is needed. It's stable in >> current status, but it's functionality doesn't match the older series. >> This make many people reluctant to upgrade. >> The proposed changes to 1.0 are: >> 1. To implement volume mounting wth udisks and don't completely rely >> on gvfs for this. >> This won't be too difficult and only requires some coding. This can >> make pcmanfm work well without gvfs, which solves #2 and partially >> solves #1. >> 2. Try to add support for tree view to side pane again. I already came >> up with a better way to implement it last week. So I'm confident that >> this can be done. >> 3. Leave search utility since it's a Google SoC project now and as the >> old one doesn't work correctly, leaving this won't affect much. >> 4. A developer from the community is trying to work on template >> support, so you can create new files based on some template files in >> the popup menu. It's still a work in progress, but since it's simple, >> can we include this in 1.0? >> >> I want to make an exception for the feature-freeze and add the missing >> features udisks and dir tree prior to 1.0. Then it's possible to >> totally replace the old pcmanfm with it. >> Of course we can do them in branch and leave 1.0 as it is now, but >> this may cause problems in promotion and since some old features are >> missing, replacing the old series can be more difficult. Missing >> features can give the new pcmanfm a bad name sometimes even its >> internal structure is much better than the old one. >> >> Any comments? >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Lxde-list mailing list >> Lxd...@li... >> https://lists.sourceforge.net/lists/listinfo/lxde-list >> > > _______________________________________________ > Mailing list: https://launchpad.net/~lubuntu-desktop > Post to : lub...@li... > Unsubscribe : https://launchpad.net/~lubuntu-desktop > More help : https://help.launchpad.net/ListHelp > |
From: Zsolt P. B. <shi...@gm...> - 2010-06-10 05:17:44
|
Hello In my opinion you should release a stable one with the version of 1.0. If you always want to make a perfect software (in every aspect), the usual thing can happen when the software won't ever be done since you always want to change something, the users always want something. The current state is okay I guess, distros could already ship it. The change what you talk about is important, but not crucial. In my opinion it's all ok for a 1.1 version , but this is only my personal opinion. (Only some distro ships with rc version. Some still ships with the 0.5 .. oh my. Some only includes it if it gets a stable/final 'mark'. *I* say, the old 1.0 goals are totally ok.) ps.: Now... where should I send this message ? Sorry if reply to all list is not the correct way. Peter On Thu, Jun 10, 2010 at 6:45 AM, PCMan <pcm...@gm...> wrote: > Hi list, > After observing the reaction of users to the new pcmanfm and gathering > some feedback, I'm now thinking about the necessity to change goals > for 1.0 release. > The major problems encountered by most users seem to be: > 1. They don't want gvfs, or if they use it outside gnome, it can be > problematic sometimes. > 2. Volume management doesn't work sometimes due to some unknown issue of gvfs. > 3. Tree view in the side pane is not available. > 4. File searching utility is gone. > > So, I'm considering if a revise for 1.0 plan is needed. It's stable in > current status, but it's functionality doesn't match the older series. > This make many people reluctant to upgrade. > The proposed changes to 1.0 are: > 1. To implement volume mounting wth udisks and don't completely rely > on gvfs for this. > This won't be too difficult and only requires some coding. This can > make pcmanfm work well without gvfs, which solves #2 and partially > solves #1. > 2. Try to add support for tree view to side pane again. I already came > up with a better way to implement it last week. So I'm confident that > this can be done. > 3. Leave search utility since it's a Google SoC project now and as the > old one doesn't work correctly, leaving this won't affect much. > 4. A developer from the community is trying to work on template > support, so you can create new files based on some template files in > the popup menu. It's still a work in progress, but since it's simple, > can we include this in 1.0? > > I want to make an exception for the feature-freeze and add the missing > features udisks and dir tree prior to 1.0. Then it's possible to > totally replace the old pcmanfm with it. > Of course we can do them in branch and leave 1.0 as it is now, but > this may cause problems in promotion and since some old features are > missing, replacing the old series can be more difficult. Missing > features can give the new pcmanfm a bad name sometimes even its > internal structure is much better than the old one. > > Any comments? > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: PCMan <pcm...@gm...> - 2010-06-10 04:45:34
|
Hi list, After observing the reaction of users to the new pcmanfm and gathering some feedback, I'm now thinking about the necessity to change goals for 1.0 release. The major problems encountered by most users seem to be: 1. They don't want gvfs, or if they use it outside gnome, it can be problematic sometimes. 2. Volume management doesn't work sometimes due to some unknown issue of gvfs. 3. Tree view in the side pane is not available. 4. File searching utility is gone. So, I'm considering if a revise for 1.0 plan is needed. It's stable in current status, but it's functionality doesn't match the older series. This make many people reluctant to upgrade. The proposed changes to 1.0 are: 1. To implement volume mounting wth udisks and don't completely rely on gvfs for this. This won't be too difficult and only requires some coding. This can make pcmanfm work well without gvfs, which solves #2 and partially solves #1. 2. Try to add support for tree view to side pane again. I already came up with a better way to implement it last week. So I'm confident that this can be done. 3. Leave search utility since it's a Google SoC project now and as the old one doesn't work correctly, leaving this won't affect much. 4. A developer from the community is trying to work on template support, so you can create new files based on some template files in the popup menu. It's still a work in progress, but since it's simple, can we include this in 1.0? I want to make an exception for the feature-freeze and add the missing features udisks and dir tree prior to 1.0. Then it's possible to totally replace the old pcmanfm with it. Of course we can do them in branch and leave 1.0 as it is now, but this may cause problems in promotion and since some old features are missing, replacing the old series can be more difficult. Missing features can give the new pcmanfm a bad name sometimes even its internal structure is much better than the old one. Any comments? |
From: PCMan <pcm...@gm...> - 2010-06-10 04:29:33
|
IIRC, on POSIX systems, // is treated as /, but // in the beginning of the path has special meanings, such as samba share which uses \\ on Windows. So, if the first two characters are //, I think they should be kept. If // is found in path, it should be treated as /. Any comments? Besides, do we need to introduce more standard URI parsing by using some RFC comforming lib which is small enough? On Thu, Jun 10, 2010 at 3:51 AM, Marty Jack <mar...@co...> wrote: > As a general rule in Unix-like systems, // in a path is the same as /. So for example you could also say /usr/share//applications. This makes it easier when you are concatenating things together, so you don't have to be looking for and removing extra slashes. > > On 06/09/2010 01:18 PM, Josef Reidinger wrote: >> Hi, >> I check where is problem with bug 3012747 [1]. And found that implementation of libfm doesn't expect more then one beginning slash in its structure. I can fix it[attachment] with resolving it same as '/' , but I am not sure if it is correct as posix specify it as it can be implementation specific handling (that is reason why I am not commit it). Do you thing that it is expected behavior or on some posix systems is expected different behavior for path like //tmp ??? >> >> Josef >> >> [1] http://sourceforge.net/tracker/?func=detail&aid=3012747&group_id=156956&atid=801864 >> >> >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> >> >> >> _______________________________________________ >> Lxde-list mailing list >> Lxd...@li... >> https://lists.sourceforge.net/lists/listinfo/lxde-list > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Sven G. <mai...@gu...> - 2010-06-10 02:00:23
|
* Christoph Wickert <chr...@go...> [2010-06-09 13:03]: > The BBQ will properly take place > later that day at c-base. > http://www.c-base.org/ "properly" - or "probably"? ;) who is actually the person taking care about setting up the BBQ? does he exist? and does the orga team of the c-base know about this event? and when does it start *exactly*? i do not see any announcement on the c-base website nor on their irc channel. and on thursdays on 9pm there is the c-lounge + go-lounge happening. and do you really want to BBQ at the c-base while hundreds of people are attending the Social Event known as "LinuxNight"? anyway, if c-base has approved of this BBQ and there is a chef for this then please put the info into the wiki. "more info!" greetings from the west pole (it's all east around here!) SvenHH |
From: Andrew L. <aj...@de...> - 2010-06-09 20:35:39
|
Hi Christoph, Thanks organize this LXDE meet up. I'd like to propose some topics for discussion. Please read topics below, and add up your questions/topics. On 2010年06月09日 17:15, Christoph Wickert wrote: > Hi everybody, > > the poll about the meeting time has a result now. The LXDE community > will meet on > > Thursday, June 10th from 14:00 - 17:00. > We will meet at the Sidux booth¹. @LXDE foundation people, please attend this meet up. We have very important question/discussion for LXDE community to discuss: How can the LXDE foundation starts up without invlove orginal LXDE founder and developers? How can the LXDE foundation invlove original LXDE founder and developers and future new contributors? How the LXDE developers can make decisions and who to make decisions inside of the foundation? How the LXDE foundation can help developers? How LXDE foundation give transparency to developers and members. > The BBQ will properly take place later that day at c-base². Nice. Distros maintainers may enjoy the beers and BBQ at c-base to discuss and share about the technique topics with community during this time. I'd propose the discussion on - pcmanfm 0.9 series - Design of LXDM - Debian's LXDE packaging team - about how to proceed with the LXDE Foundation Look forward to have a nice LXDE meet up. -Andrew |
From: Marty J. <mar...@co...> - 2010-06-09 19:51:30
|
As a general rule in Unix-like systems, // in a path is the same as /. So for example you could also say /usr/share//applications. This makes it easier when you are concatenating things together, so you don't have to be looking for and removing extra slashes. On 06/09/2010 01:18 PM, Josef Reidinger wrote: > Hi, > I check where is problem with bug 3012747 [1]. And found that implementation of libfm doesn't expect more then one beginning slash in its structure. I can fix it[attachment] with resolving it same as '/' , but I am not sure if it is correct as posix specify it as it can be implementation specific handling (that is reason why I am not commit it). Do you thing that it is expected behavior or on some posix systems is expected different behavior for path like //tmp ??? > > Josef > > [1] http://sourceforge.net/tracker/?func=detail&aid=3012747&group_id=156956&atid=801864 > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > > > > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list |
From: Andrea F. <an...@op...> - 2010-06-09 18:36:49
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i josef, thank you for the patch. waiting for pcman answer, i guess it can be used. actually nautilus (just for example) open //path as it was /path without any other concern. i guess that what follow the same thing or we can do like this: allow the user to type even ///////path as soon the user type enter, the "wrong" path is converted to the right one (/path) and the latter is opened. just my 2 cents Andrea Il 09/06/2010 19:18, Josef Reidinger ha scritto: > Hi, > I check where is problem with bug 3012747 [1]. And found that implementation of libfm doesn't expect more then one beginning slash in its structure. I can fix it[attachment] with resolving it same as '/' , but I am not sure if it is correct as posix specify it as it can be implementation specific handling (that is reason why I am not commit it). Do you thing that it is expected behavior or on some posix systems is expected different behavior for path like //tmp ??? > > Josef > > [1] http://sourceforge.net/tracker/?func=detail&aid=3012747&group_id=156956&atid=801864 > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > > > > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list - -- - ------------------------------------------ Andrea Florio QSI International School of Brindisi Sys Admin CISCO CCNA Certified openSUSE-Education Administrator openSUSE Official Member (anubisg1) Email: an...@op... Packman Packaging Team Email: an...@li... Web: http://packman.links2linux.org/ Cell: +39-328-7365667 - ------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkwP3/MACgkQyCZT87TFPuhwnQCg5R1hcyy7C1bbtWg5sVyRbaRo o08An0+MHWzf+LXRZd44gAlQ86IrDq/q =DzVu -----END PGP SIGNATURE----- |
From: Josef R. <jre...@su...> - 2010-06-09 17:19:06
|
Hi, I check where is problem with bug 3012747 [1]. And found that implementation of libfm doesn't expect more then one beginning slash in its structure. I can fix it[attachment] with resolving it same as '/' , but I am not sure if it is correct as posix specify it as it can be implementation specific handling (that is reason why I am not commit it). Do you thing that it is expected behavior or on some posix systems is expected different behavior for path like //tmp ??? Josef [1] http://sourceforge.net/tracker/?func=detail&aid=3012747&group_id=156956&atid=801864 -- Josef Reidinger YaST team maintainer of perl-Bootloader, YaST2-Repair, parts of webyast |
From: Christoph W. <chr...@go...> - 2010-06-09 09:15:42
|
Hi everybody, the poll about the meeting time has a result now. The LXDE community will meet on Thursday, June 10th from 14:00 - 17:00. We will meet at the Sidux booth¹. The BBQ will properly take place later that day at c-base². Regards, Christoph ¹ Hall 7.2a, booth 106 ² http://www.c-base.org/ |