You can subscribe to this list here.
2005 |
Jan
|
Feb
(25) |
Mar
(84) |
Apr
(76) |
May
(25) |
Jun
(1) |
Jul
(28) |
Aug
(23) |
Sep
(50) |
Oct
(46) |
Nov
(65) |
Dec
(76) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(60) |
Feb
(33) |
Mar
(4) |
Apr
(17) |
May
(16) |
Jun
(18) |
Jul
(131) |
Aug
(11) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(5) |
2007 |
Jan
(71) |
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(19) |
Jul
(40) |
Aug
(38) |
Sep
(7) |
Oct
(58) |
Nov
|
Dec
(10) |
2008 |
Jan
(17) |
Feb
(27) |
Mar
(12) |
Apr
(1) |
May
(50) |
Jun
(10) |
Jul
|
Aug
(15) |
Sep
(24) |
Oct
(64) |
Nov
(115) |
Dec
(47) |
2009 |
Jan
(30) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(4) |
Nov
(132) |
Dec
(93) |
2010 |
Jan
(266) |
Feb
(120) |
Mar
(168) |
Apr
(127) |
May
(83) |
Jun
(93) |
Jul
(77) |
Aug
(77) |
Sep
(86) |
Oct
(30) |
Nov
(4) |
Dec
(22) |
2011 |
Jan
(48) |
Feb
(81) |
Mar
(198) |
Apr
(174) |
May
(72) |
Jun
(101) |
Jul
(236) |
Aug
(144) |
Sep
(54) |
Oct
(132) |
Nov
(94) |
Dec
(111) |
2012 |
Jan
(135) |
Feb
(166) |
Mar
(86) |
Apr
(85) |
May
(137) |
Jun
(83) |
Jul
(54) |
Aug
(29) |
Sep
(49) |
Oct
(37) |
Nov
(8) |
Dec
(6) |
2013 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(14) |
May
(5) |
Jun
(15) |
Jul
|
Aug
(38) |
Sep
(44) |
Oct
(45) |
Nov
(40) |
Dec
(23) |
2014 |
Jan
(22) |
Feb
(63) |
Mar
(43) |
Apr
(60) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(57) |
Sep
(36) |
Oct
(2) |
Nov
(30) |
Dec
(27) |
2015 |
Jan
(5) |
Feb
(2) |
Mar
(14) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(10) |
Aug
(63) |
Sep
(31) |
Oct
(26) |
Nov
(11) |
Dec
(6) |
2016 |
Jan
|
Feb
(11) |
Mar
|
Apr
|
May
(1) |
Jun
(16) |
Jul
|
Aug
(4) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(1) |
2017 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(20) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(10) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(3) |
Apr
(9) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(4) |
2021 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Frederick W. <fre...@go...> - 2012-01-15 05:57:58
|
Before, selecting a tile of the upgrade panel could lead to the message "This tile cannot be laid in a valid orientation." Now, tiles are excluded from the upgrade panel selection if such message would be issued upon clicking on them. Stated differently, every tile listed in the upgrade panel can now be laid by the user. The level of rule enforcement is not affected by this change. So hopefully there are no objections to this change. |
From: Erik V. <eri...@xs...> - 2012-01-13 20:46:14
|
> Now the tooltip is configured such that it will never disappear. On top of that, > the tooltip appears on the map panel upon mouse click if no > action/correction is expected. Thanks. I had not realized that this was possible. Erik. |
From: Frederick W. <fre...@go...> - 2012-01-13 20:34:43
|
Regarding the token texts: > The token labels fit inside the circles indeed, but readability has suffered a bit too much for my taste. > For instance, the 1830 NYNH and 1856 BBG tokens are now hardly readable (for me) at normal scale. Origin master now includes a logic for displaying 3 char tokens in a condensed font a 4+ char texts in two lines. 1830 token texts are now readable on 1024x800. What I did not do is to introduce a minimal font size. That proposal is valid - but it would entail a lot of additional consideration (enlarged clips for repaint) - and perhaps the decision is to use svg tokens at the end... That's why I did not implement this. |
From: Frederick W. <fre...@go...> - 2012-01-13 17:56:57
|
@Stefan: These are very good observations. > That is an argument: however then it is surprising that pressing the left > mouse button removes the tooltip and still have the hex highlighted. > And If I move the mouse pointer over the tooltip, the tooltip remains, but the > hex itself is not highlighted anymore. Both fixed now in origin/master. Tooltips are now lightwight again (became possible due to the prior hexmap layering/refactoring). > Other observations: > * The revenue calculation is now displayed twice at the revenue step. Fixed now in origin/master. > * The disadvantage of the fixed size info panel is that one has to scroll down > if one want to show the revenue details. Here it would be better to increase > size if one activate details (even if this triggers a resize). Such size increase is now also available in origin/master. @Erik: > That would also remove the annoyance (at least to me), that the tooltip disappears after a very short while. Now the tooltip is configured such that it will never disappear. On top of that, the tooltip appears on the map panel upon mouse click if no action/correction is expected. @Erik/Brett: > Another idea might be to replace the tooltip by a message in some special > area or status line. I prefer tooltips to another info area - mainly because this saves some space. So don't count on me to refactor that. |
From: Erik V. <eri...@xs...> - 2012-01-13 15:28:59
|
> To answer your questions: > 1. would only de-activate those menu-items which are corresponds to Rails > actions. All others should be still active. Agreed. > 2. message pop-ups should never be modal (or quasi-modal, as you are > currently implementing), most likely they could be replaced by displaying it in > the info/status panel (adding an info panel in the stock window would allow > that). That doesn't work in all cases: some messages are pretty long, such as those that report the CGR formation details. Another idea could be a permanent message window. > Some other remarks: > > * Most likely it makes sense to merge your commit with the code that > deactivates the windows when the game history is used, which tries to > achieve a similar effect. I'll look at that. I'll probably first refactor dialog handling itself, which is now spread over various UI classes in a not very logical way. In any case we need a dialog type enum. |
From: brett l. <bre...@gm...> - 2012-01-13 14:33:39
|
On Fri, Jan 13, 2012 at 9:01 AM, Erik Vos <eri...@xs...> wrote: >> That is an argument: however then it is surprising that pressing the left >> mouse button removes the tooltip and still have the hex highlighted. >> And If I move the mouse pointer over the tooltip, the tooltip remains, but >> the hex itself is not highlighted anymore. > > Another idea might be to replace the tooltip by a message in some special > area or status line. > That would also remove the annoyance (at least to me), that the tooltip > disappears after a very short while. > > Erik. > +1 I think it would be great to have a message area in one of the windows (or maybe all of them) to present information to the user. I'm not a fan of pop-ups (modal or otherwise). They tend to complicate the UI's work flow without adding much value. ---Brett. |
From: Erik V. <eri...@xs...> - 2012-01-13 14:01:22
|
> That is an argument: however then it is surprising that pressing the left > mouse button removes the tooltip and still have the hex highlighted. > And If I move the mouse pointer over the tooltip, the tooltip remains, but > the hex itself is not highlighted anymore. Another idea might be to replace the tooltip by a message in some special area or status line. That would also remove the annoyance (at least to me), that the tooltip disappears after a very short while. Erik. |
From: Stefan F. <ste...@we...> - 2012-01-12 18:23:58
|
On Thursday, January 12, 2012 04:01:45 pm Frederick Weld wrote: > > The highlighting of map hexes is always active not only during tile and > > token lays. > > Stefan: > This is as designed as I wanted to highlight the hex to which the > tooltip is associated - and tooltips are active all the time too. > Wouldn't that be what a user expects? > That is an argument: however then it is surprising that pressing the left mouse button removes the tooltip and still have the hex highlighted. And If I move the mouse pointer over the tooltip, the tooltip remains, but the hex itself is not highlighted anymore. Other observations: * The revenue calculation is now displayed twice at the revenue step. * The disadvantage of the fixed size info panel is that one has to scroll down if one want to show the revenue details. Here it would be better to increase size if one activate details (even if this triggers a resize). Stefan |
From: Stefan F. <ste...@we...> - 2012-01-12 18:12:22
|
Erik: To answer your questions: 1. would only de-activate those menu-items which are corresponds to Rails actions. All others should be still active. 2. message pop-ups should never be modal (or quasi-modal, as you are currently implementing), most likely they could be replaced by displaying it in the info/status panel (adding an info panel in the stock window would allow that). Some other remarks: * Most likely it makes sense to merge your commit with the code that deactivates the windows when the game history is used, which tries to achieve a similar effect. * More general: I think there in principle there is no general difference between the non- model popup requests and any other situation: Only those buttons and menu- items should be active that are either available generally (like save/load, zoom, show/hide windows) or are allowed actions at that time. Currently there are some other cases when buttons are still active, which do not contain active commands, that generate error messages if pressed. The ideal solution would be if the UI would be able to figure out what to activate and deactivate given the current set of actions and maybe a few flags. I know that the current UI already tries to achieve that already, but there are some bits still missing. Stefan On Thursday, January 12, 2012 04:39:58 pm Erik Vos wrote: > I have pushed a change to disable all buttons (in the current window) as > long as a non-modal popup request has not been answered. > Two questions remain, on which I'm in doubt: > 1. Should (most) menu items also be disabled? > 2. Should we make an exception to message-only popups? I currently do. > > Erik. > > > --------------------------------------------------------------------------- > --- RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Chris S. <chr...@gm...> - 2012-01-12 18:01:01
|
Right, but you asked if the menu items should be disabled, and one of them is "let me see that other window" which should not be disabled. Does that make sense? -- Chris Please consider the environment before printing this e-mail. On Thu, Jan 12, 2012 at 9:52 AM, Erik Vos <eri...@xs...> wrote: > Yes, that’s the whole point of making popups non-modal. Several ones > already are.**** > > Erik.**** > > ** ** > > *From:* Chris Shaffer [mailto:chr...@gm...] > *Sent:* Thursday, January 12, 2012 4:54 PM > *To:* Development list for Rails: an 18xx game > *Subject:* Re: [Rails-devel] Nonmodal popups**** > > ** ** > > Are there times when the respondent might want to view other windows > before answering? I can imagine being frustrated if the popup says "do you > want to convert this share?" and my answer is dependent on needing to use > the menu to see the stock market, for example. > **** > > ** ** > > -- > Chris > > Please consider the environment before printing this e-mail. > > **** > > On Thu, Jan 12, 2012 at 7:39 AM, Erik Vos <eri...@xs...> wrote:**** > > I have pushed a change to disable all buttons (in the current window) as > long as a non-modal popup request has not been answered. > Two questions remain, on which I'm in doubt: > 1. Should (most) menu items also be disabled? > 2. Should we make an exception to message-only popups? I currently do. > > Erik. > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel**** > > ** ** > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > > |
From: Erik V. <eri...@xs...> - 2012-01-12 17:53:05
|
Yes, that's the whole point of making popups non-modal. Several ones already are. Erik. From: Chris Shaffer [mailto:chr...@gm...] Sent: Thursday, January 12, 2012 4:54 PM To: Development list for Rails: an 18xx game Subject: Re: [Rails-devel] Nonmodal popups Are there times when the respondent might want to view other windows before answering? I can imagine being frustrated if the popup says "do you want to convert this share?" and my answer is dependent on needing to use the menu to see the stock market, for example. -- Chris Please consider the environment before printing this e-mail. On Thu, Jan 12, 2012 at 7:39 AM, Erik Vos <eri...@xs...> wrote: I have pushed a change to disable all buttons (in the current window) as long as a non-modal popup request has not been answered. Two questions remain, on which I'm in doubt: 1. Should (most) menu items also be disabled? 2. Should we make an exception to message-only popups? I currently do. Erik. ---------------------------------------------------------------------------- -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 _______________________________________________ Rails-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Chris S. <chr...@gm...> - 2012-01-12 15:54:29
|
Are there times when the respondent might want to view other windows before answering? I can imagine being frustrated if the popup says "do you want to convert this share?" and my answer is dependent on needing to use the menu to see the stock market, for example. -- Chris Please consider the environment before printing this e-mail. On Thu, Jan 12, 2012 at 7:39 AM, Erik Vos <eri...@xs...> wrote: > I have pushed a change to disable all buttons (in the current window) as > long as a non-modal popup request has not been answered. > Two questions remain, on which I'm in doubt: > 1. Should (most) menu items also be disabled? > 2. Should we make an exception to message-only popups? I currently do. > > Erik. > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
From: Erik V. <eri...@xs...> - 2012-01-12 15:40:08
|
I have pushed a change to disable all buttons (in the current window) as long as a non-modal popup request has not been answered. Two questions remain, on which I'm in doubt: 1. Should (most) menu items also be disabled? 2. Should we make an exception to message-only popups? I currently do. Erik. |
From: Erik V. <eri...@xs...> - 2012-01-12 15:31:02
|
Thanks, it's OK now on my side too. Erik. > -----Original Message----- > From: Frederick Weld [mailto:fre...@go...] > Sent: Thursday, January 12, 2012 4:19 PM > To: Development list for Rails: an 18xx game > Subject: Re: [Rails-devel] Push request: Correction bundle (Precise token > label positioning, initial map image display, 1856 map) > > > Now, I have been able of reproducing this (only occurs if config for > > auto-zoom is disabled). > > I'm taking care of fixing this now. > > The bug is now fixed in master. > > ---------------------------------------------------------------------------- -- > RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Frederick W. <fre...@go...> - 2012-01-12 15:19:04
|
> Now, I have been able of reproducing this (only occurs if config for > auto-zoom is disabled). > I'm taking care of fixing this now. The bug is now fixed in master. |
From: Frederick W. <fre...@go...> - 2012-01-12 15:01:55
|
> The highlighting of map hexes is always active not only during tile and token > lays. Stefan: This is as designed as I wanted to highlight the hex to which the tooltip is associated - and tooltips are active all the time too. Wouldn't that be what a user expects? |
From: Stefan F. <ste...@we...> - 2012-01-12 14:53:34
|
Frederick: Another minor glitch I realized during testing: The highlighting of map hexes is always active not only during tile and token lays. Stefan On Thursday, January 12, 2012 03:50:20 pm Frederick Weld wrote: > Update: > Now, I have been able of reproducing this (only occurs if config for > auto-zoom is disabled). > I'm taking care of fixing this now. > > Thanks for finding that bug. > > --------------------------------------------------------------------------- > --- RSA(R) Conference 2012 > Mar 27 - Feb 2 > Save $400 by Jan. 27 > Register now! > http://p.sf.net/sfu/rsa-sfdev2dev2 > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Frederick W. <fre...@go...> - 2012-01-12 14:50:26
|
Update: Now, I have been able of reproducing this (only occurs if config for auto-zoom is disabled). I'm taking care of fixing this now. Thanks for finding that bug. |
From: Frederick W. <fre...@go...> - 2012-01-12 14:31:21
|
Erik/Stefan: The attached jpg displays the background with a scale factor of 1.0 (instead of 0.1632 - specified in origin/master's map.xml). Stefan is right that the observed symptom is due to a missing resize of the map image after gvt rendering. Unfortunately, I cannot experiment how to fix this as the symptoms do not occur on my local machine. The first place to look at would probably be: rails / ui / swing / hexmap / HexMapImage.java line 83: change "gvtRenderingPrepare" to "gvtRenderingCompleted" |
From: Stefan F. <ste...@we...> - 2012-01-12 14:21:53
|
All: some more info on this (tested on a Linux system:) * The wrong scaling effect does not only occur for 1856, but for all games with background maps (18AL, 1856, 1889) (see 1889 attachment as an example). * As soon as you zoom from the menu the background map gets scaled correctly. * There is nothing wrong if I open the svg file from your zip in a graphic editor. So I assume there is something wrong with the zoom scale at the start/reload of a game. Stefan On Thursday, January 12, 2012 03:01:07 pm you wrote: > Brett, Frederick, > > > commit b41262c12a86ef75045d0a8e1edfa0b0a4983be3 > > > > > Fixed 1856 background map's mini-map (Windsor area) > > Please have a look at the JPEG included in the attached zip file: that is > what the 1856 map looks like when I start or reload an 1856 game. Before > this commit is was OK. I suppose the SVG file somehow got mangled (also > included). > > Erik. |
From: Frederick W. <fre...@go...> - 2012-01-11 19:00:04
|
As (3) was also my favorite, I went for this solution (now already available in master). Here are the commit details: Prohibited resizing of OR's message panel (and ORPanel to some extent) Frequent resizing by the message panel and the OR panel caused the map panel to being resized - which was not desirable in case of activated auto-zoom. Message Panel is now fixed to the height of two lines. The additional vertical scrollbar allows for text containing more than two lines. ORPanel used to resize itself for each set-revenue step as the size of the revenue input box did not match the one of the revenue read-only field. These sizes are now aligned. (ORPanel still resizes if companies are added/removed from the list.) |
From: Chris S. <chr...@gm...> - 2012-01-11 15:46:58
|
On Wed, Jan 11, 2012 at 7:14 AM, Frederick Weld < fre...@go...> wrote: > (3) Freeze the message panel's size to 2-3 lines: But how to deal with > multiline route details? > I prefer this option. If the message panel overflows, could you add scroll bars? -- Chris Please consider the environment before printing this e-mail. |
From: Frederick W. <fre...@go...> - 2012-01-11 15:14:16
|
Stefan: The size of the map panel changes if the message panel's height changes. This is typically the case if new info texts (lay tile, set revenue) are displayed. So you have probably not experienced "superfluous" resizes - but, on a second thought, it's clear also to me that this is not as nice at it was supposed to be. I perceive several design options: (1) No change to the functionality: as already said, not nice... But nobody is forced to use the auto-zoom (can be disabled at any point in time by clicking on the selected menu item again). (2) Disable auto-zoom: I wouldn't like this disablement as I really would like to have the auto-zoom (eg., think of frequent OR Panel height changes in 18EU). (3) Freeze the message panel's size to 2-3 lines: But how to deal with multiline route details? (4) Only auto-zoom on special occasions (eg., beginning of the OR): But will the end-users understand that it's not a bug that the auto-zoom is only triggered occasionally? What would be your favorite? Are there other options? Technically, all would be viable. But I wouldn't like (2) that much. --- Frederick |
From: Stefan F. <ste...@we...> - 2012-01-11 12:06:52
|
Frederick: On my system the auto-zoom noticeably resizes the map after each change to the map (e.g. laying a tile or revenue calculation), even if the map panel size remains untouched: It creates a flicker effect as Rails seems to first shrink the map a smaller size and then expand it to full size again. As long as this effect is not fixed, I would prefer a one-time zoom. Stefan On Tuesday, January 10, 2012 10:26:20 pm Frederick Weld wrote: > After having added a further round-off (transformed fit-to zoom from > one-time zoom to permanent auto-zoom), I'm finally satisfied with the > available zoom options. > > --------------------------------------------------------------------------- > --- Write once. Port to many. > Get the SDK and tools to simplify cross-platform app development. Create > new or port existing apps to sell to consumers worldwide. Explore the > Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join > http://p.sf.net/sfu/intel-appdev > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Frederick W. <fre...@go...> - 2012-01-10 21:26:27
|
After having added a further round-off (transformed fit-to zoom from one-time zoom to permanent auto-zoom), I'm finally satisfied with the available zoom options. |