Re:Richard Feynman is cool...
on
Flywheel UPS
·
· Score: 1
Wouldn't the Bellhop notice that the suitcases are slightly trembling, as soon as he picks them up (a little bit like the feel of a holding a spinning HD in your hands)? And what about that whirring sound?
Not if you have good bearings. I don't have any suitcases with flywheels in them myself, so I don't really know, but I imagine that vibrations and noise could be minimized, or at least kept at a low enough level that a busy bellhop wouldn't notice immediately in a noisy hotel lobby. It doesn't have to fool him forever. Besides, it doesn't have to spin at 3200 RPM like hard drives do. If its mass or radius is large enough it doesn't have to spin that fast at all.
As for spinning up the wheels, it's easy. Just drive your car up to the curb, spin up the suitcases inside the car, and then get out and walk straight in. You could probably even do it in plain sight, I doubt there would be any bellhops standing around staring at you through the hotel lobby doors. It doesn't matter if other people see.
Richard Feynman is cool...
on
Flywheel UPS
·
· Score: 2
Heh, this reminds me of a practical joke Richard Feynman did using flywheels...
Ingredients:
2 large suitcases
2 large flywheels
A nice hotel
Fasten the flywheels inside of the suitcases, one in each. Point them in the direction of the hotel and spin them up, then close them (looks like two innocent suitcases). Take both suitcases and walk in to the hotel (in a straight line). Get a bellhop to take your luggage. Watch as the bellhop rounds a corner and the suitcases jump out of his hands! He'll probably think your suitcases have been posessed by the devil:-)
When is a game considered "nerd enough" to be posted on/.??
When CmdrTaco likes it.
If you don't like that, you can go somewhere else. Slashdot is his news site (well sort of) and he can report what he wants. I think one of the things that makes Slashdot interesting is the strange variety of stuff that gets reported due to the fact that its run by a couple of guys posting stories about what they like most.
Native Widget look/feel? Yeah, we got that.
on
Qt for Mac
·
· Score: 2
Did you even look at the screenshots? QT/Mac is quite capable of looking and feeling exactly like any other Mac app.
"Just another in a long series of cases that prove that if you have a trademark, you have the right to any domain name that contains those letters in that order."
You know, you guys don't have any right to complain about the spreading of FUD when you do it so often yourselves. AOL wouldn't have any right to the domain www.aimtokill.com as long as nobody was offering instant-messenger stuff there. You know that.
I agree that this is stupid, as long as Aimster has notices in reasonably conspicuous places to the effect that they are not affiliated with AOL, they should get to keep the domains. The name Aimster is not meant to confuse people into thinking its an officially AOL-endorsed product but its a clever (well, maybe not that clever) play on words that both lets people know its a file-sharing service and that it works with AIM.
However, just because this case is stupid doesn't give you the right to spread FUD, so keep quiet!
Huh? Quake 3 runs just fine on my Savage4, thank you very much! Maybe I can't play at 1024*768, or I can't have the super-mega-huge textures, but it has a high framerate, and it is still fun! What are you talking about?
Probably Tribes 2 would be too much for my card, but games released prior to Tribes 2 (which are far more numerous, for now) seem to work just fine.
Also, Myth 2 is a 3D game and probably requires an accelerator card (or at least won't run very fast otherwise). I wasn't talking about SimCity or the like, I know those will run just fine. I'm talking about 3D accelerated games, which seem to be in the majority these days. Linux needs more 3D card support to really be a gaming platform.
I am just tired of all those guys who say "well, I have a GeForce 2 GTS turbo super ultra mega alpha 1337 with 37 GB of RDRAM overclocked to 500 MHz, and I think Linux has great 3D support!" Just because you're lucky enough to have a supported card doesn't mean that Linux 3D support is great.
You mean that Linux games run well on the fastest, most expensive hardware available?
Wow, that really is amazing!
Seriously, though, what about those of us who have S3 Savage4 based 3D cards or any one of the trillions of other 3D cards that aren't supported under Linux? What about those of us who have slow 3D cards that just barely run the latest games on Windows? THAT's the kind of hardware Linux games need to run well on to be successful in the mainstream.
You will find that Moore's Law holds even before silicon. Therefore, it is reasonable to assume that Moore's Law will hold even after we have reached the limits of silicon technology
Sorry. Didn't you read the fine print?
"Past performance is not a guarantee of future results."
I would make a joke here having to do with patenting stupid comments about patenting patents, but even that joke has been made so many times that its not funny anymore.
Maybe I should make a comment about patenting comments relating to patenting stupid comments about patenting patents.
No, I know, I'll make a comment about copyrighting comments about patenting stupid comments about patenting patents! Then I'll trademark making comments having to do with copyrighting comments relating to patenting stupid comments about patenting patents!
KDE is fully capable of Anti-Aliasing. In fact, I'm posting this from Anti-aliased Konqueror right now. GNOME is not expected to be able to use AA until the next major version number change.
To use AA you need XFree 4.X, QT 2.3.X, and a reasonably recent version of KDE. You also need a supported video card (I think almost all are supported now) and XFree needs to be configured a certain way (Render extension and the Freetype libraries need to be built). Some distros include all the things you need for AA in their packages, like Debian woody. Other distros sometimes require you to compile X yourself in order to get the Render extension and Freetype.
For info on the IceWM plugin, as well as some other KWin themes and a KControl module to configure them (configurable button placement! Nice!), go here.
I have also noticed that the GTK theme importer doesn't work perfectly. Some GTK themes will cause QT to choke, requiring you to go and delete some config files just to start KDE again! However, if fonts are your only problem, couldn't that be solved with a quick trip to the Fonts control panel? The GTK themes might use odd-sized fonts, and we all know how well X fonts scale (not well at all). If you select sane font sizes, or even different fonts, they should be quite readable. Or, enable font anti-aliasing as I have done and kiss your jagged fonts goodbye!
FYI, GTK themes can be imported by KDE. Check out the "Legacy theme importer." Despite the unfortunate name (no its not an insult, its the result of coders who don't speak English as a first language) it does in fact import GTK themes.
About KWM themes - Acually they're KWin themes now. KWin has a great new modular architecture that allows all sorts of incredible C++ plugins. Unfortunately, that means that it is required to code in C++ to make a new theme! This is the reason there are no good KWin themes yet (programmers usually aren't good artists and vice versa).
That is about to change, though. Just recently, a KWin plugin was released that imports IceWM themes and uses them as-is. This is the strength of a plugin architecture. Now you can use any IceWM theme you want. Its in CVS now, you can download it youself or wait until KDE 2.2. In the future, also expect to see many more style plugins for KWin (KDE 2.2 will include several new ones). Eventually someone may make a generic themeable plugin that will allow themeing of KWin without C++ coding. Either that or everyone will simply make IceWM themes for KDE!
I see no reason why a particular tooklit or API should be more accessible to one language or another.
In an ideal world, it would be like this. However, becuase this isn't an ideal world, a toolkit will almost always be more accessible in its native language (the one it was programmed in). You are, of course, free to chip in and change that with a new cross-language toolkit - I suggest you do it yourself if that's what you really want done. If you build it, they will come! That's what's great about Open Source and Free Software.
Consistent look and feel =! theming! Please understand this! Its dialog boxes, widget behavior, panel application behaviour, drag and drop behaviour (xdnd still isn't used properly by either Konq or the GNOME desktop - try it with Konq FTP sometime).
Ah, we're getting more OT. I thought you weren't talking about KDE/GNOME, only QT/GTK! Dialog boxes are provided mostly by the desktop environment. Panels and panel applications are provided completely by the environment, not the toolkit at all. (BTW, the KDE 2 panel supports WindowMaker dock applets - I think it can use GNOME panel applets as well). Widget behavior *is* part of themeing, with QT its possible to change the operation of a widget just with themes! Drag and drop interoperability is also provided by the desktop, and its improving - I suspect within the year it'll be working perfectly. The duplicate Control Centers and such are not a problem - just don't use the other one! And don't think nobody cares! That just shows that you don't read the KDE or GNOME mailing lists. Desktop Integration has been a big topic recently - there are joint mailing lists, community standards, and other stuff. The results are starting to show: the QT-GTK widget, XParts, more standardized DND (it used to be much worse), the gphoto KDE IOSlave. Its getting better all the time!
Good point, but they're both unfortunately very rarely used.
That's because they were just invented 2-3 months ago! Give them time, they will be used now that they are available.
My understanding of the current QT licensing situation were that someone could port the Linux version of QT to Win32 to create a GPLed Win32 QT. Anyone care to correct me?
Oh, sure. You'll *just* PORT it! Gee, why didn't I think of that?
Seriously, though, if you think it's needed, start the project yourself. If it's really needed, others will help you. I think you'll have to get a lot of people to keep up with those guys at TrollTech, though. They aren't going to be standing still while you port QT/Linux to Windows.
Um, yes. That's what I'm talking about.
No its not. At least it wasn't. You seem to have switched gears now from "lets merge GTK and QT and keep compatibility" to "Lets create a whole new toolkit." Its a totally different argument now. Before you seemed to want to create a super-library that would be both backward and forward binary- and source-compatible with apps written in both C and C++ using different graphics toolkits! Now you want to start a new library that's better than all the rest. In that case, more power to you. Just don't expect source or binary compatibility with GTK and QT, and don't expect others to do it for you once they hear your great idea. If you want something done, do it yourself! Others may join you later, but they won't start it for you.
Yes, GTK has C++ bindings. However, it is programmed in C itself. It's interface is through C libraries. The most natural (and most resource-efficient) way of programming in GTK is in C. You do not seem to understand the difference between a language binding and native support of a language. They're NOT the same thing.
if you're speaking about KDE / GNOME (semi OT), no
No, I'm not speaking about KDE vs. GNOME. KDE simply enables QT to import the themes - it would be quite possible for QT to do it without KDE (only with the help of the small converter program). QT can be made to look and feel *exactly* like GNOME, totally erasing the "look and feel" issue. The "common dialogs" issue is OT, as it refers to KDE and GNOME themselves.
Because Win32 is not Open Source, controled by MS and is broken according to some.
Win32 isn't open source, but WINE is, and WINE is an implementation of Win32. By your logic, we should try to merge all graphics toolkits into one big, happy API family. Why stop at QT and GTK? Why not try to make a giant über-library that can run any program for any graphics toolkit ever made? It's impractical and unnecessary! QT and GTK do the job just fine the way they are, thank you very much! I see no concievable benefit in merging them. Less memory usage? Maybe a megabyte. But certainly no more than that.
Actually, I was thinking of having Qt compile GTK apps, as it seems to be the more well developed and cross platform of the two.
That still doesn't help the portability problem. QT Windows and QT [something that's not linux] is NOT GPL and NOT FREE(as in beer). You'd have to pay QT licensing fees to develop GTK Windows applications! What kind of sense does that make?
a single object model would still be cleaner
A single object model would require either:
Changing the existing object models
or
Adopting one object model over the other.
Changing the existing object models would simply be creating a whole NEW object model. Just what we need. There's no guarantee that the new one will be better than either of the old ones (it'd probably be worse due to compromises). Adopting one object model over the other will simply not happen, because it would change the API and therefore require lots of people to totally rewrite their programs. If you think people are going to go for that, you're crazy.
This whole "make QT compatible with GTK" thing would just be a lot of work for questionable benefit. What do we get? Consistent look and feel? Already got it (theme importer). Interoperability? Already got it (QT-GTK widget and XParts). Lower memory usage? Not much at all (if you want to support programs written for both toolkits). A better programming environment? If that's what you're after, why not start a whole new toolkit? It would make more sense. You seem to want to both merge QT and GTK's APIs AND keep compatibility (how come QT can't compile my GTK apps?) I'm sorry, that's simply not possible. Changing APIs requires total program rewrites. Might as well start a whole new toolkit, QTK or something.
Sorry, your idea is neither practical nor worthwhile, because:
QT and GTK use different langages (C vs. C++ - yes that's too much of a difference to compensate for in any reasonable way).
If this came about, what would be the point of having 2 toolkits anyway? Why don't we all just switch to Win32 programming and use WINE? One toolkit is better than 2, right?
KDE can import your GTK+ and IceWM themes, making "lack of constant appearance" a matter of user choice.
What lack of consistency in UIs? Buttons, scrollbars, checkboxes, radio buttons, dockable toolbars - these concepts are almost identical in both toolkits. The only difference is in their appearence (KDE puts two buttons at the bottom of a scrollbar, but only in some themes, etc - this would be solved by QT importing GTK themes).
Making GTK compile QT apps (even though it's really impossible) would not help the stability, speed, or functionality of the Windows port of GTK, so it wouldn't help get a quality free toolkit for Windows any more than simply working more on GTK for Win32 directly.
Finally, the "limited widget availability between both toolkits" problem is about to go away. With QT-GTK and GTK-QT widgets almost ready and XParts in the works, programs for either toolkit can use widgets or components (think KParts/Bonobo) from both.
Please bear in mind this is a completely different concept to merging KDE and GNOME, which have less to do with Qt and GTK than many people think.
What? It has everything to do with QT and GTK! GNOME was started for the express purpose of providing a desktop environment based on something other than QT. If KDE and GNOME used the same toolkit, merging them would almost be a trivial task. Their choice of toolkits is the only thing really keeping them apart.
Well, my iPAQ requires syncing because I like to have my e-mail and websites downloaded to it every morning but I don't have the PC card sleeve so I can't use the Internet directly. If I had some form of Internet access for it, I probably wouldn't sync it nearly as much. Of course, there are other benefits to syncing, such as having your data automatically backed up (you can never be too careful). I guess syncing isn't really "required," especially if you have a modem or ethernet card. If you really had something against syncing, though, you could just use the AC adapter to power up at any old outlet once a day or so.
Also, I seriously doubt that the Newton's handwriting recognition is any better than Microsoft's Transcriber (an amazing piece of software). However, a keyboard is still faster than handwriting, even on actual paper, and especially for coding (writing characters like *, &, {, and } is not fun)
How often do you have to change the batteries in one of these iPaqs?
Try "never." It has an internal Li-polymer (or some such) battery that is about 2mm thick (!). It recharges as long as its on the docking cradle. Its not really a problem, since for the iPAQ to be really useful, its best to sync it at least once a day, and the battery recharges pretty fast while you sync.
what do you think they[PC cards]'re going to do to a handheld on AAAs?
Who knows? Although you can never have too much battery power, I think they iPAQ's battery does pretty well even with PC cards. Of course it does depend on what card you're using as well. Also, there are battery extenders available that can simply plug in to the bottom of the iPAQ, doubling the battery life.
But 64 is ridiculous.
I don't think so. I'd love 64 MB. That way, my iPAQ could have a reasonable music collection on it and it could be my MP3 player as well as a PDA. Plus, when you start putting Linux on it, and get one of these,
the iPAQ becomes a serious competitor to a full-fledged laptop. Why lug around a 2 lb brick when you can carry around your iPAQ with wireless (or wired) Internet access, a full-sized keyboard, and the processor power and memory to make good use of both?
I have had no problems with my iPAQ. There have of course been stories about dust under the screen, styluses getting stuck, etc. However, all seem to agree that Compaq has acted admirably in fixing these problems. For example, everyone who has had dust under the screen has simply been able to send the iPAQ in to Compaq and they repair it and send it right back.
There is only one issue I have with my iPAQ: the fact that it can only detect one button press at a time. That is really the only complaint I have (it's making it harder for me to finally beat Super Mario Bros. 3;-) If it was really a problem, though, I'd just go get one of these. In fact, I may get one anyway, just because they're SO DARN COOL!
I am very impressed with Compaq's willingness to help out with porting Linux to the iPAQ. The handhelds.org site is hosted by them and they provide technical specs for the iPAQ to porters.
Overall, I'm extremely happy with my iPAQ. It's a great product, don't deprive yourself because of some silly vendetta.
P.S. The best way to get an iPAQ is to simply go down to your local Best Buy (they probably already have a sample unit for you to play with) or other tech store and get on a waiting list. Compaq is doling out iPAQs in small increments to retail chains as they become available. Don't fiddle around with online retailers or whatever. I got my iPAQ in Febuary from my local Best Buy, after waiting a little more than a month.
Not if you have good bearings. I don't have any suitcases with flywheels in them myself, so I don't really know, but I imagine that vibrations and noise could be minimized, or at least kept at a low enough level that a busy bellhop wouldn't notice immediately in a noisy hotel lobby. It doesn't have to fool him forever. Besides, it doesn't have to spin at 3200 RPM like hard drives do. If its mass or radius is large enough it doesn't have to spin that fast at all.
As for spinning up the wheels, it's easy. Just drive your car up to the curb, spin up the suitcases inside the car, and then get out and walk straight in. You could probably even do it in plain sight, I doubt there would be any bellhops standing around staring at you through the hotel lobby doors. It doesn't matter if other people see.
Ingredients:
2 large suitcases
2 large flywheels
A nice hotel
Fasten the flywheels inside of the suitcases, one in each. Point them in the direction of the hotel and spin them up, then close them (looks like two innocent suitcases). Take both suitcases and walk in to the hotel (in a straight line). Get a bellhop to take your luggage. Watch as the bellhop rounds a corner and the suitcases jump out of his hands! He'll probably think your suitcases have been posessed by the devil :-)
When CmdrTaco likes it.
If you don't like that, you can go somewhere else. Slashdot is his news site (well sort of) and he can report what he wants. I think one of the things that makes Slashdot interesting is the strange variety of stuff that gets reported due to the fact that its run by a couple of guys posting stories about what they like most.
Did you even look at the screenshots? QT/Mac is quite capable of looking and feeling exactly like any other Mac app.
You know, you guys don't have any right to complain about the spreading of FUD when you do it so often yourselves. AOL wouldn't have any right to the domain www.aimtokill.com as long as nobody was offering instant-messenger stuff there. You know that.
I agree that this is stupid, as long as Aimster has notices in reasonably conspicuous places to the effect that they are not affiliated with AOL, they should get to keep the domains. The name Aimster is not meant to confuse people into thinking its an officially AOL-endorsed product but its a clever (well, maybe not that clever) play on words that both lets people know its a file-sharing service and that it works with AIM.
However, just because this case is stupid doesn't give you the right to spread FUD, so keep quiet!
The BSD license is hardly proprietary. People are getting all worked up over nothing!
OK guys, go slashdot that server of his running AtheOS! Help him stress-test it :-)
Probably Tribes 2 would be too much for my card, but games released prior to Tribes 2 (which are far more numerous, for now) seem to work just fine.
Also, Myth 2 is a 3D game and probably requires an accelerator card (or at least won't run very fast otherwise). I wasn't talking about SimCity or the like, I know those will run just fine. I'm talking about 3D accelerated games, which seem to be in the majority these days. Linux needs more 3D card support to really be a gaming platform.
I am just tired of all those guys who say "well, I have a GeForce 2 GTS turbo super ultra mega alpha 1337 with 37 GB of RDRAM overclocked to 500 MHz, and I think Linux has great 3D support!" Just because you're lucky enough to have a supported card doesn't mean that Linux 3D support is great.
You mean that Linux games run well on the fastest, most expensive hardware available?
Wow, that really is amazing!
Seriously, though, what about those of us who have S3 Savage4 based 3D cards or any one of the trillions of other 3D cards that aren't supported under Linux? What about those of us who have slow 3D cards that just barely run the latest games on Windows? THAT's the kind of hardware Linux games need to run well on to be successful in the mainstream.
If that's a threat, we truly have a global information economy. Think how silly that would have sounded ten years ago.
Sorry. Didn't you read the fine print?
"Past performance is not a guarantee of future results."
Maybe I should make a comment about patenting comments relating to patenting stupid comments about patenting patents.
No, I know, I'll make a comment about copyrighting comments about patenting stupid comments about patenting patents! Then I'll trademark making comments having to do with copyrighting comments relating to patenting stupid comments about patenting patents!
Awww, fsck it.
Stiffle?
monolythic?
>Mach has done more to stiffle microkernels than any theory or performance debate has ever.
Tsk tsk...
To use AA you need XFree 4.X, QT 2.3.X, and a reasonably recent version of KDE. You also need a supported video card (I think almost all are supported now) and XFree needs to be configured a certain way (Render extension and the Freetype libraries need to be built). Some distros include all the things you need for AA in their packages, like Debian woody. Other distros sometimes require you to compile X yourself in order to get the Render extension and Freetype.
I have also noticed that the GTK theme importer doesn't work perfectly. Some GTK themes will cause QT to choke, requiring you to go and delete some config files just to start KDE again! However, if fonts are your only problem, couldn't that be solved with a quick trip to the Fonts control panel? The GTK themes might use odd-sized fonts, and we all know how well X fonts scale (not well at all). If you select sane font sizes, or even different fonts, they should be quite readable. Or, enable font anti-aliasing as I have done and kiss your jagged fonts goodbye!
About KWM themes - Acually they're KWin themes now. KWin has a great new modular architecture that allows all sorts of incredible C++ plugins. Unfortunately, that means that it is required to code in C++ to make a new theme! This is the reason there are no good KWin themes yet (programmers usually aren't good artists and vice versa).
That is about to change, though. Just recently, a KWin plugin was released that imports IceWM themes and uses them as-is. This is the strength of a plugin architecture. Now you can use any IceWM theme you want. Its in CVS now, you can download it youself or wait until KDE 2.2. In the future, also expect to see many more style plugins for KWin (KDE 2.2 will include several new ones). Eventually someone may make a generic themeable plugin that will allow themeing of KWin without C++ coding. Either that or everyone will simply make IceWM themes for KDE!
Really? Why does Mozilla even need QT then? Why doesn't someone just port it to XLib and be done with it?
In an ideal world, it would be like this. However, becuase this isn't an ideal world, a toolkit will almost always be more accessible in its native language (the one it was programmed in). You are, of course, free to chip in and change that with a new cross-language toolkit - I suggest you do it yourself if that's what you really want done. If you build it, they will come! That's what's great about Open Source and Free Software.
Consistent look and feel =! theming! Please understand this! Its dialog boxes, widget behavior, panel application behaviour, drag and drop behaviour (xdnd still isn't used properly by either Konq or the GNOME desktop - try it with Konq FTP sometime).
Ah, we're getting more OT. I thought you weren't talking about KDE/GNOME, only QT/GTK! Dialog boxes are provided mostly by the desktop environment. Panels and panel applications are provided completely by the environment, not the toolkit at all. (BTW, the KDE 2 panel supports WindowMaker dock applets - I think it can use GNOME panel applets as well). Widget behavior *is* part of themeing, with QT its possible to change the operation of a widget just with themes! Drag and drop interoperability is also provided by the desktop, and its improving - I suspect within the year it'll be working perfectly. The duplicate Control Centers and such are not a problem - just don't use the other one! And don't think nobody cares! That just shows that you don't read the KDE or GNOME mailing lists. Desktop Integration has been a big topic recently - there are joint mailing lists, community standards, and other stuff. The results are starting to show: the QT-GTK widget, XParts, more standardized DND (it used to be much worse), the gphoto KDE IOSlave. Its getting better all the time!
Good point, but they're both unfortunately very rarely used.
That's because they were just invented 2-3 months ago! Give them time, they will be used now that they are available.
My understanding of the current QT licensing situation were that someone could port the Linux version of QT to Win32 to create a GPLed Win32 QT. Anyone care to correct me?
Oh, sure. You'll *just* PORT it! Gee, why didn't I think of that?
Seriously, though, if you think it's needed, start the project yourself. If it's really needed, others will help you. I think you'll have to get a lot of people to keep up with those guys at TrollTech, though. They aren't going to be standing still while you port QT/Linux to Windows.
Um, yes. That's what I'm talking about.
No its not. At least it wasn't. You seem to have switched gears now from "lets merge GTK and QT and keep compatibility" to "Lets create a whole new toolkit." Its a totally different argument now. Before you seemed to want to create a super-library that would be both backward and forward binary- and source-compatible with apps written in both C and C++ using different graphics toolkits! Now you want to start a new library that's better than all the rest. In that case, more power to you. Just don't expect source or binary compatibility with GTK and QT, and don't expect others to do it for you once they hear your great idea. If you want something done, do it yourself! Others may join you later, but they won't start it for you.
if you're speaking about KDE / GNOME (semi OT), no
No, I'm not speaking about KDE vs. GNOME. KDE simply enables QT to import the themes - it would be quite possible for QT to do it without KDE (only with the help of the small converter program). QT can be made to look and feel *exactly* like GNOME, totally erasing the "look and feel" issue. The "common dialogs" issue is OT, as it refers to KDE and GNOME themselves.
Because Win32 is not Open Source, controled by MS and is broken according to some.
Win32 isn't open source, but WINE is, and WINE is an implementation of Win32. By your logic, we should try to merge all graphics toolkits into one big, happy API family. Why stop at QT and GTK? Why not try to make a giant über-library that can run any program for any graphics toolkit ever made? It's impractical and unnecessary! QT and GTK do the job just fine the way they are, thank you very much! I see no concievable benefit in merging them. Less memory usage? Maybe a megabyte. But certainly no more than that.
Actually, I was thinking of having Qt compile GTK apps, as it seems to be the more well developed and cross platform of the two.
That still doesn't help the portability problem. QT Windows and QT [something that's not linux] is NOT GPL and NOT FREE(as in beer). You'd have to pay QT licensing fees to develop GTK Windows applications! What kind of sense does that make?
a single object model would still be cleaner
A single object model would require either:
Changing the existing object models
or
Adopting one object model over the other.
Changing the existing object models would simply be creating a whole NEW object model. Just what we need. There's no guarantee that the new one will be better than either of the old ones (it'd probably be worse due to compromises). Adopting one object model over the other will simply not happen, because it would change the API and therefore require lots of people to totally rewrite their programs. If you think people are going to go for that, you're crazy.
This whole "make QT compatible with GTK" thing would just be a lot of work for questionable benefit. What do we get? Consistent look and feel? Already got it (theme importer). Interoperability? Already got it (QT-GTK widget and XParts). Lower memory usage? Not much at all (if you want to support programs written for both toolkits). A better programming environment? If that's what you're after, why not start a whole new toolkit? It would make more sense. You seem to want to both merge QT and GTK's APIs AND keep compatibility (how come QT can't compile my GTK apps?) I'm sorry, that's simply not possible. Changing APIs requires total program rewrites. Might as well start a whole new toolkit, QTK or something.
-
-
-
-
-
-
Please bear in mind this is a completely different concept to merging KDE and GNOME, which have less to do with Qt and GTK than many people think.QT and GTK use different langages (C vs. C++ - yes that's too much of a difference to compensate for in any reasonable way).
If this came about, what would be the point of having 2 toolkits anyway? Why don't we all just switch to Win32 programming and use WINE? One toolkit is better than 2, right?
KDE can import your GTK+ and IceWM themes, making "lack of constant appearance" a matter of user choice.
What lack of consistency in UIs? Buttons, scrollbars, checkboxes, radio buttons, dockable toolbars - these concepts are almost identical in both toolkits. The only difference is in their appearence (KDE puts two buttons at the bottom of a scrollbar, but only in some themes, etc - this would be solved by QT importing GTK themes).
Making GTK compile QT apps (even though it's really impossible) would not help the stability, speed, or functionality of the Windows port of GTK, so it wouldn't help get a quality free toolkit for Windows any more than simply working more on GTK for Win32 directly.
Finally, the "limited widget availability between both toolkits" problem is about to go away. With QT-GTK and GTK-QT widgets almost ready and XParts in the works, programs for either toolkit can use widgets or components (think KParts/Bonobo) from both.
What? It has everything to do with QT and GTK! GNOME was started for the express purpose of providing a desktop environment based on something other than QT. If KDE and GNOME used the same toolkit, merging them would almost be a trivial task. Their choice of toolkits is the only thing really keeping them apart.
Now if only they could address your other complaints...
Rad! I'm definitely going to have to try that out! Too bad I don't have a CF card, that means I'll only be able to get 15-30 min of TV...
Also, I seriously doubt that the Newton's handwriting recognition is any better than Microsoft's Transcriber (an amazing piece of software). However, a keyboard is still faster than handwriting, even on actual paper, and especially for coding (writing characters like *, &, {, and } is not fun)
Try "never." It has an internal Li-polymer (or some such) battery that is about 2mm thick (!). It recharges as long as its on the docking cradle. Its not really a problem, since for the iPAQ to be really useful, its best to sync it at least once a day, and the battery recharges pretty fast while you sync.
what do you think they[PC cards]'re going to do to a handheld on AAAs?
Who knows? Although you can never have too much battery power, I think they iPAQ's battery does pretty well even with PC cards. Of course it does depend on what card you're using as well. Also, there are battery extenders available that can simply plug in to the bottom of the iPAQ, doubling the battery life.
But 64 is ridiculous.
I don't think so. I'd love 64 MB. That way, my iPAQ could have a reasonable music collection on it and it could be my MP3 player as well as a PDA. Plus, when you start putting Linux on it, and get one of these, the iPAQ becomes a serious competitor to a full-fledged laptop. Why lug around a 2 lb brick when you can carry around your iPAQ with wireless (or wired) Internet access, a full-sized keyboard, and the processor power and memory to make good use of both?
There is only one issue I have with my iPAQ: the fact that it can only detect one button press at a time. That is really the only complaint I have (it's making it harder for me to finally beat Super Mario Bros. 3 ;-) If it was really a problem, though, I'd just go get one of these. In fact, I may get one anyway, just because they're SO DARN COOL!
I am very impressed with Compaq's willingness to help out with porting Linux to the iPAQ. The handhelds.org site is hosted by them and they provide technical specs for the iPAQ to porters.
Overall, I'm extremely happy with my iPAQ. It's a great product, don't deprive yourself because of some silly vendetta.
P.S. The best way to get an iPAQ is to simply go down to your local Best Buy (they probably already have a sample unit for you to play with) or other tech store and get on a waiting list. Compaq is doling out iPAQs in small increments to retail chains as they become available. Don't fiddle around with online retailers or whatever. I got my iPAQ in Febuary from my local Best Buy, after waiting a little more than a month.