www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: [OT] Was: totally satisfied :D

On Wed, Sep 26, 2012 at 12:56:14AM +0200, Adam D. Ruppe wrote:
 On Tuesday, 25 September 2012 at 22:49:36 UTC, H. S. Teoh wrote:
I must've been half-asleep when I wrote that. I meant a
mail-handling library that can handle MIME attachments.

I did a simple one a while ago. Jush pushed to github: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/fd7bfd5c250901a8c546b502772f18fe019ed7e9/email.d Nothing really special, but it works for what I've tried with it so far. I need to do a parser soon too, to replace my current indexOf hacks in my mail reading apps. Eh, I'll get around to it eventually.

Cool, I'll have to look into that sometime. On Tue, Sep 25, 2012 at 08:19:00PM -0400, Nick Sabalausky wrote:
 On Tue, 25 Sep 2012 15:52:09 -0700
 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote:
 On Tue, Sep 25, 2012 at 05:36:48PM -0400, Nick Sabalausky wrote:
 Newer Operas also got rid of the "native-ish" theme, which is why
 I'm not upgrading past v10. It may seem trivial, but skinned apps
 *really* bug me.

Skinned apps don't bug me at all. I tend to like apps where you can delete useless buttons off the UI and turn off toolbars and stuff you never use. As well as configure custom keyboard bindings

That's not really skinned, that just simply customizable (which I agree is good). What I mean by "skinned" is "Blatantly disregards my system settings and poorly re-invents all the standard UI controls." Often that's done so that users like me can re-skin it to make it look and act like *anything* we want...*except* for native and "consistent with the rest of the fucking system".

Ah I see. Reminds me of early versions of Java Swing. :-P I remember playing around with it and being utterly aghast at the incongruous appearance of my app. Nowadays, though, I couldn't care less... ratpoison maximizes everything anyway and has no overlapping windows, so I can hardly tell the difference. :) [...]
 What I'd _really_ like, is browser *library*, where you get to
 assemble your own browser from premade parts.

A "web browser control" is pretty common, AIUI. I know IE and WebKit can be used as controls that you just plop into a window. Then you have to add in all the bells and whistles like address bar, bookmarking, etc., which all still adds up to a lot of extra work, though.

No no, that's still part of the monolithic system. I find that kinda silly, actually. It's a system that lets the user to illogical things like put the "forward" button to the left of the "back" button followed by the "next" button with "rewind" interspersed between them. It gives you the illusion of control, but hides the fact that you still can't do things like rip out the entire dang UI and sticking a totally new one in its place.
 Like replace the lousy UI front end with a custom interface.
 Applications nowadays suffer from excessive unnecessary integration.
 Software should be made reusable, dammit. And I don't mean just code
 reuse on the level of functions. I mean entire software systems that
 are pluggable and inter-connectible. If there's a browser that has a
 good back-end renderer but lousy UI, it should be possible to rip
 out the UI part and substitute it with the UI of another browser
 that has a better UI but lousy back-end. And if there's a browser
 that comes with unnecessary bloat like a mail app, it should be
 possible to outright _delete_ the mail component off the HD and have
 just the browser part working. Software these days is just so
 monolithic and clumsy. We need a new paradigm.

More like "need an old paradigm" because it sounds like you're describing the Unix philosophy ;) I'm with you though, that would be nice.

Haha, to that I'll have to pull out this quote: Those who don't understand Unix are condemned to reinvent it, poorly. :) But on a more serious note, *all* programs should be written as though they're intended for a library. The frontend, be it main() or whatever the toolkit substitute for it is, should just be wrappers that call the library functions. The key idea behind this is automation and scripting, which is something sorely lacking in GUI-centric applications. To me, it is stupid that just because a program that solves problem P with algorithm X comes with a GUI, you're stuck with having to use the badly-designed GUI instead of just plugging into algorithm X directly. The whole point of the program is to solve problem P, so X should be in a library that you can call directly from an external program without having to jump through GUI hoops just to get at it. I mean, this is just basic computer science. It's function composition. Something that most software of today seems to have forgotten. [...]
 The result is that people revert to using table-based formatting

Hey, I *like* table-based formatting :). Beats the hell out of trying to kluge together sane layouts/flowing with CSS. And nobody's ever going to convince me that HTML isn't the presentation layer.

I say trash it all, tables, HTML, everything. Markdown is good enough for email. If you need more than that, go buy a real website and post it there instead of transmitting that crap over SMTP.

Well, I just meant on the web, not email. Death to HTML emails!

LOL... If I had my way, the web would be formatted with LaTeX (or equivalent) instead of that crappy HTML+CSS+JS which makes it so easy for clueless people to create webpages that make your eyes bleed. HTML was never intended to be used for the kinds of stuff people use it for these days, and while CSS has some nice points, it's also insufficient to express some basic page layout concepts, which necessitates hacks to make things appear the way you want it to. Yes the hacks are clever, but a complete and consistent layout language shouldn't need hacks to express basic layout concepts. Like an explicit horizontal centering for containers that doesn't need half a dozen different shenanigans with auto margins and padding and text-align and what-not to accomplish. Or basic container alignment between two elements that aren't immediate siblings. Or a true fluid layout that doesn't require hard-coding to specific browser resolutions (like seriously... you'd have thought CSS should've obsoleted that, but no, it's still happening). Ad nauseum. T -- Those who don't understand Unix are condemned to reinvent it, poorly.
Sep 25 2012