Matthias Schoettle

Software Engineer

Page 5 of 8

How to use OCL when running EMF standalone with Eclipse Mars

I previously explained on how to use OCL when running EMF in standalone (not as an Eclipse application). This method works until Eclipse Luna. With Eclipse Mars, OCL was heavily updated again. For instance, it was promoted out of the examples space.

The good thing is it seems to be much easier to initialize it now. Add a dependency to org.eclipse.ocl.xtext.completeocl and use the following code:

PivotStandaloneSetup.doSetup();
CompleteOCLStandaloneSetup.doSetup();

Move more than one directory into a new repository

I just realized that my previous post on how to move one directory from one repository to another really only works for one directory.

Fortunately, there is a very easy solution to that using a nice little tool called git_filter.

Basically follow the instructions of it’s README. Then, all I did was put the two directories into the filter file. It is important to note here that this file had to end with an empty line in my case, otherwise the last directory will be ignored.

You will get a new branch, which can be pushed to an empty repository:

git remote add origin_repoB <url of repo>
git push origin_repoB <localBranch>:master

It also works for one directory and is a lot faster compared to the other method.

Move directory from one repository to another, preserving history

I just moved one directory within a Git repository to a directory within another repository including its history. For example:

repositoryA/
.........../directoryToKeep
.........../otherDirectory
.........../someFile.ext

repositoryB/
.........../someStuff

The goal is to move directoryToKeep into repositoryB with its history, i.e., all commits that affect directory1. If instead, you want to create a repository just for the contents of directoryToKeep, just skip the last step of the preparation of the source repository.

If you have files tracked by git-lfs, please note the update at the bottom first.

Continue reading

Show old title bar in Thunderbird

With the latest release of Thunderbird 17, the menu bar and tabs are drawn into the title bar. On Windows XP, this then looks like the following:

New title bar in Thunderbird

In the default theme, the active title bar is blue. Thunderbird adds more stuff to the title bar which increases the blue area. This is not acceptable but fortunately this can be configured. Go to Settings > Advanced > Config Editor (in the Advanced Configuration section).

Search for the setting mail.tabs.drawInTitlebar and change the value to false (e.g., by double-clicking on it). And voilà, much better:

Restored title bar in Thunderbird

 

Modifying the “New Child” sub-menu items in EMF

I was just looking into a way to adjust the text of the items in the “New Child” (the same applies to “New Sibling” as well) sub-menu of the generated editor with EMF. By default the items just show the type name of the element to create. Depending on your meta-model it might be necessary to add some more information in order to be able to see which feature the new element gets added (or set) to.

The available items are depending on the current selected element. The collectNewChildDescriptors(Collection<Object>, Object) method is called on the item provider of this element. The actions for those menu items are created inside your ActionBarContributor class (see generateCreateChildActions(Collection<?>, ISelection)), which is located in the editor project. The text for this action is determined by CreateChildCommand.getText(), which in turn calls getCreateChildText(Object, Object, Object, Collection<?>) of the corresponding item provider. The default case is implemented in ItemProviderAdapter.

There seem to be two approaches, depending on what your goal is.

General approach: If you want to change the text independent from the element, meaning for all elements, you should change the _UI_CreateChild_text key in plugin.properties. By default this is {0}. This refers to the type name of the child. Also available are the feature text ({1}) and the type name of the owner ({2}).

Case-specific approach: If you just need to adjust it for one element, simply overwrite getCreateChildText(Object, Object, Object, Collection<?>) in the corresponding item provider and adjust it to your needs. Here is an example, that simply adds the features’ text in front of the default child text:

@Override
public String getCreateChildText(Object owner, Object feature,
        Object child, Collection<?> selection) {
    StringBuffer result = new StringBuffer();

    result.append(getFeatureText(feature));
    result.append(" ");
    result.append(super.getCreateChildText(owner, feature, child, selection));

    return result.toString();
}
« Older posts Newer posts »

© 2024 Matthias Schoettle

Theme by Anders NorenUp ↑