Menu
▾
▴
rails-devel
|
From: Frederick W. <fre...@go...> - 2012-01-01 09:57:30
|
Feel free to push this into origin/master.
This patch is independent of the patches for forced train purchases
and network info.
---Frederick
commit 9fe97ef2fa38cf5d7c6d43c1916a0ceb0541034b
Added precise sizing and positioning of token labels
Introduced a generic logic that provides for precise sizing/positioning
for any label text length and zoom factor.
Replaces prior heuristic that, among others, placed labels partly
outside of the tokens.
--> See Erik's description of the prior state:
https://sourceforge.net/mailarchive/message.php?msg_id=28555719
commit b41262c12a86ef75045d0a8e1edfa0b0a4983be3
Fixed 1856 background map's mini-map (Windsor area)
commit d7e7993a920c1d275d87b4e80fac0652f9e678fd
Fixed the glitch of initially displaying map images in the wrong scale
Glitch description:
If the scale factor of the background map image differs from 1, the
map is initially displayed in the wrong scale for a second before
resizing eventually corrects this (especially applies to 1856/1889
background images as their scale is lower than 0.2).
|
|
From: brett l. <bre...@gm...> - 2012-01-01 14:44:12
|
Patches applied to master. ---Brett. On Sun, Jan 1, 2012 at 4:57 AM, Frederick Weld <fre...@go...> wrote: > Feel free to push this into origin/master. > > This patch is independent of the patches for forced train purchases > and network info. > > ---Frederick > > commit 9fe97ef2fa38cf5d7c6d43c1916a0ceb0541034b > > Added precise sizing and positioning of token labels > > Introduced a generic logic that provides for precise sizing/positioning > for any label text length and zoom factor. > > Replaces prior heuristic that, among others, placed labels partly > outside of the tokens. > > --> See Erik's description of the prior state: > https://sourceforge.net/mailarchive/message.php?msg_id=28555719 > > commit b41262c12a86ef75045d0a8e1edfa0b0a4983be3 > > Fixed 1856 background map's mini-map (Windsor area) > > commit d7e7993a920c1d275d87b4e80fac0652f9e678fd > > Fixed the glitch of initially displaying map images in the wrong scale > > Glitch description: > If the scale factor of the background map image differs from 1, the > map is initially displayed in the wrong scale for a second before > resizing eventually corrects this (especially applies to 1856/1889 > background images as their scale is lower than 0.2). > > ------------------------------------------------------------------------------ > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel > |
|
From: Erik V. <eri...@xs...> - 2012-01-01 23:00:01
|
> > commit 9fe97ef2fa38cf5d7c6d43c1916a0ceb0541034b > > > > Added precise sizing and positioning of token labels > > > > Introduced a generic logic that provides for precise > > sizing/positioning > > for any label text length and zoom factor. > > > > Replaces prior heuristic that, among others, placed labels partly > > outside of the tokens. > > > > --> See Erik's description of the prior state: > > https://sourceforge.net/mailarchive/message.php?msg_id=28555719 Now that I have seen the result, I'm not too happy about it. 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. It's fine for me to have to rely on the colours only, but that's not true for everybody, as we have recently discussed. I'm not proposing to revert this commit, but I don't consider it a final solution either. Erik. |
|
From: Stefan F. <ste...@we...> - 2012-01-12 14:21:53
Attachments:
Rails1889.jpg
|
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-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: 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 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: 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: brett l. <bre...@gm...> - 2012-01-01 23:14:49
|
On Sun, Jan 1, 2012 at 5:59 PM, Erik Vos <eri...@xs...> wrote: >> > commit 9fe97ef2fa38cf5d7c6d43c1916a0ceb0541034b >> > >> > Added precise sizing and positioning of token labels >> > >> > Introduced a generic logic that provides for precise >> > sizing/positioning >> > for any label text length and zoom factor. >> > >> > Replaces prior heuristic that, among others, placed labels partly >> > outside of the tokens. >> > >> > --> See Erik's description of the prior state: >> > https://sourceforge.net/mailarchive/message.php?msg_id=28555719 > > Now that I have seen the result, I'm not too happy about it. 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. > It's fine for me to have to rely on the colours only, but that's not true for everybody, as we have recently discussed. > > I'm not proposing to revert this commit, but I don't consider it a final solution either. > > Erik. > That's about what I expected. IMO, the calculation being performed has improved, but now we'll need to figure out a sensible default value for the scaling. ---Brett. |
|
From: Frederick W. <fre...@go...> - 2012-01-02 06:43:26
|
I think the discussion could be reduced to the following question:
"How would an end-user want the NYNH token to be displayed?"
Possible options I could think of would be:
(1) In a font the height of which matches the token size.
= logic prior to the patch
--> The label "NYNH" by far exceeds the right bound of the token.
(2) Auto-size the font so that the label always perfectly fits the token size.
= logic applied in the patch
--> The label "NYNH" is too small to be readible (on small resolutions)
(3) Enter line break between NY and NH and applied (2) to the resulting label.
--> New company attribute ("tokenLabel") to define this
Given a second thought, I think option (3) would be the best option.
To all: What would you prefer (including other options not listed here)?
|
|
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: Erik V. <eri...@xs...> - 2012-01-02 11:45:42
|
Yes, I also had concluded that a line break (option 3) would be best. But
that will not simplify calculations...
In the end, we might still want to have SVG tokens.
Erik.
> -----Original Message-----
> From: Frederick Weld [mailto:fre...@go...]
> Sent: Monday, January 02, 2012 7:43 AM
> 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)
>
> I think the discussion could be reduced to the following question:
> "How would an end-user want the NYNH token to be displayed?"
>
> Possible options I could think of would be:
>
> (1) In a font the height of which matches the token size.
> = logic prior to the patch
> --> The label "NYNH" by far exceeds the right bound of the token.
>
> (2) Auto-size the font so that the label always perfectly fits the token
size.
> = logic applied in the patch
> --> The label "NYNH" is too small to be readible (on small resolutions)
>
> (3) Enter line break between NY and NH and applied (2) to the resulting
label.
> --> New company attribute ("tokenLabel") to define this
>
> Given a second thought, I think option (3) would be the best option.
>
> To all: What would you prefer (including other options not listed here)?
>
>
----------------------------------------------------------------------------
--
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
desktops
> for less than the cost of PCs and save 60% on VDI infrastructure costs.
Try it
> free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
From: Stefan F. <ste...@we...> - 2012-01-02 18:29:49
|
Frederick:
First I have to say I like the new zooming options and your new background
maps. I still have to apologize that I forgot to add a thanks to the latest
release message (however added you to the Wikipedia changelog).
On the label size:
Regardless of line breaks or not, maybe a simple minimum font size would help.
Currently all other labels (coordinates and/or costs) do not scale at all,
which has the advantage that even at smaller zooms they stay readable.
if one still wants some scaling even at smaller size is the following: Define
a threshold size. Below that font size the labels do not scale linearly
anymore but with an exponential less than one (e.g. square-root).
Stefan
On Monday, January 02, 2012 12:45:31 pm Erik Vos wrote:
> Yes, I also had concluded that a line break (option 3) would be best. But
> that will not simplify calculations...
> In the end, we might still want to have SVG tokens.
>
> Erik.
>
> > -----Original Message-----
> > From: Frederick Weld [mailto:fre...@go...]
> > Sent: Monday, January 02, 2012 7:43 AM
> > 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)
> >
> > I think the discussion could be reduced to the following question:
> > "How would an end-user want the NYNH token to be displayed?"
> >
> > Possible options I could think of would be:
> >
> > (1) In a font the height of which matches the token size.
> > = logic prior to the patch
> > --> The label "NYNH" by far exceeds the right bound of the token.
> >
> > (2) Auto-size the font so that the label always perfectly fits the token
>
> size.
>
> > = logic applied in the patch
> > --> The label "NYNH" is too small to be readible (on small resolutions)
> >
> > (3) Enter line break between NY and NH and applied (2) to the resulting
>
> label.
>
> > --> New company attribute ("tokenLabel") to define this
> >
> > Given a second thought, I think option (3) would be the best option.
> >
> > To all: What would you prefer (including other options not listed here)?
>
> ---------------------------------------------------------------------------
> - --
>
> > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> > infrastructure or vast IT resources to deliver seamless, secure access to
> > virtual desktops. With this all-in-one solution, easily deploy virtual
>
> desktops
>
> > for less than the cost of PCs and save 60% on VDI infrastructure costs.
>
> Try it
>
> > free! http://p.sf.net/sfu/Citrix-VDIinabox
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ---------------------------------------------------------------------------
> --- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> complex infrastructure or vast IT resources to deliver seamless, secure
> access to virtual desktops. With this all-in-one solution, easily deploy
> virtual desktops for less than the cost of PCs and save 60% on VDI
> infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
|
|
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 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 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: 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 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: 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: 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. |
×
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