[cp-patches] [generics] FYI: Getting ready for concurrency
I'm committing the attached patch which adds some features required by
the new concurrency tree prepared by Tom Tromey and documented by
myself.
Changelog:
2006-03-20 Andrew John Hughes [EMAIL PROTECTED]
* java/lang/System.java:
(nanoTime()): Documented.
* java/lang/Thread.java:
(setUncaughtExceptionHandler(UncaughtExceptionHandler):
Added docs and security check.
(getUncaughtExceptionHandler()): Documented.
(setDefaultUncaughtExceptionHandler(UncaughtExceptionHandler):
Added docs and security check.
(getDefaultUncaughtExceptionHandler()): Documented.
(getId()): Documented.
(Thread.State): Documented.
* vm/reference/gnu/classpath/Unsafe.java:
Documented.
(getUnsafe()): Updated to handle security.
2006-03-20 Tom Tromey [EMAIL PROTECTED]
* java/lang/System.java:
(nanoTime()): Implemented.
* java/lang/Thread.java:
(getId()): Implemented.
* java/util/AbstractMap.java:
(SimpleImmutableEntry): New 1.6 class.
(BasicMapEntry): Modified to be SimpleEntry.
* java/util/Collections.java:
Modified to use SimpleEntry.
* java/util/EnumMap.java: Likewise.
* java/util/HashMap.java: Likewise.
* java/util/Hashtable.java: Likewise.
* java/util/TreeMap.java: Likewise.
* vm/reference/gnu/classpath/Unsafe.java:
New class to handle low-level facilities for concurrency.
* vm/reference/java/lang/VMSystem.java:
(nanoTime()): Implemented.
Index: java/lang/System.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/System.java,v
retrieving revision 1.38.2.15
diff -u -3 -p -u -r1.38.2.15 System.java
--- java/lang/System.java 2 Mar 2006 09:33:58 - 1.38.2.15
+++ java/lang/System.java 20 Mar 2006 00:21:11 -
@@ -233,6 +233,36 @@ public final class System
{
return VMSystem.currentTimeMillis();
}
+
+ /**
+ * p
+ * Returns the current value of a nanosecond-precise system timer.
+ * The value of the timer is an offset relative to some arbitrary fixed
+ * time, which may be in the future (making the value negative). This
+ * method is useful for timing events where nanosecond precision is
+ * required. This is achieved by calling this method before and after the
+ * event, and taking the difference betweent the two times:
+ * /p
+ * p
+ * codelong startTime = System.nanoTime();/codebr /
+ * code... emphevent code/emph .../codebr /
+ * codelong endTime = System.nanoTime();/codebr /
+ * codelong duration = endTime - startTime;/codebr /
+ * /p
+ * p
+ * Note that the value is only nanosecond-precise, and not accurate; there
+ * is no guarantee that the difference between two values is really a
+ * nanosecond. Also, the value is prone to overflow if the offset
+ * exceeds 2^63.
+ * /p
+ *
+ * @return the time of a system timer in nanoseconds.
+ * @since 1.5
+ */
+ public static long nanoTime()
+ {
+return VMSystem.nanoTime();
+ }
/**
* Copy one array onto another from codesrc[srcStart]/code ...
Index: java/lang/Thread.java
===
RCS file: /cvsroot/classpath/classpath/java/lang/Thread.java,v
retrieving revision 1.8.2.12
diff -u -3 -p -u -r1.8.2.12 Thread.java
--- java/lang/Thread.java 2 Mar 2006 09:33:58 - 1.8.2.12
+++ java/lang/Thread.java 20 Mar 2006 00:21:12 -
@@ -131,9 +131,18 @@ public class Thread implements Runnable
/** The context classloader for this Thread. */
private ClassLoader contextClassLoader;
+
+ /** This thread's ID. */
+ private final long threadId;
+
+ /** The park blocker. See LockSupport. */
+ Object parkBlocker;
/** The next thread number to use. */
private static int numAnonymousThreadsCreated;
+
+ /** The next thread ID to use. */
+ private static long nextThreadId;
/** The default exception handler. */
private static UncaughtExceptionHandler defaultHandler;
@@ -349,6 +358,11 @@ public class Thread implements Runnable
this.name = name.toString();
this.runnable = target;
this.stacksize = size;
+
+synchronized (Thread.class)
+ {
+this.threadId = nextThreadId++;
+ }
priority = current.priority;
daemon = current.daemon;
@@ -378,6 +392,10 @@ public class Thread implements Runnable
this.priority = priority;
this.daemon = daemon;
this.contextClassLoader = ClassLoader.getSystemClassLoader();
+synchronized (Thread.class)
+{
+ this.threadId = nextThreadId++;
+}
}
/**
@@ -1020,29 +1038,100 @@ public class Thread implements Runnable
return locals;
}
- /** @since 1.5 */
+ /**
+ * Assigns the given codeUncaughtExceptionHandler/code to this
+ * thread. This will then be called if the thread terminates due
+ *
[cp-patches] FYI:Scroll with the wheel into the table row and tree node boundaries.
2006-03-20 Audrius Meskauskas [EMAIL PROTECTED]
* javax/swing/JTable.java (getScrollableUnitIncrement): Rewritten.
* javax/swing/JTree.java (getScrollableUnitIncrement): Rewritten.
(getScrollableUnitIncrement
* javax/swing/Scrollable.java: Documented.
* javax/swing/plaf/basic/BasicScrollPaneUI.java
(MouseWheelHandler):Rewritten.
Index: swing/JTable.java
===
RCS file: /sources/classpath/classpath/javax/swing/JTable.java,v
retrieving revision 1.87
diff -u -r1.87 JTable.java
--- swing/JTable.java 20 Mar 2006 00:08:27 - 1.87
+++ swing/JTable.java 20 Mar 2006 09:03:32 -
@@ -2104,23 +2104,31 @@
}
/**
- * Get the amount to scroll per one mouse wheel click.
+ * Return the preferred scrolling amount (in pixels) for the given scrolling
+ * direction and orientation.
+ *
+ * @param visibleRect the currently visible part of the component.
+ * @param orientation the scrolling orientation
+ * @param direction the scrolling direction (negative - up, positive -down).
+ * The values greater than one means that more mouse wheel or similar
+ * events were generated, and hence it is better to scroll the longer
+ * distance.
*/
- public int getScrollableUnitIncrement(Rectangle visibleRect,
-int orientation, int direction)
+ public int getScrollableUnitIncrement(Rectangle visibleRect, int orientation,
+int direction)
{
+int h = (rowHeight + rowMargin);
+int delta = h * ROWS_PER_WHEEL_CLICK * direction;
+
+// Round so that the top would start from the row boundary
if (orientation == SwingConstants.VERTICAL)
{
-return (rowHeight + rowMargin) * ROWS_PER_WHEEL_CLICK;
- }
-else
- {
-int sum = 0;
-for (int i = 0; i getColumnCount(); ++i)
- sum += columnModel.getColumn(0).getWidth();
-int inc = getColumnCount() == 0 ? 10 : sum / getColumnCount();
-return inc;
+int near = ((visibleRect.y + delta +h/2) / h) * h;
+int diff = visibleRect.y + delta - near;
+delta -= diff;
}
+return delta;
+// TODO when scrollng horizontally, scroll into the column boundary.
}
/**
Index: swing/JTree.java
===
RCS file: /sources/classpath/classpath/javax/swing/JTree.java,v
retrieving revision 1.57
diff -u -r1.57 JTree.java
--- swing/JTree.java 20 Mar 2006 00:08:27 - 1.57
+++ swing/JTree.java 20 Mar 2006 09:03:38 -
@@ -1627,11 +1627,42 @@
{
return new Dimension (getPreferredSize().width, getVisibleRowCount()*getRowHeight());
}
-
- public int getScrollableUnitIncrement(Rectangle visibleRect,
-int orientation, int direction)
+
+ /**
+ * Return the preferred scrolling amount (in pixels) for the given scrolling
+ * direction and orientation.
+ *
+ * @param visibleRect the currently visible part of the component.
+ * @param orientation the scrolling orientation
+ * @param direction the scrolling direction (negative - up, positive -down).
+ * The values greater than one means that more mouse wheel or similar
+ * events were generated, and hence it is better to scroll the longer
+ * distance.
+ *
+ * @author Audrius Meskauskas ([EMAIL PROTECTED])
+ */
+ public int getScrollableUnitIncrement(Rectangle visibleRect, int orientation,
+int direction)
{
-return rowHeight*ROWS_PER_WHEEL_CLICK;
+int delta;
+
+// Round so that the top would start from the row boundary
+if (orientation == SwingConstants.VERTICAL)
+ {
+int row = getClosestRowForLocation(visibleRect.x, visibleRect.y);
+row = row + direction;
+if (row 0)
+ row = 0;
+if (row getRowCount())
+ row = getRowCount();
+
+Rectangle newTop = getRowBounds(row);
+delta = newTop.y - visibleRect.y;
+ }
+else
+ delta = direction * ROWS_PER_WHEEL_CLICK * rowHeight == 0 ? 20
+ : rowHeight;
+return delta;
}
public int getScrollableBlockIncrement(Rectangle visibleRect,
Index: swing/Scrollable.java
===
RCS file: /sources/classpath/classpath/javax/swing/Scrollable.java,v
retrieving revision 1.6
diff -u -r1.6 Scrollable.java
--- swing/Scrollable.java 13 Sep 2005 09:17:21 - 1.6
+++ swing/Scrollable.java 20 Mar 2006 09:03:39 -
@@ -50,14 +50,57 @@
{
Dimension getPreferredScrollableViewportSize();
+ /**
+ * Return the preferred scrolling amount (in pixels) for the given
+ * scrolling direction and orientation when scrolling in small amounts
+ * like table
Re: [cp-patches] FYI:More general mouse wheel support
Hi Audrius, Am Montag, den 20.03.2006, 01:06 +0100 schrieb Audrius Meskauskas: Surely, we can make via BasicScrollPaneUI and then have the JTrees scrolling with the wheel as well! Wow, very nice! However, I would not recommend to change the getScrollableUnitIncrement methods. The units must stay the same (like one row for a JTable, one line of text in JTextComponent and so on). This is because a single click on a scollbar button scrolls the thing for exactly one unit. Only the MouseWheelListener should multiply the unit by 3 to provide the wheel scrolling behaviour of 3 lines per wheel move. /Roman 2006-03-20 Audrius Meskauskas [EMAIL PROTECTED] * javax/swing/JTable.java (ROWS_PER_WHEEL_CLICK): New field. (getScrollableUnitIncrement): Rewritten. * javax/swing/JTree.java (ROWS_PER_WHEEL_CLICK): New field. (getScrollableUnitIncrement): Rewritten. (getScrollableBlockIncrement): Rewritten. * javax/swing/plaf/basic/BasicScrollPaneUI.java (MouseWheelHandler): Implemented. (ViewportContainerListener): New class. (containerListener): New field. (SCROLL_NON_SCROLABLES): New field. (installListeners): Install wheel listeners. (uninstallListeners): Uninstall wheel listeners. * javax/swing/plaf/basic/BasicTableUI.java: Remove the implementation of the MouseWheelListener. (installListeners): Do not install wheel listener. (ROWS_PER_WHEEL_CLICK): Removed. -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [cp-patches] RFC: Checking file resource validity by walking path components
Hi Olivier, On Tue, 2006-03-07 at 22:57 +0100, Olivier Jolly wrote: the current implementation which retrieves a File resource allows to retrieve Files which are located above the root dir (imagine ClassLoader.getResource(../../../etc/passwd)) while it shouldn't (hence the current regression in gnu.testlet.java.net.URLClassLoader.getResource about '..'). Nasty. Good catch. I propose to check the validity of a File resource by walking through all the path components and making sure that all intermediate components are valid (ie File.isDirectory and File.exists are true) and that we never try to get out the root directory. I only consider .. as a way to escaping the root directory, it may be more complex than that ... .. seems a good heuristic. I assume much more will break on any platform were .. isn't up in the file hierarchy. I also think that extracting the path components could be improved from a performance point of view, maybe working on the char[] representation instead of using charAt and storing the length once for all. I was thinking about using a StringTokenizer but it doesn't handle '//' as a single separator and split cie are 1.4+ additions. You can use 1.4+ additions as long as we have implemented them. The only real exceptions are Graphics2D and things that need 1.5 language features. Our Graphics2D is just not mature enough to let anything really depend on it and the 1.5 language features can only be used on the generics branch atm. The implementation seems correct, but as you say it could be made more efficient. You could do the walking over the char[] or use String.indexOf(File.separatorChar, currentIndex) to get more efficiently at the next token. And I would try to get rid of the recursion by keeping track of the last separator position you saw. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [cp-patches] FYI:More general mouse wheel support
On Mon, 2006-03-20 at 10:20 +0100, Roman Kennke wrote: The units must stay the same (like one row for a JTable, one line of text in JTextComponent and so on). This is because a single click on a scollbar button scrolls the thing for exactly one unit. Only the MouseWheelListener should multiply the unit by 3 to provide the wheel scrolling behaviour of 3 lines per wheel move. I looked a bit around how other toolkits do this. And 3 seems to be some magic number. But no really good explanations of why. The best discussion I could find for determining scroll increments was in gnome bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=89259 The bug report is actually about making the step amount configurable which it currently isn't in gtk+. If it was then we could add that to the MouseWheelEvent which currently has a hardcoded value of 1 for the scrollAmount property and we could derive a scroll amount for various components from that for different user settings. Cheers, Mark signature.asc Description: This is a digitally signed message part
RE: [cp-patches] [generics] FYI: Getting ready for concurrency
Andrew John Hughes wrote: I'm committing the attached patch which adds some features required by the new concurrency tree prepared by Tom Tromey and documented by myself. +public class Unsafe Unsafe should be final, otherwise you can create an instance by subclassing and capturing the this in the finalize method. (Note that gnu.classpath.* classes aren't (shouldn't be) visible to untrusted code, so this is just an additional precaution.) Regards, Jeroen
Re: [cp-patches] FYI:More general mouse wheel support
This is not so trivial, because, following the API, getScrollableUnitIncrement should also perform the rounding operation, completely exposing the subsequent item. I will think how to do this better. Audrius. Roman Kennke wrote: Hi Audrius, Am Montag, den 20.03.2006, 01:06 +0100 schrieb Audrius Meskauskas: Surely, we can make via BasicScrollPaneUI and then have the JTrees scrolling with the wheel as well! Wow, very nice! However, I would not recommend to change the getScrollableUnitIncrement methods. The units must stay the same (like one row for a JTable, one line of text in JTextComponent and so on). This is because a single click on a scollbar button scrolls the thing for exactly one unit. Only the MouseWheelListener should multiply the unit by 3 to provide the wheel scrolling behaviour of 3 lines per wheel move. /Roman 2006-03-20 Audrius Meskauskas [EMAIL PROTECTED] * javax/swing/JTable.java (ROWS_PER_WHEEL_CLICK): New field. (getScrollableUnitIncrement): Rewritten. * javax/swing/JTree.java (ROWS_PER_WHEEL_CLICK): New field. (getScrollableUnitIncrement): Rewritten. (getScrollableBlockIncrement): Rewritten. * javax/swing/plaf/basic/BasicScrollPaneUI.java (MouseWheelHandler): Implemented. (ViewportContainerListener): New class. (containerListener): New field. (SCROLL_NON_SCROLABLES): New field. (installListeners): Install wheel listeners. (uninstallListeners): Uninstall wheel listeners. * javax/swing/plaf/basic/BasicTableUI.java: Remove the implementation of the MouseWheelListener. (installListeners): Do not install wheel listener. (ROWS_PER_WHEEL_CLICK): Removed.
Re: [cp-patches] FYI:More general mouse wheel support
Hi Audrius, Am Montag, den 20.03.2006, 10:53 +0100 schrieb Audrius Meskauskas: This is not so trivial, because, following the API, getScrollableUnitIncrement should also perform the rounding operation, completely exposing the subsequent item. I will think how to do this better. maybe do a 2-step scrolling: the first step would scroll by one unit (thus exposing the next item) and the second step scrolls by unit*3. Results in 3-4 scrolled units overall, depending how the component was aligned before. /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[cp-patches] FYI: Fixing scrolling with the scroll bar keys
As Roman noticed, in the previous patch the number of rows per whell
click is multiplied to the magic number 3 in the JTree and JTable. This
forces always to scroll by 3 lines, when clicking on the arrow button of
the scroll bar should only scroll by one.
I move the magic 3 constant to the BasicScrollPaneUI. Probably we may
later think about making it adjustable via system property or something
like that.
2006-03-20 Audrius Meskauskas [EMAIL PROTECTED]
* javax/swing/JTable.java (ROWS_PER_WHEEL_CLICK): Removed.
(getScrollableUnitIncrement): Rewritten.
* javax/swing/JTree.java (ROWS_PER_WHEEL_CLICK): Removed.
(getScrollableUnitIncrement): Rewritten.
* javax/swing/plaf/basic/BasicScrollPaneUI.java
(ROWS_PER_WHEEL_CLICK): New field.
(MouseWheelHandler.mouseWheelMoved): Rewritten.
Index: JTable.java
===
RCS file: /sources/classpath/classpath/javax/swing/JTable.java,v
retrieving revision 1.88
diff -u -r1.88 JTable.java
--- JTable.java 20 Mar 2006 09:09:36 - 1.88
+++ JTable.java 20 Mar 2006 11:15:06 -
@@ -1325,12 +1325,6 @@
* in the table) to provide or absorb excess space requirements.
*/
public static final int AUTO_RESIZE_LAST_COLUMN = 3;
-
- /**
- * The number of rows to scroll per mouse wheel click. From impression,
- * Sun seems using the value 3.
- */
- static int ROWS_PER_WHEEL_CLICK = 3;
/**
* A table mapping [EMAIL PROTECTED] java.lang.Class} objects to
@@ -2105,7 +2099,9 @@
/**
* Return the preferred scrolling amount (in pixels) for the given scrolling
- * direction and orientation.
+ * direction and orientation. This method handles a partially exposed row by
+ * returning the distance required to completely expose the item. When
+ * scrolling the top item is completely exposed.
*
* @param visibleRect the currently visible part of the component.
* @param orientation the scrolling orientation
@@ -2113,22 +2109,24 @@
* The values greater than one means that more mouse wheel or similar
* events were generated, and hence it is better to scroll the longer
* distance.
+ * @author Audrius Meskauskas ([EMAIL PROTECTED])
*/
public int getScrollableUnitIncrement(Rectangle visibleRect, int orientation,
int direction)
{
int h = (rowHeight + rowMargin);
-int delta = h * ROWS_PER_WHEEL_CLICK * direction;
-
-// Round so that the top would start from the row boundary
+int delta = h * direction;
+
+// Round so that the top would start from the row boundary
if (orientation == SwingConstants.VERTICAL)
{
-int near = ((visibleRect.y + delta +h/2) / h) * h;
+// Completely expose the top row
+int near = ((visibleRect.y + delta + h / 2) / h) * h;
int diff = visibleRect.y + delta - near;
delta -= diff;
}
return delta;
-// TODO when scrollng horizontally, scroll into the column boundary.
+// TODO when scrollng horizontally, scroll into the column boundary.
}
/**
Index: JTree.java
===
RCS file: /sources/classpath/classpath/javax/swing/JTree.java,v
retrieving revision 1.58
diff -u -r1.58 JTree.java
--- JTree.java 20 Mar 2006 09:09:36 - 1.58
+++ JTree.java 20 Mar 2006 11:15:13 -
@@ -1347,12 +1347,6 @@
}
private static final long serialVersionUID = 7559816092864483649L;
-
- /**
- * The number of rows to scroll per mouse wheel click. From impression,
- * Sun seems using the value 3.
- */
- static int ROWS_PER_WHEEL_CLICK = 3;
public static final String CELL_EDITOR_PROPERTY = cellEditor;
@@ -1630,7 +1624,8 @@
/**
* Return the preferred scrolling amount (in pixels) for the given scrolling
- * direction and orientation.
+ * direction and orientation. This method handles a partially exposed row by
+ * returning the distance required to completely expose the item.
*
* @param visibleRect the currently visible part of the component.
* @param orientation the scrolling orientation
@@ -1638,8 +1633,7 @@
* The values greater than one means that more mouse wheel or similar
* events were generated, and hence it is better to scroll the longer
* distance.
- *
- * @author Audrius Meskauskas ([EMAIL PROTECTED])
+ * @author Audrius Meskauskas ([EMAIL PROTECTED])
*/
public int getScrollableUnitIncrement(Rectangle visibleRect, int orientation,
int direction)
@@ -1649,19 +1643,17 @@
// Round so that the top would start from the row boundary
if (orientation == SwingConstants.VERTICAL)
{
-int row = getClosestRowForLocation(visibleRect.x, visibleRect.y);
+// One pixel down, otherwise picks another row too high.
+
[cp-patches] FYI: BasicTabbedPane fixes
I have reworked parts of the BasicTabbedPaneUI.TabbedPaneLayout layout
manager. This makes the layout and switching-between-tabs more efficient
and correct (I hope).
This also includes some JDK1.5 additions wrt rollover tabs which wrote
some time ago and which I originally wanted to complete first (in the
MetalTabbedPaneUI) but which I'll commit now anyway. Also this includes
some older adjustments to mouse handling in tabbed panes.
The painting of the metal tabs is still ugly, I'll work on this next.
2006-03-20 Roman Kennke [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicTabbedPaneUI.java
(MouseHandler.mousePressed): Rewritten for clearer and simpler
code.
(MouseHandler.mouseEntered): Implemented to set the rollover
tab.
(MouseHandler.mouseMoved): Implemented to set the rollover tab.
(MouseHandler.mouseExited): Implemented to unset the rollover
tab.
(TabbedPaneLayout.calculateLayoutInfo): Don't set the
component's
bounds here. That is moved into layoutContainer().
(calculateSize): Correctly respect insets. Made code slightly
more
clear and efficient.
(calculateTabRects): Rewritten completely. The old code was
not quite right and unstable in some situations.
(layoutContainer): Moved layout of tabbed pane's subcomponents
here.
(tabRunsDirty): New field.
(rolloverTab): New field.
(tabForCoordinate): Rewritten for simplicity and correctness.
(setRolloverTab): New method.
(getRolloverTab): New method.
/Roman
--
“Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of Genius.” - William Blake
Index: javax/swing/plaf/basic/BasicTabbedPaneUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTabbedPaneUI.java,v
retrieving revision 1.33
diff -u -r1.33 BasicTabbedPaneUI.java
--- javax/swing/plaf/basic/BasicTabbedPaneUI.java 16 Feb 2006 14:39:14 - 1.33
+++ javax/swing/plaf/basic/BasicTabbedPaneUI.java 20 Mar 2006 11:12:43 -
@@ -130,52 +130,49 @@
*/
public void mousePressed(MouseEvent e)
{
- int x = e.getX();
- int y = e.getY();
- int tabCount = tabPane.getTabCount();
-
- if (tabPane.getTabLayoutPolicy() == JTabbedPane.SCROLL_TAB_LAYOUT)
+ if (tabPane.isEnabled())
{
- if (e.getSource() == incrButton)
+ int index = tabForCoordinate(tabPane, e.getX(), e.getY());
+ if (index = 0 tabPane.isEnabledAt(index))
{
- if (++currentScrollLocation = tabCount)
-currentScrollLocation = tabCount - 1;
-
- int width = 0;
- for (int i = currentScrollLocation - 1; i tabCount; i++)
-width += rects[i].width;
- if (width viewport.getWidth())
-// FIXME: Still getting mouse events after the button is disabled.
-// incrButton.setEnabled(false);
-currentScrollLocation--;
- else if (! decrButton.isEnabled())
-decrButton.setEnabled(true);
- tabPane.revalidate();
- tabPane.repaint();
- return;
-}
- else if (e.getSource() == decrButton)
-{
- if (--currentScrollLocation 0)
-currentScrollLocation = 0;
- if (currentScrollLocation == 0)
-decrButton.setEnabled(false);
- else if (! incrButton.isEnabled())
-incrButton.setEnabled(true);
- tabPane.revalidate();
- tabPane.repaint();
- return;
+ tabPane.setSelectedIndex(index);
}
}
+}
- int index = tabForCoordinate(tabPane, x, y);
-
- // We need to check since there are areas where tabs cannot be
- // e.g. in the inset area.
- if (index != -1 tabPane.isEnabledAt(index))
-tabPane.setSelectedIndex(index);
- tabPane.revalidate();
- tabPane.repaint();
+/**
+ * Receives notification when the mouse pointer has entered the tabbed
+ * pane.
+ *
+ * @param ev the mouse event
+ */
+public void mouseEntered(MouseEvent ev)
+{
+ int tabIndex = tabForCoordinate(tabPane, ev.getX(), ev.getY());
+ setRolloverTab(tabIndex);
+}
+
+/**
+ * Receives notification when the mouse pointer has exited the tabbed
+ * pane.
+ *
+ * @param ev the mouse event
+ */
+public void mouseExited(MouseEvent ev)
+{
+ setRolloverTab(-1);
+}
+
+/**
+ * Receives notification when the mouse pointer has moved over the tabbed
+ * pane.
+ *
+ * @param ev the mouse event
+ */
+public void mouseMoved(MouseEvent ev)
+{
+ int tabIndex = tabForCoordinate(tabPane, ev.getX(), ev.getY());
+
[cp-patches] FYI: BasicTabbedPaneUI painting fix
My last patch seems to have broken TabbedPane painting slightly. This
was because the order in which the tabs are stored internally has
changed. I fixed this and made the painting code slighly more
straightforward.
2006-03-20 Roman Kennke [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicTabbedPaneUI.java
(paint): Make sure the layout is valid before painting.
(paintTabArea): Made tab painting more straightforward and
efficient.
/Roman
--
“Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of Genius.” - William Blake
Index: javax/swing/plaf/basic/BasicTabbedPaneUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTabbedPaneUI.java,v
retrieving revision 1.34
diff -u -r1.34 BasicTabbedPaneUI.java
--- javax/swing/plaf/basic/BasicTabbedPaneUI.java 20 Mar 2006 11:14:06 - 1.34
+++ javax/swing/plaf/basic/BasicTabbedPaneUI.java 20 Mar 2006 11:38:07 -
@@ -1770,6 +1770,9 @@
*/
public void paint(Graphics g, JComponent c)
{
+if (!tabPane.isValid())
+ tabPane.validate();
+
if (tabPane.getTabCount() == 0)
return;
if (tabPane.getTabLayoutPolicy() == JTabbedPane.WRAP_TAB_LAYOUT)
@@ -1795,42 +1798,26 @@
// Please note: the ordering of the painting is important.
// we WANT to paint the outermost run first and then work our way in.
int tabCount = tabPane.getTabCount();
-int currRun = 1;
-
-if (tabCount 1)
- return;
-
-if (runCount 1)
- currRun = 0;
-for (int i = 0; i runCount; i++)
+for (int i = runCount - 1; i = 0; --i)
{
-int first = lastTabInRun(tabCount, getPreviousTabRun(currRun)) + 1;
-if (isScroll)
- first = currentScrollLocation;
-else if (first == tabCount)
- first = 0;
-int last = lastTabInRun(tabCount, currRun);
-if (isScroll)
+int start = tabRuns[i];
+int next;
+if (i == runCount - 1)
+ next = 0;
+else
+ next = i + 1;
+int end = (next != 0 ? next - 1 : tabCount - 1);
+for (int j = start; j = end; ++j)
{
-for (int k = first; k tabCount; k++)
+if (j != selectedIndex)
{
-if (rects[k].x + rects[k].width - rects[first].x viewport
-.getWidth())
- {
-last = k;
-break;
- }
+paintTab(g, tabPlacement, rects, j, ir, tr);
}
}
-
-for (int j = first; j = last; j++)
- {
-if (j != selectedIndex || isScroll)
- paintTab(g, tabPlacement, rects, j, ir, tr);
- }
-currRun = getPreviousTabRun(currRun);
}
-if (! isScroll)
+
+// Paint selected tab in front of every other tab.
+if (selectedIndex = 0)
paintTab(g, tabPlacement, rects, selectedIndex, ir, tr);
}
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
[cp-patches] FYI: More BasicTabbedPaneUI fixlets
And on we go with fixing the BasicTabbedPaneUI. This patch fixes the
layout of the tabs a little more:
2006-03-20 Roman Kennke [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicTabbedPaneUI.java
(calculateTabHeight): Not need to use SwingUtilities here.
(getTabInsets): Do not rotate insets.
/Roman
--
“Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of Genius.” - William Blake
Index: javax/swing/plaf/basic/BasicTabbedPaneUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTabbedPaneUI.java,v
retrieving revision 1.35
diff -u -r1.35 BasicTabbedPaneUI.java
--- javax/swing/plaf/basic/BasicTabbedPaneUI.java 20 Mar 2006 11:42:11 - 1.35
+++ javax/swing/plaf/basic/BasicTabbedPaneUI.java 20 Mar 2006 14:07:41 -
@@ -2601,24 +2601,14 @@
protected int calculateTabHeight(int tabPlacement, int tabIndex,
int fontHeight)
{
-Icon icon = getIconForTab(tabIndex);
-Insets insets = getTabInsets(tabPlacement, tabIndex);
+// FIXME: Handle HTML somehow.
-int height = 0;
+int height = fontHeight;
+Icon icon = getIconForTab(tabIndex);
+Insets tabInsets = getTabInsets(tabPlacement, tabIndex);
if (icon != null)
- {
-Rectangle vr = new Rectangle();
-Rectangle ir = new Rectangle();
-Rectangle tr = new Rectangle();
-layoutLabel(tabPlacement, getFontMetrics(), tabIndex,
-tabPane.getTitleAt(tabIndex), icon, vr, ir, tr,
-tabIndex == tabPane.getSelectedIndex());
-height = tr.union(ir).height;
- }
-else
- height = fontHeight;
-
-height += insets.top + insets.bottom;
+ height = Math.max(height, icon.getIconHeight());
+height += tabInsets.top + tabInsets.bottom + 2;
return height;
}
@@ -2751,9 +2741,7 @@
*/
protected Insets getTabInsets(int tabPlacement, int tabIndex)
{
-Insets target = new Insets(0, 0, 0, 0);
-rotateInsets(tabInsets, target, tabPlacement);
-return target;
+return tabInsets;
}
/**
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [cp-patches] Patch: FYI: implement NumericShaper
On 3/19/06, Stuart Ballard [EMAIL PROTECTED] wrote: As far as I can figure out, an annotation is pretty much the only way to get these kinds of methods to get flagged by Japi. Actually, I figured out (and implemented in Japi) a place where we can carry a flag on any method without requiring 1.5 at all. Adding an unchecked exception to the throws clause has absolutely no semantic effect (and Japi knows this and ignores them), but Japi can be (and has been) modified to pick up a particular exception and report based on it. I believe Classpath already has an unchecked NotImplementedException so that's what I used. Any method marked as throws NotImplementedException will be reported by Japi as not implemented in Classpath, in the same category as missing errors. Any feedback on this approach is welcome, I'm certainly willing to modify it if people have any suggested improvements. Note that I'm not suggesting we just leave all stub methods around indiscriminately and use this trick on them; stub methods that aren't inherited from a superclass and can be removed without breaking compilation should just be removed. But for the ones we can't remove, we can now flag them. Obviously, the throws clause technique only works on methods and constructors, not fields or classes, but I don't think this is a big problem. There's not really any such thing as a stub field (it's either there or not) and any classes made up entirely of stubs should surely be removed anyway. If this approach is acceptable to everyone, the next question is how do we identify the stub methods to flag them? Obviously there's no reliable programmatic way but it seems like a program ought to be able to report possible candidates for a human to look through. I think any stub method would fall into one of these categories: A) Void method that does nothing at all or nothing but return; B) Method that unconditionally throws; C) Method that unconditionally calls superclass implementation of the same method with the same args; or D) Method that unconditionally returns a hardcoded constant, including null. Obviously detecting these things would give a lot of false positives, especially D, but I think it should catch all the stubs. Anyone know of a good tool that could produce a list of methods meeting these criteria? Stuart. -- http://sab39.dev.netreach.com/
[cp-patches] Re: RFC: gdkpixbuf looking vs main gdk lock
Hi, On Sun, 2006-03-19 at 11:54 +0100, Mark Wielaard wrote: Only for those functions that manipulate Graphics state also the main gdk lock is acquired. Yes, this patch looks good. The danger in introducing another lock is mutual-embrace deadlocks but I looked through the code and there aren't any cases where the locks are obtained in the reverse order. Please commit. Thanks, Tom
Re: [cp-patches] [Patch] locale data update - part 2
Hi Michael, On Sun, 2006-03-19 at 22:40 +, Michael Koch wrote: I just commited another update for the locale data update to CLDR 1.3. The only things still missing is the update of the currency formats and the new locales. Could you take a quick look at the following regressions (and one improvement!) pointed out by builder.classpath.org? On Mon, 2006-03-20 at 11:07 +, [EMAIL PROTECTED] wrote: Baseline from: Mon Mar 20 00:20:23 UTC 2006 Regressions: FAIL: gnu.testlet.java.lang.Thread.sleep: Interrupted sleep (number 2) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 1) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 10) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 11) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 12) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 15) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 16) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 17) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 2) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 20) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 21) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 22) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 23) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 24) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 25) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 5) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 6) FAIL: gnu.testlet.locales.LocaleTest: numberformats locale: fi_FI (number 7) Improvements: PASS: gnu.testlet.java.text.SimpleDateFormat.regress: CDT (number 1) The sleep one seems spurious and not important. It certainly isn't caused by the locale update. Thanks, Mark signature.asc Description: This is a digitally signed message part
[cp-patches] Re: RFC: gdkpixbuf looking vs main gdk lock
Hi, On Mon, 2006-03-20 at 09:28 -0500, Thomas Fitzsimmons wrote: On Sun, 2006-03-19 at 11:54 +0100, Mark Wielaard wrote: Yes, this patch looks good. The danger in introducing another lock is mutual-embrace deadlocks but I looked through the code and there aren't any cases where the locks are obtained in the reverse order. Thanks for checking that. Please commit. Done. If you have a scroll mouse please try out WW2D with Cacao (I didn't get it working with jamvm yet, which seems to crash after loading jawt). Make sure you have a libgnujawt.so that is named correctly in /usr/local/classpath/lib/classpath (there is some trick to that which I always forget... we probably should add it to our build/install so there is a real libjawt.so). Then just follow the instructions at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348504 Next up is figuring out why KeyEvents aren't delivered to the custom Canvas (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26703). And it seems to use a bit much cpu loading/scaling some of the higher resolution images. Also the colors seem a little off, but running it with -Dgnu.java.awt.peer.gtk.Graphics=Graphics2D seems to fix that (but you don't actually need Graphics2D support for WW2D). But the current result is already pretty nice! http://gnu.wildebeest.org/diary/index.php?p=156 Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [cp-patches] Re: RFC: gdkpixbuf looking vs main gdk lock
Hi Mark, On 3/20/06, Mark Wielaard [EMAIL PROTECTED] wrote: Hi, Done. If you have a scroll mouse please try out WW2D with Cacao (I didn't get it working with jamvm yet, which seems to crash after loading jawt). What version of JamVM are you using (i.e. is it CVS or a released version)? Can you give details as to how to reproduce? Thanks, Rob.
[cp-patches] Re: Flagging stubs -- was FYI: implement NumericShaper
On 3/20/06, Andrew John Hughes [EMAIL PROTECTED] wrote: It sounds like a bad hack on the JAPI side, but it's up to you if you're maintaining this. True enough, but I think the problem of stub-inflated japi reports is important enough to try to find some way of tackling it. Obviously an annotation would be nicer and I'll probably migrate to that once it becomes practical, but I'd rather have a hacky solution today than no solution at all for months. I can't currently find NotImplementedException in Classpath outside the new jdwp code, but I may be missing something. If we have a gnu.classpath.NotImplementedException, then we could catch this specifically in JAPI, and also output a nice message. I must have misremembered I guess. Japi actually scans for *anything* called NotImplementedException in any package (because I was writing this code while offline and besides I want it to work for other projects too who might not be happy with gnu.classpath. (coughharmonycough). The immediate problem I see (and why we don't generally use an exception) is that the problem can still continue with an exception, whereas it can't with an error. I could easily change it to NotImplementedError, or accept either. The important thing from Japi's perspective isn't whether the exception *actually* gets thrown - it could be, or the class could silently do nothing as it currently does, which in some cases may still be preferable if the functionality is noncritical. All Japi cares about is whether it shows up in the throws clause. The main problem I can foresee is actually finding all the code and putting this in... Yep. Hence the question about automated scanning to find a list of candidates... :) I'd rather have a process that gives lots of false positives than a process that misses lots... Stuart. -- http://sab39.dev.netreach.com/
[cp-patches] FYI: BasicTabbedPaneUI painting
I took a deep look at how the painting of the TabbedPane work. I
determined which methods call which under which circumstances and with
which parameters and tried to recreate the paining behaviour as close as
possible in the BasicTabbedPaneUI. The according Metal fixes follow
soon.
2006-03-20 Roman Kennke [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicTabbedPaneUI.java
(paintTab): Fixed painting.
(paintText): Fixed text painting.
(paintFocusIndicator): Fixed painting of the focus rectangle.
(paintContentBorder): Fixed painting of the content area.
/Roman
--
“Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of Genius.” - William Blake
Index: javax/swing/plaf/basic/BasicTabbedPaneUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTabbedPaneUI.java,v
retrieving revision 1.36
diff -u -r1.36 BasicTabbedPaneUI.java
--- javax/swing/plaf/basic/BasicTabbedPaneUI.java 20 Mar 2006 14:10:09 - 1.36
+++ javax/swing/plaf/basic/BasicTabbedPaneUI.java 20 Mar 2006 17:33:53 -
@@ -1835,49 +1835,34 @@
protected void paintTab(Graphics g, int tabPlacement, Rectangle[] rects,
int tabIndex, Rectangle iconRect, Rectangle textRect)
{
-FontMetrics fm = getFontMetrics();
-Icon icon = getIconForTab(tabIndex);
-String title = tabPane.getTitleAt(tabIndex);
+Rectangle rect = rects[tabIndex];
boolean isSelected = tabIndex == tabPane.getSelectedIndex();
-calcRect = getTabBounds(tabPane, tabIndex);
-
-int x = calcRect.x;
-int y = calcRect.y;
-int w = calcRect.width;
-int h = calcRect.height;
-if (getRunForTab(tabPane.getTabCount(), tabIndex) == 1)
+// Paint background if necessary.
+if (tabPane.isOpaque())
{
-Insets insets = getTabAreaInsets(tabPlacement);
-switch (tabPlacement)
-{
-case TOP:
- h += insets.bottom;
- break;
-case LEFT:
- w += insets.right;
- break;
-case BOTTOM:
- y -= insets.top;
- h += insets.top;
- break;
-case RIGHT:
- x -= insets.left;
- w += insets.left;
- break;
-}
+paintTabBackground(g, tabPlacement, tabIndex, rect.x, rect.y,
+ rect.width, rect.height, isSelected);
}
-layoutLabel(tabPlacement, fm, tabIndex, title, icon, calcRect, iconRect,
-textRect, isSelected);
-paintTabBackground(g, tabPlacement, tabIndex, x, y, w, h, isSelected);
-paintTabBorder(g, tabPlacement, tabIndex, x, y, w, h, isSelected);
+// Paint border.
+paintTabBorder(g, tabPlacement, tabIndex, rect.x, rect.y, rect.width,
+ rect.height, isSelected);
-// FIXME: Paint little folding corner and jagged edge clipped tab.
-if (icon != null)
- paintIcon(g, tabPlacement, tabIndex, icon, iconRect, isSelected);
-if (title != null ! title.equals())
- paintText(g, tabPlacement, tabPane.getFont(), fm, tabIndex, title,
+
+// Layout label.
+FontMetrics fm = getFontMetrics();
+Icon icon = getIconForTab(tabIndex);
+String title = tabPane.getTitleAt(tabIndex);
+layoutLabel(tabPlacement, fm, tabIndex, title, icon, rect, iconRect,
textRect, isSelected);
+// Paint the text.
+paintText(g, tabPlacement, tabPane.getFont(), fm, tabIndex, title,
+ textRect, isSelected);
+// Paint icon if necessary.
+paintIcon(g, tabPlacement, tabIndex, icon, iconRect, isSelected);
+// Paint focus indicator.
+paintFocusIndicator(g, tabPlacement, rects, tabIndex, iconRect, textRect,
+isSelected);
}
/**
@@ -1949,6 +1934,7 @@
FontMetrics metrics, int tabIndex, String title,
Rectangle textRect, boolean isSelected)
{
+g.setFont(font);
View textView = getTextViewForTab(tabIndex);
if (textView != null)
{
@@ -1956,23 +1942,19 @@
return;
}
-Color fg = tabPane.getForegroundAt(tabIndex);
-if (fg == null)
- fg = tabPane.getForeground();
-Color bg = tabPane.getBackgroundAt(tabIndex);
-if (bg == null)
- bg = tabPane.getBackground();
-
-Color saved_color = g.getColor();
-Font f = g.getFont();
-g.setFont(font);
-
-if (tabPane.isEnabledAt(tabIndex))
+int mnemIndex = tabPane.getDisplayedMnemonicIndexAt(tabIndex);
+if (tabPane.isEnabled() tabPane.isEnabledAt(tabIndex))
{
+Color fg = tabPane.getForegroundAt(tabIndex);
+if (isSelected (fg instanceof UIResource))
+ {
+Color selectionForeground =
+ UIManager.getColor(TabbedPane.selectionForeground);
+if (selectionForeground != null)
+ fg = selectionForeground;
+ }
[cp-patches] Flagging stubs -- was FYI: implement NumericShaper
On Mon, 20 Mar 2006 09:15:41 -0500
Stuart Ballard [EMAIL PROTECTED] wrote:
On 3/19/06, Stuart Ballard [EMAIL PROTECTED] wrote:
As far as I can figure out, an annotation is pretty much the only way
to get these kinds of methods to get flagged by Japi.
Actually, I figured out (and implemented in Japi) a place where we can
carry a flag on any method without requiring 1.5 at all. Adding an
unchecked exception to the throws clause has absolutely no semantic
effect (and Japi knows this and ignores them), but Japi can be (and
has been) modified to pick up a particular exception and report based
on it.
I believe Classpath already has an unchecked NotImplementedException
so that's what I used. Any method marked as throws
NotImplementedException will be reported by Japi as not implemented
in Classpath, in the same category as missing errors.
It sounds like a bad hack on the JAPI side, but it's up to you if you're
maintaining this. I can't currently find NotImplementedException in
Classpath outside the new jdwp code, but I may be missing something.
If we have a gnu.classpath.NotImplementedException, then we could catch
this specifically in JAPI, and also output a nice message.
The immediate problem I see (and why we don't generally use an exception) is
that the problem can still continue with an exception, whereas it can't with
an error.
Any feedback on this approach is welcome, I'm certainly willing to
modify it if people have any suggested improvements.
The main problem I can foresee is actually finding all the code and putting
this in...
Note that I'm not suggesting we just leave all stub methods around
indiscriminately and use this trick on them; stub methods that aren't
inherited from a superclass and can be removed without breaking
compilation should just be removed. But for the ones we can't remove,
we can now flag them.
Agreed; I think this should be a last resort course of action.
Obviously, the throws clause technique only works on methods and
constructors, not fields or classes, but I don't think this is a big
problem. There's not really any such thing as a stub field (it's
either there or not) and any classes made up entirely of stubs should
surely be removed anyway.
If this approach is acceptable to everyone, the next question is how
do we identify the stub methods to flag them? Obviously there's no
reliable programmatic way but it seems like a program ought to be able
to report possible candidates for a human to look through. I think any
stub method would fall into one of these categories:
A) Void method that does nothing at all or nothing but return;
B) Method that unconditionally throws;
C) Method that unconditionally calls superclass implementation of the
same method with the same args; or
D) Method that unconditionally returns a hardcoded constant, including null.
Obviously detecting these things would give a lot of false positives,
especially D, but I think it should catch all the stubs. Anyone know
of a good tool that could produce a list of methods meeting these
criteria?
There are some FIXMEs in the code that would also help, but I think it has to
be
a largely manual process starting with a grep of the source for FIXMEs and then
checking likely candidates (there are obviously some classes that are fully
or largely implemented).
This seems like another case of reviewing code that is going to become more
prominent as Classpath matures to a largely implemented codebase. The same
really needs to be done for documentation and security.
Stuart.
--
http://sab39.dev.netreach.com/
Cheers,
--
Andrew :-)
Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Support OpenDocument instead.
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn.
-- Richard Stallman
The views expressed above are representative of my own personal
opinions, and not necessarily those of the University of Sheffield.
pgpQEM3zGaNgv.pgp
Description: PGP signature
Re: [cp-patches] Re: RFC: gdkpixbuf looking vs main gdk lock
Hi Rob, On Mon, 2006-03-20 at 15:37 +, Robert Lougher wrote: On 3/20/06, Mark Wielaard [EMAIL PROTECTED] wrote: Done. If you have a scroll mouse please try out WW2D with Cacao (I didn't get it working with jamvm yet, which seems to crash after loading jawt). What version of JamVM are you using (i.e. is it CVS or a released version)? Can you give details as to how to reproduce? Sorry for the vague bug report. It is with the last release of jamvm 1.4.2. To be really honest I cannot remember how to recreate the libjawt.so from the one in /usr/local/classpath/lib/classpath The jogl library is very specific in how it wants this named and loaded. If you have that (Christian/Tom?) then you can replicate the issue with the instructions (just replace cacao with jamvm) of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348504 Cheers, Mark
Re: [cp-patches] Re: RFC: gdkpixbuf looking vs main gdk lock
On Mon, 2006-03-20 at 19:20 +0100, Mark Wielaard wrote: Hi Rob, On Mon, 2006-03-20 at 15:37 +, Robert Lougher wrote: On 3/20/06, Mark Wielaard [EMAIL PROTECTED] wrote: Done. If you have a scroll mouse please try out WW2D with Cacao (I didn't get it working with jamvm yet, which seems to crash after loading jawt). What version of JamVM are you using (i.e. is it CVS or a released version)? Can you give details as to how to reproduce? Sorry for the vague bug report. It is with the last release of jamvm 1.4.2. To be really honest I cannot remember how to recreate the libjawt.so from the one in /usr/local/classpath/lib/classpath The jogl library is very specific in how it wants this named and loaded. If you have that (Christian/Tom?) then you can replicate the issue with the instructions (just replace cacao with jamvm) of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=348504 We use this invocation in java-gcj-compat: echo | gcc -shared -O2 -fPIC -o libjawt.so -Wl,-soname,libjawt.so -xc - -lgcjawt to create a binary-compatible replacement for Sun's libjawt.so. (Note that libgcj's version of libjawtgnu.so is called libgcjawt.so. I would like to change this and have all free runtime environments standardize on the name libjawtgnu.so). Tom
Re: [cp-patches] FYI:javax/swing/ViewportLayout.java (layoutContainer) rewrite
Hi Audrius, The patch seems bringing no regressions, as far as I was able to test. Thanks for fixing this. Do you think you could write a testcase for the problem you originally had? /Roman I only used visual tests at the moment. However the table was really bottom aligned, and the empty area before the first table column was also discussed in FOSDEM. Sure, I know. I was not suggesting that the patch is wrong. I only thought it would be nice to have this added to the testsuite for that class so that we can better catch regressions in this area. /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [cp-patches] Patch: FYI: implement NumericShaper
Andrew == Andrew John Hughes [EMAIL PROTECTED] writes: Tom We need to declare war on stubs. They improperly inflate our japi Tom scores and blind us to the real state of Classpath. Also I seem to Tom keep running into them as I dig around :-( Andrew My gut instinct would be to remove them all, and really show Andrew up where we at, in order to motivate people to work on these Andrew things that appear implemented. While tempting, I think this is too big a hammer for this problem. I'd rather we not break anything that currently works -- whether it is programs that run poorly, or even programs that currently compile (eg where we may rely on a program not using some of the stubs). Having a list of stubs would be a good start. The ones I fixed this weekend I ran across by chance; I had no idea we had stubs in AWT at all. I like David's idea of a STUB comment. Tom
Re: [cp-patches] Patch: FYI: implement NumericShaper
Stuart == Stuart Ballard [EMAIL PROTECTED] writes: Stuart What's the status on the whole ecj-as-gcc-frontend thing? It is still being discussed by the GCC Steering Committee. I'm hopeful that we'll get the go-ahead and be able to have this in GCC 4.2. Stuart Since gcj Stuart and ecj are pretty much the only maintained Free java compilers at Stuart this point, seems to me that's the only blocker to making the generics Stuart branch the primary development trunk and adopting the new language Stuart features wholesale... Yes, I want to kill the generics branch (by merging it in :-) this year. With some luck, by the summer. Tom
Re: [cp-patches] Patch: FYI: implement NumericShaper
Tom Tromey writes: Andrew == Andrew John Hughes [EMAIL PROTECTED] writes: Tom We need to declare war on stubs. They improperly inflate our japi Tom scores and blind us to the real state of Classpath. Also I seem to Tom keep running into them as I dig around :-( Andrew My gut instinct would be to remove them all, and really show Andrew up where we at, in order to motivate people to work on these Andrew things that appear implemented. While tempting, I think this is too big a hammer for this problem. I'd rather we not break anything that currently works -- whether it is programs that run poorly, or even programs that currently compile (eg where we may rely on a program not using some of the stubs). Having a list of stubs would be a good start. The ones I fixed this weekend I ran across by chance; I had no idea we had stubs in AWT at all. I like David's idea of a STUB comment. Yes. I would love to see the stubs gone, but I love evolutionary development more. Andrew.
[cp-patches] FYI: BasicTabbedPane fixlet
In my last patch I made a slight mistake. I used the next index
directly, instead of looking up the next tab run in the tabRuns array.
This caused most tabs to be not drawn.
2006-03-20 Roman Kennke [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicTabbedPaneUI.java
(paintTabArea): Look up tab run indices in tabRuns array instead
of using the index directly.
Roman
--
“Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of Genius.” - William Blake
Index: javax/swing/plaf/basic/BasicTabbedPaneUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTabbedPaneUI.java,v
retrieving revision 1.37
diff -u -r1.37 BasicTabbedPaneUI.java
--- javax/swing/plaf/basic/BasicTabbedPaneUI.java 20 Mar 2006 17:34:57 - 1.37
+++ javax/swing/plaf/basic/BasicTabbedPaneUI.java 20 Mar 2006 19:28:36 -
@@ -1803,9 +1803,9 @@
int start = tabRuns[i];
int next;
if (i == runCount - 1)
- next = 0;
+ next = tabRuns[0];
else
- next = i + 1;
+ next = tabRuns[i + 1];
int end = (next != 0 ? next - 1 : tabCount - 1);
for (int j = start; j = end; ++j)
{
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
Re: [cp-patches] RFC: Checking file resource validity by walking path components
Re
Mark Wielaard wrote:
I propose to check the validity of a File resource by walking through
all the path components and making sure that all intermediate components
are valid (ie File.isDirectory and File.exists are true) and that we
never try to get out the root directory.
I only consider .. as a way to escaping the root directory, it may
be more complex than that ...
.. seems a good heuristic. I assume much more will break on any
platform were .. isn't up in the file hierarchy.
ok, fine
I also think that extracting the path components could be improved
from a performance point of view, maybe working on the char[]
representation instead of using charAt and storing the length once for
all. I was thinking about using a StringTokenizer but it doesn't handle
'//' as a single separator and split cie are 1.4+ additions.
You can use 1.4+ additions as long as we have implemented them. The only
real exceptions are Graphics2D and things that need 1.5 language
features. Our Graphics2D is just not mature enough to let anything
really depend on it and the 1.5 language features can only be used on
the generics branch atm.
The implementation seems correct, but as you say it could be made more
efficient. You could do the walking over the char[] or use
String.indexOf(File.separatorChar, currentIndex) to get more efficiently
at the next token. And I would try to get rid of the recursion by
keeping track of the last separator position you saw.
okey,
here is attached another version of the patch rewrote with
StringTokenizer and an iterative algorithm. It still passes all the
mauve test about resources and looks more efficient.
Cheers,
Thanks for feedback,
take care
Mark
+Olivier
Index: URLClassLoader.java
===
RCS file: /sources/classpath/classpath/java/net/URLClassLoader.java,v
retrieving revision 1.45
diff -u -r1.45 URLClassLoader.java
--- URLClassLoader.java 5 Mar 2006 17:20:51 - 1.45
+++ URLClassLoader.java 20 Mar 2006 19:12:45 -
@@ -538,6 +538,11 @@
{
try
{
+
+ // Make sure that all components in name are valid by walking through them
+ if (!checkFileValidity(name))
+return null;
+
File file = new File(dir, name).getCanonicalFile();
if (file.exists())
return new FileResource(this, file);
@@ -548,6 +553,55 @@
}
return null;
}
+
+/**
+ * Check all path tokens for validity. At no moment, we are allowed to reach
+ * a directory located above the root directory, stored in dir property.
+ * We are also not allowed to enter a non existing directory or a non
+ * directory component (plain file, symbolic link, ...). An empty or null
+ * path is valid. Pathnames components are separated by
+ * codeFile.separatorChar/code
+ *
+ * @param resourceFileName the remaining name to be checked for validity.
+ * @return whether all path components are valid
+ * @see File#separatorChar
+ */
+private boolean checkFileValidity(String resourceFileName)
+{
+ StringTokenizer stringTokenizer = new StringTokenizer(resourceFileName, File.separator);
+ File currentFile = dir;
+ int tokenCount = stringTokenizer.countTokens();
+
+ for (int i = 0; i tokenCount - 1; i++)
+{
+ String currentToken = stringTokenizer.nextToken();
+
+ // If we are at the root directory and trying to go up, the walking is
+ // finished with an error
+ if (...equals(currentToken) currentFile.equals(dir))
+return false;
+
+ currentFile = new File(currentFile, currentToken);
+
+ // If the current file doesn't exist or is not a directory, the walking is
+ // finished with an error
+ if (! (currentFile.exists() currentFile.isDirectory()))
+return false;
+
+}
+
+ // Treat the last token differently, if it exists, because it does not need
+ // to be a directory
+ if (tokenCount 0)
+{
+ String currentToken = stringTokenizer.nextToken();
+
+ if (...equals(currentToken) currentFile.equals(dir))
+return false;
+}
+
+ return true;
+}
}
static final class FileResource extends Resource
[cp-patches] Fix for classification of XML characters
During development of the XML parser I prevented U+fffd from being classified as an XML Char. Since the introduction of the UnicodeReader class this hack is no longer required. I committed this patch to re-classify U+fffd as a Char and permit the parsing of documents containing this character. 2006-03-20 Chris Burdess [EMAIL PROTECTED] Fixes PR 11070 * gnu/xml/stream/XMLParser.java: Permit U+fffd as XML Char. -- 犬 Chris Burdess They that can give up essential liberty to obtain a little safety deserve neither liberty nor safety. - Benjamin Franklin patch Description: Binary data PGP.sig Description: This is a digitally signed message part
Re: [cp-patches] Patch: FYI: implement NumericShaper
Stuart == Stuart Ballard [EMAIL PROTECTED] writes: I like David's idea of a STUB comment. Stuart Does anyone know if eclipse allows plugging in custom rules to produce Stuart warnings, and where (if anywhere) there's documentation on how to Stuart produce such rules? I don't know. Eclipse can easily find things like 'FIXME' comments, and the list of keywords to search for is configurable. So that would work. The unchecked exception idea would also work, since you can easily search for all references to a given class... if we had a new class for just this purpose, the search would only yield stubs. One thing I've done before to try to find some stubs is search for references to the various Error constructors. This is imprecise though. Tom
[cp-patches] FYI: BasicTabbedPane fix
I added support for the tabsOpaque UIManager property to the
BasicTabbedPane. This property causes the tab background (note: not the
whole JTabbedPane!) to be painted or not, depending on the value.
2006-03-20 Roman Kennke [EMAIL PROTECTED]
* javax/swing/plaf/basic/BasicTabbedPaneUI.java
(tabsOpaque): New field.
(installDefaults): Fetch tabsOpaque property from UIManager.
(paintTab): Fill tab background when tabsOpaque property is
true.
* javax/swing/plaf/basic/BasicLookAndFeel.java
(initComponentDefaults): Added TabbedPane.tabsOpaque property.
/Roman
--
“Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of Genius.” - William Blake
Index: javax/swing/plaf/basic/BasicTabbedPaneUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicTabbedPaneUI.java,v
retrieving revision 1.38
diff -u -r1.38 BasicTabbedPaneUI.java
--- javax/swing/plaf/basic/BasicTabbedPaneUI.java 20 Mar 2006 19:29:17 - 1.38
+++ javax/swing/plaf/basic/BasicTabbedPaneUI.java 20 Mar 2006 21:51:09 -
@@ -1403,6 +1403,12 @@
private int rolloverTab;
/**
+ * Determines if tabs are painted opaque or not. This can be adjusted using
+ * the UIManager property 'TabbedPane.tabsOpaque'.
+ */
+ private boolean tabsOpaque;
+
+ /**
* Creates a new BasicTabbedPaneUI object.
*/
public BasicTabbedPaneUI()
@@ -1617,6 +1623,7 @@
selectedTabPadInsets = UIManager.getInsets(TabbedPane.tabbedPaneTabPadInsets);
tabAreaInsets = UIManager.getInsets(TabbedPane.tabAreaInsets);
contentBorderInsets = UIManager.getInsets(TabbedPane.tabbedPaneContentBorderInsets);
+tabsOpaque = UIManager.getBoolean(TabbedPane.tabsOpaque);
calcRect = new Rectangle();
tabRuns = new int[10];
@@ -1838,7 +1845,7 @@
Rectangle rect = rects[tabIndex];
boolean isSelected = tabIndex == tabPane.getSelectedIndex();
// Paint background if necessary.
-if (tabPane.isOpaque())
+if (tabsOpaque || tabPane.isOpaque())
{
paintTabBackground(g, tabPlacement, tabIndex, rect.x, rect.y,
rect.width, rect.height, isSelected);
Index: javax/swing/plaf/basic/BasicLookAndFeel.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/basic/BasicLookAndFeel.java,v
retrieving revision 1.87
diff -u -r1.87 BasicLookAndFeel.java
--- javax/swing/plaf/basic/BasicLookAndFeel.java 18 Mar 2006 13:42:03 - 1.87
+++ javax/swing/plaf/basic/BasicLookAndFeel.java 20 Mar 2006 21:51:10 -
@@ -1114,6 +1114,7 @@
TabbedPane.shadow, new ColorUIResource(shadow),
TabbedPane.tabbedPaneContentBorderInsets, new InsetsUIResource(3, 2, 1, 2),
TabbedPane.tabbedPaneTabPadInsets, new InsetsUIResource(1, 1, 1, 1),
+ TabbedPane.tabsOpaque, Boolean.TRUE,
TabbedPane.tabAreaInsets, new InsetsUIResource(3, 2, 0, 2),
TabbedPane.tabInsets, new InsetsUIResource(0, 4, 1, 4),
TabbedPane.tabRunOverlay, new Integer(2),
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
[cp-patches] MetalTabbedPaneUI painting fixes
Here comes the bulk of my today's work. It fixes up the painting of the
TabbedPane, including support for the OceanTheme.
The paint* methods look quite difficult, but 1. after my observations I
couldn't think of a more simple way to perform the painting (while
beeing correct). 2. Once you grok the logic behind it, it's actually not
that complicated. Only lengthy.
I also added a couple of stub methods for the content border painting. I
did this because the BasicTabbedPaneUI content border really looks ugly
with the MetalLF, no border is much better. I'll finish this up
tomorrow or so.
2006-03-20 Roman Kennke [EMAIL PROTECTED]
2006-03-20 Roman Kennke [EMAIL PROTECTED]
* javax/swing/plaf/metal/MetalTabbedPaneUI.java
(TabbedPaneLayout.normalizeTabRuns): New method.
(createLayoutManager): Return the Metal TabbedPaneLayout, not
super.
(paintTabBorder): Replaced if-else chain with switch.
(paintTopTabBorder): Rewritten to correctly paint tab. Also
support
Ocean theme.
(paintBottomTabBorder): Rewritten to correctly paint tab. Also
support
Ocean theme.
(paintLeftTabBorder): Rewritten to correctly paint tab. Also
support
Ocean theme.
(paintRightTabBorder): Rewritten to correctly paint tab. Also
support
Ocean theme.
(paintTabBackground): Fetch background color from the
TabbedPane.
Fixed painting and improved by not using fillPolygon, and
instead
using fillRectangle. Replaced if-else chain with switch.
(calculateMaxTabHeight): Added overridden method with FIXME.
(getTabRunOverlay): Overridden to provide overlay for LEFT or
RIGHT
placement.
(paintContentBorderTopEdge): Added stub with FIXME.
(paintContentBorderBottomEdge): Added stub with FIXME.
(paintContentBorderLeftEdge): Added stub with FIXME.
(paintContentBorderRightEdge): Added stub with FIXME.
/Roman
--
“Improvement makes straight roads, but the crooked roads, without
Improvement, are roads of Genius.” - William Blake
Index: javax/swing/plaf/metal/MetalTabbedPaneUI.java
===
RCS file: /cvsroot/classpath/classpath/javax/swing/plaf/metal/MetalTabbedPaneUI.java,v
retrieving revision 1.15
diff -u -r1.15 MetalTabbedPaneUI.java
--- javax/swing/plaf/metal/MetalTabbedPaneUI.java 23 Nov 2005 19:45:43 - 1.15
+++ javax/swing/plaf/metal/MetalTabbedPaneUI.java 20 Mar 2006 22:06:33 -
@@ -101,6 +101,17 @@
// do nothing, because the selected tab does not have extra padding in
// the MetalLookAndFeel
}
+
+/**
+ * Overridden because tab runs are only normalized for TOP and BOTTOM
+ * tab placement in the Metal LF.
+ */
+protected void normalizeTabRuns(int tabPlacement, int tabCount, int start,
+int max)
+{
+ if (tabPlacement == TOP || tabPlacement == BOTTOM)
+super.normalizeTabRuns(tabPlacement, tabCount, start, max);
+}
}
/**
@@ -153,7 +164,7 @@
*/
protected LayoutManager createLayoutManager()
{
-return super.createLayoutManager();
+return new TabbedPaneLayout();
}
/**
@@ -172,16 +183,24 @@
protected void paintTabBorder(Graphics g, int tabPlacement, int tabIndex,
int x, int y, int w, int h, boolean isSelected)
{
-if (tabPlacement == TOP)
- paintTopTabBorder(tabIndex, g, x, y, w, h, 0, 0, isSelected);
-else if (tabPlacement == LEFT)
- paintLeftTabBorder(tabIndex, g, x, y, w, h, 0, 0, isSelected);
-else if (tabPlacement == BOTTOM)
- paintBottomTabBorder(tabIndex, g, x, y, w, h, 0, 0, isSelected);
-else if (tabPlacement == RIGHT)
- paintRightTabBorder(tabIndex, g, x, y, w, h, 0, 0, isSelected);
-else
- throw new AssertionError(Unrecognised 'tabPlacement' argument.);
+int bottom = y + h - 1;
+int right = x + w - 1;
+
+switch (tabPlacement)
+{
+case LEFT:
+ paintLeftTabBorder(tabIndex, g, x, y, w, h, bottom, right, isSelected);
+ break;
+case BOTTOM:
+ paintBottomTabBorder(tabIndex, g, x, y, w, h, bottom, right, isSelected);
+ break;
+case RIGHT:
+ paintRightTabBorder(tabIndex, g, x, y, w, h, bottom, right, isSelected);
+ break;
+case TOP:
+default:
+ paintTopTabBorder(tabIndex, g, x, y, w, h, bottom, right, isSelected);
+}
}
/**
@@ -194,35 +213,90 @@
* @param y the y-coordinate for the tab's bounding rectangle.
* @param w the width for the tab's bounding rectangle.
* @param h the height for the tab's bounding rectangle.
- * @param btm ???
- * @param rght ???
+ * @param btm the y coordinate of the bottom border
+ * @param rght the x coordinate of the right border
* @param isSelected indicates whether the tab is selected.
*/
protected void paintTopTabBorder(int tabIndex, Graphics g, int x, int y,
int w, int
Re: [cp-patches] Patch: FYI: implement NumericShaper
Stuart == Stuart Ballard [EMAIL PROTECTED] writes: Stuart I believe Classpath already has an unchecked NotImplementedException Stuart so that's what I used. Any method marked as throws Stuart NotImplementedException will be reported by Japi as not implemented Stuart in Classpath, in the same category as missing errors. This is a nice hack, I like it. We probably don't want to use the JDWP exception as a marker, in general... I'd rather not overload it like this. We can easily add 'gnu.classpath.NotImplementedException' though. Stuart If this approach is acceptable to everyone, the next question is how Stuart do we identify the stub methods to flag them? By hand I'm afraid... Stuart A) Void method that does nothing at all or nothing but return; Stuart B) Method that unconditionally throws; Ones that 'throw new Error' are probable stubs. Sometimes there are methods which legitimately do nothing else; but those tend to throw something more specific. Tom
