In my program I have a bunch of RectangleFigures where each figure holds text. The text is held in a TextFlow which is held by FlowPage to allow word wrapping. RectangleFigure then uses getPrefferedSize() to make itself just big enough to hold it's text (using a fixed width).
These RectangleFigures are held by a ScalableLayeredPane. The problem rises when I try to zoom by calling setScale(). Most of the time it works fine but occasionally the ends of the text will be cut off. If I zoom again the figure will correct itself. I should also say that I have tested my program using Figure instead of RectangleFigure with the same result.
Has anyone dealt with this bug before and can shed some light on why this is happening and/or know of any workarounds?
I havn't included any code because this is a rather large program and relevant chunks of code are spread out. But if you would like to see the code let me know and I will try piecing it together.
I was holding the text inside a Figure and that was the Figure I was calling getPrefferedSize() on. But I then put that Figure(lets call it textFigure) inside a second Figure(called containerFigure). I was essentially doing the equivalent of containerFigure.setSize(textFigure.getPrefferedSize()).
You're probably wondering why I was doing that. Well originally I planned on having containerFigure hold multiple things instead of just textFigure. I ended up coding it differently but forgot about the unnecessary extra layer.
So even though containerFigure was technically the size it needed to be scaling caused problems. But when I removed containerFigure and started placing textFigure directly on the screen this bug was fixed.
This is a fairly specific error on my part so I don't know how much help this will be to others. To make it more broad if you're having some kind of sizing issue just check to see how the size of parent Figures are being set. Using sizes from child Figures might be incorrect and/or causing problems.
I am new to coding and wanted to get some hands on practice with a project I have in mind. Here it is:
Let's say you have blank page and on the side of a screen you have several items you can choose to draw on the blank page. For example the background can be mountains, the ocean, a forest etc. On top of that you can place a house, a church or another selectable element. Whatever you like.
It is like a picture editor where you can put together a picture with different pre-given elements. Or like in video games where you can create your own character.
What would I need to build a web application for that kind of thing?
This link should get you started but it won't be the complete answer to your question - http://www.webdesignerdepot.com/2013/08/how-to-use-html5s-drag-and-drop/
Essentially, you can achieve your image dragging and dropping using similar techniques. It will require a bit of Spike work from yourself, and looking into how HTML5 can handle drag and drop. I discovered this resource fairly quickly and I think the solution you want isn't as complicated as you may think, it just requires a bit of know-how regarding drag and drop operations within HTML5 :-)
Also, there may already be some JavaScript based API's that do this sort of thing easier but I'm not too aware - I suppose starting this way could be a great introduction for you and you may wish to expand once you've done some work for it :-)
Hope this helps you and your coding journey!
Greetings everyone,
A friend and I are discussing the possibility of a new project: A translation program that will pop up a translation whenever you hover over any word in any control, even static, non-editable ones. I know there are many browser plugins to do this sort of thing on webpages; we're thinking about how we would do it system-wide (on Windows).
Of course, the key difficulty is figuring out the word the user is hovering over. I'm aware of MSAA and Automation, but as far as I can tell, those things only allow you to get the entire contents of a control, not the specific word the mouse is over.
I stumbled upon this (proprietary) application that does pretty much exactly what we want to do: http://www.gettranslateit.com/
Somehow they are able to get the exact word the user is hovering over in almost any application (It seems to have trouble in a few apps, notably Windows Explorer). It even grabs text out of obviously custom-drawn controls, somehow. At first I thought it must be using OCR. But even when I shrink the font so far down that the text becomes a completely unreadable blob, it can still recognize words perfectly. (And yet, it doesn't recognize anything if I change the font to Wingdings. But maybe that's by design?)
Any ideas as to how it's achieving this seemingly impossible task?
EDIT: It doesn't work with Wingdings, but it does work with some other nonsense fonts, so I've confirmed it can't be OCR.
You could capture the GDI calls that output text to the display, and then figure out which word's bounding box the cursor falls in.
Well, for GDI controls you can get the position and size of the control, and you can usually get the font info. For example, with static text controls you'd use WM_GETFONT. Then once you have that you can get the position of the mouse relative to the position of the control and use one of the font functions, perhaps something like GetTextExtentPoint32 to figure out what is under the cursor. I'm pretty sure the answer lies in that direction...
You can run dumpbin /imports on the other application and see what APIs they are calling.
Ours is an open-source Mac application localized by volunteers. These volunteers will do their work on special localization builds of the software (with unstripped nibs), then send us the changes to integrate into the original xib and strings files.
The problem is that, while there is a way to integrate string changes without blowing away previous size changes, I can't see a way to integrate new string and size changes (as when we add or replace views).
The only way to do both that I can see is for localizers to work directly with the original xibs and send us diffs. That means they have to download the entire source code, not just a localizable version of the release, work in Xcode as well as IB, and either run the diff command themselves (per xib) or install and use Mercurial.
Is there any better way for a xib-based application?
UPDATE January 2014: Apple’s ‘autolayout’ code combined with their ‘Base’ localization stuff took most my ideas and improved on them. I recommend against using my old tools that I talk about in this answer. But, also, man was I right!
I strongly strongly STRONGLY recommend against frame changes in localizations. I know this runs counter to Apple's advice, but there are SO MANY problems with allowing frame changes - you end up with a billion edge cases.
Imagine you have 10 XIBs in your app, and you support 12 languages. You've got 120 different layouts to support, now. You just can't do this.
Change the strings, leave the views where they are. Make 'em bigger in ALL languages, if you need to. It sounds like this shouldn't work but it does. (I won three Apple Design Awards with an app that's localized in 10 or so languages this way.)
Specifics:
For radio and checkboxes, just let them extend far to the right, beyond the last English character. That also provides a nice big landing area for imprecise mousers.
For buttons, they should be wide anyhow, because it never looks good to have text cramped in the middle of the buttons.
For titles on tableview columns, you should autosize when you load 'em up, if needed.
For explanatory text, you should have some extra space to the right, and maybe an extra line. It just makes the English version of the XIB seem less cluttered. Sure, the Germans are going to see a slightly tighter XIB, but, hey, they're Germans -- they're probably used to that. There's probably even a German word for it. "Deutscheninterfakkenclutterlongen."
If a text field is centered, just add equal space on both sides. There's no reason not to.
I've combined this with scripts that suck all the strings out of my XIBs and put them in .strings files, and then dynamically put the strings back at run-time, so anyone can localize my app without any special tools. Just drop in a bunch of .strings files and run it!
Blog post including full source: [Lost in Translations]¹.
I confess that I'm not all that familiar with the process of localizing Mac apps. But I did run across a script that's part of the Three20 iPhone library that seems like it might be useful: diffstrings.py is a Python script that "compares your primary locale with all your other locales to help you determine which new strings need to be translated. It outputs XML files which can be translated, and then merged back into your strings files."
EDIT: As a companion to Wil Shipley's answer to this question, I'll add a link to a blog post he just wrote that goes into more detail about localization, and provides some of the tools that he's built to ease the process.
Where I used to work, we had this issue as well. Our app was getting translated into 10 different languages.
At first, we tried doing what Wil suggested, which is to make everything super wide and fit in every language. Unfortunately, "online backup" might be pretty short in English, but in other languages (especially Spanish), it's really long ("copia de seguridad" just means "backup"). Widening our UI made everything look pretty terrible.
One day, I was playing around with some Core Animation stuff and discovered the CAConstraint class. CAConstraint is basically a way to define a layout relationship between two CALayers. You give one layer a name (like "layerA") and then say "layerB is constrained [in such-and-such a way] to a sibling layer called layerA". Then, whenever the layer named layerA is repositioned or resized, layerB automatically moves as well. It's really neat, and it's just what we were looking for.
After a couple of days of work, I came up with what is now CHLayoutManager. It's basically a re-make of CAConstraint and friends, but for NSViews. Here's a simple example of how it works:
CHLayoutConstraint * centerHorizontal = [CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMidX relativeTo:#"superview" attribute:CHLayoutConstraintAttributeMidX];
CHLayoutConstraint * centerVertical = [CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMidY relativeTo:#"superview" attribute:CHLayoutConstraintAttributeMidY];
[aView addConstraint:centerHorizontal];
[aView addConstraint:centerVertical];
This will keep aView centered in its superview, regardless of how the superview is resized. Here's another:
[button1 setLayoutName:#"button1"];
[button2 addConstraint:[CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMinX relativeTo:#"button1" attribute:CHLayoutConstraintAttributeMaxX]];
[button2 addConstraint:[CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeMaxY relativeTo:#"button1" attribute:CHLayoutConstraintAttributeMaxY]];
[button2 addConstraint:[CHLayoutConstraint constraintWithAttribute:CHLayoutConstraintAttributeWidth relativeTo:#"button1" attribute:CHLayoutConstraintAttributeWidth]];
This will keep button2 anchored to the right edge of button1, as well as keeping button2's Y position and width the same as button1's.
Internally, CHLayoutManager uses an NSValueTransformer to calculate the new positioning information. Some of the CHLayoutConstraint initializers accept an NSValueTransformer, so you can create arbitrarily complex layout manipulations.
We used this for constraining and laying out the entire UI, and then doing all of the localization in code (and subsequently calling -sizeToFit, with some modifications). Our UI would just flow into its final layout. It turned out to be extremely convenient. We'd just package up our .strings files, send them off to the translators, and then drop them in to place when we got them back, and our app would instantly be localized for that language.
CHLayoutManager isn't perfect. It doesn't resolve conflicts, but simply applies constraints in the order they're added. So you can constrain (for example) the MinX of a view 42 different ways, but only the last one will be used. Also, if you constrain the MinX and the MaxX, they'll also be applied in the order they're added and will not end up stretching or shrinking the width. In other words, constraining one attribute of a view will not affect the other attributes. It's compatible with 10.5+ (GC and non). However, due to some changes in Lion, it's unlikely that I'll address the shortcomings.
Despite these shortcomings, it's an extremely flexible framework, and (IMO) some pretty nifty code. (Plus, I swizzle -[NSView dealloc]! Yay!)
Update
Now that AppKit has this same functionality (via NSLayoutConstraint), I recommend using that system instead of CHLayoutManager. It is far more robust.
Bear in mind that XIB files are merely XML files in an obscure format, so you can translate those easily enough, provided that you can find what strings there are there to translate in the first place. For example, here's the snippet that creates a button called Jenson:
<object class="NSButtonCell" key="NSCell" id="41219959">
<int key="NSCellFlags">67239424</int>
<int key="NSCellFlags2">134217728</int>
<string key="NSContents">Jenson</string>
...
</object>
So you can get that string translated and then substitute occurrences of it in the XIB with your translated value. In order to verify it's working as expected, you could change the language to use random keys instead (like BUTTON_TITLE) which will make it easier to spot when one's missing.
However, the positions/sizes of the items are fixed, so you can have titles that overflow the space given in a different language. That's one of the reasons why Macs have separate XIB files for every language, to allow adjustments to be made on a language-by-language basis, however difficult it is to maintain.
Before you throw me out into the cold with your bold assertions that this is not programming related, please hear me out.
I'm looking for a visual metaphor (Icon) to suggest the idea of inversion of a filter. So if a user has a filter which reduces a list of 10 items to 4, I want a button that will allow the user to invert the filter to display only the other 6.
Another wrinkle is that the UI will also have a button for removing the filter nearby.
While this certainly isn't a nuts-and-bolts programming question, I think it's relevant to the process of software creation. As a developer it's relatively easy to construct the mechanisms to perform complex filters, but it's all for naught if normal users find the presentation confusing.
If an icon doesn't jump to mind for you, then there probably isn't one that will have obvious meaning to your users either. You're better off using a text label for this.
If it must be an icon, then it doesn't matter much what it is, since users won't be able to guess it any way, but at least try to make it visually distinct and memorable if not particularly intuitive. MS Access uses a funnel to represent "filtering." Maybe use an upside-down or white-on-black funnel for inversion? (An X'ed-out funnel means "don't filter").
Whatever. Like I said, it doesn't matter much.
Maybe it's not the most appropriate, but what about the logical inverter icon?
Maybe something like this: Invert Selection?
If you really need an image, I'd suggest looking at image editing programs like GIMP or Photoshop and seeing how their "invert selection" buttons look.
16x16 pixels is enough to draw two small list boxes with an arced arrow going from one to the other where the second has an inverted selection list of the first.
alt text http://img524.imageshack.us/img524/6782/4092009000139am.png
I think the 3 icons above could be used in one spot with each user click causing a rotation through the 3 of them. I think the above icon set offers the following benefits:
F - clearly communicates it is for a filter control.
Red and Green - clearly communicate ON and OFF action.
The line above F means inversion (I think - based on memories of boolean algebra at university - I could be wrong?)
The use of yellow while still maintaining the F, links the new action (filter inverted) to the previous filter actions let still communicates it is different to the filter simply being turned on or off.
On icon click rotation could be, (starting) Red - Green - Yellow - Red. This is a widely understood rotation pattern that the user would quickly pick-up. Therefore no need for additional filter on/off button.
Simpler solution - a user only needs to look at a single icon (even perhaps only with peripheral vision) to deduce the current state of the control.