Well I won't be messing with things, I don't know OSX well enough to dig myself out of problems, but if anything it actually feels quicker on OSX, GUI rendering/Font rendering is not as good as on windows, but its workable and readable, so that's more likely a setting here or within the wrapper, but like I have said I am not looking for breaking things here until i am more up to doing the repairs, self preservation rules in some cases, two days of wrestling to get this computer to run OSX is not that enjoyable - lol

Martin Spencer-Ford

Hi Martin, yeah the font rendering on Wine happens through FreeType and it only gets a kind of grayscale level type anti-aliasing rather than the sub-pixel type anti-aliasing.

I have to make a customized version of FreeType in order to get that enabled and I did have that working at one point early on but then at some point with one particular Wineskin upgrade it stopped working from some kind of mismatch between different FreeType versions and I gave up on it because it's not really too bad as-is with the colors that MoI happens to mostly use for backgrounds. It tends to look worse on white backgrounds.

At some point I may be able to dig back into that and get that back working again.

I think though that everything else in the GUI other than the font rendering should be identical between OSX and Windows, since it uses the exact same Qt rasterization code for things like gradients, rounded corners and that type of stuff.

- Michael

Hi Michael -

[I have to make a customized version of FreeType in order to get that enabled and I did have that working at one point early on but then at some point with one particular Wineskin upgrade it stopped working from some kind of mismatch between different FreeType versions and I gave up on it because it's not really too bad as-is with the colors that MoI happens to mostly use for backgrounds. It tends to look worse on white backgrounds.]

Yeah it is noticeable, but your app is certainly not the only one with poor font rendering on the Mac so i certainly wouldn't be feeling too bad over it, to be honest, if i had not used the windows version beforehand, i would probably not have noticed

[At some point I may be able to dig back into that and get that back working again.]

Not a problem here really, just noticeable that's all. I think personally, it is more important to have system stability over having everything system identical. They are different OS's at the end of the day, identical behaviour with the same level of robustness is what i am more interested in above all else. Also, I must keep in mind that my GTX560 is not directly supported by nvidia with an **official** driver for OSX and is pretty much dependent upon kernel settings and extensions rather than being a full blown driver. If it's possible to detect within MoI if it's operating under wine or not, it might be just as easy to set the font to boldfaced if the words would still sit on the buttons as a temp solution until such time as there is no mismatch. But like I have said, not needed here, but just a thought.

Martin Spencer-Ford

Hi Martin, if you'd like to give bold text on buttons a try on your system, you can set that up by editing a line in moi.css .

To get to it, right-click on the MoI app and choose "Show package contents", and then inside there go to drive_c/moi/ui/moi.css - you should be able to edit it with TextEdit.app

Inside of there go to the section right near the top (at line 43) that says: /*** Command buttons ***/ , and inside the first rule there add an entry for font-weight:bold; , it should look like this, the extra line is marked with >>>> <<<<< do not actually put the>>> <<<< when you add it though:

     /*** Command buttons ***/

    moi\:CommandButton, moi\:CommandMenuButton, moi\:CommandSplitButton {
        display:inline-block;
        text-align:center;
        border:1px solid transparent;
        border-radius:4px;
        padding:1px 0.1em 2px 0.1em;
        font-size:75%;
        white-space:nowrap;
>>>>    font-weight:bold;  <<<<
    }

After that your button text will be bold. Sometimes it's a bit surprising how heavy bold text can be though.

- Michael

Hi Michael, that works a treat for most of the UI, but not all of the buttons are effected by that change, but they are not *that* important - It got the main ones that i use,

drawing tools, file - delete, help and options, Pan and Zoom buttons

screen selectors, dimensions and angle, command line, snap settings and the browser button are all unaffected

This is not at all unpleasant to look at, and it works. What it does show though is how much of a pain it would be to make those changes system wide. Screen type here is a 27 inch backlit LCD, so we have a kind of a fix for anyone else with same issues. Must be my age creeping up on me (lol)

Many thanks for the quick solution though

Martin Spencer-Ford

Hi Martin, yup that change that I posted before will only modify "command buttons", those are the type of buttons that have an icon with smaller sized text underneath them - when you had mentioned something about "words sitting on buttons" I had thought you were asking about modifying just these kinds of buttons, but I guess what you meant by that was just if the bolded text would fit or whether it would get chopped off. The fitting part should not be a problem, the UI will expand automatically to accommodate the slightly larger bold text, that ability to make controls adapt to text size is a fundamental part of MoI's whole UI mechanism.

So would you instead like to have all text in every spot in the UI as bold? If so then it's possible to do that by modifying one line at the top of the moi.css file instead, go to the rule at the very top of the file (the one for "html, body"), and add a font-weight:bold; to it so that it looks like this: (again the >>>> <<<< shows the added line, don't actually add the>>> <<< characters themselves):

html, body {
    color:#000000;
    width:100%;
    height:100%;
    margin:0;
    -webkit-box-sizing:border-box;
>>> font-weight:bold; <<<<
}

That should then get pretty much all text to be bold - I think about the only thing that won't be bold would be the object snap tags that are displayed inside inside of the viewport and the shortcut key editor, those are on somewhat different systems than the rest of the UI. And I guess a couple of other assorted minor things like tooltips would not be bold, but for the most part it should do it I think.


By the way if you want to see a really funny UI customization, go to moi.css and "uncomment" (remove the /* */ around them) the 2 rules at the very bottom of the file. Maybe not if you tend to get vertigo though... ;)


- Michael

Yeap, that makes it even better regarding text, but oh boy what was you thinking with the other, lol. You just knew i would have to play with that didn't you. What was even more surprising though was that it affected everything other than the drawing area, i expected the whole display to rotate by steps of 45 degrees. It would however make for a nice transition effect for those who want to be able to move their menues about, e.g drawing toolset to the top of the screen and the browser to the left etc. Nice bit of trickery, but as you say, totally unworkable, trying to click the buttons is amusing as they keep moving out of the way.

Nice feature .... I think :\

Martin Spencer-Ford

Hi Martin, yeah I thought you would get a kick out of that one! :) It's pretty funny how the UI actually functions when that rotation is going on if you can manage to actually click on things.

> i expected the whole display to rotate by steps of 45 degrees.

The sort of top level layout is basically a custom layout mechanism, that level is not handled by HTML, mostly because the viewport 3D display area is pretty much a separate thing from the GUI / buttons type area.

The top level layout handles a kind of generic "panel", and there can be ViewPanel that hold the viewports, and UIPanels that hold HTML content. Things like dialogs and flyout menus just have one UI panel in them.

This structure actually ended up helping quite a bit when I did the big transition from IE to WebKit - MoI v3 (and v2.52) use a completely different HTML engine for the UI panels than MoI v1 and v2.0.

- Michael

It would be a niffty trick to pull on someone when that have had a little to much beer/wine etc.

It's all clever stuff, I got about as far as playing with Dynamic HTML many years back (10 or so) but decided web design was not for me, trying to maintain client sites and still finding time to design new ones was getting too much.

Martin Spencer-Ford

Hi Martin, yeah definitely Dynamic HTML has a whole lot of its own quirks, I invested a lot of time back about that same time period before getting comfortable with it. It tends to be particularly good in the area of handling text though, with a lot of features involving text layout, word wrapping, and sizing things to fit child content. These are the reasons why I've persisted in using it for application UI for quite a long time now. And it's also the closest thing that exists to a global cross-platform "known by many" type of UI. Also it's had scripting built into it for quite a long time and the ability to bundle script code along with the UI in one package is very flexible.

- Michael

Yeah, I could see the potential for it, but flash and css came along and DHTML seemed to drop from flavour of the month to the poor mans tool. But yes it was good for animating text blocks and adding some cool mouse over effects, i miss animation at times, but I am happy to tinker with my 3D hobby. I used to do programming too, but then .net came along and i lost the whole logic and struggled so that got abandoned too. But that was done purely as fun and for my own system checking tools. Who knows, one day I might go back to it.

Martin Spencer-Ford