How to replace the standard Filer

Hello,

Is there a way to replace standard Filer by custom app? I would like that my app be opened by click on Taskbar file systems icons.
I naively tried to change the “Filer$Path” to point on my app but it does not work.
Other idea is to intercept somehow the “Service_StartFiler” but don’t know how..
Is it even possible to replace the standard Filer?

Thanks.

Do I understand correctly that you want to open your app by clicking on, say, the harddisk icon? Even if that were possible, how would you open the root directory then?

You could mimic a filer icon, by creating one for your app and put it at the left side of the icon bar by setting the appropriate flag in R0 in Wimp_CreateIcon. But I would never replace the original filer, even if I were able to. For me, the RISC OS filer is one of the biggest selling points of the system.

Is there a way to replace standard Filer by custom app?

Filer is a module, not an app.
You can rewrite the source, compile a new Filer module and load that during startup.

Note that a replacement Filer module needs to implement the same interfaces as the current Filer module, such as issuing Service_StartFiler, responding to Filer_OpenDir etc. Best to study the current source! But it can be done – I would suggest loading it in PreDesk after RMKill Filer.

You can use a Wimp filter to intercept clicks on filer icons. I wrote some modules that intercepted right clicks in order to eject removable media such as CDs and ZIP discs.

Do I understand correctly that you want to open your app by clicking on, say, the harddisk icon? Even if that were possible, how would you open the root directory then?

Isn’t Sergey involved somehow with CLFiler?

I think the “proper” way to do this is to alias *Filer_OpenDir to your own command, which opens your filer instead of the standard one. This will work for some filers, but others appear to call *%Filer_OpenDir to block such shenanigans.

I naively tried to change the “Filer$Path” to point on my app but it does not work.

I’m not that surprised…

Other idea is to intercept somehow the “Service_StartFiler” but don’t know how.

I’m not sure that’s what you want, either. That’s concerned with starting the iconbar resident bits of each Filer (ie. the bits that you want to replace), isn’t it?

Is it even possible to replace the standard Filer?

I don’t know. For me, aliasing *Filer_OpenDir is the way to do it, but it seems that some of the Filer authors blocked this. I don’t know what the official position is on why those blocks are there, but you could always try submitting patches to remove the %s from the commands, with reasoning.

A quick straw poll of icons on a Titanium iconbar suggests that OS filers call *%Filer_OpenDir while third-party ones call *Filer_OpenDir. That’s not exhaustive, however.

Filer is a module, not an app.

Yes, but the bit that the user sees is a module application which could easily be replaced by a standard user-space application.

It would help if Sergey were less cryptic in many of his questions, but I strongly suspect that this boils down to “I would like clicks on disc icons on the iconbar to open a CLFiler window instead of the standard Filer window”.

You can rewrite the source, compile a new Filer module and load that during startup.

Probably not the correct approach here. I would assume that the intent would be for both front-ends to remain available, but for the user to be able to choose for one or the other to be the “default” one.

I had a look with MsgMon; when the Filer gets a *Filer_OpenDir it broadcasts it back out as a Message_FilerOpenDirAt. Some filers, like clicking on Apps or RAM disc, send a Message_FilerOpenDir directly to the Filer task, with no broadcasting.

Thanks to all!

I will try to alias *Filer_OpenDir and check what happens.
@Steve Fryatt yes, I’m programming the CLFiler and main task not to replace whole Filer module but just open CLFiler by click on disc icons.

But – as Julie points out – unless you replace the Filer module, you won’t get to handle all directory open request messages. And unless you stop the current filing system filers from issuing %Filer_OpenDir, you won’t handle those either.

But – as Julie points out – unless you replace the Filer module, you won’t get to handle all directory open request messages

Yup, as I pointed out quite a while back, it is documented that the underlying filesystem records the filer’s task handle to send messages only to it (in other words, they aren’t normally broadcast – those that do are just being lazy).

So, really, the only way to replace the filer is to replace the filer, however…

Probably not the correct approach here.

…you would have to be certain that a replacement can do all of the things the existing filer can do. It’s a fundamental part of the user interface and the look’n’feel of RISC OS so…

So, really, the only way to replace the filer is to replace the filer

Which was the logic of suggesting loading the replacement during startup

you would have to be certain that a replacement can do all of the things the existing filer can do

Which was the logic of suggesting rewriting the existing source.
Of course, while producing a whole rewrite of the Filer, mapping out the expected behaviour and producing C source for that might be a good idea.

What would perhaps make sense – though I’m not sure if the CLFiler guys feel like the challenge…

…is to rewrite the filer, as it is, as a tight little C application for replacing the current filer.
It can contain a few lines of code that if CLFiler is present, hand the request on to it, otherwise open the traditional filer window.

In that way, we get an updated (readable) filer source and they get the hooks necessary to permit easy integration of CLFiler (or any third party filer, though I don’t imagine a rush of people making such things ;) ).

@Rick
To replace the Filer 100% we first need to be sure that all works 100%. Otherwise we will be in trouble.
And at the moment I wouldn’t say that CLFiler is perfect but very helpful.

I had never heard of CLFiler before so I googled it and had a look, it seems pretty nifty.
If they had paypal I would have bought it but their barrier to payment exceeded my impulse purchases motivation.

If they had paypal I would have bought it but their barrier to payment exceeded my impulse purchases motivation.

CLFiler did generate an impulse and being determined not to be beaten by the ‘computer’ I went for it.

The payment method is an IBAN job and as far as I can see required doing on the bank’s website and not its mobile app. Once Germany was set as the destination the required IBAN fields appeared. One little catch is that the IBAN number needed the spaces in the confirmation email removing. The Apple Watch has just confirmed the transfer, which may take 24 hours to complete.

IBAN stands for International Bank Account Number.

In case you don’t know CLFiler can be purchased via PlingStore.

In case you don’t know CLFiler can be purchased via PlingStore.

No, missed that, and I must admit to swearing a bit. OTOH I appear to have saved £1.92.

@Alan
Yes sorry for the incovenience about sending money. Paypal is no longer available. Need to look for another payment service. But you could use www.wise.com to send to our bank also.

@David
Thanks for the order. Did you get my email with latest version as no reply from you? Next update will come during the next days.

@David
Thanks for the order. Did you get my email with latest version as no reply from you?

I have now replied.

CLFiler offers interesting added capabilities to Filer operations. For instance, it can be a better than Thump thumbnailer.