Changeset 6256
- Timestamp:
- 2003-12-12T17:56:14+13:00 (20 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/gli/buglist/status.txt
r6218 r6256 693 693 4e3 694 694 Pending 695 Should work. See 203B074 - UNICode compliance<br>Values for metadata are unicode compliant. Difficulty occurs when metadata names are unicode as Greenstone build scripts fail to correctly match such metadata to the requested classifiers. Investigate ways to correctly match unicode metadata names. 695 Should work. See 203B074 - UNICode compliance<br>Values for metadata are unicode compliant. Difficulty occurs when metadata names are unicode as Greenstone build scripts fail to correctly match such metadata to the requested classifiers. Investigate ways to correctly match unicode metadata names.<br>While the import script appears to work fine, the build process (presumably somewhere in mg_passes) is not finding any metadata for unicode character metadata names 696 696 697 697 203B087 … … 1220 1220 Mac 1221 1221 NA 1222 Pending 1223 Find out how Mac handles launching applications. (Note: I have just read on the web that Runtime.exec() doesn't work on the Mac. - kjdon, 14/11/03)<br>Ah, Runtime.exec() sort of works on the Mac. But because the underlying system isn't a shell-type OS, you need to do magic to get things to work. Thats where a miracle Mac application, 'open', comes in. If file associations you can just type in 'open %1' (no speech marks) click add association and Bob's your uncle - open handles figuring out how to open the given file. If you instead want to force a particular application to be used try 'open -a <app_name> %1'. I'll talk with Ian and see if MacGLI(tm) - or should that be iGLI - should just try open by default but allow the user to override via file associations 1222 Fixed 1223 Find out how Mac handles launching applications. (Note: I have just read on the web that Runtime.exec() doesn't work on the Mac. - kjdon, 14/11/03)<br>Ah, Runtime.exec() sort of works on the Mac. But because the underlying system isn't a shell-type OS, you need to do magic to get things to work. Thats where a miracle Mac application, 'open', comes in. If file associations you can just type in 'open %1' (no speech marks) click add association and Bob's your uncle - open handles figuring out how to open the given file. If you instead want to force a particular application to be used try 'open -a <app_name> %1'. I'll talk with Ian and see if MacGLI(tm) - or should that be iGLI - should just try open by default but allow the user to override via file associations<br>Mac now uses open %1 by default, and the browse button (which is problematic at best) is hidden 1224 1224 1225 1225 203B154 … … 1228 1228 Mac 1229 1229 NA 1230 Pending 1231 Perhaps custom file browser that reacts appropriately to application bundles on Mac<br>Now the browse feature crashes with a NPE in apple.laf.AquaFileChooserUI, which unfortunately I can't do much about 1230 Fixed 1231 Perhaps custom file browser that reacts appropriately to application bundles on Mac<br>Now the browse feature crashes with a NPE in apple.laf.AquaFileChooserUI, which unfortunately I can't do much about<br>Fixed, or at least dodged, as explained in 203B153 1232 1232 1233 1233 203B155 … … 1453 1453 NA 1454 1454 Fixed 1455 The Metadata Set Editor is due for a completeoverhaul.<br>Mostly due to the DOM node remove not being implemented properly.1455 The Metadata Set Editor is long overdue for a overhaul.<br>Mostly due to the DOM node remove not being implemented properly. 1456 1456 1457 1457 203B183 … … 1548 1548 Linux (Mandrake) 1549 1549 2.5 1550 Pending 1550 Fixed 1551 1551 It appears from the error message generated that the classpath has been read as one giant string rather then folders separated by the : character. Not knowing Mandrake I can only assume that a different character should be used to have the script parsed correctly. Investigate the shell used, and contact Mike Jensen<br>Well, it turns out to be much simplier than that. Apparently not all java implementations support the -cp shortcut for classpath. Hence java ignores '-cp' then tries to run the 'classes/:GLI/jar:lib/apache/jar:lib/calpa/jar:lib/jp/jar:lib/polloxml/jar:lib/qfslib/jar:lib/skinlf/jar:lib/nanoxml/jar' class - which of course fails (and not just because no classpath is specified and the '.' classpath isn't default under Mandrake). Ensure the full string '-classpath' is used in startup script. 1552 1552 … … 1901 1901 NA 1902 1902 Pending 1903 Find out what this means, and if I'm causing it 1903 Find out what this means, and if I'm causing it<br>Apparently this may be caused by using HTML code when providing strings to controls. The most basic solution - as far as I can see - is to disable formatting arguments under mac 1904 1904 1905 1905 203B239 … … 1917 1917 NA 1918 1918 Pending 1919 Determine if this is a refresh problem (which I doubt) or something symptomatic of Java/Mac 1919 Determine if this is a refresh problem (which I doubt) or something symptomatic of Java/Mac<br>The bug itself is triggered by a pretty specific set of circumstances. You must a) have a dynamic custom TreeModel, b) have the underlying TreeUI decide to use a VariableHeightLayoutCache and c) expand a node higher in the tree than an already expanded node. If you do this the layout cache returns an incorrect value for the number of displayable rows and things go pear shaped. As best as I can figure the model modified events being thrown by the custom model are not being recieved in a timely fashion by the layout cache. Anyhow the solution was painfully easy - simple prevent the TreeUI using VariableHeightLayoutCache by providing a prototype row height, and thus switching to a FixedHeightLayoutCache, which apparently doesn't suffer the same bug. Co-incidently under any other circumstances a fixed height layout cache would have been faster anyway. Unfortunately with the FileSystemModel and saving/loss in layout time is drawfed by the file IO time 1920 1920 1921 1921 203B241 … … 1924 1924 Mac 1925 1925 NA 1926 Pending 1927 The easiest way to restore these is to make the root node visible - however we don't want that so I have to figure out a different smarter way 1926 Fixed 1927 The easiest way to restore these is to make the root node visible - however we don't want that so I have to figure out a different smarter way<br>Yes, I had to be especially sneaky. I had to call the setShowsRootHandles() method with a value of... true. Wow. 1928 1928 1929 1929 203B242 … … 1932 1932 Mac 1933 1933 NA 1934 Pending 1935 Ensure transparency set, and perhaps choose a different colour 1934 Fixed 1935 Ensure transparency set, and perhaps choose a different colour<br>transparency had transferred to a different colour - all bad. It's fixed now though. 1936 1936 1937 1937 203B243 … … 1941 1941 NA 1942 1942 Pending 1943 Check how line created, and investigate other, less platform specific, solutions 1943 Check how line created, and investigate other, less platform specific, solutions<br>Menu lines under mac default to an empty line. Replaced UI with BasicSeparatorUI. Oh-no. This has the undesired effect of transforming all of the menu separators in gli. New plan - provide a BasicSeparatorUI implementation just for the plugin separator 1944 1944 1945 1945 203B244 … … 2390 2390 Fixed 2391 2391 Ensure that the cancel action doesn't call the clear filter methods (as it used to before the remove filter button was added)<br>Done 2392 2393 203F354 2394 Allow free editing of the collect.cfg - to allow commenting etc 2395 NZDL 2396 All 2397 NA 2398 Pending 2399 This of course was the reason I rewrote the entire CDM to use a DOM as its model. My previous data model caused all non-recognized commands in the config - including comments - to be pushed to the bottom of the collect.cfg gli wrote out. Now that the DOM is in place a free editor shouldn't be too dificult - simply use a list proxied onto the DOM and treat adding/removing a list entry as adding/removing a node in the tree.
Note:
See TracChangeset
for help on using the changeset viewer.