pftp no longer alpha!

Download here:

http://os4depot.net/index.php?functio ... file=network/ftp/pftp.lha

0.1 (30-Jan-2008)
-----------------

- Its no longer alpha (dancing bananas...)
- Cool new about window.
- PFTP is now completely localised (.cd file
included)
- Added an Amiga version string.
- New toolbars at the top of the directory windows.
- Now properly searches the system search path
for ssh when run from WB (thanks to Fredrik
Wikstr?m for the report).
- You can now retry or delete transfers from the
aborted transfer list.
- Should now start up a bit faster when you start
it for the first time after a boot (its gone
from ~4 seconds to ~2 seconds here).
- PFTP now works a lot better in smaller modes like
640x480 and 800x600 provided you don't have huge
fonts i guess... (and i remember when 800x600
was huge
- There is now proper documentation.

@orgin

Yeah, about that... could you remove "Alpha preview version" from the description line? I didn't notice when I uploaded it. Edit: Thanks

BTW, the html documentaion is also available online here:
click me.

@xeron

I guess running it on a window on the workbench is on the ToDo list? Running it full screen in 1600*1200 isn't very comfortable...

@orgin

Its tricky because it doesn't have "one" window...

But i've never had any discomfort using it fullscreen.

@xeron

Reaction doesn't have any class for virtual groups? (sub windows or windows in windows)

@orgin

Well, not as such, or at least i don't think so. It has layout groups to group objects together, but PFTP isn't a fixed 2-pane client which makes it trickier.

Although I think you can dynamically add children to groups (and therefore add browsers to an existing window), i would either end up with a lot of switch statements in the gui code depending on which "mode" it is in, or two seperate gui modules t maintain in parallel, neither of which i'm keen on.

The official answer, i guess, is "we'll see".

I'm considering adding a docky so that you can keep an eye on your transfers from the workbench screen.

@orgin

Quote:

Ugh, that's very Windowsy and a feature I absolutely hate. That what screens are for: to group together related windows.

Having said that, I don't see why xeron can't just tell all the windows to open on the default public screen. It wouldn't be pretty and I'd much rather have it on it's own screen, but as a configuration option it should take about two minutes to add and provide some choice for people who do want to run it like that.

@xeron

This is a great little program, thanks!

Chris

@Chris

When I created PFTP I had two main goals. I didn't want to be restricted to the simple 2 pane paradigm, but at the same time I wanted t retain the ease of use that comes from it.

There is an OS3.x FTP client called mFTP-II which is also multithreaded and supports multiple windows. It opens its browser windows on workbench which you could freely move and size like DOpus listers. I found it clumsy and messy compared to the classic 2-pane FTP client because there is no intrinsic or implied "connection" between listers which allows 2-pane clients to have arrow buttons to send files to the nearby lister.

I solved this in PFTP by allowing multiple windows, but keeping them managed and tiled by PFTP. This maintains an implied link between adjacent windows and allows me to have "send-to" arrows in the top toolbar, while still allowing for things like drag and drop.

Of course managed windows don't lend themselves to being open on the workbench since people generally like to be able to move windows on the workbench around as they see fit, but of course the Amiga provides the perfect solution; screens!

@Chris

Well we all have a different taste. I don't like to run applications on different screens, I basically never run any application full screen. To me that's just annoying and cumbersome. For me, separate screens are better for games where you don't want to keep track of other applications or to simply have more than one work space.

Just for comparison, on my Ubuntu setup I have three workspaces, one for everyday use with file listers (local,samba,ftp), browser windows, icq, irc and email, the second for web development with relevant browser windows, shells, editors and its relevant file listers, and the third one for graphics editing and the occasional movie/tv-series player with its relevant file listers. Currently there's 13 windows on the first, 10 on the second and 6 on the third. Having each application on its own screen or certain applications requiring their own screen would be rather impractical to me.

(Try doing that on a normal windows setup. And the above is in no way extreme, on a good day I can easily have up to 30 windows on a single workspace)

When I use my A1 with OS4 I use it in a similar way with lots of applications and windows open on the workbench with amistart to keep track of the windows. I usually do several tasks at once and want to keep track of more than one window and application at the same time, having to use specific applications on their own screen just interrupts the individual activities I'm doing.

@Xeron

Great! Thanks

@xeron

Quote:

I didn't realise that as I've never had cause to try to move them. I can see how that could be a problem on the WB screen.

@orgin

I tend to use programs on screens when they need the space. My email/news clients always run on WB though. AWeb runs on it's own screen (as I can make it full screen). It annoys me on Windows that everything has to be on the same screen, so I don't run things full screen there unless I only have one app open. I like to keep a bit of variety but I agree that screens aren't very easy to monitor. Often I'll scrunch a window up and drag the screen down a bit if I need to view two screens at the same time, but it doesn't happen very often.

@Chris

Quote:

Thats why i'm thinking of adding a docky, so that you can always see what pftp is up to and only go to its screen if you need to do something new, which is in my mind the best of both worlds.

@xeron

Great idea for docky ...waiting for this ;) abd thx on this beta version!!

Well, I'm with Orgin on this; I almost never open separate screens, and have tons of windows open on WB, using the DepthMenu to find my way around them if necessary. And this is one of the two things that is currently keeping me from using PFTP as my main FTP client. You *really* should add the possibility to open the windows on WB. If I want them there, I want them there regardless of whether they are "managed", that will be behaviour I can live with (or even find useful) on WB as well as on a separate screen.

(The other thing? I want to be able to save the local directory for each connection, e.g. I always download files from site x in a specific path, and from site y in a different one. ATC does it.)

Best regards,

Niels

@nbache

Thats tricky also, since local browsers aren't necessarily associated with remote browsers. I think i might have a way around that, though.

@xeron

I like the fullscreen idea. very good job!

But my favorite ftp client is CyberDuck on OS X, it is drag and drop based, simple and intuitive.

I'm working on a french catalog for PFTP...

@xeron

Quote:
If I understand you correctly, the problem is not to add a field for an optional local path specification in the FTP servers window (and the file where the server details are saved), but rather to know when to set a local browser to a specific local path based on which remote site is being loaded in another (conceptually totally unrelated) browser. Right?

Well, how about waiting until the moment where a relation between a remote and a local browser is actually established, either by drag and drop, or by putting them next to each other, so the arrow comes up (or would come up if the local browser was displaying a real path and not the default volume listing). Then, if a local path was defined in that remote server's details, either automatically load that directory in the local browser before starting the transfer, or prompt the user for whether to change to the predefined local directory or stay in the one already loaded. The choice between those two behaviours should of course also be an option selectable in the FTP server definition.

Best regards,

Niels

@nbache

What I was going to do, was this:

When a remote browser with a local path set is opened, it checks if there is a local browser to the left of it. If there is, and it is currently just listing volumes, it changes the directory of it to the set local directory. This covers the case where you run PFTP and connect to a server.

I will also include a checkbox in the server window to open a local browser next to the remote browser you're about to open, if there isn't one already there.

BTW, the next release of Pete's FTP will support AmiUpdate, but since the current one doesn't, AmiUpdate won't know you've got it installed and update it for you.

If you use AmiUpdate and want it to notice when 0.2 is released, make a file called "ENVARC:AppPaths/PetesFTP" containing the full path of the drawer that contains the pftp executable.