Using the GNOME Documentation, I wanted to write a demo of using webkit and GTK4 together in Vala by porting GTK3 code. However, when changing the library from gtk3 to gtk4, a crazy amount of errors occur, 2726 in total. Most of them are very similar, seeming like library conflicts, saying "error: `Gdk' already contains a definition for ...". It seems like Webkit2GTK is on version 4 in Vala, while in Rust there is a Version 5. It also seems like they had an Experimental flag to support GTK4, but you have to compile from source, and that was almost a year ago.
webkit2gtk is a library that integrates WebKit into GTK: webkit2gtk4 integrates with GTK3; webkit2gtk5 will work with GTK4. It isn't ready yet however, so that's why it's an experimental flag still at this point. Once webkit2gtk5 is out, you'll also have to wait until the Vala bindings are out.
In other words, the library/bindings you're using can't work with GTK4, as that's not what it's built for. That's why you have all those errors.
Related
I starting to look into porting my application from Gtkmm 3.24 to Gtkmm 4.x (not sure which version yet). For now, I am only trying to understand what exactly is deprecated and how much work is needed for planning. One way to ease porting is to look into all deprecated usages in the Gtkmm 3.24 version and update them to the newer flavor before porting. I have found several macros that can help with that:
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
When I #define these, the compiler throws error when meeting deprecated stuff because they have been disabled. This is nice, once the code is leveled up, to make sure the code stays free of deprecated usages.
In my case, however, the code is still full of deprecations and the compiler stops compilation on the first deprecation it meets. This does not help me much in understanding where the deprecations lie and how much work is needed. I could go about and solve every error, one by one, until there is no more (this is ultimately what I will do) but I can't know ahead how much time this will take.
What I would really like are macros that throw warnings when meeting deprecation, but let the compiler go on about building. This way I could get a list of everything that is deprecated in my codebase and plan work appropriately. I have browsed the Gtkmm documentation and codebase but found nothing.
Do such macros exist and if so, what are they?
The solution was to use
GTKMM_DISABLE_DEPRECATED
GDKMM_DISABLE_DEPRECATED
GLIBMM_DISABLE_DEPRECATED
GIOMM_DISABLE_DEPRECATED
like I did but to use the -k flag with make. From man make:
-k, --keep-going
Continue as much as possible after an error. While the target
that failed, and those that depend on it, cannot be remade, the
other dependencies of these targets can be processed all the same.
Source: Inkscape GTK+ 3 migration wiki page.
I am looking for a way of controlling translation format for Purescript code when target platform is JavaScript.
"spago bundle-app" generates JavaScript code for ES5 version.
spago/pulp/purs --help doesn't tell much.
googling by keywords like "Purescript codegen target ES6" is not helpful either.
Some discussions regarding ES6 and Purescript popped up among results but nothing practically useful.
I've found lebab tool translating ES5 to ES6,
but I guess it is not right way to go.
The PureScript compiler creates mostly ES3 code. This is on purpose because Ecma Script is strictly backwards compatible and ES3 code runs in a ES5-, ES2015-, ES2016- (and so on) environment. This means that code created by the PureScript compiler runs even in older browsers.
If you are coming from TypeScript or Babel, you might be used to being able to choose the target. This is because these compilers work with plugins that run after each other. But the PureScript compiler does not have such a feature (since it is not transforming JS to JS like these specific compilers).
So what can be the benefit of targeting a newer version? Code size, performance and features. If you want to use new ES2015 features in your FFI code there is great news: You can make use of these features now in PureScript 0.13. There are also talks about making the compiler target newer JavaScript environments in the future for the benefits mentioned above. If someone would have to support older environments they could still add Babel to their toolchain. But PureScript is a small community project and neither performance nor code size are of a very high priority for the project (and if they were, there would probably be other optimisations that could yield much greater results).
I had programmed in c/c++ some years ago, amongst other languages, before I started to spend a lot of time on web stuff using php. Recently I decided to refresh my knowledge which is minimal in c++ using c++11. So, I went back to Eclipse, a few years old by now?
But obviously, my old version was not very well adaptable to C++11 because, even though I added the compiler directive "-std=c++11" in the appropriate places, the editor still complains, not only about current c++11 stuff, but also now about statements like "using namespace std" which used to be acceptable in the past. But the code compiles and runs just fine, but with a whole bunch of icons in the editor that just confuses any attempt to discover what actual errors exist.
So the c++11 stuff works, but the editor complains about stuff that (1) it did not complain about before and (2) refuses to accept with the more recent C++11 stuff. In fact, the bogus errors are so frequent that I have a devil of a time finding the real ones, a forest for the trees effect.
I have accessed whatever solutions have been offered for making the editor more tolerant, with no success. Any other thoughts out there? I am using Eclipse Juno under Window 7 with the cygwin compiler.
There is a relatively-new lightweight JVM called Avian that can produce executables for iOS targets.
There isn't too much documentation on the website (and not much can be found searching with Google). I was wondering if anybody was aware of a step-by-step tutorial on how to get a basic Scala program running on iOS, using Avian.
Another alternative JVM to iOS compiler is RoboVM. Although it is at an early stage, it looks quite promising, with examples on how to compile Scala for iOS.
EDIT This was an old answer, valid at that time, but, as #JamesMoore points out, RoboVM is no more. What looks very promising now, and may well be the way to run Scala code in iOS in the near future is Scala Native
Compiled Scala sources are completely standard class files. You should be able to follow the instructions (look for “Embedding”) on the website without large changes, just treat scala-library.jar as a dependency of your code.
I managed to bootstrap the complete compiler and the standard library running on Avian a few days ago.
Some parts might still be a bit rough around the edges, e. g. there is one mandatory fix which will be part of the next release of Scala (2.10.1) but is not in 2.10.0. If you want to play with it right now, you need to use a nightly build until 2.10.1 is released.
If you encounter any additional issues, please report them!
I may not need it anymore, now that Oracle is making JavaFX open-source on iOS and Android!
EDIT: Oracle updated the article to announce that they will not release a JVM, so it looks like JavaFX+Avian may be the way to go.
Running Java byte code on iOS (not-rooted) is not only running that or those JVM. As far as I understand iOS memory management doesn't allow executable memory pages to be writable in user mode. That basically prohibits any JIT compilation.
So even if it's possible to run some compiled (either from Java or Scala) classes on specific Java VM I would carefully check how this VM supports Ahead-Of-Time compilation in order to be runnable on iOS.
As I have seen Avian AOT works well on a desktop. For iOS you will have to check it yourself, although the project looks promising in AOT area.
Glade helped me get started on a project quickly, but I've found it harder to maintain in the long run, and I'm thinking about switching it all to native code. In what circumstances would you choose glade, and when would you use native code?
I would personally only use native code for performance reasons. I find it much easier to work with gtkbuilder. Have you used glade or gtkbuilder? With Glade 3, gtkbuilder format is easy to use and easy to layout and design. Also, gtkbuilder is easier to load widgets from than glade was.
if by native code you mean "direct GTK calls to build ui", then i'd switch to it for several reasons:
if widgets are built dynamically depending on user preferences, etc
if i use a lot of custom widgets, esp. contained within each other (for example GDL docking panels)
to maintain backwards compatibility with older version of GTK
upd: also i'm still using glade2.x which has code generation (patched it to compile against latest gtk2). it really helps to get quickstart on "gui build from code", and works with both ancient and newer GTK versions. though i'm afraid i will have some troubles porting to gtk3 :)
and i never choose gtkbuilder over other alternatives, 'cause it is not available in (still widespread) older GTK versions.. dunno if i'll ever switch to it.. maybe when gtk3 comes out.