You can subscribe to this list here.
2002 |
Jan
(17) |
Feb
(80) |
Mar
(56) |
Apr
(79) |
May
(9) |
Jun
(60) |
Jul
(29) |
Aug
(40) |
Sep
(23) |
Oct
(6) |
Nov
(25) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(17) |
Feb
(85) |
Mar
(22) |
Apr
(3) |
May
(18) |
Jun
(27) |
Jul
(38) |
Aug
(19) |
Sep
(15) |
Oct
(6) |
Nov
(2) |
Dec
(5) |
2004 |
Jan
(19) |
Feb
(26) |
Mar
(30) |
Apr
(29) |
May
(8) |
Jun
(28) |
Jul
(39) |
Aug
(17) |
Sep
(19) |
Oct
(12) |
Nov
(18) |
Dec
(9) |
2005 |
Jan
(5) |
Feb
(18) |
Mar
(4) |
Apr
(5) |
May
(9) |
Jun
(10) |
Jul
(15) |
Aug
(11) |
Sep
(6) |
Oct
(6) |
Nov
(11) |
Dec
(6) |
2006 |
Jan
(10) |
Feb
(27) |
Mar
(24) |
Apr
(39) |
May
(14) |
Jun
(14) |
Jul
(5) |
Aug
(15) |
Sep
(21) |
Oct
(25) |
Nov
(10) |
Dec
(6) |
2007 |
Jan
(19) |
Feb
(23) |
Mar
(10) |
Apr
(10) |
May
(10) |
Jun
(9) |
Jul
(8) |
Aug
(6) |
Sep
(10) |
Oct
(7) |
Nov
(4) |
Dec
(5) |
2008 |
Jan
(23) |
Feb
(13) |
Mar
(19) |
Apr
(11) |
May
(11) |
Jun
(10) |
Jul
(12) |
Aug
(19) |
Sep
(11) |
Oct
(4) |
Nov
(6) |
Dec
|
2009 |
Jan
(8) |
Feb
(15) |
Mar
(21) |
Apr
(12) |
May
(14) |
Jun
(9) |
Jul
(2) |
Aug
(17) |
Sep
(36) |
Oct
(31) |
Nov
(13) |
Dec
(13) |
2010 |
Jan
(24) |
Feb
(17) |
Mar
(32) |
Apr
(18) |
May
(9) |
Jun
(6) |
Jul
(11) |
Aug
(18) |
Sep
(7) |
Oct
(20) |
Nov
(5) |
Dec
(4) |
2011 |
Jan
(1) |
Feb
(5) |
Mar
(3) |
Apr
(1) |
May
(2) |
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(7) |
Oct
(1) |
Nov
(3) |
Dec
(1) |
2012 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(3) |
Dec
|
2013 |
Jan
(1) |
Feb
(3) |
Mar
(1) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2003-02-09 09:09:58
|
Bugs item #683322, was opened at 2003-02-09 03:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=683322&group_id=44253 Category: User interface Group: Annoying Status: Open Resolution: None Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: "Save As..." Lingering Filenames Initial Comment: Story: A user executes the "Save As..." command to save a new copy of an open file. He then does the same thing with another file. The dialog still displays the filename used by the previous save command. Note: The "Save As..." command should always populate the filename and directory for the dialog with the path of the current document. If the current document has never been saved, the path should be the same as the last command (or the working directory set in the user's config, if none has occurred yet), and the filename should be blank. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=683322&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-09 08:59:05
|
Bugs item #683320, was opened at 2003-02-09 03:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=683320&group_id=44253 Category: User interface Group: Could cause data loss Status: Open Resolution: None Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Canceling Save During Quit Initial Comment: Story: A user has a new, never-saved document open in DrJava. He attempts to Quit and is prompted whether he wants to save the file. He clicks the "Yes" button, and a "Save As..." dialog is displayed. He decides to cancel the dialog, perhaps because he cannot remember the name of the class and wants to find it in the document. Rather than cancelling the Quit process and returning him to DrJava, this instead cancels only the save dialog. DrJava quits, taking his open, unsaved document with it. The user commences cursing DrJava and its developers for causing him to lose data. . . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=683320&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-09 07:58:58
|
Feature Requests item #683307, was opened at 2003-02-09 02:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=683307&group_id=44253 Category: User interface Group: Small (< 1 pair-week) Status: Open Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: More Keyboard Shortcuts Initial Comment: Many commands in the DrJava menus do not have shortcuts and cannot be configured to have them. All command should be able to have manually-configured shortcuts, even if they don't have any by default. I've listed some suggestions for defaults for some commands, organized by menu. I've used the Mac convention of cmd and opt - other platforms would use ctrl and alt instead. Save All: cmd-opt-S Close All: cmd-opt-W Redo: cmd-shift-Z (instead of cmd-R) Preferences: cmd-; Test Using JUnit: cmd-T Reset Interactions: cmd-R Help: help ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=683307&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-09 07:20:08
|
Feature Requests item #683300, was opened at 2003-02-09 01:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=683300&group_id=44253 Category: User interface Group: Medium (< 1 pair-month) Status: Open Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Multiple Shortcuts for a Single Command Initial Comment: Story: A DrJava user spends some time using both UNIX-based editors (e.g. emacs) and Windows- or Mac-based editors. In order to smooth the transitions between various platforms, the user wishes to support both emacs-style shortcuts and Windows-style shortcuts simultaneously. He goes to the key mapping settings in the Preferences dialog of DrJava and adds custom key mappings for all of his favorite emacs shortcuts, leaving the current Windows-like shortcuts intact. Note: This will require support throughout the config framework as well as the UI setup code. Currently, there is no support for storing multiple instances of the same config option or for installing multiple listeners with different shortcuts for a single command. Adding this support may require significant refactoring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=683300&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-09 06:43:29
|
Feature Requests item #683291, was opened at 2003-02-09 00:50 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=683291&group_id=44253 Category: Other Group: Medium (< 1 pair-month) Status: Open Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Infer Tests From Documents Initial Comment: Story: A user is editing a class named e.g. "MyClass". After making a change to the file, he wishes to verify his code with a pre-existing JUnit test case, which is not currently open for editing. When he hits the "Test" button on the toolbar, DrJava searches the classpath for a class named "MyClassTest" and executes it using the built-in JUnit support, displaying progress and results in the JUnit tab. Note: Ideally the inference algorithm would properly locate test cases which are inner classes of the current class, if any exist, and also run them as tests. This might require batching the test cases a la the "Test All" command mentioned in a previous feature request. Like that request, this one was suggested by Dr. Cartwright. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=683291&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-09 06:36:29
|
Feature Requests item #683288, was opened at 2003-02-09 00:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=683288&group_id=44253 Category: Other Group: Small (< 1 pair-week) Status: Open Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: "Test All" Command Initial Comment: Story: A user is working within a large project (e.g. DrJava), which has many JUnit test classes in many separate files. After performing a refactoring, she wants to execute a series of tests to verify her changes. She opens the source files for all of the tests she wishes to execute, then hits the "Test All" button on the toolbar to run them all at once within the JUnit framework. Progress and results of the tests are displayed in the JUnit tab. Notes: This might be implemented by constructing a temporary test suite class which contains all of the open test cases. This feature was originally suggested by Dr. Cartwright. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=683288&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-09 06:25:52
|
Ease of use Issues item #683286, was opened at 2003-02-09 00:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=460211&aid=683286&group_id=44253 Category: Platform Independent Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Contextual Menus Everywhere Initial Comment: DrJava is currently inconsistent in its use of contextual menus. They appear in the definitions pane, the JUnit pane, and perhaps other places, but they are missing from the document pane and most other locations. DrJava should provide feedback for an attempt to bring up a context menu in all circumstances, even if it only builds a completely disabled menu. Ideally, it should have something useful to offer in all locations. This would increase user confidence that there is consistent support for this feature, and will encourage users to use them throughout the application. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=460211&aid=683286&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-09 03:36:55
|
Bugs item #683246, was opened at 2003-02-08 19:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=683246&group_id=44253 Category: Other Group: Could cause data loss Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: wrong value returned from a large numbers being modded Initial Comment: A very large number (such as 5^23) modulus, say 7, returns the wrong value of 2.0. The correct is 3.0 I'm using JRE 1.4.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=683246&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-07 22:39:36
|
Feature Requests item #682610, was opened at 2003-02-07 22:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=682610&group_id=44253 Category: Other Group: Small (< 1 pair-week) Status: Open Priority: 6 Submitted By: Charles Reis (csreis) Assigned to: Charles Reis (csreis) Summary: Improve tools.jar-finding heuristic on Windows Initial Comment: Story: The user starts DrJava for the first time on a Windows machine with a standard installation of the Java SDK. DrJava finds tools.jar without prompting the user. Implementation: Currently, the first time DrJava is used on *most* Windows machines, the user is forced to specify the location of tools.jar, even though we make a guess as to its location. This is because JAVA_HOME is set to the JRE in the "Program Files" directory, rather than the SDK in the root directory (by default). There's no fool proof way to find the SDK if the user installed it somewhere else (short of a full hard drive search), but we can do a better job of finding it in the default location, which should work for 90% of our users. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=682610&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-07 22:35:25
|
Feature Requests item #682606, was opened at 2003-02-07 22:42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=682606&group_id=44253 Category: Compiler integration Group: Small (< 1 pair-week) Status: Open Priority: 6 Submitted By: Charles Reis (csreis) Assigned to: Charles Reis (csreis) Summary: Make JSR-14 work on OS X Initial Comment: Story: User specifies the location of the JSR-14 jar in the Preferences window on OS X, and he is then able to use it as a valid compiler. Implementation: Currently, OS X puts its own compiler on the classpath before JSR-14, so we can't use JSR-14 unless the user starts DrJava with the "-Xbootclasspath/p:" option. By the same logic as Feature Request 682602, we can simply do this automatically by restarting with that argument if we were started without it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=682606&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-07 22:32:17
|
Feature Requests item #682602, was opened at 2003-02-07 22:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=682602&group_id=44253 Category: Other Group: Small (< 1 pair-week) Status: Open Priority: 7 Submitted By: Charles Reis (csreis) Assigned to: Charles Reis (csreis) Summary: Always make debugger available Initial Comment: Story: User starts DrJava on any platform. If DrJava cannot automatically find tools.jar with an educated guess, it prompts the user to specify the location. The user enters the location of tools.jar, and DrJava starts up with both a compiler and the debugger. Implementation: The trick is to get tools.jar onto the system classpath so that the JPDA debugging classes are accessible. Of course, we have a framework for starting a new JVM, so Eric realized we can just restart with tools.jar on the classpath if it isn't already. Thus, the debugger should always be available. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=682602&group_id=44253 |
From: Peter C. <cen...@ri...> - 2003-02-07 20:55:19
|
> Was there something specific in DrJava's code you were referring to? I didn't have anything in particular in mind. I thought this particular technique might make our existence checks clear when reading the code. Reading through the javadoc, I see that we'd have to do just as many exception checks with this code as with any other method, so there may not be much advantage afterall. -- Peter |
From: Peter C. <cen...@ri...> - 2003-02-07 20:45:09
|
I took this off of the java-seed mailing list at Apple, which is dedicated to discussion of the new Apple Java releases. This sounds like an excellent library to use for supporting Mac-specific features. I will investigate further. The license is the following: You are free to use, modify and redistribute this software as you wish for your own purposes, in either personal or commercial software applications, without restrictions. Accordingly, this software comes with no guarantee whatsoever and you are fully responsible for any problems that might arise from its usage. However, I will do my best to fix any problem reported to me. Finally, if you were to redistribute this software, in part or in whole, you must include proper credits. In my non-expert opinion, this might conflict with the GPL because of it lacks the restrictions of the GPL. I will ask the author if he will allow us to release it under GPL. -- Peter Begin forwarded message: > February 7, 2003 > By Steve Roy <sr...@ma...> > http://homepage.mac.com/sroy > > MRJ Adapter is a library that assists in implementing Mac OS and Mac > OS X > integration in your Java application by providing a unified API to the > different > mechanisms used by different platforms to handle menu items provided > by the OS > as well as some interapplication messages. In a broader sense, MRJ > Adapter is an > API for managing the About, Preferences and Quit menu items in your > application > in a way that will work with all platforms and that ensures that your > app > doesn't look like a second class citizen on the Mac. > > The main features of MRJ Adapter are the following. > > - About, Preferences and Quit menu items are implemented as normal menu > components on all platforms. > > - Supports both AWT and Swing. > > - Encapsulates the smarts to find out whether the About, Preferences > or Quit > menu item is automatically present or not on the current platform. > > - Enables and uses the Preferences item in the Application menu with > MRJ 3.1 and > 3.2 on Mac OS X, which is something those two VMs didn't directly > support. Many > thanks to Eric Albert for this. > > - Provides an easy, Java-like way to handle the four required Apple > events on > Mac OS and Mac OS X, namely Open Application, Open Document, Print > Document and > Quit Application. > > - Supports Java 1.1 and up. > > - Supports the latest 1.4.1 VM from Apple. > > - If you link with MRJAdapter.jar, there is no need for stubs of any > kind. It > will just work. > > - A set of stubs is provided for compiling the library on platforms > other than > the Mac. This is just for compiling, and the stubs don't need to be > included in > the resulting JAR file. > > This is a prerelease version. At this point, I'm making it available > online to > get comments as well as some testing mileage out of the community. > Since MRJ > Adapter contains information relative to the 1.4.1 VM, which is still > under NDA, > I have put MRJ Adapter onto my .Mac site in a passworded area, and I'm > only > letting people on this private list know the password. -- Peter |
From: SourceForge.net <no...@so...> - 2003-02-07 07:50:38
|
Feature Requests item #682171, was opened at 2003-02-07 01:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=682171&group_id=44253 Category: Definitions (source editor) Group: Small (< 1 pair-week) Status: Open Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Bookmarks Initial Comment: Story: A user is performing a refactoring task (or adding a feature) which has implications for several different locations within various documents. While editing in one location, the user decides to move to another location to verify something. Before moving, he sets a bookmark point on the current line. He then navigates to the other point and performs his secondary task. When it is done, he hits a key combination to return him to the bookmark, restoring his window and cursor positions and switching documents if necessary. This feature should allow multiple bookmarks to be set and navigated via "previous" and "next" shortcuts. My hunch is that the order of traversal should be the creation order, but this could be debated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438938&aid=682171&group_id=44253 |
From: Charles R. <cr...@ri...> - 2003-02-07 04:43:43
|
Well, that is sort of how we handle it. We don't base our decisions for the compiler and debugger on the presence of tools.jar in the preferences, but rather on whether the classes load successfully, either through classloading methods or direct instantiation. We're always careful either way about ClassNotFoundExceptions and NoClassDefFoundErrors, in any event. Was there something specific in DrJava's code you were referring to? Charlie Peter Centgraf wrote: > This was just posted to the java-seed list at Apple: > >> Programs should not assume that certain classes are always and only >> available when certain JARs or filenames are present. Instead, programs >> should probe for the necessary class using Class.forName() > > > He's got a good point here. This might be a better way of checking for > debuggers, compilers, junit, and other such optional DrJava add-ons. > > -- > Peter > |
From: Peter C. <cen...@ri...> - 2003-02-07 04:26:33
|
This was just posted to the java-seed list at Apple: > Programs should not assume that certain classes are always and only > available when certain JARs or filenames are present. Instead, > programs > should probe for the necessary class using Class.forName() He's got a good point here. This might be a better way of checking for debuggers, compilers, junit, and other such optional DrJava add-ons. -- Peter |
From: Charles R. <cr...@ri...> - 2003-02-06 18:03:54
|
Ok, it's fixed now. Kind of subtle, actually-- we used to use an InteractionsEditorKit in the InteractionsPane, which would ensure that all documents created in the pane were our InteractionsDocuments. The refactoring changed the contract a bit so that the kit had to be "installed" after the pane was created. Well, apparently an undocumented side-effect of installing an EditorKit is that a new document is immediately created. Thus, the InteractionsPane was displaying a different document than the one the model was using, so nothing that was entered by the user was being sent to the interpreter. Here's a good reason to avoid side-effects in your methods! (And be aware of them in the core Java libraries.) Anyway, I added a test to cover this scenario, and the InteractionsEditorKit isn't currently being used. (To tell the truth, I don't see it's usefulness, since there's only ever one document per InteractionsPane anway.) Charlie On Thu, 6 Feb 2003, Charles Reis wrote: > Hey guys-- > I appear to have inserted a pretty massive bug into the Interactions > Pane yesterday as part of my refactoring effort. If you hit Enter, it > appears to lock up. I'm amazed neither I nor the unit tests caught it > before I committed, but I'll write a test to display it and fix it ASAP. > (I'm on my way to get my oil changed at the moment, but I should have it > fixed by noon or so.) > > Sorry about that, > Charlie > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > drjava-hackers mailing list > drj...@li... > https://lists.sourceforge.net/lists/listinfo/drjava-hackers > |
From: SourceForge.net <no...@so...> - 2003-02-06 17:51:15
|
Ease of use Issues item #681808, was opened at 2003-02-06 11:57 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=460211&aid=681808&group_id=44253 Category: Platform Independent Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: State Everlasting Initial Comment: There are a lot of aspects of DrJava that the user can modify during a session, but which are not maintained across sessions. Many of these things can and should be preserved transparently through the config framework. I would like to begin tabulating a list of such states, so that they can be gradually implemented as config options. When posting an idea, it would be helpful to include some comments about potential problems in restoring the state which would need to be checked when doing so. My initial list: Interactions history -- the current buffer of recent actions could be spooled to a file, or written out as a big-ass String in the .drjava. This would allow someone to resume their testing after a crash, for example. Semantics might be difficult to define when multiple copies of DrJava are being run simultaneously, but the problem isn't unique to this feature. The current locations of windows and split panes -- these could easily be restored based on the last known coordinates. There is currently a bug which causes the split panes to revert to their default positioning, which could be fixed when adding this feature. We should check whether the main window has somehow gotten off-screen and correct it. Most recent compiler -- restore the previous selection in the Compiler Output tab. Might revert to the first one (as now) if the previous compiler is no longer available. Open documents -- restore the last known set of open documents when DrJava was quit. This may be too ambitious, but it is often handy. There are lots of potential problems with moved and renamed files, but most can be avoided by just failing to load the document in question. We might be able to restore the last visible portion of the document as well. Debugger state -- breakpoints and watches are lost when the interactions pane is reset. Just restoring the debug mode at all after a reset would be a step in the right direction. Find/Replace -- contents of the search fields and the Match Case toggle could be saved and restored. That's all I can think of for now. Please post more as you encounter them. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=460211&aid=681808&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-06 17:32:54
|
Bugs item #681800, was opened at 2003-02-06 11:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681800&group_id=44253 Category: Definitions (source editor) Group: Ugly Status: Open Resolution: None Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Line Numbers Lag When Scrolling Initial Comment: When scrolling through a document with Line Number Enumeration turned on, the numbers seem to lag behind the main document. The scrolling process is disorienting, because the numbers and the text are continually shifting relative to each other. This behavior is especially dramatic on Mac OS X, where the redraw speed isn't so hot. I estimate a half-second delay between moving the body and moving the line numbers. This happens in the Metal LAF as well as under Aqua. The problem also exists on Solaris over X11, but isn't as bad. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681800&group_id=44253 |
From: Peter C. <cen...@ri...> - 2003-02-06 15:31:05
|
Hey folks, You may have seen me turning up some bugs and inconsistencies in DrJava lately, and you may be wondering how I found them. Answer: When I'm using DrJava, I often encounter situations where I think, "Gee, no reasonable person would ever decide to do X right now." And then I do it. Basically, if there's no reason an average user would want to do it, it's likely that the developers never thought to test it. So please, do your best to break things. Especially the things you are currently working on. Resize the window really small and see what it does. Try to cause an exception while the main window is minimized. Click on lots of things while DrJava is in the middle of some slow, annoying operation. Turn your keyboard mapping to Japanese. This is how bugs are found. I'll get off the soapbox now. Thanks for listening. -- Peter |
From: SourceForge.net <no...@so...> - 2003-02-06 15:12:27
|
Bugs item #681712, was opened at 2003-02-06 09:18 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681712&group_id=44253 Category: UI: MacOS X-specific Group: Annoying Status: Open Resolution: None Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Selection Lost With Ctrl-Click on OS X Initial Comment: On OS X, select a bunch of text in the definitions window. Use a multi-button mouse to right-click and bring up the context menu. The selection is preserved. Now try using a Ctrl-click for the same action. This time, the selection is removed. In fact, you can create a new selection even while the context menu is being displayed. I don't know yet if this is an OS bug or if it belongs to us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681712&group_id=44253 |
From: Charles R. <cr...@ri...> - 2003-02-06 15:08:34
|
Hey guys-- I appear to have inserted a pretty massive bug into the Interactions Pane yesterday as part of my refactoring effort. If you hit Enter, it appears to lock up. I'm amazed neither I nor the unit tests caught it before I committed, but I'll write a test to display it and fix it ASAP. (I'm on my way to get my oil changed at the moment, but I should have it fixed by noon or so.) Sorry about that, Charlie |
From: SourceForge.net <no...@so...> - 2003-02-06 09:23:06
|
Bugs item #681552, was opened at 2003-02-06 03:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681552&group_id=44253 Category: Interactions Group: Makes DrJ unstable Status: Open Resolution: None Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Fun With Killing Interactions Initial Comment: Launch DrJava. Select the "> " on the first line of the Interactions pane. hit Delete. Notice that nothing happened. Now put the cursor back where it belongs and hit Enter. Visit the Console tab to see: java.lang.IllegalArgumentException: bad position: 22 at javax.swing.text.JTextComponent.setCaretPosition(JTextComponent.java:1120) at edu.rice.cs.drjava.ui.InteractionsPane$CaretUpdateListener.insertUpdate(InteractionsPane.java:74) at javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:175) at javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:537) at edu.rice.cs.drjava.model.repl.AbstractInteractionsDocument.insertString(AbstractInteractionsDocument.java:176) at edu.rice.cs.drjava.model.DefaultGlobalModel._docAppend(DefaultGlobalModel.java:916) at edu.rice.cs.drjava.model.DefaultGlobalModel.interpretCurrentInteraction(DefaultGlobalModel.java:783) at edu.rice.cs.drjava.model.repl.DefaultInteractionsDocument.interpretCurrentInteraction(DefaultInteractionsDocument.java:68) at edu.rice.cs.drjava.ui.InteractionsPane$2.construct(InteractionsPane.java:95) at edu.rice.cs.util.swing.SwingWorker$2.run(SwingWorker.java:150) at java.lang.Thread.run(Thread.java:491) The Interactions JVM is now dead. If you try to reset it, it will prevent you from quitting DrJava gracefully. (See my last bug report about comments in the interactions for an example.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681552&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-06 09:13:07
|
Bugs item #681547, was opened at 2003-02-06 03:19 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681547&group_id=44253 Category: Interactions Group: Makes DrJ unstable Status: Open Resolution: None Priority: 8 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Interactions and Comments Initial Comment: Type a comment into the interactions pane, like so: /* stuff and junk */ Hit enter. Nothing appears to happen, except that the cursor is now at position 4. Hit enter again -> position 6. Keep hitting enter until it tries to go to position > amount of text in the current interaction. Look in the Console tab for this message: ava.lang.IllegalArgumentException: bad position: 25 at javax.swing.text.JTextComponent.setCaretPosition(JTextComponent.java:1120) at edu.rice.cs.drjava.ui.InteractionsPane$CaretUpdateListener.insertUpdate(InteractionsPane.java:74) at javax.swing.text.AbstractDocument.fireInsertUpdate(AbstractDocument.java:175) at javax.swing.text.AbstractDocument.insertString(AbstractDocument.java:537) at edu.rice.cs.drjava.model.repl.AbstractInteractionsDocument.insertString(AbstractInteractionsDocument.java:176) at edu.rice.cs.drjava.model.DefaultGlobalModel._docAppend(DefaultGlobalModel.java:916) at edu.rice.cs.drjava.model.DefaultGlobalModel.interpretCurrentInteraction(DefaultGlobalModel.java:783) at edu.rice.cs.drjava.model.repl.DefaultInteractionsDocument.interpretCurrentInteraction(DefaultInteractionsDocument.java:68) at edu.rice.cs.drjava.ui.InteractionsPane$2.construct(InteractionsPane.java:95) at edu.rice.cs.util.swing.SwingWorker$2.run(SwingWorker.java:150) at java.lang.Thread.run(Thread.java:491) Reset the interactions pane. Try to quit DrJava. Get this message: java.lang.IllegalStateException: tried to quit when no slave running and startup not in progress at edu.rice.cs.util.newjvm.AbstractMasterJVM.quitSlave(AbstractMasterJVM.java:254) at edu.rice.cs.drjava.model.repl.newjvm.MainJVM.killInterpreter(MainJVM.java:291) at edu.rice.cs.drjava.model.DefaultGlobalModel.resetInteractions(DefaultGlobalModel.java:731) at edu.rice.cs.drjava.ui.MainFrame$29.construct(MainFrame.java:528) at edu.rice.cs.util.swing.SwingWorker$2.run(SwingWorker.java:150) at java.lang.Thread.run(Thread.java:491) Weep. It also occurs with "//" comments. I can reproduce the problem very quickly with just "//" + Enter + Enter. Maybe it happens with anything that DynamicJava thinks is an empty statement. The error on quit is probably a side effect of the JVM throwing an exception and the Interactions pane dying ungracefully. In case you didn't notice, THIS IS REALLY BAD! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681547&group_id=44253 |
From: SourceForge.net <no...@so...> - 2003-02-06 08:53:48
|
Bugs item #681544, was opened at 2003-02-06 02:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681544&group_id=44253 Category: Compiler integration Group: Annoying Status: Open Resolution: None Priority: 5 Submitted By: Peter Centgraf (centgraf) Assigned to: Nobody/Anonymous (nobody) Summary: Compile All with (Untitled) Initial Comment: Open DrJava. Hit the Compile All button. Result: 1 error found: Error: java.lang.NullPointerException(no associated file) Yet another reason why a new document is NOT THE SAME as an already-saved document! A fix for the already-reported saving-new-documents bug should also fix this automatically. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=438935&aid=681544&group_id=44253 |