[Designer] Summary of bugs and feature requests

[GoogleCodeExporter]

This issue serves just to collect and discuss bugs and feature requests for the 
designer.

After some discussion I would like to have a prioritized order of the results 
in order to create a new issue for each of them.

Feel free to add your ideas!

Original issue reported on code.google.com by oliver_l...@gmx.de on 2 Nov 2013 at 10:41

[GoogleCodeExporter]

Original comment by kai.openhab on 3 Nov 2013 at 7:35

[GoogleCodeExporter]

Original comment by kai.openhab on 3 Nov 2013 at 7:35

• Changed state: Accepted

[GoogleCodeExporter]

My first remarks:
In order to identify the bugs and feature requests I assign an ID to every 
sub-issue.
Bugs:
1) sitemap language: Content assist for icon inserts the icon name without 
quotes (leads to errorneous model)

Feature requests:
2) All languages: Provide an outline view: An outline view would improve the 
clearness dramatically
3) In contrast to 2: What's the purpose of the "Items" view?
4) sitemap language: Promote a preview of the icon in content assist, hover, 
outline (if one exists)
5) items language: Content assist for choosing an icon (see sitemap language)
6) In general: the sitemap languae is much more verbose than the items 
language. The sitemap language uses key value pairs (key=value), the items 
language expects the user to know the syntax. This is inconsistent, but hard to 
change due to downward compatibility.
7) Why is the global cfg-file not based on Xtext?
8) The content assist in rules overcharges the user: In the demoproject there 
are 192 proposals (I counted them by myself!). I would call this content 
confusion instead of content assist. But how to solve this?
Some ideas (I don't like any of them, but it's a starting point):
a) Define at the beginning of a rule which items are involved. Only these items 
can be used within the rule
b) Group the items in the items language, so they can be accessed via a 
qualified name.
9) Sitemap language: Validate if the Widget fits to the item

Most of the previous issues can be solved by keeping the current architecture. 
I would like to mention some ideas which are based on a tighter coupling 
between the designer and the runtime. The advantage is that you are able to 
lead the user much better at design time. You can shift a lot of runtime errors 
to design time.
10) Items language: Provide content assist for the available bindings 
(installed in the runtime)
11) Items language: Provide helpful content assist for configuring the items. 
Just an example for the HttpBinding:
Number Weather_Temperature      "Outside Temperature [%.1f °C]"    <temperature> 
(Weather_Chart) { http: 
url="http://weather.yahooapis.com/forecastrss?w=638242&u=c" interval=60000 
xslt="yahoo_weather_temperature.xsl" }
This should be much easier to read and you can lead the users which kind of 
information the binding expects.
12) Items language: Validate if the binding and the item type fits to each other
13) After using Xtext for defining the global config (.cfg) you can benefit 
from the same possibilities as mentioned in issue 11.

This is just a short abstract of the capabilities you get, if you provide some 
more information of the runtime for using in the designer. 

Please add your comments. Remember that this is just a starting point. It took 
me one hour to write down my ideas, so don't expect this to be a solution ;-)

Original comment by oliver_l...@gmx.de on 4 Nov 2013 at 9:12

[GoogleCodeExporter]

As we already discussed at EclipseCon Europe 2013 my suggestions on improving 
the Designer will focus on RCP stuff:
Add new functionality:
- link button to link editor to "Configurations" tree view
- save / save all buttons
- menu button to get the file history
- remove unused preferences from the preferences view
- remove unused commands from the context menu
- add "new file" commands
- load new / changed files
- multiple projects for "Configurations" view
- wizard for adding a new configurations project
- upload configuration command to upload the configuration to the openHAB 
server, using a  REST service
- new "Browser View" based on javaFX webView (webkit based, needs java7u2x?)

Maybe try to publish in mac app store (?)

Switch to eclipse4 with compatibility layer for the xtext editors, which means 
that the current "Configurations view" has to be reimplemented, because it uses 
the "common navigator framework", which is not yet ported to e4.

I would suggest that I will try to implement a prototype based on e4.

What do you think?

Regards,
Theo

Original comment by theo.weiss@gmail.com on 27 Nov 2013 at 7:24

[GoogleCodeExporter]

This sound reasonable to me.
I think there are two main topics we have to discuss (and solve):
1. Improving the UX of the designer (buttons, preferences, wizards, dsl 
assistence,...)
2. Connection to openHAB runtime/server (file based?, REST based?,....)

The first issue can be solved without influencing the runtime, but the second 
one highly involves the runtime and so it's harder to solve imho.

Btw. why is this issue not migrated to github?

Original comment by oliver_l...@gmx.de on 28 Nov 2013 at 7:26

[GoogleCodeExporter]

> Btw. why is this issue not migrated to github?

Because it concerns the code that goes to Eclipse SmartHome, so this issue will 
be migrated to BugZilla soon!

Original comment by kai.openhab on 28 Nov 2013 at 3:19

[GoogleCodeExporter]

RCP UX features have been moved to 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=423500.
The REST-connection feature has been moved to 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=423501.

Original comment by kai.openhab on 7 Dec 2013 at 8:37

• Changed state: Invalid