View mode: basic / threaded / horizontal-split · Log in · Help
February 22, 2012
Re: Questions about windows support
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message 
news:mailman.860.1329924869.20196.digitalmars-d@puremagic.com...
> On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote:
> [...]
>> This has been changing in the last years since Microsoft introduced
>> Powershell and due to market pressure created headless versions of
>> Windows.
>
> Wow. Headless Windows? Can it even be called Windows anymore? :)
>

Microsoft Drywall :)
February 22, 2012
Re: Questions about windows support
On Wed, Feb 22, 2012 at 11:08:41AM -0500, Nick Sabalausky wrote:
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message 
> news:mailman.860.1329924869.20196.digitalmars-d@puremagic.com...
> > On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote:
> > [...]
> >> This has been changing in the last years since Microsoft introduced
> >> Powershell and due to market pressure created headless versions of
> >> Windows.
> >
> > Wow. Headless Windows? Can it even be called Windows anymore? :)
> >
> 
> Microsoft Drywall :)
[...]

LOL

On a more serious note, this is perhaps a proof that it's not a good
idea to conflate the OS with the GUI. :) But then I'm just being
pedantic.


T

-- 
If you think you are too small to make a difference, try sleeping in a closed room with a mosquito. -- Jan van Steenbergen
February 22, 2012
Re: Questions about windows support
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message 
news:mailman.865.1329932055.20196.digitalmars-d@puremagic.com...
> On Wed, Feb 22, 2012 at 11:08:41AM -0500, Nick Sabalausky wrote:
>> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message
>> news:mailman.860.1329924869.20196.digitalmars-d@puremagic.com...
>> > On Wed, Feb 22, 2012 at 08:53:06AM +0100, Paulo Pinto wrote:
>> > [...]
>> >> This has been changing in the last years since Microsoft introduced
>> >> Powershell and due to market pressure created headless versions of
>> >> Windows.
>> >
>> > Wow. Headless Windows? Can it even be called Windows anymore? :)
>> >
>>
>> Microsoft Drywall :)
> [...]
>
> LOL
>
> On a more serious note, this is perhaps a proof that it's not a good
> idea to conflate the OS with the GUI. :) But then I'm just being
> pedantic.
>

I've thought about that, and always been conflicted on it. User-choice and 
configurability is great, but OTOH there's something to be said about being 
able to assume one GUI system and not worry about a program or a set of 
instructions working on KDE *and* GNOME *and* xfce *and* lxde *and* blackbox 
*and* afterstep (is that still in use?) *and* etc... It'd be great if we 
could just have one GUI that's flexible/customizable/efficient enough for 
everyone. But then, problem is half the GUIs out there are *all* trying to 
be that "one and only" GUI. Oh well.

> If you think you are too small to make a difference, try sleeping in a 
> closed room with a mosquito. -- Jan van Steenbergen

Heh, you've got some good quotes. I also really liked that one about "Why 
didn't he append 'I think' to 'wiser people are so full of doubts'?"
February 22, 2012
Re: Questions about windows support
On Wednesday, 22 February 2012 at 17:34:16 UTC, H. S. Teoh wrote:
> On a more serious note, this is perhaps a proof that it's not a 
> good
> idea to conflate the OS with the GUI. :) But then I'm just being
> pedantic.

Do you wanna say modern hardware still can't run GUI system?
February 22, 2012
Re: Questions about windows support
On Wed, Feb 22, 2012 at 07:36:24PM +0100, Kagamin wrote:
> On Wednesday, 22 February 2012 at 17:34:16 UTC, H. S. Teoh wrote:
> >On a more serious note, this is perhaps a proof that it's not a good
> >idea to conflate the OS with the GUI. :) But then I'm just being
> >pedantic.
> 
> Do you wanna say modern hardware still can't run GUI system?

That's not what I mean. When your OS is running on a dedicated remote
server, it makes no sense to have a GUI running on it, since all
administration is done remotely anyway. A GUI on a server is just a
waste of resources.


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
February 23, 2012
Re: Questions about windows support
On Wed, Feb 22, 2012 at 01:14:46PM -0500, Nick Sabalausky wrote:
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote in message 
[...]
> > On a more serious note, this is perhaps a proof that it's not a good
> > idea to conflate the OS with the GUI. :) But then I'm just being
> > pedantic.
> >
> 
> I've thought about that, and always been conflicted on it. User-choice
> and configurability is great, but OTOH there's something to be said
> about being able to assume one GUI system and not worry about a
> program or a set of instructions working on KDE *and* GNOME *and* xfce
> *and* lxde *and* blackbox *and* afterstep (is that still in use?)
> *and* etc... It'd be great if we could just have one GUI that's
> flexible/customizable/efficient enough for everyone.

I thought that was called X11?  Oh wait... ;-)

The problem with X11 is that it was designed almost 30 years ago, and as
a result its API is, by today's standard, rather baroque. It was also
from a time before the dominance of the so-called desktop metaphor,
which means many contemporary programs require a lot more infrastructure
than it provides. Which is why KDE and GNOME exist.

I've always been a stickler for configurability. But I can see the value
of having a consistent set of instructions for a newbie to follow when
she encounters problems with your app. If everyone has a different setup
then tech support is a veritable waking nightmare.

Perhaps the solution is to have a single *default* desktop, and then
power users can configure it to their hearts' content, with the caveat
that if things go wrong, they're on their own. Power users ought to know
how to translate instructions intended for the default desktop to their
own environment anyway.

For example, I don't think *anyone* could give me sane instructions that
would work on my "desktop"... which is more like a glorified console
than a real desktop. :P  But if you said something like "go to
applications -> browsers, click on Firefox", then I'd just smile and nod
and type "firefox&" at the shell prompt. :)


> But then, problem is half the GUIs out there are *all* trying to be
> that "one and only" GUI. Oh well.

To me, one GUI has already won, and it's called rxvt. ;-)


> > If you think you are too small to make a difference, try sleeping in
> > a closed room with a mosquito. -- Jan van Steenbergen
> 
> Heh, you've got some good quotes. I also really liked that one about
> "Why didn't he append 'I think' to 'wiser people are so full of
> doubts'?"
[...]

Here's one of my all-time favorites:


T

-- 
There is no gravity. The earth sucks.
February 23, 2012
Re: Questions about windows support
I started the dshell just to waste a little time:

http://arsdnet.net/dcode/dshell.d

        dmd dshell.d -L-lreadline -L-lncurses

It doesn't do much here, but there's a few things I think
are cool:

1) D reflection rox. You can write D functions with simple
arguments and it works basically. I want to detect bitfield
enums to automatically do -flags too.

2) Your functions can return whatever, and it is wrapped in
a runtime polymorphic range.

If you just want strings, you can do ProgramDataByLine(input).

If you want something fancier, you can use 
originalProgramData!Type
to fetch out the original input range.


The syntax is so far just the basics... calling functions
and pipes.



but hey its kinda cool already.
February 23, 2012
Re: Questions about windows support
On 23 February 2012 15:56, Adam D. Ruppe <destructionator@gmail.com> wrote:
> I started the dshell just to waste a little time:
>
> http://arsdnet.net/dcode/dshell.d
>
>        dmd dshell.d -L-lreadline -L-lncurses
>
> It doesn't do much here, but there's a few things I think
> are cool:
>
> 1) D reflection rox. You can write D functions with simple
> arguments and it works basically. I want to detect bitfield
> enums to automatically do -flags too.
>
> 2) Your functions can return whatever, and it is wrapped in
> a runtime polymorphic range.
>
> If you just want strings, you can do ProgramDataByLine(input).
>
> If you want something fancier, you can use originalProgramData!Type
> to fetch out the original input range.
>
>
> The syntax is so far just the basics... calling functions
> and pipes.
>
>
>
> but hey its kinda cool already.

And I've been playing with trying to write my own terminal emulator. I
actually kinda have one working, in C. I just need to wrap all the C
code in functions and do all the interesting stuff in D.

The terminal doesn't support most (any) terminal codes, in either
direction it also doesn't do any scrolling, so if you hit the end of
the window, you're kinda screwed... Its more a proof-of-concept than
anything actually usable.

But I have plans for it, including some cool graphical stuff. I'm
using clutter to render everything, so I can do all sorts of things
with it, but to start with, I'd like to be able to display pictures
inline, so you can do `cat my_pic.jpg` and rather throwing masses of
garbage at you, it renders the picture, I might have to write my own
cat to do so however...

--
James Miller
February 23, 2012
Re: Questions about windows support
On Thu, Feb 23, 2012 at 06:02:30PM +1300, James Miller wrote:
[...]
> And I've been playing with trying to write my own terminal emulator. I
> actually kinda have one working, in C. I just need to wrap all the C
> code in functions and do all the interesting stuff in D.
[...]
> But I have plans for it, including some cool graphical stuff. I'm
> using clutter to render everything, so I can do all sorts of things
> with it, but to start with, I'd like to be able to display pictures
> inline, so you can do `cat my_pic.jpg` and rather throwing masses of
> garbage at you, it renders the picture, I might have to write my own
> cat to do so however...
[...]

Now *that* is an excellent idea!

Perhaps there's a way of detecting JPEG or PNG output, say some kind of
magic number detection ala /usr/bin/file. Buffer the first few bytes at
output at the start of new lines, and if it looks like a JPEG file,
buffer the rest of the output instead of displaying it immediately, and
if after reading more input it does appear to be a valid JPEG file, then
display it as an image.  Otherwise flush the buffer and display it as
text.

To prevent problems with false positives causing output not to appear,
you could use a timer: if the data type can't be determined within, say,
1/20 of a second, then skip the detection and display the output as
text. Presumably if you do cat my_pic.jpg more than just the first few
bytes will come out in the first 1/20 of a second, so it will pretty
much reliably detect image data.

Or you can do it the easy way by having a dedicated escape sequence that
switches to image mode, and write a wrapper for cat that outputs this
sequence when it detects image data in its output. The danger though is
that you might get stuck in image mode if cat crashes before the image
data is completely spooled, in that case it'll be like the ole DOS days
when you got stuck in VGA mode when it has dropped back to the DOS
prompt, and typing only produces line noise on the screen. :P


T

-- 
This is a tpyo.
February 23, 2012
Re: Questions about windows support
On Thu, Feb 23, 2012 at 03:56:49AM +0100, Adam D. Ruppe wrote:
> I started the dshell just to waste a little time:
> 
> http://arsdnet.net/dcode/dshell.d
> 
>         dmd dshell.d -L-lreadline -L-lncurses
> 
> It doesn't do much here, but there's a few things I think
> are cool:
> 
> 1) D reflection rox. You can write D functions with simple
> arguments and it works basically. I want to detect bitfield
> enums to automatically do -flags too.

Nice!!! So you can write the same code for both the "shell library" and
the actual shell itself.


> 2) Your functions can return whatever, and it is wrapped in
> a runtime polymorphic range.

Cool, this is better than just plaintext stdin/stdout. :)


> If you just want strings, you can do ProgramDataByLine(input).
> 
> If you want something fancier, you can use originalProgramData!Type
> to fetch out the original input range.

Nice.


> The syntax is so far just the basics... calling functions
> and pipes.

The echo command has a bug, it's not supposed to output 'echo' as part
of its output. :)


> but hey its kinda cool already.

It's extremely cool. Definitely orders of magnitude better than writing
the equivalent thing in C. Can you imagine the amount of code
duplication & ugliness that you'd need in an equivalent C
implementation?  Without reflection, you'd either need hand-coded tables
all over the place or insanely complex nested macros that nobody can
understand.


T

-- 
GEEK = Gatherer of Extremely Enlightening Knowledge
5 6 7 8 9 10 11
Top | Discussion index | About this forum | D home