Real tabs support for browser #46
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 30 commits
February 28, 2014 13:52
WebView contains all dependencies that it used to have. Mininal number of changes have been done inorder to isolate WebView from BrowserPage to and a new component. Upcoming commits will move WebView related functions from BrowserPage to WebView.
This also adds property tabModel for WebView
Previous commit SHA1: 60811e7
This commit also moves load function to WebView.
DeclarativeTab contains now always update to date information. When tab is activate, bookmark clicked, or history item clicked, DeclarativeTab gets update immediately. Database actions are triggered in parallel and that might update tab's properties when transaction is done.
In reality exposing these like this would require that matching api would be met, now there is no guarantee but this is still internal.
…gered. This handles tab change from the grid and closing of active tab.
Loading is now started immediately when active tab changes.
suspendView and resumeView of active MozView directly.
This fixes first load not to emit activeTabChanged twice. Currently title text blinks in toolbar when navigating links. This is not visible in update3 version.
Replace firstFrameRendered with DomContentLoaded
[sailfish-browser] First use with real tabs. Contributes to JB#17886
- parent is QQuickItem pointer - container property is read-only to QML side
Send available composition size to embedlite components when virtual keyboard open
It is still assumed that contentItem can only be DeclarativeWebPage.
Remove explicit DeclartiveWebPage dependency from DeclarativeTabModel
There are lot of small changes done. DeclarativeWebContainer uses now only title and url from the active page and those are also exposed to QML side. DeclarativeTabModel owns now one Tab instance that matches to the current active tab. This is the tab that is pushed back to model data when a new tab is activated or an active tab is changed.
This commit adds getters and setters for url, title, and thumbnail path. Also currentLink() is there but now it is returning the linkId similarly as previousLink() and nextLink() methods.
Now signal has oldTabId and activeTabId parameters.
Now tst_webview is the only linking against xulrunner. Other unit tests are more less standalone but e.g. tst_declarativetabmodel needs mocked DeclarativeWebPage. Linking to gecko caused random bad binaries (don't completely understand) as inside gecko RTLD_GLOBAL is used to when calling dlopen. What I saw is that Qt SQL module found sqlite3_bind_int64 from ibmozsqlite3.so causing unexpected behaviour when running tst_declarativetabmodel.
Remove DeclarativeTab class
When BrowserPage is not active we should wait until it is the active page. This leaves time to animate the PageStack pop if TabPage happens to be the active page when new tab is requested.
Don't let new tab creation to block PageStack animation
| @@ -15,11 +15,12 @@ | |||
| #include <QAbstractListModel> | |||
| #include <QQmlParserStatus> | |||
| #include <QPointer> | |||
| #include <QScopedPointer> | |||
| #include <QQuickItem> | |||
| #include <QQmlComponent> | |||
There was a problem hiding this comment.
QQuickItem and QQmlComponent are not needed anymore here. Left overs and should be removed.
rainemak
changed the title
Conflicts: src/pages/BrowserPage.qml
| @@ -23,8 +23,8 @@ BuildRequires: qt5-qttools-linguist | |||
| BuildRequires: gdb | |||
There was a problem hiding this comment.
Wrong line but...
BuildRequires: pkgconfig(qt5embedwidget) >= 1.7.3
Needs to be updated.
added 3 commits
April 7, 2014 14:38
rainemak
pushed a commit
that referenced
this pull request
Apr 7, 2014
Real tabs support for browser
rainemak
pushed a commit
that referenced
this pull request
Jun 24, 2015
Cleanup garbage from test name
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Working in progress pull request for reviewing.
There are following topics that we should do. Not necessarily immediate actions needed but in my opinion would be still best to do these fast so that we don't start building up more too much new stuff on top of these.
TabModel should be merged with DeclarativeTabModel. This was fastest approach to do up to this point (task NewWebView: Merge TabModel with DeclarativeTabModel #47)WebViewTabCache.js (pragma) should be merged with DeclarativeTabModel (task NewWebView: Merge WebViewTabCache.js (pragma) with DeclarativeTabModel #48)All declared properties in QML side should be defined in C++ to help integration of TabModel & DeclarativeTabModel. For MozView this could mean that we could expose DeclarativeWebPage and create page instances through WebView. Conceptually MozView is quite close to a page that can be navigated back and forth. (task NewWebView: Declare properties in C++ side #50)Will write down tasks of these.