[BangPypers] What are you using for developing desktop GUIs?

[BibhasD]

Maybe that's another way of looking at it. It's introducing network 
related issues when we should be concentrating on building the app that 
has nothing to do with network, right?

> That is definitely very true. But in this day and age of html5 boilerplate,
> twitter bootstrap, jquery, etc. this particular problem can be considered
> well under control.

IMO, you can never trust the user system too much. It is a possible 
case that the user system doesn't have a browser installed, right? 
What'd happen then? Any fallback mechanism?

On Saturday 28 September 2013 12:04:40 AM IST, Gopalakrishnan Subramani 
wrote:
> I have spent 10+ years of Desktop app development using VC++/.NET, mostly
> on Windows. After Windows XP SP 3 onwards, Microsoft changed the
> application installation and execution architecture, specifically the
> socket servers, firewall, administrator rights etc.
>
> We have WCF Web Service (part of MS .NET framework), which was running on
> TCP/IP, we have so much of trouble when users install application on their
> machines.
>
> Basic issues are listed here, which are difficult for common users to deal.
>
> 1. Anti-virus apps block the socket/outgoing emails/application altogether
> 2. Firewall blocks the binding to port, incoming/outgoing connections.
> 3. End user shall not have admin rights to install/run the server
> applications that especially binds to socket server.
> 4. Socket port number could have been bind  by other process, so we get
> port bind exceptions.
>
> None of above are not part of our application, but affected by external
> world. Situation is completely based on what user had before, what is there
> right now, what he/she might have later.
>
> On Windows, we use WCF Named Pipe binding now. No more socket related
> issues. During installation, we install our server as Windows Service with
> admin rights which uses named pipe (using GUID + some strong identity
> options for naming pipe).
>
> --
>
> Krish
>
>
>
>
>
>
>
>
>
> On Fri, Sep 27, 2013 at 10:20 PM, Dhananjay Nene
> <dhananjay.nene at gmail.com>wrote:
>
>> On Fri, Sep 27, 2013 at 10:04 PM, Sriram Karra <karra.etc at gmail.com>
>> wrote:
>>> On Fri, Sep 27, 2013 at 8:55 PM, Dhananjay Nene <
>> dhananjay.nene at gmail.com>wrote:
>>>
>>>
>>>>
>>>> In most cases I find users want a installer. Basically just point and
>>>> click. So if there is no installer where a user selects a install
>>>> directory and presses a button called install (and perhaps a couple of
>>>> app specific items), there's a huge support cost due to users being
>>>> not able to install apps successfully. I presume what you mean by a
>>>> standard python application, but if it means a user having to install
>>>> python if not installed, create a virtualenv, run pip install, create
>>>> desktop shortcuts to start / stop servers, in most cases it is very
>>>> very unlikely to work with lay end users. (Much of this applies to
>>>> desktop based apps as well).
>>>>
>>>
>>>
>>> None of that pip/virtualenv stuff is required. There are tools available
>>> that can convert a python application into a native executable - py2exe
>> for
>>> windows, and py2app mac, for. e.g. Once you have the native, self
>> contained
>>> executables, they can be wrapped into a msi or dmg package like any other
>>> native application.
>>>
>> Ok. I haven't tried them myself ever :( Though usually there's more
>> required during installation (eg. where does the program get installed
>> what directory should data go to etc. Not sure if these get addressed
>> by these. Perhaps there are standard python ways to deal with all such
>> issues that I am unaware of.
>>
>>> When I said the embedded webapp is like any other python application I
>>> wanted to say that the above packaging options area available for a
>> webapp
>>> as well - because all the code is pure python and is completely self
>>> contained. I hope that was clear.
>>>
>> It wasn't to me, but that could be my shortcoming.
>>>
>>>>
>>>>> I have not done this. The invocation is explicitly on demand. It is
>>>> trivial
>>>>> to protect against multiple invocations of the program, and to
>> support a
>>>>> 'Exit Program' action on the front end that will shut down the web
>>>> server.
>>>>
>>>> Ok. I've never tried this. Perhaps it is trivial. But shutting down a
>>>> server even as the controller is processing a request may
>>>> "potentially" be hard. Perhaps one could set a timeout to allow the
>>>> request to complete and then trigger a shutdown.
>>>>
>>>
>>>
>>> You should definitely fire up the PRS program below, and look at how the
>>> shutdown action is triggered and handled in the controller. My guess is
>> you
>>> will find it very straightforward.
>>>
>> Ok.
>>>
>>>
>>>>>
>>>>> It is as easy as any other program. To give you an example, take a
>> look
>>>> at
>>>>> a sample: https://github.com/skarra/PRS
>>>>
>>>> Ok, I am not particularly familiar with how the windows integration
>>>> works so am not able to quickly figure it out.
>>>>
>>>
>>>
>>> There is no windows integration of any sort here. If you are using python
>>> on Windows already, just clone that repo and double click on the file
>>> called prs.pyw -> that is all you need to start the program.
>>>
>> Haven't used windows in ages :(
>>>
>>>
>>>> The difficulty is that the user may have multiple versions of python
>>>> installed and/or his default version may not be compatible with the
>>>> one you want. Plus virtualenv specific for your app will need to be
>>>> configured.
>>>>
>>>
>>>
>>> As explained above, the py2exe / py2app type programs are able to make
>>> completely self contained native executables.
>>>
>>>
>>>>
>>>> You did mention reusable code. Service integration, system tray
>>>> integration etc. are all cross platform issues that are introduced
>>>> when you install a web app on a desktop
>>>
>>>
>>>
>>> I do not know if there are any cross-platform python libraries that take
>>> care of issues such as this. I will only say that the webapp approach to
>>> cross-platform UI programming does not put you at any greater
>> disadvantage
>>> than using a UI toolkit. Remember the original topic was discussion on UI
>>> toolkits!
>>>
>> My point was that service and system tray integration are usually not
>> required for desktop apps. But if your webapp is going to be
>> explicitly started and stopped by user, it may not be required by such
>> webapps as well.
>>>
>>> You also open yourself up to cross browser portability issues. Also
>>>> having to deal with older vs newer browsers (IE6??). Which if you were
>>>> using a standard widget library wouldn't have worried you.
>>>>
>>>
>>>
>>> That is definitely very true. But in this day and age of html5
>> boilerplate,
>>> twitter bootstrap, jquery, etc. this particular problem can be considered
>>> well under control.
>>>
>>>
>>>>
>>>> At the minimum you have an open port. You probably need to restrict
>>>> traffic only from localhost.
>>>
>>>
>>>
>>> Yes, and this is done very easily, I am sure agree.
>> Yes.
>>>
>>>
>>>> In addition you need to worry about SQL
>>>> injection, XSS, XSRF, and a bunch of other alphabet soup combinations.
>>>>
>>>
>>>
>>> I would image these are all non-issues if you reject all connections not
>>> from localhost as discussed above?
>> I am afraid not.
>>>
>>>
>>> I don't mean to suggest it is wrong or inappropriate to use webapps as
>>>> desktop apps. But just wanted to point out there are a whole bunch of
>>>> counter issues as well that need to be dealt with.
>>>>
>>>
>>>
>>> Absolutely. It is definitely constructive and instructive to think about
>>> all angles - even if just to understand the limits of a given approach.
>>> Thank you for this conversation.
>> The pleasure's mutual. I learnt a few things along the way.
>>
>> Dhananjay
>> _______________________________________________
>> BangPypers mailing list
>> BangPypers at python.org
>> https://mail.python.org/mailman/listinfo/bangpypers
>>
> _______________________________________________
> BangPypers mailing list
> BangPypers at python.org
> https://mail.python.org/mailman/listinfo/bangpypers