Update VFS and new filemanager

Ralf_Becker_6 2008-03-03 23:11:36 UTC #1

I worked the last days on the new filemanger GUI, which is mostly
inspired by KDE konqueror.

A first version is now available in trunk. The new UI starts by default,
the old UI is still available via the sidebox menu.

Here are some screenshots:

http://www.outdoor-training.de/ralf/filemanager.index.png
http://www.outdoor-training.de/ralf/filemanager.file.general.png
http://www.outdoor-training.de/ralf/filemanager.file.perms.png
http://www.outdoor-training.de/ralf/filemanager.file.preview.png

Some characteristics:

List contains files of one directory or additionally of all
subdirectories too
Selection of multiple files with actions in selectbox below
Buttons to navigate one level up, to the user’s home dir or a free
typable address
Button and prompt to create new dirs
Copying and moving of files to other directories is done via a clipboard.
Popup with prefs of a single file or dir including a preview (for
images and text-files for now)

I switched the default mount of the vfs to the old vfs again, to allows
an easy testing of the new interface. Please note: You can not change
permissions with the old vfs! You can use the filemanager cli to mount
the new sqlfs instead, if you want to test with it.

I have not yet added a tree. It’s planned for a faster navigation and
moving of files.

Ralf

Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Pongracz_Istvan-2 2008-03-04 09:16:27 UTC #2

Hi Ralf,

I would like to share some of my thoughts.
First I have to tell you, I did not test the latest trunk, but I plan
it.

Upload/download really big files would be nice (800MB)
Continue an interrupted file transfer also would be nice (this is
related to the previous line)
An option for counting the downloads (for example when I use it to
share contents to the public, but I need a counter to know, how popular
a file)

Thank you for your effort and happy coding :),
István

–
BSA. Mert megérdemlitek.
Open Source. Mert megérdemlem.

BSA. They value it.
Open Source. The value. It.

http://www.osbusiness.hu

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Ralf_Becker_6 2008-03-04 17:46:14 UTC #3

Hi István,

Pongracz Istvan schrieb:

Hi Ralf,

I would like to share some of my thoughts.
First I have to tell you, I did not test the latest trunk, but I plan
it.

Upload/download really big files would be nice (800MB)

The upload is no longer limited by the memory_limit setting in php.ini.
But you still have to set both max_upload_size and post_max_size to a
value of your greatest upload. It’s not like in FMail or the old
filemanager where you need a memory_limit of a multiple times the file size.

Continue an interrupted file transfer also would be nice (this is
related to the previous line)

I’m not aware you can do that with an apache/php upload.

An option for counting the downloads (for example when I use it to
share contents to the public, but I need a counter to know, how popular
a file)

That’s something we can add …

Thank you for your effort and happy coding :),

Thanks

Ralf

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Hans-Jurgen_Tappe 2008-03-05 08:37:12 UTC #4

Hi Ralf!

Ralf Becker wrote:

Upload/download really big files would be nice (800MB)
The upload is no longer limited by the memory_limit setting in php.ini.
But you still have to set both max_upload_size and post_max_size to a
value of your greatest upload. It’s not like in FMail or the old
filemanager where you need a memory_limit of a multiple times the file size.

According this “problem”: Have you been able to implement some
consistency check if the upload fails? The old filemanager felt OK,
saving a file of 0 Byte without feedback that something might have gone
wrong…
Maybe, a warning could show up indicating e.g.:
“Warning: Uploaded file size is zero byte. Note that the upload is
limited to [MIN(max_upload_size, post_max_size)]. Contact the system
administrator rto adapt these limits or split / zip your file before
upload.”

Would be very helpful in order to prevent from unrecognized data loss.
Else, I’d not dare to give access to the application to standard users.

Thanks,
Hans-Jürgen

P.S.: See also Feature Request Filemanager / 1351.

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Pongracz_Istvan-2 2008-03-05 08:58:35 UTC #5

1. 5, szerda keltezéssel 09.37-kor Hans-Juergen Tappe ezt írta:

Hi Ralf!

Ralf Becker wrote:

Upload/download really big files would be nice (800MB)
The upload is no longer limited by the memory_limit setting in php.ini.
But you still have to set both max_upload_size and post_max_size to a
value of your greatest upload. It’s not like in FMail or the old
filemanager where you need a memory_limit of a multiple times the file size.

According this “problem”: Have you been able to implement some
consistency check if the upload fails? The old filemanager felt OK,
saving a file of 0 Byte without feedback that something might have gone
wrong…
Maybe, a warning could show up indicating e.g.:
“Warning: Uploaded file size is zero byte. Note that the upload is
limited to [MIN(max_upload_size, post_max_size)]. Contact the system
administrator rto adapt these limits or split / zip your file before
upload.”

Would be very helpful in order to prevent from unrecognized data loss.
Else, I’d not dare to give access to the application to standard users.

And I am thinking about how to make a workaround of this kind of
situation: resume download/upload process.

Is there any possibility to use a java based transfer?
I guess, technically there are two sides of this problem:

one on the client side
how to read a part of a file and send to the server
server side
how to receive a part and append the next chunk to the file

And how to synchronise between them.

I’m just thinking loudly.

Cheers,
István

–
BSA. Mert megérdemlitek.
Open Source. Mert megérdemlem.

BSA. They value it.
Open Source. The value. It.

http://www.osbusiness.hu

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

Ralf_Becker_6 2008-03-05 13:00:12 UTC #6

Hi Hans-Juergen,

Hans-Juergen Tappe schrieb:

Hi Ralf!

Ralf Becker wrote:

Upload/download really big files would be nice (800MB)
The upload is no longer limited by the memory_limit setting in php.ini.
But you still have to set both max_upload_size and post_max_size to a
value of your greatest upload. It’s not like in FMail or the old
filemanager where you need a memory_limit of a multiple times the file size.

According this “problem”: Have you been able to implement some
consistency check if the upload fails? The old filemanager felt OK,
saving a file of 0 Byte without feedback that something might have gone
wrong…
Maybe, a warning could show up indicating e.g.:
“Warning: Uploaded file size is zero byte. Note that the upload is
limited to [MIN(max_upload_size, post_max_size)]. Contact the system
administrator rto adapt these limits or split / zip your file before
upload.”

Yeap, we dont create a 0Byte file, but give an error message …

Ralf

Would be very helpful in order to prevent from unrecognized data loss.
Else, I’d not dare to give access to the application to standard users.

Thanks,
Hans-Jürgen

P.S.: See also Feature Request Filemanager / 1351.

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers

–
Ralf Becker
eGroupWare Training & Support ==> http://www.egroupware-support.de
Outdoor Unlimited Training GmbH [www.outdoor-training.de]
Handelsregister HRB Kaiserslautern 3587
Geschäftsführer Birgit und Ralf Becker
Leibnizstr. 17, 67663 Kaiserslautern, Germany
Telefon +49 (0)631 31657-0

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft® Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

eGroupWare-developers mailing list
eGroupWare-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-developers