A question about Windows 10

I have always done my developing on a Mac, but have finally decided it is worthwhile having a PC (instead of a Parallels virtual Drive). On the Windows PC I have downloaded and installed both Git and SourceTree. I am about to transfer my files from the Mac to the PC. My question is, should I delete the (mostly invisible) Git files from my project, or will Windows 10 recognise them as such, and keep them invisible? I am thinking of .git (which I think is a folder) and .*.xojo_uistate.

Any advice would be appreciated, because I haven’t much real knowledge of the Windows OS.

Why don’t you just pull the project from your git repository?

I don’t have a git depository, mainly because everything I do is for free, and a hobby, so I don’t want to have to pay. Sounds mean, I know, but National Super is not that flash.

If it’s free and open source, github is open to you.

@Cliff Strange you make a lot of mention of git in your question so hence my answer. As you don’t currently have a git repository I would save the project as a binary project onto a flash drive & open it on you new Windows machine then save it as a text project where you want it to live.

However that won’t synchronize changes between systems, so as @Tim Parnell says use the free github solution.

Cliff, may we ask why you are doing this? Are you abandoning the Mac for development?

If not, you do realize that you can remote debug from the mac to a windows machine and it’s a very useful way to do your testing.

Also, most folks say that the Xojo IDE is more stable when running on Mac than Windows…

For closed source, 1 free private project on bitbucket.

@Michael Diehr I just feel that I would like to feel exactly how the app works on Windows. Also, and it could be something that I am doing wrong, I so often have to make a change to the layout when the app is finally transferred to Windows, particularly in Container Controls. I really don’t think that Xojo works any worse on Windows, not for the short time I have been using Windows.

However, I love the Mac, and prefer to write apps for the Mac, but that is not always a choice.

@Oliver Scott-Brown I will look at bitbucket. The lack of a free private project was keeping me off GitHub.

FWIW: to download the last El Capitan beta (the other day), I used my Windows Laptop for internet stuff while the OS X laptop was installing the OS.

This was nearly my worst moment in life. I was asking myself how I was capable of using that WIndows machine during nearly two months last year (Nov. Dec. 2014)… And I had an external mouse…

Back to the subject: VirtualBox (free) with a Shared Folder (thanks to Norman advice) was nice for me when I used it.

main entry

Downloads page.

You are right. Using your program on a true Windows machine is the only way to make sure it performs adequately. In particular, it is impossible to see what flickers on a Mac.

As for all the unnecessary comments about how bad Windows is supposed to be, just let them kwack…

If customers use Windows, who am I to tell them wrong ?

[quote=247427:@Cliff Strange]@Michael Diehr I just feel that I would like to feel exactly how the app works on Windows. Also, and it could be something that I am doing wrong, I so often have to make a change to the layout when the app is finally transferred to Windows, particularly in Container Controls. I really don’t think that Xojo works any worse on Windows, not for the short time I have been using Windows.
[/quote]

True, but all of that can be done using the remote debugger and a windows VM. I don’t think there’s any advantage to moving the IDE to windows if you are a mac guy. Write your code and debug on the Mac, and then when you need to do windows testing, just set up the remote debugger on Windows.

The only exception to this is for performance: I write OpenGL/real-time audio/video software and it’s not possible to get a really good idea of the performance until I run it on “real metal” rather than a VM. But 95% of the time or more, the VM is great.

@Michael Diehr I do agree with everything you have said regarding the Mac. I have worked on a Mac (and only a Mac) since 1989. Not that I have been programming all that time, rather typesetting (Desktop Publishing it is called now). I had a Parallels VM and felt nothing but frustration with it.I upgraded my MacBook Pro to 8GB memory and allowed the VM to have 4GB. But I spent all my time developing on the Mac, and then only transferred the project to the VM when I wanted to Build it and create an installer, after making any changes due to controls not looking the same.

I just found the VM fairly sluggish, and because I didn’t start it up very often, I could have over a hundred Windows updates waiting, and they just took ages to download and install. So, I have purchase a PC and feel a lot happier about it. I haven’t as yet started a new program that is destined for the PC, so I am not sure if I will get it working on the Mac then transfer it over, or do the whole thing on the PC.

I do wish that all this wasn’t necessary, but in any case, I do need a PC or a VM to finally create the installer. I guess with time I will become as familiar with the PC as I am with the Mac.

However, I do appreciate everything you have mentioned, and I thank you for your thoughts.

Oh darn.
I have a Windows project coming up but no Windows machine. I’d hoped to use Virtualbox.
So I wont be able to see the real deal? If it looks ok on Virtualbox, it can still flicker on a Windows machine?

My main machine is a mid 2011 21.5" iMac. For years I complained that VM where sluggish, until I decided to use an SSD. The difference is striking. Now I can use Windows or Linux with decent performances.

However, even if developing on Mac, with all the familiarity it entails, is very enjoyable, I consider it paramount to do the last mile on a real PC. 99% of the mistakes one would do on a Mac that creates tremendous flicker can be avoided by running on a true PC, because VMs iron out any flicker, thanks to the excellent Mac double buffering. Personally, I rather work on the same machine as my user (well, the fastest PC I could find) instead of discovering I have to rewrite the whole UI after completing the program on Mac. Nice to have a Rolls Royce, but it is of no help when you need to actually drive a Chevy.

There are also enough hardware differences to make sure a program works as expected right away, rather than complain later in the forum with the phrase that should be hashtagged : “#It works perfectly on Mac”. Nothing is worse than a developer who has no idea about a PC, who did not even test in a VM, and goes spitting on the PC instead of working with the machine. The same goes for Linux as well.

I have the same philosophy for Web apps. Sure, it works perfectly when one runs local, but the only true test is to put it on the host, and preferably access it on a slow 3G phone. If I am not mistaken, Facebook developers are forced one day a month to work in the conditions of Internet.org at ridiculous throughput just to make sure the app will still perform adequately in 2G.

We awe it to our users to make sure our apps on THEIR hardware. Not simply in our lab.

VM’s need enough RAM and a SSD.

Because I wanted to have a redundant computer to run and test my VM’s on, just in case, I bought a simple quad core mac-mini with 1TB conventional drive. And yes, it is what it is, works but you would not persevere developing and testing on it all day, once you’re used to a fast computer.

To avoid getting surprised late I primary develop and test in the environment of the expected end user. Mac is not Windows and Windows is not Mac. Besides that it’s important to have a machine just meeting the minimal specifications you develop for and use that one for intensive testing. This is the way to be aware of the worst user experience and decide if that should be acceptable or not.

Once you’re feature-complete you’re roughly half way the development process. A fast computer does not change much. Back in 1996 I had a manager by default multiplying my expectations by 3. He was realistic and still satisfied.

On Windows I use a Samsung Transformer T100 as test for low end. It is a tablet screen (10") with a 1.33Gz processor and 1GB RAM. And the keyboard is extremely far from the Mac one. Rather bad. It is an excellent benchmark to see if I designed the app right for backscale.

On Mac too we tend to believe that all customers have fast machines and recent systems , and that may not be true. In spite of indeed renewals are more frequent, but I still have regularly questions from Snow Leo users on dual core.

Nothing is more embarrassing than to have an app on the market, and to get angry users report that it simply does not work on their machines.

Indeed.

As a developer you want to know if you have your work done well, you met the specs.
So a clear definition of the minimal platform to run on is indispensable and has to be taken into consideration during the entire designing process.

[quote=247713:@Joost Rongen]As a developer you want to know if you have your work done well, you met the specs.
So a clear definition of the minimal platform to run on is indispensable and has to be taken into consideration during the entire designing process.[/quote]

For end user programs specs tend to be the lower end of the spectrum. In the Windows world in particular, users do not upgrade their machine until it breaks down. As a result, and even if that system is not supported by MS anymore, there are still a significant number of XP machines. Actually about the same as Windows 8.1 http://www.theregister.co.uk/2015/01/08/windows_xp_overtakes_81_in_december_stats/

Corporate development is a different case, where minimum specs can be enforced much more easily.

The good old XP… I don’t support it anymore. Xojo inc. took the decision for me.

You are right at 100%.

On the other hand, if no one complain, nothing will be changed.