Community support - how to develop for BokehJS

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?

Hi,

···

On Fri, Sep 25, 2015 at 9:52 AM, Pythonic [email protected] 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 [email protected].

To post to this group, send email to [email protected].

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.

Hey Mateusz

thank you very much for this

One comment on my side:

Unfortunately, slickgrid isn’t currently maintained, so this process won’t work. Maybe we should fork slickgrid under bokeh organization and continue development there

bokeh-slickgrid is a great idea. Just opened an issue on this.

To note a user named 6pac has done some work keeping slickgrid up to date in his own fork, with the latest work done a few months ago

···

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

Hi,

On Fri, Sep 25, 2015 at 9:52 AM, Pythonic [email protected] 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 [email protected].

To post to this group, send email to [email protected].

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.

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.

Bryan

Big +1!

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

Cheers,
Steve

···

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.

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:

-Peter

···

On Fri, Sep 25, 2015 at 9:35 AM, Steve Waterbury <[email protected]> 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. :slight_smile:

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 09/25/2015 11:31 AM, Peter Wang wrote:

On Fri, Sep 25, 2015 at 9:35 AM, Steve Waterbury > <[email protected] <mailto:[email protected]>> 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. :slight_smile:

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

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

···

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 > > > <[email protected] mailto:[email protected]> 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

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

-Peter

···

On Fri, Sep 25, 2015 at 1:54 PM, JMk <[email protected]> wrote:

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

How about this one, I think the most comprehensive datatable: https://datatables.net/

···

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

On Fri, Sep 25, 2015 at 1:54 PM, JMk [email protected] wrote:

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

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

-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