October 12, 2009
language_fan wrote:
> Now every time I see a gtk+/swt/dwt application I wonder where the heck that unintuitive terrible piece of cr*p came:
> 
> http://book.javanb.com/swt-the-standard-widget-toolkit/images/0321256638/
> graphics/14fig03.gif

2002, maybe?
October 12, 2009
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hb05cv$2bru$1@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.?


October 12, 2009
"Bill Baxter" <wbaxter@gmail.com> wrote in message news:mailman.177.1255384255.20261.digitalmars-d@puremagic.com...
>
> My understanding is that WPF is
> supposed to supersede WinForms, but it seems to me like they appeal to
> different audiences.  (Like people who want professional
> native-looking apps, vs the people who think the Windows Media Player
> has a nice  interface).
>

Hee hee hee, I like how you put that :)


October 12, 2009
"Walter Bright" <newshound1@digitalmars.com> wrote in message news:hb08gf$2hvq$1@digitalmars.com...
> Nick Sabalausky wrote:
>> "language_fan" <foo@bar.com.invalid> wrote in message
>>> "Practical" languages
>>> have lots of boiler-plate, and I can easily generate hundreds of lines
>>> of
>>> code with a couple of key combinations or mouse clicks.
>>
>> I disagree very much. For a puritanical anal-retentive language like Java, you *have* to have all that fancy stuff just to make the language even usable. But with a practical language like D, I have mixins, and I've gotten pretty good with regex find and replace, which obviously isn't as good, but it's good enough when dealing with any language that's at least somewhat sensible. With practical languages I never need to generate hundreds of lines of code. If I ever actually needed to do so (and in a way that an IDE could actually help with), I'd take that as a very big red flag that I was using an incredibly shitty language in the first place (like Java).
>
> I think Nick has a point. Java lacks template mixins, and so inserting hundreds of lines of code from an IDE "template" is normal. But with D, doing such would be abnormal.

And not only that, but D supports higher-level and non-OOP constructs far better than Java, and far less verbosely, so you don't always even need to resort to mixins. A lot of the time you can just simply use better features. Like delegate literals instead of functors.


October 12, 2009
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 the letter A at
the cursor, but then tell me so I can do fancier processing too."

This, not being written in any code at all, however, is subject to change. I'm not sure how well it will actually work in real apps.




Nevertheless, even if there is a requirement for special widgets to be slow and talk to the server for everything, the majority of cases should be covered by the standard widgets, giving a big boost overall.



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.

-- 
Adam D. Ruppe
http://arsdnet.net
October 12, 2009
On Tue, Oct 13, 2009 at 12:20:01AM +0200, Yigal Chripun wrote:
> regarding working on a remote machine:
> you can mount a remote file system through ssh and work localy on that
> remoted filesystem.

Eh, sshfs leaves a lot to be desired. There is a noticeable lag when performing basic operations on it - it really kills the flow when doing a rapid edit/compile loop.

It sounds cool on paper, but in practice is rather disappointing.

-- 
Adam D. Ruppe
http://arsdnet.net
October 13, 2009
Adam D. Ruppe wrote:
> On Tue, Oct 13, 2009 at 12:20:01AM +0200, Yigal Chripun wrote:
>> regarding working on a remote machine:
>> you can mount a remote file system through ssh and work localy on that remoted filesystem.
> 
> Eh, sshfs leaves a lot to be desired. There is a noticeable lag when
> performing basic operations on it - it really kills the flow when doing
> a rapid edit/compile loop.
> 
> It sounds cool on paper, but in practice is rather disappointing.

I've had positive results with sshfs. Sure, it could probably stand a
lot of improvements, but overall my experience has been good.

The Phobos remote build on the machine you donated access to (thanks!)
uses sshfs.

One cool thing is combining sshfs with autofs. That way the connection
is automatically made when you first open a dir. For example, if I write:

ls /ssh/erdani.com/

an sshfs session is automatically opened to erdani.com.

What are the issues that you encountered? My problems invariably involve
suspending the laptop to RAM or changing wireless connections, to then
find sshfs blocked. I need to "killall ssh" and then whenever I resume
reestablish connection(s). This is a considerable, but not major,
annoyance.


Andrei
October 13, 2009
"Adam D. Ruppe" <destructionator@gmail.com> wrote in message news:mailman.179.1255391198.20261.digitalmars-d@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".


October 13, 2009
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
October 13, 2009
Nick Sabalausky wrote:
> "Walter Bright" <newshound1@digitalmars.com> wrote in message news:hb05cv$2bru$1@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