Right now, when I go to the diffview of a file in gitkraken, it more or less exactly shows only the changed lines. Is it somehow possible to see the whole file with the changes highlighted? Seems like a really basic requirement to me.
As of KitKraken 6.1.4, there are two ways to view the whole file, depending on wheter you want to see the old and the modified version side by side or just the modified version:
In the top right of the diff view, change from Hunk View (which only shows hunks, as the name suggests) to Split View: This will show the whole file in the old and the new (modified) version:
In the top center of the diff view, change from Diff View to File View. This will show the whole file in the modified version on the whole screen:
Related
I am trying to intergrate our input method to the 10.10.3
And I found it's not easy to act like SCIM.app as the pic shows
I opened the activity monitor to see what file it opened (the SCIM.app was not running) As you can see in the following images:
The left shows the file list opened by System preference, and the right shows after I click the pinyin-chinese, the file list opened.
So I guess the little view was created by CoreChinese.framework. Since it was in /System/Library/PrivateFramework , It seems impossible for me to show this view as SCIM.app by a normal way.
I turned to nm and hopper disassembler...But I found it a long way to go
I guess you guys may encounter the same question, maybe you can help me.
Yes, I came across the same problems with yours.
1.It's easy to know that the view you saw, is provided by two part, the upper keyboard is a webview, which takes data in /System/Library/Input Methods/SCIM.app/Contents/Resources/*.keylayout, and finally shown by IntlKeyboard.prePane located in resources directory of Keyboard.prePane. and also you can find the actual html and pics, and 2nd part is a self-defined view provided by Preferences.prefPane.
2.Then 2nd part is to show the view you saw under the keyboard. as SCIM.app does, a file named Preferences.prefPane(must in the Resources directory of SCIM.app) was taken by IntlKeyboard.prePane.
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.
Every once in a while I try to add a new data model version, and the menu item is missing. It seems the Editor menu is supposed to change depending on the file selected, and this sometimes doesn't happen. It the past I've randomly clicked, cleaned, built, etc. and eventually it showed up again with me not knowing what happened. Today it seems restarting Xcode fixed it, but I don't know if that will always work. Below are two screen shots, the first showing the wrong menu, and the second showing the correct menu. My data model is selected in both cases. Has anyone else seen this? Is it a bug, or is there some setting or selection I'm missing?
From the color of that file navigator bar I can see that you did not select the datamodel file. You probably were in "Assistant Editor"-Mode and had a .h or .m file on the right side. The active cursor was in the right file too.
The selected file shows a darker shade of gray:
The not selected file uses a lighter shade of gray:
It's important to know that the file selection highlight in the left side bar does not change when you select a different file without using the side bar. Don't trust the sidebar when you are editing files.
Click into the data model file first and your menu will be like you expect it.
Unless your are selecting the menu super fast after selecting the file (possibly not giving Xcode time to swap it out) then I say file a bug report http://bugreporter.apple.com
You should give Xcode a few moments to swap the menu out though to determine what kind of bug it is, if it doesn't swap out after 60 seconds or so then it likely isn't just a performance issue). Make sure to include a system profile as I just checked on my and every time I switched to a data model it changed the menu accordingly.
Does the same thing ever happen with xib files? Any other file types you use that sometimes have different menus?
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.
My project has maybe 130 controls (total of all labels, textboxes, etc.) in an SSTab (4 tabs). The project loads fine, it runs fine, I don't see a single error or warning at any point, but when I save the form with the SStab on it, the SStab data isn't saved (it is completely gone). Normally the relevant portion of the .frm file looks like this:
Begin TabDlg.SSTab SSTab1
Height = 8895
[1550 more lines of code for all the controls]
Width = 540
End
Begin VB.Menu FileMenu
But lately it's getting cropped to:
Begin TabDlg.SSTab SSTab1
Begin VB.Menu FileMenu
This is very frustrating! In my VB IDE, the frame, sstab, and all the controls are there, editable, running/compiling fine, no error messages at any point, but when you save the file, 1550 lines of precious sstab data just disappears - again, with no warning or error messages. So if you exit and restart the IDE, you get a form load error because 60% of the code is now missing. The log file points to the first error it finds (in this case a Begin TabDlg with no End) - there's no other info in it. (The log file was generated after the code was deleted and saved, so it makes sense that it wouldn't be helpful.)
When I first posted this question, I thought it had to do with the number of controls, because it appeared after I added a control, and in my first few tests, seemed to disappear when that control (or other controls) was deleted. Now I can't seem to get that form to save under any circumstances, even when I delete many controls (bringing the number of controls far below where it was when it was last stable).
I also tried deleting the SStab and moving all the controls to 4 different frames. I successfully did that in the IDE, but when I saved, a huge chunk of the data (starting with a slider control) was missing. So I have no fraking idea what is going on.
The problem is reproducible on two different PCs, so it doesn't appear to be a hardware/corrupt software VB install issue.
Has anyone else run into something like this?
Create a UserControl for each tab. That makes editing MUCH easier. It also allows you to nicely modularize the code, so each tab lives in its own file, and it'll allow you to reuse tabs elsewhere if you want.
Sounds horrible, never heard of anything like that.
Presumably you aren't getting an error log file from VB6 when you load the form into the IDE before it gets corrupted? The log file has the same filename as the form file but with a .log filename extension. For example, if errors occurred when loading Myform.frm, Visual Basic would create a log file named Myform.log. The error messages you might see there are documented in the manual.
Have a look in the Windows Event Log, see whether it records any interesting problems against the VB6 IDE?
Are you using any weird controls? Maybe one of them is somehow corrupting the FRM or FRX. FRM files are just text as you obviously know & the format is documented in the VB6 manual. Can you see any corruption in the FRM in a text editor? If you remove any properties defined in the FRX, does it still fail.
I think I would try creating a new project and a new form, and then use the IDE to copy and paste all the control definitions into it - no code. Play with the new form, see whether it has the same problem. Maybe you can recreate the form this way without the problem. If the new form does have the problem, do the same thing but only take half the controls. Maybe you can find a problem control by "binary search".
I get the same problem when attempting to save a form when the .FRM is writable but the .FRX is read-only
Not sure if this is the issue, but on a VB6 form, there is a limit to 255 (or is it 256) named controls. Perhaps you are running into that?
One way around that limitation is to use control arrays. For example, if you had 10 labels, instead of label1, label2, label3, etc, you could do label(0) through label(9), and use up only one named control.
The other thing worth mentioning about the SSTAB is the way it shows/hides controls. While it may appear that the controls are on separate tabs, what is really happening is that the controls are getting moved waaaayyyyy to the left (and consequently out of view). Perhaps with so many components, the SSTAB is choking on this in the IDE as it tries to render the controls in design view?
Again, not sure if this is the issue, but I know these two tidbits are relatively unknown.
So the SAVE function is not working.
I suspect one of the components you are placing on the tab strip is the culprit.
So ..
1) Take an inventory of each and every kind of component you are placing on the form
2) eliminate one (kind), SAVE
3) Did it SAVE?
-> Yes = that was the problematic control
-> No = return to step 2, but pick another kind
Of course, its important to remove all controls of a certain kind in step #2 (for example, ALL labels, or ALL textboxes, etc).
I have never heard of this happening however.
You are not alone! I've seen this problem. . .in fact I'm dealing it right now, which is what brought me to this site.
I've been working with VB since '94 (VB3) and I first saw this problem about 5 or 6 years ago, while using VB6. My solution then, was not unlike some of the suggestions that you have recieved from the good folks who've responded above: throw out the existing file and rebuild the form in a new file. I did that back and the affected form has worked ever since.
My current problem is appearing in another, much newer form, and the replace/rebuild option (performed about a month ago) only worked for about three weeks. Now the problem is back and each new iteration of the file gets corrupted very quickly. Following the reply above regarding the total number of allowable controls, I'm looking into just how many controls I have. . .and, as it happens, I was in the process of consolidating the primary the buttons and menus into control arrays, simply because it was going to streamline their management.
I can also confirm your observations about moving the project to a second PC. . . I've done that too, and problem persists. Moreover, I can add that I have moved the project from one shared storage system to another to no avail. (The original storage location was on a drive mounted to a Win-tel system and the new location is on a UNIX-based NAS!)
Just rebuilt the file again and checked: Controls.Count = 62, so I am no where near the 255 control limit mentioned previously. This is indeed strange! (Not to mention furstrating!)