Xamarin Studio for Mac

[twardoch]

I wonder if we could find a volunteer to build a simple Cocoa UI for FontVal using Xamarin Studio for Mac, which is now free: https://developer.xamarin.com/guides/mac/getting_started/hello,_mac/

[HinTak]

+1 :-).

[HinTak]

Actually if somebody can do the Cocoa UI, it does not need to be functional - I'll be happy to fill in the guts and hook up the buttons and options with the interior.

[HinTak]

BTW, with https://github.com/HinTak/Font-Validator/commit/8575e92d47c27d2722e67e2c9c79099f273c9ad4 , the XML report viewer finally works correctly with webkit-gtk . That basically means the GUI on linux works as well as on windows. It is very satisfying to see 4 reports opened simultaneously, and all the embedded windowing interactions - automatic horizontal and vertical tiling, cascading, etc - the whole nine-yards, work. :-).

I have since learned that webkit-gtk is not Mac OS X's webkit . OTOH, bundling the webkit-gtk libraries for Mac OS X is tolerable, so Mac OS X would gain a working XML report viewer the next time I make a build in any case. i.e. GUI-wise functionality, it is on the same level as windows, finally.

This begs the question: do people really want a 'mac os x' look-and-feel with Cocoa UI?

@moyogo @davelab6 @anthrotype @n8willis @schriftgestalt @behdad - BTW : the new built-in IronPython interpreter in FontVal, can load any c# -based libraries - inclusive of Xamarin Mac's cocoa binding, I think. This means you can script in python to make a new FontVal cocoa GUI, no compiler involved , if you are so inclined :-) .

[schriftgestalt]

This begs the question: do people really want a 'mac os x' look-and-feel with Cocoa UI?

YES

[schriftgestalt]

And what is wrong with converting the xml to html and opening it in Safari?

[HinTak]

This begs the question: do people really want a 'mac os x' look-and-feel with Cocoa UI?

YES

There are also question of varying 'degree' - and it may not necessarily involve writing a whole GUI from scratch. The current GUI is theme'able, BTW, just with a boring "windows" theme. One possibility is simply finding and loading a mac os x desktop application "theme", styling the buttons, menu's etc the mac way. In the same way, and perhaps a good deal more, as how one might configure a windows box to look like a macintosh, without actually running mac os. That might even be quite easy.

I suspect the one usability thing that bothers me a bit is the fontconfig cache rebuilding time. There is a possibility that switching to sysdrawing-coregraphics (a replacement of some of mono's cross-platform library bits with mac specific library bits, from the mono folks, still in dev) will get rid of that since it does not even use fontconfig; and will likely bring a more mac-centric look-and-feel too. It does not involve modifying FontVal or adding to it - more a 'packaging' task, though the 'packaging' involves spending significant amount of time building a bleeding-edge mac-specific wrapper from source, and fixing problems from using 'bleeding-edge' source code. as such.

On packaging, I tried cross-compiling webkit-gtk for windows, and one arch (32-bit) took about 8 hours and over 2GB disk space, so I stopped the 64-bit window build that followed - just to sanity-check the linux webkit-gtk bridge, by forcing windows fontval to use webkit-gtk instead of ms ie. (apparently the 8-hour build time is typical even for native webkit build) . As I am largely linux based, if the 'wrapper' is mac-specific and does not cross-compile, (or takes 8 hours and 2GB to just to see if mac webkitgtk cross-compiles successfully...), I am not going in that direction any time soon. So this is just sharing ideas and pointing in directions that others motivated enough can try.

[schriftgestalt]

What advantage do we get from a UI written in Mono over one that is written in Xcode?

[HinTak]

And what is wrong with converting the xml to html and opening it in Safari?

Nothing - just less convenient and additional steps for end-users. Since the webkit-gtk bridge is fully functional as of this morning, having the built-in XML report viewer working on mac os x is a matter for packaging, not end users', and not developer(s)'. The package will be slightly larger, that's all.

[schriftgestalt]

Nothing - just less convenient and additional steps for end-users.

No, That can be done automatic as in the Mac app I did. I still don't understand why it needs to be shown in the same app. Could you post a screenshot on how the mac UI currently looks?

[HinTak]

What advantage do we get from a UI written in Mono over one that is written in Xcode?

One is here and now and real (and may be improved to some extent). The other is in the future ( if at all) and does not exist now. It is not as if there are many developers queueing up wanting to contribute, aren't there? :-).

[HinTak]

Here is the horizontal tiled look, from linux, newly working, a few hours ago:

http://htl10.users.sourceforge.net/FontVal-Linux-xml-tiled.png

The default is cascading windows (i.e. multiple font reports are shown offset'ed by a small amount in the top-left<->bottom-right direction). The other positioning options are vertical tiles, and minimizing selected ones, also. I agree, for a single font test, there is not much difference with an external launch.

[schriftgestalt]

The other is in the future ( if at all)

I told you a while ago that I have a working implementation written in Xcode. I asked for feedback before I put the code in github but I didn't get much. I just uploaded the code to my repository: https://github.com/schriftgestalt/Font-Validator in the MacUI folder.

[HinTak]

I told you a while ago that I have a working implementation written in Xcode. I asked for feedback before I put the code in github but I didn't get much. I just uploaded the code to my repository: https://github.com/schriftgestalt/Font-Validator in the MacUI folder.

Thanks. Sorry there might be some communication - I thought it was good and I was basically waiting for the code to turn up in the open :-). So now it is. Great!

There is also the question of Microsoft's involvement - being a corporate entity, they might be more sensitive to branding and use of icon/images. i.e. are you going to give it to them (and sign a CLA on the way), and also, are they okay with you changing/creating a new look and feel...

[schriftgestalt]

The version in my repository used a very old version of the command line executable. I don't remember where I got it. The advantage of using the CLE is that we don't need to deal with Mono directly.

[HinTak]

@schriftgestalt, thanks a lot for contributing and participating in this, as I know you have a lot of experience especially on the mac platform and better visual design. I am all for better experiences for the end users, so a new mac-centric GUI is a very good thing.

GUI running on Mac (built from Xamarin Studio) doesn't deal with / depends on Mono being on the end users' machine either , - it is mostly a matter of how it is built/packaged. anyway ... since I am mostly linux-centric, my effort towards Mac OS support in FontVal is largely a side-effect / common ground between the two unices.

This is how the current GUI opens multiple reports after testing a list of fonts - the cascading-window look, the default: http://htl10.users.sourceforge.net/FontVal-Linux-xml-cascade1.png http://htl10.users.sourceforge.net/FontVal-Linux-xml-cascade2.png

I have got win32 webkit working against win32 mono also - http://htl10.users.sourceforge.net/win32-mono-webkit-2.png

In case you are interested, that unusual details will continue in wine's bugtracker ( https://bugs.winehq.org/show_bug.cgi?id=30988#c10 ). It is somewhat important to some people for running hybrid win32 + dotnet applications. The original FontVal itself was such a thing - and it is becoming not such a thing :-).

[HinTak]

I got hold of Xamarin.Mac, and is part-way making the webkit window operational. Actually Xamarin Studio is irrelevant - it is just a rebranded version of monodevelop. What you want is Xamarin.Mac (different thing), which is a C# binding of Mac OS X's native API, including Cocoa. Do not confuse Xamarin.Mac with Xamarin Studio for Mac. The latter is quite useless for what you have in-mind, a native Mac OS X Cocoa GUI.

While debugging my mac os webview in fontval issue, I came across

http://screencast.com/t/kdQt3QXfzh https://github.com/Clancey/MonoMac.Windows.Form

and I did some quick update to that: https://github.com/HinTak/MonoMac.Windows.Form

If you can fix the bit-rot: https://github.com/Clancey/MonoMac.Windows.Form/pull/10 and together with: https://github.com/mono/sysdrawing-coregraphics/issues/16

Fontval will possibly gain a native Mac OS X Cocoa GUI, just by re-linking with those two alternative libraries. That's assuming MonoMac.Windows.Form sufficiently complete - I do not know. It built against a 5 year-old MonoMac which is useless, and does not currently build against current Xamarin.Mac.

So it is just a bit of tedious reading to find out what changed in the 5 years, to fix https://github.com/Clancey/MonoMac.Windows.Form/pull/10 .

BTW, Xamarin.Mac , also recently open-sourced, is a larger version of MonoMac .

[HinTak]

sysdrawing-coregraphics is cross-build'able from non-Mac now:

https://github.com/HinTak/sysdrawing-coregraphics/tree/crossbuild

https://github.com/HinTak/MonoMac.Windows.Form is my not quite successful to fix the 5-year bit-rot.

https://github.com/Microsoft/Font-Validator/issues/29 is my notes on the Cocoa Mac OS X webkit bridge.

[davelab6]

AWESOME JOB!! :)

[HinTak]

I have pull'ed http://github.com/schriftgestalt/Font-Validator into the embedded-python branch a few days ago, BTW.