MDLops in wine or playonlinux?

[xander2077 80]

Ah red hat, one of the first encounters i had with linux! those were the days. where you had to start the desktop from command-line, install every driver manually (or write them on your own from copying forum posts) and the packages were all rpms and a mish mash of varying styles and goofiness. Many linux distros were still in its awkward stage back then, and some distros still have a similar awkwardness.You also had to pay for things that are usually free now. But enough reminiscing...

 

I believe there may be support for TK windowing in linux kernel (GTK maybe?) but it for sure has to be in the correct case consistently, and that is usually the issue (besides the dotnet fiasco in many exes), not necessarily the fact that Tk is present, but that there was a case discrepency. Linux is case sensitive, while windows is case agnostic, so a script can reference something in all caps and even if the dll or the exe is in all lower case it will still work in windows, but not in linux. linux all the references have to match 100% or something will not work.

 

Now in games like Kotor, where internally case may not match, the game engine translates or accepts the case discrepencies because they are hidden from the OS, for instance an all upper case reference inside the model tree, doesnt effect the game negatively because it is handled internally, but for something like mdlops which does more of the work externally in wine or mono, with perl or python acting as a go between as well sometimes, (with it translating code for the windows executable), it almost demads the case consistency.

 

I also like that you suggested commenting out certain things, but i will have to look into it further to figure it all out.

 

If the code had to be retooled in the exe itself, then i dont have the things i need to do that any more (i used to)

 

just commenting out in the perl script is easy as pie.

[DrMcCoy 40]

That being said, I won't assume anything for sure unless I can test it.

Fair enough.

 

I believe there may be support for TK windowing in linux kernel (GTK maybe?)

 

No, it's separate from the kernel. It's a normal userspace library, just like GTK. It doesn't use GTK, though, it's an alternative to GTK (or maybe the other way round: Tk predates GTK).

 

But both were meant, in a way, as a free and easier-to-use alternative to Motif (with different other agendas).

 

For a bit of a look into history, Tk has been working on Linux since 1992, before it even worked on Windows (which came after the Windows 95 release). And yes, it does still work.

[xander2077 80]

No, it's separate from the kernel. It's a normal userspace library, just like GTK. It doesn't use GTK, though, it's an alternative to GTK (or maybe the other way round: Tk predates GTK).

 

But both were meant, in a way, as a free and easier-to-use alternative to Motif (with different other agendas).

 

For a bit of a look into history, Tk has been working on Linux since 1992, before it even worked on Windows (which came after the Windows 95 release). And yes, it does still work.

 

Well i knew the were similar, just did not know they were two different alternates. Yes it is not a part of the kernel, since it has to be added to lubuntu if you want some functionality for certain packages. I made the assumption since some distros come with it prepackaged.

 

I guess what would be cool is if it could use GTK instead of TK. But im not sure how that would pan out.

[ndix UR 218]

...you do realize that MDLOps has in-built commandline usage, right? There's no need to strip GUI from it to do that. Of course, you may need to strip Tk from it to be able to run it on Mac, but that's another story completely (and in that case, you could rewrite the GUI with another library).

 

Yeah, so, the fact that MDLOps is designed to work on the command line is why it is so easy to fix for command line usage on other platforms. The problem with how it is currently written, is that it requires Tk & Win32 to be present ... even when you are not using them. Win32 is a non-starter and has to go (on non-Windows platforms), and Tk I just don't feel like installing (because I don't want/need it).

 

I really do love MDLOps as a unix command line tool ... when I was recompiling the entire KoTOR weapon model overhaul to use in TSL, I only had to run two commands: mdlops *.mdl and mdlops -k2 *-ascii.mdl and *boom*, 70+ Kotor1 models recompiled and ready to go for TSL. Thinking about using a GUI for that makes me groan (although a featureful one wouldn't be too bad).

 

I just realized that there's an even easier fix, which is to just move the 'use Tk...' and 'use Win32...' lines into the actual usegui = yes block.  Sorry ... code. That would make it still useable as usual on Windows while also supporting command-line usage on other perl-enabled platforms.

[LiliArch 115]

I believe there may be support for TK windowing in linux kernel (GTK maybe?) but it for sure has to be in the correct case consistently, and that is usually the issue (besides the dotnet fiasco in many exes), not necessarily the fact that Tk is present, but that there was a case discrepency. Linux is case sensitive, while windows is case agnostic, so a script can reference something in all caps and even if the dll or the exe is in all lower case it will still work in windows, but not in linux. linux all the references have to match 100% or something will not work.

 

I also like that you suggested commenting out certain things, but i will have to look into it further to figure it all out.

 

If the code had to be retooled in the exe itself, then i dont have the things i need to do that any more (i used to)

 

just commenting out in the perl script is easy as pie.

You can throw the exe out of the window if you like. You don't need it. Just edit the .pl file and execute it.

 

It's not a difficult edit in any sense... just follow the instructions I posted. That should work after those. (I actually tried it on my Win-system after removing the Win32-dependencies and it run like a charm. Well, I would have probably missed the autoglob if I would have used it from command-line, but I wasn't.) I hope they were clear enough? I'm so stuck with that old phpBB mod-installation instruction form that I can hardly give code-edit instructions without it... ahem. If you look closely, most of the edits are simply adding # mark in front of a line; that's what makes it a comment (everything on that line after the # mark is a comment). There's also fixed the "TK" to be "Tk" (you need Tk::Tree if you want to use the tree view) and Win32-file open dialog changed to Tk's one, that should be cross-platform compatible.

 

As far as the case-sensitivity goes, Perl is actually case-sensitive even on Windows systems. If the "TK" would have been a normal variable, it would never work. Only thing I can imagine why it actually does work on Win-systems is that it is essentially a file path, but it's definitely not valid Perl, no matter how you look at it.

 

I just realized that there's an even easier fix, which is to just move the 'use Tk...' and 'use Win32...' lines into the actual usegui = yes block.  Sorry ... code. That would make it still useable as usual on Windows while also supporting command-line usage on other perl-enabled platforms.

Actually, no. For Tk, sure, there's no reason for "use Tk" -stuff to be there if you're using it from command-line, so it would definitely make sense to include that under the part that is defined if you use gui (and in that case you can run it from command-line without having Tk installed). But Win32... not. The only Win32-one that is actually required to be used on Win-systems is Win32::Autoglob, and only point to use it is when you are using it from command-line. For the file-opener dialog you can simply switch to use Tk's in-built open file dialog, as I did in those instructions of mine. Better than dump the "use Win32::Autoglob;" into a location where it's not used would be to make an if-clause where the script checks OS and use the library only if it is run on Windows. That way the same script can be used in all platforms, with of without Tk installed (if it is called correctly from command-line) and Autoglob would be used where it matters.

 

I guess what would be cool is if it could use GTK instead of TK. But im not sure how that would pan out.

If what would use GTK? MDLOps? It could, but it would require some rewriting. Probably not a big deal... after learning how GTK works first, of course.

[xander2077 80]

You can throw the exe out of the window if you like. You don't need it. Just edit the .pl file and execute it.

 

It's not a difficult edit in any sense... just follow the instructions I posted.

 

 

 

yep, it is easy with your instructions. i remember learning about commenting out previously at some point but never really had to use it for anything til now. thanks for making it easy.

[ndix UR 218]

@LiliArch you are totally correct about the Win32::Autoglob thing ... sorry, I was talking from memory and not looking at the code!  Yeah, without Win32::Autoglob, on Windows, you wouldn't even be able to easily figure out whether you were supposed to be in command line mode or not.

 

According to perl docs the if would look like ... 

if ($^O eq 'MSWin32') {
  # code that assumes Windows
  use Win32::Autoglob;
}

Personally I would probably do...

if ($^O =~ /^mswin/i) {
  use Win32::Autoglob;
}

Which checks that the version string 'starts with mswin' (case-insensitive). The only reason I would do it that way is to potentially avoid breaking if Windows ever starts reporting itself as MSWin64 (while still providing Win32, the perl library) or something crazy 

[LiliArch 115]

For a bit of a look into history, Tk has been working on Linux since 1992, before it even worked on Windows (which came after the Windows 95 release). And yes, it does still work.

To be fair, that was the source of my concern about it not working anymore. It is old, and old systems tend to get replaced by newer ones at some point. Plus, I just found out that certain Win32 libraries don't work properly on my 32-bit Windows, or on my 64-bit Windows.

 

The only reason I would do it that way is to potentially avoid breaking if Windows ever starts reporting itself as MSWin64 (while still providing Win32, the perl library) or something crazy 

Makes sense to me. (Though you can tell if the program is called with arguments even without Autoglob - so it can decide if GUI needs to be fired or not - the functionality is obviously limited.)

 

yep, it is easy with your instructions. i remember learning about commenting out previously at some point but never really had to use it for anything til now. thanks for making it easy.

All part of the service. What point is in knowledge if it's not shared?

 

Okay, okay, I move to do something else.