Should "plugins" be a sym link to another directory (like "/Library/Application Support/Perceptive\ Automation/Plugins") that wouldn't get smashed with a reinstall/update?

I have found the need more than once to have a place for "my stuff" (saved data, command line scripts, etc.) that is safe from the installer. It would be nice to have standard.

nsosnicki wrote:Should "plugins" be a sym link to another directory (like "/Library/Application Support/Perceptive\ Automation/Plugins") that wouldn't get smashed with a reinstall/update?

I don't think it needs to be. The installer should only replace files that have been updated (which is why not backing up your .py file changes is dangerous), and it only deletes files if they were installed by a previous Indigo installer but aren't installed by the more recent one being run. So in theory the plugins folder should be pretty safe inside the IndigoWebServer folder, just as Indigo database files are safe inside the Databases folder.

We would want to double-check this of course to make sure reality matches up with the theory.

Regards,
Matt

DaveGee wrote:This is just a rough idea but I think it's nice and clean and makes for pretty easy backup and installs with everything being self contained and located in the web servers 'home' directory in a subdirectory called /plugins or /plugs as in the example below.

This looks good. I need to think about how this applies to the bigger picture of future plugins that add custom hardware support and UI to Indigo itself. In those cases there might be AppleScript, .nib's, etc., that Indigo needs to load as well, which might make moving the plugin folder up a level (into Indigo 2 instead of IndigoWebServer) a good idea. For example, if someone wanted to add support for the Elk alarm system they could potentially want to:

• Add a new Device type and Device dialog NSView nib
• Add new Action types and Action panel NSView nib
• Add Control Page icons, new Control Page control types for the Control Page Editor along with NSView nib to edit its properties
• Add Control Page web handler function for rendering control HTML/JS

Regardless, this is exactly what I was thinking we need to do -- localize all of the plugins to a particular folder with a specific structure.

Matt

I totally agree Matt...

That was the primary reason for writing those ideas out... To get peoples wheels a spinning and perhaps some of them might just chime in with things, ideas and concepts that haven't yet been considered.

Now, while this type of 'official' feature is clearly a 2.X release (at the bare minimum) it doesn't prevent the script hackers among us from getting started now. Even if it means having to do some ugly 'hand hacks' on the templates and css files to get things to integrate in a semi cohesive manner.

The point still remains if we all keep some of these concepts in mind while (you're) still adding code for other 2.0 features and for (for us) potential code hackers out there. It could/would/might be a benefit and/or timesaver.

Final note:

Thinking about this... this thread is going to get awfully messy and go off on several different tracks (making it hard to follow) - perhaps a sub-group either at the top level of this message board or under the v2.0 beta sub-forum may be in order.

After all.... While this is technically 'beta discussion' issues these are not the type of things that non-programmers (end users) will want to wade thru just to report a bug or issue or normal feature request.

Just a thought

Dave

Dave,

I filled in a few details on the FAQ posts at the top of this thread, and I moved this thread into a new forum topic.

I'm going to work on a technique that will let you extend the web server with new pages, without the risk of future Indigo installs overwriting your modifications.

FYI, the file "indigoreqhandler.py" is where quite a bit of logic happens. Almost all web server page requests come through that file automatically via CherryPy. The function defines are based on the HTTP page request. For example, if you request page "http://127.0.0.1:8000/basicpage" then that calls this function in that file:

def basicpage(self, ...)

That function then loads (and caches) the appropriate Cheetah template file and renders it with the current Indigo database objects. The Control Pages are more complicated since there is JS on the client side that polls the server for changed controls, but it still all funnels through that same file.

You can extend indigoreqhandler.py to handle new pages by creating new functions. Currently, those changes will be overwritten the next time you run the Indigo installer, which is something for which I need to create a solution by breaking out the request handler into 2 files (1 core one installed by Indigo, and 1 user definable one that Indigo doesn't touch).

Regards,
Matt

Is there a way to display actual widgets on your control page?
Say for instance, the accuweather widget with the icons for a 6 day forcast.

How would you hand tweek the Indigo Web Server template files to use one?
I am not sure what this file can offer or how I would call it up


/Library/Application Support/Perceptive Automation/Indigo 2/IndigoWebServer/templates/_pageelemlist.html

What are the template files able to do, And how are they implemeted?

Cosmuk wrote:Is there a way to display actual widgets on your control page?

I think you should read over this forum thread -- it sounds like Ollivier was offering to help figure it out?

I personally am not sure how to do this.. I think it would take a bit of hacking, but I imagine it is possible.

Regards,
Matt

Cosmuk wrote:What are the template files able to do, And how are they implemeted?

The template files contain a mixture of HTML and Cheetah templating constructs. They are processed by the IndigoWebServer using Cheetah every time a page is requested in order to dynamically construct a Control Page from your Indigo database. If you edit the _pageelemlist.html template file, then you can insert custom HTML code into all of your Control Pages. After editing them, you'll need to stop and restart the Indigo Server (Indigo 2->Stop Server menu item) for the change to take effect because they are cached by the IndigoWebServer.

Regards,
Matt

support wrote:

Cosmuk wrote:Is there a way to display actual widgets on your control page?

I think you should read over this forum thread -- it sounds like Ollivier was offering to help figure it out?

I personally am not sure how to do this.. I think it would take a bit of hacking, but I imagine it is possible.

Regards,
Matt

I worked with the weather widget code for quite some time and it needs to read/write some preferences. If I comment all of them out, the widget no longer runs locally and exhibits the same behavior as when running via apache. I tried manually setting each preference so it didn't have to read them from a file and I was never able to get it to work locally like that let alone via apache.

All the code is there for reading the weather feed and populating the graphics so I may just try to build something from scratch using that as an example but time hasn't been permitting.

Is there an applscript to change an image on the control page
lets say if its daylight, change the "moon" to a "sun"

or if the accuweather icon = 33 { when its polled}
change the "clouds" to a "sun" image

You might try this tip I wrote when mric asked the same question.
Haven't tested it myself.

Actually the accuweather web site has the icons already numbered and avaiable for download.

The Accuweather varible, I have on the control page, displays the icon number it is looking for.
(AWWeathericon) <<value>>

I have the icons in the varibles folder I just don't know how to create the applescript to post them when they are represented in the
(AWWeathericon) varible.

I know I am being a bit rudementary here but thanks in advance for any examples.

http://accunet.accuweather.com/wx/accun ... _icons.htm
[/url]

Indigo does not currently let you (via AppleScript or any other mechanism) swap in arbitrary icons. Instead it lets you toggle between two different icon files based on the boolean (either true or false) setting of a variable value. So you could have a variable called "isCloudy" which you set to either true or false, and then you could have two different image files:

iscloudy.png (image file of sun)
iscloudy+true.png (image file of clouds)

Eventually here Indigo will allow variable controls with arbitrary images, so you can have:

weathericon+cloudy.png
weathericon+sunny.png
weathericon+snow.png
etc.

But Indigo doesn't currently support that. There might be a way to hack around it though by using AppleScript to swap in the image file you want, and then toggle the variable value from false back to true to get the IndigoWebServer to push out the changed file. I'm not sure if that would work or not...

Regards,
Matt

I have tinkerd with placing a PDA url on a frame in a control page.
such as:
http://www.ssec.wisc.edu/data/paw/usmw_ ... _none.html

It worked quite well,But Ihave no understanding of how to do it with Indigo.

This would completly negate the compexity of creating an applescript to post an icon and instead simply post the different "frame" information you are requesting from the URL.
i.e. create a button that calls the PDA URL and displays it in a frame on the control page.
This could be very useful.
Is there an Easy way of implementing this?
these are more resources
http://www.ssec.wisc.edu/data/paw/
http://www.cantoni.org/palm/
Thanks in advance for any suggestions or examples.