GfW 2.0.9 feature request: two ways to allow for specifying paths to icon files

[ToddA]

Hello,

I'm attempting to come up with a general and consistent way for GfW to find the icon files used for the registering app and the notifications. In particular, a way that will allow a mix of 32-bit and 64-bit Windows PCs to run GfW on the same LAN, and allow the icons to be found in the case where GfW is not installed on drive C: on each PC on the LAN. I'm looking for flexibility.

I know that I can specify "x-growl-resource://<uniquevalue>" and embed the binary graphic when sending a REGISTER and NOTIFY packet, however, this is impractical for the environment I'm developing for: The source machine sending the notifications to GfW will often be low-powered Linux devices such as a TiVo or a RaspberryPi with WiFi. I've created a bash script to do the REGISTER and NOTIFY, however, it is important that the size of the packets be small to keep the network footprint low and to allow the notifications to be sent as quickly as possible. (The notifications will be caller ID name/number, occurring in real time.) It's also important that the size of the bash script be kept as small as possible so that it will load/run as quickly as possible.

The REGISTER and NOTIFY will be sent in the same script. I already thought about converting the icon binary data into hexadecimal strings (since bash scripts are just text files and are not binary friendly), but of course this requires the script to have variables with hexadecimal strings twice the binary size of the icon file, multiplied by the number of "Notifications-Count:"'s. Upon transmitting to GfW, the hex strings must be converted to binary for the "Identifier:" lines, and the length also determined. I'm attempting to keep things simple by using one, small, lean script.

In addition, the script will be configured to have the GfW hosts listed as multiple IP addresses in a simple bash array, with the script simply looping through each element to send the REGISTER/NOTIFY using netcat.

So I'd like to specify the icon files with the file:/// URL and have the icons installed on the PC running GfW.

What would be great is if GfW could handle:

1) Relative paths, in particular using the default search path as the directory where GfW is installed. So instead of having to specify two separate full paths:

     file:///C:/Program Files (x86)/Growl for Windows/gntp-images/app-icon.png <-64 bit Windows

     file:///C:/Program Files/Growl for Windows/gntp-images/app-icon.png       <-32 bit Windows

Instead I could tell users to simply paste the gntp-images folder within the folder where GfW is installed. Then in REGISTER/NOTIFY I can use:

     file:///./gntp-images/app-icon.png

When I tested the above the image was not found. I don't know whether GfW just doesn't recognize relative paths, or if I just don't know what GfW thinks is the current directory.

2) Resolution of Windows environment variables within the file:/// URL:

     file:///%HOMEDRIVE%%HOMEPATH%/gntp-images/app-icon.png

or

     file:///USERPROFILE/gntp-images/app-icon.png

-----

I would prefer method #1 (relative paths to the GfW installation folder) so that icon images don't have to be copied for each user on a multi-user Windows PC.

MY QUESTION FOR NOW: Does GfW 2.0.9 allow for relative icon paths? If so, this would eliminate the need to modify GfW for this feature request. If relative paths are allowed, what is the default directory where I would need to paste my gntp-images folder?

[ToddA]

Hello,

I hope to submit my GfW integration app to the NCID maintainer (http://ncid.sourceforge.net) in the next 2-3 weeks and I was wondering if someone could let me know the answer to my question. I want to make it easy for people to install GfW. Here's my question again:

[Brian Dunnington]

GfW handles the file:// protocol using the built-in OS mechanisms. Those mechanisms dont support relative paths (see documentation here: http://msdn.microsoft.com/en-us/library/aa767731%28v=vs.85%29.aspx) so GfW doesnt support relative paths either.

I have been trying to think of a good way to handle your scenario since you originally posted about it and havent stumbled on anything great yet. Just an FYI though, using the Windows environment variables should work, specifically: file://%USERPROFILE%/gntp-images/app-icon.png (your original post had an extra / and was missing the % characters) so that may be one way to go.

--
You received this message because you are subscribed to the Google Groups "growl for windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to growl-for-wind...@googlegroups.com.
To post to this group, send email to growl-fo...@googlegroups.com.
Visit this group at http://groups.google.com/group/growl-for-windows?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brian Dunnington]

I actually misspoke. Although the OS seems to be able to handle file://%USERPROFILE% urls, the image does not show up when sent to Growl. I am investigating and will let you know what I find.

[Brian Dunnington]

GfW's image handling code is being too smart for its own good. When an image url is passed in, it could be one of many formats (file://, http://, x-growl-resource://, etc) so it has to parse it first. To do that, it relies on .NET's Uri class which is specifically designed to parse urls. However, calling 'new Uri(url)' when 'url' contains % characters in the host portion cause it to fail and throw an exception. I tried a bunch of ways of working around the issue, but so far have not been able to come up with a working solution.

On a side note: if you are going to instruct the users to copy the images to some local folder anyway, why not standardize on a folder so that your sending code already knows it? For example, always install the image to C:\GrowlImages or something static so it wont matter if they are on a x86 or x64 machine? Just an idea to get up you and running until a better solution comes a long.

[ToddA]

Hi Brian,

Thanks for researching this and for your efforts to find a work around. I did think about something like c:\growlimages but I've noticed Win 7 (and maybe Win 8?) does not like users putting things in the root directory, giving "access denied" type messages.

I'm mindful of the fact that GNTP should remain OS-agnostic, so for GfW's purposes, does the .NET Uri class validate the path, meaning, the specified path must exist? Or could a future version of GfW have a special beginning path that the Uri class would accept but not require to actually exist, something like:

     file://gfwinstallpath/gntp-images/app-icon.png

This would require GfW to substitute the literal "gfwinstallpath" with its installed location.

Or, maybe something like using a tilde as described here: http://technet.microsoft.com/en-us/library/dd569096.aspx  "A URL starting with a tilde (~), such as ~/ErrorPage.htm, indicates that the specified URL is relative to the root path of the application."

     file://~/gntp-images/app-icon.png

I just tried using a tilde and GfW 2.0.9 isn't able to find the images. (I'm not too surprised and just thought I'd give it a shot.) I realize a tilde is also used to represent a Unix user's home directory, but I think as long as it's documented somewhere in GfW that the tilde points to the GfW application, it shouldn't be a problem. I'm suggesting to use ASP.NET's interpretation of the tilde as the reason (precedent) for GfW's interpretation of the tilde.

It sounds like it just isn't possible within GfW 2.0.9 to do something like what I'm asking for, which is fine for now. I at least wanted to see what might be possible in GfW 2.0.9.

Kind regards,

Todd