From: Andrej N. G. <an...@re...> - 2012-11-16 21:28:43
|
Hello! In latest GIT sources of libfm is implemented support of templates. It catches both system and user defined templates and correctly supports both GNOME style templates and KDE style templates. Behavior of templates support in context menu can be altered by libfm.conf variables: only_user_templates: defines if use system+user templates or only user. template_run_app: defines if 'Create New...' should just create file or also run default application for that file type after creation. Installed templates will be shown in 'Create New...' submenu of the folder context menu with textual description (most possibly localized). Anyone who can compile it from sources and want to test it are welcome. I would like to get all possible feedback from you. Thank you very much. With the best wishes. Andriy. |
From: Sergio <ser...@ya...> - 2012-11-17 17:20:15
|
--- Em sex, 16/11/12, Andrej N. Gritsenko <an...@re...> escreveu: > De: Andrej N. Gritsenko <an...@re...> > Assunto: [Pcmanfm-develop] Templates support in libfm. > Para: pcm...@li... > Cc: lxd...@li... > Data: Sexta-feira, 16 de Novembro de 2012, 19:28 > Hello! > > In latest GIT sources of libfm is implemented > support of templates. > It catches both system and user defined templates and > correctly supports > both GNOME style templates and KDE style templates. Behavior > of templates > support in context menu can be altered by libfm.conf > variables: > > only_user_templates: defines if use system+user templates or > only user. > template_run_app: defines if 'Create New...' should just > create file or > also run default application for > that file type after creation. > > Installed templates will be shown in 'Create > New...' submenu of the > folder context menu with textual description (most possibly > localized). > Anyone who can compile it from sources and want to test it > are welcome. > I would like to get all possible feedback from you. Thank > you very much. > > With the best wishes. > Andriy. > > Hi, how are these GNOME and KDE template formats? If it's just any file with a descriptive name and some common content then it works in Thunar but not in pcmanfm: http://www.zimagez.com/zimage/screenshot-11172012-031118pm.php http://www.zimagez.com/zimage/screenshot-11172012-031118pm.php I forgot if it worked in pcmanfm before this change. Also, as seen on the image, context menu offers only to create a new 'Folder'. In Edit menu it still offers 'Blank File' but it doesn't work. A side-note is that that desktop file is called 'Desktop File' (not 'Desktop File.desktop') and pcmanfm recognizes it's a desktop file by its contents and doesn't display its name (because the 'Name' key is empty). |
From: Sergio <ser...@ya...> - 2012-11-17 17:25:14
|
--- Em sáb, 17/11/12, Sergio <ser...@ya...> escreveu: > De: Sergio <ser...@ya...> > Assunto: Re: [Pcmanfm-develop] Templates support in libfm. > Para: pcm...@li..., "Andrej N. Gritsenko" <an...@re...> > Data: Sábado, 17 de Novembro de 2012, 15:20 > > > --- Em sex, 16/11/12, Andrej N. Gritsenko <an...@re...> > escreveu: > > > De: Andrej N. Gritsenko <an...@re...> > > Assunto: [Pcmanfm-develop] Templates support in libfm. > > Para: pcm...@li... > > Cc: lxd...@li... > > Data: Sexta-feira, 16 de Novembro de 2012, 19:28 > > Hello! > > > > In latest GIT sources of libfm is implemented > > support of templates. > > It catches both system and user defined templates and > > correctly supports > > both GNOME style templates and KDE style templates. > Behavior > > of templates > > support in context menu can be altered by libfm.conf > > variables: > > > > only_user_templates: defines if use system+user > templates or > > only user. > > template_run_app: defines if 'Create New...' should > just > > create file or > > also run default application for > > that file type after creation. > > > > Installed templates will be shown in 'Create > > New...' submenu of the > > folder context menu with textual description (most > possibly > > localized). > > Anyone who can compile it from sources and want to test > it > > are welcome. > > I would like to get all possible feedback from you. > Thank > > you very much. > > > > With the best wishes. > > Andriy. > > > > > > Hi, how are these GNOME and KDE template formats? > If it's just any file with a descriptive name and some > common content then it works in Thunar but not in pcmanfm: > http://www.zimagez.com/zimage/screenshot-11172012-031118pm.php > http://www.zimagez.com/zimage/screenshot-11172012-031118pm.php (correct here →) http://www.zimagez.com/zimage/screenshot-11172012-031256pm.php > > I forgot if it worked in pcmanfm before this change. > > Also, as seen on the image, context menu offers only to > create a new 'Folder'. In Edit menu it still offers 'Blank > File' but it doesn't work. > > A side-note is that that desktop file is called 'Desktop > File' (not 'Desktop File.desktop') and pcmanfm recognizes > it's a desktop file by its contents and doesn't display its > name (because the 'Name' key is empty). > > Ops. I posted both screenshots of Thunar. Here's pcmanfm: http://www.zimagez.com/zimage/screenshot-11172012-031256pm.php |
From: Sergio <ser...@ya...> - 2012-11-17 17:30:19
|
> > > > Hi, how are these GNOME and KDE template formats? > > If it's just any file with a descriptive name and some > > common content then it works in Thunar but not in > pcmanfm: > >(thunar→) http://www.zimagez.com/zimage/screenshot-11172012-031118pm.php > (correct pcmanfm here →) http://www.zimagez.com/zimage/screenshot-11172012-031256pm.php > > > > I forgot if it worked in pcmanfm before this change. > > > > Also, as seen on the image, context menu offers only > to > > create a new 'Folder'. In Edit menu it still offers > 'Blank > > File' but it doesn't work. > > > > A side-note is that that desktop file is called > 'Desktop > > File' (not 'Desktop File.desktop') and pcmanfm > recognizes > > it's a desktop file by its contents and doesn't display > its > > name (because the 'Name' key is empty). > > > > Note: I don't have the latest 3 commits to libfm so when I build it again I test it again. |
From: Andrej N. G. <an...@re...> - 2012-11-17 21:07:18
|
Hello! Sergio has written on Saturday, 17 November, at 9:30: >> > Hi, how are these GNOME and KDE template formats? GNOME way is to create (empty or minimal, depending on what you want) file in ~/Templates, such as: image.jpeg script.sh file.txt document.odt KDE way is to create some ShellScript.desktop file with contents: [Desktop Entry] Name=Shell script ... Comment=Enter the shell script file name: Type=Link URL=script.sh Icon=system-run >> > If it's just any file with a descriptive name and some >> > common content then it works in Thunar but not in >> pcmanfm: >> >(thunar→) http://www.zimagez.com/zimage/screenshot-11172012-031118pm.php >> (correct pcmanfm here →) http://www.zimagez.com/zimage/screenshot-11172012-031256pm.php I see. Your files seems to be something neither clean GNOME nor KDE. >> > I forgot if it worked in pcmanfm before this change. Never. It's new functionality, it's why I asked you to test. >> > Also, as seen on the image, context menu offers only >> to >> > create a new 'Folder'. In Edit menu it still offers >> 'Blank >> > File' but it doesn't work. I hope, 'Blank File' in Edit menu should work after last changes. And context menu shows only entries which were recognized. There was no deep test (for file content) done because in most cases (as GNOME way assumes often empty file) template type should be recognized by its name. Therefore your non-suffixed files were ignored. And since file name is a hint to create new file from template (where suffix is preserved and the dialog offers you to change name part of file name - i.e. from text.txt you'll replace "text" while ".txt" will stay) it's not convenient to have it not-suffixed. >> > A side-note is that that desktop file is called >> 'Desktop >> > File' (not 'Desktop File.desktop') and pcmanfm >> recognizes >> > it's a desktop file by its contents and doesn't display >> its >> > name (because the 'Name' key is empty). Yes, pcmanfm folder view will recognize it but templates filter (which attempts to remove duplicates, hidden and invalid entries) assumes it is not template. May be the templates filter of libfm should be loosed a bit. I would like to see file names of your templates and contents of them to have clues. You know, loosing the check may make duplicates and wrong entries other users will complain about... that's hard decision. I have, for example, 19 entries in /usr/share/templates, and only 5 of those are functional, others work only in KDE4. And some number of entries are under /opt/* as well. And without check I can end up with very big list where most will not work. And guessing from contents may give such recognitions as "undefined" or "binary file" (application/octet-stream. How about some prompt text: "Enter the name for new Undefined:" in window "Creating new Undefined"? Are you sure it is OK to have such entries in templates submenu? ;) I understand, user should blame himself if he/she puts such junk into Templates folder but I think we should filter it. Or we should not? If it's better not filter such things I will enable guessing from content. What do you think? WBR, Andriy. |
From: Stephan S. <gma...@sp...> - 2012-11-17 21:37:13
|
On 12-11-17 04:07 PM, Andrej N. Gritsenko wrote: > > GNOME way is to create (empty or minimal, depending on what you want) > file in ~/Templates, such as: > > image.jpeg > script.sh > file.txt > document.odt > > KDE way is to create some ShellScript.desktop file with contents: So, let me get this straight. GNOME somehow managed to get the Nautilus templates folder into ~/.config/user-dirs.dirs alongside stuff that's actually used by more than one application in the same desktop environment like the desktop, documents, downloads, pictures, and music folders? My first (sane) impression was that it was something where you drop templates for all applications and each application filters by filetype for only its own formats but, if I understand you correctly, doing so would render Nautilus's New menu uselessly large. (eg. Suppose everything supported it and I dropped 10 LibreOffice templates and 5 Inkscape ones in there.) Given that I've never seen a file manager other than Nautilus that supports parsing a ".hidden" file to hide non-dotfiles, I tend to blame GNOME developers' NIH syndrome whenever I see a non-hidden folder in my homedir getting regenerated but I don't actually expect to see such an impression confirmed in a standard. |
From: Andrej N. G. <an...@re...> - 2012-11-17 22:02:03
|
Hello! Stephan Sokolow has written on Saturday, 17 November, at 16:36: >On 12-11-17 04:07 PM, Andrej N. Gritsenko wrote: >> >> GNOME way is to create (empty or minimal, depending on what you want) >> file in ~/Templates, such as: >> >> image.jpeg >> script.sh >> file.txt >> document.odt >> > > KDE way is to create some ShellScript.desktop file with contents: >So, let me get this straight. GNOME somehow managed to get the Nautilus >templates folder into ~/.config/user-dirs.dirs alongside stuff that's >actually used by more than one application in the same desktop >environment like the desktop, documents, downloads, pictures, and music >folders? Precisely. It's XDG_TEMPLATES_DIR statement in that file. >My first (sane) impression was that it was something where you drop >templates for all applications and each application filters by filetype >for only its own formats but, if I understand you correctly, doing so >would render Nautilus's New menu uselessly large. >(eg. Suppose everything supported it and I dropped 10 LibreOffice >templates and 5 Inkscape ones in there.) Exactly. Each file in ~/Templates will be added by Nautilus to the 'New' submenu. I've implemented it such way pcmanfm will show only one file per file type (i.e. only one LibreOffice text doc or only one JPEG file) and it's why I do some filtering which caused the beforementioned effect. >Given that I've never seen a file manager other than Nautilus that >supports parsing a ".hidden" file to hide non-dotfiles, I tend to blame >GNOME developers' NIH syndrome whenever I see a non-hidden folder in my >homedir getting regenerated but I don't actually expect to see such an >impression confirmed in a standard. GNOME ways are sometimes very out of common sense. That's why I prefer to avoid GNOME ways sometimes. :) Cheers! Andriy. |
From: Stephan S. <gma...@sp...> - 2012-11-17 22:24:41
|
On 12-11-17 05:01 PM, Andrej N. Gritsenko wrote: > Hello! > > Stephan Sokolow has written on Saturday, 17 November, at 16:36: >> So, let me get this straight. GNOME somehow managed to get the Nautilus >> templates folder into ~/.config/user-dirs.dirs alongside stuff that's >> actually used by more than one application in the same desktop >> environment like the desktop, documents, downloads, pictures, and music >> folders? > > Precisely. It's XDG_TEMPLATES_DIR statement in that file. I should have phrased that differently. What I had trouble believing was XDG_TEMPLATES_DIR is in a state of "Use it as intended, break your file manager" limbo. > > Exactly. Each file in ~/Templates will be added by Nautilus to the 'New' > submenu. I've implemented it such way pcmanfm will show only one file per > file type (i.e. only one LibreOffice text doc or only one JPEG file) and > it's why I do some filtering which caused the beforementioned effect. > Do you have a clear plan for how the user will select the one to appear? (Hopefully, something less amateurish than how, in the 2000s, all the Windows users were sticking "!!" at the beginning of their torrents' README files to game the explorer.exe sorting algorithm) Also, have you given any thought to potential alternative implementations that could overcome that "one entry per type" limitation? (eg. Suppose I wanted multiple .txt templates and I wasn't using Vim+SnipMate for that) >> Given that I've never seen a file manager other than Nautilus that >> supports parsing a ".hidden" file to hide non-dotfiles, I tend to blame >> GNOME developers' NIH syndrome whenever I see a non-hidden folder in my >> homedir getting regenerated but I don't actually expect to see such an >> impression confirmed in a standard. > > GNOME ways are sometimes very out of common sense. That's why I prefer to > avoid GNOME ways sometimes. :) Agreed, though I'd definitely love it if ".hidden" started to get used outside Nautilus so I could have the option of hiding things I almost never visit and only in the terminal (like /proc and /sys) from my GTK+ Open/Save dialogs and PCManFM. It'd make for a much cleaner experience. ...not to mention allowing me to hide things like ~/espeak-data while I wait to see if devs are going to actually fix reported use-of-filesystem bugs. |
From: Andrej N. G. <an...@re...> - 2012-11-17 23:20:54
|
Hello! Stephan Sokolow has written on Saturday, 17 November, at 17:24: >On 12-11-17 05:01 PM, Andrej N. Gritsenko wrote: >> Exactly. Each file in ~/Templates will be added by Nautilus to the 'New' >> submenu. I've implemented it such way pcmanfm will show only one file per >> file type (i.e. only one LibreOffice text doc or only one JPEG file) and >> it's why I do some filtering which caused the beforementioned effect. >Do you have a clear plan for how the user will select the one to appear? >(Hopefully, something less amateurish than how, in the 2000s, all the >Windows users were sticking "!!" at the beginning of their torrents' >README files to game the explorer.exe sorting algorithm) The implementation allows creation of simple .desktop file which will override any names and select one of them which will be used as template. For example: [Desktop Entry] Type=Link URL=The Document.odt >Also, have you given any thought to potential alternative >implementations that could overcome that "one entry per type" >limitation? (eg. Suppose I wanted multiple .txt templates and I wasn't >using Vim+SnipMate for that) The way I've implemented it removes duplicates but probably it would be good to add a setting to select another behavior - remove duplicates by basename, not by type. It will show all your LibreOffice documents from your example in 'Create New' submenu though. >>> Given that I've never seen a file manager other than Nautilus that >>> supports parsing a ".hidden" file to hide non-dotfiles, I tend to blame >>> GNOME developers' NIH syndrome whenever I see a non-hidden folder in my >>> homedir getting regenerated but I don't actually expect to see such an >>> impression confirmed in a standard. >> GNOME ways are sometimes very out of common sense. That's why I prefer to >> avoid GNOME ways sometimes. :) >Agreed, though I'd definitely love it if ".hidden" started to get used >outside Nautilus so I could have the option of hiding things I almost >never visit and only in the terminal (like /proc and /sys) from my GTK+ >Open/Save dialogs and PCManFM. It'd make for a much cleaner experience. >...not to mention allowing me to hide things like ~/espeak-data while I >wait to see if devs are going to actually fix reported use-of-filesystem >bugs. I would like to avoid such things very much. They may be changed by GNOME people in any moment and if I want to follow any step of GNOME then I would just use GNOME. Let follow standards (XDG specifications). If we reimplement some bloated and dirty things we multiply the mess which they made for own sake. The more we use Nautilus hacks the more we will behave Nautilus-like, heavy and fat. I'm sorry. Let make it convenient but use only standard means, OK? WBR, Andriy. |
From: Stephan S. <gma...@sp...> - 2012-11-17 23:46:47
|
On 12-11-17 06:20 PM, Andrej N. Gritsenko wrote: >> ...not to mention allowing me to hide things like ~/espeak-data while I >> wait to see if devs are going to actually fix reported use-of-filesystem >> bugs. > > I would like to avoid such things very much. They may be changed by > GNOME people in any moment and if I want to follow any step of GNOME then > I would just use GNOME. Let follow standards (XDG specifications). If we > reimplement some bloated and dirty things we multiply the mess which they > made for own sake. The more we use Nautilus hacks the more we will behave > Nautilus-like, heavy and fat. I'm sorry. Let make it convenient but use > only standard means, OK? > Agreed. What I'm saying is that it'd be nice to see a new standard which provides a way to mark files and folder as hidden without renaming them and breaking things. (Essentially, a properly Unixy analogue to FAT's hidden attribute) |
From: Sergio <ser...@ya...> - 2012-11-18 10:48:18
|
I'll be honest here. I don't have much experience with template files but regardless of whatever convoluted hacks GNOME and KDE use for that, which libfm can support or not depending on the developer's wishes, pcmanfm should have a simple system just like Thunar. I place a file called 'Foo' in ~/Templates with content 'bar'. AFAICS pcmanfm should simply display 'Create New...'>'Foo', open a rename dialogue and create the new file with 'bar' contents. If libfm tries itself to discover the kind of file (like by extension) the drawbacks are: - impossible to have more than one different template with the same extension. - impossible to choose the most descriptive name for the user. - need specific hacks for the likes of .desktop, .directory etc. files to display their names (a .desktop file in XDG_TEMPLATES_DIR should not look for the 'Name' key). |
From: Sergio <ser...@ya...> - 2012-11-18 10:58:40
|
--- Em dom, 18/11/12, Sergio <ser...@ya...> escreveu: > De: Sergio <ser...@ya...> > Assunto: Re: [Pcmanfm-develop] Templates support in libfm. > Para: pcm...@li..., "Stephan Sokolow" <gma...@sp...> > Data: Domingo, 18 de Novembro de 2012, 8:48 > I'll be honest here. I don't have > much experience with template files but regardless of > whatever convoluted hacks GNOME and KDE use for that, which > libfm can support or not depending on the developer's > wishes, pcmanfm should have a simple system just like > Thunar. > > I place a file called 'Foo' in ~/Templates with content > 'bar'. AFAICS pcmanfm should simply display 'Create > New...'>'Foo', open a rename dialogue and create the new > file with 'bar' contents. > > If libfm tries itself to discover the kind of file (like by > extension) the drawbacks are: > - impossible to have more than one different template with > the same extension. > - impossible to choose the most descriptive name for the > user. > - need specific hacks for the likes of .desktop, .directory > etc. files to display their names (a .desktop file in > XDG_TEMPLATES_DIR should not look for the 'Name' key). > *In short*: keep it simple! Don't incur on the mistake of trying to know better than the user. I have no idea whatever hack is there to discover the templates (I have no knowledge to read the code) but display the name the user defined for the file regardless of the extension in the 'Create New...' context menu and if libfm can't recognize the file as any known 'template', display it all the same (don't hide anything). That's my modest opinion and I admit I know very little about the possibilities in this subject. |
From: PCMan <pcm...@gm...> - 2012-11-18 11:57:25
|
Here are some short comments regarding to the overall designs after code review. I'm not at home now and will test the code in 1 - 2 days after I get home. About API degisn: The programming interface looks good. It's simple enough for use in other programs and I like it. It'll be better if there is _get_name() which returns a const char* rather than duplicating the string. About the specs supported: I agree with others that it should be as simple as possible. The KDE way is too complicated and not intuitive. The pros of there way is applications can install template files with localized names. The cons of course is its complexity. However I'm not completely against the idea. The Gnome and Thunar ways are more friendly for the users to add customized templates. The KDE way, in the contrary, seems to be designed for applications to install built-in templates. They are good at different things so it's not bad to support both. For applications which requires more complicated stuff, there is another way to install popup menu items. They can use the DES-EMA spec to install popup menu actions. So even if we don't support the KDE way, applications can still install custom items to the popup menu. We just need to extend that DES-EMA support a little to enable creating items in "Create New" submenu. Since adding this does not create much overhead, it's OK to keep KDE support, though. For the gnome support, the menu items can simply show the file names assigned by the users. Many thanks to Andriy for the hard work. I'll compile the code and do some real tests as soon as possible. BTW, I noticed some significant slow down of startup of pcmanfm in Lubuntu 12.10. Maybe it's time to do some profiling again to see what's wrong. On Sun, Nov 18, 2012 at 6:58 PM, Sergio <ser...@ya...>wrote: > > > --- Em dom, 18/11/12, Sergio <ser...@ya...> escreveu: > > > De: Sergio <ser...@ya...> > > Assunto: Re: [Pcmanfm-develop] Templates support in libfm. > > Para: pcm...@li..., "Stephan Sokolow" < > gma...@sp...> > > Data: Domingo, 18 de Novembro de 2012, 8:48 > > I'll be honest here. I don't have > > much experience with template files but regardless of > > whatever convoluted hacks GNOME and KDE use for that, which > > libfm can support or not depending on the developer's > > wishes, pcmanfm should have a simple system just like > > Thunar. > > > > I place a file called 'Foo' in ~/Templates with content > > 'bar'. AFAICS pcmanfm should simply display 'Create > > New...'>'Foo', open a rename dialogue and create the new > > file with 'bar' contents. > > > > If libfm tries itself to discover the kind of file (like by > > extension) the drawbacks are: > > - impossible to have more than one different template with > > the same extension. > > - impossible to choose the most descriptive name for the > > user. > > - need specific hacks for the likes of .desktop, .directory > > etc. files to display their names (a .desktop file in > > XDG_TEMPLATES_DIR should not look for the 'Name' key). > > > > *In short*: keep it simple! > Don't incur on the mistake of trying to know better than the user. > I have no idea whatever hack is there to discover the templates (I have no > knowledge to read the code) but display the name the user defined for the > file regardless of the extension in the 'Create New...' context menu and if > libfm can't recognize the file as any known 'template', display it all the > same (don't hide anything). > > That's my modest opinion and I admit I know very little about the > possibilities in this subject. > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Pcmanfm-develop mailing list > Pcm...@li... > https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop > |
From: Andrej N. G. <an...@re...> - 2012-11-18 15:02:15
|
Hello! PCMan has written on Sunday, 18 November, at 19:57: >About API degisn: >The programming interface looks good. >It's simple enough for use in other programs and I like it. >It'll be better if there is _get_name() which returns a const char* rather >than duplicating the string. I decided to do duplicating instead of unlink the FmTemplate and insert another one into the list on rebuild. But counting number of rebuilds in comparison to duplicating it's not worth it. Thank you for pointing on that, I'll rewrite that part so _get_*() will be used instead. [.......] >Since adding this does not create much overhead, it's OK to keep KDE >support, though. >For the gnome support, the menu items can simply show the file names >assigned by the users. I see the difference now. As I already said, I'll add one more config statement to choose implemented way or simpler one, with default to the one described by you, as it seem to be more expected. Thank you all for the feedbacks, feedback is the thing I need the most to make it better! I'll inform you as soon I'll make required changes. With best regards. Andriy. |
From: Andrej N. G. <an...@re...> - 2012-11-19 01:34:04
|
Hello! I have written on Sunday, 18 November, at 17:02: >I'll inform you as soon I'll make required changes. I've implemented another mode. It is default one and may be switched to previous one with 'template_type_once' option in libfm.conf. Test it, please, and tell me if it works now as you expect it to behave. Thank you very much. With best regards. Andriy. |