Restructure files to allow for easy import of cef2go package

[cztomczak]

Make necessary changes so that the cef2go package can be imported with statement like this: import github.com/CzarekTomczak/cef2go.

Not yet sure how to do that, golang documentation is not clear in that regard.

I think that after restructuring, the main_windows.go example should update this code:

import cef
import wingui

To this:

import github.com/CzarekTomczak/cef2go/cef
import github.com/CzarekTomczak/cef2go/wingui

Some questions:

1. Should package be installed with "go get" or "go install"?
2. Will it also work by writing "import cef2go/cef" after cef2go package is installed?
3. Are there any additional changes required to run.bat and Makefile?
4. The main_windows.go example - should this example be provided in two copies, one with import cef for local development and the other for download with import github.com/...? Do we need to make two copies of the same file or is there a better way to do this? Is there something like try: import cef except: import github.com/...?
5. cef2go is not a pure go package. After compiling to run it it is required for .so/.dll files to be in app directory. Adding it to PATH may not be the best idea, as it may cause loading of wrong .dll libraries (one such issue was already reported on forum). So how do we go about that, writing import github.com/... is not enough? What would be the simplest Hello World example? This needs further investigation.

I don't think there can be created a simple one click HelloWorld example. It is still required to download binaries and copy them to the Release/ directory, as explained in README.

[neonsoftware]

Hi Czarek,

I think that this would really be a crucial next step. It would make it, as people say, 'idiomatic', so it will feel natural and people would implicitly know how to use it even without instructions.
I am try to add my thoughts on you r points here, sorry it they are not accurate and might be wrong, but I am not a big expert.

1. The first handle to the project for users should be 'go get', which will also install it
2. It should still need the github prefix I guess : "import .github.com/CzarekTomczak/cef2go/.."
3. The makefiles and .but files should ... go :) All should then be compiled by the go (and cgo) compiler. It can be done probably by using the functionality of .h import that go provides with the built-in cgo mechanism. https://golang.org/cmd/cgo/ . All the compile and linking flags can easily be moved from the makefiles and specified directly inside the .go files, which will be also cleaner.
4. Probably the examples will need to be external and re-designed.
5. This is true. The fact that the 'output' of cef2go requires external dynamically linked resources makes it a bit 'special'. But maybe this might be mitigated by the fact that it might be separated the concept of the main binary and the concept of the encapsulation.

Continuing with 5.
For example: an OS X application needs two things :
a) the main binary
b) its 'capsule', which is the structured .app folder and the cef.framework for linking

Now, to the current state, while the application is developed, a) gets re-compiled every time, while b) is always the same.
So b) might very well, in my opinion, be excluded by the complexity of the application generation, which is now done by the makefiles, and become just a folder that is provided by cef2go somewhere statically. (or, generated by a special tool provided by cef2go which downloads the latest cef binaries and creates an .app with the name chosen by the user).
If we consider that the role of cef2go, at that point, is just to generate a) then the mechanism gets simpler and it could be achieved with a pure GO compilation workflow.
Of course, it would be then the responsibility of the user to place the binary inside the static .app that he must have provided himself with, but I think that that would be more that acceptable for him, or even natural.

regarding the HelloWolrd, yes, it will be different in some way it will be done, maybe, again, as external tool.