Re: UI toolkit for the future Modeler

[Aristedes Maniatis]

A possible UI toolkit for creating a visualisation of the object graph:

https://pathwaycommons.github.io/cytoscape-sbgn-stylesheet/


There are certainly a lot of js/html tools that will solve this 
particular need.




Ari

Re: UI toolkit for the future Modeler

[Aristedes Maniatis]

On 21/12/21 4:11am, Andrus Adamchik wrote:

Is it worth examining DBeaver to see whether Cayenne functionality could be 
added on top of the existing ERD 
features?https://dbeaver.com/docs/wiki/ER-Diagrams

While I use DBeaver almost daily and appreciate all the work that went into it 
and shared at no cost, the UI is horrible (esp on the Mac). The Eclipse-style 
widgets, bad responsiveness and modality everywhere are driving me crazy. E.g. 
you reopen DBeaver with 5 tabs from a previous session, that are connected to a 
DB that is no longer there, and you get exactly 5 modal error popups that you 
need to dismiss manually.



I think its important to target what people will find useful, rather 
than UI details which will one day be fixed. It is good to go to where 
the users are... and right now they are using tools like Intellij or 
DBeaver.


An Intellij plugin need not reproduce the entire Cayenne modeler. Even a 
few cgen integrations or annotation helpers could expand the visibility 
of Cayenne. Could Cayenne modeler be split into a set of services which 
could then be exposed in different front-ends?



Let me start by asking a basic question. Do we see Modeler as just a 
tool which parses and writes an XML file, or does it do more? What is 
its relationship (as a product, not technically) with cgen, mvn/gradle 
plugins? Could it import Hibernate annotations so that users have an 
easier path to try Cayenne? How should it interact with a DB?


DBeaver can already read a DB schema and output it to sql, json, etc. 
Would a Cayenne 'plugin' just allow it to output that schema to Cayenne XML?


What utility could we give Intellij understanding Cayenne better? Could 
it understand our annotations and allow users to click through to entity 
events from the entities themselves?



So first let's agree on what Modeler is today and what it should be in 
the future.







If Modeler changed to another language or UI library, could it leverage that to 
better integrate with other tooling?

I may have one such integration scenario I care about myself - integration with 
Liquibase... I no longer use a permanent local DB to run my code. My APIs and jobs are 
tested via JUnit, Testcontainers, and a Docker-based transitory DB, and I never ever 
check them manually. But I still forced to maintain a semi-permanent local DB to do 
"DB Import" for Cayenne, and this creates extra friction. Allowing 
CayenneModeler to create its own transitory schema with Docker/Testcontainers/Liquibase 
for the purpose of DB Import would be extremely cool.



Phabricator has a really nice feature. When you run a new version in 
production it compares the real database with the model it has, and 
automatically fixes the production database to look the way it should. 
Sure that's not possible when you need to migrate data to a new schema, 
but for verifying and adding indexes or simply adding or dropping 
columns, its quite nice.


Liquibase is great, but its only good for applying a set of rules and 
not for getting the database into a known state. Some integration 
between liquibase (transition rules) and cayenne (a known db state) 
would be great.




Ari

Re: UI toolkit for the future Modeler

[Andrus Adamchik]

Hi Ari,

I think you are on to something. New functionality and streamlining the ORM 
flow is what I am looking for in the rewrite we contemplate. I don't care that 
much about directly rewriting what we already have on top of another toolkit. 
If we are not planning to drastically change anything, we can keep supporting 
the Swing version for another 10+ years. 

I hope we can change the way we do ORM, making it more intuitive and 
productive. Remove friction from dev work. E.g. the current separation into Obj 
and DB layers is clunky; maybe we visually collapse it into a single layer of 
entities like EOF did or something. So a question to answer is how do we 
rethink the current form-based editor before we pick a technology.

> Is it worth examining DBeaver to see whether Cayenne functionality could be 
> added on top of the existing ERD features? 
> https://dbeaver.com/docs/wiki/ER-Diagrams

While I use DBeaver almost daily and appreciate all the work that went into it 
and shared at no cost, the UI is horrible (esp on the Mac). The Eclipse-style 
widgets, bad responsiveness and modality everywhere are driving me crazy. E.g. 
you reopen DBeaver with 5 tabs from a previous session, that are connected to a 
DB that is no longer there, and you get exactly 5 modal error popups that you 
need to dismiss manually.

> I like the idea of converting a query into SQL in order to understand what it 
> is doing. 

Yeah, we need this kind of features - making the Modeler a developer tool that 
helps to understand your own Cayenne code. That of course will also require 
extra backend work (replacing EJBQL with a syntax for ObjectSelect). But it 
should be worth it.

> What would be involved in making Cayenne modeler an Eclipse or Intellij 
> plugin? Would that increase market awareness, especially if the IDE could be 
> made more aware of how to handle Cayenne annotations.

I am a bit weary of *direct* integration with other tooling (as in becoming a 
plugin). E.g. writing the Modeler as an Eclipse plugin sounded entirely 
uncontroversial in 2006, but luckily we never got there. This would've been a 
dead end in the current market. Most of the industry is using IntelliJ now, and 
I still encounter customers who are fully Eclipse or Netbeans. The current 
standalone Modeler can serve all of them the same way. It is a big deal.

> A modeler which runs inside a browser reduces the barrier to entry hugely. 
> Imagine going to a demo website, uploading your database schema and being 
> able to instantly play with your schema and output a working Java project.

You mentioned this before. So the goal would be to obtains a starter Java 
project? This is potentially interesting. E.g. people seem to like 
https://start.spring.io/  . On the other hand 
generating usable projects is quite an undertaking. We are developing a CLI 
project generator under Bootique (see 
https://bootique.io/docs/2.x/bootique-tool-docs/ 
 ), and the problem is that 
there are too many possible configurations. So getting a project that is in 
your preferred style is hard. I constantly struggle with it.

> If Modeler changed to another language or UI library, could it leverage that 
> to better integrate with other tooling?


I may have one such integration scenario I care about myself - integration with 
Liquibase... I no longer use a permanent local DB to run my code. My APIs and 
jobs are tested via JUnit, Testcontainers, and a Docker-based transitory DB, 
and I never ever check them manually. But I still forced to maintain a 
semi-permanent local DB to do "DB Import" for Cayenne, and this creates extra 
friction. Allowing CayenneModeler to create its own transitory schema with 
Docker/Testcontainers/Liquibase for the purpose of DB Import would be extremely 
cool.

If anyone can propose other similar use cases from their own experience, let's 
discuss.

Andrus



> On Dec 16, 2021, at 2:21 AM, Aristedes Maniatis  
> wrote:
> 
> A few random thoughts.
> 
> 
> ## Integrations
> 
> If Modeler changed to another language or UI library, could it leverage that 
> to better integrate with other tooling?
> 
> For example, could making parts of the modeler a js library allow it to work 
> with existing js database modelers like Vertabelo 
> https://my.vertabelo.com/try-db-designer
> 
> 
> 
> Here are some desktop app database modelers I found:
> 
> * https://www.toadworld.com/products/toad-data-modeler
> 
> * https://www.mysql.com/products/workbench/
> 
> * https://www.idera.com/products/er-studio/enterprise-data-modeling
> 
> * https://sparxsystems.com/products/ea/
> 
> * https://astah.net/
> 
> 
> 
> ## Building on an existing platform
> 
> Is it worth examining DBeaver to see whether Cayenne functionality could be 
> added on top of the existing ERD features? 
> https://dbeaver.com/docs/wiki/ER-Diagrams
> 
> 
> What would be involved in making Cayenne modeler an Eclipse or Intell

Re: UI toolkit for the future Modeler

[Michael Gentry]

Hi John,

JavaFX /without/ Scene Builder would be far less interesting to me. SB
shields me from having to learn the FXML semantics, plus I think I'm just
drawn to a more visual editing approach (which is why I want a great
Cayenne Modeler over putting annotations/etc on POJOs).

With something like SwiftUI, you have to know all the classes/attributes
and how to lay them out, even if there is a quick preview of the UI. With
SB, that is largely presented to you in the UI, which lessens the cognitive
load, IMO. You'd still have to learn the UI patterns, though.

I stumbled upon this over the weekend:

http://griffon-framework.org/

"Griffon supports 4 different UI toolkits: Swing, JavaFX, Apache Pivot, and
Lanterna.

Griffon encourages the use of the MVC pattern but it's not limited to a
single interpretation, you can for example apply standard MVC, MVP, MVVM,
PMVC and others. Griffon also follows in the spirit of the Swing
Application Framework (JSR 296), it defines a simple yet powerful
application life cycle and event publishing mechanism regardless of the UI
toolkit of choice."

I haven't explored it yet, though.

mrg


On Mon, Dec 20, 2021 at 11:41 AM John Huss  wrote:

> Thanks Michael! I was able to run the JFX version on Java 11 and open the
> sample model at "src/test/resources/cayenne-analytic.xml".
>
> For JFX, the existence of a visual editor like Scene Builder is a huge
> feature in my opinion. Being able to directly edit the UI in a visual
> manner makes it much easier for a developer to just jump in and change
> something.
>
> I also looked at the kotlin compose-mpp library Andrus mentioned. The
> approach it takes with a reactive, declarative UI is definitely the current
> trend. It is very much like SwiftUI, which I have used a bit. It says you
> can "preview" layouts in the IDE. If that actually works, then that makes a
> big difference. Without it, I would be hesitant to use this. Here's some
> sample code for a screen:
>
> https://github.com/JetBrains/compose-jb/blob/master/examples/issues/common/src/jvmAndAndroidMain/kotlin/androidx/ui/examples/jetissues/view/JetIssuesView.kt
>
> I like Kotlin and don't find it to be a big jump from Java.
>
> I think both of these are viable paths. It really depends on finding a
> person who is excited to champion the project. As long as a developer is
> passionate about doing this either approach should be fine. However, if the
> goal is to incorporate a larger developer community into the maintenance, I
> suspect the JFX route is easier for onboarding.
>
>
> On Sun, Dec 19, 2021 at 2:17 PM Michael Gentry 
> wrote:
>
> > Hi John (and anyone else who is curious),
> >
> > I think I've got it running again. Pull the changes.
> >
> > Haven't really updated the docs, so to run:
> >
> > From Terminal: mvn clean javafx:run
> > From Eclipse/IDE: Set up a Maven build with the "clean javafx:run" goal.
> >
> > You'll most likely need to load the included Cayenne Project (since
> > upgrading versions/etc isn't supported yet):
> >
> >   src/test/resources/cayenne-analytic.xml
> >
> > A good starting point to look at code/UI is the splash page since it is
> > pretty simple. If you don't have Scene Builder installed, grab it from
> > here:
> >
> >   https://gluonhq.com/products/scene-builder/
> >
> > Then open the splash page in Scene Builder:
> >
> >   src/main/resources/layouts/SplashLayout.fxml
> >
> > And open the Java code in Eclipse/IDE:
> >
> >   src/main/java/org/apache/cayenne/modeler/layout/SplashLayout.java
> >
> > Keep in mind this is just a demo/proof-of-concept and not fully
> functional.
> > Also, there are many other FXMLs you can open up in Scene Builder. The
> > approach I was going for was to have lots of components/views I could
> swap
> > in/out as navigation was triggered in the UI.
> >
> > Let me know if you have questions or can't run it.
> >
> > Note: If on macOS you might have to give Eclipse/Terminal permissions in
> > System Preferences. Also, if on Monterey, it likes to hide newly opened
> > windows behind current windows. I don't have an app icon yet, so it shows
> > up as a folder icon if you Command+Tab.
> >
> > mrg
> >
> >
> > On Thu, Dec 16, 2021 at 11:17 AM John Huss  wrote:
> >
> > > If we want to move off Swing I'd say this JavaFX project you started is
> > the
> > > best way to go.
> > >
> > > I can't get it to run out of the box. Any chance you could get it
> running
> > > again?
> > >
> > > On Tue, Dec 14, 2021 at 6:49 PM Michael Gentry 
> > > wrote:
> > >
> > > > I've considered an Electron app in the past. One negative is you lose
> > > > access to existing Java code, but perhaps there is a way around this
> > I've
> > > > not seen.
> > > >
> > > > Examples:
> > > > - Existing code to read model XML files.
> > > > - JDBC drivers.
> > > > - Velocity (assuming we want to continue using Velocity templates).
> > > >
> > > > For anyone curious, I thought JavaFX was looking good before I lost
> > > > momentum:
> > > 

Re: UI toolkit for the future Modeler

[John Huss]

Thanks Michael! I was able to run the JFX version on Java 11 and open the
sample model at "src/test/resources/cayenne-analytic.xml".

For JFX, the existence of a visual editor like Scene Builder is a huge
feature in my opinion. Being able to directly edit the UI in a visual
manner makes it much easier for a developer to just jump in and change
something.

I also looked at the kotlin compose-mpp library Andrus mentioned. The
approach it takes with a reactive, declarative UI is definitely the current
trend. It is very much like SwiftUI, which I have used a bit. It says you
can "preview" layouts in the IDE. If that actually works, then that makes a
big difference. Without it, I would be hesitant to use this. Here's some
sample code for a screen:
https://github.com/JetBrains/compose-jb/blob/master/examples/issues/common/src/jvmAndAndroidMain/kotlin/androidx/ui/examples/jetissues/view/JetIssuesView.kt

I like Kotlin and don't find it to be a big jump from Java.

I think both of these are viable paths. It really depends on finding a
person who is excited to champion the project. As long as a developer is
passionate about doing this either approach should be fine. However, if the
goal is to incorporate a larger developer community into the maintenance, I
suspect the JFX route is easier for onboarding.


On Sun, Dec 19, 2021 at 2:17 PM Michael Gentry  wrote:

> Hi John (and anyone else who is curious),
>
> I think I've got it running again. Pull the changes.
>
> Haven't really updated the docs, so to run:
>
> From Terminal: mvn clean javafx:run
> From Eclipse/IDE: Set up a Maven build with the "clean javafx:run" goal.
>
> You'll most likely need to load the included Cayenne Project (since
> upgrading versions/etc isn't supported yet):
>
>   src/test/resources/cayenne-analytic.xml
>
> A good starting point to look at code/UI is the splash page since it is
> pretty simple. If you don't have Scene Builder installed, grab it from
> here:
>
>   https://gluonhq.com/products/scene-builder/
>
> Then open the splash page in Scene Builder:
>
>   src/main/resources/layouts/SplashLayout.fxml
>
> And open the Java code in Eclipse/IDE:
>
>   src/main/java/org/apache/cayenne/modeler/layout/SplashLayout.java
>
> Keep in mind this is just a demo/proof-of-concept and not fully functional.
> Also, there are many other FXMLs you can open up in Scene Builder. The
> approach I was going for was to have lots of components/views I could swap
> in/out as navigation was triggered in the UI.
>
> Let me know if you have questions or can't run it.
>
> Note: If on macOS you might have to give Eclipse/Terminal permissions in
> System Preferences. Also, if on Monterey, it likes to hide newly opened
> windows behind current windows. I don't have an app icon yet, so it shows
> up as a folder icon if you Command+Tab.
>
> mrg
>
>
> On Thu, Dec 16, 2021 at 11:17 AM John Huss  wrote:
>
> > If we want to move off Swing I'd say this JavaFX project you started is
> the
> > best way to go.
> >
> > I can't get it to run out of the box. Any chance you could get it running
> > again?
> >
> > On Tue, Dec 14, 2021 at 6:49 PM Michael Gentry 
> > wrote:
> >
> > > I've considered an Electron app in the past. One negative is you lose
> > > access to existing Java code, but perhaps there is a way around this
> I've
> > > not seen.
> > >
> > > Examples:
> > > - Existing code to read model XML files.
> > > - JDBC drivers.
> > > - Velocity (assuming we want to continue using Velocity templates).
> > >
> > > For anyone curious, I thought JavaFX was looking good before I lost
> > > momentum:
> > >
> > > https://github.com/apache/cayenne-modeler
> > >
> > > If you look carefully, you'll see some of the extra features in the
> > > screenshots I was planning on adding, plus multiple windows (same
> project
> > > or different projects) in the video.
> > >
> > >
> > > On Tue, Dec 14, 2021 at 6:58 PM Lon Varscsak 
> > > wrote:
> > >
> > > > What about an Electron app? 😬
> > > >
> > > > On Tue, Dec 14, 2021 at 3:59 PM John Huss 
> wrote:
> > > >
> > > > > My 2 cents is that Java desktop UI is effectively dead. So
> switching
> > to
> > > > > another UI library that is either already dead or is dying isn't a
> > > great
> > > > > use of time. So I would try to change it as little as possible.
> > > > >
> > > > > For the tables with editable cells problem, my recommendation would
> > be
> > > to
> > > > > move editing into a separate "inspector" area that is laid out as a
> > > > > vertical form. Then the table can be read-only.
> > > > >
> > > > > For layout, I liked MigLayout when I did Swing apps back in the
> day.
> > > But
> > > > > that doesn't solve the problem with the existing usage of JGoodies.
> > > > >
> > > > >
> > > > > On Tue, Dec 14, 2021 at 12:37 AM Andrus Adamchik <
> > aadamc...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I see a couple of problems with the current UI (beside it being
> > > > > > subjectively old) :
> > > > > >
> > > > > 

Re: UI toolkit for the future Modeler

[Andrus Adamchik]

> Another concern I'd have is
> learning/mastering another language (Kotlin). It might be the right path,
> ultimately, but still a concern.


This is a real concern. Similar to what we previously discussed about writing 
the Modeler in JS. At least Kotlin is kinda Java though :)

> Would we be "encouraged" to use IntelliJ
> (for Kotlin support)? Haven't looked into Eclipse or even VSC support for
> Kotlin.

Kotlin is big on Android. Android Studio supports it. For non-Android use 
cases, looks like there are alternatives, but IntelliJ is still the best. As 
long as they have a non-crippled free Community Edition of IntelliJ, shouldn't 
be a big deal.

Andrus


> On Dec 11, 2021, at 4:21 PM, Michael Gentry  wrote:
> 
> I've not heard of it before. It seems that Google is kind of the upstream
> provider, but Google is known to drop things all the time, too. If that
> happened, I wonder what JetBrains would do? Another concern I'd have is
> learning/mastering another language (Kotlin). It might be the right path,
> ultimately, but still a concern. Would we be "encouraged" to use IntelliJ
> (for Kotlin support)? Haven't looked into Eclipse or even VSC support for
> Kotlin.
> 
> Looks like it already has native packaging, menu management, etc support:
> 
> https://github.com/JetBrains/compose-jb/blob/master/FEATURES.md#features-currently-available-in-compose-for-desktop
> 
> 
> Hopefully this wouldn't remain "Experimental" for long:
> 
> https://github.com/JetBrains/compose-jb/raw/master/tutorials/Getting_Started/screen3.png
> 
> 
> As for JavaFX and Oracle, I'm still confused if they are involved. The
> latest release (JavaFX 17, September 2021) still has Oracle on some of the
> docs:
> 
> https://openjfx.io/javadoc/17/javafx.fxml/javafx/fxml/doc-files/introduction_to_fxml.html
> 
> https://openjfx.io/javadoc/17/javafx.graphics/javafx/scene/doc-files/cssref.html
> 
> 
> I also really liked using Scene Builder to create the FXML visually and not
> have the UI "code" in the Java code. Compose seems more traditional and
> with the UI in the source code. Perhaps I'm just more of a visual person in
> that regard, which is another reason why I like using CM to model a DB
> instead of annotations or whatnot in code.
> 
> 
> On Sat, Dec 11, 2021 at 3:15 AM Andrus Adamchik  wrote:
> 
>> A datapoint to our perennial discussion of technology to use for the
>> future CayenneModeler... With Swing being old and crusty, and JavaFX no
>> longer supported by Oracle, perhaps we should be looking for something
>> fresh. I just came across a new "Compose Multiplatform" desktop UI
>> framework by JetBrains [1]. It is programmed in Kotlin and is based on
>> Google toolkit for Android. Their GitHub examples [2] are not that visually
>> impressive, but I would imagine it is a matter of styling. A million $
>> question is whether it will be around and open source in 10-15 years.
>> 
>> Anyone knows anything about it?
>> 
>> Andrus
>> 
>> [1] https://www.jetbrains.com/lp/compose-mpp/
>> [2]
>> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
>> 
>> 
>> 

Re: UI toolkit for the future Modeler

[Michael Gentry]

Hi John (and anyone else who is curious),

I think I've got it running again. Pull the changes.

Haven't really updated the docs, so to run:

>From Terminal: mvn clean javafx:run
>From Eclipse/IDE: Set up a Maven build with the "clean javafx:run" goal.

You'll most likely need to load the included Cayenne Project (since
upgrading versions/etc isn't supported yet):

  src/test/resources/cayenne-analytic.xml

A good starting point to look at code/UI is the splash page since it is
pretty simple. If you don't have Scene Builder installed, grab it from here:

  https://gluonhq.com/products/scene-builder/

Then open the splash page in Scene Builder:

  src/main/resources/layouts/SplashLayout.fxml

And open the Java code in Eclipse/IDE:

  src/main/java/org/apache/cayenne/modeler/layout/SplashLayout.java

Keep in mind this is just a demo/proof-of-concept and not fully functional.
Also, there are many other FXMLs you can open up in Scene Builder. The
approach I was going for was to have lots of components/views I could swap
in/out as navigation was triggered in the UI.

Let me know if you have questions or can't run it.

Note: If on macOS you might have to give Eclipse/Terminal permissions in
System Preferences. Also, if on Monterey, it likes to hide newly opened
windows behind current windows. I don't have an app icon yet, so it shows
up as a folder icon if you Command+Tab.

mrg


On Thu, Dec 16, 2021 at 11:17 AM John Huss  wrote:

> If we want to move off Swing I'd say this JavaFX project you started is the
> best way to go.
>
> I can't get it to run out of the box. Any chance you could get it running
> again?
>
> On Tue, Dec 14, 2021 at 6:49 PM Michael Gentry 
> wrote:
>
> > I've considered an Electron app in the past. One negative is you lose
> > access to existing Java code, but perhaps there is a way around this I've
> > not seen.
> >
> > Examples:
> > - Existing code to read model XML files.
> > - JDBC drivers.
> > - Velocity (assuming we want to continue using Velocity templates).
> >
> > For anyone curious, I thought JavaFX was looking good before I lost
> > momentum:
> >
> > https://github.com/apache/cayenne-modeler
> >
> > If you look carefully, you'll see some of the extra features in the
> > screenshots I was planning on adding, plus multiple windows (same project
> > or different projects) in the video.
> >
> >
> > On Tue, Dec 14, 2021 at 6:58 PM Lon Varscsak 
> > wrote:
> >
> > > What about an Electron app? 😬
> > >
> > > On Tue, Dec 14, 2021 at 3:59 PM John Huss  wrote:
> > >
> > > > My 2 cents is that Java desktop UI is effectively dead. So switching
> to
> > > > another UI library that is either already dead or is dying isn't a
> > great
> > > > use of time. So I would try to change it as little as possible.
> > > >
> > > > For the tables with editable cells problem, my recommendation would
> be
> > to
> > > > move editing into a separate "inspector" area that is laid out as a
> > > > vertical form. Then the table can be read-only.
> > > >
> > > > For layout, I liked MigLayout when I did Swing apps back in the day.
> > But
> > > > that doesn't solve the problem with the existing usage of JGoodies.
> > > >
> > > >
> > > > On Tue, Dec 14, 2021 at 12:37 AM Andrus Adamchik <
> aadamc...@gmail.com>
> > > > wrote:
> > > >
> > > > > I see a couple of problems with the current UI (beside it being
> > > > > subjectively old) :
> > > > >
> > > > > * We are effectively blocked from any significant evolution of the
> > > > > Modeler. Any time we want to do anything fancy (e.g. improve
> > usability
> > > of
> > > > > tables with editable cells, etc.), we quickly run into the wall
> with
> > > > Swing
> > > > > capabilities.
> > > > > * JGoodies library that we depend heavily upon for layouts is no
> > longer
> > > > > free/open source [1], creating risks for JVM upgrades.
> > > > >
> > > > > So modernization of the Modeler is a practical matter.
> > > > >
> > > > > Looks like Fleet is not using Compose [2], but a lesser known
> > JetBrains
> > > > > Toolbox does [3]. And everyone admits it is still raw.
> > > > >
> > > > > Andrus
> > > > >
> > > > > [1] https://www.jgoodies.com/downloads/libraries/
> > > > > [2] https://twitter.com/jetbrains/status/1465245360973131777 <
> > > > > https://twitter.com/jetbrains/status/1465245360973131777>
> > > > > [3]
> > > > >
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > > <
> > > > >
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > > On Dec 14, 2021, at 12:48 AM, John Huss 
> > wrote:
> > > > > >
> > > > > > I believe that compose UI library is used to build the new
> upcoming
> > > IDE
> > > > > > from JetBrains called Fleet. So I expect it will continue to be
> > > > supported
> > > > > > unless that product completely flops.
> > > > > >
> > > > > > I don't mind the current modeler UI. 

Re: UI toolkit for the future Modeler

[Sergey Baranov]

Maybe try to communicate with JGoodies author? It is single-man company
(not huge corporation) and you have an open source non-profit project. Who
knows, maybe he will to support Cayenne...
So you can continue with robust and battle-proven Swing, no need to
transfer to javafx, electron, sciter or some another garbage...

чт, 16 дек. 2021 г. в 19:17, John Huss :

> If we want to move off Swing I'd say this JavaFX project you started is the
> best way to go.
>
> I can't get it to run out of the box. Any chance you could get it running
> again?
>
> On Tue, Dec 14, 2021 at 6:49 PM Michael Gentry 
> wrote:
>
> > I've considered an Electron app in the past. One negative is you lose
> > access to existing Java code, but perhaps there is a way around this I've
> > not seen.
> >
> > Examples:
> > - Existing code to read model XML files.
> > - JDBC drivers.
> > - Velocity (assuming we want to continue using Velocity templates).
> >
> > For anyone curious, I thought JavaFX was looking good before I lost
> > momentum:
> >
> > https://github.com/apache/cayenne-modeler
> >
> > If you look carefully, you'll see some of the extra features in the
> > screenshots I was planning on adding, plus multiple windows (same project
> > or different projects) in the video.
> >
> >
> > On Tue, Dec 14, 2021 at 6:58 PM Lon Varscsak 
> > wrote:
> >
> > > What about an Electron app? 😬
> > >
> > > On Tue, Dec 14, 2021 at 3:59 PM John Huss  wrote:
> > >
> > > > My 2 cents is that Java desktop UI is effectively dead. So switching
> to
> > > > another UI library that is either already dead or is dying isn't a
> > great
> > > > use of time. So I would try to change it as little as possible.
> > > >
> > > > For the tables with editable cells problem, my recommendation would
> be
> > to
> > > > move editing into a separate "inspector" area that is laid out as a
> > > > vertical form. Then the table can be read-only.
> > > >
> > > > For layout, I liked MigLayout when I did Swing apps back in the day.
> > But
> > > > that doesn't solve the problem with the existing usage of JGoodies.
> > > >
> > > >
> > > > On Tue, Dec 14, 2021 at 12:37 AM Andrus Adamchik <
> aadamc...@gmail.com>
> > > > wrote:
> > > >
> > > > > I see a couple of problems with the current UI (beside it being
> > > > > subjectively old) :
> > > > >
> > > > > * We are effectively blocked from any significant evolution of the
> > > > > Modeler. Any time we want to do anything fancy (e.g. improve
> > usability
> > > of
> > > > > tables with editable cells, etc.), we quickly run into the wall
> with
> > > > Swing
> > > > > capabilities.
> > > > > * JGoodies library that we depend heavily upon for layouts is no
> > longer
> > > > > free/open source [1], creating risks for JVM upgrades.
> > > > >
> > > > > So modernization of the Modeler is a practical matter.
> > > > >
> > > > > Looks like Fleet is not using Compose [2], but a lesser known
> > JetBrains
> > > > > Toolbox does [3]. And everyone admits it is still raw.
> > > > >
> > > > > Andrus
> > > > >
> > > > > [1] https://www.jgoodies.com/downloads/libraries/
> > > > > [2] https://twitter.com/jetbrains/status/1465245360973131777 <
> > > > > https://twitter.com/jetbrains/status/1465245360973131777>
> > > > > [3]
> > > > >
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > > <
> > > > >
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > > On Dec 14, 2021, at 12:48 AM, John Huss 
> > wrote:
> > > > > >
> > > > > > I believe that compose UI library is used to build the new
> upcoming
> > > IDE
> > > > > > from JetBrains called Fleet. So I expect it will continue to be
> > > > supported
> > > > > > unless that product completely flops.
> > > > > >
> > > > > > I don't mind the current modeler UI. It's good enough for me.
> > > > > >
> > > > > > https://www.jetbrains.com/fleet/
> > > > > >
> > > > > >
> > > > > > On Sat, Dec 11, 2021 at 2:15 AM Andrus Adamchik <
> > aadamc...@gmail.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > >> A datapoint to our perennial discussion of technology to use for
> > the
> > > > > >> future CayenneModeler... With Swing being old and crusty, and
> > JavaFX
> > > > no
> > > > > >> longer supported by Oracle, perhaps we should be looking for
> > > something
> > > > > >> fresh. I just came across a new "Compose Multiplatform" desktop
> UI
> > > > > >> framework by JetBrains [1]. It is programmed in Kotlin and is
> > based
> > > on
> > > > > >> Google toolkit for Android. Their GitHub examples [2] are not
> that
> > > > > visually
> > > > > >> impressive, but I would imagine it is a matter of styling. A
> > > million $
> > > > > >> question is whether it will be around and open source in 10-15
> > > years.
> > > > > >>
> > > > > >> Anyone knows anything about it?
> > > > > >>
> > > > > >> Andrus
> > > > > >>
> > > > > >> [1] https://www.jetbrains

Re: UI toolkit for the future Modeler

[Michael Gentry]

Yeah, it is likely suffering from bit rot. Was working with I last
committed it, I believe. I think the last thing I was working on was a good
pattern to handle change notifications and undos. I'll see if I can get it
up and running again.



On Thu, Dec 16, 2021 at 11:17 AM John Huss  wrote:

> If we want to move off Swing I'd say this JavaFX project you started is the
> best way to go.
>
> I can't get it to run out of the box. Any chance you could get it running
> again?
>
> On Tue, Dec 14, 2021 at 6:49 PM Michael Gentry 
> wrote:
>
> > I've considered an Electron app in the past. One negative is you lose
> > access to existing Java code, but perhaps there is a way around this I've
> > not seen.
> >
> > Examples:
> > - Existing code to read model XML files.
> > - JDBC drivers.
> > - Velocity (assuming we want to continue using Velocity templates).
> >
> > For anyone curious, I thought JavaFX was looking good before I lost
> > momentum:
> >
> > https://github.com/apache/cayenne-modeler
> >
> > If you look carefully, you'll see some of the extra features in the
> > screenshots I was planning on adding, plus multiple windows (same project
> > or different projects) in the video.
> >
> >
> > On Tue, Dec 14, 2021 at 6:58 PM Lon Varscsak 
> > wrote:
> >
> > > What about an Electron app? 😬
> > >
> > > On Tue, Dec 14, 2021 at 3:59 PM John Huss  wrote:
> > >
> > > > My 2 cents is that Java desktop UI is effectively dead. So switching
> to
> > > > another UI library that is either already dead or is dying isn't a
> > great
> > > > use of time. So I would try to change it as little as possible.
> > > >
> > > > For the tables with editable cells problem, my recommendation would
> be
> > to
> > > > move editing into a separate "inspector" area that is laid out as a
> > > > vertical form. Then the table can be read-only.
> > > >
> > > > For layout, I liked MigLayout when I did Swing apps back in the day.
> > But
> > > > that doesn't solve the problem with the existing usage of JGoodies.
> > > >
> > > >
> > > > On Tue, Dec 14, 2021 at 12:37 AM Andrus Adamchik <
> aadamc...@gmail.com>
> > > > wrote:
> > > >
> > > > > I see a couple of problems with the current UI (beside it being
> > > > > subjectively old) :
> > > > >
> > > > > * We are effectively blocked from any significant evolution of the
> > > > > Modeler. Any time we want to do anything fancy (e.g. improve
> > usability
> > > of
> > > > > tables with editable cells, etc.), we quickly run into the wall
> with
> > > > Swing
> > > > > capabilities.
> > > > > * JGoodies library that we depend heavily upon for layouts is no
> > longer
> > > > > free/open source [1], creating risks for JVM upgrades.
> > > > >
> > > > > So modernization of the Modeler is a practical matter.
> > > > >
> > > > > Looks like Fleet is not using Compose [2], but a lesser known
> > JetBrains
> > > > > Toolbox does [3]. And everyone admits it is still raw.
> > > > >
> > > > > Andrus
> > > > >
> > > > > [1] https://www.jgoodies.com/downloads/libraries/
> > > > > [2] https://twitter.com/jetbrains/status/1465245360973131777 <
> > > > > https://twitter.com/jetbrains/status/1465245360973131777>
> > > > > [3]
> > > > >
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > > <
> > > > >
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > > On Dec 14, 2021, at 12:48 AM, John Huss 
> > wrote:
> > > > > >
> > > > > > I believe that compose UI library is used to build the new
> upcoming
> > > IDE
> > > > > > from JetBrains called Fleet. So I expect it will continue to be
> > > > supported
> > > > > > unless that product completely flops.
> > > > > >
> > > > > > I don't mind the current modeler UI. It's good enough for me.
> > > > > >
> > > > > > https://www.jetbrains.com/fleet/
> > > > > >
> > > > > >
> > > > > > On Sat, Dec 11, 2021 at 2:15 AM Andrus Adamchik <
> > aadamc...@gmail.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > >> A datapoint to our perennial discussion of technology to use for
> > the
> > > > > >> future CayenneModeler... With Swing being old and crusty, and
> > JavaFX
> > > > no
> > > > > >> longer supported by Oracle, perhaps we should be looking for
> > > something
> > > > > >> fresh. I just came across a new "Compose Multiplatform" desktop
> UI
> > > > > >> framework by JetBrains [1]. It is programmed in Kotlin and is
> > based
> > > on
> > > > > >> Google toolkit for Android. Their GitHub examples [2] are not
> that
> > > > > visually
> > > > > >> impressive, but I would imagine it is a matter of styling. A
> > > million $
> > > > > >> question is whether it will be around and open source in 10-15
> > > years.
> > > > > >>
> > > > > >> Anyone knows anything about it?
> > > > > >>
> > > > > >> Andrus
> > > > > >>
> > > > > >> [1] https://www.jetbrains.com/lp/compose-mpp/
> > > > > >> [2]
> > > > > >>
> > > > >
> > > >
>

Re: UI toolkit for the future Modeler

[John Huss]

If we want to move off Swing I'd say this JavaFX project you started is the
best way to go.

I can't get it to run out of the box. Any chance you could get it running
again?

On Tue, Dec 14, 2021 at 6:49 PM Michael Gentry  wrote:

> I've considered an Electron app in the past. One negative is you lose
> access to existing Java code, but perhaps there is a way around this I've
> not seen.
>
> Examples:
> - Existing code to read model XML files.
> - JDBC drivers.
> - Velocity (assuming we want to continue using Velocity templates).
>
> For anyone curious, I thought JavaFX was looking good before I lost
> momentum:
>
> https://github.com/apache/cayenne-modeler
>
> If you look carefully, you'll see some of the extra features in the
> screenshots I was planning on adding, plus multiple windows (same project
> or different projects) in the video.
>
>
> On Tue, Dec 14, 2021 at 6:58 PM Lon Varscsak 
> wrote:
>
> > What about an Electron app? 😬
> >
> > On Tue, Dec 14, 2021 at 3:59 PM John Huss  wrote:
> >
> > > My 2 cents is that Java desktop UI is effectively dead. So switching to
> > > another UI library that is either already dead or is dying isn't a
> great
> > > use of time. So I would try to change it as little as possible.
> > >
> > > For the tables with editable cells problem, my recommendation would be
> to
> > > move editing into a separate "inspector" area that is laid out as a
> > > vertical form. Then the table can be read-only.
> > >
> > > For layout, I liked MigLayout when I did Swing apps back in the day.
> But
> > > that doesn't solve the problem with the existing usage of JGoodies.
> > >
> > >
> > > On Tue, Dec 14, 2021 at 12:37 AM Andrus Adamchik 
> > > wrote:
> > >
> > > > I see a couple of problems with the current UI (beside it being
> > > > subjectively old) :
> > > >
> > > > * We are effectively blocked from any significant evolution of the
> > > > Modeler. Any time we want to do anything fancy (e.g. improve
> usability
> > of
> > > > tables with editable cells, etc.), we quickly run into the wall with
> > > Swing
> > > > capabilities.
> > > > * JGoodies library that we depend heavily upon for layouts is no
> longer
> > > > free/open source [1], creating risks for JVM upgrades.
> > > >
> > > > So modernization of the Modeler is a practical matter.
> > > >
> > > > Looks like Fleet is not using Compose [2], but a lesser known
> JetBrains
> > > > Toolbox does [3]. And everyone admits it is still raw.
> > > >
> > > > Andrus
> > > >
> > > > [1] https://www.jgoodies.com/downloads/libraries/
> > > > [2] https://twitter.com/jetbrains/status/1465245360973131777 <
> > > > https://twitter.com/jetbrains/status/1465245360973131777>
> > > > [3]
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > <
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > >
> > > >
> > > >
> > > >
> > > > > On Dec 14, 2021, at 12:48 AM, John Huss 
> wrote:
> > > > >
> > > > > I believe that compose UI library is used to build the new upcoming
> > IDE
> > > > > from JetBrains called Fleet. So I expect it will continue to be
> > > supported
> > > > > unless that product completely flops.
> > > > >
> > > > > I don't mind the current modeler UI. It's good enough for me.
> > > > >
> > > > > https://www.jetbrains.com/fleet/
> > > > >
> > > > >
> > > > > On Sat, Dec 11, 2021 at 2:15 AM Andrus Adamchik <
> aadamc...@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > >> A datapoint to our perennial discussion of technology to use for
> the
> > > > >> future CayenneModeler... With Swing being old and crusty, and
> JavaFX
> > > no
> > > > >> longer supported by Oracle, perhaps we should be looking for
> > something
> > > > >> fresh. I just came across a new "Compose Multiplatform" desktop UI
> > > > >> framework by JetBrains [1]. It is programmed in Kotlin and is
> based
> > on
> > > > >> Google toolkit for Android. Their GitHub examples [2] are not that
> > > > visually
> > > > >> impressive, but I would imagine it is a matter of styling. A
> > million $
> > > > >> question is whether it will be around and open source in 10-15
> > years.
> > > > >>
> > > > >> Anyone knows anything about it?
> > > > >>
> > > > >> Andrus
> > > > >>
> > > > >> [1] https://www.jetbrains.com/lp/compose-mpp/
> > > > >> [2]
> > > > >>
> > > >
> > >
> >
> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: UI toolkit for the future Modeler

[Aristedes Maniatis]

A few random thoughts.


## Integrations

If Modeler changed to another language or UI library, could it leverage 
that to better integrate with other tooling?


For example, could making parts of the modeler a js library allow it to 
work with existing js database modelers like Vertabelo 
https://my.vertabelo.com/try-db-designer




Here are some desktop app database modelers I found:

* https://www.toadworld.com/products/toad-data-modeler

* https://www.mysql.com/products/workbench/

* https://www.idera.com/products/er-studio/enterprise-data-modeling

* https://sparxsystems.com/products/ea/

* https://astah.net/



## Building on an existing platform

Is it worth examining DBeaver to see whether Cayenne functionality could 
be added on top of the existing ERD features? 
https://dbeaver.com/docs/wiki/ER-Diagrams



What would be involved in making Cayenne modeler an Eclipse or Intellij 
plugin? Would that increase market awareness, especially if the IDE 
could be made more aware of how to handle Cayenne annotations.



## Competing implementations

It is worth looking at the feature set over here:

https://tools.jboss.org/features/hibernate.html#hibernate-console


I like the idea of converting a query into SQL in order to understand 
what it is doing. But of course that needs a modeler which can talk to 
the Java Cayenne library and might rule out a pure browser/js 
implementation. Rather it might look like the Cayenne server library 
with some sort of rest API to serve the front end. Cayenne as a service, 
if you will.




## Browser/cloud modeler

A modeler which runs inside a browser reduces the barrier to entry 
hugely. Imagine going to a demo website, uploading your database schema 
and being able to instantly play with your schema and output a working 
Java project.



## Developer skills

Does anyone in the existing team have js skills?



Ari




On 11/12/21 7:15pm, Andrus Adamchik wrote:

A datapoint to our perennial discussion of technology to use for the future 
CayenneModeler... With Swing being old and crusty, and JavaFX no longer supported by 
Oracle, perhaps we should be looking for something fresh. I just came across a new 
"Compose Multiplatform" desktop UI framework by JetBrains [1]. It is programmed 
in Kotlin and is based on Google toolkit for Android. Their GitHub examples [2] are not 
that visually impressive, but I would imagine it is a matter of styling. A million $ 
question is whether it will be around and open source in 10-15 years.

Anyone knows anything about it?

Andrus

[1] https://www.jetbrains.com/lp/compose-mpp/
[2] https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png

Re: UI toolkit for the future Modeler

[Michael Gentry]

I thought about a web app (non-Electron) in the past, too, and it just
seemed even clunkier. For example, I would really like the ability to have
the same model open in multiple windows, so I could see different parts at
the same time. Doing that in a browser window would be awkward at best and
hard to sync changes between windows. Plus, how do you really launch the
app? Command-line only? Shell scripts? On the Mac especially, you'd not
have the custom menus or app icons.

JavaFX + Scene Builder to edit the FXML still seems the "sane" option to
me. Not that there is a lot of sanity. Java gave up on the desktop a long
time ago. Kind of sad because Sun worked with NeXT in creating OpenStep and
could've made Java's UI OpenStep-based, instead of AWT and then Swing. In
some ways, OpenStep is still alive in macOS and iOS. And UI apps in Java
leave us wanting.

mrg

PS. I'm using Spring + Thymeleaf at work currently and I REALLY miss
Tapestry.


On Tue, Dec 14, 2021 at 8:24 PM Lon Varscsak  wrote:

> I've thought about this before for apps...what if the app runs a web app
> (using whatever stack Andrus decides...maybe Tapestry) as the backend.  I
> don't know if that's possible.
>
> Also, on JavaFX...I wrote an app in it recently and it's decent. It still
> seems to be alive via openjfx.io, but I could be wrong.
>
> On Tue, Dec 14, 2021 at 5:49 PM Michael Gentry 
> wrote:
>
> > I've considered an Electron app in the past. One negative is you lose
> > access to existing Java code, but perhaps there is a way around this I've
> > not seen.
> >
> > Examples:
> > - Existing code to read model XML files.
> > - JDBC drivers.
> > - Velocity (assuming we want to continue using Velocity templates).
> >
> > For anyone curious, I thought JavaFX was looking good before I lost
> > momentum:
> >
> > https://github.com/apache/cayenne-modeler
> >
> > If you look carefully, you'll see some of the extra features in the
> > screenshots I was planning on adding, plus multiple windows (same project
> > or different projects) in the video.
> >
> >
> > On Tue, Dec 14, 2021 at 6:58 PM Lon Varscsak 
> > wrote:
> >
> > > What about an Electron app? 😬
> > >
> > > On Tue, Dec 14, 2021 at 3:59 PM John Huss  wrote:
> > >
> > > > My 2 cents is that Java desktop UI is effectively dead. So switching
> to
> > > > another UI library that is either already dead or is dying isn't a
> > great
> > > > use of time. So I would try to change it as little as possible.
> > > >
> > > > For the tables with editable cells problem, my recommendation would
> be
> > to
> > > > move editing into a separate "inspector" area that is laid out as a
> > > > vertical form. Then the table can be read-only.
> > > >
> > > > For layout, I liked MigLayout when I did Swing apps back in the day.
> > But
> > > > that doesn't solve the problem with the existing usage of JGoodies.
> > > >
> > > >
> > > > On Tue, Dec 14, 2021 at 12:37 AM Andrus Adamchik <
> aadamc...@gmail.com>
> > > > wrote:
> > > >
> > > > > I see a couple of problems with the current UI (beside it being
> > > > > subjectively old) :
> > > > >
> > > > > * We are effectively blocked from any significant evolution of the
> > > > > Modeler. Any time we want to do anything fancy (e.g. improve
> > usability
> > > of
> > > > > tables with editable cells, etc.), we quickly run into the wall
> with
> > > > Swing
> > > > > capabilities.
> > > > > * JGoodies library that we depend heavily upon for layouts is no
> > longer
> > > > > free/open source [1], creating risks for JVM upgrades.
> > > > >
> > > > > So modernization of the Modeler is a practical matter.
> > > > >
> > > > > Looks like Fleet is not using Compose [2], but a lesser known
> > JetBrains
> > > > > Toolbox does [3]. And everyone admits it is still raw.
> > > > >
> > > > > Andrus
> > > > >
> > > > > [1] https://www.jgoodies.com/downloads/libraries/
> > > > > [2] https://twitter.com/jetbrains/status/1465245360973131777 <
> > > > > https://twitter.com/jetbrains/status/1465245360973131777>
> > > > > [3]
> > > > >
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > > <
> > > > >
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > > On Dec 14, 2021, at 12:48 AM, John Huss 
> > wrote:
> > > > > >
> > > > > > I believe that compose UI library is used to build the new
> upcoming
> > > IDE
> > > > > > from JetBrains called Fleet. So I expect it will continue to be
> > > > supported
> > > > > > unless that product completely flops.
> > > > > >
> > > > > > I don't mind the current modeler UI. It's good enough for me.
> > > > > >
> > > > > > https://www.jetbrains.com/fleet/
> > > > > >
> > > > > >
> > > > > > On Sat, Dec 11, 2021 at 2:15 AM Andrus Adamchik <
> > aadamc...@gmail.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > >> A datapoint to our perennial discussion of technology to use for
> > the
> > > 

Re: UI toolkit for the future Modeler

[Lon Varscsak]

I've thought about this before for apps...what if the app runs a web app
(using whatever stack Andrus decides...maybe Tapestry) as the backend.  I
don't know if that's possible.

Also, on JavaFX...I wrote an app in it recently and it's decent. It still
seems to be alive via openjfx.io, but I could be wrong.

On Tue, Dec 14, 2021 at 5:49 PM Michael Gentry  wrote:

> I've considered an Electron app in the past. One negative is you lose
> access to existing Java code, but perhaps there is a way around this I've
> not seen.
>
> Examples:
> - Existing code to read model XML files.
> - JDBC drivers.
> - Velocity (assuming we want to continue using Velocity templates).
>
> For anyone curious, I thought JavaFX was looking good before I lost
> momentum:
>
> https://github.com/apache/cayenne-modeler
>
> If you look carefully, you'll see some of the extra features in the
> screenshots I was planning on adding, plus multiple windows (same project
> or different projects) in the video.
>
>
> On Tue, Dec 14, 2021 at 6:58 PM Lon Varscsak 
> wrote:
>
> > What about an Electron app? 😬
> >
> > On Tue, Dec 14, 2021 at 3:59 PM John Huss  wrote:
> >
> > > My 2 cents is that Java desktop UI is effectively dead. So switching to
> > > another UI library that is either already dead or is dying isn't a
> great
> > > use of time. So I would try to change it as little as possible.
> > >
> > > For the tables with editable cells problem, my recommendation would be
> to
> > > move editing into a separate "inspector" area that is laid out as a
> > > vertical form. Then the table can be read-only.
> > >
> > > For layout, I liked MigLayout when I did Swing apps back in the day.
> But
> > > that doesn't solve the problem with the existing usage of JGoodies.
> > >
> > >
> > > On Tue, Dec 14, 2021 at 12:37 AM Andrus Adamchik 
> > > wrote:
> > >
> > > > I see a couple of problems with the current UI (beside it being
> > > > subjectively old) :
> > > >
> > > > * We are effectively blocked from any significant evolution of the
> > > > Modeler. Any time we want to do anything fancy (e.g. improve
> usability
> > of
> > > > tables with editable cells, etc.), we quickly run into the wall with
> > > Swing
> > > > capabilities.
> > > > * JGoodies library that we depend heavily upon for layouts is no
> longer
> > > > free/open source [1], creating risks for JVM upgrades.
> > > >
> > > > So modernization of the Modeler is a practical matter.
> > > >
> > > > Looks like Fleet is not using Compose [2], but a lesser known
> JetBrains
> > > > Toolbox does [3]. And everyone admits it is still raw.
> > > >
> > > > Andrus
> > > >
> > > > [1] https://www.jgoodies.com/downloads/libraries/
> > > > [2] https://twitter.com/jetbrains/status/1465245360973131777 <
> > > > https://twitter.com/jetbrains/status/1465245360973131777>
> > > > [3]
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > <
> > > >
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > > >
> > > >
> > > >
> > > >
> > > > > On Dec 14, 2021, at 12:48 AM, John Huss 
> wrote:
> > > > >
> > > > > I believe that compose UI library is used to build the new upcoming
> > IDE
> > > > > from JetBrains called Fleet. So I expect it will continue to be
> > > supported
> > > > > unless that product completely flops.
> > > > >
> > > > > I don't mind the current modeler UI. It's good enough for me.
> > > > >
> > > > > https://www.jetbrains.com/fleet/
> > > > >
> > > > >
> > > > > On Sat, Dec 11, 2021 at 2:15 AM Andrus Adamchik <
> aadamc...@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > >> A datapoint to our perennial discussion of technology to use for
> the
> > > > >> future CayenneModeler... With Swing being old and crusty, and
> JavaFX
> > > no
> > > > >> longer supported by Oracle, perhaps we should be looking for
> > something
> > > > >> fresh. I just came across a new "Compose Multiplatform" desktop UI
> > > > >> framework by JetBrains [1]. It is programmed in Kotlin and is
> based
> > on
> > > > >> Google toolkit for Android. Their GitHub examples [2] are not that
> > > > visually
> > > > >> impressive, but I would imagine it is a matter of styling. A
> > million $
> > > > >> question is whether it will be around and open source in 10-15
> > years.
> > > > >>
> > > > >> Anyone knows anything about it?
> > > > >>
> > > > >> Andrus
> > > > >>
> > > > >> [1] https://www.jetbrains.com/lp/compose-mpp/
> > > > >> [2]
> > > > >>
> > > >
> > >
> >
> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
> > > > >>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>

Re: UI toolkit for the future Modeler

[Michael Gentry]

I've considered an Electron app in the past. One negative is you lose
access to existing Java code, but perhaps there is a way around this I've
not seen.

Examples:
- Existing code to read model XML files.
- JDBC drivers.
- Velocity (assuming we want to continue using Velocity templates).

For anyone curious, I thought JavaFX was looking good before I lost
momentum:

https://github.com/apache/cayenne-modeler

If you look carefully, you'll see some of the extra features in the
screenshots I was planning on adding, plus multiple windows (same project
or different projects) in the video.


On Tue, Dec 14, 2021 at 6:58 PM Lon Varscsak  wrote:

> What about an Electron app? 😬
>
> On Tue, Dec 14, 2021 at 3:59 PM John Huss  wrote:
>
> > My 2 cents is that Java desktop UI is effectively dead. So switching to
> > another UI library that is either already dead or is dying isn't a great
> > use of time. So I would try to change it as little as possible.
> >
> > For the tables with editable cells problem, my recommendation would be to
> > move editing into a separate "inspector" area that is laid out as a
> > vertical form. Then the table can be read-only.
> >
> > For layout, I liked MigLayout when I did Swing apps back in the day. But
> > that doesn't solve the problem with the existing usage of JGoodies.
> >
> >
> > On Tue, Dec 14, 2021 at 12:37 AM Andrus Adamchik 
> > wrote:
> >
> > > I see a couple of problems with the current UI (beside it being
> > > subjectively old) :
> > >
> > > * We are effectively blocked from any significant evolution of the
> > > Modeler. Any time we want to do anything fancy (e.g. improve usability
> of
> > > tables with editable cells, etc.), we quickly run into the wall with
> > Swing
> > > capabilities.
> > > * JGoodies library that we depend heavily upon for layouts is no longer
> > > free/open source [1], creating risks for JVM upgrades.
> > >
> > > So modernization of the Modeler is a practical matter.
> > >
> > > Looks like Fleet is not using Compose [2], but a lesser known JetBrains
> > > Toolbox does [3]. And everyone admits it is still raw.
> > >
> > > Andrus
> > >
> > > [1] https://www.jgoodies.com/downloads/libraries/
> > > [2] https://twitter.com/jetbrains/status/1465245360973131777 <
> > > https://twitter.com/jetbrains/status/1465245360973131777>
> > > [3]
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > <
> > >
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > > >
> > >
> > >
> > >
> > > > On Dec 14, 2021, at 12:48 AM, John Huss  wrote:
> > > >
> > > > I believe that compose UI library is used to build the new upcoming
> IDE
> > > > from JetBrains called Fleet. So I expect it will continue to be
> > supported
> > > > unless that product completely flops.
> > > >
> > > > I don't mind the current modeler UI. It's good enough for me.
> > > >
> > > > https://www.jetbrains.com/fleet/
> > > >
> > > >
> > > > On Sat, Dec 11, 2021 at 2:15 AM Andrus Adamchik  >
> > > wrote:
> > > >
> > > >> A datapoint to our perennial discussion of technology to use for the
> > > >> future CayenneModeler... With Swing being old and crusty, and JavaFX
> > no
> > > >> longer supported by Oracle, perhaps we should be looking for
> something
> > > >> fresh. I just came across a new "Compose Multiplatform" desktop UI
> > > >> framework by JetBrains [1]. It is programmed in Kotlin and is based
> on
> > > >> Google toolkit for Android. Their GitHub examples [2] are not that
> > > visually
> > > >> impressive, but I would imagine it is a matter of styling. A
> million $
> > > >> question is whether it will be around and open source in 10-15
> years.
> > > >>
> > > >> Anyone knows anything about it?
> > > >>
> > > >> Andrus
> > > >>
> > > >> [1] https://www.jetbrains.com/lp/compose-mpp/
> > > >> [2]
> > > >>
> > >
> >
> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
> > > >>
> > > >>
> > > >>
> > >
> > >
> >
>

Re: UI toolkit for the future Modeler

[Lon Varscsak]

What about an Electron app? 😬

On Tue, Dec 14, 2021 at 3:59 PM John Huss  wrote:

> My 2 cents is that Java desktop UI is effectively dead. So switching to
> another UI library that is either already dead or is dying isn't a great
> use of time. So I would try to change it as little as possible.
>
> For the tables with editable cells problem, my recommendation would be to
> move editing into a separate "inspector" area that is laid out as a
> vertical form. Then the table can be read-only.
>
> For layout, I liked MigLayout when I did Swing apps back in the day. But
> that doesn't solve the problem with the existing usage of JGoodies.
>
>
> On Tue, Dec 14, 2021 at 12:37 AM Andrus Adamchik 
> wrote:
>
> > I see a couple of problems with the current UI (beside it being
> > subjectively old) :
> >
> > * We are effectively blocked from any significant evolution of the
> > Modeler. Any time we want to do anything fancy (e.g. improve usability of
> > tables with editable cells, etc.), we quickly run into the wall with
> Swing
> > capabilities.
> > * JGoodies library that we depend heavily upon for layouts is no longer
> > free/open source [1], creating risks for JVM upgrades.
> >
> > So modernization of the Modeler is a practical matter.
> >
> > Looks like Fleet is not using Compose [2], but a lesser known JetBrains
> > Toolbox does [3]. And everyone admits it is still raw.
> >
> > Andrus
> >
> > [1] https://www.jgoodies.com/downloads/libraries/
> > [2] https://twitter.com/jetbrains/status/1465245360973131777 <
> > https://twitter.com/jetbrains/status/1465245360973131777>
> > [3]
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > <
> >
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> > >
> >
> >
> >
> > > On Dec 14, 2021, at 12:48 AM, John Huss  wrote:
> > >
> > > I believe that compose UI library is used to build the new upcoming IDE
> > > from JetBrains called Fleet. So I expect it will continue to be
> supported
> > > unless that product completely flops.
> > >
> > > I don't mind the current modeler UI. It's good enough for me.
> > >
> > > https://www.jetbrains.com/fleet/
> > >
> > >
> > > On Sat, Dec 11, 2021 at 2:15 AM Andrus Adamchik 
> > wrote:
> > >
> > >> A datapoint to our perennial discussion of technology to use for the
> > >> future CayenneModeler... With Swing being old and crusty, and JavaFX
> no
> > >> longer supported by Oracle, perhaps we should be looking for something
> > >> fresh. I just came across a new "Compose Multiplatform" desktop UI
> > >> framework by JetBrains [1]. It is programmed in Kotlin and is based on
> > >> Google toolkit for Android. Their GitHub examples [2] are not that
> > visually
> > >> impressive, but I would imagine it is a matter of styling. A million $
> > >> question is whether it will be around and open source in 10-15 years.
> > >>
> > >> Anyone knows anything about it?
> > >>
> > >> Andrus
> > >>
> > >> [1] https://www.jetbrains.com/lp/compose-mpp/
> > >> [2]
> > >>
> >
> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
> > >>
> > >>
> > >>
> >
> >
>

Re: UI toolkit for the future Modeler

[John Huss]

My 2 cents is that Java desktop UI is effectively dead. So switching to
another UI library that is either already dead or is dying isn't a great
use of time. So I would try to change it as little as possible.

For the tables with editable cells problem, my recommendation would be to
move editing into a separate "inspector" area that is laid out as a
vertical form. Then the table can be read-only.

For layout, I liked MigLayout when I did Swing apps back in the day. But
that doesn't solve the problem with the existing usage of JGoodies.


On Tue, Dec 14, 2021 at 12:37 AM Andrus Adamchik 
wrote:

> I see a couple of problems with the current UI (beside it being
> subjectively old) :
>
> * We are effectively blocked from any significant evolution of the
> Modeler. Any time we want to do anything fancy (e.g. improve usability of
> tables with editable cells, etc.), we quickly run into the wall with Swing
> capabilities.
> * JGoodies library that we depend heavily upon for layouts is no longer
> free/open source [1], creating risks for JVM upgrades.
>
> So modernization of the Modeler is a practical matter.
>
> Looks like Fleet is not using Compose [2], but a lesser known JetBrains
> Toolbox does [3]. And everyone admits it is still raw.
>
> Andrus
>
> [1] https://www.jgoodies.com/downloads/libraries/
> [2] https://twitter.com/jetbrains/status/1465245360973131777 <
> https://twitter.com/jetbrains/status/1465245360973131777>
> [3]
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> <
> https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
> >
>
>
>
> > On Dec 14, 2021, at 12:48 AM, John Huss  wrote:
> >
> > I believe that compose UI library is used to build the new upcoming IDE
> > from JetBrains called Fleet. So I expect it will continue to be supported
> > unless that product completely flops.
> >
> > I don't mind the current modeler UI. It's good enough for me.
> >
> > https://www.jetbrains.com/fleet/
> >
> >
> > On Sat, Dec 11, 2021 at 2:15 AM Andrus Adamchik 
> wrote:
> >
> >> A datapoint to our perennial discussion of technology to use for the
> >> future CayenneModeler... With Swing being old and crusty, and JavaFX no
> >> longer supported by Oracle, perhaps we should be looking for something
> >> fresh. I just came across a new "Compose Multiplatform" desktop UI
> >> framework by JetBrains [1]. It is programmed in Kotlin and is based on
> >> Google toolkit for Android. Their GitHub examples [2] are not that
> visually
> >> impressive, but I would imagine it is a matter of styling. A million $
> >> question is whether it will be around and open source in 10-15 years.
> >>
> >> Anyone knows anything about it?
> >>
> >> Andrus
> >>
> >> [1] https://www.jetbrains.com/lp/compose-mpp/
> >> [2]
> >>
> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
> >>
> >>
> >>
>
>

Re: UI toolkit for the future Modeler

[Andrus Adamchik]

I see a couple of problems with the current UI (beside it being subjectively 
old) : 

* We are effectively blocked from any significant evolution of the Modeler. Any 
time we want to do anything fancy (e.g. improve usability of tables with 
editable cells, etc.), we quickly run into the wall with Swing capabilities.
* JGoodies library that we depend heavily upon for layouts is no longer 
free/open source [1], creating risks for JVM upgrades. 

So modernization of the Modeler is a practical matter.

Looks like Fleet is not using Compose [2], but a lesser known JetBrains Toolbox 
does [3]. And everyone admits it is still raw.

Andrus

[1] https://www.jgoodies.com/downloads/libraries/
[2] https://twitter.com/jetbrains/status/1465245360973131777 

[3] 
https://blog.jetbrains.com/kotlin/2021/08/compose-multiplatform-goes-alpha/#toolbox
 




> On Dec 14, 2021, at 12:48 AM, John Huss  wrote:
> 
> I believe that compose UI library is used to build the new upcoming IDE
> from JetBrains called Fleet. So I expect it will continue to be supported
> unless that product completely flops.
> 
> I don't mind the current modeler UI. It's good enough for me.
> 
> https://www.jetbrains.com/fleet/
> 
> 
> On Sat, Dec 11, 2021 at 2:15 AM Andrus Adamchik  wrote:
> 
>> A datapoint to our perennial discussion of technology to use for the
>> future CayenneModeler... With Swing being old and crusty, and JavaFX no
>> longer supported by Oracle, perhaps we should be looking for something
>> fresh. I just came across a new "Compose Multiplatform" desktop UI
>> framework by JetBrains [1]. It is programmed in Kotlin and is based on
>> Google toolkit for Android. Their GitHub examples [2] are not that visually
>> impressive, but I would imagine it is a matter of styling. A million $
>> question is whether it will be around and open source in 10-15 years.
>> 
>> Anyone knows anything about it?
>> 
>> Andrus
>> 
>> [1] https://www.jetbrains.com/lp/compose-mpp/
>> [2]
>> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
>> 
>> 
>> 

Re: UI toolkit for the future Modeler

[John Huss]

I believe that compose UI library is used to build the new upcoming IDE
from JetBrains called Fleet. So I expect it will continue to be supported
unless that product completely flops.

I don't mind the current modeler UI. It's good enough for me.

https://www.jetbrains.com/fleet/


On Sat, Dec 11, 2021 at 2:15 AM Andrus Adamchik  wrote:

> A datapoint to our perennial discussion of technology to use for the
> future CayenneModeler... With Swing being old and crusty, and JavaFX no
> longer supported by Oracle, perhaps we should be looking for something
> fresh. I just came across a new "Compose Multiplatform" desktop UI
> framework by JetBrains [1]. It is programmed in Kotlin and is based on
> Google toolkit for Android. Their GitHub examples [2] are not that visually
> impressive, but I would imagine it is a matter of styling. A million $
> question is whether it will be around and open source in 10-15 years.
>
> Anyone knows anything about it?
>
> Andrus
>
> [1] https://www.jetbrains.com/lp/compose-mpp/
> [2]
> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
>
>
>

Re: UI toolkit for the future Modeler

[Michael Gentry]

I've not heard of it before. It seems that Google is kind of the upstream
provider, but Google is known to drop things all the time, too. If that
happened, I wonder what JetBrains would do? Another concern I'd have is
learning/mastering another language (Kotlin). It might be the right path,
ultimately, but still a concern. Would we be "encouraged" to use IntelliJ
(for Kotlin support)? Haven't looked into Eclipse or even VSC support for
Kotlin.

Looks like it already has native packaging, menu management, etc support:

https://github.com/JetBrains/compose-jb/blob/master/FEATURES.md#features-currently-available-in-compose-for-desktop


Hopefully this wouldn't remain "Experimental" for long:

https://github.com/JetBrains/compose-jb/raw/master/tutorials/Getting_Started/screen3.png


As for JavaFX and Oracle, I'm still confused if they are involved. The
latest release (JavaFX 17, September 2021) still has Oracle on some of the
docs:

https://openjfx.io/javadoc/17/javafx.fxml/javafx/fxml/doc-files/introduction_to_fxml.html

https://openjfx.io/javadoc/17/javafx.graphics/javafx/scene/doc-files/cssref.html


I also really liked using Scene Builder to create the FXML visually and not
have the UI "code" in the Java code. Compose seems more traditional and
with the UI in the source code. Perhaps I'm just more of a visual person in
that regard, which is another reason why I like using CM to model a DB
instead of annotations or whatnot in code.


On Sat, Dec 11, 2021 at 3:15 AM Andrus Adamchik  wrote:

> A datapoint to our perennial discussion of technology to use for the
> future CayenneModeler... With Swing being old and crusty, and JavaFX no
> longer supported by Oracle, perhaps we should be looking for something
> fresh. I just came across a new "Compose Multiplatform" desktop UI
> framework by JetBrains [1]. It is programmed in Kotlin and is based on
> Google toolkit for Android. Their GitHub examples [2] are not that visually
> impressive, but I would imagine it is a matter of styling. A million $
> question is whether it will be around and open source in 10-15 years.
>
> Anyone knows anything about it?
>
> Andrus
>
> [1] https://www.jetbrains.com/lp/compose-mpp/
> [2]
> https://github.com/JetBrains/compose-jb/blob/master/artwork/readme/apps.png
>
>
>