As I said, ALL gnome apps should be using a *.desktop file for putting a shortcut on the foot menu. All gnome apps that I get do this. If it doesn't it is not a real gnome app. However, the gnome developers aren't the rulers of some world order, so they can't MAKE anybody do this. The only thing they should do is don't provide a link on the gnome website to an app that doesn't install a *.desktop file.
Could you tell me what you mean by no standard. It seems about as good as a standard as you can get, considering there is no law on breaking them.
Re:before we put the cart before the horse . . .
on
The Future of GNOME
·
· Score: 1
IceWM handles the panel pretty, even if it isn't compiled with gnome support. Howevever, sometimes it can go haywire, and not respect the panel. If this happens, reshape the panel in someway, like enable then disable autohide, or retract and then re-retract(or track, make it visable again, you know) with the hide buttons. However, if you have been using newer gnome releases (like 1.0+) this won't happen.
I went to try E again, it crashed, probably a fluke, but, I think I will wait a few months before I use it again.
The apps add shortcuts to the foot menu automaticly. What are you talking about? Yea, some don't, but most do. Their is no way to force an app maker to include a *.desktop file, but it is expected of them.
Re:before we put the cart before the horse . . .
on
The Future of GNOME
·
· Score: 1
What exactly do you change in the E config app so it acts "normally". Also, can E be made to not covoer up the gnome panel. IceWM does this fine, but e will let certain apps like netscape cover up the panel, and others like gmc not.
I run X normally with 15bpp. I then have a game mode, that is 16bpp. This lets me go fullscreen without worrying about the mouse panning. And as I said above, games can go fullscreen without all of this fuss automatilcy like q3test, to bad none of them do.
DRI should let GL accelerated games run as fast as they do in windows, under X. That assumes that agp is supported by linux by that time.
Get a DreamCast if you want NO overhead. For computers, you expect a little overhead. With computers, you expect more than just games to be run. People who design the process assume you wan't to return to normal work afterwards.
X is not that big a resource to have running in the background. All the work that it will be doing is opening a window. What makes X seams like a pig is that most of your apps use X's resources, for things like pixmaps. Just open a little X session with "xinit -e gamename" to get a minimal X session.
Well, modern games should be using OpenGL. When the opengl drivers get DRI support, then they all should run much faster. This even goes for 2d games.
Ohh yea, you can shrink the size of X, so you can get fullscreen. Quake should do that itself, but it doesn't for some reason. Q3 does automaticly go fullscreen however. It is the games fault.
For single user, just set the limit to about as much memory as you have per process. Netscape used to hang my machine in thrashing. Tried something like this: ulimit -Hs 31000 ulimit -Hd 63000 when I had 32mb of ram. Netscape would crash a lot though, but at least the rest lived.
Although, I still wonder, how would I stop one of those malloc or fork bombs. The fork bomb made my system very slow, lucky I didn't lose focus on the xterm it was running in. About how long would it take to die.
Wasn't that Maya port just the renderer. Anyway, that means linux needs some real good 3D apps. Something that cost $29 or $100 just can't match software that cost $30,000+. Nobody is that deluded to pay that much more. Hell, if their was some open source 3d apps, I might believe they could stand a chance against the big time 3d apps, as the price/quality ratio isn't so glaring.
I remember doing something like that with IE 3.0. Didn't use it much, didn't fid much use for it. How did it fail to deliver (assuming that IE uses DCOM for this)
When you say something like that, right away some guy is gonna respond, like he and the rest that use network tranparency are the norm. Im with you, id be suprised if network tranparency is even used 5% of the time.
Play in X. I have very simple scripts that open a new X server on a different virtual terminal and then launches the game. I can use a different resolution for that X server. So, it basicly ends up were the game is fullscreen. The only problem is that you can easily change the game resolution while playing it. But thats no problem for me, I am dedicated to 640x480.
Xfree86 X servers have an extension to the X protocal called XF86VidMode (I think). This lets apps switch the resolution on the fly. Its what Quake3 Test uses to go fullscreen, and what all games for Linux should use in my opinion. Yea, I know its XFree86 specific, but most people use XFree86. If it becomes common, commercial servers will add it.
Another reason to make a fat partition for ports like this. Kingpin suffured from this problem. By playing it off of my windows partition, all the File/FILE/file problems were gone. By the way, Im to lazy to go check the man pages, so il ask here: can you make fat partitions from linux. Im sure their is, right?
Blender, and Houdini is maybe already available, or at least being beta tested on linux. I don't know squat about hudini, but it cost a lot of money, which should make it good for somebody, and usefull on that hardware.
I was gonna yell without thinking something like "q2, q3, kingpin, and lots of other binary only software works fine with . .." then I remembered these games work fine RedHat, and I have never tested them on a different distrobution on linux.
For a game like quake3, it links to libMesa.so, and a lot of X libraries that just about every distro has. And glibc. Most newer distro's include all of that. The only problem would be 3d drivers. For a game like quake3, users have to do a little work getting the 3d drivers, as I don't think Voodoo, G200, or TNT drivers ship with any distros. Same for every distrobution. I guess when the next batch come out, this will no longer be a problem. I guess the main problem now is getting the drivers faster, and generally avialable.
Including drivers, and static linking seems to not be a problem for these game makers under windows, so that is a silly excuse to not port to linux.
I have been compiling the tnt drivers from the CVS server, and even with MesaCVS, it is slower than the drivers that came with the rpms pointed to on mesa3d. About 15% slower with q2. They however do fix one bug: xscreensaver gl screensavers don't flicker.
They really can't manipulate linux's development, since the thing requires a whole new computer. Most people probably wont get a new computer just for linux, so you should really just fear a company making a really good but different distro. for the x86 platform. Do you mean that amiga might defy the GPL. It seems like a very fragile company, and a challenge like that would kill them in months, once and for all.
I compiled glx with Mesa 3.0 and Mesa 3.1, and I got no speedup in q2.
What does this have to do with Amiga? I would say there is almost no chance they will use X or the Mesa 3DFX drivers, which is what slows Quake down for Linux.
They allowed hardware info to one person. And I am pretty sure the windows and linux glide codebases are different. This one guy makes glide drivers for Voodoo cards (Daryll Strauss).
Slashdot Mirror
You know that GNOME started years after KDE. That is one good reason why KDE is ahead.
As I said, ALL gnome apps should be using a *.desktop file for putting a shortcut on the foot menu. All gnome apps that I get do this. If it doesn't it is not a real gnome app. However, the gnome developers aren't the rulers of some world order, so they can't MAKE anybody do this. The only thing they should do is don't provide a link on the gnome website to an app that doesn't install a *.desktop file.
Could you tell me what you mean by no standard. It seems about as good as a standard as you can get, considering there is no law on breaking them.
IceWM handles the panel pretty, even if it isn't compiled with gnome support. Howevever, sometimes it can go haywire, and not respect the panel. If this happens, reshape the panel in someway, like enable then disable autohide, or retract and then re-retract(or track, make it visable again, you know) with the hide buttons. However, if you have been using newer gnome releases (like 1.0+) this won't happen.
I went to try E again, it crashed, probably a fluke, but, I think I will wait a few months before I use it again.
No comment has been scored down, not even obvious trolls. Come on, at least get the ones in all caps.
The apps add shortcuts to the foot menu automaticly. What are you talking about? Yea, some don't, but most do. Their is no way to force an app maker to include a *.desktop file, but it is expected of them.
What exactly do you change in the E config app so it acts "normally". Also, can E be made to not covoer up the gnome panel. IceWM does this fine, but e will let certain apps like netscape cover up the panel, and others like gmc not.
I run X normally with 15bpp. I then have a game mode, that is 16bpp. This lets me go fullscreen without worrying about the mouse panning. And as I said above, games can go fullscreen without all of this fuss automatilcy like q3test, to bad none of them do.
DRI should let GL accelerated games run as fast as they do in windows, under X. That assumes that agp is supported by linux by that time.
Get a DreamCast if you want NO overhead. For computers, you expect a little overhead. With computers, you expect more than just games to be run. People who design the process assume you wan't to return to normal work afterwards.
X is not that big a resource to have running in the background. All the work that it will be doing is opening a window. What makes X seams like a pig is that most of your apps use X's resources, for things like pixmaps. Just open a little X session with "xinit -e gamename" to get a minimal X session.
Well, modern games should be using OpenGL. When the opengl drivers get DRI support, then they all should run much faster. This even goes for 2d games.
Ohh yea, you can shrink the size of X, so you can get fullscreen. Quake should do that itself, but it doesn't for some reason. Q3 does automaticly go fullscreen however. It is the games fault.
For single user, just set the limit to about as much memory as you have per process. Netscape used to hang my machine in thrashing. Tried something like this:
ulimit -Hs 31000
ulimit -Hd 63000
when I had 32mb of ram. Netscape would crash a lot though, but at least the rest lived.
Although, I still wonder, how would I stop one of those malloc or fork bombs. The fork bomb made my system very slow, lucky I didn't lose focus on the xterm it was running in. About how long would it take to die.
Wasn't that Maya port just the renderer. Anyway, that means linux needs some real good 3D apps. Something that cost $29 or $100 just can't match software that cost $30,000+. Nobody is that deluded to pay that much more. Hell, if their was some open source 3d apps, I might believe they could stand a chance against the big time 3d apps, as the price/quality ratio isn't so glaring.
I remember doing something like that with IE 3.0. Didn't use it much, didn't fid much use for it. How did it fail to deliver (assuming that IE uses DCOM for this)
You wouldn't be comparing fvwm95 to BeOS's gui. That would be kind of unfair. Just asking, since you say you are using RH 5.2.
I think so. Try the glx from CVS.
When you say something like that, right away some guy is gonna respond, like he and the rest that use network tranparency are the norm. Im with you, id be suprised if network tranparency is even used 5% of the time.
"shouldn't be allowed to enforce any of them"
Even murder, robbery, and jaywalking. Yea, thats a good idea.
Play in X. I have very simple scripts that open a new X server on a different virtual terminal and then launches the game. I can use a different resolution for that X server. So, it basicly ends up were the game is fullscreen. The only problem is that you can easily change the game resolution while playing it. But thats no problem for me, I am dedicated to 640x480.
Xfree86 X servers have an extension to the X protocal called XF86VidMode (I think). This lets apps switch the resolution on the fly. Its what Quake3 Test uses to go fullscreen, and what all games for Linux should use in my opinion. Yea, I know its XFree86 specific, but most people use XFree86. If it becomes common, commercial servers will add it.
Another reason to make a fat partition for ports like this. Kingpin suffured from this problem. By playing it off of my windows partition, all the File/FILE/file problems were gone.
By the way, Im to lazy to go check the man pages, so il ask here: can you make fat partitions from linux. Im sure their is, right?
Blender, and Houdini is maybe already available, or at least being beta tested on linux. I don't know squat about hudini, but it cost a lot of money, which should make it good for somebody, and usefull on that hardware.
I was gonna yell without thinking something like "q2, q3, kingpin, and lots of other binary only software works fine with . . ." then I remembered these games work fine RedHat, and I have never tested them on a different distrobution on linux.
For a game like quake3, it links to libMesa.so, and a lot of X libraries that just about every distro has. And glibc. Most newer distro's include all of that. The only problem would be 3d drivers. For a game like quake3, users have to do a little work getting the 3d drivers, as I don't think Voodoo, G200, or TNT drivers ship with any distros. Same for every distrobution. I guess when the next batch come out, this will no longer be a problem. I guess the main problem now is getting the drivers faster, and generally avialable.
Including drivers, and static linking seems to not be a problem for these game makers under windows, so that is a silly excuse to not port to linux.
I have been compiling the tnt drivers from the CVS server, and even with MesaCVS, it is slower than the drivers that came with the rpms pointed to on mesa3d. About 15% slower with q2. They however do fix one bug: xscreensaver gl screensavers don't flicker.
Of course.
They really can't manipulate linux's development, since the thing requires a whole new computer. Most people probably wont get a new computer just for linux, so you should really just fear a company making a really good but different distro. for the x86 platform.
Do you mean that amiga might defy the GPL. It seems like a very fragile company, and a challenge like that would kill them in months, once and for all.
Should have mentioned that I also use a TNT.
I compiled glx with Mesa 3.0 and Mesa 3.1, and I got no speedup in q2.
What does this have to do with Amiga? I would say there is almost no chance they will use X or the Mesa 3DFX drivers, which is what slows Quake down for Linux.
They allowed hardware info to one person. And I am pretty sure the windows and linux glide codebases are different. This one guy makes glide drivers for Voodoo cards (Daryll Strauss).