Log in

No account? Create an account
LogJam [entries|archive|friends|userinfo]

[ website | LogJam ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

ljit - a tool for posting images to LJ [Sep. 17th, 2003|08:38 pm]


I use logjam for posting to LiveJournal and found it very nice and useful (thank you, evan). But after some time of using it I have finally realized what some pieces of functionality that would be useful for me are missing.

One such piece is an ability to insert images to journal entries. Sure I know HTML well and can write IMG tag with all needed attributes. But it is boring; besides, I have to upload image to some web server and learn its dimensions (for writing width and height attributes). This involves a lot of typing, and is error-prone. Even more typing is needed if you want to resize image.

So I wrote a small GUI-based utility called ljit (for the sake of better name), which really saves me a lot of typing. Visit ljit home page for more info and download. I use the program right from logjam (with the help of “insert command output” patch, which hopefully be included into next logjam release).

Note that it’s still a beta software; although I believe it can be useful for people. Sure it’s free software (covered by GNU GPL).

PS Unofficial source RPM of logjam patched with the above mentioned patch (and with yet another patch adding the other feature I feel missing) is available from here (501 Kb). To build binary RPMS, use rpmbuild --rebuild command.

From: evan
2003-09-17 12:18 pm (UTC)
I haven't tried it yet, but this looks awesome!

I've often wanted similar functionality in LogJam, so it might be worthwhile to merge some of it. I'm not sure how much of this belongs in LogJam (managing passwords to sites other than LiveJournal makes me a little nervous), but at least doing the auto-width/height would be useful.

For example, you could have a menu option like "insert image", that retrieves the URL and automatically extracts the width/height from the image...
(Reply) (Thread)
[User Picture]From: k001
2003-09-18 03:08 am (UTC)
I was thinking about the same thing too (having "insert image" menu option in LogJam which asks for URL and inserts the proper IMG tag). But finally I found out that this functionality is not enough, because most of the time I want a thumbnail image linked to original picture inserted to my journal.

Also, most of pics I want to post are on my local PC and have to be uploaded somewhere first. The process of me uploading image and then LogJam downloading it just to know its size looks ugly to me.

So I ended up with an idea of separate app that suits my needs and can be called right from LogJam. This is also consistent with UNIX philosopy "app should do one thing, and do it well".
(Reply) (Parent) (Thread)
From: evan
2003-09-18 09:16 am (UTC)
Those are very good points. And with the "insert command output" feature it integrates well already. :)
(Reply) (Parent) (Thread)
[User Picture]From: k001
2003-09-18 09:35 am (UTC)
Still, I'd rather see "Insert image" menu item which will run logjam.

But for it to be implemented in a right (read generic) way, we need some configuration dialog where you can add items to menu and commands to be executed. And that looks too cumbersome to me, so afer all I'm OK with 'insert command output' (which itself need to use GtkCombo instead of GtkEntry and remember last, say, 5 commands.

The patch of "external command output" still needs work, because we have to at least redraw GUI while waiting for command to finish. This can be either implemented with two processes, or using select() on FD returned by popen() with a small timeout and redraw the GUI in between calls to select(). I tried the 'select' approach but haven't succeeded.
(Reply) (Parent) (Thread)
From: evan
2003-09-18 10:20 pm (UTC)
Yes, the blocking is why I haven't committed the "external command output" patch yet.

I think the right way to do this is:
- pop up a dialog, asking for the command.
- when they pick ok, show a "waiting for command to complete" dialog, do a gtk_input_add_full() on the file descriptor, and then run gtk_main() to let the dialog continue processing while waiting for the command. (this is how the blocking network processes run while the gui still updates.)
- if they hit cancel from that dialog, stop watching the fd, and maybe kill() the process.

That way, there is no blocking.
(Reply) (Parent) (Thread)