Opened 18 years ago

Last modified 17 years ago

#1457 closed Patch

(fzs+fzsi) gui enhancement

Reported by: tropics Owned by: Tim Kosse
Priority: normal Component: Other
Keywords: Cc: tropics, Tim Kosse
Component version: Operating system type:
Operating system version:


this patch adds:

  • name of the file/directory currently transferred, display

as local filename or as ftp name

  • transfer speed per connection
  • transfer progress in %
  • sort user display by ip or account
  • group display for windows xp
  • the pane layout can be switched horizontal/vertical
  • pane layout setting, pane splitter position, filename

display setting and user sorting settings are saved to the
options file

tested under windows 98, 2000 and xp.

Attachments (3)

patch6.diff (71.3 KB ) - added by tropics 18 years ago.
patch v1
transfer_modes.bmp (758 bytes ) - added by tropics 18 years ago.
new file in source\Interface\res
transfer_toolbar.bmp (718 bytes ) - added by tropics 18 years ago.
new file in source\Interface\res

Download all attachments as: .zip

Change History (17)

by tropics, 18 years ago

Attachment: patch6.diff added

patch v1

by tropics, 18 years ago

Attachment: transfer_modes.bmp added

new file in source\Interface\res

by tropics, 18 years ago

Attachment: transfer_toolbar.bmp added

new file in source\Interface\res

comment:1 by Tim Kosse, 18 years ago

Thanks, merging this will take some time.

comment:2 by tropics, 18 years ago

of course.
the patch also adds WINVER=0x410 to the compiler settings,
which defines the minimum operating system as windows 98. i
didn't try 95, if you want to, set WINVER=0x400.

comment:3 by Tim Kosse, 18 years ago

Completed Step 1: Applied changes to CPermissions

comment:4 by Tim Kosse, 18 years ago

Group display, isn't that this useless feature form Windows
explorer which just wastes space? IIRC a group header did
occupy almost three entire lines. If yes, then sorry, but I
won't implement that.

comment:5 by Tim Kosse, 18 years ago

About reverse hostname resolving: Depending on the network
configuration this may take up to several minutes. During
this time the interface will be totally blocked and under
heavy load, the protocol buffers will fill and eventually
the interface will timeout.
So unfortutately it won't be possible to implemented that
either in its current form.

comment:6 by tropics, 18 years ago

about the group display: it is implemented as optional, meaning
you can turn it on and off and the setting is stored in the
options file. it currently defaults to 'on' on windows xp, but we
can change it to 'off' so you will never have to see it.

hostname resolving: we can add an option which defaults to
'off' if you like.

comment:7 by tropics, 18 years ago

proposed solution:

  • remove line 178 in UsersListCtrl.cpp to change the default

group view setting to 'off'

  • remove lines 200-220 and replace them with

return -1;
to disable hostname resolving. i would fill in an asynchronous
hostname resolver in a later patch.

let me know if you want a new diff file.

comment:8 by Tim Kosse, 18 years ago

Btw, the reverse hostname lookup has to be done by the
service. Since server and interface can run on different
machines, the hostname may be different on both machines.
So in order to use the hostname based filters, the correct
hostnames have to be used, and those are the ones from the

comment:9 by Tim Kosse, 18 years ago

Applied part 2: Display transfer information

comment:10 by Tim Kosse, 17 years ago

I'm now merging in the progress and speed information
handling. I had to change your code a lot, since it wastes
huge amounts of bandwidth: Full t_connectiondata for each
connection each second. But despite the userid, only one
piece of information really has to be transferred: The
current file offset.

Though I'm not really happy with it, as in the worst case
transferspeed updating speed is in O(n*n) (n = number of
connected users) (Update all users and each time scan the
users list sequentially.)

I think I'll modify the users list to be a virtual list,
this should improve performance to be at least in
O(n*log(n)) if storing elements in std::map.
I'm not sure about the performance of std::hash_map, but if
it's using good hashes (O(1)), transferspeed updating
performance might increase to O(n)

Anyhow, this is much work and I'll have to modify large
parts of FZS, but following security, performance is most

comment:11 by anonymous, 17 years ago

Logged In: NO

yes i know the solution was far from perfect, but i didn't
expect you wanted to rewrite the patch. i thought you would
tell me what was bad about it and i would improve it then.

this was more a first solution to get the things going i wanted
to see in the server. i also thought that sending all that
information from the server to the interface would not be such
a good idea but it worked surprisingly well. on the other hand, i
have never more than 5 users with 10 connections (or so) on
my server. sending only the user id and the ints for speed and
progress would definately be an improvement.

another solution would be to send only one update per second
for all users. that would be only one big message containing all
the user ids that transfer something currently and the details
of their transfers. the performance of the gui update would
also be O(n) in that case, assuming that the user ids in the
message are sorted ascending (which would be trivial i guess).

comment:12 by Tim Kosse, 17 years ago

another solution would be to send only one update per second
for all users. that would be only one big message containing

That's exactly what I'm implementing now.

comment:13 by Tim Kosse, 17 years ago

Thx again for the patch, I've applied the useful parts of
this patch.

What I did not apply is the following:

  • XP group display
  • Layout switching. Since especially the filename column is

quite long, the only layout which makes sense is the
horizontal split one, which is now the default.

  • Hostname resolving
  • pane splitter position: This did not work, each restart

pane size did change a few pixels.

comment:14 by tropics, 17 years ago

great. i will try to make seperate patches for the other stuff,
improving it so you don't have that much work with them.

Note: See TracTickets for help on using tickets.