Quinoid v0.0.6alpha

[Mark S.]

Two new mechanisms for refresh (see Readme.md). Installing the available JSON should allow standard refresh to work for maximum convenience.  Backing out of Q. should completely close out activity. Added some GEO permissions to see if that allows basic geo-functionality. User will be blocked from browsing if no files chosen for blocking.

Additional suggestions re GDrive in the Readme.md. As always, be careful and treat with caution. Be sure to backup regularly.

-- Mark

[Mohammad]

Hi Mark,

Updated to 0.0.6alpha

Works great! The wiki on GDrive and local folder both work

favicon works

Android 9.

Note: I use the system explorer.

--Mohammad

[Watt]

https://github.com/Marxsal/Quinoid01/releases/tag/v0.0.6alpha

.apk is to be found under Assets

[Watt]

Installs ok and functionality of v0.0.5 still working but new features not working for me this time.

Refresh: imported the Refresh-for-Quinoid.json. Exited quinoid, restarted, refresh not doing anything. The tiddler containing the script is displaying the script in italics minus the first <script> tag. Tried deleting the comment, no change. Not very refreshing news, sorry.

Geo: Didn't ask for location permissions, had to go to settings and allow them. I've got some geo points previously created using the leaflet plugin and geoloc macro and those points create maps as they did previously in a browser. Map display works.

The button that I'd previously used to capture the geolocation points in a browser doesn't work for me in quinoid. However the version of the geoloc macro I installed a while ago had a few quirks and my application of it probably added a few more so it may well be nothing to do with quinoid. TonyM might be able to give you better feedback, I'll wait to see if it's working for him or others. Maybe there's a specific test you could ask users to try?

Hope this helps.

[TonyM]

Mark,

Testing 0.0.6alpha on Android 8

I can load the wiki from one drive using the system explorer. I can update the wiki from the desktop, on one drive, close and then reopen Quinoid and even although the file change is propagated to the mobile, it continues to open the prior version, until I remove it from the wiki list and add it back. Then on opening it has being updated.

Does this make sense?

Regards

Tony

[Mark S.]

How are you updating the wiki from the desktop? If you back out of Q, then update from the desktop, and then go back in, it *should* see the new wiki. But if you're using GDrive, GDrive itself doesn't recognize the changed date stamp. So there's a different order in which to do things. It's possible other synch software (such as dropbox) has this same limitation. So it would be helpful to understand what your synching mechanism is.

Thanks!

-- Mark

[TonyM]

Mark,

I will research further, but I followed these basic steps and the result befuddled me

All from memory, thus I will retest soon.

• Placed wiki in OneDrive on desktop
• Waited for to it to sync latest version on android
• Added/Opened the wiki in Quinoid from the local synced copy, made changes saving occurred
• Returned to Wikilist in Quinoid, closed Quinoid
• Awaited for the changed wiki to be synced to desktop, opened and saw the change made on mobile was visible 
• Made a change on the Wiki via the desktop and saved
• Waited for to it to sync latest version on android
• Opened Quinoid, selected from the wiki list
• Wiki opened with the changes made on the mobile but not the changes made on the desktop
  Even although the oneDrive file on the android had the time stamp of the desktop version
• I then removed the Wiki from the Quinoid wiki list, then added it back using system explorer
• The Wiki opened and contained the Desktop modifications

Regards

Tony

[Mark S.]

When you exit from Q, does it disappear from the recent-run list (the one activated with the right-hand square) ?

On GDrive you need to tell GDrive that a file is "pinned" for offline. Does the same concept apply on 1drive ?

At this step:

>> Waited for to it to sync latest version on android

Did you verify with some other app that the contents of file were modified on the Desktop? That is, there needs to be confirmation that the actual contents changed, and not just a change in the datestamp. Otherwise it's possible that 1Drive changes the datestamp without changing the contents.

Thanks!

-- Mark

[@TiddlyTweeter]

Quick note.

All working well. So, thanks again.

Only difference on install was that Android (8.0.0) on this version adds a level of  confirmations. "PlayProtect" popped up with a warning flag. First time round I backed out. Mistake. I then had to disable PlayProtect in the Google Store thing. Install after that went fine. Then I re-enabled it.

Just FYI, Josiah

[Mark S.]

Probably quinoid-v0-0-6-190217a.apk deserves to be in it's own release, but there's a lot that isn't settled yet. It has a new look, with "System Explorer" now activated through the "+" icon and "File Explorer" activated though the overflow menu. On the new overflow menu is also a download option, that is meant to download an empty TW from tiddlywiki.com. This is in preparation for offering users the chance to quickly load up on well-known and crafted TW files.

It's testing on the download functionality that interests me. I'm only able to test through emulators at the moment, and they give me inconsistent information on multiple levels. One emulator works great. Another gives the "OK", but then says there's something wrong with the file system, and then chooses to put the file somewhere else and with a nonsensical name.

What I'm trying to do is to save to a sub-directory of the user's external download directory. This way the user can be in charge of deleting and cleaning up. If people are willing to test, they should have an android with an external card, preferably with an existing "Download" directory. After running the download menu option, the new item should appear in your browse list. Unfortunately, at least on one emulator, it's possible that it will instead write to the download directory of the internal card, using a name that won't even look like a standard html file name. I don't know if this is for real, or just an anomaly of the emulator.

If you have a slow connection and have to log out of quinoid before the download is complete, then it's possible that the download will complete later but not appear in your list. In my tests, with WiFi, this wasn't a problem as the download was almost instantaneous. There's a bunch more coding I would have to do to prevent the non-listed download situation. But first I want to know how well the downloading works at all. It's another question whether I should prevent downloads except when connected to WiFi. Possibly a user configuration.

@Tony  -- I added some additional geo permissions to the v0.0.6 update. Curious if that made your geo-json file work any better. These additional permissions may be why TT was getting additional quizzing by the PlayProtect system.

Thanks everyone -- be sure to backup and take precautions if you try the release!

-- Mark

https://github.com/Marxsal/Quinoid01/releases/tag/v0.0.6alpha

[TonyM]

Mark,

Reviewing now quinoid-v0-0-6-190217a on Android 8.0.0

Selecting Download tesat had no feedback so I soon had 2 downloading in the background. Canceled one in the download manager, it is slow (but thats ok).

Found in the internal memory Download TW-files two empty files

empty-20190218014-17-29.html

empty-20190218014-17-18.html

of 2.17MB in size

Oddly I went to use back to close quinoid and I had to press three times before it exited.

• No change to the wiki list, + and browsed to Internal > Downloads and TW-Files and opened one of the empty files, 
• Tap to open from list opens my two existing items and a blank screen, 
• swipe left to open one of my existing wikis, has a 1-3sec display or white, before it displays (unlike previously) - I think this is an artifact of the mobile view, material theme, sidebar open.
• Empty wiki not appearing after time, but is now in list as TIDDLYWIKISTUB738395282426977923.html
• New download test whilst staying on wiki list screen (will report later)
• Will try geo-location soon

Question

Is there any reason we can't swipe left back to the Quinoid list, and arguably swipe right to load/(re)view the open wikis? It may be a little more intuitive.

Regards

Tony

[Mark S.]

Hi Tony,

Are you on a data plan or WiFi? When you normally open tiddlywiki.com/empty in your browser, how long does it take?

I'm wondering if some combination of a data plan and/or your remoteness from the main TW site may slow things down enough that the items don't immediately appear on your list. Unfortunately, if you navigated away from Q in the mean time, then it may not know how to add the download to the main list. I might have to prioritized persistence of the download manager.

empty-20190218014-17-29.html and empty-20190218014-17-18.html would have been the items downloaded. When you view them in your browser, are they OK?

TIDDLYWIKISTUB7383952824269779 is a stub file typically created when you navigated via the System explorer. I don't think it's the empty file unless it was created when you navigated with the system explorer. In general, you shouldn't be seeing the stub file. The stub files are temporary and get erased when the app reboots. Too hard to diagnose at a distance ;-(

Just to confirm, you say the two empties downloaded to your *internal* download directory? Do you have a SD card, and is it formatted as external or internal memory (Starting 7 (?) you have to tell Android whether you want your card to be formatted as though internal space -- giving more space for apps -- or as external space -- giving more space for shared MP3s, photos, etc.).

I might be able to manage swipe left to leave some day, but swiping from the list into the browser would be much more challenging.

Thanks!

-- Mark

[Watt]

Hi Mark

quinoid-v0-0-6-190217a on Android 7

Installs ok.

Opens, no location permissions requested.

Used the experimental 'Download empty' option - worked.
Fast download on wifi.

It didn't save to sdcard. It created a new folder 'TW-files' in internal storage and saved the timestamped empty.html there.

I think my sdcard is configured as 'external storage' and seems to resist write operations anyway unless it's via SAF mode. Internal storage of 'TW-files' suits me better anyway.

Repeated process for three 'empty' downloads, all work ok in Quinoid.

Added an existing wiki from sdcard using the + . Opened and worked fine. Wrote tids and saved (on sdcard!).

Swiping is good - big wiki's slow it down because they take time to reload. I'm thinking of it like Quinoid is the OS, the list is the Windows95 Start menu and each wiki is an application. Some applications take time to open. Swiping between them is a bonus!

Imported a plugin - JD's mobile theme. Imported 'Refresh for Quinoid'. Back-arrowed to list and re-opened wiki. Mobile theme working. (not sure if Refresh for Quinoid did anything but the wiki refreshed on reload from list, I didn't have to exit Quinoid).

Exiting Quinoid via Android back-arrow clears it completely from recent apps.

Reopened Quinoid. Loaded a pre-made wiki with the Leaflet plugin installed. It successfully displays maps previously created outside of Quinoid, with location points previously stored in a points field.

GeoLoc macro, which acquires geo points, doesn't work in Quinoid. I gave Quinoid location permission in settings but it still didn't work for me.

GeoLoc macro does work in firefox for Android using the same wiki and macro, acquiring and saving location points. The only visible difference was firefox asking for location permissions so that suggests it's a Quinoid thing and it's not getting the location on request from geoLoc.

Hope this helps. Do you think 'intents' will ever be doable? There is an app in playstore called Orgzly which might give some ideas on managing multiple wiki targets destinations, with tags, fields etc. It's org mode though not wikis, but possibly a similar mechanism.

Keep up the great work, thanks a lot!

[@TiddlyTweeter]

Mark S.

I reply in bits (from Andy 8-zero-zero).

I notice that Local Explorer is now deprecated?

Is this because future Android may dump it?

Personally I find it more logical and sensible than the other method that is "picture" driven.

Josiah

[@TiddlyTweeter]

Mark S.

I have "external" storage .. i.e. plugin SD card that is discontinuous with internal storage.

Empty downloaded (Download test) in seconds into "/storage/emulated/0/Download/TW-files" on INTERNAL storage.  

Auto-installed in Quinoid. 

Loaded fine.

Let me check pathing on "external" SD ... a dopo.

J.

[Mark S.]

Thanks for your feedback!

I'm not sure what you mean by "intents".

Thanks!

-- Mark

[Mark S.]

I find LE to be more logical too, but unfortunately this doesn't seem to be the future for Android (or any platform, actually). Everything is about security, and with each upgrade they've found some new way to tighten things up. In the new paradigm, apps talk to apps only after getting permission, and then only in a limited capacity.

Thanks!

-- Mark

[Mark S.]

Well, darn. I pulled every knob Android gave me hoping for the files to end up on the external drive where I figure most people have more space. Do you know if you have a download folder on your external drive? That is, where does Firefox download its files? Google doesn't just want to limit the drive where one can download, it also wants to shoehorn people off into directories meant for downloads, photos, or documents, depending on purpose. Manufacturers can change the pathing structure, so I can't be sure what is actually available.

Can you tell me the direct path to your external storage? Maybe I make a custom test using the actual path. If that doesn't work, then I know it's hopeless. If it does work, then I know I need to add a user preference where a working directory can be recorded.

Thanks!

-- Mark

[@TiddlyTweeter]

There is Whole (off-topic) world in that subject. The main issue is stuff gets so very obscured. Protection at the price of deepening Obscurity? Something seems wrong!

[Watt]

For me the specific 'intent' I'm interested in is the ability to 'share..' something e.g selected text, from any android app to a Quinoid housed wiki (or vice versa).

Orgzly is an example of an app that receives and broadcasts 'shares'. It receives to what it calls notebooks and offers a 'select which notebook' dialogue that might be a good model for a Quinoid ui.

The accepted answer here is clearer about intents;
https://stackoverflow.com/questions/6578051/what-is-an-intent-in-android

or, if you speak Android;
https://developer.android.com/reference/android/content/Intent

[Mark S.]

What sort of apps would use Q's internal files? I can't think of anything other than browsers. How would other apps use Q's internal files?

Going the other way, when Q gets a file on GDrive, it's actually using the internal sharing.

My original goal was to have Q access external files the way AndTidWiki did, so sharing wouldn't be necessary. But as time progresses, it might be better to think about "internalizing" the TW files, and only exporting them as needed. Since it seems I can only reliably depend on the internal protected space. The problem is that it makes it harder for people to synchronize files across their systems.

Hmm. Maybe if Q could pull from a node, work to its own copy, and then send results back that would provide portability. Like SimpleNotes. A bit ambitious though...

Forgot to mention. If you install the JSON from the release site, TW's reload buttons should work (after a first time reload). I'm thinking of making this the main avenue of reload. Currently, if you want to reload in Q, you back out of Q. The problem is, if you have a Download pending, Q loses the info for setting it up in the list. And if the download completes while you're in another app, I'm not sure Q will ever get notified. So I'm thinking of taking out the shutdown-on-back behaviour, though that will make things harder when people want to reload but haven't set up the JSON. For my own testing, downloads happen so fast that I probably couldn't even back out of Q before they were done.

Thanks!

-- Mark

[@TiddlyTweeter]

The path root to my "external" is ... "/storage/8806-1BFD"

TBH I get lost in a forest of NO drive identifiers on my internal and external.

I will keep on probing.

J.

Mark S. wrote:

Well, darn. I pulled every knob Android gave me hoping for the files to end up on the external drive where I figure most people have more space. Do you know if you have a download folder on your external drive? That is, where does Firefox download its files?

I DO. But is it ...

1 -- in the right position? (/storage/8806-1BFD/Download/)

&

2 -- do I need to NOT have "Download" on "internal" (currently, /storage/emulated/0/Download/)

Yours

Brain-Warp

[@TiddlyTweeter]

Quick note regarding paths.

Once Quinoid is up and running can it decide its own default paths?

"Download" is fine for starting but auto-downloads from within Quinoid, once running, do they HAVE to be in a Downloads sub-dir?

Just wondering

Josiah

[Mark S.]

2 -- do I need to NOT have "Download" on "internal" (currently, /storage/emulated/0/Download/)

That's a good question. I may be fighting someone else's (or some other times') war. The only reason to not use the internal Download is space. But TW files are small in the great scope of things. So maybe I should just live with whatever Android says is available. For that matter, maybe I should just tuck the downloaded file into internal space, allowing apps to send data (per Watt's suggestion) via sharing, with a possible Download option when people want their data out of Q. It may even be a mix, with some files external (and managed by the user) and some files internal (accessed through the app).

Thoughts?

-- Mark

[Mark S.]

Well, they need to be some place that Q can write to. There's only certain places (libraries) that Android will help the developer find -- for Documents, Download, Images, Music. The days of the Wild West, write anywhere are over. Unless you root your device, of course. Is there somewhere in particular you were thinking of?

-- Mark

[@TiddlyTweeter]

Just a footnote, I hope is practical. 

Decide your base Android version. Then look at typical memory on actual phones that run it.

TBH on the Andy 8 I am on ... "external" stores are for backup, not running. I'd need another 20 bloated TW to start worrying internally.

Just a thought

Josiah

Mark S. wrote:

Thoughts?

[Watt]

"What sort of apps would use Q's internal files?"

All of them potentially, but I think I may have explained it badly. It's not Q's internal files but the wiki files that 'intents' would target.

'All' I'm talking about is the ability to 'share...' to a wiki in Quinoid.

It already works sharing out of a wiki in Quinoid.

If I highlight some text in a quinoid wiki then Android automatically offers me the option of sharing that text to other apps (a 'broadcast intent'). If I hit 'share...' (next door to copy,translate etc) it asks me to choose the app I want to share to.

Going in the other direction, if I highlight text in almost any other app, Android automatically asks if I want to copy, translate or share that text. If I choose share then I get a selection of apps to share to. Quinoid isn't among them because it isn't set to 'receive intents'.

If Quinoid was adjusted to receive 'implicit intents' as outlined here (scroll down a bit to 'receiving implicit intents';

https://developer.android.com/guide/components/intents-filters#ExampleSend

then, possibly using a dialogue to select which wiki to use in a way similar to Orgzly, a tiddler could receive the text.

Haha! Not much to ask for Mark!

I'm only trying cackhandedly to explain a bit more clearly. I've no idea how difficult or time consuming it would be to implement. But I hope you can see what I'm on about. Essentially highlight, click share, choose quinoid, choose a wiki, text appears in a tiddler.
Similar to BJ's Tiddlyclip but works in Android.

Best

[Mark S.]

It would need to send to a previously designated TW and/or tiddler. Having to select from a list of TW's and/or tiddlers would interfere with one's concentration, I imagine (or maybe I'm just avoiding the work of writing all those dialogs ;-) ).

-- Mark

[Watt]

I don't blame you, hope I didn't sound too intents! If you get a chance have a look at Orgzly, and try and share some text into it.

I appreciate how much work you've already done on Quinoid, I use it and aTW daily so thanks a lot!

[@TiddlyTweeter]

Since its limited. Since you have to fit in. 

I think "Documents" is better than "Download" as the parent category.

TW working is a document in Androidville.

Just IMO

J.

[Mark S.]

So I think I've decided on a design direction. I'm going to give up on downloading to external drives, since Android doesn't want to give me accurate information about them. Instead downloads will go to an internal app directory. Because they're internal, it will be possible to scan them at boot-up and add them to the view list, in case Q was closed when the download-complete notice came in. People can still use other mechanisms to download wherever Android allows them to and then add them via the + or file explorer option. A long press will allow a user to designate a TW file as a target for sharing. When text is shared via other apps, a new tiddler will be created in the target tiddler. Of course, I don't know how long any of this will take, or how much is feasible, but it seems like a fairly good plan, allowing a mix of old-time file browsing and new-time application driven behaviour.

-- Mark

[Watt]

Fantastic! If there's anything useful I can contribute say the word.
Tiddlyclip did actually use exactly that 'designated shared wiki' method. Called it docking.
Thanks again for the perseverance!

[TonyM]

Mark,

My data plan is faster than Wifi and I normally have no complaints, However on Wifi for my test , and just entering tiddlywiki.com/empty now seems to take forever. I will see if I can get better performance and retest.

Empty files open OK on my desktop, znd in the mobile FireFox

The stub file is disappeared and I now have a link to one of the empty files so perhaps patience was needed.

I have a 64mb SD Card but also 64mb Internal storage (LG V20). Downloads occur to the subfolder in the download/tw-files I am not sure how the SD  is formatted but I have moved apps to it, and do not seem to have any limitations.

Perhaps you miss understand me, I only mean swipe left back to the Quinoid Wiki list, no reference to another browser, swipe right to the open wikis.

Thanks so much for your work on this. I will continue to try and pushit to access oneDtive, Google Drive, Dropbox etc.. I only wish we had a way to lock single file wikis so we could reliably not edit them from two locations or two people at once.

Speculation/idea

Since Quinoid is a TiddlyWiki manger for want of a better word, perhaps it could write a stub file wikiname.lock.quinoid to the same folder as the wiki when a wiki is opened in Quinoid, and Delete it on exit thus another browser accessing the wiki across the wire of cloud file sync could see Quinoid currently owns the file and may save over it at any moment. If the app is cancelled/abended it may fail to delete the file, but it would be a simple matter of reopen and gracefully exit. 

I am looking for a way to get a single file wiki test for existence of wikiname.lock.* files and respond differently if such a file exists, like informing the user it is open elsewhere and entering a read only mode.

By the way, although not well designed for Mobile, I have succeeded in opening my 9.3MB GTD wiki on Quinoid, takes <30 seconds to load 

Android 8.0.0 

64GB internal, 64GB SD, 4GB ram, 3GB in use with above wiki, 1 empty.html and two others all open

Quinoid 22.64MB used in Internal memory

I did get a couple of sorry Quinoid app stopped, reload. (Opening control panel from downloaded empty)

I will continue to report what I observe

Tony

[TonyM]

Mark,

If it is possible to use the import mechanism as the destination of a share to a wiki, it may result in more possibilities. ctrl-V acts like a drop on Tiddlywiki and generates an untitled import from the clipboard. If a json or tid file were pasted perhaps it would allow import. I same ways it makes sense that sharing into tiddlywiki is a tiddler creation process, and if it is a single or set of tiddlers to allow the import mechanism to work. If someone pastes inside a text area it will go there, otherwise it perhaps should trigger the import mechanism (Which itself pastes into the temporary $:/import tiddler)

Also the import process is open to manipulation by designers.

Regards

Tony

[@TiddlyTweeter]

Ciao Mark S.

This is not a request for you to do anything. Just thinking out-loud.

The mechanism to "fetch" and auto-install a wiki is great (currently "Download Test").

What I'm wondering is if a user like me can configure a version of the tool so it can fetch a TW I set-up?

Use Case: I'm thinking of students of film who need a start-up wiki. One click setup is better for them, I think.

Just thoughts

Josiah

[Mark S.]

It occurred to me that if you had a configuration directory, with setup files and icons, you could essentially make your own TW-driven app.

-- Mark

[Watt]

Quinoid is the OS, List is the start menu, TW is the GUI, plugins are the apps?

[Mark S.]

Once again Android is making me alter plans. I'm back to saving to an external (not private) dir. This time it will be a
subdir of a documents folder. I don't know if it will be on the actual external drive or not. One feature of this
arrangement is that any files added to the directory will be automatically added to the Q list, if not already there.

--Mark