biolab / orange-canvas-core Goto Github PK

(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

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.

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.

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.

Upon hovering over a link between two nodes on canvas, additional information shows up:

• link text fades in,
• the link changes in color, depending on signal type (Data, Model, Learner, Corpus, ...?)

Am I the only one who doesn't like the new quick menu design? Are these dark buttons intentional?

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.

(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.

• save crash recovery state also on Setting change, not just workflow change (CanvasMainWindow.save_swp). Also, the workflow should freeze when restoring crashed state, so a perpetually crashing state is not restored.
• set SchemeEditWidget as modified on Setting change. With this change, Orange should be acutely aware of when the workflow is and is not modified. No more 'do you want to save?' when no changes have been made.

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.

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:

    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?

• What's wrong?
  I installed Orange3, and it was working very well but then when I try to open it again, I could not. It opens for a few seconds then it closes immediately. I re-downloaded it twice, but I had the same issue.

• Operating system: macOS Catalina, version 10.15
• Orange version: 3.27
• How you installed Orange: from the website

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.

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.

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).

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.

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).

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'

System specs

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

Expected behavior

Quick Menu loads instantly upon right-click on canvas (also when loading for the first time).

Actual behavior

When the quick menu is loaded for the first time, it takes about 2-3 seconds. Afterward, it opens instantly.

Steps to reproduce the behavior

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?

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:

• the canvas, in which the main window runs,
• the widgets, in which widget windows and computation run.

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.

Concept image:

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 :)

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?

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
-------------------------------------------------------------------------------

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?

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.

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.

In the orangecanvas/application/application.py,
self.__in_exec = True
What is the effect? After this modification, the following try - finally will be changed to false

• What's your use case?

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.

• What's your proposed solution?

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.

• Are there any alternative solutions?
  I guess the alternative is to leave it as it is :-)

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.

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

and when you have have orange it is done like this

https://github.com/biolab/orange-widget-base/blob/dd3e3eab3b040ef5f57125847093c6d701450e1c/orangewidget/workflow/discovery.py#L5-L10

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?

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: ()

• Operating system: Ubuntu 20.04
• Orange canvas version: 0.1.19
• Orange version: 3.28.0
• How you installed Orange: pip

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?

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).

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.

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

#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?

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.

Expected behavior

Add-ons that can be installed, get installed on Orange.

Actual behavior

When one add-on installation fails, the add-on window closes and none of the checked add-ons after the failing one gets installed.

Steps to reproduce the behavior

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.

Additional info (worksheets, data, screenshots, ...)

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?

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:

• All categories at the sidebar are hidden (This is already possible via the settings).
• The workflow can no longer be changed (add and delete widgets and connections)
• Single selected widgets can still be configured, e.g. File Import.

Proposed realization:

• You can save a workflow as "locked" or "restricted" (Using the save as dialog).
• A new dialog appears, which lists all widgets of the workflow together with a checkbox. This can be used to set which widgets should remain configurable.
• This gives the .ows file a flag that the workflow is locked and each widget a flag if it is still configurable.
• When such a workflow is opened, Orange behaves as described above.

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.

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:

• Prevent pip installations into conda environment, except when explicitly allowed (perhaps a setting among the global settings).
• A dialog suggesting adding the conda-forge environment into available channels and that would add if the user agrees.
• Display (and install) versions as available on the current channels. After installation of the newest available version, perhaps show an indication that there exist newer versions on currently unavailable channels, and make some instructions on fixing that available.

@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.

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.

Add-on dialogue in v 3.23.1

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.

Orange opens reload prompt ("Restore unsaved changes from crash?") on new workspace for no reason.

To reproduce:

1. Open Orange and place a widget on the canvas. Don't save anything.
2. Open a new workspace. It tries to reload a 'crashed' workflow, even where none exist.

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.

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.

The "Selected Data -> Data" text is broken in many ways.

OS: Windows10
Orange version: 3.28.0

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.

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.

Steps to reproduce the behavior

Create an addon that does below

import sys
sys.stdout.encoding

Run addon block in Orange and should throw an attribute error.

Proposed Fix

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

I believe this is related to #154. :(

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

  • checks if one of input or output connection lines is almost horizontal (this does not mean that the corresponding widgets are aligned, because there may be multiple connections, so they are not vertically centered with the widget). If so, it snaps the widget position so that line is horizontal.
  • If there are no such lines, it checks whether there is a widget with a similar y coordinate and snaps to 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. :)

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.

This issue is important for scOrange and Quasar. If I update any add-on Orange asks for a restart. In the message window, it naturally refers to itself as "Orange", however for the users of scOrange and Quasar this could be slightly confusing.

Suggestion: handle the application name dynamically.

• What's wrong?

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.

• How can we reproduce the problem?

Create some workflows with File→New, then select Window. It should (in my opinion) list the workflow windows just created. it does not.

• What's your environment?

• Operating system: macOS 11.1
• Orange version: 3.27.1
• How you installed Orange: Disk image downloaded from https://download.biolab.si/download/files/Orange3-3.27.1-Python3.7.6.dmg