phovea / phovea.github.io Goto Github PK

I had thought @ngehlenborg had registered a domain, but might be imagining that. I'm comfortable with phovea.github.io or with a domain we own, but we should clarify this before linking from caleydo.org.

@bikramkawan: I haven't ported over your web_bundle_2:

• I'm not sure if it's ready to go yet?
• With the work Sam has done, it might no longer be the preferred approach.
• Maybe crop the screenshots more tightly do we don't see as much of the headers which are likely to change?
• For data structures, consider capturing test, rather than copy and paste.

(Once images are checked in, they are part of the history forever, so I wanted to hold off on these until we were more confident.)

There are also a few punctuation / grammar issues I might touch, which is part of a larger discussion: How good does the writing need to be?

e.g. phovea.js.org

free to register at https://dns.js.org/

@thinkh wrote: (Caleydo/caleydo.github.io#132)

I haven't debugged it, but assume that the call is triggered in idtype.fillUp() when using idtype.list().

A possible to prevent the call is to set the library into the offline mode. However, I don't know the side effects in the Caleydo library.

Looking at http://phovea.caleydo.org/developers/directory_structure/ I see potential for improvement:

1. Could we organize this into directories at the developer needs to touch vs. those that will be managed automagically by Phovea.
2. Could we give some hint as to where the developers are supposed to add their own code and then maybe link to the corresponding coding tutorial describing how to get started with Phovea development?

I'm not sure that the project list makes sense for us now.

Instead, I propose that the we have a naming convention for repos which makes clear what kind of thing each is, and that we only bring into the Phovea space projects which are really ready to go. Also, my sense is that applications built with Phovea will not be under github.com/phovea: They will stay under Caleydo, or in individual contributor's spaces. Taken together, this means the space will be much tider, and we won't need to maintain an outside list.

If this sounds good to folks, after we make this live, I will delete the list-generating script over at github.com/caleydo.

From @thinkh: Caleydo/caleydo.github.io#163

• web_bundle version: 0.0.1
• browser version: Firefox 49.0.1
• OS: Windows 10

Reproducer:

Open Data Structures Tutorial

Observed behavior:

The source code is not really self-explained and hard to understand if you have less programming knowledge and/or not familiar with Caleydo.

A few examples:

  var sequence = Array.from(Array(200).keys())
      .map(function(x){return (x-100)/50;});

or

      sequence.map(function (m) {
        return sequence.map(function (n) {
          // Gentle gradient across the whole thing...
          // with ripples in the middle.
          return m*n + Math.sin(1/(m*m+n*n));
        })
      }),
      sequence, // row_ids
      sequence // col_ids

What does matrix.view(parse('(0:200:5),(0:200:5)')), do?

Expected behavior:

Please add more comments, either as commend in the source code (prefered) or as text in the Markdown file.

currently serving 404s

When it's up, the site needs a design review:

• Since it's just a subset of the caleydo site, I've removed the banner buttons... but it looks pretty bare now.
• Old Caleydo logo has vectorized text. Replaced it with ... but the Helvetica is too skinny in that role.
• I got rid of the title, since everything was "Documentation", but maybe it should come back and be used more appropriately?
• Does the sidebar idiom work? At the very least, I think we should highlight the current page for context... but even then, if this list gets longer than the window height it's not going to work well.

Let's wait a week at least, but at some point when we decide this is working, the original can be removed from caleydo.github.io.

Here is another proposal how to restructure the Phovea documentation page.

• Welcome
  • Mission Statement
  • Features (aka What Phovea can do for you?)
  • Comparison table between library and stand-alone version
• Getting Started
  • Library Version
  • Initialize client-side app
  • Initialize server-client app
• Docs
  • Cheatsheet
  • Data Connectors
  • Data Structures
  • Add dependencies
    • To other Phovea plugins
    • External libraries
• Tutorials
• Contribute
  • Used Technologies and Tools
  • Development Process
    • Phovea repository structure
    • Contribute to Phovea repositories
    • Phovea release process
  • Phovea Documentation
  • Phovea Repository Owners
• Reference

At least for typescript, there is now a problem if you try to use the liquid tag. (See #17.) Backticks also render nicely on github itself.

The old site referenced https://creativecommons.org/licenses/by/4.0/legalcode on the homepage, but had BSD checked in as LICENSE. Confirm that cc-by is correct.

Some of the sections are changing rapidly with Sam's work: When that's stable we should do a systematic check to make sure that that is correct. We also have sections which are just TODOs: Perhaps keep that out of the public documentation, and create an issue here?

I'm not sure what's going on, but on localhost it's now rendering badly for me:

I've reverted back to a much earlier version of the code, and I still see the same thing, which makes me think that what's at the root of it is the gems, which I upgraded locally in order to reproduce the behavior in #17. Normally, you would lock your gemfile versions, but because what really matters is the behavior at github, we're not doing that.

That said, http://phovea.caleydo.org/tutorials/tutorial_getting_started/ still looks fine. Perhaps travis is running with a newer set of gems than github? But that doesn't make sense: in the Gemfile we just say "gem 'github-pages'"... It would be weird if they introduced a problem in their own gem?

The current system requires us to keep a configuration file in sync with the files on disk. Instead, let's divide _documentation into a number of collections, and then if you add a file in the right place it will just show up. Nested collections don't seem to be possible, but having to enumerate the half dozen types of collections isn't the worst thing.

(Orignally noted by @thinkh: Caleydo/caleydo.github.io#165)

• web_bundle version: v0.0.1
• browser version: Firefox 49.0.1
• OS: Windows 10

Reproducer:

Open Demo 9 and click a heat map cell.

Observed behavior:

The heat map cell is not highlighted.

Expected behavior:

The heat map cell should be highlighted. The CSS class caleydo-select-selected is already set to the selected rect element. I assume that the caleydo.css is not imported in this example.

There seems to be a missing link in the section highlighted in the screenshot:

Sam writes:

I just read: http://phovea.caleydo.org/contributors/prereqs/

Note, however, that we are not really using the Node.js language, nor the central NPM repository.

we are using the npm registry for managing web-libraries/plugins and we might publish tagged versions, too

Server-side code uses the Python Flask framework.

actually plugins that register namespaces can use any WSGI compliant python framework

multiple libraries are combined using Webpack.

quite and understatement for applications. Everything is packed using webpack, including assets and stylesheets

Anything that can return either a zero (success) or non-zero (failure) status can be part of your tests, but typically unit tests will be written with Jasmine and run with the Karma test runner.

why is that important that people can use any tool? they should use the generator and there the travis config is given. btw. python side -> pytest + linting is not mentioned at all

• Short writeup on what makes a good bug report
• add a template to the generator and to projects that already exist
• see if there's any easy way to get the same set of labels across a set of projects

Earlier discussion on Caleydo/caleydo.github.io#111

hello world at http://bl.ocks.org/sgratzl/f5e23207a83cc6f159184a85765db476