"Nick Vatamaniuc" <[EMAIL PROTECTED]> wrote:
|HJ, | |As far as GUI language/library goes: | |Some people suggested HTML, but I think HTML is a very awkward way to |create a good looking dynamic GUI that is _both_ easy to use and fast |and easy to design (which is what you would want probably). Just to |have a nice user editable table for example, you would have to jump |through hoops (using Javascript, DOM, CSS etc), while you could do it |much easier with PyGTK and wxPython, especially if you use a gui |designer like Glade or wxGlade. Even Tkinter beats HTML as far as |building GUIs in Python goes. I believe this might change in the future |with the adaption of SVG but that will take a while... That said, if |your interface can "get by" with just buttons, text boxes, and text |areas HTML will be the best choice. | At the moment my toy system just uses Tkinter- Buttons, Labels, Entry boxes and Listboxes (which I populate from a dict) - and it has logic in it to do only one dummy transaction, which I just ship to the server machine where nothing happens - it is just echoed back to the client which prints it on stdout - If I stay with this it will be a most uninteresting GUI - but that is not the point at issue now... | |As far as "updating-on-the-fly" goes: | |For the client to get the code on the fly you will have to implement |some sort of a downloader in the first place that when the user logs |in, it downloads the GUI code from the server and runs it. So if you |update the code the day before the next day they will get a different |interface, or if a new user/machine type is created you just have the |new code ready on the server and it will automatically be downloaded |and run, is that right? | This is broadly what I had in mind, yes - but sort of down to a transaction level - this user does invoicing, this one enters cheques, this one does credit notes, and their supervisor can do all three, and in a different department its different because the jobs are different, but the invoicing GUI module is the same for wherever its used... |Here is then how I see your use case: |1) You would define your business rules in your database, you will have |usernames, user types, access rights, data tables, columns types, |relations, views, etc... Yes no matter how you do it, you need to keep a per user or per machine set of what can be done. - in banking terms - a sort of Terminal Management System... My thinking is simpler than this, because you are already thinking in "data base speak" - now dont get me wrong - I realise that I will have to use a database - but for me to start thinking in terms of views and stuff is kind of premature when I dont even have a clear picture in my head of the kind of data the said management system should keep, as I am not sure of what can, and cannot be done. |2) Then each user type will have a specific interface GUI code kept on |the server (perhaps as a zipped binary GUI.zip in a database column |called ClientSpecificGUI). I would like to split this down further - see above - so for each user there is a sort of *pointer* to each of the kinds of transactions she can do, and these are shipped separately and *linked* at the client side... |3) The client starts your Application.py which is the same across all |clients. They will enter their username/password. The Application.py |then sends those to the server to log into the DB. *nods* |4) After successful login, the Application.py performs a SELECT query |to download the zipped GUI.py file. |5) GUI.py is unzipped and executed to start the GUI. The Application.py |code will pass the DB connection object to the GUI.py, so the GUI can |continue to talk with the database. GUI.py runs and does its magic, in |the meantime Application.py waits for GUI.py to finished and then both |exit. |Is that what you had in mind? Very close - I have not even thought this far - I did not think of building a GUI for each user, I thought of building it for each transaction - kind of a series of things like my toy - and then I got stuck on the "linking the separate transaction guis into an app on the fly" bit, which is why I started the thread - I really want to know if it is possible to do this sort of thing in Python, and so far Bruno has come up with Pyro, while everybody else (including Bruno) is beating me over the head with HTML Now part of the reason I would like to go the transaction type route instead of the "per user" route is robustness and maintainability, and the ability it would give me to introduce new transaction types easily - as I see it if say an invoice's GUI code is stable I would never have to touch it again even if I combine it with anything else, as it would have been designed from the start to combine with others of it's own ilk, under a kind of communications controller that is standard... |NOTE: This means that the client will need to have all the required |libraries at just the right versions. Imagine that your user decides to |upgrade to Python 3000 because it sounds cooler than plain old Python |2.4 ;) , but then they won't realize that it will break your code and |they might not be able to run your application anymore. So you would |have to know at least roughly how much control over the whole client |machine you will have. Will they all be regular desktops that users |will use day to day and then once in a while launch your application |then close it, or will these all be dedicated terminals like an ATM? |The two are very different. You can assume complete control of all the |OS environment in a dedicated terminal but not in the case of a user |desktop. True - have not even considered this - this would, I imagine, vary from site to site, and depend more on local IT policy - this is probably the strongest argument to date against going this route, as these machines would not be as tightly controlled as an ATM... but then - If I want to use Python in the client at all, I would have to somehow come to terms with this - its more the normal sort of version control that would have to be done - after all if a user's machine is an XT running DOS - then its going to have to be upgraded before it can be used as a terminal... So this is more an argument against the use of Python on the client and I don't like that... |Hope this helps, |Nick Vatamaniuc 8<---------------------------------------------------- Yes it does, Thanks. I feel we are getting closer to the point where I can decide if what I am thinking of is practical or a pipe dream - it sounded so simple - make a series of guis for a series of transactions, ship them to the client, where there is a simple top level thingy that swallows them and ties them all together and handles the comms to the server... I mean the language is called Python... :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
