I was just about to start a git branch off the master branch to add some functionality to my application, that would also involve some additions to the interface.
However, i already have a branch for some other functionality that also involves some interface additions.
Will i be able to merge both those branches to master when i finish with them? Is there some good practice to, probably, structure xib-files in a certain way that would make it easy to merge afterwards?
What if I, for example, have a tab view with three tabs in one branch, and a tab view with three tabs in the other, and two of the tabs are the same, and one is not, will i get a four-tabbed tab view after the merge
You will most likely have a conflict, if the modified lines (involved in the tab definitions) are the same.
You will have 4 tabs only if, during the manual merge resolution, you mistakingly leave an extra tab definition.
See Painless Merge Conflict Resolution in Git for a great article on merge resolution.
That being said, regarding xibs specifically, its presentation seems good:
As of Interface Builder version 3, a new file format (with extension .xib) has been added, which is functionally identical to .nib, except it is stored in a flat file, making it more suitable for storage in revision control systems and processing by tools such as diff.
But this thread summarizes the actual feeling:
How is Git able to merge changes to XIBs?
The structure of an XIB isn't linear; there's no guarantee that you can just swap out portions of an XIB and wind up with a usable XIB.
Unless Git has an understanding of XIBs near Apple's, I don't see how merging could be
guaranteed to work.
That would leave you with the extra step, before adding your merge resolution in case of conflict, to open the modified .xib file in your XCode4 editor and check if everything still looks good.
Once that visual check is done, record the merge resolution through rerere, and you will have potentially automatic resolution in the future.
Of course you will be able to merge them both into master. It doesn't matter how you structure your files, git doesn't care about that.
Related
I'm trying to use the Visual Studio AutoHistory extension.
However, when I select "Take Snapshot" (except for the very first time), I see no difference in the AutoHistory pane. The "Old" timestamp remains the same and the "Now" edit box (and "X" to its right) are read-only:
How can I verify that my snapshots are really being taken? I feel as if the lens cap is still on the camera or something. How can I compare my last two snapshots?
It's not enough to look at the filename list with the 'old' and 'new' columns. Instead you really need to hover over those tiny snapshot entries to get information on when AutoHistory is doing the captures. If you want to change the label of a snapshot, seems like the interface requires you to grab the top of the little range box and drag it down to just above the item in question. Only then does it seem to allow your snapshot's label to be changed:
So, drag this box...
...down to this spot, right above the snapshot you just took:
And, apparently, a snapshot's label value is changed when the textbox looses focus (there's little indication that you've updated the text).
If you want to compare two snapshots, you have to painstakingly set the box's bounds to that of the two snapshots you want to compare:
I do like the power of this extension, but the interface can be maddening and isn't very intuitive.
Looks like the author(s) have abandoned support for it since they no longer reply to comments or requests. Would be awesome if it were open source since it just needs a few tweaks to really take this thing across the finish line!
When I launch the Comparison View (View > Version Editor > Show Comparison View), it shows me a timeline of two versions of my git repository:
If I tap the clock icon in the center, I can choose exactly which revisions I want to compare.
The problem is that there is only one revision available (light gray line), and the rest don't appear (i.e. they are dark gray lines). For example, in the screenshot above, there are only 3 revisions the user can choose from.
The repository definitely has many more revisions as evidenced by the fact that when I go to Source Control > History, I see many commits.
How do I make it so that all my revisions (or at least a specific one) is available in this list?
Comparison view is about reviewing the changes to this one file.
The repository definitely has many more revisions as evidenced by the fact that when I go to Source Control > History, I see many commits.
Yes, but the majority of those are not commits involving a change in the state of this file, so you are not seeing them in this part of the interface. And rightly so; that would be pointless. You are being shown here everything there is to show, i.e. the log for this file. Every version of this file in this branch contained in the repository is shown in this interface.
Now, having said all that, part of the problem is that this really is not a great interface. It's cute, and it's nice as far as it goes, but if you are trying to review and understand your project's history as a whole, it isn't all that helpful. Personally I almost never use it. Try Atlassian's SourceTree; it's free and fantastic. And ultimately, of course, there is no substitute for the command line.
I'm working on a document-editing application using CKEditor, where the user can open multiple documents side-by-side in a pair of editor instances.
Most of the time, the user will be editing two different documents, but it's also possible that the two editor instances might contain different views of the same document. That makes things tricky, since I'd like to changes in one editor instance to be immediately reflected in the other instance.
Without hacking the CKEditor core, is something like that possible?
If not, would it be possible to write a plugin that would provide that kind of functionality?
What about if I was willing to get into the core code and hack around a bit? How difficult would it be?
This is a very similar case to a collaborative editing like Google Docs allows. The only differences are that you won't need to synchronize this via network and that it's very unlikely (if not impossible) that the same documents will be modified by two users at the same time. This makes things simpler... a little bit.
A year ago me and my colleague (we are both CKEditor core devs) took part in Node.JS Knockout and our plan was to create a collaborative editor based on CKEditor. It was only 48h, so the result is not impressive, but it worked. The source code is here.
The main problem you'll have is applying changes from editor A to editor B without breaking a caret position in editor B. Basically, you cannot just take data from editor A and set them in editor B, because everything in editor B will be reset including scroll position and caret. Unless this is not a problem, but I assume it is.
So you would need to:
either find a nice algorithm for extracting changes (like diff, but working on a DOM tree, not an HTML string) made in editor A and an algorithm to apply them to editor B (and this is what we implemented on Node.JS Knockout),
or find a way to guess caret position after resetting data in editor B; for example you can remember the caret context in editor B before setting data and try to find it in data that will be loaded.
Both ways are doable, but the first way will give better results if you'll implement it well. However, if your you don't know enough about DOM and contenteditable, then this task may overwhelm you. In this case I would advise to block possibility of opening one document twice.
I'm new to developing on the Mac and am looking to implement an interface similar to Spotlight's - the main part which seems to be an expanding table/grid view.
I was wondering if there is a component Apple provides for creating something like this or is available open source else where.
Of course if not I'll just try and work something out myself but it's always worth checking!
Thanks for your help in advance.
New Answer (December, 2015)
These days I'd go with a vertical stack view ( NSStackView ).
You can use its hiding priorities to guarantee the number of results you show will fit (it'll hide those it can't). Note, it doesn't reuse views like a table view reuses cell views, so it's only appropriate for a limited number of "results" in your case, especially since it doesn't make sense to add a bunch of subviews that'll never appear. I'd go so far as to say outright you shouldn't use it for lists of things you intend to scroll (in this case, go with a table view).
The priority setting can be used to make sure your assumption of what should be "enough" results doesn't cause ugly layout issues by letting the stack view "sacrifice" the last few.
You can even emulate Spotlight's "Spotlight Preferences" entry (or a "show all" option) by adding it last and setting its priority to required (1000) so it always stays put even if result entries above it are hidden due to lack of space.
Lately all my UI designs for 10.11 (and beyond) have been making heavy use of them. I keep finding new ways to simplify my layouts with them. Given how lightweight they are, they should be your go-to solution first unless you need something more complex (Apple engineers stated in WWDC videos they're intended to be used in this way).
Old 2011 Answer
This is private Apple API. I don't know of any open-source initiatives that mimic it off-hand.
Were I trying to do it, I might use an NSTableView with no enclosing scroll view, no headers, two columns, right-justified lighter-colored text in the left column, the easily-googled image/text cell in the right column, with vertical grid lines turned on. The container view would observe the table view for frame changes and resize/reposition accordingly.
Adding: It might be a good idea also to see if the right/left justified text (or even the position of the columns) is different in languages with different sweep paths. Example: Arabic and Hebrew are read right-to-left. Better to adapt than to say "who cares" (he says flippantly while knowing full well his own apps have problems with this sort of thing :-)). You can test this by making sure such languages are installed on your computer, then switching between them and testing out Spotlight. Changing languages shouldn't pose an issue since the language switching UI doesn't rely on reading a foreign language. :-)
For reasons unknown, the VB6 compiler often likes to reorder the contents of .vbp files and the control descriptor block at the top of .frm files (The code that describes the properties of controls on the form. Code that you don't see in the IDE but you do see in a text editor and when doing diffs against the previous revision in version control.). This is monumentally annoying and very distracting when comparing revisions of a file.
Is there a way to prevent this?
I don't think there's much you can do about this. I've noticed the same problem: the IDE likes to rearrange things for seemingly no apparent reason. Some things I've noticed:
When you use the SSTab control, VB
likes to rearrange properties for
tabs, especially the TabEnabled
property.
For project files, it randomly
rearranges the order in which files
appear and I think I remember seeing
cases where similar file types are
not always grouped together and end
up mixed in with the project
properties. You don't have
much control over this, unless you run all your VBP's through some type of sanitizer that groups like files together (forms in one group, modules in another group, etc.) and sorts them alphabetically or something, so that they remain consistent. One possible way to handle this could be to write an IDE add-on that automatically does this everytime you save changes to a project file, or come up with some batch process that will just recurse over your source directories and clean up all the VBP's in one go.
The IDE seems to randomly change the
case of things; this seems to happen
frequently to project references.
Sometimes they are output in lower
case, and other times they are
output in upper case. You can get
around this by choosing "Ignore
Case" when you diff files in
SourceSafe.
Control coordinates, such
Top, Left, Height, and Width, can differ between
two revisions of the same form. This is due
to different developers using
different screen resolutions and/or
different screen DPI settings while working on the same form.
If you aren't doing this already, I
highly recommend that you get
everyone to develop using the same
resolution and same DPI setting.
The differing values are caused by rounding errors that
occur when logical screen
coordinates at different resolutions/DPI settings
are converted to twips, the default
coordinate space that VB uses for
laying out forms. Additionally, while I'm on the topic, make
sure everyone has their display set to 96dpi,
because if you develop VB forms at
120dpi, there is a really really good
chance they won't display correctly
on a display set to 96dpi.
There are probably other things I
can't remember right now...
As for the order of controls being changed in form files, this is normal, and you usually don't want to try rearrange the order of controls by hand if it happens to change from one revision of the form to the next. The order that the controls appear in a form file determines their Z-order on the form. If the order of the controls changes in the .frm file, this will change their relative Z-order on the form, which could lead to unintended results in how your forms are displayed.
Can you make the .vbp file read-only when you aren't editing it (ie, adding modules, etc)?
As far as form files...I can't think of any good way at all to make VB not reorder them. But I have to say that I've never encountered this before. Are you sure that something else isn't going on?
It's entirely possible that I just never paid any attention to this in the past, so I'm not saying you are mistaken, just offering my own observations.
I have noticed that re-opening the form and saving again often restores a consistent order.