• "H. S. Teoh" <hsteoh quickfur.ath.cx> Sep 25 2012

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

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
 and


 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.