biolab / orange-canvas-core Goto Github PK
View Code? Open in Web Editor NEWOrange Canvas core workflow editor
License: GNU General Public License v3.0
Orange Canvas core workflow editor
License: GNU General Public License v3.0
This has been a visual enhancement I've been contemplating for quite some time now, so I'll ask here because there are some visual improvements in progress, like #133.
The channel names display is a very useful and important feature to know if the right inputs/outputs are connected.
However, especially with large workflows (and I mean LARGE with dozens of widgets) having the text over the widget connectors can be very messy and visually distracting.
So I wonder if it would be a good improvement to have no channel names as default and adding a shortcut key, which upon keypress would either toggle the names or simply show them for the duration of the keypress? @irgolic, what do you think of this as a visual improvement?
Upon hovering over a link between two nodes on canvas, additional information shows up:
Continued from biolab/orange3#4154.
A button for recomputation of all widget positions is probably not feasible. What may be feasible is snapping when the user moves widgets. We could emulate snapping in drawing tools, like Illustrator. Canvas could do the following.
For horizontal snapping, it
For vertical snapping, it checks whether there is a widget with a similar x coordinates and snaps.
However, we said that while this would be very nice to have, it is not a priority. Can be implemented when @irgolic has nothing else on his list. :)
Many users delete widgets by clicking on them (selecting them) and pressing backspace. This is an instinctive action for users, a convention found across most applications, much like duplicating via Ctrl+C, Ctrl+V.
After learning to delete widgets this way, users try to delete links this way too.
It would be nice to support this feature. A selected link should display as if it's being hovered over. It should only be selectable via click, not via rectangle drag. However, should its source/sink widgets be selected, it should also be selected.
A selected link should only support deletion – I don't see how copy/paste or drag would function.
Because hardly anyone clicks it before reporting to us. Like biolab/orange3#3118
So it should actually display the error in an edit box that is big enough to display relevant information and (probably scroll down).
Orange canvas version: 0.1.3.dev0
Orange version: 3.23.0.dev
PyQt version: 5.9.2
Operating system: macOS Mojave 10.14.3
Quick Menu loads instantly upon right-click on canvas (also when loading for the first time).
When the quick menu is loaded for the first time, it takes about 2-3 seconds. Afterward, it opens instantly.
I've found that commenting out orangecanvas/gui/tooltree.py:48
(view.setUniformRowHeights(True)
) fixes the issue on my computer, even though this is meant to optimize. Perhaps a Qt bug on specific platforms?
I noticed matchDashPattern
fails for a certain number of dashes (e.g. 10, 11, 14, ...)
from orangecanvas.canvas.items.nodeitem import drawDashPattern, matchDashPattern
dash6 = drawDashPattern(6)
dash10 = drawDashPattern(10)
matchDashPattern(dash6, dash10)
Traceback (most recent call last):
File "test.py", line 7, in <module>
matchDashPattern(dash6, dash10)
File "/home/denolf/dev/orange-canvas-core/orangecanvas/canvas/items/nodeitem.py", line 585, in matchDashPattern
new_l1, new_l2 = matchDashPattern(l1s, l2s)
File "/home/denolf/dev/orange-canvas-core/orangecanvas/canvas/items/nodeitem.py", line 585, in matchDashPattern
new_l1, new_l2 = matchDashPattern(l1s, l2s)
File "/home/denolf/dev/orange-canvas-core/orangecanvas/canvas/items/nodeitem.py", line 538, in matchDashPattern
l1l = l1[l1d]
IndexError: list index out of range
Here is a widget with 10 inputs that has the issue:
from orangewidget.widget import OWBaseWidget, Input
class Adder(OWBaseWidget):
name = "Add two integers"
description = "Add two numbers"
icon = "icons/add.svg"
class Inputs:
a1 = Input("A1", object)
a2 = Input("A2", object)
a3 = Input("A3", object)
a4 = Input("A4", object)
a5 = Input("A5", object)
a6 = Input("A6", object)
a7 = Input("A7", object)
a8 = Input("A8", object)
a9 = Input("A9", object)
a10 = Input("A10", object)
@Inputs.a1
def set_A1(self, a):
pass
@Inputs.a2
def set_A2(self, a):
pass
@Inputs.a3
def set_A3(self, a):
pass
@Inputs.a4
def set_A4(self, a):
pass
@Inputs.a5
def set_A5(self, a):
pass
@Inputs.a6
def set_A6(self, a):
pass
@Inputs.a7
def set_A7(self, a):
pass
@Inputs.a8
def set_A8(self, a):
pass
@Inputs.a9
def set_A9(self, a):
pass
@Inputs.a10
def set_A10(self, a):
pass
There are problems with installing add-ons into Orange installed with conda.
Anaconda, where a lot of users find Orange for the first time, comes with an out-of-date Orange version. Also, the default Anaconda channels do not include conda-forge. Thus, whenever users install add-ons that require a newer version of Orange, or, god forbid, use the add-on dialog to actually update Orange, Orange installs from pip
and wreaks havoc on the current environment. Examples: biolab/orange3#5693 and problem when testing biolab/orange3#5064.
Possible improvements:
@PrimozGodec already started preparing for this: he put most official add-ons onto conda-forge.
When the dialog is improved sufficiently, we could finally enable biolab/orange3#5064.
Now that link selection (#114) is a thing, and context menu shortcuts (#136) are a thing, the link's context menu should also show shortcuts. E.g., remove should show the backspace icon, as it does in the widget's context menu.
This is a matter of refactoring I think, with which some other nuances will be taken care of. For example, selecting some widgets and a link, then right-clicking the link shouldn't clear the selection, it should behave the same way as right-clicking a widget does.
(transferring from #191 so it doesn't get lost)
Until now, canvas-core was not aware of changes to settings in widget-base. It only knew to call sync_node_properties to pack Settings when saving. We have added a node_properties_changed signal, intended to be emitted by subclasses of Scheme. (for widget-base, this is implemented in biolab/orange-widget-base#151)
The following improvements should be relatively trivial to implement. There's probably some more uses for it elsewhere.
Currently, there is an option to add text to Orange workflows. However, there is only one size/colour of text. Thus all the annotations seem equally important although when preparing a workflow this is rarely the case. It would be very beneficial if there was an option to change at least size of the text for different annotations and possibly the colour as well. The use of markdown would be an option.
I believe this is related to #154. :(
Some elements overlap in layout when window is narrowed. When there is a drop down menue that does not have enough space it would be prettier if the main text window was narrowed (and the text was added dots or so) and the arrow part stayed of fixed width.
Additionally, sometimes when Orange freezes the layout is even more shifted (see drop down list of the middle column).
Version: Latest release on Mac. Latest dev version on Linux.
Updating Orange on Windows via the add-on dialog results in an error and defaults back to pip when updating Orange via the add-on dialog as uncovered by biolab/orange3#5064. Updating while running Orange as Administrator succeeds.
Attempting uninstall: Orange3
Found existing installation: Orange3 3.26.0
Uninstalling Orange3-3.26.0:
Successfully uninstalled Orange3-3.26.0
ERROR: Could not install packages due to an EnvironmentError: [WinError 5] Access is denied: 'c:\\users\\thocevar\\appdata\\local\\orange\\lib\\site-packages\\~range\\data\\_contingency.cp37-win_amd64.pyd'
Consider using the `--user` option or check the permissions.
Process Explorer shows that pythonw process has *.pyd files loaded. However, it is possible to update Orange (3.26.0 -> 3.27.1) while it's running from the Orange Command Line. Strangely, it requires two runs. In the first run conda reports that "The environment is inconsistent" and upgrades, installs some packages. In the second run it updates Orange without any errors.
The add-on executes the first run of conda install. It probably detects that it didn't upgrade the package and then runs pip install. The displayed error is the result of this second pip run which shouldn't happen.
When building htmlhelp sphinx chooses the output encoding per table https://www.sphinx-doc.org/en/master/_modules/sphinxcontrib/htmlhelp.html
, but Orange always tries to load the help index with "utf-8".
This means that index can fail to load. I know at least two instances where it does (did) not: biolab/orange3-example-addon#10 and Quasars/orange-spectroscopy#356. Both times smartquotes were the culprit. Disabling them prevents the immediate problem, but it is not the permanent solution.
When I open Orange on my laptop(retina) and I'm connected to an external monitor(non-retina) I get this error:
Traceback (most recent call last):
File "/Users/iNejc/miniconda3/envs/orange/lib/python3.7/site-packages/orangecanvas/gui/dropshadow.py", line 189, in paintEvent
assert pixr == self.devicePixelRatio()
AssertionError
Abort trap: 6
A similar error appears when I run orange on my laptop screen and then I move the canvas to the external monitor screen.
It would be nice if it was possible to rename widgets by directly clicking on the label, not having to right-click on the widget icon to select Rename from the context menu.
To take the macOS Finder as a concrete example – if you want to rename a file, you can right-click on its icon and select Rename from the context menu, but it is also possible to slow-click on the file label directly and then type in the new name. Most other applications I use also behave in this way – if you can see an editable label, you can also click on it to change its name. In consequence my reflex is to click on the label and only then remember that I have to right-click on the icon.
I suggest that it be possible to click on a widget label to edit the label. Currently, renaming pops up an editing dialogue, but it should be possible to edit the text right where it stands. This would allow for smoother interaction and less redirection of visual and mental focus.
Orange opens reload prompt ("Restore unsaved changes from crash?") on new workspace for no reason.
To reproduce:
Expected:
No prompt appears.
Currently, to open a workflow in a frozen state, you first need to press 'Freeze' (the pause button next to the help button in the toolbox), then load the workflow.
This should be saved in the workflow file itself.
Also, it seems the way it works is, if you open a workflow frozen, the widget's aren't created yet. Flicking 'freeze' on and off real quick doesn't propagate the changes, but then allows you to open all the widget windows.
'Freeze' should probably only halt signal propagation, not also widget creation.
The order is multiple inputs is mostly stable within a run of Orange (barring biolab/orange3#4215), but there is no visual indication of it in the canvas.
(Written by @markotoplak; moved from biolab/orange3#4216).
When the user clears settings, Orange says that they will take effect upon restart and then quits. It should restart.
We thought this would be difficult to implement, but it seems it's not: I once googled for how to restart a Qt application and as far as I remember the trick was to just put the QApplication
's exec
in a loop that checks the apps exit code.
Hi,
I have seen that the example workflows are sorted for each examples_entry_points in this function:
The example workflows of my add-on are always placed at the end. I can't place them between or in front of the default workflows, no matter what prefix I give them.
I would suggest sorting the whole workflow list at the end of collecting them:
orange-canvas-core/orangecanvas/application/examples.py
Lines 72 to 73 in 28669be
workflows.extend(examples)
workflows.sort(key=lambda x: x.resource)
return workflows
Or is it your intention to always put the default examples bundled at the front?
We are struggling quite a bit with widget signals in Text. Currently, widgets look at signal type (Table, Corpus, Distances, etc.) and take the first suitable input. However, we'd often like to be more specific.
I.e. Ontology outputs Words, which is a Table. Connecting it to Semantic Viewer first, results in Words being used as a Corpus instead of Words.
Preferably, one could define a more specific input type, so when Words are on the input, they would be used as Words, not Corpus. This would currently be most useful for Text, but surely there could be other use cases.
I am getting a log of an error in the command prompt. It appears after pressing the OK button to restart Orange for updating/installing add-ones via GUI. Although Orange restarts normally, someone should still look into it so it doesn't cause problems in the future.
The error:
--- Logging error ---
Traceback (most recent call last):
File "/usr/lib/python3.8/logging/__init__.py", line 1084, in emit
stream.write(msg + self.terminator)
File "/home/robert/git/.../venv/lib/python3.8/site-packages/orangecanvas/application/outputview.py", line 283, in write
raise ValueError("write operation on a closed stream.")
ValueError: write operation on a closed stream.
Call stack:
File "/home/robert/git/.../venv/bin/orange-canvas", line 8, in <module>
sys.exit(main())
File "/home/robert/git/.../venv/lib/python3.8/site-packages/Orange/canvas/__main__.py", line 706, in main
log.info('Restarting via exit code 96.')
Message: 'Restarting via exit code 96.'
Arguments: ()
It seems widgets cannot be loaded when using python -m orangecanvas
while they can be loaded if you have a full orange installation with python -m Orange.canvas
.
Looking at the code I noticed that extracting the widget description from a module is done in orange-canvas-core like this
orange-canvas-core/orangecanvas/registry/utils.py
Lines 16 to 20 in 7c87f68
and when you have have orange it is done like this
Is there a reason for this difference?
In addition we have two entry points orange.widgets
and orangecanvas.widgets
. Does this mean if I have an addon that should work for both, I have to register my project with both?
Moved from biolab/orange3#2407.
@ales-erjavec (or another person who knows this code), please check whether the fix would be too complicated; if so, just close the issue.
Add-ons that can be installed, get installed on Orange.
When one add-on installation fails, the add-on window closes and none of the checked add-ons after the failing one gets installed.
Windows. Try to install Networks or Timeseries. Then tick an add-on that is listed after one of these two. The add-ons fail and the final add-on doesn't get installed because the windows closes.
Can we make the add-on installation continue after the error was reported? Perhaps catch the error, write it as the status of the add on (e.g. Timeseries - Error), then run the installation for the rest of the selected add-ons?
Orange3 and orange-widget-base have both abandoned python3.5
support, making it impractical to set up a minimum-requirements virtual environment for orange development.
Is there any special reason orange-canvas-core is on 3.5?
I assume that this is not intentional: In all other Mac applications the Window menu lists all the open windows in the application, so that one can choose one to bring to the front, but Orange only has the options Minimize and Zoom.
Create some workflows with File→New, then select Window. It should (in my opinion) list the workflow windows just created. it does not.
First of all, I hate to be the first one to open an issue, because this separation is major!
Second of all, I don't know whether this repo is the right one for this issue, but here goes nothing.
Icons of widget categories are now bigger than before. The left one is the current version, the right one the old version.
(Written by @markotoplak; moved from biolab/orange3#4215).
Describe the bug
When a user connects widgets to the multiple-input widget, these inputs appear in the widget in the order as they were connected. If then, one of the inputs becomes None, the receiving widget does not see them. If, then, it is set to something != None, the order changed.
To Reproduce
Make a workflow like this. Take care that you select things first in the lower Data Table, and then connect this output first to the Table on the right. The order of tabs is going to be (selection, the who DS).
Now, clear selection in the lower Table, and select something in it. The order of tabs in the right table changed.
I first discovered this with the Python Script widget, where this was more painful.
Expected behavior
The order should stay the same and the receiving widget should also see empty connection. Possible solution: "None"s are not filtered, but passed forward.
Orange version:
master
Ctrl+R reloads the most recent workflow. If the workflow was moved to a different location in the meantime, the user gets an error:
----------------------------- EOFError Exception ------------------------------
Traceback (most recent call last):
File "/Users/ajda/orange/orange-canvas-core/orangecanvas/application/canvasmain.py", line 1351, in reload_last
self.open_scheme_file(path)
File "/Users/ajda/orange/orange-canvas-core/orangecanvas/application/canvasmain.py", line 1077, in open_scheme_file
self.ask_load_swp_if_exists()
File "/Users/ajda/orange/orange-canvas-core/orangecanvas/application/canvasmain.py", line 1634, in ask_load_swp_if_exists
self.ask_load_swp()
File "/Users/ajda/orange/orange-canvas-core/orangecanvas/application/canvasmain.py", line 1653, in ask_load_swp
self.load_swp()
File "/Users/ajda/orange/orange-canvas-core/orangecanvas/application/canvasmain.py", line 1683, in load_swp
self.load_swp_from(swpnames[0])
File "/Users/ajda/orange/orange-canvas-core/orangecanvas/application/canvasmain.py", line 1703, in load_swp_from
loaded = Unpickler(f, document.scheme()).load()
EOFError: Ran out of input
-------------------------------------------------------------------------------
We should handle this gracefully - with a warning Workflow not found or similar.
Add two file widgets and a test and score,
connect both (Data -> Data, Data -> Test Data),
move the test and score widget such that the two links are close together,
double-click them such that both links' hitboxes are hit (two edit links windows will open),
create a link in one widget that will disconnect the link in the other widget, (e.g., in the Data -> Data widget, create a Data -> Test Data connection)
then delete that one in the other window (e.g., delete the Data -> Test Data connection in the other link).
-------------------------- AssertionError Exception ---------------------------
Traceback (most recent call last):
File ".../orangecanvas/document/schemeedit.py", line 1634, in __onLinkActivate
action.edit_links()
File ".../orangecanvas/document/interactions.py", line 1130, in edit_links
assert len(links) == 1
AssertionError
-------------------------------------------------------------------------------
Add-on dialogue on current master
Somewhere we have lost markdown formatting. @markotoplak is in favour of removing markdown altogether. I like it, but if no markdown is a better option, I'm fine with it also.
What we need to do is either make the dialogue render as .md or rewrite add-on descriptions to have a nicer format.
In developing an addon, I've encountered dependencies that assume sys.stderr and sys.stdout have an encoding
attribute. (Which is the expected behavior using python 3.7) The replacement of stdout out and stderr with the TextStream class defined in orangecanvas/application/outputview.py
does not define the encoding attribute, and prevents execution of needed code.
Create an addon that does below
import sys
sys.stdout.encoding
Run addon block in Orange and should throw an attribute error.
The problem can be fixed by adding
encoding = None
to /orangecanvas/application/outputview.py
on line 266
This works for my use case, but it might be more appropriate to set a correct encoding value, and provide other missing methods/attributes(if any) defined in https://docs.python.org/3/library/io.html#io.TextIOBase which defines the interfaces used by for sys.stderro/sys.stdout
In __main__.py
, setup_notifications()
and check_for_updates()
display notifications related to Orange3 (usage statistics collection permission, short survey prompt, update check).
These should be moved to the Orange3 repository.
When trying to replicate some problems, we often ask users to run Orange from terminal with -l 4, which may be a hassle for some. Instead, it would be nice to always have a level 4 log in the Log window of the canvas, even when not running with -l 4
, so we could ask users to copy&paste&send it.
Currently this window is mostly empty and useless. Having a huge log there would be unnoticeable and useful.
A similar fix to #194 is likely needed.
The second action on this image (which does not show a quickmenu) results in the following exception.
ERROR:orangecanvas.document.interactions:Failed to create a new node, ending.
Traceback (most recent call last):
File "/Users/marko/dev/orange-canvas-core/orangecanvas/document/interactions.py", line 594, in mouseReleaseEvent
node = self.create_new(event)
File "/Users/marko/dev/orange-canvas-core/orangecanvas/document/interactions.py", line 689, in create_new
action = menu.exec(pos)
File "/Users/marko/dev/orange-canvas-core/orangecanvas/document/quickmenu.py", line 1566, in exec
self.popup(pos, searchText)
File "/Users/marko/dev/orange-canvas-core/orangecanvas/document/quickmenu.py", line 1525, in popup
screen_geom = screen.availableGeometry()
AttributeError: 'NoneType' object has no attribute 'availableGeometry'
This issue will likely require work in biolab/orange-widget-base, but I'm opening it here because it mainly pertains canvas.
Here's an idea: instead of implementing biolab/orange-widget-base#86, which seems complex and hard to execute, let's start simple, and separate canvas-core into two processes:
Even if widgets are threaded, it's very hard to interact with the application, as inputs are ignored. I find myself spam-clicking something when a widget is doing work in a thread, hoping I will click at just the right time for the event loop to catch it. Let's at least separate the canvas process so if an unwanted link that freezes Orange is made, you don't need to crash the whole application; you can restart the kernel.
The pause button pauses computation while the restart button shuts down the kernel and starts it anew.
Off the top of my head, this seems relatively straightforward to implement. I'm not sure how easily we can cut canvas-core in half, but it feels like a realistic idea. @ales-erjavec, what do you think?
If we can pull this off, it will fix a massive UX issue. Crash recovery covers up the symptom of crashing and restarting Orange, but a feature like this could bring us to the reliability of a jupyter notebook (which inspired this issue). Imagine if you had to restart the process every time you wanted to cancel computation. It seems unimaginable – I think that's how we'll feel about Orange if we push this through :)
Original issue: biolab/orange3#4910.
The idea is to start Orange canvas with an .ows file name as an argument, and with some additional argument that would cause it to open the workflow; process it; and close when the processing is finished. Running Orange in this was would not show any GUI.
We usually have some people creating Orange workflows for certain evaluations. If they are happy with it, the workflow stays as it is and other people run it again and again with new data.
To make Orange as reduced as possible for the workflow executors, to avoid errors and to avoid changing the workflow (intentionally or by accident), I would like to see some kind of runtime mode for Orange with the following features:
Proposed realization:
It's not about security (of course the flags in the .ows file could be reset by hand with an editor), but about ease of use and error prevention.
The topic is somewhat related to #144, but in contrast here the user should still be able to interact with the workflow (for data selection and evaluation he has to), but only at certain points.
Would you agree to such an extension in principle?
I would take care of the implementation - if necessary with some startup help, since I have only developed my own widgets so far, but have not yet contributed to the Orange core.
As outlined in biolab/orange3#2749
Dark mode is implemented in Orange, but it doesn't look nice with the category colors.
Some work would also need to be put into changing colors of objects such as shadows.
@JakaKokosar, you had dark mode enabled automatically on a new MacOS recently, right? Did we disable that?
gh-154 introduced making widget channels explicit when you mouseover AND hold shift.
I love it. Makes some workflows so much easier to build. It also enhances discoverability for new users. And it is beautifully executed, thanks again, @irgolic.
At the time we discussed it, someone mentioned that having this as default could confuse new users. I agree. It definitely could confuse confused users, but I strongly believe that it is better to make confusion explicit.
In documentation (click a widget, press F1), there should be 'Find' functionality. Upon pressing Ctrl+F, a widget should pop up much like in other web browsers, taking text input and exposing a 'Next' and 'Previous' button, mapped to 'Enter' and 'Shift+Enter' shortcuts respectively.
QtWebEngine supposedly exposes some methods (QWebEngineView::findText
) to help with this, but I think we have to implement the widget by ourselves. I'm sure someone has done this before, I suggest looking around and copying the skeleton of a widget from elsewhere if possible.
#59 detects and installs missing add-ons but fails if they are installed but the workflow was created by a newer version.
project_name
currently stores only the add-on name. Maybe it should also include the version and then check and update as needed? Could Orange core also be updated via this route?
Pickling error continuously pops us.
To reproduce:
File (iris) - Box Plot. Click on the big blue field (first to third quartile). Delete File widget.
Stack trace:
Traceback (most recent call last):
File "/Users/ajda/orange/orange-canvas-core/orangecanvas/application/canvasmain.py", line 1582, in save_swp
self.save_swp_to(swpname)
File "/Users/ajda/orange/orange-canvas-core/orangecanvas/application/canvasmain.py", line 1598, in save_swp_to
Pickler(f, document).dump(diff)
_pickle.PicklingError: Can't pickle : it's not the same object as Orange.data.filter.FilterContinuous
This should probably be fixed in both, Box Plot, but also canvas. I assume this is related to autosave, so errors should be caught and handled gracefully (I suppose).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.