Somehow I get a yucky-feeling with 'solutions' that are based on wrappering the underlying cruft instead of fixing it. No amount of duck-taping and gui-frontends will make the Linux dependecy and packaging hell really go away, it will just lead to more obscure harder to track down bugs in the end. What I would really prefer to see would be one standard way to package stuff (relocatable and thus not to tied to where exactly it has to be installed, etc.) and how to handle the install. With all the distros around there is however little chance that we will see that any time soon. Only hope currently is really LSB, if lsb conforming rpms get more widespread in the future they might be a small change that packages moves more and more out of the distro and into distro independend lsb-rpms, however this will, if it ever happens take many many years, so I won't hold my breath...
I have heard that before, but what exactly does that mean? I mean is Nintendo just doing a bit of a marketing trick by not calling it Gameboy or are they going to release a GameboySP2 in the next half year and basically screw up all customers who just bought a NintendoDS?
### Fullscreen mode doesn't make sense in that context - even StarOffice abandoned the idea of running in fullscreen mode a long time back
I am not talking about everything-in-one-window fullscreen, I am talking about 'game-like' fullscreen, ie. application takes controll of the whole screen. All I want to see is the image, my mouse course and maybe the palette, no menu, toolbox or other clutter. Gimp already has such a mode (press F11), but its quite a bit limited in that it doesn't let one move the drawable area around, causing all shorts of throuble when working with larger images.
### Macro recording of mouse and menu movement is not an easy thing to do
I don't mean that kind of low-level macro recording which will screw up quite quickly and isn't much usefull since you can't add parameters to it easily. I mean high level macro recording on the function level, in CorelPhotopaint (anno 1996) I could press the 'Record' button and then see function names + arguments poping up in the record:
For tradinonal Windows3.11 WiW maybe, but thats really not what anybody wants. A simple managing window with a few places to dock stuff into would already be enough to fix most problems and thats really nothing that would require much rewrite, wouldn't even require to change Gtk. Galeon for example already has tabbed-windowing and toolbars that I can rip apart and away from the main-window if needed and things like that in Gimp could make quite a huge improvement.
Well, actually both XFree86 and the Linux kernel have exactly the same problem when it comes to binary drivers, neither of them really handles them all that good. That said, no XFree86 didn't take 90% of the time, since I could interrupt the compile once it compiled the module, quite hacky, but it was actually the recomment way to compile the module. Most of the time was actually wasted to find out that I would have to go all this recompile throuble in the first place. With proper binary drivers in case of problems I could just go download and try the newest version in basically no time, I kind of end up searching for other solutions first, since its hard to know before hand what exactly is causing the throuble (driver, configuration, other issue).
### You feel pain after six years but suggest that those who like the current interface could switch in a month?!
The GUI should be configurable enough to just rip it into pieces and go back to the 'all floating around' style of things. I am NOT saying that forcing everybody into a WiW is a good thing, just saying that playing hide&seek with my dialogboxes really can't be the right way to design a userinterface.
### So an interface like that of Blender? Won't work good with GTK.
Well, then lets go and fix Gtk, just because Gtk can't do it isn't much a good excuse for not even trying it at all. After all Gtk still stands for 'GIMP Toolkit' so I guess implementing a bit of functionality that is needed by Gimp into it shouldn't be all that difficult.
### And just look how many people are complaining about the interface of Blender!
They are complaining because the Blender GUI has some major problems, but at least the Blender developers admit it and seem to improve the situation slowly, but constantly. Every new Blender release so far was full of a wealth of good new features, new Gimp releases, which happen quite less frequently haven't provided anything substantly for quite some time.
### But as long as we deal with traditional GUI paradigms GIMP isn't halfway bad.
Gimp already is pretty far away from tradinional GUI.
### The developers aren't interested in fixed "problems" that don't really exist
Well, if these problems don't exist them I am sure we want have long endless discussions about the next time when Gimp is in the news, after all we didn't have these discussions the last five years... oh wait, maybe we did.
### Just because YOU think it's unusable, doesn't mean everybody does!
This issue pops up absolutly EVERY TIME gimp is mentioned somewhere, this really is not a 'just me' issue, its a issue for A LOT of people.
### Why don't you complain about Photoshop on Mac too?
Because I never used them, I use Gimp exclusivly for the last ~6 years and STILL have some major issues with the GUI, not because 'its me' but because the interface just has some major problems.
### Why don't you use nautilus or any other fileviewer then?
I do most of the time, however having thumbnail for all files in the open/save dialog would still be extremly usefull. This functionallity might be good to have in the Gtk+ filedialog itself, however it wouldn't have been rocket-sience to implement it in Gimp already years ago.
### It is possible for a long time already by means of "Script-Fu->Selection->To Brush".
I know, it however fills the brush dialog with junk which I then have to manually select and delete. What I mean is functionality like provided by DeluxPaint, select a region, select paintbrush and instantly you are able to use that selected region as brush, extremly usefull sometimes and its a better of seconds to use and discard a brush, Gimps current brush handling is far more tricky to use.
### Now do you seriously expect to get friendly response when you address volunteers in such a way? You get back what you throw at people.
Guess why I have written that subject line, its not that I was being hostile against Gimp back then when I started using it, it mainly where the mailing list, IRC discussions and the lack of progress that made me feel that way.
### Overall, please either by from open source friendly hardware vendors, or pay the price for a proprietary operating system.
The problem is that even IF you by from a OSS friendly hardware vendor its still a PITA to get a driver running if it happens to be developed outside the Linux kernel. Little example, my graphics tablet is perfectly supported under Linux, by both the kernel and XFree86, however the driver that came with both the kernel and XFree86 had a bug, so I had to download and recompile around 70MB of source code just to get a few Kilobytes of binary driver that would run fine with by version of the kernel and xfree86. It did cost me almost two days to figure out and get it up&running completly, this really shouldn't be acceptable these days and is completly unnecessary.
### They may not be enough for you, but those of us who like and are used to the interface it's the best way: we get improvements, but don't have to relearn.
I doubt it. I feel the pain in using the Gimp interface every time I use the Gimp, and thats after almost 6 years of regular Gimp usage. Relearning a new interface would take how long? A day to get confortable with it? Maybe a week to master it? Maybe a month to completly know it in an out? The time that is taking to relearn should be easily be made up for in very few days, after all it wouldn't be completly different or completly new, it would just mean sticking all those floating dialog boxes together in a grid, keep them in place, keep them where they are usefull (aka. not hide them behind your image window and such..) and maybe add a few more buttons say for undo/redo, for rotating, flipping stuff, rect or circle drawing, etc. Overall nothing that would take any time at all to relearn, just functionality in a better accessible place. After all some more radical change in the GUI should make the UI more accessible for everybody, keeping it as it is ensures that it is inaccessible for almost everybody.
### Do it, or find someone to do it for you; the developers aren't interested.
Yes, I know, and thats one of the things that is slowing Gimp down alot. If the developers aren't interested at all in improvements, its not really all that motivating for writing patching. As it stands now any kind of WiW patch would have quite a hard time getting accepted by the Gimp developres.
* ugly user interface, no matter of WiW is the way to go or not, currently I have to dig around for my palette or brush dialogs far to many times they really MUST be dockable to the image window to make Gimp painless to use. People saying that the current way is 'right' are just bloody ignorant, this issue is really poping up every time gimp is mentioned somewhere, yet still the developers failed to address it properly in the last 5 years
* lack of a proper fullscreen mode, while its there is quite limited in they way that one can scroll, dialog boxes cover the drawing area so that one constantly has to move stuff around, again proper docking to the image borders might help a lot
* lack of advanced brushes, currently all of gimps brushes are quite primitive, just the bare basics and there is no way to write new-ones as plug-ins, making it hard to actually create new ones. That said it was been tried to implement new cool stuff, but it never made its way into the Gimp:
http://www.levien.com/gimp/wetdream.html
* lack of macro recorder, my 1996 version of Corel Photopaint had already a kick-ass macro recorder, making it a joy to create scripts, you just recorde a macro, do what you want, go into the script editor add a few parameters to it, add a GUI dialog and you have a nice script in basically no time, Gimp today is still stuck with only Script-Fu and friends which are both a pain to write and debug, no macrorecorder there at all
* lack of power in the scripting, plug-ins and PDB interface lacks functions, there are a bunch of functions that are available in the GUI, but not available in the scripting, so that one has to manually build-them, making scripting even more a pain than it already is. The GUI should ideally be just a 'container' that connects scripts with each other, everything in the GUI should be available in the scripting and each part of Gimp should be modifiable via scripting/plug-ins, brushes, gui, whatever.
* tablet support, while its there it is not really that good, double-clicking is almost impossible on the Gtk components, with a tablet the clicks end up at different positions, Gtk+ seems to lack the tolerance to still register it as doubleclick, might be a Gimp, Gtk+, Xfree86 issue or whatever, however its causing quite huge throuble in Gimp (if there is some fix/hack/patch for it I would like to know)
* load/save dialog, these are really just the standard Gtk+ ones with a single thumbnail, however for a graphic application it would be quite usefull to have full thumbnail view of all images, like you get in Nautilus or any fileviewer
* very bad suport indexed images, one doesn't need them all that often these days, but still sometimes one need them and then Gimp is just a pain in the ass, a decade old version of DeluxPaint was way better at handling them
* no quick&easy way to create brushes, ie. I would like to use a layer click a 'to-brush' button and then paint with it, however thats more or less impossible todo today, I have to save the image as brush, tweak some parameters, then select it from the brush dialog, etc. cost by far to much time for an operation that should really be 'single-click', beside from that brush handling itself is quite a arkward, some brushes are resizable, some others not, while idealy all should be modifiable and it even shouldn't be that difficult to implement
* developers seem to be quite hostile against any suggestions from the outside, both on IRC and on the mailing list, other people seem to have made similar experiences so its not just me, other OSS projects seem to be quite a bit more friendly to their users
There are probally a lot of more issues I have forgotten, but well, that should be the more important ones. Last not least, yeah I know, many people will now say that its OSS so I have no f*** right to critic it and if I would like the features I should implement them myself and beside Gimp is of course doing everything right and I am the one that is just using it wrong (wondering how that can happen after 6 years of gimp usage...), but well, go start flame me now...
### Yes interface matters, don't break it, for those who grok it. Improvements like from 1.2 to 2.0 are the way to go.
Those micromal improvements are NOT the way to go, that way it will take a hundred years before it starts becoming a really useable application. How about making the GUI configurable? Its not that the floating-windows stuff needs to go completle, just have a checkbox in the Preferences to switch from WiW to floating-windows and some Tip-Of-Day to inform users about it. It really should not be all that difficult, especially with docking already in place, just provide a larger managing window where the docks get a fixed place and make the image windows dockable and tabable too. This issue has really been there since day 1 and it really hasn't been getting much better at all in the last five years.
### If you need it right now you'll need to look elsewhere. There are many, many applications for a raster editor where colour management does not matter.
Sadly not so much on GNU/Linux, but yeah Windows and Mac users have plenty of alternatives.
The only problem is that you can not dock the image window, which is really the one that would be most 'dock-worthy' in the end. Docking is overall a nice add-on, but it only reduces the clutter a little bit. Still by far to many windows floating around, when it comes to brushes or palette I want to have them docked where I need them, to the window, not hidden behind half a dozens other dialogs.
Beside from that the 'floating window' issue makes some of the image-menu entries rather weird, like having a 'Quit' button per-Image, but it acts for the whole App and such.
Speaking about fuzzy pixels, try to run a LCD at a non-native resolution, which is quite common required for gaming, and even the damn cheapest CRT will look like a beatifull masterpiece in comparism to the blurred scaled up image a LCD will give.
That said, yes, LCDs might be better for some uses, but they have so many disadvantages that I still wouldn't exchange them against my good old CRT.
Not really perfect and still in its very early days, but already quite a bit usefull for finding some free art is the Game Media Repository, available at:
http://undone.clanlib.org/~grumbel/show.cgi
Quality of the stuff in their varies a lot, so success of your searches may variy, still might be worth a try, especially for game related stuff like sprites and 3d models.
The easiest way to get today the 'daily fix' of sidescrolling action on a Gamecube is to get a GameBoyPlayer to play all the GameBoyAdvance games on it, since thats where the sidescrolling games are today. It won't look much better (lower res, but more colors and effects) then SNES games ten years ago, but I for one had much more fun with MetroidFusion than with MetroidPrime.
The reason why they aren't doing any 3d games is probally because they simply sell less, or well, if marketing department thinks they sell less thats probally also enough to stop producing them. Today you can still find a new R-Type, Gradius or Contra game every few years, but thats basically all that you can find in 2d, sad truth.
Overall the hobby programming world might be worth a look for 2d stuff, there are still poping up a few good games here and there.
Windstille http://windstille.berlios.de/ for example might one day be a fun 2d jump'n run in a similar style to Metroid, but it still has a long road to go.
'Paper Mario' is a RPG game in a 3d environment with an unusal graphics style and a nice round-based fight system that still requires timing, but its by far no classic sidescroller. It however contains many mixed in elements of the 'good old days' and makes fun of the older games here an there. But one really shouldn't expect a new MarioBros game of PaperMario, but more kind of like a 'FinalFantasy in comic-look'.
### The action of executing automatically is wonderful and for many is seen as a great usability enhancement. But what happens when the.doc file can be programmed to do all kinds of problems on your computer?
Aehm, so what? When you remove the automatic loading people will click the link, press the "Open" button and then get the possibily evil.doc loaded, useability is reduced, win in security is extremly close to zero. Fixing the doc-Viewer would be the right thing todo, not making viewing docs more complicated. The thing that makes this whole issue unsecure is programmers lazyness combined with the use of insecure programming languages. Simply sandboxing the viewer and not giving it any access to any part of the system (just give it a framebuffer to render to) is technically perfectly possible, but how many of todays viewers do that? Hardly any at all.
### On the other hand the OS which doesn't execute things automatically when you visit a web site doesn't require as much maintenance.
If you don't execute automatically people will execute manually, you will still have all the same problems as before and in addition to that you will bother the user each and every day with useless click-through dialog boxes, which in itself are an extreme security risk, since people get used to just clicking anything without even reading a little bit.
### Now imagine cars without locks on their doors.
Todays computers are not like cars without locks, they are more like cars that don't drive where the user wants to and bother him with useless click-through messages, no wonder that people will click the wrong button once in a while, but its the failure of the OS that makes such issues so throublesome.
For computers to be secure they ultimativly MUST have a high grade of usability, without that people will find workarounds, passwords sticked to the monitor or whatever which will render all the theoretical security into practically a complete insecure system.
### The reason that there are few games on Linux is that there are few games on Linux.
While this is in part true, Linux has far to many other glitches that make it not so much attractive for gamers. Binary incompatible which breaks games after a few years or even months is such an issue, getting some older Loki titles to work which are just a few years old is not much fun. Graphiccard driver support is also not at best, while NVidia drivers are great, ATI drivers are still more a game of luck. Configuring X11 is also still a major pain and always was, if some graphic mode has the wrong modeline you are welcome to manually 'vi XF86Config' and games are kind of used to switch video modes a lot, so most people will sooner or later run into such a problem. XFree86 also still has a bunch of issues which make it not so attractive, such as the lack of a real fullscreen mode (ie. switch color-depth at runtime) which can cause quite a bit of slowdown for some games.
Linux might be 90% down the way to be a good gaming platform, however the last 10% are really the hard part and as long as the distros don't work more together and stuff like LSB isn't more solid I don't think Linux gaming will ever become more then the pet project of some Linux freaks.
### May I ask, what has Linux Standard Base achieved?
They have a bunch of standard documents which defines which library must export which symbols and that kind of stuff that you need for portable binaries and a bunch of software to check for complience to the standard. They also provide a development environment (lsbdev) in which one can build LSB conforming binaries on any distro. That said, its currently all more or less theoretical, so far I havn't seen lsb conforming rpms in the wild and neither do I no anybody who uses lsbdev.
### Also, to my knowledge they only apply to rpm based distros. What about Slackware and Debian?
LSB does not require that the distro use rpm for their own packages. All LSB does is to use rpm for LSB-conforming packages, but those have nothing todo with the distro packages, they have their own naming scheme (lsb-*), rely on a specific version of RPM, which might differ from the one the distro uses, get installed in/opt/, etc. So all a LSB conforming distro needs todo is to provide a way to install LSB-rpms, for Debian that would be done via 'alien'. LSB does really not specify much about how the distro itself handles stuff, all it does is require an layer ontop (an own ld.so and friends) of the distro which allows lsb-binaries to run.
### Users don't need to have a clue about the actual file format of these things; they just need to be able to double-click on one of these files in (say) a Nautilus window, causing the underlying package manager to pop up a "Root password?" dialog box, then automatically install the package.
The throuble is that that is completly impossible unless you first have a standard way to package and compile stuff. You can't just resolve missing dependencies of a Redhat RPM when you are on a Debian box, it just won't work. What you need would be a self-containing LSB-conforming RPM to make this work, however so far I have neither seen one of them in the wild nor being able to compile one myself (lsbdev is kind of a pain to get working). Linux might be getting there slowly, but today from a users point of view its not much closer to the goal then five years ago.
While in the business world playing games of course don't play a major role, its one of the major issue that keeps people from using Linux on the home desktop. It doesn't matter how good Linux gets in all other aspects, as long as there isn't a wide varity of games out there it won't make any difference on the home desktop. Guess why we have multi GHz CPUs today, its not because Excel needs all that power, its all just for the games.
The Linux install itself never was much of the problem, todays Linux are not harder to install then a Windows, in many cases even much easier since almost all drivers come with it, no need to hund down a trillion different sites to find the drivers.
Where Linux however misarably fails is in the maintainability, the day to day install of some toy app or a new 'not yet in the distris standard kernel' driver. For the average Joe User RPM, DEB, tar.gz and friends don't make any sense and never will. Under Windows and MacOSX installing is a matter of double-clicking, pretty much a no-brainer, under Linux there are dozens of ways to package and compile stuff, incompatibilties all over the place, there simply is no right way to package stuff, everybody is doing it their own style, leaving the user stuck with a whole lot of try&error. Until Linux gets to the point where I can install a 'Linux App' in a common way on every Linux out there it won't make much of a difference on the desktop.
Re:Lucasarts Adventures
on
Humor in Games?
·
· Score: 2, Insightful
The good thing of the adventure genre is that they not only have humor, they can also get quite serious with other emotions (fear, hate, love, whatever). From all the genres out there adventure games are really the only one so far that is really well suited to tell a movie-like story, all other genres kind of boil down with some action levels here, some cutscene there, but they don't give you much good feel of being really into the story.
There are of course some games like 'DeusEx' or 'Beyond Good&Evil' which manage to make a good cross between adventure game elements (dialogs, use of inventory, walking around at your home with being threatend by monsters, etc) and action elements, however its kind of sad that there are not more of such games around. The gaming world has really lost a lot after the dead of the adventure genre and only slowly the elements they provided are coming back into the games world.
Slashdot Mirror
Somehow I get a yucky-feeling with 'solutions' that are based on wrappering the underlying cruft instead of fixing it. No amount of duck-taping and gui-frontends will make the Linux dependecy and packaging hell really go away, it will just lead to more obscure harder to track down bugs in the end. What I would really prefer to see would be one standard way to package stuff (relocatable and thus not to tied to where exactly it has to be installed, etc.) and how to handle the install. With all the distros around there is however little chance that we will see that any time soon. Only hope currently is really LSB, if lsb conforming rpms get more widespread in the future they might be a small change that packages moves more and more out of the distro and into distro independend lsb-rpms, however this will, if it ever happens take many many years, so I won't hold my breath...
I have heard that before, but what exactly does that mean? I mean is Nintendo just doing a bit of a marketing trick by not calling it Gameboy or are they going to release a GameboySP2 in the next half year and basically screw up all customers who just bought a NintendoDS?
### Fullscreen mode doesn't make sense in that context - even StarOffice abandoned the idea of running in fullscreen mode a long time back
... ...
I am not talking about everything-in-one-window fullscreen, I am talking about 'game-like' fullscreen, ie. application takes controll of the whole screen. All I want to see is the image, my mouse course and maybe the palette, no menu, toolbox or other clutter. Gimp already has such a mode (press F11), but its quite a bit limited in that it doesn't let one move the drawable area around, causing all shorts of throuble when working with larger images.
### Macro recording of mouse and menu movement is not an easy thing to do
I don't mean that kind of low-level macro recording which will screw up quite quickly and isn't much usefull since you can't add parameters to it easily. I mean high level macro recording on the function level, in CorelPhotopaint (anno 1996) I could press the 'Record' button and then see function names + arguments poping up in the record:
PaintStart 10,10
PaintContinue 34,34
BlurPlugin 10,40
NewDocument
I could then import that as script, modify where needed and where ready to go in a matter of a minute or two.
For tradinonal Windows3.11 WiW maybe, but thats really not what anybody wants. A simple managing window with a few places to dock stuff into would already be enough to fix most problems and thats really nothing that would require much rewrite, wouldn't even require to change Gtk. Galeon for example already has tabbed-windowing and toolbars that I can rip apart and away from the main-window if needed and things like that in Gimp could make quite a huge improvement.
Well, actually both XFree86 and the Linux kernel have exactly the same problem when it comes to binary drivers, neither of them really handles them all that good. That said, no XFree86 didn't take 90% of the time, since I could interrupt the compile once it compiled the module, quite hacky, but it was actually the recomment way to compile the module. Most of the time was actually wasted to find out that I would have to go all this recompile throuble in the first place. With proper binary drivers in case of problems I could just go download and try the newest version in basically no time, I kind of end up searching for other solutions first, since its hard to know before hand what exactly is causing the throuble (driver, configuration, other issue).
Thats basically what I did, still takes at least half a day to pump both a highly modularized kernel and an XFree through the compiler.
### You feel pain after six years but suggest that those who like the current interface could switch in a month?!
The GUI should be configurable enough to just rip it into pieces and go back to the 'all floating around' style of things. I am NOT saying that forcing everybody into a WiW is a good thing, just saying that playing hide&seek with my dialogboxes really can't be the right way to design a userinterface.
### So an interface like that of Blender? Won't work good with GTK.
Well, then lets go and fix Gtk, just because Gtk can't do it isn't much a good excuse for not even trying it at all. After all Gtk still stands for 'GIMP Toolkit' so I guess implementing a bit of functionality that is needed by Gimp into it shouldn't be all that difficult.
### And just look how many people are complaining about the interface of Blender!
They are complaining because the Blender GUI has some major problems, but at least the Blender developers admit it and seem to improve the situation slowly, but constantly. Every new Blender release so far was full of a wealth of good new features, new Gimp releases, which happen quite less frequently haven't provided anything substantly for quite some time.
### But as long as we deal with traditional GUI paradigms GIMP isn't halfway bad.
Gimp already is pretty far away from tradinional GUI.
### The developers aren't interested in fixed "problems" that don't really exist
Well, if these problems don't exist them I am sure we want have long endless discussions about the next time when Gimp is in the news, after all we didn't have these discussions the last five years... oh wait, maybe we did.
### Just because YOU think it's unusable, doesn't mean everybody does!
This issue pops up absolutly EVERY TIME gimp is mentioned somewhere, this really is not a 'just me' issue, its a issue for A LOT of people.
### Why don't you complain about Photoshop on Mac too?
Because I never used them, I use Gimp exclusivly for the last ~6 years and STILL have some major issues with the GUI, not because 'its me' but because the interface just has some major problems.
### Why don't you use nautilus or any other fileviewer then?
I do most of the time, however having thumbnail for all files in the open/save dialog would still be extremly usefull. This functionallity might be good to have in the Gtk+ filedialog itself, however it wouldn't have been rocket-sience to implement it in Gimp already years ago.
### It is possible for a long time already by means of "Script-Fu->Selection->To Brush".
I know, it however fills the brush dialog with junk which I then have to manually select and delete. What I mean is functionality like provided by DeluxPaint, select a region, select paintbrush and instantly you are able to use that selected region as brush, extremly usefull sometimes and its a better of seconds to use and discard a brush, Gimps current brush handling is far more tricky to use.
### Now do you seriously expect to get friendly response when you address volunteers in such a way? You get back what you throw at people.
Guess why I have written that subject line, its not that I was being hostile against Gimp back then when I started using it, it mainly where the mailing list, IRC discussions and the lack of progress that made me feel that way.
### Overall, please either by from open source friendly hardware vendors, or pay the price for a proprietary operating system.
The problem is that even IF you by from a OSS friendly hardware vendor its still a PITA to get a driver running if it happens to be developed outside the Linux kernel. Little example, my graphics tablet is perfectly supported under Linux, by both the kernel and XFree86, however the driver that came with both the kernel and XFree86 had a bug, so I had to download and recompile around 70MB of source code just to get a few Kilobytes of binary driver that would run fine with by version of the kernel and xfree86. It did cost me almost two days to figure out and get it up&running completly, this really shouldn't be acceptable these days and is completly unnecessary.
### They may not be enough for you, but those of us who like and are used to the interface it's the best way: we get improvements, but don't have to relearn.
I doubt it. I feel the pain in using the Gimp interface every time I use the Gimp, and thats after almost 6 years of regular Gimp usage. Relearning a new interface would take how long? A day to get confortable with it? Maybe a week to master it? Maybe a month to completly know it in an out? The time that is taking to relearn should be easily be made up for in very few days, after all it wouldn't be completly different or completly new, it would just mean sticking all those floating dialog boxes together in a grid, keep them in place, keep them where they are usefull (aka. not hide them behind your image window and such..) and maybe add a few more buttons say for undo/redo, for rotating, flipping stuff, rect or circle drawing, etc. Overall nothing that would take any time at all to relearn, just functionality in a better accessible place. After all some more radical change in the GUI should make the UI more accessible for everybody, keeping it as it is ensures that it is inaccessible for almost everybody.
### Do it, or find someone to do it for you; the developers aren't interested.
Yes, I know, and thats one of the things that is slowing Gimp down alot. If the developers aren't interested at all in improvements, its not really all that motivating for writing patching. As it stands now any kind of WiW patch would have quite a hard time getting accepted by the Gimp developres.
* ugly user interface, no matter of WiW is the way to go or not, currently I have to dig around for my palette or brush dialogs far to many times they really MUST be dockable to the image window to make Gimp painless to use. People saying that the current way is 'right' are just bloody ignorant, this issue is really poping up every time gimp is mentioned somewhere, yet still the developers failed to address it properly in the last 5 years
* lack of a proper fullscreen mode, while its there is quite limited in they way that one can scroll, dialog boxes cover the drawing area so that one constantly has to move stuff around, again proper docking to the image borders might help a lot
* lack of advanced brushes, currently all of gimps brushes are quite primitive, just the bare basics and there is no way to write new-ones as plug-ins, making it hard to actually create new ones. That said it was been tried to implement new cool stuff, but it never made its way into the Gimp:
http://www.levien.com/gimp/wetdream.html
* lack of macro recorder, my 1996 version of Corel Photopaint had already a kick-ass macro recorder, making it a joy to create scripts, you just recorde a macro, do what you want, go into the script editor add a few parameters to it, add a GUI dialog and you have a nice script in basically no time, Gimp today is still stuck with only Script-Fu and friends which are both a pain to write and debug, no macrorecorder there at all
* lack of power in the scripting, plug-ins and PDB interface lacks functions, there are a bunch of functions that are available in the GUI, but not available in the scripting, so that one has to manually build-them, making scripting even more a pain than it already is. The GUI should ideally be just a 'container' that connects scripts with each other, everything in the GUI should be available in the scripting and each part of Gimp should be modifiable via scripting/plug-ins, brushes, gui, whatever.
* tablet support, while its there it is not really that good, double-clicking is almost impossible on the Gtk components, with a tablet the clicks end up at different positions, Gtk+ seems to lack the tolerance to still register it as doubleclick, might be a Gimp, Gtk+, Xfree86 issue or whatever, however its causing quite huge throuble in Gimp (if there is some fix/hack/patch for it I would like to know)
* load/save dialog, these are really just the standard Gtk+ ones with a single thumbnail, however for a graphic application it would be quite usefull to have full thumbnail view of all images, like you get in Nautilus or any fileviewer
* very bad suport indexed images, one doesn't need them all that often these days, but still sometimes one need them and then Gimp is just a pain in the ass, a decade old version of DeluxPaint was way better at handling them
* no quick&easy way to create brushes, ie. I would like to use a layer click a 'to-brush' button and then paint with it, however thats more or less impossible todo today, I have to save the image as brush, tweak some parameters, then select it from the brush dialog, etc. cost by far to much time for an operation that should really be 'single-click', beside from that brush handling itself is quite a arkward, some brushes are resizable, some others not, while idealy all should be modifiable and it even shouldn't be that difficult to implement
* developers seem to be quite hostile against any suggestions from the outside, both on IRC and on the mailing list, other people seem to have made similar experiences so its not just me, other OSS projects seem to be quite a bit more friendly to their users
There are probally a lot of more issues I have forgotten, but well, that should be the more important ones. Last not least, yeah I know, many people will now say that its OSS so I have no f*** right to critic it and if I would like the features I should implement them myself and beside Gimp is of course doing everything right and I am the one that is just using it wrong (wondering how that can happen after 6 years of gimp usage...), but well, go start flame me now...
### Yes interface matters, don't break it, for those who grok it. Improvements like from 1.2 to 2.0 are the way to go.
Those micromal improvements are NOT the way to go, that way it will take a hundred years before it starts becoming a really useable application. How about making the GUI configurable? Its not that the floating-windows stuff needs to go completle, just have a checkbox in the Preferences to switch from WiW to floating-windows and some Tip-Of-Day to inform users about it. It really should not be all that difficult, especially with docking already in place, just provide a larger managing window where the docks get a fixed place and make the image windows dockable and tabable too. This issue has really been there since day 1 and it really hasn't been getting much better at all in the last five years.
### If you need it right now you'll need to look elsewhere. There are many, many applications for a raster editor where colour management does not matter.
Sadly not so much on GNU/Linux, but yeah Windows and Mac users have plenty of alternatives.
The only problem is that you can not dock the image window, which is really the one that would be most 'dock-worthy' in the end. Docking is overall a nice add-on, but it only reduces the clutter a little bit. Still by far to many windows floating around, when it comes to brushes or palette I want to have them docked where I need them, to the window, not hidden behind half a dozens other dialogs.
Beside from that the 'floating window' issue makes some of the image-menu entries rather weird, like having a 'Quit' button per-Image, but it acts for the whole App and such.
Speaking about fuzzy pixels, try to run a LCD at a non-native resolution, which is quite common required for gaming, and even the damn cheapest CRT will look like a beatifull masterpiece in comparism to the blurred scaled up image a LCD will give.
That said, yes, LCDs might be better for some uses, but they have so many disadvantages that I still wouldn't exchange them against my good old CRT.
Not really perfect and still in its very early days, but already quite a bit usefull for finding some free art is the Game Media Repository, available at:
http://undone.clanlib.org/~grumbel/show.cgi
Quality of the stuff in their varies a lot, so success of your searches may variy, still might be worth a try, especially for game related stuff like sprites and 3d models.
The easiest way to get today the 'daily fix' of sidescrolling action on a Gamecube is to get a GameBoyPlayer to play all the GameBoyAdvance games on it, since thats where the sidescrolling games are today. It won't look much better (lower res, but more colors and effects) then SNES games ten years ago, but I for one had much more fun with MetroidFusion than with MetroidPrime.
The reason why they aren't doing any 3d games is probally because they simply sell less, or well, if marketing department thinks they sell less thats probally also enough to stop producing them. Today you can still find a new R-Type, Gradius or Contra game every few years, but thats basically all that you can find in 2d, sad truth.
Overall the hobby programming world might be worth a look for 2d stuff, there are still poping up a few good games here and there.
Windstille http://windstille.berlios.de/ for example might one day be a fun 2d jump'n run in a similar style to Metroid, but it still has a long road to go.
'Paper Mario' is a RPG game in a 3d environment with an unusal graphics style and a nice round-based fight system that still requires timing, but its by far no classic sidescroller. It however contains many mixed in elements of the 'good old days' and makes fun of the older games here an there. But one really shouldn't expect a new MarioBros game of PaperMario, but more kind of like a 'FinalFantasy in comic-look'.
### The action of executing automatically is wonderful and for many is seen as a great usability enhancement. But what happens when the .doc file can be programmed to do all kinds of problems on your computer?
.doc loaded, useability is reduced, win in security is extremly close to zero. Fixing the doc-Viewer would be the right thing todo, not making viewing docs more complicated. The thing that makes this whole issue unsecure is programmers lazyness combined with the use of insecure programming languages. Simply sandboxing the viewer and not giving it any access to any part of the system (just give it a framebuffer to render to) is technically perfectly possible, but how many of todays viewers do that? Hardly any at all.
Aehm, so what? When you remove the automatic loading people will click the link, press the "Open" button and then get the possibily evil
### On the other hand the OS which doesn't execute things automatically when you visit a web site doesn't require as much maintenance.
If you don't execute automatically people will execute manually, you will still have all the same problems as before and in addition to that you will bother the user each and every day with useless click-through dialog boxes, which in itself are an extreme security risk, since people get used to just clicking anything without even reading a little bit.
### Now imagine cars without locks on their doors.
Todays computers are not like cars without locks, they are more like cars that don't drive where the user wants to and bother him with useless click-through messages, no wonder that people will click the wrong button once in a while, but its the failure of the OS that makes such issues so throublesome.
For computers to be secure they ultimativly MUST have a high grade of usability, without that people will find workarounds, passwords sticked to the monitor or whatever which will render all the theoretical security into practically a complete insecure system.
### The reason that there are few games on Linux is that there are few games on Linux.
While this is in part true, Linux has far to many other glitches that make it not so much attractive for gamers. Binary incompatible which breaks games after a few years or even months is such an issue, getting some older Loki titles to work which are just a few years old is not much fun. Graphiccard driver support is also not at best, while NVidia drivers are great, ATI drivers are still more a game of luck. Configuring X11 is also still a major pain and always was, if some graphic mode has the wrong modeline you are welcome to manually 'vi XF86Config' and games are kind of used to switch video modes a lot, so most people will sooner or later run into such a problem. XFree86 also still has a bunch of issues which make it not so attractive, such as the lack of a real fullscreen mode (ie. switch color-depth at runtime) which can cause quite a bit of slowdown for some games.
Linux might be 90% down the way to be a good gaming platform, however the last 10% are really the hard part and as long as the distros don't work more together and stuff like LSB isn't more solid I don't think Linux gaming will ever become more then the pet project of some Linux freaks.
### May I ask, what has Linux Standard Base achieved?
/opt/, etc. So all a LSB conforming distro needs todo is to provide a way to install LSB-rpms, for Debian that would be done via 'alien'. LSB does really not specify much about how the distro itself handles stuff, all it does is require an layer ontop (an own ld.so and friends) of the distro which allows lsb-binaries to run.
They have a bunch of standard documents which defines which library must export which symbols and that kind of stuff that you need for portable binaries and a bunch of software to check for complience to the standard. They also provide a development environment (lsbdev) in which one can build LSB conforming binaries on any distro. That said, its currently all more or less theoretical, so far I havn't seen lsb conforming rpms in the wild and neither do I no anybody who uses lsbdev.
### Also, to my knowledge they only apply to rpm based distros. What about Slackware and Debian?
LSB does not require that the distro use rpm for their own packages. All LSB does is to use rpm for LSB-conforming packages, but those have nothing todo with the distro packages, they have their own naming scheme (lsb-*), rely on a specific version of RPM, which might differ from the one the distro uses, get installed in
### Users don't need to have a clue about the actual file format of these things; they just need to be able to double-click on one of these files in (say) a Nautilus window, causing the underlying package manager to pop up a "Root password?" dialog box, then automatically install the package.
The throuble is that that is completly impossible unless you first have a standard way to package and compile stuff. You can't just resolve missing dependencies of a Redhat RPM when you are on a Debian box, it just won't work. What you need would be a self-containing LSB-conforming RPM to make this work, however so far I have neither seen one of them in the wild nor being able to compile one myself (lsbdev is kind of a pain to get working). Linux might be getting there slowly, but today from a users point of view its not much closer to the goal then five years ago.
While in the business world playing games of course don't play a major role, its one of the major issue that keeps people from using Linux on the home desktop. It doesn't matter how good Linux gets in all other aspects, as long as there isn't a wide varity of games out there it won't make any difference on the home desktop. Guess why we have multi GHz CPUs today, its not because Excel needs all that power, its all just for the games.
The Linux install itself never was much of the problem, todays Linux are not harder to install then a Windows, in many cases even much easier since almost all drivers come with it, no need to hund down a trillion different sites to find the drivers.
Where Linux however misarably fails is in the maintainability, the day to day install of some toy app or a new 'not yet in the distris standard kernel' driver. For the average Joe User RPM, DEB, tar.gz and friends don't make any sense and never will. Under Windows and MacOSX installing is a matter of double-clicking, pretty much a no-brainer, under Linux there are dozens of ways to package and compile stuff, incompatibilties all over the place, there simply is no right way to package stuff, everybody is doing it their own style, leaving the user stuck with a whole lot of try&error. Until Linux gets to the point where I can install a 'Linux App' in a common way on every Linux out there it won't make much of a difference on the desktop.
The good thing of the adventure genre is that they not only have humor, they can also get quite serious with other emotions (fear, hate, love, whatever). From all the genres out there adventure games are really the only one so far that is really well suited to tell a movie-like story, all other genres kind of boil down with some action levels here, some cutscene there, but they don't give you much good feel of being really into the story.
There are of course some games like 'DeusEx' or 'Beyond Good&Evil' which manage to make a good cross between adventure game elements (dialogs, use of inventory, walking around at your home with being threatend by monsters, etc) and action elements, however its kind of sad that there are not more of such games around. The gaming world has really lost a lot after the dead of the adventure genre and only slowly the elements they provided are coming back into the games world.