Filer for AmigaOS4?

It's been a while we haven't heard about Filer.

Does anyone know if it's stopped, cancelled, postponed???

@Balis

I've been taking care of some family stuff for a while. Filer definitely isn't canceled, I've just had to focus on other stuff for some time.

Development will start up again in a while.

Is there something that makes it unusable now that you want me to look at first when I start up again?

@orgin
My personal wishes:

* Look at eliminating recursion when doing Find operations, because I previously reported crashes that looked like stack issues. I've only used Workbench's Find since.

* Selected files should be remembered when you change the sorting of the lister. Very annoying to loose stuff, and actually prevents me from doing some things.

* It would be nice to be able to hide certain files based upon a pattern. For example, PortablE creates several .pem files for each .e source code file, and this makes looking through my source code files difficult.

* The pop-up Help bubbles does not work for User Buttons.

* The H & P protection bit are not shown in the lister.

* If we can't have the order of the columns freely changed, it would be very nice to have the option for the Size column to come before the Name column.

* As I think you already know, sometimes double-clicking on a Workbench desktop icon causes FilerCX to wrongly open a new Filer.

I haven't been able to figure out how to use the "Set Destination" button in combination with for instance the Copy button. It always gives me remarks but doesn't do anything.

I wonder if it is actually working.


I would still like to see dual listers because that works more intuitive and easier. If this thing will end up in OS 4.1 it would be nice to have that support.

ClassAction is still my favourite because of the dual listers.

@PulsatingQuasar

There's two sets of copy buttons. One that works with the src/dst paradigm (copy to/move to) and the other as a copy/paste paradigm (copy/cut/paste).

- src/dst requires at least two windows. A destination window and one or more source windows. copy to/move to then does it's operation from the active source window to the selected destination window.

- copy/paste only requires one window and simply works like .. err .. copy/paste. Works between different windows as well of course.

Both paradigms works flawlessly, provided that you know how to use them ;) The src/dst one is somewhat different from the diropus magellan one and I suppose it could cause some confusion if your're used to Magellan.

The text on the src/dst button can be reversed as well, some people seem to prefer a button that says what happens when you click on it others seems to prefer a button that says what state the window is in.


Dual list mode still won't be implemented. If you want a dual list file manager (Filer isn't one .. obviously) then you're better off using such a file manager. One of the main points of the filer is to actually get away from a dual list file managers. Diropus and Classaction are excellent dual list file managers.

@ChrisH

"* Look at eliminating recursion when doing Find operations, because I previously reported crashes that looked like stack issues. I've only used Workbench's Find since."

There's a stack cookie in the next version that should resolve this. Hopefully the next OS release will have dynamic stack not just implemented but also actually activated.

"* Selected files should be remembered when you change the sorting of the lister. Very annoying to loose stuff, and actually prevents me from doing some things."

Should be easy to change.

"* It would be nice to be able to hide certain files based upon a pattern. For example, PortablE creates several .pem files for each .e source code file, and this makes looking through my source code files difficult."

Doable.

"* The pop-up Help bubbles does not work for User Buttons."

Not meant to work. I've spent quite a few hours on this issue, unfortunately 'reaction' has a really stupid way of defining popup texts. You can't specify a text and then assign it to a gadget, you have to have a flat continuous array of all popup texts and then assign the index number of a text to the gadget you want to display it from. Having a GUI with several dynamic areas makes it somewhat painful to keep the array and the GUI together. Hopefully the next OS update will let you throw the array in a bin (where it belongs) and simply assign a STRPTR to a gadget with the popup text. If not then I'll have to do the more complicated dynamic array version, currently the work/gain factor doesn't tip things in favor of using the current popup definition system.

"* The H & P protection bit are not shown in the lister."

Easy to add. Might add a few selectable options for which flags to show.

"* If we can't have the order of the columns freely changed, it would be very nice to have the option for the Size column to come before the Name column."

I'll look at making the listbrowser view more dynamic after a first final release is made and I can start working on the next generation of the lister. The listbrowser class doesn't have any type of named column indexing so I'd have to glue that on top of it, but there's other issues that need attention before I'd consider working on something like that.

"* As I think you already know, sometimes double-clicking on a Workbench desktop icon causes FilerCX to wrongly open a new Filer."

Unfortunately I don't have access to the input device source code so I can't see what could cause it to not send the input events properly. I suppose I could write a setpatch for it. I wonder how much time it would take to rewrite input.device .. or perhaps I should focus on other issues ;)

The source code for the launcher is available here if anyone wants to check it out.

@orgin

OK. I'll try again when I'm back home this weekend.

@orgin Quote:
A stack-cookie is an improvement, but still not a solution for *deep* recursion (and I have deep folders!).

Recursion is NOT required for scanning folders & sub-folders. Instead you have a special list, on to which you add folders found in the current directory scan. At the end of scanning the current directory, you pick the next directory off that special list. You keep looping until the list is empty - no recursion required!

Also, Rogue has previously said that they were mistaken in thinking they could implement a dynamic stack for AmigaOS, therefore I do not believe we will ever see it (without tasks having their own address space).

@ChrisH

I honestly hope you don't believe that you just wrote anything I didn't know already ;)

Quote:

Hmm that would be bad, an OS where you have to specify stack size is .. well, a joke.

@orgin Quote:
I would hope not, however you didn't actually deny you were using recursion for such scans...

Quote:
...a price we pay for having a single address space (which also has other advantages & disadvantages). To be honest, it doesn't seem like a big problem - we manage pretty well fixed stacks.

@Origin
Only what i miss now it's drag&drop :) Becouse as you say, you do not want to add options for the second lister (it can be just like options, old-classic mode (dual lister), or new one (as it now) ), so, becouse of it, for me will be logical to have running 2 listers, and i just will do copy beetwen by drag&drop :) At moment i use filler for everythink , but not for copy :( Dunno, maybe i have strange logica, but for me these dest/src/etc copy stuff looks a bit annoing at moment :(

@orgin

Two minor issue I've been noticing:

1.
When you try to copy over a write protected file you get the option to "Force", but if you copy *from* a read protected one, you get no such option. Creates isues whn moving large directory structures arround....

2.
Whe copying as over an existing file the error requester says

The file "oldfilename" exists in the destination folder. This is confusing if it isn't present under the old name and possibly even more so of it is, as the reason for renaming them is probably to avoid overwriting it in the first place...

In terms of features the two I like most at the moment are more options for processing the search results, currently you can 'only' view them, options to edit etc would be very useful.

And secondly to be able to use the search results as a filetr in the current directory.

@ChrisH

Quote:

I'm not sure but didn't MOS already got (automatic) stack enlargment ? I'm not sure automatic is good however at least we should get back StackSwap() which enable programmer to manually enlarge the stack when needed... (I didn't check recently but IIRC when new memory system was introduced we were told not to use this function anymore)

@abalaban

Quote:

See NewStackRun function of exec.library. The old StackSwap can only be used reliably from assembler. Using it from C code is not recommended. NewStackRun OTOH has no such problems.

@Origin

I'm finding myself repeatedly going to certain directories, and having to click alot, what about saving project icons, that will open a filer (or even filers) at a given directory...

Hi @broadblues

I'm finding myself repeatedly going to certain directories...
How about putting a copy of Filer in your wherever dir. and use the WB Menu - LeaveOut option? Just saying...

@Snuffy
It would also help if he set-up ContextMenus to offer opening folders with Filer. Then you can right-click on a left-out folder, and choose "Open in Filer".

@Snuffy

Not really sure what your are suggesting there, but if you mean keep a copy of Filer in the drawer I want to list often, I don't think that will work.

@CrisH
Yes that is an option, but I'm not a big fan of contextmenus, and I want to avoid to many leftout drawers, if you have a drawer left out, it doesn't appear in it's workbenchparent directory, which gets a bit confusing if you need to havigate through the workbench for some reason.


What I have done is create a one line script like so

<pre>
sys:utilities/Filer/Filer "Projects:blender-svn/blender/source"
</pre>

Named it simply "blendersrc" put it in a dir named work:temp/filershortcuts

Then added a tool icon to that, starting from Shell. I can leave that out on the workbench. It would be nicer to have a project icon with Filer as the default tool and the path as a tooltype, preferably created directly by filer itself.


In the old DOpus5 days on my a1200 I used to have a bar of buttons along the top of the DOpus5 screen (I always used as a companion to workbench never a replacement) with shortcuts to my current projects. To able to replicate this in a non fiddly way is what I'm looking for.

@Orgin

Ah, tried it now. So that is how the Source Destination button works. That works pretty good.

Might I make a suggestion that would make people understand how it works without to have to read a manual?

Instead of giving the error message "There is no destination path selected" add a line to the requester which says something like "Open a second instance of Filer and set the Source/Destination button".