qmlweb / qmlweb Goto Github PK
View Code? Open in Web Editor NEWA QML engine in a web browser. Current state: fixing things…
Home Page: https://qmlweb.github.io/
License: Other
A QML engine in a web browser. Current state: fixing things…
Home Page: https://qmlweb.github.io/
License: Other
collected all the git instructions from the comments and created a wiki page; https://github.com/qmlweb/qmlweb/wiki/Contribute-Code
@ChALkeR could you please see if this is correct?
also added some links that describes the general workflow, if anyone has a better/shorter link please suggest it.
Would be good to have a section on when to rebase and when to merge (ff-only or no-ff)
does this make sense to us: http://emmajane.github.io/rebasing-workflow/#/0/26
We need tests coverage to be sure that new patches aren't breaking existing things.
See https://git.reviewboard.kde.org/r/117456/
Author: shry15harsh [email protected]
Title:
Add property 'pressedButtons' to MouseArea
Description:
Added pressedButtons property for QMLMouseArea for QMLWeb. Currently, e.buttons is not available in browsers other than Firefox Dom Level 3. So, it is just assigned to mouse.button for now. So, this property will not be able to tell all the mouse buttons pressed at a time.
Merge fork by @arnopaehler.
Object.create
polyfill which is restored by the follow-up commits (and is not there anyway on the master branch).I'm not sure if I like that idea or not, but let's have a discussion.
See #90 for the start of this.
The idea is to add a css file that could set the default styles to our elements based on classes.
This css file could also be split like our js files (per modules/components).
For example, we could apply box-sizing: border-box
to all elements inside the root QML element this way.
Is it worth it? What would be the downsides of introducing a css file to the bundle?
/cc @qmlweb/collaborators.
Merge fork by @labsin.
Needs everyone's approval.
See #4.
Merge kde/realInheritance by @akreuzkamp.
This is aimed to replace #12.
Current issues:
The LICENSE is a modified BSD-3-Clause, we should pick an SPDX-approved variant.
The LICENSE is a BSD-3-Clause, but the files in src/qtcore/qml/lib/
have BSD-2-Clause headers.
We bundle uglify-js
which is BSD-2-Clause
.
Most of web js libraries just use MIT (see #12 for previous discussion).
Given the 1, 2 and 3, I don't know what to put into the license
field of package.json
, and npm
spits on me with these messages:
npm WARN [email protected] license should be a valid SPDX license expression
I guess everyone should be fine with either of these three licenses, but I must ask everyone.
We can also discuss the preferred license here. After that, I will make a PR with the chosen license that everyone would need to review again.
Author | BSD-3-Clause | BSD-2-Clause | MIT | Preferred | Notes |
---|---|---|---|---|---|
@lpaimen | + | + | + | No preference | |
@akreuzkamp | + | + | + | BSD-2-Clause (with parser included), BSD-2-Clause or MIT (with parser excluded) | |
@jangmarker | + | + | + | One commit, through KDE reviewboard | |
@Somsubhra | + | + | + | No preference | |
@JoshuaKolden | + | + | + | MIT | Only Readme changes |
@ChALkeR | + | + | + | MIT or BSD-2-Clause | |
@Plaristote | + | + | MIT? | ||
@labsin | + | + | + | No preference | |
@arnopaehler | + | + | + | ||
@pavelvasev | + | + | + | No preference | |
@henrikrudstrom | + | + | + | No preference | |
@aspidites | + | + | + | MIT | Only Readme changes |
@shry15harsh | + | + | + | No preference | One commit, through KDE reviewboard |
@igosoft | + | + | + | MIT or BSD-2-Clause | |
@aspotashev | + | + | + | One commit, through KDE Phabricator | |
@stephenmdangelo | + | + | + |
Please leave a comment about yourself — are you fine with:
eslint should be added to gulpfile, but it would be better to do that after #15 gets done.
Atm, these GitHub forks are not merged yet:
Also, I should check what was going on on the KDE repo (by @akreuzkamp):
Also, one commit from KDE reviewboard (by @shry15harsh):
Also, one huge commit from KDE Phabricator (by @igosoft):
@qmlweb/collaborators — please review your names and the main emails in the AUTHORS file. Additional emails could be added later in a separate file, if required.
Those would be also used in the «Reviewed-By» header field of commits that you review.
Specifically, @Plaristote, what should be used as the main email?
This blocks #25 landing =).
Some standard element from QML have properties named 'signal' (QtQml.StateMachine.SignalTransition for instance).
However, the qml parser goes nuts when he meets the signal keyword used as a property name. We'll have to fix that at some point.
Atm, we bundle uglify-js
is src
dir and have our own encapsulate wrappers. That is affecting several things and has to be fixed in some way, and using browserify or webpack to make sure that we don't have to deal manually with various module systems would be nice.
We need to decide what to do with the lib/
dir (which contains bundled code).
Do we keep it (and update it) or do we remove it from the repo?
If we keep it — how often do we update it? With each commit or between the releases?
Options that I see (anyone could propose any other solution):
lib/
from the repo. Downsides — it would be harder to download this directly from GitHub, and I guess this will make the package unusable with Bower. I could be mistaken here, though.lib/
before each release tag, with a separate commit. Downsides — lib/
in the repo is desynced with the actual changes in the code, and this would make everyones git status
not so pretty — there will (almost) always be uncommited changes in the lib/
dir.lib/
with each commit. Downsides — this would make merging, reverting, and every other everyday work a little more inconvenient. The work-around is to reset and rebuild it every time, but this would still break automatic merges.lib/
from the master branch (as in 1), make a separate branch (or branches if we would want to keep several of those somewhere in the future) for releases and package all releases from that branch (as in 2). Downsides — master
would be uninstallable with Bower, but this looks better than having master
actually install a previous version.
lib/
from the master branch (as in 1), make tags for each release that are not inside any branches, but in individual tags. Looks similar to 4, see a follow-up comment./cc @qmlweb/core
There should be an org logo, perhaps.
This text does not look neutral to me and could be viewed as being offensive by someone:
CSS and HTML are boring and lame. And they suck at designing cool, interactive interfaces. Qt came up with a much better answer for its renowned framework: QML, a declarative language perfect for designing UIs (and much more). Here's a sample of how QML looks like
We should better rephrase it to be more neutral. I'm not a native English speaker, and I would be glad if someone else filed a pull request to fix this.
Merge kde/master by @akreuzkamp.
Tracking issue: #1.
Git submodules? npm deps? Not sure yet.
I'm not even sure that this has to be done atm.
See branch igosoft-patches.
These patches contain a Loader class, childrenRect and some small fixes.
Unfortunately everything is in one commit. Probably needs some splitting up and needs to be rebased on top of current master.
See also https://phabricator.kde.org/D623
/cc @igosoft Maybe you can set hand to it yourself, you know your patches best :)
/cc @henrikrudstrom
Perhaps we should make them looser? E.g. <10% drift, not <5%.
There is a lot of good discussion going here on individual commits and issues, but i miss a bit a global view of how we see qmlweb after the merge and restructuring.
Im all for merging as much as possible before we refactor, (i suffer a bit from refactor-itis), but i also see there are some interconnected issues with diverging solutions in different forks and i think we need a better idea of what we are working towards. The biggest one of these issues is the file loading and importing, which i made a separate issue for: #...
I would like to propose that we make some design documents in the repo: requirements/scenarios, modules structure, apis, abstractions and how they relate etc. Nothing too formal, but at least something concrete we can refer to and revise to capture conclusions from discussions we have in various threads.
Good idea? waste of time?
Merge fork by @pavelvasev.
That is actually based on #19, I excluded the commits that are already present in #19.
This is what the master
looks like atm:
commit 1ae6a8e787ef18739496a2542d3b3f8c7260b8e3
Author: henrikrudstrom <[email protected]>
Date: Fri Mar 4 13:57:19 2016 +0000
something is not right with test/fix, not.toThrow() makes a lot of other tests fail... changed the test and added it to failing
commit f44fe528e43b7c9881b57122da87e9b71bd9b6a4
Author: henrikrudstrom <[email protected]>
Date: Thu Mar 3 16:11:23 2016 +0100
tests: added timer test
PR-URL: #94
The timer is not very accurate, currently passes is values are "roughly" the same
Reviewed-By: ????????? ?????? ????????? <[email protected]>
Reviewed-By: Michael Martin Moro <[email protected]>Close #94
commit ca19719869818cc7de7e545008a4692b018d4da6
Author: henrikrudstrom <[email protected]>
Date: Thu Mar 3 16:12:22 2016 +0100
tests: basic state and property change tests
PR-URL: #95
Reviewed-By: ????????? ?????? ????????? <[email protected]>
Reviewed-By: Michael Martin Moro <[email protected]>
Close #95
commit 979d61dde45aa1dc9e1c4c3695b524c4ee0a012e
Author: henrikrudstrom <[email protected]>
Date: Tue Mar 1 21:52:19 2016 +0100
use 'spec' reporter
PR-URL: #89
Reviewed-By: ????????? ?????? ????????? <[email protected]>
Reviewed-By: Michael Martin Moro <[email protected]>
Closes #89
commit 4d36ad1b65adc75e87650001a9a8936debf30fb4
Author: henrikrudstrom <[email protected]>
Date: Tue Mar 1 16:15:35 2016 +0100
move div creation and removal to beforeEach, afterEach, loadQmlFile now returns the rootObject instead of rootElement
commit 39bd9d040563a3b3d552b7be8151b53cedaff7d5
…
Below example rendered in a browser changes size of Rectangle due to the fact that the size of the border width is greater than width of component.
Rectangle {
border.width: 200
border.color: "red"
height: 100
width: 100
color: 'blue'
}
At the moment, I don't know which browsers this project is meant to work on. It would be nice to know, for instance, if this relies on technology which precludes running a qmlweb app on IE8.
Declaring a set of supported browsers would also allow choices to be made about supporting libraries and standards. For instance, if only IE10+ is required, I'd then wonder if using ES2015 or TypeScript would make development more sane than plain ol' JavaScript.
Obviously sticking to plain JavaScript has the benefit of being ubiquitously understood, though.
If legacy browsers aren't a concern, it might be nice to state that we officially support the latest x stable releases of Firefox, Chrome, and IE (and whoever else is a big player nowadays). More accurate might be to declare supported version of rendering engines, which would prevent us from alienating niche browsers. dd
Something is wrong with the tests, that needs to be investigated.
No, seriously. 28%?
We can throw half of the code out and tests would still pass — it's not fine.
This has to be fixed asap.
How about we make a separate project with all files and tools relevant to development of qmlweb itself but would clutter the official distribution:
we can add it as a submodule in the main repo, so it would not be downloaded automatically but still we can reference the path consistently in gulp tasks etc.
We should probably integrate with Coveralls to get code coverage analysis reports and badge.
Istanbul should generate the coverage output files.
Merge fork by @henrikrudstrom.
Blocked by #6.
Note: these should be treated as an incomplete list of blockers, for example everything listed here for 0.4.0 could be actually done by the 0.2.0 release, and that would not be something bad.
Update: removed, see Milestones instead.
Hey guys,
I'm very glad to see this initiative arising, to get us collaborate more.
Some time ago (once two and a half years ago and once one year ago) I tried the same, but unfortunately without much success. Namely I have made QmlWeb a KDE project. Now we're here, back on Github.
I would like us to decide together, whether we want to stay/become a KDE project or become/stay an independent project.
KDE is a community of developers, mainly focused on creating the KDE Plasma Desktop and the KDE Applications. But it's a very open minded community, open to everyone who want's to collaborate (i.e. you don't need to use core KDE software to become a community member). It's a project, which is closely linked to the Qt project itself.
Github as well as KDE can offer us all the infrastructure we need (except of github missing mailing lists).
Github's advantage is, that all of us already are on Github, while only three of us are on KDE so far (@pavelvasev, @jangmarker and me). Still we're already a KDE project and pulling the eight of us into KDE might even be less work than building up independent infrastructure. Github still makes it easier to pull in newcomers, though (KDE unfortunately still fails at communicating the ease of contributing there).
One advantage of being a KDE project, that I'd like to emphasize, is not only community but funding. KDE has a big community, that brings us opinions and help, but KDE also has funding. The last two years QmlWeb has been present at the KDE Randa Meetings, which is a annual hacking sprint, where all kinds of teams inside KDE meet and work together for one week. And all expenses are defrayed by KDE e.V.
So: KDE can not only bring us together mentally, but KDE can bring us together physically, let it be Randa Meetings or our own QmlWeb sprint in Berlin, Heidelberg or even Russia.
I think, there's no need to tell you my favorite, still I ask you for your input and want us to decide together. Do we want to stay on github or join the QmlWeb-team of KDE?
Based on the git history:
This means:
Using proper module.exports
instead of setting globals.
Making sure that we don't set globals in the parser.
Making an entrance point that allows users to do something as simple as:
const qmlweb = require('qmlweb');
const data1 = qmlweb.parsePath(path_to_file);
const data2 = qmlweb.parseQML(qml_file_content);
const data3 = qmlweb.parseJS(js_file_content);
Key points:
PR-URL
, Reviewed-By
, and (sometimes) Fixes
fields.PR-URL
and Fixes
should be full links to relevant GitHub PR and Issues accordingly.How to achieve this:
Rebase the commits that you are merging against current master.
Add header fields (PR-URL
, Reviewed-By
, Fixes
) to them.
This and step 1 could be done together, using git rebase -i master
and marking all commits with an e
to amend them.
If possibble — force-push to the branch that is being merged, this way the PR will be marked as Merged
afterwards.
Wait around two minutes for Travis CI tests to complete and make sure that those are green.
Note to self: I was not waiting for them at this point, and this is why we got red Travis statuses on the closed pull requests, because the merge itself failed.
Land the commits on master
and push.
/cc @qmlweb/collaborators
For example, 3fab595 («Rename TextArea to TextEdit to conform QtQuick») was not landed and needs to be redone.
There could be other elements that need renaming or moving.
Update: actually, I'm merging 3fab595 in #28, let's get that in for now.
I'm going to keep a TODO list here.
Re-check TextArea and TextEdit.
Atm, both of them are defined in TextArea, see 636b1e0 for details. Perhaps those should be split, perhaps TextEdit should at least have a separate file.
Re-check Button — registerQmlType('Button', QMLButton);
does not look valid.
Re-check PropertyChanges — registerQmlType('PropertyChanges', QMLPropertyChanges)
does not look valid.
Re-check Component — registerQmlType('Component', QMLComponent);
does not look valid.
Re-check QMLDocument — registerQmlType('QMLDocument', QMLComponent)
does not look valid.
Noticed that in a CI job.
Will take a look at that.
All collaborators should be probably asked to join to the org.
Will prepare a list a bit later, should be based on #3.
This should be probably done after merges.
Instead of using global, everything should be added to a single object (qmlweb
? QmlWeb
? QMLWeb
? QML
?) and that object should be added as a window
property on browsers or directly exported in CJS.
This will allow us to ditch encapsulate.begin.js
and encapsulate.end.js
files which are actually not js files and make the build process simplier.
I should finishin the WebSocket implementation.
Previous work by me: https://git.reviewboard.kde.org/r/116067/
Something is wrong with the build atm, it produces inconsistent results.
That's not suitable for putting into git.
Looks like the order of files is random.
I've noticed some strange behaviours when testing:
Has anyone else noticed this kind of behaviour?
is this a gulp issue or something related to webqml?
should we consider tests that suddenly fail without any direct changes a failed test, i mean there must be some conditions that trigger it that we havent accounted for?
most recent example is the propertyNamedSignal
test. Had to sneak in a fix: 1ae6a8e
I mean the .loadFile()
and .loadQML()
methods.
Targeting 1.0.0, as the API might change.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.