logicmail-devel — Discussions of on-going development

[Logicmail-devel] Developing

[George S. <ge...@mh...>]

I'm using Logic Mail 2.0 development snapshot on my Storm, running OS
version 5.0. (Not that the OS Version matters).

Essentially, the 2.0 build is just horribly broken. Obvious functionality
just doesn't work. I mean things like deleting a message doesn't work at
all. Period. Not at all.

Another MAJOR hassle is that the subscribed folders feature isn't present in
2.0.

I'm willing to pitch in here, and start trying to fix some of these things
but I want to make sure my changes go back into the source tree.

I didn't see on the development page any information on how to contribute
changes that I make back to the source tree.

How is this done?

George Sexton
MH Software, Inc. - Home of Connect Daily Web Calendar
http://www.mhsoftware.com/
Voice: 303 438 9585
  

Re: [Logicmail-devel] lockup issue with 1.9.0 builds

[Derek K. <dko...@lo...>]

Ahh, the joys of you being on the west coast (and me on the east coast), 
and us both doing most of this after work...  Puts a day lag between us 
:-)  Though it reminds me of when I spent a summer durring college in San 
Diego, and was delighted that I could still chat /w my night-owl 
east-coast friends and still get to bed at a reasonable hour.

On Tue, 1 Sep 2009, Chris Seawood wrote:
> Yeah, I'm a firm believer in eating your own dogfood.  Plus, everyone
> was raving about 1.9.0 in a previous thread and there were binary builds
> so I had to try it out. :-)

I'm very close to that point myself with trunk (1.9).  My main hesitation 
had to do with the fact that I haven't put much effort yet into ironing 
out all the error conditions that can arise from a flaky network, which is 
a mostly non-existant problem at home.  I do periodically load the lastest 
build onto my older 8820 and test it over Wi-Fi, however.  Though right 
now I'm discovering some random/minor UI quirks as a side-effect of my 
attempt to support Storm and conventional UIs from the same source tree. 
Hopefully those will be ironed out soon enough, and there aren't many of 
them.  (I just wish it was less annoying to switch back and forth in the 
dev tools.)

> The first 1.9.0 build was your binary build from last week (8/26?).  My
> local builds are done using ant.
The build server (obviously) uses ant as well, so they should match up 
fairly well.  Though anything's possible.  Mixing and matching Eclipse and 
Ant builds on a real device could very well cause entry-point issues, 
however.

> I just ran my local build in the simulator and it crashes with the
> unhandled exception error when LogicMail attempts to get my folder list.
>
> I can't figure out how to copy the stack trace but essentially, it looks
> something fails when ImapProtocol::executeList tries to update the
> status of the MailProgressHandler.  When I commented out all of those
> calls, then the app stopped crashing at that point.

The inability to get your usual Java-style stack trace has to be my #1 pet 
peeve in the world of BlackBerry software development.  Especially, of 
course, when the "user" isn't willing/able to run the app in the simulator 
from a development IDE.

That being said, the code you're hitting is fairly recent.  My wild guess 
would be that I'm incorrectly calculating something in regards to progress 
reporting, or you're hitting some strange condition when it tries updating 
the status bar in the GUI.  I actually did some work this past weekend on 
how the status bar gets displayed, so I'd make sure you have that before 
moving forward.  Once you're past that point, some more direct debugging 
would be extremely helpful.  The Eclipse debugger makes it fairly easy to 
see what line of code the exception was thrown from, usually, though not 
necessarily what on the line caused the error.  So it never hurts to set a 
breakpoint right before it and step through.

I'll have to test some of that later myself, of course.  The output of the 
folder listing is one of those items that gets cached, so I'm probably not 
re-running that code very often.

P.S. I recently realized that if I keep focusing 100% on nitpick issues 
(of which I'm aware of plenty, and have been keeping a to-do list) then 
I'm never going to make real progress, so I'm currently focusing on 
the infrastructure code for offline message caching.  (that and connection 
management being the two key big-ticket items necessary for release...)
Someday I'll figure out a way of making my TO-DO list more visible, since 
its a more convenient way to work right now than Trac tickets.  (maybe if 
Tomboy Notes ever stabilizes their web service project)

-- 
----------------------------
  Derek Konigsberg
  dko...@lo...
----------------------------

Re: [Logicmail-devel] lockup issue with 1.9.0 builds

[Chris S. <cl...@se...>]

Yeah, I'm a firm believer in eating your own dogfood.  Plus, everyone
was raving about 1.9.0 in a previous thread and there were binary builds
so I had to try it out. :-)

The first 1.9.0 build was your binary build from last week (8/26?).  My
local builds are done using ant.

I just ran my local build in the simulator and it crashes with the
unhandled exception error when LogicMail attempts to get my folder list.

I can't figure out how to copy the stack trace but essentially, it looks
something fails when ImapProtocol::executeList tries to update the
status of the MailProgressHandler.  When I commented out all of those
calls, then the app stopped crashing at that point.

- cls

Derek Konigsberg said the following on 9/1/2009 3:16 AM:
> You're definitely a braver guy than me.  I'm still running a 1.1 build on my 
> own phone. :-)
> 
> The TLS support is pretty new, though it is also fairly simple.  However, what 
> you really should be doing is testing this all on the simulator.  If you have 
> a development environment setup in Eclipse, and run LogicMail that way, you 
> can at least see what sort of lockup is actually happening.  You're obviously 
> testing a case I've never run into, which means I probably can't debug it on 
> my own.
> 
> The trunk (1.9/2.0) version has a lot of threading and asynchronous stuff under 
> the covers, so there's definitely a chance you either triggered a deadlock or 
> (maybe) an infinite loop.  Most of my own testing so far has been far more 
> "scripted" than a real user on a real device.  (i.e. I don't navigate screens 
> while stuff is loading, or trigger loading different things at once)  So any 
> debugging help you can offer is greating appreciated.
> 
> As far as entry point issues, that could be something getting corrupted in the 
> build process, but I can't say.  I had those sorts of issues a lot when I was 
> first getthing things ironed out, but haven't seen them in a while.  But there 
> are two tidbits you should know about this:
> - LogicMail (devel) has two "entry points", one that runs at BlackBerry 
> startup to initialize device notifications, and the one that runs when you 
> actully click the icon to start the app.
> - The way Eclipse builds the app is *different* from the way "ant" builds the 
> app.  Any entry-point settings or startup issues may be unique to the way you 
> were building the app.  These problematic builds...  were they done in Eclipse 
> (/w plugin), the RIM JDE, or straight Ant?
> 
> -Derek
> 
> On Tuesday 01 September 2009 3:20:29 am Chris Seawood wrote:
>> Has anyone else managed to get 1.9.0 to lock up their BB hard?  I was
>> giving it a test run last week to see if the new APIs would allow me to
>> get passed my MS Exchange SSL/TLS problem.
>>
>> The first problem I saw was that LogicMail refused to get a list of
>> folders from my personal Courier-Imap server.  I suspect that the
>> problem has to do with either the number of folders (100+) or that the
>> names of some folders are longer than the token 8 or 15 chars.  I run
>> the same version of Courier-Imap at work with just a dozen folders and
>> LogicMail had no problem getting a directory listing for that one.
>>
>> When attempting to send mail via the Exchange server, I received the
>> exception message:
>>   Unable to switch to TLS mode: (null)
>> I'm not sure which condition in Connection.java startTLS() that I'm
>> hitting.
>>
>> At some point, I tried repeatedly to connect to my personal imap server
>> and send via Exchange/SSL and then the BlackBerry locked up.  I had to
>> pull the battery to reset it.  Now, whenever I try to start up LogicMail
>> 1.9.0 (any build from the past week), it appears to return to the same
>> spot.  Occasionally, it will throw up a dialog box:
>>
>>     Uncaught exception: Module with handle [1823]
>>     and index [0] has no application entry point
>>             [OK]
>>
>> I've tried downgrading to 1.1.x, which works. But after re-upgrading to
>> 1.9.0, the broken behavior persists.
>>
>> I purchased the signing keys and was able to build my own trunk version,
>> sign it and install it but it behaves the same way.  I tried renaming
>> the local build to LogicMail-1.9 via the project.properties file and the
>> problem still persists.
>>
>> I used 'JavaLoader erase' to forcibly remove the bad modules from the
>> device but when I load 1.9.0 again, it pops up the same dialog box with
>> a different handle number.
>>
>> - cls
>>
>> ---------------------------------------------------------------------------
>> --- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day trial. Simplify your report design, integration and deployment - and
>> focus on what you do best, core application coding. Discover what's new
>> with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Logicmail-devel mailing list
>> Log...@li...
>> https://lists.sourceforge.net/lists/listinfo/logicmail-devel
> 

Re: [Logicmail-devel] lockup issue with 1.9.0 builds

[Derek K. <dko...@lo...>]

You're definitely a braver guy than me.  I'm still running a 1.1 build on my 
own phone. :-)

The TLS support is pretty new, though it is also fairly simple.  However, what 
you really should be doing is testing this all on the simulator.  If you have 
a development environment setup in Eclipse, and run LogicMail that way, you 
can at least see what sort of lockup is actually happening.  You're obviously 
testing a case I've never run into, which means I probably can't debug it on 
my own.

The trunk (1.9/2.0) version has a lot of threading and asynchronous stuff under 
the covers, so there's definitely a chance you either triggered a deadlock or 
(maybe) an infinite loop.  Most of my own testing so far has been far more 
"scripted" than a real user on a real device.  (i.e. I don't navigate screens 
while stuff is loading, or trigger loading different things at once)  So any 
debugging help you can offer is greating appreciated.

As far as entry point issues, that could be something getting corrupted in the 
build process, but I can't say.  I had those sorts of issues a lot when I was 
first getthing things ironed out, but haven't seen them in a while.  But there 
are two tidbits you should know about this:
- LogicMail (devel) has two "entry points", one that runs at BlackBerry 
startup to initialize device notifications, and the one that runs when you 
actully click the icon to start the app.
- The way Eclipse builds the app is *different* from the way "ant" builds the 
app.  Any entry-point settings or startup issues may be unique to the way you 
were building the app.  These problematic builds...  were they done in Eclipse 
(/w plugin), the RIM JDE, or straight Ant?

-Derek

On Tuesday 01 September 2009 3:20:29 am Chris Seawood wrote:
> Has anyone else managed to get 1.9.0 to lock up their BB hard?  I was
> giving it a test run last week to see if the new APIs would allow me to
> get passed my MS Exchange SSL/TLS problem.
>
> The first problem I saw was that LogicMail refused to get a list of
> folders from my personal Courier-Imap server.  I suspect that the
> problem has to do with either the number of folders (100+) or that the
> names of some folders are longer than the token 8 or 15 chars.  I run
> the same version of Courier-Imap at work with just a dozen folders and
> LogicMail had no problem getting a directory listing for that one.
>
> When attempting to send mail via the Exchange server, I received the
> exception message:
>   Unable to switch to TLS mode: (null)
> I'm not sure which condition in Connection.java startTLS() that I'm
> hitting.
>
> At some point, I tried repeatedly to connect to my personal imap server
> and send via Exchange/SSL and then the BlackBerry locked up.  I had to
> pull the battery to reset it.  Now, whenever I try to start up LogicMail
> 1.9.0 (any build from the past week), it appears to return to the same
> spot.  Occasionally, it will throw up a dialog box:
>
>     Uncaught exception: Module with handle [1823]
>     and index [0] has no application entry point
>             [OK]
>
> I've tried downgrading to 1.1.x, which works. But after re-upgrading to
> 1.9.0, the broken behavior persists.
>
> I purchased the signing keys and was able to build my own trunk version,
> sign it and install it but it behaves the same way.  I tried renaming
> the local build to LogicMail-1.9 via the project.properties file and the
> problem still persists.
>
> I used 'JavaLoader erase' to forcibly remove the bad modules from the
> device but when I load 1.9.0 again, it pops up the same dialog box with
> a different handle number.
>
> - cls
>
> ---------------------------------------------------------------------------
>--- Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and deployment - and
> focus on what you do best, core application coding. Discover what's new
> with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Logicmail-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logicmail-devel

-- 
---------------------------
Derek Konigsberg
dko...@lo...
---------------------------

[Logicmail-devel] lockup issue with 1.9.0 builds

[Chris S. <cl...@se...>]

Has anyone else managed to get 1.9.0 to lock up their BB hard?  I was
giving it a test run last week to see if the new APIs would allow me to
get passed my MS Exchange SSL/TLS problem.

The first problem I saw was that LogicMail refused to get a list of
folders from my personal Courier-Imap server.  I suspect that the
problem has to do with either the number of folders (100+) or that the
names of some folders are longer than the token 8 or 15 chars.  I run
the same version of Courier-Imap at work with just a dozen folders and
LogicMail had no problem getting a directory listing for that one.

When attempting to send mail via the Exchange server, I received the
exception message:
  Unable to switch to TLS mode: (null)
I'm not sure which condition in Connection.java startTLS() that I'm hitting.

At some point, I tried repeatedly to connect to my personal imap server
and send via Exchange/SSL and then the BlackBerry locked up.  I had to
pull the battery to reset it.  Now, whenever I try to start up LogicMail
1.9.0 (any build from the past week), it appears to return to the same
spot.  Occasionally, it will throw up a dialog box:

    Uncaught exception: Module with handle [1823]
    and index [0] has no application entry point
            [OK]

I've tried downgrading to 1.1.x, which works. But after re-upgrading to
1.9.0, the broken behavior persists.

I purchased the signing keys and was able to build my own trunk version,
sign it and install it but it behaves the same way.  I tried renaming
the local build to LogicMail-1.9 via the project.properties file and the
problem still persists.

I used 'JavaLoader erase' to forcibly remove the bad modules from the
device but when I load 1.9.0 again, it pops up the same dialog box with
a different handle number.

- cls

Re: [Logicmail-devel] J2ME vs BB-specific APIs

[Louis T. <lou...@gm...>]

Hey guys,

In case someone still doubts about the ton of work. Just think in term of
Derek vs. Google Gmail team. What LogicMail is gonna be is something better
than Gmail client for BB. That's why it looks like forever to get 2.x done.

Anyway i hope you, Derek would get it done soon. At least the whole
Vietnamese BlackBerry community is waiting for it.

Cheers.

On Wed, Aug 26, 2009 at 10:59 AM, WJCarpenter
<bil...@ca...>wrote:

>
> > Is it possible? Sure.  Is it a ton of work?  Absolutely. :-)
>
> I'll take your word for it and avoid distracting you and LogicMail from
> completing the BB quest in the 2.x line.  :-)
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Logicmail-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logicmail-devel
>

Re: [Logicmail-devel] J2ME vs BB-specific APIs

[WJCarpenter <bil...@ca...>]

> Is it possible? Sure.  Is it a ton of work?  Absolutely. :-)

I'll take your word for it and avoid distracting you and LogicMail from
completing the BB quest in the 2.x line.  :-)

Re: [Logicmail-devel] J2ME vs BB-specific APIs

[Derek K. <dko...@lo...>]

On Tuesday 25 August 2009 7:03:20 pm WJCarpenter wrote:
> [[First of all, forgive me!  I had LogicMail 1.0.4 installed for quite a
> while and figured it was just another half-baked but promising IMAP
> client that would soon be abandoned like so many others.  Just today I
> installed the lasted 1.9 build, and woo-hoo!  This baby is starting to
> rock!  It's now pretty close to what I have been looking for ever since
> I got my BlackBerry.  Kudos.]]
I'll admit that I'm certainly taking forever to get to 2.0.  Its because the 
scope and complexity of 2.0 is orders of magnitude beyond 1.x.  (and I did at 
least fork 1.1, which is 1.0 with updated development infrastructure, more bug 
fixes, and some community patches)  The real reason is that 1.x was almost too 
simple.  Really the minimum app that got the job done.  To make a desktop 
analogy, going from LM 1.x -> 2.0 is like going from Pine to Thunderbird, at 
least under the covers.

> I haven't had the chance to browse through the LogicMail sources, but I
> am curious about the separation/modularity/abstraction of the BB
> proprietary APIs versus generic J2ME APIs.  My assumption is that
> BB-specific APIs are used to save work and/or to make a better user
> experience.  Are there fundamental features that would be extremely
> difficult or impossible to implement without the BB-specific APIs?
This is an interesting topic, actually.  When starting on a BlackBerry app, 
its easy to think that you only need the BB-specific APIs for the UI and some 
minor integration issues.  However, once you really get going (and far more so 
once you cave in to getting a code signing key), you find that the generic J2ME 
are almost absurdly limited.  (and RIM is more than happy to fill the gap with 
their own stuff)

Now on the bright side, whenever RIM adds a major new general-purpose API 
feature these days, they do try to find and implement a JSR for it.  So at 
least some of the new stuff does tend to use standard Java APIs.  (however, 
J2ME in general seems to be a crapshoot across devices for anything 
interesting, or so I've heard, due to lack of forced standards)

So the general answer is that the UI code is all RIM-specific, while the non-UI 
code is mostly generic Java.  But the more detailed answer is that there's a 
whole smattering of net.rim.* classes used in non-UI code.  These classes 
cover everything from array-handling utilities, to sortable vectors, to 
efficient hashtables for storing primative types, to MIME parsing utilities, to 
persistant object storage for application configuration (ok, this is the only 
one I used a J2ME approach for in 1.x due to code signing), to Base64 
decoding, and various other random tidbits.

If you're curious, recursively search the source tree for import statements 
referencing anything starting with "net.rim".

> The real question I am asking is .... would it be feasible to have
> non-BB LogicMail versions where some things have alternative or missing
> or dumbed down implementations without BB-specific APIs?  The mobile
> world in general needs a good IMAP client so much, and LogicMail is
> starting to look so good, that it seems a shame to limit it to BB only.
> Even though I use a BB Bold, I might be able to put some effort into a
> "pure J2ME" LogicMail if it looks tractable in the first place.

Is it possible? Sure.  Is it a ton of work?  Absolutely. :-)
First you'd have to write a whole new UI, or do even more overcomplicated 
refactoring of the existing UI to remove any RIM class references from the 
code.
Then you'd have to essentially abstract and reimplement a whole variety of 
utility classes.

Another option might involve doing this to just the core "engine" of the 
application (mail protocol handlers and asychronous event-driven data model), 
and breaking that out into a common code base that can be shared by different 
front-end applications that handle everything else.

The biggest issue here is that there really is no "standard" for mobile Java.  
From what I've seen, you have the following:

Android - More modern J2SE 1.5 derrived API, but very much a Google creation

BlackBerry - J2ME underpinnings, with additional JSR-based APIs, but very much 
a RIM creation with plenty of BB-specific useful functionality to fill the gaps.

Generic J2ME - Somewhat unstandardised and often ugly (unless using a 3rd 
party UI toolkit) and definitely primative API designed for dumb phones, though 
also offered on real smartphones as what feels like a second-class citizen to 
the native platform.
(Caveat: Its been a while since I seriously looked at regular J2ME)

-- 
---------------------------
Derek Konigsberg
dko...@lo...
---------------------------

[Logicmail-devel] J2ME vs BB-specific APIs

[WJCarpenter <bil...@ca...>]

[[First of all, forgive me!  I had LogicMail 1.0.4 installed for quite a 
while and figured it was just another half-baked but promising IMAP 
client that would soon be abandoned like so many others.  Just today I 
installed the lasted 1.9 build, and woo-hoo!  This baby is starting to 
rock!  It's now pretty close to what I have been looking for ever since 
I got my BlackBerry.  Kudos.]]

I haven't had the chance to browse through the LogicMail sources, but I 
am curious about the separation/modularity/abstraction of the BB 
proprietary APIs versus generic J2ME APIs.  My assumption is that 
BB-specific APIs are used to save work and/or to make a better user 
experience.  Are there fundamental features that would be extremely 
difficult or impossible to implement without the BB-specific APIs?

The real question I am asking is .... would it be feasible to have 
non-BB LogicMail versions where some things have alternative or missing 
or dumbed down implementations without BB-specific APIs?  The mobile 
world in general needs a good IMAP client so much, and LogicMail is 
starting to look so good, that it seems a shame to limit it to BB only.  
Even though I use a BB Bold, I might be able to put some effort into a 
"pure J2ME" LogicMail if it looks tractable in the first place.

Re: [Logicmail-devel] Development Version

[Louis T. <lou...@gm...>]

Hi Derek,

It's nice now for the VI file. I've done fixing it almost. It's better now a
lot.

Could u do me a favour? It's about the subject, now i really need the
subject should be treated as the body before the Message will be sent. I
mean when putting Vietnamese in the subject, NOW, it becomes question marks
when it arrives. That's why i really need to know how to fix it by applying
the process which u r using to process the body part. Since the body is
correctly handled.

Thank you very much.

Louis Tang.

Re: [Logicmail-devel] Development Version

[Louis T. <lou...@gm...>]

I am touching the 1.1 now and i see it gets some problem with Vietnamese,
specially the resource file bundle, don't know why it's not correctly
displaying the meaningful text LOL...I am fixing them now. By the way, i am
gonna introduce 1.1 to Viet users soon tonight...

But before that, i will send you something which i correct or modify. Just
to let you know it's ready to serve while waiting for the 2.0

Anyway see ya later.

Louis Tang.

Re: [Logicmail-devel] Development Version

[Louis T. <lou...@gm...>]

Hi Derek,

For the Vietnamese translation I've got feedback that they would like to see
English rather than Vietnamese since something like the English language
used in term of email is very similar to them rather than Vietnamese. They
really understand what is going on within the LogicMail. That's why I stop
for a while and listen to people. I think just leave the Vietnamese
translation for a while, just keep English and other languages. If many
people like to have it then they will suggest me which part should be
translated. For example, the word "Reply" is so familiar to people when
using email, some guys ask me that how can they reply?!?!!? Since I
translated the word "Reply" into Vietnamese correctly, but they are always
looking for the word "Reply"...Just the habit.

For the Input Method, it's all inside the keyChar method. The code checks
the Char key parameter, checks where the cusor is, and if it's in the
TextField related components. Then the code will detect the current
character right before the cursor. Then depends on the character right
before the cursor and the character(key) the user have just entered, the
code decides whether it's an attempting to create Vietnamese characters or
not. for example, if we type letter ' o ', and type ' o ' again right after,
it should create ' ô ' which is the Vietnamese character. The code will
delete the current character, ignore the one has been entered and return new
special Vietnamese character in stead. It's might not easy to understand for
u since my English gets worse and worse..LOL =))

So, if we would like to plug the Input Method into somewhere which has the
TextField components, then just put the code into the keyChar method.
Actually the code the TextField components so it can delete the last letter,
insert new letter...It's so far i have made. I also need to improve the code
too. Although the speed of handling character is good. It's as fast as
normal typing in English. However i will improve it in order to make it
better and better.

I guess that we need an option like u did for the Unicode Converter.
Something like Vietnamese Input Method, if it's checked, then the keyChar
method will touch my code, otherwise it will ignore the detecting code. Or
we can have Vietnamese version like Opera does or the VNLogicMail. I think
this will be the last part and I can plug it in easily. You don't need to
handle it, when your global version is ready then we think about Vietnamese
version. It's my opinion, like the Opera does for Opera Mini. then the
package is simple and neat.

That's what i am thinking. You can decide and let me know when possible.

Regards.

Louis Tang.

On Wed, Jul 1, 2009 at 8:57 AM, Derek Konigsberg <dko...@lo...
> wrote:

> How exactly does this input method integrate, and how does it differ from
> the
> input methods normally selectable on the BlackBerry?  And is there a good
> way
> to integrate it that won't affect anyone who doesn't want to use it?
>
> I'm definitely interested in what you have, once its ready.  For both the
> 1.1
> branch and trunk, depending on what you've worked on.
>
> I'd also like updated Vietnamese translations, with priority give to the
> 1.1
> branch.
>
> Thanks.
>
> On Tuesday 30 June 2009 1:25:56 am Louis Tang wrote:
> > Dear Derek,
> >
> > I am finishing the Vietnamese Input Mechanism for BlackBerry OS 4.5 and
> > below( 4.6 or above should be finished soon). So when you need it or when
> u
> > need me to plug it in then let me know. Just an Input Method specially
> for
> > Vietnamese BB users.
> >
> > I test it with Gmail POP/IMAP client on BlackBerry and the result is
> sweet,
> > I can type Vietnamese correctly and the content is displayed correctly
> when
> > it arrives. And ofcos' it's Decomposed Unicode. I guest it doesn't mater
> of
> > Composed/Decomposed Unicode...As logn as it's displayed correctly.
> >
> > Anyway best wish and regards.
> >
> > Louis Tang.
>
> --
> ---------------------------
> Derek Konigsberg
> dko...@lo...
> ---------------------------
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Logicmail-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logicmail-devel
>

Re: [Logicmail-devel] Development Version

[Derek K. <dko...@lo...>]

How exactly does this input method integrate, and how does it differ from the 
input methods normally selectable on the BlackBerry?  And is there a good way 
to integrate it that won't affect anyone who doesn't want to use it?

I'm definitely interested in what you have, once its ready.  For both the 1.1 
branch and trunk, depending on what you've worked on.

I'd also like updated Vietnamese translations, with priority give to the 1.1 
branch.

Thanks.

On Tuesday 30 June 2009 1:25:56 am Louis Tang wrote:
> Dear Derek,
>
> I am finishing the Vietnamese Input Mechanism for BlackBerry OS 4.5 and
> below( 4.6 or above should be finished soon). So when you need it or when u
> need me to plug it in then let me know. Just an Input Method specially for
> Vietnamese BB users.
>
> I test it with Gmail POP/IMAP client on BlackBerry and the result is sweet,
> I can type Vietnamese correctly and the content is displayed correctly when
> it arrives. And ofcos' it's Decomposed Unicode. I guest it doesn't mater of
> Composed/Decomposed Unicode...As logn as it's displayed correctly.
>
> Anyway best wish and regards.
>
> Louis Tang.

-- 
---------------------------
Derek Konigsberg
dko...@lo...
---------------------------

Re: [Logicmail-devel] Development Version

[Louis T. <lou...@gm...>]

Dear Derek,

I am finishing the Vietnamese Input Mechanism for BlackBerry OS 4.5 and
below( 4.6 or above should be finished soon). So when you need it or when u
need me to plug it in then let me know. Just an Input Method specially for
Vietnamese BB users.

I test it with Gmail POP/IMAP client on BlackBerry and the result is sweet,
I can type Vietnamese correctly and the content is displayed correctly when
it arrives. And ofcos' it's Decomposed Unicode. I guest it doesn't mater of
Composed/Decomposed Unicode...As logn as it's displayed correctly.

Anyway best wish and regards.

Louis Tang.

Re: [Logicmail-devel] Development Version

[Derek K. <dko...@lo...>]

On Monday 29 June 2009 4:33:52 pm you wrote:
> > > 7) The user interface could stand a few improvements. One suggestion
> >
> The problem I have is that I have sub-folders, and I'm reduced to using the
> menu button instead of clicking on the folder to open it.

I did some investigation, and this is very much a Storm-specific issue.  To be 
more specific, I originally wrote LogicMail against the 4.1 API, which only 
supported thumbwheel devices.  When I started on 2.0, I implemented click-ball 
support in a way that was still backwards-compatible with the 4.1 API, using a 
bit of a kludge in how I override onMenu() in the BaseScreen class.

This workaround no longer functions correctly on the Storm (4.6).  My solution 
will be to fix how I handle navigation clicks by correctly overriding 
navigationClick() instead, which works fine on the Storm, and exists in 4.2 
onward.  (and LM 2.0 won't support anything older than 4.2.1 anyways, so this 
is now a non-issue)

I'll still need to do more Storm-simulator testing, because I might also be 
hooking to navigationUnclick() in some places now, and that doesn't trigger as 
reliably on the Storm as it does on click-ball devices.

> > > Another improvement would be to have icons for deleting, replying,
> The Storm mail program has a toolbar at the bottom of the screen when
> you're reading a message. There are about 4, reply, delete, move, and close
> (I think).

This would definitely have to be a Storm-specific UI mode.  I currently don't 
have any multi-OS-target support built into my source tree, and am still 
debating between the many different ways to accomplish it.  However, issues 
like this make it all the more important to actually have a few variants of 
the UI.  (I also know that 4.6, which my Bold runs, has some home screen hooks 
I'd like to use that are finally in the public API, for example.)

> > > It would be nice if you could make some of the buttons bigger on the
> > > dialogs. Examples would be the delete confirmation. If you could make
> I would have to say that should not be a real high priority then.
Its amazing just how many UI quirks appear on the Storm that are a complete 
non-issue on the rest of the traditional BB devices.  Its almost like you have 
to design a completely custom Storm-specific UI just to have a clean and usable 
app.  I wonder what RIM's future Storm plans are, and how future devices will 
work.  (I really wish they had a Wi-Fi capable Storm out there so I could play 
with something other than the simulator, since I really don't want to move my 
SIM out of my Bold just for tinkering)

> > > 8) The "Move" function doesn't work right. I can't move things to a
> I can't select the folder. Attempting to select the folder
> expands/unexpands it.
See my comment near the top of the message.  I think any/all TreeField widgets 
in the app are currently affected by the exact same issue, but hopefully it 
shouldn't be too hard to fix in a BB OS 4.2 compatible way.

> > > 9) Attachments aren't handled. With the Blackberry mail client, I can
> That's fine. 99% of my attachments are PDFs and Word documents.
Which reminds me that I need to implement some stub support for all the major 
MIME types so the app will correctly let you download/save such attachments.  
(and then, on-demand attachment downloading is coming up really soon on my to-
do list)

> > > If I pull the current code down from Subversion and compile it, is
> Maybe I'll try downloading the source and taking a look at it. I'm a pretty
> decent Java programmer.
If you merge in the subscribed-folder bits as implemented in the 1.1 branch, 
it'll take a little hand-tweaking to make everything line up in the diff tools.  
(personally, I've become partial to BeyondCompare, even if it costs money)  
The real tricks will just be working through the use cases of where to put the 
option, and how to react to it being changed.  (which goes back to many 
possible configuration-change use cases, and what should/shouldn't trigger a 
refresh of the known/loaded folder tree)

Going forward, if you'd like to become a contributor, I'd certainly welcome 
that.  One thing you're definitely reminding me to do is get serious about 
multi-OS support, so the Storm UI can be better.  And if I head in that 
direction, I really need to get back on track with my attempt at refactoring 
the UI to a model-view-presenter approach, which I never really did to more 
than the MailHomeScreen.

-- 
---------------------------
Derek Konigsberg
dko...@lo...
---------------------------

Re: [Logicmail-devel] Development Version

[Derek K. <dko...@lo...>]

Now that I've finally had time to look through and follow up on this, my
comments are below:
(FYI, what I refer to as "trunk" can also be known devel version, 1.9.0(X),
or milestone 2.0)

On Thu, 25 Jun 2009 13:00:29 -0600, "George Sexton"
<ge...@mh...>
wrote:
> I've been using the LogicMail 1.9.0(49) build for a while with a
Blackberry
> Storm and Courier IMAP on the server, and I wanted to give some feedback.
FYI, my personal configuration is a BlackBerry Bold on Cyrus IMAP, in case
anyone else here is curious.

> 1) It's vastly more reliable than 1.0.x and 1.1.x.
Interesting, since the low-level bits aren't that different.  Though I've
made a few minor data structure tweaks in the low-level network code of
1.1.x and trunk recently, the only real difference here is the way the
low-level code interacts with the rest of the app, and the fact that all
IMAP message referencing is UID-based in trunk, while its pure index-based
in 1.x.

> 2) I'd really love to see the subscribed folder option that's in 1.1.x on
> the devel build.
Yes, I definitely need to forward-port this one.

> 3) There should be a Delete option available from the menu when you're
> reading a message.
Will do

> 4) URLs embedded into messages are not clickable. I have preferred
message
> format set to HTML.
If you're talking about actual HTML message content, then I'll have to test
this one on the Storm simulator.  Also, I'll mention that the whole menu
handling of the HTML message field is a bit of a hack, since the API for
dealing with that isn't very clean.  However, it works on the 8800
simulator I normally use for development.  If you're talking about normal
plain text message content, then its a feature I still need to implement.

> 5) The move function doesn't seem to remove a message from the source
> folder. I selected Move from the Inbox to a sub-folder, and there are
> copies
> of the message in both places now. This is not just on the hand-held, but
> on
> the server itself.
This request prompted me to add the "Code Tags" Trac plugin to the project
website, so everyone can easily see notes I leave for myself while working
on the code.  Why?  Smack in the middle of the method that handles Move,
you'll find this comment:
//TODO: Move To Folder should delete after append

That being said, I still need to implement the IMAP COPY command, which is
the correct/safe way to handle copy and move.  Currently, the implemented
method just uses data already downloaded into LogicMail.  This works fine
for cross-account copies, but isn't really guaranteed to be an exact copy
of the original message, so I never felt comfortable using it for Move. 
Okay, so if you're not confused enough by now...  I'll make Move work
correctly as soon as I fix the Copy implementation to use IMAP COPY.

> 6) Delete doesn't work quite right. If I delete a message, it deletes on
> the
> server but the message is still shown in the Inbox. I've set the global
> configuration option to hide deleted messages. If I delete, and I have
hide
> deleted messages set, then the message should no longer be displayed.
I'll need to investigate and fix this.  Probably just a use case I haven't
tried yet.

> 7) The user interface could stand a few improvements. One suggestion that
> jumps out is handling nested folders. In order to open the Inbox, which
has
> sub-folders, I have to select the menu folder, click the Menu button, and
> then click on "Select". It would be really nice if maybe the default
action
> was to expand the folder, while pressing down the folder for an extended
> period would open it. Sort of like the way the keyboard works. You press
> the
> "s" button, and you get "s". Hold it down longer, and you get "S".
Not a bad idea, but I can also think of plenty of cases where this could
get exceptionally annoying.  (especially when INBOX has sub-folders)  So
we'll need to think about and discuss this one further.  It may also make
sense to design a somewhat Storm-specific folder tree, which actually makes
the "[+]" mark next to the folder into something independently click-able.

On keyboard devices, I'll probably want to stick with SPACE to expand,
ENTER/click to open.

> Another improvement would be to have icons for deleting, replying, etc.
> visible in the bottom of the screen when you're viewing a message.
Providing a rough visual mock-up of how this might look would be helpful. 
This is also probably something only Storm users would actually want,
unless you can think of a way to do it that would also be usable for
traditional BB users.  Heck, there may be a lot of Storm-specific usability
ideas out there that should probably be implemented.

> It would be nice if you could make some of the buttons bigger on the
> dialogs. Examples would be the delete confirmation. If you could make the
> buttons half again taller, and twice as wide, that would make them 3
times
> larger. That would be a LOT easier to hit.
This dialog is pretty much a standard BlackBerry UI popup screen, so its
really RIM's fault that it is hard to use on the Storm.  Of course creating
a customized Storm-specific version could help as a workaround.

> 8) The "Move" function doesn't work right. I can't move things to a
message
> folder that has sub-folders. For example, I have "Calendar" folder that
> contains messages, and "Errors" which is a sub-folder of Calendar. I
can't
> move the message to the Calendar folder.
Can you clarify?  Is the problem that you can't select the destination
folder, or that you can select it but the move/copy operation fails?

> 9) Attachments aren't handled. With the Blackberry mail client, I can
read
> PDFs that are attached. Perhaps this is a server-side function and the
PDF
> isn't actually rendered on the handheld.
I'm just starting to implement attachment handling.  The latest build
actually gives you the ability to save them, for example.  However, I
haven't yet implemented selective attachment downloading, or the ability to
open attachments.  Of course, you'll only be able to actually open
attachments for which the BlackBerry has a registered content handler, or
the native ability to display.

> If I pull the current code down from Subversion and compile it, is the
> Subscribed Folder handling in the repository? If not, is the patch
> available
> someplace so that I could integrate it?
The subscribed-folder thing isn't implemented in trunk yet, so the answer
is no.

P.S. While replying to this message, I've put together a little to-do list
for myself.

-- 
----------------------------
Derek Konigsberg
dko...@lo...
----------------------------

[Logicmail-devel] Development Version

[George S. <ge...@mh...>]

I've been using the LogicMail 1.9.0(49) build for a while with a Blackberry
Storm and Courier IMAP on the server, and I wanted to give some feedback.

1) It's vastly more reliable than 1.0.x and 1.1.x.
2) I'd really love to see the subscribed folder option that's in 1.1.x on
the devel build.
3) There should be a Delete option available from the menu when you're
reading a message.
4) URLs embedded into messages are not clickable. I have preferred message
format set to HTML.
5) The move function doesn't seem to remove a message from the source
folder. I selected Move from the Inbox to a sub-folder, and there are copies
of the message in both places now. This is not just on the hand-held, but on
the server itself.
6) Delete doesn't work quite right. If I delete a message, it deletes on the
server but the message is still shown in the Inbox. I've set the global
configuration option to hide deleted messages. If I delete, and I have hide
deleted messages set, then the message should no longer be displayed.
7) The user interface could stand a few improvements. One suggestion that
jumps out is handling nested folders. In order to open the Inbox, which has
sub-folders, I have to select the menu folder, click the Menu button, and
then click on "Select". It would be really nice if maybe the default action
was to expand the folder, while pressing down the folder for an extended
period would open it. Sort of like the way the keyboard works. You press the
"s" button, and you get "s". Hold it down longer, and you get "S".

Another improvement would be to have icons for deleting, replying, etc.
visible in the bottom of the screen when you're viewing a message.

It would be nice if you could make some of the buttons bigger on the
dialogs. Examples would be the delete confirmation. If you could make the
buttons half again taller, and twice as wide, that would make them 3 times
larger. That would be a LOT easier to hit.

8) The "Move" function doesn't work right. I can't move things to a message
folder that has sub-folders. For example, I have "Calendar" folder that
contains messages, and "Errors" which is a sub-folder of Calendar. I can't
move the message to the Calendar folder.
9) Attachments aren't handled. With the Blackberry mail client, I can read
PDFs that are attached. Perhaps this is a server-side function and the PDF
isn't actually rendered on the handheld.

If I pull the current code down from Subversion and compile it, is the
Subscribed Folder handling in the repository? If not, is the patch available
someplace so that I could integrate it?

George Sexton
MH Software, Inc. - Home of Connect Daily Web Calendar
http://www.mhsoftware.com/
Voice: 303 438 9585
  

[Logicmail-devel] Feature request

[Stefan W. <45...@gm...>]

I would like to say thank you again. With your latest build I’m not only able the receive mails, I can also send mails. That’s very cools ! Thank you.

At this point I would like to submit an feature request for upcoming releases. For me it would be very handy when the application starts directly with my inbox instead of using the folder view. That would be more similar to other blackberry menus.

Thanks
Stefan

-------- Original-Nachricht --------
> Datum: Mon, 8 Jun 2009 20:10:06 -0400
> Von: Derek Konigsberg <dko...@lo...>
> An: log...@li...
> Betreff: Re: [Logicmail-devel] building branch 1.1 using ant

> Thanks for the reminder!
> 
> I'd totally forgotten about that issue.  When I first started using the
> newer 
> JDE libraries, I did discover that I'd accidentally been using some 
> undocumented/unsupported methods of the Arrays utility class that got
> removed.  
> (gotta love IDE code completion, I guess)  I'll go ahead and back-port
> that 
> little fix.  (besides, the whole event listener bit was really just a
> proof-of-
> concept in the 1.x branch anyways, though its used quite extensively in
> trunk)
> 
> -Derek
> 
> On Monday 08 June 2009 12:25:38 am Chris Seawood wrote:
> > FYI,
> >
> > Using rev 454 of /branches/LogicMail-1.1 , I get the following error
> > when attempting to build the project using ant (1.7.0 from the eclipse
> > plugin) and JDE 4.5.0 .  The problem goes away if I merge r308 of
> > trunk/LogicMail/src/org/logicprobe/LogicMail/util/EventListenerList.java
> > onto the 1.1 branch.
> >
> > cls@shockwave ~/mydocs/Blackberry/LogicMail-1.1/LogicMail
> > $ ant
> > Buildfile: build.xml
> >
> > build:
> >     [mkdir] Created dir: c:\Documents and Settings\cls\My
> > Documents\Blackberry\LogicMail-1.1\LogicMail\dist
> >      [copy] Copying 1 file to c:\Documents and Settings\cls\My
> > Documents\Blackberry\LogicMail-1.1\LogicMail\dist
> >      [rapc] Compiling 101 source files to LogicMail.cod
> >      [rapc] C:\Documents and Settings\cls\My
> >
> Documents\Blackberry\LogicMail-1.1\LogicMail\src\org\logicprobe\LogicMail\u
> >til\EventListenerList.java:67: cannot find symbol
> >      [rapc] symbol  : method removeAt(java.lang.Object[],int)
> >      [rapc] location: class net.rim.device.api.util.Arrays
> >      [rapc]                Arrays.removeAt(listenerList, i);
> >      [rapc]                      ^
> >      [rapc] C:\Documents and Settings\cls\My
> >
> Documents\Blackberry\LogicMail-1.1\LogicMail\src\org\logicprobe\LogicMail\u
> >til\EventListenerList.java:68: cannot find symbol
> >      [rapc] symbol  : method removeAt(java.lang.Object[],int)
> >      [rapc] location: class net.rim.device.api.util.Arrays
> >      [rapc]                Arrays.removeAt(listenerList, i);
> >      [rapc]                      ^
> >      [rapc] Note: Some input files use or override a deprecated API.
> >      [rapc] Note: Recompile with -Xlint:deprecation for details.
> >      [rapc] 2 errors
> >      [rapc] Error!: Error: java compiler failed: javac -source 1.3
> > -target 1.1 -g -O -d C:\cygwin\tmp\rapc_679a1f33.dir -bootclasspath
> > "C:\Program F ...
> >
> > BUILD FAILED
> > c:\Documents and Settings\cls\My
> > Documents\Blackberry\LogicMail-1.1\LogicMail\bu
> > ild.xml:35: Java returned: 97
> >
> > Total time: 6 seconds
> >
> > - cls
> >
> >
> ---------------------------------------------------------------------------
> >--- OpenSolaris 2009.06 is a cutting edge operating system for
> enterprises
> > looking to deploy the next generation of Solaris that includes the
> latest
> > innovations from Sun and the OpenSource community. Download a copy and
> > enjoy capabilities such as Networking, Storage and Virtualization. Go
> to:
> > http://p.sf.net/sfu/opensolaris-get
> > _______________________________________________
> > Logicmail-devel mailing list
> > Log...@li...
> > https://lists.sourceforge.net/lists/listinfo/logicmail-devel
> 
> 
> -- 
> ---------------------------
> Derek Konigsberg
> dko...@lo...
> ---------------------------
> 
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Logicmail-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logicmail-devel

Re: [Logicmail-devel] building branch 1.1 using ant

[Derek K. <dko...@lo...>]

Thanks for the reminder!

I'd totally forgotten about that issue.  When I first started using the newer 
JDE libraries, I did discover that I'd accidentally been using some 
undocumented/unsupported methods of the Arrays utility class that got removed.  
(gotta love IDE code completion, I guess)  I'll go ahead and back-port that 
little fix.  (besides, the whole event listener bit was really just a proof-of-
concept in the 1.x branch anyways, though its used quite extensively in trunk)

-Derek

On Monday 08 June 2009 12:25:38 am Chris Seawood wrote:
> FYI,
>
> Using rev 454 of /branches/LogicMail-1.1 , I get the following error
> when attempting to build the project using ant (1.7.0 from the eclipse
> plugin) and JDE 4.5.0 .  The problem goes away if I merge r308 of
> trunk/LogicMail/src/org/logicprobe/LogicMail/util/EventListenerList.java
> onto the 1.1 branch.
>
> cls@shockwave ~/mydocs/Blackberry/LogicMail-1.1/LogicMail
> $ ant
> Buildfile: build.xml
>
> build:
>     [mkdir] Created dir: c:\Documents and Settings\cls\My
> Documents\Blackberry\LogicMail-1.1\LogicMail\dist
>      [copy] Copying 1 file to c:\Documents and Settings\cls\My
> Documents\Blackberry\LogicMail-1.1\LogicMail\dist
>      [rapc] Compiling 101 source files to LogicMail.cod
>      [rapc] C:\Documents and Settings\cls\My
> Documents\Blackberry\LogicMail-1.1\LogicMail\src\org\logicprobe\LogicMail\u
>til\EventListenerList.java:67: cannot find symbol
>      [rapc] symbol  : method removeAt(java.lang.Object[],int)
>      [rapc] location: class net.rim.device.api.util.Arrays
>      [rapc]                Arrays.removeAt(listenerList, i);
>      [rapc]                      ^
>      [rapc] C:\Documents and Settings\cls\My
> Documents\Blackberry\LogicMail-1.1\LogicMail\src\org\logicprobe\LogicMail\u
>til\EventListenerList.java:68: cannot find symbol
>      [rapc] symbol  : method removeAt(java.lang.Object[],int)
>      [rapc] location: class net.rim.device.api.util.Arrays
>      [rapc]                Arrays.removeAt(listenerList, i);
>      [rapc]                      ^
>      [rapc] Note: Some input files use or override a deprecated API.
>      [rapc] Note: Recompile with -Xlint:deprecation for details.
>      [rapc] 2 errors
>      [rapc] Error!: Error: java compiler failed: javac -source 1.3
> -target 1.1 -g -O -d C:\cygwin\tmp\rapc_679a1f33.dir -bootclasspath
> "C:\Program F ...
>
> BUILD FAILED
> c:\Documents and Settings\cls\My
> Documents\Blackberry\LogicMail-1.1\LogicMail\bu
> ild.xml:35: Java returned: 97
>
> Total time: 6 seconds
>
> - cls
>
> ---------------------------------------------------------------------------
>--- OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization. Go to:
> http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Logicmail-devel mailing list
> Log...@li...
> https://lists.sourceforge.net/lists/listinfo/logicmail-devel


-- 
---------------------------
Derek Konigsberg
dko...@lo...
---------------------------

[Logicmail-devel] building branch 1.1 using ant

[Chris S. <cl...@se...>]

FYI,

Using rev 454 of /branches/LogicMail-1.1 , I get the following error
when attempting to build the project using ant (1.7.0 from the eclipse
plugin) and JDE 4.5.0 .  The problem goes away if I merge r308 of
trunk/LogicMail/src/org/logicprobe/LogicMail/util/EventListenerList.java
onto the 1.1 branch.

cls@shockwave ~/mydocs/Blackberry/LogicMail-1.1/LogicMail
$ ant
Buildfile: build.xml

build:
    [mkdir] Created dir: c:\Documents and Settings\cls\My
Documents\Blackberry\LogicMail-1.1\LogicMail\dist
     [copy] Copying 1 file to c:\Documents and Settings\cls\My
Documents\Blackberry\LogicMail-1.1\LogicMail\dist
     [rapc] Compiling 101 source files to LogicMail.cod
     [rapc] C:\Documents and Settings\cls\My
Documents\Blackberry\LogicMail-1.1\LogicMail\src\org\logicprobe\LogicMail\util\EventListenerList.java:67:
cannot find symbol
     [rapc] symbol  : method removeAt(java.lang.Object[],int)
     [rapc] location: class net.rim.device.api.util.Arrays
     [rapc]                Arrays.removeAt(listenerList, i);
     [rapc]                      ^
     [rapc] C:\Documents and Settings\cls\My
Documents\Blackberry\LogicMail-1.1\LogicMail\src\org\logicprobe\LogicMail\util\EventListenerList.java:68:
cannot find symbol
     [rapc] symbol  : method removeAt(java.lang.Object[],int)
     [rapc] location: class net.rim.device.api.util.Arrays
     [rapc]                Arrays.removeAt(listenerList, i);
     [rapc]                      ^
     [rapc] Note: Some input files use or override a deprecated API.
     [rapc] Note: Recompile with -Xlint:deprecation for details.
     [rapc] 2 errors
     [rapc] Error!: Error: java compiler failed: javac -source 1.3
-target 1.1 -g -O -d C:\cygwin\tmp\rapc_679a1f33.dir -bootclasspath
"C:\Program F ...

BUILD FAILED
c:\Documents and Settings\cls\My
Documents\Blackberry\LogicMail-1.1\LogicMail\bu
ild.xml:35: Java returned: 97

Total time: 6 seconds

- cls

[Logicmail-devel] Server maintenance notice

[Derek K. <dko...@lo...>]

The server that hosts the LogicMail project website will be going down for 
maintenance tomorrow (5/16/09) morning.  It is being moved from one co-lo 
facility to another, so I expect it to be offline for several hours starting 
around 9am EDT.

When it comes back up, it will have a new IP address, so the updated DNS 
records may take some time to propagate.  Don't worry if it takes a little 
while before you can get to it again.

P.S. Yes, I do have complete backups just in case.
-- 
---------------------------
Derek Konigsberg
dko...@lo...
---------------------------

[Logicmail-devel] Development status and direction

[Derek K. <dko...@lo...>]

So I'm sitting here in a local coffee shop place on a Sunday afternoon, and
getting ready to pack up.  I figured that since we now have mailing lists up
and running, I might as well get the conversation flowing a little more
freely than the occasional blog post or private e-mail.  If you've been
following the project website lately, it should be obvious that I now have 2
somewhat parallel development efforts (both with automated builds) going on
now.  So I'll comment on them separately:

 

LogicMail 1.1, "the maintenance branch":

-          Continuing to merge in translations from trunk, and adding
resource references for any other user-visible strings I find.  Most of the
normal screens are done.  Still have some error/status messages to do, and
the configuration screens (which have the most text to deal with).
Eventually, I'll need to get the translators to go over these resource files
once things stabilize

-          Merged in 4 contributed patches, #74, #75, #131, #132.  These
were provided by a user named "cls", who has not given me an e-mail address.

-          Still have some possible outstanding bugs to resolve (i.e. #133,
when servers need an authenticated user to not lie about capabilities)

-          May have a bug in POP message parsing, as seen on
Logicmail-users, still need to reproduce

-          Some of the above patches may need corresponding 2.0
implementations

-          May have some outstanding issues with international character
encoding for message composition (will affect 2.0 as well)

 

LogicMail 2.0, "trunk"

-          Implemented a quick fix for the Outbox so you can send mail
again.  This issue was a side-effect of some oversight in a major
refactoring that changed messages to be referenced by MessageToken objects
instead of the less clean FolderMessage objects.  Still need to make Outbox
a real persistable mailbox, but it will need a different implementation than
other local folders.  (outgoing messages need associated metadata, and
FileConnection (what other local mailboxes use) may have issues on some
devices/security policies)

-          Finally checked in a new Message Properties screen, to replace
the Message Properties dialog.  This makes it easier to show more detail
about a message, especially its MIME structure.

-          Currently planning the next major refactoring, which is a
necessary prerequisite to message caching, selective loading, and better
attachment handling.

o   This refactoring will completely separate the MIME structure tree of a
message from the actual content.

o   The plan is the strip all content out of the MessagePart class
hierarchy, keeping those objects to represent only structure and arguments
(i.e. MIME type/subtype, charset, filename, size, etc.)

o   Then a new MessageContent class hierarchy will be created to hold actual
content.  These will support selective loading, and be directly accessible
likely using the corresponding MessagePart as a key.

o   The whole message loading process will need major changes to support all
of this, especially since IMAP lets you retrieve the structure separately
from the content, but POP does not.

 

So what does this mean for everyone?  Well, I just gave you an exhaustive
dump of my current thought process.  (and since I work an unrelated job
doing other Java coding M-F, this won't get more than a few hours attention
here or there until next weekend)  How can everyone get involved?  Well,
this e-mail should hopefully start that discussion.  I'm thinking I can
start by delegating out some of the outstanding 1.1 activities, but there
probably are plenty of 2.0-related things that I could use help with too.

 

-Derek

 

 

[Logicmail-devel] Welcome to the LogicMail Development mailing list!

[Derek K. <dko...@lo...>]

This is the development mailing list. Subscribe to this list to take part in 
discussions about anything relating to the development of LogicMail.

-- 
---------------------------
Derek Konigsberg
dko...@lo...
---------------------------