Heh -- don't tempt me -- I'm just about at that point to be honest. On Tue, Nov 25, 2008 at 01:45, Josh McDonald <[EMAIL PROTECTED]> wrote:
> I say build a bunch of custom Swing components and build the whole thing > in Java FX, it goes live in a week. > > On Mon, Nov 24, 2008 at 9:38 PM, Jules Suggate <[EMAIL PROTECTED]>wrote: > >> Grr, ok the plot sickens :) >> >> Have just spoken with the guys and someone pointed out that native >> drag-and-drop, custom context menus and similar OS-level integrations are >> never going to be added to the Flash Player now that Adobe have AIR to put >> those features into. I'm inclined to see their point, but I need to think up >> a way around the one-click install showstopper. >> >> Naive approach would be: use a native installer to automate download and >> install of Adobe AIR (if not exists) and an AIR application without user >> intervention. Has anyone tried this? Can it be done (legally/technically)? >> >> Another alternative would be the Shu Player (http://www.shu-player.com). >> This bundles the AIR runtime into a single standalone exe with your AIR app, >> however distributing such applications contravenes the standard Adobe AIR >> license (see http://www.shu-player.com/air-runtime-notice). >> >> Has anyone had any luck negotiating a "case by case runtime distribution >> agreement" with Adobe for bundling the AIR runtime with an AIR application? >> >> Hope you guys can shed some light on this! >> >> Cheers, >> Jules >> >> >> On Mon, Nov 24, 2008 at 22:33, Jules Suggate <[EMAIL PROTECTED]>wrote: >> >>> Hi, sorry for my late reply. >>> >>> Merapi is on our list of "possibles", but we don't like the socket-server >>> approach for reasons of technical aesthetic. Having two separate processes >>> just smells icky... conceptually the Java code and the Flex code both >>> address the same concern -- To Build a Rich Client. Separating them >>> technically is only necessary because the AIR framework doesn't support >>> everything we need. We'd rather keep the technical structure as similar to >>> the logical structure as possible. >>> >>> An example of what could happen: if the Flex UI crashes, the CD burning >>> process might continue. Things like this give the socket server approach an >>> unnatural feel IMHO. >>> >>> The main advantage for us of using AIR would be the application updater >>> harness, but that's ruled out when using the Merapi approach anyway. Most >>> crucially though, we want a self-contained one-click install, and this is >>> just not possible using AIR and Merapi from what I can see. >>> >>> Cheers, >>> Jules >>> >>> >>> On Sat, Nov 22, 2008 at 04:31, valdhor <[EMAIL PROTECTED]> wrote: >>> >>>> I don't know about others but this seems, to me, to be a very >>>> difficult route to take. >>>> >>>> Have you looked at the Merapi Project (http://www.merapiproject.net/)? >>>> This would give you a bridge between your AIR application and the >>>> local Java implementation. >>>> >>>> --- In flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, >>>> "Jules Suggate" >>>> >>>> <[EMAIL PROTECTED]> wrote: >>>> > >>>> > Hi list, long-time-no-post :) >>>> > >>>> > I've a gnarly one here. >>>> > >>>> > I contract to a VC funded startup formed to create a cross-platform >>>> desktop >>>> > client. Unfortunately AIR's APIs are not low-level enough (e.g. you >>>> can't >>>> > burn a CD with AIR). We've looked at Zinc, Shu Player, Janus and the >>>> rest >>>> > but Zinc and Janus don't support MacOS very well and the legal >>>> issues around >>>> > Shu Player make us wary of using it. This is a consumer-facing app >>>> and needs >>>> > to be squeaky clean. >>>> > >>>> > How about embedding the NPAPI FP10 in a Java process? That would be >>>> > cross-platform, and we could use NPRuntime to interact seamlessly >>>> from Java. >>>> > >>>> > The Flash Player license allows us to automate download of the FP10 >>>> > installer, however these are the problems we still face: >>>> > >>>> > - If a user doesn't have the player installed, there will be a >>>> two-step >>>> > install process (one for the player, one for our app), which is >>>> sooo 90s >>>> > - We can't legally change the install location of the NPAPI >>>> plugin, so if >>>> > we automate downloads of the NPAPI FP10 and the user doesn't have >>>> Mozilla >>>> > installed it's unclear what we should do >>>> > - Not sure if we can specify the kind of Player (NPAPI vs ActiveX) to >>>> > download from adobe.com if the user is on Windows >>>> > >>>> > Even for the base case (a user with Mozilla and the NPAPI FP10 plugin >>>> > installed prior to install of our app), should we talk this over >>>> with Adobe >>>> > legal? >>>> > >>>> > Has anyone heard of Adobe entering into custom licensing agreements >>>> for this >>>> > kind of thing (and I mean, actual bonafide true stories, not >>>> conjecture >>>> > based on Adobe's licensing page making passing reference)? >>>> > >>>> > Hope this hits someone's cache! >>>> > >>>> > Cheers, >>>> > Jules >>>> > -- >>>> > Jules Suggate >>>> > Owner and Technical Lead >>>> > Uphill Sprint Limited >>>> > >>>> > +64-21-157-8562 >>>> > >>>> >>>> >>> >> > > > -- > "Therefore, send not to know For whom the bell tolls. It tolls for thee." > > Like the cut of my jib? Check out my Flex blog! > > :: Josh 'G-Funk' McDonald > :: 0437 221 380 :: [EMAIL PROTECTED] > :: http://flex.joshmcdonald.info/ > :: http://twitter.com/sophistifunk > >
