If you plan to use just traditional web server connections and
traditional local interface. May be the methods and properties
could be cloned, but the event part could not be used if you
have not a socket always opened, and even having it, some
events like "MouseMove" could be quite expensive if they're
sent continuously to the server. There should be a way to
decide which events are managed in the client and which ones
are managed in the server, but this is not implemented in
gb.qt nor gb.gtk.
There will be things that gb.whatever has that gb.qt and gb.gtk
don't have, and vice versa. MouseMove in particular is
something that cannot be implemented at all if there's a network
round-trip between the event firing and the program responding.
But I think there will be other gb.form implementations someday
that have the same issues.... can anyone imagine
Apart from this there are other problems: how do you plan to
fill a large list or a big table? the internet bandwith is
This was perhaps the worst problem I had to deal with in my
current Ajax-based project. My solution was to replace list
boxes with auto-suggest text boxes whose onkeyup events
triggered a search that would fill the list box. If I were to
implement that as a more literal replacement for a Gambas list
box, I would probably populate the list box with Listbox.Count
blank items, and only populate the items when the user scrolled
the list to view them. If that wouldn't work, I might end up
having to do some kind of canvas-based thing.
There are lots of other glaring issues too. The PictureBox
control in Gambas has a lot more features than the img tag in
(X)HTML. We'll have a lot less control over the app window than
we do in Qt or Gtk. If the app has more than one window, each
one may open its own connection to the back end app, even if
we're simulating a dialog like a color picker or InputBox. Some
classes, like Desktop and Embedder, will be meaningless in a web
environment, while others like Font and Window will be vastly
reduced in functionality. Most layout controls (VSplit, HBox,
etc.) will be so code-intensive as to negate their value. And I
don't even want to think about things like UserControl yet.
Apart from that, though, Gambas developers looking to migrate
their apps to the web will need to adapt their programming
styles to the limitations of sending everything over a network.
One of my goals will be to make it easier for them to do so than
it presently is. The app I've been reimplementing on the web
was an Access 2.0 application originally, and I don't want
anyone else to ever have to jump through the hoops I did.
May be the design should be adapted to a network environment,
instead of writting a clone. The RAD could provide a special
form design for those widgets, I think that is the less
expensive part of the project. And the widgets could be
Hopefully someone who understands the IDE better than I do will
someday attempt something like that. To me (even though I have
hacked it and added to it in the past) the IDE has a lot of
magic in it.
designed to provide the feedback needed: automatic progress
bars while the data is beeing received in a table or list,
information about the synchronization status between data
shared in server and client, etc
I have to admit I never even considered the progress bar approach
before. It makes a lot of sense.
The component should provide also a way to store information
to be shared between server and client, so both parts can read
and modify it in a transparent way for the programmer, so
programming could become as easy as in a local app, without
caring about server and client concepts when possible. In the
Futura project we're using "network shared memory" (CRUDE) in
XML, but may be here something lighter could be used for
Yeah, I think I'll have to use XHTML for the form design that
gets sent to the browser, but otherwise I'd like to avoid
sending XML over the wires. It's just too big. Again, though,
I don't mean for the developer to have direct access to the
having to include a way to inject custom code.
May be SVG could be also a good idea to draw the widgets,
there are plugins for IE and Firefox supports it natively, as
The SVG plugin for IE will be discontinued as of the end of next
year and MS hasn't implemented SVG themselves, so I see SVG as a
dead end unless IE's market share goes below 50%. If we were
going to go the vector graphics route, I think it might actually
make more sense to use swftools.
button, and this is just the minor problem. XBL is another
interesting idea to create complex widgets, but it is valid
only for Firefox and Webkit at this moment.
It could be that we could have a dual target, XBL and XAML (for
IE7) but I personally can't see myself writing anything in XAML
unless Microsoft were giving me money.
And talking about images an other resources, the design of
gb.qt and gb.gtk supposes that images, pdf files and other
data is stored locally inside the executable. However, using
browsers you have to deal with the URL of the resources, an
incompatible way to work. Well, you can put an image into the
server executable and send it to the client, but then you can
have a big executable that you have to load and unload per
Yes, that's a limitation too. But again, I think that falls into
the category of "things the developer must learn", and we could
give him tips along the way. (As far as PDF's go, I can't see
myself embedding one in a Gambas app, even on the desktop.
Generate them in Gambas, sure, but not store a static one in my