Xamarin Studio for Mac about font-validator HOT 19 OPEN

+1 :-).

from font-validator.

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.

from font-validator.

BTW, with
HinTak@8575e92 ,
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 :-) .

from font-validator.

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

YES

from font-validator.

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

from font-validator.

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.

from font-validator.

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

from font-validator.

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.

from font-validator.

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?

from font-validator.

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? :-).

from font-validator.

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.

from font-validator.

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.

from font-validator.

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...

from font-validator.

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.

from font-validator.

@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 :-).

from font-validator.

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:
Clancey/MonoMac.Windows.Form#10
and together with:
mono/sysdrawing-coregraphics#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 Clancey/MonoMac.Windows.Form#10 .

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

from font-validator.

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.

#29 is my notes on the Cocoa Mac OS X webkit bridge.

from font-validator.

from font-validator.

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

from font-validator.