Re: dmd support for IDEs + network GUI
Adam D. Ruppe destructiona...@gmail.com wrote in message news:mailman.208.1255923114.20261.digitalmar...@puremagic.com... On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote: Excellent! Sounds exactly like what I had in mind. I'll definately want to keep an eye on this. Any webpage or svn or anything yet? I wrote up some of a webpage for it over the weekend: http://arsdnet.net/dws/ I haven't had a chance to clean up my code yet, so it isn't posted, but there's some overview text there, including some implementation details that I haven't discussed yet here, but the document still has a long way to go. But there it is, becoming more organized than anything I've written on it before. Great! Thanks for your interest and to the rest of the group for letting me go off topic like this! The offtopics are some of the most interesting bits!
Re: dmd support for IDEs + network GUI
Nick Sabalausky wrote: Adam D. Ruppe destructiona...@gmail.com wrote in message news:mailman.208.1255923114.20261.digitalmar...@puremagic.com... On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote: Excellent! Sounds exactly like what I had in mind. I'll definately want to keep an eye on this. Any webpage or svn or anything yet? I wrote up some of a webpage for it over the weekend: http://arsdnet.net/dws/ I haven't had a chance to clean up my code yet, so it isn't posted, but there's some overview text there, including some implementation details that I haven't discussed yet here, but the document still has a long way to go. But there it is, becoming more organized than anything I've written on it before. Adam. What you written at your web site is a very interesting read. Re your use of a binary protocol. Perhaps instead of re-inventing the wheel, you may want to look at what Google has done with the design of their Google Protocol Buffers, which also implements a very fast binary protocol. See here for a overview: http://code.google.com/apis/protocolbuffers/docs/overview.html It is also worthwhile reading the section called A bit of history. Note that there is also D implementation. http://256.makerslocal.org/wiki/index.php/ProtocolBuffer I don't know how current this is, though. One more point. What, if any, library to you plan to use ? cheers Nick B
Re: dmd support for IDEs + network GUI
On 10/20/09, Nick B ni...@gmail.com wrote: Re your use of a binary protocol. Perhaps instead of re-inventing the wheel, Eh, my code is already written and works. One of the advantages to my code generator reading a C like syntax is that I might be able to fully automate porting some existing APIs down the wire - I'm particularly looking at OpenGL, or at least a subset of it, to work with ease. Another one is porting my generator to a new language is easy - I already know the code and it is fairly simple anyway. Anyway, quickly skimming through the google page, their system isn't bad (Coincidentally, it and I encode unsigned ints and strings in exactly the same way! Cool.), but I don't think there's much to gain by me switching to it. Though, their signed varint algorithm is pretty elegant; I might have to use that. And it reminds me that I didn't even consider optional arguments on functions. Trivial to implement though, even compatible with my current protocol: if message length is shorter than what you expect, use default values for the rest of the arguments. This means they'd have to be at the end, but you expect that from C like functions anyway. It is also worthwhile reading the section called A bit of history. I thought about future compatibility, which is why my protocol has a length field on every message. If you read the length and the function number and find it isn't something you know, you can simply skip past the whole message and carry on. The ugliness might be that future functions deprecate old functions... if this took off and was widely used, it might end up looking like Win32 in 10 years (CreateWindow() nope, CreateWindowEx()!), but I'm ok with that. One more point. What, if any, library to you plan to use ? The D side is all custom code (I've written various libraries and helper tools over the years for myself - the big one used here is a network manager thing that handles incoming connections and output buffering) and Phobos - nothing third party there. I'm using D2, but there's nothing preventing it from being backported to D1 at some point. I actually want to do a DMDScript port that speaks it too, but that's way down the line. For the viewer, my current implementation is C++ with Qt. I'd like to actually do various viewers, including ones with less fat dependencies (asking users to download Qt just to run it is a bit heavy), but for now, I just wanted something I could start using immediately without too much trouble for me. Qt on C++ works pretty well across platforms, and I already know how to use it, so it was an easy choice for early stages. cheers Nick B Thanks! -Adam
Re: dmd support for IDEs + network GUI
On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote: Excellent! Sounds exactly like what I had in mind. I'll definately want to keep an eye on this. Any webpage or svn or anything yet? I wrote up some of a webpage for it over the weekend: http://arsdnet.net/dws/ I haven't had a chance to clean up my code yet, so it isn't posted, but there's some overview text there, including some implementation details that I haven't discussed yet here, but the document still has a long way to go. But there it is, becoming more organized than anything I've written on it before. Thanks for your interest and to the rest of the group for letting me go off topic like this! -- Adam D. Ruppe http://arsdnet.net
Re: dmd support for IDEs + network GUI (OT)
Nick Sabalausky wrote: Video game developers don't make multiplayer games by sending a compressed video stream of the fully-rendered frame - they know that would be unusable. Instead, they just send the minimum higher-level information that's actually needed, like PlayerA changed direction 72 degrees (over-simplification, of course). And they send it to a client that'll never insist on crap like interpreted JS or open-for-interpretation standards. And when there's a technology that's inadequate for their needs, like TCP, they make a proper replacement instead of hacking in a half-assed solution on top of the offender, TCP. And it works great even though those programs have visuals that are *far* more complex than a typical GUI app. So why can't a windowing toolkit be extended to do the same? And do so *without* building it on top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, etc.? This is generally true, although see OnLive (http://www.onlive.com/). I hear it works better than you'd expect, but don't have much interest in actually trying it.
Re: dmd support for IDEs + network GUI
Mon, 12 Oct 2009 19:53:32 -0400, Adam D. Ruppe thusly wrote: In addition to GUI components, I also want to support local file and sound access, along with a few other things. It sucks when you are using an X program and it decides to blare sound out of your home computer when you are using the app from your work computer! Or it is a real pain in the ass to have to save the file in X, then scp it over to open it in a local program. These things should Just Work, and it isn't hard to implement, so I'll be setting that up too. Nomachine NX does pretty much what you are describing here. It is not equivalent technically but very similar and backwards compatible.
Re: dmd support for IDEs + network GUI (OT)
David Gileadi f...@bar.com wrote in message news:hb24km$pm...@digitalmars.com... Nick Sabalausky wrote: Video game developers don't make multiplayer games by sending a compressed video stream of the fully-rendered frame - they know that would be unusable. Instead, they just send the minimum higher-level information that's actually needed, like PlayerA changed direction 72 degrees (over-simplification, of course). And they send it to a client that'll never insist on crap like interpreted JS or open-for-interpretation standards. And when there's a technology that's inadequate for their needs, like TCP, they make a proper replacement instead of hacking in a half-assed solution on top of the offender, TCP. And it works great even though those programs have visuals that are *far* more complex than a typical GUI app. So why can't a windowing toolkit be extended to do the same? And do so *without* building it on top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, etc.? This is generally true, although see OnLive (http://www.onlive.com/). I hear it works better than you'd expect, but don't have much interest in actually trying it. Yea, I've heard of that. I'm extremely skeptical though. Even at *absolute* best, I still can't imagine it having less lag than one of those laggy HDTVs, which I already consider entirely inadequate for gaming. Plus they'd essentially have to have a whole high-end gaming rig (plus all the higher-end-than-usual video-capture/compression and network needs) for each simultaneous user, which I'd imagine would either make the subscription fee absurdly high, lead to 90's-AOL-style too-many-connection issues, or send them right into bankruptcy. It's just unnecessary bandwidth/latency bloat.
Re: dmd support for IDEs + network GUI
Mon, 12 Oct 2009 19:09:11 -0400, Nick Sabalausky thusly wrote: A different branch of the this topic started taking about (or rather, bashing on) web-apps-being-used-as-desktop-apps, and I mentioned I felt that was ass-backwards and that the focus should be the other way around: making desktop apps work on the web. [snip] And do so *without* building it on top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, etc.? You have probably lived under a rock these days. This is the way the world is moving. If something can be made Web 2.0 compatible, it is also what will happen. A new platform might come up in 201x or 202x, but nowadays the best we have got is Web 2.0. Ever used twitter, facebook, google wave (or any google's services) etc. ? Large part of the online enterprises have already jumped on the wagon, not only early adopters. Modern browsers such as opera 10, firefox 3.5, safari, and chrome already support the latest standards.
Re: dmd support for IDEs + network GUI
Adam D. Ruppe destructiona...@gmail.com wrote in message news:mailman.179.1255391198.20261.digitalmar...@puremagic.com... My DWS project aims to work up on a widget level. It isn't quite as visually fancy as what you are describing (though it could grow into it later), but works on a high enough level of abstraction to be fast - and cross platform. Here's another thought I've had that I forgot to mention before. Just tossing it out there, don't know if you've looked into it or not: Instead of (or, better yet, in addition to) a special network-GUI toolkit, what about a server (kind of like a modified version of remote desktop) that actually queries the OS to find out about all the GUIs running on the system, and details about all their controls, relays that info to the client to reproduce, and accepts input back from the client like a softwareKVM would? It probably wouldn't work quite as well as a special network-GUI toolkit (it would probably have to detect and handle Win32/GTK/Delphi apps seperately, it probably wouldn't be able to do everything 100%, and it wouldn't be able to do any of the smart client tricks you have up your sleeve), but it would allow for at least some basic compatibility with apps that weren't specifically coded for a special network-GUI toolkit. Regarding the technical feasability of gaining information on all the controls of the running processes, I could swear I've seen some Windows program (some dev tool IIRC) that was able to detect that stuff from Win32 and Delphi apps, although I have no recoloction what what in the world that program was... I have no idea as to the feasability on Mac or Unix.
Re: dmd support for IDEs + network GUI
Walter Bright newshou...@digitalmars.com wrote in message news:hb05cv$2br...@digitalmars.com... Bill Baxter wrote: But it doesn't sound to me like it will be that much use to serious IDEs. Possibly not, but for lightweight IDEs I think it would be of much use. It would also make things very accessible to Emacs and Vim, two very widely used programmers' editors. (One thing I like about Vim is I can run it remotely via putty. A graphical gui IDE is impractical to use remotely, and yes, I've tried remote desktops. Unusable.) A different branch of the this topic started taking about (or rather, bashing on) web-apps-being-used-as-desktop-apps, and I mentioned I felt that was ass-backwards and that the focus should be the other way around: making desktop apps work on the web. What you say here is actually hinting at what I meant: What we need is a proper GUI equivalent to something like TTY or telnet. Not remote desktops, which really just act like streaming video, but something that'll say Hey client, host here, talking through something much more appropriate than XML/HTTP, I want a button that says 'Ok' at (7,14) with size (50,20) on the form 'FooForm', and if the user wants a skin, may I suggest (but not insist) the 'buttonSkinFoo' that I already sent you earlier, plus I need a user-editable textbox over here...etc. (In fact, I think X11 already provides something like this in a slightly more low-level form) I actually tried doing code-editing through remote desktop a few weeks ago and noticed just how poorly-suited (not to mention unusable) the whole approach was for anything more than clicking around on a few buttons. A fully-loaded Eclipse is vastly more responsive! And why? The client system I was using was perfectly capable of handling a text-box on it's own, and I really didn't need everything to look exactly as it does on the client machine. Video game developers don't make multiplayer games by sending a compressed video stream of the fully-rendered frame - they know that would be unusable. Instead, they just send the minimum higher-level information that's actually needed, like PlayerA changed direction 72 degrees (over-simplification, of course). And they send it to a client that'll never insist on crap like interpreted JS or open-for-interpretation standards. And when there's a technology that's inadequate for their needs, like TCP, they make a proper replacement instead of hacking in a half-assed solution on top of the offender, TCP. And it works great even though those programs have visuals that are *far* more complex than a typical GUI app. So why can't a windowing toolkit be extended to do the same? And do so *without* building it on top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, etc.?
Re: dmd support for IDEs + network GUI
On Mon, Oct 12, 2009 at 07:09:11PM -0400, Nick Sabalausky wrote:
What you say here is actually hinting at what I meant: What we need is a
proper GUI equivalent to something like TTY or telnet. Not remote desktops,
which really just act like streaming video, but something that'll say Hey
client, host here, talking through something much more appropriate than
XML/HTTP, I want a button that says 'Ok' at (7,14) with size (50,20) on the
form 'FooForm', and if the user wants a skin, may I suggest (but not insist)
the 'buttonSkinFoo' that I already sent you earlier, plus I need a
user-editable textbox over here...etc. (In fact, I think X11 already
provides something like this in a slightly more low-level form)
X11 is too low level - it works on windows and drawing commands, but that's
about it. Windows Remote Desktop is actually in a much better position, but
it is still fairly slow for its own reasons.
My DWS project aims to work up on a widget level. It isn't quite as visually
fancy as what you are describing (though it could grow into it later), but
works on a high enough level of abstraction to be fast - and cross platform.
One of the things that makes X feel slow is that it needs to make a lot of
round-trips to the server to get anything done. (And the modern toolkits make
this *worse* by shoehorning in features the low level protocol wasn't really
meant to support.)
To solve this, I want to hand off as much processing as possible to the client.
And to make that happen, I say you shouldn't be too concerned about the
specifics. Tell what widgets you want, but leave the specifics to the viewer.
This also gives a bonus for cross platform: when using an app on Windows,
the little details should feel like a Windows program, not a Linux one, even
if the app itself is running on a Linux server somewhere.
One the apps I already have running on it is a notepad program. The code
looks like this:
---
auto app = new DWSApp;
auto window = new MainWindow;
window.title = My notepad;
auto editBox = new TextEdit(window);
auto menu = new Menu(File);
menu.addItem(new Action(Save, { std.file.write(file.txt, editbox.text); }));
window.addMenu(menu);
window.show;
app.exec();
---
Most the lines turn into network calls pretty directly. The protocol is
binary, so no wasted time parsing text and no wasted bandwidth on bloated
stuff like XML. It works on an always open connection, so no annoying lag
from stupid nonsense like HTTP polling.
The window, menu, and edit box are created however the viewer wants to do it.
Currently, I have a Qt/C++ viewer that uses Qt widgets for the actual
implementation, but this can be anything - I want to do a MS-DOS text mode
viewer eventually to demonstrate the flexibility.
A network session would look something like this (each function name is just
one byte show down the wire and the arguments are mostly plain ints):
createWindow(0); // the argument is the window ID - you tell the server, so you
// can use it immediately without waiting on the lag of a response
// the D language API hides this from you though as a private member
createWidget(TEXT_EDIT, 0);
createMenu(0, File); // strings are sent across as length ~ data
createAction(0, Save);
addActionToMenu(0, 0); // menuId, actionId
showWindow(0);
That's just 24 bytes of payload to create the window, no round trip required
(except for the ACK from TCP).
Now, the user starts typing. His text appears instantly - the computer he is
in front of handles the text widget all on its own. The only thing it sends
back on the wire:
widgetTextUpdate(0, /* description of text changes since last update */);
It doesn't need to wait on the program's response - it doesn't care. It just
sends this update back to boost speed on future operations and to provide
crash protection. (If the viewing computer crashes, or if the network link
suddenly dies, the app knows its state, so it can recreate the window when
the network comes back. Also useful for migrating the app display to another
machine.)
You don't have an X11 style
keyEvent('a');
drawText('a');
back and forth.
What if the user clicks the menu item? Easy:
widgetTextUpdate(); // it flushes updates to ensure the app sees the most
// recent text
actionTriggered(0); // the D API sees these 2 bytes on the wire and calls
// the delegate I passed in the code.
That's it!
The entire session to edit a quick text file might have only two required
round trips to the server - it sips bandwidth and is latency tolerant.
More complex programs that can't be built on the ~20 standard widgets will
be slower, since they'll have to actually subscribe to the low level key
events, etc., but I have a plan (not yet implemented at all) to fix that too
by caching event paths.
Basically, your app tells the viewer as much as it can to handle little things
on its own. When the user presses 'A', go ahead and draw
Re: dmd support for IDEs + network GUI
Adam D. Ruppe destructiona...@gmail.com wrote in message news:mailman.179.1255391198.20261.digitalmar...@puremagic.com... My DWS project aims to work up on a widget level. [big snip] Excellent! Sounds exactly like what I had in mind. I'll definately want to keep an eye on this. Any webpage or svn or anything yet? Couple questions: Have you given any thought to security? The stuff about local file/etc access sounds great, but it also makes me think a little of Adobe's FLEX (but with a much more professional appearance and sensible language) which is notorious for, first, opening the door for no-install cross-platform malware and then not caring one whit about the fact that they've done so (sort of like how they don't care about the evils of flash super-cookies, but I digress...). How do you have the client-side working from the perspective of a new user? Ie, Do they still need to install each app (or at least each app's client) individually, or is it just a one-time install of the DWS library? If the latter, how do they find/launch a remote program? I ask because one of the things that web-app fans like about web-apps is that they're no-install, at least beyond the installation of the platform (ie, browser) itself. But I've always felt there's no technical reason why it shouldn't be possible to have a link to, for instance, dws://www.somedomain.com/apps/someGUIApp?cmdlineparams and have that launch the client's remote-GUI toolkit on that someGUIApp.
Re: dmd support for IDEs + network GUI
On Mon, Oct 12, 2009 at 09:06:38PM -0400, Nick Sabalausky wrote: Excellent! Sounds exactly like what I had in mind. I'll definately want to keep an eye on this. Any webpage or svn or anything yet? Not yet. I've discussed it on random forums (in various states of development) but haven't written up anything cohesive at all. I'd tar up my code as it is right now, but it is a huge mess with outdated notes and my real passwords just hardcoded in there it isn't suitable to go public at all, sadly. I'll try to fit in a few hours to clean it up over the weekend though. Have you given any thought to security? A little bit, but not a lot. I was thinking the viewer could be as locked down as it wants*, but I've just been considering it an implementation detail so far. * Any app should be able to gracefully handle permission denied errors on file writing, so it shouldn't be hard to code up. The viewer could also run as a restricted user, using the operating system's protections to keep it in check. How do you have the client-side working from the perspective of a new user? Ie, Do they still need to install each app (or at least each app's client) individually, or is it just a one-time install of the DWS library? It is just a one time install of the viewer, if you want to run remote programs. If you want to run programs on your local box, you need to get the library (well, not really, since it is statically linked, but conceptually) and the app manager, which runs in the background. The manager seems like an unnecessary step, but it abstracts the app and the viewer from each other. The app connects to the manager on localhost and gives it the instructions to forward to the viewer. Next, the viewer also connects to the manager. The manager presents it with a list of active tasks. The viewer selects a task to attach, and then the manager shoots its current state down to the viewer, allowing the user to use the program. If the viewer crashes, no big deal - just restart it and pick up where you left off. But anyway, from the end user perspective, he just needs to grab the viewer and connect to the right server. If the latter, how do they find/launch a remote program? I ask because one of the things that web-app fans like about web-apps is that they're no-install, at least beyond the installation of the platform (ie, browser) itself. But I've always felt there's no technical reason why it shouldn't be possible to have a link to, for instance, dws://www.somedomain.com/apps/someGUIApp?cmdlineparams and have that launch the client's remote-GUI toolkit on that someGUIApp. Exactly. The way my current implementation works is you just run the viewer and connect it to the server, using plain old TCP (tunneled over SSH for auth and encryption right now, but that might change) The process looks something like this: Connect App #1 Notepad running, App #2 IM running The user can view this in a variety of ways. My Qt implementation gives a list widget, which the user double clicks the one he wants. Attach app #1 CreateWindow, Create text widget, set text widget contents, etc. The user now sees the program and interacts with it. Or, he can launch a new program - Exec app /app/notepad CreateWindow, . While my implementation currently uses a GUI list, it could just as well be a command line or a URL. Eventually, I'd like to make it Just Work on hyperlinks - it should be easy enough to rig something up so it downloads the viewer and connects all transparently to the user. -- Adam D. Ruppe http://arsdnet.net
Re: dmd support for IDEs + network GUI
Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote in message news:hb05cv$2br...@digitalmars.com... Bill Baxter wrote: But it doesn't sound to me like it will be that much use to serious IDEs. Possibly not, but for lightweight IDEs I think it would be of much use. It would also make things very accessible to Emacs and Vim, two very widely used programmers' editors. (One thing I like about Vim is I can run it remotely via putty. A graphical gui IDE is impractical to use remotely, and yes, I've tried remote desktops. Unusable.) A different branch of the this topic started taking about (or rather, bashing on) web-apps-being-used-as-desktop-apps, and I mentioned I felt that was ass-backwards and that the focus should be the other way around: making desktop apps work on the web. What you say here is actually hinting at what I meant: What we need is a proper GUI equivalent to something like TTY or telnet. Not remote desktops, which really just act like streaming video, but something that'll say Hey client, host here, talking through something much more appropriate than XML/HTTP, I want a button that says 'Ok' at (7,14) with size (50,20) on the form 'FooForm', and if the user wants a skin, may I suggest (but not insist) the 'buttonSkinFoo' that I already sent you earlier, plus I need a user-editable textbox over here...etc. (In fact, I think X11 already provides something like this in a slightly more low-level form) [snip] Video game developers don't make multiplayer games by sending a compressed video stream of the fully-rendered frame - they know that would be unusable. Instead, they just send the minimum higher-level information that's actually needed, like PlayerA changed direction 72 degrees (over-simplification, of course). And they send it to a client that'll never insist on crap like interpreted JS or open-for-interpretation standards. And when there's a technology that's inadequate for their needs, like TCP, they make a proper replacement instead of hacking in a half-assed solution on top of the offender, TCP. And it works great even though those programs have visuals that are *far* more complex than a typical GUI app. So why can't a windowing toolkit be extended to do the same? And do so *without* building it on top such warped, crumbling, mis-engineered foundations as (X)HTML, Ajax, etc.? It sounds like you are talking about Immediate Mode Graphical User Interface ? Have you checked out Hybrid (IMGUI) developed by team0xf ? See http://hybrid.team0xf.com/wiki/ Nick B
