Author Topic: FARR plugin: Akete (Read 71165 times)

ewemoa · « **Reply #25 on:** January 15, 2009, 10:47 PM »

I'm thinking of providing a way of handling files with no file extension.

My current candidate for doing this is via the user variable Options.NoExtension. Possible associated values should be the same as for a file extension.

phitsc · « **Reply #26 on:** January 16, 2009, 02:24 AM »

I think I'll go with a default of "with" as the prefix, provide a way to change the prefix, and leverage any existing file extension association configuration so that it may be used with a keyword (e.g. if you have an association defined for 'html', then the plugin should recognize the keyword 'withhtml').
-ewemoa (January 15, 2009, 08:38 AM)

sounds good to me.

ewemoa · « **Reply #27 on:** January 16, 2009, 05:44 AM »

Thanks for the feedback -- I really appreciate it

ewemoa · « **Reply #28 on:** January 21, 2009, 01:11 AM »

I've put together a new experimental version -- the first post of this thread should contain an updated download link as well as the associated README.txt in the spoiler section.

I think I have made initial attempts at all of the features discussed in this thread.

If you give it a try, I'd appreciate knowing how it works (or doesn't

) for you.

phitsc · « **Reply #29 on:** January 21, 2009, 02:23 AM »

I'm afraid it's a 'doesn't' for me. See attached screen shot.

FARR plugin: Akete

ewemoa · « **Reply #30 on:** January 21, 2009, 03:07 AM »

Thanks for the report.

Hmm...May I ask how you performed the installation of the plugin and what version of FARR you are using (I'm using 2.45.01)?

FWIW, the new plugin has some code split out into a separate file so upgrading is no longer a matter of replacing fscript.js -- on the off-chance that that's what was going on

Edit: I managed to reproduce the error -- investigating now

ewemoa · « **Reply #31 on:** January 21, 2009, 03:37 AM »

Terribly sorry -- completely my fault. Sorry to have wasted your time.

I have uploaded a version with a work-around [1] -- this time I tested the installation from the downloaded file (like I should have done to begin with!).

[1] I had code for determining the directory of the plugin that was specific to my atypical set up -- as I understand it, a future version of FARR should make the work-around unnecessary (though I'll need to update the plugin to make use of the feature).

phitsc · « **Reply #32 on:** January 21, 2009, 04:35 AM »

Thanks. Works perfectly now!

Can I disable the 'Failed to look up value for' popping up for non-configured file types somehow? (not all files want to be opened by Akete

)

Now if only mouser could fix the 'wildcard matching not working anymore in alias result' problem...

ewemoa · « **Reply #33 on:** January 21, 2009, 05:10 AM »

Thanks for testing again and noticing the issue with non-configured file types. Very good point

I tested a change I made to address the issue and it seems to be working here.

I've uploaded a new version and I have my fingers crossed.

Edit: there may be an issue w/ right-clicking on a result which has an extension that has not been configured -- looking into this now.

ewemoa · « **Reply #34 on:** January 21, 2009, 05:35 AM »

Ok, I think the "right-clicking on a result which has an extension that has no related configuration" issue has been addressed -- hopefully in an appropriate manner.

nitrix-ud · « **Reply #35 on:** February 17, 2009, 08:20 AM »

very nice plugin

plugins that enhance core FARR features are great

let me suggest the following feature that i would love to see :

what if we could specify what application to run based on the file's folder

[Akete]
C:\_joker\lnk=C:\Program Files\Notepad++\notepad++.exe

would mean every file inside C:\_joker\lnk should be opened with notepad++

that would gives us even more power !

Keep up the good work
nitrix

ewemoa · « **Reply #36 on:** February 17, 2009, 08:36 AM »

Interesting idea.

If this were to be implemented, I wonder if it might work better to do it with something like:

[Akete.Folders]
C:\Documents and Settings\Administrator=C:\Program Files\Notepad++\notepad++.exe

One thing to consider is what to do about files in subfolders...

On a tangential note, I wonder if having something like:

[Akete.Variables]
$np=C:\Program Files\Notepad++\notepad++.exe

might allow one to do something like:

[Akete.Folders]
C:\Documents and Settings\Administrator=$np

If this were doable, it might make some of the existing functionality a little nicer. That's off the top of my head though -- probably a good idea to explore the consequences and practicality a bit more.

nitrix-ud · « **Reply #37 on:** February 18, 2009, 04:23 PM »

any implementation would please me

my goal is to simplify my workflow when using FARR ...

i have several aliases with action and folder modifiers (ex : Favorites search $$1 | dosearch +folder_fav +open_fav -alias $$1)
having this folder-based configuration would remove the need for those aliases...
and therefore remove the need for the few first characters (to trigger the aliases...)

so much power, i would feel like a super hero

ewemoa · « **Reply #38 on:** February 19, 2009, 03:59 AM »

I might consider working on an implementation, but at a minimum I think I'd like to convince myself of a coherent design. If I don't understand how it is supposed to work, I'm not going to have an easy time getting it to work, nor maintain

Another potential issue that occurred to me is precedence. It's not clear to me yet whether a folder setting should take precedence over a file extension setting or vice versa. If "it depends", then coming up with a way of expressing which setting "wins" for a particular situation or for certain situations seems like a possible way out.

It seems to me that the idea (as I currently understand it) is not well-defined enough for an attempt at an implementation. Perhaps I'll think of something -- or may be someone else will

nitrix-ud · « **Reply #39 on:** February 19, 2009, 08:34 AM »

you are right about precedence and in general about the fact that it is not trivial

the way i see it, is a bit dumb i must admit

i simply told myself : that is a nice plugin ! what if we could trigger what application to run based on the file's path

it could be a completely different plugin with no connection whatsoever

when using Akete plugin, we are talking serious fine tuning and i believe that people that use it, know what they do
i will not ask for a refund if it creates some after effects

as a simple example, please consider the following :

i have a folder named snippets with all sorts of code snippets inside...
i'd like to use FARR to search for one of them then copy its content to the clipboard thanks to an homemade .exe

with the Akete.folders

plugin i just do :

[Akete.Folders]
C:\Documents and Settings\My Snippets=C:\Program Files\copytoclip.exe

of course i could do it now with Akete, by specifying a special extension :
[Akete]
.snip=C:\Program Files\copytoclip.exe

but for some reason i would rather not go this path

so my suggestion is : if you do it, do it any way you see fit

PS : It could also be part of FARR core-functions right within the Search folder interface...

ewemoa · « **Reply #40 on:** February 21, 2009, 09:58 AM »

it could be a completely different plugin with no connection whatsoever
-nitrix-ud (February 19, 2009, 08:34 AM)

It's not clear to me that doing it in a separate plugin will help -- it might, but it isn't clear to me how yet (if it indeed is helpful).

i will not ask for a refund if it creates some after effects

Well, you might not, but it's not entirely unlikely that it would bother me -- I use the plugin too and at least currently, I look after the code. I think it would be kinder to the current and potential future maintainers if the plugin's design and implementation are clear and coherent

with the Akete.folders plugin i just do :

Actually, this wasn't meant as a separate plugin -- user variables under [Akete.Folders] are accessible to any plugin as far as I understand. I had thought that placing the settings in a separate section might simplify the design and configuration.

so my suggestion is : if you do it, do it any way you see fit

I do not see a way that is fit just yet -- however, who knows what the future may bring?

nitrix-ud · « **Reply #41 on:** February 22, 2009, 05:43 AM »

i'll keep using my aliases then

ewemoa · « **Reply #42 on:** March 13, 2009, 04:12 AM »

if AketeFolder plugin was first then the same questions about precedence would have arised with Akete plugin
-nitrix-ud (March 13, 2009, 03:33 AM)

My leaning on this issue so far has been not to do a separate plugin -- it may have seemed like it because of the configuration example, but actually that configuration example would work fine from a suitably modified Akete plugin.

The motivation for me to split the configuration sections into Akete and Akete.Folders was because my impression is that handling the configuration is clearer -- I think that everything living in the Akete section makes for a mess in terms of design as well as in terms of users specifying configurations.

with an hyper complex filtering system where you could see things like :

(if the extension of the file is xxx
AND
if the file is in Folder yyyy
AND
file has been modified within zz hours)
then open with notepad++

Do you think you could start spelling out specifically how this kind of thing would be specified by a user?

nitrix-ud · « **Reply #43 on:** March 13, 2009, 08:57 AM »

maybe this could be done like the directory file opus filter system :
http://www.dopus.com/manual9/NetHelp/default.htm?turl=WordDocuments%2Ftheopusfilefiltersystem.htm

however this should??/could??/must?? be much much simpler

ewemoa · « **Reply #44 on:** March 13, 2009, 04:46 PM »

I took a look and my initial impression is that I very much doubt I have the resources or inclination to try to make something like that -- if FARR provided some way for plugins to easily provide configuration panes that integrated with the existing Options dialog, I might consider it, but AFAIK that doesn't exist currently.

I think the kind of thing that might be practical is doing something within the existing User Variables mechanism -- so imagine a potential user is going to be specifying their configuration via the User Variables pane in FARR's Options dialog box. With this approach we've got:

Separate sections (e.g. Akete, Akete.Folders, etc.)
Name, value pairs separated by equals signs

As I understand it, those are our practical building blocks. Do you have any ideas that can be expressed well using these pieces?

May be there are other practical approaches that don't involve creating basic configuration-related building blocks...I know there is some support available via FARR/FScript for handling INI files, but as I understand it, that's not too different from what User Variables supplies.

If you have any thoughts regarding other approaches, I'm happy to hear them

nitrix-ud · « **Reply #45 on:** March 13, 2009, 07:22 PM »

i completely agree that the existing User Variables mechanism is the way to go...

as i said i would be very happy with a plugin that does not try to handle precedence
because basically, i think a Akete.Folder plugin (as a standalone one or as an extension of the current one) would help people to simplify aliases.
i see immediate applications...

i don't see immediate applications for a more complex version where you could specify different applications to run depending on extension or/and path

with much more complex criterias (attributes, modified date, size, ...), i can see applications, that would even be fun to play with

BUT that would be a LOT of work
and as you said, FARR does not provide the configuration power to do it...

I'm sure that it wouldn't take too long to do a simple version as opposed to one that would try to achieve perfection

and maybe this simple version would cover 80% of our need

in anycase, keep up the good work ewemoa !
and thanks again for the Akete plugin

ewemoa · « **Reply #46 on:** March 14, 2009, 01:06 AM »

as i said i would be very happy with a plugin that does not try to handle precedence
-nitrix-ud (March 13, 2009, 07:22 PM)

As I understand it, it's a problem to not address the precedence issue.

Perhaps one useful way of looking at this situation is to see that multiple plugins trying to handle file extensions is potentially murky. If you've got two such plugins installed and both either are configured or set up to handle a particular file extension, which one should end up doing it?

May be I'm misunderstanding how things work in FARR -- perhaps mouser could clarify

nitrix-ud · « **Reply #47 on:** March 14, 2009, 03:47 AM »

one would handle files based on its path
the other one based on its extension

as i said previously, Akete would not exist, you could very well have created Akete.Folder

and THAT plugin would suit me (personnaly as of today, i would only use Akete.Folder so there would not be any precedence issue...)

however i perfectly understand that having two plugins that could lead to unexpected behavior is not confortable for you

you are right maybe mouser could clarify...

JaneDC · « **Reply #48 on:** December 27, 2011, 11:15 PM »

files launched are not added to the history list? Any way to change the behaviour?

ewemoa · « **Reply #49 on:** December 28, 2011, 02:39 AM »

I don't think there is a way at the moment.

May be mouser could comment on whether this should be doable from a technical standpoint.