I just started working with EA and I am doing my first diagram. I want multiple boxes (documents in diagram) to point to 1 other box but I want it to look nice, that is I want there to be just one head of the arrow and the other arrows to connect to the arrow that's pointing to the box
So my question is - Is it possible to connect a couple of arrows to one (let's say I want the secondary arrows to meet in the middle of the main arrow)
Preview image of what I would like to achieve:
UML and related languages do not allow connectors to connect to other connectors; connectors run between two elements (strictly speaking one or two, since a connector can connect an element to itself).
That said, any modelling tool allows you to move the connectors around in the diagram in order to superimpose them to achieve the visual effect you describe.
In EA, you can add bends to a connector using Ctrl-click. You can also change the line style of a connector by right-clicking it. Finally, in Tools - Options - Links you can select "tree" style as the default for Generalizations.
Related
A child Gtk::Window or Gtk::Dialog may be moved around by dragging on the title bar. Being top level windows this activity requires support from the window manager. What is the mechanism by which Gtk requests the window manager to move the position of the window?
Background
I have a Gtk application running on a custom Linux distribution (based on Yocto running Waland/Weston). The application is developed on Ubuntu 20 which has both X11 backend and Wayland backend. The child dialogs or windows that are spawned by the main window are perfectly centered on the main window (in Ubuntu on both backends). However on the target (with Weston) the dialogs or windows appear at random position. Now I understand that this is reported in several forums (like this one in stackoverflow itself).
Different Approach?
With what ever little I know I tried Gtk::Window::move, Gdk::Window::move and even dared to play with Wayland surfaces (gdk_wayland_window_set_transient_for_exported ) but with no avail.
That left me wondering how the user is able to move such child windows by grabbing the header bar (or title bar as Gtk::Window calls it) even under Weston. If I get to know how this works then perhaps I can emulate a grab-drag to position the window where ever I want.
I tried sifting through gtkwindow.c to find out what happens when one sets the title bar using the function gtk_window_set_titlebar but the rabbit hole went a little too deep.
It would be great if someone can point me in the right direction, at least quote some functions whose implementation I can study to get this working....
Your question consists of multiple smaller ones, so I'll try to give a shot at answering each and one of them.
The general idea is that Wayland is quite minimal, so to make it suitable for desktop use cases, you need a protocol extension. This extension is called XDG Shell.
A child Gtk::Window or Gtk::Dialog may be moved around by dragging on the title bar. Being top level windows this activity requires support from the window manager. What is the mechanism by which Gtk requests the window manager to move the position of the window?
This first part is described in the Wayland book, but the idea is that you forward an input event (usually a drag) back to the compositor, who will know what do with it. That might mean moving the window (or not moving it, if you've reached the edge of the screen.
However on the target (with Weston) the dialogs or windows appear at random position. Now I understand that this is reported in several forums (like this one in stackoverflow itself).
Note that your confusing 2 questions here: one is where to put a child window, compared to a parent window, while the second sentence here talks about position any toplevel window. There is also a section in the Wayland book on popups (part of XDG shell also) which also describe something similar.
So whether you can arbitrarily move windows: the answer is no.
The most important question then becomes: what can you do to solve your problems with Weston? It's hard to say without any kind of code. You might want to make sure you set the GtkDialog parent when constructing it (also known as the transient_for property. You might want to play around with the modal flag also. There might be other options too, but it's a bit of a blind guess.
I'm currently working with VS Code. It has an option, located on the top-right of the screen, that allows you to split the editor. I'm wondering what is the utility of splitting an editor with the same file?
Thanks
Editor Groups
This feature allows you to create multiple "editor groups".
The default functionality of the UI option you're referring to, is to open the active editor in a new editor group.
One potential use case for this would be to simultaneously view and edit multiple places in one large file.
Multiple Files
However, you can also drag different files into this new editor group — allowing you to view and edit different files at the same time — which is very useful when you have very modularized code (which usually means there's a lot of related code in different files).
You can create virtually unlimited editor groups, and have virtually an unlimited number of files in each group.
Variety of Layouts
Additionally, with the latest version of VS Code, you can create two by two grid editor layouts, or create your own custom layout and attach it to a keybinding for easy switching.
Keybindings
Editor groups and their files can be controlled with the mouse (click, drag and drop), but you'll end up being a lot more productive if you make an effort to learn the keyboard shortcuts for the commands that you use most often.
Is there a way i can display fully qualified class names for the debugger's callstack?
E.g. rather than this:
I would like to have the packages of the classes included - like where the green boxes remain here:
(NOTE: Actually i dont care where they are displayed as long as there is a easy way to determine the package of a class in the callstack)
Motivation:
I am currently working on legacy systems where there is multiple layers of frameworks (both self-made as well as old stuff like Struts 1.1.), service components etc. etc. and i try to figure out the first point our code is included in some way). Since there are now about 100 Projects in my Eclipse -all with their Maven dependencies - things get complicated by just "Link with Editor" and see where the according class is placed in.
What i tried:
Aprox. 20min Webresearch (incl. reading the SO questions/ answers recommended when i created this question) without any remarkable results.
Using my entire design skills combinated with my 15+ years of MS Paint experience i drew the above images (Feel free to add those stunners to your art collection).
Does this help? In the upper right-hand corner of the Debug (callstack) view, click the menu button (the upside down white triangle), then Java, then see the 'Show Qualified Names' option.
Is it possible to configure NetBeans on a multi-monitor system such that one monitor shows source, and another shows design? How?
Something similar will be supported in NB74.
See http://wiki.netbeans.org/wiki/images/9/91/Horizontal_split.png
Not as separate windows, but next to each other.
There is small cross icon in the upper right corner.
Drag it and split
I am developing a plug-in for Eclipse. I have to develop a Java text editor which allows several users to write the code at the same time, the same way as in Google Docs. But I came across the following problem: the text editor has to show the cursor position of the other users who are coding in same Java document. In other words, I want to place a marker in the text editor content (see this image that shows what I'm trying to implement).
I've already looked IMarker, but IMarker is placed on the text editor's vertical ruler, which is not what I want. Can I use this class? If not, what other class should I use?
The other idea of mine was to insert a JTable in the text editor, but I couldn't find the way how to do that. Is this a right approach, or I'm wrong?
Stack Overflow Gods, please help me...
Eclipse has two different concepts for managing extra information related to files: markers and annotations. Annotations are related to a single editor instance, and their appearance can be customized with a corresponding extension point; markers are used to store extra information permanently (and additionally an annotation can be set up for that reason).
I think, you need to use annotations, as markers are too heavyweight for a real-time collaboration. For future reference, see the Annotations in the Eclipse Help; and some time ago I have written a blog post that describes an automatic translation (and customization) of markers to annotations.