Changeset 6256


Ignore:
Timestamp:
2003-12-12T17:56:14+13:00 (20 years ago)
Author:
jmt12
Message:

Fixed more bugs

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/gli/buglist/status.txt

    r6218 r6256  
    6936934e3
    694694Pending
    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.
     695Should 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
    696696
    697697203B087
     
    12201220Mac
    12211221NA
    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
     1222Fixed
     1223Find 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
    12241224
    12251225203B154
     
    12281228Mac
    12291229NA
    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
     1230Fixed
     1231Perhaps 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
    12321232
    12331233203B155
     
    14531453NA
    14541454Fixed
    1455 The Metadata Set Editor is due for a complete overhaul.<br>Mostly due to the DOM node remove not being implemented properly.
     1455The Metadata Set Editor is long overdue for a overhaul.<br>Mostly due to the DOM node remove not being implemented properly.
    14561456
    14571457203B183
     
    15481548Linux (Mandrake)
    154915492.5
    1550 Pending
     1550Fixed
    15511551It 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.
    15521552
     
    19011901NA
    19021902Pending
    1903 Find out what this means, and if I'm causing it
     1903Find 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
    19041904
    19051905203B239
     
    19171917NA
    19181918Pending
    1919 Determine if this is a refresh problem (which I doubt) or something symptomatic of Java/Mac
     1919Determine 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
    19201920
    19211921203B241
     
    19241924Mac
    19251925NA
    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
     1926Fixed
     1927The 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.
    19281928
    19291929203B242
     
    19321932Mac
    19331933NA
    1934 Pending
    1935 Ensure transparency set, and perhaps choose a different colour
     1934Fixed
     1935Ensure transparency set, and perhaps choose a different colour<br>transparency had transferred to a different colour - all bad. It's fixed now though.
    19361936
    19371937203B243
     
    19411941NA
    19421942Pending
    1943 Check how line created, and investigate other, less platform specific, solutions
     1943Check 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
    19441944
    19451945203B244
     
    23902390Fixed
    23912391Ensure 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
     2393203F354
     2394Allow free editing of the collect.cfg - to allow commenting etc
     2395NZDL
     2396All
     2397NA
     2398Pending
     2399This 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.