axr / core Goto Github PK

elementA { focusable: yes; }
elementA::focus { focusable: no; }

The next element focusable should be focused when elementA is focused.

spec chapter

1.3.3

"selects the element that contains it, in the object tree"

Right now, it always acts as if all borders had position "center". The positioning algorithm must take into account all the different positions and sort the borders, then position them accordingly.

http://axr.vg/spec/chapter/24

I'm a complete noob in anything unit tests related. Can anyone help me out? What should we use? One thing I've seen that looks interesting is http://code.google.com/p/googletest/ Could this be useful for us?

related to #60 and #61

Here's @vprimachenko's first draft:

https://gist.github.com/1548157

We need to work out the exact API for our wrapper classes, so that the core library can be easily integrated into different environments, as app or as plug-in.

Related to #5

Turns out that, many times, failing to do so allows the value to be modified outside of the intended way.

*Edit: changed the description to more accurately reflect what we need to do

http://spec.axr.vg/specification.html#n1.6.3.9

code the acid test in relation to the result of axr/specification#9's completion

http://spec.axr.vg/specification.html#n1.4.6

What documentation system should we use? I propose Doxygen:

http://www.stack.nl/~dimitri/doxygen/index.html

What would you recommend?

http://axr.vg/spec#1.5.1

1.3.6 on http://axr.vg/spec/chapter/9

http://wiki.axrproject.org/resources/modules#basic

HSSDisplayObject's setDBorder is the way to go. We need to refactor all setters (most importantly, those which accept multiple values), to follow this implementation.

http://axr.vg/spec/chapter/36

This should happen at HSSObject level, I think

http://spec.axr.vg/specification.html#n1.2.6
http://spec.axr.vg/specification.html#n1.3.3

The dylibs must be copied and there must be a script for automatically adjusting the install_path so that they are relative to the app bundle.

#support (354) { }
#support (≥ v1.2) { }
#support (:filter) { }
#support (::flag) { }
#support (/splitter) { }
#support !(A) & (B) { }
#support (A) | (B) { } //short-circuit OR

support module

Of course it can be nested.

What would you guys think of this thing? It think it's something that will prove very useful for backward compatibility.

We could use Firebreath: http://www.firebreath.org/display/documentation/FireBreath+Home

Any other ideas? Should we create an individual wrapper for NPAPI and for ActiveX (IE), or should we use a framework like the one above?

http://axr.vg/spec/chapter/85

http://wiki.axrproject.org/resources/modules#basic

The Windows port throws an error when closing the "open file" dialog without selection a file.

https://castle.so/16k4n/preview

One of the proposals is Jenkins: http://jenkins-ci.org/

http://spec.axr.vg/specification.html#n1.6.3.8

We need to discuss how we are going to best solve the issue of auto updating the rendering engine.

When an author links to a stylesheet, the version of HSS that is used needs to be declared, like so:

<?xml-stylesheet type="application/x-hss" src="style.hss" version="1.0"?>

This way, whenever a newer version is required, the rendering engine will check if such a version is available, and if so, prompt the user to update to the latest version.

Now, we need to find a great cross platform solution, or discuss the merits of doing each platform separately. One interesting project I've found on this regard: http://code.google.com/p/update-engine/ and Sparkle: http://sparkle.andymatuschak.org/ but they are only for OSX. How is auto update usually done on windows?