[RDD] OSX -> OT Java?

Wayne Merricks WayneMerricks at TheVoiceAsia.Com
Sat Sep 1 17:30:37 EDT 2012


Hi,

I agree with everything you said.  Removing the GUI from the guts of the program would mean using any language for a GUI (either via JNI to the back end or seeing as most of Riv is the caed, rdcatchd and ripcd daemons, theoretically you could just send the same commands to those and have a purely Java GUI).

For my purposes this would suit me because I can write Java so much faster than C++/QT because I've spent years getting used to it.  For a Riv GUI (and some back end), Java has lots of advantages and few disadvantages if done right.  The only major disadvantage being the time needed to do the conversion.

Layout managers is the way I've always done things.  I took one look at grid bag layout and got bored to tears the same as you seem to have.  The difference being I settled on a combination of BorderLayouts and GridLayouts to achieve the same effect.

In your label/field example I normally do two grids 1 column wide (for labels and fields) then shove them both in a BorderLayout (labels west, fields center).  I then nest more BorderLayouts in the center panels if I need more columns.

In my example of fonts wrapping, it wasn't really a move to a different OS and Java won't work deal it was more of a move OS and it will look different to what you might have intended.  It can be as simple as Windows GUIs having a nice pad around the internals of a Window where as Linux shoves it right to the edge which just doesn't look as pleasing to me.  Then theres the ne'er do wells that mess with the L&F settings and all sorts of GUI weirdness can happen.

To be honest the only show stopper bug I ever found going cross platform was when using some of the awt.Robot class functionality.  I can't remember the reasoning for it now as its been over 10 years but I had to accommodate an offset for the Window Title Bar.  At the time I was using XP so I worked out it was roughly 20px.  I then happened to go to my bi-annual lets install linux from some random magazine CD pilgrimage (most likely an ancient red hat back then) and I realised the title bar wasn't 20px which threw my carefully worked out Robot.moveMouse(x, y) off by a few pixels.

Forgetting all the rambling, if I could flick a switch and Riv would be written in Java for the GUI side I would instantly do it mostly because it lowers the barrier of entry to developers and it means I can be lazy and not learn different things.  However, its not a small amount of work to convert this.  If its something you want to go for, let me know the details and I'll certainly contribute whatever time I have but I get the feeling it would be just us two using it.

At the moment I have three small ideas I'd like to put into Riv that would take me less than a day in Java and at least a week or so just to learn the relevant QT + no idea how long hitting compile before the errors go away.



Regards,

Wayne

-----Original Message-----
From: rivendell-dev-bounces at lists.rivendellaudio.org on behalf of Gregg Wonderly
Sent: Sat 01/09/2012 17:02
To: User discussion about the Rivendell Radio Automation System
Subject: Re: [RDD] OSX -> OT Java?
 
Hi Wayne, thanks for sharing your experiences.  I have some replies in line.  I wrote quite a bit here, to kind of frame my experiences and where I come from.  I'm not trying to say "mine is better than yours" or anything to create an argument, I hope.

On Aug 30, 2012, at 9:31 PM, Wayne Merricks <waynemerricks at thevoiceasia.com> wrote:

> OT for OSX as its almost turned into a bit of a Java discussion.  Java has its problems, the main one being write once test everywhere although it generally works OK as long as you don't go over board with complicated libraries you plug into.  You normally just get stupid problems like fonts wrapping because they are different sizes on different systems and the like.

This is the primary reason why Java has layout managers and why you should use them.  The layout manager mechanism asks the component for its preferred size, and organizes the horizontal and vertical layout to make things fit.

> I'm not the worlds best Java expert by any stretch but over the last 5 years of professionally using it, I've programmed a call handling system built on top of asterisk that handled about 2,000 calls a day (at its peak) without skipping a beat.  I even have the complication of having to share data between the UK and India but even that didn't break anything once I had a MySQL slave over there.

My data broker moves along at 100's of thousands of records per hour, sticking all of that into databases using Oracle JDBC, MS SQL server JDBC and postgresql JDBC interfaces.  So, I am not worried about those tasks being possible/stable.

> All I'm trying to say is like any language if you're a crap programmer you'll make crap programs regardless of the language (I hope none of you have had the misfortune of using the Cisco firewall management stuff, 1GB of RAM minimum reqs for a firewall GUI in Java is ridiculous).  In general the big corp Java apps I've used seem to be overly complicated junk, thankfully I don't have to use them anymore as I'm in a tiny IT shop these days.

Most large scale Java development happens with all kinds of "productivity tools" which creates non-maintainable software systems, quickly.  I've stayed away from that mode of operation to have maintainable software.

> I'd be all for converting to Java as I can write it while I sleep instead of having to think about all this C stuff but I think I'm leaning towards the fact that its a lot of work with not a great pay off.  I don't know a lot about QT but I know that QT5 is going web orientated and QT is quite cross platform once you set it up so it seems like the Java cross platform advantages will disappear.

The issue for me, is that GUI layout and productivity using an application that requires a GUI should be something that you don't worry about.  The issues I have with my casual exposure to the QT code in Rivendell, is that I don't really know QT, and I stopped programming in C (I worked for AT&T on the 5ESS project in the 90's and did thousands of lines of it back then) since about 1998.   I just have tried hard to not be burdened by memory management and C portability with "configure".  Finding enough Java work to not have to do that, has been easy.  But, I've been doing Objective-C stuff lately, and so I'm back in the position of dealing with less features in the language.

> Finally I need to quickly defend Eclipse (Netbeans is OK but I found the auto generated GUI code it produces to be a complete mess and it put me off using the whole thing), I haven't found any IDE that comes close to it once you get used to it, with the tool tip API lookups, auto completion and an awesome debugger its pretty much Visual Studio but free (albeit without a gui builder, which suits me).  

Auto generated GUI code is not my thing either.  I've always hand coded my GUIs and I've found that easy to do using my Packer class that I describe below.  

> Its a rude awakening going from that to gedit for C++/QT stuff where the only way I know of debugging is to throw in lots of console writes and keep compiling until the errors go away (I have the same problems with PHP so its not just a C/QT thing).

I really don't want to start going on and on about Java vs QT, because I don't have the background to really compare them.  

In 1997, I was coming out of a TCL/TK project at AT&T where I had been using the "pack" command to build GUIs and as I was picking up my speed on Java GUIs, I really wanted to have a rectangular layout manager that was easy to use, like the TCL/TK packer was.

The GridbagLayoutManager, in Java, has the same features as "pack", but it's API was designed like a Windows 3.x API with about 10 lines of assignments needed per component, and that's what I see in the QT code for GUIs as well.  My experience with that was that there were always issues with trying to reuse code because so much stuff was "invisible" for all the lines of code.

So, I wrapped the GridbagLayoutManager with a new API by subclassing it.  The resulting class and interface is at http://java.net/projects/packer.  Basically, for a simple 

	"Label: "   [text field]
	"Label: "   [text field]
	"Label: "   [text field]
	"Label: "   [text field]

kind of rectangular form, you'd code it using my Packer class with something like

int y = -1;  // how this value is used and changed is key to easy layout

JPanel p = new JPanel();
Packer pk = new Packer( p );

// move to next line and put two fields on it
for( int i = 1; i <= 4; ++i ) {
	pk.pack( new JLabel( "Field "+i+":" ) ).gridx( 0 ).gridy( ++y ).inset( 0, 4, 0, 4 ).
	pk.pack( new JTextField( 10 ) ).gridx( 1 ).gridy( y ).fillx().inset( 0, 0, 0, 4 );
}

The Packer class instance wraps all of the context inside of itself, so that there isn't a "sharing" of state across blocks of code like there is, when a "structure" is reused over and over with variations on its content.

The deal for me, is that layout is then compartmentalized in a way that you can move fields around, wrap groups of things into panels and move panels around etc.  This could be done with a C++ class as well, for QT I suppose.

With Java LayoutManagers, then you also get nice cross platform layout support so that any font size works depending on your screen size.   That means you can use large fonts on large screens with excellent readability.

Gregg

> Regards,
> 
> Wayne
> 
> 
> -----Original Message-----
> From: rivendell-dev-bounces at lists.rivendellaudio.org on behalf of Gregg Wonderly
> Sent: Fri 31/08/2012 01:53
> To: User discussion about the Rivendell Radio Automation System
> Subject: Re: [RDD] OSX
> 
> 
> On Aug 30, 2012, at 6:05 PM, Fred Gleason <fredg at paravelsystems.com> wrote:
> 
>> On Aug 30, 2012, at 18:11 08, Dan Mills wrote:
>> 
>>> I don't know if it is just me (And I have not worked on Riv for a
>>> while), but EVERY major java application (Possibly except Chrome, I have
>>> not used it much) I have ever run across has been a right pain to
>>> install, xml infested, massive, slow to start up, and generally slightly
>>> crash happy, maybe it just comes with the "Enterprise" label or
>>> something.....
>> 
>> This has been my experience as well, with the addition of extreme sensitivity to the precise version of JRE being used, to the point where I've even had to *downgrade* it to get a working setup.  Not a particularly impressive showing for a system that purports to deliver 'write once, run anywhere' functionality.  This was several years ago however, so perhaps things have improved since then.
> 
> Many people seem to have experience with JavaEE servers as their "Java" experience.  There, too many large scale, mismanaged resources and "code-by-tools" creates a lot of problems.
> 
> I've been using JavaSE for a data brokering system that I wrote from scratch, deployed in the petroleum products market, for the past decade.  My experience has been that I haven't had to worry about Java versions, except for some point releases with actual bugs.
> 
> I understand the GC at the wrong moment won't be good.  That's why I'd prefer to leave the play out system in a native C/C++ application framework.  It could still load the JVM in that process, and call out to it, if that was a useful part of the system.  GC in that JVM would happen on threads independent of the play out mechanisms.
> 
>> 
>>> I mean eclipse, really, come back emacs (or vim) all is forgiven, and a
>>> glorified text editor really should not crash! 
>> 
>> I'm there, baby!  Using emacs v23.1 (and yes, it's available for OS X as well).  :)
> 
> I'm a VI user and I am not always excited about IDEs.  The Netbeans IDE, is much preferable to Eclipse for me, because it seems to be more like an editor with a navigation tree, instead of some kinds of systems engineering nightmare.
> 
>>> Now as it happens the log playback logic is somewhat too tightly tied to
>>> the gui in rivendell, and could very usefully be abstracted into a
>>> logplayd process (Or three), but remember that even this is fairly hard
>>> realtime if you want the transitions to sound smooth. GC at the wrong
>>> time there would be a dead air situation, possibly making the next
>>> transition also miss its timing.
>> 
>> This is the real crux of the matter, I think.  Multimedia systems that demand realtime performance remain the almost exclusive province of C/C++.  Unpredictable GC in languages with automatic memory management is one of the major reasons for that.
> 
> As I said above.  I'd prefer to leave the play out system outside of the realm of a Java implementation.  That would not be a great thing without some careful engineering.
> 
> Don't get excited or too argumentative, because I'm just thinking out loud here. 
> 
> Gregg
> 
>> Cheers!
>> 
>> 
>> |-------------------------------------------------------------------------|
>> | Frederick F. Gleason, Jr. |               Chief Developer               |
>> |                           |               Paravel Systems               |
>> |-------------------------------------------------------------------------|
>> |  The UNIX philosophy basically involves giving you enough rope to hang  |
>> |  yourself.  And then a couple of feet more, just to be sure.            |
>> |                                           -- Anonymous                  |
>> |-------------------------------------------------------------------------|
>> 
>> _______________________________________________
>> Rivendell-dev mailing list
>> Rivendell-dev at lists.rivendellaudio.org
>> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
> 
> _______________________________________________
> Rivendell-dev mailing list
> Rivendell-dev at lists.rivendellaudio.org
> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
> 
> label or
> 
> #######################
> Scanned by MailMarshal
> #######################
> 
> ############
> 
> Attention: 
> 
> The information contained in this message is confidential and intended 
> for the addressee(s) only. If you have received this message in error 
> or there are any problems, please notify the originator immediately.
> The unauthorised use, disclosure, copying or alteration of this message
> is strictly forbidden. Christian Vision or any of its subsidiaries will
> not be liable for direct, special, indirect or consequential damages 
> arising from alteration of the contents of this message by a third party
> or as a result of any virus being passed on. Please note that we reserve
> the right to monitor and read any e-mails sent or received by the 
> company under the Telecommunications (Lawful Business Practice) 
> (Interception of Communications) Regulation 2000. Christian Vision is 
> registered in England as a limited company 2842414 and as a charity 
> 1031031  
> 
> ############
> <winmail.dat>_______________________________________________
> Rivendell-dev mailing list
> Rivendell-dev at lists.rivendellaudio.org
> http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev

_______________________________________________
Rivendell-dev mailing list
Rivendell-dev at lists.rivendellaudio.org
http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev


#######################
Scanned by MailMarshal
#######################

############

Attention: 

The information contained in this message is confidential and intended 
for the addressee(s) only. If you have received this message in error 
or there are any problems, please notify the originator immediately.
The unauthorised use, disclosure, copying or alteration of this message
is strictly forbidden. Christian Vision or any of its subsidiaries will
not be liable for direct, special, indirect or consequential damages 
arising from alteration of the contents of this message by a third party
or as a result of any virus being passed on. Please note that we reserve
the right to monitor and read any e-mails sent or received by the 
company under the Telecommunications (Lawful Business Practice) 
(Interception of Communications) Regulation 2000. Christian Vision is 
registered in England as a limited company 2842414 and as a charity 
1031031  

############
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 12624 bytes
Desc: not available
Url : http://lists.rivendellaudio.org/pipermail/rivendell-dev/attachments/20120901/bd94bef9/attachment-0001.bin 


More information about the Rivendell-dev mailing list