(Re-sending....)
I'm getting ready to do some Python learning on PluralSight.com and the dude mentioned PyQT for desktop applications.
Ed & Paul (and others) -- your thoughts on that? Was interested in your take since you did Dabo for desktop applications with Python.
Thanks! --Mike
PyQT has 2 different licensing models which may complicate your decision to go this route. PyQT has a fat distribution as well.
Other options for Python desktop apps are wxPython (Dabo's choice) and Tkinter/ttk. While Tkinter/ttk often gets a bum rap, I've seen some cool apps built with this GUI framework. While the Tkinter/ttk is definitely a contrarian route, its advantages are that its a lightweight distribution that ships out of the box with most Python distributions, its cross platform (Windows, Mac, Linux), it supports both Python 2 and 3 ... and contrary to the press it receives, the ttk side has surprisingly modern widgets. Check out this great tutorial to see more: http://www.tkdocs.com/tutorial/index.html. Bryan Oakley on Stackoverflow has some great tips as well. BTW: Python's default IDE (Idle) is built entirely on tkinter and while its not pretty, the full source code to this app ships with the Python distribution as well.
In 2017, how many users are looking for desktop apps? If you're going the Python route, why not check out some of the great Python web frameworks like Django, Flask, or Bottle?
Welcome to the dark side!
Malcolm
On Tue, May 30, 2017 at 3:07 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
In 2017, how many users are looking for desktop apps?
Still plenty.
Seriously?
On Tue, 30 May 2017, at 12:05 PM, Stephen Russell wrote:
On Tue, May 30, 2017 at 3:07 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
In 2017, how many users are looking for desktop apps?
Still plenty.
Seriously?
Seriously. Anything that needs any sort of meaningful interaction with a local file system or devices, or a rich UI for example.
On Tue, May 30, 2017 at 9:55 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
On Tue, 30 May 2017, at 12:05 PM, Stephen Russell wrote:
On Tue, May 30, 2017 at 3:07 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
In 2017, how many users are looking for desktop apps?
Still plenty.
Seriously?
Seriously. Anything that needs any sort of meaningful interaction with a local file system or devices, or a rich UI for example.
I think that you are dreaming or have not exposed your network properly to fulfill your needs of what to do with a "system."
have worked with Document Management systems that acted on and then moved files because they were in a specific folder. That location also enacted a special set of rules for those documents.
Printers? We have 300-400 printers on our network that all receive correct documents because the direction is not a part of the report but of the application that made the output.
UI? Using css, jquery, as well as a host of other javascript frameworks UI is a look and feel that you pick and it is applied, <div> is your friend when you reference the class or Id.
Desktop or web app, whichever, when your only tool is a hammer, everything looks like a nail,
Fred
On Tue, May 30, 2017 at 8:44 AM, Stephen Russell srussell705@gmail.com wrote:
On Tue, May 30, 2017 at 9:55 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
On Tue, 30 May 2017, at 12:05 PM, Stephen Russell wrote:
On Tue, May 30, 2017 at 3:07 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
In 2017, how many users are looking for desktop apps?
Still plenty.
Seriously?
Seriously. Anything that needs any sort of meaningful interaction with a local file system or devices, or a rich UI for example.
I think that you are dreaming or have not exposed your network properly to fulfill your needs of what to do with a "system."
have worked with Document Management systems that acted on and then moved files because they were in a specific folder. That location also enacted a special set of rules for those documents.
Printers? We have 300-400 printers on our network that all receive correct documents because the direction is not a part of the report but of the application that made the output.
UI? Using css, jquery, as well as a host of other javascript frameworks UI is a look and feel that you pick and it is applied, <div> is your friend when you reference the class or Id.
-- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN
901.246-0159 cell
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
Seriously.
Not all programming is for web-based applications and not all clients want web-based applications.
If this were true, this group would not exist.
Neither would any of the thousands of desktop (VFP!) applications that are still being supported every day.
Neither would my business.
Paul H. Tarver Tarver Program Consultants, Inc.
-----Original Message----- From: Stephen Russell [mailto:srussell705@gmail.com] Sent: Tuesday, May 30, 2017 6:06 AM To: profoxtech@leafe.com Subject: Re: [NF] PyQT for desktop applications
On Tue, May 30, 2017 at 3:07 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
In 2017, how many users are looking for desktop apps?
Still plenty.
Seriously?
-- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN
901.246-0159 cell
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
[excessive quoting removed by server]
+1
On May 30, 2017 6:28 PM, "Paul H. Tarver" paul@tpcqpc.com wrote:
Seriously.
Not all programming is for web-based applications and not all clients want web-based applications.
If this were true, this group would not exist.
Neither would any of the thousands of desktop (VFP!) applications that are still being supported every day.
Neither would my business.
Paul H. Tarver Tarver Program Consultants, Inc.
-----Original Message----- From: Stephen Russell [mailto:srussell705@gmail.com] Sent: Tuesday, May 30, 2017 6:06 AM To: profoxtech@leafe.com Subject: Re: [NF] PyQT for desktop applications
On Tue, May 30, 2017 at 3:07 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
In 2017, how many users are looking for desktop apps?
Still plenty.
Seriously?
-- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN
901.246-0159 cell
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
On May 30, 2017, at 11:26 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Just responded to Ed's post saying that a desktop UI still kicks ass over a web page UI.
Ten years ago I would have wholeheartedly agreed with you. Five years ago I wouldn't have been too sure about that. Now think that the Javascript tools and frameworks have advanced so that they can do as much or more than desktop widgets, and they totally kick ass when used on mobile platforms.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature ---
The thing is that yes you can get a fluid, responsive, beautiful UI using one of the three billion client side frameworks, coupled to a back end developed with this week's server-side framework but to make it secure and to test it on all the browsers on all the platforms is literally ten times the work.
1/10 th of the time using FoxinCloud with integrated Bootstrap support. Just adapt your VFP app, and/or write an extension for the web using your extent classes, and you're done.
Thierry Nivelet http://foxincloud.com/ Give your VFP app a second life in the cloud
Le 30 mai 2017 à 20:45, Alan Bourke alanpbourke@fastmail.fm a écrit :
The thing is that yes you can get a fluid, responsive, beautiful UI using one of the three billion client side frameworks, coupled to a back end developed with this week's server-side framework but to make it secure and to test it on all the browsers on all the platforms is literally ten times the work. -- Alan Bourke alanpbourke (at) fastmail (dot) fm
On Tue, 30 May 2017, at 07:33 PM, Ed Leafe wrote: On May 30, 2017, at 11:26 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
Just responded to Ed's post saying that a desktop UI still kicks ass over a web page UI.
Ten years ago I would have wholeheartedly agreed with you. Five years ago I wouldn't have been too sure about that. Now think that the Javascript tools and frameworks have advanced so that they can do as much or more than desktop widgets, and they totally kick ass when used on mobile platforms.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature
[excessive quoting removed by server]
On Tue, May 30, 2017 at 1:45 PM, Alan Bourke alanpbourke@fastmail.fm wrote:
The thing is that yes you can get a fluid, responsive, beautiful UI using one of the three billion client side frameworks, coupled to a back end developed with this week's server-side framework but to make it secure and to test it on all the browsers on all the platforms is literally ten times the work.
Seems like it can be done. Now tell me about OCX files that need to be installed.
Each environment has it's own line issues, but no users who are well versed in "the internet vs the network" would ever ask for limited functionality, instead, they would demand the web as it provides access to everything.
On 2017-05-30 15:27, Stephen Russell wrote:
Seems like it can be done. Now tell me about OCX files that need to be installed.
Each environment has it's own line issues, but no users who are well versed in "the internet vs the network" would ever ask for limited functionality, instead, they would demand the web as it provides access to everything.
Does anybody use OCX controls anymore???
The PC is dead and it will be all mobile devices... It'll all be cloud and nothing local... No more native apps, they'll all be in the browser...
Like all predictions the truth is in between somewhere.
If for example Microsoft still don't have a browser version of Word that is anything near the native version then we're a ways off everything in the browser yet.
Ever tried office365 ? What a nice piece of rubbish that is. ;)
On Wed, May 31, 2017 at 9:11 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
The PC is dead and it will be all mobile devices... It'll all be cloud and nothing local... No more native apps, they'll all be in the browser...
Like all predictions the truth is in between somewhere.
If for example Microsoft still don't have a browser version of Word that is anything near the native version then we're a ways off everything in the browser yet.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
On Tue, 30 May 2017, at 08:27 PM, Stephen Russell wrote:
On Tue, May 30, 2017 at 1:45 PM, Alan Bourke alanpbourke@fastmail.fm wrote:
The thing is that yes you can get a fluid, responsive, beautiful UI using one of the three billion client side frameworks, coupled to a back end developed with this week's server-side framework but to make
it
secure and to test it on all the browsers on all the platforms is literally ten times the work.
Seems like it can be done. Now tell me about OCX files that need to be installed.
Each environment has it's own line issues, but no users who are well versed in "the internet vs the network" would ever ask for limited functionality, instead, they would demand the web as it provides access to everything.
-- Stephen Russell Sr. Analyst Ring Container Technology Oakland TN
901.246-0159 cell
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html
[excessive quoting removed by server]
On Wed, 31 May 2017, at 09:32 AM, Jean Laeremans wrote:
Ever tried office365 ? What a nice piece of rubbish that is. ;)
We have that at a corporate level, and it's pretty good in terms of the browser versions of Word and Excel. But a million miles away from the desktop versions, still.
We too and you're welcome to it. 1st thing I did was install libre office.
On May 31, 2017 11:02 AM, "Alan Bourke" alanpbourke@fastmail.fm wrote:
On Wed, 31 May 2017, at 09:32 AM, Jean Laeremans wrote:
Ever tried office365 ? What a nice piece of rubbish that is. ;)
We have that at a corporate level, and it's pretty good in terms of the browser versions of Word and Excel. But a million miles away from the desktop versions, still.
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
On 2017-05-30 14:33, Ed Leafe wrote:
Ten years ago I would have wholeheartedly agreed with you. Five years ago I wouldn't have been too sure about that. Now think that the Javascript tools and frameworks have advanced so that they can do as much or more than desktop widgets, and they totally kick ass when used on mobile platforms.
What are your favorite JavaScript tools/frameworks, Ed?
On May 30, 2017, at 4:27 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
What are your favorite JavaScript tools/frameworks, Ed?
To be honest, I haven't done any client-side interfaces for some time now, so I don't have a favorite. I work pretty much exclusively on the back end of the cloud, specifically the Nova compute project in OpenStack. Sometimes, though, I come across a site that I really like, and look at the page source to get an idea as to what JS libs it's loading so that I can keep it in mind if I ever get another UI project to work on. The last site I saw that made me look at the source used EmberJS (https://emberjs.com/). I don't claim they're the best or anything; it's just that whoever developed the site I was on sure knew how to make it look good.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature ---
On 5/30/2017 2:33 PM, Ed Leafe wrote:
Just responded to Ed's post saying that a desktop UI still kicks ass over a web page UI.
Ten years ago I would have wholeheartedly agreed with you. Five years ago I wouldn't have been too sure about that. Now think that the Javascript tools and frameworks have advanced so that they can do as much or more than desktop widgets, and they totally kick ass when used on mobile platforms.
...
Rich client will always be a better user experience than dumb terminal.
Note that "javascript" is essentially "rich client thinking" - albeit rich client as rendered within a "browser platform". Most "mobile apps" that are "good" do not use "browser" technology: they implement their own form of "rich client". Essentially, what we're witnessing to a degree is a return to "rich client" design and processing.
What amazes me is the horrific browser-based incompatibilities that still exist. Even within a single enterprise... sometimes we have to turn on IE's "View in Compatibility Mode" sometimes not - and don't even try to view the same web pages in firefox, IE, and Chrome and expect similar results. There is no web page that is truly responsive: every web application where I work (which is quite a large company) is pathetically slow. All their "browser-based" applications have essentially turned into "Excel-export" engines because the user experience is so horrible. That's after 100's of millions of dollars were sucked into creating those supposedly wonderful browser-based applications.
So, while javascript, silverlight, and whatever else have gotten us close to where we were in the 1990's in regards to user interfaces, I hope folks can understand my negativity. Just imagine where our UI's would have been if we had avoided the decades jump backward of "browsers"
Note my views have NOTHING to do with "the internet" or "centralized data" or "connecting to everything", etc. Accessing, sharing, publishing data securely "across the internet" can, and does, work just fine without any browser involvement.
In fact, I'm planning on building the web pages for this Automated Data Dictionary concept for my company. Most of the functionality will be in the "API" (aka stored procedures in the database). I'm going to also build, on my own time, a VFP integration into that API. I'll show both of the UI's and let them decide which is the better experience. I have a very strong suspicion that the user population simple does not realize how much they're being hampered by web browsers.
And before people start slobbering themselves with "... but... but... the DISTRIBUTION!!!! OMG!! How could you DISTRIBUTE a rich client application..." - really, don't bother. Simple file shares (dare I say even "sharepoint"?) make rich client distribution fall-off-a-log easy and secure. I have seen more browser-based "distribution" problems than I've ever seen with my "desktop" distributions.
I imagine the usual MS-heads, or browser-pundits, or whatever will say... "oh, it sounds like your web developers are just too STUPID to know how to do things right..." Whatever. They're all "MS-certified" "Web page designer-certified" developers. So it seems a little fishy that "certified experts" working in the field for 2 decades still cannot do it well (I'm being a little facetious here - based on my experience, I realize "certifications" mean almost nothing in the real world of software development).
-Charlie
Care to enlarge on this please. " Simple file shares (dare I say even "sharepoint"?) make rich client distribution fall-off-a-log easy and secure. "
Andrew Stirling
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Charlie, +1 Laurie
On 1 June 2017 at 22:10, Andrew Stirling support@calcpay.co.uk wrote:
Care to enlarge on this please. " Simple file shares (dare I say even "sharepoint"?) make rich client distribution fall-off-a-log easy and secure. "
Andrew Stirling
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
Posting a document to Sharepoint is so simple. Setting the library to hold it is real easy as well. Keeping versions for me on the file is tremendous. Having a recycle section for me to republish what you didn't think you were screwing up is pretty good too.
On Fri, Jun 2, 2017 at 8:05 AM, Laurie Alvey trukker41@gmail.com wrote:
Charlie, +1 Laurie
On 1 June 2017 at 22:10, Andrew Stirling support@calcpay.co.uk wrote:
Care to enlarge on this please. " Simple file shares (dare I say even "sharepoint"?) make rich client distribution fall-off-a-log easy and secure. "
Andrew Stirling
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
I was really asking Charlie about how he proposed to get the 'desktop' bit working easily. 'And before people start slobbering themselves with "... but... but... the DISTRIBUTION!!!! OMG!! How could you DISTRIBUTE a rich client application..." - really, don't bother. Simple file shares (dare I say even "sharepoint"?) make rich client distribution fall-off-a-log easy and secure.'
Kind regards
Andrew Stirling
On 02/06/2017 14:49, Stephen Russell wrote:
Posting a document to Sharepoint is so simple. Setting the library to hold it is real easy as well. Keeping versions for me on the file is tremendous. Having a recycle section for me to republish what you didn't think you were screwing up is pretty good too.
On Fri, Jun 2, 2017 at 8:05 AM, Laurie Alvey trukker41@gmail.com wrote:
Charlie, +1 Laurie
On 1 June 2017 at 22:10, Andrew Stirling support@calcpay.co.uk wrote:
Care to enlarge on this please. " Simple file shares (dare I say even "sharepoint"?) make rich client distribution fall-off-a-log easy and secure. "
Andrew Stirling
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
SharePoint does a great deal of simple work for you if you let it. We fill internal SP lists, orders to be shipped, with data from the ERP. We then have mainly stagnant lists, Customers per say, and in SP we set a drop-down list for the customer and it filters the orders, needing to go out today or when it did leave, in the view list. Real simple and the control works across all of our many plant's sites.
On Fri, Jun 2, 2017 at 9:01 AM, Andrew Stirling support@calcpay.co.uk wrote:
I was really asking Charlie about how he proposed to get the 'desktop' bit working easily. 'And before people start slobbering themselves with "... but... but... the DISTRIBUTION!!!! OMG!! How could you DISTRIBUTE a rich client application..." - really, don't bother. Simple file shares (dare I say even "sharepoint"?) make rich client distribution fall-off-a-log easy and secure.'
Kind regards
Andrew Stirling
On 02/06/2017 14:49, Stephen Russell wrote:
Posting a document to Sharepoint is so simple. Setting the library to hold it is real easy as well. Keeping versions for me on the file is tremendous. Having a recycle section for me to republish what you didn't think you were screwing up is pretty good too.
On Fri, Jun 2, 2017 at 8:05 AM, Laurie Alvey trukker41@gmail.com wrote:
Charlie,
+1 Laurie
On 1 June 2017 at 22:10, Andrew Stirling support@calcpay.co.uk wrote:
Care to enlarge on this please.
" Simple file shares (dare I say even "sharepoint"?) make rich client distribution fall-off-a-log easy and secure. "
Andrew Stirling
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[excessive quoting removed by server]
On 6/1/2017 5:10 PM, Andrew Stirling wrote:
Care to enlarge on this please. " Simple file shares (dare I say even "sharepoint"?) make rich client distribution fall-off-a-log easy and secure. "
The basic principle is: - create a "startup" application that checks a "file share" for updates and downloads them (all kinds of ways to do this - I myself never relied on "file timestamps") - the "file share" can be anything: FTP site, even using HTTP, and Sharepoint can be used because you can access files via http links there (although it is a MS product so gotta be careful :) ) - the main app also checks the file share for updates to the "startup" app and downloads as necessary (can't overwrite an .exe in use... well, not easily anyway)
From there you can add all kinds of security checking of the .exe content, etc, to ensure someone did not compromise the file share. And in one very paranoid case, we had a "secret sever" monitoring the "visible/published" file share, comparing it to it's own version - and if something was out of sync, log it, and copy over it from the "secret server". But really, if someone hacked the enterprise network deep enough to copy files around, figuring out where and what .exe to substitute is probably not even a thought.
Using this approach I also added a little logic inside the .exe to detect the operating system version and existence of other resources (one program actually used MS Powerpoint via Automation - to my chagrin... but that's what they wanted). I believe at one time I had an application running on desktops with Windows 98, XP, Vista (which was a pain in the a....), 7, all at the same time.
Compared to browser incompatibilities, bizarre rendering that experts could not figure out, security snafus, and did I mention pathetic performance.... desktop application distribution was a dream.
-Charlie
Le 3 juin 2017 à 00:33, Charlie-gm ccbibleman@gmail.com a écrit :
Compared to browser incompatibilities, bizarre rendering that experts could not figure out, security snafus, and did I mention pathetic performance
browser incompatibilities
Again, this is from the past; except very advanced HTML5/CSS3 features, all browsers now follow the standard, including IE 10+ or Edge
bizarre rendering that experts could not figure out
Your experts were in fact amateurs. Rendering is made by an algorithm based on CSS: the browser’s CSS and your CSS. Each CSS directive has a priority based on specificity and location in the CSS flow. Items can either be rendered top-down or left-right (or RTL) based on the ‘display’ directive; it may also combine with ‘float’ directive that make items flow around others, the kind of option Word offers for images. Each block has a border, a padding and a content. Dimension can be taken either from the border of a block, or for its contents, depending on the ‘box-model’ directive. Once you fully understand the CSS block model and CSS selectors priority rules, you’re able to fully control the rendering. It’s obviously not simple; too many people believe they can just ‘play with CSS’ to make it happen. In fact nothing happens until you fully understand what you’re doing. The CSS you build in fist shot is often quite complex and you need some further refining steps to make it reliable: plain debugging / refactoring, just like you'd do for a professional software. On top of that you can alter rendering using JavaScript (plain or through a framework like jQuery); this again can contradict what CSS does.
Good news: you now have (free) CSS/JS frameworks such as Bootstrap; you just need to follow a standard HTML structure, assign classes like explained and, in most cases, it displays as expected. I write ‘in most cases’ because, here again, and despite the immense quality put into these frameworks, you still need some CSS tweaks to cover all possible use cases.
That’s a classic story: HTML/CSS/JS is a Formula 1 Ferrari that you need years of experience — or having started when you were 14 — to fully master. As any powerful tool, you can do almost anything, provided you reach the suitable level of understanding. If you’re curious, Google the various CSS tricks you can find here and there: for specific situations, some guy spend days to find a simple CSS instruction (or hack), and share with others.
pathetic performance
Here is the truism; running a single application, on the single machine, for a single user, will always be faster that running an application that is shared across users, reachable through a worldwide network, through a bunch of protocols.
The real question is the trade-off between: easily access from anywhere using any device through any browser — desktop and/or handheld without any installation, almost no training, no on-site maintenance, etc. deploying on multiple workstations / synchronising databases across sites (how? security?) / installing RDP and paying for adequate servers, connections and licenses, managing upgrades, forcing users on a specific OS or develop multiple versions across OSs, etc.
Route 2 is what one we’ve practised for years and we know best. Route 1 is what younger generations expect as they’ve been in that bath since there teenage years.
Both routes impose compromises and/or adaptations to go with. Using route 1 requires a ‘lighter’ application, with less controls on each form/page, lighter lists, etc. It’s more a matter of making it smarter than more simple: instead of displaying a full client list in a grid, just add some search/filter controls on top of it (Google-like or enumerated selections) and display the list as soon as the number of records is acceptable instead of a 10-page pageframe with 100 controls in each page, build a container class out of each page and display in a child form. etc.
We need to consider the question from a high level point of view, rather than discussing what alternative desktop dev. language we could choose instead of VFP. The end decider is always the user. Each year 2.5 % new users enter the work force (and almost as many retire) — what do these people expect for the future? That we develop desktop apps in Python rather than VFP?
Thierry Nivelet FoxinCloud Give your VFP app a new life in the cloud http://foxincloud.com/
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
On 6/3/2017 6:05 AM, Thierry Nivelet wrote:
[Lots of text snipped out below - trying to get to just key points]
Compared to browser incompatibilities, bizarre rendering that experts could not figure out, security snafus, and did I mention pathetic performance
browser incompatibilities
Again, this is from the past; except very advanced HTML5/CSS3 features, all browsers now follow the standard, including IE 10+ or Edge
This is not true in my ACTUAL experience. Even inside an huge organization that spends 10's or 100's of millions of dollars a year on internal software development.
And maybe I did not make something clear before: I'm talking about internal enterprise applications. Not "general public" web pages. This thread started with someone asking if anyone is even "looking for" desktop applications any more. And my contention is if users actually saw "rich client/desktop" applications in action, you better believe they'd be begging for more (especially for internal enterprise applications).
bizarre rendering that experts could not figure out
Your experts were in fact amateurs. Rendering is made by an algorithm based on CSS: the browser’s CSS and your CSS. Each CSS directive has a priority based on specificity and location in the CSS flow. Items can either be rendered top-down or left-right (or
And there it is, just like I predicted. Someone would just blame the developers as being stupid and not doing "HTML/CSS/AJAX/.NET?...." correctly. They've been doing it for over 2 decades (25+ years), including big hiring direct out of college where I would think all that grand HTML/CSS/AJAX/.NET "standard" stuff is taught, yes? So if you want to call all those people stupid, ok, fine by me. It does not change the reality of terrible browser-based application results.
pathetic performance
Here is the truism; running a single application, on the single machine, for a single user, will always be faster that running an application that is shared across users, reachable through a worldwide network, through a bunch of protocols. The real question is the trade-off between: easily access from anywhere using any device through any browser — desktop and/or handheld without any installation, almost no training, no on-site maintenance, etc. deploying on multiple workstations / synchronising databases
I'll reiterate I'm talking about internal enterprise applications. Most "public" web pages in the world do work pretty well for a specific purpose such as selling products, information publishing, etc. Internal business applications that attempt to produce a lot of specialized "business logic" value are what fails in my experience. And, from what I've seen, the trend for mobile users IS NOT browser-based any more. They build "custom" (aka rich-client) apps that run on IOS or Android. For example, my bank DOES NOT force me to use their web page on my phone: they created an app for me, as a customer, to use. Why do you think they did that when they already had web pages built?
Anyway, the main point is, inside an enterprise, where desktop configurations are tightly controlled, it really is much more logical, cost-effective, and cheaper to have rich client applications. You can still access the data "from anywhere" - heck, even the internal company web pages cannot be accessed unless I log in through VPN, etc.
And you did agree on a key point, but I'll phrase it a little differently: rich client applications will always perform better than browser based applications. Even going across the web. Because rich client applications, by design, require less "traffic through the wire" - rendering data, script "data", etc. None of that has to be transmitted and then reinterpreted by some intermediary layer (aka a browser). You can just pull "raw" data only. Therefore, rich client will always be faster and yield a better experience to the end user.
And I'm afraid you are wrong regarding "training": the enterprise web pages I've seen require massive training. In fact, most of my time in my current company is "helping" people use the <bleeping> web pages. Surely, you are not saying a hyperlink is "easier to understand" than a button? Of course, any UI can be poor - it's just I've seen the poorest designs in web pages.
discussing what alternative desktop dev. language we could choose instead of VFP. The end decider is always the user. Each year 2.5 % new users enter the work force (and almost as many retire) — what do these people expect for the future? That we
To be clear, I am not pushing for VFP in this thread: in fact, since it is still a closed, proprietary dev tool, I would not recommend it for a new developer. I'm trying to make the conceptual point that rich client applications are better for the user, especially when the platform (aka the PC) is strictly controlled by an enterprise. And it seems quite odd to me that that same strict control cannot yield a consistent browser-application experience.
You ask what will users expect? My answer is they will expect trash if trash is all they ever see. If you show them something responsive and cool, they'll demand that. <shrug> I'm going to test this theory over the next couple months.
The really sad thing is all the 'browser pundits' back in the 1990's promised that web pages would give us "develop once run anywhere" solutions and solve all distribution nightmares (like MS's dll-hell). Well, here we are 25+ years later and those promises have not been kept. We are just now getting close to what we had in the 1990's: that would be hilarious except I see so many "young" developers claim this stuff is fantastic advancements.
Last, I am not saying browser-based applications should be thrown away. They work quite well for some types of needs - selling, publishing, etc: but, inside an enterprise? They are a waste, and a backwards LEAP, from my experience. But like most things in the world, the truth does not really matter much. Gotta go where the "dollars" are. That is a fact I have to learn to live with. It still does not sit well with me though, which is why it triggered all this typing.
-Charlie
Your experience is biased by your rejection of the Web model.
If HTML/CSS was so 'inconsistent' across browsers, frameworks like Bootstrap would be impossible. Bootstrap works perfectly, not only for what you call 'general public' web pages, also for business application, internal or not; on any browser and any device; and is customizable.
If users preferred desktop applications, as you seem to argue, the web-based Salesforce would not have forced the fastest growing company of the 90's -- Siebel systems -- to a quasi bankruptcy in the early 2000's, pushing them to be bought by Oracle.
I'll give you another example from ACTUAL experience: with FoxInCloud we can have the very same application, running the very same code against the very same data, on the desktop and/or in the browser. One of our clients, US based, has such an application. Initially the Web version was designed for the external partners -- suppliers and clients -- to interact with the company. Guess what, nowadays **all employees** of the company use the Web version, though it's undoubtedly slower. They all have a shortcut to the desktop application and no way, they use the web version.
As for large companies investing millions in latest techs, sorry to write that, and I do have an ACTUAL experience with a billion-dollar company, they're just like dinosaurs compared to what startups can achieve.
Thierry Nivelet FoxInCloud Give your VFP app a second life in the cloud http://foxincloud.com/
Le 03/06/2017 à 15:22, Charlie-gm a écrit :
On 6/3/2017 6:05 AM, Thierry Nivelet wrote:
[Lots of text snipped out below - trying to get to just key points]
Compared to browser incompatibilities, bizarre rendering that experts could not figure out, security snafus, and did I mention pathetic performance
browser incompatibilities
Again, this is from the past; except very advanced HTML5/CSS3 features, all browsers now follow the standard, including IE 10+ or Edge
This is not true in my ACTUAL experience. Even inside an huge organization that spends 10's or 100's of millions of dollars a year on internal software development.
And maybe I did not make something clear before: I'm talking about internal enterprise applications. Not "general public" web pages. This thread started with someone asking if anyone is even "looking for" desktop applications any more. And my contention is if users actually saw "rich client/desktop" applications in action, you better believe they'd be begging for more (especially for internal enterprise applications).
bizarre rendering that experts could not figure out
Your experts were in fact amateurs. Rendering is made by an algorithm based on CSS: the browser’s CSS and your CSS. Each CSS directive has a priority based on specificity and location in the CSS flow. Items can either be rendered top-down or left-right (or
And there it is, just like I predicted. Someone would just blame the developers as being stupid and not doing "HTML/CSS/AJAX/.NET?...." correctly. They've been doing it for over 2 decades (25+ years), including big hiring direct out of college where I would think all that grand HTML/CSS/AJAX/.NET "standard" stuff is taught, yes? So if you want to call all those people stupid, ok, fine by me. It does not change the reality of terrible browser-based application results.
pathetic performance
Here is the truism; running a single application, on the single machine, for a single user, will always be faster that running an application that is shared across users, reachable through a worldwide network, through a bunch of protocols. The real question is the trade-off between: easily access from anywhere using any device through any browser — desktop and/or handheld without any installation, almost no training, no on-site maintenance, etc. deploying on multiple workstations / synchronising databases
I'll reiterate I'm talking about internal enterprise applications. Most "public" web pages in the world do work pretty well for a specific purpose such as selling products, information publishing, etc. Internal business applications that attempt to produce a lot of specialized "business logic" value are what fails in my experience. And, from what I've seen, the trend for mobile users IS NOT browser-based any more. They build "custom" (aka rich-client) apps that run on IOS or Android. For example, my bank DOES NOT force me to use their web page on my phone: they created an app for me, as a customer, to use. Why do you think they did that when they already had web pages built?
Anyway, the main point is, inside an enterprise, where desktop configurations are tightly controlled, it really is much more logical, cost-effective, and cheaper to have rich client applications. You can still access the data "from anywhere" - heck, even the internal company web pages cannot be accessed unless I log in through VPN, etc.
And you did agree on a key point, but I'll phrase it a little differently: rich client applications will always perform better than browser based applications. Even going across the web. Because rich client applications, by design, require less "traffic through the wire" - rendering data, script "data", etc. None of that has to be transmitted and then reinterpreted by some intermediary layer (aka a browser). You can just pull "raw" data only. Therefore, rich client will always be faster and yield a better experience to the end user.
And I'm afraid you are wrong regarding "training": the enterprise web pages I've seen require massive training. In fact, most of my time in my current company is "helping" people use the <bleeping> web pages. Surely, you are not saying a hyperlink is "easier to understand" than a button? Of course, any UI can be poor - it's just I've seen the poorest designs in web pages.
discussing what alternative desktop dev. language we could choose instead of VFP. The end decider is always the user. Each year 2.5 % new users enter the work force (and almost as many retire) — what do these people expect for the future? That we
To be clear, I am not pushing for VFP in this thread: in fact, since it is still a closed, proprietary dev tool, I would not recommend it for a new developer. I'm trying to make the conceptual point that rich client applications are better for the user, especially when the platform (aka the PC) is strictly controlled by an enterprise. And it seems quite odd to me that that same strict control cannot yield a consistent browser-application experience.
You ask what will users expect? My answer is they will expect trash if trash is all they ever see. If you show them something responsive and cool, they'll demand that. <shrug> I'm going to test this theory over the next couple months.
The really sad thing is all the 'browser pundits' back in the 1990's promised that web pages would give us "develop once run anywhere" solutions and solve all distribution nightmares (like MS's dll-hell). Well, here we are 25+ years later and those promises have not been kept. We are just now getting close to what we had in the 1990's: that would be hilarious except I see so many "young" developers claim this stuff is fantastic advancements.
Last, I am not saying browser-based applications should be thrown away. They work quite well for some types of needs - selling, publishing, etc: but, inside an enterprise? They are a waste, and a backwards LEAP, from my experience. But like most things in the world, the truth does not really matter much. Gotta go where the "dollars" are. That is a fact I have to learn to live with. It still does not sit well with me though, which is why it triggered all this typing.
-Charlie
[excessive quoting removed by server]
On Jun 3, 2017, at 1:46 PM, Thierry Nivelet tnivelet@foxincloud.com wrote:
One of our clients, US based, has such an application. Initially the Web version was designed for the external partners -- suppliers and clients -- to interact with the company. Guess what, nowadays **all employees** of the company use the Web version, though it's undoubtedly slower. They all have a shortcut to the desktop application and no way, they use the web version.
Years ago I had a VFP client who ran an inventory system I had helped to write. I had an opportunity to visit the site once, and in the warehouse they had a PC at several locations for the workers to enter their information. Since it was a dusty place, the PC and keyboard were covered with these yellowing plastic covers. The workers would fill their order, then find the nearest PC and enter what they did.
Thinking about that now, imagine if they could have had a mobile device, such as a tablet or smartphone, and could have entered their information as they filled their order, instead of having to go to one of the PCs nearby. If I were to create an inventory system like that today, there is no way that I would for a second consider creating a desktop app. Mobile capabilities are critical in most things, whether an inventory system for a warehouse, or a POS system for a small business. I went to the local farmer's market this morning, and many of the vendors had tablet-based systems that took credit cards. You just can't do things like that with a PC-only app.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature ---
As always it's horses for courses! The major benefit of bespoke systems is that they can be tailored to suit the task and there are undoubtedly some where the web application is best and others where a desktop application wins.
John
John Weller 01380 723235 079763 93631 Sent from my iPad
On 4 Jun 2017, at 04:29, Ed Leafe ed@leafe.com wrote:
On Jun 3, 2017, at 1:46 PM, Thierry Nivelet tnivelet@foxincloud.com wrote:
One of our clients, US based, has such an application. Initially the Web version was designed for the external partners -- suppliers and clients -- to interact with the company. Guess what, nowadays **all employees** of the company use the Web version, though it's undoubtedly slower. They all have a shortcut to the desktop application and no way, they use the web version.
Years ago I had a VFP client who ran an inventory system I had helped to write. I had an opportunity to visit the site once, and in the warehouse they had a PC at several locations for the workers to enter their information. Since it was a dusty place, the PC and keyboard were covered with these yellowing plastic covers. The workers would fill their order, then find the nearest PC and enter what they did.
Thinking about that now, imagine if they could have had a mobile device, such as a tablet or smartphone, and could have entered their information as they filled their order, instead of having to go to one of the PCs nearby. If I were to create an inventory system like that today, there is no way that I would for a second consider creating a desktop app. Mobile capabilities are critical in most things, whether an inventory system for a warehouse, or a POS system for a small business. I went to the local farmer's market this morning, and many of the vendors had tablet-based systems that took credit cards. You just can't do things like that with a PC-only app.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/signed text/plain (text body -- kept) application/pgp-signature
[excessive quoting removed by server]
That's the point I was trying to make. As of today trying to implement everything in a browser remains impractical for many use cases. For many others it is ideal.
Hi Alan,
I wish you could be a little more specific so that we can learn from your facts and figures.
What I can say for sure, as it's real life, current experience, that a biological analysis company, client of FoxInCloud, manages ALL its operations, end to end from order entry to accounting, including capturing measures from its bio analysis devices, through a web app running on a remote server (only desktops and internet connection in the premises); 100k patients, 250k 'orders' (MD ordonnances), 2M 'order lines' (unit examination), 70 forms, 50 reports, 300 users
Why? To get rid of the installation / maintenance / versioning hassles, and set up news labs quicker (developing country).
Grids and data are the only limiting factor we've seen so far, that requires some workaround: - more than 3 grids on the same form: move to subforms - more than 1000 lines in a grid: use the grid pager supplied with FoxInCloud. - light views that take more than .2 sec. to requery: use a cursor instead; if view is updateable, use getfldstate and update back end yourself
Especially when updateable, grids almost count for as many controls as the number of cells in it: takes some server time to manage the state.
Thierry Nivelet http://foxincloud.com/ Give your VFP app a second life in the cloud
Le 4 juin 2017 à 11:47, Alan Bourke alanpbourke@fastmail.fm a écrit :
trying to implement everything in a browser remains impractical for many use cases
This is a similar argument as the one about 20 years ago as to whether posting into tables interactively was preferable to posting transactions in the traditional mainframe batches.
I hated Sage and other "post it now" accounting systems at first but as hardware and network reliability improved this is now the defacto standard for most software.
I guess we are suffering from dinosaur syndrome to a certain extent in that old habits die hard....
(Retreats back into his stone age cave)
Dave
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Thierry Nivelet Sent: 05 June 2017 10:18 To: profox@leafe.com Subject: Re: [NF] PyQT for desktop applications
Hi Alan,
I wish you could be a little more specific so that we can learn from your facts and figures.
What I can say for sure, as it's real life, current experience, that a biological analysis company, client of FoxInCloud, manages ALL its operations, end to end from order entry to accounting, including capturing measures from its bio analysis devices, through a web app running on a remote server (only desktops and internet connection in the premises); 100k patients, 250k 'orders' (MD ordonnances), 2M 'order lines' (unit examination), 70 forms, 50 reports, 300 users
Why? To get rid of the installation / maintenance / versioning hassles, and set up news labs quicker (developing country).
Grids and data are the only limiting factor we've seen so far, that requires some workaround: - more than 3 grids on the same form: move to subforms - more than 1000 lines in a grid: use the grid pager supplied with FoxInCloud. - light views that take more than .2 sec. to requery: use a cursor instead; if view is updateable, use getfldstate and update back end yourself
Especially when updateable, grids almost count for as many controls as the number of cells in it: takes some server time to manage the state.
Thierry Nivelet http://foxincloud.com/ Give your VFP app a second life in the cloud
Le 4 juin 2017 à 11:47, Alan Bourke alanpbourke@fastmail.fm a écrit :
trying to implement everything in a browser remains impractical for many use cases
_______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/E9242B2A-0710-415E-AF6C-CE8342559981@... ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
On Mon, Jun 5, 2017 at 9:00 AM, Dave Crozier DaveC@flexipol.co.uk wrote:
This is a similar argument as the one about 20 years ago as to whether posting into tables interactively was preferable to posting transactions in the traditional mainframe batches.
I hated Sage and other "post it now" accounting systems at first but as hardware and network reliability improved this is now the defacto standard for most software.
I guess we are suffering from dinosaur syndrome to a certain extent in that old habits die hard....
(Retreats back into his stone age cave)
Are you calling us old?
Bad __Steve
Thierry
Why? To get rid of the installation / maintenance / versioning hassles, and set up news labs quicker (developing country).
Absolutely a big advantage of the browser-centric application, in a single-tenant installation at least.
You say 50 reports - how do you implement that? Render to PDF and let the browser handle it from there? How do you design them?
What if you needed to access local printers or file systems directly?
We are retiring many of our reports in SSRS and replacing them with Data Cube access to the data. We had 140 reports at last upgrade in 2015 and now planning for our next upgrade that number will fall to 50-60. All the data is crunched in Excel at the user's need.
BI is such a major aspect of business nowadays. Keeping your customers current in information is helpful in keeping customers as well as getting new ones.
On Mon, Jun 5, 2017 at 10:01 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
Thierry
Why? To get rid of the installation / maintenance / versioning hassles, and set up news labs quicker (developing country).
Absolutely a big advantage of the browser-centric application, in a single-tenant installation at least.
You say 50 reports - how do you implement that? Render to PDF and let the browser handle it from there? How do you design them?
What if you needed to access local printers or file systems directly?
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
PDF displayed in either a sub form within the same tab, a new tab or a new browser window
http://foxincloud.com/tutotest/report.tuto
Thierry Nivelet http://foxincloud.com/ Give your VFP app a second life in the cloud
Le 5 juin 2017 à 17:51, Stephen Russell srussell705@gmail.com a écrit :
We are retiring many of our reports in SSRS and replacing them with Data Cube access to the data. We had 140 reports at last upgrade in 2015 and now planning for our next upgrade that number will fall to 50-60. All the data is crunched in Excel at the user's need.
BI is such a major aspect of business nowadays. Keeping your customers current in information is helpful in keeping customers as well as getting new ones.
On Mon, Jun 5, 2017 at 10:01 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
Thierry
Why? To get rid of the installation / maintenance / versioning hassles, and set up news labs quicker (developing country).
Absolutely a big advantage of the browser-centric application, in a single-tenant installation at least.
You say 50 reports - how do you implement that? Render to PDF and let the browser handle it from there? How do you design them?
What if you needed to access local printers or file systems directly?
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
FWIW, Web and/or FoxinCloud supports this scénario
Thierry Nivelet http://foxincloud.com/ Give your VFP app a second life in the cloud
Le 5 juin 2017 à 17:51, Stephen Russell srussell705@gmail.com a écrit :
We are retiring many of our reports in SSRS and replacing them with Data Cube access to the data. We had 140 reports at last upgrade in 2015 and now planning for our next upgrade that number will fall to 50-60. All the data is crunched in Excel at the user's need.
BI is such a major aspect of business nowadays. Keeping your customers current in information is helpful in keeping customers as well as getting new ones.
On Mon, Jun 5, 2017 at 10:01 AM, Alan Bourke alanpbourke@fastmail.fm wrote:
Thierry
Why? To get rid of the installation / maintenance / versioning hassles, and set up news labs quicker (developing country).
Absolutely a big advantage of the browser-centric application, in a single-tenant installation at least.
You say 50 reports - how do you implement that? Render to PDF and let the browser handle it from there? How do you design them?
What if you needed to access local printers or file systems directly?
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
Browser can only access printers.
It may propose user to save a file, the latter decides where
Thierry Nivelet http://foxincloud.com/ Give your VFP app a second life in the cloud
Le 5 juin 2017 à 17:01, Alan Bourke alanpbourke@fastmail.fm a écrit :
Thierry
Why? To get rid of the installation / maintenance / versioning hassles, and set up news labs quicker (developing country).
Absolutely a big advantage of the browser-centric application, in a single-tenant installation at least.
You say 50 reports - how do you implement that? Render to PDF and let the browser handle it from there? How do you design them?
What if you needed to access local printers or file systems directly?
-- Alan Bourke alanpbourke (at) fastmail (dot) fm
[excessive quoting removed by server]
On 6/3/2017 11:29 PM, Ed Leafe wrote:
On Jun 3, 2017, at 1:46 PM, Thierry Nivelet tnivelet@foxincloud.com wrote:
One of our clients, US based, has such an application. Initially the Web version was designed for the external partners -- suppliers and clients -- to interact with the company. Guess what, nowadays **all employees** of the company use the Web
I built something like this in VFP several years ago.
Remember when those "small form" laptops first came out? One of them was EE PC or something like that: running Windows XP and I think a 9 inch screen (nifty little devices: 8 hour battery life easy, quick "suspend/resume" - as in close the lid, open the lid). In this case they were driving around neighborhoods checking houses, etc. The app could use the built-in camera to take pictures, manage notes, get special instruction, blah blah blah. The system would connect to wifi if available, otherwise it would just "buffer up" the info until the wifi was detected. A background app took care of syncing stuff they did or stuff they needed.
We could have done a full-on web-enabled app but the owner did not want to initially spend the money on the cellular cards and service <shrug>. There would have been a lot of other cool things that could have been done with an always-on internet connection. Anyway, it worked great and the users really liked the sub-second response time on the functions in the application.
-Charlie
On 6/3/2017 2:46 PM, Thierry Nivelet wrote:
Your experience is biased by your rejection of the Web model.
If HTML/CSS was so 'inconsistent' across browsers, frameworks like Bootstrap would be impossible. Bootstrap works perfectly, not only for what you call 'general public' web pages, also for business application, internal or not; on any browser and any device; and is customizable.
What do you want? Should I itemize the inconsistencies that I've seen between browsers and even the same browser between applications? It is pretty rude to say someone's "experience" is biased. That's like saying I cannot see what is clearly in front of my face. I definitely admit I have biases, but I do know how to make observations and listen to people - especially when it is part of my job assignment. And I thought it was pretty clear I did NOT uniformly reject the Web model. I've developed many applications that USE the Internet - just not within a browser. Perhaps you are the one that is biased because you want everyone to buy your "browser based" product?
And this has nothing to do with a particular Web framework. Maybe the dev teams are using .Net, maybe JBOSS, maybe JQuery, maybe something else. Would you prefer to retract your previous statement that the developers are CSS dummies (paraphrased) and say instead the enterprise is stupid because it has not standardized on Bootstrap?
If users preferred desktop applications, as you seem to argue, the web-based Salesforce would not have forced the fastest growing company of the 90's -- Siebel systems -- to a quasi bankruptcy in the early 2000's, pushing them to be bought by Oracle.
I seriously doubt a "browser app" is what gave one company a boost over another. More likely they had a better centralized data model and feature set. Or maybe the loser just had a snobbier attitude toward clients: that seems to be a frequent issue.
I'll give you another example from ACTUAL experience: with FoxInCloud we can have the very same application, running the very same code against the very same data, on the desktop and/or in the browser. One of our clients, US based, has such an
If you are saying the users have access to a "rich client" application and a "browser based" application, and those applications look almost identical, and those applications have the same functions, and those applications access same data, and that the browser-based application is slower. I find it very hard to believe the end users would prefer the browser-based application if they knew the desktop one was available. I am pretty confident that the user base at my organization would be exclusively using the rich client one. A constant complaint I hear from users at my company is the applications (all browser-based) are too <bleeping> slow - which is why they just jump to the Excel-export function and do their work in Excel (which, as a side note, I think is pure poison to an enterprise - spreadsheets should be out-right banned - they create islands of information, protected data-turfs, etc.... but getting rid of spreadsheets is s a difficult sell to users while all the <bleeping> browser-based applications are so <bleeping> slow).
As for large companies investing millions in latest techs, sorry to write that, and I do have an ACTUAL experience with a billion-dollar company, they're just like dinosaurs compared to what startups can achieve.
So, what the hell, lets be clear. I'm talking about AT&T: that's the company I'm working for now. So they're at 150+B/yr I think. They are not a software company (although they claim they have made the transition). And because of their size they spend far more on software projects that most software-exclusive companies. And ooooooh yes, they are a dinosaur (I find it ironic that Bell-labs gave the world "Unix" - and compare that to AT&T today <g>). They have horrific, terrible, software development practices which I'm trying to help change (<picture of me with an eye-dropper of water in front of a 10,000 acre forest fire>). And even AT&T is now taking a lot of their web pages and creating "rich client" apps out of them for mobile devices (so yeah, repeating the creation and maintenance of "GUI" programming 3 or more times over). Of course, even if "desktop" designs would be the standard, that multiplicity would still have happened because of major platform differences. But the point is "browser world" promised we would never have to do that again. They LIED!!!! (hahahaha, just kidding, it was more naive thinking than malicious intent to get paid to do the same thing over and over again... well, at least I hope "most" people were not thinking that).
But remember what started this thread: "... does anyone even look for desktop applications any more..." I rephrased that to "rich client" applications because I think that is the really the point. And I think that yes indeed, those kinds of applications are very much in demand - if the user base knows they could get them. And from a technical point of view, there really is no reason to NOT do rich client applications. But you have to consider the context: if I want to publish some products for people to buy, or I want to publish my vacation video, or I want to put a whitepaper up on a blog... all those are really great fits for brower-based code. But if performance is important for the user, or if reducing network traffic is important, or if server load is desired to be minimized, those are great fits for rich client applications.
Anyway, I'm out. Enough time spent on this thread for me. I will do my little experiment over the next few months and drop a note to the list regarding the results: did the users prefer browser-based, or desktop-based for my application.
-Charlie
On 6/3/2017 2:46 PM, Thierry Nivelet wrote:
Your experience is biased by your rejection of the Web model.
If HTML/CSS was so 'inconsistent' across browsers, frameworks like Bootstrap would be impossible. Bootstrap works perfectly, not only for what you call 'general public' web pages, also for business application, internal or not; on any browser and any device; and is customizable.
What do you want? Should I itemize the inconsistencies that I've seen between browsers and even the same browser between applications? It is pretty rude to say someone's "experience" is biased. That's like saying I cannot see what is clearly in front of my face. I definitely admit I have biases, but I do know how to make observations and listen to people - especially when it is part of my job assignment. And I thought it was pretty clear I did NOT uniformly reject the Web model. I've developed many applications that USE the Internet - just not within a browser. Perhaps you are the one that is biased because you want everyone to buy your "browser based" product?
And this has nothing to do with a particular Web framework. Maybe the dev teams are using .Net, maybe JBOSS, maybe JQuery, maybe something else. Would you prefer to retract your previous statement that the developers are CSS dummies (paraphrased) and say instead the enterprise is stupid because it has not standardized on Bootstrap?
If users preferred desktop applications, as you seem to argue, the web-based Salesforce would not have forced the fastest growing company of the 90's -- Siebel systems -- to a quasi bankruptcy in the early 2000's, pushing them to be bought by Oracle.
I seriously doubt a "browser app" is what gave one company a boost over another. More likely they had a better centralized data model and feature set. Or maybe the loser just had a snobbier attitude toward clients: that seems to be a frequent issue.
I'll give you another example from ACTUAL experience: with FoxInCloud we can have the very same application, running the very same code against the very same data, on the desktop and/or in the browser. One of our clients, US based, has such an
If you are saying the users have access to a "rich client" application and a "browser based" application, and those applications look almost identical, and those applications have the same functions, and those applications access same data, and that the browser-based application is slower. I find it very hard to believe the end users would prefer the browser-based application if they knew the desktop one was available. I am pretty confident that the user base at my organization would be exclusively using the rich client one. A constant complaint I hear from users at my company is the applications (all browser-based) are too <bleeping> slow - which is why they just jump to the Excel-export function and do their work in Excel (which, as a side note, I think is pure poison to an enterprise - spreadsheets should be out-right banned - they create islands of information, protected data-turfs, etc.... but getting rid of spreadsheets is s a difficult sell to users while all the <bleeping> browser-based applications are so <bleeping> slow).
As for large companies investing millions in latest techs, sorry to write that, and I do have an ACTUAL experience with a billion-dollar company, they're just like dinosaurs compared to what startups can achieve.
So, what the hell, lets be clear. I'm talking about AT&T: that's the company I'm working for now. So they're at 150+B/yr I think. They are not a software company (although they claim they have made the transition). And because of their size they spend far more on software projects that most software-exclusive companies. And ooooooh yes, they are a dinosaur (I find it ironic that Bell-labs gave the world "Unix"
- and compare that to AT&T today <g>). They have horrific, terrible,
software development practices which I'm trying to help change (<picture of me with an eye-dropper of water in front of a 10,000 acre forest fire>). And even AT&T is now taking a lot of their web pages and creating "rich client" apps out of them for mobile devices (so yeah, repeating the creation and maintenance of "GUI" programming 3 or more times over). Of course, even if "desktop" designs would be the standard, that multiplicity would still have happened because of major platform differences. But the point is "browser world" promised we would never have to do that again. They LIED!!!! (hahahaha, just kidding, it was more naive thinking than malicious intent to get paid to do the same thing over and over again... well, at least I hope "most" people were not thinking that).
But remember what started this thread: "... does anyone even look for desktop applications any more..." I rephrased that to "rich client" applications because I think that is the really the point. And I think that yes indeed, those kinds of applications are very much in demand - if the user base knows they could get them. And from a technical point of view, there really is no reason to NOT do rich client applications. But you have to consider the context: if I want to publish some products for people to buy, or I want to publish my vacation video, or I want to put a whitepaper up on a blog... all those are really great fits for brower-based code. But if performance is important for the user, or if reducing network traffic is important, or if server load is desired to be minimized, those are great fits for rich client applications.
Anyway, I'm out. Enough time spent on this thread for me. I will do my little experiment over the next few months and drop a note to the list regarding the results: did the users prefer browser-based, or desktop-based for my application.
-Charlie
On May 29, 2017, at 7:50 AM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:
I'm getting ready to do some Python learning on PluralSight.com http://pluralsight.com/ and the dude mentioned PyQT for desktop applications.
Ed & Paul (and others) -- your thoughts on that? Was interested in your take since you did Dabo for desktop applications with Python.
When we created Dabo way way back in 2004 (!) Qt was only available under a commercial license, so while it looked nice, we passed on it in favor of wxPython. Since then they have released a “free” version that while you don’t pay to use it in some circumstances, it doesn’t come with an open license. I haven’t played around with it very much, so I don’t have an opinion on how working with it would be.
And yeah, it is 2017 now, and most of the demand I see is not only for web-based apps, but also mobile-aware web apps. I’m sure that there are people who still want desktop apps, but then again, there are still people running Windows XP.
-- Ed Leafe
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---
On 2017-05-30 08:51, Edward Leafe wrote: <snipped>
And yeah, it is 2017 now, and most of the demand I see is not only for web-based apps, but also mobile-aware web apps. I’m sure that there are people who still want desktop apps, but then again, there are still people running Windows XP.
Yes, it seems like everybody wants web apps...and honestly, it seems like sometimes for intracompany items, a web app isn't needed but still, that's what they want. That said, in 2017, I think you could still argue that a more productive UI could be built for a desktop app, "but that's not cool."
-
Alan Bourke -
Andrew Stirling -
Charlie-gm -
Dave Crozier -
Ed Leafe -
Edward Leafe
-
Fred Taylor -
Jean Laeremans -
John Weller -
Laurie Alvey -
Malcolm Greene -
mbsoftwaresolutions＠mbsoftwaresolutions.com -
Paul H. Tarver -
Stephen Russell -
Thierry Nivelet