Supporting Exchange 5.5 would require a complete DCOM implementation, as well as an understanding of the MAPI protcols.
In short, it's a LOT of work. So much work, in fact, that the investment probably wouldn't be easily recouped. As many places are upgrading anyway, I can see why they don't want to support it.
OTOH it is open source. Perhaps once Wine gets full DCOM support, it will be possible. But by the time that happens, truly nobody will use Exchange 5.5 any more at all:(
If websites start designing for features found in IE7, large groups of people will be left behind.
They won't do that until the majority actually use IE7. How many apps do you know that require Windows XP? Hell, how many even require an NT based OS?
Not many. They've been around for years! The same thing is true of websites - if it comes down to asking people to upgrade their OS and alienating them in the process, or using some gee-whiz feature, they will choose backwards compat every time.
What really interests me is the idea that at some point in the future, the idea of targeting Konqueror will begin to begin to look increasingly attractive.
I don't think that will happen for a long long time, if ever.
After all, there are a nontrivial amount of web designers who use the mac.
Don't kid yourself. Market areas vary, but not that much. Most web work is still carried out on a PC, in order to work with Internet Explorer, which is what the users use. The Mac market share is still only 2% or lower, even if the majority of them are web designers (which I'd be surprised about), it's still mostly insignificant. I have a friend who uses a Mac (but he has done for a very long time now). Whenever he does web design work, he has to get me to test it out in IE (i run it under wine). Of course, it never works because he uses InDesign or something stupid to design his web pages, so the markup is full of crud that only looks right on his box, at his screen resolution. He doesn't know much about CSS, so it normally takes most of the evening (or several) to sort it out. Very few people are willing to screw about like that, especially not in business.
You appear to have overlooked the fact that there is no KHTML based browser on Konqueror. It relies heavily upon Qt, which is available under a free license only on X11 and now the Mac.
The Windows version of Qt is still what makes TrollTech most of their money. They have no incentive to release it.
The KWQ stub library that Apple used to make Safari without paying Qt developer costs is written in Objective C++ (i kid you not), and is tied to Cocoa. Cocoa of course is a proprietary set of APIs, which are not portable.
As such, if anything other than IE6 is going be targetted anytime soon by the masses (not likely) it'll be Gecko, as that is what people have access to, and it's available on every platform, and (at least on Linux and Windows) it's the most popular 2nd place browser.
What makes you think that if 95% of people used Macs, it'd be any different.
If Safari comes set up "out the box", why would anybody except the few who care enough to do browser market research use anything else?
From what I know, Mac IE actually did a better job of rendering web pages than Safari does now. What if we were all cheering Microsoft on, and wishing that stupid users would realise that just because MacIE is not brushed metal, doesn't mean it's bad.
I mean, I don't get how people can trash Microsoft then in the same breath wish that everybody used MacOS. We'd be in exactly the same boat now even if history was reversed. It'd be just s/IE/Safari/.
Apple patents everything they can imaginably think of, right down to the skins on their OSes, and they never use a single one of these patents.
Define "use", because thanks to Apples patents, the open source community has had to work around TrueType bytecode interpreting, and can't use spring loaded folders.
Here's an analogy. Say you live on an island of vegetarians. You do happen to have your own land, and decide to raise pigs. That's fine and dandy, until you need to sell your pigs to pay the bills.
Who said you had to sell the pigs to pay your bills?
What's wrong with making yourself useful around the island, perhaps fixing up that fallen down tree over there, and earning your keep that way? You get to raise your pigs, and still have money.
The analogy is extremely stretched, but what I mean is that you don't have to make your salary from selling software. You can also make it by performing services for those who are willing to pay. In fact, that's how most of us make our money.
I think he's ignoring something even more fundamental: OSS locks you into the same moving-target APIs and environments. Be it libc5/glibc, QT, Gnome, KDE, or any other substantial "farm", things are going to change beyond your control. Bugs are going to get fixed in newer versions, while your older library version is ignored by the developers.
I think you'd have a hard time claiming that you were seriously "locked in" to any Linux APIs. Glibc is based on the POSIX standards, with a bit of work it's possible to use many other libcs (though as it's free software you can always change whatever it is that you want). The GUI level libraries are likewise either free software, or based on open standards, or both (X for instance). You are always free to backport fixes to the version you're using, if you don't want to upgrade.
The grass is always greener on the other side. If you were working with Linux, you'd be complaining about the boring things and obnoxious "features" there, too.
Sure. I get paid to hack Wine at the moment, or rather, make an app work on Linux using it. Some days it's pretty boring. I don't think I'd want to be screwing about with web apps though....
Isn't that true of *any* solid server OS? If you get it set up correctly then leave it, most machines will run until the hardware dies.
I personally don't know many real Linux production servers (as opposed to bobs personal box) where the admins mess with kernel patches - ever. They normally use a stable distro, normally Debian or one of the older Red Hats, and just leave it.
We're talking about generics here, it's fairly trivial to make updating the database automatic. Then it's just a case of "sudo apt-get install foo", or whatever. And yes, I know it can be improved upon, but the basic concept allows for installation with very little effort.
On Linux at any rate, virtually an program that uses glade, or loads data files/artwork from an external file, will have paths hard coded into it by the C preprocessor at build time. Removing these hardcodings is a royal pain in the ass.
I'm hoping once we get a nice API and strong implementation projects will begin to deprefix their software with our library.
I don't agree. To install software on a Mac, you have to:
1) Open up your web browser
2) Find it on the web.
3) Download the DMG
4) Open the DMG (i know safari does that for you, good usability that, magic self destructing folderfiles)
5) Decide - is the icon an AppFolder, or an installer? Installers are rather common on MacOS these days, primarily because a pure appfolders system is too limited.
5a) If it's an AppFolder, open up the finder
5b) Navigate to Applications
5c) Drag and drop the appfolder in
At this point, there is no system integration (file associations), and multi-user control is questionable.
6a) If it's an installer, run it, and hope things work well.
Now is that truly easier than:
1) Open a terminal
2) Type in the name of the software you want
3) Run it.
.. at which point you have good system integration, with internationalized, self organising menus.
Well. Is it easier? I don't think so. The Mac way is more work for users, it's more limiting for developers.
The main problems with the Linux way are that it's not always that easy, and when it is, it's still not got an intuitive GUI (synaptic is too confusing really). Well, there are solutions to both of those, and people working on them.
Bear in mind that "installation" as a process can be entirely abstracted by a good user interface. It can be as simple as drag and drop, but WITH all the benefits of a strong packaging system.
Believe me. If all goes according to plan, Linux is going to end up with the most kickass software installation system the world as ever seen. It's going to rock. I can hardly wait:)
My project is working on a library that will allow programs to find out where they are installed to. At the moment it's fairly crude, and needs to be improved, but volunteers are required:)
I'd note that libprefix(db) is not so users can pointlessly drag icons around all day and mess about with filing system structures in the process. It's so you can install to peoples home directories, or/opt, or/usr, or/usr/local, or perhaps a path on another mounted drive. Having relocatable programs is just convenient.
I would have posted this yesterday, but slashcode was up the wazoo.
xpdf uses a strange toolkit (motif?), which looks ugly. It's also unintuitive - left clicking drags a selection rectangle that selects.... what? Not text. Bitmap? Not sure. To move the area with the mouse, you have to use the middle button.
GGV would be great, but despite the "use antialiasing" checkbox being ticked, it doesn't use it (not here anyway). For most apps (like emacs) that's OK, but for some reason ghostview renders text horribly without AA enabled. It also tends to give me errors about GConf typing and such. It doesn't support all the PDF features, like bookmarks/content pane.
AcroRead doesn't even bother trying to integrate. It uses the same on disk layout as on Windows, and also uses Motif, making it butt ugly as well as having a file open dialog box that doesn't even pay attention to the dotfile rules.
I should probably have qualified my original post with this stuff, but now you know. So far, my quest for a PDF viewer that is feature compatible, renders as nicely and integrates as well as AcroRead on Windows does is not yet complete.
b) It can work with C and C++, which are the most common languages (on Linux at any rate) today, whereas for instance Ant is tied to Java.
c) Python is a widely known and easy to learn language.
d) They have great documentation.
I've already encountered several projects pondering moving up the "next level" in tools, ie Subversion with some new build system (usually scons). At some point, one of the new systems has to stick, and I think this one might just be it.
I'm not exactly sure what the original problem was that motivated autoconf, but autoconf and libtool cause me many many many problems on non-Linux platforms.
Nothing is perfect. Autoconf was built, essentially, to abstract imperfection from the developer.
Read up on its history, it's in the info pages. Back when Linux was a nothing, people wanted free software to compile on pretty much any machine they could. They all varied in obscure ways, some had features others did not and so on. Before autoconf, people spent a long time writing their own configuration scripts. Autoconf, which automated the process and provided libraries of high quality scripts (relative to peoples home made ones), was a godsend. The reason it uses m4 by the way is that unfortunately, shell functions did not fall into the lowest common denominator of features that all UNIXen were guaranteed to have.
Now, we have scons. Scons, from what I've seen, is good. I'm still not entirely convinced that Python is the best syntax for describing a build system, but I'll withhold true judgement until I've tried it.
It probably addresses different needs. Today, being able to build on obscure deceased form of UNIX A is arguably less important than having an easy to use build system for 99.99% of the users who are on Linux or one of the BSDs. Windows users often put their own build system in when porting, so that isn't a big deal.
I know that scanline of PicoGUI fame has been playing with a sparkly new build system based on scons and some other stuff, that looks very nifty indeed. It'll be interesting to see if scons, pgbuild and the rest eventually take over from autotools.
.NET is going to be used heavily for Windows desktop apps anyway. People will use it, and love it.
The fact is that Win32 is a steaming cowpat of an API. This is rammed through my head time and time again whenever I am forced to use it. It has some of the most braindamaged behaviours in the world - it's so bad that practically nobody uses it in fact. It's kind of sad, but it's not really possible to write Windows programs without a (usually expensive) IDE and wrapper library to help you.
Well,.NET is mostly just Microsoft creating yet another wrapper, albiet one that doesn't suck quite as much as their previous attempts did. That's just as well, perhaps one day the sheer hell of Win32 will be banished forever, much the same way that nobody pokes the BIOS anymore to print stuff to the screen. To be honest, I think that'll happen more because of Linux than.NET replacing Win32 entirely, but only time will tell.
Other useful tools are logger from the Windows Debugging Toolkit, which records every API call made, with details of the structures used and so on. Another good technique is to run the app in Wine, which gives you a very high level of debug output which is a rich source of data.
Dude, that's a thin line you're walking there. If Google had paid you for that stuff then ANY website that needed a bit of extra funding and had a loyal base of visitors (there are plenty) could just "encourage" people to click on the link. Of course it's not fraud, but it is, hmm, milking? Google so I can understand why they might not like that.
OK. Transparent Windows require driver breakage (ie drivers have to be altered), so it's been put off until XFree 5. Luckily, XFree 5 is the next release, and transparent windows are explicitly on the TODO list. Unluckily, it's not been that long since 4.3, and XFree has a long release cycle. Check back next year?
Re:Great, another GTK appearance option (long).
on
Menu Shadows in GTK2
·
· Score: 2, Interesting
Somebody was working on a colour theme control applet for Gnome2, but I haven't heard anything about it for a while.
There isn't really great demand for it. If you want consistancy in your desktop, you're already using BlueCurve/Galaxy/Geramik etc, which do colours for you.
Setting GTKs colours, themes, fonts and so on should be done via XSETTINGS. Unfortunately the lack of a standardised colour format prevents this from happening currently, believe me, I'd like it too as then Wine and KDE could sync to *my* colours. But it's not done yet. Volunteers, as ever, are welcome.
Slashdot Mirror
In short, it's a LOT of work. So much work, in fact, that the investment probably wouldn't be easily recouped. As many places are upgrading anyway, I can see why they don't want to support it.
OTOH it is open source. Perhaps once Wine gets full DCOM support, it will be possible. But by the time that happens, truly nobody will use Exchange 5.5 any more at all :(
Try Evo 1.4 - that's based on GTK2, which uses Pango, which has lots of international characters/unicode support goodness.
Variations of that post have been appearing in pretty much every slightly hardware related story for days now. Just ignore it, it'll go away.
SGI boxes are remarkably versatile. You should ponder this before claiming that a PowerMac "can" (can what?)
They won't do that until the majority actually use IE7. How many apps do you know that require Windows XP? Hell, how many even require an NT based OS?
Not many. They've been around for years! The same thing is true of websites - if it comes down to asking people to upgrade their OS and alienating them in the process, or using some gee-whiz feature, they will choose backwards compat every time.
I don't think that will happen for a long long time, if ever.
After all, there are a nontrivial amount of web designers who use the mac.
Don't kid yourself. Market areas vary, but not that much. Most web work is still carried out on a PC, in order to work with Internet Explorer, which is what the users use. The Mac market share is still only 2% or lower, even if the majority of them are web designers (which I'd be surprised about), it's still mostly insignificant. I have a friend who uses a Mac (but he has done for a very long time now). Whenever he does web design work, he has to get me to test it out in IE (i run it under wine). Of course, it never works because he uses InDesign or something stupid to design his web pages, so the markup is full of crud that only looks right on his box, at his screen resolution. He doesn't know much about CSS, so it normally takes most of the evening (or several) to sort it out. Very few people are willing to screw about like that, especially not in business.
You appear to have overlooked the fact that there is no KHTML based browser on Konqueror. It relies heavily upon Qt, which is available under a free license only on X11 and now the Mac.
The Windows version of Qt is still what makes TrollTech most of their money. They have no incentive to release it.
The KWQ stub library that Apple used to make Safari without paying Qt developer costs is written in Objective C++ (i kid you not), and is tied to Cocoa. Cocoa of course is a proprietary set of APIs, which are not portable.
As such, if anything other than IE6 is going be targetted anytime soon by the masses (not likely) it'll be Gecko, as that is what people have access to, and it's available on every platform, and (at least on Linux and Windows) it's the most popular 2nd place browser.
If Safari comes set up "out the box", why would anybody except the few who care enough to do browser market research use anything else?
From what I know, Mac IE actually did a better job of rendering web pages than Safari does now. What if we were all cheering Microsoft on, and wishing that stupid users would realise that just because MacIE is not brushed metal, doesn't mean it's bad.
I mean, I don't get how people can trash Microsoft then in the same breath wish that everybody used MacOS. We'd be in exactly the same boat now even if history was reversed. It'd be just s/IE/Safari/.
Define "use", because thanks to Apples patents, the open source community has had to work around TrueType bytecode interpreting, and can't use spring loaded folders.
I'd say they very much use their patents.
Who said you had to sell the pigs to pay your bills?
What's wrong with making yourself useful around the island, perhaps fixing up that fallen down tree over there, and earning your keep that way? You get to raise your pigs, and still have money.
The analogy is extremely stretched, but what I mean is that you don't have to make your salary from selling software. You can also make it by performing services for those who are willing to pay. In fact, that's how most of us make our money.
I think you'd have a hard time claiming that you were seriously "locked in" to any Linux APIs. Glibc is based on the POSIX standards, with a bit of work it's possible to use many other libcs (though as it's free software you can always change whatever it is that you want). The GUI level libraries are likewise either free software, or based on open standards, or both (X for instance). You are always free to backport fixes to the version you're using, if you don't want to upgrade.
The grass is always greener on the other side. If you were working with Linux, you'd be complaining about the boring things and obnoxious "features" there, too.
Sure. I get paid to hack Wine at the moment, or rather, make an app work on Linux using it. Some days it's pretty boring. I don't think I'd want to be screwing about with web apps though....
I personally don't know many real Linux production servers (as opposed to bobs personal box) where the admins mess with kernel patches - ever. They normally use a stable distro, normally Debian or one of the older Red Hats, and just leave it.
We're talking about generics here, it's fairly trivial to make updating the database automatic. Then it's just a case of "sudo apt-get install foo", or whatever. And yes, I know it can be improved upon, but the basic concept allows for installation with very little effort.
On Linux at any rate, virtually an program that uses glade, or loads data files/artwork from an external file, will have paths hard coded into it by the C preprocessor at build time. Removing these hardcodings is a royal pain in the ass.
I'm hoping once we get a nice API and strong implementation projects will begin to deprefix their software with our library.
1) Open up your web browser
2) Find it on the web.
3) Download the DMG
4) Open the DMG (i know safari does that for you, good usability that, magic self destructing folderfiles)
5) Decide - is the icon an AppFolder, or an installer? Installers are rather common on MacOS these days, primarily because a pure appfolders system is too limited.
5a) If it's an AppFolder, open up the finder
5b) Navigate to Applications
5c) Drag and drop the appfolder in
At this point, there is no system integration (file associations), and multi-user control is questionable.
6a) If it's an installer, run it, and hope things work well.
Now is that truly easier than:
1) Open a terminal
2) Type in the name of the software you want
3) Run it.
Well. Is it easier? I don't think so. The Mac way is more work for users, it's more limiting for developers.
The main problems with the Linux way are that it's not always that easy, and when it is, it's still not got an intuitive GUI (synaptic is too confusing really). Well, there are solutions to both of those, and people working on them.
Bear in mind that "installation" as a process can be entirely abstracted by a good user interface. It can be as simple as drag and drop, but WITH all the benefits of a strong packaging system.
Believe me. If all goes according to plan, Linux is going to end up with the most kickass software installation system the world as ever seen. It's going to rock. I can hardly wait :)
I'd note that libprefix(db) is not so users can pointlessly drag icons around all day and mess about with filing system structures in the process. It's so you can install to peoples home directories, or /opt, or /usr, or /usr/local, or perhaps a path on another mounted drive. Having relocatable programs is just convenient.
xpdf uses a strange toolkit (motif?), which looks ugly. It's also unintuitive - left clicking drags a selection rectangle that selects.... what? Not text. Bitmap? Not sure. To move the area with the mouse, you have to use the middle button.
GGV would be great, but despite the "use antialiasing" checkbox being ticked, it doesn't use it (not here anyway). For most apps (like emacs) that's OK, but for some reason ghostview renders text horribly without AA enabled. It also tends to give me errors about GConf typing and such. It doesn't support all the PDF features, like bookmarks/content pane.
AcroRead doesn't even bother trying to integrate. It uses the same on disk layout as on Windows, and also uses Motif, making it butt ugly as well as having a file open dialog box that doesn't even pay attention to the dotfile rules.
I should probably have qualified my original post with this stuff, but now you know. So far, my quest for a PDF viewer that is feature compatible, renders as nicely and integrates as well as AcroRead on Windows does is not yet complete.
a) It is 100% free software, unlike, say, Jam
b) It can work with C and C++, which are the most common languages (on Linux at any rate) today, whereas for instance Ant is tied to Java.
c) Python is a widely known and easy to learn language.
d) They have great documentation.
I've already encountered several projects pondering moving up the "next level" in tools, ie Subversion with some new build system (usually scons). At some point, one of the new systems has to stick, and I think this one might just be it.
Nothing is perfect. Autoconf was built, essentially, to abstract imperfection from the developer.
Read up on its history, it's in the info pages. Back when Linux was a nothing, people wanted free software to compile on pretty much any machine they could. They all varied in obscure ways, some had features others did not and so on. Before autoconf, people spent a long time writing their own configuration scripts. Autoconf, which automated the process and provided libraries of high quality scripts (relative to peoples home made ones), was a godsend. The reason it uses m4 by the way is that unfortunately, shell functions did not fall into the lowest common denominator of features that all UNIXen were guaranteed to have.
Now, we have scons. Scons, from what I've seen, is good. I'm still not entirely convinced that Python is the best syntax for describing a build system, but I'll withhold true judgement until I've tried it.
It probably addresses different needs. Today, being able to build on obscure deceased form of UNIX A is arguably less important than having an easy to use build system for 99.99% of the users who are on Linux or one of the BSDs. Windows users often put their own build system in when porting, so that isn't a big deal.
I know that scanline of PicoGUI fame has been playing with a sparkly new build system based on scons and some other stuff, that looks very nifty indeed. It'll be interesting to see if scons, pgbuild and the rest eventually take over from autotools.
Good plan. Publish the report in a format for which there are precious few good viewers available on Linux. What's wrong with good old HTML?
You appear to have missed the 2nd page, which has an interview with the people behind it.
The fact is that Win32 is a steaming cowpat of an API. This is rammed through my head time and time again whenever I am forced to use it. It has some of the most braindamaged behaviours in the world - it's so bad that practically nobody uses it in fact. It's kind of sad, but it's not really possible to write Windows programs without a (usually expensive) IDE and wrapper library to help you.
Well, .NET is mostly just Microsoft creating yet another wrapper, albiet one that doesn't suck quite as much as their previous attempts did. That's just as well, perhaps one day the sheer hell of Win32 will be banished forever, much the same way that nobody pokes the BIOS anymore to print stuff to the screen. To be honest, I think that'll happen more because of Linux than .NET replacing Win32 entirely, but only time will tell.
Other useful tools are logger from the Windows Debugging Toolkit, which records every API call made, with details of the structures used and so on. Another good technique is to run the app in Wine, which gives you a very high level of debug output which is a rich source of data.
Dude, that's a thin line you're walking there. If Google had paid you for that stuff then ANY website that needed a bit of extra funding and had a loyal base of visitors (there are plenty) could just "encourage" people to click on the link. Of course it's not fraud, but it is, hmm, milking? Google so I can understand why they might not like that.
OK. Transparent Windows require driver breakage (ie drivers have to be altered), so it's been put off until XFree 5. Luckily, XFree 5 is the next release, and transparent windows are explicitly on the TODO list. Unluckily, it's not been that long since 4.3, and XFree has a long release cycle. Check back next year?
There isn't really great demand for it. If you want consistancy in your desktop, you're already using BlueCurve/Galaxy/Geramik etc, which do colours for you.
Setting GTKs colours, themes, fonts and so on should be done via XSETTINGS. Unfortunately the lack of a standardised colour format prevents this from happening currently, believe me, I'd like it too as then Wine and KDE could sync to *my* colours. But it's not done yet. Volunteers, as ever, are welcome.