<br><br><div class="gmail_quote">On Mon, Jan 19, 2009 at 11:21 PM, Patrick Shirkey <span dir="ltr"><<a href="mailto:pshirkey@boosthardware.com">pshirkey@boosthardware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

With xul runner it will load at runtime so it would not contribute to any inefficiency in ardour unless enabled.  The code required to embed it into the interface is quite minimal. The only addition would be including the xulrunner folders in the  Ardour package so they are always available.<br>

</blockquote><div><br>I personally think this is not minimal to be honest.  XULRunner last I checked also provides a complete UI setup as well, which is tons of waste there.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
It would make Ardour a complete standalone solution and make it that much harder for users *not* to get involved.<br>
</blockquote><div><br>Ardour already IS a complete standalone solution to be honest.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I don't see why it is a problem to embed a browser if we are going to have external links directly in the interface and expect people to be connected to the internet in order to contribute anyway.<br>
<br></blockquote><div><br>Several reasons.  One, providing an ability to launch an external web browser means less code to upkeep by having it contained in a seperate program.  Large difference between code to execute an external program, vs code to render XML out in a specific method to a window, as I am sure you are aware.<br>
<br>Second, and this is a big one for end users, in many cases having production systems not connect to the internet is standard practice.  Be it a Windows, Mac, or when it picks up likely Linux as well.  It is that much less to worry about, when you don't need to for a purpose built machine.  I know I would never consider having a machine connected to the internet for any machine I was going to record a live show on.  I don't care if it is Linux, Mac or Windows, it doesn't need to be worried about that, I will disable anything I possibly can as it is that much less chance of something odd happening to screw things up.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
IMO, The only thing making it an issue is the time it takes to add the code. It might even be faster than creating and laying out a custom screen with embedded links. Also any changes that get made to the website are immediately visible.<br>

</blockquote><div><br>To be honest the time to add the code isn't the issue at all for me.  The issue is as an end user it is not what I want to deal with.  Also to be honest *I* could probably write the code to do this in Ardour, which means that it is probably minimal effort to embed.  But upkeeping it to match changing web standards for example, as the Ardour website stays up to date, is something to consider.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Seems like it would actually be less maintenance in the long run.<br>
</blockquote><div><br>I would strongly disagree.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
It would also allow users to make financial contributions from directly inside the app while they are using it which is the most likely time they will feel like giving anyway.<br>
</blockquote><div><br>And this I think would be a possible mistake to say the least.  The moment you introduce someone needing to handle financial information you add another level of paranoia for most people.<br><br>Its not that I don't get what you are trying to do.  It is that I strongly disagree with the implementation you are suggesting to achieve such a goal.  It is much better IMO to let the user's web browser handle all the web browsing side of things and not duplicate what is essentially unneeded functionality that would likely add problems and more maintenence in the future.<br>
<br>         Seablade<br></div></div>