You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cordova.apache.org by Pat Deegan <pa...@psychogenic.com> on 2018/01/04 22:06:20 UTC

Cordova CLI integration for Linux Wrapper

Greets,

Made a post to JIRA (https://issues.apache.org/jira/browse/CB-13723) but
was advised this would be a more appropriate venue. Also, sorry if this
is a dupe--wasn't subscribed to the list at time of original send, and
can't see it in the archive on markmail, so I'm trying again...


*** Cordova-Ubuntu is Dead ***

To recap, I create apps using cordova and ionic.  I had been using
cordova-ubuntu for Ubuntu releases of the apps, but that's been dead for
a while and there's nothing for us with Ubuntu 17.x.

To address this, and to address the fact that cordova apps were
restricted to *Ubuntu*, I've created Coraline:
https://coraline.psychogenic.com/

It's basically a webkit renderer plus a plugin system so we can use the
same codebase for iOS/Android/Win as for Linux.

*** Coraline: Cordova wrapper for Linux ***

Coraline is the same as cordova-ubuntu in that it renders the web-tech
apps and gives you access to the native system through plugins, using
the standard interfaces.

It's different from cordova-ubuntu in that:

  * it doesn't rely on the ubuntu-sdk, of course, or Qt--it's straight
up C++, though plugins _can_ use Qt;

  * in theory, it runs on any flavour of Linux;

  * plugins are dynamically loadable, and shared--no need to install the
same functionality with every app (though there are facilities for
app-specific plugins);

  * because of the above point, apps don't actually need to be compiled
–you just need a directory with all the html/js/resources, massaged
appropriately to get rid of the Node stuff.


You can get details, and see a walk-through video, on linux deployment
at: https://coraline.psychogenic.com/developers/deployment/

The short of it is that the ideal procedure is to create a bundle (.deb
or .rpm, say) that includes the transpiled JS/HTML and other resources,
along with desktop shortcuts and such.

*** Plugins ***

The plugins need only:
  * be dynamically loadable
  * implement the Coraline Plugin interface
  * have standard functions to actually get a handle on an instance

I've got a wrapper that maps the CPlugin/Qt stuff to integrate old
ubuntu plugins (though it requires some manual tweaking), and have
ported a few (Device and SQLite), so we can rescue the existing
cordova-ubuntu plugins.

*** Wish List ***

The reason I'm writing is that I'd like to know what it would take to
integrate coraline app "builds" with the cordova CLI.

In my ideal scenario, we'd have a new "linux" target that would allow
creation of coraline-compatible bundles.
	
It shouldn't take too much effort, but I'd like to both gauge interest
and get pointers on how integration with the cordova CLI build actually
happens.  In short, I want to know what it would take to get integration
going, and some ideas on how to do it.

Any input on this, feedback on Coraline, or questions are welcome.

Thanks!
Pat Deegan


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
For additional commands, e-mail: dev-help@cordova.apache.org

Re: Linux Platform Integration Alpha (Api.js etc)

Posted by julio cesar sanchez <jc...@gmail.com>.

That ugly message is caused probably by Cordova lib, I think we "broke"
something when switching from a pinned npm to the system one, all the
errors are appearing like that now.

2018-01-16 3:08 GMT+01:00 Shazron <sh...@gmail.com>:

> 3. Promises, ugh. Try reject OR throw, not both.
> https://github.com/psychogenic/cordova-linux/blob/
> 69a4dc92cae54e86761ad286c38710df8693b244/src/cordova/Api.js#L256
> reject does not terminate the execution, it will still throw after the
> reject here...
>
> 4. "cordova clean -> Cleanup project from build artifacts". Are they
> "produced" by the build? Then you clean that up.
>
> On Tue, Jan 16, 2018 at 9:49 AM, Pat Deegan <pat.cordovadev@psychogenic.
> com>
> wrote:
>
> > Hi,
> >
> > First off, thanks for the answers.
> >
> > On 2018-01-15 08:25 PM, Shazron wrote:
> > > 1. Core platforms get the reserved names. Third-party platforms are
> named
> > > after what I presume is their repo name (not 100% sure on that last
> > part).
> >
> > Ok, cool--I can wait for a nice reserved name, down the road.
> >
> > >
> > > 2. I would check out a platform example, i.e. 'ios':
> > > Is this what you were looking for?
> >
> > Yes, perfect.  Will base mods on that.
> >
> > >
> > > 3. What do you mean by ugly? Example. AFAIK it's just "throw new
> > > CordovaError('error string')"
> >
> > Ok.  By ugly I mean instead of getting some:
> >
> >   "Error, cannot proceed: error string"
> >
> > or something similar, the output is instead:
> >
> > === snip ===
> >
> > (node:1025) UnhandledPromiseRejectionWarning: Error
> > [ERR_UNHANDLED_ERROR]: Unhandled error. (error string)
> >     at EventEmitter.emit (events.js:140:19)
> >     at EventEmitter.module.exports.emit
> > (/tmp/SomeApp/node_modules/cordova-common/src/events.js:71:17)
> >     at Object.module.exports.error
> > (/tmp/SomeApp/platforms/cordova-linux/cordova/logger.js:54:12)
> >     at Api.rejectAndThrow
> > (/tmp/SomeApp/platforms/cordova-linux/cordova/Api.js:258:9)
> >     at /tmp/SomeApp/platforms/cordova-linux/cordova/Api.js:280:8
> >     at new Promise (<anonymous>)
> >     at Api.build (/tmp/SomeApp/platforms/cordova-linux/cordova/Api.js:
> > 270:9)
> >     at
> > /usr/local/lib/node_modules/cordova/node_modules/cordova-
> > lib/src/cordova/compile.js:40:30
> >     at
> > /usr/local/lib/node_modules/cordova/node_modules/cordova-
> > lib/src/util/promise-util.js:30:24
> >     at _fulfilled
> > (/usr/local/lib/node_modules/cordova/node_modules/cordova-
> > lib/node_modules/q/q.js:787:54)
> > (node:1025) UnhandledPromiseRejectionWarning: Unhandled promise
> > rejection. This error originated either by throwing inside of an async
> > function without a catch block, or by rejecting a promise which was not
> > handled with .catch(). (rejection id: 2)
> > (node:1025) [DEP0018] DeprecationWarning: Unhandled promise rejections
> > are deprecated. In the future, promise rejections that are not handled
> > will terminate the Node.js process with a non-zero exit code.
> >
> >
> > === /snip ===
> >
> > Yeah, it contains the error string up there, at the top, but seems like
> > a pretty messy exit.
> >
> > I guess I kind of expect a catch somewhere above my call to make this
> > output more user friendly. Maybe it's an issue with my setup?
> >
> >
> > >
> > > 4. I couldn't find a question in there.
> >
> > Yeah, I sent the email somewhat incomplete there... the short of it was
> > "is it a faux pas to leave some built packages from previous versions
> > lying around after a 'clean'?".
> >
> > It's currently setup such that all the generated files/intermediate
> > results of a build are cleaned up on 'clean', but the versioned packages
> > created are left intact (unless you actually remove the platform).  I
> > like the "safety" of keeping older versions around, but will eliminate
> > them on 'clean' if it's the convention/expectation.
> >
> >
> > >
> > > TBH you would be the only person working on this, and there is no point
> > in
> > > putting this in the dead cordova-ubuntu repo. I would keep it in your
> > repo
> > > for now since that will be the fastest to iterate on since you won't
> have
> > > Apache committer privileges yet, and you will be blocked by us having
> to
> > > pull it in. Once it gets to a usable state, send a proposal to donate
> > your
> > > repo to Cordova in this dev@ list and we will proceed from there.
> >
> >
> > Sounds great, will do.
> >
> > Thanks,
> > P
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@cordova.apache.org
> > For additional commands, e-mail: dev-help@cordova.apache.org
> >
> >
>