Hi Andrus! Loving this. Been building and using the updates for the last few days as the commits roll in (have a couple of private projects running Caynne 5). Looks great, works like a charm (JDK 25) and the improvements are very visible for a frequent user. Just the "table columns are pretty wide by default" thing alone has made me very happy :).
Cheers, - hugi > On 6 May 2026, at 14:58, Andrus Adamchik <[email protected]> wrote: > > I am mostly done with the massive refactoring effort. So I guess I can > finally start looking at the MCP task. > > There's definitely more code to clean up, but it is fairly well isolated. At > the top level, I think the structure is solid. The main changes: > > 1. Abandoned the idea of separating controllers from Swing components and > treating components as mere "views". It only took us 20 years to give up > fighting the framework :) Vanilla Swing components are this old-school > beautiful OO: deep inheritance hierarchies (something frowned upon these > days), easily composable, cleanly encapsulated. Web development is all > stateless processors, so stateful component-based OO design is a lost art in > Java. > > 2. All the Modeler state is stored in two classes - Application and > ProjectSession. Common component superclasses are created to pass those two > around the hierarchy (so there's AppPanel, AppDialog, ProjectPanel, > ProjectDialog, etc. classes.) Make sure you use them when creating new > components. On a side note, the use of DI in the Modeler is completely alien > and is getting in the way. Have to keep it only for the purpose of overriding > defaults from cayenne, cayenne-project and cayenne-dbimport (I'd rather we > use builders in those instead of DI). > > 3. Fixed preferences mess. There's a single "repository" to map prefs > locations (PreferencesRepository), and a bunch of highly custom > PreferenceAdapters. Very easy to create new preferences (and hence capture > more user selections, component sizes etc.) Feature wise: > > * A 5.0-specific preference tree root, so that we don't pollute common JVM > preferences namespace > * Auto-migrations of most existing preferences to the new root > * GUI for preferences export as JSON > * GUI for resetting preferences back to defaults (with or without 4.x > re-migration) > > (still a few issues remain around renaming DataMaps and projects... working > on those) > > 4. Small UI fixes: clean window resizing behavior, borders around editable > table fields, etc. Haven't done FlatLaf yet. > > 5. Proper event hierarchies (clean immutable events); removed project events > from the core. > > 6. Logging console - still ugly, but consistent and functional. > > I have a request for the community - before we make an M2 release, could you > create a local Modeler build and take it for a spin? Due to the sheer volume > of changes, there may be some regressions. If you see anything broken, please > open a Jira and assign to me. > > Thanks, > Andrus > > >> On Apr 20, 2026, at 10:23 AM, Andrus Adamchik <[email protected]> wrote: >> >> So I feel like the advent of agentic coding opens up new possibilities for >> CayenneModeler. While some want you to think you can simply prompt Claude to >> "Rewrite CayenneModeler in JavaFX" (or Electron or JetBrains Compose >> Multiplatform), still with our limited resources, building and supporting an >> entirely new thing is realistically out of reach. >> >> But I think we can take the current Swing app to a new level by augmenting >> our rusty Swing skills with AI. A few of my experiments adding this or that >> UI piece were mostly successful. A few idea on top of my mind: >> >> 1. A built-in MCP server for DB Import and CGen. This is to close the loop >> on agentic coding, allowing to use both of these tools from an agent CLI. >> (The MCP idea was what prompted me to look into this to begin with) >> 2. Fix table editors UX (selections conflicting with cell editors) >> 3. Write unit tests >> 4. Modernizing L&F. Not sure how far we can get while staying in Swing, but >> worth a try. Looking at FlatLaf lib, which is a successor of JGoodies that >> we already use >> 5. Implement dozens of small usability features (such as showing currently >> selected Obj|DbEntity in tab view headers, etc.) >> >> My first pass (about 70% done) was not anything visual, but rather >> refactoring the existing messy code to rid it of various architectural >> experiments accumulated over the years (such as auto-bindings) and unifying >> the MVC structure to be as close as possible to vanilla Swing. Ironically, >> Claude was not that helpful in this process. It was good old IDE >> refactoring, manually going through hundreds of files chasing dead code and >> inconsistencies. >> >> Anyways, just putting this on the radar. >> >> Andrus >
