This question is answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 18 - Pages: 2 [ 1 2 | Next ] - Last Post: 7 Feb 18, 23:05 Last Post By: JeffTucker Threads: [ Previous | Next ]
JeffTucker

Posts: 8,039
Registered: 31-Jan-2006
JPlaylist() monitoring
Posted: 5 Feb 18, 16:43
 
  Click to reply to this thread Reply
Am I correct in assuming that one cannot use a StateMonitor() to listen for changes to a JPlaylist() component? I'm so accustomed to using StateMonitor()'s for everything, I scarcely remember how to use anything else. If I want to monitor a JPlaylist() for changes, is it an ActionListener() that I should be using?
davidekholm

Posts: 3,442
Registered: 18-Oct-2002
Re: JPlaylist() monitoring
Posted: 5 Feb 18, 17:45   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
True, but that should be supported. Get the new beta core file. Now you can add yourPlayListList.getModel() to the StateMonitor. It's untested, but should work ;-)
JeffTucker

Posts: 8,039
Registered: 31-Jan-2006
Re: JPlaylist() monitoring
Posted: 5 Feb 18, 18:01   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
Attachment ss003750.png (9.9 KB)
Attachment ss003751.png (7.2 KB)
It may not help. I've run into a whole series of bizarre problems when trying to use JPlaylist() in a custom UI.

If the custom UI is in the little panel on the right, the size of the component is different depending upon whether there are any selected tracks (it's wider when empty, perversely). The attached pair of screenshots capture the flavor. ;)

If the custom UI is in a popup frame (which is where Matrix has its image- and folder-specific settings), things get much worse, and very quickly. The "add" button mysteriously stops working, changes aren't saved to the .info file, and so on. A real mess.

Later I'll put together some little test skins that aren't loaded down with a bunch of other stuff. I wouldn't wish the Matrix.java file on anyone!
JeffTucker

Posts: 8,039
Registered: 31-Jan-2006
Re: JPlaylist() monitoring
Posted: 5 Feb 18, 18:41   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:
If the custom UI is in the little panel on the right, the size of the component is different depending upon whether there are any selected tracks (it's wider when empty, perversely). The attached pair of screenshots capture the flavor. ;)

Actually, it does that even when the JPlaylist is shown in the main skin settings panel!

Edit: But only in Windows, and only with some of the look-and-feel choices, including the system default and Nimbus. With Darcula, the JPlaylist displays normally, though it ends up being too large to use in a custom UI side panel.

EditEdit: And it has to do with the width of the controls above the track list. If that's smaller than the default width of the track list, the list is wide. But when you add a track or two, the list narrows to match the width of the controls above it.
JeffTucker

Posts: 8,039
Registered: 31-Jan-2006
Re: JPlaylist() monitoring
Posted: 5 Feb 18, 19:47   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
True, but that should be supported. Get the new beta core file. Now you can add yourPlayListList.getModel() to the StateMonitor. It's untested, but should work ;-)

Maybe I'm not getting the correct core file, but if I try to put a StateMonitor() on a Playlist(), the skin won't even load:
se.datadosen.util.ScriptException: 
bsh.TargetError: Sourced file: inline evaluation of: ``new Xui(engine);  ;'' : Object 
constructor : at Line: 1 : in file: inline evaluation of: ``new Xui(engine);  ;'' : 
new Xui ( engine ) 
 
Target exception: java.lang.IllegalArgumentException: 
se.datadosen.component.JPlaylist not an allowed component
 in onload.bsh at line number 1
	at se.datadosen.util.ScriptException.of(ScriptException.java:59)
	at se.datadosen.jalbum.AlbumBean.processScript(AlbumBean.java:2396)
	at se.datadosen.jalbum.JAlbumFrame.executeScript(JAlbumFrame.java:1203)
	at se.datadosen.jalbum.JMainSettingsPanel$5$1.run(JMainSettingsPanel.java:308)
The core file I have is 3,759,569 bytes.
JeffTucker

Posts: 8,039
Registered: 31-Jan-2006
Re: JPlaylist() monitoring
Posted: 5 Feb 18, 20:06   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Ah, it is working. You have to use a construction that I've never even seen before:
new StateMonitor() {
	public void onChange() {
		System.out.println("Playlist changed");
	}
}.add(myMusic.getModel()).done();
I have no idea why getModel() is required - I've never used it in the StateMonitor() for any other skin variable.
JeffTucker

Posts: 8,039
Registered: 31-Jan-2006
Re: JPlaylist() monitoring
Posted: 5 Feb 18, 22:13   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:
If the custom UI is in a popup frame (which is where Matrix has its image- and folder-specific settings), things get much worse, and very quickly. The "add" button mysteriously stops working, changes aren't saved to the .info file, and so on. A real mess.

It turns out that having a working StateMonitor() for JPlaylist seems to cure these ills.

I discovered long ago that if you do a custom UI in the panel on the right in the Explore view, you don't have to worry about saving changes - the jAlbum core takes care of it just fine.

But if you do a custom UI in a popup JFrame(), you have to take charge of saving user inputs. Some things get saved OK, like JCheckBox or JComboBox, but other things, like JSpinner and JPlaylist, manifestly do not. User inputs vanish from one viewing to the next, even if you "OK" out of the popup custom UI. The safe move is to put a StateMonitor() on absolutely everything, and force a saveUI() if anything has changed. That probably generates some unnecessary disk I/O, but it's not detectable, even when you're scrolling in a JSpinner.

So, from all of this thread, there's only one outstanding issue, and that's the mysterious self-resizing of the JPlaylist component. If you want to see it in action, install the latest version of Saturn on a Windows machine, using the system default look-and-feel, and go to the Maps & Music tab. Make note of the size of the playlist. Now add an MP3, and watch what happens! You might have to move your mouse up to one of the tabs at the top to trigger the change.
davidekholm

Posts: 3,442
Registered: 18-Oct-2002
Re: JPlaylist() monitoring
Posted: 6 Feb 18, 21:44   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
I believe I've addressed the resizing of the JPlaylist component now. Just get the core file again to test. The reason why you need to add .getModel() when passing it to the StateMonitor is that I don't want to introduce dependencies to custom jAlbum components to this rather generic utility class. By passing the ListModel() to StateMonitor, we use standard Java classes only. (A Plain JList also has a getModel() call that reveals its ListModel)
JeffTucker

Posts: 8,039
Registered: 31-Jan-2006
Re: JPlaylist() monitoring
Posted: 6 Feb 18, 21:50   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
Attachment Xpopup.jaskin (8.5 KB)
I'll give it a shot, and post back.

But in the meantime, I have stumbled across a couple other odd bits of behavior with JPlaylist(). The first is the file chooser filtering - I started a separate thread in Bug reports about that one.

The second is more obscure. Attached is a skeletal skin called Xpopup. It's just a minimal user interface, but with a popup for the custom UI. The source files are bundled with the skin.

Start a new project with it, and add a few images. Go into editing mode for an image, hit the Xpopup panel on the right, and click the button to open the custom UI. It consists solely of a JPlaylist(). Add a couple of music tracks, then OK out of it. Now click the button to open the custom UI again, and try to add another track. It's nonresponsive. You can rearrange the tracks that are there, and you can delete a track, but you can't add another one. A quick save, close, and reopen of the project, and you're back in business.

A rare problem, but a puzzling one.
JeffTucker

Posts: 8,039
Registered: 31-Jan-2006
Re: JPlaylist() monitoring
Posted: 6 Feb 18, 21:53   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
I believe I've addressed the resizing of the JPlaylist component now.

Yes, it's no longer bouncing around when it goes from "empty" to "populated," and vice-versa. :)
davidekholm

Posts: 3,442
Registered: 18-Oct-2002
Re: JPlaylist() monitoring
Posted: 6 Feb 18, 22:08   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Great
JeffTucker

Posts: 8,039
Registered: 31-Jan-2006
Re: JPlaylist() monitoring
Posted: 6 Feb 18, 23:08   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
Still have the "popup" mystery (sorry to be loading this thread up with multiple issues, but they're all related, so....).
JeffTucker

Posts: 8,039
Registered: 31-Jan-2006
Re: JPlaylist() monitoring
Posted: 6 Feb 18, 23:19   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
One perhaps revealing observation about the popup problem. The JPlaylist() becomes unresponsive only if you use the "OK" button to leave the custom UI. If you hit the "X" to close the window, it behaves normally. The "OK" button is just doing a frame.dispose(). Should it be doing something else?
JeffTucker

Posts: 8,039
Registered: 31-Jan-2006
Re: JPlaylist() monitoring
Posted: 6 Feb 18, 23:53   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Leave me to thrash around for a while, and I will come up with the answer. Instead of using frame.dispose(), this bit of code seems to mimic the "click the X" action, and the problem goes away:
frame.dispatchEvent(new WindowEvent(frame, WindowEvent.WINDOW_CLOSING));
Why is this different, you ask? Damned if I know, but I generally don't argue with success.
davidekholm

Posts: 3,442
Registered: 18-Oct-2002
Re: JPlaylist() monitoring
Posted: 7 Feb 18, 18:55   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
frame.dispose() releases OS related resources bound to a window. After calling .dispose(), things needs to be rebuilt before the window can be displayed again. Could that play a role?
Legend
Forum admins
Helpful Answer
Correct Answer

Point your RSS reader here for a feed of the latest messages in all forums