-
Notifications
You must be signed in to change notification settings - Fork 52
Bugzilla ‐ GEF
Created attachment 265363 Two entries - upper is a broken one, and the lower is regular letters only entry.
My custom entries of a palette may contain letters and special symbols. The strings are properly shortened with ellipsis when they consist of letters only. If I type in a string with such $%^&* symbols, it is not shortened.
Drawers icons should probably look like folders or maybe a "drawer". Then an opened and closed version.
Add functionality to facilitate the creation of editors such as Wordpad, Powerpoint, etc. See: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/gef- home/team/wysiwyg.html?cvsroot=Tools_Project
Populate the edge list with an edge that has source and target node the same.
Call "visit" on DirectGraphLayout.
Result:
- Endless loop.
Expected:
- Should throw an exception instead.
The delete action in the toolbar doesnt have hover help on it. Other actions in all languages should be checked also.
Version 1.0.2
Please could we have a preference flag for the animation when different headings in the palette toolbar are selected (the "exploding" effect).
I find it distracting.
If the palette is a common UI control, perhaps this should be a global setting.
For bonus points, make it default to choosing the same on/off state as the visual effects settings. To find it under MS-Windows, right-click the desktop, select the effects tab, and unclick "use transition effects for menus and tooltips".
The toggle grid and ruler commands(and other GEF specific commands) cannot be shown in the right click menu of the editor. However the ZoomIN and Zoom Out are shown. The reason seems to be because only two extensions (i:e zoom in and zoom out ) are made to "org.eclipse.ui.commands" in the GEF plugin. Which fails to add any other command id (like toogle_ruler_visibility etc.) to the command definitions in the registry while initial extension processing during loading. PATCH:
Add more extensions for respective GEF specific actions to the current plugin. Requires merely a change in the plugin.xml.
Type a really large word with no spaces. The caret will go outside the viewer and disappear. The caret gets placed during the updatemanager's validate step. It's going to be tricky to actually scroll the viewport right after the layout has occurred. I think it's not a problem though. It just adds more dirty regions and should not cause more invalid figures to be added.
When the caret goes out of the viewport by pressing one of arrow keys, the viewport doesn't move with the caret.
The viewport should 'follow' the caret if the caret location has been changed by the arrow keys.
TreeViewerTransferDropListener.getCommand() iterates the TreeViewerTransfer items, gathering a command for each one separately. This causes a problem when multiple objects are dragged to a location in front of their current one. If each item is going to the same index, each subsequent object will be placed in front of the previous one, reversing their original order, even though they were being dragged together. It would be best to package up all the objects in a single command rather than iterating and gathering commands for each separately.
This problem is clearly visible in the Logic example. Add several items, select a couple of adjacent ones in the outline and drag them upwards. They will be left in the reverse order in which they appeared originally.
We have a MultiPageEditorPart extension with quite a few pages, two of which use a palette (GraphicalEditorWithFlyoutPalette). The two pages that use the palette can be different palettes.
This is no problem when the "Palette View" is not open, as each palette is maintained by the page. The issue is that the palette view seems to only be loaded once per editor - ie: the MultiPageEditorPart. If the current inner editor has a palette when the palette view is loaded, then the palette view will consist of that particular palette, even if the page (inside the MPE) is changed to a page that doesn't support a palette, or a page with a different palette.
What should happen is that if the active editor inside the MultiPageEditorPart changes, the palette view should also update to reflect the current editor's palette, if any.
SnapToGrid has an issue where it only works for snapping to the top right (NORTH | WEST) corner of a figure.
The issue is that in the code for handling SOUTH and EAST, it sets preciseHeight and preciseWidth instead of preciseX and preciseY. Since preciseX and preciseY is used to determine snapping, but is always 0, snapping then turns off completely.
It's easy to replicate the issue. Simply change snapLocations in SnapToGrid.snapRectangle to (EAST | SOUTH). This should make the figure snap to the bottom right corner, but instead turns all snapping off.
The code below fixes the issue:
public int snapRectangle(Request request, int snapLocations,
PrecisionRectangle rect, PrecisionRectangle result) {
rect = rect.getPreciseCopy();
makeRelative(container.getContentPane(), rect);
PrecisionRectangle correction = new PrecisionRectangle();
makeRelative(container.getContentPane(), correction);
if (gridX > 0 && (snapLocations & EAST) != 0) {
double rightCorrection = Math.IEEEremainder(rect.preciseRight()
- origin.x - 1, gridX);
correction.preciseX -= rightCorrection;
snapLocations &= ~EAST;
}
if ((snapLocations & (WEST | HORIZONTAL)) != 0 && gridX > 0) {
double leftCorrection = Math.IEEEremainder(rect.preciseX - origin.x,
gridX);
correction.preciseX -= leftCorrection;
if ((snapLocations & HORIZONTAL) == 0)
correction.preciseWidth += leftCorrection;
snapLocations &= ~(WEST | HORIZONTAL);
}
if ((snapLocations & SOUTH) != 0 && gridY > 0) {
double bottomCorrection = Math.IEEEremainder(rect.preciseBottom()
- origin.y - 1, gridY);
correction.preciseY -= bottomCorrection;
snapLocations &= ~SOUTH;
}
if ((snapLocations & (NORTH | VERTICAL)) != 0 && gridY > 0) {
double topCorrection = Math.IEEEremainder(
rect.preciseY - origin.y, gridY);
correction.preciseY -= topCorrection;
if ((snapLocations & VERTICAL) == 0)
correction.preciseHeight += topCorrection;
snapLocations &= ~(NORTH | VERTICAL);
}
correction.updateInts();
makeAbsolute(container.getContentPane(), correction);
result.preciseX += correction.preciseX;
result.preciseY += correction.preciseY;
result.preciseWidth += correction.preciseWidth;
result.preciseHeight += correction.preciseHeight;
result.updateInts();
return snapLocations;
}
From bug 212060 comment 4:
The org.eclipse.gef.doc.isv plugin has three files which are failing PII standards for HTML validity.
Failing files are: /about.html /guide/guide.html /guide/index.html
This should be fixed before someone in TVT land complains. ;-)
I have a tree viewer, and some of the editparts in it are non-draggable. When the user selects one of them and starts dragging it, there's a drag feedback and the cursor changes to a dragging crsor.
Currently class PaletteView considers only IEditorPart being an 'important' workbench part that may provide palette contents (see isImportant(...) method). This is an absolutely needless limitation. I suggest to consider IViewPart to be asked for palette contents as well.
5-pixel space is left around the primary layer for feedback. But feedback does not zoom. So, that space does not need to zoom either.
AbstractTransferDropTargetListener should check for enablement in its handleDragOver() method. The data is not always available and there is not always a target edit part, but when they are available, it should check to see if the command retrieved is executable and should update its cursor accordingly.
Changes made to a part through the property sheet could move or resize the part so that it's attached edge is not properly aligned with the guide anymore.
Feedback is shown when a part is dragged and attached to a guide. However, some sort of feedback should also be shown indicating that a part is attached to a guide when no dragging is occuring. This can then also be used to indicate when a part is being detached from a guide while dragging.
Need a better router than manhattan router. One which supports the user's specifying the vertical and horizontal segment locations. The router may or may not use anchors.
GEF tools (and drag trackers ?) should be able to publish some information that could be shown in the status bar. This is a common feature for graphical tools. The the information that could be shown includes:
- An intuitive icon
- Some description (perhaps optional)
- Mouse coordonates
- Other state information such as selection bounds
Example: Selection tool: selection tool icon, Select, the current mouse position Marquee took: marquee icon, Marquee, the bounds of the current selection
Generally the format of the published information should be customizable with GEF providing some sensible defaults. Perhaps tools like Visio should be checked out for ideas on this feature.
See http://dev.eclipse.org/newslists/news.eclipse.tools.gef/msg08383.html
Summary: If a PaletteRoot instance for a palette is repopulated by removing all children and adding the updated list of palette entries and the editor is open, when a tool in the palette is selected, there is a null pointer in the graphical viewer.
There is a work around by adding a listener to the palette root and when the children change, obtain the palette viewer and setActiveTool(null); however it would be much cleaner if the PaletteViewer clears the active tool reference if the referenced active tool has been removed. External listeners should not need to know when to update the palette viewer.
Exception stack trace: java.lang.NullPointerException at org.eclipse.gef.ui.palette.PaletteViewer.setActiveTool(PaletteViewer.java:36 1) at org.eclipse.gef.internal.ui.palette.editparts.ToolEntryEditPart$2.actionPerf ormed(ToolEntryEditPart.java:256) at org.eclipse.draw2d.Clickable.fireActionPerformed(Clickable.java:200) at org.eclipse.draw2d.Clickable$1.actionPerformed(Clickable.java:172) at org.eclipse.draw2d.ButtonModel.fireActionPerformed(ButtonModel.java:131) at org.eclipse.draw2d.ToggleModel.fireActionPerformed(ToggleModel.java:28) at org.eclipse.draw2d.ButtonModel$DefaultFiringBehavior.released(ButtonModel.ja va:484) at org.eclipse.draw2d.ButtonModel.fireReleased(ButtonModel.java:169) at org.eclipse.draw2d.ButtonModel.setPressed(ButtonModel.java:444) at org.eclipse.gef.internal.ui.palette.editparts.ToolEntryEditPart$OtherToggleB uttonTracker.handleButtonUp(ToolEntryEditPart.java:159) at org.eclipse.gef.tools.AbstractTool.mouseUp(AbstractTool.java:1042) at org.eclipse.gef.tools.SelectionTool.mouseUp(SelectionTool.java:535) at org.eclipse.gef.EditDomain.mouseUp(EditDomain.java:241) at org.eclipse.gef.ui.parts.DomainEventDispatcher.dispatchMouseReleased(DomainE ventDispatcher.java:344) at org.eclipse.draw2d.LightweightSystem$EventHandler.mouseUp(LightweightSystem. java:516) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:136) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:82) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:796) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:2772) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2431) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1377) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1348) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:254) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:141) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:96) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator. java:335) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:273) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:129) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:183) at org.eclipse.core.launcher.Main.run(Main.java:644) at org.eclipse.core.launcher.Main.main(Main.java:628)
It always gets the preferred size assuming that scrollbars are present. As a result, it's determination of whether scrollbars are needed or not can be incorrect.
Instead it should assume that the scroll bar visibility will not change for the current control, and later re-calculate the preferred size, if needed.
I use GEF3.1 & Eclipse3.1M5a, when i run org.eclipse.gef.examples.shapes_3.1.0, I found a bug.
I found this sample use ShortestPathConnectionRouter to create connection's router. now I add a big ellipse, a small ellipse and a rectangle to the penal, two ellipse both connect to rectangle. when two ellipse cross, the connection will through the ellipse, cannot count correct router to the rectangle.
I'm trying to customize default cursor for Canvas with Canvas.setCursor() method. Unfortunately, it doesn't work well. At the time the view is opened the cursor looks good - the one I specified. But when I move mouse over selection handle and then move it back to canvas, the cursor changes to default arrow, and doesn't seem to change to my custom cursor ever after that.
I use Eclipse3.1M5a & GEF3.0.1 & GEF Example3.0.1 When you create a logic example file, and open it by example editor. Then move your mouse pointer to the editor name, here will show a tooltips. The tooltips contain the file path and file name.(now they are both right) Then keep the editor open, rename the project name to another name, when you mouse pointer move to the editor name, the tooltips context is wrong(the file path is error).
In my opinion it would be very useful, if there would exist additional to the ZoomComboContributionItem, single ZoomActions for special cases like FIT-ALL. Furthermore it would be also very nice if a "Zoom to Selection"-State + Action could be integrated.
Thank you and Greetings Daniel
I'm having some problems dragging parts via the keyboard on GTK. It doesn't process the arrow keys once the drag has been started if the previous part that had focus was in another graphical viewer (such as the rulers) or if the cursor was not in the graphical viewer.
Bug 99990 - [Tool] CreationTool.handleButtonDown should transition to INVALID state if there is no target
I had an empty palette and tried to bring up the popup menu. Got the following exception because it tried to get the first selected editpart, but since there were none it failed:
ENTRY org.eclipse.ui 4 0 2005-06-22 10:27:01.722 !MESSAGE Index: 0, Size: 0 !STACK 0 java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.RangeCheck(ArrayList.java:507) at java.util.ArrayList.get(ArrayList.java:324) at java.util.Collections$UnmodifiableList.get(Collections.java:1139) at org.eclipse.gef.ui.palette.PaletteContextMenuProvider.buildContextMenu(PaletteContextMenuProvider.java:54) at org.eclipse.gef.ContextMenuProvider.menuAboutToShow(ContextMenuProvider.java:60) at org.eclipse.jface.action.MenuManager.fireAboutToShow(MenuManager.java:285) at org.eclipse.jface.action.MenuManager.handleAboutToShow(MenuManager.java:372) at org.eclipse.jface.action.MenuManager.access$0(MenuManager.java:369) at org.eclipse.jface.action.MenuManager$2.menuShown(MenuManager.java:386) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:116) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:844) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:868) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:849) at org.eclipse.swt.widgets.Control.WM_INITMENUPOPUP(Control.java:3336) at org.eclipse.swt.widgets.Control.windowProc(Control.java:3063) at org.eclipse.swt.widgets.Decorations.windowProc(Decorations.java:1577) at org.eclipse.swt.widgets.Display.windowProc(Display.java:3682) at org.eclipse.swt.internal.win32.OS.TrackPopupMenu(Native Method) at org.eclipse.swt.widgets.Menu._setVisible(Menu.java:225) at org.eclipse.swt.widgets.Display.runPopups(Display.java:3084) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2685) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1716) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1680) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:365) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:103) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948)
!ENTRY org.eclipse.ui 4 4 2005-06-22 10:27:05.698 !MESSAGE Unhandled event loop exception
DirectEditManager#handleValueChanged() invoked showFeedback() which leads to the original figure's text being updated. The AncestorListener added to that figure will then be notified and it will relocate the celleditor. Then handleValueChanged() itself invokes placeCellEditor() at the end of the method.
The fix would be remove the invocation of placeCellEditor() from handleValueChanged(). At the very least, since our examples are updating the text in the underlying immediately, they should override handleValueChanged() to make the above-mentioned change.
Drag-and-drop or click-and-drop from the palette selects the newly created part. Pasting should do the same. PasteTemplateAction can get the viewer from the IAdaptable workbenchpart, and select and reveal it if there's a veiwer available.
If I select an element in a diagram and moves it to the border of the window and while autoscrolling is in progress press the right mouse button the popup menu is displayed. Now the app gets into a state where it just continues to autoscroll even after releasing the all mouse buttons and the popup menu stays up without it being possible to select anything from it, nor is it possible to cancel the menu by pressing escape or clicking anywhere else. I have to kill my app from the Windows Task Manager (yes, Windows XP it is).
While this may be considered obscure it is the kind of thing that many persons may do accidently given enough attempts. This is how I ran into it, i.e, my fingers slipped on the mouse while autoscrolling.
Bug 101558 - [Tool] Inconsistent post-execute selection between CreationTool and ConnectionCreationTool
In CreationTool performAction invokes selectAddedObject() so that the newly created object is selected.
ConnectionCreationTool has no equivalent behaviour.
So in e.g. EDiagram new nodes are selected, but new links are not.
Copying the CreationTool code to ConnectionTool works fine. ? should it move up the hierarchy or just be copied?
Specifically, I need to be able to: a) Assign different DPU for horizontal and vertical rulers. My diagram uses dialog units which scale differently horizontally and vertically. b) Provide feedback to user when a guide is dragged to an invalid part of the diagram. (this would mean setting a custom DragGuidePolicy on the guide editpart).
Plus, I have not seen any good reason why the Ruler API should be private.
FlowPage page = new FlowPage(); TextFlow text = new TextFlow(); page.add(text); text.setLayoutManager(new ParagraphTextLayout(text)); text.setText("some text"); page.setFont(new Font(null, "Tahoma", 8, 0)); page.setSize(100, 30); page.validate();
The NPE will be encountered during page.validate() because the text flow's new layout's context is null.
I think this is an unnecessary restriction on the user of Draw2d and we can fix this by caching the context in the FlowFigure instead of the FlowFigureLayout. The layout can then just get it from the figure.
See Bug 106114.
The proper fix for that problem is to not allow the DragEditPartsTracker to go into drag state.
insert key is not hooked up. It doesn't do anything.
In GEF 3.2M2, transferring (copy-pasting or dragging) assumes that the given
template is the factory. This causes a problem when the factory is from a
different editor. Currently, it is the clients' responsibility to verify that
the part being pasted/dropped in the viewer is of a type it understands.
However, most clients won't be aware of that and will likely run into some
problem (Logic example encounters a ClassCastException).
A potential solution is to make the clients provide some sort of a context id that would prevent the transferring of a type to a viewer that does not support it.
When selection moves outside of a block, the selection range should switch to selecting blocks; and move back to selecting characters if it then goes back into the originating block.
Some OSes (MacOS, in particular) have different keybindings for navigating/editing text. Text example has a few hard-coded shortcuts for now. It should be OS-dependent and can be done via TextTool#lookUpAction().
Attached is Rotated Rectangle and related GEF policies & trackers code that I would like donate to gef & draw2d project.
Hasan Ceylan
The zoom contributions provided by ZoomManager to fit zoom level to height/width/page should take the minimum zoom level into account. Currently they only restrict by the maximum.
for example: if a very tall figure is on the page, and zoom is set to 'Page', then the zoom might actually get set to below the minimum zoom level such that it actually fits on the page (in my particular case, 8%). Then, when the user selects the zoom dropdown combo, the zoom is automatically updated to the actual minimum (default is 50%).
The TextTool, in lookupAction(), currently maps certain keystrokes to actions such as pg up, pg down, line up, line down, navigate forward, backwards, etc. It should register handlers with the platform's keybinding service for these commands (which are defined in org.eclipse.ui.workbench.texteditor).
Currently, GraphicalTextViewer has the revealCaret() method. It should be updated to take two rectangles, one the size of the caret, and the other being the rectangle representing the SelectionRange. The viewer should then expose both, or the caret and as much of the selection range as possible if both are not feasible.
Perhaps CaretInfo can be enhanced to carry this information, or new API could be added to TextEditPart to determine this information. This would help TextTool determine information such as the type of caret to be used (bidi uses a directional caret), the direction of the caret when in OVERWRITE mode, whether the caret should be hidden (when the selection is an embedded graphic and handles are shown instead of range), or any other special caret characteristics (such as a slanted caret when in italicized text).
SelectionRange changes very quickly and often in the text example, and it's expensive to update all the actions everytime the range changes. There should be a delay introduced to avoid this problem. When selecting with the mouse, the actions can be update on mouse up. When selecting with the keyboard, the delay should be introduced.
When on the last line, hitting Shift + Down should select the rest of the text on that line and the caret should be placed at the end of the line. Similarly, for when navigating up from the first line. These cases do not currently work in the text example. I've added a TODO where this code should go in TextFlowPart#searchRow().
I recently added these to CaretRequest and TextTool properly updates the request when this kind of navigation is requested. The TextEditParts, however, don't handle these requests just yet.
The code in the getTextLocation() method of the various implementations of TextEditPart should be moved out into Helper classes so that they can be reused. These helpers could be singletons, in which case they can't be EditPolicies.
Need to add actions for these. They should be usable in editors such as the text example as well as in the case of direct-editing (such as in the logic example).
The SelectionProcessor could be thought of as an extension of what the TextTool does. It would be a smart tool that would determine what the user is trying to do and update the selection accordingly. For instance, when a user navigates from one cell in a table to another, it might switch to selecting cells rather than text. If the user then goes back to the original cell, it would start selecting text again. Similarly, when selecting while swiping, it could change to word selection (like Microsoft Word does) and switch back to character selection when the user moves backwards. This functionality should be easily configurable and pluggable in the TextTool, hence the need of a separate SelectionProcessor.
The text example needs to expose both the text selection as well as the object selection to the platform's SelectionService. Related views might work off of either one. We should look at source editing team's ITextSelection for ideas how to address this.
Information such as Insert/Overwrite mode, column and row number, etc. should be added to the status bar.
Steps to repeat. -create Logic example; -add any element to the view, move it behind the view bottom to make vertical scrollbar appear; -start connection drawing from the element; At this step, while mouse is moving over the view, GEF draws connection feedback line to the mouse pointer; -scroll viewport with mouse wheel - connection feedback is not updated - this is the bug; -move mouse a little - the feedback is correctly updated.
You should be able to query the SelectionRange to get the EditPart that completely contains it. At this point, this information is in SelectionModel (although its not being set/used). It should be removed from there.
Bug 125991 - [Command] Should converge GEF command (org.eclipse.gef.commands) to undoable operations framework(org.eclipse.core.commands.operations)
In 'eclipse', there are three Command frameworks which support/enable very similar functions ( redo/undo/execute ). Having similar functions would confuse the developers and affect the software maintenance cost. Need to converge GEF command to Platform's command. No more similar functions.
- Run Eclipse using -dir rtl attribute.
- Open a regular file and GEF example file (File -> new -> example -> GEF WYSIWYG document Example.
- Click next and type file name with .text extension. Click Finish.
- The Editor is opened with the file.
Problem1: The direction icons should be switched in RTL mode. The LTR icon is accosiated with right arrow and the RTL icon with left arrow, where it should be opposite.
- Click with the mouse on the source code on the text file (the last lines) in editor and click on LTR icon.
Expected Result: The code lines should have a LTR ordering schema thus the code will be readable. Actual result (problem2): The ordering is still RTL, only the alignment is changed to left.
I want to be able to customise the colours of the GEF palette so that the palette fits in more closely with the rest of our application which uses a custom theme. Currently the colours for the palette seem to be taken straight from the operating system and we can't change them. Is there any chance of adding a method to DrawerFigure.java to allow overriding of the default PaletteDrawer titlebar colour?
Hi,
tooltips for EditParts are not closed, when a native DnD is initiated.
Think of somewhat more complex and bigger tooltips. In the case of native DnD they might obstruct the view on the drag target, which might be another Eclipse view or editor.
There should be an API to hide tooltips manually at runtime, or tooltips should generally get closed when DnD starts.
Kind regards
Sven
Hi,
the selection state of
org.eclipse.gef.ui.actions.ToggleSnapToGeometryAction
and
org.eclipse.gef.ui.actions.ToggleGridAction
does not seem to be in sync with the corresponding setting, when these actions are used in a menubar or toolbar.
I guess, there is a problem with the isChecked() method, which is overwritten from org.eclipse.jface.action.Action!
Cheers
Sven
Eclipse 3.2M5a Build date: GEF-ALL-3.2M5
Problem description: Thai word wrap does not work properly in Label text
Steps to create the problem
- Create a label in the logic editor by dragging a label from the palette.
- Click on the label's text and then enter long Thai text into the label until the line wrap occurs.
Please note that Thai word break works correctly while editing Thai text in label.
- Click mouse outside the label to quit from edit mode.
Problem: After exit from edit mode, Thai word break does not work correctly on label text (Please see the screen captures in the attachment).
Please investigate the problem.
Thanks, Suwit
Eclipse build: M6 GEF build: I20060331-1528 OS: Windows 2000, Windows 2003, Windows XP with Arabic locale.
Scenario:
- Generate a general project.
- Create a new logic diagram (File->New->Example->GEF->Logic Diagram).
- From the palette, drag a "Label" to the Logical Graphical Editor.
- Edit the label text with mixed Arabic-English text and numerals. (You may use the following key strokes sequence: "'HFU 123 label 123", where the capital letters represent Arabic characters)
- Save the model.
Expected Behavior: Arabic characters are correctly displayed and contextual behavior is respected.
Actual Behavior:
- While the label is in the "Edit" mode, everything works as expected.
- When exiting the "Edit" mode, Arabic display is fine; However, contextual behavior is not respected. i.e. Numbers are always in nominal format.
Refer to the attached screen capture for futher illustration.
OS : RHEL 3.1 Must fix or not a must fix: YES Build date: 0514 Blocking: NO Language: fi Bitmap Location: V:\defects\fi\24001390.jpg Tester Name: Mika Salminen Problem Description:
Actual Description of the problem: Double click on the eclipse.exe icon Click OK First, you need to create a simple project. Go to File > New > Project. Select General > Project. Type in a name (for example, Test). Click Finish.
Right click on Test. Select New > Other. Select Examples > Logic Diagram Click Next Select Four-bit Adder Model Click Finish If the rulers are not visible, go to the View menu and enable them (View> Rulers) Right click anywhere on either of the rulers to bring up its context menu Select Create Guide Highlight the guide you just created
Click on Edit on the toolbar Select Delete (You can also click on and press Delete key)
Delete key works but the Delete option is grayed out. Please see the attached screen capture and advise. Thanks.
This article was reassigned from Category:''TVT/Testing''.
The NOR tester executed the following steps for the GEF:
First, you need to create a simple project. Go to File > New > Project. Select General > Project. Type in a name (for example, Test). Click Finish.
Right click on Test. Select New > Other. Select Examples > Logic Diagram Click Next Select Four-bit Adder Model Click Finish If the rulers are not visible, go to the View menu and enable them (View> Rulers) Right click anywhere on either of the rulers to bring up its context menu Select Create Guide Highlight the guide you just created
Click on Edit on the toolbar Select Delete (You can also click on and press Delete key)
When she highlight ed the guide and Selected Edit> Delete from the toolbar, the Delete function was greyed out. The Delete key did work for her and also Delete in the menu is translated correctly.
This article was reassigned from Category:''TVT/Testing''.
OS: RHEL 3.1 Must fix or not a must fix: NO Build date: 051406 Blocking: NO Language: da Bitmap Location: V:\defects\da Tester Name: Mette Djoerup Problem Description: The Danish title of the Select Print Mode dialog is truncated. The last letter is not visible. This problem was also reported in TCT 471, which was originally opened for another problem and then returned.
Please expand the dialog or make it resizable.
Mette
Same happens in PTG.
Thank you!
Sorry, the correct Testcase number (and screenshot number) is 24.001100.
Mette
This article was reassigned from Category:''TVT/Testing''.
Here are the steps to display the dialog:
Double click on the eclipse.exe icon Click OK First, you need to create a simple project. Go to File > New > Project. Select General > Project. Type in a name (for example, Test). Click Finish.
Right click on Test. Select New > Other. Select Examples > Logic Diagram Click Next Select Four-bit Adder Model Click Finish In the Package Explorer view, right-click on the logic file
Select Print. The print option on the menu and the dialog that pops up afterwards should be completely translated.
The dialog title is Select Print Mode in English. In Danish, the dialog title is Vælg udskrivningstilstand but the dialog is too narrow to display the entire string.
Mette
I found the ZoomManager supports scaling functionality but the zoom level set in the manager applies to both dimensions. I was thinking if there could be in future versions of GEF an ability to zoom the area using separated zoom levels for each axis. What do you think?
In my GEF editor, I have bound actions that select tools to keys. The actions call paletteViewer.setActiveTool(...). However, when I press a key while the mouse is over a diagram and the select tool is active, first the mouse pointer turns into an "X" (this is Linux here), indicating that "I cannot do that here" (create a new object, e.g.). When I move the mouse a little bit (1 pixel is enough), the mouse pointer turns into something indicating that I can perform the tool's action. (May I call another method to work around this and update the "tool state" manually?)
Furthermore, when I activate a tool (no matter whether I am clicking on the palette or pressing the corresponding key) while the mouse pointer is outside the diagram, and then carefully (pixel by pixel) enter the diagram, first the pointer turns into an "X" and after moving one more pixel, everything is fine again. So this somehow looks to me as if the "tool state" is updated on mouse move events only but not on focus-in events or when the active tool changes.
When click the page up or page down key, the scrollbar has no effect.
AbstractConnectionCreationTool#calculateCursor currently looks like that:
protected Cursor calculateCursor() { if (isInState(STATE_INITIAL)) { if (getCurrentCommand() != null) return getDefaultCursor(); } return super.calculateCursor(); }
It sets the cursor to Default even if the command is not actually executable. This can mislead User into thinking that a Connection is supported when it's not. A better implementation would be:
protected Cursor calculateCursor() { if (isInState(STATE_INITIAL)) { Command command = getCurrentCommand(); if (command != null && command.isExecutable()) return getDefaultCursor(); } return super.calculateCursor(); }
(BTW, super.calculateCursor() does call canExecute())
setImageDescriptor should use the JFaceResources class to manage the Image needed. When deactivated or when the descriptor changes, the current descriptor should get deallocated.
Fixed via https://github.com/eclipse-gef/gef-classic/pull/793
With a GEF application displayed in an RCP ViewPart (not an EditorPart) and the view open in detached mode (torn away from the rest of the workbench window), pressing the Esc key dismisses the view. This is normal behavior for a view, but inappropriate when the user is in the middle of a create operation from the GEF palette or drag-and-drop move in a GEF application. In these cases, the Esc key should abort the operation in progress (as it does when the view part is attached to the workbench window), but not dismiss the view.
I attempted to subclass ScrollingGraphicalViewer and FigureCanvas to include an override, but the createControl(Composite) method on ScrollingGraphicalViewer is declared final, so I can't have a subclass of the one make a subclass of the other.
A stack trace captured from the ViewPart's dispose method is included for reference. The method FigureCanvas.translateTraversal(MSG) is in the stack prior to the shell being closed, so it should be possible to prevent the shell from being closed at this point.
Possible solutions to explore include: (a) modify FigureCanvas to override Control.translateTraversal(MSG) to ignore the Esc key when such an operation is in progress (b) modify FigureCanvas to allow application developers to hook in an event override function that can decide how to handle certain events, and override to call that function from translateTraversal(MSG) (c) override Control.translateTraversal(MSG) to simply ignore the Esc key.
Thread [main] (Suspended (breakpoint at line 281 in MyGEFView)) MyGEFView.dispose() line: 281 ViewReference(WorkbenchPartReference).doDisposePart() line: 659 ViewReference.doDisposePart() line: 94 ViewReference(WorkbenchPartReference).dispose() line: 628 WorkbenchPage.disposePart(WorkbenchPartReference) line: 1439 WorkbenchPage.partRemoved(WorkbenchPartReference) line: 1431 ViewFactory.releaseView(IViewReference) line: 237 Perspective.hideView(IViewReference) line: 498 WorkbenchPage.hideView(IViewReference) line: 2023 DetachedWindow.handleClose() line: 202 DetachedWindow.access$0(DetachedWindow) line: 194 DetachedWindow$1.shellClosed(ShellEvent) line: 65 ShellPool$2.shellClosed(ShellEvent) line: 67 TypedListener.handleEvent(Event) line: 159 EventTable.sendEvent(Event) line: 66 Shell(Widget).sendEvent(Event) line: 843 Shell(Widget).sendEvent(int, Event, boolean) line: 867 Shell(Widget).sendEvent(int, Event) line: 852 Shell(Decorations).closeWidget() line: 257 Shell.close() line: 430 Shell.traverseEscape() line: 1318 Shell(Control).traverse(Event) line: 2783
FigureCanvas(Control).translateTraversal(MSG) line: 2759
FigureCanvas(Composite).translateTraversal(MSG) line: 840
Display.translateTraversal(MSG, Control) line: 3577
Display.filterMessage(MSG) line: 933
Display.readAndDispatch() line: 2754
Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 1699
Workbench.runUI() line: 1663
Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 367
PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 143
Application.run(Object) line: 18
PlatformActivator$1.run(Object) line: 226
EclipseStarter.run(Object) line: 376
EclipseStarter.run(String[], Runnable) line: 163
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object[]) line: 324
Main.invokeFramework(String[], URL[]) line: 334
Main.basicRun(String[]) line: 278
Main.run(String[]) line: 973
Main.main(String[]) line: 948
From what I understand, the GEF palette requires the entire palette definition to be passed to it upon initialization. For large products that have hundreds of palette items, it can take substantial amounts of time to create this palette definition. (Especially if the palette definition is built from parsing extension points).
I would like this bug to serve as a placeholder for investigating ways that GEF could lazily initialize the palette, instead of requiring the entire definition be passed to it on creation.
Bug 162893 - [Tool] AbstractConnectionCreationTool should consider executability of current command when calculating Cursor
In org.eclipse.gef.tools.AbstractConnectionCreationTool, method
protected Cursor calculateCursor() { if (isInState(STATE_INITIAL)) { if (getCurrentCommand() != null) return getDefaultCursor(); } return super.calculateCursor(); }
should be replaced by
protected Cursor calculateCursor() { if (isInState(STATE_INITIAL)) { if (getCurrentCommand() != null && getCurrentCommand().canExecute()) return getDefaultCursor(); } return super.calculateCursor(); }
Reason: Treatment of unexecutable commands and null commands should be the same across EditParts and Tools. Method getCommand() in org.eclipse.gef.editparts.AbstractEditPart returns an unexecutable command when one of the EditPart's installed EditPoliciys returns an unexecutable command, and ignores 'null commands' returned by installed EditPolicys (by chaining them which doesn't have any effect on an existing chain of commands). Method calculateCursor() in org.eclipse.gef.tools.AbstractConnectionCreationTool returns a default cursor (in state STATE_INITIAL) even if the current command is unexecutable, which contradicts the semantics of treating unexecutable commands in AbstractEditPart. Method calculateCursor() in AbstractTool also considers executability of the current command.
TextFlows ignore the opaque setting. It should be fairly straight-forward to fill the background of the TextFlow (fragment by fragment) before drawing the text. This can be useful for something like highlighting, custom selection, etc.
The selection tool ignores all connections whose end points are another connection. This was discovered during the investigation of GMF Bugzilla #162083.
I could not find any GEF-only examples where connections between connections are used, but this bug can be reproduced using the GMF logic diagram example.
Steps:
- Create a GMF logic diagram.
- Create 4 notes (N1, N2, N3, N4) on the diagram.
- Connect N1 to N2 and N3 to N4 with note attachments.
- Connect the 2 note attachments together with another note attachment.
- Using the selection tool, draw a rectangle around the note attachment between the 2 note attachments
Result:
- Nothing on the diagram is selected
Expected:
- The connection contained within the rectangle created by the selection tool should be selected
Currently, there are the PaletteViewerPreferences which are set in a PreferenceStore and the FlyoutPreferences which use org.eclipse.core.runtime.Preferences. They could be unified.
While the FlyoutPreferences are live (changing a property in one editor, immediately updates all other open editors), the PaletteViewerPreferences are not.
Also, there is no easy way to set the defaults for these preferences.
Note that I'm suggesting an API change here, and so this wouldn't really be for a point release.
To reproduce:
- Create a GEF logic example.
- Add a LED.
- Grab the LED in the center, drag the shape to the right side of the viewport, and hover near the very edge of the viewport. Notice that autoscrolling will occur.
- Now repeat, but grab the LED close to the right edge of the LED instead. In this scenario, autoscrolling does not occur.
I did some investigation into this issue. If you grab the shape in the middle, when you get close to the edge, the viewport scrolls a bit which makes the viewport bigger to the right (i.e. you could scroll further right). In the ViewportAutoexposeHelper.step() method, the call to port.setViewLocation(loc) at the bottom, then causes the viewport to move further to the right and this starts off the autoscrolling.
If you grab the shape on the right side (or use the accessibility handles to move the shape), the viewport does not scroll when you get to the autoscroll trigger area because the shape is fully exposed. So then in the ViewportAutoexposeHelper.step() method, the call to port.setViewLocation(loc) does not change the horizontal range model value because the code in DefaultRangeModel.setValue() does not let you scroll past he maximum value.
I think what needs to be done is that the DefaultRangeModel's maximum value needs to be changed. I played with changing the bounds of the viewport content's, but I couldn't get this to work.
Build ID: M20060921-0945
Steps To Reproduce: 1.Install eclipse 3.2.1 SDK 2.Install the GEF SDK 3.Start eclipse and create a new Java class 4.In that class create a ZoomManager variable 5.Move the cursor over the "ZoomManager", and press F3 to see the ZoomManager class source 6.Navigate to the zoomTo(Rectangle) method implementation and observe that is empty
More information: The ZoomManager#zoomTo(Rectangle) method is a very useful method when attempting to write a zoom-to-selection action (the action would then consist of simply finding the bounding box, and calling ZoomManager#zoomTo(Rectangle))
Build ID: I20061102-1715 GEF 3.2.0.v20060626
Steps To Reproduce: In our editor it's easy to reproduce, but in LogicEditor I could not reproduce it
- Select an object in the editor
- An action derived from SelectionAction is enabled by selecting the object in step 1.
- Switch to a different workbenchpart for which this action is not available. The action disables
- switch back to the editor
The action does not get the right selection to base its enablement from. The reason is a wrong construct in SelectionAction.update(). It is implemented as follows:
public void update() { if (provider != null) setSelection(provider.getSelection()); else setSelection( getWorkbenchPart() .getSite() .getWorkbenchWindow() .getSelectionService() .getSelection()); }
but should be implemented as
public void update() { if (provider != null) setSelection(provider.getSelection()); else setSelection( getWorkbenchPart() .getSite() .getSelectionProvider() .getSelection()); }
With the wrong construct there is a risk that the selection obtained from the selectionService is the selection from the previous part, and not of the just activated part. This is because the selection service updates its own selection as part of the part-change-listening proces (setActivepart), the same proces from which update() is called. There is no predefined order in which the listeners to the partChanged event will be called. When update() is called before setActivepart of the selectionService is called, the wrong selection will be returned.
Also, it's more logical in SelectionAction.update() to
(a) derive the current selection from the provider in use (be it the alternative selection source (see setSelectionProvider) or the provider of the active part)
than
(b) in one case use the alternative selection source, other case ask the selectionservice.
With the current construct of SelectionAction.update() it is required that update() is called from a selectionListener registered in the selectionService (in LogicEditor it is the editor which is registered and calls update()). When update() is called from the selectionProvider of the editor, this construct fails. We do not really want to call update() from the editor, because the editor should not concern itself with its actions, for that we have the editorActionBarContributor (see help on org.eclipse.ui.editors). LogicEditor is not following Eclipse guidelines in this aspect.
Hope I make myself clear......
More information:
Currently, the behavior of SnapToGeometry is not really configurable :
- What directions (vertical, horizontal) are allowed
- what sides of the other figures are used to define the corrections
- ...
Moreover the class cannot be easily extended because of the "Entry" class with a protected constructor unusable outside SnapToGeometry.
Build ID: M20060921-0945
Steps To Reproduce: PaletteSettingsDialog has no context help. For consistency with most dialogs in Eclipse which are derived from JFace Tray dialog and therefore have a help control and context help, it would be nice for GEF palette settings dialog to also have context help and a help control.
More information:
Build ID: I20061214-1445
Steps To Reproduce:
- Run Eclipse using -nl iw attribute.
- Open the example document file (File -> new -> example -> GEF WYSIWYG document Example.
- Click next and type file name with .text extension. Click Finish.
- The Editor is opened with the file.
Result: Text direction in the file is RTL.
Expected Result: The source code lines should have a LTR text direction thus the code will be readable.
More information: When click on LTR button in toolbar the ordering remains RTL, but only the alignment is changed to left.
Build ID: I20061214-1445
Steps To Reproduce:
- Launch eclipse in mirrored mode (using nl -iw attribute)
- Create a simple project in workspace
- Go to File -> New -> Example… -> GEF WYSIWYG document Example.
- In the opened editor, type in some complex expression such as ABC def GHI (where capitals are Hebrew characters)
Result: While typing def (after typing ABC) the cursor is stays in the beginning of the line (in the right side of the editor). When typing Hebrew characters again, the cursor starts to move from the beginning of the line thus there is no correlation between text typing and cursor movement.
Customize Palette Dialog don't display in the correct Eclipse font.
-
Customize of category Radio button and Browse button of [Show/Hide Drawer]group.
-
Customize of Item
- Variables table
- Add/Remove button of Variables
- Template pattern text
- Insert Variable Placeholder button
When using a custom root edit part, this is a big waste of time. If this can't be removed from the constructor, there should be a way to set a new root before trying to create a default.
I have a gef diagram with a set of edit parts arranged in a grid. When dragging a selection box, GraphicalNodeEditPolicy.getTargetEditPart() gets called on many of my parts which are no where near the mouse. This happens seemingly at random. So far, I haven't been able to track down which code is being called because of the interactive nature. This has a huge performance impact on dragging a selection and is making the diagram very hard to use.
I would like to have a Tree based Browser for browsing my EditParts and the corresponding EditPolicies and Commands. The browser would not only show me the editParst but also select them and the selected editPart gets opened in the editor. With a large code base its troublesome to go through the navigator/Package Explorer and find the Editpart or policies. Indeed Eclipse provides a search facility but having a tree based browser would be more flexible.
The highlighting of a guide line is offset in a compartment. To reproduce:
- Create a Logic Diagram.
- Create a circuit with a LED inside.
- Turn on the ruler.
- Create a guide line through the circuit compartment.
- Try to snap the LED to the guide line. RESULT: It works fine, but the highlighting of the guide line in red is in the wrong spot. It looks to be offset by the distance between the diagram's origin and the compartment location.
Build ID: I20070608-1718
Steps To Reproduce: Can easily reproduce this with the Logic example. Just install the lastest Logic example plugin (3.3RC3 at the time of writing). Create a logic file and place a few shapes in edit area, save and right-click on the file and select print. I have only tried "print to PDF" due to no functional printers, and when printing to a pdf I end up with a huge file with all blank pages. Actually around 20000 pages depending on the logic diagram.
More information: Tried the same procedure on Windows and it works just fine there.
Bug 195165 - [Tool] Tools receive multiple handleButtonUp() calls when doing a quick drag and release.
If I do a slow drag and release on my GEF canvas, the tool receives only one call to handleButtonUp(), generated from the Eclipse mouse-up event. If however I drag and release quickly, the tool receives 2 calls to handleButtonUp(), the first being generated during a mouse move, and the second by the mouse up. Attached are two stacktraces showing how each gets generated. The first event is generated from what looks like a hacky section of code in AbstractTool.mouseMove(...), to wit:
if (!isInputSynched(me)) { boolean b1 = getCurrentInput().isMouseButtonDown(1); boolean b2 = getCurrentInput().isMouseButtonDown(2); boolean b3 = getCurrentInput().isMouseButtonDown(3); boolean b4 = getCurrentInput().isMouseButtonDown(4); boolean b5 = getCurrentInput().isMouseButtonDown(5); getCurrentInput().verifyMouseButtons = true; getCurrentInput().setInput(me); if (b1) handleButtonUp(1); if (b2) handleButtonUp(2); if (b3) handleButtonUp(3); if (b4) handleButtonUp(4); if (b5) handleButtonUp(5); ...
Build ID: 20060921-1617 (3.2.x)
Steps To Reproduce: In our product we use GEF for a palette, with palette template entries with icons. We would like to be able to offer the ability to see the image of the icon being dragged. I see no API to do this.
Build ID: M20060921-0945
Steps To Reproduce:
- Right-click a drawer in Palette
- Select Customized... and open Customize Palette Dialog
- Select an existing Component or Create a new one.
- Click the 'Small icon' button and Open 'Open' Dialog
- Do not select an icon, just click 'cancel' to close it.
- Then, click 'OK' or 'Apply' to make it work
- See, the component's icon become to a small red icon.
More information:
Build ID: I20070601-1539
Steps To Reproduce: 1.Create new example GEF project (Logic Diagram) New->Example->GEF->Logic Diagram 2.Wizard ask to create some logic file in the workspace, create default "emptyModel1.logic". 3."emptyModel1.logic" file is opened with the Example Logic Diagram editor. 4.Right click over some palette item e.g "LED" and select "Customize..." 5.Change the "Name" of the item with some BIDI string say in hebrew "XYZ" now as it is BIDI the cursor would be before X in XYZ now type English string and make the label as "abcXYZ". Press OK. 6. Label is applied as "XYZabc" not as "abcXYZ" as expected.
More information:
Created attachment 76224 A screenshot of the issue.
If you create a palette stack with lots of entries (try more than 15), there will be blank space whe the palette stack is shown. It is still possible to get to all the entries using the scroll button, but it looks quite ugly.
To reproduce this, modify the LogicPlugin.createComponentsDrawer() method to add an entry 15 times or so to the palette stack.
See that attached screenshot.
The problem is reproducible on Linux Redhat and not on Windows.
Created attachment 79570 A snapshot of the widget
Build ID: M20070212-1330
Steps To Reproduce: 1.Have an editor open that contains an org.eclipse.swt.widgets.Combo or a class that contains it 2.Make sure that the class uses org.eclipse.gef.editparts.ZoomManager as its zoom manager such as org.eclipse.gef.ui.actions.ZoomComboContributionItem 3.Make sure to add the combo to the menu bar 4.Launch your eclipse in english and the combo list shows the numbers in the list formatted as 100% 5.Launch your eclipse in Turkish and the combo list shows the numbers in the list formatted as 100%, too 6.Well in Turkish the percent sign is on the wrong side and should be displayed as %100
More information: I work for the Modeler team at IBM Canada and we have some customers in Turkey that have pointed out this problem to us. The source of the problem is that the ZoomManager have hard coded the format attribute to DecimalFormat format = new DecimalFormat("####%"); So, any application that wants to support Turkish, cannot modify this attribute since it is not accessible. Thus the solution is for this attribute to somehow support "%####" for Turkish and "####%" for thr rest of the world except those using Arabic. Strangely enough, in an Arabic locale, the numbers are formatted properly. Only the turkish locale has this problem.
Fixed via https://github.com/eclipse-gef/gef-classic/pull/794
Build ID: M20070212-1330
Steps To Reproduce: A user of our gef application reports that it is extremely difficult to get the canvas to auto scroll thereby making it very tough to make long connections.
More information: This is to report bug in gef version 3.2.2
Build ID: M20071023-1652
Steps To Reproduce:
- create an EditPart derivative with a Figure that has a Label as child
- create a CellEditorLocator derivative that uses the Label's bounds as location information.
- enable direct edit on the EditPart
- call performRequest( new DirectEditRequest() ) from the EditPart's activate()
More information: DirectEditManager.hookListeners() registers an ancestorListener with the EditPart's Figure: getEditPart().getFigure().addAncestorListener(ancestorListener);
The ancestor listener moves the CellEditor when the EditPart's Figure is moved. However, in common cases, the EditPart consist of a compound figure, and you actually want to edit one of the children of the EditPart's figure. That is, the location of the CellEditor is dependent on the location of the child, not the parent. Therefor, it should register an ancestorListener on the child, not on the parent.
Due to the way layoutManagers work, the ancestorListener for the parent is called before the children are layed out. Therefore, the CellEditor's Locator may have incorrect information about the location of children.
I run into this bug when I wanted to do an automatic direct edit after creation of an EditPart. So I called performRequest(new DirectEditRequest()) from the EditPart's activate(). The bug may also occur in designs where the location of the child within the parent can vary.
One possible solution could be to pass the Label as a parameter to the DirectEditManager (either in the constructor or in show()). Another would be to let the CellEditorLocator register the ancestorListener. In the latter case, a "dispose()" should be added to the CellEditorLocator interface, so it has a chance to remove the listener again.
I am making extensive use of the new text API in GEF, which hides quite a bit of the API. I'm opening this bug to maintain a list of API that I think needs to be exposed. Here are a few cases:
-
FlowBox#getLineRoot() should be made public. In fact, all the package-protected methods there should be made protected, if not public.
-
CaretInfo's constructor should be exposed. It's already marked as internal.
-
FlowAdapter's private fields should be made protected so that it can be subclassed as needed.
- Open a GEF diagram.
- Change the system font -- Right-click desktop > Appearance > Font Size. RESULT: Notice that the font on the palette drawers & tools are not updated. WORKAROUND: Restart Eclipse and the palette fonts are updated. NOTE: There are other things in Eclipse that have this problem as well, but not everything.
Currently, when a property is changed in the Customize Palette dialog, the PaletteCustomizer applies the change immediately to the palette model. When the Cancel button is pressed the changes are not reverted.
Why not keep track of the changes to be made and only change the palette model when the Apply or Ok buttons are pressed?
I implement collapsible composite control and found problems with hidden figures:
class MyEditPart extends AbstractGraphicalEditPart {
boolean isExpanded = true;
protected IFigure createFigure() {
Figure figure = new Figure();
ToolbarLayout toolbarLayout = new ToolbarLayout(false);
figure.setLayoutManager(toolbarLayout);
Figure contentPane = new Figure();
figure.add(contentPane);
...
return figure;
}
...
public void performRequest(Request request) {
if (request.getType() == equestConstants.REQ_OPEN) {
isExpanded = !isExpanded;
contentPane.setVisible(isExpanded);
refresh();
}
}
};
If figure is collapsed it still have space as if its visible. I found 2 solutions:
-
Override getMinimumSize and getPreferredSize in contentPane figure: contentPane = new Figure() { public Dimension getMinimumSize(int hint, int hint2) { Dimension d = new Dimension(super.getMinimumSize(hint, hint2)); if(!isVisible()) { d.height = 0; } return d; } public Dimension getPreferredSize(int hint, int hint2) { Dimension d = new Dimension(super.getPreferredSize(hint, hint2)); if(!isVisible()) { d.height = 0; } return d; } };
-
Override ToolbarLayout methods layout and calculateChildrenSize - check children visibility before calculation.
Is this a bug or 'by design'?
Hello GEF team,
we are two students of the Christian-Albrechts University of Kiel. Currently we are participating in a course where we create features for GMF generated editors. Our task is to add the feature 'snap to distance' - snapping of objects at simular distance of each other (see attachement).
We noticed that in M4 the snap to shape (geometry) is implemented. We would like to contribute our extension of this which is implemented in a simmilar way in GEF to the community.
Here is how you can add the snap to distance feature:
- unfortunately, the feature has to be registered in GMF, so add to the SnapHelperUtil.java in org.eclipse.gmf.runtime.diagram.ui.internal.editparts to method getSnapHelper() at the end (*): snapStrategies.add(new SnapToDistanceEx(parent));
- add file SnapToDistanceEx.java to package org.eclipse.gmf.runtime.diagram.ui.internal.ruler;
- add file SnapToDistance.java to package org.eclipse.gef
- Replace file SnapFeedbackPolicy.java in org.eclipse.gef.editpolicies by SnapFeedbackPolicy.java (We will create a patch if you like the feature.)
Though we are not in the gef-dev list, please respond to [email protected] or via comment here.
Best, Sven and Florian
(*) we also added a button similar to the snap to shape button in the preference pane, but that's gmf and we will contact the gmf people after our feature is in gef :)
Build ID: Integration build ID I20080324-1005
Steps To Reproduce:
-
Install Eclipse SDK with NL Bidi package
-
Run Eclipse with command line including following argument -nl iw
-
Go to File->New->Example…->Logic Diagram and hit "Next"
-
Hit "Back"
-
Select "Flow diagram" (or any other)
-
Try to hit "Next"
Expected result: "Next" works Actual result: "Next" does nothing
Note: in the English version "Next" works properly
More information:
Build ID: Integration build ID I20080324-1005
Steps To Reproduce:
- Install: - Eclipse SDK with NL Bidi package
- Run mirrored Eclipse with Hebrew translation (use command line argument -nl iw)
- Create a simple project in the workspace
- Go to File->Example…->Logic Diagram. Next. Finish
- Drag the Voltage positive node (V+) from the palette to the editor.
- Expand voltage options in the palette
- Inspect V+ display in opened views: editor, palette, outline
Expected result: Positive voltage should be displayed V+ Actual result: Positive voltage is displayed V+ and +V
More information:
Build ID: I20080207-1530
Steps To Reproduce: The bug can be reproduced using logic example:
- put two any diagram elements from palette. Distance between elements should be as long to activate scroll bar
- Move scroll bar that you can see only one element
- Try to select these two elements. Autoscrolling does not work (scroll bar does not move during selection)
More information:
Created attachment 95166 Extra Tchinese string
Build ID: I20080324-1005 GEF version: GEF-SDK-I200803111830.zip
===== Steps To Reproduce ===== 1.Create a simple project in the workspace. 2.Go to File -> New -> Example… -> Logic Diagram and hit “Next.” 3.In the dialog that pops up, you should be able to edit the project and file names. 4.Go ahead and create an empty model file (to be used for the next test case). 5. Create a label in the logic editor that opens up (by dragging a label – under components – from the palette). If a palette is not visible, open the Palette View (Window -> Show View -> Other… -> Basic -> Palette). 6.Create a file using the WYSIWYG example file wizard. 7.Open Editor
===== Expected Result ===== Editor should display normally without extra string.
===== Actual Result ===== Editor display extra TChinese string or space in the square bracket.
More information: ==== Environment ===== Build Level: I20080324-1005 Platform: Windows XP Affected Locale(s): TChinese
Created attachment 95893 Screen Capture
Build ID: I20080330-1350
Steps To Reproduce:
- Run Eclipse 3.4 platform
- Select File->New->Example from menu
- Select Logic Diagram under GEF(Graphical Editing Framework) and click Next > button
- Select the parent folder
- Enter ThaiModel.logic as File name and select Empty Model for Logic Model Samples
- Click Finish button
- Click label icon at Palette View to create label in the logic editor
- Click on the label's text and type Thai text for the label (Please find the sample Thai text in the attached sampleThaitext.txt file).
- Click at the outside of the label to accept text.
Problem: Thai line break position in GEF label are incorrect. For example, some Thai characters cannot be the first character of the line. You can find the linebreak problem in attached screenshot. Please use Java or ICU 's Iterator class to identify word break or line break position for Thai locale. Note: Thai line break within label works correctly in edit mode only.
Regards, Suwit
Created attachment 95896 screen capture
Build ID: I20080330-1350
Steps To Reproduce:
- Run Eclipse 3.4 platform
- Select File->New->Example from menu
- Select Logic Diagram under GEF(Graphical Editing Framework) and click Next > button
- Select the parent folder
- Enter ThaiModel.logic as File name and select Empty Model for Logic Model Samples
- Click Finish button
- Right-click anywhere on the palette and select "Customize..." from the pop-up menu.
- In the dialog that pops up, enter Thai long text without space in the Description's field (Please find the sample Thai text in the attached sampleThaitext.txt file).
- Click OK
- Place mouse pointer over the icon we added Thai text in its description.
- Tooltip text will show up
Test environment: Eclipse 3.4 M6 GEF 3.4 M6 GEF Example 3.4 M6 Operating System: Windows XP SP2 (Regional Setting is Thai)
Problem description: There are no line wrap in tooltip text. All Thai characters are displayed within one line. Please find screen capture in attachment.
It seems that there are no Thai work break implementation there.
Please use Java or ICU 's Iterator class to identify word break or line break position for Thai locale.
Regards, Suwit
If you call setContents(EditPart) on a graphical viewer, it should fire selection changed. I saw a bug where the actions hold on to the previous selection since not selection change event is fired.
I had a request to implement auto-scrolling support when resizing shapes in GMF. In doing this, I realized that GEF's auto-scrolling support is limited to TargetingTools and I don't think it needs to be.
I suggest we support auto-scrolling in GEF when:
- Resizing a shape with the resize handles. This has been specifically requested by multiple clients of GMF (see GMF Bug 111899).
- Selecting multiple shapes with the marquee selection tool. A GEF request already exists for this: Bug 25314. GMF has handled this in its own code already.
- Creating a shape of variable size (i.e. sizing it to extend beyond the viewport). This has been requested in GMF Bug 167243.
I have an implementation to support the resizing shape scenario (patch to be attached), but it requires copying code from TargetingTool to the ResizeTracker as the ResizeTracker does not extend TargetingTool and this is where the auto-scroll behavior is added. Instead, I suggest we move the auto-scroll behavior from TargetingTool to AbstractTool so that other tools (like those mentioned above) could also make use of the auto-scroll behavior.
Another complaint we have had in GMF and I see a similar complaint exists in GEF (see Bug 207053) is that users don't actually know that auto-scrolling is possible because it requires waiting the hover time near the edge of the diagram and there is no feedback to indicate this is what is required. We have fixed this in GMF when moving shapes and creating connections by auto-scrolling sooner and changing the cursor to provide a visual cue that something can happen near the edge of the diagram. I suggest we move this fix into GEF in all the tools that support auto-scrolling. I will attach a patch to illustrate the change required to the DragEditPartsTracker as an example.
Build ID: I20080530-1730
Steps To Reproduce: I have a palette with several drawers with items in each drawer. When I drag/drop any item into my editor, that works fine, but the remaining items in that drawer disappear. If I move my mouse over them or expand/collapse the drawer, they will reappear. This has happened on every version of Eclipse 3.4 that I've tried. It doesn't happen on Windows.
More information: To get around this, on the TemplateTransferDropTargetListener get a handle to the palette and force it to repaint. This works most time, but not always. I'd really like this fixed. It looks pretty ugly in our product. Thanks.
Build ID: I20080523-0100
Right now the plane the viewport slides along is tied to the canvas a diagram occupies. This causes some awkward effects because the canvas is automatically clipped to fit the contents of the diagram.
Example 1:
- place two objects very far away from each other
- zoom in so you can only see the right object on screen
- move the object to the left of the screen
Result: the object will stay on the right edge of the screen, because the canvas has been shrunk to fit, and then the viewport is shifted over to stay within the shrunken canvas. You have to look at the outline view to figure out what's going on.
Example 2: if you want to place an object outside the current canvas bounds (expand the diagram) you have to either zoom out to place it directly, or drop it in the current bounds, then drag it outside the viewport. If dragging outside the viewport for anything but a short distance, multiple drags are required.
Also, seeing separation between the "sheet and the table" would help give feedback about what's going on with the canvas (like auto shrink fitting)
Build ID: I20080523-0100
Steps To Reproduce:
- open logic diagram example
- expand palette to 2 or more tools wide
- open the drawer on the voltage source tool
- close the drawer
More information: when closing the drawer, it flashes over the other tools to fill the entire width of the palette as part of its closing animation
Bug 238595 - SWTGraphics should support pushState() and restoreState() also if non-rectangular clipping is involved.
When specifying clipping not via setClip(Rectangle), but via setClip(Path), currentState.relativeClip is set to null.
Within pushState(), the following check then causes a IllegalStateException to be thrown: if (currentState.relativeClip == null) throw new IllegalStateException("The clipping has been modified in" + //$NON-NLS-1$ "a way that cannot be saved and restored."); //$NON-NLS-1$
Build ID: I20080617-2000
Steps To Reproduce: ZoomComboContributionItem does not treat Combo#setVisibleItemCount. Because of this, not all zoomings won't be displayed if more than 5 items are in the combo. ZoomComboContributionItem should automatically calculate the number of items, or it should have either "setVisibleItemCount" or "getCombo".
Build ID: 3.4.1.v20080716
Steps To Reproduce:
- Call to PaletteViewer.reveal(<>) dosen;t activate the palette entry.
More information: From the code PaletteViewer's reveal method if (part.getParent() != null && part.getParent() instanceof PaletteStackEditPart) ((PaletteStack)part.getParent().getModel()).setActiveEntry((PaletteEntry)part.getModel()); the check is only for the PaletteStackEditPart and not PinnablePaletteStackEditPart causing the problem. It will be good if the "instanceof" check is extende to PinnablePaletteStackEditPart.
Build ID: M20071023-1652
Steps To Reproduce:
- Make a multiple selection (select several nodes) in your GEF editor
- Click in one of the selected nodes
- My application builds a ProgressBar to report the progress spent in a private task
- NullPointerException is thrown
More information: I get a NullPointerException in the method handleButtonUp, because getCurrentViewer() is null. I want to give the user some feedback about a task that's being performed, so to report the progress and allow the cancellation, I've used a ProgressMonitorDialog. This is the situation: when the user clicks a node in my editor I return some info about that node. This exception only happens when, after I select several nodes, I click in one of them... When I click in only one (without previous multiple selection), the progress bar and all the information are displayed.
I believe the problem would be solved with a correction provided in 'org.eclipse.gef.tools.SelectEditPartTracker' class. There is 'null' check missing.
Method 'handleButtonUp(int button)':
protected boolean handleButtonUp(int button) { if (isInState(STATE_DRAG)) { performSelection(); if (getFlag(FLAG_ENABLE_DIRECT_EDIT)) performDirectEdit(); if (button == 1 && getSourceEditPart().getSelected() != EditPart.SELECTED_NONE) getCurrentViewer().reveal(getSourceEditPart()); <-- before this line there should be check: 'getCurrentViewer()!=null' setState(STATE_TERMINAL); return true; } return false; }
Bug 263548 - [Palette] When a stack at the bottom of the palette is opened, the contents of the stack cannot be seen without scrolling down
Build ID: I20081211-1908
Steps To Reproduce:
- Open the Logic Example
- Close the Canned Parts drawer
- resize the eclipse Window so that the V+ stack is close enough to the Canned Parts drawer that another icon could not fit inbetween.
- Open the V+ stack.
More information: This seems a bit ugly. Anyone opening a stack is going to want access to its contents, so it should scroll automatically. All that would need to be done would be to check whether any of the extended pane was below the Drawer/Group that contains it, and scroll the Drawer/Group down by the amount that was hidden.
Build ID: M20090211-1700
Steps To Reproduce:
- Select an edit part in a diagram.
- Enter the accessible drag state.
- Hold down the appropriate snapping disablement button (ALT on Windows, CTRL on Mac), and attempt to move the edit part horizontally (using either the left or right arrow key).
- Vertical snapping disablement works fine.
More information: This appears to be a key binding collision with the navigation actions provided by the Eclipse UI. Alt + (Left|Right) are already registered with the Navigation backward/forward actions.
Build ID: 1.1.0v20080507-1326
Steps To Reproduce:
- Open Rational Requirments Composer and resize to a small screen
- Open a sketch in the sketch editor
- Open the palette and a drawer with many items in it
- Note the scroll bars
More information: After running a usability test on Rational Requirements Composer most people missed the scroll bars within a palette section.
Build ID: I20081211-1908
Right now, figures are blissfully ignorant of the zoom level that lies between them and the screen; however, how they draw themselves should be a function of that zoom level in some cases.
Scaling Down: When rendering themselves to an outline view, there's no point wasting time drawing text or an icon that's going to be 3 pixels high on screen. It may make more sense to draw a gray box instead of text, or use a lower resolution icon.
Scaling Up: On the other end of the scale, at +400% zoom icons start to look pretty crummy because they're scaled up from a tiny image file, and it would hurt performance to scale down a higher resolution one all the time. Again, if the figure knows its true size on screen, it could load an appropriate resource.
Performance Gain: The outline view makes every figure on a diagram consult whatever model is behind it for information, regardless of whether that information is going to get communicated to a user. For example, text in labels of figures that are too small to read in the outline view, and off the page in the main view. Querying the model for those parameters, or listening to it for changes, can be costly and could be avoided until the full sized figure is within the bounds of the main view.
Feature gain: This can be used to implement "semantic zoom" where a figure substantially morphs through zoom levels, for example just showing a "C" icon for a class on a UML diagram in the outline view instead of a full class box, or annotating it with extra details when zoomed in sufficiently.
Implementation: If Graphics just had some property the figure could check in its paint method to make that decision, then it could render differently. I say "some property" because there's room for different designs there.
It could be:
- an arbitrary integer/enum "level of detail"
- the zoom level, effectively a screen pixels/drawn pixel resolution
- the real world resolution, in pixels/inch (combination of zoom level, and Device.getDPI()'s resolution)
Anyone have thoughts on this? Useful? Priority? Preference of implementation? Other ideas of how it could be used?
Created attachment 132960 Inconsistent resource name direction
Build ID: I20090313-0100
Steps To Reproduce: Launch eclipse with RTL environment using -nl iw attribute
- Create a general project contains complex expression (mixed of English and Hebrew text)
- Create a GEF logic diagram
- Click on the project name Result: In the Create logic file wizard in the field of the parent folder the project name has LTR text direction whereas it displayed in the view tree in RTL direction (as it should)
More information: See screenshot attachment
Build ID: I20090313-0100
Steps To Reproduce:
- Launch eclipse in mirrored mode (using dir -rtl attribute)
- Create a simple project in workspace
- Go to File -> New -> Example… -> Logic Diagram and create a logic diagram file
- Create a label in the logic editor that opens up (by dragging a label – under components – from the palette).
- Type in some Bidi text in the label
Result: The label description in outline view has RTL text ordering and thus it is disordered. It should have LTR text direction in order to display it correctly. See attached screenshot for illustration.
More information:
Created attachment 133244 Outline view is disordered with multline label
Build ID: I20090313-0100
Steps To Reproduce:
- Launch eclipse in mirrored mode (using dir -rtl attribute)
- Create a simple project in workspace
- Go to File -> New -> Example… -> Logic Diagram and create a logic diagram file
- Create a label in the logic editor that opens up (by dragging a label – under components – from the palette).
- Type in some Engish text in the label in multiple lines (Type Enter in the end of each line)
Result: The label description in outline view is curropted. See attached screenshot for illustration.
More information:
Build ID: I20090313-0100
Steps To Reproduce:
- Launch eclipse in mirrored mode (using dir -rtl attribute)
- Create a simple project in workspace
- Go to File -> New -> Example… -> Logic Diagram and create a model file contains mixed text name
Result: The model file name has RTL text direction in the model view whereas it has LTR direction in the package explorer view.
More information:
Bug 274567 - [Palette] BIDI3.5:Wrong shaping for digits in Customize Palette dialog and in Logic editor
Created attachment 133993 Snap shots for the defects
Build ID: I20090313-0100
Steps To Reproduce: Platform : Windows vista
1-Open the eclipse 2-Go to File->New->Other->General->Project 3-Add Arabic name mixed with numbers for the project name and then press finish
4-Go to File->New->Example->GEF->Logic diagram and hit Next.
Be sure to select Logic Diagram and not Logic under the GEF (Graphical Editing Framework) Plug-ins
5- give the new file an Arabic name.
6-Create a label in the logic editor that opens up (by dragging a label - under components - from the palette).
7-Edit the label text in the logic editor and enter an Arabic text mixe with digits
Check Result 1
8-Right-click anywhere on the palette and select "Customize" from the pop-up menu. 9-In the dialog that pops up, select the tree item labeled "Components." You should be able to edit its name and description by typing Arabic text and numbers in the areas on the right-hand side of the tree 10-press ok to close the dialog 11-View the changes you applied on the palette component name and hover the mouse to check the description
Check result 2
Expected Results
Result 1:Arabic text and numerals are displayed and shaped correctly in the label inside the logic editor Result 2:Arabic text and numerals are displayed and shaped correctly
Actual Results:
Result 1:When editing in the text in the label the numerals are shaped correctly (check screen shot LabelInLogicEditor_underFocus_Result1.JPG) However the numerals are shaped wrongly it is shaped as Arabic European digits instead of Arabic indic digits after losing the focus (check screen shot LogicEditor_Result1.JPG)
Result 2:When editing in the customize palette editor ,Arabic and numeral are displayed and shaped correctly(check screen shot CustomizeEditingdialog_Result2.JPG) However after pressing ok and hover over the component to check the new description for the component , the numerals are shaped wrongly it is shaped as Arabic European digits instead of Arabic indic digits(check screen shot CustomizeEdit_Result2.JPG)
More information:
Use the logic example to reproduce the problem:
-
Add 3 labels. Set their text to 1, 2, 3 and order them accordingly.
-
In the Outline view select labels 2 and 3 and drag them to the first position
-
Now the order of labels is 3, 2, 1 but should be 2, 3, 1
I am not sure what the solution should be. Looks like the LogicTreeContainerEditPolicy#getMoveChildrenCommand is called once for each edit part instead of being called once for all of them.
Build ID: Build id: M20090211-1700
Steps To Reproduce: In GEF the GridLayout layout manager ignores the vertical indent. The horizontal indent is displayed as excepted. If you look in the source code you'll find parts which exclude the verticalIndent attribute of the GridData.
More information:
Build ID: 20090619-0625
Steps To Reproduce:
- Add the zoom actions and combo box to the editor tool bar.
- Use zoom factors 0.25, 0.5, 0.75 and 1.0, add also FIT_ALL, FIT_HEIGHT and FIT_WIDTH
- Use mouse wheel in combo box to change the zoom level.
- If you scroll to 100% and then scroll more then it does not stop at 100% but jumps to xx% which is the same as FIT_ALL. Next is FIT_HEIGHT.
More information: I expected that it goes to 100% then then shows me not the percantage of FIT_ALL but shows me the word "page" like it does, when you open the combo box list and select the word "page".
Created attachment 143239 Horizontal right alignment
Build ID: 20090619-0625
Steps To Reproduce: 1.Create a figure with layout manager GridLayout and numcolumns=3 2.add 3 figures to first figure 3.set horizontal alignment to right. 4. You will see spaces between the 3 figures which should be not there.
More information: If you compare the 3 possible alignments left, center and right, then right should look like left but all childs should clue on the right border.
<response_by> Shenia Tang at 2009.08.17.13.06.47 </response_by> NLS Build Label:20090816-0100-nl1-win32
Language: T.Chinese
Must-Fix: no
Steps To Recreate Problem: In the main menu find the Zoom Manager
Problem Description: The width of the Zoom Manager is too narrow to truncate the percentage strings
<response_by> Matthew McClintock at 2009.08.19.21.49.13 </response_by> When testing this, I encountered a similar problem with the first number of the selected zoom percentage. This number is truncated in T. Chinese, but it is displayed correctly in English.
For an example of this problem, please compare the two attached screenshots, one in English, and the other in T.Chinese:
PercentZoom_ENG.png PercentZoom_CHT.png
I believe this may be due to the fact that the English strings "Page", "Width", and "Height" are longer than the T.Chinese translations of those strings. As a result, the English field is long enough to display the percentage correctly, but the T.Chinese field is not. Would it be possible to set a minimum size for this drop down field?
Regarding the truncation of the % sign in the drop down menu, that may just be caused by the low resolution on the test machines. I tested this problem on two different machines, and I didn't encounter this problem, just the one mentioned above.
Thank you, Matthew McClintock
<response_by> Matthew McClintock at 2009.08.19.21.50.22 </response_by> This article was reassigned from Category:''TVT/Testing,Inbox''.
Bug 288754 - ZoomManager doesn't provide mechanizm to define is the current zoom value FIT_HEIGHT or FIT_WIDTH or FIT_PAGE value
getFitHeightZoomLevel, getFitPageZoomLevel and getFitWidthZoomLevel are protected - why?
Bug 288757 - org.eclipse.gef.examples.logic - zoom combobox - if you select Page, Width or Height - will get 2 different results in some cases
It is easy reprodusable - just select firstly in zoom combobox - Width - get result and then once again Width - get other result. In my particular case first Width selection - result zoom is 103%, second Width selection - result zoom is 106%, third - 103%, 4th - 106%, etc. If it is not reproducable in your case - just try to vary editor window size and you'll reproduce it.
I do not sure is Component Examples right component here, cause it is look like common Zoom bug.
The default anchors used by AbstractConnectionEditPart.getTarget/SourceConnectionAnchor(), i.e. DEFAULT_TARGET_ANCHOR and DEFAULT_SOURCE_ANCHOR resp., should be made public. As stated in bug #29919 (https://bugs.eclipse.org/29919), these anchors are "only there to let the developer know that something went wrong". Now, it is impossible to check that if the instance cannot be retrieved. E.g, it is impossible to do something like that in a derived class:
ConnectionAnchor anchor = super.getTargetConnectionAnchor(); if (anchor==DEFAULT_TARGET_ANCHOR) { .... // something went wrong }
Background: I need this for a 3D version of AbstractConnectionEditPart, because in case of 3D (in the GEF3D project) the default anchors must be 3D anchors. I certainly could copy the original behaviour or getTargetConnectionAnchor() and simply return a DEFAULT_TARGET_ANCHOR_3D instead of a 2D version (which I have to do as a workaround), but I would prefer to copy as little as possible -- and I also think it's a general issue.
Cheers
Jens
BTW: Maybe it would be a good idea to make these default anchors immutable as well, as they could be changed even when they are private.
Here is an immutable version:
/**
-
ImmutableXYAnchor used for default anchors, all setters are overridden
-
to avoid changing an instance of this class.
-
@author Jens von Pilgrim
-
@since Sep 25, 2009 */ public class ImmutableXYAnchor extends XYAnchor {
/**
- Creates an immutable xy anchor with the given location.
- @param i_p */ public ImmutableXYAnchor(Point i_p) { super(i_p); }
/**
- As this class is immutable, this method throws an
- {@link UnsupportedOperationException}.
- @see org.eclipse.draw2d.XYAnchor#setLocation(org.eclipse.draw2d.geometry.Point) */ @Override public void setLocation(Point i_p) { throw new UnsupportedOperationException("Anchor is immutable"); }
/**
- As this class is immutable, no events will ever been thrown.
- Thus, this method does nothing.
- @see org.eclipse.draw2d.ConnectionAnchorBase#addAnchorListener(org.eclipse.draw2d.AnchorListener) */ @Override public void addAnchorListener(AnchorListener i_listener) { } }
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.15) Gecko/2009101601 Firefox/3.0.15 Build Identifier: 20090619-0625
There is no check for null pointer in
AbstractEditPartViewer.addSelectionChangedListener(ISelectionChangedListener listener).
If I add the null listener there is no exception raised. But after that the AbstractEditPartViewer.fireSelectionChanged() method works wrong, because there is no any protection against null pointer exception inside. Thus the firing of selection listeners is stopped, after the null listener is reached.
Reproducible: Always
Steps to Reproduce: /*
- here I get a graphical
- viewer (any implementation for org.eclipse.gef.GraphicalViewer,
- viewer is inheritor of org.eclipse.gef.ui.parts.AbstractEditPartViewer) / GraphicalViewer viewer = ... ; /
- here I create changes listener
/ ISelectionChangedListener listener = ...; /
- here I assign the null listener,
- no exception is raised / viewer.addSelectionListener(null); /
- here I assign the null listener,
- no exception is raised / viewer.addSelectionListener(null); /
- here I assign the null listener,
- no exception is raised */ viewer.addSelectionListener(null);
/*
- here I assign the null listener,
- no exception is raised */ viewer.addSelectionListener(listener);
/*
- last listener will never be executed in
- the current AbstractEditPartViewer.fireSelectionChanged() implementation
*/
Build Identifier: Build id: I20091030-1201
I have created a file using GEF Flow example, When opened using Flow Example editor you can see that the a particular sub graph (parallel flow is not visible fully),
I can implemented a flow chart using the same graphlayoutmanager principle in that this type of error occurs frequently.
I will attach both files so that you can view them.
Reproducible: Always
Steps to Reproduce: 1.Take GEF Flow example plugin. 2.Run it as an eclipse application. 3.Open the attached layouterror.flow in GEF FLOW editor. 4.At the end of the diagram you can see a particular subgraph(parallel flow not visible fully)
Bug 302064 - [EditPolicy] LayoutEditPolicies should check whether the content pane's layout manager is compatible.
Build Identifier:
Up to now, layout edit policies do not assert that the layout manager of their layout container (the host's content pane) is a compatible one. This is a likely pitfall that could easily be prevented by adding a respective assertion within setHost().
Just a comment: bug #302062 would allow to also perform such a check within ConstrainedLayoutEditPolicy be means of something like: Assert.isLegal(getLayoutContainer().getLayoutManager() instanceof ConstrainedLayoutManager);
Reproducible: Always
Build Identifier: M20100211-1343
Palette entries' names and descriptions wrap up but not always at the point where word breaks when using some Unicode signs.
Reproducible: Always
Steps to Reproduce:
- This can easily be tested with GMF. Generate a basic diagram editor.
- Modify the messages.properties file in the generated project.
- See the value "\uff22\uff4f\uff52\uff44\uff45\uff52\uff45\uff44 \uff23\uff49\uff52\uff43\uff4c\uff45" into the title of one of the *CreationTool_title entries.
- Run the editor. Resize the palette. You should observe the string wrapped up like in the attached screenshot.
Bug 307383 - Multiple selection at org.eclipse.gef.ui.parts.TreeViewer using Shift key doesn't work correctly.
Build Identifier: M20100211-1343
Multiple selection using the shift key isn't possible at some cases - If the tree contains both modifiable and non-modifiable nodes. There is private boolean ignore; flag at org.eclipse.gef.ui.parts.TreeViewer class which determines whether the selection should be done or not. When you try to do multiple selection with the help of the shift key at modifiable nodes of the tree the method private void showSelectionInTree() is called two times. First time the private boolean ignore flag is true and second time is false. But first time should be false and second time should be true. This causes the shift key has similar behaviour like ctrl key.
Reproducible: Always
Steps to Reproduce:
- Create some Eclipse plugin which uses Outline.
- Create some content of the Outline with the help of org.eclipse.gef.ui.parts.TreeViewer class (nodes are non-modifiable and leafs are modifiable). Set edit domain for the TreeViewer.
- Run the plugin and try to do multiple selection from leaf to another leaf with the help of the shift key. Shift key works in the way of the ctrl key (but it works well from node to node because the nodes are non-modifiable).
Build Identifier: I20100313-1044
In GEF WYSIWYG examples, the highlight doesn't work correctly for Arabic language.
Reproducible: Always
Steps to Reproduce: 1.In Redhat Linux 5 OS, open eclipse in rtl mode , using -nl ar_EG 2.Press file->new->project 3.Enter an Arabic project name then press finish. 4.Select the project and right click, choose new -> examples -> GEF 5.Choose GEF WYSIWYG document example. Name the file any Arabic name. 6.Highlight any of the text in the file.
Expected result The text is highlighted correctly
Actual Result : The text disappears when we highlight a certain word or select a few lines.
Note : This bug doesn’t happen in English locales.
Build Identifier: I20100330-0800
The bracket is swapped
Reproducible: Always
Steps to Reproduce: Note: This scenario is assuming that the GEF examples package are including in eclipse.
- Launch eclipse using -nl he attribute in order to enable RTL orientation
- Select File -> New -> Example
Result: In the section of the GEF (Graphical Editiong Framework)on the New Examples wizard the last bracket is swapped See attached screenshot
Build Identifier: 20100218-1602
Text boxes for GEF figures are incorrectly drew when windows system font is set to Large or greater.
Reproducible: Always
Steps to Reproduce:
- Open GEF Flow example
- enter windows control panel->display->appearance
- set font size to Large, or Extra Large
Build Identifier: 20090920-1017
Palette entry icons that are transparent PNGs are rendered incorrectly when the palette entries are selected (the icon background area typically turns black for a white palette background).
This bug is probably related to the numerous other transparent PNG bugs were the icons were rendered incorrectly in various controls, but many of these issues have now been fixed while the problem remains for the GEF palette.
Reproducible: Always
Steps to Reproduce:
- In an existing GEF app that provides a palette, add a transparent png icon to one of the palette entries (like a TemplatePaletteEntry). Use for example the following png: https://bugs.eclipse.org/bugs/attachment.cgi?id=19921
- Run the app, and notice that when the palette entry is selected, the icon background turns black (the icon background area for this particular icon is not very large, so only a small area turns black)
<response_by> Keiko Terada at 2010.05.11.04.24.37 </response_by> NLS Build Label: 20100509-1500 Language: Japanese Must-Fix: No
Problem description: Rulers are truncated. I may have reported this in the previous release...
- The Logic Example should now be open with a complex drawing on it.
- Drag the LED that displays "10" to a new location.
- Select one of the large panels (circuits). Handles should appear.
- Click and drag one of the handles to resize the panel.
- Select Circuit from the Palette and drop a circuit into some empty space
- Now create a connection inside that circuit. Select Connection from the Palette.
- Click once inside the top of one of the circuits, and then click again inside the bottom of the same circuit.
- Click the Selection tool in the palette and select the connection you just created and delete it from the edit menu.
- Right-click on the LED displaying "7" and select Decrement.
- Open the properties view and select a circuit.
- Expand the Location property, edit the X property and press Enter.
- If the rulers are not visible, go to the View menu and enable them. Right-click anywhere on either of the rulers to bring up its context menu
- Create a guide.
- Verify that the Undo Create Guide option is translated.
<response_by> igultek at 2010.05.11.14.24.14 </response_by> This article was reassigned from Category:''TVT/Testing,Inbox''.
<response_by> cema tester 13 at 2010.06.09.13.17.11 </response_by> NLS Build Label: 20100608-1400 Language: Hungairan Must fix: N/A
Problem description: One national character is not displayed normally in Print panel in as it can be seen from the attached screenshot. I checked the related rc file (DiagramPrint.rc), but I found everything OK. As I now that it's hard to fix rc file based problem I set the related Testcase completed.
Steps:
- Create a normal Project, and than a Geoshape diagram by rightclick on the project-> new-> example-> Geoshape diagram 2)Double click geoshapes diagram you just created to view it, if it is not already displayed
- Navigate to File > Print Preview.
- Select the Print icon.
If ScrollingGraphicalViewer.reveal is called while workbench shutdown is in progress, the call to getFigureCanvas can return null, resulting in an NPE at line 89. There may be other cases where this occurs, but workbench shutdown is the only one I have observed to date.
Build Identifier: I20100608-0911/Helios/3.6
When direct editing any label when current value is selected leads to a NPE.
When the value is NOT selected, it works until the string is empty. Then it crashes again.
Reproducible: Always
Steps to Reproduce:
- Install GEF Examples
- Open Flow Example
- Select an EditPart, e.g. an Activity
- Press F2 -> it goes into direct editing, selecting the whole value
- Type a character, e.g. "a" -> NPE
Build Identifier: I20100608-0911
We have a professional Eclipse-based tool that uses a FormEditor with multiple tabs (FormPages). One of those contains a GEF graph editor with a Flyout Palette. In Eclipse 3.5 (on Mac only) there was a problem that the palette was sometimes becoming invisible, and the user had to resize the window or move the sash to actually see it.
But with Helios this situation has become significantly worse, and now the areas of the FormPage (including the button tool bar and the graph itself) are invisible most of the time. The screen flickers and only if scrollbars are visible, the graph is visible too. Otherwise it's just a grey area.
I have managed to reproduce this problem in a simpler case, and I attach a demo plugin. The plugin is basically the same as the one used by Koen Ars EclipseCon 2008 tutorial: http://www.eclipsecon.org/2008/?page=sub/&id=102. The only difference is that the GraphEditor is a subclass of FormEditor, and that I am inserting the GEF component into a FormPage. The key bit of code is this:
protected void addPages() {
FormPage page = new FormPage(this, "XY", "TAB") {
@Override
protected void createFormContent(IManagedForm managedForm) {
super.createFormContent(managedForm);
Composite body = managedForm.getForm().getBody();
body.setLayout(new GridLayout());
SashForm form = new SashForm(body, SWT.HORIZONTAL);
form.setLayoutData(new GridData(GridData.FILL_BOTH));
createPaletteViewer(form);
createGraphViewer(form);
form.setWeights(new int[] { 15, 85 });
managedForm.getForm().getToolBarManager().add(new Action("Test") { } );
managedForm.getForm().getToolBarManager().update(false);
}
};
try {
addPage(page);
}
catch(PartInitException ex) {
ex.printStackTrace();
}
}
See steps to reproduce. I believe this happens more often if the tool bar contains anything, and also only in conjunction with the palette. Maybe there is an exception in the middle of the drawing subroutine.
While this particular example seems to be uncritical, I suspect that this is the same bug that we are seeing in our commercial tool, and there it happens much more reliably and the situation is a blocker for us.
I would like to understand whether this is indeed a bug or whether placing a paletteViewer inside a Form is simply not supported and I need to work around it. Many thanks.
Reproducible: Always
Steps to Reproduce: 1.Install the plugin (that I am trying to attach to this bug report) 2.Create an empty file ending with .par 3.Open the .par file in the Graphical editor (this plugin) 4. Move the divider between the Navigator and the Graph Editor You should see the whole page flickering, and on many pixels, the whole content disappears
Build Identifier: All
Due to the whole idea behind the HandleBounds interface, I think GEF viewers should honor the handlebounds() if the target is HandleBounds instance...
Reproducible: Always
Comment from Randy Hudson on bug #160482:
[...] sounds like there is behavior in DragEditPartsTracker that might be useful in other tools.
DragEditPartsTracker stores a relative coordinate, and has a repair method that updates the absolute start point when auto-scroll happens.
Maybe marquee, dragging bendpoints, etc., all need to invoke autoscroll, and so they all need this repairStartLocation method.
In reference to this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=142336
- scrollwheel drag (or middle drag, or Ctrl-left drag) to pan. As the user drags, whatever was under the pointer at the time the drag was initiated would remain under the pointer throughought the drag until, of course, the drag was released.
I search a little into it, it seems to me that there is a missing capture a event combination: in org.eclipse.gef.ui.parts.DomainEventDispatcher, in the method dispatchMouseMoved(org.eclipse.swt.events.MouseEvent me), it doesn't detect that the scrollwheel is pushed. The state mask seems to not be properly updated during dispatchMousepressed(org.eclipse.swt.events.MouseEvent me).
Currently, AbstractEditPartViewer and SelectionManager handle focus as follows:
- select(EditPart) will not change focus if the edit part to be selected already is the focus part; it will unset the focus part (and notify the former focus part about loss of focus) otherwise.
- appendSelection(EditPart) will not change focus if the appended edit part already is the focus part; it will unset the focus part (and notify the former focus part about loss of focus) otherwise.
- deselect does not affect focus at all.
- deselectAll unsets focus part, notifying the former focus part about loss of focus.
While this is not really an inconsistency I think it may be hard to understand for clients that a primary selected edit part may either explicitly (if it was the focus part before being selected) as well as implicitly (if there is no focus part) have focus, and that it may or may not get notified about gain/loss of focus (if the viewer gains or looses focus) dependent on its former state. Further, an explicit focus part may not only be set in case it differs from the primary selection, but also in case it corresponds to it; while on the other side, a primary selected edit part may also have (implicit) focus while not being the focus part.
To improve understandability I think it would be better that an explicit focus part is only set in case it differs from the primary selection (or in case there is no selection and an edit part other than the contents or root should have focus). This way, an edit part that has keyboard focus may either be the explicit focus part (in case not being selected primary) or it may be the implicit focus part (when being selected primary and no other edit part is set as explicit focus part) and both states could be clearly separated.
Concerning the notification of edit parts about gaining and loosing focus (via EditPart#setFocus()), I think the two following options would be consistent:
a) every edit part that gains/looses focus should be notified about this (via EditPart#setFocus()), independent of whether it is the explicit or implicit (being the primary selection) focus part of the viewer.
b) only the explicit focus part should be notified about gain/loss of focus (via EditPart#getFocus()). An implicit focus part (primary selected) should not get notified.
While b) is the current behavior, which pretty much corresponds to what is needed for how focus is displayed today (implicit focus part do only show their primary selection state and no explicit focus border), I think a) would be the more consistent option. This way, the fact that the edit part viewer gains or looses focus could e.g. be graphically displayed by implicit (primary selected) focus parts as well. Further, clients could rely on the fact that - in case an edit part gains or looses focus - it always gets notified about this.
Build Identifier: Eclipse 3.4, perhaps others
Please see https://bugs.eclipse.org/bugs/show_bug.cgi?id=337574 for the full text. This defect is being opened to address the GEF-specific issues:
- palette
- making connections
Reproducible: Always
Steps to Reproduce: See full text in referenced defect.
According to bug 80561 canvas is limited by the OS. It would be nice to have an unlimited canvas, which displays only visible elements, and you can easily scroll it.
We could avoid bugs like https://bugs.eclipse.org/bugs/show_bug.cgi?id=340475
Hi,
when opening a GEF editor (e.g. the logic sample) the toolbar actions are visualized only by text. The icons are not shown. It seems that the icons are not packaged into the bundle. I see the problem when testing milestone 2 of 4.2/3.8.
My IDE contains version: org.eclipse.gef (3.7.1.v20110830-1143)
Best, Tim
Build Identifier: 20110615-0604
Since I want to put some SWT controls on the palette, I cannot do this using the current palette implementation because it is based on GEF itself. As I can see, the only way to provide components like combo boxes, lists, text fields etc. on the palette is to re-implement them by extending Draw2D figures. But that is an laborious task and therefore I suggest to source out the concrete palette implementation from the EditDomain class. My attached solution introduces a further EditDomain class called EditDomainWithPalette which then represents the base for the already existing DefaultEditDomain. For a successful outsourcing, the EditDomain class needs to become abstract because understandably the method loadDefaultTool() does not know how to determine the default tool. As from now, the concrete extensions of EditDomain shall ensure to implement this method (e.g. EditDomainWithPalette). Due to making EditDomain abstract, the class PaletteViewerProvider also needs to be adapted. In this class, every reference to EditDomain must be replaced with a reference to EditDomainWithPalette. Of course with the proposed solution, the API of GEF 3.x breaks at some points. But I think that only few available projects are affected by this API evolution because every GEF project that I've seen so far is based on DefaultEditDomain, and not directly on EditDomain.
Reproducible: Always
while ToggleRulerVisibilityAction was both added to contextmenu and workbench menu,the state of ruler menuitem can't disppear properly the reason is because of the methods isChecked() and run() when the ruler menuitem in contextmenu was clicked twice,the state of menuitem is different from the GraphicsViewer PROPERTY_RULER_VISIBILITY property advise : the method isChecked() shuld not be over written the method shuld beover written as below public void run() { diagramViewer.setProperty(RulerProvider.PROPERTY_RULER_VISIBILITY, new Boolean(isChecked())); }
I've created a diagram that represents the same model element both as a connection and an edit part. When I do that, the code fails with a ClassCastException. See below.
The issue is that the following code assumes that if an edit part exists for a model in the same registry, there will be one and only one and that if it exists it will be a connection. This is a reasonable enough assumption in the primary case, though of course there are cases where multiple edit parts exist for the same model object, and this needs to be over-riden for the specific edit part. However, it seems like it would be straightforward distinguish for the case of connections, perhaps by storing them in their another registry. There might even be performance advantages to doing so.
protected ConnectionEditPart createOrFindConnection(Object model) {
ConnectionEditPart conx = (ConnectionEditPart) getViewer()
.getEditPartRegistry().get(model);
if (conx != null)
return conx;
return createConnection(model);
}
java.lang.ClassCastException: com.tasktop.internal.sync.architect.editparts.ConnectedHostEditPart cannot be cast to org.eclipse.gef.ConnectionEditPart at org.eclipse.gef.editparts.AbstractGraphicalEditPart.createOrFindConnection(AbstractGraphicalEditPart.java:336) at org.eclipse.gef.editparts.AbstractGraphicalEditPart.refreshSourceConnections(AbstractGraphicalEditPart.java:696) at org.eclipse.gef.editparts.AbstractGraphicalEditPart.refresh(AbstractGraphicalEditPart.java:645) at org.eclipse.gef.editparts.AbstractEditPart.addNotify(AbstractEditPart.java:253) at org.eclipse.gef.editparts.AbstractGraphicalEditPart.addNotify(AbstractGraphicalEditPart.java:223) at org.eclipse.gef.editparts.AbstractEditPart.addChild(AbstractEditPart.java:212) at org.eclipse.gef.editparts.AbstractEditPart.refreshChildren(AbstractEditPart.java:781)
Build Identifier:
This issue is related to Bug 154145, but it's not the same. The current approach in PaletteEditPart to create images is via a static ImageCache. Images are created once and then never disposed. This is an issue in my case as the palette contents is more dynamic and can change at runtime. Since images are never disposed the application runs out of SWT resources at some point.
I think a proper solution should use a ResourceManager that is passed down into the edit part using a viewer property. If there is no ResourceManager then the code can fall back to using ImageCache. This way the host application can better control the lifecycle of images. It can choose to pre-allocate images to match current behavior or create them on demand. The ResourceManager can also be shared between multiple palettes to allow for image reuse.
I created a patch for what I have in mind. Note that when the descriptor changes, a new image is created first and old descriptor is destroyed after. This way if the descriptor is the same (equals) then the image is reused.
Reproducible: Always
Bug 380586 - ScrollingGraphicalViewer won't scroll automatically when moving nodes outside of viewer's visible area
In GEF based graphical editors, if I drag a node outside the visible area of the editor's canvas, scrollbars will appear after the mouse is released. But the editor won't scroll to reveal the dragged node. User has to scroll the editor manually in order to see the dragged node.
I've tried to call ScrollingGraphicalViewer's reveal() method after the node is dragged. It only works if part of the node is still in the current visible area of the canvas. If the node is moved "far" away, it won't scroll the editor to reveal the node.
Is there a workaround for this issue?
Build Identifier: Version: 3.7.2 Build id: M20120208-0800
The class CreateRequest in the org.eclipse.gef.requests does not extend the LocationRequest class from the same package, instead of subclassing it simply reimplements the whole functionality. I confirmed this in the 3.7_maintenance and master branch of the eclipse git repository aswell.
Reproducible: Always
Fixed via https://github.com/eclipse-gef/gef-classic/pull/795
Build Identifier: Version:3.5.2 Build id: M20100211-1343
Zoom In/Out toolbar buttons are not disabled for minimum or maximum zoom values. For minimum zoom value say, 1% zoomOut toolbar button is not disabled. It is disabled only when the mouse is taken away from the button.
Same behavior is noticed in Zoom In behavior for maximum zoom value say, 1000%
Reproducible: Always
Steps to Reproduce: 1.Enable Zoom In/Out Actions for the graphical editor 2.Zoom in to the minimum value by clicking on the ZoomIn toolbar button 3.Mouse should remain on the toolbar button.
It is noticed that this button is disabled only when moving the mouse away from the toolbar button
Build Identifier: Version: 4.2.1 Buid id: J20120711-1640
Because it's uncomfortable to enter Hebrew or Arabic text in LTR direction, the BIDI end-user expects possibility to set base text direction of component and have it persisted in in-cell editor.
The problem is described in details here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=273198
Reproducible: Always
Steps to Reproduce:
- Create new Logic Diagram
- Pick up Label from Pallete and draw it in the model editor
- Double-click on the label to open in-cell editor and enter mixed English-Hebrew or English-Arabic text, The text direction is LTR.
- Press on Right Ctrl+Shift. The text direction becomes RTL.
- Click in space out of the Label to exit in-cell editor. The text direction becomes LTR once, again, and the text looks differently from when it was in the in-cell editor.
- Enter the in-cell editor once again - the text direction is LTR. RTL direction that was set in the previous time was not kept.
Created attachment 223155 Patch for GEF logic example that adds a drop listener for resources
I am trying to implement drag & drop of resource files from Project Explorer into a GEF editor. When the file is dragged over I want to show some feedback under the mouse cursor. This results in a bad repaint issue on Windows only. Specifically the area under the dragged image is not repainted correctly.
I created 2 test cases that show what happens. One is a patch for Logic example that adds a drop listener for resources. Dragging files from Project Explorer over a Circuit or Flow Container shows the repaint issue.
Second test case is pure SWT but which uses the same technique GEF does. Specifically, it calls Control#update method on drag over. This is what GEF essentially does by calling Viewer#flush() (see DeferredUpdateManager#repairDamage).
After looking through differences between platforms I narrowed my search to the following code in DropTarget class:
DropTarget#DragOver { ... notifyListeners(event.type, event); refresh(); ... }
The notify listeners method calls the drop listeners. But there is an additional call to refresh on Windows platform. Refresh method seems to do some additional repaint like this:
void refresh() { if (control == null || control.isDisposed()) return; int /long/ handle = control.handle; RECT lpRect = new RECT(); if (OS.GetUpdateRect(handle, lpRect, false)) { OS.ImageList_DragShowNolock(false); OS.RedrawWindow(handle, lpRect, 0, OS.RDW_UPDATENOW | OS.RDW_INVALIDATE); OS.ImageList_DragShowNolock(true); } }
I found another SWT bug Bug 218823 that looks similar but I am not sure this is the same issue.
It this cannot be fixed then please suggest some workarounds. Not using a drag image is out of the question as it's done in platform code.
Created attachment 246526 palette tooltip out of screen
The palette tooltip is out of screen. In every palette i saw it's the same problem e.g. new sirius class diagramm, graphiti example etc.
PrintAction() does not handle the fit to print size option on printer. The result is multiple pages instead of arranging the printout onto one page. Eclipse Version: 3.8.0 PrintAction printAction = new PrintAction( HandlerUtil.getActivePart( ExectuionEvent ) );
The current alignment action only works within the same parent. In the eclipse BPMN-modeler project it would be a great improvement if it would work across different lanes.
The part responsible is in the getOperationSet():
EditPart parent = ((EditPart) editparts.get(0)).getParent(); for (int i = 1; i < editparts.size(); i++) { EditPart part = (EditPart) editparts.get(i); if (part.getParent() != parent) return Collections.EMPTY_LIST; }
If it is too troublesome to implement, a solution might be to work with a flag, passed in the constructor e.g.:
public AlignmentAction(IWorkbenchPart part, int align, boolean allowDifferentParent)
The default constructor would pass 'false'.
GEF (Legacy) uses custom Drag&Drop cursors created in SharedCursors class. Unfortunately these cursors do not work correctly on HiDPI displays and show up in their unscaled version and look very small.
I believe that the original problem is in SWT and filed Bug 515794 for that. There is an attached image that shows the described problem. Depending on the proposed solution, GEF will most probably also need to adapt its code.
I know that GEF Legacy is in maintenance mode, however with recent developments for HiDPI GEF stays too far behind to be 100% usable with new versions of Eclipse.
A minimal update would consist in adopting new HiDPI APIs and providing x2 resources for icons and other images. For icons it would mean providing an SVG version that can then be exported to different resolutions.
Bug 519210 - Compatibility issue: Can not select the component in the palette by clicking on the component name.
Created attachment 269207 the sample for testing.
We have a product which is based the eclipse plugin development, we use the gef to create myself the Palette, when we update the eclipse from 4.4 to 4.6, the gef version from 3.9.100 to 3.11.0, the component can't select in the palette if you click the its name. I attached a the simple eclipse plugin sample.
Test steps: 1.Import this plugin into the eclipse 4.6 (Neon.3). 2.Run as a eclipse application. 3.Create a project, and new a xml file. 4.Open the xml file to use the default xml editor. 5.You will see the a Palette is created in the xml editor. Like: Component Button 6.Please click the "Button" name, it is not selected, but the same code, it can be selected in the eclipse 4.4 (gef 3.11.0).
Created attachment 270215 Rendering problem on HiDPI display
GEF uses images in RulerFigure to draw rotated texts in vertical rulers. This doesn't work with HiDPI images as no hires image is created. See the attached screenshot of what the result looks like on Windows with 200% scaling.
I've created a patch that uses native GC rotation to draw rotated text. I figure that the code that uses rotated images dates back to the early stages of SWT, and rotated images where used as a workaround for missing rotation transform in GC. This shouldn't be a problem anymore.
I'm attaching a patch that uses native rotation to fix this issue, and a screenshot that shows the end result. Please consider including this patch in the next version.
Created attachment 270285 Error log
Eclipse 3.6.2 and Eclipse 3.7.0 GEF (MVC) SDK 3.11.0.201606061308
- New GEF Example (Flow, Shapes, etc)
- Go through wizard
- Hit Finish button
- Nothing happens
- Error written to log (attached)
in the newer eclipse version GEF 3 is still part of the release. so the language packs for GEF 3 should also be included in the babel gef feature. ATM there are only the translations for GEF 5 contained.
i already entered the bug for the babel project: https://bugs.eclipse.org/bugs/show_bug.cgi?id=543654
as they mentioned there the are just following the release informations from Eclipse SimRel release. is there a way of getting the old translations also into the new feature?
When creating a product providing preferences from a customization .ini file, with for exemple :
#Palette layout in detail mode by default org.eclipse.gef/Layout\u0020Setting=3
This property value is overriden by org.eclipse.gef.ui.palette.DefaultPaletteViewerPreferences.DefaultPaletteViewerPreferences(IPreferenceStore store) constructor.
Bug 338587 - GraphicalViewerImpl.findObjectAtExcluding() exclusionSet tested for IFigures instead of EditParts
According to the documentation for "EditPartViewer.findObjectAtExcluding(location, exclusionSet)", the exclusionSet parameter is a set of EditParts to be excluded from the search.
However, the implementation of this method in GraphicalViewerImpl uses the ExclusionSearch class which incorrectly tests the exclusionSet collection for the presence of IFigures instead of EditParts.
The implementation of this method in TreeViewer correctly tests the exclusionSet parameter against EditParts.
DefaultPaletteViewerPreferences adds listeners to the preference store and the font registry. Because DefaultPaletteViewerPreferences never removes the listeners, it consumes memory even when PaletteViewer is released.
I know it is static for Logic Editor and its memory usage is small but I want to create a subclass of DefaultPaletteViewerPreferences for my palette implementation.
Create a logic diagram that is taller than it is wider. Zoom to a level such that the entire diagram fits on the screen (no scrollbars). Select Fit to Width from the drop-down. You'll see that both the horizontal and vertical scrollbars appear at this new zoom level. It seems "fit to" options are not taking into account the possibility of scrollbars showing up.
Build Identifier: I20100330-0800
The arrow icons using for expand and hide the palette should be flipped in RTL mode i.e right arrow for expanding and left arrow in order to hide it.
Reproducible: Always
Steps to Reproduce:
- Launch eclipse using -nl he attribute in order to enable RTL orientation
- Select File -> New -> Example -> Logic Diagram and hit "Next."
- In the new logic file dialog type some file name and click Finish
Result: In the logic editor that opens up, the appropriate arrow icons for the palette are flipped. See attached screenshots
Build Identifier: I20100313-1044
Caret and cursor positions are not in sync in WYSIWYG document therefore the HOME, END ,RIGHT_ARROW and LEFT_ARROW do not work appropriately
Reproducible: Always
Steps to Reproduce:
-
Launch eclipse with Arabic locale (eclipse.exe - nl ar_EG)
-
Create a file using the WYSIWYG document file wizard.
-
Try inserting mixed Arabic and English text.
-
Then click on the line or move using up and down keys, try LEFT_ARROW, RIGHT_ARROW, HOME and END, inspect the cursor and caret movement in this editor
Expected Results
-
Keys like LEFT_ARROW, RIGHT_ARROW, HOME and END should work appropriately,
-
Caret and cursor position should be in sync
Actual Results
- When we press HOME or END, the cursor doesn’t move to the corresponding position although the caret goes to it.
- When you click anywhere within a line, and press backspace, the last letters of the line are the ones being deleted, not where the cursor shows
- Pressing RIGHT_ARROW and LEFT_ARROW keys don’t work properly, also the caret and the cursor are not in sync.
Note : On Windows vista, the caret and the cursor position are not in sync using the LEFT_ARROW and RIGHT_ARROW keys. Although they work fine when using the HOME/END buttons
<response_by> Gaby Pelleg at 2010.05.10.16.26.04 </response_by> Build: 20100509
Language: Hebrew
Component: GEF
Steps:
- The Logic Example should now be open with a complex drawing on it.
- Display the property sheet from the Window menu (Window. -> Show View > Other? -> General -> Properties).
- Click on the LED at the bottom that is displaying "10".
- It has 3 properties that should be translated: Location, Size and Value
Problem:
The properties sheet for the LED displays the value point(x,y), but "point" is not translated and I can't find it in the files. Since the Value field is RTL, the parentheses are garbled.
Should this string be translated? where is it coming from? it may be better to leave in English but set the Value field LTR , which would also accommodate negative values (if any).
See attached screen shot.
<response_by> igultek at 2010.05.11.09.02.51 </response_by> This article was reassigned from Category:''TVT/Testing,Inbox''.
Build ID: I20061214-1445
Steps To Reproduce:
- Launch eclipse in mirrored mode (using dir -rtl attribute)
- Create a simple project in workspace
- Go to File -> New -> Example… -> Logic Diagram and create a model file
- Create a label in the logic editor that opens up (by dragging a label – under components – from the palette). 5 Create a LED in the logic editor.
- From properties view, set the following values for these objects: For label: Location = (80,300); Size = (90,-1) For LED: Location = (100,200); Size = (61,47)
- From menu select: a)View -> Grid b)View -> Snap to Geometry
- Select the left edge of the label and try to reduce the lable width using the mouse.
Result: The LED is disappeared from the editor
More information: In order ot make the LED to appear again, one should select it in the outline view
I would like to implement a number of options in the palette. Currently this seems to be impossible as all palette EditParts must inherit from PaletteEditPart (due to saveState and restoreState). And PaletteEditPart is internal and thus inaccessible. My only option seems to be to copy org.eclipse.gef.internal.ui.palette.editparts.* to my own plug-in....
But that cannot be right ;-)