Subj says it... Right now it has options to call a script after a WP change, but how about
the ability to call a script w/a monitor#, and have the script return the path for the next image (surprised no one has asked for this!)...

Thanks,
A*a

I would think it would be at least as useful as the scripts called when it is done -- what are they for?

So 1) whatever they are for. And 2, with this one the user can be in control of what images to display -- maybe best if they are coming from my computer as mine do, but order or "playlist" a user wants to display picture. Maybe it would be good to provide a separate program to send the picture change request to DF, as well, that way the script could drive the timing too.

_If_ I don't like the fact that it changes pictures after full screen stops --- just as I see an interesting picture -- it changes -- I could choose to suspend the timer for picture changing while in full screen mode, and reset the timer if the user forces a picture change.

Again -- often I may skip a few looking for a favorite, or a darker one if lights are down, but then as soon as I find one, it used to seem the change-paper timer triggered -- which "should" have been reset to the fixed time after the last paper-change.

If I have access to ratings of the pictures, I could display favorites more often than lower-liked pics.

Basically, DF could be run in a script-driven mode.

Keith Lammers (BFS) DisplayFusion Administrator hours, 32 mins ago
Ah I see. The run program after wallpaper change setting isn't really meant for that kind of stuff. It's just a blind "run this process" after the wallpaper changes. We added it way back in the day so that people could have BGInfo run after a wallpaper change, to update the BGInfo wallpaper overlay.

The stuff you're requesting would be better suited to DisplayFusion Scripted Functions/Triggers. If we're able to add that functionality in the future, we'll definitely let you know!

Well, I wasn't trying to use your old script hooks for passing the name of a WP back, since they don't seem to be usable for that purpose.

I think I was confusing in that I got a 2nd, related idea while I was writing the 1st.

The 1st idea was simply to call an external program with the monitor # as an argument that would pass back a pathname of the picture to display on that monitor. Seemed very simple, w/the benefits that the user can write the program in any language they want and use any algorithm they want to choose the next wallpaper.

The 2nd idea that is related, but not a part of idea 1, is to provide a cmd-line program that allows me to remotely control DF.  (And here I find myself about to addon to this idea! ARG!) .  Simply, though, I wanted the ability for my program (I use the word program in a general sense -- only to allow the user to write it anyway they want -- though it could be a scripting language like perl or python).  Ideally, I could just call DisplayFusion with the correct command line arguments -- just as one can do with Firefox, and the instance with the command line arguments would pass those arguments to a running instance (if available), or launch a new instance of DF with the cmd-args that would handle the request.  The FF ability to allow invoking FF with a URL, allowed any program to bring up a URL.

Since DF Scripted Functions/Triggers isn't out yet (and doesn't sound like something available in the near future), I can't say how well it would fulfill the requirements of allowing a user program (or arbitrary scripting language) to call DF w/params, OR the simpler case of allowing the user to provide a program that passes back what pathname of picture to display next.  The name of the feature makes me a bit nervous, as it sounds like it might be something only callable through some arcane windows interface or in a special, limited scripting language inside DF -- disallowing the user writing their "extension" in whatever language they wanted.

I wrote random wallpaper changers that took into account ratings and also forwarded keypresses from the image display back to the program to allow me to raise or lower a rating, or go back or forward.  I note that DF doesn't have the ability to go backward if you have "random"[sic] selected.  It's not really "random", but more like "shuffle".  Shuffling being like what you do to a card deck -- random order, but only allowing each card to be picked once until you re-shuffle the deck -- similarly, if the complete set of pictures are known, one would shuffle the order in which they are to be displayed, providing a "fixed order" for one cycle allowing one to go backwards or forwards without disrupting the order of the shuffle.  If the complete set is too large or unknown, then one could pull in the next 'N' names (100, 1000, 256, ... whatever), and use that as the next shuffle set.

But how one chooses the order is a major reason to allow the user to use their own script to select an order, since when you get a bunch of interested users that have their own ideas of orders, you'll get a bunch of different ways -- way more than a fixed program could be expected to guess.

For what types of "commands" could be passed to DF (if you expanded it beyond simply displaying an image passed), that's where you could provide a set of functions/triggers to open up the functions inside, but that would be alot more complex than what's needed for the simpler functions I mention.  Though being able to intercept a global keys that are passed to the external program as rating modifiers or such, would be a more complicated next step.

Meanwhile, the simplest feature here is simply calling a user-provided "chooser" script that passes back the next image(s).  I wouldn't want to complexify something like that with the result that it is shelved.  It would be useful, of course, if that routine was written in a modular manner to at least allow for future re-usage in more complex remote--trigger/function offerings.

Hopefully that makes it more clear?

Tnx,
-linda