If you're going to put in libxml and gtkhtml support, at least put compile-time options like --disable-libxml and --disable-gtkhtml, and don't require them for normal program usage. Those features would definitely be useful, though.
I should clarify that I said "Ick" for the second question, but because of reason for the next answer: "browsing functionality belongs in the web browser." Library dependencies are not bad; programs that try to do too many things are.
I can see LogJam evolving to read mail, just like that law about bloated programs... first we'll want to read LJ posts, then we'll want to be able to reply to them from within the client, then we'll want to get notification of those replies... voila! an email reader! ;-)
However, I wouldn't be against a checkfriends feature (and I thought about writing it myself before I realized it would be much easier to do in Perl).
Also, I'm not really sure what "fancy features" means in the third question. Are they something that can't be handled individually through autoconf?
"Browsing functionality belongs in the web browser." I agree. The idea isn't too rewrite a complete browser, just to display a single web page. If you clicked any links, up would pop a web browser. No forward. No back. No location toolbar.
It would let you keep track of all of your journals in one place, and would save the web from reloading again and again by keeping track of checksums
for non-LJ journals, and checkfriends for LJ.
You might think of it as a "friends" view for the entire world wide web.
(The gui needs some work yet, I know.)
So that's the reasoning behind gtkhtml. I agree it should go in with an autoconf option, the question is whether we should support every permutation of libraries as an option. Doing so is not only a major pain in the ass, it also litters the code with ifdefs. So the idea is to pick some "target platforms" and support them.
Erm. When I was thinking gtkhtml, I wasn't quite thinking of it that way.. The UI looks more bloated than an actual browser.
I don't much like the gui either, I've been thinking of a good way to keep the functionality but have a better presentation.
Any ideas for a better display? (glade mockups gladly accepted.)
Hm. well if it's just to preview a journal entry, a whole browser-type interface isn't necessary at all. maybe just either a pop-up window or a replacement of the current text box with the gtkhtml mockup of it.. nothing fancy, no need to see the whole livejournal friends page.
2001-08-03 05:09 am (UTC)
Do you have a snapshot available for download? I want to figure out how integration into Evolution works, and I'm running a binary RPM release that I can't afford to download the source for (dialup link).
You won't be able to "figure out how integration into Evolution works" without looking at the source, anyway.
When it stabilizes, there'll be binaries. It's still undergoing massive changes.
Instead of linking in another library, couldn't it just pass the html along to the gnome http-handler or whatever it's called? You can set a default browser in gnome, why not use it? Or does it require gtkhtml just to pass it along?
2001-08-01 05:05 pm (UTC)
LogJam does use gnome's http handler, but John is integrating some browsing support directly into LogJam.
2001-07-29 04:24 pm (UTC)
change for your nickel
I assumed for the purposes of this survey that s/GNOME/gnome-libs/. gnome-xml
is also a part of the current GNOME distribution, as is gtkhtml
In a brazen attempt to sway the vote, my personal feeling it that the targets should be:
- minimalist: gtk + libcurl + libxml
- regular: gnome1.4 + libcurl
Technically, you could cast the division of libraries any which way. But I think the political camps lie along these lines -- minimalist and "will-install-another-library-for-cool-f
2001-07-29 05:47 pm (UTC)
Re: change for your nickel
I agree. libxml is big outside GNOME already in many cases, and it's small (650k or so).
Although previewing with GtkHTML might be neat, it doesn't provide enough CSS support to render any decent split between style and content, and you'd need to download the user's style to do it right, anyway. I say put it in (little to no bloat, anyway; I'll never understand why using more libraries is bloat), but don't expect it to be very useful.
2001-07-30 01:59 am (UTC)
There's two main issues I'd like to touch on here: firstly, my response to the first question, and secondly, the idea of previewing entries.
I responded "other" to the first question because I'd like to be able to use a logjam docklet, like the little Frank docklet that's been kicking around for ages, but IceWM doesn't support the window hints on those, so I can't really use GNOME docklets yet. If / when IceWM supports them, or I make a switch to a window manager that does, that'll probably be the extent that I'll use GNOME support. I don't really have a need for most of the GNOME desktop stuff. (I'm probably mincing words here, don't jump on me!)
With respect to previewing entries, I'm not really sure. Would it be acceptable to write out to a temporary file of some sort and invoke the default browser on it? I feel more comfortable doing web stuff in a browser, and I think I'd rarely preview an entry if I didn't have my browser running.
Mmm, and I like the idea of a sort of GTK / GNOME split, with one only requiring a few libs and things to work, and the other one using the full power of whatever libs are available.