Does Browser widget make a good browser?

[deadparrotsoftware]

Whether it is the community version or business version (we have both), can you make a decent
"web browser" (for browsing several sites) with the browser widget?

Our other multi-platform compilers (Delphi, Xojo, etc.) have fairly decent "browsers"
for interfacing with web sites. We have used them extensively.

But since I am trying to steer us towards a livecode base, at least for new projects,
I thought I would ask among those whom I assume have used the widget to a greater
degree than we have, as yet, for the good and the bad about the widget?

Thanks

Sid B.

[bogs]

This entry maybe has what your looking for? I'm not usually in the later than 7x series, so I would probably if needing a browser launch the users default browser to open a page.

[shaosean]

Isn't the new browser widget based on the Chromium Embedded Framework (CEF)?

[deadparrotsoftware]

I do not know if the browser widget is based on CEF - that's type of
Information I would like to know.

The browser widget was introduced to version 8, for community, Indy
And Business editions.

And no, I am talking about using the widget to create a stack screen for
Browsing a web site/page, not calling up the device default web browser

I do appreciate all the responses, thanks

Joe

[shaosean]

I know they added CEF at one point, for the revBrowser stuff.. Not too certain if that got repurposed for the browser widget though - you could always check the source code or wait until someone who has more knowledge answers..

[bogs]

And no, I am talking about using the widget to create a stack screen for
Browsing a web site/page, not calling up the device default web browser
...I do appreciate all the responses, thanks

I thought that might be the case, which is why I put that entry first

I am sure some of the more experienced with that end of it might show up, such as shaosean did.

On a side note, I often wonder if it is possible to put a copy of the users default browser into a stack, or make it look as if it is part of a stack. hmmm. I'll have to look into it at some point.

[deadparrotsoftware]

lol - "...is possible to put a copy of the users default browser into a stack,..." is an interesting question as well.

I am surprised there are not more on the forum who have experience with this they could relate.
I am obviously not the only one with a bit less than "in depth" experience on the subject.

Sid B.

[bogs]

I am able to guarantee that you are not the only one with less than an "in depth" experience on almost any aspect of Lc, you wouldn't believe how long it has taken me just to get to the point where I can sometimes ask coherent questions !

I am just as sure that there are more than a few who have experience on this topic, just as I am sure they will chime in if/when/as they are able. Might not be in a minute, or even today, but those that know are usually very willing to share

Something else I forgot to ask, is this for a project across both desktop and mobile? ...just one or the other?... just in general? Sometimes it makes a difference.

[PBH]

You should also check the LiveCode QCC and search for "Browser Widget", you'll find a list of the current problems with the Browser Widget.

The show stopper for me was not being able to use it to upload a file to a website, e.g. Dropbox or anything similar, I reported Bug 17928 http://quality.livecode.com/show_bug.cgi?id=17928 well over a year ago which is now by superseded by Bug 18955 http://quality.livecode.com/show_bug.cgi?id=18955.

The response from LC was "Recently, the language team's focus for stability improvements has been on the core LiveCode engine, rather than on peripheral components like the browser widget." So I was forced to abandon my project with the Browser Widget for the time being.

There are many other small issues, but the LC QCC should help you decide if it's developed enough for your use case.

http://quality.livecode.com/buglist.cgi ... =substring

Paul

[bogs]

Hmm. I just installed Lc 8 to find out how bad the browser widget for the stack really was. For just displaying pages, it seems to work ok?

The code to do it wasn't very difficult either. This was shot from Linux, like I said earlier though, would really have to know which targets your shooting for, I would imagine most of it works for Mac and Win if it runs on Lin (my experience so far anyway).

The show stopper for me was not being able to use it to upload a file to a website, e.g. Dropbox or anything similar,

Again, I'm speaking from ignorance here, so forgive me PBH, but couldn't you just use built in commands to do that? uploading to ftp has been around forever, and I remember recently reading something about using dropbox libraries as well (not from the browser widget, or maybe it was ?) elsewhere on the forum.

Anyhoo, if your only looking to display pages, it seems like it would do it maybe depending on how complicated the page is? I actually answered this for myself, I went to the PeaceKeeper website with it, at the point I finally quit out, it seemed to be keeping up quite well.

[deadparrotsoftware]

It is a mobile world now - I personally would consider a FULLY functional
Browser componenant as critical, NOT "peripheral".

And uploading files is NOT just about "dropbox" - it too is a critical function!
Would prefer not to have to "kludge" that.

Based on what you are telling us, the browser widget would not allow us to create
An interface to a wordpress site (that is both desktop and mobile) because uploading
Plugins, themes, etc. is a DAILY operation, especially for admins with several sites.

That, and LC's attitude, is very dissapointing. A LOT of money has been paid by many of
Us and kickstarters for "new" development, and that is great, but there are some
Critical "peripherals" that really need to be kept up to par.

Yes, very dissappointed.

But I thank all for contributing information.

Sid B.

[FourthWorld]

It is a mobile world now - I personally would consider a FULLY functional
Browser componenant as critical, NOT "peripheral".

Depends on what you're building, of course. Personally I've never deployed anything that required an embedded browser application, and among those projects I know of that have most report good results.

It seems there are details at play, as outlined in those reports, describing specific functionality which affect only a subset of projects. That can certainly be frustrating if your project happens to be in that subset, but of course any single project isn't reflective of the vast scope of apps made with a tool this flexible.

Just the same, let's explore those specifics to help find a solution:

And uploading files is NOT just about "dropbox" - it too is a critical function!
Would prefer not to have to "kludge" that.

While I've never needed an embedded browser application, many of my apps upload files. LC's support for POST has handled that swimmingly for many years, and in more recent proprietary-licensed versions the addition of tsNet to the mix offers even broader options.

Perhaps if we could learn more about the specific functionality your app requires, whether that functionality is truly dependent on also including an embedded browser application, and which platforms you're looking to deploy to, we may be able to explore solutions meeting those requirements with what we have on hand today while the team continues work on those reported issues.

[bogs]

Well, I'm not sure if those were directed at my reply, or PBH's, but I would guess a bit of both

About the way I suggested for uploading, that is not a *kludge*, ftp and url commands have been in the language probably since before there was a mobile. I don't think they are overly complicated to use, but I suppose that is open to interpretation and need.

I don't dev for mobile as I said earlier, but I can say the rendering of the browser widget as is worked fine on *my* system. PBH put up very good information about the weaknesses, I have no idea about how it interacts with a word press site since I don't use or develop for that either

Obviously I don't speak for Lc, but from version to version I do tend to see changes. They aren't always perfect, but then, I don't think anyone else is either. I do see honest efforts to fix things that go wrong, and that usually is good enough for me. If it isn't fixed, I will try to work around it, but again my attitude tends to be nothing is perfect in any way, programming languages tend to take that to a unbelievable level.

As an aside, I used to work (and still do for some things) in Realbasic. My first (and favorite) version was 5.5.5 and 2006 was my 2nd fav. After 2006, it seemed like it got buggier and goofier, then they changed it to Xojo. When I couldn't get the ide to run correctly anymore (around 2013-14), I called it quits and just kept using 5.5 and '06. Not a perfect solution, but workable.

I believe that RB/Xojo care about their cust. base as much as Lc does, however no one can please everyone. Otherwise, there would only be one programming language wouldn't there?

Just my .02, no harm no foul, remember kids, behind every silver lining, theres a dark cloud! .. and if you play a sport, go ahead

[deadparrotsoftware]

Thanks for your input Richard.

Without disclosing what I can't:

Our experience is the opposite of yours. We have 37 projects in the corporate
World with embedded browsers - most done in Xojo or Delphi - baceasue, as I said,
It is a mobile world now, and Apps have to be able to integrate with the web world.

Our current projects use embedded browsers becaues of things like a standard
Browser Interconnection - you don't have to contend with knowing, and adjusting
For which web browser an employee is using. You control that when using embedded
Browser, and you can control usage, such as removing the address bar (You would be
Amazed how much nonesense and headaches we eliminated for one client JUST by
Doing that).

So, while you may have seen no need for embedding web, it is for us, critical:
Almost every project we have done, and are doing, has at least one screen that
Is an embeeded browser.

I would like to be able to talk specific needs, but these are not open source type
Projects (most of the time), so we are constrained to talking in more general terms,
Or in small chunks. But, being able to do uploads via an embedded browser, without
Having to do a Post, is definetly one of them.

I DO appreciat your help.

Sid

[FourthWorld]

I can certainly respect the need to keep a product's key features related to its value proposition secret while it's in development. Of course once it's released an app's focus and feature set become public knowledge, but the trick now is getting from here to there while overcoming a technical hurdle.

Native apps are indeed increasingly web-connected. But a common distinction from web apps is that a native app talks directly to the OS APIs for its UI, rather than inserting a separate browser process to deliver a UI rendered from HTML.

In this most common benefit of going to the trouble of crafting multiple native apps for each OS over a web app that runs everywhere, while both share HTTP connections with a server, the web app will usually have that request met with a reply delivered in an HTML wrapper, while the native app doesn't need to page elements, just the data, so it'll use an API to obtain only the data instead, usually in JSON or XML.

LC can GET and POST requests to HTTP servers quite well, and process the returning JSON and XML with equal grace.

That said, there appears to be something very specific to this collection of apps which requires an uncommon architecture, one in which the UI must be rendered partially in an embedded browser app and partially within the native app process.

I appreciate that you may not be at liberty pre-release to discuss that without tipping your hand, but if there's any way we can lend a hand with technical aspects of that without revealing the business logic behind them we're happy to help.