[Freecol-developers] Panels as own windows

[Enrico Weigelt, metux IT consult]

Hi folks,


I'd like to have the various panels (eg. colony view) as separate
windows (instead of frames within the main window) for better usability
(eg. keeping some panels open on a separate workspace, and keep the map
view visible, etc)

It seems that swing only supports that for JDialog - and the panels are
derived from JPanel, which is pretty differrent, thus would need a lot
rework in the whole GUI architecture.

The situation gets even more complex, if both modes should be supported
(client setting, etc) - in that case we'd need an bridge layer which
can create both kind of panels.

Any ideas on that ?


--mtx

[w***@genial.ms]

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).
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.



Regards,

wintertime



> Gesendet: Mittwoch, 25. Januar 2017 um 07:20 Uhr
> Von: "Enrico Weigelt, metux IT consult" <***@gr13.net>
> An: Freecol-***@lists.sourceforge.net
> Betreff: [Freecol-developers] Panels as own windows
>
> Hi folks,
>
>
> I'd like to have the various panels (eg. colony view) as separate
> windows (instead of frames within the main window) for better usability
> (eg. keeping some panels open on a separate workspace, and keep the map
> view visible, etc)
>
> It seems that swing only supports that for JDialog - and the panels are
> derived from JPanel, which is pretty differrent, thus would need a lot
> rework in the whole GUI architecture.
>
> The situation gets even more complex, if both modes should be supported
> (client setting, etc) - in that case we'd need an bridge layer which
> can create both kind of panels.
>
> Any ideas on that ?
>
>
> --mtx

[Enrico Weigelt, metux IT consult]

On 25.01.2017 15:23, ***@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

[Caleb Williams]

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: ***@gmail.com
c: 612-275-7796

On Wed, Jan 25, 2017 at 11:42 PM, Enrico Weigelt, metux IT consult <
***@gr13.net> wrote:

> On 25.01.2017 15:23, ***@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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freecol-developers
>

[w***@genial.ms]

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" <***@gmail.com>
> An: "FreeCol Developers" <Freecol-***@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: ***@gmail.com
> c: 612-275-7796
>
> On Wed, Jan 25, 2017 at 11:42 PM, Enrico Weigelt, metux IT consult <
> ***@gr13.net> wrote:
>
> > On 25.01.2017 15:23, ***@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-***@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-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freecol-developers
>

[Enrico Weigelt, metux IT consult]

On 27.01.2017 10:47, ***@genial.ms wrote:

Hi,

> 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 ).

it seems we're mixing up several orthogonal things in one discussion,
so let's try to sort things out:

#1 fullscreen mode can mean two different things

a) <FULLSCREEN>: the window occupies the whole screen / client area.
b) <EXCLUSIVE>: application gets exclusive access to the frame
buffer (possibly changing display mode, etc)

While <FULLSCREEN> is just a trival matter of resizing and decorations
(actually, pretty much which J2D does when b) is not available -
"emulated mode"), <EXCLUSIVE> is pretty obsolete nowadays - it was a
performance workaround when there was no hw composition of separate
(userland-accessible) framebuffers. (even a simple onchip i915 can do
that - embedded socs usually have hw overlays at the scanout unit,
which makes it even easier an cheaper).

The bad side of <EXCLUSIVE>: it doesn't play well w/ other windows,
which seems is what several people complained about.

Ergo: we can safely drop <EXCLUSVE>
(yet to check: GraphicsDevice::setFullscreenWindow() still needed ?)

#2: nested vs. toplevel windows

That really seems to be a matter of individual taste. IIRC, some of
the complaints actually are feature requests for having all windows
nested (even the dialogs). OTOH, I'd prefer the classical multi-
window approach.

Ergo: that should be the user's choice.


--mtx