Re: [RDD] OSX - OT Java?
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-boun...@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 fr...@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
Re: [RDD] OSX
I spent some time a year ago trying to make Rivendell play on OS X but aside from some driver issues it seemed like QT mis-matches were the major malfunction. Fred G says a QT up-rev is on the list of things to do. Bill Putney - KPTZ Port Townsend, WA Sent from my iPad On Aug 30, 2012, at 10:33 AM, WBHM Web Operations la...@wbhm.org wrote: I'm trying to compile a checkout from: cvs -d:pserver:c...@cvs.rivendellaudio.org:/home/cvs/cvsroot checkout rivendell On OSX lion, loosely following these instrctions: http://rivendell.tryphon.org/wiki/Install_Rivendell_on_OSX I say loosely, because these are obviously outdated. First thing I noticed was that configure told me Qt4 not found, unable to continue, so using MacPorts, I removed qt3 and installed qt4-mac-devel. Still no love. I'm looking for the qt4 libs and headers to no avail. Does anyone have some Rivendell OSX knowledge to share. Thanks, Larry ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] OSX
On Aug 30, 2012, at 13:33 25, WBHM Web Operations wrote:
I'm trying to compile a checkout from:
cvs -d:pserver:c...@cvs.rivendellaudio.org:/home/cvs/cvsroot checkout
rivendell
On OSX lion, loosely following these instrctions:
I've not tried it (yet) on Lion, but it *does* build and (basically) work on
Snow Leopard. This is CVS-Head mind you, so it's 3.x ALPHA, using Qt4. *Very*
alpha, as far as OS-X goes. :)
As for the library dependencies, you may need to tweak $LIBS and $INCLUDES to
tell the build system where to find things. I installed Qt4 (v4.7.3) from
source as per the stock TrollTech instructions, and the build system finds that
fine by default. I use the following invocation for configure:
./configure --prefix=/usr --libexecdir=/Library/WebServer/rd-bin
Note the '--libexecdir' argument, which is needed to tell the build system
where to put the web components so OS X's built-in Apache server can find them.
You'll also need to copy the web configuration ('rd-bin.conf') into
'/etc/apache2/extra/httpd-rivendell.conf'.
This is all bleeding-edge stuff and still subject to major change going
forward. However, feel free to hack on it and let us know what you find.
Patches welcomed...
Cheers!
|-|
| Frederick F. Gleason, Jr. | Chief Developer |
| | Paravel Systems |
|-|
| This software comes with ABSOLUTELY NO WARRANTY. Even if it erases |
| your hard drive, too bad. Although we did fix that bug from the |
| last release. |
|-- README from the DJGPP package |
|-|
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] OSX
On Thu, 2012-08-30 at 16:29 -0500, Gregg Wonderly wrote: Practically, we could have a much more friendly admin environment, I believe, if we could shed the simplicity of QT in favor of more elaborate UI components. It is the simplicity of QT which makes it desirable/practical/effective. No program is going to be compatible with every conceivable platform. As a follower of the evolution of Rivendell it's success has been the ability to deliver on affordable, readily available, hardware, as well as industry standard sound cards. Installations that require few, if any, upgrades, with reliability determined by hardware rather then code. This ineviteably restricts some options, but it gets the job done. Robert Jeffares ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] OSX
On Aug 30, 2012, at 16:13 18, WBHM Web Operations wrote: ls -l /opt/local/lib | grep QtCore -rwxr-xr-x1 root admin 3433260 Apr 28 10:26 libQtCore.4.8.0.dylib lrwxr-xr-x1 root admin21 Apr 28 10:26 libQtCore.4.8.dylib - libQtCore.4.8.0.dylib lrwxr-xr-x1 root admin21 Apr 28 10:26 libQtCore.4.dylib - libQtCore.4.8.0.dylib lrwxr-xr-x1 root admin21 Apr 28 10:26 libQtCore.dylib - libQtCore.4.8.0.dylib -rw-r--r--1 root admin 657 Apr 28 10:26 libQtCore.la -rw-r--r--1 root admin 984 Apr 28 10:28 libQtCore.prl I'm using the configure as follows: ./configure CPPFLAGS=-I/opt/local/lib/ The -I flag is for providing a path to header files. You want -L for giving a path to the libraries themselves. Try something like: ./configure CPPFLAGS=-L/opt/local/lib -Ipath-to-include-headers You'll need to be doing something similar for each dependency as well. See 'INSTALL' in the sources for a list. I've found that building each dependency from source and then doing 'sudo make install' puts it in a place where it gets found by default without having to futz around with the environment. Good enough for alpha development, but will likely need some major rework when the time comes to build proper app bundles -- DLL library management on OS X is *very* different from Linux! One thing at a time though -- let's learn to walk before we try a hundred meter dash... :) Cheers! |-| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-| | At the beginning of the week, we sealed ten BSD programmers into a | | computer room with a single distribution of BSD Unix. Upon opening | | the room after seven days, we found all ten programmers dead, | | clutching each others' throats, and thirteen new flavors of BSD. | | -- Anonymous | |-| ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
Re: [RDD] OSX
On Aug 30, 2012, at 6:05 PM, Fred Gleason fr...@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@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev ___ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
