Re: Modeler (modest) ambition

--00000000000030d7d506512a3ce2
Content-Type: multipart/alternative; boundary="00000000000030d7d506512a3ce1"

--00000000000030d7d506512a3ce1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

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.

[image: Screenshot 2026-05-06 at 1.14.43=E2=80=AFPM.png]

On Wed, May 6, 2026 at 10:01=E2=80=AFAM Andrus Adamchik <[email protected]=
m> 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 t=
wo
> 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 captur=
e
> more user selections, component sizes etc.) Feature wise:
>
> * A 5.0-specific preference tree root, so that we don't pollute common JV=
M
> 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 editabl=
e
> 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=E2=80=AFAM, Andrus Adamchik <aadamchik@gmail.=
com>
> 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 min=
d:
> >
> > 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 unifyi=
ng
> 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 a=
nd
> inconsistencies.
> >
> > Anyways, just putting this on the radar.
> >
> > Andrus
>
>

--00000000000030d7d506512a3ce1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I ran it successfully on macOS 26.4.1 with Java 21.0.1 and=
 poked around. It looks good to me!=C2=A0<div><br></div><div>The one UI ann=
oyance I have had with modeler is that the DB Type is unreadable for the se=
lected row since the text is the same color as the background.<div><br></di=
v><div><img src=3D"cid:ii_moudusz40" alt=3D"Screenshot 2026-05-06 at 1.14.4=
3=E2=80=AFPM.png" width=3D"562" height=3D"30"><br></div></div></div><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 6=
, 2026 at 10:01=E2=80=AFAM Andrus Adamchik &lt;<a href=3D"mailto:aadamchik@=
gmail.com" target=3D"_blank">[email protected]</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">I am mostly done with the m=
assive refactoring effort. So I guess I can finally start looking at the MC=
P task.<br>
<br>
There&#39;s definitely more code to clean up, but it is fairly well isolate=
d. At the top level, I think the structure is solid. The main changes:<br>
<br>
1. Abandoned the idea of separating controllers from Swing components and t=
reating components as mere &quot;views&quot;. It only took us 20 years to g=
ive up fighting the framework :) Vanilla Swing components are this old-scho=
ol beautiful OO: deep inheritance hierarchies (something frowned upon these=
 days), easily composable, cleanly encapsulated. Web development is all sta=
teless processors, so stateful component-based OO design is a lost art in J=
ava.<br>
<br>
2. All the Modeler state is stored in two classes - Application and Project=
Session. Common component superclasses are created to pass those two around=
 the hierarchy (so there&#39;s AppPanel, AppDialog, ProjectPanel, ProjectDi=
alog, etc. classes.) Make sure you use them when creating new components. O=
n a side note, the use of DI in the Modeler is completely alien and is gett=
ing in the way. Have to keep it only for the purpose of overriding defaults=
 from cayenne, cayenne-project and cayenne-dbimport (I&#39;d rather we use =
builders in those instead of DI). <br>
<br>
3. Fixed preferences mess. There&#39;s a single &quot;repository&quot; to m=
ap prefs locations (PreferencesRepository), and a bunch of highly custom Pr=
eferenceAdapters. Very easy to create new preferences (and hence capture mo=
re user selections, component sizes etc.) Feature wise:<br>
<br>
* A 5.0-specific preference tree root, so that we don&#39;t pollute common =
JVM preferences namespace<br>
* Auto-migrations of most existing preferences to the new root<br>
* GUI for preferences export as JSON <br>
* GUI for resetting preferences back to defaults (with or without 4.x re-mi=
gration)<br>
<br>
(still a few issues remain around renaming DataMaps and projects... working=
 on those)<br>
<br>
4. Small UI fixes: clean window resizing behavior, borders around editable =
table fields, etc. Haven&#39;t done FlatLaf yet.<br>
<br>
5. Proper event hierarchies (clean immutable events); removed project event=
s from the core.<br>
<br>
6. Logging console - still ugly, but consistent and functional. <br>
<br>
I have a request for the community - before we make an M2 release, could yo=
u create a local Modeler build and take it for a spin? Due to the sheer vol=
ume of changes, there may be some regressions. If you see anything broken, =
please open a Jira and assign to me.<br>
<br>
Thanks,<br>
Andrus<br>
<br>
<br>
&gt; On Apr 20, 2026, at 10:23=E2=80=AFAM, Andrus Adamchik &lt;<a href=3D"m=
ailto:[email protected]" target=3D"_blank">[email protected]</a>&gt; wr=
ote:<br>
&gt; <br>
&gt; 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 Cla=
ude to &quot;Rewrite CayenneModeler in JavaFX&quot; (or Electron or JetBrai=
ns Compose Multiplatform), still with our limited resources, building and s=
upporting an entirely new thing is realistically out of reach. <br>
&gt; <br>
&gt; But I think we can take the current Swing app to a new level by augmen=
ting 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:<br>
&gt; <br>
&gt; 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 C=
LI. (The MCP idea was what prompted me to look into this to begin with)<br>
&gt; 2. Fix table editors UX (selections conflicting with cell editors)<br>
&gt; 3. Write unit tests<br>
&gt; 4. Modernizing L&amp;F. Not sure how far we can get while staying in S=
wing, but worth a try. Looking at FlatLaf lib, which is a successor of JGoo=
dies that we already use<br>
&gt; 5. Implement dozens of small usability features (such as showing curre=
ntly selected Obj|DbEntity in tab view headers, etc.)<br>
&gt; <br>
&gt; My first pass (about 70% done) was not anything visual, but rather ref=
actoring the existing messy code to rid it of various architectural experim=
ents accumulated over the years (such as auto-bindings) and unifying the MV=
C 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, man=
ually going through hundreds of files chasing dead code and inconsistencies=
. <br>
&gt; <br>
&gt; Anyways, just putting this on the radar.<br>
&gt; <br>
&gt; Andrus<br>
<br>
</blockquote></div>

--00000000000030d7d506512a3ce1--
--00000000000030d7d506512a3ce2--