Xavier Nodet | 3 Oct 2002 13:07
Picon
Favicon

Re: [Bug 700] New: create temp files in $TMP and with fixed extension

On Sun, 22 Sep 2002 15:34:15 -0700 bugzilla-daemon <at> users.sourceforge.net wrote:

> http://mahogany.sourceforge.net/cgi-bin/show_bug.cgi?id=700

> temporary files are currently created in the root of the current drive under 
> Windows and also have meaningless/random extensions because we use tmpnam() for 
> them -- use wxFileName::CreateTemp() instead.

Unless I missed something, neither wxFileName::CreateTemp() or the Win32
API allow to specify an extension for temporary files. Only the prefix
(i.e. the directory where the file is stored) can be specified.

--

-- 
Xavier Nodet
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Benjamin Franklin, 1759.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Nerijus Baliunas | 3 Oct 2002 14:32
Picon

Re[2]: [Bug 700] New: create temp files in $TMP and with fixed extension

On Thu, 3 Oct 2002 13:07:58 +0200 Xavier Nodet <xavier.nodet <at> free.fr> wrote:

XN> > temporary files are currently created in the root of the current drive under 
XN> > Windows and also have meaningless/random extensions because we use tmpnam() for 
XN> > them -- use wxFileName::CreateTemp() instead.
XN> 
XN> Unless I missed something, neither wxFileName::CreateTemp() or the Win32
XN> API allow to specify an extension for temporary files. Only the prefix
XN> (i.e. the directory where the file is stored) can be specified.

You can add extension to temporary file yourself, there is already such
code in Mahogany IIRC.

Regards,
Nerijus

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Xavier Nodet | 3 Oct 2002 15:07
Picon
Favicon

Re: [Bug 700] New: create temp files in $TMP and with fixed extension

On Thu, 3 Oct 2002 14:32:25 +0200 (EET) Nerijus Baliunas <nerijus <at> users.sourceforge.net> wrote:

> On Thu, 3 Oct 2002 13:07:58 +0200 Xavier Nodet <xavier.nodet <at> free.fr> wrote:

> XN> > temporary files are currently created in the root of the current drive under 
> XN> > Windows and also have meaningless/random extensions because we use tmpnam() for 
> XN> > them -- use wxFileName::CreateTemp() instead.
> XN> 
> XN> Unless I missed something, neither wxFileName::CreateTemp() or the Win32
> XN> API allow to specify an extension for temporary files. Only the prefix
> XN> (i.e. the directory where the file is stored) can be specified.

> You can add extension to temporary file yourself

I'm not so sure: we would not be guaranteed to have a fileName that does
not already exist.

--

-- 
Xavier Nodet
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." - Benjamin Franklin, 1759.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Nerijus Baliunas | 3 Oct 2002 15:41
Picon

Re[2]: [Bug 700] New: create temp files in $TMP and with fixed extension

On Thu, 3 Oct 2002 15:07:47 +0200 Xavier Nodet <xavier.nodet <at> free.fr> wrote:

XN> > You can add extension to temporary file yourself
XN> 
XN> I'm not so sure: we would not be guaranteed to have a fileName that does
XN> not already exist.

Oh, sure, yes. Sorry. So wxFileName::CreateTemp() should be extended?

Regards,
Nerijus

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Vadim Zeitlin | 3 Oct 2002 15:55
Picon

Re[3]: [Bug 700] New: create temp files in $TMP and with fixed extension

On Thu, 3 Oct 2002 15:41:35 +0200 (EET) Nerijus Baliunas <nerijus <at> users.sourceforge.net> wrote:

NB> On Thu, 3 Oct 2002 15:07:47 +0200 Xavier Nodet <xavier.nodet <at> free.fr> wrote:
NB> 
NB> XN> > You can add extension to temporary file yourself
NB> XN> 
NB> XN> I'm not so sure: we would not be guaranteed to have a fileName that does
NB> XN> not already exist.
NB> 
NB> Oh, sure, yes. Sorry. So wxFileName::CreateTemp() should be extended?

 Yes, this is what I was going to do -- but didn't have time for it yet.

 Regards,
VZ

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Thomas Finneid | 4 Oct 2002 01:41
Picon
Favicon

Re: profile class (any takers?)


I'm sorry for asking again, but I found it difficult getting to know how
this one works.

On Thu, 26 Sep 2002 01:03:27 +0200 (CEST) Thomas Finneid <mfinneid <at> broadpark.no> wrote:

> 
> Hi
> 
> Could some one help with an abstract type description of how the Profile
> class / system works for global profiles, with respect to the identity
> part. I am looking into how to implement network profiles (as discussed
> around january 24th this year. Better late than never :/ ) Also I am
> looking into how to copy/rename identity profiles. 
> 
> regards
> 
> -- 
> Thomas Finneid
> 
> email: tfinneid <at> ifi.uio.no
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf

(Continue reading)

Vadim Zeitlin | 4 Oct 2002 18:40
Picon

Re: profile class

[sorry for not replying earlier but 27 was the day of my PhD defense
 and I was a bit busy the 26 -- and then I had a few other things to do]

On Thu, 26 Sep 2002 01:03:27 +0200 (CEST) Thomas Finneid <mfinneid <at> broadpark.no> wrote:

TF> Could some one help with an abstract type description of how the Profile
TF> class / system works for global profiles, with respect to the identity
TF> part.

 I think the best would be to read the code because I don't remember how
exactly does it work by now and don't want to confuse you.

 The relevant code is in ProfileImpl::readEntry(LookupData &ld, int flags)
method and here is what it does (typing this while looking at it):

1. if the profile is in suspended mode, try to read the value from
   __SUSPENDED__ subdirectory

2. if it wasn't found there, try the normal location

3. if still not found, use the identity override before looking up the
   parent (see comment in the code):

 a) first try the __SUSPENDED__ path
 b) then the normal one

4. finally go up the parent hieerarchy until we find it

 Does this answer your question?

(Continue reading)

marc | 4 Oct 2002 19:43
Picon

Mahogany Win32 enhancement request (cursor in editor)

Hi.

I've recently downloaded MAHOGANY for WIN32 for use as IMAP client.

The most annoying thing is that the cursor disappears when writing a
message.  It is almost impossible to navigate the cursor to a specific
position on screen, because it becomes visible only 0.5 sec after
releasing the cursor keys.

I think your function is something like this:

      if (cursor movement due to cursor keys or printing new char)

        set cursor blink state to INVISIBLE
        reset blink timer

while in fact it should better be 

      if (cursor movement due to cursor keys or printing new char)

        set cursor blink state to VISIBLE
        reset blink timer         ^^^^^^^

In case that this problem doesn't appear on all machines:  My setup
is WinXP SP1 on P3/800 512MB RAM,  Mahogany v0.64.1 Sparc Release build
13-Jan-2002 21:47:59.   By the way, 13-Jan is my birthday!

Marc

PS: Keep on good work.  Free programs are a good thing.  Back in
(Continue reading)

Vadim Zeitlin | 4 Oct 2002 20:29
Picon

Re: c-client patch that could solve Frankenstein messages

On Wed, 18 Sep 2002 15:08:38 +0200 Xavier Nodet <xavier.nodet <at> free.fr> wrote:

XN> Here is a patch for c-client that could solve the problem of missing
XN> bodies in some messages. I really say that it *could* because I did not
XN> fully identify the problem. 

 Me neither and this really bothers me. Anyhow, I assume it still works for
you (what about you, Michele, did you try it?)?

XN> In any case, those changes should not hurt. At least, they did not hurt
XN> during the whole last week...

 Have you been able to understand when/how can netmsg_slurp() call return
non NULL text but fill LOCAL->hdrsize with 0? As far as I can see, this is
the only situation when your patch helps but this seems impossible to me
:-(

 Alternatively, would it be enough to simply not set LOCAL->hasbody to T in
such case? Sorry to ask you about all this but I still haven't been able to
reproduce the bug myself. To be honest, by now I even forgot what was the
best way to try to reproduce it, could you please remind me?

 Thanks a lot,
VZ

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
(Continue reading)

Vadim Zeitlin | 4 Oct 2002 20:30
Picon

Re[3]: toolbar buttons

On Mon, 16 Sep 2002 02:56:21 +0200 (EET) Nerijus Baliunas <nerijus <at> users.sourceforge.net> wrote:

NB> On Mon, 16 Sep 2002 01:53:14 +0200 (Romance Daylight Time) Vadim Zeitlin
<zeitlin <at> dptmaths.ens-cachan.fr> wrote:
NB> 
NB> VZ> NB> If 'Show toolbar buttons as' is Text, there are no buttons at all and an assert:
NB> VZ> NB> [Debug] 02:23:13: ../wxWindows/src/gtk/tbargtk.cpp(385): assert "wxFalse" failed:
invalid bitmap for wxToolBar icon
NB> VZ> 
NB> VZ>  Even with the latest (i.e. > yesterday) M sources?
NB> 
NB> Yes, of course. I tried earlier, but it didn't work, so I tried yesterday,
NB> when I saw your changes. BTW, images with text work.

 It might be a bit late to return to this, but I suppose that this is not
true any longer, is it?

 Thanks,
VZ

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Gmane