MWEdit
- This topic has 225 replies, 2 voices, and was last updated 14 hours, 9 minutes ago by
.
-
Okay, got the Features.txt file cleaned up 🙂
There’s also a to-do list in the docs folder that we’ll want to look through. Some of the items may be worth adding to the bug tracker
Somehow, some stray invisible characters wound up wandering in to the features file. Will try to take care of them. Not sure how to check if they exist in other files but they need to be banished if we can figure out how to track them all down.
Edit:
May need to use a hex viewer to track them down
Okay, stripped the extraneous characters and updated the repo. Geany’s function to strip trailing spaces apparently works on invisible control characters as well. Ran it on all of the documentation files. 🙂
Looking at the to-do list now, the items on it are pretty vague. Maybe we should wait on adding those items to the tracker until we understand them better?
If the docs are now pretty satisfactory, I’ll update the OpenMW thread 🙂
Edit:
More information regarding the image library stuff: DevIL is cross-platform but MWEdit is written to use the DLLs. In all of my experiments with DLLs, I never was able to figure them out. This could be fixed in a few ways, with the simplest being a static build as mentioned earlier. Another option would be to wrap the DLL code in a conditional compilation block for the Windows platform. The IL code is in the folder of the same name. Personally, I prefer the static option as it means we won’t need to deal with figuring out how to properly ship and use a bunch of different DLLs. Would make it more difficult to update the libraries since we’d need to ship out a new build each time but Windows doesn’t have a central repository for libraries like other systems
Looks like Astyle missed the spacing around the parentheses for function parameters as well in addition to the pointer operands (I wonder if Uncrustify would have worked any better, didn’t think of it at the time) so I’m working on that now. This will take a bit as I need to go through each file and adjust things manually but we’ll get there! 🙂
Another item on the cleanup list is to clean up the returns. The return command is used inconsistently. Sometimes we see things like this:
return (true);
While other times we see this:
return true;
In some cases, the parentheses can be removed but will need to be done on a case-by-case basis to prevent the order of operations from getting messed up and giving us improper values. I’ll do that in a separate commit down the road. Side note: really wish we had syntax highlighting for the code tags. May look for a plugin for that at some pointThere’s a mixture of boolean variable types from throughout the standard’s history: BOOL, boolean, and the current bool. bool is the current form and everything should probably be brought up to date to ensure the code will work across many different compilers and continue to work unless the variable is ever changed again in the future. Will add it to the list of things to do. I’m thinking of saving much of the overhaul until after the cpplint and cppcheck tasks are done as they’ll help with the initial pass and should help keep it from getting too overwhelming 🙂
This isn’t exactly a note but more something interesting that I just found. Some of the files have conditional includes that check for DOS or regular Windows, even though DOS was mostly phased out in the mid-90s for the consumer (still used for kiosks at the time and since has been mostly superseded by kiosk mode)
#if defined(__MSDOS__) #include "dos.h" #include "dir.h" #include "time.h" #include "io.h" #elif defined(_WIN32) #include "io.h" #endif #if defined(_WIN32) && defined(__BORLANDC__) #include <windows.h> #include <time.h> #endifWe should be able to remove the DOS support without issue. It’s also interesting that Borland has some stuff in there even though the majority of the code was written to require Visual Studio and used its code generating functions. It does make me wonder: would Borland also compile the project? Not too familiar with it but it’s possible it has similar code generating.
Did we ever consider using ResIL instead?
Yes, you’ll want to check if the caller is looking for “(true)”.
Can’t imagine Morrowind running in Dos16/32 mode, He might have been hoping for a pending groundswell of Windows begone and DOS revivus. :p
Not a fan of namespaces during development- get everything prefixed::then convert at the final pass. Direct references while no thing of beauty, easy to debug. 🙂Another oddity that’ll need investigation:
SYS_WIN32(m_TimerID = timeSetEvent(55, 22, l_Win32TimerProc, 0, TIME_PERIODIC)); SYS_WIN32(if (m_TimerID == 0) { ) SYS_WIN32( ErrorHandler.AddError(ERR_BADINPUT, "Failed to initialize the timer using SetTimer()!") ); SYS_WIN32( return (FALSE) ); SYS_WIN32( } )I have no idea how that’s supposed to work. The macro function’s ) is before the closing brace while the final macro function sets the closing brace. Not sure why it even uses a macro function, to be honest. For that matter, I’m not even sure what this file is for. It’s tasktime.cpp/tasktime.h. From the code, it sounds like it may be a re-implmentation of some Windows system stuff for handling processes but I don’t know why MWEdit would need such code. It’s a file editor, not a low-level program. There’s a good chance it’ll be slated for removal.
I’m a little nervous about touching it right now with how weird it’s set up: I don’t want to break anything.
There’s also custom code for running it in a console in Common/conapp.cpp even though it’s a GUI application. It’s starting to look like the Common directory was just a holding space for custom code for a variety of projects even if it didn’t necessarily pertain to the program.
I’m also seeing a lot of stuff like this:
DEFINE_FUNCTION("CreateBlockInfo(void*, size_t, char*)");
Just about every function has a similar line as the first line in the block where DEFINE_FUNCTION just repeats the function line. In some cases, it’s commented out. I’m assuming this is an old legacy artifact that can be safely removed?That snippet of code won’t pass the “pub test”, the bracket on its own has to match the expression in the above statement and
SYS_WIN32(has to go straight off. The final closing bracket has to bereplaced with a semicolondeleted, is best. And yes, what system library hasSYS_WIN32?
Yeah,DEFINE_FUNCTIONisn’t part of VC++ or gcc, all you want to do is to remove it, and just define the function in the header. 🙂Oh, that’s no issue at all. C++, unlike other languages, is very flexible when it comes to style. You can even have all of the code on one line if you want or even split things across several lines. The biggest thing is to make sure you use the delimiters appropriately, either in your macros (so they’re properly expanded during the pre-processing stage) or your blocks/lines. Other than that, the sky is pretty much the limit 🙂
That’s part of what I love about it: I can adjust things to each situation for maximal readability 🙂
Getting close to being done looking through and adjusting the whitespace of the Common library as we’re now calling it after looking it over with some of the OpenMW folks. Once done with this task, I probably won’t focus too much on it as the growing consensus seems to be to remove as much of its use as possible from the main code. Once that’s done, what’s left may be brought in as self-contained code split up from Common as I’m really not liking what I’m seeing with Common.
More notes!
Taking a look at the issues, issue 3 may or may not be still relevant. It would need testing with the current UI library to make sure it wasn’t an old bug in Windows.
Issue 9 sounds like it’s an issue in the base CS as opposed to MWEdit so should probably be deleted from the issue list.
No idea what 7 would be referring to. That’s pretty standard behavior for search functionalities.
Decided it was time to get a post up on AFK. I’ll get a separate thread up there later on 🙂
That actually brings up a good question: is the issue referring to the tab key or a GUI tab? I can’t tell based on the description.
Sounds like it should be able to, unless the conditions listed are met. Sounds like a null pointer or similar is causing the issue with it assuming the data is there and crashes when it realizes there’s nothing to access.
Will find out about the search. If regex, we can switch to the regex library that was added in C++11. The regex library is broken in a certain version of VS and gives an infinite loop but the later versions with support are fine (no issues in any of the libstdc++ versions with support from GCC that I know about)
There are also some alternative libraries that may be worth plugging in: https://en.cppreference.com/w/cpp/links/libs#Text:Search
Looks like the Glade GUI designer for GTK has been discontinued for whatever reason. I think there’s work on a replacement, I’ll try to look it up when I get the opportunity
- You must be logged in to reply to this topic.