A circumflex a circumflex a circumflex a circumflex a circumflex a circumflex a circumflex a circumflex

@MiffTheFox said:
Also the all programs menu hasn't been relevant in Windows for over half a decade except as a searchable index of software on the PC.

I know that's how I use recent Windows, but I wonder how true that is across the user base. I'm willing to bet that it's still relevant, given the number of people who are amazed when I tell them about Ctrl-F. Of course, a lot of those have a desktop full of icons, too.

The "All Programs" menu has never been relevant for the majority of users. The vast majority of computers I have seen over the years all have a desktop filled with icons, including lots of ulesless crap that was put there automatically by installers -- the desktop is the All Programs menu.

dhromed

Fun fact: understanding that the Programs menu can't be prevented from becoming a total mess (a design flaw) and that the desktop musn't become a total mess, I've always had a separate Applications folder at the top of my start menu for the software that I actually use.

The design flaw of the Programs menu was first addressed with XP's new start menu, and refined with Vista and 7. I can't say yet if Win8's start screen is good (if anything, people who bitch about the colours seriously need to reprioritize. Also custom added tiles don't have a colour. So quit bitching.). I miss the search/console combo field. I've grown used to hitting the WinKey and typing "cmd" or "C:\some\path" or "[keyword for program I can't find]"

@dhromed said:

understanding that the Programs menu can't be prevented from becoming a total mess (a design flaw)

I agree that it is a design flaw and it's true that you can't prevent programs from filling your Start Menu with a lot of crap. However, it only takes a few minutes to organize everything and clean out all the crap. And once you get everything organized in a neat and sensible manner, it's just a matter of an occasional edit or two when you install something new. It's a bit annoying that you have to do that, but it's pretty simple and easy.@dhromed said:

The design flaw of the Programs menu was first addressed with XP's new start menu, and refined with Vista and 7.

How was it "addressed"? It's still possible for every program you install to fill your Programs Menu with a metric shit-ton of useless crap. Maybe you are referring to the Start Menu keeping a list of most recently used programs. That is a nice feature and as soon as I noticed it in XP, I immediately removed all the icons from my desktop. Since about 90% of everything I do revolves around 11 or 12 programs, everything fits nicely on the Start Menu.

boomzilla

@El_Heffe said:

Maybe you are referring to the Start Menu keeping a list of most recently used programs. That is a nice feature and as soon as I noticed it in XP, I immediately removed all the icons from my desktop. Since about 90% of everything I do revolves around 11 or 12 programs, everything fits nicely on the Start Menu.

Yes, I generally pin the few things that I use all the time in Windows to the start menu. It's especially handy (in Win7) for stuff like RDP, where the pinned entry turns into a menu of recently connected to remote hosts.

Of course, you're generally not going to have lots of useful but infrequently used stuff installed like on Linux, where a lot of stuff comes effectively pre-loaded when you pick a desktop install. And the automatic categorization is really useful for looking for stuff when you're not sure what its name even is. Also, the categories are included in the search (at least on KDE), which makes the search more useful.

dhromed

@El_Heffe said:

How was it "addressed"?

Pinning
Recent programs (with a really, really shit algorithm in XP.)
Searchbox

All good stuff, given that both you and boomy have made proper use of it. Q.E.D.

In XP, I still have my own Apps submenu in the Startmenu, plus the trusty quicklaunch.
Vista, I pin some stuff, use search otherwise, and still have my trusty quicklaunch.

I have not used Win7 or 8 in order to develop a workflow like that. MMMV.

blakeyrat

Crotchety Luddite people do not adopt new OS features! New OS features exist only to be complained about! If it was not present in Windows 3.1 it does not exist for the likes of them!

ASheridan

@dhromed said:

Fun fact: understanding that the Programs menu can't be prevented from becoming a total mess (a design flaw) and that the desktop musn't become a total mess, I've always had a separate Applications folder at the top of my start menu for the software that I actually use.
The design flaw of the Programs menu was first addressed with XP's new start menu, and refined with Vista and 7. I can't say yet if Win8's start screen is good (if anything, people who bitch about the colours seriously need to reprioritize. Also custom added tiles don't have a colour. So quit bitching.). I miss the search/console combo field. I've grown used to hitting the WinKey and typing "cmd" or "C:\some\path" or "[keyword for program I can't find]"

Probably one of the main reasons why I could never go back to Windows as my main OS anymore. I'm so used to the Krunner in KDE. Hit alt + F2 and type the name of any program. If I can't remember the name, I can type part of the description. In Windows, about the closest I can get is to hit the Windows key and start typing the beginning of the program name (or the start of a word of the program name, i.e. it won't list MySQL Workbench if I type in 'SQL', but it will if I type in 'my' or 'work'). If You can't remember what the app was called, you're stuck to looking through the menus in Windows. In KDE, if I'm looking for something that I can't remember the name of (a specific media player for example) then all I would have to type is 'music' and it would be listed.

Simple functionality, but saves me loads of time as Krunner works on pretty much anything that's indexed (docs, IM conversations, emails, bookmarks, etc).

ASheridan

@blakeyrat said:

Crotchety Luddite people do not adopt new OS features! New OS features exist only to be complained about! If it was not present in Windows 3.1 it does not exist for the likes of them!

Of course people adopt new features, we've all added animated cursors of cats at one point.

ender

@ASheridan said:

In Windows, about the closest I can get is to hit the Windows key and start typing the beginning of the program name (or the start of a word of the program name, i.e. it won't list MySQL Workbench if I type in 'SQL', but it will if I type in 'my' or 'work').

Let me guess: you disabled indexing? Not only does the search in Windows 7 Start Menu work on partial matches (of icon name, description, path and a few other things), it'll also find Control Panel items if you type a vague description of what you want to do.

blakeyrat

@ender said:

Let me guess: you disabled indexing?

That would be a crotchety luddite thing to do.

ais523

OK, so I looked into the original WTF to see exactly which piece of software was screwing up.

First off, the dialog box in question looks like it was drawn using dialog(1). dialog(1) uses ncursesw(3) (a commonly used library for drawing on terminals) in order to draw lines on the screen. First WTF: you know how the picture looks like misinterpreted Unicode? Well, dialog(1) doesn't actually use Unicode to draw lines on screen, but the DEC alternate VT100 line-drawing charset (verified using ltrace). So if the terminal didn't understand it, it wouldn't look like âââââââ… but like lqqqqqqq…qqqx. (I've seen that particular bit of misencoding more than once before now.) This is interpreted correctly by PuTTY regardless of the Unicodiness or otherwise of the terminal; after all, the characters that are being sent are all ASCII, with control codes to switch between letters and line-drawing. blakeyrat, were you running inside screen by any chance? If so, my strong theory (based on a reasonably active hobby working on terminal applications) is that it's actually it that was at fault. I don't see how it'd happen otherwise; I tested running dialog(1) in a terminal that was actually set to an 8-bit codepage but which I'd told to incorrectly claim to be UTF-8, and it rendered just fine.

Next, it's typically the job of environment variables to send information about the terminal and the encoding it expects. With my TERM variable to "xterm" (what PuTTY uses by default), it renders correctly. If I set it to "screen", it renders correctly, but now starts sending, instead of DEC line-drawing characters, information depending on the charset I send. (This is further evidence in favour of the theory that screen, which wasn't mentioned, is at fault. Or perhaps some other intermediate terminal layer.) If I set LC_ALL=C and TERM=screen, it renders correctly on a terminal set to pretty much any ASCII-based encoding I tried. If I set LC_ALL=en_GB.UTF-8 and TERM=screen, it now renders incorrectly on a terminal set to ISO-8859-1 (and fine on a terminal set to Unicode). Conclusion: dialog(1) uses drawing codes as requested by the TERM and LC_ALL variables. So dialog(1) is not the WTF. (Note: the programs I work on on my hobby are in the same position as dialog(1), and often have to do unreasonable things in order to work around WTFs elsewhere, so I was guessing this conclusion.)

Next step: what's setting those environment variables? Well, the shell can, but ssh should be setting them up. And a bit of testing reveals that, in fact, ssh is transmitting the TERM environment variable. That's reasonable. Also, that it's transmitting the LC_ALL environment variable. That's how it's meant to work, and here's how it looks in practice:

ais523@mycomputer:~$ export LC_ALL=en_GB.UTF-8
ais523@mycomputer:~$ ls /blakeyrat
ls: cannot access /blakeyrat: No such file or directory
ais523@mycomputer:~$ export LC_ALL=fr_FR.UTF-8
ais523@mycomputer:~$ ls /blakeyrat
ls: impossible d'accéder à /blakeyrat: Aucun fichier ou dossier de ce type
ais523@mycomputer:~$ ssh anothercomputer
ais523@anothercomputer:~$ ls /blakeyrat
ls: impossible d'accéder à /blakeyrat: Aucun fichier ou dossier de ce type

Now, it's pretty easy to accidentally customize your startup scripts to set the locale, and if you do, you accidentally blow away your encoding information in the process. (In fact, I'd done it on one of my systems before running these tests, and got confusing results for a while.) I'd recommend looking in .profile or .bash_profile or .bashrc or .login or .bash_login or whatever it's called nowadays to see if there's any locale setting done. (Yes, there are far too many of those files. It probably seemed like a good decision at the time…)

So, why would dialog be sending UTF-8 to a terminal configured to use ISO-8859-1? There are two possibilities, and possibly both apply.

The first is that PuTTY isn't bothering to set LC_ALL at all. (blakeyrat can test this via "echo $LC_ALL" in his remote terminal.) In this case, programs he runs have no information about what encoding he's expecting (or, fwiw, about what language he's expecting; most likely, this wouldn't show up as an obvious problem to an English-speaker, because it's the language most programs are going to default to). I've tested what dialog(1) and ncursesw(3) do with a blank LC_ALL: they assume C.UTF-8 as the language and encoding. ("C" is a sort of default language used by programmers when they want portable output; text is in English, things like numbers and dates follow typical programming conventions.) This wouldn't be noticeable with the TERM set to "xterm"; but with TERM set to "screen", ncursesw assumes Unicode and outputs that. (After all, it's the Unicode version of ncurses, right?) So this is an arguable bug #1: given no information about encoding, ncursesw assumes UTF-8 rather than falling back to a lowest common denominator.

The other is that PuTTY is sending LC_ALL correctly (something along the lines of "en_US.ISO-8859-1", assuming that blakeyrat likes the USA variant of English best). Why wouldn't this render correctly (again with TERM set to "screen")? Because, the .ISO-8859-1 encoding isn't actually implemented for English in Ubuntu! At least, not with the default set of locale packages (and I haven't found which package it's actually in). Presumably someone removed it on the basis that with Unicode awareness everywhere nowadays, it wasn't necessary. The result of that would be that the shell wouldn't understand the locale it was given and would fall back to a default instead, which might well reasonably be C.UTF-8. So this is arguable bugs #2 and #3.

And the reason that the bugs weren't caught is most likely that they were tested directly, rather than via screen (or some other bizarre terminal type that doesn't just use line-drawing commands). The bug only comes up if two things are unusual.

The best fix to all this is, IMO, to react to missing or impossible encoding declarations by sending back only ASCII in ncursesw. Oh, and to adjust PuTTY to start up in Unicode mode by default, and tell the other end of the connection that that's what it expects. (I'd also love it if the default Ubuntu terminal capability files TERM=screen used the actual standard VT100 codes for everything they could be used for, rather than randomly doing things differently from xterm just to be perverse, but hey, you can't have everything. And arguably that would hide genuine bugs, although I doubt blakeyrat would care if it made the screen render correctly.)

(BTW, I can confirm that the terminals I tested do indeed treat an instruction to render something as ISO-8859-1, to render it as ISO-8859-1. Not as Windows-1252. So only the âs of the misencoding are visible, because the other characters aren't valid in that character set.)

I bet after all the time I put into diagnosing this, my post will largely be ignored and people won't care about it.

boomzilla

@ais523 said:

I bet after all the time I put into diagnosing this, my post will largely be ignored and people won't care about it.

Actually, I thought it was an interesting bit of forensics, so thanks for that. I'm eagerly anticipating the incoherent and misdirected outpouring of rage from the OP, however.

ASheridan

@blakeyrat said:

@ender said:
Let me guess: you disabled indexing?

That would be a crotchety luddite thing to do.

That would be a pretty dumb thing to do, I agree. I didn't disable anything, so if it wasn't enabled in the first place by default...

Are you sure it's working on partial matches the way I'm talking about though?

As an example, lets say I didn't know what Microsoft Outlook was named fully. I start to type 'look' because that's the only part I remember. What do you think should happen? This is what I got:

control panel

change how the mouse pointer looks
change how the mouse pointer looks when it's moving
view recent messages about your computer

documents

we_may_look_silly_but.gif
look_inside_grey.jpg

etc (but no programs)

There are no programs listed at all. Notice anything here? All the matches were made at the beginning of word boundaries, not within words. This is the very thing I'm saying KDE can do that Windows apparently can't.

dhromed

@ASheridan said:

All the matches were made at the beginning of word boundaries, not within words.

It's the same thing with IE's address bar autocompletion and it's the reason it's just not very good.

boomzilla

@ASheridan said:

There are no programs listed at all. Notice anything here? All the matches were made at the beginning of word boundaries, not within words. This is the very thing I'm saying KDE can do that Windows apparently can't.

I just tried this, and can confirm your results here on Win7. First, I verified that indexing was turned on. Searching on "soft" didn't turn up any programs. "Microsoft," of course, finds all sorts of stuff. Likewise, "pad" didn't find WordPad. I brought up the indexing dialog (also stuff like "Change the way windows searches" and similar) and didn't see anything that would obviously affect this.

blakeyrat

@ASheridan said:

This is the very thing I'm saying KDE can do that Windows apparently can't.

It can, it just doesn't by design. And no I don't know the reason for that.

blakeyrat

@ais523 said:

blakeyrat, were you running inside screen by any chance?

I was running it ON a screen.

Seriously, though, was I running "inside screen"? I don't know, and I don't know how to find out. Not explicitly? I can say that for certain.

@ais523 said:

I bet after all the time I put into diagnosing this, my post will largely be ignored and people won't care about it.

Well you've confirmed there's a bug, but we already knew that from looking at the output. It's also revealed to me how much of a clusterfuck this whole thing is, considering how simple the task it actually does is.

boomzilla

@blakeyrat said:

@ASheridan said:
This is the very thing I'm saying KDE can do that Windows apparently can't.

It can, it just doesn't by design. And no I don't know the reason for that.

What does that mean? Is it something like, "I can quit smoking any time I want. I just don't want to." Is there some configuration setting to fix this bug? Seriously, I'd like to be able to fix it locally. Or is this just a banal observation about the nature of text?

Hmmmm

@boomzilla said:

@ASheridan said:
There are no programs listed at all. Notice anything here? All the matches were made at the beginning of word boundaries, not within words. This is the very thing I'm saying KDE can do that Windows apparently can't.

I just tried this, and can confirm your results here on Win7. First, I verified that indexing was turned on. Searching on "soft" didn't turn up any programs. "Microsoft," of course, finds all sorts of stuff. Likewise, "pad" didn't find WordPad. I brought up the indexing dialog (also stuff like "Change the way windows searches" and similar) and didn't see anything that would obviously affect this.

WTF!!! Stop being morons and search for *soft