Creating a minimalistic MSHTML-based window - winapi

I have a library for Haskell that can take an ordinary web application, run it on a local server, and then open up a window displaying that application using QtWebkit. The code to interface with Qt is very short. However, I would like to avoid the Qt overhead for Windows users.
It seems like the best approach would be to have an alternative to this QtWebkit-based C++ file that instead uses the MSHTML library on Windows. Unfortunately, I have almost no experience with Windows-specific libraries. It seems like I need to use the IWebBrowser2 interface, but that seems mostly speculative.
If someone can point me in the right direction on this, I would be much obliged. The final trick here is that it has to compile with MinGW. Not sure how much of a complication that is in this case.
Thanks

You can use hdirect to call the IWebBrowser2 interface from Haskell. It's messy to code against OLE/COM but it can do the job. Making a C binding to the interface is possible but if you need MinGW then it may actually be harder than a purely Haskell approach.

Related

Is there a way to create a GUI in Lua?

I am working on a Genetic Algorithm solution to TSP in Lua, and have reached a point where I need a better method of troubleshooting and checking results. The best way to do this would be with a GUI, but I can't seem to find anything about GUIs in Lua.
I've done some searching around Google, and haven't found anything built in to the language. I have found Toolkits such as the one found here:
http://lua-users.org/wiki/GraphicalUserInterfaceToolkits
However, I am new enough to Lua that I do not know how to properly use these. Any help on the matter would be greatly appreciated.
A few ideas:
But first, what platform are you on?
Are you constrained by platform? If not, I've done very exciting things directly on an iPad, in Codea. Pure Lua, built on OpenGL, so built-in API for graphics support.
Beyond that, you could probably use Love2d. It's meant for game dev, but you could probably adapt it to your needs. It's a Lua API, has graphics support, and is cross-platform. I don't know much about it (yet), so others could pipe in with their thoughts/opinions.
If you are still shaky in Lua, I suggest to stick to the console for a while. GUI, whatever the language, is usually messy and unsatisfying for beginners.
If you already know some HTML and Javascript, consider using Lua with a web framework, and using the browser to control your program through a REST API:
Awesome-Lua#Web/Networking Platforms
Apart from that, I have yet to find a GUI framework that feels right for Lua. Almost everything is a thin wrapper around a C or C++ API and handles exactly like that. On the other hand, with the web and Electron on the rise there seems little need for it.

Using windows.pas with Lazarus on OS X

I was wondering if it's possible somehow to use windows.pas on OS X with Lazarus?
I need to use special library in my project, and one of key-files uses windows.pas :( Any ideas?
Windows.pas only works on Windows. You will have to edit the library to put an IFDEF around it in the uses clause, and then provide alternatives for any functionality that is then broken. Or contact the library author and see if there is already a non-Windows version available.
You certainly cannot use Windows.pas under OSX. Because Windows.pas exposes the functionality of the Win32 library.
If you need to execute Win32 code on OSX pretty much your only option is Wine.
A more plausible solution is that you find an alternative to this "special" library to which you refer.
Windows.pas is mostly a wrapper around different DLLs contained in the Windows operating system. As it is unlikely that you will find those DLLs in OSX I guess you are out of luck.
You could check the library's source code and try to identify the constants, procedures and functions that are used in windows.pas. If it is not too much code you could try to modify the library so that it uses corresponding Carbon functions instead.
While the various answers are correct, and the vast bulk of unit windows is not portable, some functionality IS abstracted. Structures like interlockedincrement, Rect and ColorRef, and some message related functionality. Have a look at types and lcltype and the system unit interface of FPC.
A lot of Delphi code still uses Windows for that functionality, while e.g. unit types already exists since D6.
Some other things are abstracted, but not using the same (windows unit) calls. Better explain what exactly you need in a separate post.

Creating GUI desktop applications that call into either OCaml or Haskell -- Is it a fool's errand?

In both Haskell and OCaml, it's possible to call into the language from C programs. How feasible would it be to create Native applications for either Windows, Mac, or Linux which made extensive use of this technique?
(I know that there are GUI libraries like wxHaskell, but suppose one wanted to just have a portion of your application logic in the foreign language.)
Or is this a terrible idea?
Well, the main risk is that while facilities exist, they're not well tested -- not a lot of apps do this. You shouldn't have much trouble calling Haskell from C, looks pretty easy:
http://www.haskell.org/haskellwiki/Calling_Haskell_from_C
I'd say if there is some compelling reason to use C for the front end (e.g. you have a legacy app) and you really need a Haskell library, or want to use Haskell for some other reason, then, yes, go for it. The main risk is just that not a lot of people do this, so less documentation and examples than for calling the other way.
You can embed OCaml in C as well (see the manual), although this is not as commonly done as extending OCaml with C.
I believe that the best approach, even if both GUI and logic are written in the same language, is to run two processes which communicates via a human-readable, text-based protocol (a DSL of some sort). This architecture applies to your case as well.
Advantages are obvious: GUI is detachable and replaceable, automated tests are easier, logging and debugging are much easier.
I make extensive use of this by compiling haskell shared libs that are called outside Haskell.
usually the tasks involved would be to
create the proper foreign export declarations
create Storable instances for any datatypes you need to marshal
create the C structures (or structures in the language you're using) to read this information
since I don't want to manually initialize the haskell RTS, i add initiallisation/termination code to the lib itself. (dllmain in windows __attribute__ ((constructor)) on unix)
since I no longer need any of them, I create a .def file to hide all the closure and rts functions from being in the export table (windows)
use GHC to compile everything together
These tasks are rather robotic and structured, to a point you could write something to automate them. Infact what I use myself to do this is a tool I created which does dependency tracing on functions you marked to be exported, and it'll wrap them up and compile the shared lib for you along with giving you the declarations in C/C++.
(unfortunately, this tool is not yet on hackage, because there is something I still need to fix and test alot more before I'm comfortable doing so)
Tool is available here http://hackage.haskell.org/package/Hs2lib-0.4.8
Or is this a terrible idea?
It's not a terrible idea at all. But as Don Stewart notes, it's probably a less-trodden path. You could certainly launch your program as Haskell or OCaml, then have it do a foreign-function call right out of the starting gate—and I recommend you structure your code that way—but it doesn't change the fact that many more people call from Haskell into C than from C into Haskell. Likewise for OCaml.

Programming language for GUI compilable to native binary

I need to write an app that reads a config file with info on the menu bars it needs to create.
Normally, I'd just use java, but I need the application to have the least run-time dependencies possible, this includes not forcing the user to download anything, even JRE, let alone something like NET Framework.
So I need something that can compile to an EXE (windows only for now), and that will allow me to CODE the GUI, so I can dynamically create it from my config.
BTW: something like C++ is a bit too low level, all I need is to create menus, and display HTMLs in a panel.
How about wxPython together with py2exe?
There is a nice tutorial on how to do it here.
If Java's too high-level and C++ too low-level, there ins't much in-between. Maybe Delphi?
I wouldn't totally write off using Java and/or Python for a few reasons.
1) py2exe can compile your Python code to an exe.
2) GCJ can compile your Java code to an exe.
Delphi is best chose for you. Because Delphi compile source code into native x86.
Unless you have serious reasons to avoid interpreted languages, I would suggest you better look into ways of packaging or compiling interpreted scripts because doing this will likely reduce your learning and development time.
I would write a simple GUI in Tcl/Tk, and then package it as a Starpack.
ActiveState provides a distribution (ActiveTCL) and a decent editor (Komodo Edit), and it is fairly easy to get simple GUIs going with Tk. Check out TkDocs for some hand holding.
Once you're done, you can package your code, a Tcl runtime, a database, and a virtual filesystem, all into a single executable that you can easily distribute.
Earwicker is right. You can use HTA:
http://www.interclasse.com/scripts/htanotepad.php
But if you know C++, then creating this type of an application is actually very easy with Visual C++. Use MFC, and statically link everything. You can draw the menu in the resource editor, and attach events to the menu items. I wouldn't use HTML if I were you. Just use regular Windows controls. But if you're really set on using HTML, you can embed a Browser control in the formview.
Have you considered D ? It has a syntax that is like a mixture of Java, C++ and Python with the ability to make native windows apps. The tutorials on dprogramming.com are great to get up and going with the language. For quick GUIs you'd be interested in The D Forms Library and the Entice Designer.
Here are some short video tutorials to get up and running with Entice.
Alternatively, have you tried Qt & Qt Creator? It takes a lot of the hair pulling out of C++ Programming and it's also cross-platform.
You say:
all I need is to create menus, and
display HTMLs in a panel.
A lot like a Web browser, then. If it's going to run on Windows, then the user has IE. Why not use IE to do all the work for you?
You can make something a lot like an .exe with IE, called an .hta:
http://msdn.microsoft.com/en-us/library/ms536496(VS.85).aspx

Common Lisp GUI Programming With System Calls

Can anyone tell me about using (Steel Bank) Common Lisp for writing GUIs via system calls? I know there are some libraries out there but this is a language learning exercise, so I want to do it myself.
I'm developing on Kubuntu 8.10 and SBCL 1.0.18.
Thanks.
You can take a closer look at the sb-posix-package. But as the page sais "The functionality contained in the package SB-UNIX is for SBCL internal use only; its contents are likely to change from version to version."
Another Possibility - the one I would choose - is to include the C-syscall(2)-Instruction via CFFI, and then perform it.
To create a windowed GUI, you must use X11, at least to give you a Window to paint on. Therefore, you must know the X11-Specifications to create a window, and implement the Syscalls for accessing Unix Domain Sockets, or initiating shm-devices etc.
If you just want graphics on a console, you could think of using the framebuffer-device /dev/fb*. You need ioctl(2)'s and the syscalls for read(2)ing and write(2)ing to use it, but still, I think this would be a lot easier than using X11 for this (even though still a lot of work). Maybe you shoudld look at the sourcecode for libFB or something similar to see how to initialize it, etc.
Is this really what you want to do? This is a lot of work, you will learn a lot, but more about the linux system infrastructure, rather than about SBCL, I think. If you want to use Syscalls under SBCL, maybe its better to try to open TCP-Sockets only with Linux-Syscalls - alone this can take hours of frustration.
By writing GUI via system calls you mean not using any GUI toolkit such as Gtk+ or Qt? In such case, you should talk directly to the X-server via socket and implement all the X11 protocol (or use CLX) and GUI on top of it. But that is not an easisest task, because X11 is complex.
In case you decide to dig into X11, there are some links for specifications: http://www.xfree86.org/current/specindex.html
http://www.freedesktop.org/wiki/Specifications?action=show&redirect=Standards

Resources