Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Simplified browser configuration for MacOS X #421

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
Contributor

khinsen commented Sep 2, 2013

Add an optional #:browser argument to send-url/mac and export it.

This makes it straightforward to use different browsers and/or to
configure a different one:

(require net/sendurl)
(external-browser (lambda (url) (send-url/mac url #:browser "Conkeror")))
@khinsen khinsen Simplified browser configuration for MacOS X
Add an optional #:browser argument to send-url/mac and export it.

This makes it straightforward to use different browsers and/or to
configure a different one:

    (require net/sendurl)
    (external-browser (lambda (url) (send-url/mac url #:browser "Conkeror")))
e97d115
Owner

samth commented Sep 3, 2013

@elibarzilay are you still the person to review this?

Owner

elibarzilay commented Oct 16, 2013

Kind of. It seems to me like a bad idea to add this, since send-url/mac is supposed to be an internal helper that gets invoked when we're on a mac, so it's not really intended to be exposed. And when it is exposed, there's another issue of this being a completely different mechanism than what happens on Unix. More than that, using the keyword is a thin wrapper around a run of osascript anyway.

If this is really needed, then I think that a much better solution would be to somehow unify this with the unix thing, but I think that it's best to avoid it if possible, since the idea on mac/windows is that the OS is left with the decision of what browser to run.

Contributor

khinsen commented Oct 16, 2013

Whether browser selection is needed depends on everyone's personal needs. I can't live with a single browser on the Mac because there is none that handles all sites correctly and conveniently. I think many Mac power users share this point of view, though others are perfectly happy with a single browser.

Unifying the Mac and Unix approaches is fine with me, though it would probably look alien to most Mac users. I'd say that my send-url/mac is as close in spirit to osascript as is possible, but that's of course a matter of taste.

Owner

samth commented Mar 11, 2015

@elibarzilay @khinsen What should happen to this PR?

Owner

elibarzilay commented Jun 8, 2015

I don't think that I'm right for dealing with this: I wrote what I think about it above -- mainly, that the the /mac version is supposed to be internal (it is made public in this commit without documentation, BTW) and if there's any real need for this then it would be much better to extend the unix facility instead of adding more specific configuration to something that is already a pile of messy configurations.

(FWIW, and without any real OSX experience, unifying with the unix thing could also make sense in making it easy to deal with unix-y browsers that people might use on a Mac, if there are any.)

Owner

rfindler commented Jun 8, 2015

I don't mind exposing it as the arguments for exposing seem reasonable. But
not without documentation! And it also seems good to check that we are on
Mac OS X and perhaps other checks that are appropriTe now that the function
is directly callable.

Robby

On Monday, June 8, 2015, Eli Barzilay <notifications@github.com
javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

I don't think that I'm right for dealing with this: I wrote what I think
about it above -- mainly, that the the /mac version is supposed to be
internal (it is made public in this commit without documentation, BTW) and
if there's any real need for this then it would be much better to extend
the unix facility instead of adding more specific configuration to
something that is already a pile of messy configurations.

(FWIW, and without any real OSX experience, unifying with the unix thing
could also make sense in making it easy to deal with unix-y browsers that
people might use on a Mac, if there are any.)


Reply to this email directly or view it on GitHub
plt#421 (comment).

Contributor

khinsen commented Jun 10, 2015

@elibarzilay: In today's computing world, I don't think "Unix" is a good platform category any more. MacOS and Android are technically members of the Unix family, but both add a user interface layer that has nothing in common with the X11-based approach of traditional Unices.

MacOS distinguishes between systems-level processes and user-level applications. The first are handled like in other Unices, the second are something different. MacOS browsers live in the high-level layer. I am not sure that browser handling in MacOS and traditional Unices can be unified into something that makes sense from a user's point of view. It's probably more reasonable to unify the Mac and Windows ways of addressing browsers.

@rfindler: All very valid points of course!

Owner

elibarzilay commented Jun 10, 2015

Re "unix", the point there is that the unix version of send-url uses a command-line configuration. Even with the mac thing that you're talking about, the bottom line is that it does use a command-line to start the browser. This has nothing to do with X, and therefore the point still stands.

Detailed explanation follows, most likely repeating stuff I previously wrote. The actual work is likely to be shorter then this text.

I don't see how an exposed send-url/mac can be a good thing. What would it be useful for? On one hand, current clients of the library use send-url and therefore this will have no effect on them. If you do envision adapting existing clients (like DrRacket) to use it, then that means that the decision of "are we on a mac" is pulled out of the library and into the client. It's true that you can do this with setting the external-browser parameter, but that would require the client to have a hook that allows you to initialize it (in the DrR case, that would probably be done by some tool). If the tool is installed/loaded automatically, then it's the problem of the decididing code being duplicated in several places, and if it's left for the user to install then it's a worse place for doing the decision. On the other hand, new client code would often suffer from the same problem: for example, any application that uses send-url will need some "startup configuration file" feature so people can set the parameter before the application runs.

(As a side note, I'm half-guessing that the existence of the external-browser parameter is what made you go down this path -- but it's not a good way to configure the browser since it receives an arbitrary function. For example, you generally want a configuration that can be saved in the preference file, which you can't with a random function. IIRC, the reason for that parameter was from the days of using the racket browser ("scheme" browser, since it came from prehistoric times), where the documentation pages were shown with it, but other pages would invoke a proper browser.)

Worse, you'd probably want some preference to set the browser application name -- and that would need to be done in each client too. But that would be too insane; the right way would be to further add functionality in the library to set this preference. The thing is that this adds more complexity, which itself is similar to the complexity that is already there in the /unix version.

IMO (the "M" is important), a proper way to fix this would be:

  • Start with the unix configuration -- it suffers from a hack which is a hard-wired list of executable names, but the configuration itself can be used in any environment that uses a command-line to invoke a browser.
  • Clean it up. I don't remember the details, but at some point I did play with the idea of doing this.

This should result in a generic interface that has several parts:

  • Find the list of available browsers, specific to each OS. I'm guessing that doing this on a mac would be similar to modern linux: dig through some OS list of browsers that can handle urls (on linux, this would use xdg-mime)
  • For each, there should be some user-presentable name, which should be shown in the preferences dialog, and some string to store in the preferences file (maybe a path to some desktop file in linux, and an application name on a mac)
  • Then, the generic send-url would dispatch to the platform version which would consult this value to do its work.
  • Also, make it possible to use the arbitrary command-line "backdoor" on all platforms, possibly extending it (like using different % things for different URL encodings and/or indicating whether things like a trampoline page should be used).

The main thing in all of this is that send-url/mac is kept as an internal private function.

Contributor

khinsen commented Jun 10, 2015

@elibarzilay I think I see your point, and I agree with it in principle. The fundamental question is where the decision about browser configuration happens. For GUI programs such as DrRacket, it should happen as part of the program's preferences, set once by the user and saved in a file. Whatever browser mechanism exists at the level of Racket libraries happens at a lower level, so it's up to the GUI layer on top of it to handle OS dependencies.

What you propose looks like a good approach to provide better library support for configurable GUI applications. I am all for it, but I don't have the competences to design or implement such an API. I wouldn't want to use it either, as I don't write configurable GUI programs.

My proposition to expose send-url/mac aims at a very different use case: writing special-purpose scripts that simply open a given URL in a given browser. I tried to use send-url with external-browser initially, but never got anything to work under MacOS. The mechanism of external-browser doesn't fit MacOS, where applications live in a different namespace than paths to executables.

So my ideal solution would be a generic send-url using a platform-specific browser specification instead of the Unix-centric external-browser. For MacOS, the browser specification should be just a string naming the application.

Owner

elibarzilay commented Jun 20, 2015

[...] For GUI programs such as DrRacket, it should happen as part of the program's preferences, set once by the user and saved in a file.

Right -- in the form of the preference file, which is already done for Unix (being the only platform where there is a need to save a user choice). (And this is only because of the inherent indecisiveness of an open-source platform, where there are OS-wide ways similar to Mac/Windows, but there was no clear winner for a long time. That's why I raised XDG as something that should probably be the default there too.)

My proposition to expose send-url/mac aims at a very different use case: writing special-purpose scripts that simply open a given URL in a given browser.

Did you have any need to actually use it rather than writing your own quick helper that ran the appropriate command-line? I can see some situations where this would be needed -- like using send-url/contents, or .../file, and if that's what you wanted then you really are looking for a proper extension in the library. But if you wanted just to fire off a browser pointing somewhere and you're doing your own private scripts then IMO such a helper is perfectly fine -- you're not in a situation where you need it to work everywhere anyway, which is an important point in the sendurl library.

I tried to use send-url with external-browser initially, but never got anything to work under MacOS. The mechanism of external-browser doesn't fit MacOS, where applications live in a different namespace than paths to executables.

(Yeah, I suspect that external-browser is not a good idea in general.)

So my ideal solution would be a generic send-url using a platform-specific browser specification instead of the Unix-centric external-browser. For MacOS, the browser specification should be just a string naming the application.

I think that you're confusing external-browser as the Unix thing -- it's not. Rather, it's a generic way to say what you want to happen when a browser is launched through a function that you set in a parameter, with the problem of not being able to store it as a preference. The Unix related stuff that I was talking about is just the ability to choose from a list of browsers, each with its own command-line pattern -- you can see that in the send-url/unix function. That's the thing that should be generalized a bit and used on Macs too, and there, it happens that most of these command-line templates are running osascript with the name of the browser (IIUC, at least).

Contributor

khinsen commented Jun 21, 2015

I did start writing my own helper function. That turned out to be much more complicated than I thought, and the Racket documentation about external-browser and friends was not very helpful. So I decided to package my solution as a pull request to make it available to others.

I agree that external-browser is not unix-specific from a design point of view. But the support code available for using it is not of much practical use elsewhere. My pull request is just that: support code to make external-browser easier to use on the Mac.

Owner

elibarzilay commented Jun 22, 2015

I agree that external-browser is not unix-specific from a design point of view. But the support code available for using it is not of much practical use elsewhere. [...]

Yes, and like I said, I think that it's generally not useful at all as a setting, since you can't save a random value put into it, and given that there's no gui-ish way to set it.

Anyway, why was it complicated to write a helper? IOW, why wasn't it just a matter of calling osascript with a different command line? (Which is what your chage did, IIRC--?)

Contributor

khinsen commented Jun 22, 2015

As so often, it's not the solution that's complicated, but the process of getting there. The Racket documentation leads to you external-browser but provides no help for implementing the required function. I found it only by studying the source code of the Racket standard library. Users shouldn't have to dig that deep for solving a simple task.

Owner

elibarzilay commented Jun 22, 2015

[...] The Racket documentation leads to you external-browser but provides no help for implementing the required function. I found it only by studying the source code of the Racket standard library. Users shouldn't have to dig that deep for solving a simple task.

Ah -- you're talking about a documentation bug where the procedure case is not mentioned. That definitely sounds like something that should be fixed. But IMO the fix should mention that and say that it's not really useful to set it to a procedure since it can't be saved as a preference (in addition to not being mirrored in the preferences dialog, which might be applicable for Macs too if its fixed).

Contributor

khinsen commented Jun 22, 2015

It's not only the documentation of external-browser that needs to be improved. It isn't obvious either how "open this URL in that browser" can be implemented in Racket. I doubt many Racketeers know about osascript and how to use it from Racket code.

Owner

rfindler commented Jun 28, 2015

I've added documentation and a contract and pushed this. Thank you.

@rfindler rfindler closed this Jun 28, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment