Cross-Browser, Cross-Device Universality ... dream or reality?

[Josiah]

Ciao

TiddlyWiki can be opened in any browser on any device running any platform that supports JavaScript.

However it can't currently be saved in a consistent way across them.

And on mobile devices its look is often messy.

I'm wondering if there is a UNIVERSAL solution to this?

Like combining Riz's mobile theme (that looks excellent on all devices I've looked at it---AND for normal screens too ... Looks good as the default) ....

   ... with Daniello's saving mechanism (using pouchDB) that functions well over several platforms?

In any case I guess I'm making a point that for the broader user-base the more Universal and consistent the behaviour of the starting TiddlyWiki you download is the better.

Best wishes
Josiah

[Jeremy Ruston]

Hi Josiah

There is already a near-universal solution to saving changes within the browser: the built-in HTML5-compatible “download saver”. It works on practically all desktop browsers, and many mobile browsers. However, the user experience is poor, and there is scope for human error.

Apart from the universal, fallback saver, we’ve got more specialised savers that work in specific environments. For example, the saver for TiddlySpot, or TiddlyFox, or the one that works with Windows HTA files.

So, I’m not sure what you’re asking. I don’t think that the HTML5 standard contains any overlooked mechanisms that can allow TiddlyWiki saves changes. I am not aware of any non-standardised browser features that help us, either.

Finally, you mention PouchDB. Again, as we’ve discussed before, there’s nothing magical going on there. Data is saved to one of several HTML5 local storage mechanisms. TiddlyWiki5 could use those mechanisms to save changes, but it’s scarcely a replacement for the standard saving mechanism because ones data remains locked up within the browser, and can’t easily be transported elsewhere.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/7c1f1786-bda7-4fd3-af70-d1361994448f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Riz]

Hi Jeremy,

Pardon my ignorance, but is it possible to synchronise tiddlywiki data (when running in html format) to a database outside the browser?

[Jeremy Ruston]

Hi Riz

Pardon my ignorance, but is it possible to synchronise tiddlywiki data (when running in html format) to a database outside the browser?

Sadly, most browsers now prevent network access by HTML files running in the browser via a file:// URI, so the general answer is now “no”.

It’s not entirely hopeless. Desktop Chrome, for example, has a switch to let users relax that restriction:

http://www.chrome-allow-file-access-from-file.com/

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/01377db9-1ef2-498d-b104-fc40abbaca11%40googlegroups.com.

[Josiah]

Ciao Jeremy

I get your points. I come out in a slightly different place.

On FILE SAVING my point is that the save is not re-entrant under normal conditions. That is my understanding. You can save but you then have to open the thing in a new instance? Have I understood correctly?

Part of what I am getting at, I think, is naive users when coming across TW can get befuddled when its not re-entrant. I myself have frequently got confused using it in Opera. Save. Open. Which tab is which? You get the idea?

PouchDB we discussed, yes. I just think its a neat example that works pretty damn well. I agree its not really a universal portable solution.

I think my broad question is still valid. Of course I'm very much focused on people like me who like TiddlyWiki but find the saving aspect of it odd. I'm sure I'm not alone. Really I want it as always re-entrant software behaves.

Best wishes
Josiah

[Mark S.]

I have the same problem with Riz's theme as I do the standard theme, at least under the Mobile firefox. When I zoom in on text the text "grows" off the edge of the screen. So I would have to tinker with all the settings in the themes to make the text larger when on a mobile device, and then have to tinker with them again when back on the desktop.

What's needed is a quick switch that would allow a whole set of font-size and width settings to be changed at once without having to go back to the theme page and type in memorized values.

Under antidwiki, the zooming works like a regular android app. But antidwiki will only allow one particular directory for its files which is unfortunately on the main card where space is scarce.

Mark

[Jeremy Ruston]

Hi Josiah

On FILE SAVING my point is that the save is not re-entrant under normal conditions. That is my understanding. You can save but you then have to open the thing in a new

instance? Have I understood correctly?

That's exactly what I meant about the confusing user experience, and potential for human error.

Part of what I am getting at, I think, is naive users when coming across TW can get befuddled when its not re-entrant. I myself have frequently got confused using it in Opera. Save. Open. Which tab is which? You get the idea?

Yes, I think you're saying that the default fallback saver is confusing for users. That's true, but it's the best we've got.

PouchDB we discussed, yes. I just think its a neat example that works pretty damn well. I agree its not really a universal portable solution.

It works OK for demos and temporary caching before syncing to a server. But it wouldn't be suitable for, say, writing a novel: would you really want weeks of work locked up in a browser where it can be arbitrarily deleted at will by the browser? Local storage is designed for caching, and present implementations are not robust for other usages.

I think my broad question is still valid. Of course I'm very much focused on people like me who like TiddlyWiki but find the saving aspect of it odd. I'm sure I'm not alone. Really I want it as always re-entrant software behaves.

What is the question are you asking?

We've established that we have a near-universal saving technique with usability issues, and more specialised techniques that don't have the usability issues. I am sure we'd all love a universal technique that doesn't have the usability issues, but sadly it doesn't exist.

Best wishes

Jeremy.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/3a7d3f4c-c8a1-428a-b969-b458257b66e5%40googlegroups.com.

[Josiah]

Hopefully Riz will want to look at this issue. He's been very responsive to other queries.

[Josiah]

Ciao Jeremy

Jeremy > What is the question are you asking?

> We've established that we have a near-universal saving technique with usability issues, and more specialised techniques that don't have the usability issues. I am sure we'd all love a universal technique that doesn't have the usability issues, but sadly it doesn't exist.

Perhaps a forlorn one. Perhaps not.

You are using "universal" in a way I am not quite. I focusing mainly on first experience. Someone who does NOT understand, or stumbles at the relation between the HTML5 universalish save and what happens next. So my point is in the spot of "sadly it doesn't exist." I'm thinking about the best approximations to what does exist and wondering it can be implemented wider. Something like that.

For instance a TiddlyFox for every browser. Not wanting to create work so much as noting TiddlyWiki's reach & uptake is, I believe, currently hampered by how browsers work.

Best wishes
Josiah

[Jeremy Ruston]

Hi Josiah

You are using "universal" in a way I am not quite.

I’m using it to mean a technique that works with all browser configurations.

I focusing mainly on first experience. Someone who does NOT understand, or stumbles at the relation between the HTML5 universalish save and what happens next.

Do you mean that you are concerned with users who do not understand the mechanism by which saving happens?

I don’t think that changes anything. Those users are best served by the user experience of something like TiddlyFox, not by the HTML5 fallback saver. Because, as established, the fallback saver has a poor user experience for users who don’t understand what’s going on.

So my point is in the spot of "sadly it doesn't exist." I'm thinking about the best approximations to what does exist and wondering it can be implemented wider. Something like that. 

For instance a TiddlyFox for every browser. Not wanting to create work so much as noting TiddlyWiki's reach & uptake is, I believe, currently hampered by how browsers work.

None of the other browsers allow JavaScript extensions direct and full access to the filesystem. Some browsers (like Chrome) provide access to a sandboxed filesystem (I believe that is how TiddlyChrome works), but they don’t generally allow access to arbitrary files.

Anyhow, if your concern is primarily beginners then I suspect that very often the entire concept of working with an offline file is alien for them. I think that most of the time, those users are best served with an online TiddlyWiki configuration. That’s the configuration that minimises the new things that users need to learn in order to use TiddlyWiki, because it behaves like any other online service.

Fundamentally, to use TiddlyWiki locally, users must become their own sysadmin. They have sole responsibility for managing and protecting their data. That responsibility requires a level of understanding and awareness. That’s a small price for those of us that value the ability to work offline, but erects a fundamental barrier for beginners who don’t have the inclination to learn.

Best wishes

Jeremy

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/665c8443-dc3e-4c7e-a49e-5452788b2a3d%40googlegroups.com.

[Riz]

On Wednesday, 16 November 2016 00:27:15 UTC+5:30, Mark S. wrote:

I have the same problem with Riz's theme as I do the standard theme, at least under the Mobile firefox. When I zoom in on text the text "grows" off the edge of the screen. So I would have to tinker with all the settings in the themes to make the text larger when on a mobile device, and then have to tinker with them again when back on the desktop.

What's needed is a quick switch that would allow a whole set of font-size and width settings to be changed at once without having to go back to the theme page and type in memorized values.

Under antidwiki, the zooming works like a regular android app. But antidwiki will only allow one particular directory for its files which is unfortunately on the main card where space is scarce.

Mark

Hi Mark.

I do not want to hijack this post. So I would keep the response to this single post. Do feel free to post to the ghostwriter thread with further inputs.

Hmmm, did you mean a text-reflow on pinch to zoom? Can you suggest a setting where you have it working? Coz the only android mobile I have fails to do that in chrome, firefox and andtidwiki on sites like wikipedia, sciencedaily and google search. A quick googling tells me that there are firefox addons to achieve that albeit imperfectly, and there are drafts of some CSS properties under consideration to achieve it.

A simple workaround I can do is a setting in the ghostwriter tab where you can specify a font-size you would prefer on mobile screens once, and it will switch to that font size automatically thereafter whenever you switch to mobile. Will that do for you?

[Josiah]

Ciao Jeremy

I push this just a little bit more. I hope it will get a bit clearer where I am coming from.

By "universal" I was meaning consistent behaviour by TW on saving & appearance across browsers, screen sizes & devices. Not so much the "universal" as in the common fall-back behaviour in browsers.

What I am getting may be clearer if I lay out a concrete scenario... 

(1) To create several hundred TWs of novels.
(2) With a consistent interface that renders well over multiple device types.
(3) That has a consistent, standard, way of saving.

I have this in mind doing this next year. I have held off till now because (2) was not satisfied. Its getting closer, thanks to Riz.

(3) Remains an issue.

Whilst I understand there are things I don't grasp about browser limits, I'm still finding it hard to grasp this ...

... why on earth its SO difficult to get a browser to stop saving (downloading) TW as TW, TW(1), TW(2) etc, rather than being nudged to overwrite TW as TW.

Best wishes
Josiah

[PMario]

On Saturday, November 19, 2016 at 10:38:26 PM UTC+1, Josiah wrote:

(3) Remains an issue.

Whilst I understand there are things I don't grasp about browser limits, I'm still finding it hard to grasp this ...

... why on earth its SO difficult to get a browser to stop saving (downloading) TW as TW, TW(1), TW(2) etc, rather than being nudged to overwrite TW as TW.

There are only 3 things that are essential for browsers.

 1) security
 2) security.
 3) security!

Most browser vendors consider an "active" write from a web page to the harddisk as a security risk.
Most vendors consider an active write from an file:// URI as a security risk too!

So they don't let us do this. period.

------- more detailed info ------------

A browser basically is a sandbox, that lets us (the users) execute untrusted code, from potentially evil sites, on our private computers, with a lot of private stuff on it.
In favour of security, it is essential, that browsers don't allow javscript programs full access to the PC resources. I think, that's a good thing. right?


That's why browser vendors limit the access to the users harddisk in different ways. Depending on the browser vendor, those methods are completely different.

eg:

WebKit based browsers like Chrome, Safari, Opera and others don't allow javascript to actively write anything to the harddisk at all! It's forbidden! They don't let us do this! They provide us the "passive" file download feature instead :/

Gecko based browsers like FireFox and its cousins, let javascript actively write to the hardisk, if "signed" AddOns are involved. The signing and review mechanism should protect users from evil software.

Chakra based browsers like IE10 allow AddOns to actively write to the disk. The HTA file extension is treated as a trusted application, that allows an hta app file access out of the box.

EdgeHTML based browser like MS Edge try hard to be WebKit compatible. I don't know the details about MS Edge web extensions. ... So not much info here. ... Just NO active write, if WebKit compatibility is true!


An "active write" works like this:

 - a javascript program says to the browser: "Hey browser, I want to save some content to the disk."
   - "Give me a container, where I can write to"
 - The browser does as requested and offers a file-handler. (after the user explicitly allowed the AddOn to do so)
 - The program writes a new file to the harddisk.
   - If the file exists, it's overwritten. 


A "passive" write / download works like this:

 1 a javascript program tells the browser, there is a file at location xxx with the name yyy.html,
    - please download it.
 2 The browser sends a request to the server: "Hey server send me file yyy.html"
 3 The server does this and
 4 the browser saves it as file: yyy.html
 5 If the user requests the same file-name again, the browser wants to be helpful and it doesn't overwrite the file
    - instead it saves the new file as yyy(1).html, because it could be a different file with the same name.

With some js magic its possible to do step 2,3,4 without the need of a server. So a javscript program like TW can use the "passive" download mechanism.

I hope you can see, these 2 file saving mechanisms are completely different!

-------------

So the reason why we can't just overwrite tw.html is: Many browser vendors just don't allow active file saving, initiated by a javascript app!
Even if we go like this, imo it won't happen ;)

------------

The full truth is: Also FireFox will make it harder or even impossible to use TiddlyFox in the future. IMO both security and performance wise. TiddlyFox type of plugins are incompatible with the new Webkit like WebExtensions.

See paragraph 4.

Before WebExtensions, you could develop Firefox add-ons using one of three different systems: XUL/XPCOM overlays, bootstrapped extensions, or the Add-on SDK. In the future, WebExtensions will be the recommended way to develop Firefox add-ons, and other systems will be deprecated.

More research needs to be done!

I hope I could shed some more light on the topic.

have fun!
mario

[Riz]

Hi PMario and others in the group,


So, I have been using this plugin from chrome store: Downloads Overwrite Existing files successfully for some time now. The limitation is: It allows you to write only to downloads folder. I tried to shortcut this using another plugin from chrome store: Downloads Router, which allows you to save a file that you are ownloading automatically sorted to folders based on conditions like where you download it from, filename or extension. Problem is, it doesn't play nice with the first plugin.

My question is, will it be possible to combine these to with TW in mind? The first one has a single line of code that goes like

chrome.downloads.onDeterminingFilename.addListener(function(item, suggest) {
  suggest({filename: item.filename, conflictAction: 'overwrite'});
});

and the second one is more like 20-30.

I have no idea on the underlying complexities and all, but if someone can pull it out, it can act as a temporary solution to tide over the oncoming death of tiddlychrome.

[PMario]

Hi Riz,
Thx for sharing. Did you find development info too?
Since FireFox also adopts WebExtensions standard, it may also be the right way for FF... maybe :)
-m

[Riz]

Did you find development info too?

I do not know what that is or where to find it. May be someone more familiar with the chrome architecture will drop in, combine the two and magically solve our issues for us.

[Josiah]

Ciao Mario

  > So they don't let us do this. period.

Thank you for the very detailed response on file saving. Its enlightening. It also makes me mildly depressed.

Given that I'd like to create a few hundred TW's of novels with an ability to save (in one STANDARD way or another) do you have thoughts about how to do that as things stand?

I don't really care whether its via offline filesave, internal browser storage (pouchDB et al), or on-line cloud. Just so long as its ONE method that works across browsers. I'm wishing for a universal first user solution, and still hoping it exists.

Best wishes
Josiah

[Ákos Szederjei]

Hello everyone!

What about Qupzilla (https://www.qupzilla.com/)? It uses QT web-engine.
Is it possible to have a TW plug-in there? Not that I could write it,
unfortunately. :(

Ákos

> WebKit <https://en.wikipedia.org/wiki/WebKit>based browsers like
> Chrome, Safari, Opera and others *don't* allow javascript to
> *actively *write anything to the harddisk at all! It's forbidden!

> They don't let us do this! They provide us the "passive" file
> download feature instead :/
>

> Gecko <https://en.wikipedia.org/wiki/Gecko_(software)>based browsers

> like FireFox and its cousins, let javascript actively write to the
> hardisk, if "signed

> <https://wiki.mozilla.org/Add-ons/Extension_Signing>" AddOns are

> involved. The signing and review mechanism should protect users from
> evil software.
>

> Chakra <https://en.wikipedia.org/wiki/Chakra_(JScript_engine)>based

> browsers like IE10 allow AddOns

> <https://en.wikipedia.org/wiki/Chakra_(JScript_engine)> to actively

> write to the disk. The HTA file extension

> <https://en.wikipedia.org/wiki/HTML_Application> is treated as a

> trusted application, that allows an hta app file access out of the box.
>
> EdgeHTML

> <https://en.wikipedia.org/wiki/Microsoft_Edge#EdgeHTML>based browser

> like MS Edge try hard to be WebKit compatible. I don't know the
> details about MS Edge web extensions

> <https://en.wikipedia.org/wiki/Microsoft_Edge>. ... So not much info