TBH, if this is a project you want to tackle, this could be a tremendous
help to moving FreeCol forward. The lack of Windows testing/developers has
hampered this effort.
*Caleb R. Williams*
*Photographer*
w: http://calebwilliamsphotography.com
b: http://blog.calebwilliamsphotography.com
e: cale...@gmail.com
c: 612-275-7796
On Wed, Jan 25, 2017 at 11:42 PM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:
> On 25.01.2017 15:23, win...@genial.ms wrote:
>
> Hi,
>
> > reading the last paragraph of the blue text above the bug-tracker at
> > https://sourceforge.net/p/freecol/bugs/ should give you the reason
> > why doing this would be a very bad idea, as making even more subwindows
> > succeptible to the problems with JDialog is not something desirable.
> > Reading both of the linked BR gives you even more information on that
> > (BR#2328 and BR#2729).
>
> That really seems to be a bug in certain JRE versions on Windows, in
> combination w/ fullscreen.
>
> OTOH, the fullscreen mode (in contrast to fullscreen-sized window)
> shouldn't be required anymore. On older windows versions, as well as
> early (pre KSM/DRM) accelerated Xservers, the accelerated rendering
> was a lot faster, as composition could be entirely bypassed and no
> gpu command stream filtering was required (they did the composition
> just by copying-around the already rendered frames into the main
> frame buffer). Later on, the composition was done at either by command
> stream rewriting (old hw) or employing hw composition (some gpus/ipus
> do that entirely on their own, for others you'd employ an dma engine).
>
> Nowadays the situation is even more relaxed (even on embedded SOCs),
> when gpu is behind an iommu and supports real multitasking (just like
> cpus w/ mmu) - here we can just run separate tasks per application
> and push in the unfiltered command streams, and let the hw do the rest.
>
> Ergo: just drop the fullscreen mode at all and use a maximized
> (undecorated) window instead.
>
> > If you'd want to work on such conversions, please, do the opposite
> > of your idea and make more panels/dialogs use JInternalFrame instead
> > of JDialog, which would be a highly desired but lengthy and difficult
> > task.
>
> That would be the opposite of my goal. I'm concerned about usability
> here. In the current situation, the panels always overlap the map view
> and cannot be moved to a separate vdesktop (or even screen), which in
> turn one of the most annyoing problems for me.
>
> Meanwhile I did a litle bit hacking: just wrapping panels in JDialogs.
> The change ist pretty minimal: instead of calling showSubPanel(),
> added an showPopupPanel(), which does the wrapping. That then would
> be the place where the user setting can be handled, so the user can
> decide which way he wants.
>
> I'll yet have to find a (minimal-intrusive) way for handling the close
> button, and prevent it from always moving back these windows to the
> vdeskop of the main window (probably JDialog isn't the right class).
>
>
> --mtx
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Freecol-developers mailing list
> Freecol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freecol-developers
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Freecol-developers mailing list
Freecol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freecol-developers
