On Sun, 17 May 2015 09:32:17 +0200 win...@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
pgpuoyZGYsyk_.pgp
Description: OpenPGP digital signature
------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________ Freecol-developers mailing list Freecol-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freecol-developers
