Hard to enter a network connection in new Studio dialog box

[FrancescoMondada]

With build 459 on MACOSX, a standard user need documentation to connect to a distant place by TCP. The previous interface had a predefined box for TCP allowing to enter the port, without worrying for the full command. Now the distant connection requires to enter the full line and this require to look for documentation, which is a barrier to access. I suggest to have at least a menu of predefined connections for the common types of connections.

[stephanemagnenat]

Zeroconf resolves the problem for targets in the local network. With the new dialogue box, targets on global Internet must be entered by hand, which is only arguably more difficult than filling the old network entry, as anyway these targets should be provided by the remote host, as they cannot be discovered. So one could even argue that copy/pasting a single line is easier than copy pasting the host plus the port.

But the proper user-friendly solution is to implement a global target server, see #701. I am closing this issue and let the discussion continue there.

[FrancescoMondada]

with the old interface, one can provide IP number and port, and the user can enter them easily. Not with the new interface. Copy-paste of a whole line is simpler but reduces the understanding of what is going on.

[marvelous]

I guess a combo box pre-filled with common dashel target patterns or even a simple label with those would alleviate this problem a lot.

[marvelous]

If the underlying issue is how to distribute the connection string to others, why not have aseba: clickable links that open aseba studio?

[davidjsherman]

We have had this discussion before. See the archives for the aseba-thymio mailing list, message 484 on 2016-08-08T12:34 for example (paragraph 5 talks about Universal Links, which are the preferred technology on iOS).

[stephanemagnenat]

@marvelous, do you know how to register the aseba: protocol on the different systems? We could also have thymiovpl: that would opens the standalone application.

[davidjsherman]

You don't do it that way on iOS, you need to use Universal Links on the web page

[stephanemagnenat]

Yes but for other systems? I see the interest of universal links, but I think it's a lot of work to solve our basic problem. Also, it looks like an Apple-specific approach. The need of @FrancescoMondada is currently desktop platforms.

[davidjsherman]

Windows 10L https://docs.microsoft.com/en-us/windows/uwp/launch-resume/handle-uri-activation
macOS https://developer.apple.com/library/content/documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html#//apple_ref/doc/uid/20001431-102207

[stephanemagnenat]

Commit 5e8c1ec adds a link to the documentation of Dashel targets in the dialogue box.

[FrancescoMondada]

Tested with the solution of the doc, frankly speaking this is not acceptable for standard users. Reading the doc and extracting the information is a real obstacle in comparison with the click we had before. I liked the option suggested by @marvelous why not implementing this? We can contribute to implementation, if this helps.

[stephanemagnenat]

Tested with the solution of the doc, frankly speaking this is not acceptable for standard users

What specific problem do you try to solve? If it is to connect to a switch, this will be solved once issue #679 is implemented. If it is to connect to a remote location online, for example for R2T2, why is copying the target line a problem?

That said, I think that the idea of @marvelous is good, although the point raised by @davidjsherman is also relevant. However, we are now focusing the efforts in releasing 1.6 as soon as possible, and adding this is not in the critical path if it is a temporary problem due to #679 not being implemented yet.

[FrancescoMondada]

We have both issues:

• connect to a remote location (regular R2T2 events, soon also from ETHZ)
• connect locally to a switch

Concerning the copy-paste option: it is different to copy a link without understanding it and enter data that makes sense. It happened to me, during R2T2, to write on the white board the IP for all groups and list (also on the white board) which port is assigned to which group. Each group understands what we are doing, enters the data and we are done. No need to distribute an electronic document and request to make blind copy-paste. No need to ask to enter a complex line of code that scares everybody. Complexifying the process with a specific syntax does not bring anything. Why removing the options we had until now? For me the goal should be to make the life of the users easier, and not more complex. This is well achieved with the new discovery functions, but the choice of removing the others options without replacing them with a similar solution is for me a wrong choice.

I agree about the priority to issue 1.6, but leaving this situation unresolved during the 1.6 version life means that we will just decrease the user experience of a set of users, the ones we are working with.

[stephanemagnenat]

Thank you for the detailed description, I understand more your problem now. As #679 will be implemented by 1.6 release, only the remote connection problem remains.

In that sense, I also suggest to implement, in a first step, the solution that @marvelous proposed, that is, to support the aseba: target. Note that it is purely a packaging issue, as already currently opening Studio or VPL with a command line target will attempt to connect to this target.

Help in implementation is of course warmly welcome, and I'll be glad to review pull requests related to that question, I am also available by Skype to discuss it if it is helpful.

[FrancescoMondada]

The actual interface is listing all serial ports of the machine, also those where no thymio is connected; they are all listed in the box called "Discovered targets". Is this normal? Will this be "corrected", listing only the existing targets? If not, can we add another "fake" target which is a tcp connection?

[stephanemagnenat]

Indeed the listing of all serial ports is annoying, especially on Linux because there are a lot of "virtual" serial ports. The reason is simple: this box is generic and cannot know whether a given port is a valid Aseba target or not without opening it, and opening third-party devices whose protocol is unknown is dangerous. That is a limitation of old protocols such as serial connections. In Aseba, a target is a network, not a single node.

To improve the usability, as discussed in #694, we plan to have a specialised connection box in the Thymio launcher (and we could have it also in VPL standalone) that allows to filter these and only show Thymio targets, both for serial and internet connections (zeroconf reports the productId of nodes in the target network). In general, we will make the Thymio launcher the natural entry point for all Thymio-related activities. That should provide a smooth connection path for Thymio users.

[FrancescoMondada]

My question was (also): can we add to this list examples of connections that could be used as templates?

[mbonani]

To go forward with this issue here is the status discussed with @stephanemagnenat. For 1.6 release the actual line is sufficient to make technically all case work as #679 will be implemented . The command line also accepts simplification like tcp:toto.epfl.ch;33333 that could be easy to explain to R2T2 users. Actually when this dialogues opens, the last connexion is shown; instead, we could by default make an example like "tcp:IP address;port=33333"

Later, this dialogue box could be improved in different ways.

• combo box pre-filled like @marvelous suggest (probably not supported in Qt4.8, to be invested?)
• instead of the link to the help open a popup windows that makes a better help on the Dashel targets with examples and translation, it is agreed that the actual help is for a technical-minded person.
• open a popup windows that allows to select either serial or network, and in that case to enter the host and the port individually.

The improvement could be made also after the release 1.6 and added to it.

[FrancescoMondada]

OK, let chose one option on which everybody agrees.

The default line could be a simple solution. The "last connection", as there is a discovery mechanism, does not bring a lot. Do we agree this could be an acceptable solution?

[stephanemagnenat]

The "last connection", as there is a discovery mechanism, does not bring a lot.

Yes I agree, we could disable it for now, and use a default tcp entry. For example: tcp:HOST;port=33333.

[stephanemagnenat]

Commit 423da89 implements this approach.

[mbonani]

I agree