Re: Modeler (modest) ambition

--Apple-Mail=_DB7F8FA9-6A94-4391-A7B0-BD3DA6F1BC01
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> I ran it successfully on macOS 26.4.1 with Java 21.0.1 and poked =
around. It looks good to me!=20

Thanks for checking!

> The one UI annoyance I have had with modeler is that the DB Type is =
unreadable for the selected row since the text is the same color as the =
background.


Yep, been annoyed by this myself for like forever. And... it is fixed.

Andrus



> On May 6, 2026, at 2:21=E2=80=AFPM, John Huss <[email protected]> =
wrote:
>=20
> I ran it successfully on macOS 26.4.1 with Java 21.0.1 and poked =
around. It looks good to me!=20
>=20
> The one UI annoyance I have had with modeler is that the DB Type is =
unreadable for the selected row since the text is the same color as the =
background.
>=20
>=20
>=20
> On Wed, May 6, 2026 at 10:01=E2=80=AFAM Andrus Adamchik =
<[email protected] <mailto:[email protected]>> wrote:
>> I am mostly done with the massive refactoring effort. So I guess I =
can finally start looking at the MCP task.
>>=20
>> 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:
>>=20
>> 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.
>>=20
>> 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).=20
>>=20
>> 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:
>>=20
>> * 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=20
>> * GUI for resetting preferences back to defaults (with or without 4.x =
re-migration)
>>=20
>> (still a few issues remain around renaming DataMaps and projects... =
working on those)
>>=20
>> 4. Small UI fixes: clean window resizing behavior, borders around =
editable table fields, etc. Haven't done FlatLaf yet.
>>=20
>> 5. Proper event hierarchies (clean immutable events); removed project =
events from the core.
>>=20
>> 6. Logging console - still ugly, but consistent and functional.=20
>>=20
>> 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.
>>=20
>> Thanks,
>> Andrus
>>=20
>>=20
>> > On Apr 20, 2026, at 10:23=E2=80=AFAM, Andrus Adamchik =
<[email protected] <mailto:[email protected]>> wrote:
>> >=20
>> > 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.=20
>> >=20
>> > 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:
>> >=20
>> > 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.)
>> >=20
>> > 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.=20
>> >=20
>> > Anyways, just putting this on the radar.
>> >=20
>> > Andrus
>>=20


--Apple-Mail=_DB7F8FA9-6A94-4391-A7B0-BD3DA6F1BC01--