Nightlies for MuseScore 2.0.3
In parallel to the addition of new features for the next major release of MuseScore, we believe it's important to release regular bug fixes. In the past we issued MuseScore 2.0.1 and MuseScore 2.0.2 to fix urgent issues and introduce carefully chosen features. We are now working towards MuseScore 2.0.3 in the same spirit.
Since yesterday, the nightly build servers for Windows and Mac OSX create packages for the master and the 2.0.3 branches.
The nightlies for 2.0.3 branch should be compatible with 2.0.2. Meaning 2.0.2 will in most of the cases open a score made with 2.0.3 (except if you use some small new features in 2.0.3, not present in 2.0.2). In addition to the various bug fixes, MuseScore 2.0.3 nightlies now use the same version of Freetype on every platform to layout the musical glyphs. This is a bit on the edge for a bug fix release, but I believe it's important enough to have the same layout on all platforms to take the risk. The 2.0.3 nightly builds should be relatively stable but they are still untested software, so be careful and backup your work often.
The nightlies for the master branch are incompatible with MuseScore 2.0.x. Files created with these nightlies will not open in 2.0.x. The master branch being our playground, these nightlies can become very unstable.
If you are eager to get your hands on MuseScore 2.0.3, please download a 2.0.3 nightly and give your feedback! Feel free to squash some bugs from the issue tracker so we can include the fixes in 2.0.3. Join IRC #musescore on freenode.net or ask on the forum if you need any help.
Comments
It looks to me like the 2.0.3 nightlies are not 100% compatible with 2.0.2. The new text lines with hairpin playback were added to 2.0.3 as of 3dedc1f4cf, but if a score containing these elements is opened in 2.0.2 they irrevocably turn into hairpins. Is it possible to back that commit out of the 2.0.3 branch, and save it for 2.1 (when the different file format version number would trigger a warning if such a score was opened in a 2.0 version)?
In reply to It looks to me like the 2.0.3 by Isaac Weiss
If you use a new feature in 2.0.3, then of course that new feature won't be available in an older version. This was explained way back when we made this. But the score can still be opened and will look exactly as it would have had you used 2.0.2 all along. I don't see any reason to deprive people of the ability to use this feature just because it wasn't availabel in older versions and thus won;'t be available any more if someone for some reaosn chooses to go back to an older version. That just doesn't make any sense to me.
In reply to If you use a new feature in by Marc Sabatella
But at that time there was not a statement from lasconic saying "The nightlies for 2.0.3 branch should be 100% compatible with 2.0.2."
In reply to But at that time there was by Isaac Weiss
That was the intent all along, and in any case, statement or no statement, what I wrote above remains true. I see no reason to deprive someone of a new feature just because they might be disappointed if they are silly enough to expect that new feature to still be available if they revert to an older version of MuseScore for some reason.
In reply to That was the intent all by Marc Sabatella
For some reason, we don't seem to be communicating. Let me put it this way: what is the reason for the idea of maintaining "100% compatibility" in the first place? To me, it's so that you can work with the same score in different versions of the program. Right? Maybe because you have different installations on different computers depending on where you are, and you're using MuseScore.com in the middle. Maybe for some other reason.
In general, of course you shouldn't expect a new feature to still be available if you revert to an older version of MuseScore. But what we're talking about here is supposed to be almost the same version of MuseScore. That's why it seems to me reasonable to expect that nothing should be lost from a file in either direction.
In reply to For some reason, we don't by Isaac Weiss
I think I understand you, I just disagree with your characterization of the situation. You *can* work on the same score in different versions. This is very much unlike the situation with 1.3 and 2.0.2, or 2.0.2 and 2.1, where it simply will not work - a score created in the newer version quite simply cannot be opened in an older version. With 2.0.2 and 2.0.3, scores *can* be opened in either version.
Now, if you make the choice to use a 2.0.3-only feature, then you have no right to expect that particular feature to still be available in 2.0.2 as well, but assuming you limit your ussage of 2.0.3 to features that were available in 2.0.2, all is well. To me this is compeltely logical and it boggles my mind that anyone would expect otherwise. You are welcome to use both 2.0.2 and 2.0.3, just don't try adding any 2.0.3-specific elements and expect them to actually be visible in 2.0.2. They will simply be ignored, but the score will still open just fine, so everything will be just as it was had you not tried something so silly.
In reply to I think I understand you, I by Marc Sabatella
Okay, now I think I understand you as well, though it's not just that the element doesn't display correctly in 2.0.2—if you save the score with 2.0.2 then and go back to it in 2.0.3, it's actually been messed up into a dotted hairpin (see attached image). So what about this proposition: save people from themselves by making sure there aren't any 2.0.3-specific elements?
The idea of there being such a thing as a 2.0.3-specific element is what boggles my mind. We've had the same elements in 2.0, 2.0.1, and 2.0.2. When we've added new elements like new clefs and system dividers, they've been saved for the 2.1 series. I'm not sure that even needs an explanation—it's just common sense practice. So why is this one new thing so important that it be added into 2.0.3?
EDIT: Attached image.
In reply to Okay, now I think I by Isaac Weiss
As far as I recall, it's not just this one feature. I am pretty sure there were similar discussions reagrding some tab feature or other, maybe also something involving lyrics.
Again, the situation with other elements is entirely different. I am pretty sure that system dividers or new clefs present in a score will prevent it from being openable at all in 2.0.2 - even without the version mismatch check, the program would simply choke on the unrecognized element. Or, in the case of clef, the music might be displayed with the wrong clef, which would be disastrous. Similar story with other new features that are inherently not backwards compatible. The hairpin change happens to be one that 2.0.2 *doesn't* choke on, and in fact behaves very gracefully on. The music is perfectly correct and looks *exactly* as it would have had you not tried the new feature in the first place.
To me, it just seems pontless and mean to deprive thousands of users of a feature they might love just because there is a slight theoretical chance that someone might try to use it and but then lose it because they chose to downgrade and then load a file and save it. Isn't it better to have loved and lost than never to have loved at all? :-).
Put another way: what is the worst case scenario here? As I see it, there is zero downside. If the thing you seem so afraid of happens - which strikes me as pretty unlikely, really - then the worst that happens is people are left with a score that looks *exactly* as it would have had the feature never been added. So how does not adding the feature in the first place improve their lives? Either way, they end up with a score that is 100% correct and looks and works exactly as it would of had they never tried 2.0.3. That's the absolute worst case - someone who does this very unlikely thing is left in the *exact* same state they'd have been in had we chosen not to include the feature. But the best case is, thosuands of users appreciate the new feature and thank us and never even think once about complaining. To me, it seems no contest.
That said, it doesn't actually matter to me. I'm just surprised to hear anyone argue against someone including a new feature when there is essentially no downside to it.
In reply to As far as I recall, it's not by Marc Sabatella
But there is a non-zero downside—the risk of your score suddenly being full of these .
In reply to But there is a non-zero by Isaac Weiss
Ok, that's new information, didn't know about that when we discussed this before. Still, for an unlikely scenario, and a three-click solution (select all similar, change line type back to normal), it still seems worth the very small risk to me. But whatever, like I said, I don't really care that much - I'm just quite surprised by the desire to deprive people of a very useful feature over concerns that seem extremely minor.
In reply to I think I understand you, I by Marc Sabatella
I'm inclined to 'side with' Zack on this one.
When using a version that is labeled '100% compatible' I would expect all info of my score to still be present. Of course I don't expect a feature from 2.0.3 to be available in 2.0.2, but I do expect my 2.0.3 score to be intact after I've opened it with 2.0.2.
If 100% compatible is to be true, then of course 2.0.3 can have new features, but the result of those features in the score should all be existing things from 2.0.2.
How is the end user to know which features from 2.0.3 he/she shouldn't use?
In reply to I'm inclined to 'side with' by jeetee
I personally have no problem with including new features in 2.0.3 that 2.0.2 cannot display (as long as they are handled gracefully, which Marc says they will be). After all, 2.0.3 will be a free download, and there won't be any huge changes to the interface, so there is no excuse for not upgrading. However, I would agree that "100% compatible" implies that nothing will be lost if the score is opened in 2.0.2, and users would be rightfully disappointed if that was not the case.
So I think the real issue here is that "100% compatible" is not the best way to describe it. But this is only a nightly discussion in the Technology Preview Forum, so there's plenty of time to think of a different phrase to use before the official release.
(On a side note, nightly builds of 2.0.3 for Ubuntu are coming soon!)
In reply to I personally have no problem by shoogle
Wow... I didn't expect so much noise about a simple statement. I will edit it in the my post.
The simple fact we replaced a dynamic loaded freetype by an embedded version, the same on all platform might completely blow your score in certain situation (for example if the score is extremely dense and compressed, and no line breaks are used). As Marc said, there are probably a dozen of other feature/bug fixes that could make your score looks different in MuseScore 2.0.2 if you created it in 2.0.3 but nothing as severe as a crash or unability to read the music.
As we don't know when MuseScore 2.1 will be ready (after all it took 5 years from 1.3 to 2.0...), I feel that it makes sense to add the simplest new features in MuseScore 2.0.3 even if it means we are not 100% compatible by some users standard.
So no, we won't remove these commits.
In reply to Wow... I didn't expect so by [DELETED] 5
Fair enough, if that's the intent. Thanks. ;-)
I would like testing 2.1 version. PPA has automatically downgraded my installed one. In time, the 2.1 version has worked fine but the 2.0.3 has no sound at all. (My OS is Xubuntu 15.10)
In reply to I would like testing 2.1 by mtuliosax
I was missing the new tab features, that are missing in 2.0.3, so I 'downgraded' again.
I found the last nightly *.deb under /var/cache/apt/archives - I copied the last version before the new 2.0.3 nightly and installed it with "sudo dpkg -i musescore*.deb", from the directory I had copied it (linuxmint/ubuntu 14.04).
In reply to I would like testing 2.1 by mtuliosax
Be sure your soundfont folder preference makes sense - see Edit / Preferences / Soundfonts and make sure it points to a locationw ith a valid soundfont. Having multiple versions of MuseScore installed and switching between them might get you into a state where one version of MuseScore looks for a soundfont somewhere that doesn't exist.
In reply to I would like testing 2.1 by mtuliosax
@mtuliosax, @MLutz
Now that 2.0.3 has been released the Nightly PPA for Ubuntu is back to building the "master" branch again.
Wow, I didn't realised the nightlies actually got used... ;) You guys kind of stole my thunder, but...
2.0.3 nightlies now available for Ubuntu!
You just need to add this PPA to your list of sources, like this:
If enough people want it I could probably do parallel builds from both branches. That said, they aren't really for regular use. I hope you guys realise that any scores you save with a 2.1 nightly build won't work with 2.0.x and they might not even work with 2.1 when it gets released. But I guess you don't have much choice if the feature you need isn't in 2.0.3.
The nightlies use a different namespace to the normal MuseScore builds so there shouldn't be any conflicts there, but there could be conflicts between one nightly and the next, especially after a 0.1 version change. Any problems and you can safely do a factory reset
`$ mscore-nightly -F`without affecting the standard version.From now on the packages will be named like this:
And when I go back to the master (currently 2.1) branch:
You can see what the latest packages are here. You could probably write a script to alert you when the change happens, but obviously it is likely to happen immediately after the release of 2.0.3.
In reply to Wow, I didn't realised the by shoogle
Thank you very much for contributing the nightlies for Ubuntu!
If I still want to use the 2.1-nightly (because of features, that aren't in the 2.0.3 - the better possiblities for lute notation are very important for me), it probably isn't senseful to update, as there is no master-nightly at the moment, isn't it?
In reply to Thank you very much for by MLutz
That's right. If you want to make sure that you have the last 2.1 nightly before the switch, and you want to ensure that it doesn't automatically update to the newer 2.0.3 package, you should be able to do it like this:
Replace XX.YY in ubuntuXX.YY.1 with your Ubuntu release, e.g. 14.04 for Trusty.
Once 2.0.3 gets officially released, start checking the packages at the bottom of this page. Once they say "master" instead of "2.0.3" you can repeat the instructions to install the nightlies and that will re-enable updates.
Edit: For the sake of clarity, the instructions you will need to repeat to re-enable updates later on are the instructions on the nightly builds page, not the instructions in this post.
In reply to That's right. If you want to by shoogle
Hi! Unfortunately I have already installed version 2.0.3. Any chance for getting back 2.1 version?
sudo apt-get install musescore-nightly=201601051050+REVISION.d08e14c~ubuntu15.10.1
Lendo listas de pacotes... Pronto
Construindo árvore de dependências
Lendo informação de estado... Pronto
E: Versão '201601051050+REVISION.d08e14c~ubuntu15.10.1' para 'musescore-nightly' não foi encontrada
Thanks
In reply to Hi! Unfortunately I have by mtuliosax
It seems that lauchpad removes old packages from the PPA immediately after a new version appears (I thought they would still be there until the PPA ran out of room). However, the old versions are still available, just not via apt-get. You can try MLutz's method to install it manually.
Simply go to this page, and look for the packages with REVISION.d08e14c in the version name (hit Ctrl+F and type "d08e14c"). You might have to click the Next/Previous buttons to go to the next page if there have been enough new builds in the meantime.
Once you find the packages (there are 6) pick the ONE that matches your Ubuntu flavour and system, either 32 bit (i386) or 64 bit (amd64). If you don't know it, type "arch" in a terminal to find out whether your system is 32-bit (result is “i686”) or 64-bit (result is “x86_64”). Download the package to your computer and then double-click on it to open it in Ubuntu Software Centre and install it.
Having been very busy with my new business, I missed this announcement all together !
Since MusicXml export is a key feature for me, I would like to be able to see which MusicXml bug fixes are being integrated into v2.0.3
However, when I look at the issue tracker, there does not seem to be a filter which will let me see this.
Have I missed something ?
Is there a page elsewhere which holds this information ?
In reply to Having been very busy with my by Simon Giddings
I don't know of one single easy way to get a full list (although there may well be one). but it's easy enough to tell if any specific bug is fixed or feature implemented for 2.0.3 - visit the issue in the tracker, scroll down to the end, see if you see a message indicating it is fixed in 2.0.3.
In reply to I don't know of one single by Marc Sabatella
Thanks Marc. I put v2.0.3 as a search term and the result was good for me.
However, is there a way to request the inclusion of an issue in v2.0.3 ?
In reply to Thanks Marc. I put v2.0.3 as by Simon Giddings
Commenting in the issue itself seems the most straightforward to put the request somewhere we can track it.
In reply to Commenting in the issue by Marc Sabatella
Would it be appropriate to reopen the issue in that case? Otherwise, it would not show up in the issue tracker.
In reply to Thanks Marc. I put v2.0.3 as by Simon Giddings
I believe all issues are considered for 2.0.3, and the sole factor that determines if they are included is whether or not they break things for 2.0.0 - 2.0.2 users. There's basically one developer that approves code contributions for the master branch, and the same guy is responsible for the 2.0.3 branch too, so he's unlikely to have missed anything.
In general I don't think you'll get very far by asking for specific things to be included, but there are a few borderline cases where you might have some luck. E.g. if there's a risk something small might break but the benefit is considered to outweigh the negatives.
In reply to I believe all issues are by shoogle
Nothing to add, except that I'm happy to integrate anything safe in 2.0.3 if a pull request exists. So if you do want to see something integrated in 2.0.3, the easiest way is to do the coding work or contract someone to do so and make a PR. Requesting an issue to be fixed will not fixed it unfortunately.
Also when MuseScore 2.0.3 will be released, we will make sure to publish a list of fixed issues (basically by going through the git log)
Wouldn't it be possible to include also the current additions for historical lute? I worked quite much with it and it is quite stable, though some things still should be improved.
In reply to Wouldn't it be possible to by MLutz
Unfortunately no. That would add elements that MuseScore 2.0.1 and MuseScore 2.0.2 would completely ignore or it could even crash. It will have to wait for a major release. Same answer for most of the features listed here https://musescore.org/en/node/85301
In reply to Unfortunately no. That would by [DELETED] 5
OK - thanks for this very clear answer.
So I hope that on 2.0.3 the above mentioned major release will follow.
Are there any plans when 2.0.3 will be released?
In reply to Are there any plans when by drowo
Just the usual: "when it's ready".
In reply to Just the usual: "when it's by Marc Sabatella
OK, I deserved that ;-)
I realized that no commit has been made on the 2.0.3 branch since February 26th. This could be interpreted as "no new bugs found", which could be interpreted as "pretty stable". So I reformulate my question: what ist the criterion for "ready"? No bugs found for 1 month or something similar?
In reply to OK, I deserved that ;-) I by drowo
Well, a better way to track what bugs are found and fixed is the Issue Tracker. Bugs are still being found and fixed; sometimes other things get in the way of spending time testing and merging the fixes. In this case, I suspect Google Summer of Code has been taking a lot attention away from 2.0.3
In reply to OK, I deserved that ;-) I by drowo
Bugs have indeed been found, they just haven't been fixed immediately. Here's Marc's own list of the most important, and as you can see, many are still active: https://musescore.org/en/issue-hit-list-marc-sabatella#Crashes-and-Corr…
In reply to Bugs have indeed been found, by Isaac Weiss
Oops .... that look pretty far from stable. Thanks anyway for the hints.
In reply to Oops .... that look pretty by drowo
It's unlikely that those will all be fixed for 2.0.3. Many of them only occur in rare circumstances and don't lead to anything too bad anyway. It's already perfectly usable as it is really, but as always you should keep backups and save regularly! At this point its just a case of finding the balance between an early release and a release that is actually worth having.
In reply to It's unlikely that those will by shoogle
OK I understand. Well I experience a crash now and then with 2.0.2 as well, however I never lost work worth more than a couple of minutes due to my saving paranoia ;-)
Maybe one or the other is fixed already, so I will go for the nightly 2.0.3.
In reply to Bugs have indeed been found, by Isaac Weiss
FWIW, most of what is on that list is an issue in 2.0.2; the ones that are crossed out are already fixed for 2.0.3. Also, the ones highlighted in yellow or light green have a fix pending that is still being tested. And as mentioned, many of the ones left are pretty obscure corner cases.
So you should be seeing that list as showing 2.0.3 is considerably *more* stable than 2.0.3 - dozens of potential crashes or corruptions are fixed. I don't think there is any fixed set of criteria for deciding when it's "ready", but you should know that it is practically a given in the software world that there will be known bugs in software when released - it's a question of managing how many and how bad. If people literally waited until there were no known issues, nothing would ever be released.
In this context I wanted to ask, if it wouldn't be possible to have the master-nightly (2.1) and the current nightly (2.0.3) parallel on the computer. As I use the baroque lute tablature, I have to use the master-nightly, but anyway I would also use the current nightly for testing, if that would not be too complicated.
I use an ubuntu system (14.4), more precise: linuxmint.
In reply to In this context I wanted to by MLutz
Obviously you want to be using 2.0.2 for regular stuff right now, but if there are features that are only in the nightlies then one way would be to get the 2.0.3 nightly from the PPA and use a master nightly AppImage. Nightlies shouldn't conflict with stable releases but be aware that a 2.0.3 nightly may conflict with a master nightly (they share preferences files), so a better way would be to create a second user account on your Ubuntu machine and use a master AppImage in user account and a 2.0.3 AppImage in the other.
In reply to Obviously you want to be by shoogle
I see - so master nightlies could be the way to go.
BTW, do I at all need the 2.0.3 nightly at all, if I want to use the 2.1 nightly? It seems as if normally all bugs also are fixed in the master nightly, isn't it?
In reply to I see - so master nightlies by MLutz
Yes, all bugs and features are fixed in master and only then do they get added to 2.0.3, and only if they don't break compatibility with 2.0.2. So if the features you need are only in master then there is no reason for you to have the 2.0.3 nightly. The best thing to do is to remove the 2.0.3 nightly and download the master nightly AppImage. Just download the file, give it execute permission, and reset the preference files that the 2.0.3 nightly will have left behind:
Once this has been done you can simply double-click on it to run it.
In reply to Yes, all bugs and features by shoogle
Thank you for these clarifications!
On one of my computers I already have installed the AppImage - it works quite fine.
Here I also don't have the problems with dialogues that can be hidden behind a window as under linuxmint - unfortunately I didn't find my message on that now.
But it seems as if this AppImage relies on wine, isn't it?
In reply to Thank you for these by MLutz
Glad to hear it's working for you! The dialogue issue was probably a bug in Qt rather than MuseScore. The AppImage bundles the latest version of Qt so that's probably why the issue is gone.
The AppImages do not rely on Wine at all - they are built on Linux, for Linux! AppImages are just containers (a bit like a zip archive) that contains all of the executables, icons and dependencies needed to run the program. These files are simply copied from an installation on a clean Linux system and packed into the AppImage in exactly the same way as DEB and RPM packages do, except you don't need to extract the AppImage to use the program inside. However, the format AppImages use is ISO 9660, which was originally designed for storing information on a CD-ROM and as such was often used on Windows way back in ancient times when programs were still distributed on CDs. If you have Wine on your system it is possible that it will detect the AppImage and assume that, because it is ISO 9660 it must be a Windows binary.
I don't have Wine on my system, so if I double-click a fresh AppImage I get the message 'Could not display “MuseScore*.AppImage”. Do you want to search for an application to open this file?', but once I give execute permission double-clicking on it actually runs it and MuseScore starts up. What happens on your system with Wine installed?
In reply to Glad to hear it's working for by shoogle
That's true, I'm also using the Linux version. But it seems as if it needs and uses silverlight (pipelight), which relies on wine. See the output of the terminal ;-):
markus@Amtszimmer:~$ Apps/MuseScore*AppImageinitScoreFonts 0x40476c0
QObject::connect: Cannot connect (null)::stateChanged(QNetworkSession::State) to QNetworkReplyHttpImpl::_q_networkSessionStateChanged(QNetworkSession::State)
QObject::connect: Cannot connect (null)::stateChanged(QNetworkSession::State) to QNetworkReplyHttpImpl::_q_networkSessionStateChanged(QNetworkSession::State)
QObject::connect: Cannot connect (null)::stateChanged(QNetworkSession::State) to QNetworkReplyHttpImpl::_q_networkSessionStateChanged(QNetworkSession::State)
QObject::connect: Cannot connect (null)::stateChanged(QNetworkSession::State) to QNetworkReplyHttpImpl::_q_networkSessionStateChanged(QNetworkSession::State)
QObject::connect: Cannot connect (null)::stateChanged(QNetworkSession::State) to QNetworkReplyHttpImpl::_q_networkSessionStateChanged(QNetworkSession::State)
QObject::connect: Cannot connect (null)::stateChanged(QNetworkSession::State) to QNetworkReplyHttpImpl::_q_networkSessionStateChanged(QNetworkSession::State)
[PIPELIGHT:LIN:unknown] attached to process.
[PIPELIGHT:LIN:unknown] checking environment variable PIPELIGHT_SILVERLIGHT5_1_CONFIG.
[PIPELIGHT:LIN:unknown] searching for config file pipelight-silverlight5.1.
[PIPELIGHT:LIN:unknown] trying to load config file from '/home/markus/.config/pipelight-silverlight5.1'.
[PIPELIGHT:LIN:unknown] trying to load config file from '/etc/pipelight-silverlight5.1'.
[PIPELIGHT:LIN:unknown] trying to load config file from '/usr/share/pipelight/configs/pipelight-silverlight5.1'.
[PIPELIGHT:LIN:unknown] sandbox not found or not installed!
[PIPELIGHT:LIN:silverlight5.1] using wine prefix directory /home/markus/.wine-pipelight.
[PIPELIGHT:LIN:silverlight5.1] checking plugin installation - this might take some time.
[install-dependency] wine-silverlight5.1-installer is already installed in '/home/markus/.wine-pipelight'.
[install-dependency] wine-mpg2splt-installer is already installed in '/home/markus/.wine-pipelight'.
fixme:winediag:start_process Wine Staging 1.7.51 is a testing version containing experimental patches.
fixme:winediag:start_process Please report bugs at http://bugs.wine-staging.com (instead of winehq.org).
wine: cannot find L"C:\\windows\\system32\\winemenubuilder.exe"
err:wineboot:ProcessRunKeys Error running cmd L"C:\\windows\\system32\\winemenubuilder.exe -a -r" (2)
In reply to That's true, I'm also using by MLutz
Well MuseScore itself doesn't use Pipelight, Silverlight or Wine, but it does use Qt's network component (QNetwork) for the web view in the Start Centre (and nothing else as far as I'm aware). I don't know how QNetwork operates (after all, that's the point of a library) but perhaps it checks the system for available network services and, on your system, Pipelight advertises itself as an available service. It would be interesting to know whether you get the same messages with the distribution package of 2.0.2, and whether the messages disappear when you run with the "-w" option to disable the web component.
Try these:
Which of those gives you messages about Wine and/or Pipelight?
In reply to Well MuseScore itself doesn't by shoogle
It seems as if all versions, AppImage and mscore use pipelight (wine) as soon as the start-center is used, no matter if I use -w or not!
So probably the web component is started always by it, isn't it?
In reply to It seems as if all versions, by MLutz
On my system I don't get any QNetwork messages printed on the console if I use "-w", and there is no web view in the Start Centre (see pics). Does "-w" have no effect for you, or does it work like mine but you still get Pipelight messages?
In reply to On my system I don't get any by shoogle
This is very interesting: On my laptop I don't have pipelight installed - then it looks like your messages. On other computer with pipelight, it seems as if it is started in both cases ...
But I will look at it again tommorrow.
In reply to Obviously you want to be by shoogle
Currently it seems as if the nightly AppImages are not available. At least I tried do download the latest ones and always get a file with 10 bytes "Forbidden" ...
How can I get the files? Do I need to login to bintray or is there another problem?
In reply to Currently it seems as if the by MLutz
We are over quota at bintray. We are working on it.
In reply to Currently it seems as if the by MLutz
Yes, it's annoying. Their pricing page says that there is no quota for open source projects, but then they emailed to say that we were using too much space anyway. I think it's the fact that we are using the space for nightlies rather than release builds that bothers them, which is fair enough I suppose, but they could have given a bit more warning before disabling the account.
In reply to Yes, it's annoying. Their by shoogle
I hope you soon find a good solution!
In reply to I hope you soon find a good by MLutz
The AppImage nightlies are working again. I made a script to deletes any that are more than a week old each time a new one is uploaded. Some old ones will be kept longer than a week for archival purposes.