View Single Post
Posts: 1,335 | Thanked: 3,931 times | Joined on Jul 2010 @ Brittany, France
#350
Originally Posted by llelectronics View Post
Mimer since its newest version calls actually harbour-webcat --set-default when it detects harbour-webcat being chosen.

So harbour-webcat --set-default should work just fine in setting the correct default browser.
The terminal output however shows Setting as default first and then comes the usual warnings that you get apparently when loading qml stuff from c++ in SailfishOS nowadays.

And then it exits.

I tested on Jolla, Jolla C, Jolla Tablet and my Xperia X aswell as the Moto X2 port and it is working fine there.
I even tested it on my Gemini PDA right now and it is working there fine from Mimer.
I had taken a screenshot of the terminal output to show you because it looked like an error and not a simple warning, but after I reinstalled some packages and uninstalled/reinstalled QtWebkit 5.212, it seems to have finally worked correctly. I am not sure what fixed it, probably not QtWebkit, and I haven't even launched Mimer again to start over the procedure. But at least it is working as it should now. Before that, Webcat would be opened from *some* links but some others would still trigger Sailfish Browser, and in any case it would just focus the application but not open new tabs unless the application was closed.

That sounds like a broken dbus service.
The way how it works is that the default browser is set to a dbus service that either calls the openUrl function of the already running browser or when the browser is not running execute a command to start it.
This should work just fine when harbour-webcat --set-default does its magic of setting the default browser (actually copying over the dbus service file and using it as default).
I found maybe a bug in mimer which might set the webbrowser after harbour-webcat --set-default is running which might lead to an issue.
So maybe you need to manually run harbour-webcat --set-default after setting it as default in mimer.
I will take a look at that when I have more time dealing with it.
Same here, Webcat now opens new tabs as it should. This totally changes the experience and I'm glad I finally got it working, although I have no idea what I did. Before my previous post, I already had refreshed the repository and re-installed every single package on my Jolla, so it's puzzling.


You can swap it.
Last time upgrading worked fine. But I cannot guarantee it.
Great, thanks! Then the warning in the description might be a bit confusing now.

I could not upgrade to 2.2.0.29 the last time with QtWebkit 5.212, but I was several Sailfish versions behind.

Maybe it was a split second the sensors told it to be in landscape and it started loading landscape UI and then switched to portrait which took a second as it was loading all the components it needs in the background
Maybe, but then the layout was persisting even after minimizing/refocusing the application. But I can't tell if I changed between landscape and portrait between those manipulations to refresh the sensors. Next time it happens, you'll get a screenshot here and I will try to check if the phone was displaying the landscape UI in the first place.

I had that and removed it and no one cared :P
Tripple click is confusing as hell from a user perspective.
I am currently out of ideas when it comes to how this can be implemented in any sane way currently without feeling awkward.

Honestly I don't see an issue with the two clicks that we have right now.
Now you have at least two people who care in the last few messages here. The problem is opening the tab UI takes some time, there is an animation since the layout is reorganized, you need two hands or big gestures since you need to tap on the left and then on the right, and doing that repeatedly can get old when managing multiple tabs. But it's true that triple tap would probably be very confusing, and often end up in unintentional closes, which is even worse. Long press was my first idea since it is not used for anything else in the UI. Maybe it could be a long press that spawns an icon just above the tab icon, and the user has to swipe is finger (still holding it down) to that new icon to confirm closing, a bit like the pulley system? This would surely prevent unintentional closes.

Of course, it is not vital, but I'm sure I wouldn't be the only one to use that if it was there. Then I am not a coder and I have absolutely no idea how much work that would be, or if it would be worth the effort.

Last edited by Kabouik; 2018-07-14 at 12:51.
 

The Following 2 Users Say Thank You to Kabouik For This Useful Post: