I hate Chrome



  • @boomzilla said:

    @blakeyrat said:
    Look at this lovely Firefox bug, extraordinarily trivial, utterly obvious, and unfixed in version 1, 2, 3, 4.

    My new favorite.

    Who is sillier? The devs for not correcting this? Or the guy who's been commenting on it for almost 5 years? If it were my project, I might see how long I could string him along, too.
     

    Oh, I would *totally* be that dev :) For one, it's not a Firefox bug; as explained, they take the images from the current theme, and Gnome (in this case) supplies those.  Second, if I were a Gnome-dev, I'd argue it's not a bug there, either: the rotated figurehead is intended for ordinary people to realise what they're about to select. You know, the average users to whom "portrait" or "landscape" prolly mean as much as "stale symlink" or "dependency injection".

    The Real WTF(tm) therefore, is that not much more fun is being made out of this. Probable cause: the Mozilla devs have better things to do?



  • @blakeyrat said:

    @Monomelodies said:
    Hm? I'm not seeing the problem, to be honest... the following works fine for me:

    What you're missing is that the code runs in the BeforeUnload handler. I should have made that clearer in my original post.

     

    Ah, I see: you are required by some external crap to use that handler? I didn't get that. But when in the lord's name would a form submission lead you to another domain? Okay, it's technically possible, but highly unlikely, or am I missing something here?

    Anyway, the beforeUnload handler is crappy, but that's by design. You're not supposed to f*ck with people who want to leave your page :) It's really only any good for "you entered stuff in a form and have now clicked on a link, so your toil will have been in vain. Agree?"-type of messages.



  • @Monomelodies said:

    Oh, I would totally be that dev :) For one, it's not a Firefox bug; as explained, they take the images from the current theme, and Gnome (in this case) supplies those.

    You didn't read the bug. It also occurs in the Windows version, where Mozilla is responsible for the theme.

    @Monomelodies said:

    Second, if I were a Gnome-dev, I'd argue it's not a bug there, either: the rotated figurehead is intended for ordinary people to realise what they're about to select.

    But selecting landscape doesn't rotate the printout-- that's the entire point!

    The figurehead makes the icon worse than useless, because now the user thinks, "not only does this print in landscape, but for some reason it rotates the image 90 degrees also", and then they'll be confused when the paper comes out and the image isn't rotated.

    @Monomelodies said:

    Probable cause: the Mozilla devs have better things to do?

    Undoubtedly. I'm not arguing that this is a horrible bug, or one that should have blocked a release. And I have relatively high standards when it comes to bug-free software. But keep in mind:

    During the period of time this bug has been opened, the Firefox theme (on OSes where it uses its own theme) has been redone from scratch several times-- all of those times, the person redoing the theme didn't bother to check the bugtracker for open bugs against the current theme. That is, he didn't do his damned job.

    Despite the theme designer not doing his job, practically anybody with commit access and a copy of Paint.NET could have fixed this bug in seconds at any time. Once fixed, the next theme would undoubtedly carry the fix because the theme designer would be working from the fixed example.

    Anyway, I just found it amusing.



  • @Monomelodies said:

    Ah, I see: you are required by some external crap to use that handler? I didn't get that. But when in the lord's name would a form submission lead you to another domain? Okay, it's technically possible, but highly unlikely, or am I missing something here?

    Well, you do have a point, the odds that we'd have the page with the submission tagged and the page with the thank you untagged are pretty slim. That said, the problem still applies to external links, and it's a huge pain-in-the-ass to recode the back-end to be able to retroactively put events into pageviews that have already been closed-out. (Hm... actually it wouldn't be too tough.) Also, we have had clients complain about excessive cookie usage in the past. Some clients on crappy CMS' have huge, huge cookies. So we try to minimize the cookie space we use on their domain.

    @Monomelodies said:

    Anyway, the beforeUnload handler is crappy, but that's by design. You're not supposed to f*ck with people who want to leave your page :)

    Like I've said several times in this page, I don't want to delay the page unload, nor do I want to disrupt the user's experience. This code is there because there's literally no other way of fulfilling our requirements. I'd love to see the W3C (or browser makers independently) decide to add a way of popping off a pixel on page unload without requiring a delay, but the odds of that happening are pretty much nil. (Although IE already does this when you use XMLHttpRequest, this might be by accident, or specifically to solve this problem... who knows.)

    @Monomelodies said:

    It's really only any good for "you entered stuff in a form and have now clicked on a link, so your toil will have been in vain. Agree?"-type of messages.

    That's a krajillion times more disruptive than anything our analytics script does.



  • @blakeyrat said:

    It also occurs in the Windows version, where Mozilla is responsible for the theme.
    ????

    Here's what mine looks like (Firefox 4 on Windows with the default Firefox Theme):


     That looks pretty reasonable to me.  However, I do agree that TRWFT is taking 5 years to fix something that could have been fixed in a few seconds.



  • @El_Heffe said:

    @blakeyrat said:

    It also occurs in the Windows version, where Mozilla is responsible for the theme.
    ????

    Here's what mine looks like (Firefox 4 on Windows with the default Firefox Theme):

    Yes. The bug report, which I've been trying to get people to read mentions that the bug is now fixed (by accident) in Firefox 4, due to the designer deciding to remove the buddy icon altogether.

    Reading is fundamental.



  • @blakeyrat said:

    Reading is fundamental.
    So is remembering what you orginally said, which was:

     @blakeyrat said:

    and unfixed in version 1, 2, 3, 4.
    It's fixed in v4.  Fixed by accident, but still fixed.



  • @El_Heffe said:

    @blakeyrat said:

    Reading is fundamental.
    So is remembering what you orginally said, which was:

     @blakeyrat said:

    and unfixed in version 1, 2, 3, 4.
    It's fixed in v4.  Fixed by accident, but still fixed.

    I was going to write a long rebuttal defending my position, but I think I'll just say the word "poop".

    Poop.



  •  I tagged your post as part of my ongoing duties.



  • You are an hero.



  • @blakeyrat said:

    @bridget99 said:
    But somehow this is not good enough for Microsoft, who 1) puts up a misleading "Not Responding" title when this happens, encouraging support calls

    How dare Microsoft tell users my buggy-ass application stopped responding to the UI thread! Why, I'm so angry I'm going to call the message "misleading" when in fact it's about the clearest error message Microsoft has ever written!

    @bridget99 said:

    2) throws up stupid, cryptic messages during development if an app running in debug mode doesn't pump messages and 3) bombards the web with propaganda about multithreaded UIs and how they're mandatory.

    Those bastards! Encouraging developers to write bug-free applications! They should be tarred and feathered!

    @bridget99 said:

    Well then... I'll just let Microsoft and its legion of fanboys explain to my boss why I have to spend extra time making sure my app pumps messages at all times, even while it's basically running a batch process.

    Dude, first of all, if you're writing apps that simple and using Win32 to do it, you're a gigantic fail. Shove it in .net and use a BackgroundWorker thread; that's what it's for. (You know, doing work. In the background.)

    Secondly, if it really is a batch process, put it in a fucking console app. Then you don't have a UI thread, then Microsoft won't gripe at you for not responding to UI messages. "Damn these screwdrivers! It makes it so hard to pound in these nails!"

    Thirdly, if you don't give a shit about the quality of your end-product to the extent that you're actually yelling at the OS maker for having the audacity to say "hey, you should probably give a shit about the quality of your end-product" at you during development... well... you really should enter another field. Maybe digging ditches. Or being a movie producer. You know, somewhere where it doesn't matter if you really give a shit or not.

    @bridget99 said:

    Anything less would be unprofessional. And programming is a profession, right?

    Not the way you're doing it. I actually kind of hope you're trolling.

    I just re-read this and it encapsulates perfectly what I call "The Microsoft Mentality." Right or wrong, there's a philosophical distinction here, at a very high level.



    You posit the existence of a certain category of "bug" in my program. This "bug" you assert consists of failing to pump messages.



    I would submit that this is not a bug. Allowing division-by-zero to occur, without at least squelching the resultant crash, is a bug. So is attempting to dereference a pointer whose value is zero (usually).



    What you accuse me of falls into a different category. I have made no logical error. Rather, I have taken an API (Win32), and written code that uses it to my own purposes.



    A user types some things into boxes and clicks a button. The program ceases interacting with the user and does some work. It doesn't purport to be doing anything other than what the user has requested of it, until it completes the request. This is actually pretty refreshing, to me. Programs do me no service by, for example, still pretending to be taking orders from me when they're really in no state to do so. (Why does Visual Studio allow me to edit the files it is compiling, for example?)



    All of this non-pumping code of mine looked good and behaved in reasonable fashion from Win16 (which for years did not even have threads) until the advent of Windows XP. Then, without any request for this change, Microsoft updated their API such that these programs displayed an embarrassing banner message. (Incidentally, this is equally true of both .NET and native applications... not sure what you meant by your "gigantic fail" comment; and I'm far from enthusiastic to your suggestion that I downgrade my apps to a console window... Gee, my boss would really be thrilled about that.)



    The question I would ask, rhetorically, is whether this embarrassing banner is an appropriate change for an API-builder to make. Remember, Win32 is an evolution of Win16, which did not even have distinct threads. Am I now required to go back and add threads - an exquisitely bug-prone feature - to the apps I originally wrote for Win16? Why should that even be encouraged (to say nothing of required)? Isn't that an irresponsible attitude to take toward code that's fulfilling its original purpose? And what was the point of the heroic efforts of Raymond Chen and his team if Win32 is allowed to break Win16?



    My answer to this line of questioning is that an API is just an API; creating an API does not give one right or reason to say how it ought to be used. Quite the opposite, in fact; API uses "discovered" by applications programmers ought to be nurtured by the API builder.



    Obviously, the API maker must at least attempt to specify the function of the underlying implementation. But breaking past versions is a cardinal sin. And to do what Microsoft did- to intentionally make working programs written against their API appear to be non-working- is offensive.



    I like to contrast the evolution of Windows with the evolution of UNIX. If Ken Thompson were more like Bill Gates, he would be lecturing us about the proper use of SafeGrepEX (regular GREP having long ago been deprecated in a speech by Dennis Ritchie), and would be trying to squeeze every last billion out of it. C would be a huge, multi-paradigm language (having long ago eaten both COBOL, LISP, and FORTRAN whole, to horrifying effect) and its use would be mandatory. Your cell phone would run "man," and the new X-Men movie would have a tie-in with X-Windows. "Pine" would have grown into a 9.5 gigabyte GUI application that runs your whole life on a minute-by-minute basis, and automatically schedules periodic reunions with your schoolmates.



    Thank God for decent human beings.



    I hinted above that there's an almost religious or at least philosophical difference in the way we approach this question. Computers to me are just a means to an end. I don't give a flip what other programmers think about my code. It doesn't matter if my colleagues think I'm unprofessional; from management's perspective, I'm the one who Gets Things Done. I'm "That Dude." I'm the one writing mind-blowing demos while you all write mind-numbing UML-based pornography.



    Of course, I'm scorned by other programmers as a result, but who cares? I could engage in Gang-of-Four style mental masturbation all day, too; or, I could slavishly follow every stupid Microsoft fad like a gerbil on a wheel. But where would it get me? It would just make me slow (and my code flabby) like all the other CRAP code out there, of which there is an abundance.



  • @bridget99 said:

    You posit the existence of a certain category of "bug" in my program. This "bug" you assert consists of failing to pump messages.

    If your GUI doesn't respond to user input and also doesn't indicate to the user that it's currently unresponsive to user input (for example, by greying out all the controls) it is buggy. I don't see how anybody could possibly claim otherwise.

    @bridget99 said:

    What you accuse me of falls into a different category. I have made no logical error. Rather, I have taken an API (Win32), and written code that uses it to my own purposes.

    Yeah, but if you don't want a GUI-- if you don't give a shit whether or not the GUI is responsive-- why did you tell the OS to create one for you? Windows has a concept of "console application", that is, an application with no GUI, only text input/output. Why didn't you use it? It's stupid to complain about Microsoft when they've already solved your problem, you just chose not to use the solution.

    If you do want a GUI, and the GUI is unresponsive, that is a bug. Period.

    Now, you could claim that Microsoft should make it literally impossible for the GUI to become unresponsive, for example, BeOS got pretty damned close to that ideal, but unfortunately Microsoft did not do that early in Windows' development, and now there's too many backwards compatibility issues to make it work. That is unfortunate. But, hey, guess what? Creating your own UI thread is just one of many of the "taxes" you have to pay when writing GUI apps.

    @bridget99 said:

    A user types some things into boxes and clicks a button. The program ceases interacting with the user and does some work. It doesn't purport to be doing anything other than what the user has requested of it, until it completes the request.

    Except if it's unresponsive, it can't respond to a request to cancel the task. (Maybe the user typoed the path and wants to stop it... oops too late! Your shit program has him trapped!) Which, again, is a bug. And what if the OS is shutting down? How is your program going to respond intelligently to a shutdown request if it's not responding to window manager messages? The answer is: it's not. BAM, there's another bug!

    @bridget99 said:

    All of this non-pumping code of mine looked good and behaved in reasonable fashion

    Obviously not, if it stops responding. It was buggy in Windows 3.x and it's buggy now. The only difference is that now Windows tells your users that it's buggy, so they aren't scratching their heads going, "what's up with this window? Clicking does nothing!"

    @bridget99 said:

    (Incidentally, this is equally true of both .NET and native applications... not sure what you meant by your "gigantic fail" comment;

    I'm pointing out that Win32 is a gigantic pain-in-the-ass for writing little GUI utilities. If you're using Win32 for that, you're wasting a ton of your company's time on retarded, complex, boilerplate you could be skipping if you used a more advanced environment, say, .net.

    @bridget99 said:

    and I'm far from enthusiastic to your suggestion that I downgrade my apps to a console window... Gee, my boss would really be thrilled about that.

    If you're not going to write a GUI that works, then don't fucking bother. Is what I'm saying.

    Take some fucking pride in your work, and write the program correctly. That's all I want-- if it's worth doing, it's worth doing right! Not half-assing.

    @bridget99 said:

    Remember, Win32 is an evolution of Win16, which did not even have distinct threads. Am I now required to go back and add threads - an exquisitely bug-prone feature - to the apps I originally wrote for Win16?

    Don't be stupid, and don't assume I'm stupid. I was writing apps in Classic Mac that somehow miraculously managed to keep the cooperative multitasking system humming away long before I knew what a fucking thread even was. You very well know the answer to this, better than I do probably (since I never programmed in Win16), so don't fucking ask.

    Somehow other developers of Win16 apps managed to keep up on the message pump without threads. Miracles? Magic? WHO KNOWS! But do what they did.

    @bridget99 said:

    Why should that even be encouraged (to say nothing of required)? Isn't that an irresponsible attitude to take toward code that's fulfilling its original purpose? And what was the point of the heroic efforts of Raymond Chen and his team if Win32 is allowed to break Win16?

    Look:

    1) Your code was WRONG in Win16 also. It's NEVER OK for a GUI app to stop processing messages, that's universally true in ALL versions of Windows. So stop acting like XP "broke" something that worked just fine before, because it didn't.

    2) Microsoft didn't break anything; in fact, it's improved your program by resolving the mystery of "hey why aren't these buttons working?" for the user. And you got this improvement for free! Whee

    @bridget99 said:

    My answer to this line of questioning is that an API is just an API; creating an API does not give one right or reason to say how it ought to be used. Quite the opposite, in fact; API uses "discovered" by applications programmers ought to be nurtured by the API builder.

    An API is a contract; you have to fulfill your end of the contract. You read Raymond Chen; this is what he's talking about when he mentions "programming taxes". One of those "taxes" is that if you have a message pump, you have to respond to messages in it. This is not new. Windows has always been this way. Windows is chiding you because you're not paying your taxes, you're not fulfilling your end of the API contract.

    @bridget99 said:

    Obviously, the API maker must at least attempt to specify the function of the underlying implementation. But breaking past versions is a cardinal sin. And to do what Microsoft did- to intentionally make working programs written against their API appear to be non-working- is offensive.

    Jesus. Your program was always wrong. It was wrong when you first wrote it. The only reason Windows is telling users that your program isn't working is that, from the user's point of view, your program isn't fucking working! They click in the window, nothing happens! That's pretty much the most succinct description of "not working" as I've ever heard.

    @bridget99 said:

    If Ken Thompson were more like Bill Gates, he would be lecturing us about the proper use of SafeGrepEX (regular GREP having long ago been deprecated in a speech by Dennis Ritchie),

    Yes; obviously Microsoft increasing the security of applications on their platform is a bad thing.

    @bridget99 said:

    C would be a huge, multi-paradigm language (having long ago eaten both COBOL, LISP, and FORTRAN whole, to horrifying effect) and its use would be mandatory.

    Because... C# is a huge multi-paradigm language? (Oh wait, no, it's actually rather small.) Because Microsoft forces people to use C#? (Oh wait, no, they don't do that at all, even within .net.) What the fuck!

    You can't just make shit up and call it an analogy.

    @bridget99 said:

    Your cell phone would run "man,"

    Because Windows Phone runs... wait what? What are you gibbering about?

    @bridget99 said:

    and the new X-Men movie would have a tie-in with X-Windows.

    Because Microsoft does movie tie-ins with Windows? Huh?

    @bridget99 said:

    "Pine" would have grown into a 9.5 gigabyte GUI application that runs your whole life on a minute-by-minute basis, and automatically schedules periodic reunions with your schoolmates.

    Because... Microsoft runs Classmates.com? Wha-huh?

    That was quite a barrage of confusion! Congrats!

    @bridget99 said:

    I don't give a flip what other programmers think about my code.

    I don't give a shit about your code. I care about your users, who are the people harmed by your laziness. What does rankle me is how you simply do not care that your program is buggy and seem to have no remorse or desire to fix it.

    @bridget99 said:

    It doesn't matter if my colleagues think I'm unprofessional;

    Dude, think back to Tron. Programs are for users. No programmer should ever give a holy shit what another programmer thinks, unless they're writing development tools.

    @bridget99 said:

    It would just make me slow (and my code flabby) like all the other CRAP code out there, of which there is an abundance.

    Your stuff is the crap!


  • ♿ (Parody)

    @blakeyrat said:


    If your GUI doesn't respond to user input and also doesn't indicate to the user that it's currently unresponsive to user input (for example, by greying out all the controls) it is buggy. I don't see how anybody could possibly claim otherwise.

    If you're not going to write a GUI that works, then don't fucking bother. Is what I'm saying.

    Don't be fucking retarded. His GUI works. It gets the job done. This is more or less equivalent to not handling window resizes gracefully. Get off your high horse. He's already got all of the boilerplate junk. It's been around for years. Why in the hell would he want to port stuff to .Net? The GUI is obviously not the key to this program, it's the stuff that it's doing behind the scenes. Why rewrite all of that into some other language when it's already working? That's a fucking retarded suggestion.

    Actually, it's not necessary to use threads. You just have to yield to the window manager occasionally so that repaints or whatever get handled. Still, you need to disable stuff that could cause problems (like editing files that are compiling). The easiest way is with a modal dialog that just allows the user to cancel, or watch a progress bar or something. Still, you're describing something that is more of a UI guideline or preference. It's not a fucking bug, just because you don't like it.

    TRWTF is assuming you need threads for something like this.



  • @boomzilla said:

    His GUI works.
     

    UIs should not freeze.

    @boomzilla said:

    This is more or less equivalent to not handling window resizes gracefully.

    Not handling resizes gracefully is more forgivable. Unless it's a small unresizeable window with a list of some sort. Then it's a case of Fuck Users.

     


  • ♿ (Parody)

    @dhromed said:

    @boomzilla said:
    His GUI works.

    UIs should not freeze.

    Look, I agree that it's better for GUIs to not freeze up while doing long tasks. So, poorly styled, less friendly than it could be: YES. Buggy: NO.

    It's not like his GUI has a button that does nothing, or crashes the program (as far as we know). It's just not amenable to blakeyrat sized attention spans. But not every app needs to be super duper shiny and polished.



  • @boomzilla said:

    Look, I agree that it's better for GUIs to not freeze up while doing long tasks. So, poorly styled, less friendly than it could be: YES. Buggy: NO.
     

    We have a different threshold for minimum acceptability, apparently.

    That's cool, but I still think you're wrong. UIs should not freeze. Ever.

    @boomzilla said:

    But not every app needs to be super duper shiny and polished.

    Yup. But in the time it took bridget99 to write all these posts, he could have put a spinner on the GUI. There. Done.



  • @dhromed said:

    UIs should not freeze. Ever.
    Absolutely - by definition. If it's frozen, it isn't a UI at that time because, obviously, the user can't interface with the system. Clearly, for a UI to become not-a-UI is a bug.



  • @intertravel said:

    @dhromed said:
    UIs should not freeze. Ever.
    Absolutely - by definition. If it's frozen, it isn't a UI at that time because, obviously, the user can't interface with the system. Clearly, for a UI to become not-a-UI is a bug.
     




  • @bridget99 said:

    All of this non-pumping code of mine looked good and behaved in reasonable fashion from Win16 (which for years did not even have threads) until the advent of Windows XP. Then, without any request for this change, Microsoft updated their API such that these programs displayed an embarrassing banner message. (Incidentally, this is equally true of both .NET and native applications... not sure what you meant by your "gigantic fail" comment; and I'm far from enthusiastic to your suggestion that I downgrade my apps to a console window... Gee, my boss would really be thrilled about that.)
    If there's anything I hate, it's Windows applications that do some processing, don't show that they're doing it, don't respond to clicks, and don't let me move their window out of the way. Luckily, Microsoft fixed this at the OS level with XP, where if you click such broken application a few times, it'll mark it as not responding, and let me move it away.
    Just because something was acceptable behaviour in Win16 era, it doesn't mean it still is 15 years after that era ended.



  • @ender said:

    Just because something was acceptable behaviour in Win16 era, it doesn't mean it still is 15 years after that era ended.

    It was the wrong thing to do at that time as well, but it was tolerated because it was harder to do.  Nowadays there is no fucking excuse.



  • @boomzilla said:

    Actually, it's not necessary to use threads. You just have to yield to the window manager occasionally so that repaints or whatever get handled.

     

    Have you ever heard of separation of concerns?  GUI code should not be intermingled in business logic, library code, or whatever you want to call it.  This is what makes VB 6 such a pain in the ass to use.  For anything that takes longer than a few hundred milliseconds, you have to make calls to DoEvents or your application seems unresponsive.  Multi-threading may not be needed, but it is definitely an excellent way to handle GUI code.



  • @boomzilla said:

    @blakeyrat said:

    If your GUI doesn't respond to user input and also doesn't indicate to the user that it's currently unresponsive to user input (for example, by greying out all the controls) it is buggy. I don't see how anybody could possibly claim otherwise.

    If you're not going to write a GUI that works, then don't fucking bother. Is what I'm saying.

    Don't be fucking retarded. His GUI works. It gets the job done.

    Ah, the old "gets the job done" canard.  That's the classic incompetent's definition of "working": it only actually amounts to "appears to be working".  No concept of correctness or validity is so much as contemplated.

    @boomzilla said:

    This is more or less equivalent to not handling window resizes gracefully. Get off your high horse. He's already got all of the boilerplate junk. It's been around for years. Why in the hell would he want to port stuff to .Net? The GUI is obviously not the key to this program, it's the stuff that it's doing behind the scenes. Why rewrite all of that into some other language when it's already working? That's a fucking retarded suggestion.

    Y'know, if you're going to throw the phrase "fucking retarded" around like confetti, you should really try not to come out with gibberish like this: 

    @boomzilla said:

    You just have to yield to the window manager occasionally so that repaints or whatever get handled.

    So, perhaps you'd like to explain:

    1) What exactly is "the window manager", i.e. which process in a running windows system you are referring to?

    2) How would it know what to paint in other process' windows for them?

    2) How exactly you would choose to yield to it rather than to any other process?

    3) Why exactly would yielding to it make a blind bit of difference when every version of windows since 95 has had pre-emptive multitasking?

    What you say may have meant something meaningful back in windows 3.11 days, but the world has in fact changed since then, and statements that were valid back then can become meaningless as a result of the things that have changed.

    FWIW I agree with Blakey on pretty much everything.  Bridget99's code was always wrong because it always violated the semantics of the win(16|32) GUI API.  MS have been saying since day one "whatever you do, never stop pumping messages".  Bridget99 has made the classic cowboy coder's mistake of observing a behaviour that is not guaranteed or defined by the API spec and falsely inferring that it could be relied on; but the behaviour observed was a mere accident of the implementation, and when the implementation changed Bridget's false assumption turned round and bit her.  If she had just done it right in the first place, she could have got forward-compatibility for free, but instead wrote something that was tied to what should have been a black-box detail of the underlying implementation.  That is fail.



  • ♿ (Parody)

    @frits said:

    @boomzilla said:

    Actually, it's not necessary to use threads. You just have to yield to the window manager occasionally so that repaints or whatever get handled.

     

    Have you ever heard of separation of concerns?  GUI code should not be intermingled in business logic, library code, or whatever you want to call it.  This is what makes VB 6 such a pain in the ass to use.  For anything that takes longer than a few hundred milliseconds, you have to make calls to DoEvents or your application seems unresponsive.  Multi-threading may not be needed, but it is definitely an excellent way to handle GUI code.

    Yes, I'm familiar with this concept, but as with everything else, there are limits. If the only purpose of having a multithreaded app is to keep a spinner going while you do some processing, you're probably making life more difficult for yourself than you need to. Especially when it comes to legacy stuff like we're discussing.


  • ♿ (Parody)

    @DaveK said:

    @boomzilla said:

    @blakeyrat said:


    If your GUI doesn't respond to user input and also doesn't indicate to the user that it's currently unresponsive to user input (for example, by greying out all the controls) it is buggy. I don't see how anybody could possibly claim otherwise.

    If you're not going to write a GUI that works, then don't fucking bother. Is what I'm saying.

    Don't be fucking retarded. His GUI works. It gets the job done.

    Ah, the old "gets the job done" canard.  That's the classic incompetent's definition of "working": it only actually amounts to "appears to be working".  No concept of correctness or validity is so much as contemplated.

    @boomzilla said:

    This is more or less equivalent to not handling window resizes gracefully. Get off your high horse. He's already got all of the boilerplate junk. It's been around for years. Why in the hell would he want to port stuff to .Net? The GUI is obviously not the key to this program, it's the stuff that it's doing behind the scenes. Why rewrite all of that into some other language when it's already working? That's a fucking retarded suggestion.

    Y'know, if you're going to throw the phrase "fucking retarded" around like confetti, you should really try not to come out with gibberish like this: 

    Well, mostly "fucking retarded" was thrown in there because it seems to be the language that blakey understands. And I like to overreact to his overreactions.

    @DaveK said:

    @boomzilla said:
    You just have to yield to the window manager occasionally so that repaints or whatever get handled.

    So, perhaps you'd like to explain:

    1) What exactly is "the window manager", i.e. which process in a running windows system you are referring to?

    2) How would it know what to paint in other process' windows for them?

    Are you being serious? Many frameworks have some sort of function for this. Essentially, in windows, it's just taking a break from processing to pump some messages. In VB, for instance, DoEvents, as frits brought up. Yield is a common metaphor for this sort of thing. See, for instance, wxWidgets.

    @DaveK said:

    2) How exactly you would choose to yield to it rather than to any other process?

    3) Why exactly would yielding to it make a blind bit of difference when every version of windows since 95 has had pre-emptive multitasking?

    See above.



  • @boomzilla said:

    @frits said:

    @boomzilla said:

    Actually, it's not necessary to use threads. You just have to yield to the window manager occasionally so that repaints or whatever get handled.

     

    Have you ever heard of separation of concerns?  GUI code should not be intermingled in business logic, library code, or whatever you want to call it.  This is what makes VB 6 such a pain in the ass to use.  For anything that takes longer than a few hundred milliseconds, you have to make calls to DoEvents or your application seems unresponsive.  Multi-threading may not be needed, but it is definitely an excellent way to handle GUI code.

    Yes, I'm familiar with this concept, but as with everything else, there are limits. If the only purpose of having a multithreaded app is to keep a spinner going while you do some processing, you're probably making life more difficult for yourself than you need to. Especially when it comes to legacy stuff like we're discussing.

    The purpose of having a multithreaded app is two-fold:  1. To continue processing windows events,  and 2.  to be able to write my code in a simple way that is only concerned with the task at hand. If you think handling non-GUI stuff in a single different thread is too much trouble, then do as Blakey said and use a console app.

     



  • @boomzilla said:

    Yes, I'm familiar with this concept, but as with everything else, there are limits. If the only purpose of having a multithreaded app is to keep a spinner going while you do some processing, you're probably making life more difficult for yourself than you need to. Especially when it comes to legacy stuff like we're discussing.

    It still needs to respond to users canceling the task. Or, in the extremely extremely remote possibility the task is actually un-cancelable, it still needs to respond intelligently when the OS says, "hey, last call, drink up, I'm-a shutting down!" So it's still a bug.

    In any case, I don't need to write a long reply here because other people have taken care of it, but I would like to emphasize a couple points:

    1) Bridget's app was always broken. Microsoft's adding a message saying that the app is broken doesn't change the fact that it was broken.

    2) You don't need threads to keep the UI responsive; that's only the modern technique. The old Win16 "yield time to OS" function still works. (In Mac Classic, it was "WaitNextEvent()"*, I dunno what it was in Win16.)

    On point 1, Bridget is kind of like those people who complained that Vista suddenly stopped letting apps write data files to their own Program Files directory. Well... guess what? If your app was doing that, it was always broken on WinNT, even back to NT4. That's always been a rule, and you were only getting away with it because you were a shitty programmer who only tested their app using an Administrator account. The only difference between Windows 2000 and Vista is that Vista actually provides a method (UAC) to make your busted-ass app run on a limited account, and Windows 2000 would just fail. Which is another case of exactly this: Microsoft handling your broken-ass app better, and developers complaining about it.

    *) You passed in a "get back to me" param to WaitNextEvent, so if your program was doing absolutely nothing but waiting for user input, you could pass in MaxInt and Mac Classic would basically just "sleep" your app until something happened. If you were doing some animation, you set the delay to whatever the timing of the animation required. If you were doing hard work you could pass, IIRC, -1 which means "ok let other apps do their thing, but give me attention ASAP." It was a slick, simple, system. There's probably kiddie programmers starting work now who *never* wrote code on a cooperatively-multitasked system... scary.



  • You don't need threads. If it's an MFC application, this is all you need to put in the loop that's running over your input or whatever:

    MSG msg;
    while (::PeekMessage(&msg, NULL, NULL, NULL, PM_REMOVE)) { // pump messages until none are left in the queue
        DispatchMessage(&msg);
        if (msg.message == WM_QUIT || msg.message == WM_CLOSE) // adjust this part as appropriate
            break;
    }
    

    Translating that to straight Win32 is left as an exercise.



  • @DaveK said:

    Bridget99 has made the classic cowboy coder's mistake of observing a behaviour that is not guaranteed or defined by the API spec and falsely inferring that it could be relied on;
    Well, not quite.

    @bridget99 said:

    Quite the opposite, in fact; API uses "discovered" by applications programmers ought to be nurtured by the API builder.
    I could understand doing this as a mistake. But I find it scary that people actually embrace this as a philosophy.

     

    <side rant>

    And yes, I know this seems to be a rather widespread view in the unix world. This is why

    ifconfig | grep 'inet addr:'
    is the commonly accepted way to get the current IP address in a shell script and
    ls -1 | wc -l
    to get the number of files in a directory. Very creative, very concise and works absolutely great if your directory contains > 10.000 files.

    The unix philosophy of "do one thing and do it well" is awesome. The philosophy that proper interfaces between those tools are not necessary, because coders can just "discover" uses like this, not so much.

    </side rant>

     



  • I do like that about Unix tools. In fact, I'd like to see a standardised interface for switches and parameters which can be supplied as either text or as a GUI making them dual-purpose.



  • Perhaps relevant to your interests:

    Raymond Chen's blog contains an interesting discussion of open source vs. closed source APIs, with Raymond basically taking the position that if you opened up the source even *more* developers would ignore the contract and call into undocumented, implementation-detail functions and it would be impossible to ever change anything in the system at all. Various other users contest this. I'm inclined towards Raymond's point of view.

    For example:

    @PSWorx said:

    <side rant>

    And yes, I know this seems to be a rather widespread view in the unix world. This is why

    ifconfig | grep 'inet addr:'
    is the commonly accepted way to get the current IP address in a shell script and
    ls -1 | wc -l
    to get the number of files in a directory. Very creative, very concise and works absolutely great if your directory contains > 10.000 files.

    The unix philosophy of "do one thing and do it well" is awesome. The philosophy that proper interfaces between those tools are not necessary, because coders can just "discover" uses like this, not so much.

    </side rant>

    Let's say a program wants to grab your IP address for whatever reason. Let's assume they use that method to do it. (I'm sure that's the wrong method, but bear with me.) Now you're in a shit sandwich where changing the output text of the ifconfig tool, or hell shipping a Linux distribution that doesn't even have an ifconfig tool, will break some random program somewhere. Or what if the Linux distribution doesn't have grep? Or what if the params to grep change? (Of course, the Linux community solves this by: 1) acting as if it's 1973 at all times, and 2) not giving one whit for backwards-compatibility in the first place.)

    If you make a bunch of little tools that all rely on other little tools, you've made it impossible to change what any of the little tools do, or how they're called. If you can't change them, you can't improve them. Sounds like a bad idea to me, but hey, I don't run Linux.


  • ♿ (Parody)

    @blakeyrat said:

    Raymond Chen's blog contains an interesting discussion of open source vs. closed source APIs, with Raymond basically taking the position that if you opened up the source even more developers would ignore the contract and call into undocumented, implementation-detail functions and it would be impossible to ever change anything in the system at all. Various other users contest this. I'm inclined towards Raymond's point of view.

    To a certain extent, this is true. OTOH, part of the idea of open source is that you're not completely reliant on the original developer to fix or add something in the future.* Of course, some of that activity can actually lead to improvements or fixes, so it's not all bad.

    @blakeyrat said:

    Let's say a program wants to grab your IP address for whatever reason. Let's assume they use that method to do it. (I'm sure that's the wrong method, but bear with me.) Now you're in a shit sandwich where changing the output text of the ifconfig tool, or hell shipping a Linux distribution that doesn't even have an ifconfig tool, will break some random program somewhere. Or what if the Linux distribution doesn't have grep? Or what if the params to grep change? (Of course, the Linux community solves this by: 1) acting as if it's 1973 at all times, and 2) not giving one whit for backwards-compatibility in the first place.)

    If you make a bunch of little tools that all rely on other little tools, you've made it impossible to change what any of the little tools do, or how they're called. If you can't change them, you can't improve them. Sounds like a bad idea to me, but hey, I don't run Linux.

    It's only impossible if you have as little imagination as a Windows fanboi. You could always simply add a switch or something to get some other type of output. OMFG, that was hard! And you even still have backwards compatibility!

    * Nitpicker's corner: Of course, it's not always as easy as it sounds, etc, etc, etc. But still easier than updating a closed source program. At the very least, possible to do legally.



  • Surely if you wanted additional functionality you'd add another program? Otherwise, you're breaking the "do one thing and do it well" rule as well as introducing a new kind of backwards compatibility issue akin to DLL hell.



  • @boomzilla said:

    It's only impossible if you have as little imagination as a Windows fanboi. You could always simply add a switch or something to get some other type of output. OMFG, that was hard! And you even still have backwards compatibility!

    And what about change number 2? Another switch? Do you duplicate the entire code of the tool, so you can keep track of how it's supposed to behave for each switch? What if compatibility was broken for security reasons, do you still allow programs to call into the insecure version? What about the person using the tool? They always want the newest version, so they always have to add the /v2 switch every time they use it?

    It's not nearly as simple as you imply.

    A better solution would be to store the data in some sort of system-wide database, and have the CLI (and GUI) programs be able to call into it using a well-documented and stable API. Instead of asking a tool like ifconfig, you just query the OS directly. That requires separating the UI from the underlying logic, which you'd think would be one of those cute little Linux "rules", but apparently isn't.

    @boomzilla said:

    * Nitpicker's corner: Of course, it's not always as easy as it sounds, etc, etc, etc. But still easier than updating a closed source program.

    The best solution is one where the closed source (and open source for that matter) program doesn't need to be updated. Which is the system Microsoft's doing their best to build, which is why Windows 7 can run Visicalc 1.0.


  • ♿ (Parody)

    @blakeyrat said:

    @boomzilla said:
    It's only impossible if you have as little imagination as a Windows fanboi. You could always simply add a switch or something to get some other type of output. OMFG, that was hard! And you even still have backwards compatibility!

    And what about change number 2? Another switch? Do you duplicate the entire code of the tool, so you can keep track of how it's supposed to behave for each switch? What if compatibility was broken for security reasons, do you still allow programs to call into the insecure version? What about the person using the tool? They always want the newest version, so they always have to add the /v2 switch every time they use it?

    So, are you for or against backward compatibility? It's hard to keep up sometimes. You were the one who asked about changes to the output, and what about backward compatibility. This is not a new concept. There are even tools that cause the program to work like the BSD version (ps comes to mind). I guess it's not very different from flipping a new configuration switch in a GUI.

    @blakeyrat said:

    A better solution would be to store the data in some sort of system-wide database, and have the CLI (and GUI) programs be able to call into it using a well-documented and stable API. Instead of asking a tool like ifconfig, you just query the OS directly. That requires separating the UI from the underlying logic, which you'd think would be one of those cute little Linux "rules", but apparently isn't.

    Now you're confusing the source of the data with a particular way to query it. That's all, e.g., ifconfig is. ifconfig isn't the keeper of the data. But you're right that there's not One Tool to Query Them All. Well, I guess you could just use grep for that, since everything is a file.

    @blakeyrat said:

    @boomzilla said:
    * Nitpicker's corner: Of course, it's not always as easy as it sounds, etc, etc, etc. But still easier than updating a closed source program.

    The best solution is one where the closed source (and open source for that matter) program doesn't need to be updated. Which is the system Microsoft's doing their best to build, which is why Windows 7 can run Visicalc 1.0.

    Well, some versions can, I suppose. I would imagine that's 16-bit code, so you won't be running that on a 64-bit machine without rebuilding it in at least 32-bit mode. I'm not saying that MS doesn't do a great job with backwards compatibility, but there are limits to what they can accomplish, and we or they don't even know what the limits all are. Of course, they pretty much have to do that, given that most of the MS ecosystem is closed source.



  • @boomzilla said:

    So, are you for or against backward compatibility? It's hard to keep up sometimes. You were the one who asked about changes to the output, and what about backward compatibility.

    For, obviously.

    @boomzilla said:

    This is not a new concept. There are even tools that cause the program to work like the BSD version (ps comes to mind). I guess it's not very different from flipping a new configuration switch in a GUI.

    I think you lost me. Are you saying the only way for the CLI to be backwards-compatible is to flip a switch that changes the behavior of the entire system to the old behavior? That's the best you got?

    @boomzilla said:

    That's all, e.g., ifconfig is. ifconfig isn't the keeper of the data.

    Yah I figured that, which is the "bear with me" up a few posts back.

    What you really need is something like the "Gestalt" database in Mac Classic.

    @boomzilla said:

    Well, I guess you could just use grep for that, since everything is a file.

    Do all the files have the same format? How do you handle a case where two tools want to change the file at the same time? Is there intelligent locking? Revision control? Can you use a file/files on a remote computer, for example, if you want to boot the system from a disk?

    "Everything is a file" also sounds like a shitty solution to me.

    @boomzilla said:

    Of course, they pretty much have to do that, given that most of the MS ecosystem is closed source.

    They have to do that because they actually want people to use their OS. It has nothing to do with closed vs. open.


  • ♿ (Parody)

    @blakeyrat said:

    @boomzilla said:
    This is not a new concept. There are even tools that cause the program to work like the BSD version (ps comes to mind). I guess it's not very different from flipping a new configuration switch in a GUI.

    I think you lost me. Are you saying the only way for the CLI to be backwards-compatible is to flip a switch that changes the behavior of the entire system to the old behavior? That's the best you got?

    Look, you were asking about what if you wanted to change the output of some tool. You brought up the issue of backwards compatibility. I suppose you could build an entirely new tool, but that's probably overkill. Maybe not, depending on how radically different you want the new thing to be. How is adding a new switch terribly different than having GetIpAddress() and adding GetIpAddressEx()?

    That seems to be one of the main ways Windows keeps backwards compatibility. Is that the best they've got? What else would you do? I mean, I guess you can go the compatibility shim route, but that's a whole nother ball of wax. Plus, you've still gotta be worth it for them to make a shim for you. And if your use case doesn't fit within whatever they're willing to do, you're SOL.

    @blakeyrat said:

    @boomzilla said:
    That's all, e.g., ifconfig is. ifconfig isn't the keeper of the data.

    Yah I figured that, which is the "bear with me" up a few posts back.

    What you really need is something like the "Gestalt" database in Mac Classic.

    @boomzilla said:

    Well, I guess you could just use grep for that, since everything is a file.

    Do all the files have the same format? How do you handle a case where two tools want to change the file at the same time? Is there intelligent locking? Revision control? Can you use a file/files on a remote computer, for example, if you want to boot the system from a disk?

    "Everything is a file" also sounds like a shitty solution to me.

    I'm not sure what standard format they would or do use. Does it make sense to say that your network connection file is in the same format as the data for a process? You'd have different format (i.e., fields) if you had stuff stored in a database, too, because it's all different information. Everything is a file has its advantages. The alternative is having stuff like the Windows registry, which has its own pros and cons.

    @blakeyrat said:

    They have to do that because they actually want people to use their OS. It has nothing to do with closed vs. open.


    Yes, they want people to use their OS. But also, whether you'll admit it or not, is the fact that most of the stuff their users use is closed source, and so it's not easy to change all of that when something in the OS changes. You have the same problem with closed source stuff on any system.



  • @blakeyrat said:

    "Everything is a file" also sounds like a shitty solution to me.
    Actually, it sounds like SSDS.



  • @boomzilla said:

    Look, you were asking about what if you wanted to change the output of some tool. You brought up the issue of backwards compatibility. I suppose you could build an entirely new tool, but that's probably overkill. Maybe not, depending on how radically different you want the new thing to be. How is adding a new switch terribly different than having GetIpAddress() and adding GetIpAddressEx()?
     

    You could, for example, have defined a sane, standard output format for, ifconfig and friends in the first place, instead just writing human-readable text to STDOUT and then later, when people start to parse it, going "oh yeah, it gets the job done, so I guess that's how we'll do it from now on".

    For some reason, GetIpAddress() got by with one compat switch during the whole line of Windows OSses, so far. On the other hand, my current version of [code]ls[/code] has switches for no less than seven(!) different output formattings, even though its core task never got more complex than "return a list of file names".



  • @boomzilla said:

    I'm not sure what standard format they would or do use. Does it make sense to say that your network connection file is in the same format as the data for a process?

    Sure; why not? The main thing is you don't want to have 23,000 different parsers on the system, all of which are subtly different. Which is exactly why Microsoft stopped using .ini files.

    @boomzilla said:

    Does it make sense to say that your network connection file is in the same format as the data for a process? You'd have different format (i.e., fields) if you had stuff stored in a database, too, because it's all different information.

    You can do what Microsoft and OS X do and use an extensible schema (Registry hives and XML, respectively). At least that way there's only one parser involved.

    @boomzilla said:

    Everything is a file has its advantages.

    It also has significant disadvantages, some of which I mentioned above. Linux seems to have the added disadvantage that there's no standard format for these files. Both Linux and OS X have the concurrency issues, when two programs are modifying the same file at the same time, which the Windows registry solves. (You can argue about how well it solves the issue, but at least it's trying.)

    @boomzilla said:

    The alternative is having stuff like the Windows registry, which has its own pros and cons.

    The cons are:

    1) Limited data types (you can't easily store an image in it, for example)

    2) Poor export/import-ability

    I don't know of any other cons that don't also apply to .ini or .xml files.

    @boomzilla said:

    Yes, they want people to use their OS. But also, whether you'll admit it or not, is the fact that most of the stuff their users use is closed source, and so it's not easy to change all of that when something in the OS changes. You have the same problem with closed source stuff on any system.

    If you want people to use your system, your system has to run closed-source software.


  • Discourse touched me in a no-no place

    @PSWorx said:

    And yes, I know this seems to be a rather widespread view in the unix world. This is why

    ifconfig | grep 'inet addr:'
    is the commonly accepted way to get the current IP address in a shell script
    Seriously? You have to be kidding me...

    [pjh@sofa ~]$ ssh laptop.work
    Last login: Mon Jun 27 19:43:50 2011 from xps.work.pjh
    [pjh@xps ~]$ ssh 6.<subsystem>
    [root@<6.<subsystem>> ~]# ifconfig | grep 'inet addr:'
              inet addr:192.168.98.1  Bcast:192.168.98.255  Mask:255.255.255.0
              inet addr:192.168.224.56  Bcast:192.168.224.255  Mask:255.255.255.0
              inet addr:172.16.1.250  Bcast:172.16.1.255  Mask:255.255.255.0
              inet addr:192.168.100.1  Bcast:192.168.100.255  Mask:255.255.255.0
              inet addr:10.6.20.1  Bcast:10.6.20.255  Mask:255.255.255.0
              inet addr:10.6.0.1  Bcast:10.6.15.255  Mask:255.255.240.0
              inet addr:10.6.30.1  Bcast:10.6.30.255  Mask:255.255.255.0
              inet addr:172.19.52.1  Bcast:172.19.52.255  Mask:255.255.255.0
              inet addr:166.<elided>  P-t-P:166.<elided>  Mask:255.255.255.255
              inet addr:32.<elided>  P-t-P:32.<elided>  Mask:255.255.255.255
              inet addr:32.<elided>  P-t-P:32.<elided>  Mask:255.255.255.255
              inet addr:26.<elided>  P-t-P:26.<elided>  Mask:255.255.255.255
              inet addr:127.0.0.1  Mask:255.0.0.0
              inet addr:192.168.61.6  P-t-P:192.168.61.254  Mask:255.255.255.255
              inet addr:192.168.62.6  P-t-P:192.168.62.254  Mask:255.255.255.255
              inet addr:192.168.63.6  P-t-P:192.168.63.254  Mask:255.255.255.255
              inet addr:192.168.64.6  P-t-P:192.168.64.254  Mask:255.255.255.255
              inet addr:192.168.65.6  P-t-P:192.168.65.254  Mask:255.255.255.255
              inet addr:192.168.66.6  P-t-P:192.168.66.254  Mask:255.255.255.255
              inet addr:192.168.67.6  P-t-P:192.168.67.254  Mask:255.255.255.255
              inet addr:192.168.68.6  P-t-P:192.168.68.254  Mask:255.255.255.255
              inet addr:192.168.69.6  P-t-P:192.168.69.254  Mask:255.255.255.255
              inet addr:72.<elided>  P-t-P:68.<elided>  Mask:255.255.255.255
              inet addr:75.<elided>  P-t-P:66.<elided>  Mask:255.255.255.255
              inet addr:108.<elided>  P-t-P:68.<elided>  Mask:255.255.255.255
              inet addr:107.<elided>  P-t-P:68.<elided>  Mask:255.255.255.255
    

    There are 22 hosts in <subsystem> - and that's just one subsystem - I work with others that have up to 50+ hosts that have similar outputs.

    Even on my work laptop (the 2nd host above):

    [pjh@xps ~]$ ifconfig | grep 'inet addr:'
              inet addr:172.16.4.130  Bcast:172.16.4.255  Mask:255.255.255.0
              inet addr:127.0.0.1  Mask:255.0.0.0
              inet addr:172.16.3.196  Bcast:172.16.3.255  Mask:255.255.255.0
    


  • I'm confused as to what you're trying to say, specifically.


  • Discourse touched me in a no-no place

    @Sutherlands said:

    I'm confused as to what you're trying to say, specifically.

    That the idiom of "ifconfig | grep 'inet addr:' gets you the current IP address" is wrong, because (I presume) it assumes the first address is 'it' with only one more of 127.0.0.1 (after the first) being present.



    Which address is "the current IP address" in the first example I quoted for example? In this particular instance, any of the 192.168.60.0/22 addresses would be the right one. Any of the public IP's which have <elided> in them would most certainly be a wrong IP address to pick. 192.168.98.1 (the first one) would be certainly wrong, because (again, in this instance) it happens to be acting as a link-local address.


Log in to reply