Recent Posts

Pages: [1] 2 3 ... 10
1
Development / Re: WxPython 4.0.0 porting
« Last post by Mike on October 29, 2017, 05:10:57 pm »
The wx 4.0.0 port works pretty well now. I got rid of the deprecations and all the GUI functions seem to work. I should be able to upgrade CM to 4.0.0 as soon as distributions start including it.
2
Development / WxPython 4.0.0 porting
« Last post by Mike on October 27, 2017, 12:14:38 am »
WxPython 4.0.0 is now available a Windows package, and I am working on porting CM to it. I am hoping for a more reliable Rich Text Editor. Some people have reported problems with the editor in 3.0.2.0.

There are a lot of little changes where things have been moved around. So far I have it sending and receiving; now I have to hunt down various bugs and fix all the "deprecated method" messages. At the moment the Linux distributions are not shipping 4.0.0, so once it's working I will release a source package and possibly a Windows package for anyone who wants to try it.
3
Development / Re: It would be nice to be able to select plaintext when composing
« Last post by Mike on September 20, 2017, 07:45:11 pm »
Yes, the attachments are files in the zip archive preceded by an underscore. The underscore is removed when you extract the attachment. It is also possible to forward a message with the original sender signature intact, by adding the message zip and sig into the outer zip. There is a spec PDF on the download page that fully explains the format and protocol. You seem to be into this stuff, so please post your opinions.

I have had an email exchange with one well-known open source guru, and that's exactly what he wanted: a scriptable toolkit. It's possible but would require something more complex than command line invocation. I am not sure what the best type of interface to provide is. CM is already divided into a client agent and a GUI, and I have several automatic clients which drive the client agent. One of those is a mailing list server, and another is a file server.

I can definitely add a "show me text by default" option, and all messages are required to contain text. HTML and XML are optional.
4
Development / Re: It would be nice to be able to select plaintext when composing
« Last post by rowanthorpe on September 20, 2017, 07:15:05 pm »
Obviously this is just a feature-request which I suspect is probably not a very popular one, but I am a bit addicted to text-only interfaces and scriptability. I would personally love to see (in addition to the wxwindows GUI) a highly configurable/hookable TUI interface for CM (like mutt/pine/etc for email, & lynx/w3c/etc for web) come out one day. Aside from the obvious reasons (security, bandwidth-savings), I find that sticking to text-and-attachments-only as much as possible is a good technique for staying focused when working (messages load/render faster, less eye-candy to navigate in order to read the actual content, less chance of hitting bugs, etc).

You would like the sender to be able to set plaintext only?

Yes. I do that with my email clients.

The next version of CM is going to display text-only in case of a bad signature or key collision. I am somewhat worried about an exploit in wx.RichTextCtrl being the easiest way to attack someone via CM.

You would also like the receiver to be able to set a menu option and have the double-click action default to open text only?

Yes. I do that with my email clients too. Also, when I subscribe to mailing lists the first thing I do is set "text-only digests".

Right now there are three types: text, HTML, and Rich Text XML as supported by wx. The HTML is there for future compatibility, as I would like CM to use HTML for its rich text someday. At the moment there is no good editor available.

The message is a ZIP file with the text, html, and xml formats as separate files inside the ZIP.

...so are attachments handled as separate files (from the message-content) within the zip archive? I presume they are not encoded into the html/xml content itself, considering you have stated you've successfully sent/received 4GB attachments..? If attachments are entirely possible with plaintext messages, then my request is "enthusiastic". If plaintext excludes attachments then it would still be worth having as an option, but much less likely to be used often.
5
Support / Re: GPG generation error during Easy Setup
« Last post by rowanthorpe on September 20, 2017, 06:32:07 pm »
How would I go about detecting that? I could put up a "hey dummy" whenever someone starts up with gpg2 and invalid configuration. Is this just the symlink for pinentry? I.e. what did you change to make it work.

Sorry, I didn't see your reply on this issue until now. The change I made was to comment out the following line:

Code: [Select]
pinentry-program /usr/bin/pinentry-curses
in my ~/.gnupg/gpg-agent.conf

Gpg2 has been a large pain due to the way it handles passwords. I wish ECC was backported to gpg 1.4

I had my share of banging my head against gpg2 a few years ago (when making a shellscript-tool for automating creation of super-strong keys following best-practises). Your predicament with the passphrase-entry reminded me that I had an extensively updated private-branch of that project, including with changes using gpg-preset-passhprase, --pinentry-mode loopback, etc. On the off-chance that any of it may prove useful, I just now pushed that branch to the "devel" branch on the github repo, with all the untested changes as a WIP commit, along with a big warning that that branch is only a work-in-progress, so may not even run (and is mainly useful for reading the code). Feel free to have a look at the gpg2 invocations/flags there, and also the comment about the gpgwrap manpage. Depending on your interest in paranoiac things, you may also find the memlockd stuff relevant.
6
Development / Re: It would be nice to be able to select plaintext when composing
« Last post by Mike on September 20, 2017, 06:16:15 pm »
You would like the sender to be able to set plaintext only?

The next version of CM is going to display text-only in case of a bad signature or key collision. I am somewhat worried about an exploit in wx.RichTextCtrl being the easiest way to attack someone via CM.

You would also like the receiver to be able to set a menu option and have the double-click action default to open text only?

Right now there are three types: text, HTML, and Rich Text XML as supported by wx. The HTML is there for future compatibility, as I would like CM to use HTML for its rich text someday. At the moment there is no good editor available.

The message is a ZIP file with the text, html, and xml formats as separate files inside the ZIP.
7
Support / Re: Truncated fields in client (due to hidpi screen?)
« Last post by Mike on September 20, 2017, 06:07:50 pm »
That got me a 0 x 0 in my test environment. I think I have an approach that will work.
I can call these on the sizers for the button row or largest set of inputs:
 ComputeFittingWindowSize(self, window)
 Like ComputeFittingClientSize , but converts the result into window size.
If the result is larger than the default window size, then resize the window up.
That should make the fixed size windows at least render properly on large-font displays.
The scale factor is still there in case someone wants to set it manually.

Any more UI ideas? I got the confirm overwrite.
Thanks
8
Support / Re: Truncated fields in client (due to hidpi screen?)
« Last post by rowanthorpe on September 20, 2017, 05:50:57 pm »
..[snip]..
so I can find out the pixel dimensions of the screen. It is possible to default the scale factor to larger if the screen has more than some number of pixels, but what I really need is the dots per inch, and that is impossible to know without interrogating the hardware. A 4K display could be a laptop or a huge TV used as a monitor.

This is a unique case because I don't have outside-the-user configuration files. The scale factor is something the application needs to know before it opens a user account. I am not sure where to configure that besides the command line.

The way I usually get physical dimensions (on a POSIX box) from commandline is using xrandr, namely:

Code: [Select]
xrandr -q --verbose | sed -n -e '/^[^ ]\+ connected/p'
and looking at the end of the line for the
Code: [Select]
###mm x ###mm part, so it should be straightforward to use the python-xrandr library to get that same info in a way more elegant than piping from the CLI tool. As for Mac OSX and Windows, I guess there must be access-libraries analogous to xrandr, but I don't know what they are.
9
Support / Re: Attachment-save dialogue clobbers existing files without prompting
« Last post by Mike on September 20, 2017, 05:49:29 pm »
Yes that needs to be done. It will be in 0.42
10
Support / Re: Truncated fields in client (due to hidpi screen?)
« Last post by Mike on September 20, 2017, 05:28:49 pm »
There are a couple more places where I am adding the resizing, such as the agent status indicator on the lower right.
wx does provide these:

print 'x',wx.SystemSettings.GetMetric(wx.SYS_SCREEN_X)
print 'y',wx.SystemSettings.GetMetric(wx.SYS_SCREEN_Y)

so I can find out the pixel dimensions of the screen. It is possible to default the scale factor to larger if the screen has more than some number of pixels, but what I really need is the dots per inch, and that is impossible to know without interrogating the hardware. A 4K display could be a laptop or a huge TV used as a monitor.

This is a unique case because I don't have outside-the-user configuration files. The scale factor is something the application needs to know before it opens a user account. I am not sure where to configure that besides the command line.
Pages: [1] 2 3 ... 10