From: Andrej N. G. <an...@re...> - 2013-11-07 02:48:17
|
Hello! I'm currently working on implementation of next feature for PCManFM. It is different sort and view mode for selected folders. I.e. user can check an option 'Use these settings for this folder only' and sort (and view mode) will be remembered for current folder independently from common settings. The question is how to do that. I know two ways now: 1. Use '.directory' file in folder in question. Pros: - can be used by other implementations and other file managers; - settings persist if folder is renamed; - settings persist if folder is accessed other way (via ssh, ftp, etc.). Cons: - can be used only if user can write into .directory file in folder. 2. Use cache file somewhere. Pros: - can be used against system directories (/usr for example). Cons: - completely implementation-dependent and even environment-dependent; - settings are lost when folder is renamed; - it may be impossible to have different settings for removable media; - cache will grow indefinitely, no sane cleaning heuristics exist. I would appreciate all your opinions and I'm waiting for them until I start implementing it. Thank you in advance. Cheers! Andriy. |
From: PCMan <pcm...@gm...> - 2013-11-07 03:23:01
|
On Thu, Nov 7, 2013 at 10:48 AM, Andrej N. Gritsenko <an...@re...>wrote: > Hello! > > I'm currently working on implementation of next feature for PCManFM. > It is different sort and view mode for selected folders. I.e. user can > check an option 'Use these settings for this folder only' and sort (and > view mode) will be remembered for current folder independently from > common settings. The question is how to do that. I know two ways now: > > 1. Use '.directory' file in folder in question. > Pros: > - can be used by other implementations and other file managers; > - settings persist if folder is renamed; > - settings persist if folder is accessed other way (via ssh, ftp, etc.). > Cons: > - can be used only if user can write into .directory file in folder. > > 2. Use cache file somewhere. > Pros: > - can be used against system directories (/usr for example). > Cons: > - completely implementation-dependent and even environment-dependent; > - settings are lost when folder is renamed; > - it may be impossible to have different settings for removable media; > - cache will grow indefinitely, no sane cleaning heuristics exist. > > I would appreciate all your opinions and I'm waiting for them until I > start implementing it. Thank you in advance. > > Cheers! > Andriy. > > Well, I've been thinking about the issue for quite a long time but did not do it since I couldn't find a really satisfying solution. A cache is the most reliable, but it's hard to maintain and it's easy to break. Deleting dead entries in the cache periodically is needed. Otherwise the cache will be full of garbage after a period of time. Windows seems to use this approach and the info is in windows registry. Thunar uses similar way, and the info is stored in a tdb file. Tdb is the trivial key-value db developed by Samba and it's good enough for the task. Nautilus seems to use similar approach, but they use text-based meta-info files stored somewhere rather than a db, which is very inefficient. A key-value based binary db with periodic dead-entry clearance is reasonable. Good candidates are samba tdb and sqlite. Another good stuff to use is xattr. Most modern filesystems support it. This is the best place to store this kind of info. Pros: widely-available, creates no junk, can be accessed by others easily. Will not be included when you try to tar a dir (this beats the .directory approach). Cons: not available on read-only FS, remote FS, and windows FS, such as ntfs and vfat. The last one is .directory approach. I like this one, too. Windows uses similar method to store other info, such as directory icon. It uses a hidden file "desktop.ini" in every folder for that. Pros: constant access speed. No db lookup, easy to implement, no other dependencies. Portable, easily managed, and can be preserved even when you create backup for the folder. Cons: When you create a tar file for the folder, it will be included. It's hard to delete them all if you want to uninstall pcmanfm. Also, remember to add it to .gitignore. This is quite annoying. It's also visible to the user if you turn on "show hidden files", which is really bad. So, the best way I can figure out: 1. For local filesystems, check xattr first. 2. If xattr is not availble or it's not a local FS, try the key-value db-based cache. 3. remove dead entries from the db periodically. 4. Add UI options for the user to turn off per-folder config. The .directory apprach is really bad for maintainance. For example, if the user want to turn off "per-folder" setting, it's not possible to search for all .desktop files and delete them. The drawbacks make this apprach less appealing. Cheers! |
From: Petr V. <pe...@ya...> - 2013-11-07 09:43:49
|
On 11/07/2013 04:22 AM, PCMan wrote: > On Thu, Nov 7, 2013 at 10:48 AM, Andrej N. Gritsenko > <an...@re... <mailto:an...@re...>> wrote:The last one is > .directory approach. I like this one, too. Windows uses similar method > to store other info, such as directory icon. It uses a hidden file > "desktop.ini" in every folder for that. > Pros: constant access speed. No db lookup, easy to implement, no other > dependencies. Portable, easily managed, and can be preserved even when > you create backup for the folder. > Cons: When you create a tar file for the folder, it will be included. > It's hard to delete them all if you want to uninstall pcmanfm. Also, > remember to add it to .gitignore. This is quite annoying. It's also > visible to the user if you turn on "show hidden files", which is > really bad. the "one hidden file per directory" is quite annoying. I have many these files on my OS X laptop - it's copied everywhere and services like owncloud/dropbox... has to be configured to ignore these files. For me it's clear - use cache or filesystem attributes. p. |
From: Jerome L. <ad...@gm...> - 2013-11-07 10:06:24
|
Agreed. J. Leclanche On Thu, Nov 7, 2013 at 9:43 AM, Petr Vanek <pe...@ya...> wrote: > On 11/07/2013 04:22 AM, PCMan wrote: > > On Thu, Nov 7, 2013 at 10:48 AM, Andrej N. Gritsenko <an...@re...> > wrote:The last one is .directory approach. I like this one, too. Windows > uses similar method to store other info, such as directory icon. It uses a > hidden file "desktop.ini" in every folder for that. > Pros: constant access speed. No db lookup, easy to implement, no other > dependencies. Portable, easily managed, and can be preserved even when you > create backup for the folder. > Cons: When you create a tar file for the folder, it will be included. It's > hard to delete them all if you want to uninstall pcmanfm. Also, remember to > add it to .gitignore. This is quite annoying. It's also visible to the user > if you turn on "show hidden files", which is really bad. > > > the "one hidden file per directory" is quite annoying. I have many these > files on my OS X laptop - it's copied everywhere and services like > owncloud/dropbox... has to be configured to ignore these files. > > For me it's clear - use cache or filesystem attributes. > > p. > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > |
From: Andrej N. G. <an...@re...> - 2013-11-07 11:02:42
|
Hello! PCMan has written on Thursday, 7 November, at 11:22: >On Thu, Nov 7, 2013 at 10:48 AM, Andrej N. Gritsenko <an...@re...>wrote: >> I'm currently working on implementation of next feature for PCManFM. >> It is different sort and view mode for selected folders. I.e. user can >> check an option 'Use these settings for this folder only' and sort (and >> view mode) will be remembered for current folder independently from >> common settings. The question is how to do that. I know two ways now: >> 1. Use '.directory' file in folder in question. >> Pros: >> - can be used by other implementations and other file managers; >> - settings persist if folder is renamed; >> - settings persist if folder is accessed other way (via ssh, ftp, etc.). >> Cons: >> - can be used only if user can write into .directory file in folder. >> 2. Use cache file somewhere. >> Pros: >> - can be used against system directories (/usr for example). >> Cons: >> - completely implementation-dependent and even environment-dependent; >> - settings are lost when folder is renamed; >> - it may be impossible to have different settings for removable media; >> - cache will grow indefinitely, no sane cleaning heuristics exist. >> I would appreciate all your opinions and I'm waiting for them until I >> start implementing it. Thank you in advance. >Well, I've been thinking about the issue for quite a long time but did not >do it since I couldn't find a really satisfying solution. >A cache is the most reliable, but it's hard to maintain and it's easy to >break. >Deleting dead entries in the cache periodically is needed. Otherwise the >cache will be full of garbage after a period of time. >Windows seems to use this approach and the info is in windows registry. >Thunar uses similar way, and the info is stored in a tdb file. >Tdb is the trivial key-value db developed by Samba and it's good enough for >the task. >Nautilus seems to use similar approach, but they use text-based meta-info >files stored somewhere rather than a db, which is very inefficient. >A key-value based binary db with periodic dead-entry clearance is >reasonable. >Good candidates are samba tdb and sqlite. I really hate the cache solution - it is completely implementation dependent and you even have to implement it exactly the same in each application if you want them to be compatible. And yes, any cache is easy to break if any crash happens in time of its rebuild. >Another good stuff to use is xattr. Most modern filesystems support it. >This is the best place to store this kind of info. >Pros: widely-available, creates no junk, can be accessed by others easily. >Will not be included when you try to tar a dir (this beats the .directory >approach). >Cons: not available on read-only FS, remote FS, and windows FS, such as >ntfs and vfat. >The last one is .directory approach. I like this one, too. Windows uses >similar method to store other info, such as directory icon. It uses a >hidden file "desktop.ini" in every folder for that. >Pros: constant access speed. No db lookup, easy to implement, no other >dependencies. Portable, easily managed, and can be preserved even when you >create backup for the folder. >Cons: When you create a tar file for the folder, it will be included. It's >hard to delete them all if you want to uninstall pcmanfm. Also, remember to >add it to .gitignore. This is quite annoying. It's also visible to the user >if you turn on "show hidden files", which is really bad. >So, the best way I can figure out: >1. For local filesystems, check xattr first. Well, that still have the same big limitation - when you go into the folder via ssh or ftp, you get no setup for it. >2. If xattr is not availble or it's not a local FS, try the key-value >db-based cache. >3. remove dead entries from the db periodically. It is not possible really - you will remove all remembered data for remote or removable media not currently connected. And since you have proposed to use cache exactly for that purpose, that renders value of that cache close to zero. In short - either not use cache, or accept its unlimited growth, and other cons that I mentioned above. >4. Add UI options for the user to turn off per-folder config. That will be in config in any case, that was never a question. >The .directory apprach is really bad for maintainance. For example, if the >user want to turn off "per-folder" setting, it's not possible to search for >all .desktop files and delete them. The drawbacks make this apprach less >appealing. It still have all that Pros that I mentioned above though. :) Well, it seems both .directory and cache approaches have too many Cons in eyes of you, people, so only acceptable one is to use xattr. It has own drawbacks too but combine two (or more) approaches is worse as that will bring problems when detection which approach to use fails by false positive. So I would avoid double-approach as much as possible. Thank you very much for all your opinions! >Cheers! Cheers! Andriy. |
From: PCMan <pcm...@gm...> - 2013-11-07 11:34:15
|
On Thu, Nov 7, 2013 at 7:02 PM, Andrej N. Gritsenko <an...@re...>wrote: > Hello! > > PCMan has written on Thursday, 7 November, at 11:22: > >On Thu, Nov 7, 2013 at 10:48 AM, Andrej N. Gritsenko <an...@re... > >wrote: > >> I'm currently working on implementation of next feature for PCManFM. > >> It is different sort and view mode for selected folders. I.e. user can > >> check an option 'Use these settings for this folder only' and sort (and > >> view mode) will be remembered for current folder independently from > >> common settings. The question is how to do that. I know two ways now: > > >> 1. Use '.directory' file in folder in question. > >> Pros: > >> - can be used by other implementations and other file managers; > >> - settings persist if folder is renamed; > >> - settings persist if folder is accessed other way (via ssh, ftp, > etc.). > >> Cons: > >> - can be used only if user can write into .directory file in folder. > > >> 2. Use cache file somewhere. > >> Pros: > >> - can be used against system directories (/usr for example). > >> Cons: > >> - completely implementation-dependent and even environment-dependent; > >> - settings are lost when folder is renamed; > >> - it may be impossible to have different settings for removable media; > >> - cache will grow indefinitely, no sane cleaning heuristics exist. > > >> I would appreciate all your opinions and I'm waiting for them until > I > >> start implementing it. Thank you in advance. > > >Well, I've been thinking about the issue for quite a long time but did not > >do it since I couldn't find a really satisfying solution. > >A cache is the most reliable, but it's hard to maintain and it's easy to > >break. > >Deleting dead entries in the cache periodically is needed. Otherwise the > >cache will be full of garbage after a period of time. > >Windows seems to use this approach and the info is in windows registry. > >Thunar uses similar way, and the info is stored in a tdb file. > >Tdb is the trivial key-value db developed by Samba and it's good enough > for > >the task. > >Nautilus seems to use similar approach, but they use text-based meta-info > >files stored somewhere rather than a db, which is very inefficient. > >A key-value based binary db with periodic dead-entry clearance is > >reasonable. > >Good candidates are samba tdb and sqlite. > > I really hate the cache solution - it is completely implementation > dependent and you even have to implement it exactly the same in each > application if you want them to be compatible. And yes, any cache is easy > to break if any crash happens in time of its rebuild. > > >Another good stuff to use is xattr. Most modern filesystems support it. > >This is the best place to store this kind of info. > >Pros: widely-available, creates no junk, can be accessed by others easily. > >Will not be included when you try to tar a dir (this beats the .directory > >approach). > >Cons: not available on read-only FS, remote FS, and windows FS, such as > >ntfs and vfat. > > >The last one is .directory approach. I like this one, too. Windows uses > >similar method to store other info, such as directory icon. It uses a > >hidden file "desktop.ini" in every folder for that. > >Pros: constant access speed. No db lookup, easy to implement, no other > >dependencies. Portable, easily managed, and can be preserved even when you > >create backup for the folder. > >Cons: When you create a tar file for the folder, it will be included. It's > >hard to delete them all if you want to uninstall pcmanfm. Also, remember > to > >add it to .gitignore. This is quite annoying. It's also visible to the > user > >if you turn on "show hidden files", which is really bad. > > >So, the best way I can figure out: > >1. For local filesystems, check xattr first. > > Well, that still have the same big limitation - when you go into the > folder via ssh or ftp, you get no setup for it. > > You can still add that sftp://path/to/your/folder to the cache. So next time it will work. Since you don't change that folder setting everyday, the user only need to do this setting once, which is not perfect, but acceptable. Besides, you may not want to use the same setting when you access the folder from another computer. For example, you have a very small monitor and you want to use a different view mode, then applying a hidden config file for another machine is not really that suitable in this case. > >2. If xattr is not availble or it's not a local FS, try the key-value > >db-based cache. > >3. remove dead entries from the db periodically. > > It is not possible really - you will remove all remembered data for > remote or removable media not currently connected. And since you have > proposed to use cache exactly for that purpose, that renders value of > that cache close to zero. In short - either not use cache, or accept its > unlimited growth, and other cons that I mentioned above. > > It's possible sometimes. For remote filesystems, just let it grows since we don't know wether the server is dead definitely or it's just shutdown for maintaince and will be online again. Same for removable devices. For "fixed" local filesystems which does not support xattrs, such as ntfs and vfat, detecting dead entries and remove them is possible. So, let entries for remote filesystems and removable devices grows, and only do cleanup for local filesystems with no xattrs support. Or, just don't do the clean up at all since normally the folder having customized settings won't be too many and setting custom folder settings is not a frequently done operation. The cache won't be too large anyways. > >4. Add UI options for the user to turn off per-folder config. > > That will be in config in any case, that was never a question. > > >The .directory apprach is really bad for maintainance. For example, if the > >user want to turn off "per-folder" setting, it's not possible to search > for > >all .desktop files and delete them. The drawbacks make this apprach less > >appealing. > > It still have all that Pros that I mentioned above though. :) > > Well, it seems both .directory and cache approaches have too many > Cons in eyes of you, people, so only acceptable one is to use xattr. It > has own drawbacks too but combine two (or more) approaches is worse as > that will bring problems when detection which approach to use fails by > false positive. So I would avoid double-approach as much as possible. > > I really think that the dual-mechanism should be used. If only xattr is used, then it's only possible to support per-folder config for sub folders under /home in the most cases since we have no write access to others. For removable devices using vfat or ntfs for compatibility reasons, we have no xattrs, too. So sometimes the functionality works, and sometimes it does not. The user will be confused by these inconsistent behavior. I still believed that a key-value db-based binary cache is the most reliable and managable way.The reason why I propose checking xattr first is simple. We can avoid using db when xattr is available. So that operation can be faster and we also save disk space at the same time. Crashes are not a real issue. We only need to choose a more reliable and robust db. Samba tdb and sqlite are quite robust ones. Samba tdb is used in samba and thunar. Sqlite is widely used everywhere, even in firefox. It's well-tested and robust enough for this trivial task. If unfortunately the db is broken, the worst case is you'll loose your folder view preference setting. That's all. > Thank you very much for all your opinions! > > >Cheers! > > Cheers! > Andriy. > |
From: Andrej N. G. <an...@re...> - 2013-11-07 13:10:06
|
Hello! PCMan has written on Thursday, 7 November, at 19:34: >On Thu, Nov 7, 2013 at 7:02 PM, Andrej N. Gritsenko <an...@re...>wrote: >> PCMan has written on Thursday, 7 November, at 11:22: >> >1. For local filesystems, check xattr first. >> Well, that still have the same big limitation - when you go into the >> folder via ssh or ftp, you get no setup for it. > You can still add that sftp://path/to/your/folder to the cache. So next >time it will work. Since you don't change that folder setting everyday, the >user only need to do this setting once, which is not perfect, but >acceptable. No, you don't get the point. I work on machine A and I have some folder which I strongly want to see in Detailed mode with column MP3tag included, and few other settings. I've done set it working on machine A. When I come to machine B, I go to that folder which is either mounted or accessed via sftp:// and I find it very inconvenient that I have to do that full setup again and again. Imagine if administrator wants to setup convenient environment for the office - he/she have to make setup for each user then on some shared folder, that is a huge inconvenience. >> >3. remove dead entries from the db periodically. >> It is not possible really - you will remove all remembered data for >> remote or removable media not currently connected. And since you have >> proposed to use cache exactly for that purpose, that renders value of >> that cache close to zero. In short - either not use cache, or accept its >> unlimited growth, and other cons that I mentioned above. > It's possible sometimes. For remote filesystems, just let it grows since >we don't know wether the server is dead definitely or it's just shutdown >for maintaince and will be online again. Same for removable devices. Well, another example. You have some remote filesystem automounted locally on-demand. Your cache cleaner worked when it's not mounted and found it was gone, removing all metadata. Then you come into that folder (which automounts as you go into it) and (isn't that cool?) you see your setup was magically vanished. And that may be everyday setup of course! >For "fixed" local filesystems which does not support xattrs, such as ntfs >and vfat, detecting dead entries and remove them is possible. >So, let entries for remote filesystems and removable devices grows, and >only do cleanup for local filesystems with no xattrs support. >Or, just don't do the clean up at all since normally the folder having It's what I said initially. :) >customized settings won't be too many and setting custom folder settings is >not a frequently done operation. The cache won't be too large anyways. May be you're right. > I really think that the dual-mechanism should be used. >If only xattr is used, then it's only possible to support per-folder config >for sub folders under /home in the most cases since we have no write access >to others. For removable devices using vfat or ntfs for compatibility >reasons, we have no xattrs, too. So sometimes the functionality works, and >sometimes it does not. The user will be confused by these inconsistent >behavior. Well, dual-mechanism may be incostistent too, in case if local FS is mounted R/O, then R/W. That sometimes happens. That is very rare case though, I'm agree. Still xattr might be available to read but user may not have access to change it, and even worse - it might be changed on the next mount yet giving another unpredictable result. >I still believed that a key-value db-based binary cache is the most >reliable and managable way.The reason why I propose checking xattr first is >simple. We can avoid using db when xattr is available. So that operation >can be faster and we also save disk space at the same time. It is not always true. Keyfile has only keys and values. Database has single list of keys, yes, but it has indexing and other internal data too so therefore often is much bigger. Especially if DB is crash-proof, that always has the price. >Crashes are not a real issue. We only need to choose a more reliable and >robust db. Samba tdb and sqlite are quite robust ones. Samba tdb is used in >samba and thunar. Sqlite is widely used everywhere, even in firefox. It's >well-tested and robust enough for this trivial task. >If unfortunately the db is broken, the worst case is you'll loose your >folder view preference setting. That's all. You may lose all the settings in any case - is that DB or is that a keyfile. That is always possible when you keep all the settings in one file. Unlike the caches, you cannot regenerate it as it is the only copy of the settings. Cheers! Andriy. |
From: <u-...@ae...> - 2013-11-07 12:00:31
|
On Thu, Nov 07, 2013 at 01:02:33PM +0200, Andrej N. Gritsenko wrote: > >3. remove dead entries from the db periodically. > > It is not possible really - you will remove all remembered data for > remote or removable media not currently connected. And since you have Not necessarily. You know which units are connected "right now". As long as you tag cache entries with units they belong to, you do not have to expire the entries belonging to missing units, unless the user explicitly says "I want to clean up the units' forest". This can be done by using a "global" name space for directories across unit mounts, say going by the unit's uuid or disk hardware id. For garbage collection let you walk the tree of currently connected ones, not crossing the "mount points" for disconnected units. > proposed to use cache exactly for that purpose, that renders value of > that cache close to zero. It doesn't look so. > Well, it seems both .directory and cache approaches have too many > Cons in eyes of you, people, so only acceptable one is to use xattr. It Xattr is in my eyes the most inferior, being the least portable and leading to differences in the behaviour depending on where you are in the file tree. This is confusing for the users. For my personal usage pattern the xattr approach would be plainly non-working. > has own drawbacks too but combine two (or more) approaches is worse as > that will bring problems when detection which approach to use fails by > false positive. So I would avoid double-approach as much as possible. Oh by the way, do not forget versioning of any kind of meta-information you choose to save (cache, ./.file or xattr). The data _will_ be exposed to different versions of the file manager, possibly simultaneously (iow "upgrading a format by rewriting in place" is a disaster). > Thank you very much for all your opinions! Thanks for listening Andrej. Regards, Rune |
From: Александр С. <sok...@gm...> - 2013-11-07 12:05:15
|
My two cents. I check how dolphin do it. Dolphin keep global settings in the ~/.kde4/share/apps/dolphin/view_properties/global/.directory file If local folder is writable, dolphin create .directory file in it, like [Dolphin] Timestamp=2013,11,7,15,41,52 Version=3 ViewMode=1 If local directory isn't writable, dolphin create path of directories in it's config dir. And put .directory file to this path. For example, I changed properties of /usr, as result ~/.kde4/share/apps/dolphin/view_properties/local/usr/.directory file was created. For all remote filesystems (I test ftp & smb) dolphin use one file ~/.kde4/share/apps/dolphin/view_properties/remote/.directory. -- Best regards, Alexander. |
From: <u-...@ae...> - 2013-11-07 13:24:05
|
On Thu, Nov 07, 2013 at 07:34:05PM +0800, PCMan wrote: > Crashes are not a real issue. We only need to choose a more reliable and > robust db. Having in mind the goal of keeping Lxde small I would suggest considering a compact one without any redundant features. > Samba tdb and sqlite are quite robust ones. Samba tdb is used in > samba and thunar. Sqlite is widely used everywhere, even in firefox. It's > well-tested and robust enough for this trivial task. Sqlite is a PITA as it assumes certain things about the file system and creates huge files (which are being regularly updated). (A distributed file system doing consistent caching of whole files gets a _lot_ of unnecessary work to do) I can hardly tell anything about robustness or other virtues of tdb. I have on the other side used rwcdb for many years, it is used for Coda file system account database, i.e. an extremely critical piece of infrastructure. AFAICT all the needed functionality of key-value management is present there in rwcdb. It is also highly portable. coda-6.9.5/lib-src/rwcdb$ ls -l *.o -rw-r--r-- 1 x x 2752 2013-04-26 13:54 rwcdb_file.o -rw-r--r-- 1 x x 8276 2013-04-26 13:54 rwcdb.o compare to: tdb-1.2.12/bin/default$ ls -l libtdb.so -rwxr-xr-x 1 x x 89697 2013-11-07 13:40 libtdb.so which means about 10-fold difference. --------------------------- README.rwcdb This library was written based on the design of Dan Bernstein's CDB database (see cdb.txt and reading.txt). The main difference is that rwcdb allows for (infrequent) updates to the database. This implementation has been tested to read and write compatible CDB databases as generated with the cdb tools from Dan Bernstein. ... int rwcdb_sync(struct rwcdb *c); Used as a synchronization point. For read-only databases this checks whether there is a new version of the database available. For readwrite or write-only databases, it flushes the pending modifications to a temporary file and if everything is successful, moves the new database file in place of the old database. ... --------------------------- It was written by Jan Harkes at CMU and released under LGPLv2. It is distributed as part of a regular Coda source package, e.g. http://www.coda.cs.cmu.edu/pub/coda/src/coda-6.9.5.tar.gz as coda-6.9.5/lib-src/rwcdb but totally independent of Coda otherwise. Regards, Rune |
From: Andrej N. G. <an...@re...> - 2013-11-07 15:59:26
|
Hello! u-...@ae... has written on Thursday, 7 November, at 14:23: >Having in mind the goal of keeping Lxde small I would suggest >considering a compact one without any redundant features. Well, we've completely lost point of discussion I've started. It is not about implementation of data storage. It is about where to store data about directory-related settings of pcmanfm. So far there are 3 variants: 1) the file '.directory' in the target folder; 2) the extended FS attributes of target folder; 3) the centralized storage somewhere inside homedir. The centralized storage has few drawbacks: 1) it is application dependent - you cannot use setting made in pcmanfm even by pcmanfm-qt, no tell about other applications; 2) it is environment dependent (due to different paths for different environments) - settings made in LXDE are not known for LXDE-Qt; 3) settings are specific to the machine, you cannot share settings for the same folder over your office or whatever; 4) settings will be reset after folder is renamed; 5) cannot set individual settings for two identical USB sticks, one of which has videos and other has backup data, even if user strictly wants to have them shown differently; 6) centralized storage will slowly grow in size. Yes, it has bright sides too: 1) it can be used for read-only folders as well; 2) it isn't OS dependent; 3) it does not create any files in target folder. Do you think those drawbacks aren't important for our users? Well, about dual-handle settings I would like then to use approaches (1) and (3) together: if file .directory already exists then use it, if not then use own settings storage to keep settings. The approach (2) is not portable while (1) and (3) are, you know. With best regards. Andriy. |
From: <u-...@ae...> - 2013-11-07 16:38:56
|
Hello Andriy, On Thu, Nov 07, 2013 at 05:59:16PM +0200, Andrej N. Gritsenko wrote: > The centralized storage has few drawbacks: > > 1) it is application dependent - you cannot use setting made in pcmanfm > even by pcmanfm-qt, no tell about other applications; > 2) it is environment dependent (due to different paths for different > environments) - settings made in LXDE are not known for LXDE-Qt; I guess #2 is due to the fact that it is different programs who potentially use it, thus the same as #1. > 3) settings are specific to the machine, you cannot share settings for > the same folder over your office or whatever; Unclear what you mean here. My (and many others') home directory is available on all machines I am using, with the same shared contents. A file-based storage somewhere under $HOME/.something would be working fine (as long as the implementation does not do something innapropriate, i.e. specifically incompatible with shareability). That's why I would dismiss #3 as well. > 4) settings will be reset after folder is renamed; Not if the rename is done via the same file manager (otherwise yes). > 5) cannot set individual settings for two identical USB sticks, one of > which has videos and other has backup data, even if user strictly > wants to have them shown differently; Why? As long as the settings refer to the sticks' hardware (and unique) identifier they will be separate. I tried already to explain this. Thus #5 is not valid either. > 6) centralized storage will slowly grow in size. But not indefinitely, mostly as large as to correspond to the user's needs, even with a simplistic garbage collector. The information storage volume would be roughly the same for all of the approaches. Thus I can not agree with #6. This leaves us: 1) it is application dependent 2) if the user renames a folder by a different program or from a separate $HOME then the setting for the folder get lost > Do you think those drawbacks aren't important for our users? Talking as a system administrator for quite a few computers and users: I believe that this would be better for my users than properties of the other two approaches. Thanks for working on this Andriy! (I guess this is the spelling of your name which you prefer, I didn't think about it when I used the one from the mail header, sorry for that) Regards, Rune |
From: PCMan <pcm...@gm...> - 2013-11-07 16:52:32
|
On Thu, Nov 7, 2013 at 11:59 PM, Andrej N. Gritsenko <an...@re...>wrote: > Hello! > > u-...@ae... has written on Thursday, 7 November, at 14:23: > >Having in mind the goal of keeping Lxde small I would suggest > >considering a compact one without any redundant features. > > Well, we've completely lost point of discussion I've started. It is > not about implementation of data storage. It is about where to store data > about directory-related settings of pcmanfm. So far there are 3 variants: > > 1) the file '.directory' in the target folder; > 2) the extended FS attributes of target folder; > 3) the centralized storage somewhere inside homedir. > > The centralized storage has few drawbacks: > > 1) it is application dependent - you cannot use setting made in pcmanfm > even by pcmanfm-qt, no tell about other applications; > This is not true. If you use a well-know format, such as tdb or sqlite, libraries are readily available for reading them. Also, it's not a problem for pcmanfm-qt. Ideally this implementation detail should be done in libfm core. So other programs using it should have access to the settings via APIs without touching the underlying storage. > 2) it is environment dependent (due to different paths for different > environments) - settings made in LXDE are not known for LXDE-Qt; > Yes, they'll be known by lxde-qt. The problem is the uris are not known by kde. Other gio/gvfs using DEs should all know the paths/uris generated by gio. I don't see any problems here. > 3) settings are specific to the machine, you cannot share settings for > the same folder over your office or whatever; > This is true. It's a limitation. Xattr has the same problem. Only .directory approach solves this. > 4) settings will be reset after folder is renamed; > Indeed, but if the renaming is done by libfm, we can handle it. If it's not, then there is no way to update the data. > 5) cannot set individual settings for two identical USB sticks, one of > which has videos and other has backup data, even if user strictly > wants to have them shown differently; > This is partially true. If you also store uuid of the device, then it's solved. > 6) centralized storage will slowly grow in size. > Distributed storage will grow as well, but you just don't know where they are and how to clean them. > > Yes, it has bright sides too: > > 1) it can be used for read-only folders as well; > 2) it isn't OS dependent; > 3) it does not create any files in target folder. > > Do you think those drawbacks aren't important for our users? > Creating unwanted hidden files in the folders behind our back automatically can be very annoying sometimes. It's a matter of taste. But I'm ok with this solution as well since creating in-folder hidden config files is a general practice and it's done by Mac and Windows for years. > > Well, about dual-handle settings I would like then to use approaches (1) > and (3) together: if file .directory already exists then use it, if not > then use own settings storage to keep settings. The approach (2) is not > portable while (1) and (3) are, you know. > Yes, after thinking about it more, I think adding xttr can be too complicated. The only real benefit of it is no additional files are created and it's fast to access without any db query. However, it's not easy to maintain and may make things more complicated than they should be. Try .directory first then fallback to our own cache just like dolphin seems to be reasonable. Since there is no perfect solution I'm ok with less optimized approaches given they work well. Regards > > With best regards. > Andriy. > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Pcmanfm-develop mailing list > Pcm...@li... > https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop > |
From: Andrej N. G. <an...@re...> - 2013-11-07 17:36:23
|
Hello! PCMan has written on Friday, 8 November, at 0:52: >On Thu, Nov 7, 2013 at 11:59 PM, Andrej N. Gritsenko <an...@re...>wrote: >> The centralized storage has few drawbacks: >> 1) it is application dependent - you cannot use setting made in pcmanfm >> even by pcmanfm-qt, no tell about other applications; >This is not true. If you use a well-know format, such as tdb or sqlite, >libraries are readily available for reading them. Also, it's not a problem >for pcmanfm-qt. I should've explained it better it seems. Well, you have your storage in ~/.config/pcmanfm/LXDE/dirs-config file (just an example). How do you expect any other programs or non-LXDE environment to reach that storage? >Ideally this implementation detail should be done in libfm core. So other >programs using it should have access to the settings via APIs without >touching the underlying storage. I heavily against putting GUI-related things into libfm core. And that is exactly GUI-related, view mode has no relations to common file manager operations. And since it is used only internally in pcmanfm, it is simply should be done in pcmanfm itself. >> 5) cannot set individual settings for two identical USB sticks, one of >> which has videos and other has backup data, even if user strictly >> wants to have them shown differently; >This is partially true. If you also store uuid of the device, then it's >solved. I've replied it already in other mail. We should add additional APIs and stuff to retrieve and store uuids, that will bloat it a bit again. And I don't want to extend libfm API at this point anymore. >Creating unwanted hidden files in the folders behind our back automatically >can be very annoying sometimes. It's a matter of taste. But I'm ok with >this solution as well since creating in-folder hidden config files is a >general practice and it's done by Mac and Windows for years. As I said already, I have no intentions to remember setting for each folder visited. I know, many file managers do that but I would implement that setting only by explicit user's request, and if user never requested that operation then storage size is 0, no info will be saved at all. >> Well, about dual-handle settings I would like then to use approaches (1) >> and (3) together: if file .directory already exists then use it, if not >> then use own settings storage to keep settings. The approach (2) is not >> portable while (1) and (3) are, you know. >Yes, after thinking about it more, I think adding xttr can be too >complicated. >The only real benefit of it is no additional files are created and it's >fast to access without any db query. However, it's not easy to maintain and >may make things more complicated than they should be. >Try .directory first then fallback to our own cache just like dolphin seems >to be reasonable. Since there is no perfect solution I'm ok with less >optimized approaches given they work well. Thank you very much. Andriy. |
From: Andrej N. G. <an...@re...> - 2013-11-07 17:08:13
|
Hello! u-...@ae... has written on Thursday, 7 November, at 17:38: >On Thu, Nov 07, 2013 at 05:59:16PM +0200, Andrej N. Gritsenko wrote: >> The centralized storage has few drawbacks: >> 1) it is application dependent - you cannot use setting made in pcmanfm >> even by pcmanfm-qt, no tell about other applications; >> 2) it is environment dependent (due to different paths for different >> environments) - settings made in LXDE are not known for LXDE-Qt; >I guess #2 is due to the fact that it is different programs who potentially >use it, thus the same as #1. >> 3) settings are specific to the machine, you cannot share settings for >> the same folder over your office or whatever; >Unclear what you mean here. My (and many others') home directory is >available on all machines I am using, with the same shared contents. A >file-based storage somewhere under $HOME/.something would be working fine >(as long as the implementation does not do something innapropriate, >i.e. specifically incompatible with shareability). That's why I would >dismiss #3 as well. Well, you have folder ~/Video available on machine A and you set it to use Thumbnails View mode. On machine B you have default view mode as Detailed List View. You can get that folder opened on the machine B as sftp://A/home/user/Video. Guess how it will be shown on machine B? If you think it will be in Thumbnails View mode then you've failed. It will be shown in Detailed List View mode. User may expect it to be shown in the Thumbnails View on machine B, C, etc. That can be achieved though with .directory approach only. >> 4) settings will be reset after folder is renamed; >Not if the rename is done via the same file manager (otherwise yes). Well, we should put hooks everywhere to handle that, that will bloat the file manager (who dare to call it lightweight after that?). And also you wrote yourself, that is only if you rename via the same file manager and that isn't always the case, a lot of users use a lot of different tools. So we shouldn't do it in the file manager either, for consistency and to keep it still lightweight. >> 5) cannot set individual settings for two identical USB sticks, one of >> which has videos and other has backup data, even if user strictly >> wants to have them shown differently; >Why? As long as the settings refer to the sticks' hardware (and unique) >identifier they will be separate. I tried already to explain this. >Thus #5 is not valid either. Unfortunately, we never refer to sticks' hardware, we don't work with the hardware directly but we use GVFS, and the same stick will have generic name such as 'USB Dongle 16GB'. Trying to retrieve hardware identifier and use it back and forth means we should add few hooks, bloating the code again. I'm heavily against any code bloating as I said, I stay on the KISS principle - if that cannot be done simply then it should not be done at all. >> 6) centralized storage will slowly grow in size. >But not indefinitely, mostly as large as to correspond to the user's needs, >even with a simplistic garbage collector. >The information storage volume would be roughly the same for all of >the approaches. Well, it will be a bit bigger for some folders that were gone but file manager does not know yet about it. Though it is very little difference so I should agree with you, it may be safely ignored. >Thus I can not agree with #6. >This leaves us: >1) it is application dependent >2) if the user renames a folder by a different program or from a separate > $HOME then the setting for the folder get lost >> Do you think those drawbacks aren't important for our users? >Talking as a system administrator for quite a few computers and users: >I believe that this would be better for my users than properties of the >other two approaches. Thank you very much for sharing your opinion! >Thanks for working on this Andriy! >(I guess this is the spelling of your name which you prefer, I didn't >think about it when I used the one from the mail header, sorry for that) Nothing to be sorry for. In fact, both those names are right, just in different languages (Russian and Ukrainian) that I communicate the most. I just like the Ukrainian language a bit more, that's all. :) >Regards, >Rune With best regards. Andriy. |
From: <u-...@ae...> - 2013-11-08 08:48:19
|
Hello Andriy, On Thu, Nov 07, 2013 at 07:08:03PM +0200, Andrej N. Gritsenko wrote: > >> 3) settings are specific to the machine, you cannot share settings for > >> the same folder over your office or whatever; > >Unclear what you mean here. My (and many others') home directory is > >available on all machines I am using, with the same shared contents. A > Well, you have folder ~/Video available on machine A and you set it to > use Thumbnails View mode. On machine B you have default view mode as > Detailed List View. You can get that folder opened on the machine B as > sftp://A/home/user/Video. Guess how it will be shown on machine B? If you The problem you describe is easily overcome by explicitly changing the settings for the path where the "auxiliary folder" is connected. Then the setting will be accurate as it will reflect both the data properties _and_ the properties of the terminal being used to view the data. Even if you would store the metadata inside each directory you should tag it with all the relevant variables like "terminal" (the screen instance with its particilarities), "user" (as the preferences will vary depending on who is looking at that directory) and possibly even more. While storing the metadata per-user you have to also tag it with "unit" i.e. which external disk instance or which computer the data is located at. (To ease the maintenance of the metadata you might also encourage the user to synchronize the metadata database between her home directories on different computers) > code again. I'm heavily against any code bloating as I said, I stay on > the KISS principle - if that cannot be done simply then it should not be > done at all. Then I would say there should be one single and easily temporarily changeable folder view preference, common for all folders, like this is done in Rox-filer. Easy to implement, easy to understand for the user. The idea of adding metadata to each directory is just calling for a lot of effort and "code bloat" to make it even "good enough". Thanks for taking up this discussion but it looks like the feature would in any case somewhat "bloat" the file manager, both in code, memory _and_ the complexity of the UI. In my eyes this is hardly worth a functionality which quite certainly can be surprising and irritating for some of the users (creating extra files as soon as a directory is writable? no thanks! oh, did I have to change something in Preferences to avoid this?? too late...) Please use your time not for this challenge but for other ones around LXDE, there are many which may help users more. > I just like the Ukrainian language a bit more, that's all. :) :) Regards, Rune |
From: Александр С. <sok...@gm...> - 2013-11-07 17:13:03
|
The non centralized storage has another one drawback: If multiple users have write permission on the directory (for example it's mounted nfs or smb share) then the one user will overwrite the settings of another. 2013/11/7 Andrej N. Gritsenko <an...@re...> > Hello! > > u-...@ae... has written on Thursday, 7 November, at 17:38: > >On Thu, Nov 07, 2013 at 05:59:16PM +0200, Andrej N. Gritsenko wrote: > >> The centralized storage has few drawbacks: > > >> 1) it is application dependent - you cannot use setting made in pcmanfm > >> even by pcmanfm-qt, no tell about other applications; > >> 2) it is environment dependent (due to different paths for different > >> environments) - settings made in LXDE are not known for LXDE-Qt; > > >I guess #2 is due to the fact that it is different programs who > potentially > >use it, thus the same as #1. > > >> 3) settings are specific to the machine, you cannot share settings for > >> the same folder over your office or whatever; > > >Unclear what you mean here. My (and many others') home directory is > >available on all machines I am using, with the same shared contents. A > >file-based storage somewhere under $HOME/.something would be working fine > >(as long as the implementation does not do something innapropriate, > >i.e. specifically incompatible with shareability). That's why I would > >dismiss #3 as well. > > Well, you have folder ~/Video available on machine A and you set it to > use Thumbnails View mode. On machine B you have default view mode as > Detailed List View. You can get that folder opened on the machine B as > sftp://A/home/user/Video. Guess how it will be shown on machine B? If you > think it will be in Thumbnails View mode then you've failed. It will be > shown in Detailed List View mode. User may expect it to be shown in the > Thumbnails View on machine B, C, etc. That can be achieved though with > .directory approach only. > > >> 4) settings will be reset after folder is renamed; > > >Not if the rename is done via the same file manager (otherwise yes). > > Well, we should put hooks everywhere to handle that, that will bloat the > file manager (who dare to call it lightweight after that?). And also you > wrote yourself, that is only if you rename via the same file manager and > that isn't always the case, a lot of users use a lot of different tools. > So we shouldn't do it in the file manager either, for consistency and to > keep it still lightweight. > > >> 5) cannot set individual settings for two identical USB sticks, one of > >> which has videos and other has backup data, even if user strictly > >> wants to have them shown differently; > > >Why? As long as the settings refer to the sticks' hardware (and unique) > >identifier they will be separate. I tried already to explain this. > >Thus #5 is not valid either. > > Unfortunately, we never refer to sticks' hardware, we don't work with the > hardware directly but we use GVFS, and the same stick will have generic > name such as 'USB Dongle 16GB'. Trying to retrieve hardware identifier > and use it back and forth means we should add few hooks, bloating the > code again. I'm heavily against any code bloating as I said, I stay on > the KISS principle - if that cannot be done simply then it should not be > done at all. > > >> 6) centralized storage will slowly grow in size. > > >But not indefinitely, mostly as large as to correspond to the user's > needs, > >even with a simplistic garbage collector. > >The information storage volume would be roughly the same for all of > >the approaches. > > Well, it will be a bit bigger for some folders that were gone but file > manager does not know yet about it. Though it is very little difference > so I should agree with you, it may be safely ignored. > > >Thus I can not agree with #6. > > >This leaves us: > > >1) it is application dependent > >2) if the user renames a folder by a different program or from a separate > > $HOME then the setting for the folder get lost > > >> Do you think those drawbacks aren't important for our users? > > >Talking as a system administrator for quite a few computers and users: > >I believe that this would be better for my users than properties of the > >other two approaches. > > Thank you very much for sharing your opinion! > > >Thanks for working on this Andriy! > > >(I guess this is the spelling of your name which you prefer, I didn't > >think about it when I used the one from the mail header, sorry for that) > > Nothing to be sorry for. In fact, both those names are right, just in > different languages (Russian and Ukrainian) that I communicate the most. > I just like the Ukrainian language a bit more, that's all. :) > > >Regards, > >Rune > > With best regards. > Andriy. > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > -- Best regards, Alexander. |
From: PCMan <pcm...@gm...> - 2013-11-08 01:47:32
|
On Fri, Nov 8, 2013 at 1:12 AM, Александр Соколов <sok...@gm...>wrote: > The non centralized storage has another one drawback: > If multiple users have write permission on the directory (for example it's > mounted nfs or smb share) then the one user will overwrite the settings of > another. > > Yes, this argument is quite valid. Do you know how dolphin solves this? This happens quite frequently. It also happen if two users mount the same removable device. > > 2013/11/7 Andrej N. Gritsenko <an...@re...> > >> Hello! >> >> u-...@ae... has written on Thursday, 7 November, at 17:38: >> >On Thu, Nov 07, 2013 at 05:59:16PM +0200, Andrej N. Gritsenko wrote: >> >> The centralized storage has few drawbacks: >> >> >> 1) it is application dependent - you cannot use setting made in pcmanfm >> >> even by pcmanfm-qt, no tell about other applications; >> >> 2) it is environment dependent (due to different paths for different >> >> environments) - settings made in LXDE are not known for LXDE-Qt; >> >> >I guess #2 is due to the fact that it is different programs who >> potentially >> >use it, thus the same as #1. >> >> >> 3) settings are specific to the machine, you cannot share settings for >> >> the same folder over your office or whatever; >> >> >Unclear what you mean here. My (and many others') home directory is >> >available on all machines I am using, with the same shared contents. A >> >file-based storage somewhere under $HOME/.something would be working fine >> >(as long as the implementation does not do something innapropriate, >> >i.e. specifically incompatible with shareability). That's why I would >> >dismiss #3 as well. >> >> Well, you have folder ~/Video available on machine A and you set it to >> use Thumbnails View mode. On machine B you have default view mode as >> Detailed List View. You can get that folder opened on the machine B as >> sftp://A/home/user/Video. Guess how it will be shown on machine B? If you >> think it will be in Thumbnails View mode then you've failed. It will be >> shown in Detailed List View mode. User may expect it to be shown in the >> Thumbnails View on machine B, C, etc. That can be achieved though with >> .directory approach only. >> >> >> 4) settings will be reset after folder is renamed; >> >> >Not if the rename is done via the same file manager (otherwise yes). >> >> Well, we should put hooks everywhere to handle that, that will bloat the >> file manager (who dare to call it lightweight after that?). And also you >> wrote yourself, that is only if you rename via the same file manager and >> that isn't always the case, a lot of users use a lot of different tools. >> So we shouldn't do it in the file manager either, for consistency and to >> keep it still lightweight. >> >> >> 5) cannot set individual settings for two identical USB sticks, one of >> >> which has videos and other has backup data, even if user strictly >> >> wants to have them shown differently; >> >> >Why? As long as the settings refer to the sticks' hardware (and unique) >> >identifier they will be separate. I tried already to explain this. >> >Thus #5 is not valid either. >> >> Unfortunately, we never refer to sticks' hardware, we don't work with the >> hardware directly but we use GVFS, and the same stick will have generic >> name such as 'USB Dongle 16GB'. Trying to retrieve hardware identifier >> and use it back and forth means we should add few hooks, bloating the >> code again. I'm heavily against any code bloating as I said, I stay on >> the KISS principle - if that cannot be done simply then it should not be >> done at all. >> >> >> 6) centralized storage will slowly grow in size. >> >> >But not indefinitely, mostly as large as to correspond to the user's >> needs, >> >even with a simplistic garbage collector. >> >The information storage volume would be roughly the same for all of >> >the approaches. >> >> Well, it will be a bit bigger for some folders that were gone but file >> manager does not know yet about it. Though it is very little difference >> so I should agree with you, it may be safely ignored. >> >> >Thus I can not agree with #6. >> >> >This leaves us: >> >> >1) it is application dependent >> >2) if the user renames a folder by a different program or from a separate >> > $HOME then the setting for the folder get lost >> >> >> Do you think those drawbacks aren't important for our users? >> >> >Talking as a system administrator for quite a few computers and users: >> >I believe that this would be better for my users than properties of the >> >other two approaches. >> >> Thank you very much for sharing your opinion! >> >> >Thanks for working on this Andriy! >> >> >(I guess this is the spelling of your name which you prefer, I didn't >> >think about it when I used the one from the mail header, sorry for that) >> >> Nothing to be sorry for. In fact, both those names are right, just in >> different languages (Russian and Ukrainian) that I communicate the most. >> I just like the Ukrainian language a bit more, that's all. :) >> >> >Regards, >> >Rune >> >> With best regards. >> Andriy. >> >> >> ------------------------------------------------------------------------------ >> November Webinars for C, C++, Fortran Developers >> Accelerate application performance with scalable programming models. >> Explore >> techniques for threading, error checking, porting, and tuning. Get the >> most >> from the latest Intel processors and coprocessors. See abstracts and >> register >> >> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk >> _______________________________________________ >> Lxde-list mailing list >> Lxd...@li... >> https://lists.sourceforge.net/lists/listinfo/lxde-list >> > > > > -- > Best regards, > Alexander. > > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. > Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and > register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Lxde-list mailing list > Lxd...@li... > https://lists.sourceforge.net/lists/listinfo/lxde-list > > |