LiveCode Forums

Couple of quick notes...
800 is too tall for some laptops. Mine is only 768 (1366 wide) so it would really need to be closer to 700.
While desktops/laptops can’t rotate, if you resize wide/short then the landscape view may be useful.
I mainly use Dash anyway though. I did test it the other night on my Win10 laptop and got it to work.

@bwmilby, gosh I completely forgot about laptops. In a way they are so far behind mobile platforms. In this case I firmly had a suggested size for mobile in mind but when finished it will take its environment fully into account.
Thanks for testing though (and yes, please don't use this as a DASH replacement. DASH is much more capable than this will ever be.)

Works great on the desktop on Mac. I like where this is going.

Even though you told us not to compile it yet, I just wanted to see how it looks on Android. There were some execution issues of course but I'll see how it does later. Mainly I was interested in the appearance, so thought I'd mention that the suggested minimum hit zone on a phone is 42 pixels square. I've used buttons as small as 34 but I wouldn't go any lower than that. When I want a tiny icon with a larger hit zone, I either use a button with a small icon and large margins, or I place a larger 99% transparent graphic under the SVG and set the SVG to disabled, so that taps go through to the graphic.

Since this is a work of love for us outliers, these small tweaks are something we can do ourselves too, so it's no big deal. Or maybe when you implement resizing things will change. The stack is looking very promising. The new UI is excellent!

@jacque 42! So the “Answer to the Ultimate Question of Life, the Universe, and Everything” was determined by a mobile interface, and Android, no less. I am not sure how Marvin would feel about this. I, for one, am becoming quite depressed. I can just hear the smirks of smug satisfaction coming from the pockets and handbags of ‘droid carriers I pass in the street. time to turn up the volume on my AirPods.

LOL! Until this is over, I suggest you pull Marvin's batteries and lock yourself in your room.

Sorry for the delay in updating the stack.
Have a few other commitments to attend to.
Of course having the b*#@ger crash on me didn’t help. I needed to talk myself back into opening it again. I think I was angry with it (go figure.)
I am currently playing with getting the resizing right depending on the platform but keep changing my approach. As a developer I want you to be able to see what different appearances there are if on a phone, tablet or desktop. You may also have seen my query on the list re detecting browser scroll. More to investigate.
I hope to have a new version up next week.

jameshale wrote: ↑

Fri Nov 09, 2018 11:30 pm

As a developer I want you to be able to see what different appearances there are if on a phone, tablet or desktop.

As a user I love choice! Having been playing with it whilst you were being frustrated by it, I did come up with a few more suggestions (nothing too drastic, I think...)

One would be to not have it try to read the docset in automatically. It produces about a 70/30 split as to whether it will open or hang here in 'nix land, although no odd effects were noticed on win. Instead, and especially since you mentioned showing the end user different appearances, I'd suggest a 'run once' type of splash screen.

I don't know if you've ever seen that setup before (pretty sure you have), but it puts up a pick of the different layouts on one screen, with a way to select the layout you want to choose (buttons work, or even the image itself). Then, the layout type is saved and referenced, and can be changed later if desired through the mechanisms you already have.

It would also be a good way of delaying choosing the docset until the programs fully loaded.

Just a thought, one is my allowance for the day

I saw your question on the mailing list but wasn't sure why you'd need to track the browser scroll. Maybe the javascript is causing the crash, you could leave it out and see what happens. I don't mind rescrolling if I change orientations.

BTW, have you considered fullscreenmode for mobile? It takes away a lot of the pain. You can change the layout on orientationChanged.

If you're doing pixel placement on mobile instead, Andre discovered that the screenrect won't report correctly until the first card is drawn (maybe you saw that on the list.)

@jacque, the browser question was to extend the browser over the button bar that sits beneath it when it was not at the top of the page. This would make it 44px longer. I thought this would make landscape on a phone show significantly more of the page.
The extra mobile requirements will have to wait until I get the simple geometry right.
Everything was fine until I inadvertently resized the stack. Then my omissions raised their arms and started screaming at me.

@bogs

don't know if you've ever seen that setup before (pretty sure you have), but it puts up a pick of the different layouts on one screen, with a way to select the layout you want to choose (buttons work, or even the image itself). Then, the layout type is saved and referenced, and can be changed later if desired through the mechanisms you already have.

Yes I had also come to this conclusion this morning.
I am intrigued by the 70/30 for loading the,docset on ‘nix.
Once the docset has been copied (which needed to happen after all the underlying libraries had been loaded) the only loading required on subsequent launches is reading in the database entries. These consist of only three small fields (albeit 4500 of them.) I made the decision to read in the whole index and use the filter command to search rather than calls to the database. Perhaps that was a mistake. Something to look at once the interface is stable.

jameshale wrote: ↑

Sat Nov 10, 2018 12:14 am

I am intrigued by the 70/30 for loading the,docset on ‘nix.
Once the docset has been copied (which needed to happen after all the underlying libraries had been loaded) the only loading required on subsequent launches is reading in the database entries.

Well, if I were your typical user, and if I were only waiting for updates to download it over and over and over again on multiple 'nix installs, I'd say opening it would probably be more like 90/10 in successes

Of course, I'm out to break the heck out of it if I can, so I am running it through many fresh vm installs. Ain't I a stinker?

I'm closing in on 70 installs now, in a number of different ways. The way most likely to see breakage on 'nix is to download it from the samples pane, not sure why. From what I can see, it almost acts like it starts reading in stuff before the whole thing is loaded. I'm not *positive * mind you, but that is because I'm not running the debugger on it like I would be my own programs.

@bogs, would it be fair to describe your setup/use as an edge case then?

Maybe an edgier-than-most case

On the other hand, I would expect at least a fair number of people *may* download the reader from the 'in IDE' samples screen, so that might make my observations a bit less edgy.

Btw, I'm not giving your app anywhere near the workout I send my own creations through, I only want to see it succeed and be popular

Oh I am not complaining. Just trying to get a handle on how much a concern this should be.
It will be addressed