Domain specific languages are a great tool when we want to give our users control over complex aspects in our applications; and in most cases, experienced uses can learn syntax and semantics of a well-designed DSL quickly. But on the other hand, there are also inexperienced users, who usually struggle with DSLs and do not want to deal with textual input. Instead, they are used to graphical user interfaces which help them to grasp the structure of information and to enter new data.
Last week, I had a project, in which I needed to provide both groups of users with a suitable user interface. In other words, I needed to create an editor, which provides both an Xtext source editor for my DSL, and a GUI editor for the model behind the DSL.
I started to search the Internet for some hints on how to do this but I did not find a complete example. Basically, to combine multiple editors into a single one, we have to subclass and implement an org.eclipse.ui.part.MultiPageEditorPart. But I did not find more than hints about how to share the model between an Xtext editor and another editor. So, I started experimenting and after some time I was successful, and I wanted to let you participate in my results. Maybe this helps someone who is looking for an example as well.
For the rest of this post, I will use the state machine example that comes with the Xtext distribution as a starting point. To demonstrate the solution I will add a GUI editor for events to the generated Xtext editor. For brevity, I will only show the relevant parts. The full modified example source code is available on GitHub.
Sometimes I need to test something in a VM which has an independent system time. Usually, this has to do with server applications which react time-based (think of a system in which users may enter information until a certain day is reached, after which only read-only is allowed).
On a standard installation of VirtualBox and Ubuntu 16.04, the system time is automatically synced to the host. When trying to change the date using date -s 2015-01-01 the date will be updated but will revert to the host's date after a few seconds.
Since I end up googling the correct way to disable the time synchronization in an Ubuntu VirtualBox client every time I set up my VM from scratch, I am posting the steps here as my personal reminder (it is always nice to get one's own article in a google result because one has forgotten ;)) - and maybe someone else also finds this useful:
VBoxManage setextradata "vm-name" "VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled" 1/opt/VBoxGuestAdditions-5.1.2/init/vboxadd-service and in start() replacedaemon $binary --pidfile $PIDFILE > /dev/nulldaemon $binary --disable-timesync --pidfile $PIDFILE > /dev/null
daemon() and add the fourth argumentif which start-stop-daemon >/dev/null 2>&1; then
daemon() {
start-stop-daemon --start --exec $1 -- $2 $3 $4
}
...
Just to be sure, remove the Ubuntu timesyncd as well:
On the client, execute:rm /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service
Reboot and from now on, changed system dates stay as intended.
BTW, I would like to be able to decouple the system time in docker as well, but from my understanding this is not possible because docker uses the host RTC directly and the only way to differ here is to set a different timezone, which has its limitations. But if someone knows a way to simulate a different system time in docker, I would love to hear about it!
Today was not the first time, I made a common mistake with NatTable layers. And since it always takes a few minutes until I identify the problem, I'll post it here (as note to myself and maybe because it is helpful for anyone else ...).
The symptom is that when scrolling in a NatTable, it is not–or not only–the NatTable which is scrolling, but each cell seems to be dislocated in itself, leading to this:
The problem lies in my misinterpretation of the constructor JavaDoc of ColumnHeaderLayer (or RowHeaderLayer), which states for the second argument:
horizontalLayerDependency – The layer to link the horizontal dimension to, typically the body layer
It turns out, that I usually confuse the body data layer with the body layer. For my typical tables, the main part of the table is composed of the body data layer, the selection layer, and the viewport layer on top.
The image shown above is usually the result of giving the body data layer as the horizontalLayerDependency parameter instead of the viewport layer (which is correct, because the viewport layer (as the topmost layer of the body layer stack) plays the role of the body layer in the sense of the ColumnHeaderLayer constructor's horizontal layer dependency).
So, should you ever encounter the above symptom, check your ColumnHeaderLayer and RowHeaderLayer constructor for the correct layer arguments.
I am currently working for a customer on an existing Eclipse RCP (based on Luna) which consists of 99% Eclipse 3.x API. The customer wants to migrate to E4 gradually, but there is no budget to migrate existing code all at once. Instead, the plan is to start using e4 with new features and migrate the other code step by step.
So, when I was given the task of creating a new view, I wanted to use the "new" (in Luna, anyways) e4view element for the org.eclipse.ui.views extension point. The good thing about this is that you can easily write JUnit tests for the new class because it is a POJO and does not have many dependencies.
My problem is that part of the customer's RCP uses Xtext and several components or "services" (not actual services in an OSGi sense) are available via Guice.
So I was confronted with the requirement to get a dependency available via Guice injected in an E4-style view implementation:
public class MyViewPart
{
@Inject // <- should be injected via Guice
ISomeCustomComponent component;
@PostConstruct // <- should be called and injected via E4 DI
public void createView(Composite parent)
{
// ...
}
}