#254 wgnuplot: open file-open-dialog in current dir

closed-accepted
None
2
2006-08-09
2006-06-13
No

Windows XP to me has a very special sense of humour
when it comes to what to set as initial directory for
the file open dialog. See 'lpstrInitialDir' on
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/WinUI/WindowsUserInterface/UserInput/CommonDialogBoxLibrary/CommonDialogBoxReference/CommonDialogBoxStructures/OPENFILENAME.asp

This patch forces the dialog to always open in the
current directory. So now, if you change the directory
via 'cd' the file open dialog opens where I would
expect it to.

On the other hand this introduces the alien concept of
a 'current directory' to the common windows user, who
are used to the weird windows behaviour.

Discussion

  • Logged In: YES
    user_id=1333817

    Confirmed working as expected, but I have no strong opinion
    whether it is the expected behaviour. Can be included in 4.2.

     
  • Logged In: YES
    user_id=1333817

    Confirmed working as expected, but I have no strong opinion
    whether it is the expected behaviour. Can be included in 4.2.

     
  • Petr Mikulik
    Petr Mikulik
    2006-06-29

    • priority: 5 --> 9
     
  • Petr Mikulik
    Petr Mikulik
    2006-06-29

    Logged In: YES
    user_id=31505

    I think this patch should come in, if it makes gnuplot on
    WXP compatible to gnuplot on other W*.

    Notes:
    1. Please change CRLF => LF in your patch.

    2. When compiled by mingw, the compiler reports:

    win/wmenu.c: In function `SendMacro':
    win/wmenu.c:402: warning: passing arg 1 of `_getcwd' from
    incompatible pointer type

    Please fix this.

     
  • Logged In: YES
    user_id=27517

    The problem, Petr, is that there are two wildly conflicting
    goals here. Should wgnuplot behave like gnuplot on other
    platforms, or should it feel like a typical Windows
    application? Both positions have strong arguments speaking
    for them. The code has behaved as it does now since just
    about forever, and hardly anybody found that behaviour
    strange enough to complain to us about it.

    As I've said before about this issue, Microsoft has gone to
    such trouble to come up with this unbelievably bizarre
    behaviour that we really shouldn't deprive users from
    reaping its benefit in the fullest. People believe M$ is a
    good thing --- let them get what they asked for.

    IMHO this is not a decision to be taken lightly, on a tight
    schedule. This can easily wait till after the release. I'm
    rating this down to priority 5 on that basis.

     
    • priority: 9 --> 5
    • assigned_to: nobody --> broeker
     
  • Petr Mikulik
    Petr Mikulik
    2006-07-03

    Logged In: YES
    user_id=31505

    As I understand from the patch report, this patch makes
    wgnuplot's "Open" menu item on Windows XP working in the
    same way on other versions of Windows. I've tried the patch
    on Wine, and I don't see any different behaviour between
    patched and unpatched wgnuplot's. So it is a WXP-specific
    fix (someone else can proove it?), that's why it should go
    in. (Note: WXP was a very fresh software when gnuplot 4.0
    appeared.)

     
  • Logged In: YES
    user_id=27517

    > As I understand from the patch report, this patch makes
    > wgnuplot's "Open" menu item on Windows XP working
    > in the same way on other versions of Windows.

    Not really. It would make wgnuplot behave like non-Windows
    gnuplot, and completely different than wgnuplot used to
    behave until now, on any version of Windows.

    And no, it's not a "WXP-specific fix". It's not a fix at
    all. It's a deliberate change of a behaviour that's not
    broken. And I really think this is not the time to check in
    such changes.

     
  • Ethan Merritt
    Ethan Merritt
    2006-07-13

    • priority: 5 --> 2
     
  • Ethan Merritt
    Ethan Merritt
    2006-07-13

    Logged In: YES
    user_id=235620

    Revisit post-4.2

     
  • Logged In: YES
    user_id=1180072

    Oter platforms do not even have a "file open" dialog. So
    in no way wgnuplot can behave like other platforms in
    this respect.
    But anyway consistency is a good thing in my opinion. ;)

    Look at the following example: Let's say a user changes
    directory using the "cd" command or the "change directory"
    dialog. The he would like to "load" a certain file.
    Wgnuplot does not have command line completion so he
    opts for the dialog. But wait: that shows a completely
    different directory. :(

    I think that behaviour is broken. In fact it annoys me
    quite a bit. And yes, its a change in behaviour. And yes,
    it really is specific to 2000/XP in the case described
    above. Microsoft changed the behaviour of it's dialog
    (see the link in my original post), which makes it
    inconsistent with gnuplot current directory. That may
    just as well be a called a fix then.

    I still vote for inclusion in 4.2.

     
  • Petr Mikulik
    Petr Mikulik
    2006-07-21

    Logged In: YES
    user_id=31505

    I propose to submit the patch into cvs (now, not after 4.2...).

     
  • Petr Mikulik
    Petr Mikulik
    2006-08-09

    Logged In: YES
    user_id=31505

    Committed to cvs.

     
  • Petr Mikulik
    Petr Mikulik
    2006-08-09

    • status: open --> closed-accepted