eclipse indigo - windowbuilder - eclipse doesn't regain focus - linux

I have eclipse 3.7 indigo; I installed gwt plugin and its designer; The problem is (time after time) when I add new widget X to composite the
palette (keeps widget selected)
components (doesn't show the new widget in the tree)
properties (doesn't show the new widget properties)
...so I cannot select another widget unless I resize the whole eclipse application to force its GUI repaint :(
It seems like palette and other managers don't get report "widget was added from windowbuilder" or similar :(
Moreover, I cannot edit widget's text if I have input method as "System" which is the default on btw so the only one input method which works is "X Input Method" but anyways it doesn't solve the mentioned focus regain problem;
That makes eclipse indigo really hard to use; So my question is... how to fix that?
p.s.
eclipse 3.7 (indigo)
gwt plugin - https://dl.google.com/eclipse/plugin/archive/3.6.0/3.7
gwt designer - http://dl.google.com/eclipse/inst/d2gwt/latest/3.7
gwt sdk 2.2
jdk 1.7
jre 1.7
OS Linux x64
Thanks

I had to do my own research concerning the issue; I noticed there is some kind of "jobs order conflict" or similar with the default constructor based code style as :
public class MyTestUI extends Composite {
private FlowPanel flowPanel;
public MyTestUI() {
flowPanel = new FlowPanel();
initWidget(flowPanel);
}
}
...so, as a workaround, I had to play with code generator as;
window -> preferences -> windowbuilder -> gwt
(combobox) method name for new statements : initComponents
variable generation : field
statement generation : flat
just to avoid having in-constructor init as a result I have code generated as :
public class MyTestUI extends Composite {
private FlowPanel flowPanel;
public MyTestUI() {
initComponents();
}
private void initComponents() {
flowPanel = new FlowPanel();
initWidget(flowPanel);
}
}
...btw there is a problem with focus regain if input method is "System" and initComponents() method generated first time; so before starting adding widgets I had to select "X input method" to avoid synch-ed jobs; So "X input method" needs to be the default one, as I can get it :)
EDIT :
The effect I faced very looks like bug 388170; So I tried to modify eclipse.ini argument as
-Djava.awt.headless=true
It seems like the headless helps a bit but anyways eclipse sometimes does hang when using windowbuilder especially DnD :P
Anyways I want to point I faced the mentioned issue first time cause similar windows x32 eclipse indigo version works pretty fine with gwt;
p.s.
The solution is not final (the hang problem still occurs on DnD evens) and I am still looking for a more optimal one; So do comment if you have some helpful tips or ideas;

Related

vaadin 7: layout displaced after opening/closing dialog window

I am new to the forum and to programming so hopefully I give you enough details and precise information needed to understand my question.
I am working with vaadin 7 in java EE web aplication and I have a layout problem/phanomena that I cannot explain and I could not find a solution on the net. Basically, when I start the server and test my application on localhost everything looks right. When I open a dialogue window and close it again, the layout of the site looks displaced. I could not find a pattern as to which click causes this effect. Sometimes it happens also when I only change a view. This is how it should look like and this is how it does look like after working in the application.
I looked through the devloper tool in the browser and noticed that in the working html, the attributes "top" and "left" are set for the gridlayout-slot. In the displaced layout these attributes are not set. Furthermore, it seems that the problem occurs more often in chrome. It does also happen in firefox but less often.
I use VerticalLayout, GridLayout and FormLayout.
Did you have similar experience? I am wondering how and when the html files are generated from the vaadin code to find out why they change and how I can fix it.
I am not sure which code exactly is causing the problem, so I am not sure what to post. If you have an idea where to look, I can add more code. Here is how the Dialog is set up:
public class Dialog extends Window implements ClickListener
public Dialog(CustomController controller, String title)
{
super(title);
setModal(true);
setStyleName("dialogWindow");
this.controller = controller;
setWidth("65.0%");
setHeight("90.0%");
// top level component properties
panLayout = new GridLayout();
panLayout.setWidth("100%");
panLayout.setHeight("100%");
buildPanToolbar();
panLayout.addComponent(panToolbar);
buildPanTop();
panLayout.addComponent(panTop);
buildPanTabs();
panLayout.addComponent(tabsheet);
panLayout.setComponentAlignment(tabsheet, Alignment.MIDDLE_CENTER);
panLayout.setRowExpandRatio(2, 1.0f);
tfThema.focus();
setContent(panLayout);
}
The buildSomething() functions are all a combination of GridLayout, FormLayout, HorizontalLayout and VerticalLayout. Below is the buildPanToolbar() function as an example
private void buildPanToolbar()
{
panToolbar = new HorizontalLayout();
panToolbar.setImmediate(false);
panToolbar.setWidth("100%");
panToolbar.setHeight("25px");
panToolbar.setMargin(false);
panToolbar.setSpacing(true);
panToolbar.setStyleName("toolbar");
HorizontalLayout panHelpToolbar = new HorizontalLayout();
panHelpToolbar.setImmediate(false);
panHelpToolbar.setWidth("-1px");
panHelpToolbar.setHeight("25px");
panHelpToolbar.setMargin(false);
panHelpToolbar.setSpacing(true);
panHelpToolbar.setStyleName("toolbarButtons");
panToolbar.addComponent(panHelpToolbar);
pbButton1 = new Button();
pbButton1.setCaption("Button1Text");
pbButton1.setStyleName(BaseTheme.BUTTON_LINK);
pbButton1.setImmediate(true);
pbButton1.setWidth("100px");
pbButton1.setHeight("-1px");
pbButton1.setIcon(new ThemeResource("../images/pic1.gif"));
pbButton1.addClickListener(controller);
panHelpToolbar.addComponent(pbButton1);
panHelpToolbar.setComponentAlignment(pbButton1, Alignment.MIDDLE_LEFT);
pbButton2= new Button();
pbButton2.setCaption("Button2 Text");
pbButton2.setImmediate(true);
pbButton2.setWidth("100%");
pbButton2.setHeight("-1px");
pbButton2.setStyleName(BaseTheme.BUTTON_LINK);
pbButton2.setIcon(new ThemeResource("../images/pic.gif"));
pbButton2.addClickListener(this);
panHelpToolbar.addComponent(pbButton2);
panHelpToolbar.setComponentAlignment(pbButton2, Alignment.MIDDLE_LEFT);
}

Want "Menu" example--Pico demo fails

In looking for a working example of "Menu" for the DSL I am writing, I tried "Pico". But the following fails:
rascal>import demo::lang::Pico::Plugin;
|plugin://rascal_eclipse/src/org/rascalmpl/eclipse/library/demo/lang/Pico/Plugin.rsc|(1791,48,<71,6>,<71,54>): The called signature: action(str, void (...)),
does not match any of the declared (overloaded) signature patterns:
Menu = action(str,void (Tree, loc))
Menu = action(str,void (str, loc))
If I comment out lines 71-73 of "Plugin.rsc" it loads successfully, but then of course I have no "Menu". Can someone point me to a fix of this (which doesn't require much Eclipse or Java expertise :) or to a different working example of "Menu"?
Thanks
My environment:
Rascal: (I don't know how to print the version, but one of the
files is
rascal_eclipse_0.7.3.201506091957.jar )
Eclipse: for RCP and RAP Developers Version: Mars Release (4.5.0)
Java: version "1.8.0_51" OS: Linux Mint 17 Qiana
Popup menus can be added as contributions to your registered language using
the popup(Menu menu) constructor. After you have created the contributions that you need call the registerContribution(..) (defined in util::IDE) function supplying the constructed Contribution data type.
For example, in Pico the contributions are defined as follows:
public set[Contribution] Pico_CONTRIBS = {
popup(
menu("Pico",[
action("Evaluate Pico program", evalPicoProgram),
action("Compile Pico to ASM", compilePicoProgram),
action("Show Control flow graph", visualizePicoProgram)
])
)
};
The signature of the evalPicoProgram, compilePicoProgram and visualizePicoProgram are
public void _name_(Tree x, loc selection) {
...
}
Eventually the contributions get registered with the following code:
registerContributions("Pico", Pico_CONTRIBS);
In the Pico example the menu that was registered contained an action constructors with a wrong type. This was indeed a bug in Rascal. The signature of the action constructor changed in the past and the Pico Plugin module was not updated accordingly.
I made the necessary changes and it should be fixed in the newest unstable version of Rascal.

Regression of IntelliJ IDEA 14 support for Spock Framework?

After upgrading from IDEA 13.1.x to 14.x (14.0.2 at the moment) I see the support for Spock Framework Mock() and Stub() methods got worse.
To be more specific, I mean in-line methods stubbing/mocking with closures like:
MyType stub = Stub {
myMethod() >> { /* do something */ }
}
IDEA 13 is aware of available methods for stubbed type, which is visible on the below screen shot.
size() method is not underlined. It can be navigated to, auto-completed, checked for possible argument types and so on - usual IDE stuff. The same is possible with any other List method inside of the 'stub closure'.
While IDEA 14 lacks this feature which really is a pity. The screen shot below shows it.
size() method is underlined and greyed out. IDE seems to not have a clue what's up.
The same applies to Mock { } method event if invoked with a type as an argument like Mock(MyType) { } (and Stub(MyType) { } respectively)
My question is - is it only me or that's a bug/regression? Or maybe I need to adjust some settings?
EDIT: seems it's a bug / regression. I raised a bug in youtrack. Up vote, please.
There is a bug in storage system, i.e. GDSL works itself, but state is inconsistent across IDE startups.
As a temporary solution:
Project View -> External Libraries -> spock-core
open org.spockframework.idea.spock.gdsl in Editor
wait until Notification about disabled GDSL comes out
use Activate link in the Notification
You should enable GDSL every time you start up your Idea.
This bug is fixed and the fix will be released asap.

Can't get LineChartBuilder to compile

I'm creating an application that uses JavaFX 2.2 and have run into a problem. I'm trying to use a LineChartBuilder, like so:
LineChart<Number, Number> chart = LineChartBuilder.<Number, Number>
create()
.XAxis(NumberAxisBuilder.create().label("X axis").build())
.YAxis(NumberAxisBuilder.create().label("Y axis").build())
.build();
However, I'm getting the following compiler errors:
java: reference to create is ambiguous, both method create() in
javafx.scene.layout.RegionBuilder and method <X,Y>create() in
javafx.scene.chart.LineChartBuilder match
and
java: cannot find symbol
symbol: method XAxis(javafx.scene.chart.NumberAxis)
location: class javafx.scene.layout.RegionBuilder<capture#1 of ?>
I know the first error means LineChartBuilder descends from RegionBuilder and both define a create() method, and the second means it's assuming the method comes from RegionBuilder and therefore cannot find the XAxis method. I've even tried casting it,
LineChart<Number, Number> chart =
((LineChartBuilder<Number, Number, ?>)
LineChartBuilder.<Number, Number>create())....
But I get the same compiler errors.
My question is, is this a mistake in LineChartBuilder or am I using it wrong? Maybe there's even a workaround?
Are you sure you are running with JavaFX 2.2 and not a JDK8 pre-release?
JDK8 will experience these issues with builders coded for JavaFX 2.2: see RT-24272.
Workaround is to use new LineChart(xaxis, yaxis). See also the Oracle forum thread post on this issue.

Java Thread Safety v Displaying a Dialog from separate Thread

Hi noticed some code in our application when I first started Java programming. I had noticed it created a dialog from a separate thread, but never batted an eye lid as it 'seemed to work'. I then wrapped this method up through my code to display dialogs.
This is as follows:
public class DialogModalVisibleThread
extends Thread {
private JDialog jDialog;
public DialogModalVisibleThread(JDialog dialog, String dialogName) {
this.setName("Set " + dialogName + " Visable");
jDialog = dialog;
}
#Override
public void run() {
jDialog.setVisible(true);
jDialog.requestFocus();
}
}
Usage:
WarnUserDifferenceDialog dialog = new WarnUserDifferenceDialog( _tableDifferenceCache.size() );
DialogModalVisibleThread dmvt = new DialogModalVisibleThread( dialog, "Warn User About Report Diffs");
dmvt.start();
Now, as far as I am now aware, you should never create or modify swing components from a separate thread. All updates must be carried out on the Event Dispatch Thread. Surely this applies to the above code?
EDT on WikiPedia
However, the above code has worked.
But lately, there have been countless repaint issues. For example, click on a JButton which then calls DialogModalVisibleThread to display a dialog. It caused buttons alongside the clicked button not to redraw properly.
The repaint problem is more frequent on my machine and not the other developers machine. The other developer has a laptop with his desktop extended onto a 21" monitor - the monitor being his main display. He is running Windows 7 with Java version 1.6.0_27.
I am running on a laptop with Windows 7 and Java version 1.6.0_24. I have 2 additional monitors with my desktop extended onto both.
In the meantime I am going to upgrade to Java 1.6 update 27.
I wondered if the above code could cause repaint problems or are there any other people out there with related paint issues?
Are there any easy ways to diagnose these problems?
Thanks
So, you're breaking a rule, having problems, and wondering if these problems could be cause by the fact that you broke the rule. The answer is Yes. Respect the rules!
To detect the violations, you might be interested by the following page: http://weblogs.java.net/blog/2006/02/16/debugging-swing-final-summary
The easiest way to check if your problems are being caused by breaking the rules is to fix them (You should fix them anyway :-)
Just use SwingWorker.invokeLater() from the thread you want to update to UI from to easily adhere to Swing's contract. Something like this should do the trick:
#Override
public void run() {
SwingUtilities.invokeLater(new Runnable() {
jDialog.setVisible(true);
jDialog.requestFocus();
}
});
}
EDIT: You should make the 'jDialog' variable final for this to work.

Resources