Most important changes:
- added support for mouse gestures;
- added initial support for customizing toolbars;
- allow to load plugins on demand;
- more actions (over 150 in total);
- added Go to Page dialog (F2);
- allow to customize menu button (JSON file);
- lots of other fixes and improvements.
Your package naming causes problems because package management considers 9.04_amd64 to be older than 9.04-dev52.
I still can't play youtube videos (HTML5 player neither Flash player) on this new beta version under windows 7.
Neither dailymotion...
This is the only issue that is keeping me away from making otter my main browser of choice.
I still can't play youtube videos (HTML5 player neither Flash player) on this new beta version under windows 7.
YouTube videos are playing here with beta 4 on Windows 7.
@py-thon, we will drop DEB packages from sf.net in favor of PPA anyway.
@zundapp, you need to have system-wide codecs (32 bit for 32 build or 64 bit for 64 bit build), we are investigating how to solve this properly (for example, bundle them).
Please post more details about that flash issue, is it just YT or any flash content (not just player(s))?
we will drop DEB packages from sf.net in favor of PPA anyway.
So I will already have to say goodbye to Otter because ppas are for Ubuntu only and known to sometimes wreck Debian systems.
@py-thon, it's identical to current packages, but without duplication, automation and with proper packaging information.
We don't have enough man power to handle all kinds of packages and these were targeting Ubuntu anyway, it's a shame that Debian haven't picked it yet itself, while there exist packages for other major distributions and ports for FreeBSD and OpenBSD (in progress, blocked by Qt5 state).
And buiding it from source is very easy and doesn't require any noticeable resources other than header files.
Note that current DEB packages were built against broken stack found in Ubuntu 14.04 (Qt 5.2 but with QtWebKit 5.1), which means that some features (like media actions) were not available at all there.
And buiding it from source is very easy and doesn't require any noticeable resources other than header files.
If you are a programmer it sure is "very easy".
I tried building from source (with other programs) several times and it never worked. Always needed tons of additonal packages and/or just gave me loads of cryptic error messages.
I'm inclined to agree that there should preferably be a DEB package available for download. I wonder how hard it'd be to set up some kind of Debian Jessie box with Vagrant.
Buntu has ceased to mention Linux on its webpage, so it should not be expected that it remains compatible with Debian. I don't myself understand the details, but if PPA means no .deb file downloadable, then this sounds totally not friendly to Debian. And the differences between Buntu and Debian in the future are likely to increase further.
Building from source is not too hard (if it succeeds), but dependencies are very hard. Most of Otter's dependencies are unknown to me. I installed Qt5 stuff the first time as a dependency of Otter. Had Otter's source not been packaged in a friendly way, properly linked to dependencies as it is in the Arch user depository, I would never have been able to install it.
In contrast, I have not been able to install the .deb files on Mint due to unsatisfied dependencies. It's not because of lack of trying. It's because dependencies really are that incomprehensible on Linux.
@py-thon, have you tried that in case of Otter?
If development packages have proper dependencies then it is enough to install header files (usually packages with -dev suffix) for qt5multimedia, qt5script, qt5webkitwidgets (it might be also just qt5webkit) and qt5sql (might get removed later).
If you don't have CMake yet then of course CMake itself.
In case of errors mentioning gst (apparently it's not always pulled in) you might need to install headers for GStreamer.
@Frenzie, we would need to automate it, it takes noticebale additional time each week, we would need to utilize something like this:
https://en.opensuse.org/openSUSE:Build_Service_supported_build_targets
@ersi, it's still possible to download them directly.
And we don't have any direct dependencies outside Qt yet (but "standard" header files plus Qt specific might seem to be a lot). ;-)
Although lack of dependencies might change soon, but nothing fancy, just icu, gcrypt and hunspell.
@Frenzie, we would need to automate it, it takes noticebale additional time each week, we would need to utilize something like this:
https://en.opensuse.org/openSUSE:Build_Service_supported_build_targets (https://en.opensuse.org/openSUSE:Build_Service_supported_build_targets)
Naturally, that's what I mean. There'd be a Vagrant bootstrap.sh to automate setting up a bunch of build environments and another script to do the actual grabbing the latest version and building. Well, if one wanted to go that route, anyway.
So, any volunteers? ;-)
Not this weekend, but next week I might be able to look into it. NB I have no special attachments to Vagrant or anything, but it's the only thing I'm familiar with.
Some potentially helpful links:
- Building a Vagrant Jessie box from scratch, automated with veewee (I'd probably prefer to avoid this) https://github.com/holms/vagrant-jessie-box
- Premade Jessie box https://downloads.sourceforge.net/project/vagrantboxjessie/debian80.box
- Packaging Otter for Debian and derivatives (automate away the manual steps with git rev-parse --short HEAD or some such) https://dndsanctuary.eu/index.php?topic=507.msg27803#msg27803
I expect that I should be able to automate the packaging itself easily. For the Vagrant VMs I'm hoping the same applies, but I don't really have much experience with that.
We don't have enough man power to handle all kinds of packages and these were targeting Ubuntu anyway, it's a shame that Debian haven't picked it yet itself, while there exist packages for other major distributions and ports for FreeBSD and OpenBSD (in progress, blocked by Qt5 state).
How about using some distribution-independent packaging system? http://0install.net/ reads interesting. I think such would make sense for Otter.
How about using some distribution-independent packaging system? http://0install.net/ reads interesting. I think such would make sense for Otter.
What might also make sense: a static build with no dependencies (Opera had one, I think). It might take a while to build, but since betas are published only every few months, it should be done. That way, even users of unusual platforms could test this promising browser.
YouTube videos are playing here with beta 4 on Windows 7.
@zundapp, you need to have system-wide codecs (32 bit for 32 build or 64 bit for 64 bit build), we are investigating how to solve this properly (for example, bundle them).
Please post more details about that flash issue, is it just YT or any flash content (not just player(s))?
Weird... it is now playing youtube videos fine.
From treego post I decided to instal flash again. So I did and not it is playing youtube videos both using Flash and HTML5 when before even HTML5 player wouldn't work.
Weird...
@py-thon, have you tried that in case of Otter?
If development packages have proper dependencies then it is enough to install header files (usually packages with -dev suffix) for qt5multimedia, qt5script, qt5webkitwidgets (it might be also just qt5webkit) and qt5sql (might get removed later).
No, I have never tried with Otter. There are deb-packages so far :-)
This compiling might sound simple to you but to non-programmers it is not. Even with programs where there is a detailed explanation about the procedure the reality always differed from the explanation in my experience and I got stuck.
According to http://sourceforge.net/projects/otter-browser/files/otter-browser-beta4/ I would need qt-sdk. This means 22,5 MB for the online installer (plus whatever's installed afterwards) or 542 MB for the offline installer just to get the environment to compile Otter's 2 MB package. That's what I meant with "tons of additional packages".
Alright, here's a quick proof of concept for the automated creation of proper DEB packages.
https://gist.github.com/Frenzie/468540b519eb8951a6ec
@Frenzie, thanks, we would need to think about dedicated VPS in next weeks, something cheap but powerful enough.
OTTER_VERSION_MAIN=$(grep OTTER_VERSION_MAIN otter.pro | grep -Eo "([0-9].?)*")
OTTER_VERSION_CONTEXT=$(grep OTTER_VERSION_CONTEXT otter.pro | grep -Eo "\-.*")
It's safer to extract this from
CMakeLists.txt, I would like to drop qmake project file as soon as there will be clean solution to set icon for Windows binaries.
What might also make sense: a static build with no dependencies (Opera had one, I think). It might take a while to build, but since betas are published only every few months, it should be done. That way, even users of unusual platforms could test this promising browser.
Yes, we can finally reconsider this, as we might need to create custom Qt packages anyway for Windows:
https://github.com/Emdek/otter/issues/631
Although I'm not sure if it is possible to have static build of QtWebKit and if it is doable for QtWebEngine.
We can at least try. ;-)
@zundapp, don't ask me, Windows is mysterious platform.
@py-thon, I know, I've used to compile stuff from source (like
warzone2100, which has far more dependencies and uses autotools, which are far less friendlier than CMake or qmake) before creating own projects. ;-)
SDK is mentioned as it's generic solution which applies to all platforms, if you have system wide Qt 5.3 or later then you need to install only header files which will take far less space and can be reused by other projects.
It's safer to extract this from CMakeLists.txt, I would like to drop qmake project file as soon as there will be clean solution to set icon for Windows binaries.
Sure thing.
Edit: I thought this Vagrant thing would take a while to figure out, but it's actually quite simple — at least for some basic stuff. It's all a bit hacked together atm obviously, but in principle anyone can now get their own almost fully-automated DEB package. https://gist.github.com/Frenzie/468540b519eb8951a6ec
So yeah, that's basically it as far as proof of concept goes.
@Frenzie, so the missing stuff seems to be support for 32 bit (should be doable on the same machine) and some VPS itself, right?
@Emdek
Well, I'm not quite sure what the goals are. Of course my own immediate goal is to secure the availability of DEB packages, which I believe to be in Otter's best interest. But secondarily it's also a clean environment for testing the quality of said packages and automatically notifying you of most potential problems. For example, a lacking build dependency will almost certainly show up, while your regular environment may have all kinds of stuff installed you don't really think about. That kind of thing is not only important for Debian inclusion, but it's also just good sense. And third, of course you can do a whole lot more with the concept. At the simplest level there's simply executing the exact same commands in e.g. an Ubuntu VM.
Anyway, I suppose the biggest missing things right this moment would be 32-bit and some way to create a "proper" release rather than a nightly build.
Regarding a VPS, I really couldn't say whether that has any added value or not. Note that for automated unit testing Travis CI (https://travis-ci.com/) integrates with Github.
@Frenzie, well, so far the best notifier about something missing in Debian control files is Launchpad, sending the same emails for each architecture separately (from daily PPA). :-D
But users are faster than build bot and deprecating otter.pro would mean single project file and at least no chance to break CMake by accident.
Uhm, I didn't know that Travis CI is free for open source projects...
But I don't have time to research it further right now.
@Frenzie, well, so far the best notifier about something missing in Debian control files is Launchpad, sending the same emails for each architecture separately (from daily PPA). :-D
Good, good.
Uhm, I didn't know that Travis CI is free for open source projects...
But I don't have time to research it further right now.
It's pretty simple. You'd add a .travis.yml file to the root with something like this:
language: c
compiler:
- gcc
before_install:
- sudo apt-get update
install:
- sudo apt-get install blabla
script:
- cmake
- make
- make backend-unit-test-stuff
after_success:
- make gui-unit-test-stuff (does Travis support that? no idea)
But I just remembered, their VMs run Ubuntu 12.04, so for the moment it probably wouldn't do much for Otter regardless. (You could just download the Qt5 SDK, but that seems a bit abusive. :P)
Edit: oh, there's something possibly helpful in the form of https://gist.github.com/jreese/6207161
Anyhoo, the more automation the better I say. But definitely low priority until some GUI things stabilize a bit more lest it causes more work rather than less. ;) Still, even a mere automated build completion test might not be a bad idea.
@Frenzie, Travis can wait, we would need to automate packaging first anyway.
Maybe we should research this option for now, to get even more targets for free?
https://en.opensuse.org/openSUSE:Build_Service_supported_build_targets
Maybe we should research this option for now, to get even more targets for free?
https://en.opensuse.org/openSUSE:Build_Service_supported_build_targets
Since you didn't mention it, did you also look at <a href="http://0install.net/">Zero Install[/url], as I suggested earlier, regarding getting targets for free? It's <a href="http://0install.net/why.html">About[/url] page describes it as a cross-platform installer, that uses some XML file, that describes the software and dependencies to be installed. The file needs to be published somewhere by the developer and is apparently to be used like an RSS feed by the user (for updates). There is a <a href="http://0install.net/injector-packagers.html">packaging guide[/url], which describes how to create such a software description file. That way, the software developer only needs to maintain the XML file and the installer will fetch the necessary files for the user's system from the description. Zero Install itself seems to be available from the package installers of a <a href="http://0install.net/distribution-integration.html">number of distributions[/url] already.
There's also the <a href="http://nixos.org/nix/">Nix package manager[/url], which seems to implement similar functionality, although Zero Install seems to come with more conceptual forethought, like digital signatures for software packages. Nix seems to be available for some Linux distributions and Mac OS X, but unlike Zero Install, not Windows.
Although I'm not sure if it is possible to have static build of QtWebKit and if it is doable for QtWebEngine.
We can at least try. ;-)
I think, static builds should still be preferred for maximum compatibility. Fully custom build options might also allow for minimal file size. I'm not sure how the <a href="http://alpinelinux.org/about/">Alpine Linux[/url] folks do it, but since they're using <a href="http://www.musl-libc.org/intro.html">musl[/url] as their libc, which was designed for static linking, and they seem to have a <a href="http://git.alpinelinux.org/cgit/aports/log/?qt=grep&q=otter">package[/url] for Otter, they might have built it and their Qt5 statically. I did not look into it though. But static builds should be possible. In the case of using musl as the libc to build, it might also help keeping file size low, <a href="http://www.etalabs.net/compare_libcs.html">compared[/url] to other libc implementations.
we would need to think about dedicated VPS in next weeks, something cheap but powerful enough.
The cheapest dedicated server I've seen is <a href="http://www.online.net/en/dedicated-server/dedibox-scg2">Dedibox SC Gen2[/url]. Availability seems to be limited though. Last month, it was the same picture: 42 available, but at some point, availability switched to "victim of its success", so there might only be a limited number of systems per month, after which one has to wait before they can be ordered again. If just any VPS is enough, there are of course cheaper bare minimum box <a href="http://lowendbox.com/">offers[/url].
@4r3a9n8d2o7m8, there are lots of these systems, more or less dead, that is totally separate topic, to be revisited near 1.0. ;-)
Same applies to static builds, these would be nice to have but require time and resources, so I won't work on them myself for now (again, any volunteers? ;-)).
42 available
I guess that it has nothing to do with actual number of free slots. :-)
http://en.wikipedia.org/wiki/42_(number)#The_Hitchhiker.27s_Guide_to_the_Galaxy