It is not immediately obvious which complication families need to be implemented to support a specific watch face.
Also, which complication families can be placed in the same complication slot. For example, it appears the either CLKComplicationFamily.extraLarge or CLKComplicationFamily.graphicExtraLarge can be used in the same slot on the Extra Large watch face. Yet in my testing only CLKComplicationFamily.modularSmall can be used on the Modular face, even though it seems like CLKComplicationFamily.graphicCircular should fit as well.
Is there a full list somewhere of which families work on which faces?
I found this article that contains a table with the info I am after, but I'm still wondering if there is any official documentation about this.
I started a repo on GitHub to document this for myself. Hopefully it will help others.
https://github.com/curiousdustin/watchos-complicated-faces
I went over demos within quantstrat GitHub, also took a bootcamp course on how to use the package and read several posts and Q&As concerning signals and rules, however I am still failing to implement complex rules where thresholds are hit multiple times in a given sequence/chain in order to create my entry point.
By now I am pretty much convinced I yet don't understand the mechanics so I can stretch examples I went through to implement rules such as this:
Beforehand, my expectation is just to get a hint on how to build a cross-over or threshold rule that is 'aware' of its place in a workflow so I can expand it into more complex cases, such as the one in the image above.
I searched here and found a reference to their being a canvas renderer, but have not found it as an option. Has that project been completed?
I am trying to render 200-300 nodes and roughly 600-1000 edges and am not seeing acceptable performance. I had initially been using sigma.js and was happy with the rendering, but the lack of documentation and small feature set pushed to use cytoscape.js...which I am loving for how easy it is to work with the styles and accessing node and edge attributes...
This question has been answered elsewhere, but I will reiterate for completeness. Please do not ask in more than one place in future. It will not make for faster answers, and it's confusing for others.
There is indeed a canvas renderer, and it is the only renderer available to you -- other than the trivial null renderer or a renderer you write yourself.
As for performance, it is a function of the layout performance and you're using one of the most expensive types of layouts -- forcedirected -- although nice for several graphs. If you want better performance given the size of your graph, you're better off using a nonsimulation layout, like the breadthfirst layout.
You also have the option of writing your own layout that could be completely tailoured to your dataset. It's very easy with the API: http://cytoscape.github.io/cytoscape.js/#extensions/layouts
I'm trying to develop a chess program. It will be regular bruteforce searching of a tree, the only thing different will be the evaluation. Initially I will use a standard evaluator as designed by Claude Shannon so that it is more easy to test if it works fine at the base. Move list generation and all other infra around it works fine.
Now for the searching: I would like to use the alpha/beta pruning code example of wikipedia.
And that's what is a bit of a problem: it is ambiguous about one thing; from who's perspective should the evaluation be done? I've been googling for days (literally) but no example says this explicitly.
So: should the evaluation be
from the point of view of the "current mover" at that depth
from the point of view of the "opponent of current move" at that depth
from the point of view of the mover at the root of the tree, e.g. the person for who this tree-search is being done (the AI player)
from the point of view of the opponent of the mover at the root of the tree
?
I experimentally tried rootSide, side, rootOpponent, well basically all options and then let them play against each other. The outcome of that was that "current mover at that depth" would be the one to use (it won most frequently) but testing that version against any other engine result in 100% loss.
Of course wikipedia will be updated to be more clear about it! (please ignore the note on the side in the wikipedia history: that was from myself which might be incorrect so I removed it)
Evaluation should be performed from the perspective of the node invoking it. This is your first case, and it is the only one that really makes sense.
If you're testing your very basic engine against other complete engines then yes you can expect to lose every match. You are missing lots of techniques so playing against other engines is not a good method of testing right now. Once your engine is stronger then yes you can use this method to improve strength or perform regression testing.
I'd recommend setting up simple positions and playing with it manually to look at whether it can see basic captures, checks, checkmates, etc. Be warned that even with a perfect implementation of alpha-beta and simple evaluation that your engine will still blunder at times. This is because of the fixed search horizon so next you may want to look into quiescence search.
I know they are, but my co-worker doesn't believe me. He keeps telling me that Google crawls the inside content and caches it just fine. According to Google, it does crawl them, but doesn't guarantee doing it properly.
Any thoughts why frames are bad for public web sites?
There are various usability and accessibility issues with frames:
link can open in the frame it is enclosed in (e.g. a side pane);
can break the forward/backward navigation;
difficult to bookmark;
are not easily searchable (likely to see the content in Google, etc.);
break on browsers like Lynx, that are console/terminal based;
difficult to size properly (e.g. consuming height on widescreen monitors for banner frames);
can break with screen readers and magnifiers (for blind users and visual impaired users);
See http://www.angelfire.com/super/badwebs/ for an example of what not to do.
Frames are more difficult to bookmark and, therefore, more difficult to share with others.
http://www.yourhtmlsource.com/frames/goodorbad.html
IFrames (like HTML tables) are not bad. However, people were abusing them quite a lot, thus giving them the bad name.
IFrames do represent a good concept - single visual representation of documents coming from different sources, while keeping the DOM trees properly separated and isolated.
The problem arises when a script in one of the DOM trees needs to access the elements in another tree. Or when people want to reference the document location, which happens to be the URL of the root document, and fail to realize they need to location of the secondary document.
But the biggest problem with frames is that there are sites that want to encapsulated other sites in frame and trick the user to think they are interacting with the framed site, while in fact interacting with the outer one. This is the primary reason why most websites will employ some form of frame-busting scripts for their login pages.
Update: It's Friday and we need some fun, so here's the (obligatory) link to Jeff's post on frames-busting-busters-busting... :-)
At the beginning ...
The idea behind framesets is great. It's alive and kicking today; check StackOverflow's left side panel, or the header. They are fixed divs, which is basically the same thing as having frames, although a lot more flexible.
The very concept of keeping some part while changing another is simply necessary by the logic of webpages. We need something to stay where it was (typically navigation) while we go through a lot of details in the main area. Framesets served this purpose very well, they were easy to use and fully supported by all browsers, meaning 3 at that time (Netscape, IE, Opera).
Then we scorched the sky
The real, practical problems with frames had nothing to do with their basic concept. Instead, it was us being only human. I followed this whole debate very closely so believe me when I say these were the real charges against frame technology:
Designers hated them. Yes, that was the deadliest punch. Everything looked square and straight. They hated it. They wanted arcs and image backgrounds and rounded borders. Now they have it in CSS3 - guess what, they're drawing squares. #whatever
Programmers had trouble with them. It was inconvenient to follow the logic of frames, and you had to do some extra work. I mean, some. Today it's a lot harder to create AJAX solutions for the same problem, but no one complains. #whatever
Websites could include one another. This was painful for some site owners because they worked hard on something and another fella used it as own content. Later, they invented same origin policy, but it was way after starting to hate frames. Content stealing is still an issue today, absolutely unrelated to whether we have frames or not. #whatever
Back button worked differently. Yes, it was a bit annoying. But it was not the frame concept's fault, again: it was browsers who did this to us. Could have been solved easily, but nah, browsers kept going back one by one, not providing the site a way to implement its own "step back" method, and alas, this is still happening today. #whatever
So instead of coming up with a solution, the world's web developers decided to hate frames. They ditched it, and now we live in a world where there are lots of better solutions - but with a lot more effort. This was not the only feature going thru the hate-ditch-reinvent-love cycle; see vertical centering and flexbox, aka the table tag debate - and it will happen many more times because it's always easier to point fingers at something than to learn why it's great.
I don't hate frames; don't miss them either, they belong to a somewhat outdated world of web. But they were a good solution for something, and there's a chance we'll see something similar in the future just as CSS grids came back to implement what table layouts did before. The same community who hates the old solution will happily embrace the new and tell you why it's not the same at all.
I think this story has a single takeaway:
Implementations come and go.Concepts stay and evolve.
Depending on what you want to do, most things done with frames can be done with CSS. CSS stylesheets are compatible with all MODERN browsers, meaning your website will look the same if using firefox, chrome, or IE 7(with some tweaks). Also backward-compatibility is not a concern as users can view the content even with CSS off (where as a website using frames and without a frameless version of the site will be useless to a user with an old browser), it just won't be as stylized. It's also quite easy to learn, and once you get the hang of it you'll wonder why you haven't learned it in the first place.
I know this is an old thread but..
Been using Frames almost all my life and I think they are great. I still have a few websites using frames and I cannot understand why they are being droppped. Read all of the comments above and disagree with most of them. Problem is most people never bothered to overcome the issues.
Link can open in the frame it is enclosed in (e.g. a side pane);
Yes it can, but if you do it properly it does not matter. Frames can in fact be very useful for this precise reason, as clicking on a link will only refresh the frame the link it pointing to, not the entire webpage. In the days of dialup modems at very slow speeds this used to be extremely useful to save on bandwidth and make webpages appear superfast. Dont forget, there are still people around the world today (albeit not many) that have very limited internet connectivity at very slow speeds. (people on sailboats in the middle of oceans, those die hards that dial into the internet using HF radio. Oh and those that live in war zones that revert back to poor mobile phone signals, or possibly even need to dial into the internet in another contry using their infrared connections on mobile phones via a modem)
can break the forward/backward navigation.
Yes it can, but if you do it properly it wont.
difficult to bookmark
again very easy to overcome, requires very little additional work, but can be easily overcome
are not easily searchable (likely to see the content in Google, etc.);
break on browsers like Lynx, that are console/terminal based;
Already covered by somebody else earlier. Personally I have never even heard of Lynx (apart from the deodarant). In fact it used to be quite useful that pages werent searchable when you did not want to get spammed by bots searching for email addresses... Unfortunately Google or somebody figured out how to do it.
Difficult to size properly (e.g. consuming height on widescreen monitors for banner frames);
Clearly whoever wrote this has hardly any experience of using frames. This was exactly why I used frames because I could make it work on any screensize in what some would refer to as Fluid views on modern web design
can break with screen readers and magnifiers (for blind users and visual impaired users);
I suppose it can if screen reading software and maginfiers are cheap and rubbish and dont know what they are doing, probably them that complained about it, but there are others that manage this easily.
The only argument that I think makes sense, is that people were abusing them. Now I would not know how that was done, as I am not in that game, but I suppose it would be easy to use frames to show a copy of lets say a financial payment page inside another another frame which is completely hidden to make it look like the user is on the correct page. Therefore conning users out of their beer tokens. But I believe more modern webbrowsers have been updated to overcome these issues and not allow re-direction where encryption certificates are used.
I can therefore understand why they would want to restrict the use of frames, but dont understand why they need to completely remove what is a pretty good bit of tech. (Bit like saying we are going to stop people from using 0 when they do math as it causes can sometimes cause problems when you add many 0's together.)
I still have some websites that use frames and wonder when I am going to have to re-code them one day.
PS. also note that google calendar and youtube allow one to imbed pages into websites and both of these use iframes.