Menu
▾
▴
rails-devel
|
From: Brett L. <wak...@ea...> - 2005-09-28 20:22:59
|
I've gotten ScrollBars on the Map window to work without drawing bugs. Here's the scoop on this badboy: For some reason that I haven't yet pinned down, HexMap is considered a HeavyWeight component. Most Swing objects (JPanel, JLabel, etc) are considered LightWeight components. So, when using JScrollPane with HexMap, the map hexes kept being drawn on top of the scroll bars. The reason being that HeavyWeight components are ALWAYS drawn on top of LightWeight components, regardless of Z-ordering. This has a bunch of legacy reasoning from back when Sun made the transition from AWT to Swing. This is why mixing lightweight and heavyweight components is not recommended. SO, the solution was to use AWT's ScrollPane rather than Swing's JScrollPane. ScrollPane is a heavyweight component because all of AWT's components are heavyweight components. Unfortunately, as you'll see if you examine MapWindow, this causes problems for MouseListeners. Swing objects will automatically pass events up to their parent objects. AWT objects won't. So, the MouseListener needs to be explicitly added to all levels of the hierarchy in order to function, as it is currently being done in MapWindow. For the future: If we can figure out how to make HexMap a lightweight component, I'd really like to do that. There are a lot of good things we gain if we can do it. For now, if you see any drawing weirdness with the MapWindow, this is the likely source. Be careful how you layer AWT and Swing objects. ---Brett. -----Original Message----- From: Brett Lentz <wak...@ea...> Sent: Sep 27, 2005 3:19 PM To: rai...@li... Subject: [Rails-devel] UI Updates I've just committed some UI reorganization and minor cleanups. Here's a rough list of what's changed: 1. We no longer draw every single window when a game starts. The StatusWindow opens, and if it's the beginning of a startRound, the StartRoundWindow opens. That's it. The Stock Market chart is only setVisible during stock rounds, and the Map is only setVisible during Operating Rounds. 2. I've added a series of drop-down menus to the Status Window. This includes an Options menu where you can open any of the other windows as you see fit. 3. I've added Mnemonics to all existing buttons, so now they can be accessed via ALT+key combinations if so desired. I'm still working on getting the MapWindow to correctly use ScrollBars. Hopefully that'll be working fairly soon. ---Brett. ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Brett L. <wak...@ea...> - 2005-09-28 22:53:48
|
Nope, we don't have this problem anywhere else. It's specifically HexMap that's the problem. Argh. I really gotta stop using Java 1.5 on my systems. I apologize for that. What do you mean by the tiles being clipped? ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Sep 28, 2005 2:08 PM To: rai...@li... Subject: RE: [Rails-devel] UI Updates Strange, we don't have this problem in the other windows, do we? Unfortunately, setPreferredSize() does not compile with Java 1.4, because JFrame and ScrollPane are not JComponents. I have outcommented these lines for now. I have wrestled with sizes in the other windows too, when I've more time I will have another look. Another thing to do is to better scale the map (now the tiles are clipped) and move it against the upper and left borders. Erik. > I've gotten ScrollBars on the Map window to work without drawing bugs. > > Here's the scoop on this badboy: > > For some reason that I haven't yet pinned down, HexMap is > considered a HeavyWeight component. Most Swing objects > (JPanel, JLabel, etc) are considered LightWeight components. > > So, when using JScrollPane with HexMap, the map hexes kept > being drawn on top of the scroll bars. > > The reason being that HeavyWeight components are ALWAYS drawn > on top of LightWeight components, regardless of Z-ordering. > This has a bunch of legacy reasoning from back when Sun made > the transition from AWT to Swing. > > This is why mixing lightweight and heavyweight components is > not recommended. > > SO, the solution was to use AWT's ScrollPane rather than > Swing's JScrollPane. ScrollPane is a heavyweight component > because all of AWT's components are heavyweight components. > > Unfortunately, as you'll see if you examine MapWindow, this > causes problems for MouseListeners. Swing objects will > automatically pass events up to their parent objects. AWT > objects won't. So, the MouseListener needs to be explicitly > added to all levels of the hierarchy in order to function, as > it is currently being done in MapWindow. > > For the future: If we can figure out how to make HexMap a > lightweight component, I'd really like to do that. There are > a lot of good things we gain if we can do it. > > For now, if you see any drawing weirdness with the MapWindow, > this is the likely source. Be careful how you layer AWT and > Swing objects. > > > ---Brett. > > > > -----Original Message----- > From: Brett Lentz <wak...@ea...> > Sent: Sep 27, 2005 3:19 PM > To: rai...@li... > Subject: [Rails-devel] UI Updates > > I've just committed some UI reorganization and minor cleanups. > > Here's a rough list of what's changed: > > 1. We no longer draw every single window when a game starts. > The StatusWindow opens, and if it's the beginning of a > startRound, the StartRoundWindow opens. That's it. > > The Stock Market chart is only setVisible during stock > rounds, and the Map is only setVisible during Operating Rounds. > > 2. I've added a series of drop-down menus to the Status > Window. This includes an Options menu where you can open any > of the other windows as you see fit. > > 3. I've added Mnemonics to all existing buttons, so now they > can be accessed via ALT+key combinations if so desired. > > > I'm still working on getting the MapWindow to correctly use > ScrollBars. Hopefully that'll be working fairly soon. > > ---Brett. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@hc...> - 2005-09-29 19:36:56
|
> Nope, we don't have this problem anywhere else. It's > specifically HexMap that's the problem. I had lots of problems to get scrolling right in the Log window. Now it is a JFrame containing a JPanel containing a JScrollPane (which contains the JLabel which contains all the text). Map Window is a JFrame containing a ScrollPane containing a JPanel (HexMap, which contains all the small JPanels representing tiles). I don't claim anything, I just wonder if adding a JPanel (as in LogWindow) would help (so we would get JFrame/JPanel/JScrollPane/HexMap). > Argh. I really gotta stop using Java 1.5 on my systems. I > apologize for that. > > What do you mean by the tiles being clipped? That the borders are not visible, only the center part. Or is that specific to me? I can't believe that *that* is caused by Java version differences, but you never know.... Erik. |
|
From: Brett L. <wak...@ea...> - 2005-09-29 21:13:39
|
>> Nope, we don't have this problem anywhere else. It's >> specifically HexMap that's the problem. >I had lots of problems to get scrolling right in the Log window. >Now it is a JFrame containing a JPanel containing a JScrollPane >(which contains the JLabel which contains all the text). >Map Window is a JFrame containing a ScrollPane containing a JPanel >(HexMap, which contains all the small JPanels representing tiles). >I don't claim anything, I just wonder if adding a JPanel (as in LogWindow) >would help (so we would get JFrame/JPanel/JScrollPane/HexMap). I actually had that same idea at one point, but it didn't work. After a little more reading, it seems like the difference between 'heavyweight' and 'lightweight' objects is how they tie into the windowing system. AWT seems to do more things directly with the native windowing system whereas Swing doesn't hook as deeply into the native windowing system. This is what makes Swing objects look significantly better and take up less resources regardless of the platform the code is running on. I'm not really sure what is causing HexMap to be considered 'heavyweight'. As far as I can tell, it's comprised of only lightweight objects. >> Argh. I really gotta stop using Java 1.5 on my systems. I >> apologize for that. >> >> What do you mean by the tiles being clipped? >That the borders are not visible, only the center part. >Or is that specific to me? >I can't believe that *that* is caused by Java version >differences, but you never know.... Ahh... I'm pretty sure I know what that is. In the paint() method for each GUIHex, you'll notice a call to g2.setClip(hexagon) This sets the clipping boundary for each hex to be the size and dimensions of the hexagon. This is probably cutting out the borders on the hexes. However, the reason we need to setClip() is because otherwise the clickable area for each hexagon would be a bunch of overlapping rectangles that cause problems for detecting which hex a click triggers. ---Brett. |
|
From: Brett L. <wak...@ea...> - 2005-09-29 21:27:31
|
>I had lots of problems to get scrolling right in the Log window. >Now it is a JFrame containing a JPanel containing a JScrollPane >(which contains the JLabel which contains all the text). The alternative is to have the JLabel which contains the text implement the Scrollable interface, which is what I did with HexMap. |
|
From: Brett L. <wak...@ea...> - 2005-09-29 23:24:13
|
>>> Argh. I really gotta stop using Java 1.5 on my systems. I >>> apologize for that. >>> >>> What do you mean by the tiles being clipped? >>That the borders are not visible, only the center part. >>Or is that specific to me? >>I can't believe that *that* is caused by Java version >>differences, but you never know.... >Ahh... I'm pretty sure I know what that is. >In the paint() method for each GUIHex, you'll notice a call to g2.setClip(hexagon) >This sets the clipping boundary for each hex to be the size and dimensions >of the hexagon. This is probably cutting out the borders on the hexes. >However, the reason we need to setClip() is because otherwise the >clickable area for each hexagon would be a bunch of overlapping >rectangles that cause problems for detecting which hex a click triggers. Actually, I've found a better way of doing things. In GUIHex, there's still the PaintOverlay code from Colossus. This seems to work a lot better than my rather hackish image loading code. It currently only works under the NS hex orientation. If I can get the rotation math correct I'll have it working for all hexes shortly. ---Brett. |
|
From: Brett L. <wak...@ea...> - 2005-10-02 23:24:12
|
>Actually, I've found a better way of doing things. >In GUIHex, there's still the PaintOverlay code from Colossus. Ok. I've gotten tile drawing to work using the paintOverlay() methods in GUIHex. IMO, this looks a TON better. Tiles are being drawn and rotated properly. I've even gotten hex selection working (first click selects the hex, second and subsequent clicks rotate it). However, there's still quite a few painting bugs in the frame, especially related to the scrollbar. Erik - Can you take a look at how neighbors and entrances are assigned and make sure they're correct? I think we're at a point where we need to verify this is working correctly. Even some of the hex painting code relies on checking neighbor hexes. I'm also thinking that rather than having a seperate property for TileID, we should use the Label property that's already there. Any thoughts here? ---Brett. |
|
From: Erik V. <eri...@hc...> - 2005-10-04 22:00:48
|
> Erik - Can you take a look at how neighbors and entrances are > assigned and make sure they're correct? I think we're at a > point where we need to verify this is working correctly. > Even some of the hex painting code relies on checking neighbor hexes. These are model properties and therefore belong to game.MapHex. I have renamed the old model attribute to dummyModel and introduced MapHex model as an attribute of GUIHex. Each MapHex now knows its neighbours (all assigned in MapManager). If you click on a hex, the neighbours are shown in the console (I have tested this for 1830 and 1856). Impassibility and forbidden red and grey hex sides are not yet done. The former is easy. The latter needs a peek into the tiles themselves. Entrances are also dependent on the tile internals. I will do those things later. First TileSet.xml and Tiles.xml needs be read and turned into objects. I have not yet removed Hex and BattleHex, but these are no longer the real model since I introduced MapHex as the new model, a while ago. So IMO these will have to disappear one day. > I'm also thinking that rather than having a seperate property > for TileID, we should use the Label property that's already > there. Any thoughts here? Label is currently not used (and will IMO disappear with Hex). We do have Name and Id, and these two can be different, as the same tile numbers are sometimes used for different tiles in different games. Name is what is displayed (perhaps Label would be a better name, but I consistently use Name in all object types to avoid confusion), whereas Id is the number in the Tile Dictionary and must therefore be unique. For instance, 59 and 1059 are Ids of different tiles, both labelled 59. Erik. |
|
From: Brett L. <wak...@ea...> - 2005-10-04 23:18:41
|
> I have not yet removed Hex and BattleHex, but these are no longer > the real model since I introduced MapHex as the new model, a while ago. > So IMO these will have to disappear one day. Ok, please remove these as soon as you can. It's getting a little confusing in the higher level classes. ---Brett. |
|
From: Brett L. <wak...@ea...> - 2005-11-17 01:06:04
|
Woops. I apologize if I've been stepping on your toes. I have been thinking about the token problem myself. I think we'll need Tile to hold a HashMap of Tokens (defined below). The Hashmap being a Token object and its location ( city1 or city2). Single city locations will always be mapped to "city1", and OO tiles will have tokens mapped to both "city1" and "city2". From there, I can set up drawing code in GUITile to draw Tokens based on the number of tokens in each "cityN" location and the rotation of the tile. The Token object: I'm going to rename StockToken to just Token. It already has all the necessary code for drawing a suitable token. How does this sound? ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Nov 16, 2005 3:31 PM To: rai...@li... Subject: RE: [Rails-devel] UI Updates Brett, As usual some of your changes conflicted with some of mine, and Eclipse does not do a very good job in enabling a proper merge, so I hope all your changes have survived mine. > I've committed a couple UI updates: > > 1. Closing windows now correctly updates the checkbox menu > items in the StatusWindow. > > 2. You can "preview" tile lays now at any point in the game, > but the UpgradesPanel will only display the Done button > during an Operating Round, to disallow tile placement at any > other time. I have been doing the same thing, probably in a different way (controlled from ORWindow). > I'd like to add checking whether the currently operating > company has yet laid a tile to this, but that infrastructure > doesn't appear to have been built yet. There is more logic behind that - some games allow two yellow tile lays, anytime, or just the first time, etc. Allowances can also be dependent on the company type (e.g. 18EU). OperatingRound should (as usual) provide such information. > This looks like it's starting to interfere with the current ORWindow. > > Erik - Do you already have an idea on how you'd like to approach this? Yes, I'm working on that, and for all safety (see above) I have committed my changes so far, but in fact I have only started. As soon as a company can lay a tile, MapWindow will get focus and "Done" will be enabled. Pressing "Done" will call (indirectly) OperatingRound.layTile() and control will pass back to ORWindow. The real control center is OperatingRound, but I have only started to figure out exactly how this should work. I'll be happy to sort it all out, but you'll have to give me some time for that. If you want a new topic to think about: what about token laying, and the visual representation of that? In particular NY and the OO cities worry me a bit..... Erik. |
|
From: Brett L. <wak...@ea...> - 2005-11-17 01:22:29
|
Rereading this, I should also note: I don't mean that we should be storing the very-much-GUI-specific Token object in the very-much-model-side object Tile. In StockSpace, we're holding an ArrayList of Company objects as the tokens. I'm suggesting we use the same model-side object for Tile. ---Brett. -----Original Message----- From: Brett Lentz <wak...@ea...> Sent: Nov 16, 2005 8:05 PM To: rai...@li... Subject: RE: [Rails-devel] UI Updates Woops. I apologize if I've been stepping on your toes. I have been thinking about the token problem myself. I think we'll need Tile to hold a HashMap of Tokens (defined below). The Hashmap being a Token object and its location ( city1 or city2). Single city locations will always be mapped to "city1", and OO tiles will have tokens mapped to both "city1" and "city2". From there, I can set up drawing code in GUITile to draw Tokens based on the number of tokens in each "cityN" location and the rotation of the tile. The Token object: I'm going to rename StockToken to just Token. It already has all the necessary code for drawing a suitable token. How does this sound? ---Brett. -----Original Message----- From: Erik Vos <eri...@hc...> Sent: Nov 16, 2005 3:31 PM To: rai...@li... Subject: RE: [Rails-devel] UI Updates Brett, As usual some of your changes conflicted with some of mine, and Eclipse does not do a very good job in enabling a proper merge, so I hope all your changes have survived mine. > I've committed a couple UI updates: > > 1. Closing windows now correctly updates the checkbox menu > items in the StatusWindow. > > 2. You can "preview" tile lays now at any point in the game, > but the UpgradesPanel will only display the Done button > during an Operating Round, to disallow tile placement at any > other time. I have been doing the same thing, probably in a different way (controlled from ORWindow). > I'd like to add checking whether the currently operating > company has yet laid a tile to this, but that infrastructure > doesn't appear to have been built yet. There is more logic behind that - some games allow two yellow tile lays, anytime, or just the first time, etc. Allowances can also be dependent on the company type (e.g. 18EU). OperatingRound should (as usual) provide such information. > This looks like it's starting to interfere with the current ORWindow. > > Erik - Do you already have an idea on how you'd like to approach this? Yes, I'm working on that, and for all safety (see above) I have committed my changes so far, but in fact I have only started. As soon as a company can lay a tile, MapWindow will get focus and "Done" will be enabled. Pressing "Done" will call (indirectly) OperatingRound.layTile() and control will pass back to ORWindow. The real control center is OperatingRound, but I have only started to figure out exactly how this should work. I'll be happy to sort it all out, but you'll have to give me some time for that. If you want a new topic to think about: what about token laying, and the visual representation of that? In particular NY and the OO cities worry me a bit..... Erik. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
|
From: Erik V. <eri...@hc...> - 2005-11-17 20:33:48
|
We'll also have to think ahead to how we will determine routes and calculate income. We need routes also to determine allowances to lay tiles and tokens! A route is a set of stations (not just tiles or hexes) connected by tracks. I (still) believe we will have to represent both of these in the Model somehow, e.g. by Station and Track objects. A Station is connected to the current tile on a given hex, but has a life of its own, because it (usually) survives tile upgrades. I use the work "Station" to represent both large and small cities/towns/villages I would also be OK with "City", or "Town", although that would be somewhat ambiguous. I prefer Station because (1) that is where in real life trains stop and create revenue and (2) we avoid some confusion: in my language 1830 NY would be one city with 2 stations (being able to serve up 4 bases). 1856 Toronto initially has 2 stations, which later merge to one (again with up to 4 bases). So I think tokens should be connected to Stations. How to name this kind of token in the Model? Many terms are being used: marker, token, station, garrison, base. IMHO "Depot" would best represent the real-life equivalent: a place from where a company can run trains. But that word is not being used in practice, so I would go for "Base". Token is a rather generic name: many games have special tokens (e.g. in 1856: a port token, which is laid on a tile but not in a city slot). I believe that, at least in the Model, Token could be a superclass of Base (or BaseToken) and many other kinds of token. Or perhaps just an interface. In the GUI, perhaps one type (GUIToken?) would suffice, perhaps not. See also below. > I don't mean that we should be storing the > very-much-GUI-specific Token object in the > very-much-model-side object Tile. > > In StockSpace, we're holding an ArrayList of Company objects > as the tokens. I'm suggesting we use the same model-side > object for Tile. Each company only has one stock chart token, so we do not need token there as a separate object. But a company always has more than one Base token, so we must somehow keep or at least enumerate these as separate objects. I suggest to handle tokens (incl. all special ones) similar to certificates: i.e. as objects that are "held" by some other object. All certificates and trains are held by a Portfolio object (even those ones that are not yet or no longer in play). All money is held by CashHolder objects (an interface, implemented by Bank, PublicCompany and Player). In a similar way, all tokens could be held by TokenHolder objects (another interface). TokenHolders can be: Companies (also privates), Stations (with 1 or more slots), Hexes (e.g. the 1856 port token), perhaps others. > Woops. I apologize if I've been stepping on your toes. I was already afraid that my post sounded a bit like that. What I should have said is, that this view/model integration could best be done by one person, and that I might be in a better position to do that, given past experience. > I have been thinking about the token problem myself. > > I think we'll need Tile to hold a HashMap of Tokens (defined > below). The Hashmap being a Token object and its location ( > city1 or city2). Single city locations will always be mapped > to "city1", and OO tiles will have tokens mapped to both > "city1" and "city2". That's one approach. We cannot really use "city1" and "city2", as defined in Tiles.xml, because one tile's city1 can easily become another tile's city2 (see e.g. the OO green-to-brown upgrades). That's one reason I believe we must treat cities (or stations) somewhat separately from tiles or hexes. > From there, I can set up drawing code in GUITile to draw > Tokens based on the number of tokens in each "cityN" location > and the rotation of the tile. > > The Token object: I'm going to rename StockToken to just > Token. It already has all the necessary code for drawing a > suitable token. > > How does this sound? As a good start to get my thoughts running.... These immature thoughts are of course open for discussion. Erik. |
|
From: Erik V. <eri...@hc...> - 2005-09-28 21:08:50
|
Strange, we don't have this problem in the other windows, do we? Unfortunately, setPreferredSize() does not compile with Java 1.4, because JFrame and ScrollPane are not JComponents. I have outcommented these lines for now. I have wrestled with sizes in the other windows too, when I've more time I will have another look. Another thing to do is to better scale the map (now the tiles are clipped) and move it against the upper and left borders. Erik. > I've gotten ScrollBars on the Map window to work without drawing bugs. > > Here's the scoop on this badboy: > > For some reason that I haven't yet pinned down, HexMap is > considered a HeavyWeight component. Most Swing objects > (JPanel, JLabel, etc) are considered LightWeight components. > > So, when using JScrollPane with HexMap, the map hexes kept > being drawn on top of the scroll bars. > > The reason being that HeavyWeight components are ALWAYS drawn > on top of LightWeight components, regardless of Z-ordering. > This has a bunch of legacy reasoning from back when Sun made > the transition from AWT to Swing. > > This is why mixing lightweight and heavyweight components is > not recommended. > > SO, the solution was to use AWT's ScrollPane rather than > Swing's JScrollPane. ScrollPane is a heavyweight component > because all of AWT's components are heavyweight components. > > Unfortunately, as you'll see if you examine MapWindow, this > causes problems for MouseListeners. Swing objects will > automatically pass events up to their parent objects. AWT > objects won't. So, the MouseListener needs to be explicitly > added to all levels of the hierarchy in order to function, as > it is currently being done in MapWindow. > > For the future: If we can figure out how to make HexMap a > lightweight component, I'd really like to do that. There are > a lot of good things we gain if we can do it. > > For now, if you see any drawing weirdness with the MapWindow, > this is the likely source. Be careful how you layer AWT and > Swing objects. > > > ---Brett. > > > > -----Original Message----- > From: Brett Lentz <wak...@ea...> > Sent: Sep 27, 2005 3:19 PM > To: rai...@li... > Subject: [Rails-devel] UI Updates > > I've just committed some UI reorganization and minor cleanups. > > Here's a rough list of what's changed: > > 1. We no longer draw every single window when a game starts. > The StatusWindow opens, and if it's the beginning of a > startRound, the StartRoundWindow opens. That's it. > > The Stock Market chart is only setVisible during stock > rounds, and the Map is only setVisible during Operating Rounds. > > 2. I've added a series of drop-down menus to the Status > Window. This includes an Options menu where you can open any > of the other windows as you see fit. > > 3. I've added Mnemonics to all existing buttons, so now they > can be accessed via ALT+key combinations if so desired. > > > I'm still working on getting the MapWindow to correctly use > ScrollBars. Hopefully that'll be working fairly soon. > > ---Brett. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X