You do realize that mozilla for win32 also uses MS's API's? At least I'm presuming so, unless they re-implemented outlook, ms-help, and vs URL's on their own.
They don't use the functionality provided from Microsoft applications, only the Win32 API. Relying on finding MS applications that behave exactly the same way on Windows, Mac, Linux, HP/UX, Solaris, BeOS and OS/2 is impossible. And, after all, Outlook isn't even installed on most systems, and Outlook Express can be removed with hacks such as Win98 Lite.
Hmm... Qt already support different visual styles. It contains built-in support for Motif, Windows and Mac (Platinum) lookalike. If they are implemented through C++ classes and virtual functions, this could be easier than I first had imagined.
That was not what I wanted. The KDE guys kan still use Qt, and all Gnome people can still happily live on with GTK+ and C. However, they should both use tha same low-level routines for drawing buttons, menubars and other items. No adaptation should be neccessary for the programmers, the code hiding behind the Qt and GTK+ API:s should be modified to handle this.
WHY is it this way? From a bandwidth point-of-view, this is a horrible solution for a network independent protocol. Instead of saying "draw a button at this position, caption 'OK'" you send several kilobytes of pixel information. Exactly the same thing goes for window managers as for toolkits: saying "new window here" would be much better. All drawing would be done by the library in the displaying machine.
what you are suggesting (or meaning to suggest) is probably that all these toolkits should have different API's but draw the same thing onscreen. Now why exactly is that good?
All applications would look the same and act the same. Let's say that you start Emacs and Gnumeric under KDE. Now you see three different graphical widget styles, all acting slightly different. If I set KDE to use a single menubar on top of the screen, only applications utilizing the KDE (or Qt?) framework adhere to this rule. This is just so damn wrong.
By utilizing a single, underlying library for these things, problems like these would disappear. I don't see anything wrong in all applications behaving the same - a consistent user experience can't be bad.
A standard widget and graphical component library. I don't care if you use GTK+, Qt, Motif or some other more or less perverted set of functions, they should all result in using the same components with the same look and feel. Let's say you create a menu in GTK+ with the ordinary commands. These instructions should be converted to draw the standard toolbar, using the user preference (menubar on top, in window, detachable...).
I don't see any disadvantage by doing this. You still get to program in the language you prefer with the library commands you prefer, but they all draw the same widgets. While you are at it, design a new clipboard system that works - base it on the existing code from the Gnome and KDE people if you want to.
Is there a reason not to do this? Is it technically impossible? If so, please explain why. I'm a programmer, but I'm not very experienced in X development.
If you look at the prices in Sweden, you can get your X-Box for 4700 SKR (remove last digit to get US dollars). You get a Playstation 2 for 1200 SKR less, and automatically gain the possibility to play all of your old PS1 games. The much larger existing game base for the PS2, and the price, is dragging Microsoft down.
Bingo. This is a point where the Mac - or should I say NextStep - made something very correct. Installing an application found online is a simple process in three stages: download, double-click to unpack from.tar.bz2, move it to the/Applications or ~/Applications folder. Removing it is equally simple: delete the application and *poff* it's gone.
Why hasn't this been adopted by the Unix community? It's just some special treatment of a damned folder! What else is needed for you to accept this solution?
Try to nest several DocumentRoots which have different properties. If we ignore those possibilities: XML is a standardized format. There are several usable parsers for almost every platform out there. Having an Apache-style file follows no specific standards. Parsing will also be a bit more difficult.
The grepping problem that you mentioned is really a non-problem: use xmlgrep, xmltree or similar utilities to find the data note that you are looking for.
It might be easier to make money in the Mac market. Almost all PC games are available via warez channels seconds after official release. Mac games are very hard to find, which makes you buy games more often since it's not worth the time searching for something you want.
Or do you mean "gcc is not known to compile invalid standard non-compliant code well".
No, he probably means that gcc is a good C compiler but the C++ support is bad, at best. I have to say one good thing about gcc: it is probably the most standard-compliant C++ compiler available. Too bad that it generates very slow code.
Intel has got a pretty good C compiler that gives quite a speedup compared to gcc. The bad news is that it crashes or generates bad code when using C++ with templates, operator overloading and other features that are clearly non-C. Even the Linux kernel isn't 100% stable with it.
I'm not sure about American laws, but Sweden makes it mandatory to inspect your car yearly. If not, it is illegal to drive that vehicle. During these checks in special shops, you could easily check the difference between the current driven mile count and the previous one.
Sorry, I'm used to Borland's VCL where there properties are implemented as getFoo/setFoo and accessed with ->Foo. That, and *way* too much Java lately has made my head into a pickled mushroom when it comes to C and C++.
MFC is plain horrible. It features almost none of the OO concepts at all, and encapsulation is the one feature I miss the most. In a toolkit with a good OO design, to change the font of a label to bold you type label->Font->Style = CFont.STYLE_BOLD; or something similar. Not in MFC: you have to use the Win32 API for an operation on that simple level.
The one toolkit I like the most (in the C++ world) is Borland's VCL classes. Swing is very nice and easy to extend. My experience from Apples Cocoa and other toolkits (Qt, GTK, Motif) is near zero, so I'm not going to comment on things I don't know about.
That's even more silly, because it means someone spent a shitload of money to get that C. "Remember, kids - all of your education is worthless, the only thing that matter is how much money you have access to. Just look at your president!"
You can't sit kids down at a computer and yell at them that they better start learning to spell. As an educational tool, computers suck tremendously. Correctly used, ie for information retrieval and similar things, they are a great asset. Teaching is best to leave to the teachers.
Slashdot Mirror
That would come from too much masturbation, something that is free of charge. You won't need Nintendos help with that.
And you are 100% wrong. C# code is compiled into DotNet byte code, which is executed through a virtual machine. It works exactly like Java.
What they really ment was that there are some A-holes in the MPAA that is in desperate need of plugging.
They don't use the functionality provided from Microsoft applications, only the Win32 API. Relying on finding MS applications that behave exactly the same way on Windows, Mac, Linux, HP/UX, Solaris, BeOS and OS/2 is impossible. And, after all, Outlook isn't even installed on most systems, and Outlook Express can be removed with hacks such as Win98 Lite.
Hmm... Qt already support different visual styles. It contains built-in support for Motif, Windows and Mac (Platinum) lookalike. If they are implemented through C++ classes and virtual functions, this could be easier than I first had imagined.
That was not what I wanted. The KDE guys kan still use Qt, and all Gnome people can still happily live on with GTK+ and C. However, they should both use tha same low-level routines for drawing buttons, menubars and other items. No adaptation should be neccessary for the programmers, the code hiding behind the Qt and GTK+ API:s should be modified to handle this.
WHY is it this way? From a bandwidth point-of-view, this is a horrible solution for a network independent protocol. Instead of saying "draw a button at this position, caption 'OK'" you send several kilobytes of pixel information. Exactly the same thing goes for window managers as for toolkits: saying "new window here" would be much better. All drawing would be done by the library in the displaying machine.
All applications would look the same and act the same. Let's say that you start Emacs and Gnumeric under KDE. Now you see three different graphical widget styles, all acting slightly different. If I set KDE to use a single menubar on top of the screen, only applications utilizing the KDE (or Qt?) framework adhere to this rule. This is just so damn wrong.
By utilizing a single, underlying library for these things, problems like these would disappear. I don't see anything wrong in all applications behaving the same - a consistent user experience can't be bad.
A standard widget and graphical component library. I don't care if you use GTK+, Qt, Motif or some other more or less perverted set of functions, they should all result in using the same components with the same look and feel. Let's say you create a menu in GTK+ with the ordinary commands. These instructions should be converted to draw the standard toolbar, using the user preference (menubar on top, in window, detachable...).
I don't see any disadvantage by doing this. You still get to program in the language you prefer with the library commands you prefer, but they all draw the same widgets. While you are at it, design a new clipboard system that works - base it on the existing code from the Gnome and KDE people if you want to.
Is there a reason not to do this? Is it technically impossible? If so, please explain why. I'm a programmer, but I'm not very experienced in X development.
If you look at the prices in Sweden, you can get your X-Box for 4700 SKR (remove last digit to get US dollars). You get a Playstation 2 for 1200 SKR less, and automatically gain the possibility to play all of your old PS1 games. The much larger existing game base for the PS2, and the price, is dragging Microsoft down.
Bingo. This is a point where the Mac - or should I say NextStep - made something very correct. Installing an application found online is a simple process in three stages: download, double-click to unpack from .tar.bz2, move it to the /Applications or ~/Applications folder. Removing it is equally simple: delete the application and *poff* it's gone.
Why hasn't this been adopted by the Unix community? It's just some special treatment of a damned folder! What else is needed for you to accept this solution?
bash: apt-get: command not found
chainsaw@hellport:~$
Nope, that doesn't work.
I don't see how
/some/path</DocumentRoot>
/some/path
<DocumentRoot>
is so much more usable than
DocumentRoot
Try to nest several DocumentRoots which have different properties. If we ignore those possibilities: XML is a standardized format. There are several usable parsers for almost every platform out there. Having an Apache-style file follows no specific standards. Parsing will also be a bit more difficult.
The grepping problem that you mentioned is really a non-problem: use xmlgrep, xmltree or similar utilities to find the data note that you are looking for.
It might be easier to make money in the Mac market. Almost all PC games are available via warez channels seconds after official release. Mac games are very hard to find, which makes you buy games more often since it's not worth the time searching for something you want.
No, he probably means that gcc is a good C compiler but the C++ support is bad, at best. I have to say one good thing about gcc: it is probably the most standard-compliant C++ compiler available. Too bad that it generates very slow code.
Intel has got a pretty good C compiler that gives quite a speedup compared to gcc. The bad news is that it crashes or generates bad code when using C++ with templates, operator overloading and other features that are clearly non-C. Even the Linux kernel isn't 100% stable with it.
I'm not sure about American laws, but Sweden makes it mandatory to inspect your car yearly. If not, it is illegal to drive that vehicle. During these checks in special shops, you could easily check the difference between the current driven mile count and the previous one.
Simple and effective.
Ah, but Internet Explorer is a vital component in Windows. Therefore, it is a sold product - can't sell Windows without it.
Sorry, I'm used to Borland's VCL where there properties are implemented as getFoo/setFoo and accessed with ->Foo. That, and *way* too much Java lately has made my head into a pickled mushroom when it comes to C and C++.
MFC is plain horrible. It features almost none of the OO concepts at all, and encapsulation is the one feature I miss the most. In a toolkit with a good OO design, to change the font of a label to bold you type label->Font->Style = CFont.STYLE_BOLD; or something similar. Not in MFC: you have to use the Win32 API for an operation on that simple level.
The one toolkit I like the most (in the C++ world) is Borland's VCL classes. Swing is very nice and easy to extend. My experience from Apples Cocoa and other toolkits (Qt, GTK, Motif) is near zero, so I'm not going to comment on things I don't know about.
Sorry for that... Too much C++ lately. It takes a few compiler errors before realizing which language you are using again.
/* Not accepted */
int fuckfuckfuckfuckfuckfuckfuckfuck = 2;
int fuckfuckfuckfuckfuckfuckfuckfuckfuck = fuckfuckfuckfuckfuckfuckfuckfuck + 2;
/* Accepted */
int min_value = 2;
int max_value = min_value + 2;
That's even more silly, because it means someone spent a shitload of money to get that C. "Remember, kids - all of your education is worthless, the only thing that matter is how much money you have access to. Just look at your president!"
You can't sit kids down at a computer and yell at them that they better start learning to spell. As an educational tool, computers suck tremendously. Correctly used, ie for information retrieval and similar things, they are a great asset. Teaching is best to leave to the teachers.
The bug is NOT there. You implement the method like this:
// This programmer sucks.
// TODO
void Player::SetMovelistValue(int nIndex, float x, float y)
{
if (nIndex >= MOVELISTSIZE || nIndex < 0) {
return;
}
}
This is what abstraction is for: to help the programmer doing stupid things that might crash the application or some other stupid thing.