MAPVIEW upgrade

[kevL]

excellent ...

Same conditions of course if you run Release\Mapview.exe.

great ...

Looks like is VS2019 debugging being quite picky,

grr...

( note i use SharpDevelop, not VS -- I'm a fan of lightweight apps that do the job, although #develop has been discontinued )

it made Mono builds much stable.

sounds about as good as it's going to get at present.

Ok, now we have (or better, you have) settled this, here's a purely cosmetic thing...

Could we have the UseMono also for TopView and TileView? So we can avoid all of those black backgrounds...

And... yes I tried to implement some if(UseMono) but the classes which contain it are internal sealed or private readonly and so can't use same classes from PckView-TopView-etc. I don't want to make a disaster with classes inheritance just for this

black backgrounds? i had't heard about that yet

you should be able to get the value of "UseMono" in TopView, TopPanel, TileView etc etc. like so

Code: [Select]

    if (MainViewF.Optionables.UseMono)

The MainViewF.Optionables pointer is internal static which means it can be accessed easily anywhere within the MapView project. But it can't be accessed from external projects like PckView or McdView -- that'd result in cyclical dependencies ...

If you really want the value of "UseMono" in an external project (PckView/McdView eg.), I believe it should be parsed directly out of the settings/MapConfig.cfg file, like has been done for the value of "SpriteShade" for use in PckView. The settings in the MapConfig file ordinarily pertain only to MapView (internally) itself.


i've got another project that's been on hold, i think i'm going to bang my head against that for a while But if you need a hint or tip on mapview's inner workings just ask,


ps. Monodevelop, I'm guessing, doesn't like getting SystemInformation.DoubleClickTime for whatever reason ... (it is a windows-specific setting but regardless i'm guessing that Linux and Mac have a very similar system-setting that Mono could replace it with)

[osd_daedalus]

black backgrounds? i had't heard about that yet

check the screenshot attached
The top windows are on Windows, the bottom ones on Linux with Mono.

you should be able to get the value of "UseMono" in TopView, TopPanel, TileView etc etc. like so

Code: [Select]

    if (MainViewF.Optionables.UseMono)

The MainViewF.Optionables pointer is internal static which means it can be accessed easily anywhere within the MapView project. But it can't be accessed from external projects like PckView or McdView -- that'd result in cyclical dependencies ...

If you really want the value of "UseMono" in an external project (PckView/McdView eg.), I believe it should be parsed directly out of the settings/MapConfig.cfg file, like has been done for the value of "SpriteShade" for use in PckView. The settings in the MapConfig file ordinarily pertain only to MapView (internally) itself.


i've got another project that's been on hold, i think i'm going to bang my head against that for a while But if you need a hint or tip on mapview's inner workings just ask,

I can't guarantee, but I'll gladly attempt to work on it

[kevL]

i uh, I couldn't wish that on my ex-girlfriends JUST KIDDING

seriously, i was thinking it was just some BackColors that were black ... but those sprites need to be drawn with a custom algorithm. it's been fixed in MainView already (the app was basically unusable in Mono with black rectangles all over) -- since I know how to do i'll rig it up fairly quickly,



EDIT
hopefully the latest commit will take care of those black backgrounds

as you see it's fairly complicated, or at least nontrivial ...

If you want to see what the fix is at its core, have a look at MapView.CuboidSprite -- functions with "Rembrandt" are regular .net draw routines, those with "Picasso" implement the transparency workaround. In short, pixels that are transparent aren't drawn; the binary data (byte arrays) of each sprite is iterated over, checking for non-zero/non-transparent color-ids

drawing to MainView has to scale each sprite, but the sprites in TileView and TopView are 1:1

I took the opportunity to consolidate redundant code in TopView's Quadrant panel also ...

i didn't test it thoroughly, so please check it (esp. in Mono w/ "UseMono" true),

and if by chance you want to see the full glory, so to speak, of the workaround have a look at MainViewOverlay.OnPaint() -- but don't get confused by #LOCKBITS, since that's purely experimental, non-functional code

[kevL]

@daedalus

If you want something to try your hand at, try docking TopView's toolstrip to the top of its container if Mono (cf. screenshot)

[osd_daedalus]

Hi,

well... was much difficult than I expected... I looked at Rembrandt() and Picasso(), but I have thought it was just a matter of interpolation.

Going to testing: now Mono builds behave liks Windows builds. Well done!

Maybe I could manage to dock that toolstrip, and find a better Copy icon, it is so blended with the background it's almost transparent!

[kevL]

now Mono builds behave liks Windows builds

alrightie. Perhaps we've got decently functioning code on Mono (built natively )

Maybe I could manage to dock that toolstrip,

first just drag& drop the toolstrip to the top while running Mapview. In windows, those toolstrips can be repositioned to any of the four sides, and they line the icons either vertically (on the left or right) or horizontally (if on top or bottom, of the panel). There should be a handle at the very left (or top) end of the toolstrip ... the toolstrip should snap into place when moved.

I'm wondering/hoping that Mono positions them better along the top of the panel

and find a better Copy icon, it is so blended with the background it's almost transparent!

y, i notice that also. I think it's just a matter of increasing contrast/saturation (but haven't gotten around to it yet). I like the icons themselves tho .....

[osd_daedalus]

first just drag& drop the toolstrip to the top while running Mapview.

Looks like "that" is the issue...

https://stackoverflow.com/questions/4986087/does-not-move-toolstrip
 
Although very old, I checked and looks like still true: you cannot drag&drop toolstrips in Mono.

So... nothing to do that way. I'm going to look for another workaround...

[kevL]

hrm. it looks to me like TopView(.Designer) 'tscPanel' -- ToolStripContainer object -- will need to be instantiated and added to the TopView panel in the constructor, so that the LeftToolStripPanel and the TopToolStripPanel can be switched, based on if "UseMono" is true.

at the moment, this is the relevant line in TopView.Designer

Code: [Select]

    this.tscPanel.LeftToolStripPanel.Controls.Add(this.tsTools);

'tsTools' is the toolstrip we're talkin' about


/gonna get some sleep atm..

might also add some code to the UseMono setter/changer in order to switch positions while the app is running, or just use the preprocessor directive #ifdef __Mono__ (or whatever it is ) to decide whether to put the toolstrip at the side or at the top.

[osd_daedalus]

hrm. it looks to me like TopView(.Designer) 'tscPanel' -- ToolStripContainer object -- will need to be instantiated and added to the TopView panel in the constructor, so that the LeftToolStripPanel and the TopToolStripPanel can be switched, based on if "UseMono" is true.

at the moment, this is the relevant line in TopView.Designer

Code: [Select]

    this.tscPanel.LeftToolStripPanel.Controls.Add(this.tsTools);

'tsTools' is the toolstrip we're talkin' about


/gonna get some sleep atm..

might also add some code to the UseMono setter/changer in order to switch positions while the app is running, or just use the preprocessor directive #ifdef __Mono__ (or whatever it is ) to decide whether to put the toolstrip at the side or at the top.

That, or even to get rid of that left toolstrip and convert their options in buttons like in the RouteView program.

[kevL]

That, or even to get rid of that left toolstrip and convert their options in buttons like in the RouteView program.

good idea (see screenshot)

but that would take a while, so for now ->
https://github.com/kevL/OpenXCOM.Tools/commit/57dadca3ff3a0ae5e1f39b0e6b4cafebe36e0e85

[osd_daedalus]

That looks like... different from your screenshot.
Looks like good!

[kevL]

freaky. All i did was add the toolstrip in the cTor instead of in designer's InitializeComponent()

looks like a bingo ...




must resist urge to delete Windows™


Can I ask you a question... did you have

Code: [Select]

//#define __Mono__

defined (uncommented) for that last Mono build? Because if we don't need #define __Mono__ i'd like to take it out of the code.
at the top of the TopView.cs file

[osd_daedalus]

must resist urge to delete Windows™

Just make a dual boot Windows/Linux. Or install Virtualbox and create a Linux virtual machine.
There is no real reason you have to trash Windows over Linux, but it's an experience I really suggest.

(and I had also a tri-boot Win/Linux/Hackintosh, but I deleted the latter)

Just... I wish there is a Windows.Forms designer working for Linux.

Can I ask you a question... did you have

Code: [Select]

//#define __Mono__

defined (uncommented) for that last Mono build? Because if we don't need #define __Mono__ i'd like to take it out of the code.
at the top of the TopView.cs file

Nope, just git-pull and built. Wonders of Mono trying to do .NET work!

Wait a sec... trying to do right now...

ADD: find in attachment what happens if I uncomment the #define. Eeeek! DELETE IT!!!

[kevL]

why the bleep does it to that /rant

anyway, i deleted that #define and kept the line that adds the toolstrip to the left side of the container ... hopefully it's all good, if it still renders properly. Because the 'logic' of what just happened is absurd.


/committed to master branch

[kevL]

2019 October 24

- fixed PckView not starting. Thanks to luke83 for reporting and helping troubleshoot the probl.
- plus tweaks for Mono (if applicable). Thanks to osd_daedalus for reporting Mono issues and testing changes.

https://github.com/kevL/OpenXCOM.Tools/blob/master/Distribution/README.md