I would like to extend some existing applications' drag and drop behavior, and I'm wondering if there is any way to hack on drag and drop support or changes to drag and drop behavior by monitoring the app's message loop and injecting my own messages.
It would also work to monitor for when a paste operation is executed, basically to create a custom behavior when a control only supports pasting text and an image is pasted.
I'm thinking Detours might be my best bet, but one problem is that I would have to write custom code for each app I wanted to extend. If only Windows was designed with extensibility in mind!
On another note, is there any OS that supports extensibility of this nature?
If you're willing to do in-memory diddling while the application is loaded, you could probably finagle that.
But if you're looking for an easy way to just inject code you want into another window's message pump, you're not going to find it. The skills required to accomplish something like this are formidable (unless someone has wrapped all of this up in an application/library that I'm unaware of, but I doubt it). It's like clipboard hooking, writ-large: it's frowned upon, there are tons of gotchas, and you're extremely likely to introduce significant instability into your system if you don't really know what you're doing.
Well, think of this from the point of view of the app designer. If you wrote an application, do you want users to be able to inject things into your application (more importantly, would you want to incur the support/revenue headache of clueless users doing this and then blaming you)? Each application's drag and drop infrastructure is written specifically for the application, not to allow you to drop anything you want onto it (potentially causing crashes and all sorts of other nasty behaviour when you drag something onto an app that simply can't handle it). Stuff like this is hard to do for a reason.
It is possible to do, but it's a lot of work: you need to acquire the window handle of the thing you want to drop something onto, and then replace that window's message handler with your own. That's fraught with danger, of course, since you either have to replicate all of the existing functionality of that window yourself, or risk the app not working correctly.
Hm thats really too bad. I suppose there are sometimes reasons why apps don't exist yet. Basically what I'm trying to do is simplify the process of sending image links to people using various apps (mainly web browser text forms, but also anytime I'm editing in a terminal window) by hooking the process of pasting an image in a text context, uploading the image in the background, and pasting a url to where the image was uploaded all with a single action.
Edit: I suppose the easier solution to this is to just create a new keyboard combo that is hooked by my app before it gets to any other app. There's no reason in particular that I need to tie it to copy/paste functionality.
Related
Well, the title almost says it all : Why should I not move a GUI (e.g. Gtk) window on screen from the code ? In Gtk 3 there was an API for moving windows on screen, but it was removed in Gtk 4, because it is not good to move a window from code; only the user should do so (don't ask me to provide sources for that, I read it somewhere but have forgotten where and cannot find it). But I cannot think of any reason why it shouldn't be good, but of several reasons why it could be good, for example to restore the position of a window between application restarts. Could you please shed some light on this ?
The major reason why is that it can't possibly work cross-platform, so it is broken API by definition. That’s also why it was removed in GTK4. For example: this is impossible to implement when running on top of a Wayland session, since the protocol doesn't allow getting/setting global coordinates. If you still want to have something similar working, you'll have to call the specific platform API (for example, X11) for those platforms that you want to support.
On the reason why it’s not supported by some display protocols: it’s bad for UX and security. In terms of UX: some compositors can have special behavior because they need to work on a small device, or because they have a kiosk mode in which everything should always run fullscreen, or they provide a tiling experience. Applications positioning their windows themselves then tend to give unexpected behaviour. In terms of security: if you allow this, it’s technically possible for an application to reposition and resize itself so that it covers your screens while making itself transparent, without it being noticeable, which means it has the possibility of scraping all input.
I'm looking for a way to embed another application into my own view.
The business reason is that the company has many small Electron apps (basically a small portable web program with a self-contained browser) that the company wants to embed inside an OS X program. These Electron apps would ideally integrate and display inside a subview seamlessly, so they look like little web frames inside our larger program.
I think programatically it would be easiest to open another program as a subview, but I'll take whatever I can get. Maybe even capturing it's NSWindow somehow. (Electron source is available so it is easily discoverable.) Maybe a way to dock the other program inside mine, or (getting more desperate) finding its view and sending commands to constrain it's size and location on top of mine.
So far all I've found says it is not really possible. I've found I can take the more desperate course. I can launch a process, find its view, and position it inside a spot on my display; when the window is moved or the content is scrolled send messages to move the other window. But that isn't really integrated, the menu stays separate, etc., but I cannot incorporate it.
Any ideas or helpful implementation details?
EDIT 1: Thanks for those responses. How about if we could have the electron apps expose their NSWindow somehow? Could that be leveraged? I'm thinking the application could send messages and (somehow, not sure exactly) to set the parent window inside this one. In Windows API it is much easier since you can call SetParent on anything, even items inside different processes. But Cocoa seems more difficult.
This isn't really a thing you can do in Mac OS X. Applications are not "composable" in the way you're hoping for - while it is possible to share a view with a subprocess under certain very specific circumstances (e.g, Safari or Chrome tab renderers), this requires the subapplication to be written in a very specific way to permit that. It's not something that would be feasible in the situation you're describing.
If you have access to the source of these Electron apps, consider combining them into a single overarching Electron application. Alternatively, if it's not possible for these applications to coexist within a single Electron app, you may want to consider using something like Chromium Embedded Framework to build your wrapper application; note, however, that this may require you to implement parts of the Electron framework yourself.
You cannot do that. Cocoa requires you to have only one NSApplication instance per UI app. So you will to fork/exec out new process and launch your applications.
If you can recompile the source code then you can create custom subclass of NSApplication and use that custom class in all the applications or you can create NSthread of other applications without NSApplication instance and go from there.
For a while now I've disliked the default folder browser dialog in Windows:
Granted, at least it has the text box with autocomplete; but if you go strictly with the tree view, it can take a lot of clicks and scrolling to get where you want!
It'd be nice if I could develop a superior (to my taste) UI and have this override my system's default. That is, whenever an application requests a native folder browser from Windows on my system, I'd like to be able to define my own such control so that it will be displayed instead of the built-in one. Naturally I could/would then also offer this to others to install on their systems if they like.
Does Windows provide an API to override this particular feature? Maybe via a shell extension or something like that? (I've never done anything that interacts directly with the OS like that; so I don't even know where to start looking.)
Basically I am asking if this OS-level functionality is configurable within Windows.
An app called FlashFolder seems to have done that, and has a lot of good reviews (meaning it at least works for someone) but doesn't work for me at all on Windows 8. If you have an earlier version of Windows perhaps you'll have more luck.
I want to create a system wide minimize-in-place feature that occurs when double-clicking the title bar of any visible window in layer 0.
It seems that this would be a really simple feature to re-implement... When a title-bar is double-clicked, just draw the title bar only. That's it. The problem is implimenting it in all applications. I think it requires writting a custom framework to override the behavior in AppKit? Maybe NSApplication, NSWindow or NSView?
How can I recreate minimize-in-place?
Is a framework my only choice? If I create a framework, can I replace the behavior of minimize in 3rd party apps?
Which framework do I need to override in order to intercept and recreate the default behavior of the minimize button?
More about minimize-in-place:
I am familiar with WindowShade by Unsanity, this is exactly what I want to create. Supposedly unsanity is working on a Lion version, but their track record is bismal. Minimize-in-place was a system feature way back in the days of OS 7 or 8. I have tried other utilities that try to replace this feature, and there aren't any that do minimize-in-place at a core system level like it needs to be done. Please don't offer utitlity suggestions, I am going to build my own.
I have built an Application that recreates minimize-in-place, but it's not good enough.
My Application semi-successfully recreates minimize-in-place by putting "placeholder" windows (belonging to my app) in place of the 3rd party windows when they get minimized to dock. When my window (title bar only) gets double-clicked, I close my window and restore the real window from the dock.
My custom app works perfectly, but there is a lot of application switching going on. I have optimized the switching between apps to be nearly seamless, but the fact remains that there is application switching going on every time a window title bar is double-clicked. The result of application switching is that menu bars switch back and forth, pallets of 3rd party apps hide themselves when my app takes focus, and the list goes on.
So, although I've built a concept app, this method isn't going to work as I'd like it to. Minimize-in-place needs to be implemented using some other method than building an Application, and I need help understanding how to do it.
What I know think I need to do. Suggestions and assistance welcome.
I think I need to write a custom framework that replaces AppKit? This seems overwhelming even though I only need a super-tiny portion of the code to be overridden? i.e. the core _minimize function whatever that may be.
When a title-bar of 3rd party window is double-clicked, just clip to the title bar and let the rest of the system function as normal. On un-minimize (double click 2nd time), set clip back to full window.
Simple right?
Thanks for any assistance/suggestions,
Chris
which of the following styles do you prefer?
An application which to perform tasks opens new forms
An application which keeps the various "forms" in different tabs
An application which is based on a PageControl and shows you the right tab depending on what you want to do.
Something else
Also do you have any good links for gui design?
From a programmers point of view, the PageControl solution quickly gets out of hand. Possibly too much code and certainly to many components on one form. (Originally this question was tagged Delphi, so I go from there.)
From a users point of view, the "opens new window" paradigm often is confusing. We people tend to think that we are able to multitask and handle many open windows and tasks, but we are not (we task switch at a loss of time like computers and add loss of accuracy).
Obviously this really depends on the type of application. But I would tend to a paradigm as Chrome and Firefox show in their latest incarnations:
keep the various forms in different tabs
let the user detach a tab into its own form (dock and undock via drag%drop)
add a good way of navigation
I implement something like an SDI as main screen of an application too. Look at something like "outlook style". Navigation, list of objects, object details in different panes, some additional panes like a cockpit. And then open a new window/form for certain tasks (some modal, some non modal), but short lived. After the email is written, it is sent and closes the window. But I have, if I am capable of doing so, the possibility to work on multiple emails at the time.
Look at the problem. If it has dashboard character, take "outlook style" or so. If the users are a wide spread, heterogeneous, non computer savvy crowd, use SDI or forms on tabs. If you write for programmers, you might go for multiple forms, just because we tend to think that we can handle it. And it works for multiple screens (hopefully).
MDI is the worst choice possible, in my opinion. There's nothing I hate more than having to resize a bunch of windows, or tile them or whatever.
Tabs are bad, too, especially if you have more than one row of them (or if you have one row but still have more tabs than will fit, and have to use some funky scrollbar or "more" button with them).
I would rather see the programmer think about the problem and just show me what I need to see based on what I'm doing as a user. Implementing the different user interfaces in your programs as user controls (as opposed to discrete forms) and then showing them or hiding them based on the current context is the way to go.
The Tabbed form is a good idea if you use a frame for each tab content. This keeps you out of trouble from getting too much code in one single form unit. Try to do the same as Google Chrome. I personally create a menu with the options that are actually frames that loads only when the user asks for it, so there will never be many tabs visible unless the user needs them all opened.