Yeah, justdeals are sleazebag shippers, advertising low prices and inflating shipping. They have a pretty crappy online reputation regarding shipping and dealing with defective items as well. I ordered from them just once, and it took them over two weeks to even ship the item. But for some items it's worth it anyway (like my Proxim wireless card: $12/card, $40 for the access point, can't be beat).
Also, these mice aren't really $1, since you can't amortize the high shipping cost by buying a bunch at once; each one will cost $11 to ship.
> Take a look at how users (not geeks) use their hard drives. >See how all the files are usually stuck in one huge folder?
Yes, and that's usually the result of ignorance, not organization. Most users at that level of competence that I've seen have no notion of hierarchical folders, or the distinction between files and folders. They see the menu item "My Documents" in the Start menu, and that's the only place they know where to look for their files; they click on it and magically a window with all their documents opens up, without them even being aware that they're actually looking at the contents of a folder. If an application opens the Save dialog by default in the "My Documents" folder, then they'll be fine, otherwise they'll never find those saved documents again--unless they've mastered the art of "File|Open..." to get to documents.
This level of competence is something you want to train users AWAY from, not something you want to accept as a reasonable status quo. In fact, once you teach beginners the notion of folders, you usually see them eagerly warming to the concept and going through a period of excessive folder creation and use. The moral of the story is that the behavior of most computer users is usually not the result of a best-practices analysis.
Mhm. Electrostatics and magnets, the eternal objects of fascination of crackpot science. All "technical" details invariably always related by word of mouth and memory from another guy who actually did it. Never an actual working prototype that can be demonstrated to the public. Yeah, I wonder why Slashdot is not biting.
> The ms sql gurus that get exposed to the like of > DB2 or Oracle don't even seem to like it (mssql).
Oh yeah? Give me their names and addresses, I'd like to have a good laugh. We're using both Oracle and MSSQL here, and while no-one is denying Oracle's advantages (such as they are), its strengths certainly do NOT lie in ease of use and maintenance. While we certainly have many valid reasons to hate and/or ridicule Microsoft, Enterprise Manager certainly has few peers in the database maintenance world.
Actually, it's probably one of the better kept secrets in the installer world, although, judging by the number of downloads on their website, it's quite popular. Plus, doing a Google Groups search on installers returns lots of references to Inno.
> and even better the setup compiler runs under Wine, so sending out > frequent releases from a Linux development machine is easy.
Actually, since the full Delphi source code is available, it should be quite possible to port it to Linux using Kylix, resulting in a native installer. I don't know if such an effort is underway, but I wouldn't be surprised.
That would be another totally free option. You can get it at http://www.jrsoftware.org/isinfo.php. It creates installers with the new Windows Installer look, consisting of one single Setup.exe file. Plus, some third party extensions add scripting capabilities (http://www.wintax.nl/isx) and an install builder IDE (http://www.bhenden.org/istool). Many consider this to be the best free install builder, rivaling even some commercial ones.
Of course, it doesn't address versioning or online updating. But any of the systems I've seen seemed proprietary and bound to a particular product--check out Microsoft's Windows Update, for example. It would be nice if someone came up with a complete solution, including a back-end server (or maybe FTP or HTTP based) and a client-side app that was installed along with your app and knew enough about it to do a live update. Plus, of course, an admin tool for the back-end to manage all the bits there.
Thanks, that's a great tip. However, I seem to be getting by just fine without using Quicktime at all, so I think I'll stick to that. Besides, it seems that MPEG-4 will have a bright future all by itself, and there will be plenty of non-Apple choices for players.
I would be supporting Apple. I have no more love or admiration for Apple than I have for Microsoft, and since using Quicktime is avoidable, that's precisely what I'm doing.
The utter dependence on the registry for all things COM is what makes Windows more fragile than most other systems. After several months or years of installing, uninstalling and updating software, the registry is full of dangling CLSIDs, type libraries, ProgIDs etc. Worse, the versioning system can get completely screwed up with several generations of ActiveX DLLs co-existing and periodically getting re-registered by their respective parent apps. VB developers have a particularly nasty experience, since by default VB re-generates all the CLSIDs of COM objects each time a project is built, without usually bothering to clean up the previous ones. So over time the CLSID subtree is littered with orphaned COM class debris.
Right now my work system (W2K) most of the time takes forever to pop up the context menu on files in Windows Explorer. It didn't always do it, but I can't really identify a major change to the system that precipitated that. No doubt some of the shell extensions that are being activated each time are looking for "stuff" that they're either not finding, are being slowed down by other components that they're relying on, or experiencing some other type of timeout. The menu can take 30 seconds or more to pop up. Similarly, some types of file operations take equally long: deleting a file from within Windows Explorer can take over half a minute, half of that time waiting for the confirmation dialog, the other half waiting for the "deleting file" animation dialog to quit. These are all most likely COM related problems that could probably easily be fixed--if you know what you're looking for. Unfortunately, a trace on registry operations during a context menu popup generates so much output as to be virtually useless.
Things like these all add up to make the Windows user experience increasingly frustrating with advancing time, particularly because of the seeming intractability of the problems. The new.NET architecture promises to eliminate much of this mess, since class installation and activation is FS based like Java, and not registry-based like COM. Only time will tell if it turns out being any better, though.
I refuse to use Real Player and the free Quicktime player precisely because of their annoying nag nature. Quicktime is particularly bad because it asks you if you want to upgrade EVERY SINGLE TIME you play a file or stream.
> I hope x86-64 is huge, but if it's too expensive
More expensive than Itanium? Get real. Last week's eWeek had a good editorial on this. AMD has traditionally catered towards the consumer end of the market, and even if they go more upmarket they're likely to be consideraby cheaper than Intel's high-end offerings.
Contrary to the warnings at the site, any reasonably up to date hardware shouldn't have a problem with the large database. I have a Duron 1000 with a TNT2 and 512MB RAM, and the experience with the default settings was absolutely smooth, no jerkiness at all. Even after turning on all options I was still getting decent performance, probably around 10fps or more.
Now they need to concentrate on navigation. For now the interface is extremely spartan, they really need some nifty navigation UI gadgets and metaphors. It was too easy to get lost amongst the stars and not see anything for long stretches. They should also let you browse the database and pick objects to jump to. Maybe a little bird's-eye view of the database in a corner that shows you where you are in the big picture would be nice, too.
Borland has had that one for a LONG time, since before VS even existed. Just go check out BC++ 3. Not integrated as a dockable pane, but that's simply an evolution of a prior concept into a contemporary UI metaphor.
> Form Editor
Huh? Oh, you mean the VB form designer. Let's not lump VB features together with VC features, since the latter certainly won't benefit from any of the features of the former. The whole term Visual Studio is really a misnomer, because it's certainly not an integrated environment, but rather two completely and utterly unrelated IDEs. Within the context of this thread I will assume VS to mean VC. And as far as the form designer in VC is concerned, well, Borland has had the Resource Workshop for a very long time, also long before VC's time, and that offered the same paradigm.
> Message Window
Well, you kinda NEED that one with MFC development, unlike in JBuilder, so I'm not sure it qualifies as a feature as much as a shortcoming.
And the whole docking tool window concept is hardly Microsoft's creation either. Corel and Lotus have been using it for a decade, long before Microsoft adopted it and put its own visual style on it.
Because nothing new comes from the K people, it's all just rehashes of existing software.
> JBuilder
Like VS? You must be kidding me. How exactly? If anything VS.NET copied copious amounts of ideas from JBuilder and Delphi--such as tabbed editors, the task list, the enhanced property editor, etc.
That wasn't odd at all. They already had a full IDE for win32 which they wanted ported to Linux ASAP, and using winelib was the quickest way. That would buy them time to then rewrite it natively at their leisure. The compiler OTOH emits native code that requires only Qt. While the IDE itself is written in Delphi, some parts of it aren't (like the code editor) or might possibly use win32-isms, so it wasn't a simple recompile with the Linux compiler.
> Some commercial X-servers for Windows have a local windowmanager
Those would be X clients, not X servers. They allow you to view the remote desktop of a Unix machine running X, not the remote desktop of a Windows machine. Serving up a Windows desktop to a remote machine is a lot trickier since Windows doesn't provide much hinting regarding drawing requests of local clients. IOW, when an app requests a DC and each time it draws on it, you would like to be notified of the drawing primitives used (line, fill, text, brush etc.), so that you can echo the operation to the remote client. Alas, Windows won't tell you that. You would have to rewrite GDI32.DLL to hook yourself in at this level. What the VNC server does instead is to add a system hook dll into the process space of each running app, intercepting all incoming messages to the apps' windows and checking for certain operations (such as rectangle invalidations, PAINT, window movement and resize, etc), and using the appropriate coordinates to grab a rectangular bitmap, compress it, and send it to the remote client. The VNC server on Windows is entirely bitmap based, I believe, it mirrors no vector operations at all. The VNC server for X OTOH can intercept all X drawing operations, so it can echo a much leaner data stream. That's why viewing a remote Windows desktop is a lot slower than viewing an X desktop. And no, to my knowledge VNC does in no way use the X protocol, so your assertion that the VNC server is an X server is incorrect.
If you want a cross-platform solution, you have to forget about X. Basically, the source machine from which you want to export a window to a destination machine has to become the display server, and the destination machine becomes the display client. It seems the easiest solution would be to hack a custom VNC to make it window oriented, so that the client can display multiple individual windows from the server as if they were local windows. It would also be nice to add some browsing capabilities to be able to browse for destination machines, since the current VNC is quite spartan in this respect. Then again, you have to wonder if the user experience might not become too confusing, having some remote windows intermixed with local windows, and telling which is which. Perhaps the current desktop oriented VNC is good enough?
Re:Good conclusion, poor article
on
Qt vs MFC
·
· Score: 2
> Actually the CLX library [...] is based in the Qt library.
True, but that should be thought of as an implementation detail. You code to the CLX, not to Qt. Theoretically Borland could in the future rewrite the CLX on each platform straight to the metal without using Qt, and your programs should still compile. In practice they probably did surface some Qt here and there, maybe data structures taken as parameters of some methods, same as they did with win32 in the VCL.
Re:Good conclusion, poor article
on
Qt vs MFC
·
· Score: 2
> Actually, you could (and they might) handle this by overloading the > assignment operator (assuming VCL is in C++ [..])
It isn't, though, it's in Object Pascal, which doesn't support operator overloading. You could still do it by changing the event handler method pointers to pointers to a singleton object that did the same work as connect() via an Add() method, without incurring any memory overhead per event handler per component.
> you'd have to figure out how to make a semantically similar Remove()
Well, in C++ you could simply overload the following operators:
+= : add this event handler -= : remove this event handler = : clear event handlers, then add this one
I believe that's the mechanism they're using in C# with delegates (except maybe for the third one).
Re:Good conclusion, poor article
on
Qt vs MFC
·
· Score: 2
> The problem it that it is hard to isolate a MFC example.
You've got a point, but you can still give the steps required to hook up a buttong to an event handler. Doing that would have actually strengthened the argument considerably, precisely because VS is such a mess.
> I encourage you to write it, that would be interesting.
Hey, it's easier to criticise than to create, so I'll restrict myself to that, thank you very much.
> And I don't see your point with fairness.
I meant that as in Qt towering head and sholders above the MFC in the criteria chosen, finding faults in the MFC was almost like taking candy from kids. I was just thinking about comparing Qt to a similarly OO framework.
Re:Good conclusion, poor article
on
Qt vs MFC
·
· Score: 2
> Just curious: if button.OnClick and action are both method pointers, > how can you have more than one action in response to a click?
Well, you're right, you couldn't in the current implementation. The simple method pointers on the components would have to be replaced by some sort of object with Add and Remove methods of its own, which would then insert the event handler assigned into some notification data structure. Basically you'd be "OO-fying" what connect() does in Qt. It would likely have more overhead than the Qt approach, so it's a matter of what you value more, OO-ness or performance.
Re:Advocacy, we never knew thee.
on
Qt vs MFC
·
· Score: 2
> But please learn how to find good things in other libraries.
That's hardly a sign of a well-balanced comparison. You can completely blast a product and still have a fair review--IF the product really sucks in the criteria chosen, and you can fully document why and how it sucks. Unfortunately this author didn't do that, blasting the MFC on generalities without giving specific code examples, which OTOH he was more than eager to provide for Qt. Within the criteria used--OO design and ease of use--the MFC would pitifully fail against Qt, but you wouldn't know it reading this article.
Slashdot Mirror
> The shipping is kind of steep
Yeah, justdeals are sleazebag shippers, advertising low prices and inflating shipping. They have a pretty crappy online reputation regarding shipping and dealing with defective items as well. I ordered from them just once, and it took them over two weeks to even ship the item. But for some items it's worth it anyway (like my Proxim wireless card: $12/card, $40 for the access point, can't be beat).
Also, these mice aren't really $1, since you can't amortize the high shipping cost by buying a bunch at once; each one will cost $11 to ship.
> Take a look at how users (not geeks) use their hard drives.
>See how all the files are usually stuck in one huge folder?
Yes, and that's usually the result of ignorance, not organization. Most users at that level of competence that I've seen have no notion of hierarchical folders, or the distinction between files and folders. They see the menu item "My Documents" in the Start menu, and that's the only place they know where to look for their files; they click on it and magically a window with all their documents opens up, without them even being aware that they're actually looking at the contents of a folder. If an application opens the Save dialog by default in the "My Documents" folder, then they'll be fine, otherwise they'll never find those saved documents again--unless they've mastered the art of "File|Open..." to get to documents.
This level of competence is something you want to train users AWAY from, not something you want to accept as a reasonable status quo. In fact, once you teach beginners the notion of folders, you usually see them eagerly warming to the concept and going through a period of excessive folder creation and use. The moral of the story is that the behavior of most computer users is usually not the result of a best-practices analysis.
> Such is Slashdot.
Mhm. Electrostatics and magnets, the eternal objects of fascination of crackpot science. All "technical" details invariably always related by word of mouth and memory from another guy who actually did it. Never an actual working prototype that can be demonstrated to the public. Yeah, I wonder why Slashdot is not biting.
In addition to Ground Force and the ever flopping breasts.
> The ms sql gurus that get exposed to the like of
> DB2 or Oracle don't even seem to like it (mssql).
Oh yeah? Give me their names and addresses, I'd like to have a good laugh. We're using both Oracle and MSSQL here, and while no-one is denying Oracle's advantages (such as they are), its strengths certainly do NOT lie in ease of use and maintenance. While we certainly have many valid reasons to hate and/or ridicule Microsoft, Enterprise Manager certainly has few peers in the database maintenance world.
Actually, it's probably one of the better kept secrets in the installer world, although, judging by the number of downloads on their website, it's quite popular. Plus, doing a Google Groups search on installers returns lots of references to Inno.
> and even better the setup compiler runs under Wine, so sending out
> frequent releases from a Linux development machine is easy.
Actually, since the full Delphi source code is available, it should be quite possible to port it to Linux using Kylix, resulting in a native installer. I don't know if such an effort is underway, but I wouldn't be surprised.
That would be another totally free option. You can get it at http://www.jrsoftware.org/isinfo.php. It creates installers with the new Windows Installer look, consisting of one single Setup.exe file. Plus, some third party extensions add scripting capabilities (http://www.wintax.nl/isx) and an install builder IDE (http://www.bhenden.org/istool). Many consider this to be the best free install builder, rivaling even some commercial ones.
Of course, it doesn't address versioning or online updating. But any of the systems I've seen seemed proprietary and bound to a particular product--check out Microsoft's Windows Update, for example. It would be nice if someone came up with a complete solution, including a back-end server (or maybe FTP or HTTP based) and a client-side app that was installed along with your app and knew enough about it to do a live update. Plus, of course, an admin tool for the back-end to manage all the bits there.
> You could try doing a search for regclean
I run regclean regularly, but that won't fix this problem.
Thanks, that's a great tip. However, I seem to be getting by just fine without using Quicktime at all, so I think I'll stick to that. Besides, it seems that MPEG-4 will have a bright future all by itself, and there will be plenty of non-Apple choices for players.
I would be supporting Apple. I have no more love or admiration for Apple than I have for Microsoft, and since using Quicktime is avoidable, that's precisely what I'm doing.
The utter dependence on the registry for all things COM is what makes Windows more fragile than most other systems. After several months or years of installing, uninstalling and updating software, the registry is full of dangling CLSIDs, type libraries, ProgIDs etc. Worse, the versioning system can get completely screwed up with several generations of ActiveX DLLs co-existing and periodically getting re-registered by their respective parent apps. VB developers have a particularly nasty experience, since by default VB re-generates all the CLSIDs of COM objects each time a project is built, without usually bothering to clean up the previous ones. So over time the CLSID subtree is littered with orphaned COM class debris.
.NET architecture promises to eliminate much of this mess, since class installation and activation is FS based like Java, and not registry-based like COM. Only time will tell if it turns out being any better, though.
Right now my work system (W2K) most of the time takes forever to pop up the context menu on files in Windows Explorer. It didn't always do it, but I can't really identify a major change to the system that precipitated that. No doubt some of the shell extensions that are being activated each time are looking for "stuff" that they're either not finding, are being slowed down by other components that they're relying on, or experiencing some other type of timeout. The menu can take 30 seconds or more to pop up. Similarly, some types of file operations take equally long: deleting a file from within Windows Explorer can take over half a minute, half of that time waiting for the confirmation dialog, the other half waiting for the "deleting file" animation dialog to quit. These are all most likely COM related problems that could probably easily be fixed--if you know what you're looking for. Unfortunately, a trace on registry operations during a context menu popup generates so much output as to be virtually useless.
Things like these all add up to make the Windows user experience increasingly frustrating with advancing time, particularly because of the seeming intractability of the problems. The new
I refuse to use Real Player and the free Quicktime player precisely because of their annoying nag nature. Quicktime is particularly bad because it asks you if you want to upgrade EVERY SINGLE TIME you play a file or stream.
> I hope x86-64 is huge, but if it's too expensive
More expensive than Itanium? Get real. Last week's eWeek had a good editorial on this. AMD has traditionally catered towards the consumer end of the market, and even if they go more upmarket they're likely to be consideraby cheaper than Intel's high-end offerings.
Contrary to the warnings at the site, any reasonably up to date hardware shouldn't have a problem with the large database. I have a Duron 1000 with a TNT2 and 512MB RAM, and the experience with the default settings was absolutely smooth, no jerkiness at all. Even after turning on all options I was still getting decent performance, probably around 10fps or more.
Now they need to concentrate on navigation. For now the interface is extremely spartan, they really need some nifty navigation UI gadgets and metaphors. It was too easy to get lost amongst the stars and not see anything for long stretches. They should also let you browse the database and pick objects to jump to. Maybe a little bird's-eye view of the database in a corner that shows you where you are in the big picture would be nice, too.
> Class Explorer
Borland has had that one for a LONG time, since before VS even existed. Just go check out BC++ 3. Not integrated as a dockable pane, but that's simply an evolution of a prior concept into a contemporary UI metaphor.
> Form Editor
Huh? Oh, you mean the VB form designer. Let's not lump VB features together with VC features, since the latter certainly won't benefit from any of the features of the former. The whole term Visual Studio is really a misnomer, because it's certainly not an integrated environment, but rather two completely and utterly unrelated IDEs. Within the context of this thread I will assume VS to mean VC. And as far as the form designer in VC is concerned, well, Borland has had the Resource Workshop for a very long time, also long before VC's time, and that offered the same paradigm.
> Message Window
Well, you kinda NEED that one with MFC development, unlike in JBuilder, so I'm not sure it qualifies as a feature as much as a shortcoming.
And the whole docking tool window concept is hardly Microsoft's creation either. Corel and Lotus have been using it for a decade, long before Microsoft adopted it and put its own visual style on it.
> KDevelop
Because nothing new comes from the K people, it's all just rehashes of existing software.
> JBuilder
Like VS? You must be kidding me. How exactly? If anything VS.NET copied copious amounts of ideas from JBuilder and Delphi--such as tabbed editors, the task list, the enhanced property editor, etc.
> That's why it's an odd dependency
That wasn't odd at all. They already had a full IDE for win32 which they wanted ported to Linux ASAP, and using winelib was the quickest way. That would buy them time to then rewrite it natively at their leisure. The compiler OTOH emits native code that requires only Qt. While the IDE itself is written in Delphi, some parts of it aren't (like the code editor) or might possibly use win32-isms, so it wasn't a simple recompile with the Linux compiler.
> Some commercial X-servers for Windows have a local windowmanager
Those would be X clients, not X servers. They allow you to view the remote desktop of a Unix machine running X, not the remote desktop of a Windows machine. Serving up a Windows desktop to a remote machine is a lot trickier since Windows doesn't provide much hinting regarding drawing requests of local clients. IOW, when an app requests a DC and each time it draws on it, you would like to be notified of the drawing primitives used (line, fill, text, brush etc.), so that you can echo the operation to the remote client. Alas, Windows won't tell you that. You would have to rewrite GDI32.DLL to hook yourself in at this level. What the VNC server does instead is to add a system hook dll into the process space of each running app, intercepting all incoming messages to the apps' windows and checking for certain operations (such as rectangle invalidations, PAINT, window movement and resize, etc), and using the appropriate coordinates to grab a rectangular bitmap, compress it, and send it to the remote client. The VNC server on Windows is entirely bitmap based, I believe, it mirrors no vector operations at all. The VNC server for X OTOH can intercept all X drawing operations, so it can echo a much leaner data stream. That's why viewing a remote Windows desktop is a lot slower than viewing an X desktop. And no, to my knowledge VNC does in no way use the X protocol, so your assertion that the VNC server is an X server is incorrect.
If you want a cross-platform solution, you have to forget about X. Basically, the source machine from which you want to export a window to a destination machine has to become the display server, and the destination machine becomes the display client. It seems the easiest solution would be to hack a custom VNC to make it window oriented, so that the client can display multiple individual windows from the server as if they were local windows. It would also be nice to add some browsing capabilities to be able to browse for destination machines, since the current VNC is quite spartan in this respect. Then again, you have to wonder if the user experience might not become too confusing, having some remote windows intermixed with local windows, and telling which is which. Perhaps the current desktop oriented VNC is good enough?
> Actually the CLX library [...] is based in the Qt library.
True, but that should be thought of as an implementation detail. You code to the CLX, not to Qt. Theoretically Borland could in the future rewrite the CLX on each platform straight to the metal without using Qt, and your programs should still compile. In practice they probably did surface some Qt here and there, maybe data structures taken as parameters of some methods, same as they did with win32 in the VCL.
> Actually, you could (and they might) handle this by overloading the
> assignment operator (assuming VCL is in C++ [..])
It isn't, though, it's in Object Pascal, which doesn't support operator overloading. You could still do it by changing the event handler method pointers to pointers to a singleton object that did the same work as connect() via an Add() method, without incurring any memory overhead per event handler per component.
> you'd have to figure out how to make a semantically similar Remove()
Well, in C++ you could simply overload the following operators:
+= : add this event handler
-= : remove this event handler
= : clear event handlers, then add this one
I believe that's the mechanism they're using in C# with delegates (except maybe for the third one).
> The problem it that it is hard to isolate a MFC example.
You've got a point, but you can still give the steps required to hook up a buttong to an event handler. Doing that would have actually strengthened the argument considerably, precisely because VS is such a mess.
> I encourage you to write it, that would be interesting.
Hey, it's easier to criticise than to create, so I'll restrict myself to that, thank you very much.
> And I don't see your point with fairness.
I meant that as in Qt towering head and sholders above the MFC in the criteria chosen, finding faults in the MFC was almost like taking candy from kids. I was just thinking about comparing Qt to a similarly OO framework.
> Just curious: if button.OnClick and action are both method pointers,
> how can you have more than one action in response to a click?
Well, you're right, you couldn't in the current implementation. The simple method pointers on the components would have to be replaced by some sort of object with Add and Remove methods of its own, which would then insert the event handler assigned into some notification data structure. Basically you'd be "OO-fying" what connect() does in Qt. It would likely have more overhead than the Qt approach, so it's a matter of what you value more, OO-ness or performance.
> But please learn how to find good things in other libraries.
That's hardly a sign of a well-balanced comparison. You can completely blast a product and still have a fair review--IF the product really sucks in the criteria chosen, and you can fully document why and how it sucks. Unfortunately this author didn't do that, blasting the MFC on generalities without giving specific code examples, which OTOH he was more than eager to provide for Qt. Within the criteria used--OO design and ease of use--the MFC would pitifully fail against Qt, but you wouldn't know it reading this article.