dimitar-asenov / envision Goto Github PK

There should be a generic mechanism that allows plug-ins to register custom callbacks to the handlers of particular object types, without having to reimplement the handler. An ad hoc solution in HStatement::registerKeyPressHandler is already used by the debugger framework to watch for key shortcuts that register breakpoints, etc. This should be generalized to all handler types.

This is an interesting construct from a visualization perspective. It is also used in many projects, including jEdit, which we want to experiment with.

In Envision a program is not a piece of text but rather a tree structure called a model. This is similar to a traditional AST but has some differences:

• Envision's tree model does not use predefined programming constructs. It is extensible by the user. This means that arbitrary new nodes can be attached as children to any other nodes.
• It should provide a natural interface. User should be able to call methods normally on an object, such as method.getReturnType() instead of (ReturnType) method.returnChild("returnType")
• The tree should be easy to use and navigate. This should happen in a natural way: e.g. method.getReturnType() as opposed to (ReturnType) method.getChildByName("returnType")
• The model is meant to contain not only the "parsed" source code of an application but also all its supporting software engineering artifacts. This includes things like graphs, tables, images, comments, etc.

Envision currently implements an application model that (at least in theory) supports the following features

• interaction with a persistent store
• ability to partially load a project (this needs a better design)
• concurrent access to the tree structure (not really in use right now, so we have no experience with how it performs)
• undo stack
• extensibility with new node types (there might be a better way of doing this)
• node references (this could also use some more work)

As one can see above there are some things which need to be improved and some additional requirements

• Partial loading. It is crucial that a developer is able to open only a part of huge project. A part can be a class or several classes. Currently a project in the model consists of all artifacts associated with it: classes, modules, library specifications, methods, and so on. When a project is opened some nodes are only partially loaded, that means that some of their child nodes are not read. This mechanism might not scale very well. The original idea is that the model will be also be used to resolve links. A more traditional alternative might be to keep a separate data structure that keeps an index of all symbols and the model consists of independently loadable parts (such as classes). The pros cons need to be investigated better.
• Concurrent access. The current mechanism is OK, but since it is not well tested we need to have it mind when changing the model.
• Reference Resolution. This is connected to partial loading. More thought needs to be put in how we can resolve references. This will need a special interface with the persistent store mechanism when we need to resolve references which point to something that is not loaded.
• Usability and Extensibility. It is important that we have a second look at the current design for implementing tree nodes. Currently this is done directly in the source code. This might be very efficient but it is some times not convenient.
• Visitor pattern. As embarrassing as this is, I have designed a tree structure that does not implement the visitor pattern. This gets a bit tricky when dealing with arbitrary node types but there are some versions of the pattern that deal with this. In the end such a functionality must be implemented somehow.
• Additional Information. An additional important feature that is missing is the ability to attach extra information to a tree node. Ideally this extra information would itself just be another tree node that can have arbitrary structure. This is meant to be used to record analysis information with the program. So the output of various semantic analyses can be attached to corresponding nodes: errors, profiler measurements, etc. Having this information as part of the model might simplify visualization.
• Content linking. Having many different types of artifacts in the same model, it will be useful to implements link between them. Such as a link between a comment and a method, or a link between a table cell and value in the program. This is also a big separate topic, but needs to be considered when thinking about the way referencing of nodes will work.

The more interesting parts of the current model are described in my master thesis here: http://www.pm.inf.ethz.ch/education/theses/student_docs/Asenov_Dimitar/dimitar_asenov_MA_report
The corresponding source code is in the ModelBase directory and is one of the better commented parts of Envision.

Using delete and backspace after the end of the final parenthesis in typeid(something) results in weird behavior or crashes. It seems that NodeWrapper needs to override regions() and return extra cursors if specified.

The current name of this class is somewhat ambiguous. Perhaps better names are:

• SymbolName
• SymbolReference
• SymbolBinding

This will also have an effect on other Nodes/Visualizations that derive their name from Reference.

See the attached whiteboard photo for some details on the issue + pointers to a solution.

When using auto either -> or . should be used in subsequent code visualizations based on what the auto types evaluates to.

After this either -> or . should be used based on the language (Java/C++).

At the moment the space key is an integral part of expressions, but users often type space in places where it is not strictly necessary in traditional languages, in order to just improve readability. In Envision this causes the parsed expression to include the additional space tokens as errors.

We should find a way to detect these situations and possibly remove the extraneous space characters automatically. The ultimate goal is to allow the user to type code as they are used to and not worry about having too many spaces.

At the moment, each command that is added to the undo stack, stands on its own, even if it can be easily merged with the previous one (e.g. typing each letter of an identifier). This wastes memory and, what's worse, provides for a bad user experience as they have to repeatedly perform an undo even to revert simple actions.

We need a class that behaves similarly to the current List family, but is able to provide a view of itself that looks like a list but is limited to only some elements from the list. For example it will be better to have a single list of Declaration objects in Class which can be viewed for convenience as a list of methods or a list of inner classes, etc. Such a view should still allow iteration, modification and reads.

After recently uploading Envision, there is still a lot to do before others can get started with this. Most importantly there needs to be some more documentation on-line.

Instead of using long/double for number literals, we should use a string that is able to hold arbitrary text in any precision or format that can be converted to a number on demand.

For example, when making screen shots saved as SVG or PDF, having vector icons is preferable.

Optimize expression edits by assimilating letters directly in identifiers. This remove the necessity to run the full parser and identifier edits are very common so it will have quite an effect. We should however watch out for keywords and still run the parser if we detect any.

Hi,
I have been trying to compile envision.I keep getting this error -->>
CMake Error at /home/vmur/Qt5.11.2/5.11.2/gcc_64/lib/cmake/Qt5/Qt5Config.cmake:28 (find_package):
Could not find a package configuration file provided by "Qt5WebKitWidgets"
with any of the following names:

Qt5WebKitWidgetsConfig.cmake
qt5webkitwidgets-config.cmake

Add the installation prefix of "Qt5WebKitWidgets" to CMAKE_PREFIX_PATH or
set "Qt5WebKitWidgets_DIR" to a directory containing one of the above
files. If "Qt5WebKitWidgets" provides a separate development package or
SDK, be sure it has been installed.
Call Stack (most recent call first):
VisualizationBase/CMakeLists.txt:268 (find_package)

I do have the qt sources installed on my system plus Qt5WebKitWidgets.
Can you help me out please.
Thanks

I have simple program where I have the following line:
int[] foo=new int[10]
when I now edit the 10, e.g. delete the zero the parser fails to parse it correctly.
The tokenizer generates the following tokens:
int, [], foo, =, new, int, [, 1, ]
if you tell me where to look, I will try to fix it.

Steps to reproduce:

• Open a simple Java helloworld example
• add a second line with some none sense that triggers a compiler error (e.g. sd)
• Run the program (ESC, type: run, hit enter)
• The compiler MessageOverlay will appear
• Now start to hit Backspace and Envision will crash.

The crash happens in MessageOverlay::updateGeometry() in the call setPos(..)

Only the styles inside OOVisualization should need conversion as everything else has been modified already.

Visualizations of references are not refreshed after the references have been resolved, and so the text remains red incorrectly.

All instances should be updated, but I don't know what to.

At the moment there are a number of classes used to define operators for expressions and many of these classes share a lot of functionality which should be unified. This also includes visualizations.

For example, for make all visualizations inherit from a configuration template, which in turn directly inherits from Super<Item>. The template is a thin wrapper on top that just exports the new visualization's style, node, and top-level class as types. This will make a lot of things simpler when declaring objects.

A problem might be inheriting visualizations (e.g. in TextRenderer) where multiple configurations are needed throughout the hierarchy. This needs to be investigated.

This is a standard feature of text editors and is very useful when searching for stuff. We could use highlights or even arrows from the currently selected symbol.

In some situations it is possible to perform an automatic merge and get inconsistent results. For example, if two methods have been added to the same class at the same location, but in two different versions. Currently they will not conflict and will be merged automatically even though they have the same (x,y) coordinates in the visual representation of the class grid.

There needs to be a way to detect and remedy this situation. In the particular case above the position in the grid should just be adjusted. In general the version control framework should be extensible with hooks to deal with such situations.

Steps to reproduce:

1. open a project with no git repository
2. open command prompt (ESC)
3. enter the letter d

Actual Behavior:
Exception is thrown because there is no repository

Expected Behavior:
No exception, as no repository is found no additional suggestions to diff command

Stacktrace:
0 FilePersistence::GitRepository::checkError GitRepository.cpp 1147 0x7fffda7c15bb
1 FilePersistence::GitRepository::GitRepository GitRepository.cpp 159 0x7fffda7c144e
2 Interaction::CDiff::possibleNames CDiff.cpp 258 0x7fffd84a7150
3 Interaction::CommandWithFlags::matchingNames CommandWithFlags.cpp 190 0x7fffd8460be7
4 Interaction::CommandWithFlags::suggestNamed CommandWithFlags.cpp 110 0x7fffd84612ff
5 Interaction::CommandWithFlags::suggest CommandWithFlags.cpp 87 0x7fffd8460f22
6 Interaction::CommandExecutionEngine::suggestionsForHandler CommandExecutionEngine.cpp 194 0x7fffd84a16b0
7 Interaction::CommandExecutionEngine::autoComplete CommandExecutionEngine.cpp 165 0x7fffd84a10d8
8 Interaction::CommandPrompt::determineChildren CommandPrompt.cpp 170 0x7fffd849e1a0
9 Visualization::Item::updateSubtree Item.cpp 255 0x7fffd8ab746c
10 Visualization::Scene::updateNow Scene.cpp 189 0x7fffd8acdb3d
11 Visualization::Scene::event Scene.cpp 327 0x7fffd8acf00c
12 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x7ffff727500c
13 QApplication::notify(QObject *, QEvent *) 0x7ffff727a4e6
14 Core::EnvisionApplication::notify EnvisionApplication.cpp 72 0x7ffff79b9546
15 QCoreApplication::notifyInternal(QObject *, QEvent *) 0x7ffff653b89b
16 QGraphicsView::keyPressEvent(QKeyEvent *) 0x7ffff75c8158
17 Visualization::MainView::event MainView.cpp 70 0x7fffd8aad392
18 QApplicationPrivate::notify_helper(QObject *, QEvent *) 0x7ffff727500c
19 QApplication::notify(QObject *, QEvent *) 0x7ffff727c0d3
...

Suggested fix:
Instead of trying to create a GitRepository object in CDiff 258 add a static function in GitRepository to check if there is a git repository and only if so create the actual object.
But I leave that for someone else to fix as I don't know the details of this code.

In some cases, a Qt item will gain focus even though the Envision even handling functions were not called or did not properly handle the focus.

For example:

• Start OOVisualization
• Click to the right of aLongTestMethod. This should result in a thick, long vertical cursor.
• Click under the field box of class Generic, to the left of the class outline.
• Either the field box or the entire class is selected. In both cases however the thick cursor in class HelloWorld remains, whereas it should disappear.

Tried compiling the ide on my work laptop and 95% towards the end of compilation i get
qtwebkitwidgets/qgraphicswebview:no such file or directory.I happen to have everything installed as per the instructions.So far i've added the location of the file in my profile to no avail.Any suggestions?thanks

When you create a new method you can type your arguments but for the type Envision does not accept [] brackets at the end of the type. This is annoying as one can not write a java main method like this.

The different elements in DynamicGridFormElement are all rendered on the same background and without any separators. We could make the elements more distinguishable by some combination of:

• including separator symbols
• drawing border lines
• using different background colors

During parsing, there are multiple vectors created that hold elements of type ExpressionTreeBuildInstruction*, including the one in ParseResult. These are not properly deleted.

Not much else to add

When growing a child object positioned using GridLayouter, the grid will be enlarged with every edit, which causes all other items in the grid to be potentially updated and redrawn.

To reduce the frequency of this costly operation, we could introduce a granularity to GridLayouter. It's size could be a multiple of the granularity which will buffer some of the size changes of child elements. To simplify the API the granularity could be determined based on the space between columns/rows.

This should be something similar to List. It should make it easy to define, store, and load enumeration fields in nodes. There are already a few use cases that should be consulted in the design:

• Class:cKind
• BinaryOperation::opr
• etc.

At the moment, when an expression is edited, its nodes are recreated after every parse. In most cases the new expressions is only minimally different than the old one, and it is desirable to keep the existing nodes, instead of creating new ones. This will help with associating data with expression nodes (i.e. comments).

One approach might be to create the tree corresponding to the new expression and then scan for similarities and only merge the differences.

Currently, all children of an item are always rendered and they are visible in their entirety.

In some cases (e.g. the output console in ConsoleOverlay) we need a way to only show a subset of the children - a way to scroll the contents.

It doesn't seem like macros are really needed there. If this works out, we can completely remove the definitions of the FLUENT_LAYOUT macros.

The current name does not accurately reflect all the uses of this node