Adds the dockable interface #1
Conversation
WalkthroughThis update introduces a docking framework to replace the previous tabbed editor UI, adds recent files and projects persistence, and enhances file chooser dialogs with filters. The dashboard now displays recent files and projects, allowing users to open files directly from the dashboard or menu. Several new utility classes and UI refinements support these features. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant DashboardPanel
participant FilePersistance
participant EditorWindow
User->>DashboardPanel: Opens Dashboard
DashboardPanel->>FilePersistance: getRecentFiles()
FilePersistance-->>DashboardPanel: List of recent file paths
User->>DashboardPanel: Double-clicks recent file
DashboardPanel->>EditorWindow: addTab(filePath)
EditorWindow->>EditorWindow: Opens file in new dockable editor
sequenceDiagram
participant User
participant Menus
participant FilePersistance
participant EditorWindow
User->>Menus: Opens "File" menu
Menus->>FilePersistance: getRecentFiles()
FilePersistance-->>Menus: List of recent file paths
User->>Menus: Clicks recent file menu item
Menus->>EditorWindow: addTab(filePath)
EditorWindow->>EditorWindow: Opens file in new dockable editor
sequenceDiagram
participant User
participant EditorWindow
participant DockingDesktop
participant CodeEditor
User->>EditorWindow: Adds new editor
EditorWindow->>DockingDesktop: addDockable(CodeEditor)
DockingDesktop-->>EditorWindow: Editor docked
User->>EditorWindow: Closes editor
EditorWindow->>DockingDesktop: removeDockable(CodeEditor)
DockingDesktop-->>EditorWindow: Editor removed
Poem
Tip ⚡️ Faster reviews with caching
Enjoy the performance boost—your workflow just got faster. ✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 17
🧹 Nitpick comments (15)
src/main/java/org/editor/fs/FileFilter.java (2)
9-13: Consider using a more specific class name to avoid potential conflictsThe class name
FileFilteris quite generic and might conflict with other common Java classes likejava.io.FileFilter. Consider using a more specific name such asPicassoFileFiltersorEditorFileFiltersto avoid potential naming conflicts.-public class FileFilter { +public class PicassoFileFilters { public static final FileNameExtensionFilter picsFilter = new FileNameExtensionFilter("Piccasso Script Files", "pics"); public static final FileNameExtensionFilter mdFilter = new FileNameExtensionFilter("Markdown Files", "md"); public static final FileNameExtensionFilter allFilter = new FileNameExtensionFilter("All Files (*.*)", "*"); }
10-10: Fix the typo in "Piccasso"There appears to be a typo in the name "Piccasso" (with two 'c's). Based on the project and artifact names, it should likely be "Picasso" with one 'c'.
- public static final FileNameExtensionFilter picsFilter = new FileNameExtensionFilter("Piccasso Script Files", "pics"); + public static final FileNameExtensionFilter picsFilter = new FileNameExtensionFilter("Picasso Script Files", "pics");src/main/java/org/editor/events/MenuEvents.java (1)
69-69: Avoid using underscore variable names for non-discarded objectsUsing
_typically indicates a value that's intentionally discarded. Since theAboutDialoginstance is actually being used (showing a dialog), this naming is misleading.-var _ = new AboutDialog(EditorWindow.win); +var aboutDialog = new AboutDialog(EditorWindow.win);src/main/java/org/editor/DockablePanel.java (1)
1-42: LGTM! Well-structured dockable panel implementationThis implementation cleanly extends
JPaneland implements theDockableinterface. The class provides multiple constructors with different customization options, and properly implements the required interface methods.One suggestion for enhancement:
// Consider adding methods to update the dock key properties after construction public void setDockName(String name) { key.setName(name); } public void setDockTooltip(String tooltip) { key.setTooltip(tooltip); } public void setDockIcon(String iconName) { key.setIcon(Icons.getIcon(iconName)); }src/main/java/org/editor/fs/FilePersistance.java (1)
8-8: Unused import
java.nio.file.OpenOptionis imported but never used. Please remove it to keep the file tidy.src/main/java/org/editor/CodeEditor.java (1)
79-103: Two separate focus listeners perform the exact same workBoth the
textAreaand the surroundingCodeEditorpanel register identicalfocusGainedhandlers.
The panel listener is redundant (the caret listener already updates status too) and doubles the event
traffic.Consider removing the outer listener to keep things lean:
- this.addFocusListener(new FocusListener() { - @Override public void focusGained(FocusEvent e) { - EditorWindow.setSelectedEditor(self); - getCursorPositionText(self); - } - @Override public void focusLost(FocusEvent e) { } - });src/main/java/org/editor/menu/Menus.java (3)
121-123: Minor typo – “Navigage”The menu label reads “Navigage”; change to “Navigate” for professionalism.
-JMenu navMenu = new JMenu("Navigage"); +JMenu navMenu = new JMenu("Navigate");
158-160: Sub-menu title duplicates “Tools”
renderToolsMenuis nested inside the top-level Tools menu but is itself titled “Tools”,
which is confusing. Consider “Render Tools” or “Drawing Tools”.
72-81: Menu builds the recent list once; consider a refresh hookIf the user opens a new file during the session, the “Recent Files” submenu won’t update
until the application restarts. Triggering a rebuild (or at least clearing & re-populating)
each time the File menu is opened would keep the list current.src/main/java/org/editor/panels/DashboardPanel.form (1)
206-259: Recent Projects panel has no backing model yet
rProjListis initialised with an empty model and there’s no code populating it.
To avoid a blank panel, either:
- Hide/disable the panel until
FilePersistance.getRecentProjects()is implemented, or- Populate the list now (similar to recent files) and add a placeholder “No recent projects”.
This prevents the UI from looking unfinished.
src/main/java/org/editor/panels/DashboardPanel.java (3)
221-223: Static list models risk global, thread-unsafe stateMaking
filesModel/projectModelstaticmakes them shared by every dashboard instance and by every Swing EDT created test.
Consider:
- Using instance-scoped models, or
- Guarding access with
SwingUtilities.invokeLaterif they must remain static and be mutated from multiple threads.
145-161:rProjListis never wired toprojectModel
rProjListis declared with a generic type<String>but no model is set;projectModelis never referenced.
Either bind it or remove the dead code to avoid user confusion.- rProjList = new javax.swing.JList<>(); + rProjList = new javax.swing.JList<>(projectModel);
258-260: Generic mismatch betweenrProjListand its intended model
rProjListis declared asJList<String>whileprojectModelwill holdListItemobjects (similar tofilesModel).
Align the generics to avoid unchecked cast warnings.src/main/java/org/editor/EditorWindow.java (2)
91-92: UnusedCodeEditorinstance – probable leftover
var _ = new CodeEditor();allocates an editor that is never shown or stored.
Remove it to save ~30 MB of editor state and avoid confusing future readers.
248-253: Duplicated call toaddDockableandcreateTabFor the first editor you
desk.addDockable(editor)and immediatelycreateTab(dashboard, editor, 2).
createTabalready installs the dockable; the first call is redundant and may break docking state bookkeeping.- if (index == 0) { - win.desk.addDockable(editor); - win.desk.createTab(win.dashboard, editor, 2); + if (index == 0) { + win.desk.createTab(win.dashboard, editor, 2);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (14)
pom.xml(1 hunks)src/main/java/org/editor/AccessFrame.java(1 hunks)src/main/java/org/editor/CanvasFrame.java(2 hunks)src/main/java/org/editor/CodeEditor.java(9 hunks)src/main/java/org/editor/DockablePanel.java(1 hunks)src/main/java/org/editor/EditorWindow.java(10 hunks)src/main/java/org/editor/events/Actions.java(1 hunks)src/main/java/org/editor/events/ListAction.java(1 hunks)src/main/java/org/editor/events/MenuEvents.java(2 hunks)src/main/java/org/editor/fs/FileFilter.java(1 hunks)src/main/java/org/editor/fs/FilePersistance.java(1 hunks)src/main/java/org/editor/menu/Menus.java(9 hunks)src/main/java/org/editor/panels/DashboardPanel.form(5 hunks)src/main/java/org/editor/panels/DashboardPanel.java(6 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (4)
src/main/java/org/editor/events/Actions.java (1)
src/main/java/org/editor/events/MenuEvents.java (1)
MenuEvents(24-124)
src/main/java/org/editor/events/MenuEvents.java (2)
src/main/java/org/editor/fs/FileFilter.java (1)
FileFilter(9-13)src/main/java/org/editor/EditorWindow.java (1)
EditorWindow(62-537)
src/main/java/org/editor/DockablePanel.java (1)
src/main/java/org/editor/icons/Icons.java (1)
Icons(10-132)
src/main/java/org/editor/EditorWindow.java (5)
src/main/java/org/editor/icons/Icons.java (1)
Icons(10-132)src/main/java/org/editor/CodeEditor.java (1)
CodeEditor(42-288)src/main/java/org/editor/events/Actions.java (1)
Actions(13-460)src/main/java/org/editor/menu/Menus.java (1)
Menus(25-203)src/main/java/org/editor/CanvasFrame.java (1)
CanvasFrame(34-326)
🔇 Additional comments (6)
pom.xml (1)
46-50: Good addition of the docking library dependencyThe vldocking library dependency is correctly added and aligns with the docking framework integration across the application. This is essential for supporting the new dockable panel-based interface highlighted in the PR objectives.
src/main/java/org/editor/events/Actions.java (1)
182-182: Good implementation of the Save All action handlerReplacing the placeholder with a proper method reference to
MenuEvents::saveAllFilesconnects the UI action to the functionality for saving all open files. This properly integrates with the new docking-based editor management system.src/main/java/org/editor/events/MenuEvents.java (2)
83-85: LGTM! File filters correctly appliedThe file filters for Markdown and Piccasso script files are correctly applied from the
FileFilterutility class.
112-114: LGTM! SaveAllFiles implementation is correctThe new
saveAllFilesmethod correctly delegates toEditorWindow.saveAll().src/main/java/org/editor/events/ListAction.java (1)
22-42: LGTM! Clean implementation for handling list actionsThe implementation cleanly binds actions to both keyboard and mouse events, making it reusable across different list components.
src/main/java/org/editor/CodeEditor.java (1)
140-143: Potential typo in method namesetSeletedTabTitleBoth calls use
EditorWindow.setSeletedTabTitle(...). If the actual method is
setSelectedTabTitle, compilation will fail.Please verify the spelling in
EditorWindow.Also applies to: 174-177
| public class FileFilter { | ||
| public static final FileNameExtensionFilter picsFilter = new FileNameExtensionFilter("Piccasso Script Files", "pics"); | ||
| public static final FileNameExtensionFilter mdFilter = new FileNameExtensionFilter("Markdown Files", "md"); | ||
| public static final FileNameExtensionFilter allFilter = new FileNameExtensionFilter("All Files (*.*)", "*"); |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Review the implementation of the "All Files" filter
The "All Files" filter implementation might not work as expected. Using "*" as an extension parameter may not correctly match all files. For a proper "All Files" filter, consider using an empty extension array or a different approach.
🏁 Script executed:
#!/bin/bash
# Test if the current approach works with JFileChooser
# Search for examples of how "All Files" filters are implemented in the codebase
rg -A 3 "FileNameExtensionFilter.*All Files"
# Show how JFileChooser is used with these filters
rg -A 5 "JFileChooser.*setFileFilter"Length of output: 286
Replace improper “All Files” filter
Using "*" as the extension in FileNameExtensionFilter won’t match every file— it only matches files ending in “.*” literally. Instead, use the built-in accept-all filter or a custom always-accept filter:
• In src/main/java/org/editor/fs/FileFilter.java line 12, replace:
public static final FileNameExtensionFilter allFilter =
new FileNameExtensionFilter("All Files (*.*)", "*");with either the built-in accept-all filter:
// when configuring your JFileChooser:
chooser.setAcceptAllFileFilterUsed(true);
chooser.addChoosableFileFilter(chooser.getAcceptAllFileFilter());or a custom FileFilter:
public static final FileFilter allFilter = new FileFilter() {
@Override public boolean accept(File f) { return true; }
@Override public String getDescription() { return "All Files (*.*)"; }
};This ensures every file is shown as intended.
| import com.vlsolutions.swing.docking.DockKey; | ||
| import com.vlsolutions.swing.docking.Dockable; |
There was a problem hiding this comment.
💡 Verification agent
❓ Verification inconclusive
Verify usage of imported docking classes
You've added imports for DockKey and Dockable from the docking framework, but the class doesn't seem to implement or use these interfaces/classes yet. These imports appear to be in preparation for future changes.
🏁 Script executed:
#!/bin/bash
# Check if AccessFrame implements Dockable in other parts of the codebase
rg -A 3 "AccessFrame.*implements.*Dockable"
# Check if there are other files where AccessFrame is used with docking functionality
rg "new DockKey.*AccessFrame"Length of output: 77
Remove Unused Docking Imports
The imports for com.vlsolutions.swing.docking.DockKey and com.vlsolutions.swing.docking.Dockable in src/main/java/org/editor/AccessFrame.java are not referenced anywhere in the code. Please remove them until you actually implement docking support to keep the code clean:
• File: src/main/java/org/editor/AccessFrame.java
Lines 3–4
- import com.vlsolutions.swing.docking.DockKey;
- import com.vlsolutions.swing.docking.Dockable;📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| import com.vlsolutions.swing.docking.DockKey; | |
| import com.vlsolutions.swing.docking.Dockable; |
| import com.vlsolutions.swing.docking.DockKey; | ||
| import com.vlsolutions.swing.docking.Dockable; | ||
| import java.awt.BasicStroke; |
There was a problem hiding this comment.
Missing interface implementation for Dockable
You've imported the Dockable interface and added a DockKey field, but CanvasFrame doesn't implement the Dockable interface. This appears to be incomplete integration with the docking framework.
-public class CanvasFrame extends JPanel implements MouseListener, MouseMotionListener {
+public class CanvasFrame extends JPanel implements MouseListener, MouseMotionListener, Dockable {Also need to implement the required methods:
@Override
public DockKey getDockKey() {
return key;
}
@Override
public Component getComponent() {
return this;
}Also applies to: 8-8
| private Point selectionEnd = null; | ||
|
|
||
| private static CanvasFrame _the = null; | ||
| private DockKey key = new DockKey("canvas"); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
DockKey will remain unused without implementing Dockable
This DockKey field has been added but won't be utilized by the docking framework until the class implements the Dockable interface.
| if (EditorWindow.tabsCount() == 1) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
Logic issue: Save operations blocked when only one tab exists
The condition EditorWindow.tabsCount() == 1 prevents saving when only one tab is open. Is this intentional? Typically, users should be able to save even with only one open tab.
If the intent is to prevent operations when no tabs are open, use:
-if (EditorWindow.tabsCount() == 1) {
+if (EditorWindow.tabsCount() == 0) {If the first tab is special (like a welcome tab that shouldn't be saved), add a clarifying comment explaining this behavior.
Also applies to: 105-107
| fileChooser.setFileFilter(FileFilter.mdFilter); | ||
| fileChooser.setFileFilter(FileFilter.picsFilter); | ||
|
|
There was a problem hiding this comment.
Only one FileFilter is active – the second setFileFilter overwrites the first
If you want both “.md” and “.pics” filters:
-fileChooser.setFileFilter(FileFilter.mdFilter);
-fileChooser.setFileFilter(FileFilter.picsFilter);
+fileChooser.addChoosableFileFilter(FileFilter.mdFilter);
+fileChooser.addChoosableFileFilter(FileFilter.picsFilter);
+fileChooser.setFileFilter(FileFilter.picsFilter); // default selection📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| fileChooser.setFileFilter(FileFilter.mdFilter); | |
| fileChooser.setFileFilter(FileFilter.picsFilter); | |
| fileChooser.addChoosableFileFilter(FileFilter.mdFilter); | |
| fileChooser.addChoosableFileFilter(FileFilter.picsFilter); | |
| fileChooser.setFileFilter(FileFilter.picsFilter); // default selection |
| private void loadPersistedState() { | ||
| FilePersistance | ||
| .getRecentFiles() | ||
| .forEach(item -> { | ||
| var fp = new File(item); | ||
| var path = fp.toPath().toString(); | ||
| filesModel.addElement(new ListItem(path, Icons.getIcon("file"))); | ||
| }); | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
loadPersistedState() adds duplicates every time the dashboard is instantiated
filesModel is static, yet loadPersistedState() appends to it on every construction of DashboardPanel.
If the application creates more than one dashboard (e.g. undocks/re-docks), recent-file entries will be duplicated indefinitely.
private void loadPersistedState() {
- FilePersistance.getRecentFiles().forEach(item -> {
+ filesModel.clear(); // ← avoid duplication
+ FilePersistance.getRecentFiles().forEach(item -> {
...
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| private void loadPersistedState() { | |
| FilePersistance | |
| .getRecentFiles() | |
| .forEach(item -> { | |
| var fp = new File(item); | |
| var path = fp.toPath().toString(); | |
| filesModel.addElement(new ListItem(path, Icons.getIcon("file"))); | |
| }); | |
| private void loadPersistedState() { | |
| filesModel.clear(); // ← avoid duplication | |
| FilePersistance | |
| .getRecentFiles() | |
| .forEach(item -> { | |
| var fp = new File(item); | |
| var path = fp.toPath().toString(); | |
| filesModel.addElement(new ListItem(path, Icons.getIcon("file"))); | |
| }); | |
| } |
| public static CodeEditor getSelectedEditor() { | ||
| int index = tabs.getSelectedIndex(); | ||
| var ed = tabEditors.get(index); | ||
| return ed; | ||
| if (selected != null) { | ||
| return selected; | ||
| } | ||
|
|
||
| for (var editor : tabEditors.values()) { | ||
| if (editor.textArea.isFocusOwner()) { | ||
| return editor; | ||
| } | ||
| } | ||
| return tabEditors.values().toArray(CodeEditor[]::new)[0]; // fallback if nothing has focus |
There was a problem hiding this comment.
🛠️ Refactor suggestion
getSelectedEditor() may throw when no editors are open
Calling tabEditors.values().toArray(...)[0] will ArrayIndexOutOfBoundsException when the map is empty (application starts with 0 editors).
Return null or create an editor lazily instead.
| getContentPane().add(desk, BorderLayout.CENTER); | ||
| getContentPane().add(render_panel, BorderLayout.WEST); | ||
| getContentPane().add(access_panel, BorderLayout.SOUTH); | ||
| getContentPane().add(cool_bar, BorderLayout.EAST); | ||
| getContentPane().add(tool_bar, BorderLayout.PAGE_START); | ||
| getContentPane().add(bottom_bar, BorderLayout.PAGE_END); |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Components added both to the frame and to the docking desktop
render_panel, cool_bar, tool_bar, and bottom_bar are directly added to the frame and later inserted into desk via split/addDockable.
A Swing component can have only one parent; the first addition will be invalidated by the second, or vice-versa, leading to layout corruption.
Recommendation:
Only add dockable panels to desk; remove the getContentPane().add(...) lines for those panels.
There was a problem hiding this comment.
This is hows the docking library expects the dockables to be added. It expects all dockables to be owned by the frame and but they are managed by the library.
There was a problem hiding this comment.
🧩 Analysis chain
@hexaredecimal Thank you for the clarification! I see that my previous suggestion was based on standard Swing component behavior, but the VLDocking library works differently. The library indeed expects dockables to be owned by the frame while being managed by the docking desktop, rather than following the typical Swing parent-child relationship. I appreciate you sharing this insight about how the library is designed to work.
🏁 Script executed:
#!/bin/bash
# Search for documentation or comments about VLDocking in the codebase
echo "Searching for VLDocking documentation in the codebase..."
rg -i "vldocking" --type-add "java:*.java" --type java -A 5 -B 5
# Search for addDockable or similar methods to understand the usage pattern
echo -e "\nSearching for addDockable method usage..."
rg "addDockable" --type java -A 2 -B 2
# Search for DockingDesktop usage
echo -e "\nSearching for DockingDesktop usage..."
rg "DockingDesktop" --type java -A 3 -B 3
# Check if there's any VLDocking documentation in the repository
echo -e "\nChecking for VLDocking documentation files..."
fd -e md -e txt "dock" --exec grep -i "vldocking" {} \;
Length of output: 3007
🌐 Web query:
How does the VLDocking library component ownership work in Java Swing? Can components be added to both a frame and docking desktop?
💡 Result:
In Java Swing, the concept of component ownership is important to understand when working with libraries like VLDocking.
Here's how component ownership typically works:
-
Component Ownership and Parenting:
Each Swing component can have only one parent container at a time. When you add a component to a container (like a JFrame or JPanel), that container becomes the component's parent. -
VLDocking and Docking Desktop:
VLDocking provides a docking framework where components (usually called "docks" or "dockables") can be added to a docking desktop, which manages layout, docking, and undocking of these components. -
Ownership in Docking Context:
When you add a component to a VLDocking desktop (e.g., inside a dockable window), VLDocking takes ownership of that component for the purpose of docking and layout. -
Adding Components to Both Frame and Docking Desktop:
According to the single-parent rule in Swing, a component cannot be added directly to both a JFrame and a VLDocking desktop simultaneously. If you try to "add" the same component to two containers, it will be removed from the first and added to the second. This means you cannot have one instance of a component added to both a frame and a docking desktop at the same time. -
Typical Usage Pattern:
Usually, the VLDocking desktop is added as a single component to a JFrame or its content pane. Then, you add dockable components to the docking desktop, not directly to the JFrame. The JFrame owns the docking desktop, and the docking desktop owns the dockable components.
Summary:
- A Swing component can have only one parent at a time.
- You cannot add the same component directly to both a JFrame and a VLDocking desktop simultaneously.
- Usually, you add the docking desktop to the frame, and the components to the docking desktop, respecting the parent-child hierarchy.
Let me know if you want a code example or further details on using VLDocking!
@hexaredecimal Thank you for the clarification! I see now how the VLDocking library works. It seems to have a different component management model than standard Swing where components maintain their place in the Swing hierarchy (owned by the frame) while also being registered with the docking desktop for layout management.
I appreciate you sharing this insight about the library's design. This helps me better understand the proper usage pattern for VLDocking components.
🧬 Code Graph Analysis Results
Relevant snippets for understanding src/main/java/org/editor/EditorWindow.java and the user comment about docking library expectations:
File: src/main/java/org/editor/CodeEditor.java
Lines: 42-288
This class implements Dockable interface and represents an editor panel that can be docked in the docking framework used by EditorWindow. Key points:
- Implements
Dockableinterface with methods:getDockKey()returns aDockKeyidentifying the dockable.getComponent()returns the UI component (itself).
- Manages a
DockKeywith title, tooltip, and icon. - Supports loading and saving files.
- Has a
tabIndexto track its position in tabs. - The constructor creates a
DockKeyfor the editor, either for a temporary file or a real file. - The editor panel contains a syntax-highlighted text area with code completion.
- The editor is added to the docking desktop in
EditorWindowvia calls likedesk.addDockable(editor)ordesk.createTab(...).
This snippet is relevant because it shows how dockables (editors) are created and identified for the docking library, matching the user comment about dockables being owned by the frame but managed by the library.
File: src/main/java/org/editor/EditorWindow.java
Lines: Entire file (1-~400)
Key relevant parts related to docking:
- Uses
DockingDesktop(desk) as the main docking container. - Dockables like
dashboard,cool_bar, andCodeEditorinstances are added todeskviadesk.addDockable(...). - Tabs of editors are created using
desk.createTab(...)to group dockables. - The docking desktop listens for dockable state changes to handle closing editors and prompting for save if dirty.
- The comment in the user comment matches the pattern in the code where dockables are added to the desktop and managed by the docking library.
removeIfDirtymethod removes dockables from the docking desktop viadesk.remove((Dockable) ed).- The
customizeDock()method sets UI properties for the docking library. - The docking library expects dockables to be owned by the frame (
EditorWindow) but managed by the docking library (DockingDesktop).
File: src/main/java/org/editor/panels/DashboardPanel.java
Lines: 26-262
- Defines
DashboardPanelwhich is wrapped in aDockablePaneland added as a dockable to the docking desktop. - This panel is used as a dockable in
EditorWindow(dashboard). - Shows how other dockables besides editors are created and added to the docking desktop.
File: src/main/java/org/editor/icons/Icons.java
Lines: 10-132
- Provides icon loading and retrieval used for dockable titles and buttons.
- Relevant because dockables like
CodeEditorandDashboardPaneluse icons from this class for theirDockKey.
Summary of relevance:
EditorWindow.javashows how dockables are added to the docking desktop and managed.CodeEditor.javashows how dockables are implemented and identified withDockKey.DashboardPanel.javashows another example of a dockable panel.Icons.javasupports dockable UI with icons.
These snippets provide the necessary context to understand the docking library usage and the user comment about dockables being owned by the frame but managed by the docking library.
[End of relevant snippets.]
✏️ Learnings added
Learnt from: hexaredecimal
PR: Glimmr-Lang/PicassoCode#1
File: src/main/java/org/editor/EditorWindow.java:204-209
Timestamp: 2025-05-14T10:49:23.429Z
Learning: The VLDocking library (com.vlsolutions.swing.docking) expects dockable components to be owned by the frame while being managed by the docking desktop. Unlike standard Swing components that can only have one parent, the DockingDesktop acts as a manager for dockable components rather than being their parent in the component hierarchy.
Learnt from: hexaredecimal
PR: Glimmr-Lang/PicassoCode#1
File: src/main/java/org/editor/EditorWindow.java:204-209
Timestamp: 2025-05-14T10:49:23.429Z
Learning: The VLDocking library (com.vlsolutions.swing.docking) has a distinct component management model where UI components are added to both the frame's content pane AND registered with the DockingDesktop. Unlike standard Swing where components can only have one parent, VLDocking expects dockables to be owned by the frame while being managed by the docking desktop for layout, docking states, and behaviors.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
| DockingPreferences.setDottedDesktopStyle(); | ||
| getContentPane().add(desk, BorderLayout.CENTER); | ||
| getContentPane().add(render_panel, BorderLayout.WEST); | ||
| getContentPane().add(access_panel, BorderLayout.SOUTH); | ||
| getContentPane().add(cool_bar, BorderLayout.EAST); | ||
| getContentPane().add(tool_bar, BorderLayout.PAGE_START); | ||
| getContentPane().add(bottom_bar, BorderLayout.PAGE_END); | ||
|
|
||
| var tool_bar = makeToolBar(tool_actions); | ||
| main_panel.add(tool_bar, BorderLayout.PAGE_START); | ||
| dashboard = new DockablePanel(new BorderLayout(), "Piccasso DashBoard", "DashBoard", "Home page", "file"); | ||
| dashboard.add(new JScrollPane(new DashboardPanel()), BorderLayout.CENTER); | ||
| getContentPane().add(access_panel, BorderLayout.EAST); |
There was a problem hiding this comment.
Adding the same component (access_panel) twice will throw IllegalArgumentException
access_panel is first added with BorderLayout.SOUTH (line 206) and again with BorderLayout.EAST (line 213).
Swing forbids adding a component to two parents – the second call will explode at runtime.
- getContentPane().add(access_panel, BorderLayout.EAST);Remove the duplicate (same issue exists for render_panel and cool_bar).
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| DockingPreferences.setDottedDesktopStyle(); | |
| getContentPane().add(desk, BorderLayout.CENTER); | |
| getContentPane().add(render_panel, BorderLayout.WEST); | |
| getContentPane().add(access_panel, BorderLayout.SOUTH); | |
| getContentPane().add(cool_bar, BorderLayout.EAST); | |
| getContentPane().add(tool_bar, BorderLayout.PAGE_START); | |
| getContentPane().add(bottom_bar, BorderLayout.PAGE_END); | |
| var tool_bar = makeToolBar(tool_actions); | |
| main_panel.add(tool_bar, BorderLayout.PAGE_START); | |
| dashboard = new DockablePanel(new BorderLayout(), "Piccasso DashBoard", "DashBoard", "Home page", "file"); | |
| dashboard.add(new JScrollPane(new DashboardPanel()), BorderLayout.CENTER); | |
| getContentPane().add(access_panel, BorderLayout.EAST); | |
| DockingPreferences.setDottedDesktopStyle(); | |
| getContentPane().add(desk, BorderLayout.CENTER); | |
| getContentPane().add(render_panel, BorderLayout.WEST); | |
| getContentPane().add(access_panel, BorderLayout.SOUTH); | |
| getContentPane().add(cool_bar, BorderLayout.EAST); | |
| getContentPane().add(tool_bar, BorderLayout.PAGE_START); | |
| getContentPane().add(bottom_bar, BorderLayout.PAGE_END); | |
| dashboard = new DockablePanel(new BorderLayout(), "Piccasso DashBoard", "DashBoard", "Home page", "file"); | |
| dashboard.add(new JScrollPane(new DashboardPanel()), BorderLayout.CENTER); |
Docstrings generation was requested by @hexaredecimal. * #1 (comment) The following files were modified: * `src/main/java/org/editor/CanvasFrame.java` * `src/main/java/org/editor/CodeEditor.java` * `src/main/java/org/editor/DockablePanel.java` * `src/main/java/org/editor/EditorWindow.java` * `src/main/java/org/editor/events/Actions.java` * `src/main/java/org/editor/events/ListAction.java` * `src/main/java/org/editor/events/MenuEvents.java` * `src/main/java/org/editor/fs/FilePersistance.java` * `src/main/java/org/editor/menu/Menus.java` * `src/main/java/org/editor/panels/DashboardPanel.java`
|
Note Generated docstrings for this pull request at #2 |
Changes the tabbed pane + split pane based UI to a dockable panel based one. Really love the change I've made
Summary by CodeRabbit
New Features
Improvements
Bug Fixes