Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Warp wrote:
>>> Darren New <dne### [at] sanrrcom> wrote:
>>>> They should at least stop putting misinformation in the documentation like 
>>>> "you can't delete open files in Windows" or "Windows doesn't have links". 
>>>> That's just plain wrong. The minimum would be to phrase it as "we don't open 
>>>> files in a mode that allows them to be deleted while open" and "we don't 
>>>> support links in Windows".
>>>   It's an open source project. You can contribute.
> 
>> Wow, really?? Thanks, Warp! I didn't know that!
> 
>   And then you criticize me when I use sarcasm.

No, I criticize you for not making it obvious enough. For the record. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

Orchid XP v8 wrote:
> Darren New wrote:
>> Somehow, I always find it amusing how many FOSS programs assume 
>> Windows is basically how it was in Win98 and completely fail to do the 
>> right thing.
> 
> ...which does, on the other hand, have the side-effect of making it 
> compatible with Win98. ;-)

One might think that, but that tends not to be the case. In part, for 
example, it'll support things like memory-mapped files and etc. as well.

> Or, more likely, "we just took our C sources and recompiled them on top 
> of a POSIX emulator, so we can't do anything that POSIX doesn't support 
> / the emulator doesn't implement".

Yes. Altho I don't think that's really the case. Tcl, for example, has a 
whole X-windows emulation built in. That's why it's (a) somewhat slow, (b) 
tends to look like Motif, and (c) gets used everywhere as a graphics library 
for other languages. :-)

Come to think of it, one of the nice things about Tcl is how much people 
have made extensions for accessing Windows-like stuff.  Considering this, I 
expect I can find Python (for example) extensions to Do The Right Thing.

It really wasn't a complaint, as much as it was a "I wonder why people don't 
fix this when they do it in the first place" sort of thought. Sort of "if 
you're going to try to invent an algorithm to figure out where the home 
directory is, why not just ask the OS". If it was completely unsupported, I 
could see it, but to have it half-ass supported is ... half-ass.

Maybe I'm just getting sick of half-assed technology, tho.

>> And some people wonder why FOSS feels klunky on Windows.
> 
> Heh, well, the *really* fun thing is when you have to install GTK+ 
> before the program will run... We all know what happens then. ;-)

Actually, I don't think I do.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

>> Or, more likely, "we just took our C sources and recompiled them on 
>> top of a POSIX emulator, so we can't do anything that POSIX doesn't 
>> support / the emulator doesn't implement".
> 
> Yes. Altho I don't think that's really the case.

It is sometimes.

Like, there are several CLI tools which are just recompiled against 
Cygwin to make a "Windows port", and you find that all sorts of strange 
things break when you do that.

> Maybe I'm just getting sick of half-assed technology, tho.

I know *I* am. But it's not like you can do anything about it... I used 
to think you could, but apparently you can't.

>>> And some people wonder why FOSS feels klunky on Windows.
>>
>> Heh, well, the *really* fun thing is when you have to install GTK+ 
>> before the program will run... We all know what happens then. ;-)
> 
> Actually, I don't think I do.

...the program uses the GTK+ look and feel, rather than behaving like a 
native Windows application?

Than again, on Linux it seems each program has its own totally different 
look and feel, so...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> ...the program uses the GTK+ look and feel, rather than behaving like a
> native Windows application?

I'm pretty sure Gimp on Windows uses the Windows (2000) look and feel.  It
doesn't use its API, though, it instead uses GTK file dialogs and others.

Post a reply to this message

Orchid XP v8 wrote:
>>> Or, more likely, "we just took our C sources and recompiled them on 
>>> top of a POSIX emulator, so we can't do anything that POSIX doesn't 
>>> support / the emulator doesn't implement".
>>
>> Yes. Altho I don't think that's really the case.
> 
> It is sometimes.

Sure. I meant, I don't think it's really the case that the entire Python 
language suite was ported simply by recompiling with cygwin. I might be 
wrong, but it seems like a rather large program for that sort of easy technique.

> I know *I* am. But it's not like you can do anything about it... I used 
> to think you could, but apparently you can't.

You can give up. Or get away from anything even remotely cutting-edge or 
designed for clueful people.

I have noticed my XBox works great. It's very robust and forgiving. (I 
haven't had any hardware problems, mind.) I attribute that to being aimed at 
children.

> ...the program uses the GTK+ look and feel, rather than behaving like a 
> native Windows application?

OK. I guess I don't know what GTK+ looks like enough to recognise that as 
such. Motif, yes. Tcl/Tk and derivatives, yes.

> Than again, on Linux it seems each program has its own totally different 
> look and feel, so...

Sometimes. There's at least three or four common ones.

-- 
Darren New, San Diego CA, USA (PST)
   Human nature dictates that toothpaste tubes spend
   much longer being almost empty than almost full.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Orchid XP v8 wrote:
> >>> Or, more likely, "we just took our C sources and recompiled them on
> >>> top of a POSIX emulator, so we can't do anything that POSIX doesn't
> >>> support / the emulator doesn't implement".
> >>
> >> Yes. Altho I don't think that's really the case.
> >
> > It is sometimes.
>
> Sure. I meant, I don't think it's really the case that the entire Python
> language suite was ported simply by recompiling with cygwin. I might be
> wrong, but it seems like a rather large program for that sort of easy technique.

Certainly not.  But I don't think either it'd be as easy as submitting a patch
with the W32 calls in place.  I'm sure many people may have tried before and it
was ditched because it'd not be fine to have W32 calls right into the
multiplatform core.  Are you sure the MS Windows specific modules don't give you
some handy extra features?  msvcrt, in particular.

> I have noticed my XBox works great. It's very robust and forgiving. (I
> haven't had any hardware problems, mind.) I attribute that to being aimed at
> children.

apart from 3RLs, that is? ;)

> > ...the program uses the GTK+ look and feel, rather than behaving like a
> > native Windows application?
>
> OK. I guess I don't know what GTK+ looks like enough to recognise that as
> such. Motif, yes. Tcl/Tk and derivatives, yes.

Nowadays I'd say it's mostly the industrial or clearlooks look.  The GTK file
dialog is easily recognizable too.

Post a reply to this message

Darren New wrote:
>> About the links: yes, windows does indeed support links. I do not dare 
>> to use them anymore. I tried once, but since people don't expect hard 
>> links under Windows to some it came as a nasty surprise when they 
>> discovered the doublettes they thought they were deleting were the 
>> actually hard linked files... 
> 
> Well, yes. That's not a good reason for a programming environment not to 
> use them. It's just a good reason to be careful how you expose that to 
> your users. :-)
> 

Personally more annoyed by the fact that, at least in XP, you sometimes 
get a message, "You are only deleting the shortcut to the file, not the 
file, are you sure?" Well, since 90% of the shortcuts are programs, 
deleting the original isn't going to do jack for me either, in any case, 
since it won't delete the other 2 GB of shit that got installed with the 
executable. If they cared about the distinction, they should provide an 
"Uninstall" option with that warning... Then again, its a warning for 
morons, so.. probably a bad idea, since some of them are bound to 
uninstall, when all they meant was to delete the shortcut. :p


-- 
void main () {
   If Schrödingers_cat is alive or version > 98 {
     if version = "Vista" {
       call slow_by_half();
       call DRM_everything();
     }
     call functional_code();
   }
   else
     call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models, 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott <sel### [at] npgcablecom> wrote:
> Then again, its a warning for morons, so..

  I wouldn't say that. It was previously a lot more confusing when you
attempted to delete a shortcut and it simply said "really delete xyz?"
where 'xyz' was the name of the file the shortcut was pointing to, with
no indication whatsoever in the dialog that only the shortcut itself would
be deleted, not the file. It always gave a feeling of playing russian
roulette with a potentially important file.

  Now it explicitly says that what is being deleted is only the shortcut,
not the file being pointed to, which is an improvement.

  An "uninstall" option to shortcuts would actually be a good idea IMO.

-- 
                                                          - Warp

Post a reply to this message

Darren New wrote:
> nemesis wrote:
>> My guess is that that won't change while the portable C stdlibs they use
>> don't get updated to more modern times to cope with extra features...
>> when in doubt, use the lowest common denominator.
> 
> Yeah, I think that's the basic problem. Even so, you'd think the portable
> libraries would at least try to support the same semantics where they can.
> I hear the "Windows can't delete an open file" so often it's silly. Why
> wouldn't you make your C compiler's "open" function set the flag that says
> "let me delete open files" if that's how it works in POSIX?

I'm pretty sure you have to blame Microsoft itself for that. Isn't open() 
defined in msvcrt.dll?

Post a reply to this message

Orchid XP v8 wrote:
> Heh, well, the *really* fun thing is when you have to install GTK+
> before the program will run... We all know what happens then. ;-)

In Linux you have to install GTK+ before the program will run too. The 
difference is that Linux distros have package managers that make it sane.

Post a reply to this message