I tried to find a similar question here, but found something different. I prefer to use display fonts smoothing in Windows, but I don't like the way how Windows XP smoothes the display font edges. Currently I use GDI++ that smoothes the display fonts making them look very similar to text rendered in Safari browser for Windows (as far as I know, not a Mac user, it's a native approach to MacOS). Great, GDI++ really renders the fonts very similar to Safari almost for all application I use, but I'm disappointed knowing that GDI++ does not (and can't?) support Visual Studio and Google Chrome. I guess these applications use somewhat another way to render the display fonts (just GDI O_o; and I guess they take into consideration Windows font edges smoothing settings [no smoothing, Standard or ClearType]), but I'm not sure and I'm not familiar with it. :(
Please clarify this to me. I'd really like to use GDI++ in Visual Studio and Google Chrome. Probably, someone uses some workarounds (sure, if it's possible). Thank you.
This blog post by our esteemed benefactor is relevant. GDI+ indeed does things the Apple way, it uses true resolution independent rendering. It was pretty widely panned for this, so much so that it was replaced in .NET 2.0 with the TextRenderer class. Which uses the GDI DrawTextEx() function to draw text. To give an example of how GDI+ can suck, try running this sample Windows Forms form:
public partial class Form1 : Form {
public Form1() {
InitializeComponent();
}
protected override void OnPaint(PaintEventArgs e) {
e.Graphics.DrawString("Hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii!", this.Font, Brushes.Black, 0, 0);
}
}
YMMV, but I haven't yet had a machine where that didn't look completely awful. TextRenderer saved the day.
Until .NET 3.0 when WPF was introduced. Back to resolution independent rendering. The amount of hate that generated was stunning.
Long story short, the majority of users like GDI text rendering. Or at least they get very vocal when they don't get it. Visual Studio and Chrome no doubt use GDI for text output. This is not something you can easily change yourself, although Chrome is open source afaik.
Just wait for the next version. Visual Studio 2010 will use WPF. Beta 1 generated a lot of hate for blurry text. But WPF has been tweaked to limit the fuzzies so it might not fit your taste anymore.
Related
I'm trying to make VS Code editor to look exactly like Visual Studio. I made sure the font settings are exactly the same, however text still renders differently in VS Code (it seems "lighter").
Is there any way to fix this issue?
In the image below the top text is copied from Visual Studio while the bottom one is copied from VS code.
I know the difference is subtle but is still pretty noticeable.
Font rendering in VSCode has been a reoccurring issue throughout a good portion of the editors life time. Font rendering, especially in portable GUI's, is affected by several different layers, for example:
Your Graphics Card can affect the way font is rendered (you can try adjusting the graphic cards settings manually).
Your Monitor, obviously, affects rendering. In fact your monitor has a huge impact. (Try playing with your Monitor's Settings)
The color settings that are offered by your OS may have an impact (often times the color settings are the same as the graphic card settings though. Which means you can just use your OS's GUI to adjust your cards settings in some cases (Not on Ubuntu though))_
Somethings are out of your control, like:
VSCode, it is written using Electron v6. Not only does Electron impact font rendering, but when VSCode switched it Version 6 a lot of people reported a decrease in the editors font rendering quality.
VSCode also implements Anti-Aliasing tools, but as far as I can tell, they auto configure, so you have no control over this. These tools are likely to be one of the biggest causes to the difference in rendering you see, between VS IDE & VS CODE. There is a tool however that may give you some control over the Visual Studio side of rendering that I share a link to below. And just as an FYI, the Anti-Aliasing that VSCode uses is called Sub-pixel Rendering, which is something that Visual Studio doesn't implement as far as I can tell.
The Area You Have the Most Control in:
There is ONE tool/thing that you have 100% control over, that also greatly affects font-rendering, and that is the font that you decide to use. When choosing a font, you have the choice of equipping an OTF, or a TTF. In my personal experience, OTF's render better 90% of the time. The difference is in how they are created.
TTF fonts are made using quadratic Beziers.
OTF fonts are made using cubic Beziers.
Links above are the same
Fonts use something called font-hinting
Font hinting. Essentially font-hinting is a list of instructions that dynamically changes the way a font is rendered, by using the rasterized grid background as a parameter. adjust the display of an outline font so that it lines up with a rasterized grid. Choosing a quality font equipped with good hinting is critical for non-blurry readable text.
Many people choose font because like the way they look, or the italic version of the font they use is popular. When choosing a font, it is extremely important to choose, not the coolest one, but the one that renders with the highest quality, and is the easiest for you to read.
Well Rendering Fonts:
Not only are their fonts that render well, with ligature support, but the best rendering fonts are always free IMO. Bellow are Fonts that use font hinting and have top notch rendering abilities.
JetBrains Mono (JetBrain's Font & My Personal Favorite)
Cascadia Code (Microsoft's Programming Font from 2019)
Fira Code (Not that old, but not that new either. Is loved by many.)
Fira Mono (No Ligatures, Different Font than Fira Code)
Consolas (A classic)
Menlo (Another Classic)
The top 4 are at the top of the list because they receive updates ever few months. I don't think Menlo & Consolas receive regular updates, but they aren't left forgotten either, the are updated every year or two.
To finish with as solid of an answer as I can provide:
_"Getting VSCode to render like the Visual Studio IDE, is not something that you will probably get, with 100% satisfaction, getting an exact match with all of the different factors is just an extremely and possibly impossible thing to due. You can probably make the way the two pieces of software render, more a like, not in functionality, but in looks. It would probably help a great deal to make sure that everything that affects rendering is up to date, editor, IDE, fonts, tools, ect... From their you can try different versions, and see if maybe an older version of VSCode rendered in a way that is preferable to you. You should also play with your monitors settings. I have found that I can accomplish a great deal just through the buttons under the face of my monitor. Check Visual Studio for any rendering settings it might have, VSCode doesn't have much available, but maybe Visual Studio IDE does (I haven't used the IDE in 5 years so IDK if it does).
On a final note:
Their is one tool that could help you, I haven't used it, because it isn't for VSCode, it's for Visual Studio, but it might give you more control than you have now. The tool is called..."_
Text Sharp (Click Here to see it in the VS Market Place)
Can anyone provide some insight on how to "duplicate" an iTunes style window in Windows? Specifically I am looking for the following features:
1) rounded window
2) top and bottom toolbars
3) rounded text fields
I'm currently attempting a bit of cross-platform development with Real Studio and while I've discovered the mechanism by which to perform the rounded windows in OS X (declare method call to HIWindowSetContentBorderThickness or SetContentBorderThickness), I cannot find in the MSDN how to do similar things in Windows. Obviously Apple accomplished it in actually writing iTunes for Windows. Perhaps they wrote custom controls from the ground up.
SIDENOTE: I found this article from a few years back that briefly discusses it (http://discuss.joelonsoftware.com/default.asp?joel.3.454369.12), but this is pretty much all I could find.
Even if I can't duplicate it exactly, some direction on which Windows libraries might contain the functionality I need to do it "manually" would be nice. Any further assistance would be greatly appreciated.
There's no API for doing Apple-style rounded corners, but there are lower-level APIs for creating windows (both frame windows and controls) of any shape you want.
I don't use RealStudio, but I believe it allows you to access both .NET and native Win32 APIs, so:
If you're using .NET Windows.Forms, read Shaped Windows Forms and Controls in Visual Studio .NET. It's written for VB7, but should be easy to translate to your favorite language.
If you're using the raw Win32 API, there are at least two ways to do this. The simplest, but most limited, is to call the SetWindowRgn API, which sets the shape of your window to anything you can create as an HRGN. But that probably won't cut it for you. You don't want jagged edges; you want smooth curves, with alpha-blended borders, and maybe shadows. (At least that's what Apple does.) The Layered Windows API is the way to do this. It allows arbitrary shapes (even changing on the fly, if you use UpdateLayeredWindow—although you don't need that feature to emulate iTunes), alpha transparency, and complicated hit testing. Since the original article is very out of date, and doesn't cover all of the functionality, also see Layered Windows for the current documentation, which has links to the references.
there is a third party controls that do what you want. It works on Mac & Windows.
http://www.madebyfiga.com/fgsourcelist/
works well.
sb
I have a form in VB6 with text fields and I would like to create a focus glow like you see in modern web browsers.
Is it possible to make a Glowing Effect in a Textbox using VB6.0?
Kindly give me some advice or way to accomplish this one! Thanks...
I've noticed you are asking other questions regarding modification of the visuals of your VB6 application, too, but you have to face it: VB6 is old, very old and many of the newer UI concepts are very hard to implement in VB6.
Your best shot to make your old VB6 look better is to use a set of more current controls than the original VB6 ones. (Although better look controls are no magic bullet, it's still possible to screw up the UI by making bad layout decisions, for example)
At work we have made good experiences using CodeJock to polish our UI, but even the latest version (15.0.2 at this time) doesn't have a glow effect for text boxes.
You can enable the text box "glow" in Vista/7 by using a manifest. This manifest creator will handle some of the dirty work for you. Note that the effect will only appear in your compiled app, not running from within the IDE.
I'm from a Windows programming background when writing tools, but have been programming using Carbon and Cocoa for the past year. I have introduced myself to Mac by, I admit it, hiding from UI programming. I've been basically wapping my OpenGL code in a view, then staying in my comfort zone using my platform agnostic OpenGL C++ code as usual.
However, now I want to start porting one of my more sophisticated applications to Mac OS.
Typically I use the standard Visual Studio dockable MDI approach, which is excellent, but very Windows-like. From using a Mac primarily now for a while, I don't tend to see this sort of method used for Mac UIs. Even Xcode doesn't support the idea of drag and drop/dockable views, unfortunately. I see docked views with splitter panels, but that's about it.
The closest thing I've seen to the Visual Studio approach is Photoshop CS4, which is pretty nice.
So what is the general consensus on this? Is there are more Mac-like way of achieving the same thing that I haven't seen? If not, I'm happy to write a window manager in Cocoa myself, so that I can finally delve in an learn what looks like an excellent API.
Note, I don't want to use QT or any other cross-platform libraries. The whole point is that I want to make a Mac app look like a Mac app, leave the Windows app looking like a Windows app. I always find the cross-platform libraries tend to lose this effect, and when I see a native Mac UI, with fancy Cocoa transitions and animations, I always smile. It's also a good excuse for me to learn Cocoa.
That being said, if there is an Open Source Cocoa library to do this, I'd love to know about it! I'd love to see how someone else achieves this, and would help smooth the Cocoa learning curve.
Cheers,
Shane
UPDATE: I forgot to mention a critical point. I support plugins, which can have their own UI to display various plugin specific information. I don't know which plugins will be loaded and I don't know where their UI will live, if I don't support docking. I'd love to hear people's thoughts on this, specifically: How do I support a plugin view architecture, if the UI can't change? Where do I put the plugin views?
Coming from a Windows background, you feel the need to have docking windows, but is it really essential to the app? Apple's philosophy (in my opinion) is that the designer knows better than the user how things should look and work. For example, iTunes is a pretty sophisticated app, but it doesn't let you change the UI around, change the skin, etc., because Apple wants to keep it consistent. They offer the full view, the mini player, and a handful of different viewing options, but they don't let you pull the source list off into a separate window, or dock it in other positions. They think it should be on the left, so there it stays...
You said you "want to make a Mac app look like a Mac app", and as you pointed out, Mac apps don't tend to have docking windows. Therefore, implementing your own docking windows is probably a step in the wrong direction ;)
+1 to Ken's answer.
From a user perspective unless its integral to the app like it is in Adobe CS or Eclipse i want everything as concise as possible and all the different options and displays out of my way so i can focus on the document.
I think you will find with mac users that those who have the "user skill" to make use of rearranging panels will in most cases opt for hot key bindings instead, and those who dont have that level of "skill" youre just going to confuse.
I would recommend keeping it as simple as possible.
One thing that's common among many Mac apps is the ability to hide all the chrome and focus on your content. That's the point behind the "tic tac" toolbar control in the top right corner of many windows. A serious weakness of many docking UIs is that they expect you to have the window take up most of the screen, because the docked panels can obscure content. Even if docked panels are collapsable, the space left by them is often just wasted and filled with white space. So, if you build a docking panel into your interface, you should expect it to be visible most of the time. For example, iTunes' source list is clearly designed to be visible all the time, but you can double-click a playlist to open it in a new window.
To get used to the range of Mac controls, I'd suggest you try doing some serious work with some apps that don't have a cross-platform UI; for example, the iWork apps, Interface Builder or Preview. Take note of where controls appear and why—in toolbars, in bottom bars, in inspectors, in source lists/sidebars, in panels such as IB's Library or the Font and Color panels, in contextual HUDs. Don't forget the menu bar either. Get an idea of the feel of controls—their responsiveness, modality, sizing, grouping and consistency. Try to develop some taste—not everything is perfect; just try iCal if you want to have something to make fun of.
Note that there's no "one size fits all" for controls, which can be an issue with docking UIs. It's important to think about workflow: how commonly used the control would be, whether you can replace it with direct manipulation, whether a visible indication of its state is necessary, whether it's operable from the keyboard and mouse where appropriate, and so forth. Figure out how the control's placement and behavior lets the user work more efficiently.
As a simple example of example of a good versus bad control placement and behavior in otherwise-decent applications, compare image masking in OmniGraffle and Keynote. In OmniGraffle, this uses the Image inspector where you have to first click on an unlabeled button ("Natural size") in order to enable the appropriate controls, then adjust size and position away in a low-fidelity fashion with an image thumbnail or by typing percentages into fields. Trying to resize the frame directly behaves in a bizarre and counterintuitive fashion.
In Keynote, masking starts with a sensibly named menu item or toolbar item, uses a HUD which pops up the instant you click on a masked image and allows for direct manipulation including a sensible display of the extent of the image you're masking. While you're dragging a masked image around, it even follows the guides. Advanced users can ignore the HUD entirely, just double-clicking the image to toggle mask editing and using the handles for sizing. It should be easy to see, with a few caveats (e.g. the state of "Edit Mask" mode should be visible in the HUD rather than just from the image; the outer border of the image you're masking should be more effectively used) Keynote is substantially better at this, in part because it doesn't use an inspector.
That said, if you do have a huge number of options and the standard tabbed inspector layout doesn't work for you, check out the Omni Group's OmniInspector framework. Try to use it for good, and hopefully you'll figure out how to obsess over UI as much as you do over graphics now :-)
(running in slow motion, reaching out in panic) Nnnnnoooooooo!!!!!
:-) Seriously, as I mentioned in reply to Ken's excellent answer, trying to force a "Windowsism" on an OS X UI is definitely a bad idea. In my opinion, the biggest problem with Windows UI is third-party developers inventing new and inconsistent ways of presenting UI, rather than being consistent and following established conventions. To a Mac user, that's the sign of a terrible application. It's that way for a reason.
I encourage you to rethink your UI app's implementation from the ground up with the Mac OS in mind. If you've done your job well, the architecture and model (sans platform-specific implementation) should clearly translate to any platform.
In terms of UI, you've been using a Mac for a year, so you should have a pretty good idea of "the norm". If you have doubts, it's best to post a question specifically detailing what you need to present and your thoughts on how you might do it (or asking how if you have no idea).
Just don't whack your app with the ugly stick by forcing it to behave as if it were running in Windows when it's clearly not. That's the kiss of death for an app to Mac users.
Is there a way to get textboxes, labels and other wpf controls in xna that supports margins, etc that flexes for window size?
You might give CeGui a shot.
If your game needs advanced GUI capabilities, CeGui# might just hit the nail on the head for you. Marketese aside, this is a seriously good GUI library with Buttons, ListBoxes, Scrollbars, ProgressBars, Sliders, ComboBoxes and more.
To access the Xna version you'll need to check out the latest copy from the project's SVN and load up CeGui-XNA.sln.
There are other options listed in this thread, but I have no idea how well any of the others work (and it probably isn't a comprehensive list anymore).
The official GUI systems FAQ thread in the XNA Forum:
What GUI systems are there for the XNA framework?
CEGUI# is powerful, but it doesn't support the Xbox 360 (eg. its design doesn't include responding to game pad input) - a major overhaul would be required to refit it to be usable with something else than mouse and keyboard.
Not exactly what you're looking for, but here is an example of getting winforms GUI elements mixed in with XNA 3d content:
http://creators.xna.com/en-US/sample/winforms_series1
Check out SQUID: http://www.ionstar.org/
It's a really clean, fast, and engine independent UI system. I've worked with it extensively and really enjoy using it. The download includes sample code for XNA 3.1, Truevision3D, and SlimDX.
It is possible to embed an XNA game in a WPF form (google: XNA in WPF) if you target only Windows system. You will then have access to all the controls available in XPF for your 2D GUI.
If you also target Xbox 360 or Zune; you must make your own GUI library :(