color preview!

i really don't think you should release before having a color preview .... they kinda go hand in hand.

Not sure how difficult this would be, as I have never coded a Gnome Applet... but how hard would it be to get this to sit on the GNOME panel like Windows version sits on the Task Bar?

I imagine the Applet version would be a different application than the Real(tm) version, and the Applet would just call the Real(tm) version when it was needed. The applet could do things like

a) make silly noises flash crazy icons when it has been too long since you have updated

b) blink when your friends update

c) go nutsy-cukoo when a comment is posted to your journal

d) notify you of LoserJabber updates


None of this stuff is really important, and is just extra crap that might be fun.

Thanks for all the hard work on such a great client. I know Brad had made it reasonably easy to code a client by making the protocol so straight forward, but I also know how difficult it can be to design, program, debug, release and troubleshoot an application.

Maybe when my C programming skills are up to par, I can try to help out a little. If there is anything (non-C) related I can do to help, please let me know.

Thanks Again.
Daniel

A GNOME applet would be easy. The tricky part is selectively linking to the GNOME libraries.

I considered using GNOME from the beginning, but I decided against it because many people do not want to install the GNOME libraries.
GNOME applications are written a bit differently than GTK applications; there are a lot of "stock" designs like the menu icons which would have to be selectively compiled in (if the user wanted GNOME support) to make LoserJabber a complete GNOME app.

But for just panel support, I'll keep it in mind. I've never kept LoserJabber running, because it leaked memory... but I think I fixed it in this last release. :)

I just checked out the latest CVS and compiled it. It compiled beautifully, with no warnings or other problems. I am running Mandrake 7.1 with XMMS 1.2.2 and GTK 1.2.8 and ispell 3.1.20.


Daniel

Saving posted journal entries? I think one of the text only lj programs does this already.

also, its a hassle to dial in and login to type something in loserjabber.. usually I end up typing something in gedit or vi and copy and paste into loserjabber. maybe it'd be better to have a textbox already open? and when you're ready to post, you'd dial in.. and hit submit which would then ask for the login/password.

This would be rather annoying to those of us who have Cable, DSL or any other type of constant connection to the Internet. I leave LJ running all day. I only log in once. I don't want to have to type my username and password EACH time I post if I don't have to. I may be wrong, but I think the client sends the username and password EVERYTIME and just doesn't ask for it everytime. So, in theory, one could design the application to not "log in" to begin with... but then it just makes things function wierd. Just about EVERY other application gets a username/password first, and then never asks again unless there is a problem. In order to fit the "standard" user interface, this application should do the same, in my opinion.

I guess it wouldn't be so bad to not "verify" the username and password upon initial "connection" to the LiveJournal servers, and to perform those duties at "Submit" time, then if there were an incorrect password error, or something of that nature, display that message to the user then. But to ask for the username and password each time a submit is performed would just be bad design.

YMMV.

I guess that's the thing. I have to dial in a lot (only one phone line) and it'll be a cold day in hell before we ever get cable or less than $100 a month dsl service. it was just a minor nitpick since I lose my thoughts a lot and usually write something down in some other editor, which isn't a big deal. I also tend to restart X a lot too.

I guess the only problem i'd see is that to do anything with loserjabber you have to be on the net, and login.

I was just thinking too.. email clients let you write things down and put it in an outbox type of folder. and when you do connect, you can do a 'send now' type of action.

So you are talking about an "OutBox" for LJ entrys. Now that is indeed a good idea.

Just because there are network problems, or the servers are down, or any other of the billion reasons someone could end up not being able to update, doesn't mean people don't STILL want to update. The client could store the Journal Entry to be sent at a later date.

A simple XML file format would work just fine, and users should have the ability to edit, delete and (of course) attempt to send the queued entries. One (not so obvious) benefit of this feature addition would be that the Linux client would do something the Windows client doesnt [NEENER] until Brad gives in and adds it on his side too.

I still don't think this is CRUCIAL... but nice to have? Definately.

Ack, XML introduces a dependency I'd rather avoid. But yes, storing it will do.

And I wouldn't be so quick to neener at Brad, 'cause he wrote a significant part of LoserJabber... :P

That is true. XML means one more thing a user has to have installed in order for LJ to work out-of-the-box(tm). Something plain and simple (and text based) would be fine.

I wouldn't neener Brad... I haven't done shit to neener him about. I was suggesting that YOU could. *smirk*

When you say "save posted journal entries", do you mean you want to keep local copies of the journal entries you've already written? Or do you mean some sort of outbox-like support (which you mentioned later)?

I'm looking at it thru an email program sort of way, where you have folders/directories like 'posted entries' 'outbox'.
so inside .lj directory would be posted-entries/1-2-00-1100-AM

I was originally planning to save already-posted entries locally. The older versions of LoserJabber support this.

I removed it because it's difficult to stay in sync with the server. (For example, if you removed an entry using a different client...)

The outbox idea sounds good. It's on the TODO list now.

Although I do not think it is CRUCIAL to this release of LJ, I think it would be nice to be able to edit the MetaData as well as the event text, subject, and date/time when editing an already posted journal entry.