On Tue, Sep 25, 2012 at 06:59:55PM -0400, Nick Sabalausky wrote: [...]
> > There is a general assumption by many applications/websites that *everyone* uses facebook.
> 
> I know! And it's not just software, it's all business in general. They noticed that it's popular so they think that means "nearly everyone uses it" when the reality is that even as popular as it is, it's still only a *minority* of internet users. Same with twitter.

Huh. I must've been living in a cave. Last I heard, facebook must've hit 90% market saturation, 'cos *everyone* I know has facebook (or pretty close to everyone). I'm not among the 90%, though, and never intend to be. :)

Usually when I run into a website that asks for facebook login, I hit ctrl-W by instinct and don't even flinch. When I run into an app that asks for facebook login, 99% of the time I just delete it without thinking twice.  And it's not just facebook, it's anything that *requires* signing up for some kind of social networking site. Making it an option is OK, I don't care if other people want to post their latest Doodle Jump score to their stream of inanity, all power to them, but *requiring* it to use an app that doesn't logically need it? Plonk. Nagging me about it after I said no the first time? Plonk.


[...]
> > Besides, my wife is on facebook, and if any important news happens via FB, she'll tell me :)
> > 
> 
> Heh. Similar situation here. My brother and sister are both on it, so I'll catch wind of any family news from FB. My parents, like me, aren't on FB either so they get the same benefit, too, although they usually hear much sooner I do ;)

Me too. My wife has FB, and that's good enough for me.

Sad to say, though, I got suckered into signing up for Google+. Every now and then (like once a month or less) I post something, but mostly I don't even bother logging on. Most of the stuff on it is pretty inane anyway. Y'know, your typical "what I ate for breakfast", "how many hairs fell into my bathroom sink this morning" and other such content-free posts that are a total waste of time to read. There *are* times when it's useful, like when you're going abroad and have friends who can let you crash in their place for a night or two -- but generally speaking, the signal-to-noise ratio is very low.


T

-- 
That's not a bug; that's a feature!

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".


> 
> > I find the UIs in the FF4-onward to be completely intolerable. Even FF3's UI was god-awful, and then they managed to make it worse with 4 by going all "Chrome-envy".
> 
> 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.

> 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.

> 
> [...]
> > > 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!

On Tue, 25 Sep 2012 16:24:14 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Tue, Sep 25, 2012 at 06:59:55PM -0400, Nick Sabalausky wrote: [...]
> > > There is a general assumption by many applications/websites that *everyone* uses facebook.
> > 
> > I know! And it's not just software, it's all business in general. They noticed that it's popular so they think that means "nearly everyone uses it" when the reality is that even as popular as it is, it's still only a *minority* of internet users. Same with twitter.
> 
> Huh. I must've been living in a cave. Last I heard, facebook must've hit 90% market saturation, 'cos *everyone* I know has facebook (or pretty close to everyone). I'm not among the 90%, though, and never intend to be. :)
> 
> Usually when I run into a website that asks for facebook login, I hit ctrl-W by instinct and don't even flinch. When I run into an app that asks for facebook login, 99% of the time I just delete it without thinking twice.  And it's not just facebook, it's anything that *requires* signing up for some kind of social networking site. Making it an option is OK, I don't care if other people want to post their latest Doodle Jump score to their stream of inanity, all power to them, but *requiring* it to use an app that doesn't logically need it? Plonk. Nagging me about it after I said no the first time? Plonk.
> 

Maybe I'm the one living in a cave, because I've never come across anything (besides maybe facebook itself) that actually *requires* social networking login.

The closest I've seen is Stack Overflow which I don't post to because it requires OpenPhishing, I mean OpenID.

> 
> [...]
> > > Besides, my wife is on facebook, and if any important news happens via FB, she'll tell me :)
> > > 
> > 
> > Heh. Similar situation here. My brother and sister are both on it, so I'll catch wind of any family news from FB. My parents, like me, aren't on FB either so they get the same benefit, too, although they usually hear much sooner I do ;)
> 
> Me too. My wife has FB, and that's good enough for me.
> 
> Sad to say, though, I got suckered into signing up for Google+. Every now and then (like once a month or less) I post something, but mostly I don't even bother logging on. Most of the stuff on it is pretty inane anyway. Y'know, your typical "what I ate for breakfast", "how many hairs fell into my bathroom sink this morning" and other such content-free posts that are a total waste of time to read. There *are* times when it's useful, like when you're going abroad and have friends who can let you crash in their place for a night or two -- but generally speaking, the signal-to-noise ratio is very low.
> 

Yea, that's also why I stubbornly refuse to call
my...*ahem*...site with posts and articles, a "blog" (heh, usually I
call it a "not-a-blog"). Because to me, what you've described is what a
*real* "blog" is. Like LiveJournal.

On 9/25/12 7:24 PM, H. S. Teoh wrote:
> Me too. My wife has FB, and that's good enough for me.
>
> Sad to say, though, I got suckered into signing up for Google+.

No Facebook but Google+? That's it. You're out. Use Go.

Andrei

On Tue, 25 Sep 2012 18:05:01 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> On Tue, Sep 25, 2012 at 08:19:00PM -0400, Nick Sabalausky wrote:
> > 
> > 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.
> 

Hmm, one of us is still not understanding the other, maybe both.

With what I'm talking about, all of the back/forward/etc buttons and everything are completely gone. Think Scintilla, but for HTML/CSS instead of text.

Ie, imagine you make a trivial HTML page that's nothing but a purple background and no content. Now load it in a web browser. The purple part (and maybe the scroll bars?) is the *only* part that's included. Anything else, forward, back, addr bar, etc., must be *created* by you, the developer and made to call whatever API the control exposes to do such things.

Or at least, that's my understanding anyway. Perhaps I'm mistaken.

The result does admittedly end up being another monolithic system though, just with the same layout engine.

> 
> 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.
> 

Totally agree.

In fact, I specifically tried to make sure, as much as
I could, that all the tools in my Goldie <http://semitwist.com/goldie>
system were basically just thin front-ends over a D API. (Except for
the JsonViewer thing because I didn't write that, I just hacked it up
with some extra features.) You can even check all the 'main.d' files in
the src repo <https://bitbucket.org/Abscissa/goldie/src/master/src>,
they're mostly just thin API wrappers.

I generally try to do that with all my tools. Definitely the way to go.


> I mean, this is just basic computer science. It's function composition. Something that most software of today seems to have forgotten.
> 

Good way of putting it.

> 
> [...]
> > > > > 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.
> 

I've been meaning to look into latex.

> HTML was never intended to be used for the kinds of stuff people use it for these days,

Absolutely. +1

> 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.
> 

Yup.

I do like HTML/CSS for documents, could be less verbose, could use
to not suck at diagrams and math formulas, and it has this
linking problem
<http://semitwist.com/articles/article/view/html-fragment-linking-is-stupid-here-s-the-fix>,
but it generally gets the job done reasonably well...for documents...ie,
what it was *made* for.

But it's *not*, by any means, a sane UI/general-presentation description
format (as it's increasingly being used as), nor was it ever designed to
be. A modern web browser is no different from having "applications" run
inside Acrobat Viewer or MS Word using PDF or DOC for i/o. It's
literally the same thing, just using a different format (but,
thankfully, with no page breaks or multi-column text, neither of
which make sense in electronic form).

On Tue, Sep 25, 2012 at 10:29:54PM -0400, Nick Sabalausky wrote:
> On Tue, 25 Sep 2012 18:05:01 -0700
> "H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> > On Tue, Sep 25, 2012 at 08:19:00PM -0400, Nick Sabalausky wrote:
> > > 
> > > 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.
> > 
> 
> Hmm, one of us is still not understanding the other, maybe both.

OK it's probably my fault. I'm acquiring this bad habit recently of responding before I read, and writing before I think. My bad.


> With what I'm talking about, all of the back/forward/etc buttons and everything are completely gone. Think Scintilla, but for HTML/CSS instead of text.
> 
> Ie, imagine you make a trivial HTML page that's nothing but a purple background and no content. Now load it in a web browser. The purple part (and maybe the scroll bars?) is the *only* part that's included. Anything else, forward, back, addr bar, etc., must be *created* by you, the developer and made to call whatever API the control exposes to do such things.
> 
> Or at least, that's my understanding anyway. Perhaps I'm mistaken.
> 
> The result does admittedly end up being another monolithic system though, just with the same layout engine.

Wait, so you're using HTML to make a browser UI? Or was that just an illustration?


> > 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.
> > 
> 
> Totally agree.
> 
> In fact, I specifically tried to make sure, as much as I could, that all the tools in my Goldie <http://semitwist.com/goldie> system were basically just thin front-ends over a D API. (Except for the JsonViewer thing because I didn't write that, I just hacked it up with some extra features.) You can even check all the 'main.d' files in the src repo <https://bitbucket.org/Abscissa/goldie/src/master/src>, they're mostly just thin API wrappers.
> 
> I generally try to do that with all my tools. Definitely the way to go.

You're doing better than I am. :-P  I whine and groan about it, but then very often my own programs are monolithic monsters. Hopefully once I start having more D projects replace my C/C++ ones, I'll improve in this area. D does make it a lot easier to design software in this way, which is one of the reasons I like it so much in spite of the current implementation flaws.


[...]
> > 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.
> > 
> 
> I've been meaning to look into latex.

And here's a quote for you:

	Those who've learned LaTeX swear by it. Those who are learning
	LaTeX swear *at* it. -- Pete Bleackley

My own take on it is this: LaTeX itself is quite old, and its age is starting to show. There are many things about its implementation details that I don't quite like. Lack of native UTF support is one major flaw (though there are imperfect workarounds).  Also some holdovers from the bad old days of trying to squeeze out every last byte from something, causing a zoo of command names that you pretty much have to memorize. However.  The *concepts* that it is based on are rock solid, and its layout engine beats any WYSIAYG app hands down. You cannot beat LaTeX at paragraph layout. It is optimized to prevent "running rivers" of spaces when adjacent lines in a paragraph has inter-word spaces in the wrong places -- the kind of stuff that browsers spew out every day until hardly anybody notices how awful it looks anymore.

And math!! Once you've tasted the power of math layout in LaTeX, you'll want to dash every other math layout format (esp. web-based ones) against the rocks.  Presently no combination of browser hacks + MathML + whatever other feeble attempt at math notation, etc., can beat LaTeX at math formatting. You can write insanely complex math expressions *and* have it all come out like it was designed by a professional math typographer.  *And* you can do this just by a relatively simple plaintext format that doesn't require clicking through 150 nested menus and hand-picking symbols from a 20-page character map.  You can embed math in your text or have it displayed separately, and in each instance it comes out appropriately formatted. You have symbols that automatically scale (like matrix parentheses that doesn't require stupid manual and ugly resizing, tall brackets, hats and underscores that stretch over multiple symbols, etc.). It's math notation heaven.

I mean, once I (ab)used math mode's amazing diacritic-placing ability to invent a writing system for an artificial language that involves multiple stacked accents over and under letters, and they always come out right. Try that on a modern-day browser with UTF combining diacritics and your eyes will bleed by the time you get to two accents on a single letter, possibly before that. My LaTeX macros could handle up to 5 diacritics above and below a single letter (*and* with some accents side-by-side while being stacked with others) without losing its composure. I mean, I could've formatted Vietnamese diacritics with math mode alone, if there hadn't already been a Vietnamese port of LaTeX, it's that powerful.

You've no idea how much I wish for the day when the web could even come up to 50% of the formatting power that LaTeX provides. My eyes would bleed so much less when I'm online.


[...]
> I do like HTML/CSS for documents, could be less verbose, could use to not suck at diagrams and math formulas,

Once you've tasted the power of math layout in LaTeX, you wouldn't want to go near HTML math formulas with a 20-foot sterilized asbestos-lined titanium pole. It's *that* bad by comparison.


> and it has this linking problem
> <http://semitwist.com/articles/article/view/html-fragment-linking-is-stupid-here-s-the-fix>,
> but it generally gets the job done reasonably well...for
> documents...ie, what it was *made* for.

I'm all for better ways of linking than the klunky baroque name= or id= dance, but one problem with overly-specific linking is, if the target page gets updated and stuff moves around, your link breaks. That's a bit too fragile for my tastes. (Though of course, one could argue that the same will happen if the id= gets deleted by the update, but at least if whatever it is you're linking to still exists, chances are the id= will stay, but unmarked elements can come and go at any time.)


> But it's *not*, by any means, a sane UI/general-presentation description format (as it's increasingly being used as), nor was it ever designed to be.

What never made any sense to me was the use of HTML for what amounts to a GUI (*cough*form elements*cough*JS/CSS popup dialogs*cough*). The markup for these monstrosities make no sense at all, for the simple reason that these are *user interface widgets*, not document fragments!!! So you end up with nonsense like the baroque dance of (ab)using id's and what-not to link disparate elements of a radio button set/select/whatever, <select>'s that have to be modified in real-time by JS mostly by rewriting HTML with string fragments (unless you're crazy enough to actually use native DOM operations for creating individual elements, in which case you're probably beyond help), to mimic what a *real* GUI does with a few lines of code that reads much more sensibly than any JS + HTML string fragments nonsense ever will.

Then you have this nonsensical way of simulating popup dialogs by appending <div>s to the end of the "document" and (ab)using CSS to make it appear like a "real" dialog. Which is all fine and dandy until you start scrolling the document, then all of a sudden a random subset of the form elements in the dialog scrolls off the fake dialogue window while the rest stay on screen -- because the developer forgot to apply certain CSS attributes to said form elements so their positioning got out of sync. (I've actually witnessed this first hand. This is no exaggeration. You can argue this is just a careless bug, but my point is, how did any of this convolution even make any sense in the first place? This is a *document* format, not a windowing toolkit, for crying out loud.)

And using a (semi)transparent screen-filling <div> to simulate modal dialogs? Yeah it's clever. It also shows how stupid the whole enterprise is. That's not a "document" element at all. That's a windowing *system* that got transplanted into a *document* format. It's like implementing a flight simulator in an MS Word document. Very clever if you could pull it off, but also equally ludicrous.


> A modern web browser is no different from having "applications" run inside Acrobat Viewer or MS Word using PDF or DOC for i/o. It's literally the same thing, just using a different format (but, thankfully, with no page breaks or multi-column text, neither of which make sense in electronic form).

Yeah the biggest beef I have with PDF (and LaTeX, for that matter) is that you can't break out of the page paradigm. It's just a holdover from the dead tree print days, which is quickly becoming obsolete in spite of objections from aging book lovers. It doesn't make sense for electronic documents.  This is one thing where HTML is actually better than other generally-more-superior formats.

I'm on the fence about multi-column though. I find that an unfortunately large percentage of websites out there are overly wide, with text that stretch way past your eye's natural comfortable reading width, making reading said text a very tiring experience. OTOH if you just clip the width to a more natural width you have the problem that most screen these days are too lacking in the height department^W^W^W^W^W^W overly endowed in the width department, so you end up with large swaths of empty spaces on either side, which looks awful.  Standard support for multi-columns would be a big help here. (Preferably one that's decided by the *browser* instead of hard-coded by some silly HTML hack with tables or what-not.) I think CSS3 has (some) support for this.


T

-- 
If it breaks, you get to keep both pieces. -- Software disclaimer notice

On Tue, Sep 25, 2012 at 09:42:26PM -0400, Andrei Alexandrescu wrote:
> On 9/25/12 7:24 PM, H. S. Teoh wrote:
> >Me too. My wife has FB, and that's good enough for me.
> >
> >Sad to say, though, I got suckered into signing up for Google+.
> 
> No Facebook but Google+? That's it. You're out. Use Go.
[...]

Heh heh... I was half-expecting you'd show up in this thread after all the anti-FB sentiment, and sure enough you did. ;-)

Seriously, though, no offense intended, but I find FB's privacy policy rather ... lacking for my tastes. That's not to say G+ isn't susceptible to Big Brotherisms, of course, Google being what it is, but at least it gives you the illusion of control, like controlling who sees which posts (which FB imitated after the fact, if you allow me to say so), easier management of friends with the circles system, being able to delete your account data without caveats and jumping through hoops, etc..

But anyway, I hardly ever use my G+ account... Like I said, most of the posts are a waste of time to read, and I don't feel a compelling need to add to the noise or to publish my personal life online. So *shrug*.


T

-- 
Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin & Hobbes

On Tue, 25 Sep 2012 23:00:41 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:
> On Tue, Sep 25, 2012 at 10:29:54PM -0400, Nick Sabalausky wrote:
> > With what I'm talking about, all of the back/forward/etc buttons and everything are completely gone. Think Scintilla, but for HTML/CSS instead of text.
> > 
> > Ie, imagine you make a trivial HTML page that's nothing but a purple background and no content. Now load it in a web browser. The purple part (and maybe the scroll bars?) is the *only* part that's included. Anything else, forward, back, addr bar, etc., must be *created* by you, the developer and made to call whatever API the control exposes to do such things.
> > 
> > Or at least, that's my understanding anyway. Perhaps I'm mistaken.
> > 
> > The result does admittedly end up being another monolithic system though, just with the same layout engine.
> 
> Wait, so you're using HTML to make a browser UI?

No...

> Or was that just an illustration?
> 

Let me try putting it a different way (Sorry if it sounds patronizing,
I'm not trying to be):

Most GUIs are made of common re-usable widgets, right? The "button" widget, the "checkbox" or "radio box" widgets, the "menu bar" widget, the "text box" widget, "image", "list", "grid", "treeview", etc. So then you make a GUI by plopping those widgets into a window, adjusting their exposed properties, and providing actions for stuff like "onClick". Basic stuff, right?

So if I take a text-edit control and plop it onto a window, I haven't recreated the entire GUI and functionality of Windows Notepad or Kate or Gedit or Eclipse or whatever. It's just a text box. No menu bar, no toolbar, no "save button", no "currently opened files list", no status indicators, no nothing. Just a box you can type into. You have to add those widgets in, and add code to make them cause the right things to happen to the text box widget (or as a result of the text box widget).

But then there's fancier widgets, too. Like WebKit (used by Safari, Arora, Chrome IIRC, and likely others), or a similar one from IE, and maybe FF too, I dunno. These are "HTML/CSS Viewer" widgets: You give them HTML/CSS and they show it and, I assume, give you an API for accessing the DOM somehow. I imagine you can probably give them a URL too. They may or may even do other stuff too, like offer an API for "goToPreviousPage()". I'm sure it all varies from one to another, and I honestly don't know how far any of them go because I haven't used them personally. Although I *think* with WebKit it's up to you to wire up a JS engine yourself (just as an example).

But what they *don't* do, AIUI, is provide any GUI *at all* for anything besides the final rendered HTML/CSS. (Although I do have a vague recollection that there *is* an IE widget you can use that *does* give you all of that.) So...

...suppose you made a GUI program, gave it a window, and filled that window with one of those HTML/CSS/Web widgets. It'll show *nothing*. Blank page. So in code, you tell it to go here (Go ahead and visit this link for real right now):

http://semitwist.com/blank-purple.html

(Or maybe your code just downloads that URL and hands the raw HTML to
the control. Or something.)

Then...Your program will be *nothing* but a big purple rectangle, maybe with scrollbars, and whatever window-frame is added by your system's window manager. That's it. The user won't even be able to type in a URL or go forwards/back without you putting in code and widgets (or keyboard accelerators, or whatever) to let them do that. The widget may or may not have a simple "browserView.goBack();" that you can call, I don't know, but even if it does then YOUR code has to actually bother to call it.

Interestingly, there are add-ons for FireFox that let you use the IE renderer instead of FF's renderer *in* one or more of your FF tabs. There's even some obscure browser out there that lets you choose between IE, FF and some other (WebKit?) for each of it's own tabs. Might be called Trident or something like that, IIRC?

At least...that's my understanding of it all, having never actually dealt with browser code myself. I apologize if I happen to be totally wrong ;)

> 
> You're doing better than I am. :-P  I whine and groan about it, but then very often my own programs are monolithic monsters. Hopefully once I start having more D projects replace my C/C++ ones, I'll improve in this area. D does make it a lot easier to design software in this way, which is one of the reasons I like it so much in spite of the current implementation flaws.
> 

D is seriously so awesome. I had to go back to C++ for the iOS/Andorid game I'm doing, and man do I miss D <http://semitwist.com/articles/article/view/top-d-features-i-miss-in-c>.

I miss D whenever I do maintenance on my Haxe-based webapp (one of my real-world projects). I miss D like crazy anytime I have to use any language other than D. It's so totally spoiled me :)

> 
> And here's a quote for you:
> 
> 	Those who've learned LaTeX swear by it. Those who are learning
> 	LaTeX swear *at* it. -- Pete Bleackley
> 

I think I heard that once before. I do like it :)

> My own take on it is this: LaTeX itself is quite old, and its age is starting to show. There are many things about its implementation details that I don't quite like. Lack of native UTF support is one major flaw (though there are imperfect workarounds).  Also some holdovers from the bad old days of trying to squeeze out every last byte from something, causing a zoo of command names that you pretty much have to memorize.

Might be fun to make a front-end for it. Something that spits out raw latex given a modernized equivalent.

> [...LaTeX rox stuff snipped...],

Sounds cool.

> [...]
> > I do like HTML/CSS for documents, could be less verbose, could use to not suck at diagrams and math formulas,
> 
> Once you've tasted the power of math layout in LaTeX, you wouldn't want to go near HTML math formulas with a 20-foot sterilized asbestos-lined titanium pole. It's *that* bad by comparison.
> 

Even now I wouldn't even bother. I'd just use an image, or if not that, then maybe try pre-baked MathML output. But you have convinced me to get around to trying latex when I get a chance.

> 
> > and it has this linking problem
> > <http://semitwist.com/articles/article/view/html-fragment-linking-is-stupid-here-s-the-fix>,
> > but it generally gets the job done reasonably well...for
> > documents...ie, what it was *made* for.
> 
> I'm all for better ways of linking than the klunky baroque name= or id= dance, but one problem with overly-specific linking is, if the target page gets updated and stuff moves around, your link breaks. That's a bit too fragile for my tastes. (Though of course, one could argue that the same will happen if the id= gets deleted by the update, but at least if whatever it is you're linking to still exists, chances are the id= will stay, but unmarked elements can come and go at any time.)
> 

Yea, but at least it's something. And the "alternatives" feature helps, too.

What might be a good complement to that would be a text-search fragment. To go to the first instance of some short phrase. Again, not perfect, but beats the hell out of "No 'id=' where you need one? You're SOL!"

But in any case, the whole damn web is completely fluid anyway, so even without the "id=" fragments that we *do* have, there's always still links breaking. At least a broken fragment still goes to the right page, instead of a 404 or "server not found" something.

> 
> > But it's *not*, by any means, a sane UI/general-presentation description format (as it's increasingly being used as), nor was it ever designed to be.
> 
> What never made any sense to me was the use of HTML for what amounts to a GUI (*cough*form elements*cough*JS/CSS popup dialogs*cough*).

*Exactly*

The "JS/CSS popup dialogs" (I call them "pop-ins") are probably the #1 thing that irritates me most on the web. Everything about it is wrong. Not just the technical things you describe, but the whole user experience even when it's *not* buggy. I mean, here we have a *popup*, that *can't* be killed by popup blockers, *and* makes the page underneath inaccessible! *And* it breaks the "back" button! Plus, on top of all that, it's completely unnecessary 100% of the time and does *nothing* to improve the user experience.

I had a *cough*fun experience with them recently, too:

I wanted to check the availability of some item at my local library system, but their site insists on showing the availability info in one of those "pop-ins". Ok, annoying normally, but I was out of the house so I was doing this on the iPhone (which took forever due to the barely-usable text-entry on the thing). So I finally get to what I want, get to the "item availability" pop-in, and it's too big to fit on the screen. Ok, to be expected, it *is* a phone. So I try to scroll...and the pop-in *stays in place* as I scroll around the faded-out page underneath. So I can't scroll the pop-in. So I try to zoom out. Oh, it zooms out ok, but the part that was offscreen *stays* offscreen, so that doesn't help either. Go landscape - that just makes it worse because it everything scales up to keep the page width the same, so I just loose vertical real estate.

Funny thing is, it works fine (ie without using pop-ins) when JS is off. But I can't turn JS off in iPhone Safari.

So I don't know if it's an HTML/CSS/JS problem, a site problem, an iPhone problem, or a combination of all, and honestly I don't even care - it blows, and that's all that matters.

> [...]
> And using a (semi)transparent screen-filling <div> to simulate modal
> dialogs? Yeah it's clever. It also shows how stupid the whole
> enterprise is. That's not a "document" element at all. That's a
> windowing *system* that got transplanted into a *document* format.
> It's like implementing a flight simulator in an MS Word document.
> Very clever if you could pull it off, but also equally ludicrous.
> 

Exactly.

> 
> I'm on the fence about multi-column though. I find that an unfortunately large percentage of websites out there are overly wide, with text that stretch way past your eye's natural comfortable reading width, making reading said text a very tiring experience. OTOH if you just clip the width to a more natural width you have the problem that most screen these days are too lacking in the height department^W^W^W^W^W^W overly endowed in the width department, so you end up with large swaths of empty spaces on either side, which looks awful.  Standard support for multi-columns would be a big help here. (Preferably one that's decided by the *browser* instead of hard-coded by some silly HTML hack with tables or what-not.) I think CSS3 has (some) support for this.
> 

The problem with that is you're creating excess vertical scrolling. Just to read linearly it's "scroll down, scroll up, scroll down", etc. (Of course, that pain is hugely compounded when the multi-columns are on page-based PDFs, like academic research papers.)

The root problem there is that the need for multi-column on the web is artificially created by manufacturers and consumers who have collectively decided that watching movies is by far the #1 most important thing for anyone to ever be doing on a computer. Hence, "decapitated fat midget" 16:9 screens for everyone! No matter how bad it is for...just about everything *but* movies and certain games. Which, I suspect, is also the main reason we can't have browsers anymore with nice traditional UIs - because they have to be shoe-horned into a movie-oriented half-screen.

Thank god they didn't standardize it all for those 1.85:1 films. Yet.

> If it breaks, you get to keep both pieces. -- Software disclaimer notice

Heh, that's awesome :)

On Wednesday, 26 September 2012 at 02:29:09 UTC, Nick Sabalausky wrote:
> Ie, imagine you make a trivial HTML page that's nothing but a purple background and no content. Now load it in a web browser.
> The purple part (and maybe the scroll bars?) is the *only* part
> that's included.

I think that's how most the web widgets work. Though a while ago, I was toying with doing a little browser widget in D, the idea being the window is nothing but a html thingy and everything is done by code... including stuff like link behavior, by doing event handlers in your D.

But I never really got too much done with it.

On Tue, 25 Sep 2012 18:59:55 -0400, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:


>> I don't think the photos are meant to be browsed that way.  See this
>> thread here https://discussions.apple.com/message/16514340#16514340
>>
>> I think explorer must not be using the rotation field (seems odd),
>> but the camera import rotates the picture on import.
>>
>
> Ugh, yea, exactly. I can't do a normal file copy? I can't email them?
> The way apple handled photo orientation is just terrible. Like the one
> guy said in there, at the very *least*, they should have allowed an
> option to actually store them rotated since there's obviously so damn
> much that doesn't support that metadata flag.

I think you can do a normal file copy.  But it seems like many photo viewing applications (Including explorer apparently, which surprises me) does not support the rotation data that your file copy won't look right on those.

There are probably some applications that support the rotation flag.

It kind of makes sense to me.  You are getting a raster image from the camera, and obviously the hardware doesn't do the rotation, so to be as efficient as possible, instead of doing a transformation in software, which might also require moving the data to places it doesn't have to go, it simply stores a few bits different in the image.

From that thread, I could see that Apple is not the first nor only one to do that -- cameras which have accelerometers also do it.

>> The "back button" is the rotate.  I agree it's not very well drawn,
>> it should be more like a quarter-turn and less snazzy (just a quarter
>> circle arrow would be better).
>>
>
> Ugh, geez...
>
> I miss words. I didn't mind non-word toolbar buttons on the desktop,
> because then you have the concept of "hover" which will trigger the
> words until you learn the icons (and then get annoyed because you
> usually can't turn off the tooltips once you no longer need them...).

From my software design class in college, I learned that pictures are actually better *if* they are obviously intuitive.

For example, take a large room with 10 light switches.  What is easier to understand, a bank of 10 light switches with each one having a label of what it is, or a layout of the room with a light switch placed at the location on the map that it controls in the room?

If it can't be obviously intuitive, then use words.

This feature can be obviously intuitive.  A rectangle on its side, with a rounded arrow rotating to a rectangle on it's bottom would be obvious and require no words, for anyone in any language.  It's just a failure on whoever designed that icon, and I think it should be fixed.

> Plus toolbar buttons on the desktop aren't so damn abstract. Android's
> guilty of that too, their wordless icons are just getting more and more
> abstract (and thus, obscure) with each new version. Yea, they're
> prettier now, but who cares about pretty when it's not usable?

Abstract/obscure is the *wrong* way to go with icons.  Not all operations are easy to make into an icon.  But then you will probably have the asthetics dept screaming at you if you made a toolbar with half icons and half words :)

>> My brother has an android with dedicated buttons, but they are part
>> of the touch screen (they aren't displayed, they are inlays, but are
>> part of the whole touch sensitive screen).
>
> Yea, that's how mine is, too (Nexus S 4G). I prefer the older ones with
> physical buttons, but at least this is better than the latest ones which
> merely draw it on the screen (which means they can decide to make
> the "standard" buttons disappear on a whim...gee, great...)
>
> I think they're just trying to "be like apple" and minimize the amount
> of anything tactile. I can't think of any other sane reason for it.

I can't understand the lack of love for physical buttons these days.  There are some things that need real buttons.

> I do wish tilting scroll wheels were more common though.

I had one of those.  the issue is, the software has to support it.  Not all do.

>> > Yea, "Show hidden files" is one of the first things I do when I
>> > install a new OS. And "Show my f*** extensions" on windows.
>>
>> Hells yeah!  It always strikes me as comical that MS created that
>> "feature" and it created a whole class of openme.txt.exe viruses.
>> Yet instead of just removing that misfeature, they built legions of
>> extra CPU-consuming mail filtering and anti-virus software to prevent
>> people from having any files with multiple extensions, only to piss
>> off people who tried to use .tar.gz files :)
>>
>
> Yup :)
>
> They seem to think their "Type" field solves the issue, and maybe that
> works fine for average Joes, but I'm not an average Joe and I don't
> want to be playing guessing games about "Ok, what's the Microsoft term
> for a .XXXXX file?" Or "What the hell file type is a 'Configuration
> settings' again?" And then there's different file types that will have
> the *same* Microsoft "Type".

No, it's not that!  Just *SHOW THE EXTENSION*.  I don't understand how they think people's brains are so fragile that they wouldn't be able to handle seeing the extensions.

It's like Microsoft thought that was an ugly wart and fought to cover it up at all costs -- including spawning viruses.

> And I'm not entirely joking. I mean think about, say, the 80's. Who
> were the most common people using computers? There were plenty of
> exceptions, but mostly it was people who knew what they were doing.
> That's because the people who *didn't* know what they were doing would
> either not buy one, or just let it collect dust. Now everyone uses them,
> including the "dummies" who previously avoided them.

I actually don't think that is the case.  There seems to be this common view that people who aren't computer savvy need icons and GUIs and whatever to be able to use them.  If you want to see proof that this is false, go to any Sears store, and buy something, then watch the salesperson (whom I don't consider a tech guru) breeze through the terminal-powered curses interface to enter your order -- using F keys and everything else.

I think tech-unsavvy people just take more training, but they certainly can use any interface you give them.

>> What I like about the 2-finger scroll is that it goes all 4
>> directions, it's like panning.  And I don't have to move my finger to
>> a certain spot.
>>
>
> I'm not sure this one does that (although in some apps I can do
> that by middle-dragging on my trackball - I wish it was all though).
>
> But, and maybe I'm being paranoid, I have a very strong suspicion
> that limitation is due to an apple patent. They *have* been
> very patent-litigious in recent years, and it doesn't seem like the
> kind of feature anyone would actually have any trouble getting right.

Meh, if Apple wants to sue someone like HP over PC features, I'm sure HP can shoot back.  I don't think that's the issue.  Remember, most companies hold patents so that they don't get sued, not so that they sue others.

It's probably more of the case that Windows apps just aren't built to handle it.

> Yea, sounds like the one I tried years ago at some apple store. IIRC,
> you couldn't even rest your fingers on the mouse because that would be a
> "click". You had to hover *over* the "button".

Hm... I don't think it has to be configured that way.  The whole mouse "clicks" when you push it.  But you could configure just a tap on the surface to be a click.

In any case, not worth having IMO.

>> There is a general
>> assumption by many applications/websites that *everyone* uses
>> facebook.
>
> I know! And it's not just software, it's all business in general. They
> noticed that it's popular so they think that means "nearly everyone uses
> it" when the reality is that even as popular as it is, it's still only a
> *minority* of internet users. Same with twitter.

I begrudgingly signed up for twitter, so I could send a message to a radio host (who is a twitter fanatic, so I knew he would read it).

Since then, I've tweeted a few things, but I'm not crazy about it.  At least you aren't expected to "follow" everyone you met for 5 minutes.

-Steve