A preview of KNIME Analytics Platform 4.6.0 is now available for testing. If you have any feedback, please let us know by next Friday June 10. As usual, it is a preview build and by no means recommended for production. The official release is planned for June 15.
The full (but still preliminary) changelog is available on our website.
Relevant changes include:
Bundled Python Environment & Python Node API: The KNIME Python (Labs) extension now contains its own Python environment so that you can get started with Python scripting in KNIME right away, no additional software installation needed. Also, a new Python API is provided that allows KNIME nodes to be written completely in Python.
Modern UX/UI & Visualization Nodes: A Labs extension now provides a preview of the new user interface with an improved user experience, along with a set of new visualization capabilities.
Snowflake H2O Machine Learning Model Push-Down: Perform data prediction within Snowflake without the need to move the data out of Snowflake, utilizing H2O MOJO models.
Enhancements to Connectors and Utility Nodes: This includes additional database querying and update methods, including various driver updates and additional connectors to consume 3rd party services (e.g. on Microsoft Azure).
Update of Underlying Libraries, Including an Update to Java Version 17.0.3: This is the most relevant change to users who have written custom KNIME extensions. The updates affect various libraries, including Apache CXF, Log4J and Java itself.
If youâve developed custom node extensions for KNIME, please test your extensions with this preview.
Download the preview from our build download page and take it for a test drive. Please reply here with any problems, comments, or questions â ideally as soon as possible!
Thanks for the preview :). Having a play now, some initial feedback on the new UI preview:
Can I still view KNIME tables as modals? It looks like the new UI isnât multi monitor friendly? Iâve not been able to see two tables at the same time for example.
It looks like a bit like the UI is web based? Will I lose access to my custom swing based cell renderers? Do I need to switch to JavaScript alternatives or render to SVG/PNG instead?
Will we still be able to have multiple workflows open? Getting back to the open workflow screen looks like I need to close the currently open workflow?
Is the above kind of feedback useful or am I trying to do too much with the current preview?
I will echo the points that @swebb made below. I cannot figure out a way to view results tables in another window nor if we can have multiple workflows open at once. I hope these are just due to this being a preview and not the full version.
I found using the Bar Chart (KNIME Labs Extensions) node that the text for the chart title types in backwards âenacirruHâ rather than âHurricaneâ for example.
First of all thanks for the feedback â that kind of feedback is really helpful to us.
Regarding your feedback
We are considering whether to open the table at the bottom as a modal as well, like in the current version.
Yes, the frontend is completely web based. Someday in the future you need to rewrite the renderer to a format that will be a web compatible format (e.g. SVG/PNG âŚ). However we will try to support the swing based renderer for as long as possible. The idea is that the output of the swing based renderer is turned into an image by the framework, but this is not entirely evaluated yet.
Like both of you noticed, at the moment it is only possible to open one workflow at once. However, it will be possible to open multiple workflows in the future.
The forum thread will be visible after the official release and then the redirection will work as expected.
I like to overall look and feel, but here are a few things I noticed and I wanted to give feedback on.
No search in the open workflow selection window.
Open workflow doesnât get highlighted when hovered over, i.e it doesnât go from yellow to black.
No obvious way to open another workflow in addition to what is currently open.
No table output view. This is especially crucial as the table output view has some core functionalities such as search, sorting, and table formatting (e.g making the font, column and width bigger)
But overall, I like the look and feel, and I am excited about the python integration!
first of all thank you very much for the valuable feedback. This is the kind of feedback we are looking for to get it into a shape where it is most useful for our users. Now to your points:
The open workflow selection window is just a start and makes use of existing functionality. We want to improve that in the feature and I agree that a search field would make a lot of sense.
This is intentional. The idea here is, that the âcreate workflowâ is the primary button and the âopen workflowâ is a secondary button. That is why the highlight color is a bit different (changes from dark grey to black).
This is a very good point and we are aware of this limitation at the moment.
Also a good point. The table you see at the bottom is just a start. In the future we want to integrate the same table we are using in the new âTable Viewâ-node. This new table will then also provide the functionality of searching, filtering, etcâŚ
Great to hear that you in general like the new look and feel and if you encounter any other problems let us know.
Is there a way to open a component - the only options on right-clicking a component are Create Component and Expand Component. Without Open Component it is all a bit of a dead duck.
you can enter a component by holding command (mac)/ CTRL (windows/linux) and double click onto the component. But I agree that there should probably be an option in the context menu to do this.
This is actually a very good idea to make the use of Python easier. Question is could you check if a lot of important packages are tested and bundled. I noticed that OpenPyxl seems to be missing - a popular package to manipulate Excel files.
Good point about OpenPyxl @mlauber71 ! That was not on our list for KNIME 4.6, but we will take a note for upcoming KNIME releases. Keep the ideas coming
Below is the list of currently bundled packages, which will also be publicly released with the 4.6 documentation tomorrow.
- h2o # there is obviously a knime implementation but for some advanced things it might be nice to have it
- xgboost
- lightgbm
- auto-sklearn
- autoxgb
- pycaret # no deep experience
- featuretools # feature generator
- miceforest # Missing value replacement
- prophet # time series analysis
- openpyxl # Excel Reader
- arrow
- orc
Question would be which ones should feature in a standard Python environment since experience unsers could always use a custom environment. Also I understood that there will be some development where you could build nodes based on Python - this might be a way to integrate specific packages (or would they use a central python environment?). Looking forward to this.
Another idea could be to also fully integrate a R version (though the variety of packages might be even larger). The Conda Environment propagation allows for the (well) propagation of a R version via conda/Miniconda - for Windows there are the R Windows Binaries - but maybe this could be a way for other operating systems too.
the UI looks very modern⌠but all node configuration modals are âold-fashionedâ⌠Do you see a chance to adapt these as well?
Moreover, it would be great to implement as many of the âoldâ âRight-Clickâ options in the new UI. At least for the âoldâ users, this might be very convenient.
An UI is always a topic for discussions, but I think that the shift to a webbased UI is the right step. And it looks very nice. Congratulation!
thank you for your feedback! Regarding the âold-fashionedâ dialogs: Absolutely, we are working on modern configuration dialogs, too. However, since there are thousands of nodes, itâs nothing we can achieve âover nightâ and there will be a transition phase (thatâs why we still use âold-fashionedâ dialogs in the modern UI). If you like to have a first impression how the modern configuration dialogs look like, just check out our new View nodes (still in Labs, more View nodes to come).
Your second question is best answered, e.g., by @schramm.
@mlauber71 I would advocate that the number of âstandardâ packages in KNIME is kept to a minimum. The rational for this is version control and dependency management. It is important from a KNIME component development and system management perspective to set the versions for each package so that APIs remain consistent. It would appear that we are currently on Python 3.9 which is a good reference point from which to select other packages with known features and capabilities.
As the KNIME version increments so should the Python packages - with known breaking changes well publicised. If this is not managed and controlled from KNIME then all hell will break loose.
@DiaAzul I fully agree that KNIME will have to weight how much packages would be there in a âstandardâ environment and which packages are left to experienced users that can (quite easily) configure their own settings with the help of the Conda Environment Propagation (which again might slightly differ between operating systems). With Python the management of dependencies is always a challenge.
I wanted to offer a few packages that I have in mind, specifically OpenPyxl since questions about additional Excel file manipulation come up in the forum quite often.
So packages might be chosen for the extension of critical functions (Excel, file formats, Graphics, Time Series, Machine Learning) and offer at least one option own all these fields preferably the most common one and leave out exotic examples and ones that are not well maintained.
I worry about this increased emphasis on switching to PNG/SVG rendering of chemical structures.
These do not allow resizing like the renderers do. Also a very useful feature of the renderers is you can copy the cell to the clipboard and then paste into other chemically aware software programmes. That will be lost with image rendering.
It feels like we are taking increasingly retrograde steps with chemistry handling.
Totally valid points (in all threads btw) - all of the feedback everybody provides in one of the threads will be discussed internally (or already is) and considered. We want to get it right and the entire team is waiting for more input.
Obviously, some things will change and be done different in the future, but we really want to avoid complicating simple things or actually decrease the day to day experience of our users. Your (and the feedback from everyone else) is exactly the reason why we asked for feedback so early. Keep it coming and thank you
I worry about this increased emphasis on switching to PNG/SVG rendering of chemical structures.
This isnât exactly what I meant, I think you mean something along the lines of using a Renderer To Image node? This is slow, requires everything to be pre-computed (no paged on the fly rendering) and as you say you lose things like copy the underlying serialised form of the structure.
What I meant is providing a PNG/SVG render for a chemical structure cell rather than the Java Swing implementation. I think RDKit renders may actually be generating a SVG that is then rendered in the KNIME table.
A solution like the first option will be bad (this is how I view structures in composite views and itâs has the drawbacks highlighted). With the switch to a new frontend technology weâd want to keep the capabilities around structure based cells we already have I agree !
We have some places where we do use the Rendered to Image node to generate images to add to a report. If we switch to use a live JavaScript based rendering we may end up with differences between live views and reports unless we did something like the generation of SVG the JavaScript plot nodes have?
