Hi, I am not sure which of the mentioned things you would like to see; can you be more explicit?
Btw., I would not like abandoning fullscreen mode completely. Its enough that we had to switch the default to windowed because of the mentioned bugs. I would like to see if you could easily and consistently switch all subwindows between internal and external though, as we already have 2 systems for dialogs and panels ( which are largely incompatible though atm ). Greetings, wintertime > Gesendet: Donnerstag, 26. Januar 2017 um 19:13 Uhr > Von: "Caleb Williams" <cale...@gmail.com> > An: "FreeCol Developers" <Freecol-developers@lists.sourceforge.net> > Betreff: Re: [Freecol-developers] Panels as own windows > > 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 > ------------------------------------------------------------------------------ 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
