BGB <[email protected]> writes: > it is sad, in premise, that hard-coded Visual Studio projects, and raw > Makefiles, are often easier to get to work when things don't go "just > right". well, that and one time recently managing to apparently get on > the bad side of some developers for a FOSS GPL project, by going and > building part of it using MSVC (for plugging some functionality into > the app), but in this case, it was the path of least effort (the other > code I was using with it was already being built with MSVC, and I > couldn't get the main project to rebuild from source via the > "approved" routes anyways, ...). > > weirder yet, some of the better development experiences I have had > have been in developing extensions for closed-source commercial > projects (without any ability to see their source-code, or for that > matter, even worthwhile API documentation), which "should not be".
This is probably an artifact of using Windows (I assume you're using Windows, since you mention Windows-related programs). Unfortunately building GNU-style stuff on Windows is usually an edge case; many *NIX systems use source-level packages (ports, emerge, etc.) which forces developers to make their stuff build on *NIX. If a GNU-style project even works on Windows at all, most people will be grabbing a pre-built binary (programs as executables, libraries as DLLs bundled with whatever needs them). It's probably a cultural thing too; you find GNU-style projects awkward on your Microsoft OS, I find Microsoft-style projects awkward on my GNU OS. > granted, it would also require an shift in focus: > rather than an application being simply a user of APIs and resources, > it would instead need to be a "provider" of an interface for other > components to reuse parts of its functionality and APIs, ideally with > some decoupling such that neither the component nor the application > need to be directly aware of each other. Sounds a lot like Web applications. I've noticed many projects using locally-hosted Web pages as their UI; especially with languages like Haskell where processing HTTP streams and automatically generating Javascript fits the language's style more closely than wrapping an OOP UI toolkit like GTK. > sort of like codecs on Windows: you don't have to go write a plugin > for every app that uses media (or, worse, hack on their code), nor > does every media player or video-editing program have to be aware of > every possible codec or media container format, they seemingly, "just > work", you install the appropriate drivers and it is done. > > the GNU-land answer more tends to be "we have FFmpeg / libavcodec and > VLC Media Player", then lots of stuff is built by building lots of > things on top of these, which isn't quite the same thing (you need to > deal with one or both to add a new codec, hacking code into and > rebuilding libavcodec, or modifying or plugging into VLC to add > support, ...). Windows tends to be "we have DirectFoo", then lots of stuff is built by building lots of things on top of these ;) Note that there are projects like GStreamer which are designed to be unified interfaces to libavcodec/ffmpeg/etc; however, they seem to have limitations since there are now meta-interfaces like Phonon which sit on top of GStreamer/VLC/mplayer! Reminds me of the datatypes system in AmigaOS, which was a mechanism for handling arbitrary file types. The floppy disks/CDs attached to magazines usually contained a bunch of these (eg. PNG, GIF, etc.) which could be dragged into the Workbench:Datatypes drawer and existing programs would magically be able to access files of those types. Well, that was the theory; many applications ended up bypassing the system, probably due to lowest-common-denominator effects (ie. generic access to "images" provides very little control over each particular format's features). I've only started programming since being on Linux, so that's pure speculation on my part. Would serve as another example of environment-provided features which become too limiting for applications, just like filesystems' embedded metadata. Cheers, Chris _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
