Login:    

useradd
more /root/Bugs/Shift-Delete and a couple other bugs.thread
2008-10-13 08:01:25IsmAvatar
Whomever is making the next commit should probably fix these guys.

1) Shift-Delete is the shortcut to Cut (thanks to the Look and Feel), which screws with ResNode's transferable status, especially its DataFlavor, causing it to try to convert a ResNode into an InputStream and throw a ClassCastException. The only way we found this out is due to the coincidence that we use Shift-Delete to delete a ResNode. This bug is completely independant of our key mapping, but it'd probably be good to not only stop the InputStream conversion, but also to prevent Java from stealing our key mappings.

2) Fix SoundFrame's CustomFileChooser's default selected filter. This is how it should read:
Code
		CustomFileFilter soundsFilter = new CustomFileFilter(s,d[0]);
		fc.addChoosableFileFilter(soundsFilter);
		fc.addChoosableFileFilter(new CustomFileFilter(s[0],d[1]));
		fc.addChoosableFileFilter(new CustomFileFilter(s[1],d[2]));
		fc.addChoosableFileFilter(new CustomFileFilter(s[2],d[3]));
		fc.setFileFilter(soundsFilter);


3) Deleting a ResNode does not seem to delete the underlying resource. This is probably a result of the new reference system in r205 and r206.
2008-10-13 18:41:11IsmAvatar
3) Actually this seems to have something to do with r206 when Quadduc removed line 379 from Listener for some reason. This can be fixed by re-inserting the following line after line 379:

Code
LGM.currentFile.getList(node.kind).remove(res);


Quadduc, any tips as to why you removed that line?
2008-10-13 21:18:46IsmAvatar
1) Appeared in 1.5.0, although may have originated in r4, when I first committed ResNode.
2008-10-14 09:13:12Clam
I believe that Quadduc's intention was that the ResNode listens on the Resource and removes itself from the tree when the Resource is deleted. Of course, I don't think it works the other way round, so deleting the ResNode apparently doesn't remove the underlying Resource.
2008-10-19 03:33:50IsmAvatar
One more. Java assumes 72 dpi for fonts. This may cause the FontFrame preview panel to render at the wrong font size.

FontFrame.updatePreview() at around line 290 should read as follows:

Code
	public void updatePreview()
		{
		int screenRes = Toolkit.getDefaultToolkit().getScreenResolution();
		int fontSize = (int) Math.round(size.getIntValue() * screenRes / 72.0);
		preview.setFont(new java.awt.Font(fonts.getSelectedItem().toString(),makeStyle(
				bold.isSelected(),italic.isSelected()),fontSize));
		}
2008-10-20 02:11:54Clam
Heh, when I was telling you that Java treats the font sizes differently, that's how I knew. I guess I never actually got round to investigating it.
2008-10-20 04:14:58IsmAvatar
And right after you said that, I went and investigated it.
2008-11-04 22:08:43IsmAvatar
All but 1 have been solved with r311
2008-12-08 12:05:53IsmAvatar
1 is resolved with r325.