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

nemesis wrote:
> 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.

AFAIK, GTK+ looks like Windows using the same technique as Java Swing: 
implementing the theme from scratch to look like that.

And that is when you notice subtle Windows details that you don't normally 
notice... when Swing gets them wrong.

Post a reply to this message

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

Now that you mention it, quite possibly yes. :-)

-- 
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

>> 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.

More correctly: The difference is that on Linux, *lots* of programs use 
GTK+, not just the GIMP. ;-)

Actually, one of the more perplexing things about Linux is how different 
widget toolkits look and behave completely differently. Things seem to 
have got more sane over there recently, thank God...

Post a reply to this message