Announcement

Collapse
No announcement yet.

An alternative approach to GUI!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Siamack Yousofi
    replied
    Rodney

    Technically any browser-based application should work. The concept is
    to use a light-weight local web server, like the one Erik Olsen posted
    in the source-code forum some time ago, and extend it with your application's
    logic while using the browser as the front end.

    Florent have done some excellent work in this area and there is a link
    posted a few messages above.

    Siamack

    P.S. You can download Erik's code from the download area.
    http://www.powerbasic.com/files/pub/pbwin/inet/

    Look for http.zip

    ------------------


    [This message has been edited by Siamack Yousofi (edited June 13, 2001).]

    Leave a comment:


  • Rodney Wirtz
    replied
    Siamack,

    Cool idea...

    What about using a Flash as the front-end user-interface and
    have PBCC in the background feeding all the info to flash.

    Macromedia has a program call Generator (a small version ships
    with Flash 5) that leaves place holders in Flash movies for
    information that PBCC could possibly fill.

    I don't know enough about the ins and outs of Flash and Generator
    to know if this would be possible or if it makes sense.

    I use Flash for website opening screens and it's really neat. One
    may be able to use it to make very interesting dynamic user interfaces.

    Rodney...


    ------------------

    Leave a comment:


  • Fred Lampart
    replied
    Siamack,

    I'm intrigued with your idea about using a browser (as an
    alternative to learning Windows programming) to allow a
    PB DOS program to run in a Windows "like" environment.

    Could you please send me your email address; I'd like to discuss
    this with you ...

    Fred
    Email: [email protected]


    ------------------

    Leave a comment:


  • Fred Lampart
    replied
    Originally posted by Siamack Yousofi:
    Ladies and Gentlemen

    As Black Adder used to say, "I have a cunning plan” and thought you might find it useful.

    Unfortunately I cannot post any code as my work belongs to my employer. However, I came up with the original idea before he hired me. Since he refuses to look at Powerbasic then I guess it is his loss. <IMG SRC="http://www.powerbasic.com/support/forums/supergrin.gif">

    I will explain the concept in broad terms and then you are on your own. Some feedback would be nice.

    When speed of the GUI is not an issue we can use a web browser as our GUI front-end. Here is how…

    We write all the application's logic in Powerbasic and compile it into an .exe. When the plication is invoked, it will show a very simple Dialog/Splash screen (simple stuff in DDT). If necessary, we ask for username and password here. Then the program will detect and show the IP address of the PC (in large friendly letters ). The program then invokes the browser and “serves” a “default.html” file to the browser and minimises itself. What is in the browser is our application’s main “screen”.

    The program then enters the main loop and monitors “Port 80” for user interaction. The entire user interface is handled through HTML pages and a browser. The program either dynamically builds the HTML pages in memory or retrieves them from the disk and modifies them through text substitution.

    The advantages are many. Here are some of them…

    1. We do not need to worry about Windows messages and callback functions any more.
    2. We do not need to learn DDT or API and the complexities of Windows GUI. Just HTML/XML.
    3. As HTML and XML standards evolve we can do better and better user interfaces.
    4. Our applications can be content driven.
    5. We can change the user interface very quickly.

    Of course this is not appropriate for every application and there are many disadvantages too .

    Obviously performance is a major consideration, but as someone suggested before, many applications sit idle most of the time while the user or the database back-end do their bit.

    This option will give us total independence from Windows native GUI and can be used with any language. PB/CC and PB/DLL are obviously among the best.

    The fact that these programs can also communicate with other similar programs through “Port 80” over any TCP/IP connection should open interesting avenues for distributed computing.

    If the concept is successful then Bob Zale and his team can consider introducing native support for this model at the compiler level.

    I know this sounds quite revolutionary and GUI elements in a browses are not as mature as Windows native GUI. But lateral thinking never hurt anyone.

    Siamack


    [This message has been edited by Siamack Yousofi (edited March 06, 2000).]


    ------------------

    Leave a comment:


  • Florent Heyworth
    replied
    Hi Martin

    some while back I started working on a PB web application server
    to do just that and I posted a working example. While working
    on my Listener application I realised that what I actually needed
    was a multi-threaded server since I didn't want to restrict
    myself to just servicing one user and hanging in long running requests.

    I threw my whole design out of the window and started re-working
    it as a full-fledged high-performance web/application server.

    To address the performance issue I decided to go with I/O Completion
    ports which is essentially a kernel I/O threading model which gives
    very high throughput - the downside is that it's only available
    on NT and higher.

    Since my goal was to go beyond just a GUI server this hasn't bothered
    me. It's been a lot of work - I'm just now completing my first
    application for a large music store in Switzerland.

    Here are the features of the server:
    - Requires NT and higher
    - uses very fast I/O completion port model
    - uses thread pools
    - support for SMP
    - supports application namespaces
    - supports customisable settings per application/namespace
    - allows to define routines which should be called before
    delivering documents (to check security and all that)
    - Own api (no CGI) which allows PB and other DLLs to get loaded
    by the server - the server then calls exported functions according
    to URL Get/Post requests.
    - Uses SEH structure exception handling for robustness
    - Comprehensive API:
    - Datetime functions
    - ODBC wrapper functions
    - Associative dictionary functions
    - CGI/cookie handling functions
    - fast inline assembler string functions
    - XML parsing functions - supports well formed XHTML but not
    HTML
    - secure hashing functions

    This is still a work in progress. I have yet to add a DOM extension
    for XML parsing, SSL and TLS support for security and write include
    files for PB, C and maybe Delphi.

    I'll probably rework the API as well to make it more user friendly
    as well as exposing the server as a C++ class...

    Notwithstanding, my first customer should be installing the first
    app to go with it so I may be able to show you an example real
    soon now (but don't hold your breath

    If PB people are interested I may decide to release the server
    and API - on what terms etc, I still haven't decided.

    Cheers

    Florent

    ------------------

    Leave a comment:


  • Martin Francom
    replied
    ..The idea of letting IE and HTML/XML files be the
    GUI user interface is very interesting. Has anyone
    completed a simple appication using this technique
    that they can share with us?
    ..Did you know the there is a compiler available
    for HTML/XML file? If not, check this out:
    .
    http://www.webcompiler.com/product.html
    .
    By compiling your HTML/XML files your program will
    be better protected from unauthorized changes.


    ------------------
    Marty
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Florent Heyworth
    replied
    Hi Scott

    I'm not sure I understand what you mean with
    So lets say the user wants to input something BACK to the program....that may require you to re-launch the browser and use port 80
    .

    Per default (in the sample program) the server waits on port 80 - you can ask it to wait on another port though. Browsers per default want to talk to port 80 but you can also steer that in your html files. Let's say you want your browser to talk to a server waiting on port 8088 you would do something like: http://localhost:8088/hello

    The standard way to get input back from the browser is to use the "POST" mechanism:
    <FORM ACTION="http://localhost:8088/mycgi" METHOD="POST">
    <INPUT TYPE="text" NAME="User Entry">
    <INPUT TYPE="submit" NAME="SendIt" VALUE="Click Me">
    </FORM>

    The browser then makes a request to the server telling it that it used the "POST" method. The server parses the header sent by the browser and makes it available to environment variables such as: REQUEST_METHOD="POST", etc. The cgi can then use this information to process the user input and sends back the result to the server which returns it to the browser for display.

    As Lance likes to say: "clear as MUD"?

    Cheers

    Florent


    [This message has been edited by Florent Heyworth (edited March 08, 2000).]

    Leave a comment:


  • Scott Turchin
    replied
    Quick question...

    ..you send a file to the browser, piece of cake right? Yup...

    So lets say the user wants to input something BACK to the program....that may require you to re-launch the browser and use port 80, but what if you are running on the machine with another webserver already?
    How does the browser talk back? Is it for one way communications only? Awesome idea, very very good...


    And how does IE communicate BACK to the main program in general terms without using OLE???


    Front Page has a tool much like this, just a script, like anything else, and it saves a JET database file I guess much like another product I work with....

    Scott


    ------------------
    Scott
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Siamack Yousofi
    replied
    Florent

    Thank you and well done! This is exactly what I had in mind!

    Although I happen to be the one who started this thread, the idea had already crossed the minds of a number of participants including you.

    The example you have posted proves that the concept is a viable alternative indeed. Browsers will only get better and more versatile with each new release. In fact we may have a browser as a stand-alone “Operating System” of sorts for dedicated Internet devices in the not too distant future. So where appropriate, why not use the browser and HTML/XML as our GUI platform and Powerbasic as the engine?

    This is particularly useful in Linux. None of the Linux GUI options are native to the OS. The browser is the best bet for compatibility on Linux and when PB/Linux is released this model would be a potent alternative.

    You asked about licensing. Obviously, you must receive compensation and recognition for you work. However, if a number of people in this forum alone had independently thought about this model then chances are many more in the world at large are also working on this. The model can be implemented in any language and is reasonably straightforward. So putting the code in public domain and using the credits and recognition may indeed pay better dividends.

    IMHO Powerbasic should seize the opportunity and implement this model at the language level. Browsers have APIs too. So why not extend the DDT to cover Browser API’s also and make this model native to the compiler! Its implementation is certainly less complicated than Windows native GUI and well within the excellent expertise of Powerbasic development team. If done in a timely fashion and before everyone else, this will put Powerbasic in a position of leadership.

    I look forward to the enhancements you have planned.

    Thank you again.

    Siamack.


    ------------------




    [This message has been edited by Siamack Yousofi (edited March 06, 2000).]

    Leave a comment:


  • Florent Heyworth
    replied
    Hi Siamack et all

    I finally got round to taking a first shot at implementing an I/O driven GUI server. Since there are several files and some sparse documentation, I've uploaded the zip file to my server.

    Look at the beginning of the thread to have a look at the discussion which prompted this prototype.

    Download: http://www.radbit.com/code/listen.zip and unzip. Run sample.exe: it will show you the documentation and some example code.

    Comments, flames and gripes are welcome

    Florent



    [This message has been edited by Florent Heyworth (edited March 05, 2000).]

    Leave a comment:


  • Philippe Monteil
    replied
    <<In fact, many of clients are now using my program, because of <<your software, which I'm unlimited in what I can do with HTML <<& PowerBasic together.
    Thanks for the nice words. Please note that the demo was a joined effort by Patrice Terrier and me. Patrice is the author of the WinLift skin engine while the JA COM/PB 2.0 was used to ActiveX enable the PB/DLL form.

    <<I now label my html (dll's) of what the content is. No reason <<to add this to my fast exe file.
    Also, the WebBrowser demo can be used to display very different types of documents: HTML pgaes but also Word files, Excel spreadsheets, Visio drawings ...

    Philippe



    ------------------

    Leave a comment:


  • Michael Meeks
    replied
    Siamack Yousofi
    Philippe Monteil

    Yousofi, your idea (which I also have been working on) is right on que!
    Monteil, when I purchased your skin, I had asked you for the source to the html/help file. This engine of yours does exactly what Siamack was talking about. In fact, many of clients are now using my program, because of your software, which I'm unlimited in what I can do with HTML & PowerBasic together.

    If others out there don't know what I'm talking about, contact
    Philippe Monteil and ask for a demo of the skwebber application. This is a simple example, but gives you an idea what some of the possiblities are! I can now create html files as I need them and delete them when I'm done, using a simple PB DLL file. I now label my html (dll's) of what the content is. No reason to add this to my fast exe file.

    As far as I'm concern, Philippe has already done the work for me. All I have to do is design my html pages. Couldn't haven't any better than this!

    My $.02 worth!

    MWM Consulting



    ------------------
    mwm

    Leave a comment:


  • Siamack Yousofi
    replied
    Thank you.

    ------------------

    Leave a comment:


  • jcfuller
    replied
    Originally posted by Siamack Yousofi:
    James

    Thanks for the tip. I shall have a look. Where can I find rsrc utility?

    Siamack

    www.capital.net/com/jcfuller/rsrc.zip


    ------------------

    Leave a comment:


  • Siamack Yousofi
    replied
    James

    Thanks for the tip. I shall have a look. Where can I find rsrc utility?

    Siamack

    ------------------


    [This message has been edited by Siamack Yousofi (edited February 27, 2000).]

    Leave a comment:


  • jcfuller
    replied
    Originally posted by Siamack Yousofi:

    I forgot to mention before but Greg Turgeon posted the code for a utility that allows us to embed any file in an EXE or DLL
    You can do the same thing using the rsrc utility ( or now with BRC32 from the free BC++ 5.5 download) and a standard rc file.

    Saves you having to recompile the bas source evertime you need changes.

    James




    ------------------

    Leave a comment:


  • Siamack Yousofi
    replied
    florent

    i see your point about the complexity of the html/javascript page negating the advantages of this model.

    we are all so used to windows that it is natural to think in windows gui terms when we design web pages. if we think within html limits then may be a simpler interface could do the trick for certain applications.

    after all the real advantage of a browser interface is its "content-driven" paradigm. many web designers seem to have forgotten about this capability and are carried away with fancy graphics and special effects.

    i am very grateful to you for trying out this idea. obviously, it will not be a universal method of gui design but if it proves useful even for specific applications where user interaction is minimal then we have an alternative solution.

    since the application can send the data to the browser without waiting for a "request" then we have some sort of "push" technology right away. it may also prove more useful on linux where the os and its many gui front-ends are in a constant state of flux.

    i forgot to mention before but greg turgeon posted the code for a utility that allows us to embed any file in an exe or dll




    i used it in conjunction with eric olson's http server and created an "instanet" where web pages are linked into the executable and are modified through text substitution just before they are served. text substitution is in the same way eric has done it in his example. the result is a single exe containing both the server and content that you can run from the floppy. nothing needs to reside on the pc. combine this with the model i am proposing and we have some very clever stuff.

    i think no matter what the outcome, it is worth a try. thank you again for investigating the idea.


    siamack


    ------------------


    [this message has been edited by siamack yousofi (edited february 26, 2000).]

    Leave a comment:


  • Florent Heyworth
    replied
    Hi Siamack

    FWIW I've been exploring the possibility of using a browser as a UI component. I've got a half-clobbering example of an app - the PB app is implemented as single-threaded concurrent server using a "select" loop ISO of Eric's HTTP server. When it's a bit further along I'll be happy to post the code.

    However, even at that early stage many problems become apparent: using a browser (IE is the most advanced at the moment) does not IMO simplify UI design. To get any non-trivial UI interface together requires a thorough grounding in HTML as well as a good working knowledge of Javascript/Jscript. The interaction between the page elements and the PB server app rapidly become complex.

    Implementing some kind of CGI is straightforward - but updating parts of the page ISO just presenting a new page requires using (I won't mention XML data islands or other forms of data binding) numerous frames which again complicates UI design.

    Additionally, Microsoft has been extending IE so that it is becoming an application development tool in its own right. As an example see the code below. Cut and paste the code and save it to a file with an HTA (HTML Application) extension as in "test.hta". You can provide an icon in the current directory so that you'll see an application icon. Test the code by invoking it from the command line: test.hta

    Note that this example requires IE5 (might work with IE4)
    Code:
    <HTML>
    <HEAD>
    <TITLE>Test Application</TITLE>
    <HTA:APPLICATION ID="Test App"
         APPLICATIONNAME="myApp"
         BORDER="thin"
         BORDERSTYLE="complex"
         CAPTION="yes"
         MAXIMIZEBUTTON="yes"
         MINIMIZEBUTTON="yes"
         SHOWINTASKBAR="yes"
         SINGLEINSTANCE="yes"
         SYSMENU="yes"
         VERSION="1.0"
         SCROLL="no"
         ICON="Gnome.ico"
         >
    </HEAD>
    <BODY>
    This is a simple HTML Application.
    <BR>
    <BUTTON onclick="self.close()">Exit</BUTTON>
    </BODY>
    </HTML>
    If you were able to run the code, you'll see that very much is possible (when using IE4/5). Can we get the best of both worlds (simple UI and PB speed and syntax? I think that the answer is: yes, to a point, but it is complex. The point being that I do not see the development cycle becoming easier/faster than using DDT/the API let alone a Visual Designer. Supplying the right framework/tools might hide a lot of the complexity but I don't know if it's worth the trouble.

    Implementing the PB server side you basically get the following beast: a lightweight server serving documents/data on the client side. The client does not need a webserver. You can make sure that the HTML page requests data using a particular port, etc..

    In essence you get a lightweight, personal application server. Again is it worth the trouble when you can essentially install the light version of "Cold Fusion" or some other app server on your client's computer and have a lot more functionality "out of the box" - if you need speed you can always spawn off a PB app to deliver the information.

    My personal opinion is that it's not worth the effort, although, as I said, I will post the prototype as soon as it's ready for human consumption .

    I think that the way to go is with a description language, layout designers, ideally using XML - which can be used as a common language by all Visual designers.

    Stay tuned

    Cheers

    Florent

    ------------------

    Leave a comment:


  • Siamack Yousofi
    replied
    Florent

    Your idea for using XML as a resource definition language is brilliant. You did suggest it in the "visual design tool" thread and IMHO it should be taken seriously by those who are thinking of developing such tools for Powerbasic.

    In fact future resource editors would possibly create resource scripts in XML instead of the current plain text format.

    However, my suggestion at the beginning of the current discussion was to offer an alternative technique that we could use right now with what we have. Once the concept is proven as workable, a logical path for future development would present itself.

    It is possible to take Eric Olson's "HTTP server" example and modify it to do what I am suggesting.

    It just needs someone with a bit of spare time to investigate the practicality of the concept.


    Siamack


    ------------------


    [This message has been edited by Siamack Yousofi (edited February 26, 2000).]

    Leave a comment:


  • John Hackl
    replied
    Print to a printer, with headings repeated on each page.
    Regular reports are sort of dull, html tables can use
    proportional fonts with numbers right justified so they line up.


    ------------------

    Leave a comment:

Working...
X