Hello!
PCMan has written on Saturday, 15 June, at 6:46:
>On Tue, Jun 11, 2013 at 11:48 PM, Andrej N. Gritsenko
><[email protected]> wrote:
>> I basicly done with $subj. It is in GIT, in branch 'vfs-menu-fileops'
>> and I would ask everyone who is willing to test it, to give all possible
>> feedback, suggestions, questions, bugreports. You don't have even install
>> it and compile pcmanfm with it - running libfm-demo is pretty enough for
>> the testing (configure --enable-demo .....). What is possible now:
>> - create application in any menu folder;
>> - remove application from menu;
>> - move application from one folder to another;
>> - change anything for application (name, icon, etc.);
>> - create new folder in menu;
>> - remove any folder from menu.
>> Though it is possible to create a folder in menu, it is not possible to
>> see it just because empty folders are hidden there. It will be possible
>> after I release libmenu-cache-0.5.0 (the code is in GIT for some time
>> already) and add the code into libfm to ask the libmenu-cache to include
>> hidden directories into the cache. Therefore the most probably I will
>> conditionally disable that if it isn't compiled with new libmenu-cache,
>> so users will be not confused with "not working" folder adding. Sure, you
>> can create new item (or change existing one) with appropriate Category
>> that it come into that new folder, then the folder will become visible,
>> but that require some editing with text editor and none of generic users
>> would do that usually.
>> The possibilities to change name or icon for menu folders are not
>> implemented yet, just because "Properties" dialog in folder view doesn't
>> support such changes for folders. It will be implemented later.
>> So I'm waiting your feedback. Do it, please. :)
>Here is some feedback.
>1. The order of libs listed in Makefile.am is wrong, so it cannot be
>linked correctly upon installation. I just pushed a fix for it.
Thank you very much!
>2. I don't think that libfm-extra is needed. Given the small size of
>the xml parser, making it an additional lib actually adds additional
>overhead. The needs for a symbol export table, runtime symbol
>resolution and linking, and generating less-optimized PIC code all
>contribute the unnecessary overhead which outweigh the benefit of
>moving that tiny piece of code out of libfm core. Having it build-into
>libfm core may be actually cheaper. I'd suggest that we should
>decrease the numbers of libs instead and put fmxml code inside libfm.
>If you want to do something totally irrelevant to file management and
>the size of the code significantly affect the total size of libfm,
>then the real question is, should this be part of the project?
>Nautilus did not become so huge in one day. Otherwise if the code is
>small, it better to make it part of libfm rather than having an
>additional lib.
The main reason to have it in small additional library is the fact I
want to use the XML parser in menu-cache-gen program from libmenu-cache
package, as we discussed earlier. And since the libfm is already linked
against libmenu-cache, linking menu-cache-gen against libfm will create a
cyclic dependency. Therefore another available option (beside of creating
a libfm-extra) is just copy-paste the code into menu-cache-gen. I prefer
to make a small library instead and think that little overhead is not too
big price. Is this acceptable reason for you to create the libfm-extra?
>3. Creating new dirs partially works. The generated xml menu file is
>correct, but the desktop directory file is not. That *.directory file
>should not be empty. Besides, the newly created dir is not visible to
>the user, making it unusable.
I've added some starting contents for the file so it will be not
empty anymore. Thank you very much.
The newly created dir will be visible to the user a bit later, it
will be shown as hidden one (i.e. with 'show_hidden' enabled it will be
visible) but that will be possible with libmenu-cache >= 0.5 only. It's
why I think that creation should be conditionally disabled for < 0.5.
>4. I'd recommend using FILE* or g_file_set_contents, the old school
>ways for file I/O rather than using GInputStream everywhere inside the
>menu code. We don't really need to overhead of the cancellable streams
>for reading/writing a simple desktop entry file. Old unix way for file
>I/O is enough here.
Unfortunately it is not so simple because we don't operate on real
file path and we should not reveal "real file" paths to application
there: just keep in mind we have no exact "real file" and therefore we
operate with GFile path "menu://applications/blah/blah.desktop". And the
application trying to open the file would get either GFileInputStream or
GFileOutputStream (depending whether application wants to open or write
the file), i.e. application can work with menu items via GFile*Stream
APIs only. And working with virtual stream but operating with real file
will just do near the same thing that GVFS does and implementing that
will reimplement some parts of GVFS code. It may be simpler a bit but
counting the fact it will take memory for duplicating code and that code
will be used rarely enough, I believe it just doesn't worth the efforts.
>5. Moving menu items around does not work and DND items causes seg faults
Thank you very much. I've found where it was crashed and fixed it.
>6. Deleting menu items do not work as expected. There are no menu
>items for it in the popup menu and deleting items with "<Del>" key
>causes gio moving it to trash:///, which does not work.
Yes, context menu is next thing I will rework so that issue will be
fixed later. It should work with "Del" key though and yes, it warns the
item cannot be moved into trash can so it will be deleted instead, the
same way as it is done with another file systems that doesn't support
trashing. May be we should skip that warning window for menu items? That
will make the behavior inconsistent though. :)
>7. Editing application items with the file property dialog generates
>empty *.desktop files in ~/.local/applications. The changes are not
>properly saved.
Could you help me to reproduce the issue? Are you sure it wasn't
another crash? I've tried to edit two existing menu items (by Properties
dialog) and one newly created too few moments ago and in all cases that
was ended with new copies of properly updated original items. I have no
idea what might happen in your case. :(
>Here are the problems I found so far.
>The xml parser bascially works as expected and the genreated xml menu
>file seems to be correct. Nice work! Well done!
>Unfortunately, menu editing does not work yet and still requires much work.
>I haven't got enough time to dig into the causes of the preceding
>problems and I'll leave this to you instead.
I believe I can handle them with a bit of your help. Thank you for
all your testing!
Cheers!
Andriy.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Pcmanfm-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
