Community support - how to develop for BokehJS

On Fri, Sep 25, 2015 at 9:52 AM, Pythonic gsp.sette@gmail.com wrote:

Hello

Bryan this is for you:

further to this discussion where you mention community support, can we have a bit of direction on how to develop for BokehJS?

Case study: I’d like to modify the autocomplete editor for datatables to enable remote ajax-based autocomplete. I thought I could simply expand /bokehjs/src/vendor/slickgrid/editors with this autocomplete editor modified for jquery ajax autocomplete (this solution works in a plain slickgrid application), however I then realised I don’t know how to surface that in Bokeh as the js code in github is in coffeescript, and I can’t even locate BokehJS in my local bokeh directory. Clearly I have a limited understanding on the development process…

Can we have a bit of guidance on how to start from a modification of the /bokehjs/src/vendor of master, to its incorporation in bokeh proper?

You should start with http://bokeh.pydata.org/en/latest/docs/dev_guide.html. This should give you the basics, but not the complete picture. The source code of bokehjs is located in bokehjs/src/{coffee,js,less}. Besides this, there is also bokehjs/src/vendor and dependencies pulled in from npm (see dependencies section in bokehjs/package.json). In therory, we should only have npm dependencies, but some need special attention and they land in vendor. However, we don’t implement any new features in vendor, only apply integration patches. If possible, you should implement new features in bokehjs, in this case somewhere in bokehjs/src/coffee/widget. Alternatively, especially if you have to modify slickgrid, you should make the modifications upstream, wait for a release and upgrade slickgrid in vendor, maintaining our changes. Unfortunately, slickgrid isn’t currently maintained, so this process won’t work. Maybe we should fork slickgrid under bokeh organization and continue development there.

Mateusz

–

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+unsubscribe@continuum.io.

To post to this group, send email to bokeh@continuum.io.

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/e052321b-9fa1-48c8-a2ce-fe9f89e57a08%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

On Friday, 25 September 2015 10:36:55 UTC+1, mateusz.paprocki wrote:

Hi,

On Fri, Sep 25, 2015 at 9:52 AM, Pythonic gsp....@gmail.com wrote:

Hello

Bryan this is for you:

further to this discussion where you mention community support, can we have a bit of direction on how to develop for BokehJS?

Case study: I’d like to modify the autocomplete editor for datatables to enable remote ajax-based autocomplete. I thought I could simply expand /bokehjs/src/vendor/slickgrid/editors with this autocomplete editor modified for jquery ajax autocomplete (this solution works in a plain slickgrid application), however I then realised I don’t know how to surface that in Bokeh as the js code in github is in coffeescript, and I can’t even locate BokehJS in my local bokeh directory. Clearly I have a limited understanding on the development process…

Can we have a bit of guidance on how to start from a modification of the /bokehjs/src/vendor of master, to its incorporation in bokeh proper?

You should start with http://bokeh.pydata.org/en/latest/docs/dev_guide.html. This should give you the basics, but not the complete picture. The source code of bokehjs is located in bokehjs/src/{coffee,js,less}. Besides this, there is also bokehjs/src/vendor and dependencies pulled in from npm (see dependencies section in bokehjs/package.json). In therory, we should only have npm dependencies, but some need special attention and they land in vendor. However, we don’t implement any new features in vendor, only apply integration patches. If possible, you should implement new features in bokehjs, in this case somewhere in bokehjs/src/coffee/widget. Alternatively, especially if you have to modify slickgrid, you should make the modifications upstream, wait for a release and upgrade slickgrid in vendor, maintaining our changes. Unfortunately, slickgrid isn’t currently maintained, so this process won’t work. Maybe we should fork slickgrid under bokeh organization and continue development there.

Mateusz

–

You received this message because you are subscribed to the Google Groups “Bokeh Discussion - Public” group.

To unsubscribe from this group and stop receiving emails from it, send an email to bokeh+un...@continuum.io.

To post to this group, send email to bo...@continuum.io.

To view this discussion on the web visit https://groups.google.com/a/continuum.io/d/msgid/bokeh/e052321b-9fa1-48c8-a2ce-fe9f89e57a08%40continuum.io.

For more options, visit https://groups.google.com/a/continuum.io/d/optout.

On 09/25/2015 09:02 AM, Bryan Van de Ven wrote:

In therory, we should only have npm dependencies, but some need special attention and they land in vendor. However, we don't implement any new features in vendor, only apply integration patches. If possible, you should implement new features in bokehjs, in this case somewhere in bokehjs/src/coffee/widget. Alternatively, especially if you have to modify slickgrid, you should make the modifications upstream, wait for a release and upgrade slickgrid in vendor, maintaining our changes. Unfortunately, slickgrid isn't currently maintained, so this process won't work. Maybe we should fork slickgrid under bokeh organization and continue development there.

We should absolutely do this.

On Fri, Sep 25, 2015 at 9:35 AM, Steve Waterbury <waterbug@pangalactic.us> wrote:

On 09/25/2015 09:02 AM, Bryan Van de Ven wrote:

In therory, we should only have npm dependencies, but some need special

attention and they land in vendor. However, we don't implement any new
features in vendor, only apply integration patches. If possible, you should
implement new features in bokehjs, in this case somewhere in
bokehjs/src/coffee/widget. Alternatively, especially if you have to modify
slickgrid, you should make the modifications upstream, wait for a release
and upgrade slickgrid in vendor, maintaining our changes. Unfortunately,
slickgrid isn't currently maintained, so this process won't work. Maybe we
should fork slickgrid under bokeh organization and continue development
there.

We should absolutely do this.

Big +1!

I think a maintained fork of slickgrid would be welcomed by many,
including myself.

On 09/25/2015 11:31 AM, Peter Wang wrote:

On Fri, Sep 25, 2015 at 9:35 AM, Steve Waterbury > <waterbug@pangalactic.us <mailto:waterbug@pangalactic.us>> wrote:

    On 09/25/2015 09:02 AM, Bryan Van de Ven wrote:

            In therory, we should only have npm dependencies, but some
            need special attention and they land in vendor. However, we
            don't implement any new features in vendor, only apply
            integration patches. If possible, you should implement new
            features in bokehjs, in this case somewhere in
            bokehjs/src/coffee/widget. Alternatively, especially if you
            have to modify slickgrid, you should make the modifications
            upstream, wait for a release and upgrade slickgrid in
            vendor, maintaining our changes. Unfortunately, slickgrid
            isn't currently maintained, so this process won't work.
            Maybe we should fork slickgrid under bokeh organization and
            continue development there.

        We should absolutely do this.

    Big +1!

    I think a maintained fork of slickgrid would be welcomed by many,
    including myself.

In the past when I talked about with Brian Granger (Jupyter project), he
indicated interest in working on QGrid, the Quantopian fork/enhancement
of SlickGrid:

qgrid · PyPI

On Friday, September 25, 2015 at 11:46:46 AM UTC-4, Stephen Waterbury wrote:

On 09/25/2015 11:31 AM, Peter Wang wrote:

On Fri, Sep 25, 2015 at 9:35 AM, Steve Waterbury > > > <wate...@pangalactic.us mailto:wate...@pangalactic.us> wrote:

On 09/25/2015 09:02 AM, Bryan Van de Ven wrote:

        In therory, we should only have npm dependencies, but some

        need special attention and they land in vendor. However, we

        don't implement any new features in vendor, only apply

        integration patches. If possible, you should implement new

        features in bokehjs, in this case somewhere in

        bokehjs/src/coffee/widget. Alternatively, especially if you

        have to modify slickgrid, you should make the modifications

        upstream, wait for a release and upgrade slickgrid in

        vendor, maintaining our changes. Unfortunately, slickgrid

        isn't currently maintained, so this process won't work.

        Maybe we should fork slickgrid under bokeh organization and

        continue development there.

    We should absolutely do this.

Big +1!

I think a maintained fork of slickgrid would be welcomed by many,

including myself.  :)

In the past when I talked about with Brian Granger (Jupyter project), he

indicated interest in working on QGrid, the Quantopian fork/enhancement

of SlickGrid:

https://pypi.python.org/pypi/qgrid

Ah, that would make sense. I was unaware of that one. I spoke too

soon, anyway – I see that (even according to the author of slickgrid)

there are a lot of forks of slickgrid on github, so since I might be

using it in other application contexts than ipython, I would probably

want to use one of the other ones … thanks, Peter!

Cheers,

Steve

On Fri, Sep 25, 2015 at 1:54 PM, JMk <lampkld2@gmail.com> wrote:

There is also this phosphor spreadsheet:
GitHub - jupyter/spreadsheet: A spreadsheet component for phosphor

Op zaterdag 26 september 2015 05:24:14 UTC+2 schreef pwang:

On Fri, Sep 25, 2015 at 1:54 PM, JMk lamp...@gmail.com wrote:

There is also this phosphor spreadsheet: https://github.com/jupyter/spreadsheet

LOL I guess we should probably focus on integrating that one!

-Peter

For information, services and offers, please visit our web site: http://www.klm.com.

This e-mail and any attachment may contain confidential and privileged material intended for the addressee only.

If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed,

and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful.

If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or

incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt.

Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands,

with registered number 33014286