View mode: basic / threaded / horizontal-split · Log in · Help
October 12, 2009
Re: dmd support for IDEs
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
Re: dmd support for IDEs + network GUI
"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
Re: dmd support for IDEs
"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
Re: dmd support for IDEs
"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
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 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
Re: dmd support for IDEs
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
Re: dmd support for IDEs
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
Re: dmd support for IDEs + network GUI
"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
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
October 13, 2009
Re: dmd support for IDEs + network GUI
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
14 15 16 17 18 19 20 21 22
Top | Discussion index | About this forum | D home