So, I understand the concept of TideKit (and TideSDK) of packaging a database, and native functionality (such as file system manipulation) through the TI interface into what otherwise would be a (potentially offline) web-app.
I'm confused as to how deep or powerful server side scripting integration goes with the desktop app?
To the point for a potential use case of mine: could I package complex server-side scripting tasks like video compression/encoding/manipulation into my HTML app, so that when that is packaged as a desktop app, the client's desktopp app is capable of running those tasks itself via the packaged executable, without needing any extra software on the client side (python / node / whatever server side scripting language) ?
Related
In Windows, developers are able to write a program, letting it automate lots of applications (such as Photoshop, Office Word) which are not in the same process as the program itself, provided those applications support OLE.
Since many of those well-known applications that support OLE automation in Windows also come with MacOS version. I wonder if there's a similar technique that can let developers write programs that can automate other applications which are not in the same process as the program itself.
I am developing a cross platform application (OS X, Linux, Windows) in C++11 that should provide a custom debug shell as an external application.
This debug shell is used to invoke methods that are exposed by the public interface of the application. Mainly it should allow to perform the same operations that are available from the app GUI.
Debug shell and application will run on the same machine (remote access would be a plus, so it is not necessary).
I was wondering which approach I could use to assure portability (different OS), performance and code reuse (I would like to share the same model for GUI and debug shell).
My first idea was to use gRPC and Google Protocol Buffer to access to the application interface from both GUI and debug shell, but I am afraid that such solution would add performance and design overhead.
Do you have any design and technical suggestion about?
gRPC should be fine for this use.
On Mac and Linux you could make use of unix domain sockets to do this.
Since you want to be portable to Windows too, you'd be better off binding to localhost, as is done in the helloworld examples in the github repository: https://github.com/grpc/grpc/tree/master/examples/cpp/helloworld.
gRPC uses very little CPU while nothing is happening, and the serialization and network overhead in making a request will be well within interactive usage latencies (expect 100's of microseconds at worst).
So far I have only been developing desktop applications using C++ or C#.
Now I am considering building a local standalone application using a browser GUI. The application would be similar to something I could e.g. build with C#. It should have local database access and offer some limited image editing (line drawing, polygon filling) and user defined, clickable graphical elements (basically polygons the user draws).
The application should not be web or server based. The application will also not be very complex.
The main thought behind this is to have the GUI be OS independent and as platform independent as possible.
Is that feasible? Or should I go about something as Swing, SWT or Java FX (which I have just read about)?
What programming language should I use for the application (Java, Python, ...)?
Are there toolkits for a programming language you recommend that offer an abstraction layer from OS specific stuff like file system handling?
Are there toolkits or tools that would help me in creating the browser GUI?
Well you can use c++ for this :) and for your GUI use OpenGL, and then you can use glut... You can take a look at OpenGL superbible book, it mostly about 3D drawing, but there is also something about gui... and it comes with examples for linux, windows, mac... basicly it is OS independent...
I know that cross platform GUIs can be built in Ruby using various tools like shoes and FxRuby, but do these types of tools have platform specific access to the level that I need?
My app is mostly web based, but needs a thin client that is basically just for desktop configuration settings. So I'm only going to have it exist as a menu, and then a few simple tools like folder selection boxes, and when the thin client is launched it will only exist in the tray on windows or in the status item section for a Mac.
Just looking through what is out there, I can't tell if something like this can be coded in a cross platform way or if it is too platform specific.
Using Swing through JRuby might be your best bet. Whether you're ok distributing JARs that allow easy access to your source code is another matter. The MonkeyBars gem sought to simplify the use of Swing in JRuby but I don't think it's seen much development recently. At any rate it's fairly trivial to wrap most of the Swing classes without piling syntactic sugar on top.
MacRuby can't be rivalled for its integration with Cocoa and other OS X frameworks, but you'd then be tied to macs.
I hope this isn't a stupid question:
I wonder if there’s a way to build a web client and a windows desktop client (that looks the same and offer the same features) with the same code (not just same language), at least till a certain point - in other words, having an abstract code that will fit the web server and windows?
Thanks!
You should take a look at Adobe's FLEX, you can have same classes/layout for both web apps (run under Flash) and desktop app (run under AIR). The only difference will be in the main file, you will have one for each flash and air app. (The rest of code will can be compiled into one SWF, also have in mind that you should use same functionalities for both web and desktop )
I believe Java can do what you want, with minor modifications to have it run as a full-blown desktop application vs a Java applet.
One thing you'll need to do, is ensure that for the app, your main function is very small (ie, only call the main JFrame or whatever), and replicate that simple call in the applet code.
For the differences between the two, see for example, here and here. You'll need exactly one tiny source file that's different for the applet vs application.
Real Studio will also let you do this to some extent. Newer versions can create web applications and desktop applications. Non-UI code can be shared with web and desktop apps. The UI code will have to be different, though.