Writing a WPF Display
95 views
Skip to first unread message
Joel Bennett
Jul 14, 2012, 8:55:48 PM7/14/12
to growl-fo...@googlegroups.com
Hey Brian ...
After all this time I've been thinking again about writing that skinable WPF display, but I have two questions:
1) Is it enough to derive from VisualDisplay, or do you have a dependence on NotificationWindow?
2) What do I have to do to get my dll to show up in the list while I'm developing?
Asked another way: what does your "Deployment" package do? I'm working on a Win8 box, and installed VS2012 but not 2010 (yet), and the Deployment project won't convert (Those projects were deprecated in 2010 http://msdn.microsoft.com/en-US/library/wtzawcsz.aspx http://msdn.microsoft.com/library/e2444w33.aspx )
Joel Bennett
Jul 14, 2012, 9:02:54 PM7/14/12
to growl-fo...@googlegroups.com
Ok, you can ignore 2 (for now), I've found AppData\Local\Growl\2.0.0.0\Displays and made it my pet.
I'll still need to create a new installer project eventually. I'm thinking WIX - would you like it if I make it?
Brian Dunnington
Jul 14, 2012, 9:54:48 PM7/14/12
to growl-fo...@googlegroups.com
Yeah, you are on the right track. The old 'Deployment' project for displays pretty much just installs the files into the AppData location and that is it, so it is not necessary.
In fact, most displays that are available on the GfW website now use GfW's built-in ability to install its own displays. Display authors can zip up their display files (assemblies and any supporting files that would normally be in the AppData folder) and provide an xml manifest file that describes the display. The author can then construct a special link to the manifest file using a growl: protocol handler and when a user clicks the link, GfW will launch, read the manifest, download and unzip the files to the right place, and let the user know that the new display has been installed.
As for the actual display, you should be able to implement VisualDisplay and not have to inherit from NotificationWindow. Another contributor on here (FrozenCow) created the Translucent Dark display using WPF and inherited directly from IDisplay (even higher up the chain than VisualDisplay). He also created a WPF wrapper assembly for creating WPF-based displays, so maybe install that display and then take a look at Growl.Displays.Wpf.dll or ask any questions on here.
In fact, most displays that are available on the GfW website now use GfW's built-in ability to install its own displays. Display authors can zip up their display files (assemblies and any supporting files that would normally be in the AppData folder) and provide an xml manifest file that describes the display. The author can then construct a special link to the manifest file using a growl: protocol handler and when a user clicks the link, GfW will launch, read the manifest, download and unzip the files to the right place, and let the user know that the new display has been installed.
As for the actual display, you should be able to implement VisualDisplay and not have to inherit from NotificationWindow. Another contributor on here (FrozenCow) created the Translucent Dark display using WPF and inherited directly from IDisplay (even higher up the chain than VisualDisplay). He also created a WPF wrapper assembly for creating WPF-based displays, so maybe install that display and then take a look at Growl.Displays.Wpf.dll or ask any questions on here.
--
You received this message because you are subscribed to the Google Groups "growl for windows" group.
To post to this group, send email to growl-fo...@googlegroups.com.
To unsubscribe from this group, send email to growl-for-wind...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/growl-for-windows?hl=en.
Joel Bennett
Jul 14, 2012, 11:31:09 PM7/14/12
to growl-fo...@googlegroups.com
The installation thing sounds great. Although, you know, you should probably create a file type too, rename the .zip file to .grwd or something and register the extension in the installer ... then you don't *have* to use the special protocol, and anyone that downloads them can carry them around on a thumb-drive and install them by just double clicking on any computer where Growl is :-)
And yes, deriving from VisualDisplay looks like a problem, because you've got a List<NotificationWindow> and Show(NotificationWindow win) and so on. Since NotificationWindow is a Form, it's pretty much tied into WinForms.
I'll have a look at his, because otherwise I'll have to make a WPF version of VisualDisplay myself :)
Joel Bennett
Jul 17, 2012, 12:11:55 AM7/17/12
to growl-fo...@googlegroups.com
Is GfW currently still a .Net 2.0 project?
On Sat, Jul 14, 2012 at 9:54 PM, Brian Dunnington <briandu...@gmail.com> wrote:
Joel Bennett
Jul 17, 2012, 2:24:03 AM7/17/12
to growl-fo...@googlegroups.com
By the way, I'm asking about the framework version because I grabbed it from svn and it is set to 2.0 and it wouldn't compile until I switched it to 3.x (it looks like the included Newtonsoft,JSON is 3.x). Of course, I have to use 3.0 to get WPF, but Growl doesn't have to...
Anyway, I have a patch to change the use of NotificationWindow to an interface INotificationWindow and then implement that interface on your NotificationWindow class. Everything works ;-) and it basically just adds the INotificationWindow interface, and then alters NotificationWindow to implement it, and LayoutManager to use it. Other than that it just fixes all the references to the NotificationWindow in VisualDisplay (and the GetLayoutManager method that's in all it's children).
Hopefully I got all the changes that matter (I had to convert everything to my newer copy of Visual Studio, and then I had to try to ignore all those changes (next time I'll take a snapshot after that somehow)).
Anyway, based on those modifications which I hope you'll accept, I have a working, skinable WPF notification, with it's own implementation of NotificationWindow based on System.Windows.Window instead of System.Forms.Form.
It still needs a lot of work (no settings, etc), but I'm going to hold off on that until I know you're willing to accept the patch ;-)
If you want to see the display http://HuddledMasses.org/downloads/Skint.zip will load whatever file is named Skin.xaml for it's display (I included two really ugly ones).
Brian Dunnington
Jul 18, 2012, 9:24:44 PM7/18/12
to growl-fo...@googlegroups.com
Growl is still built against .NET 2.0 - I maintain a VS 2005 instance that I build it from and all of the System.* dlls are 2.0 versions. In fact, VS 2005 wont even let me change the target framework to something else. I am not sure why it wouldnt build for you as-is (I have cloned the repository on other machines and built it successfully myself), but it is probably something to do with the CLR being 2.0 even if the framework is 3.* or something like that?
Regardless, I am more than happy to accept the patch to extract out INotificationWindow. I just got back from a long break and need to get caught up on a few things, but I will get this reviewed and committed later this week.
Regardless, I am more than happy to accept the patch to extract out INotificationWindow. I just got back from a long break and need to get caught up on a few things, but I will get this reviewed and committed later this week.
Brian Dunnington
Jul 20, 2012, 2:32:49 PM7/20/12
to growl-fo...@googlegroups.com
Hey Joel -
I am just reviewing the patch you sent and it mostly looks good. The only question I had was in regards to the changes to LayoutManager that handle repositioning the windows. For example, in a few places you replaced 'currentWindow.Bottom' with 'currentWindow.Top + currentWindow.Height' - was there a specific reason to do so? I dont actually care too much, but I want to be sure that the code still works as intended in all scenarios (whether notifications are stacking up or down or right or left with or without padding, etc). Just wanted to be sure these were intentional and well-tested changes before I commit them.
Thanks,
- brian
I am just reviewing the patch you sent and it mostly looks good. The only question I had was in regards to the changes to LayoutManager that handle repositioning the windows. For example, in a few places you replaced 'currentWindow.Bottom' with 'currentWindow.Top + currentWindow.Height' - was there a specific reason to do so? I dont actually care too much, but I want to be sure that the code still works as intended in all scenarios (whether notifications are stacking up or down or right or left with or without padding, etc). Just wanted to be sure these were intentional and well-tested changes before I commit them.
Thanks,
- brian
Joel Bennett
Jul 20, 2012, 5:53:40 PM7/20/12
to growl-fo...@googlegroups.com
Right. I didn't put Bottom in the interface because it's not already implemented in both Forms.Form and Windows.Window. Top and Height are in the interface; they're already implemented in both frameworks.
By definition 'currentWindow.Bottom' equals 'currentWindow.Top + currentWindow.Height' ...
"The value of this property is equal to the sum of the Top property value, and the Height property value."
I thought about adding Bottom to the interface just for Layout Manager, (even though it would force WPF to implement it), but since the only place we needed it was in LayoutManager, I just changed it there.
I tested it with the displays I had available, and made sure that Smokestack still works properly from any corner.
If you prefer, we can put it on the interface, either way, it's not a big deal :)
Brian Dunnington
Aug 27, 2012, 4:58:58 PM8/27/12
to growl-fo...@googlegroups.com
Just an update on this in case you think I forgot about it - I integrated the patch but found some issues in testing. Specifically, any custom displays (not the built-in 4 or 5) started failing. The reason is that they were compiled against a version of Growl.DisplayStyle that had the following methods:
Show(NotificationWindow)
GetLayoutManager(NotificationWindow)
And even though the updated version of those methods take an INotificationWindow, and NotificationWindow implements INotificationWindow, the .NET runtime throws a 'method not found' exception. I started going down the path of re-adding overloads that took a NotificationWindow, but it causes the interface to look wonky to new displays and doesnt work anyway since the internal implementation of those methods has to retain the old code paths as well, making for a big mess.
I am going to continue to try to think of a good solution, but I havent committed anything yet due to these issues.
Show(NotificationWindow)
GetLayoutManager(NotificationWindow)
And even though the updated version of those methods take an INotificationWindow, and NotificationWindow implements INotificationWindow, the .NET runtime throws a 'method not found' exception. I started going down the path of re-adding overloads that took a NotificationWindow, but it causes the interface to look wonky to new displays and doesnt work anyway since the internal implementation of those methods has to retain the old code paths as well, making for a big mess.
I am going to continue to try to think of a good solution, but I havent committed anything yet due to these issues.
Joel Bennett
Aug 27, 2012, 10:52:04 PM8/27/12
to growl-fo...@googlegroups.com
Yeah ... I guess any third party displays would need to be recompiled. I mean, it should be just a recompilation, no code change, but replacing the concrete base object with an interface is still a breaking change.
I can't evaluate how big of a deal that is. :)
I can't evaluate how big of a deal that is. :)
Reply all
Reply to author
Forward
0 new messages