Re: Mail Wrapping
Am 13.08.2010 um 22:35 schrieb steve: Le 13-08-2010, à 19:45:51 +0200, Dr. H. Nikolaus Schaller (h...@computer.org) a écrit : such a thing is quite unlikely to expect from any large phone manufacturer. Even if they open up an existing design. They ususally squeeze every bit out of the design to reduce manufacturing cost and may have very special test procedures. And they may change internals every now and then to improve their production process. I.e. you may get version B4 this week and someone else version C7 in two weeks with differences in the not-documented area. Nikolaus, couldn't you wrap your lines to something more standard (72 or so ?) Thanks, I like reading your prose, but those long lines are really irritating. Hi Steve, there are different opinions if the 80 char line wrapping of mail is standard or some old-fashioned relict from the 80ies. I have tried to find out what it is but it appears to be a problem with some MUAs not correctly handling RFC 2646. Here is also some discussion about mailman being responsible or not: http://www.mail-archive.com/mailman-us...@python.org/msg49755.html which says: The problem is that prior to Mailman 2.1.10, the format=flowed and delsp=yes parameters were not preserved in the outgoing message. I think the OM list uses version 2.1.9 so it could be a bug. I don't know if my mail client uses these paramters - but it does not have an option to do line wrapping when sending. So, wouldn't it be simpler if you reduce the width of your display window? Your client should then wrap long lines. BR, Nikolaus PS: I have tried to format this mail manually, but it is quite a pain... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
El día Friday, August 13, 2010 a las 11:53:07PM +0100, Rui Miguel Silva Seabra escribió: Em 13-08-2010 10:37, Matthias Apitz escreveu: Wrong question, for me. I will not use any other 'smartphone' (computerphone), which: - is not Linux or FreeBSD driven and open as Linux/FreeBSD are normaly Ah, so you'll not be using any Android/Linux, I see :) No, of course not. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ Solidarity with the zionistic pirates of Israel? Not in my name! ¿Solidaridad con los piratas sionistas de Israel? ¡No en mi nombre! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
Dr. H. Nikolaus Schaller h...@computer.org writes: Am 13.08.2010 um 22:35 schrieb steve: Nikolaus, couldn't you wrap your lines to something more standard (72 or so ?) Thanks, I like reading your prose, but those long lines are really irritating. there are different opinions if the 80 char line wrapping of mail is standard or some old-fashioned relict from the 80ies. I have tried to find out what it is but it appears to be a problem with some MUAs not correctly handling RFC 2646. Well, i can't really see how format=flowed can make any sense, even nowadays. I think all sane MUAs go without it by default, and for a reason: it messes with formatting which is important when you're sending snippets of code, patches, logs etc. Probably it's the right time for you to stop following the rules set by Apple and to start using a better MUA? ;) So, wouldn't it be simpler if you reduce the width of your display window? Your client should then wrap long lines. That's not exactly a good option for those of us using tiling window managers, sorry. Good luck and happy hacking :) -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
El día Saturday, August 14, 2010 a las 08:34:51AM +0200, Dr. H. Nikolaus Schaller escribió: Nikolaus, couldn't you wrap your lines to something more standard (72 or so ?) Thanks, I like reading your prose, but those long lines are really irritating. Hi Steve, there are different opinions if the 80 char line wrapping of mail is standard or some old-fashioned relict from the 80ies. I have tried to find out what it is but it appears to be a problem with some MUAs not correctly handling RFC 2646. Here is also some discussion about mailman being responsible or not: Hi Nikolaus, It is the responsibility of your MailUserAgent to wrap lines correctly around column 72. You are using Apple Mail (2.1081). If this can not do this, just use another MUA or another system providing correct software. I'm using Mutt as MUA which in turn can use any editor when writing the body of the mail. I've set the editor to vim with some magic flags: set editor=vim \'+set textwidth=72\' \'+syntax match WarningMsg /\\%70v.*/\' -i NONE this puts any char from position 70 in red color and wraps the line if my typing hits positin 72, but breaks it at the last blank before, i.e. does not break a word into two pieces. Just as a hint matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ Solidarity with the zionistic pirates of Israel? Not in my name! ¿Solidaridad con los piratas sionistas de Israel? ¡No en mi nombre! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
Please people stop spamming about line length. If you MUA is so good then ask it to automatically split long lines :-p ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
Hi, Am 14.08.2010 um 09:48 schrieb David Morris: Hi Dr. Schaller, I am interested in new boards with umts. I would like more openness with the radio module including dynamically assigning an imei and using a remote sim card. Unfortunately this is beyond what we can provide. The trick to build such an upgrade-board at a fairly reasonable price is to use some halfway (at least AT commands and interfaces) open and precertified UMTS module. Part of this certification requires that it is not possible to change IMEI :( Please view the concept as a (more or less closed) UMTS stick/key with USB interface soldered onto the main board like in all the 3G-Netbooks floating around. For providing such a feature we would have to design and certify our own complete UMTS system. And that is the million $$$ effort large handset suppliers can afford. It has turned out that there are currently only two such modules that are small enough to fit into the existing plastics. One comes from OPTION, the other one from Ericsson. Both still have unfortunately some NDA limitations - but we are working on it. BR, Nikolaus PS: it appears that I am not the only one who posts long lines... I'd also be interested in bidding in an auction for prototypes in order to raise cash. Sent from my mobile On 13 Aug 2010, at 18:54, Dr. H. Nikolaus Schaller h...@computer.org wrote: Am 13.08.2010 um 11:51 schrieb arne anka: Assume, you could get a motherboard upgrade board that fits into the Freerunner (or Neo1973) case. Based on the TI OMAP3 SoC (OMAP3530 or DM3730) and UMTS. Let me ask two questions to everybody: * How long could you be willing to wait for it to really become available? * How much would you think you could afford to pay for such a board? - re waiting: since most people change their phones after a couple of years, waiting shouldn't be an issue -- per se. more important would be to see a definite progress and sufficient informatrion about the way development takes (including delays, glitches and so on). Another question: where would you like such status messages and discussions take place? Here on the community list? Or on the om-devel-list? Or on a new, project specific devel/issues list? Nikolaus ___ devel mailing list de...@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
+1 Rui Miguel too! 2010/8/14 Rui Miguel Silva Seabra r...@1407.org Em 13-08-2010 10:56, Matthias Apitz escreveu: Em 13-08-2010 10:49, Dr. H. Nikolaus Schaller escreveu: Do I interpret you correclty, that your answer to my questions are: * I will wait *any* time, as long as it fulfills my opensource requirements yes; * I accept any price yes, any price in the range of my Freerunner, more or less; or even 500 euro, depends on my economic situation in that moment; Add me as a metoo if you want. I had a Nokia 6600 (I regret the 500€ but I extended them as much as I could), shortly after I learn of OpenMoko. I decided to try to keep 6600 until Freerunner comes out, but sadly one year before that I sent it for a 20 min swim. Still no Freerunner, so I get a cheap Nokia 2760 (GTA01 was clearly too early for me), lasts until today carrying my job's SIM (the work phone is *that* crappy). My main phone, carrying my personal SIM is OpenMoko and I'm treating it as carefully as I can to extend it's life well beyond the current two years, 1.5 of them with definite usage :) If it breaks, and no viable alternative exists, I hope to get an A7+, or A7, or A6, or A5+buzz fix (in this decreasing order of preference). Even with all the bugs and immaturity of the platform, I'm so passionate for Free Software I rather go through all this again than go back to proprietary phones or get a pseudo-open phone (Android/Linux, Meego, etc...). To all SHR and FSO core develpers: a *HUGE* thank you, I'm only sorry I can't help out more. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WikiReader sales and the future of Openmoko
2010/8/14 Christoph Pulster openm...@pulster.de: PS: I heard on IRC something about next Openmoko phone running Android. I think, it's a good idea. Please note Android is a Google(TM) product. TM stands for total monopol. Or terrible monster. Google is evil. Android is no free OS. I agree. But Openmoko Inc. need sales like every hardware company. It can use Android's fame for second start-up and make open hardware more attractive to lot of people. Martin 'Martix' Holec ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
First, let me start by saying I bought a Neo 1973, and would support such a device again -- depending on my finances at the time. :) On Fri, Aug 13, 2010 at 6:41 AM, arne anka openm...@ginguppin.de wrote: And, I never understood why we should assume, that a premier league player would ever care for a small community like ours. not for that small community per se. it would most likely be only a intersection of interests. the manufacturer would be able to - gain a reputation as being open (which might appeal to goverments as well b/c of several reasons) Or not -- see the current spat over Blackberry in India/UAE/etc. Open isn't good for governments looking for tight controls. And while it might be great for their citizens, it's the gov'ts that control devices, unfortunately. - additional promotion by mouth-to-mouth through people being interested in open devices, probably cheaper than paid merchandising for the same group While this is true, this target audience is small. - somewhat broadened developer base Do you really think that the term open will attract more developers? Maybe a handful or two, but developers flock to where the money is. See iPhone. :S - android inspired cost structure: make your hw specs public - enable developers to make the best from it - gain market share since your device offers the most b/c developers can use the hw and are not limited to app-like apis (cf iP[od|hone|ad]) with the success of android, i think a more open approach might appeal to vendors. I'm not up on all the latest android stuff, but from what I've seen, you can make a pretty closed system from those building blocks. What Sean got right was that a phone should have mass appeal. If your girlfriend and her mother want to use it, then that's good. The Neo and the Freerunner are second (third?) class hardware -- there is no doubt. The idea was to build great software, and that would make the appeal to ordinary people strong, despite having hardware that wasn't best of class. The problem was that the great software never got there, and combined with old and problematic hardware, it didn't have a decent chance. It's clear from the GTA03/0X wishlists that there are people out there who want an open phone. Some are even willing to pay good money for one. I am. However, to not end up with a hobbyist phone, some compromises have to be made. Not everyone will be happy, but the journey to a fully open smartphone will be long, expensive and perilous. It's important not to lose sight of the end goal -- which should be a device that is long-term viable. There aren't enough geeks out there to make an open phone successful, unfortunately. And to get the latest bells and whistles, the phone has to be successful, so that there is another phone to follow. So, it's important that the phone be pleasing to the eye, have good software and hardware. So, forget about open short term. Consumers don't care, vendors don't care, operators don't care. If we can build something _appealing_, that hackers find fun and consumers will buy, even if it isn't as open as everyone would like, then that would be awesome. And as such a project gains success, it has more clout and more money. And more clout and more money means more leverage with suppliers, hopefully meaning that things can be more and more open. Let's remember that even the great iPhone maker Apple stumbled with their first phone -- not iPhone 1, but the joint deal with Motorola called Rokr. And even their latest phone has some issues. Now, some on the mailing list might already know this. What I haven't seen, so far, is anyone talk about how many devices would be needed to be a success. Would 100,000 phones do it? 1 Million? More, or less? I'd love to see a truly open smartphone running Linux and BSD, with full access to as much of the hardware as we want. I'm hoping to see this sooner, but we'll have to see how many intermediate steps there are, from mostly closed to fully open. I'm willing to accept Android as a stepping stone, but it won't warm anyone to open or push suppliers in that direction. Gerald ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
I don't know if my mail client uses these paramters - but it does not have an option to do line wrapping when sending. Indeed. That's the one thing I really hate when using Mail.app. Cheers, -- :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
Am 14.08.2010 um 10:14 schrieb ri...@happyleptic.org: Please people stop spamming about line length. If you MUA is so good then ask it to automatically split long lines :-p I agree that we should not spam - but IMHO this was raised as a serious problem. I could live with the idea that everyone uses a MUA that can wrap lines when reading and displaying long lines. But it appears there are systems out there that can't (which I did not yet know). And I am asked to solve their display problem on the senders side (although I have much better things to do)... Am 14.08.2010 um 09:28 schrieb Matthias Apitz: El día Saturday, August 14, 2010 a las 08:34:51AM +0200, Dr. H. Nikolaus Schaller escribió: Nikolaus, couldn't you wrap your lines to something more standard (72 or so ?) Thanks, I like reading your prose, but those long lines are really irritating. Hi Steve, there are different opinions if the 80 char line wrapping of mail is standard or some old-fashioned relict from the 80ies. I have tried to find out what it is but it appears to be a problem with some MUAs not correctly handling RFC 2646. Here is also some discussion about mailman being responsible or not: Hi Nikolaus, It is the responsibility of your MailUserAgent to wrap lines correctly around column 72. You are using Apple Mail (2.1081). If this can not do this, just use another MUA or another system providing correct software. Before we start fingerpointing on any client we are using, let's do a little more research. http://mailformat.dan.info/body/linelength.html quotes RFC 2822 (the successor to RFC 822): There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. I.e. lines more than 78 characters are *not* forbidden. From this I conclude that a mail recipient must cope with that. If not, the client is broken. And, I conclude that it is not a rule for writing or displaying mails - just for transferring them over SMTP without making buffer overflows. Now let's look into the plain code my MUA is sending. Here is an example: Hi Steve, there are different opinions if the 80 char line wrapping of mail is standa= rd or some old-fashioned relict from the 80ies. I have tried to find out what it is bu= t it appears to be a problem with some MUAs not correctly handling RFC 2646. Here is also some discussion about mailman being responsible or not: So Apple Mail *is* correclty sending wrapped lines according to RFC. I do not excactly know what the rules are to interpret the = signs at the end of the line. I guess it has to do with Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable A little more search shows this comes from RFC 2045 (MIME) on page 19 (Soft Line Breaks). From this I conclude that the mails my client sends are correct (according to the standard). So it appears to me that we are trying to treat a corectly implemented feature as a bug because there is some habit of expecting that lines are always *displayed* with wrapping (even if they are sent as non-wrapped lines using MIME quoted-printable). But I may be missing something. If somebody can point me to the RFC that *requires* that lines must be *visibly* wrapped by the sender so that no client ever shows long lines, I am happy to file a bug report for Apple Mail (wouldn't be the first one :). If there is no such RFC, please report bugs for your clients that don't wrap long (MIME encoded) lines they receive to the width of the display window. Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
El día Saturday, August 14, 2010 a las 03:41:06PM +0200, Dr. H. Nikolaus Schaller escribió: So Apple Mail *is* correclty sending wrapped lines according to RFC. I do not excactly know what the rules are to interpret the = signs at the end of the line. I guess it has to do with Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable A little more search shows this comes from RFC 2045 (MIME) on page 19 (Soft Line Breaks). From this I conclude that the mails my client sends are correct (according to the standard). So it appears to me that we are trying to treat a corectly implemented feature as a bug because there is some habit of expecting that lines are always *displayed* with wrapping (even if they are sent as non-wrapped lines using MIME quoted-printable). But I may be missing something. If somebody can point me to the RFC that *requires* that lines must be *visibly* wrapped by the sender so that no client ever shows long lines, I am happy to file a bug report for Apple Mail (wouldn't be the first one :). If there is no such RFC, please report bugs for your clients that don't wrap long (MIME encoded) lines they receive to the width of the display window. http://www.faqs.org/rfcs/rfc1855.html 2.1 User Guidelines 2.1.1 For mail: ... - Limit line length to fewer than 65 characters and end a line with a carriage return. ... matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e g...@unixarea.de - w http://www.unixarea.de/ Solidarity with the zionistic pirates of Israel? Not in my name! ¿Solidaridad con los piratas sionistas de Israel? ¡No en mi nombre! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
Hi, Dr. H. Nikolaus Schaller h...@goldelico.com writes: If there is no such RFC, please report bugs for your clients that don't wrap long (MIME encoded) lines they receive to the width of the display window. Nikolaus, thanks for the serious attitude wrt this issue. My client does wrap long lines to the width of the display window, but as i'm using a tiling window manager, my client is almost always fullscreen (and sometimes i split my screen horizontally, with MUA's width obviously not affected). I can agree that using f=f is legal but nevertheless i can see no reason why insist on using it given it seems to have no benefits but quite some drawbacks and hence it's customary to avoid it (e.g. most mails at LKML are wrapped). -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] how to work on a theme
Radek Polak wrote: You can also mount NFS for /opt with qtopia directory on your PC and avoid transfering filies. Or you can use SSHFS to mount Freerunner's filesystem on your PC. ehr... actually I don't know how to do that :) However, I followed Petr's suggestion Petr wrote: yes, see here: http://qtmoko.org/wiki/GITs but, although I installed all the required packages, if I proceed with the configure I receive: $ ../qtmoko/configure -device neo -D _FORTIFY_SOURCE=0 -confirm-license -rtti This is the Qt Extended Open Source Edition. Skipping confirmation of the Qt Extended license agreement. Testing the system Qt: FAIL Qt Extended requires Qt 4.3 or higher to be installed. You must have qmake in your PATH. If your system's package manager does not provide Qt 4 development libraries please see the Guide to Configuring and Building Qt Extended for information on how to build Qt from the included source. Alternatively, pass -build-qt to configure and it will build Qt for you (and then bootstrap QBuild from that). make: *** [src/build/mkconf/configure] Error 2 I'm on Debian Squeeze x64, I installed qt4-qmake, libqt4-dev, qt4-dev-tools and all their dependecies. Regards Joif -- View this message in context: http://openmoko-public-mailinglists.1958.n2.nabble.com/QtMoko-work-on-a-theme-virtualization-QEMU-tp5413206p5423256.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
- gain a reputation as being open (which might appeal to goverments as well b/c of several reasons) Or not -- see the current spat over Blackberry in India/UAE/etc. Open isn't good for governments looking for tight controls. And while it might be great for their citizens, it's the gov'ts that control devices, unfortunately. the spat you mentioned is just about rim not being open with it's servers. were they open, gouverments could simply set up their own and force their citizens to use those. what i was refering to, wa sthe fact that with open sw/hw gouvernments would be able to check on their own the integrity and safety of implemantations, not being dependent on the vendors. - additional promotion by mouth-to-mouth through people being interested in open devices, probably cheaper than paid merchandising for the same group While this is true, this target audience is small. sure. but so is, after all, the target audience for apple products. and as said before, openess would have this increased promotion at no additional costs. - somewhat broadened developer base Do you really think that the term open will attract more developers? Maybe a handful or two, but developers flock to where the money is. See iPhone. :S see below. openess would mean, developers are not restricted by limited apis, but could access the complete bandwith of options available. - android inspired cost structure: make your hw specs public - enable developers to make the best from it - gain market share since your device offers the most b/c developers can use the hw and are not limited to app-like apis (cf iP[od|hone|ad]) with the success of android, i think a more open approach might appeal to vendors. I'm not up on all the latest android stuff, but from what I've seen, you can make a pretty closed system from those building blocks. sure you can. but otoh, android being (more or less) opene, it allows vendors to get their devices to market in rather limited time compared to closed, vendor-specific os which need a lot of inhouse investment to develop and get stable. and seeing how an open os, offered at no costs helps saving money, an open hw design easily extensible might appeal as well. assume vendor X creates a design freely available, there would probably be a lot of other vendors re-use that design to decrease their costs -- google did not create android out of altruistic motives, they have their profit and interests at heart, and yet, android is attractive to the market. but after all, i have the sure feeling as if the very same discussion has been had already, years ago and all arguments have been on the table already. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
Am 14.08.2010 um 15:55 schrieb Matthias Apitz: El día Saturday, August 14, 2010 a las 03:41:06PM +0200, Dr. H. Nikolaus Schaller escribió: If somebody can point me to the RFC that *requires* that lines must be *visibly* wrapped by the sender so that no client ever shows long lines, I am happy to file a bug report for Apple Mail (wouldn't be the first one :). If there is no such RFC, please report bugs for your clients that don't wrap long (MIME encoded) lines they receive to the width of the display window. http://www.faqs.org/rfcs/rfc1855.html 2.1 User Guidelines 2.1.1 For mail: ... - Limit line length to fewer than 65 characters and end a line with a carriage return. ... Ok. But: October 1995 Status of This Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This document provides a minimum set of guidelines for Network Etiquette (Netiquette) which organizations may take and adapt for their own use. I.e. I would not take it as a *requirement* and it is also quite old to stick to it. It appears to be stimulated by times where 50% of the Internet users did use a VGA screen and 95% dial-up modems. People did not have many WYSIWYG systems as mail clients. Most mail clients were VT100 compatible. So I fear I can't convince Apple with this (it does not even convince me...). The only solution is, that I promise to try to press the return key every now and then (unless I forget)... BR, Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
sorry, but i completely fail to understand the issue. every mail client worth using should be able to wrap lines even for received mails when displaying. instead of forcing their idea of (maybe even outdated) conventions on other people, those having issues with lines being too long, simply should check their mail clients configuration and get over with it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Mail Wrapping
Hi, Nikolaus, First, thanks for your work on next generation of free hardware, I hope to use it one day. Didn't came to conclusion how my next device should look like exactly, and i'm ok with fr so far. But about line wrapping - i am using web interface to read community-ml, so no way to control my 'client' parameters. To get idea how your mail look like in web interface, try this link: http://lists.openmoko.org/pipermail/community/2010-July/062609.html I think many people may find your letters this way, and it's really not easy to read sometimes. Just a note, all this wrapping topic is not really serious problem. Gennady. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
Le 14-08-2010, à 08:34:51 +0200, Dr. H. Nikolaus Schaller (h...@computer.org) a
écrit :
Am 13.08.2010 um 22:35 schrieb steve:
Le 13-08-2010, à 19:45:51 +0200, Dr. H. Nikolaus Schaller
(h...@computer.org) a écrit :
such a thing is quite unlikely to expect from any large phone
manufacturer. Even if they open up an existing design. They
ususally squeeze every bit out of the design to reduce
manufacturing cost and may have very special test procedures. And
they may change internals every now and then to improve their
production process. I.e. you may get version B4 this week and
someone else version C7 in two weeks with differences in the
not-documented area.
Nikolaus, couldn't you wrap your lines to something more standard
(72 or so ?) Thanks, I like reading your prose, but those long lines
are really irritating.
Hi Steve,
Hi Niklaus (not in Zürich toniht?)
there are different opinions if the 80 char line wrapping of mail is standard
or some
old-fashioned relict from the 80ies. I have tried to find out what it is but
it appears
to be a problem with some MUAs not correctly handling RFC 2646.
I just read (in diagonal) through rfc 2646. It seems that it clearly
says to stick to lines not longer that 80 caracters.
Anyway, may studies have shown that the reader begins to be less
concentrated when lines exceed 80 caracters, that's *my* main point.
Here is also some discussion about mailman being responsible or not:
http://www.mail-archive.com/mailman-us...@python.org/msg49755.html
which says:
The problem is that prior to Mailman 2.1.10, the format=flowed and
delsp=yes parameters were not preserved in the outgoing message.
I think the OM list uses version 2.1.9 so it could be a bug.
Maybe, but a lot of posters here don't have any problems with 72-80
caracters. I don't see where mailman comes in the game.
I don't know if my mail client uses these paramters - but it does not have
an option to do line wrapping when sending.
Bad MUA, change MUA (mutt maybe?)
So, wouldn't it be simpler if you reduce the width of your display window?
Your client should then wrap long lines.
No it's not simpler, imagine that many people wrap at diffenrent
numbers, what should I do? Reduce *my* display every time a mail is
excedding 72-80 caracters? I'd become crazy.
BR,
Nikolaus
PS: I have tried to format this mail manually, but it is quite a pain...
I understand that. But bottom line, you're using a mua that sucks, if it
doesn't give you the possibility to wrap lines at the lenght *you*
choose. Have a try at mutt [1], you'll be happy.
Personaly, I use mutt with vim as a text editor, and a simple {gq},
wraps the whole paragraph as I want, awsome :-)
[1] http://www.mutt.org/
Best regards,
--
steve
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
Le 14-08-2010, à 11:09:58 +0400, Paul Fertser (fercer...@gmail.com) a écrit : Dr. H. Nikolaus Schaller h...@computer.org writes: Am 13.08.2010 um 22:35 schrieb steve: Nikolaus, couldn't you wrap your lines to something more standard (72 or so ?) Thanks, I like reading your prose, but those long lines are really irritating. there are different opinions if the 80 char line wrapping of mail is standard or some old-fashioned relict from the 80ies. I have tried to find out what it is but it appears to be a problem with some MUAs not correctly handling RFC 2646. Well, i can't really see how format=flowed can make any sense, even nowadays. I think all sane MUAs go without it by default, and for a reason: it messes with formatting which is important when you're sending snippets of code, patches, logs etc. Probably it's the right time for you to stop following the rules set by Apple and to start using a better MUA? ;) Absolutely! Mutt maybe? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
Le 14-08-2010, à 09:28:43 +0200, Matthias Apitz (g...@unixarea.de) a écrit : It is the responsibility of your MailUserAgent to wrap lines correctly around column 72. You are using Apple Mail (2.1081). If this can not do this, just use another MUA or another system providing correct software. +1 I'm using Mutt as MUA which in turn can use any editor when writing the body of the mail. I've set the editor to vim with some magic flags: set editor=vim \'+set textwidth=72\' \'+syntax match WarningMsg /\\%70v.*/\' -i NONE My setting too. this puts any char from position 70 in red color and wraps the line if my typing hits positin 72, but breaks it at the last blank before, i.e. does not break a word into two pieces. Just as a hint A good one! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
Le 14-08-2010, à 15:41:06 +0200, Dr. H. Nikolaus Schaller (h...@goldelico.com) a écrit : Please people stop spamming about line length. If you MUA is so good then ask it to automatically split long lines :-p I agree that we should not spam - but IMHO this was raised as a serious problem. Serious no, just courtesy. I could live with the idea that everyone uses a MUA that can wrap lines when reading and displaying long lines. But it appears there are systems out there that can't (which I did not yet know). How does *your* mua display your own long lines? Does it wrap the lines to a predefined length? Or do you see them as you type them? And I am asked to solve their display problem on the senders side I'm not obliging you at all, it was just a nice remark and I felt I could share it with you because through your prose I felt someone open to remarks. That's all. (although I have much better things to do)... I'm sure of that! (I don't write a lot here, but I read nearly everything). Am 14.08.2010 um 09:28 schrieb Matthias Apitz: El día Saturday, August 14, 2010 a las 08:34:51AM +0200, Dr. H. Nikolaus Schaller escribió: Nikolaus, couldn't you wrap your lines to something more standard (72 or so ?) Thanks, I like reading your prose, but those long lines are really irritating. Hi Steve, there are different opinions if the 80 char line wrapping of mail is standard or some old-fashioned relict from the 80ies. I have tried to find out what it is but it appears to be a problem with some MUAs not correctly handling RFC 2646. Here is also some discussion about mailman being responsible or not: Hi Nikolaus, It is the responsibility of your MailUserAgent to wrap lines correctly around column 72. You are using Apple Mail (2.1081). If this can not do this, just use another MUA or another system providing correct software. He said it (also) :-) Before we start fingerpointing on any client we are using, let's do a little more research. http://mailformat.dan.info/body/linelength.html quotes RFC 2822 (the successor to RFC 822): There are two limits that this standard places on the number of characters in a line. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. I.e. lines more than 78 characters are *not* forbidden. From this I conclude that a mail recipient must cope with that. If not, the client is broken. No. Mutt displays long line but that's not a reason for it to be broken. I repeat, it is easier for humains to read lines not excedding 80 caracters, after you get tired and your concentration decreases. So as the writer, your goal is to catch your readers attention and one way to do it, is to wrap lines to a descent lenght (between 72 and 80 caracters). And, I conclude that it is not a rule for writing or displaying mails - just for transferring them over SMTP without making buffer overflows. I don't care what the MTA does (at this point). Now let's look into the plain code my MUA is sending. Here is an example: Hi Steve, there are different opinions if the 80 char line wrapping of mail is standa= rd or some old-fashioned relict from the 80ies. I have tried to find out what it is bu= t it appears to be a problem with some MUAs not correctly handling RFC 2646. Here is also some discussion about mailman being responsible or not: So Apple Mail *is* correclty sending wrapped lines according to RFC. You're kidding I hope? Second line, there is only three words, same on fourth line. The text presented like that just sucks. I do not excactly know what the rules are to interpret the = signs at the end of the line. I guess it has to do with Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable A little more search shows this comes from RFC 2045 (MIME) on page 19 (Soft Line Breaks). From this I conclude that the mails my client sends are correct (according to the standard). I think your conclusion is wrong. [...] Kind regards -- steve ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mail Wrapping
Le 14-08-2010, à 17:05:55 +0200, Dr. H. Nikolaus Schaller (h...@goldelico.com) a écrit : The only solution is, that I promise to try to press the return key every now and then (unless I forget)... IMHO, it is not a good solution. Otherwise, why use machines? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: When is the next and more powerful openmoko releasing
Heya, On Sat, Aug 14, 2010 at 10:40 AM, arne anka openm...@ginguppin.de wrote: - gain a reputation as being open (which might appeal to goverments as well b/c of several reasons) Or not -- see the current spat over Blackberry in India/UAE/etc. Open isn't good for governments looking for tight controls. And while it might be great for their citizens, it's the gov'ts that control devices, unfortunately. the spat you mentioned is just about rim not being open with it's servers. were they open, gouverments could simply set up their own and force their citizens to use those. what i was refering to, wa sthe fact that with open sw/hw gouvernments would be able to check on their own the integrity and safety of implemantations, not being dependent on the vendors. The issue I was referring to was if hardware and software is open enough, then said governments won't even consider allowing the devices in, since end users could use them to circumvent whatever protections the regulators put on. - additional promotion by mouth-to-mouth through people being interested in open devices, probably cheaper than paid merchandising for the same group While this is true, this target audience is small. sure. but so is, after all, the target audience for apple products. and as said before, openess would have this increased promotion at no additional costs. With 14% of the market and 4th place in the Smartphone market (source: http://en.wikipedia.org/wiki/File:Smartphone_share_2009_full.png), I would say that Apple's target audience is naturally slightly larger. Would apple being open help them? In some ways, sure. However, if we had Apple's war chest, we wouldn't be having discussions, we'd all have devices in our hands. :S - somewhat broadened developer base Do you really think that the term open will attract more developers? Maybe a handful or two, but developers flock to where the money is. See iPhone. :S see below. openess would mean, developers are not restricted by limited apis, but could access the complete bandwith of options available. Lot's of platforms have crap apis. If api's defined success, Unix would have triumphed over Windows long ago. Nice APIs do help, don't get me wrong -- but don't get lost in the clouds. - android inspired cost structure: make your hw specs public - enable developers to make the best from it - gain market share since your device offers the most b/c developers can use the hw and are not limited to app-like apis (cf iP[od|hone|ad]) with the success of android, i think a more open approach might appeal to vendors. I'm not up on all the latest android stuff, but from what I've seen, you can make a pretty closed system from those building blocks. sure you can. but otoh, android being (more or less) opene, it allows vendors to get their devices to market in rather limited time compared to closed, vendor-specific os which need a lot of inhouse investment to develop and get stable. and seeing how an open os, offered at no costs helps saving money, an open hw design easily extensible might appeal as well. assume vendor X creates a design freely available, there would probably be a lot of other vendors re-use that design to decrease their costs -- google did not create android out of altruistic motives, they have their profit and interests at heart, and yet, android is attractive to the market. but after all, i have the sure feeling as if the very same discussion has been had already, years ago and all arguments have been on the table already. True true. If Android is used as a stepping stone, I think that is fine. But Android isnn't the end, it's only something along the path. Gerald ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
