> Him: This number must be absolutely accurate, no rounding is allowed.
Assuming no irrational numbers, this is actually completely possible, using fixed point datatypes. You answered your boss like a coder, thinking in terms of float and double. I don't think this was what he was expecting of you in this precise case.
Technically your boss was not wrong, but he was certainly misunderstanding the issues at hand.
An engineer might have answered, "The tools we have to compute floating point numbers use the standard binary approximations that CPUs come with. They allow for very good precision usually, over 10 digits after the point. To do without any rounding at all, we will need to either find and buy custom dedicated tools, or write our own. By when do you want the cost estimate of this approach?"
That's what bosses -- the good ones, anyway -- expect. It comes with their job.:)
You've just described what DCOP does in KDE. Contact info is offered by the address book component, which can be queried by the email suite, the IM tool, etc. The entire desktop is built upon this approach, in fact.
The Freedesktop group has begun working on a generalization of DCOP called D-BUS, primarily geared toward exchanging message between backend (hardware detection...) and frontend (desktop environment), if I got it right, but I think that GNOME will also eventually be able to use it to tap into KDE components as well. This would be really nice.
The sad thing is that even if the ruling against Microsoft passes, this won't change a thing.
The problem is not so much software shipping with the OS, as APIs relying on the integrated software. Where Internet Explorer is concerned, for example, the Windows API offers certain features that are implemented in IE rather than in the OS. This means that from the moment you've got -any- piece of software that uses any of those API functions (to render help, for instance), then IE will no longer be optional. This is why back in the days when Windows 98 was released but didn't dominate the market yet, some third party software packages shipped with IE (in the same way games ship with the DirectX version they need nowadays), so that their software would run on 95. And the IE-ization of Windows 95 boxes everywhere happened just on its own.
And you can -bet- the exact same thing will happen here. One likely possibility is, [Palladium.latestName()] will provide some API to allow media-oriented software to transfer audio/video to the hardware via an encrypted conduit, and that API will be implemented in Microsoft Media Player. And without looking so far forward, I believe that there already are some products (Adobe Premiere?) that depend on some bit of API provided by Microsoft Media Player.
Even if your OS comes with competing products, sooner or later you'll need to install MMP.
Judge Jackson had the right idea all along. Split up Microsoft, **AND** have ANY technical information (API definitions...) exchanged between MS-core and MS-components made public.
This way, competitors could have accessed the information necessary to provide THEIR own implementation of any middleware API Microsoft published.
It would be the variable set for "machine is off."
Think about it.
Re:Konsole slow?
on
Review: KDE 3.2
·
· Score: 4, Informative
No problem here -- Konsole is zippy as usual, with all the helpful stuff (antialiasing, transparency + contrast, tabbed terms) turned on.
You should try to:
1) Fiddle with the conf (font family and size -- I use Andale Mono 8pt here, excellent readability/size ratio; transparency; bidi text...) to see if something in particular seems to trigger the slowness;
2) Submit a bug. Random slowness in some configurations is NOT normal. If it's a regression since KDE 3.1, do indicate so.
Hmm, you may want to make sure that your Konsole got compiled with the right font support, now that I think of it. Does the command 'ldd `which konsole`' yield links to libXrender.so, libfreetype.so and libXft.so.2 (not sure about that list, but that's already a start)?
Found the information a while back on dot.kde.org (can't find the link though, sorry).
The thing is that OO's input filters apparently load files directly into its memory structures, without an intermediate API. This makes it highly difficult for other projects to use them directly. So the best they can do is peek and poke at OO's code, try to understand what it does and why, and then use it in their own filter -- which they actually export as a library (libwv2) so that other projects can make use of it.
I -WISH- OO would have been more modular though. Would have saved loads of time...
I think their plan is to use OpenOffice as a stopgap, while keeping the work on KOffice. If you want to know, I used to believe that they were being stupid and should throw their technological knowledge at OO, like everybody else... But after actually giving the latest KOffice a try (I like to try stuff for myself, just to know what I'm talking about), I changed my mind.
I've basically switched to KOffice for my daily use, in fact. It is -NOT- yet as featureful as OO. However, it is so fast, lightweight and efficient (I'm in love with it's layout model) that I'm finding it a somewhat better tool for most of my daily tasks.
I'm not sure they'll ever be able to really compete with such a large, commercially-backed (by Sun) app as OpenOffice, but I must admit I now find myself darn glad they're trying. It'd be quite unlikely, but I wouldn't put it above them to pull a Konqueror in that market as well. You never know.
In the meanwhile, it's damn nice to have a KOffice to show to non-geek people -- especially those who won't switch to OO because of its massive weight and slowness. And if they don't manage it, well at least one can hope the competition will prod OO into getting lighter and faster...
QuickTime actually works pretty fine in a Linux browser, given the right tool. In this case, Kaffeine. Small Xine-based video player, fast and lightweight, simple interface but LOADS of features (DVD playback, with menus of course, post-processing video filters, stream saving...). It managed to impress me, and that's no small feat. It integrates completely seamlessly in Konqueror, so you can watch those embedded QuickTimes without a problem. It also ships with a plug-in for Netscape-related browsers, although I've not tested it personally -- please feel free to provide feedback if you do.
> Ever run win2k3? No? Because win9x sucked so hard? double standards are fun.
Exactly what in my post makes you assume I've never run the later Windows, and that I don't judge it based on the exact same standards I apply to Debian and whatever other distro I happen to be running right now?
As it happens, as far as closeness to the ideal "it should Just Work, the way *I* want it to" goes, even the latest Windows are behind on both counts -- partly because its idiosyncrasies are often hard to solve, when they're end-user solvable at all, while that of my current chosen Linux distro are not for whomever knows what they're doing, which I like to believe I do. Thus making that distro much closer to the "Just Works" ideal for me than Windows.
Some of us DO check out competing offers and then decide purely on which is the best tool, which doesn't have to be the one your biases (or paycheck) drags you to. Cope.
Debian used to snub KDE, alright. Thing is, they nolongerdo. So cut them some slack, who cares what they used to do and say as long as they've changed and improved. Don't blame the current distro for how it used to be managed.
In fact, if Debian keeps improving that way, it may very well become a strong contender for the desktop, which would be a Really Good Thing. While we may be a much of geeks here on/., I found that as you mature, you eventually reach a point where you're tired of fiddling with stuff all day long, and end up only using stuff that Just Works the way YOU want. In that regard, Debian+KDE is pretty much a killer combo.
(NB: Nope, I don't currently use Deb on my desktops, but if it keeps its current trend I may well switch eventually.)
> Derived objects, on the other hand, don't seem too useful for GUIs > so long as you have interfaces or a good implementation of generic > functions and type inference.
That's where you're wrong, with my apologies for putting it so bluntly.
Derivation is the #1 thing that makes the difference between a good widget set and a bad one, for several reasons.
The major reason is that in any complex application, you'll need custom widgets (entry fields with browsable history, viewing pane with custom repaint, etc). If you have to provide the functionnality by manually appending it to the native widget everywhere it's needed, your LOC (and the potentiality for bugs) explodes. The right way is to derive a self-contained widget from the general case, specialize it for the need once for all, and use it instead of its parent where needed, which only requires adding code in -one- place.
Typical example is KDE's file dialogs, that all derive from a common root, but can be expanded on an as-needed basis (and without even adding bloat since the common logic is in the parent class).
Typical counter-example is the MFC, which are absolutely awful to code against, because they're based on a non-object-oriented framework and have very little extensibility (WinForms is thankfully a major improvement in that regard).
Second important reason is granularity. Derivation allows an API to provide very high-level widgets (text editors, MDI areas...) -and- their lower-level parents, which in turn allows you to use the high-level widget where it's the fitting tool, and derive your own from the parent where it isn't, all the way down to the lower level widgets if they're what you need. Lack of the extensibility derivation offers in an API means your API will either have to remain very low-level, thus requiring you to reinvent higher-level wheels everytime you'll need them, -or- overbloating the API with countless specialized widgets to try to cover most of your needs (that's the MFC approach).
Typical example of why that matters is GTK's handling (or lack thereof) of MDI interfaces. Another saddening example is Gimp 1.3, and the considerable amount of time that has been spent on nothing but interface code rather than actual features.
Third reason is, of course, as you rightfully point out, event handling, which derivation allows to specialize as needed (for instance, tablet XInput events on a drawing widget -- see how Qt does it for a good example) -without- building a dedicated widget from the ground up -or- special-casing against XInput. Once again, Gimp 1.3 and its XInput handling problems are a good example of why it matters.
There are no two ways around it. There is virtually NO pure-C widget API left in existence (if you except GTK, which pays it dearly in LOC and slowness). This is not without reason.
Once again, I'm sorry, but while you're right about event handling, that is a -runtime- issue and pretty much orthogonal to widget development. You'll note, by the way, that Qt provides signals and slots -precisely- so that you don't have to think about that orthogonality in the common cases -- its widgets handle events on their own and emit the appropriate signals as required, which allows you to design your code according to WHAT is to be done in response to something, as opposed to HOW that something happened. Best example is the concept of QAction, which can be triggered from a butten, a menu, a context menu, or a key shortcut. You only have one signal to slot against, regardless of which way that action was triggered.
There, that's it for now. I hope I managed to make it a bit clearer why object orientation is primordial to a good GUI toolkit?
Actually, in France (been living there for a while, talked to more of them than you could throw a frog at), if you ask anyone who the 'father' of the plane would be, most of them don't know much at all of Santos-Dumont. However, that Clement Ader invented the plane is questioned by none (and it is hard to question when the plane in question is still in the CNAM museum for all to see...). This thing actually flew in 1890, a whole decade and a half before other widely recorded successes such as Santos-Dumont's, and first proved the possibility for heavier-than-air flight.
Which, of course, doesn't diminish in any way the extraordinary feat that the Wright brothers pulled, please don't take me wrong: no matter whose shoulders they were or weren't standing on, they're the ones who saw farther, and there is no questioning it their place in history for it. They didn't give up where others did.
It's just that Santos-Dumont was never a contender for the title of first man to fly, and not even the French claim so (although I can see people pretending that they do, for the sole sake of pointing out that the Wright brothers came before Santos-Dumont, and thus "Go us we invented the plane!", I suppose... but thankfully the average enlightened geek here on/. seems more interested in the engineering history than national dick contests, which is good).
If you're ever in Paris you may want to go see this thing in the CNAM museum. It's hanging from the ceiling over a large stairway. Extremely impressive sight.
This pretty interface you see...
on
Xandros version 2
·
· Score: 4, Informative
... is the native Plastik theme that comes with KDE 3.2. (Tip of the day: for added prettiness, set Nimbus Sans L as your default font. Then watch people gape and go 'ooooh!'). None of Xandros' doing, although their choosing it certainly sounds like a proof of good taste.
>... the customized OpenOffice which is one of the key perks of Ximian
Just to pipe in, I've been giving KDE 3.2beta2 a big hard testing, and so far Konqueror starts up in fractions of a second and renders most pages almost instantly. KMail opens almost as fast, is able to open mailboxes with over 36,000 messages in one second or so. KNode starts up almost instantly. Same for about all the apps I've tested so far, in fact -- they're really surprisingly fast.
In fact, they're much faster than many a standalone app (Mozilla, etc), counterintuitive as it may seem. I have a feeling this may be due to their noted good organisation and code reuse, but a deeper study of just how they managed it would certainly be interesting, as other notoriously slow projects (I'm thinking Open Office here) may wish to learn from them.
Note, I've not prelink'ed it yet. I hear it allows to divide startup times by up to a factor of two. We'll see, but I doubt it can become much faster than it already is, honestly.
For burning anything (audio CDs, data CDs, mixed CDs, DVDs, eMovix projects...) K3b is king. Never found a better burning frontend (including on Windows).
Don't worry about burning stuff under Linux, that problem seems solved for the time being, which is way cool.
> One of the articles you presented was an exposition of the > difference between writing for GTK in C and Python and Qt in C++. > It seemed a little apples-and-oranges, since nice C++ interfaces > are available for GNOME.
Maybe it -seemed-, yep. Unfortunately, it -is- not, as clearly expressed in another of the articles I presented, that from a Rosegarden developper, written after he switched to Qt/KDE from GTK/GNOME-with-C++. Interestingly, you'll note that the GTKmm maintainers didn't understand either how Qt/KDE in particular made his life a lot easier.
Besides, I still have more articles to link to -- I've been studying that precise issue for quite some time now, you know, and ressources on that matter don't lack. Although I fully understand why you wouldn't want to hear that... Apparently, from the way our minds work, emotional reactions have a lower interrupt level than what philosophers like to call our higher functions, which, frankly, sucks. (Which is why I tried to thoroughly study the depth of -both- desktop environments before I cared either way, if you want to know.)
> If you want to talk about the proprietary companies on GUIs, you > might consider that HP and Sun do that on GNOME. Even on their > Unix platforms.
I know, yes. However, and even though for each of these two you could prolly quote as many or twice as many other companies using the other desktop API, there's another reason still why Sun and HP are a subtly, but importantly different matter, I think.
They're selling desktops for OTHER people to develop on. It's -their- best interest to make the offer look as cheap as possible, and then let the customers deal with the (possible) costs of additional development times. Which is exactly what they should be doing, of course. That's what MS does as well, and it works great, commercially speaking.
Besides, you'll note that both Sun and HP are large corporations with money to spare, making them not the best example one could pick when talking about which choice is less costly, I think.
> One of the things I'd like to go for is the principle of least surprise.
I totally agree with you on this! Not on your conclusion, however. In terms of development, the principle of least surprise would have it that development tools are paid for separately. Sometimes much expensively.
This, frankly, sucks. But that's the principle of least surprise for you, though, I suppose...
The best situtation would be to be able to develop either way without fixed costs, of course. As another poster suggested, the best thing that could happen to the Linux desktop would be if someone like IBM bought off Qt and LGPL'ed it. However, until then, people for whom money isn't a commodity will pick the least costly choice. That's the way this world works, unfortunately. I wish it was otherwise, you can believe me.
Wicked! I get to catch no other than Bruce Perens himself posting a sizeable but subtle fallacy. I suppose that I get to really feel cool now, in a geeky sort of way. Anyway. Apologies, Bruce, for I strongly doubt you did it on purpose, but here it goes!
> One nice thing about GNOME is that a commercial license is not > necessary to write and distribute a proprietary GNOME application.
*clears throat*
"One nice thing about paper and pencils is that a pricy PC is not necessary to design and write loads of code."
I mean this seriously, and this says nothing either for or against paper and pencils as opposed to computers.
Only, well, in both cases, the right tool will simply saveenoughtime to make the cost well worth it.
And before some excited kid mods me down for daring to disagree with Bruce, let me tell you that if you've never used paper and pencil to design a piece of code you just thought up where no computer was at hand, you don't deserve your/. geek points.
Different tools work well in different circumstances, that's all. Deal.
And in this specific case, it is not unlikely there's a reason why one of the Linux desktop environments has moreproprietarycompanies developping for it than the others.
Food for thought, I hope.
(Having karma to spare is a nifty thing, you get to speak plainly and maybe get people to think. That's way cool.)
I hear you can get a native, Trolltech-provided Qt 3.2 Windows free edition on the CD-ROM that comes with the upcoming re-edition of the Qt book, too, if you can't want for the above project to reach completion.
Otherwise, a decent alternative is wxWindows (not as clean and elegant as Qt, and thus requires a bit more code for a given task, but still very decent, don't worry).
Grand-parent post doesn't hold MS to fault for the flaw itself, but for boasting about its supposedly 'more secure' FS. Which is, as you aptly demonstrate, mostly irrelevant to actual security.
> Why making things more complicated instead of making them > simplier?
Ever tried to code against the Gnome API, and especially the integration features (bonobo et al)? Do give it a try.
I fear it's MUCH too late to make it simple.
So instead they monetize it. Interesting idea. Whatever works, I suppose...
But I'm not really sure what to think of it, honestly. That'd they'd have to involve money to have things that SHOULD be simple get done... But then, what do I know, maybe that's where open source is headed, I don't know.
> GNOME uses the standard GTK dialogs for file selection (file save > and file open), instead of putting a GNOME layer over GTK for > those, specifically to avoid bloat.
This wouldn't be bloat if all Gnome programs shared the file dialog code. Even less so if the Gnome file dialog inherited from the GTK file dialog... but then, GTK makes reusability by inheritance a bit complicated, granted.
> I'm not sure what you mean about Nautilus being custom code;
See EEL (Eazel Extension Library). It's -not meant- to be used outside Nautilus. But you effectively get somewhat cool effects, at the cost of a little more bloat. That's not inherently a bad thing! The KDE development model seems to prefer adding capabilities to the core API, and -then- let apps use it, which is why it takes them more time to add cool effects I think (but it's also why when the effects are available, their use spreads through KDE apps much faster).
Slashdot Mirror
> Him: This number must be absolutely accurate, no rounding is allowed.
:)
Assuming no irrational numbers, this is actually completely possible, using fixed point datatypes. You answered your boss like a coder, thinking in terms of float and double. I don't think this was what he was expecting of you in this precise case.
Technically your boss was not wrong, but he was certainly misunderstanding the issues at hand.
An engineer might have answered, "The tools we have to compute floating point numbers use the standard binary approximations that CPUs come with. They allow for very good precision usually, over 10 digits after the point. To do without any rounding at all, we will need to either find and buy custom dedicated tools, or write our own. By when do you want the cost estimate of this approach?"
That's what bosses -- the good ones, anyway -- expect. It comes with their job.
You've just described what DCOP does in KDE. Contact info is offered by the address book component, which can be queried by the email suite, the IM tool, etc. The entire desktop is built upon this approach, in fact.
The Freedesktop group has begun working on a generalization of DCOP called D-BUS, primarily geared toward exchanging message between backend (hardware detection...) and frontend (desktop environment), if I got it right, but I think that GNOME will also eventually be able to use it to tap into KDE components as well. This would be really nice.
The sad thing is that even if the ruling against Microsoft passes, this won't change a thing.
The problem is not so much software shipping with the OS, as APIs relying on the integrated software. Where Internet Explorer is concerned, for example, the Windows API offers certain features that are implemented in IE rather than in the OS. This means that from the moment you've got -any- piece of software that uses any of those API functions (to render help, for instance), then IE will no longer be optional. This is why back in the days when Windows 98 was released but didn't dominate the market yet, some third party software packages shipped with IE (in the same way games ship with the DirectX version they need nowadays), so that their software would run on 95. And the IE-ization of Windows 95 boxes everywhere happened just on its own.
And you can -bet- the exact same thing will happen here. One likely possibility is, [Palladium.latestName()] will provide some API to allow media-oriented software to transfer audio/video to the hardware via an encrypted conduit, and that API will be implemented in Microsoft Media Player. And without looking so far forward, I believe that there already are some products (Adobe Premiere?) that depend on some bit of API provided by Microsoft Media Player.
Even if your OS comes with competing products, sooner or later you'll need to install MMP.
Judge Jackson had the right idea all along. Split up Microsoft, **AND** have ANY technical information (API definitions...) exchanged between MS-core and MS-components made public.
This way, competitors could have accessed the information necessary to provide THEIR own implementation of any middleware API Microsoft published.
Actually, it makes perfect sense.
It would be the variable set for "machine is off."
Think about it.
No problem here -- Konsole is zippy as usual, with all the helpful stuff (antialiasing, transparency + contrast, tabbed terms) turned on.
You should try to:
1) Fiddle with the conf (font family and size -- I use Andale Mono 8pt here, excellent readability/size ratio; transparency; bidi text...) to see if something in particular seems to trigger the slowness;
2) Submit a bug. Random slowness in some configurations is NOT normal. If it's a regression since KDE 3.1, do indicate so.
Hmm, you may want to make sure that your Konsole got compiled with the right font support, now that I think of it. Does the command 'ldd `which konsole`' yield links to libXrender.so, libfreetype.so and libXft.so.2 (not sure about that list, but that's already a start)?
Found the information a while back on dot.kde.org (can't find the link though, sorry).
The thing is that OO's input filters apparently load files directly into its memory structures, without an intermediate API. This makes it highly difficult for other projects to use them directly. So the best they can do is peek and poke at OO's code, try to understand what it does and why, and then use it in their own filter -- which they actually export as a library (libwv2) so that other projects can make use of it.
I -WISH- OO would have been more modular though. Would have saved loads of time...
I think their plan is to use OpenOffice as a stopgap, while keeping the work on KOffice. If you want to know, I used to believe that they were being stupid and should throw their technological knowledge at OO, like everybody else... But after actually giving the latest KOffice a try (I like to try stuff for myself, just to know what I'm talking about), I changed my mind.
I've basically switched to KOffice for my daily use, in fact. It is -NOT- yet as featureful as OO. However, it is so fast, lightweight and efficient (I'm in love with it's layout model) that I'm finding it a somewhat better tool for most of my daily tasks.
I'm not sure they'll ever be able to really compete with such a large, commercially-backed (by Sun) app as OpenOffice, but I must admit I now find myself darn glad they're trying. It'd be quite unlikely, but I wouldn't put it above them to pull a Konqueror in that market as well. You never know.
In the meanwhile, it's damn nice to have a KOffice to show to non-geek people -- especially those who won't switch to OO because of its massive weight and slowness. And if they don't manage it, well at least one can hope the competition will prod OO into getting lighter and faster...
It's called a quine, and it's something of an ubergeeky pastime.
Example (not mine):
#!/usr/bin/perl
$s = q<print "#!/usr/bin/perl\n\$s = q<$s>;\n$s\n";>;
print "#!/usr/bin/perl\n\$s = q<$s>;\n$s\n";
Gee, that makes my head hurt...
Good luck making a true 5-7-5 haiku out of that, though.
QuickTime actually works pretty fine in a Linux browser, given the right tool. In this case, Kaffeine. Small Xine-based video player, fast and lightweight, simple interface but LOADS of features (DVD playback, with menus of course, post-processing video filters, stream saving...). It managed to impress me, and that's no small feat. It integrates completely seamlessly in Konqueror, so you can watch those embedded QuickTimes without a problem. It also ships with a plug-in for Netscape-related browsers, although I've not tested it personally -- please feel free to provide feedback if you do.
> Ever run win2k3? No? Because win9x sucked so hard? double standards are fun.
Exactly what in my post makes you assume I've never run the later Windows, and that I don't judge it based on the exact same standards I apply to Debian and whatever other distro I happen to be running right now?
As it happens, as far as closeness to the ideal "it should Just Work, the way *I* want it to" goes, even the latest Windows are behind on both counts -- partly because its idiosyncrasies are often hard to solve, when they're end-user solvable at all, while that of my current chosen Linux distro are not for whomever knows what they're doing, which I like to believe I do. Thus making that distro much closer to the "Just Works" ideal for me than Windows.
Some of us DO check out competing offers and then decide purely on which is the best tool, which doesn't have to be the one your biases (or paycheck) drags you to. Cope.
Debian used to snub KDE, alright. Thing is, they no longer do. So cut them some slack, who cares what they used to do and say as long as they've changed and improved. Don't blame the current distro for how it used to be managed.
/., I found that as you mature, you eventually reach a point where you're tired of fiddling with stuff all day long, and end up only using stuff that Just Works the way YOU want. In that regard, Debian+KDE is pretty much a killer combo.
In fact, if Debian keeps improving that way, it may very well become a strong contender for the desktop, which would be a Really Good Thing. While we may be a much of geeks here on
(NB: Nope, I don't currently use Deb on my desktops, but if it keeps its current trend I may well switch eventually.)
> Derived objects, on the other hand, don't seem too useful for GUIs
> so long as you have interfaces or a good implementation of generic
> functions and type inference.
That's where you're wrong, with my apologies for putting it so bluntly.
Derivation is the #1 thing that makes the difference between a good widget set and a bad one, for several reasons.
The major reason is that in any complex application, you'll need custom widgets (entry fields with browsable history, viewing pane with custom repaint, etc). If you have to provide the functionnality by manually appending it to the native widget everywhere it's needed, your LOC (and the potentiality for bugs) explodes. The right way is to derive a self-contained widget from the general case, specialize it for the need once for all, and use it instead of its parent where needed, which only requires adding code in -one- place.
Typical example is KDE's file dialogs, that all derive from a common root, but can be expanded on an as-needed basis (and without even adding bloat since the common logic is in the parent class).
Typical counter-example is the MFC, which are absolutely awful to code against, because they're based on a non-object-oriented framework and have very little extensibility (WinForms is thankfully a major improvement in that regard).
Second important reason is granularity. Derivation allows an API to provide very high-level widgets (text editors, MDI areas...) -and- their lower-level parents, which in turn allows you to use the high-level widget where it's the fitting tool, and derive your own from the parent where it isn't, all the way down to the lower level widgets if they're what you need. Lack of the extensibility derivation offers in an API means your API will either have to remain very low-level, thus requiring you to reinvent higher-level wheels everytime you'll need them, -or- overbloating the API with countless specialized widgets to try to cover most of your needs (that's the MFC approach).
Typical example of why that matters is GTK's handling (or lack thereof) of MDI interfaces. Another saddening example is Gimp 1.3, and the considerable amount of time that has been spent on nothing but interface code rather than actual features.
Third reason is, of course, as you rightfully point out, event handling, which derivation allows to specialize as needed (for instance, tablet XInput events on a drawing widget -- see how Qt does it for a good example) -without- building a dedicated widget from the ground up -or- special-casing against XInput. Once again, Gimp 1.3 and its XInput handling problems are a good example of why it matters.
There are no two ways around it. There is virtually NO pure-C widget API left in existence (if you except GTK, which pays it dearly in LOC and slowness). This is not without reason.
Once again, I'm sorry, but while you're right about event handling, that is a -runtime- issue and pretty much orthogonal to widget development. You'll note, by the way, that Qt provides signals and slots -precisely- so that you don't have to think about that orthogonality in the common cases -- its widgets handle events on their own and emit the appropriate signals as required, which allows you to design your code according to WHAT is to be done in response to something, as opposed to HOW that something happened. Best example is the concept of QAction, which can be triggered from a butten, a menu, a context menu, or a key shortcut. You only have one signal to slot against, regardless of which way that action was triggered.
There, that's it for now. I hope I managed to make it a bit clearer why object orientation is primordial to a good GUI toolkit?
Rosegarden developper Guillaume Laurent has a few interesting thoughts about why he switched from a GTK-based backed to some random object-oriented toolkit, if you'd care for a slightly different point of view on the same topic.
Are you implying that if the 'slacker' is a woman it suddenly becomes acceptable?!
Actually, in France (been living there for a while, talked to more of them than you could throw a frog at), if you ask anyone who the 'father' of the plane would be, most of them don't know much at all of Santos-Dumont. However, that Clement Ader invented the plane is questioned by none (and it is hard to question when the plane in question is still in the CNAM museum for all to see...). This thing actually flew in 1890, a whole decade and a half before other widely recorded successes such as Santos-Dumont's, and first proved the possibility for heavier-than-air flight.
/. seems more interested in the engineering history than national dick contests, which is good).
Which, of course, doesn't diminish in any way the extraordinary feat that the Wright brothers pulled, please don't take me wrong: no matter whose shoulders they were or weren't standing on, they're the ones who saw farther, and there is no questioning it their place in history for it. They didn't give up where others did.
It's just that Santos-Dumont was never a contender for the title of first man to fly, and not even the French claim so (although I can see people pretending that they do, for the sole sake of pointing out that the Wright brothers came before Santos-Dumont, and thus "Go us we invented the plane!", I suppose... but thankfully the average enlightened geek here on
If you're ever in Paris you may want to go see this thing in the CNAM museum. It's hanging from the ceiling over a large stairway. Extremely impressive sight.
... is the native Plastik theme that comes with KDE 3.2. (Tip of the day: for added prettiness, set Nimbus Sans L as your default font. Then watch people gape and go 'ooooh!'). None of Xandros' doing, although their choosing it certainly sounds like a proof of good taste.
... the customized OpenOffice which is one of the key perks of Ximian
>
Oh is it?
Just to pipe in, I've been giving KDE 3.2beta2 a big hard testing, and so far Konqueror starts up in fractions of a second and renders most pages almost instantly. KMail opens almost as fast, is able to open mailboxes with over 36,000 messages in one second or so. KNode starts up almost instantly. Same for about all the apps I've tested so far, in fact -- they're really surprisingly fast.
In fact, they're much faster than many a standalone app (Mozilla, etc), counterintuitive as it may seem. I have a feeling this may be due to their noted good organisation and code reuse, but a deeper study of just how they managed it would certainly be interesting, as other notoriously slow projects (I'm thinking Open Office here) may wish to learn from them.
Note, I've not prelink'ed it yet. I hear it allows to divide startup times by up to a factor of two. We'll see, but I doubt it can become much faster than it already is, honestly.
> Answer yes/no
- Answer No.
- Choose again.
- Choose the SAME one.
- Get new printout.
- Repeat.
[...]
- Stuff N printouts into audit box.
The day after, call for printout recount.
Boom, profit.
What is so hard? Designing a reliable system is, obviously.
Not fun, I know.
For burning anything (audio CDs, data CDs, mixed CDs, DVDs, eMovix projects...) K3b is king. Never found a better burning frontend (including on Windows).
Don't worry about burning stuff under Linux, that problem seems solved for the time being, which is way cool.
> One of the articles you presented was an exposition of the
> difference between writing for GTK in C and Python and Qt in C++.
> It seemed a little apples-and-oranges, since nice C++ interfaces
> are available for GNOME.
Maybe it -seemed-, yep. Unfortunately, it -is- not, as clearly expressed in another of the articles I presented, that from a Rosegarden developper, written after he switched to Qt/KDE from GTK/GNOME-with-C++. Interestingly, you'll note that the GTKmm maintainers didn't understand either how Qt/KDE in particular made his life a lot easier.
Besides, I still have more articles to link to -- I've been studying that precise issue for quite some time now, you know, and ressources on that matter don't lack. Although I fully understand why you wouldn't want to hear that... Apparently, from the way our minds work, emotional reactions have a lower interrupt level than what philosophers like to call our higher functions, which, frankly, sucks. (Which is why I tried to thoroughly study the depth of -both- desktop environments before I cared either way, if you want to know.)
> If you want to talk about the proprietary companies on GUIs, you
> might consider that HP and Sun do that on GNOME. Even on their
> Unix platforms.
I know, yes. However, and even though for each of these two you could prolly quote as many or twice as many other companies using the other desktop API, there's another reason still why Sun and HP are a subtly, but importantly different matter, I think.
They're selling desktops for OTHER people to develop on. It's -their- best interest to make the offer look as cheap as possible, and then let the customers deal with the (possible) costs of additional development times. Which is exactly what they should be doing, of course. That's what MS does as well, and it works great, commercially speaking.
Besides, you'll note that both Sun and HP are large corporations with money to spare, making them not the best example one could pick when talking about which choice is less costly, I think.
> One of the things I'd like to go for is the principle of least surprise.
I totally agree with you on this! Not on your conclusion, however.
In terms of development, the principle of least surprise would have it that development tools are paid for separately. Sometimes much expensively.
This, frankly, sucks. But that's the principle of least surprise for you, though, I suppose...
The best situtation would be to be able to develop either way without fixed costs, of course. As another poster suggested, the best thing that could happen to the Linux desktop would be if someone like IBM bought off Qt and LGPL'ed it. However, until then, people for whom money isn't a commodity will pick the least costly choice. That's the way this world works, unfortunately. I wish it was otherwise, you can believe me.
Wicked! I get to catch no other than Bruce Perens himself posting a sizeable but subtle fallacy. I suppose that I get to really feel cool now, in a geeky sort of way. Anyway. Apologies, Bruce, for I strongly doubt you did it on purpose, but here it goes!
/. geek points.
> One nice thing about GNOME is that a commercial license is not
> necessary to write and distribute a proprietary GNOME application.
*clears throat*
"One nice thing about paper and pencils is that a pricy PC is not necessary to design and write loads of code."
I mean this seriously, and this says nothing either for or against paper and pencils as opposed to computers.
Only, well, in both cases, the right tool will simply save enough time to make the cost well worth it.
And before some excited kid mods me down for daring to disagree with Bruce, let me tell you that if you've never used paper and pencil to design a piece of code you just thought up where no computer was at hand, you don't deserve your
Different tools work well in different circumstances, that's all. Deal.
And in this specific case, it is not unlikely there's a reason why one of the Linux desktop environments has more proprietary companies developping for it than the others.
Food for thought, I hope.
(Having karma to spare is a nifty thing, you get to speak plainly and maybe get people to think. That's way cool.)
Bali out.
Here.
I hear you can get a native, Trolltech-provided Qt 3.2 Windows free edition on the CD-ROM that comes with the upcoming re-edition of the Qt book, too, if you can't want for the above project to reach completion.
Otherwise, a decent alternative is wxWindows (not as clean and elegant as Qt, and thus requires a bit more code for a given task, but still very decent, don't worry).
Thank you.
Grand-parent post doesn't hold MS to fault for the flaw itself, but for boasting about its supposedly 'more secure' FS. Which is, as you aptly demonstrate, mostly irrelevant to actual security.
> Why making things more complicated instead of making them
> simplier?
Ever tried to code against the Gnome API, and especially the integration features (bonobo et al)? Do give it a try.
I fear it's MUCH too late to make it simple.
So instead they monetize it. Interesting idea. Whatever works, I suppose...
But I'm not really sure what to think of it, honestly. That'd they'd have to involve money to have things that SHOULD be simple get done... But then, what do I know, maybe that's where open source is headed, I don't know.
Based on those links, you sure have a strange definition of 'anyone'...
> GNOME uses the standard GTK dialogs for file selection (file save
> and file open), instead of putting a GNOME layer over GTK for
> those, specifically to avoid bloat.
This wouldn't be bloat if all Gnome programs shared the file dialog code. Even less so if the Gnome file dialog inherited from the GTK file dialog... but then, GTK makes reusability by inheritance a bit complicated, granted.
> I'm not sure what you mean about Nautilus being custom code;
See EEL (Eazel Extension Library). It's -not meant- to be used outside Nautilus. But you effectively get somewhat cool effects, at the cost of a little more bloat. That's not inherently a bad thing! The KDE development model seems to prefer adding capabilities to the core API, and -then- let apps use it, which is why it takes them more time to add cool effects I think (but it's also why when the effects are available, their use spreads through KDE apps much faster).
Different models, etc. Choice is cool.