setting favicons

62 views
Skip to first unread message

Evan Czaplicki

unread,
Jan 15, 2014, 7:05:26 AM1/15/14
to elm-d...@googlegroups.com
I just added experimental support for this in the dev branch. It'd look like this:

port favicon : String

It does not work in all browsers though! That's probably sufficient reason to take it out, but I'm hoping this can be solved. Please let me know if you know a good technique!

More fun example:


port favicon : Signal String
port favicon = lift (\n -> if n `mod` 2 == 0 then wiki else mdn) (count <| every second)

It'd be cool to allow Elements through (possible because DOM nodes can be rendered to canvas which can be turned into data URLs) but this requires much more thinking about what is a valid export value :)

John Mayer

unread,
Jan 15, 2014, 9:56:44 AM1/15/14
to elm-d...@googlegroups.com

Very neat!

Could this work in background tabs? Would be great for a notification feature of multi-browser-tab apps.

What other ports do you have in mind? Maybe we can change main to 'port display'?

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Evan Czaplicki

unread,
Jan 15, 2014, 10:31:27 AM1/15/14
to elm-d...@googlegroups.com
Looks like it does :) The cycling example between the wikipedia and MDN favicon keeps going if you switch away from the tab in Chrome.

I want to have an audio port as well, but I don't plan to work on that myself. One possibility is to have "port handlers" that could be distributed with elm-get, so anyone could create bindings for robotics, some browser API that's not in the core libraries, or whatever else.

I think main -> "port display" is reasonable, but I don't think I'd want to change it in 0.11 with the port announcement. I have been thinking of it as "main is like a special port" but hadn't considered actually making it a port outright. The key barrier would be that ports do not permit elements through, so it would probably need to be special cased. If that happened, the same special case could be applied to favicon and we could specify those with Element and Form which would be pretty cool :)

John Mayer

unread,
Jan 15, 2014, 12:03:42 PM1/15/14
to elm-d...@googlegroups.com

Why would any particular export type be invalid? Aside from importing functions (purity), what's the reason for the restrictions?

Evan Czaplicki

unread,
Jan 15, 2014, 12:19:47 PM1/15/14
to elm-d...@googlegroups.com
Exporting arbitrary types would expose internal data structures. If there is no corresponding representation in JS, you'd just have to give the value. If you export an arbitrary ADT, the JS programmer can mutate it and mess with invariants or whatever. Same with Elements and Forms.

Max Goldstein

unread,
Jan 15, 2014, 12:25:05 PM1/15/14
to elm-d...@googlegroups.com, john.p....@gmail.com

Why would any particular export type be invalid?


port my_port : Char
port my_port = 'c'

[1 of 1] Compiling Main                ( test.elm )
Type Error: the value sent out through port 'my_port' is invalid.
Acceptable values for outgoing ports include JavaScript values and the following Elm values:
Ints, Floats, Bools, Strings, Maybes, Lists, Tuples, first-order functions, and concrete records.
The values sent through this port contain Algebraic Data Types:

    Char

Arguably Char and [Char] should be converted to Strings. I was surprised to see that unit becomes empty array without any problem. Algebraic data types are not serializable, unless you can think of a JS representation and get the world to agree on it.

Evan, that's a great error message, except for the part where it calls Char an ADT. Maybe change to just "contain the types".

Chris Wright

unread,
Jan 15, 2014, 12:40:31 PM1/15/14
to elm-d...@googlegroups.com, john.p....@gmail.com
2014/1/15 Max Goldstein <maxgol...@gmail.com>
Evan, that's a great error message, except for the part where it calls Char an ADT. Maybe change to just "contain the types".
HIjacking: I've noticed some high-quality error messages in Elm. They're awesome. They make life a lot easier.

John Mayer

unread,
Jan 15, 2014, 12:52:24 PM1/15/14
to elm-d...@googlegroups.com
dilbert_bah.jpg

Evan Czaplicki

unread,
Jan 15, 2014, 12:52:51 PM1/15/14
to elm-d...@googlegroups.com, John Mayer
Hmm, I totally did not think about Chars at any point in writing this! I would not want to special case [Char], but it seems plausible to convert Char to and from strings... I don't feel super great about this though and suspect that it'll be a very rare thing to want to send between Elm and JS.

On the error messages, thank you! :D I've been trying to improve them pretty aggressively whenever I happen to touch an old one or make a new one. I think it's partly because of expecting/actual and because error messages were so bad for so long :P I'm hoping to keep improving this, but thanks for the encouragement! :D

I'll change the "ADT" part. That also messes up on type aliases. One unfortunate limitation right now is that type aliases do not get expanded so they'll get rejected even if they represent a valid type. This is pretty lame, but it's very reasonably non-trivial to fix in the compiler and quite easy to fix in source code.


--

Max Goldstein

unread,
Jan 15, 2014, 1:04:52 PM1/15/14
to elm-d...@googlegroups.com, John Mayer
You'll have to make a decision as to what happens if an incoming string is more than one character: take the first one or call the handler? This might be a good use of the ability to send events from the handler. Leaving [Char] alone is fine, and you could also go the other way and say "use Elm's conversions rather than relying on the ports API to do it for you".

Consider adding the information on type aliases to the error message and the docs.

Evan Czaplicki

unread,
Jan 15, 2014, 1:26:35 PM1/15/14
to elm-d...@googlegroups.com, John Mayer
I think I want to leave Char unsupported for now. This can always be corrected when someone comes and says it causes them issues.

I messed with the errors as suggested :) When it's possible that the error was caused by a type alias, a small note is added.

Type Error: the value sent out through port 'aoeu' is invalid.
It contains an unsupported type:

    Char


Acceptable values for outgoing ports include JavaScript values and
the following Elm values: Ints, Floats, Bools, Strings, Maybes,
Lists, Tuples, first-order functions, and concrete records.

Type aliases are not expanded for this check (yet) so you need to do that
manually for now (e.g. {x:Int,y:Int} instead of a type alias of that type).

When it cannot be related to a type alias, the note is taken away! Whoo programming! :)

Type Error: the value coming in through port 'aoeu' is invalid.
It contains functions:

    a -> Int

Acceptable values for incoming ports include JavaScript values and

the following Elm values: Ints, Floats, Bools, Strings, Maybes,
Lists, Tuples, and concrete records.

Max Goldstein

unread,
Jan 15, 2014, 1:30:20 PM1/15/14
to elm-d...@googlegroups.com, John Mayer
Very nice! And while it was surprising initially, I'm okay not supporting Char.
Reply all
Reply to author
Forward
0 new messages