On Tue, Jun 11, 2013 at 11:48 PM, Andrej N. Gritsenko
<[email protected]> wrote:
>     Hello there!
>
>     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. :)
>     Thank you in advance.
>     Andriy.

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.

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.

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.

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.

5. Moving menu items around does not work and DND items causes seg faults

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.

7. Editing application items with the file property dialog generates
empty *.desktop files in ~/.local/applications. The changes are not
properly saved.

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'll try to look into other bugs you send me previously first when I have time.

Cheers!

------------------------------------------------------------------------------
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

Reply via email to