Re: Meld 1.8.1 released



I think it's because they're not Python apps.  The problem is if you call Meld with pythonw.exe (which hides the command prompt), it doesn't wait for the process to end before returning an exit code.  The only way I've seen to get an exit code is by calling with python.exe, which will create a command prompt window.  Another idea I had to avoid having 2 wrappers is to have the first argument to the wrapper be some special maker to tell it to use python.exe (and let the default be pythonw.exe), and have it eat that arg before starting Meld with the rest of the args.  Opinions?

-Keegan


On Sat, Sep 28, 2013 at 4:10 AM, Angel Ezquerra <angel ezquerra gmail com> wrote:
That is a good point, but personally I would hate even more to get a
command prompt every time I open the diff tool.

Version Control Tools use diff such as meld for two things: diffing
and merging. I don't think that tools usually need the exit code when
using meld for diffing. For merging it would be nice to get the exit
code though. Currently TortoiseHg will simply ask the user if the
merge was successful, but with other tools this is not necessary.

I don't quite understand why other tools (e.g. KDiff3, WinMerge) do
not have this problem. These are GUI tools but they can keep
TortoiseHg (or whoever calls the tool) waiting for the exit code until
they are done, but they do not show a command prompt. Is this a
fundamental problem in how meld is wrapped on windows?

Cheers,

Angel



On Tue, Sep 24, 2013 at 4:10 PM, Keegan Witt <keeganwitt gmail com> wrote:
> That's true, but wouldn't you want tools like that to be aware of when the
> merging process has ended?  If I call pythonw, it will appear to the tool
> calling the process that the process ended immediately.  This also means the
> status code returned by pythonw is worthless since it will always be 0.
> Isn't that an issue for these tools as well?  Sorry for my ignorance, I
> don't use Meld for that.
>
> I agree that it stinks that a separate window will now be opened, but
> otherwise the calling process loses information about the status of the
> process it called.  I was thinking too of how this might be in a script that
> helps a user do some larger workflow.  If it exits immediately (and/or with
> a worthless status code), the script wouldn't know whether to proceed or not
> with the next steps.
>
> -Keegan
>
>
> On Tue, Sep 24, 2013 at 9:24 AM, Angel Ezquerra <angel ezquerra gmail com>
> wrote:
>>
>> Hi,
>>
>> personally I think this change (calling python.exe rather than
>> pythonw.exe) will be a serious regression when using meld with a tool
>> such as TortoiseHg. TortoiseHg _always_ calls meld with parameters.
>> This means that every time that you would use meld to diff or merge
>> files from TortoiseHg (or any similar tool) you'd see a prompt window
>> appear.
>>
>> Cheers,
>>
>> Angel
>>
>>
>>
>> On Tue, Sep 24, 2013 at 10:35 AM, Keegan Witt <keeganwitt gmail com>
>> wrote:
>> > Sorry for the delay.  Someone reported that GTK wouldn't load for him
>> > and I
>> > was hoping to track that down why before updating the binaries.  I
>> > haven't
>> > figured it out (it doesn't help that I've not been able to recreate the
>> > issue), but I've decided to go ahead and release new ones in the mean
>> > time.
>> > Has anyone else experienced this issue?  Have an suggestions?  I've
>> > already
>> > tried having him clear his path before calling the Python from Portable
>> > Python with the absolute paths (which didn't help), though he is able to
>> > run
>> > the GTK demo.
>> >
>> > Besides the update to 1.8.1, I also now call python.exe instead of
>> > pythonw.exe when calling meld.exe with parameters.  This allows you to
>> > call
>> > Meld from the commandline without pythonw exiting right away (the only
>> > downside being that a dialog box for python appears in that case -- not
>> > sure
>> > there's really a way around this).  When calling without parameters (for
>> > example from shortcuts), it continues to call pythonw.  The issue list
>> > for
>> > this installer release can be seen here.
>> >
>> > -Keegan
>> >
>> >
>> > On Sat, Sep 21, 2013 at 7:08 PM, Kai Willadsen <kai willadsen gmail com>
>> > wrote:
>> >>
>> >> Meld 1.8.1 has been released.
>> >>
>> >>
>> >>   Fixes:
>> >>
>> >>     * Add AppData file (Kai Willadsen)
>> >>     * Change order of version control selection for CVS and old SVN
>> >> (Kai
>> >>       Willadsen)
>> >>     * Fix escaped markup in folder comparisons (Kai Willadsen)
>> >>
>> >>   Translations:
>> >>
>> >>     * Daniel Mustieles (es)
>> >>     * Enrico Nicoletto (pt_BR)
>> >>     * Gabor Kelemen (hu)
>> >>     * Marek Černocký (cs)
>> >>     * Milo Casagrande (it)
>> >>     * Piotr Drąg (pl)
>> >>
>> >>
>> >> This release can be downloaded from:
>> >>
>> >> http://download.gnome.org/sources/meld/1.8/meld-1.8.1.tar.xz
>> >>
>> >>
>> >> What is Meld?
>> >> -------------
>> >>
>> >> Meld is a visual diff and merge tool. It lets you compare two or three
>> >> files,
>> >> and updates the comparisons while you edit them in-place. You can also
>> >> compare
>> >> folders, launching comparisons of individual files as desired. Last but
>> >> by
>> >> no
>> >> means least, Meld lets you work with your current changes in a wide
>> >> variety of
>> >> version control systems, including Git, Bazaar, Mercurial, Subversion
>> >> and
>> >> CVS.
>> >> _______________________________________________
>> >> meld-list mailing list
>> >> meld-list gnome org
>> >> https://mail.gnome.org/mailman/listinfo/meld-list
>> >
>> >
>> >
>> > _______________________________________________
>> > meld-list mailing list
>> > meld-list gnome org
>> > https://mail.gnome.org/mailman/listinfo/meld-list
>
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]