I haven't had a chance to dive into the code yet, but I'd imagine that
there may be some sort of boundary in place (or can be put in place)
between the UI and the logic such that multiple UIs can reuse the same
code. That sort of pattern is not specific to web development. :)
One of the reasons I decided on Angular rather than React for web development is that it's good
at components. We can now create custom components for the browser, like
<web-table></web-table>. So for instance there could be a <log4j-table>
component, etc. The testing framework that comes with it is also very good. Most of the time
there's no need for a web server. Most services can be mocked on tested in the browser.
Typescript and Kotlin are near duplicates and Angular uses Typescript for
component and UI development. Obviously it's up to you, but I think you'll get
a lot more mileage and reward out of your effort if you upgrade the platform.
On 12 November 2017 at 08:50, Mikael Ståldal <mi...@apache.org> wrote:
Having said that, I don't mean that Ole Ersoy's idea is inherently bad.
But it should be a new independent project (possibly in Apache Logging
Services).
On 2017-11-12 14:27, Mikael Ståldal wrote:
To me, that sound like transforming it into something completely
different, and a use case which there already exists quite some other tools
for already.
Shouldn't we keep Chainsaw as a stand-alone desktop UI app?
On 2017-11-12 05:22, Ole Ersoy wrote:
I had a brief peek. My first impression was that the whole thing needs
a facelift. I'm currently I'm reviewing the ELK stack with the Kibana user
interface as well as fluentd and Zipkin. Something that unifies these
things would be very attractive. If the UI is modern then even more so.
If we can deploy it as a progressive web app attachable to a GraphQL
provider that gets feeds from Fluentd and the ELK stack that would
definitely get Chainsaw back in the game. I think you would have an easy
time attracting a talent pool for something like that. For example
http://akveo.github.io/blur-admin/ is currently available on Github and
has 8000 stars. Could be the starting point for the next generation
logging UI.
Cheers,
Ole
On 11/11/2017 06:09 PM, Scott Deboy wrote:
I'd love to hear what folks think of the user experience with the
'latest Chainsaw' and its feature set.
There are a ton of features. It will be interesting to get a sense of
how many of those features we get 'for free' in any of these other UI
toolkits. It was a lot of heavy lifting to get Swing to do what we
wanted.
Scott
On 11/11/17, Ole Ersoy <ole.er...@gmail.com> wrote:
Kotlin is almost a duplicate of Typescript, so Javascript devs should
be
able to pickup on it fast. There's a Typescript to Kotlin converter
here:
https://github.com/Kotlin/ts2kt
Typescript is also supported in Electron:
https://electron.atom.io/blog/2017/06/01/typescript
So Kotlin should be a pretty good bridge between these worlds and
opens up a
lot of possibilities ... Suggested Kotlin to the Hipparchus group as
well:
https://github.com/Hipparchus-Math/hipparchus/issues/26
A chainsaw implementation in Electron would provide a better developer
and
user experience I would think though ... as you can now use the latest
Javascript frameworks (Angular / React) and all the packages that come
with
that ecosystem (Graphing, Widgets, etc.)
https://scotch.io/tutorials/creating-desktop-applications-wi
th-angularjs-and-github-electron
On 11/11/2017 04:42 PM, Matt Sicker wrote:
I've been using Java for years, Scala for several months (all of OOP,
hybrid, and pure FP styles in different projects), and other
languages in
the past. I've certainly found Scala to be useful in the Big Data
space,
especially when using Spark, though I've also found it useful in
projects
that consume Java APIs.
As for Kotlin fitting well to a GUI app, based on its traction in the
Android GUI space, I had the same thought. Plus, this may attract more
contributors outside ASF who are interested in using Kotlin or
working on
a
GUI app instead of low level Java bits.
Also, I'd imagine Kotlin is easier for a C# or JavaScript developer to
pick
up on than Scala, so that also helps with adoption in theory.
On 11 November 2017 at 10:23, Mikael Ståldal <mi...@apache.org>
wrote:
I have used both Java and Scala for several years, and I have been
trying
out Kotlin the latest months (for Android only).
I would say it is definitely easier for a developer with primarily
Java
experience to pick up Kotlin than Scala, especially if that Java
experience
is predominately pre-Java8. If your primary experience is functional
programming like Haskell, O'Caml or F#; then Scala is probably
easier to
pick up.
Kotlin is gaining traction in Android, since it works well there.
Scala
is
big in Big Data (Apache Spark etc) and to some extent in
server/backend.
Kotlin might be a better fit for a desktop UI Java app like Chainsaw.
On 2017-11-11 02:10, Gary Gregory wrote:
I think Kotlin would be more approachable than Scala... thoughts?
Gary
On Fri, Nov 10, 2017 at 3:26 PM, Matt Sicker <boa...@gmail.com>
wrote:
On 10 November 2017 at 16:17, Robert Middleton <osfan6...@gmail.com
wrote:
What would the advantage be of using Scala vs just normal Java?
Mostly from a curiosity standpoint; I've never done Scala so I
don't
know it works.
The main advantage I can see is that most of the developers
interested
in
working on v3 all prefer to work in Scala. I could go on and on
about
Scala
over Java, but really, my comparison would all come down to
functional
programming over object oriented programming. When it comes to
shared
libraries like Log4j, I find Java far more appropriate and work in
that
space. In a GUI application where there is no real public API? I'd
rather
work in Scala. Kotlin was another option, but it seems like none
of us
really have experience there.
Did you actually have trouble building? I'm pretty sure that when
I
built it a few months ago I simply opened up the project in
Netbeans
and it built immediately as a maven project(although looking at
the
POM it does look like it uses ant on the backend for some reason).
Building the project is simple enough. I had issues with:
1. Running mvn clean install does not work by default unless you
run
"mvn
site:site" before running "mvn install".
2. Doesn't build in Java 9.
3. The maven-release-plugin is not configured at all, so I had to
do
all
release steps by hand instead.
--
Matt Sicker <boa...@gmail.com>
.
