As I said in some questions today I´m looking for the way to get window or windowPart references at a certain location. Although I know I could use Cocoa for this purpose (I don´t know how to do it yet) I prefer (and probably need) to do this using Carbon because the entire application that needs this functionality is written in C++ but I´ve found many problems trying it.
Does anyone get a valid windowPtr or windowRef using one of the following functions? FindWindow, MacFindWindow, HIWindowFindAtLocation or FindWindowOfClass
I always get 0 as the windowRef or windowPtr that I´m looking for. What I´m doing wrong? Any ideas?
It´s true that now if you want to create a 64-bit application for Mac OS X, you need to use Cocoa to implement its user interface because some APIs commonly used by Carbon applications are not available in 64-bit applications?
Thank you.
JxXx
Based on your response to this question it appears that you are trying to get a WindowRef to another application's window.
As this posting to the carbon-dev list says:
You can't access memory in other programs. A WindowRef from another program
would be meaningless in your program's memory space.
And the word on 64-bit carbon is this:
If you want to create a 64-bit
application for Mac OS X, you need to
use Cocoa to implement its user
interface.
EDIT -
You can get the mouse location with [NSEvent mouseLocation] (Cocoa) or GetMouse() (Carbon). If you want to interact with windows belonging to another application, you'll need to use something like the Accessibility API (Cocoa), or the low-level Quartz Window list functions. The Quartz function returns a list of all windows (belonging to all applications) and limited information about each (bounds, owning PID, etc.)
Related
I want to code a primitive, DE independant application. Hence I want to be independant of Qt and GTK. What is the next lower library below Qt/GTK. I mean what is the lowest common denominator that is used by either of them and is available on every graphical linux system.
The X11/Xorg server is used by both Qt, GTK, and pretty much every GUI toolkit out there (FLTK, etc...), so it is the "lowest common denominator" you're talking about. You can use it directly with the XCB or Xlib library.
There is no such common library.
If you are writing a desktop app (i.e something you expect the user to interact with through their usual windowing system) my advice would be to use either QT or GTK - choice is yours.
There are some other reportedly simplier 'lightweight' libraries you can use such as EFL (Enlightenment) and TK (i.e. Old school tcl/tk apps haven't seen one of these for years). Or you could even use something more exotic like Motif (for that cutting edge mid 90's unix workstation CDE look and feel) - I hear that is open source now (finally).
For a full screen app like a game I believe you can use SDL or maybe ever write out directly to Linux's frame buffer device - I can't really offer anything here I have no experience.
There is no gurantee any of these libraries will be available on any given Linux installation. Thankfully package management exists to take care of this for you. Write the app publish the source and the make files. If people find it useful and want it in their distribution someone will package it for you.
If you are making a closed source binary you are left with static linking.
I have a stack which was originally built in Hypercard then migrated to Metacard. Obviously, it has expanded greatly over that time. Some core features broke when I tried to migrate to Runrev which is why I've waited till now to finally do that. I'm keeping it as a stack rather than an exe so I can save changes to it. I've built a standalone player to launch it and that is working. I've included the revmessagebox.rev stack in the Standalone Stack settings. This does add it but, incorrectly. I can put messages to it from my stack but, it won't run commands and it's missing all it's icons. I'm also included the revimagelibrary.rev and revtools.rev stacks in the hopes of fixing this but, no dice. I was also hoping that including revimagelibrary.rev would get my old Metacard icons to display but, no dice. I appreciate any help I can get on this.
Rich
I don't think you can. The message box is part of the IDE and requires the development environment to run. When you build a standalone your scripts etc are compiled and an interpreter for commands is no longer present.
To replicate it in a standalone you could use a simple window with a field to accept text and would require you passing the text entered to a "Do" command. The other functions present with the message box (accessed via the icons you mentioned) are also development tools and don't make much sense in a standalone.
The message box is not only integrated into the IDE, the engine also has hooks that directly support it. I'm not sure those hooks are included with the engine that is built into a standalone, so even if you adapt the existing message box for your standalone it still may not work correctly.
The solution, as others have said, is to build your own stack that functions as a pseudo-message box. It is easy to display messages in your own stack, and pretty easy to execute simple commands using the "do" command. It is somewhat more difficult to execute complex or multi-line commands. But I agree with Dunbarx that I'd assess the need for such a thing if you are planning this standalone for distribution. It's a non-standard interface element.
What James said. But note that though the msg box is indeed integral to the IDE, it is still just a stack, and that stack can be replicated to whatever extent you need.
That said, the msg box is usually used as a development tool, to test short scripts (usually one-liners), to get or set property values quickly, as a simple calculator, that sort of stuff. If you need that sort of functionality, you should probably integrate it more comprehensively into the structure of your project.
Craig Newman
I'm working on a wrapper to compile c++ code having MFC and windows API calls into their linux versions.
The c++ code has the following characteristics:
No GUI component present.
Has a maximum of about 10 MFC classes used mostly for string parsing.
It has lots of windows specific constants used such as HINSTANCE, LPCTSTR and so on.
I'm not allowed to compile using wine in linux. Till now i've come across wxwidgets, it seems quite vast, i doubt if i'll be needing all it's components.
Please share your ideas in creating the wrapper, is there any specific code that is already available which does this task or part of this task ?
There is no automatic or even semi-automatic way to convert an MFC application to wxWidgets. It is, of course, perfectly possible to do it and many, many projects have gone through this transformation but you just need to do it.
See MFC page of wxWiki for some starting points.
There are a few implementations of portable apps in Linux, but it seems that all Mac OS X apps are portable. Since Mac OS X completely embraces this model, I'm assuming they already have a solution to this problem.
Since Windows "installs" apps by putting files all over the place, and changing things in the registry, file associations can be made easily. But, let's say I just downloaded MPlayer for Mac OS X (or whatever). I want all my movies to open in MPlayer. Then, I decide to move MPlayer's app bundle (hey, it's portable, right?). Will the association break? Or is that not how it's done at all on OS X?
How would one implement portable apps in Linux? Should it be similar to OS X's model? I know this is a very open-ended question, but any suggestions are appreciated.
OS X's Launch Services database keeps track of document bindings in several ways—generally it does its best to try to match an application even if you've moved it.
You can run lsregister -dump (lsregister is /System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister) to see what the Launch Services database says about a binding. For example, if I bind text files to open with TextWrangler, I see:
handler id: 3124
content type: public.plain-text
options:
all roles: com.barebones.textwrangler (0x3ea30180)
public.plain-text is a Uniform Type Identifier (which maps to one or more file extensions, MIME types, etc., and may have subtypes) representing plain text, and com.barebones.textwrangler is the bundle ID of TextWrangler.
I'm not aware of any Linux standard as robust as this for document binding—to do something like the Mac, first there'd need to be a standard method for identifying applications regardless of their location or name (like the Java package-like/reverse-DNS method on the Mac), then a registry for type mappings and bindings that was followed by enough desktop environments to be useful, and some way of registering applications as they're installed.
You don't necessarily need separate files, like Info.plist in Mac application bundles, to store this information; even on Mac OS X you can embed information into a binary section which Launch Services indexes just fine (note that this is not a separate "fork" or extended attribute; it's like embedding debug information in an executable). So perhaps some derivative of the .desktop files could be embedded. On the other end, you'd need a way of recognizing content. Ideally you'd even be able to do content sniffing like the file(1) command to identify a document type; classic Mac OS did this with the Translation Manager (which permitted registration of converters from one format to another, as well as sniffers).
UTIs and the Translation Manager handle(d) clipboard and drag & drop content as well as files on disk; unifying these format representations is pretty useful while you're at it.
Each file browser (e.g. Nautilus, Konqueror) would have to be configured to use its own file associations. Fortunately, the Free Desktop project has been working on standardizing file associations (among many other things). According to the shared MIME database description, no formal specification has been written yet, but the format is pretty much standardized.
The Free Desktop project also uses .desktop files to provide "portability" (maybe you should use another word for this... perhaps "movable"?). If you move the executable outside of PATH, you can update the .desktop to point to the correct location.
Basically, there is a lot of ongoing work in the Linux community moving towards more user-friendly and developer-friendly (i.e. standardized) ways of accomplishing these goals. But things are not done yet.
I need to develop a large set of tools to be run from the server command line (i.e. not client-server architecture). The systems does not have to be high-performance; I just want something that is easy to develop with.
Which technologies are out there I can use to build simple GUI to be run from the command line? I need only menus where I can select a line/check-box/enter free text in a dialog.
Edit: forgot to add, access to Mysql (i.e. drivers available) is essential.
Shell, with dialog, the old stand-by - http://www.linuxjournal.com/article/2807
EDIT- If it's MySQL-related, take a look at PERL-Tk and DBI.
python + ncurses would be a good combo here.
i like using perl's re.pl from the Devel::REPL library for quickie cli interfaces. read on a bit for my rationale before downvoting!
in this type of app it sounds like you will be doing query-type operations. these naturally lend themselves to a "repl" style interraction. re.pl gives you all of the goodies, namely command editing and history. all you need to write are the functions that users will call. the nice thing is that users who know perl will realize they can use any installed module to extend the functionality of your system on their own. i my case, i used re.pl to create a mysqlclient-like tool to access and display data that was being compressed in a way that the standard mysqlclient couldn't deal with.
i cite perl because it's DBI is the best database abstraction and it is what i have used....but the rationale can be extended to other tools. python's repl or any other would provide the same benefit.
You could use Mono for Linux and write your program in C# .NET, then make it work for Linux, since Mono allows so.
As far as graphic command line interfaces go, one of the best frameworks is ncurses. It abstracts away most of the ugliness associated with graphic command line applications.
I have to say, use Python, because I like it.
But text-based interfaces are pretty much not worth it, because they seem like a good idea until you look at the details:
There isn't really a standard keyboard navigation model for text-UIs; they all use their own scheme
How is unicode supported? (Hint: this is nontrivial)
What about different keyboard layouts? What key does someone press if their keyboard doesn't have, say, a "home", "end", or "Escape" ?
ncurses does not provide a widget set, only low-level operations. The answers to the above questions aren't easy.
It really shows that nobody has put much thought into keyboard-and-text-driven terminal-based UIs recently, or these would all have been solved.
Web interfaces have them solved, in fact, you can use a text-mode web browser if you like.
Modern devices like i(phone|pad)s and even cheap mobile phones have a web browser which is good enough.
It is easy to write a web application which uses a very simple style (few images, little Javascrfipt) and have it work without much effort on a variety of devices.
So I would say go with dmckee's comment "go with what you know".
By building your own terminal-based interface, you are going to box yourself into a corner in the long term.