This video introduced to me the issues with X and it's replacement by the Wayland protocol. The adoption of the Wayland protocol appears to be growing over the years.
My questions:
Is tkinter and tcl/Tk going to comply with the Wayland protocol? If so, when is it expected to happen? Has it happened already? What is the roadmap?
How will tkinter programming change with the use of the Wayland Display protocol?
The undroidwish project appears to have ported Tcl/Tk to Wayland, via SDL2's support for it, in early 2017. undroidwish is a variant of AndroWish, a port of Tcl/Tk to Android. It's mentioned on the tcl.tk wiki (and other places on that wiki).
Although a Wayland port was raised as a possibility for the GSoC 2016, it doesn't appear to have been implemented as part of upstream.
There's nothing I've found to indicate that Tcl/Tk coding is different per se, though X11 calls will be unavailable for a Wayland-based application just as with, say, GTK3.
Related
I am looking to implement firewall/network filtering functionalities for macOS.
I am looking at the most secure way to do this, i.e. trying to make sure no network traffic is missed, and that my filtering cannot easily be by-passed.
After searching around, I can see that Apple has deprecated Network Kernel Extension. They recommend now to use the Network Extension framework.
However, I can see that firewalls for mac, for example Lulu and Little Snitch have moved to using Kernel Extension, and not the Network Extension framework.
Is there a good reason to do so? Do Kernel Extension allow a deeper, more secure filtering?
for example Lulu and Little Snitch have moved to using Kernel Extension
I can't speak for Lulu, but Little Snitch at least was developed long before the "Network Extension" API was introduced, it certainly didn't "move to" the NKE API. According to an article on their own blog it looks like they're actively investigating moving to Network Extensions. I suspect that as long as NKEs work without restrictions on all macOS versions they support, they'll keep using those, in order not to have to ship different back-ends simultaneously. But they probably have some kind of internal prototype using the newer APIs already to make sure they're prepared for when NKE APIs are finally removed from the OS.
If Network Extensions support your use case, you should probably go with them. If they don't, you should file Enhancement Requests with Apple, or you will be out of options when NKEs stop working.
Edit: To deploy NKEs, you will essentially need a kext signing certificate (Developer ID Application + Kext) if you don't already have one. The alternative is forcing your users to disable SIP's kext signing requirement, which is neither sensible nor reasonable in most cases. I hear Apple has made it much harder to obtain such a certificate in recent years.
I'm interested in learning Google's flutter/dart but I want to be able to create desktop x86 apps with it like with react native. Is there built in support or any 3rd party addons that I can use to make drsktop applications with flutter/dart?
I'm having a hard time deciding whether this question is off-topic or not; I won't vote to close it for now but I wouldn't be surprised if someone does (since it veers pretty close to the 'recommend a tool' type of question).
To answer your question though, the answer is sort-of for now. From the flutter FAQ:
Can I use Flutter to build desktop apps? Yes, but right now it’s not
very well supported. We’re working on making this a first class
experience. Our current progress is documented on our wiki.
The wiki is here and at the current time of this answer it has some basic information on how to set up building a flutter app for windows, mac, and linux, along with warnings that everything may change at any point and that any plugin needing native code won't work as they only contain code for iOS/Android. The flutter-desktop-embedding repository (left-over from before google officially started working on desktop embedding) is an example of how to get started but your mileage may vary as I'm not sure how up to date it is.
Basically, you could start developing a flutter app now on desktop now, but I wouldn't expect to be able to publish that app any time soon without a significant amount of work to get everything to line up properly. Also, publishing it might be difficult at least on windows, and on windows the current shell uses GLFW which isn't probably something you'd want to use in a released app if possible. I'm not from google so I can't speak as to their plans but I would guess (and hope) that there will be some sort of announcement at Google I/O about desktop embedding, but no guarantees.
So TLDR; yes for development purposes but no for deployment.
I'm interested is it possible to install and use Android Things(former Brillo) on custom produced hardware?
I can see from the official documentation there is preselected and certified SoMs listed, but I'm interested in using my own hardware.
Is it possible to have best of both worlds - use the familiar to me Android & Android Things but run it on proprietary hardware?
If not, what other options do I have - I researched about micropython, but apparently it seems it also comes with designated board(pyboard).
So my question is what are options to not thinks too much about the firmware on the device(and write C code), but focus on more higher-level business logic and programming languages(Java, Python).
Android Things isn't open source, so you can't put it into that isn't officially supported.
If you're looking for custom options, you will need to find a compiled language like C that works for that board. While C may be a bit intimidating, you may be able to find languages that compile to similar machine code. Rust and Go may work on microcontrollers too if you check.
I'm not too familiar with micro python. It says that it compiles to bare metal/machine code, so I believe you should be able to use it on other boards. While they may officially support the compiler for one board, the community may have support for additional microcontrollers.
Is there any way to implement MQTT protocol on Ingenico's POS devices? I am currently working on iCT220 on which I want to implement IOT project. In this project, I will be sending some bytes (may be 400-1000 bytes) of data to the broker (server).
There are lots of source codes for the library available in the internet, but all make use of Linux or Windows socket libraries, where as Ingenico's devices come with proprietary libraries.
Have anyone implemented similar project on the same devices? Can anyone guide me to the process of implementation?
Thanks in advance,
Pankaj
Surely, you will need to build it from source.
I had a look at several client libraries and it looks that dependencies come mostly from IP stack, so there's very little to be implemented to have it running.
You should expect the proprietary OS issues to be thing of the past in short time - newer terminal lines are based on linux.
Every indication I have, based on my experience in embedded computing is that doing something like this would require expensive equipment to get access to the platform (ICE debuggers, JTAG probes, I2C programmers, etc, etc), but I've always wondered if some ambitious hacker out there has found a way to load native code on a Blackberry device. Anyone?
Edit: I'm aware of the published SDK and it's attendant restrictions. I'm curious if anyone has attempted to get around them, and if so, how far they got.
I've seen this question pop up in a number of different forums over time. The original Blackberries were programmable in C++ but I think that RIM ran up against the problems of trying to implement a secure platform in the C/C++ compile to native paradigm.
The devices do have JTAG ports, but unless one could get hands on the RIM code as a place to start the problem is enormous.
I also have to wonder how useful a Blackberry with a replacement FOSS operating system would be, since it would not likely have the protocols to connect to BES or BIS, send PIN's etc. If one was simply looking for a the power of the hand held computing platform I suspect there are many more likely candidates available.
No, C++ is no longer a supported RIM development tool, as they phased it out a number of years ago. Client applications can be developed in Java (or one of a few 5GL frameworks), and web + sever-side apps can be developed using standard tools.
For those looking for updated information, the new Playbook os, also known as QNX, also known as Blackberry 10 (or it will be when the phones running it come out) is in fact c/c++ based, also using QML and a C++ add on called Cascades.
Unfortunately the official SDK website only seems to mention Java. According to wikipedia, different versions of the BlackBerry use different processors. Combined with the fact that RIM uses a proprietary operating system for the devices, it becomes pretty difficult to develop native code without official tools. There is also a partial API-level security restriction which would further prohibit advanced tinkering.
Just randomly searching for an answer to this and came across http://supportforums.blackberry.com/t5/Tablet-OS-SDK-for-Adobe-AIR/Native-C-C-SDK/td-p/778009 which mentions that BB intend to release a C/C++ SDK soon, more details will be provided at the 2011 Game Developer Conference.