[Freecol-developers] The size of dialogs

[Michael T. Pope]

Now that 0.11.3 is out I am looking through the list of issues I had put
aside. One of them is the question of whether dialogs/panels/whatever
should be resizable or not. What do people think? What we have ATM is
not consistent, and does not seem to be guided by any underlying
principles. Any suggestions for what these should be?

Cheers,
Mike Pope

[Caleb Williams]

Mike,

Personally, I would be in favor of non-resizable panels and dialog boxes
for pretty much every popup within FreeCol. For instance, the Advisor
panels should be non-resizable.

In a related note, the biggest related issue to me is the need for an
overhaul of the Colony panel:

[image: Inline image 1]

I realize that the GUI and MigLayout are not your specialty within the
FreeCol project, but the amount of horizontal space between each building
is prohibitive to condensing the panel horizontally (and to a far lesser
extent vertically). The screenshot above also shows the the fact that each
building graphic is clipped (the container appears to be about 120px with
some buildings extending further).

That said, unlike many of the panels within FreeCol, the Colony panel at
least responds to some changes with the horizontal size, as demonstrated in
the following:

[image: Inline image 2]

Thanks,

On Mon, Mar 9, 2015 at 1:18 AM, Michael T. Pope <***@computer.org> wrote:

> Now that 0.11.3 is out I am looking through the list of issues I had put
> aside. One of them is the question of whether dialogs/panels/whatever
> should be resizable or not. What do people think? What we have ATM is
> not consistent, and does not seem to be guided by any underlying
> principles. Any suggestions for what these should be?
>
> Cheers,
> Mike Pope
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Freecol-developers mailing list
> Freecol-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freecol-developers
>
>


--
*Caleb R. Williams*

*Photographer*
w: http://calebwilliamsphotography.com
b: http://blog.calebwilliamsphotography.com
e: ***@gmail.com
c: 612-275-7796

[w***@genial.ms]

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/

[Paolo Bizzarri]

>
>
>
> Another, secondary thought on the games code I had was to
> slowly/continuously cut down on circular dependencies, near empty
> forwarding methods and getting it a bit more in line with SOLID, to make
> it easier to understand going forward.
>
>

This is clearly a very good idea. When I worked back in the code the idea
was exactly to break those dependencies and arrive to a good state for the
GUI part.

The first important point was to hide the GUI from the rest of the code.
This has required to create a facade object (GUI class) that was hiding
most of the details of the job behind.

Clearly, this required writing forwarding methods, but at least it gave us
a first rough separation of what was GUI code and what was controller.

To move forward, we need to solve the circular dependencies between various
Canvas, MapViewer and GUI class. To do that, I have done a number of
experiments.

The result for me are clear, but the path is going to be a bit slow. We
need to make sure that:

- every event is forwarded to the InGameController (including repaint
events that are handled now by canvas via repaint, events from the
EventHandler, events coming from actions and events on the Mouse)

- the InGameController updates the status of the MapViewer variables
(activeUnit, selectedTile and so on)

- the InGameController asks the relevant part of the GUI to update and
repaint.

And so on and so fort. Eventually MapViewer will have to be split into:

- a part that is in charge of the state of the GUI (MapState or GUIState)
and it will take all the pure setters-getters for the state variables, plus
some specific code for manipulating those variables

-a part that is in charge of repainting (MapDrawer). It will take all the
chain of methods in charge of painting the various parts of the GUI itself.

Unfortunately, there are lots of places in the GUI code where MapViewer
calls Canvas and Canvas calls MapViewer, so it is not that easy.

Eventually, InGameController will grow a little too big, and it will have
to be split, but that is for later.

My two cents, naturally.

Paolo




>
> Greetings
>
> wintertime
>
> *Gesendet:* Montag, 09. MÀrz 2015 um 08:02 Uhr
> *Von:* "Caleb Williams" <***@gmail.com>
> *An:* "FreeCol Developers" <freecol-***@lists.sourceforge.net>
> *Betreff:* Re: [Freecol-developers] The size of dialogs
> Mike,
>
> Personally, I would be in favor of non-resizable panels and dialog boxes
> for pretty much every popup within FreeCol. For instance, the Advisor
> panels should be non-resizable.
>
> In a related note, the biggest related issue to me is the need for an
> overhaul of the Colony panel:
>
> [image: Inline image 1]
>
> I realize that the GUI and MigLayout are not your specialty within the
> FreeCol project, but the amount of horizontal space between each building
> is prohibitive to condensing the panel horizontally (and to a far lesser
> extent vertically). The screenshot above also shows the the fact that each
> building graphic is clipped (the container appears to be about 120px with
> some buildings extending further).
>
> That said, unlike many of the panels within FreeCol, the Colony panel at
> least responds to some changes with the horizontal size, as demonstrated in
> the following:
>
> [image: Inline image 2]
>
> Thanks,
>
> On Mon, Mar 9, 2015 at 1:18 AM, Michael T. Pope <***@computer.org>
> wrote:
>>
>> Now that 0.11.3 is out I am looking through the list of issues I had put
>> aside. One of them is the question of whether dialogs/panels/whatever
>> should be resizable or not. What do people think? What we have ATM is
>> not consistent, and does not seem to be guided by any underlying
>> principles. Any suggestions for what these should be?
>>
>> Cheers,
>> Mike Pope
>>
>
> --
> *Caleb R. Williams*
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Freecol-developers mailing list
> Freecol-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freecol-developers
>
>

[w***@genial.ms]

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/

[Paolo Bizzarri]

On Mon, Mar 9, 2015 at 5:18 PM, <***@genial.ms> wrote:

> Hi,
>
> the GUI class is really the class I feel is violating SRP most. I got the
> feeling it could be split it into, for example:
>

GUI was there for a good reason - to create a facade that was hiding the
whole GUI stuff from the rest of the application. It had to hide all the
details originally expose.

Ideally, you want to replace just the GUI class with another implementation
and change the GUI - the original plan was to make a version that could use
a web browser instead of a Swing GUI.

That said

- splitting is good, but before we need to remove lots of painful internal
dependencies.

- there is lots of code in the wrong place, that I suspect is causing many
of the issues we are seeing in the GUI.

I hope tonight to send some initial patches. I need to make my way inside
git.

Regards.

Paolo

[w***@genial.ms]

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/

[Michael T. Pope]

On Mon, 9 Mar 2015 23:41:55 +0100
***@genial.ms wrote:
> I'll try to take a closer look at those and see if circular dependencies
> can be reduced that way.

Since people are discussing code cleanups, here is a suggestion. We still have
a few type checking warning suppressions, which I always think of as a sign
that we have done something wrong.

* ListOption.readChild
* OptionGroup.setValue
* ListOptionUI.setCellRenderer
* Colony.getCorresponding
* Game.serverClass

The first three are awkward ones that I met when dealing with the Java
6->7 transition. I left them unfixed because I decided I needed
better understanding of the option handling code before fiddling with
them, and that it would probably require doing something smarter in
AbstractOption.readOption which is potentially destabilizing.

The last two are entirely my fault:-). When struggling with the
complexity of the AI colony planning code I invented getCorresponding
so that we could accurately copy a colony. serverClass() is a recent
hack to help recover from BR#2796, so urgency was the excuse there.

OTOH, I can report that IMHO all instances of
@SuppressWarnings("unused") are sensible and/or following a standard
convention, so please do not waste time chasing them.

Cheers,
Mike Pope

[Michael T. Pope]

BTW, I should have mentioned earlier that our oldest open bug (BR#479) is
about resizability, and there is some relevant discussion there.

On Mon, 9 Mar 2015 11:53:37 +0100
***@genial.ms wrote:
> you are right that the colony panel is in most need of an update.

In whatever discussion follows, please understand this: the
ColonyPanel is a *very* special case. Its code is bigger and more complex
than any other panel, it has many points where it makes calls to the
controller, and it is the most commonly used... and I doubt this is
going to change.

Therefore in trying to work out principles for panel resizing, it is
probably a bad idea to use the ColonyPanel as an example. It is highly
atypical.


> You are even lucky you get a vertical scroll bar for the buildings,
> for me its mostly a horizontal scroll bar, which is twice as ugly. When upgrading the buidings they sometimes needed even more
> space. Could you see if, as a quick fix, you could make the standard size of the whole colony panel larger to avoid scroll bars there?

I agree that scroll bars are not ideal, but growing the panel is just
dodging the issue. We should *always* be able to handle overflow in the
building area, because FreeCol allows more buildings to be added to the
spec. Indeed, all areas probably need to handle overflow. What concerns
me more here is why you are not getting the vertical bar.

> I also remember having problems with advisor panels (many months ago) and it was a godsend to be able to resize those.
> Thats why I would like to keep resizability everywhere. I also think its wise to not take away functionality some people have a
> use for, considering the other people most likely just dont care about things they dont use.

I agree these are good arguments for resizability.

> Another, secondary thought on the games code I had was to slowly/continuously cut down on circular dependencies,

Untangling the dependencies is a good idea, but another matter.

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

> Gesendet: Dienstag, 10. März 2015 um 01:45 Uhr
> Von: "Michael T. Pope" <***@computer.org>
> An: freecol-***@lists.sourceforge.net
> Betreff: Re: [Freecol-developers] The size of dialogs
>
> BTW, I should have mentioned earlier that our oldest open bug (BR#479) is
> about resizability, and there is some relevant discussion there.
>
I feel I need to admit it now, this is the only "BR" I feel strongly about
and I know that it exists since years (and when getting reminded of it
always hoping it gets forgotten, ignored or even finally closed).

Let me summerize the thread there as I would interpret it:
- A person has a diffuse feeling a _feature_ of the game is unnecessary for
_himself_ and goes to the effort of adding an issue on the _bug_tracker_.
- The person categorizing the bugs sees it and does not close it as
_not_a_bug_, I can only guess out of politeness seeing the person opening the
issue made the effort to compile a list, and only sets it to lowest priority.
- For a few years people ignore it, as its obvious there is no bug to fix.
- Jamie concisely summarizes what I felt too the moment I first read it and
asks why the issue is --even existing at all.
- The issue opener admits its unnecessary and agrees to have it closed.
- Jamie backtracks out of huge politeness.
- It gets forgotten for another year.
- It gets moved over to the new bugtracker with a pile of hundreds of real BR.
- It gets forgotten again for nearly 2 years.
- A bug category label gets updated and I guess its kept cause if it exists
thaaat long it may be relevant.
- It gets forgotten yet again.


> In whatever discussion follows, please understand this: the
> ColonyPanel is a *very* special case. Its code is bigger and more complex
> than any other panel, it has many points where it makes calls to the
> controller, and it is the most commonly used... and I doubt this is
> going to change.
>
> Therefore in trying to work out principles for panel resizing, it is
> probably a bad idea to use the ColonyPanel as an example. It is highly
> atypical.
>
>
> > You are even lucky you get a vertical scroll bar for the buildings,
> > for me its mostly a horizontal scroll bar, which is twice as ugly.
> > When upgrading the buidings they sometimes needed even more
> > space. Could you see if, as a quick fix, you could make the standard size
> > of the whole colony panel larger to avoid scroll bars there?
>
> I agree that scroll bars are not ideal, but growing the panel is just
> dodging the issue. We should *always* be able to handle overflow in the
> building area, because FreeCol allows more buildings to be added to the
> spec. Indeed, all areas probably need to handle overflow. What concerns
> me more here is why you are not getting the vertical bar.
>
Because the colony panel is more complicated, I think its a good thing to
go for the simple option at first and temporarily enlarge it a bit, as there
is not much empty space inside the panel anyway.
For me even as few as an estimated 60 pixels added to the panel width would
alleviate the problem, with always having to resize it to have all buildings
shown without scrollbars, most of the time.


Regards

wintertime

[Michael T. Pope]

On Tue, 10 Mar 2015 10:54:50 +0100
***@genial.ms wrote:
> I feel I need to admit it now, this is the only "BR" I feel strongly about
> and I know that it exists since years (and when getting reminded of it
> always hoping it gets forgotten, ignored or even finally closed).

I have never closed it because I was hoping for some strong justification
why dialogs should be/not be resizable. This thread is another attempt to
get to that point. So far all we have is your arguments in favour of
resizability. Are there any good reasons for dialogs *not* to be
resizable?


>>[ColonyPanel]
> For me even as few as an estimated 60 pixels added to the panel width would
> alleviate the problem, with always having to resize it to have all buildings
> shown without scrollbars, most of the time.

What needs to happen here is for the code that saves/restores panel sizes
from the client options to be kicked into working again. Then you (and
indeed, everyone) gets to set their dialog sizes to what they like, and it
stays that way, and we do not have to worry that much about the default
sizes. However I probably broke that code when dealing with the
FreeColDialog rewrite and have never got back to it.

Cheers,
Mike Pope

[w***@genial.ms]

> Gesendet: Dienstag, 10. März 2015 um 11:56 Uhr
> Von: "Michael T. Pope" <***@computer.org>
> An: ***@genial.ms, "FreeCol Developers" <freecol-***@lists.sourceforge.net>
> Betreff: Re: [Freecol-developers] The size of dialogs
>
> On Tue, 10 Mar 2015 10:54:50 +0100
> ***@genial.ms wrote:
> >>[ColonyPanel]
> > For me even as few as an estimated 60 pixels added to the panel width would
> > alleviate the problem, with always having to resize it to have all buildings
> > shown without scrollbars, most of the time.
>
> What needs to happen here is for the code that saves/restores panel sizes
> from the client options to be kicked into working again. Then you (and
> indeed, everyone) gets to set their dialog sizes to what they like, and it
> stays that way, and we do not have to worry that much about the default
> sizes. However I probably broke that code when dealing with the
> FreeColDialog rewrite and have never got back to it.
>
> Cheers,
> Mike Pope
>

Hi,

I did look at ColonyPanel code and it would be a 1 or 2 line change to make
it a decent default size. That call, to the save method you mentioned,
contains the default. The first statement in the constructor could also be
adapted a bit.
Now I know you said if the value could be saved everyone could just resize
him/herself, but the panel is clearly too small for everyone, so a decent
default would even in that case be better than all users resizing it once.
From looking at the different parts there is no good way to internally free
enough space. Maybe the borders/gaps could be removed, gaining maybe 20 pixels,
for a slightly worse look.
Otherwise either the maptiles would need to be shrunk, which is clearly bad,
as they are 1:1 and look decently sized atm; or the building images would
need to be shrunk, which would be a shame and a bad use of art.
As a last ditch move we could look at the images if there is empty borders
which could be cut off, but I doubt it.
There is also BR#2655, which contains pictures illustrating the space problem.
It looks like the height of the top line could profit from doubled height.

Btw., I saw a suspicious "if (colonyUnitsMenu != null)" at line 723, which
is always true, the same object is already used above and below it.
I thought of deleting the line, but there may have been some other condition
intended to include in there?


Greetings

wintertime

[Caleb Williams]

On Mar 10, 2015 5:57 AM, "Michael T. Pope" <***@computer.org> wrote:
>
> On Tue, 10 Mar 2015 10:54:50 +0100
> ***@genial.ms wrote:
> > I feel I need to admit it now, this is the only "BR" I feel strongly
about
> > and I know that it exists since years (and when getting reminded of it
> > always hoping it gets forgotten, ignored or even finally closed).
>
> I have never closed it because I was hoping for some strong justification
> why dialogs should be/not be resizable. This thread is another attempt to
> get to that point. So far all we have is your arguments in favour of
> resizability. Are there any good reasons for dialogs *not* to be
> resizable?

After trying to use FreeCol with narrow windows, it has become clear to me
that all panels should be resizeable until at least such a time as the code
has been cleaned up to handle narrow screen resolutions.

For instance, the Europe panel is not resizable, so after my test, I'm
stuck with a panel that's clipped and I can't resize it see the far right
side.

> >>[ColonyPanel]
> > For me even as few as an estimated 60 pixels added to the panel width
would
> > alleviate the pblem, with always having to resize it to have all
buildings
> > shown without scrollbars, most of the time.
>
> What needs to happen here is for the code that saves/restores panel sizes
> from the client options to be kicked into working again. Then you (and
> indeed, everyone) gets to set their dialog sizes to what they like, and it
> stays that way, and we do not have to worry that much about the default
> sizes. However I probably broke that code when dealing with the
> FreeColDialog rewrite and have never got back to it.
Anyway to set that stuff (panel sizes) back to defaults?

Thanks,

Caleb

[Michael T. Pope]

On Thu, 12 Mar 2015 09:36:36 -0500
Caleb Williams <***@gmail.com> wrote:
> Anyway to set that stuff (panel sizes) back to defaults?

Delete the settings from the client options file.

Cheers,
Mike Pope

[Caleb Williams]

How is that done? I can only find ClientOptions.java, and it would make
sense if nothing was there in the first place.

Should/can I delete the whole Documents/FreeCol/freecol/options.xml file?

On Thu, Mar 12, 2015 at 4:02 PM, Michael T. Pope <***@computer.org> wrote:

> On Thu, 12 Mar 2015 09:36:36 -0500
> Caleb Williams <***@gmail.com> wrote:
> > Anyway to set that stuff (panel sizes) back to defaults?
>
> Delete the settings from the client options file.
>
> Cheers,
> Mike Pope
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Freecol-developers mailing list
> Freecol-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freecol-developers
>
>


--
*Caleb R. Williams*

*Photographer*
w: http://calebwilliamsphotography.com
b: http://blog.calebwilliamsphotography.com
e: ***@gmail.com
c: 612-275-7796

[Michael T. Pope]

On Thu, 12 Mar 2015 18:28:06 -0500
Caleb Williams <***@gmail.com> wrote:
> How is that done? I can only find ClientOptions.java

Not in the source, in your local configuration. options.xml in
<config-root>/freecol/<rules>.

Cheers,
Mike Pope

[Caleb Williams]

Any update on this? I'd love to get my Europe panel back.

On Thu, Mar 12, 2015 at 6:28 PM, Caleb Williams <***@gmail.com> wrote:

> How is that done? I can only find ClientOptions.java, and it would make
> sense if nothing was there in the first place.
>
> Should/can I delete the whole Documents/FreeCol/freecol/options.xml file?
>
> On Thu, Mar 12, 2015 at 4:02 PM, Michael T. Pope <***@computer.org>
> wrote:
>
>> On Thu, 12 Mar 2015 09:36:36 -0500
>> Caleb Williams <***@gmail.com> wrote:
>> > Anyway to set that stuff (panel sizes) back to defaults?
>>
>> Delete the settings from the client options file.
>>
>> Cheers,
>> Mike Pope
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Freecol-developers mailing list
>> Freecol-***@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/freecol-developers
>>
>>
>
>
> --
> *Caleb R. Williams*
>
> *Photographer*
> w: http://calebwilliamsphotography.com
> b: http://blog.calebwilliamsphotography.com
> e: ***@gmail.com
> c: 612-275-7796
>



--
*Caleb R. Williams*

*Photographer*
w: http://calebwilliamsphotography.com
b: http://blog.calebwilliamsphotography.com
e: ***@gmail.com
c: 612-275-7796

[Michael T. Pope]

On Sun, 22 Mar 2015 23:30:33 -0500
Caleb Williams <***@gmail.com> wrote:
> > Should/can I delete the whole Documents/FreeCol/freecol/options.xml file?

It is harmless to delete it, but that will remove all your local
settings. Are you sure there are no EuropePanel settings in there,
probably near the end?

Cheers,
Mike Pope

[Caleb Williams]

I found options for:
EuropePanel.w, EuropePanel.h, ...x, ...y.

Both deleting the file and changing the settings manually had no effect.
The width of the Europe panel remains narrow.

Caleb
On Mar 23, 2015 3:22 AM, "Michael T. Pope" <***@computer.org> wrote:

> On Sun, 22 Mar 2015 23:30:33 -0500
> Caleb Williams <***@gmail.com> wrote:
> > > Should/can I delete the whole Documents/FreeCol/freecol/options.xml
> file?
>
> It is harmless to delete it, but that will remove all your local
> settings. Are you sure there are no EuropePanel settings in there,
> probably near the end?
>
> Cheers,
> Mike Pope
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Freecol-developers mailing list
> Freecol-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freecol-developers
>
>

[Michael T. Pope]

On Mon, 23 Mar 2015 09:28:58 -0500
Caleb Williams <***@gmail.com> wrote:
> I found options for:
> EuropePanel.w, EuropePanel.h, ...x, ...y.

Deleting them should have worked. Something weird is happening. Does
reverting back past the last EuropePanel.java changes (say to git.3de6e87)
fix the problem?

Cheers,
Mike Pope

[Caleb Williams]

On Mon, Mar 23, 2015 at 4:05 PM, Michael T. Pope <***@computer.org> wrote:

> On Mon, 23 Mar 2015 09:28:58 -0500
> Caleb Williams <***@gmail.com> wrote:
> > I found options for:
> > EuropePanel.w, EuropePanel.h, ...x, ...y.
>
> Deleting them should have worked. Something weird is happening. Does
> reverting back past the last EuropePanel.java changes (say to git.3de6e87)
> fix the problem?
>
> Cheers,
> Mike Pope
>

All:

I've tried modifying the following:

<integerOption id="net.sf.freecol.client.gui.panel.EuropePanel.w"
value="xxx"/>

For testing, I tried [3de6e8] and [7ef16d] as both revisions occurred
*before* a recent change to the EuropePanel.java file. The former is the
change you specified and the latter is one I tried from February 16, 2015.

For the test, I deleted the options.xml file. I reran the each commit and I
have found that the .EuropePanel.w was replaced with a value of 778. The
only similarity I found with further values was that for .ReportTurnPanel.w
which was the identical value. Changing the value (I changed it to 1000 and
900 for testing) and rerunning FreeCol produced no change in the interface.
The value were not replaced.

I compiled [df01d9] (pre-0.11.0) and found that the update to
"<integerOption id="net.sf.freecol.client.gui.panel.EuropePanel.w"
value="900"/>" had no initial effect. Deleting the options.xml file had not
effect either.

What was interesting to me is that the model.option.playerName value
persists, so despite deleting the relevant .xml file that value persists
somewhere.

Because of that fact, I'm led to believe it's possible that these values
persist somewhere locally. Is that possible, and if so, where?

Thanks,

--
*Caleb R. Williams*

[Caleb Williams]

On Mon, Mar 23, 2015 at 9:40 PM, Caleb Williams <***@gmail.com> wrote:

> On Mon, Mar 23, 2015 at 4:05 PM, Michael T. Pope <***@computer.org>
> wrote:
>
>> On Mon, 23 Mar 2015 09:28:58 -0500
>> Caleb Williams <***@gmail.com> wrote:
>> > I found options for:
>> > EuropePanel.w, EuropePanel.h, ...x, ...y.
>>
>> Deleting them should have worked. Something weird is happening. Does
>> reverting back past the last EuropePanel.java changes (say to git.3de6e87)
>> fix the problem?
>>
>> Cheers,
>> Mike Pope
>>
>
> All:
>
> I've tried modifying the following:
>
> <integerOption id="net.sf.freecol.client.gui.panel.EuropePanel.w"
> value="xxx"/>
>
> For testing, I tried [3de6e8] and [7ef16d] as both revisions occurred
> *before* a recent change to the EuropePanel.java file. The former is the
> change you specified and the latter is one I tried from February 16, 2015.
>
> For the test, I deleted the options.xml file. I reran the each commit and
> I have found that the .EuropePanel.w was replaced with a value of 778. The
> only similarity I found with further values was that for .ReportTurnPanel.w
> which was the identical value. Changing the value (I changed it to 1000 and
> 900 for testing) and rerunning FreeCol produced no change in the interface.
> The value were not replaced.
>
> I compiled [df01d9] (pre-0.11.0) and found that the update to
> "<integerOption id="net.sf.freecol.client.gui.panel.EuropePanel.w"
> value="900"/>" had no initial effect. Deleting the options.xml file had not
> effect either.
>
> What was interesting to me is that the model.option.playerName value
> persists, so despite deleting the relevant .xml file that value persists
> somewhere.
>
> Because of that fact, I'm led to believe it's possible that these values
> persist somewhere locally. Is that possible, and if so, where?
>
> Thanks,
>
> --
> *Caleb R. Williams*
>

Tried a restart.

Same 778 value and model.option.playerName persistence.

Any new tips?

--
*Caleb R. Williams*

[Michael T. Pope]

On Mon, 23 Mar 2015 21:40:57 -0500
Caleb Williams <***@gmail.com> wrote:
> I've tried modifying the following...

Sorry, but I am confused by what you have written here. Has *anything*
worked?

Also, looking at the code again, we should check the value of
model.option.rememberPanelSizes? If false, the EuropePanel.w setting in the
options file will be ignored.

> What was interesting to me is that the model.option.playerName value
> persists

Playername is special, it defaults to the java "user.name" property.
AFAICT no other option behaves like it, so it will only serve to confuse
the issue here.

> Any new tips?

Put a bunch of trace writes into FreeColClient.loadClientOptions to see
when/if EuropePanel.w is loaded/set.

Cheers,
Mike Pope

[Caleb Williams]

On Tue, Mar 24, 2015 at 3:49 AM, Michael T. Pope <***@computer.org> wrote:

> On Mon, 23 Mar 2015 21:40:57 -0500
> Caleb Williams <***@gmail.com> wrote:
> > I've tried modifying the following...
>
> Sorry, but I am confused by what you have written here. Has *anything*
> worked?
>
> Also, looking at the code again, we should check the value of
> model.option.rememberPanelSizes? If false, the EuropePanel.w setting in the
> options file will be ignored.
>
> > What was interesting to me is that the model.option.playerName value
> > persists
>
> Playername is special, it defaults to the java "user.name" property.
> AFAICT no other option behaves like it, so it will only serve to confuse
> the issue here.
>
> > Any new tips?
>
> Put a bunch of trace writes into FreeColClient.loadClientOptions to see
> when/if EuropePanel.w is loaded/set.
>
> Cheers,
> Mike Pope
>

Mike,

Sorry for the confusion.

To clarify, nothing has worked. None of the three revisions I tested
([3de6e8], [7ef16d] and [df01d9]) produced any changes.

model.option.rememberPanelSizes is set to true.

Unfortunately, the trace writes you mention are beyond my level of
expertise.

Thanks,

--
*Caleb R. Williams*

[Michael T. Pope]

On Tue, 24 Mar 2015 17:14:13 -0500
Caleb Williams <***@gmail.com> wrote:
> Sorry for the confusion.
>
> To clarify, nothing has worked. None of the three revisions I tested
> ([3de6e8], [7ef16d] and [df01d9]) produced any changes.

OK, so at least we did not break this recently.

> Unfortunately, the trace writes you mention are beyond my level of
> expertise.

Try something like:

if (clientOptions.getOption("EuropePanel.w") != null) System.err.println("V = " + clientOptions.getInteger("EuropePanel.w")); else System.err.println("Missing");

That would also be interesting in the EuropePanel constructor.

Cheers,
Mike Pope

[Caleb Williams]

On Wed, Mar 25, 2015 at 3:46 AM, Michael T. Pope <***@computer.org> wrote:

> On Tue, 24 Mar 2015 17:14:13 -0500
> Caleb Williams <***@gmail.com> wrote:
> > Sorry for the confusion.
> >
> > To clarify, nothing has worked. None of the three revisions I tested
> > ([3de6e8], [7ef16d] and [df01d9]) produced any changes.
>
> OK, so at least we did not break this recently.
>
> > Unfortunately, the trace writes you mention are beyond my level of
> > expertise.
>
> Try something like:
>
> if (clientOptions.getOption("EuropePanel.w") != null)
> System.err.println("V = " + clientOptions.getInteger("EuropePanel.w"));
> else System.err.println("Missing");
>
> That would also be interesting in the EuropePanel constructor.
>
> Cheers,
> Mike Pope
>

Mike,

I'm not sure where to put that though. Any place I put it in
EuropePanel.java I get the following error message:

illegal start of type
package clientOptions does not exist
<identifier> expected
illegal start of type


I can cut down that to

illegal start of type
<identifier> expected
illegal start of type


by making capitalizing the C in ClientOptions.

Not sure where to go from there. I found
http://stackoverflow.com/questions/3653625/java-illegal-start-of-type but
it was just above my head.

Also, NetBeans reports that:

-
- import java.awt.event.MouseAdapter;
-
- import javax.swing.JLabel;

Are both unused.

Best,

--
*Caleb R. Williams*

[Caleb Williams]

On Mon, Mar 30, 2015 at 4:48 AM, Michael T. Pope <***@computer.org> wrote:

> On Fri, 27 Mar 2015 22:58:34 -0500
> Caleb Williams <***@gmail.com> wrote:
> > I'm not sure where to put that though. Any place I put it in
> > EuropePanel.java I get the following error message:
> >
> > illegal start of type
> > package clientOptions does not exist
> > <identifier> expected
> > illegal start of type
>
> Sorry, in EuropePanel.java clientOptions is not defined, unlike in
> loadClientOptions. Use getClientOptions() instead in EuropePanel.
>
> Cheers,
> Mike Pope
>

Mike,

After: "public void update() {"

I inserted:
final ClientOptions co = getClientOptions();
if (co.getOption("EuropePanel.w") != null) {
logger.warning("V = " + co.getInteger("EuropePanel.w"));
} else {
logger.warning("Missing");
}

I got back "Missing."

Thanks,

--
*Caleb R. Williams*

[w***@genial.ms]

Hi,

as I slowly made some (of the many needed) changes to enable the game having scaling
(see also BR#2726), I made a couple observations and would like to know what you
think about them.

I found I could very easily allow the map to be zoomed in some more (2-3 line change,
if no graphical glitch appears).
Having the tiles be double size should be nice, but should the steps inbetween stay
at 25% of original size? Should I try enabling it?
Would it still look nice or get blocky?

The game is very inconsistent with applying the scale factor (which is saved
in ImageLibrary) when images are needed.
I would think there are only 2 cases/scaling factors needed, anything on the map
and anything else in the GUI. Both exist already and the one for the GUI is currently
always 1, though there are also many images and fonts its not applied to atm, where I
would like to add it. I would assume there is nothing which should never be scaled,
or did I miss anything?

When that is done, next step would be to add scaling for all content (images, fonts),
maybe adding some keybindings like * and / for testing.
That would surely cause many glitches until the layout of all dialogs and panels gets
checked and adapted, which I fear. I hesitate introducing such problems, which could
last for a long time.
Would that interfere with the next release? Would it help to branch the code or only
add more work?

I noticed the game is very inconsistent in the appearance of the GUI. For example:
There are 5 or even more slightly different sizes for the unit images used, which
I would think could be reduced to 3 or maybe even 2?
The dialogs/panels look too different, because the usey different fonts in different
sizes and attributes with different layouts with some using lines inbetween items
and some not. Should it be a long term goal to get it more consistent, so the
headers are same size, same font in same size is used for similar items in different
panels, same layout for the panels showing similar things and so on?


Greetings

wintertime

[Michael T. Pope]

On Sun, 29 Mar 2015 22:14:15 +0200
***@genial.ms wrote:
> as I slowly made some (of the many needed) changes to enable the game having scaling
> (see also BR#2726), I made a couple observations and would like to know what you
> think about them.
>
> I found I could very easily allow the map to be zoomed in some more (2-3 line change,
> if no graphical glitch appears).
> Having the tiles be double size should be nice, but should the steps inbetween stay
> at 25% of original size? Should I try enabling it?
> Would it still look nice or get blocky?

The only way we will really find out is to try it and see.

> The game is very inconsistent with applying the scale factor (which is saved
> in ImageLibrary) when images are needed.
> I would think there are only 2 cases/scaling factors needed, anything on the map
> and anything else in the GUI.

Do not forget the MiniMap.

> Both exist already and the one for the GUI is currently
> always 1, though there are also many images and fonts its not applied to atm, where I
> would like to add it. I would assume there is nothing which should never be scaled,
> or did I miss anything?

How do the predefined images look? (e.g. meeting Aztecs etc) IIRC this
came up a while back when the EuropePanel had a graphical background.

> When that is done, next step would be to add scaling for all content (images, fonts),
> maybe adding some keybindings like * and / for testing.
> That would surely cause many glitches until the layout of all dialogs and panels gets
> checked and adapted, which I fear. I hesitate introducing such problems, which could
> last for a long time.

I am less concerned. This can be done incrementally. Just fix things
one step at a time so that any damage is minimized. It requires
patience, but it works. Trust me on this, I reworked
net.sf.freecol.common.networking.* over the course of nearly a year, and
only occasionally broke things badly enough that anyone noticed:-).

> Would that interfere with the next release?

I do not think so. If you make incremental working changes the trunk
stays releasable with respect to this work. A new release is not urgent
yet either. IIRC a release occurred during the networking rewrite I
mentioned above.

> Would it help to branch the code or only add more work?

How you want to work is your call. All I can add there is that whenever I
have tried to do a big rework in a branch, I get annoyed with trying to
keep it in sync with important bug fixes happening in master. Then, when I
finally merge, there are surprises, usually bad ones. Hence my preference
for small cumulative changes in master, which then get better testing and
yet are still easy to back out.

> I noticed the game is very inconsistent in the appearance of the GUI.

:-) If you look back through the list archives you will see
acknowledgement that FreeCol needs a unified look and feel. You will also
see me backing rapidly away from that project, and the bulk of open bugs
having a "UI" annotation which often indicates that there are look and
feel implications.

> For example:
> There are 5 or even more slightly different sizes for the unit images used, which
> I would think could be reduced to 3 or maybe even 2?

Very likely. I encourage you to try it and see.

> The dialogs/panels look too different, because the usey different fonts in different
> sizes and attributes with different layouts with some using lines inbetween items
> and some not. Should it be a long term goal to get it more consistent, so the
> headers are same size, same font in same size is used for similar items in different
> panels, same layout for the panels showing similar things and so on?

Some dialogs/panels are just special/weird, so there is going to be a
point of diminishing returns here. However you are right that there are a
lot of unnecessarily different special cases. What specifically would you
like to unify?

Cheers,
Mike Pope

[w***@genial.ms]

> Gesendet: Montag, 30. März 2015 um 12:23 Uhr
> Von: "Michael T. Pope" <***@computer.org>
> An: freecol-***@lists.sourceforge.net
> Betreff: Re: [Freecol-developers] The size of dialogs
>
> On Sun, 29 Mar 2015 22:14:15 +0200
> ***@genial.ms wrote:
> > as I slowly made some (of the many needed) changes to enable the game having scaling
> > (see also BR#2726), I made a couple observations and would like to know what you
> > think about them.
> >
> > I found I could very easily allow the map to be zoomed in some more (2-3 line change,
> > if no graphical glitch appears).
> > Having the tiles be double size should be nice, but should the steps inbetween stay
> > at 25% of original size? Should I try enabling it?
> > Would it still look nice or get blocky?
>
> The only way we will really find out is to try it and see.
>
Have you tried it out since I implemented this and is the visual quality good enough?

> > The game is very inconsistent with applying the scale factor (which is saved
> > in ImageLibrary) when images are needed.
> > I would think there are only 2 cases/scaling factors needed, anything on the map
> > and anything else in the GUI.
>
> Do not forget the MiniMap.
>
Thanks, I'll think of it.
I also found many places using the ImageLibrary in GUI interchangably with the one in
GUI.colonyTileMapViewer, which I corrected yesterday.

> > Both exist already and the one for the GUI is currently
> > always 1, though there are also many images and fonts its not applied to atm, where I
> > would like to add it. I would assume there is nothing which should never be scaled,
> > or did I miss anything?
>
> How do the predefined images look? (e.g. meeting Aztecs etc) IIRC this
> came up a while back when the EuropePanel had a graphical background.
>
I applied the scaling factor to many more images meanwhile and checked by temporarily
having GUI create the ImageLibrary with a scaling factor of 2 and the opening all
panels and subpanels I could get access to from the menus, which already lead to some
improvements.

Its difficult for me to check the dialogs which show up only on specific circumstances.
Is there already any easier way to show them than playtesting for weeks? If not, some
debug code may need to get added to show these on demand.

> > Would it help to branch the code or only add more work?
>
> How you want to work is your call. All I can add there is that whenever I
> have tried to do a big rework in a branch, I get annoyed with trying to
> keep it in sync with important bug fixes happening in master. Then, when I
> finally merge, there are surprises, usually bad ones. Hence my preference
> for small cumulative changes in master, which then get better testing and
> yet are still easy to back out.
>
Yes, I already try to avoid holding on to code privately to avoid merge conflicts.
I think when it gets unavoidable I'll make a branch containing only the absolute
minimum of code to activate the half-implemented feature and regularly rebase and
force-push it, if that is an acceptable thing to do?

> > For example:
> > There are 5 or even more slightly different sizes for the unit images used, which
> > I would think could be reduced to 3 or maybe even 2?
>
> Very likely. I encourage you to try it and see.
>
For now I got most scaling factors for images centralized in ImageLibrary and
only took away single use sizes. But I hope the number can get reduced easier
now, though still needs checking if the panels wont get glitched on each change.

> Some dialogs/panels are just special/weird, so there is going to be a
> point of diminishing returns here. However you are right that there are a
> lot of unnecessarily different special cases. What specifically would you
> like to unify?
>
The Indian advisor panel is showing most differences to other panels.
The small version of the headerfont is only used in a few other panels and
many dont use it. This could be made more consistent, though I'm unsure if
it should be removed or used more on other panels for subheaders.
Also its the only panel currently using a bold version of the normal font
for subsubheaders, which could be used on other panels, too.

And many panels could get a bit reformatted to look more consistent.

> Cheers,
> Mike Pope
>

Regards

wintertime

[Caleb Williams]

On Apr 4, 2015 7:02 AM, <***@genial.ms> wrote:
>
> > Gesendet: Montag, 30. MÀrz 2015 um 12:23 Uhr
> > Von: "Michael T. Pope" <***@computer.org>
> > An: freecol-***@lists.sourceforge.net
> > Betreff: Re: [Freecol-developers] The size of dialogs
> >
> > On Sun, 29 Mar 2015 22:14:15 +0200
> > ***@genial.ms wrote:
> > > as I slowly made some (of the many needed) changes to enable the game
having scaling
> > > (see also BR#2726), I made a couple observations and would like to
know what you
> > > think about them.
> > >
> > > I found I could very easily allow the map to be zoomed in some more
(2-3 line change,
> > > if no graphical glitch appears).
> > > Having the tiles be double size should be nice, but should the steps
inbetween stay
> > > at 25% of original size? Should I try enabling it?
> > > Would it still look nice or get blocky?
> >
> > The only way we will really find out is to try it and see.
> >
> Have you tried it out since I implemented this and is the visual quality
good enough?
Personally, I didn't think the quality held up much beyond the previous max
zoom in.

It basically looked about the same as zooming into an image more than 100%:
each pixel of data now takes up more than 1 pixel of screen.

If the size of the base images could increase (four-fold?), then that might
allow zooming in further to hold up.

Best,

Caleb

[Caleb Williams]

>
> The Indian advisor panel is showing most differences to other panels.
> The small version of the headerfont is only used in a few other panels and
> many dont use it. This could be made more consistent, though I'm unsure if
> it should be removed or used more on other panels for subheaders.
> Also its the only panel currently using a bold version of the normal font
> for subsubheaders, which could be used on other panels, too.
>
> And many panels could get a bit reformatted to look more consistent.


To that end, I submitted a simple change for ReportForeignAffairPanel.java
(already committed
<https://sourceforge.net/p/freecol/git/ci/be09d91f366936f58c3be64a7aae890b5b4af8d2/>
by wintertime) and improved the JavaDoc for FontLibary.java. Built the
subsequent JavaDoc and it seemed to work, but I think createFont needs to
be annotated as well.

Best,

--
*Caleb R. Williams*

[Caleb Williams]

Please note that as of Wintertime's commit of [0d61c7
<https://sourceforge.net/p/freecol/git/ci/0d61c7292641e9f3c2f43d93d0b24b12319f8e61/>],
my issues with EuropePanel is now fixed.

--
Caleb R. Williams

[w***@genial.ms]

Hi,

the savegame you sent me was what finally prompted me to fix it.
A whole part of the Europe Panel was missing.
I had seen some of this already, but never saw it being that bad.
The problem is the game saving the sizes of some old version and
when you fix something in the GUI it resizes the panels to bad, old
sizes.
What makes it worse is if you deactivate saveing the size with the
option it stops both loading and saving and when you finally
reactivate it it find some ancient size that was never updated.
I would prefer changing it to always save it and just not load it,
but the otion is called REMEMBER_PANEL_SIZES and not LOAD_PANEL_SIZES.
I'd like to get the Europe Panel resizable btw..


Greetings,

wintertime


> Gesendet: Mittwoch, 08. April 2015 um 19:02 Uhr
> Von: "Caleb Williams" <***@gmail.com>
> An: "FreeCol Developers" <freecol-***@lists.sourceforge.net>
> Betreff: Re: [Freecol-developers] The size of dialogs

> Please note that as of Wintertime's commit of
> [0d61c7[https://sourceforge.net/p/freecol/git/ci/0d61c7292641e9f3c2f43d93d0b24b12319f8e61/]],
> my issues with EuropePanel is now fixed.
> --
> Caleb R. Williams

[w***@genial.ms]

> I'd like to get the Europe Panel resizable btw..
>
I can not figure out why the EuropePanel is not resizable, but
the ColonyPanel is resizable.
Both derive from PortPanel, so that cant make a difference, and
I could not find any obvious call inside either to make one
resizable or not resizable.
Any idea why?


Greetings,

wintertime

[Michael T. Pope]

On Wed, 8 Apr 2015 19:23:56 +0200
***@genial.ms wrote:
> I had seen some of this already, but never saw it being that bad.
> The problem is the game saving the sizes of some old version and
> when you fix something in the GUI it resizes the panels to bad, old
> sizes.

> What makes it worse is if you deactivate saveing the size with the
> option it stops both loading and saving and when you finally
> reactivate it it find some ancient size that was never updated.
> I would prefer changing it to always save it and just not load it,

I do not see the advantage. If you save it but never load it, the save
was pointless. What do you propose that is better than the current on/off
situation?

> but the otion is called REMEMBER_PANEL_SIZES and not LOAD_PANEL_SIZES.

(Assuming that the option is enabled):
We want panels to stay the same size after a user resizes them. If a
panel is the wrong size (for whatever reason including loading an old
broken value) the user should be able to resize the panel and the problem
is fixed. Clearly there are problems with the current code. However
there was a user request for this functionality, and some people
apparently like it (myself included for some panels at least), so I think
we should make it work.

> I can not figure out why the EuropePanel is not resizable,

Neither can I. Perhaps its the magic shrink/grow options in ColonyPanels
MigLayout that make it different? I have never really understood
MigLayout and did not write the panel code.

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

> Gesendet: Freitag, 10. April 2015 um 00:19 Uhr
> Von: "Michael T. Pope" <***@computer.org>
> An: freecol-***@lists.sourceforge.net
> Betreff: Re: [Freecol-developers] The size of dialogs
>
> On Wed, 8 Apr 2015 19:23:56 +0200
> ***@genial.ms wrote:
> > What makes it worse is if you deactivate saveing the size with the
> > option it stops both loading and saving and when you finally
> > reactivate it it find some ancient size that was never updated.
> > I would prefer changing it to always save it and just not load it,
>
> I do not see the advantage. If you save it but never load it, the save
> was pointless. What do you propose that is better than the current on/off
> situation?
>
> > but the otion is called REMEMBER_PANEL_SIZES and not LOAD_PANEL_SIZES.
>
> (Assuming that the option is enabled):
> We want panels to stay the same size after a user resizes them. If a
> panel is the wrong size (for whatever reason including loading an old
> broken value) the user should be able to resize the panel and the problem
> is fixed. Clearly there are problems with the current code. However
> there was a user request for this functionality, and some people
> apparently like it (myself included for some panels at least), so I think
> we should make it work.
>
> > I can not figure out why the EuropePanel is not resizable,
>
Sorry, I should have made myself more clear. What I meant was I wanted to
keep the functionality, but improve it.

The scenario I'd like to see fixed is someone having the option to save the
panel sizes activated at start, then they are saved, then he decides on
turning the option off, then several months pass where the gamecode changes,
then the person decides to reactivate the option and suddenly the game
loads some incompatible or very bad looking values the user has forgotten
about long ago and completely different from the look he played with for
a long time, making him assume the game is suddenly broken.
The change would entail either removing all panel sizes from saves done while
the option is off or, what I tried to say earlier, to continuously update the
saved values like its done for all other options for keeping compatibility,
to have recent values loaded when the option gets switched on again.

The change I made already mitigates this to some extent and is necessary for
the many savegames currently out there having broken panel sizes, though it
also prevents the user from conciously choosing a smaller panel size, so I
would like to revisit it, if the other proposed change can be made, to
slightly loosen the constraints.

> Neither can I. Perhaps its the magic shrink/grow options in ColonyPanels
> MigLayout that make it different? I have never really understood
> MigLayout and did not write the panel code.
>
> Cheers,
> Mike Pope
>
I already read about these MigLayout options, but the documentation I found
feels incomplete, in that it mostly advertises just the more commonly used
options and does not tell about this specific case.


Regards,

wintertime

[w***@genial.ms]

Hi all,

my long going efforts to get the code in shape for having the whole GUI
resizable are beginning to pay off.
You could check out the current state, when you apply the attached diff!

It looks mostly presentable, though weird in some places.
I put most effort into getting the Map, InfoPanel, ColonyPanel,
EuropePanel, ReportPanels, Colopedia and their subpanels presentable.
Some places, like views of tiles in Panels and header text, are
intentionally not scaled atm., to avoid breaking.
It would be nice if you could try it out and tell me about broken dialogs,
especially the ones randomly appearing for all kinds of game events,
as I was only coding and not playing!

I think the method for activating it would be best done same as the map
scaling, by adding hotkeys and menu items. I'd like to know from you if
something needs to be done before its in a good enough shape to add these
soon, for everyone to enjoy it. So, please try it out!

Btw., I saw in the old SVN repo some nice highres base art, which could
be checked out to get some better looking versions of many images with
higher, standardized resolutions to avoid upscaling.
For example, I saw the gorgeous image of the fur trapper, which the tiny
icons we currently use are not giving justice to.
For the forest and mountain images I'm not sure if there are better ones.


Greetings,

wintertime

[Michael T. Pope]

On Sun, 12 Apr 2015 18:44:18 +0200
***@genial.ms wrote:
> It looks mostly presentable, though weird in some places.
> I put most effort into getting the Map, InfoPanel, ColonyPanel,
> EuropePanel, ReportPanels, Colopedia and their subpanels presentable.

Just be wary of the sizing. We still claim to support a minimum
resolution of 1024x768, but there have been a few commits containing line
like this:

getGUI().restoreSavedSize(this, 1050, 725);

> Some places, like views of tiles in Panels and header text, are
> intentionally not scaled atm., to avoid breaking.
> It would be nice if you could try it out and tell me about broken dialogs,
> especially the ones randomly appearing for all kinds of game events,
> as I was only coding and not playing!

I am stuck in the messages clean up for now. I hope to get back to play
testing after that.

> Btw., I saw in the old SVN repo some nice highres base art, which could
> be checked out to get some better looking versions of many images with
> higher, standardized resolutions to avoid upscaling.
> For example, I saw the gorgeous image of the fur trapper, which the tiny
> icons we currently use are not giving justice to.

If there is a way to use higher resolution base images, please proceed.

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

> Gesendet: Montag, 13. April 2015 um 11:15 Uhr
> Von: "Michael T. Pope" <***@computer.org>
> An: freecol-***@lists.sourceforge.net
> Betreff: Re: [Freecol-developers] The size of dialogs
>
> On Sun, 12 Apr 2015 18:44:18 +0200
> ***@genial.ms wrote:
> > It looks mostly presentable, though weird in some places.
> > I put most effort into getting the Map, InfoPanel, ColonyPanel,
> > EuropePanel, ReportPanels, Colopedia and their subpanels presentable.
>
> Just be wary of the sizing. We still claim to support a minimum
> resolution of 1024x768, but there have been a few commits containing line
> like this:
>
> getGUI().restoreSavedSize(this, 1050, 725);
>
As I wrote at the end of the commit message (which was a bit long so you
may not have seen it completely without intentionally sidescrolling), that
is only a preferred size, and I tested that when you start the game with
"--windowed 1024x768" or even "--windowed 800x600" these panels automatically
resize themselves to just fill all available space below the menu.
Actually people playing at such small resolution will have a better
experience now through my changes, as I made sure most panels internally
adapt, where before they would just cut off parts.
The exceptions I know of are the once per game shown declaration dialog
(with all those options for choosing your flag) and the Continental Congress
Report (it could have the ok-button cut off still, which I tried to fix,
but it resists).
The End Turn Dialog looks mostly acceptable, but it got my attention as the
sizes seem all fixed and it is even more resistant to all changes I tried,
even just to have te icon shown better.

> I am stuck in the messages clean up for now. I hope to get back to play
> testing after that.
>
I hope Caleb can give it a try then?
Naturally, it would later be only an optional thing with a few steps, maybe
normal 1x, 1.25x, 1.5x, 1.75x and up to 2x; the diff you can use with
"git apply" is just the simplest way to have it show up before that code
is written.

> > Btw., I saw in the old SVN repo some nice highres base art, which could
> > be checked out to get some better looking versions of many images with
> > higher, standardized resolutions to avoid upscaling.
> > For example, I saw the gorgeous image of the fur trapper, which the tiny
> > icons we currently use are not giving justice to.
>
> If there is a way to use higher resolution base images, please proceed.
>
Well, its certainly possible, but there would be a long list of tasks:
- Someone would need to go through and see exactly which of the currently
used images are in the repo and make a list of corresponding file names
and folders and available sizes.
- Some investigation needs to be done which image resolutions would be
best, to have all be consistent and fitting to how they are used.
- Some intelligent logic would need to be added to the Resource management
and maybe also the way filenames for images are generated (as there would
need to be multiple names for same image at different resolutions).
- Most code using the images would need to be adapted, as it implicitly
assumes some base size for each image and then applies a scale factor,
which intermingles the needed size with the implicit assumption of the
size in the specific loaded file.
- Someone with access to photoshop (or I dont know if you can use those
.psd files with something else) would need to go through the lists
and crop, resize and save at the needed resolutions (multiple per image,
either exactly as needed, or like its done for mipmaps).

> Cheers,
> Mike Pope
>

Regards,

wintertime

[Caleb Williams]

All:

As I wrote at the end of the commit message (which was a bit long so you
> may not have seen it completely without intentionally sidescrolling), that
> is only a preferred size, and I tested that when you start the game with
> "--windowed 1024x768" or even "--windowed 800x600" these panels
> automatically resize themselves to just fill all available space below the
> menu.
>

Link to commit?


> The End Turn Dialog looks mostly acceptable, but it got my attention as
> the sizes seem all fixed and it is even more resistant to all changes I
> tried, even just to have te icon shown better.
>

Agreed, the End Turn panel does look better, especially now that the icons
don't move when you click on them.

> I am stuck in the messages clean up for now. I hope to get back to
> play > testing after that.
>

Once you're complete with that messages cleanup and WT's continued cleanup
of the GUI and panel changes (hopefully I'll be able to do a bit of work on
that this week as well), would it be time for the next release?


> I hope Caleb can give it a try then?
> Naturally, it would later be only an optional thing with a few steps, maybe
> normal 1x, 1.25x, 1.5x, 1.75x and up to 2x; the diff you can use with
> "git apply" is just the simplest way to have it show up before that code
> is written.


I can try it out perhaps later today, but I don't know for sure. I actually
tried last night, but Git Extentions wanted a patch file and I didn't want
to load NetBeans at the time.

--
*Caleb R. Williams*

[Michael T. Pope]

On Mon, 9 Mar 2015 16:48:35 +1030
"Michael T. Pope" <***@computer.org> wrote:
> Now that 0.11.3 is out I am looking through the list of issues I had put
> aside. One of them is the question of whether dialogs/panels/whatever
> should be resizable or not. What do people think? What we have ATM is
> not consistent, and does not seem to be guided by any underlying
> principles. Any suggestions for what these should be?

This discussion got buried without resolution. However after re-reading
the thread it is clear that there is more support for making dialogs
resizeable than for fixed sizes, if only to allow the user to work around
strange window sizes, scales and bugs.

Therefore unless a strong counter-argument appears, I think we should
start transitioning to resizeable dialog/panels. To that end, now that
EuropePanel is resizeable, can we have some comment from wintertime about
how that was done, and/or some general remarks about good practice for
enabling resizeability?

And yes, with the principle decided, I think we can now close BR#459
as "wont fix".

Cheers,
Mike Pope

[w***@genial.ms]

Hi,

the biggest problem in making it resizable was finding where in the code,
as its not in the panels. After I found out its buried in Canvas, it was
as simple as changing an enum or boolean value in the right method there.
Thats because creating the JInternalFrame is centralized in Canvas and
the panels are created and added in there, too.
Even stranger is that the JDialogs, that are basically a non-internal
empty AWT Window with modality methods, are not created in Canvas and a
FreeColDialog is a JDialog, when the equivalent of the JPanel used in
panels is the JOptionPane the dialogs only contain.

As said earlier, I was in favor of closing this old tracker item.
Everything possible should be resizable (tiny tooltips should auto-size),
but there is one exception.
We have a special dialog with a premade skin, which is only available
in a single size. This is btw the one where the SVN contains different
versions with the upper half of different people leaning over the top
of the diaog skin. Would you want to keep the single one, add more
of them or remove it?

There is one other complication with JInternalFrames, that got made non-
resizable. This created the bug where in the panel contructor a call to
Canvas.RestoreWindowSize was made, which could load bad sizes the users
were then stuck with (missing buttons and more). You had this patch to
add this call to more of the panels, and this is what delayed it.

There is some classes where getSize, getPreferredSize or getMaximumSize
is overridden to get a fixed size. I consider this a bad hack and removed
most of these, but some still remain (eg Colopedia Tree).
Normally one just calls setPreferredSize in contructor and thats it;
sometimes the layout creation can be adapted a bit.
The rebel tooltip in colony panel somehow did resist such change though,
when I tried to make it auto-size to fit its content.

There still remains the need to check many rarely used gui elements for
there sizing behaviour, but that might take a long time.


Regards,

wintertime


> Gesendet: Sonntag, 17. Mai 2015 um 08:22 Uhr
> Von: "Michael T. Pope" <***@computer.org>
> An: freecol-***@lists.sourceforge.net
> Betreff: Re: [Freecol-developers] The size of dialogs
>
> On Mon, 9 Mar 2015 16:48:35 +1030
> "Michael T. Pope" <***@computer.org> wrote:
> > Now that 0.11.3 is out I am looking through the list of issues I had put
> > aside. One of them is the question of whether dialogs/panels/whatever
> > should be resizable or not. What do people think? What we have ATM is
> > not consistent, and does not seem to be guided by any underlying
> > principles. Any suggestions for what these should be?
>
> This discussion got buried without resolution. However after re-reading
> the thread it is clear that there is more support for making dialogs
> resizeable than for fixed sizes, if only to allow the user to work around
> strange window sizes, scales and bugs.
>
> Therefore unless a strong counter-argument appears, I think we should
> start transitioning to resizeable dialog/panels. To that end, now that
> EuropePanel is resizeable, can we have some comment from wintertime about
> how that was done, and/or some general remarks about good practice for
> enabling resizeability?
>
> And yes, with the principle decided, I think we can now close BR#459
> as "wont fix".
>
> Cheers,
> Mike Pope
>

[Michael T. Pope]

On Sun, 17 May 2015 09:32:17 +0200
***@genial.ms wrote:
> the biggest problem in making it resizable was finding where in the code,
> as its not in the panels. After I found out its buried in Canvas, it was
> as simple as changing an enum or boolean value in the right method there.
> Thats because creating the JInternalFrame is centralized in Canvas and
> the panels are created and added in there, too.

That explains why I never found it.

> Everything possible should be resizable (tiny tooltips should auto-size),
> but there is one exception.
> We have a special dialog with a premade skin, which is only available
> in a single size. This is btw the one where the SVN contains different
> versions with the upper half of different people leaning over the top
> of the diaog skin. Would you want to keep the single one, add more
> of them or remove it?

It would be nice if we could use that again, but I do not consider it high
priority. Fixing the scaling was much more important.

> There is one other complication with JInternalFrames, that got made non-
> resizable. This created the bug where in the panel contructor a call to
> Canvas.RestoreWindowSize was made, which could load bad sizes the users
> were then stuck with (missing buttons and more). You had this patch to
> add this call to more of the panels, and this is what delayed it.

I think all resizeable panels should in general have a call to
restoreWindowSize somewhere. I am not worried about restoring an old
broken size as long we enforce sensible minimum values and overwrite
the broken saved value when the user resizes the panel to something
sensible. I realize this is not happening ATM.

> There is some classes where getSize, getPreferredSize or getMaximumSize
> is overridden to get a fixed size. I consider this a bad hack and removed
> most of these, but some still remain (eg Colopedia Tree).

I never understood why they were there, and am not sorry to see them go.
FreeCol dates back to 2002, there may well be code that was once needed in
old versions of Java.

> Normally one just calls setPreferredSize in contructor and thats it;
> sometimes the layout creation can be adapted a bit.

I suspect we should set a minimum size to prevent users from messing
themselves up.

> There still remains the need to check many rarely used gui elements for
> there sizing behaviour, but that might take a long time.

This is worth doing, but urgency is low.

Cheers,
Mike Pope