You can subscribe to this list here.
2003 |
Jan
|
Feb
(11) |
Mar
(37) |
Apr
(29) |
May
(5) |
Jun
(2) |
Jul
(3) |
Aug
(12) |
Sep
(20) |
Oct
(4) |
Nov
(50) |
Dec
(11) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(43) |
Feb
(29) |
Mar
(22) |
Apr
(34) |
May
(24) |
Jun
(7) |
Jul
(8) |
Aug
(30) |
Sep
(15) |
Oct
(17) |
Nov
(21) |
Dec
(19) |
2005 |
Jan
(5) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(10) |
Jul
(2) |
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(9) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2007 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
|
May
(5) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(23) |
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(15) |
Jun
(3) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
(17) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(10) |
2012 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
(6) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Fnord P. <fn...@ev...> - 2003-03-25 21:36:23
|
On Tue, 2003-03-25 at 00:08, Zach DelProposto wrote: > > WebStart support, which had been considered before, probably should be > considered again. The tricky thing is the concept of 'plugins' (variant > plugins). VariantManager loads the plugins using a URLClassLoader. It > could be webstart-aware and load the variants. However, there is no way > (as far as I can tell) for a webstart app to 'discover' the jar files that > are associated with it. So a seperate file that describes which available > plugin .jar files are available would have to be sent, and VariantManager > would have to read this file to load Variants with webstart. > > Comments? Thoughts? Have you looked at: http://rachel.sourceforge.net/index.html -Joe |
From: Zach D. <zs...@um...> - 2003-03-25 05:08:59
|
WebStart support, which had been considered before, probably should be considered again. The tricky thing is the concept of 'plugins' (variant plugins). VariantManager loads the plugins using a URLClassLoader. It could be webstart-aware and load the variants. However, there is no way (as far as I can tell) for a webstart app to 'discover' the jar files that are associated with it. So a seperate file that describes which available plugin .jar files are available would have to be sent, and VariantManager would have to read this file to load Variants with webstart. Comments? Thoughts? Zach |
From: Zach D. <zs...@um...> - 2003-03-25 05:02:40
|
> I tested the DND a bit more, and made the following changes locally: > > - I added some cursors so that when you start dragging an army or fleet, > you get a little greyed-out-army/fleet cursor with pointer, that gets a > red circle through it when the target province is invalid. It looks > good. :) > - Fixed a NPE caused when dragging from a province with no unit > - Cleaned up some if conditions (also making sure the braces style was > consistant with the rest of the code) > - Used the guiOrderFactory (note this required an explicit cast to > GUIMove). > - Change the cursor on mouseDown instead of mouseOut. This has the > effect that the regular two-click move will change the cursor also but > this actually feels more intuitive. > > Everything now seems fine on the dragging front for what it's worth. nice changes! My time has been limited as of late, so I have not tested your changes yet. Time constraints should improve soon (week or so). > Do you want to test personally before I checkin? I plan to try one more > tweak, making a right button drag default to Support (left being Move), > but I don't want to get my sources to far off the beaten path. (Clicking > center MB for hold is doable also). > Tweak it, and then merge it into CVS. I don't mind people checking stuff into CVS, as long as they really try not to break anything. If something is broken, post a message here! > I wondered if separate code to render "drag in progress tentative order" > would be needed but the current way works just fine, so that would be > extra complication for nothing. Excellent > > By the way, there seems to be a fair bit of import optimizing that could > be done, is that something you care about? Some files have been optimized, since I downloaded a plugin to do that for jEdit. However, some have not been. Some are not because for testing purposes it's occasionally easier to just include a .* and then optimize it later. I think it's better when they are optimized (makes it more clear for other developers). I've been trying to optimize more classes as I make changes. Feel free to optimize the imports, but I'm not particular about it. Zach |
From: Colin J. <co...@co...> - 2003-03-25 03:06:59
|
Hi guys. I tested the DND a bit more, and made the following changes locally: - I added some cursors so that when you start dragging an army or fleet, you get a little greyed-out-army/fleet cursor with pointer, that gets a red circle through it when the target province is invalid. It looks good. :) - Fixed a NPE caused when dragging from a province with no unit - Cleaned up some if conditions (also making sure the braces style was consistant with the rest of the code) - Used the guiOrderFactory (note this required an explicit cast to GUIMove). - Change the cursor on mouseDown instead of mouseOut. This has the effect that the regular two-click move will change the cursor also but this actually feels more intuitive. Everything now seems fine on the dragging front for what it's worth. > you should have CVS access now. Do you want to test personally before I checkin? I plan to try one more tweak, making a right button drag default to Support (left being Move), but I don't want to get my sources to far off the beaten path. (Clicking center MB for hold is doable also). > I'm not sure what you mean by 'needing another SVG layer' yet. But I > shall see soonafter I test these changes. I wondered if separate code to render "drag in progress tentative order" would be needed but the current way works just fine, so that would be extra complication for nothing. By the way, there seems to be a fair bit of import optimizing that could be done, is that something you care about? Colin |
From: Zach D. <zs...@um...> - 2003-03-23 22:33:24
|
Just a random thought. Email turn submission should be in a format such that would (or at least could) allow for submission of orders by jdip via email or in 'plain text' email (perhaps by specifying a username, password, and/or game name; somewhat similar to Judge commands). |
From: Mike R. <Mik...@gm...> - 2003-03-23 22:30:30
|
Hi all, Good to see a new name on the list, welcome! Zach: the unit tests generate, but a lot of getters and setters fail (which is normal). Do you want me to fix these and check it all in, or do I have to wait ? At the moment I'll delete the gui package, as I don't believe in unit testing gui's, and besides, there are too many errors there, let's postpone that :). Too bad there is no source directory in cvs, would have been more consistent (source + testsource). Oh well, it'll do! Once they're in CVS unit tests can be added at leasure - I'll maybe install some code coverage tool to measure progress in that area. Let me know! Mike |
From: Zach D. <zs...@um...> - 2003-03-23 22:28:44
|
Colin Jacobs wrote: >So the first step in setting up a network game would be to create and >configure a PhaseTimer, and then to register a PhaseListener that >retrieves the orders at the appropriate time and handles the cases where >deadlines are missed, etc. > >Another useful interface might be OrderSource. The second step in >setting up a network game might be specifying an OrderSource. A good >first example might be a POP3OrderSource. In any case some general >network game code could just deal with PhaseEvents and OrderSources >(i.e. on a PhaseEvent, call OrderSource.getOrders() and proceed >accordingly), and we could add more and varied ways of transmitting >orders without having to alter that code. > > [code cut] This is a good concept. We may want to title 'ordersource' and 'ordersink' as InputSource and OutputSink (or something) because we may (?) want to transmit more than just orders; for example, there could be non-order data (perhaps setting a game parameter or something) that could be input. Alternatively, such commands, since they may not need to be set by a deadline, could be implemented in another fashion. I'm going to look at this soon. First, I'm going to look at JUnitDoclet, just to see it. Then, the drag-and-drop code. Then this. This should definately be in the 1.0 release; the current interface should be retrofitted to accomodate. This would also allow the F2F mode to implement timed deadlines. Zach |
From: Colin J. <co...@co...> - 2003-03-23 18:54:26
|
Zach, As you said, > Note that one thing that is not implemented yet is the concept of > deadlines. This will be required for better support of network (any type > of network) games. This is something to think about now, and start > embedding now, so it's available later, and fewer core changes need to > be made. Here's a suggestion for timed games/games with deadlines. Implement a PhaseTimer class with which we can register PhaseListeners (naturally an interface). The PhaseTimer can be configured to increment the phase based on a set time for each type of phase, to wait until a given specified time, or to wait indefinitely. Whenever the phase ticks over, it notifies its PhaseListeners of the new phase. In addition it keeps track of the time until the next deadline. So the first step in setting up a network game would be to create and configure a PhaseTimer, and then to register a PhaseListener that retrieves the orders at the appropriate time and handles the cases where deadlines are missed, etc. Another useful interface might be OrderSource. The second step in setting up a network game might be specifying an OrderSource. A good first example might be a POP3OrderSource. In any case some general network game code could just deal with PhaseEvents and OrderSources (i.e. on a PhaseEvent, call OrderSource.getOrders() and proceed accordingly), and we could add more and varied ways of transmitting orders without having to alter that code. I suppose this framework would also require an OrderSink, where the results, messages, etc. would go... I made some simple skeletons (appended below) for discussion. PhaseListener: public interface PhaseListener { public void PhaseChange(Phase p); } OderSource: public interface OrderSource { public Collection getOrders(); public Collection getOrders(Power p); } PhaseTimer: public class PhaseTimer { private Timer t; private PhaseObservable observable; private Phase phase; public PhaseTimer(Phase initialPhase/*, a map with phase timing/deadlines*/) { observable = new PhaseObservable(); t = new Timer(1000, observable); phase = initialPhase; } /** * Starts or restarts the timer. */ public void start() { } /** * Stops and resets the timer. */ public void stop() { } /** * Temporarily halts the timer. */ public void pause() { } /** * Skips to the end of the phase */ public void advance() { // increment phase // nofify listeners } /** * Sets/resets the phase */ public void setPhase(Phase p) { } /** * * @return The time remaining in the current phase in seconds. */ public long getTimeRemaining() { return 0; } /** * @param pl A PhaseListener to be notified of phase change events. */ public void addPhaseListener(PhaseListener pl) { observable.addObserver(new PhaseObserver(pl)); } /** * @return a Phase representing the current phase */ private Phase getCurrentPhase() { return phase; } // To hide the Observer/Observable implementation private class PhaseObservable extends Observable implements ActionListener { public void actionPerformed(ActionEvent e) { advance(); notifyObservers(getCurrentPhase()); } } private class PhaseObserver implements Observer { PhaseListener pl; public PhaseObserver(PhaseListener pl) { this.pl = pl; } public void update(Observable o, Object arg) { Phase p = (Phase)arg; pl.PhaseChange(p); } } } |
From: Zach D. <zs...@um...> - 2003-03-22 21:33:53
|
you should have CVS access now. Colin Jacobs wrote: >Here's a stab at DND. Please take a look at the code following the >comment "// Hacked-up way of painting the current order in drag mode" >and tell me a better way to do that (create a new layer on the >svgCanvas?). > > comments below >I've done the JavaMail stuff for a POP3 order importer also, BTW. > > wow nice. >Finally, I found a bug with the undo (several rapid undos would generate >the fatal error dialog) but I haven't found a way to reliably reproduce. > > I've seen one undo/redo fatal exception, but could never duplicate it. Are the stack traces at all useful? >> // Hacked-up way of painting the current order in drag mode >> if(inDrag) { >> if(!dragLoc.equals(loc)) { >> if(currentOrder instanceof GUIMove) { >> GUIMove tempOrder = guiOrderFactory.createGUIMove(); >> >> >> >tempOrder.deriveFrom(guiOrderFactory.createMove(currentOrder.getPower(), >dragLoc, > > >> currentOrder.getSourceUnitType(), loc, >> >> you can just do this: (note: not tested) GUIMove tempOrder = guiOrderFactory.createMove(... args ...) because the GUIOrderFactory will return GUIOrders for ALL methods. I'm not sure what you mean by 'needing another SVG layer' yet. But I shall see soonafter I test these changes. |
From: Zach D. <zs...@um...> - 2003-03-22 21:12:43
|
Colin Jacobs wrote: > As far as I can tell though the information (element id) is only there > in a org.w3c.dom.events.Event, but there's no way to take a > java.awt.event.*Event (containing an x,y etc) and get an element ID > from it. E.g. if I click on Galicia, how could you determine that in > XJSVGCanvasListener? How would you do the loop that you mentioned above? not sure, i'd have to investigate that. What we do now is: get an event, get the ID for that event, and then lookup the ID in a hashtable to get the Province associated for that event (actually, it's a Location object, becuase there may be coast-specific information). We do a two-level lookup (if no id, we look at the parent element) because a province could be encapsulated in a <g> element with nested subelements, although that check may no longer be nescessary (it used to be). [javamail stuff .. snipped] > > I'll have a look if you like, should be a doddle. Of course, more than just a polling is required, we need to specify some sort of communications format for the messages, too, and implement parsing! Certainly have a look, though. Note that one thing that is not implemented yet is the concept of deadlines. This will be required for better support of network (any type of network) games. This is something to think about now, and start embedding now, so it's available later, and fewer core changes need to be made. > > It's actually not too bad, when I looked closely, although on a sucky > machine (like I currently have at work), it takes quite a while to > parse the variant and set up the map. In any case optimization is > probably a 1.1 thing, once the features have stopped creeping. :) The map setup is the main time-consuming feature. dip.gui.map.DefaultMapRenderer is to blame. And friends, we do a lot of private-namespace parsing of the SVG file to extract needed info and then manipulate the DOM and setup a bunch of hashmaps to keep track of those changes. |
From: Colin J. <co...@co...> - 2003-03-22 08:10:10
|
Here's a stab at DND. Please take a look at the code following the comment "// Hacked-up way of painting the current order in drag mode" and tell me a better way to do that (create a new layer on the svgCanvas?). I pasted the patches below, but the sources are also available at http://coljac.net/jdip_dnd_src.zip. I still haven't done any cursor stuff, but I'll play with that. If its OK give me CVS access and I can check it in (when I've tested it some more). I've done the JavaMail stuff for a POP3 order importer also, BTW. Finally, I found a bug with the undo (several rapid undos would generate the fatal error dialog) but I haven't found a way to reliably reproduce. Colin Index: ViewControlBar.java =================================================================== RCS file: /cvsroot/jdip/jdip/dip/gui/map/ViewControlBar.java,v retrieving revision 1.8 diff -r1.8 ViewControlBar.java 120c120,129 < --- > > // Dragging stuff > public void mouseDown(Location loc) { > // Do nothing > } > > public void mouseUp(Location loc) { > // Do nothing > } > Index: ProvinceMouseListener.java =================================================================== RCS file: /cvsroot/jdip/jdip/dip/gui/map/ProvinceMouseListener.java,v retrieving revision 1.2 diff -r1.2 ProvinceMouseListener.java 98a99,106 > else if(type == SVGConstants.SVG_MOUSEDOWN_EVENT_TYPE) > { > mmc.mouseDown(location); > } > else if(type == SVGConstants.SVG_MOUSEUP_EVENT_TYPE) > { > mmc.mouseUp(location); > } Index: OrderControlBar.java =================================================================== RCS file: /cvsroot/jdip/jdip/dip/gui/map/OrderControlBar.java,v retrieving revision 1.10 diff -r1.10 OrderControlBar.java 39a40 > import dip.order.Move; 43a45 > import dip.gui.order.GUIMove; 119c121,124 < --- > // Dragging stuff > private Location dragLoc = null; > private boolean inDrag = false; > 163c168 < --- > 176a182,192 > // Hacked-up way of painting the current order in drag mode > if(inDrag) { > if(!dragLoc.equals(loc)) { > if(currentOrder instanceof GUIMove) { > GUIMove tempOrder = guiOrderFactory.createGUIMove(); > tempOrder.deriveFrom(guiOrderFactory.createMove(currentOrder.getPower(), dragLoc, > currentOrder.getSourceUnitType(), loc, ((GUIMove)currentOrder).isByConvoy())); > mapPanel.getOrderPanel().addOrder(tempOrder); > } > } > } 204c220,225 < --- > if(inDrag && loc!=null) { > if(loc.equals(dragLoc)) { > doOrder(loc); > } > } > 240a262,266 > inDrag = false; > doOrder(loc); > } > > public void doOrder(Location loc) { 284,285c310,327 < < --- > > // Dragging stuff > public void mouseDown(Location loc) { > if(loc!=null) > { > inDrag = true; > dragLoc = loc; > } > } > > public void mouseUp(Location loc) { > if(inDrag) { > doOrder(loc); > } > inDrag = false; > dragLoc = null; > } > Index: MouseModeController.java =================================================================== RCS file: /cvsroot/jdip/jdip/dip/gui/map/MouseModeController.java,v retrieving revision 1.2 diff -r1.2 MouseModeController.java 40a41,44 > // Dragging stuff > public void mouseDown(Location loc); > public void mouseUp(Location loc); > Index: DefaultMapRenderer.java =================================================================== RCS file: /cvsroot/jdip/jdip/dip/gui/map/DefaultMapRenderer.java,v retrieving revision 1.16 diff -r1.16 DefaultMapRenderer.java 208c208,212 < --- > > // Dragging stuff > doc.getRootElement().addEventListener(SVGConstants.SVG_MOUSEDOWN_EVENT_T YPE, mouseListener, true); > doc.getRootElement().addEventListener(SVGConstants.SVG_MOUSEUP_EVENT_TYP E, mouseListener, true); > 818c822 < --- > Index: AnimateControlBar.java =================================================================== RCS file: /cvsroot/jdip/jdip/dip/gui/map/AnimateControlBar.java,v retrieving revision 1.1 diff -r1.1 AnimateControlBar.java 141c141,150 < --- > > // Dragging stuff > public void mouseDown(Location loc) { > // Do nothing > } > > public void mouseUp(Location loc) { > // Do nothing > } > |
From: Colin J. <co...@co...> - 2003-03-22 02:12:28
|
Hi there. > Batik handles it's own events, as specified (?) in the DOM. So we have to > use those. We could use raw mouse events, but then we would have to loop > through elements to determine which one contains the point. Right, I got a clue and I see the way to go now. I've just about got drag and drop working using the EventListener (I'll add to ProvinceMouseListener). As far as I know there's no way to turn the captured raw drag and drop events of Swing (or the awt.dnd classes) into Dip "business" logic since I can't map a pixel on the svgPanel to a province. But that's OK because it can be done with the EventListener that Batik lets you register. > hmmm this is sort of what the ProvinceMOuseListener does and sends to the > ContorlBar classes. As far as I can tell though the information (element id) is only there in a org.w3c.dom.events.Event, but there's no way to take a java.awt.event.*Event (containing an x,y etc) and get an element ID from it. E.g. if I click on Galicia, how could you determine that in XJSVGCanvasListener? How would you do the loop that you mentioned above? One thing I haven't tried yet is detecting the difference between right and left MB using just the Batik (DOM event) stuff. Oops, nevermind, I see I can cast the Event down to a MouseEvent. >> Yes, the obvious simple way would be to poll a pop server and parse the >> body of all mails with "jdip" in the subject as orders. That would be >> pretty easy with JavaMail. > > This would be a nice thing to implement. I'll have a look if you like, should be a doddle. > Batik converts the xml -> DOM -> GVT tree -> Java2D. Manipulating the GVT > tree may be faster. But it is also more difficult. > > But please tests. I would like to know what is slow, and what we can > speed > up. And if you endeavor to speed up Batik, I'm sure the Batik developers > wouldn't mind :) It's actually not too bad, when I looked closely, although on a sucky machine (like I currently have at work), it takes quite a while to parse the variant and set up the map. In any case optimization is probably a 1.1 thing, once the features have stopped creeping. :) Colin |
From: Zach D. <zs...@um...> - 2003-03-21 20:24:54
|
> Either because I'm not familiar with Batik, or because I'm usually a > server-side guy, or because I'm dense, some aspects of the event handling > in jDip aren't quite intuitive to me. For example, having a JToolbar > implement a custom mouse event handler; the > org.w3c.dom.events.EventListener; The JSVGComponent.SVGListener also I > haven't quite figured out yet. However, I'm still going over the source (I > could only steal so much time at work :). Batik handles it's own events, as specified (?) in the DOM. So we have to use those. We could use raw mouse events, but then we would have to loop through elements to determine which one contains the point. And SVGListener, I think (offhand) that it converts swing events (e.g., mouse click/move) and sends them to, well, "the rest" of batik :-) > > This is probably a dumb question, but is there an easy way to get > information out of the (X)JSVGCanvas from a point (i.e. from an event)? > Naturally want I want is an Element/Location that can be used in > constructing orders. If this was easily done, then event handling could be > easily done with regular dnd and awt.event *Listener classes. hmmm this is sort of what the ProvinceMOuseListener does and sends to the ContorlBar classes. > > JavaMail could be used to make this easier (could find all messages > > destined for jdip on a user's account), or jdip could be a mail server > > (?). To do this correctly would require a good bit of thought as to how > > it would work. > > Yes, the obvious simple way would be to poll a pop server and parse the > body of all mails with "jdip" in the subject as orders. That would be > pretty easy with JavaMail. This would be a nice thing to implement. > Another instance of JDip on a different machine on the network I meant - so > this is really the same as the "networking" heading. Got it. > I'll try and be more specific, I'll run some tests at home. From memory it > was the response to the mouse clicks that seemed slow, as well as the > intial setup/render of the mapPanel. I have an Athlon 2.0GHz and 1GB RAM at > home and even so it was noticeable. I blame Batik also. XML-based > graphics... who ever heard of such a crazy thing? :) Damn XML! Yep, those are slow on my machine as well. Though sometimes orders are drawn pretty quickly. It varies. The speed is the only bad thing about Batik.... it's really flexible and does a nice job rendering though. Batik converts the xml -> DOM -> GVT tree -> Java2D. Manipulating the GVT tree may be faster. But it is also more difficult. But please tests. I would like to know what is slow, and what we can speed up. And if you endeavor to speed up Batik, I'm sure the Batik developers wouldn't mind :) Zach |
From: Colin J. <co...@co...> - 2003-03-21 02:42:29
|
Hi there. I've had some sort of luck so far with the drag-and-drop following the straight-forward approach of using java.awt.dnd.*. In other words, I performed the trivial task of making the svgCanvas function as both a drop source and drop target. However, I'm wondering if it might be easier to do it from scratch using the available mouseEvents. A couple of questions/obeservations: Either because I'm not familiar with Batik, or because I'm usually a server-side guy, or because I'm dense, some aspects of the event handling in jDip aren't quite intuitive to me. For example, having a JToolbar implement a custom mouse event handler; the org.w3c.dom.events.EventListener; The JSVGComponent.SVGListener also I haven't quite figured out yet. However, I'm still going over the source (I could only steal so much time at work :). This is probably a dumb question, but is there an easy way to get information out of the (X)JSVGCanvas from a point (i.e. from an event)? Naturally want I want is an Element/Location that can be used in constructing orders. If this was easily done, then event handling could be easily done with regular dnd and awt.event *Listener classes. > Actually, drag without the image could be implemented fairly easily. I > didn't know drag images couldn't be supported on window, as I really have > not implemented much drag and drop (other than system-level; if you drag > a ".jdip" file into jdip, it will open it). This could be added to the > feature list, then. Relevant code sections Drag images aren't supported by the OS (that particular OS), but I had a couple of ideas for making the drag look OK. One I have no clue how to do: Paint an arrow from the source to where the cursor is; the other I think is easy, when the user starts dragging an unit, change the cursor to a custom cursor that looks like a greyed-out unit. Ditto with a slash through it when they enter an illegal province. I imagine that would have the correct "picking up the object and moving it" feel. > I thought about adding SMTP support, but, would rather work on networking > support (for real-time games). But ideally both would be available. > JavaMail could be used to make this easier (could find all messages > destined for jdip on a user's account), or jdip could be a mail server > (?). To do this correctly would require a good bit of thought as to how > it would work. Yes, the obvious simple way would be to poll a pop server and parse the body of all mails with "jdip" in the subject as orders. That would be pretty easy with JavaMail. > > - Importing orders from another instance of JDip > > hmmmmm why? Or should this Another instance of JDip on a different machine on the network I meant - so this is really the same as the "networking" heading. > Which parts are sluggish? Updates? (like, after a turn?) if so, blame is > on batik. What system are you running? I'm on a 933/P3/using win xp and I'll try and be more specific, I'll run some tests at home. From memory it was the response to the mouse clicks that seemed slow, as well as the intial setup/render of the mapPanel. I have an Athlon 2.0GHz and 1GB RAM at home and even so it was noticeable. I blame Batik also. XML-based graphics... who ever heard of such a crazy thing? :) Colin |
From: Zach D. <zs...@um...> - 2003-03-20 03:18:58
|
> I'll get more familiar with the app as it stands in the CVS and see > what I can come up with with regard to drag and drop. I'm hampered by > a lack of familiarity with the batik API, but I'll let you know what I > come up with. I naively assumed that new code to manipulate the SVG > tree wouldn't be necessary, since the end result of a DnD operation > would be the same as the end result of a "click, click" in terms of > the visuals. Actually visually dragging the unit around could be > problematic (mostly because under Windows drag images aren't supported > under the AWT drag-and-drop API; on other platforms it might be a lot > easier). Actually, drag without the image could be implemented fairly easily. I didn't know drag images couldn't be supported on window, as I really have not implemented much drag and drop (other than system-level; if you drag a ".jdip" file into jdip, it will open it). This could be added to the feature list, then. Relevant code sections dip.gui.map.ProvinceMouseListener dip.gui.map.MouseModeController (implemented by all dip.gui.map.ControlBar and derivatives) ?? perhaps XJSVGCanvas classes note that: XJSVGCanvas is modified to ignore small drags (< 5 pixels) and interpret them as clicks. All other drags will be processed as drags. and that: all clicks [and mousein/mouseout] are looked up to see if they are in a province. Taking a quick glance at the code, I'm not sure how we differentiate provinces from units. This used to be a problem (clicks on a unit were not interpreted as clicks on the province) but no longer is, because I changed it so that wouldn't occur, but I'm not exactly sure how :-) probably need some debug statements in ProvinceMouseListener. ok I see how, in DefaultMapRenderer: doc.getRootElement().addEventListener(SVGConstants.SVG_EVENT_CLICK, mouseListener, true); the 'true' means to use 'capture'; all click events go to the mouseListener (which is an instance of ProvinceMouseListener) before being dispatched to any EventTargets beneath them. so some additional testing would probably need to be done, in ProvinceMouseListener, I assume.... > - Individual passwords so you can edit your power's orders and/or GM > password to enable editing of orders out of turn, etc. hmmmm yes, but this is probably going to be delayed until network support is added > > - A cheap-and-nasty clock panel that can be configured (diploming > time, order writing time, adjustment orders time, etc). good idea, for a FTF mode or network mode. I like it. > > - Order input > - Import from files (users could enter their orders as text on other > machines, jDip reads the files from somewhere) actually, the "multi-order-input' dialog should process orders very easily, and cut-and-paste > > - Import the orders from email (users all email their orders to jDip > [Did I see SMTP on another ToDo list?]) I thought about adding SMTP support, but, would rather work on networking support (for real-time games). But ideally both would be available. JavaMail could be used to make this easier (could find all messages destined for jdip on a user's account), or jdip could be a mail server (?). To do this correctly would require a good bit of thought as to how it would work. > - Importing orders from another instance of JDip hmmmmm why? Or should this > > BTW, I can't help but notice the app can be a tad sluggish, even for a > Swing app. Is it the batik classes that are using the cycles? Which parts are sluggish? Updates? (like, after a turn?) if so, blame is on batik. What system are you running? I'm on a 933/P3/using win xp and the map updates aren't horribly painful but it takes a second sometimes. I can't speed up Batik! We're still using Batik 1.5b4, and a new release (1.5b5) is due out soon, though I'm not certain if it will be faster. Startup is a bit lengthy though. That's why there's a splash screen! Distract the user with pretty colors. Important dialogs (partly file chooser, Help, and New Game) are cached during startup which really helps. If you feel that any dialogs are sluggish please let me know, because they can be optimized or pre-cached. |
From: Colin J. <co...@co...> - 2003-03-20 01:59:44
|
Hi there. Thanks for inviting me into the exclusive jdip developer community. :) > This would be nice, and some people do want this. Drag-and-Drop is mostly > a matter of manipulating Batik. I think it can be done, but I'm not sure ... I'll get more familiar with the app as it stands in the CVS and see what I can come up with with regard to drag and drop. I'm hampered by a lack of familiarity with the batik API, but I'll let you know what I come up with. I naively assumed that new code to manipulate the SVG tree wouldn't be necessary, since the end result of a DnD operation would be the same as the end result of a "click, click" in terms of the visuals. Actually visually dragging the unit around could be problematic (mostly because under Windows drag images aren't supported under the AWT drag-and-drop API; on other platforms it might be a lot easier). >> I'm thinking of using jDip to help host/adjudicate a F2F game. Do you > Yes, and you are not the only one to suggest this. I think we need an FTF > (F2F) mode. A couple of things would have to be modified, but it's > actually not that bad, and some thought has been given to this. Once a > user submits his orders, the orderpanel would go to the next power. Once > enabled, FTF mode could only be disabled after all players have submitted > orders and the turn was adjudicated. This seems like a pretty good idea as it's one of the obvious uses for jDip. Random suggestions: - Individual passwords so you can edit your power's orders and/or GM password to enable editing of orders out of turn, etc. - A cheap-and-nasty clock panel that can be configured (diploming time, order writing time, adjustment orders time, etc). - Order input - Import from files (users could enter their orders as text on other machines, jDip reads the files from somewhere) - Import the orders from email (users all email their orders to jDip [Did I see SMTP on another ToDo list?]) - Importing orders from another instance of JDip BTW, I can't help but notice the app can be a tad sluggish, even for a Swing app. Is it the batik classes that are using the cycles? Colin |
From: Zach D. <zs...@um...> - 2003-03-20 00:31:29
|
Mike Rosseel wrote: >ok, junitdoclet target and necessary libs have been checked in. Test it out, >but don't check in anything, I'd like to change a few things. But it already >generates a sh*tload of unit tests! Some of them don't compile, usually >because of constructor issues (easily fixed). But as I said, just check it >out, read the homepages of junit and junitdoclet (google it, I'm lazy :)) and >feel that warm unit testing glow inside ! > > I will check this out, probably on the weekend, so feel free to make plenty of changes >>JXTA and Order Drawing are the future... >>IT's fine... I think we may be the only 2 on the list though >> >> > >yeah...let's make a kick ass 1.0 soonish, so we have some developer inflow. >And indeed, jxta and fancy graphics are for later... > > Agreed! Let's make a list of what we need "for sure" before the 1.0 release. Some things for 1.0: In No Particular order ================== - XML save format using Castor - unit tests - class javadocs (most classes have some, but some have none!) - ?? Loeb9 rules [involving support modification; all other Loeb9 rules are OK] - Face-2-Face mode this includes "power locking" [restrict entry of orders to a given list of Powers] which will be needed for future network games too - ?? start (when nescessary) integrating http://www.jgoodies.com/articles/forms.pdf layout manager instead of HIGLayout? It offers some nice options - fix bug with imported histories and orders/units not matching up - complete Help html - ?? drag-and-drop support ?? if possible need to check on Batik mailing lists, look at example code and simple demos - docs docs docs -- especially developer docs add general project summary (from a developer's perspective) add file format docs to website add API docs (javadocs) to website [so anyone can browse them online] add translation docs / info (how or what to do) - better il18n of status and report pages - ?? jasper reports integration for stats/report pages? May be overkill and while i'm at it: remaining things for 0.91 version ====================== - OrderFormat plural bug - check GUI support for Wing units - wing unit icon for maps that have iconic units (in progress) - complete animation mode - complete 'influence' mode, and make sure lastOccupier is set correctly - status view to use current order format (as selected in preferences) - 'sup' for 'support' (if map permits) in order parser - move 'game and player info' to Reports menu - retest all DATC and other cases for validation |
From: Zach D. <zs...@um...> - 2003-03-20 00:31:13
|
Mike Rosseel wrote: >ok, junitdoclet target and necessary libs have been checked in. Test it out, >but don't check in anything, I'd like to change a few things. But it already >generates a sh*tload of unit tests! Some of them don't compile, usually >because of constructor issues (easily fixed). But as I said, just check it >out, read the homepages of junit and junitdoclet (google it, I'm lazy :)) and >feel that warm unit testing glow inside ! > > I will check this out, probably on the weekend, so feel free to make plenty of changes >>JXTA and Order Drawing are the future... >>IT's fine... I think we may be the only 2 on the list though >> >> > >yeah...let's make a kick ass 1.0 soonish, so we have some developer inflow. >And indeed, jxta and fancy graphics are for later... > > Agreed! Let's make a list of what we need "for sure" before the 1.0 release. Some things for 1.0: In No Particular order ================== - XML save format using Castor - unit tests - class javadocs (most classes have some, but some have none!) - ?? Loeb9 rules [involving support modification; all other Loeb9 rules are OK] - Face-2-Face mode this includes "power locking" [restrict entry of orders to a given list of Powers] which will be needed for future network games too - ?? start (when nescessary) integrating http://www.jgoodies.com/articles/forms.pdf layout manager instead of HIGLayout? It offers some nice options - fix bug with imported histories and orders/units not matching up - complete Help html - ?? drag-and-drop support ?? if possible need to check on Batik mailing lists, look at example code and simple demos - docs docs docs -- especially developer docs add general project summary (from a developer's perspective) add file format docs to website add API docs (javadocs) to website [so anyone can browse them online] add translation docs / info (how or what to do) - better il18n of status and report pages - ?? jasper reports integration for stats/report pages? May be overkill and while i'm at it: remaining things for 0.91 version ====================== - OrderFormat plural bug - check GUI support for Wing units - wing unit icon for maps that have iconic units (in progress) - complete animation mode - complete 'influence' mode, and make sure lastOccupier is set correctly - status view to use current order format (as selected in preferences) - 'sup' for 'support' (if map permits) in order parser - move 'game and player info' to Reports menu - retest all DATC and other cases for validation |
From: Zach D. <zs...@um...> - 2003-03-20 00:06:25
|
Colin wrote: >What's the story with the drag-and-drop support in this application? From a >quick look I see some DnD code in there but the user can't drag units around >the map. Am I missing something? (I'll try to go over the code, but you can >probably save me a little time...) That was the first thing I tried to do when >I ran the app, drag the units from one province to another. > > This would be nice, and some people do want this. Drag-and-Drop is mostly a matter of manipulating Batik. I think it can be done, but I'm not sure how, and how to do it best. Getting the point within the document, and the SVG element is pretty easy. But updating the document in real-time for a drag is likely to be slow (multiple DOM updates). To get around this, there are two solutions I can think of off hand: 1) copy the rendered element to a bitmap, and drag the bitmap around, only updating the DOM when the drag is complete 2) (probably better and easier) use the internal batik GVT tree to manipulate the drag, modifying the DOM when the drag is complete. If the GVT tree modification goes well, it may be a better way to make changes to the map than modifying the DOM (better in that it may be faster). This is an area which I think would be interesting to explore but have not had the time to do it. >I'm thinking of using jDip to help host/adjudicate a F2F game. Do you think >a useful feature would be some kind of secure mode to enter your orders, that >hides all the other powers' orders from you? (As far as I could tell, the OrderPanel >always displays all the orders, regardless of the MapPanel's order-display >status. > > Yes, and you are not the only one to suggest this. I think we need an FTF (F2F) mode. A couple of things would have to be modified, but it's actually not that bad, and some thought has been given to this. Once a user submits his orders, the orderpanel would go to the next power. Once enabled, FTF mode could only be disabled after all players have submitted orders and the turn was adjudicated. I think F2F mode should be in 0.92. If you (or anyone) would like to work on drag-and-drop, be my guest! It will not be an easy task, however. |
From: Zach D. <zs...@um...> - 2003-03-19 02:32:06
|
I think we need to keep a formal ToDo list. I keep a mishmash of ideas, but, do not update it to CVS or sourceforge. perhaps we should? Suggestions? |
From: Zach D. <zs...@um...> - 2003-03-14 04:08:57
|
Slight menu reorganization (some items from the View menu have move to a new menu, Reports). This keeps things which affect the View (the map) in one menu, and reports (which bring up new windows) in another. Also, a new mode, "animate" has been added. This allows turn-by-turn animation (slowly....). A new View option to be called "Influence" will also soon be added (it hasn't been yet) which will use the new lastOccupier field in the Position object to show a Civilization-like map of territories controlled over time. |
From: Zach D. <zs...@um...> - 2003-03-09 21:19:14
|
Tested on redhat 7.3, KDE 3, jdk 1.4.1.02, and everything was fine. |
From: Zach D. <zs...@um...> - 2003-03-09 21:05:46
|
new bug report filed: summary: 'no unit' or 'bad action' (circle with line through it) cursor is too large (like 1" !!) on linux. Are any other linux users experiencing this? I will test on linux here too. Bug summary: -------------- By the "no unit" cursor, I mean the red circle and slash that appears when entering an order but the cursor is not over a unit. On my Win95 box this cursor is small and easy to use. On my Linux box, this cursor is huge -- about a inch across -- bigger than many provinces. It has grainy appearance and it appears that each pixel in the original bitmap has been magnified many times. Entering orders etc still works -- its just hard to see underneath that cursor. |
From: Zach D. <zs...@um...> - 2003-02-23 22:10:41
|
things should now work again ... implicit DTDs are back |
From: Zach D. <zs...@um...> - 2003-02-23 20:35:22
|
Mike Rosseel wrote: >Hi, > > > >>The validation option has been removed from the preferences dialog. No >>XML validation is performed. This is in CVS. >> >> Well, I found the problem. Even when not validating, the DTD must be read to resolve any ENTITY references. I tried setting setEntityResolver() [in docbuilder] with an EntityResolver that empty OR returns a DTD (in the resource directory) however, the error still occurs. The last method (returning an InputSource to an entry in the resource/ dir) should work, but it does not. Why? Don't know. May have to revert back to the non-network DTD. |