java-gnome-hackers

[Andrew C. <an...@op...>]

While peeking into a problem [note 1] that Kenneth Prugh encountered
with the TrayIcon shown by Slashtime, I got onto an interesting
discussion about the possibilities and challenges of designing an Applet
API for java-gnome with Tim Retout.

With his permission, and with only minor cleanups, I have paraphrased
that IRC conversation below, converting it to email form.


        (if you haven't a clue what I'm talking about,
        http://research.operationaldynamics.com/projects/slashtime/ It's just a fun little program that I once wrote, first as a command line Perl script, later in GUI form with java-gnome 2.x, and then ported to java-gnome 4.0; just a diversion from more important things. It's not anywhere near big enough to be regarded as a "real" application and it does not exhibit proper layering or enterprise application design; I therefore do *not* hold it up as the ultimate java-gnome example or anything like that. It is, however, done all the way to `make install` and has a solid UI, and mostly correct HIGginess, and is now packaged on Gentoo. Yeay for small programs that do their job well)


Slashtime was originally intended  to be an applet (a clock applet
replacement that would do things the way I wanted), but that's just Too
Hard™ right now. Partly because GNOME's applet APIs are insane, and
partly because they are so impossible to debug [or more to the point,
hack on and develop])

> Hehe, I take it bonobo doesn't have bindings.

That's part of the problem. Bonobo being deprecated is a bigger part of
the problem. Bonobo being a CORBA disaster puts the bigger problem into
some clarity. GNOME now using DBus for IPC now doesn't really change
anything. Especially since the panel is still Bonobo based. And since
the only person working on it is long lost off in deeply recursed land.

> Is the new panel applet api still happening sometime soon? It always
> seems to be somewhere in the future.

Yeah (and what I saw from Ryan in Berlin in March did not lend me any
encouragement [note 2])

> :/

Frankly, I haven't given up all hope to do something with the existing
panel applet implementation. I actually wonder if we couldn't come up
with a pretty bloody good wrapper. I also wonder that since all the
xml .server files etc etc etc used to drive applets are ultimately
information used to configure the CORBA interfaces,

a) couldn't we just use CORBA instead of Bonobo [noting that there is a
CORBA engine in core Java] and separately, and/or

b) couldn't we just dynamically generate (based on the result of
initializing an object in Java and setting various properties on it) all
the .server and factory information and dynamically register the applet
at runtime?

[as opposed to having to put it on disk and worse install it to /usr to
be able to see it work] Again, somewhat orthogonally, there is the
question of establishing a factory from which instances will run. Java
actually could be pretty good for that; bloated it may be off the marks,
but it's every good at efficient use of resources amortized over long
running.

I suspect that a middle road in the above would be to write a generic
Java applet server that we could then hook clients to. But that might be
just as much work as figuring it out dynamically.


> If it could be done, it would be great, but it sounds quite
> ambitious. :)

Yes. In fact, it would be *exceedingly* cool.

And yes, it would be ambitious. More to the point, it will take someone
who is well versed in CORBA [or at least the Java APIs for same] and
someone who know a fair bit about the GNOME Applet APIs +
infrastructure.

(or s/CORBA/do a Bonobo binding/).

> Yes.

I've studied the Applet part a fair bit, but I don't know if I know
enough.

Like I said, the only approach that makes any sense to me as an end
result is something that can dynamically register server and menu
information. (obviously a hard wired intermediate would be a step along
the way, but I don't really want to try and expose that as an API) It's
something I think about from time to time.

But I'm not likely to be able to get to it any time soon. Would love to
collaborate with someone on it. I almost got Srichand interested in
doing it last year :)


> The .server files are used to start a factory, so registering at
> runtime would present a bootstrapping problem, no? As in, it wouldn't
> show up in the "Add to panel" list until you ran it.

Yes. I am postulating that since they too are ORB data (or at least,
they look bloody suspiciously like it) and if so, that said data would
therefore be marshalled over the wire, and so potentially "Add to Panel"
could be conn'd into thinking that there is an applet it could add.

But yes it's a bootstrapping problem.

> Heh, I wonder if that would need changes to the existing code. :)
> Probably.

Actually, it's this: When the panel starts up, where does it get factory
[binary] names from? But the reason I am so excited about the
possibilities that arise from being dynamic about it is that the much
harder problem is "how the fuck do you develop one of these things?"

> Yeah, you have to mess about with installing the .server file, running
> and killing, then start from console...

Frankly, the fact that I have to populate a .server file (etc)
into /usr/whatever before I can even test my Hello World applet...

...yes, ok you've read the same stuff I have. It seems insane. I mean, I
understand why it is that way at present, but I cannot imagine inviting
someone who wants to do "something quick" to be all impressed with GNOME
and java-gnome as a result to follow such instructions.

"Hijack an applet that you're not using, say modem lights, and point it
at your test case."

I cannot conceive of writing that down in our JavaDoc for a prospective
java-gnome developer to read.

So.

>  that sounds nasty

The other hypothetical possibility is to write your applet program, run
it, [have it magically register factory, etc], so you can then add to
panel and play with it...

The fact that "making it permanent" would take a different strategy is
evident. Obviously the old heads in GNOME would sternly say "that's not
how it's done"

> :)

but it sure would be a better development experience. Actually, since
Applet development at present is so arcane, I would go so far as to say
at present it is de facto impossible. And that's bad for GNOME. So, I'd
love to see if we can fix that.

Because, "Subclass org.gnome.panel.Applet, set the following minimum
list of properties (name, blah blah blah) and then run your program."
+ either a) "then Add to Panel" or b) some debug only harness for applet
development which causes your applet to instantly appear somewhere on a
panel, assuming you've already Add to Panel the debug harness [that's
the intermediate step I was talking about]

... is a shitload more palatable that the present applet development
paradigm.


> It would be simple to have a method to generate a .server file in
> that class, as well. For the permanent approach later, I mean.

Yes, that's a possibility. As you point out, the chicken and egg factor
is a bit ugly, but let me put it this way.

Take my little slashtime almost-applet. I developed that over a long
period of time. [Happened to rewrite java-gnome along the way, kinda put
it on pause :)]

> Heh.

but irrespective of that, I developed the application first. Later I
created the StatusIcon to go in the notification area (which is mostly a
workaround for the fact that it's not a real applet. Bad™) but only a
few months ago (weeks even) did I create the .desktop file so it would
appear in GNOME menus when installed and supporting project metadata
files (README and friends). Not to mention a `make install` step, etc.

In other words, proof of concept comes first. Then serious development.
Only at the end does installation infrastructure and supporting system
metadata get created.

Applets fuck that up. Get it completely backwards

Actually, the case of the tray icon is an interesting one. They work
because an applet has ALREADY been added to panel - the "Notification
Area" applet. Once that is there, then starting my program causes icon
to appear. Terminating it, icon disappears.

> Mmm.

Quite sensible. One doesn't really think about it. If you are creating a
program that lives in one or more Windows, well, run program, Window
appears. Terminate program, poof. That's _development_. So while there
is a non trivial transform to get from development to system-installed
(usually via being packaged, but `/usr/local` is a variation and really
makes a mess of the option space as anyone who has written a `make
install` target knows), ease of development has to come first.

Really, this is all just a case study in the cornerstone principle I
rewrote java-gnome on: Approachability.

Anyway, your point about writing out a .server file is well made. It's a
quite sensible possibility. I note, however, that the user needing write
access to /usr/lib/bonobo/servers/ in order to create and test a Hello
World applet is patently ridiculous. So it needs something else. If
a .server is needed for the long term system-install & packaging, then
writing one out would be useful.


> Staring at gnome-panel code hasn't immediately made it obvious
> whether a generic corba interface is possible.

I'm not sure. It's all very hard wired. (So, perhaps a hard wired Bonobo
binding, ok, {shrug}. It's the generic Bonobo binding I don't want to
write). But Bonobo takes that data and does something over the wire. I'm
betting we can do so too.


> Anyway, I'd better go to bed. This is all very interesting...

> For applets, you just need a very limited interface. Not even the C
> applets use more than one macro wrapping it all.

That's what is so frustrating. The end result developer experience could
be extraordinarily good. Applets should be easy!

Good night.

AfC
Sydney

Footnotes
---------

*1 Ken's bug was due to him not running GNOME. He doesn't even run a
Desktop Environment. Arghhhh! ENOTOURTARGETAUDIENCE! (People who hang
out in #java-gnome who are not passionate about wanting to develop GNOME
applications are completely mind-boggling to me. Jeffery and I talked
about this a few years ago; he encountered the same thing when he was
running the project. THAT SAID, what I remarked to Ken at the time was
"I'm glad you are finding a way to use our software in an setting other
than what we designed it for. I can't say as how that is 'supported' but
[being able to] do things with software [unanticipated by the original
authors] is what Open Source is all about).

*2 Don't get me wrong. Ryan is hard at work on infrastructure a number
of layers down that could well be the foundation for an exciting new
technology to help facilitate GNOME applications' settings and data
interchange. And it all started because he was trying to do a next
generation Panel Applet API, and encountered  limitations he needed to
fix in the underlying infrastructure. That led to deeper problems he
wanted to address. And so on. **Deeply recursed**. I appreciate his hard
work.

java-gnome is a deep recursion for me; I am about 5 levels below where I
should be focusing my energies. Needless to say, when Naba asked me to
work on adding Java support in Anjuta [GNOME's IDE], I freaked. I'd
_love_ to help, and having Java in Anjuta would make java-gnome even
more well rounded for people, but I'm not sure working on an IDE at this
point is a going to help me pop back out of the stack at all :)

I know of a guy who started his computing career by filing a bug
(against Debian, I believe). Then he got more involved, both as a sys
admin and as a Debian packager. Then he started filing bugs in an
upstream project and programming... some time later he was writing Linux
kernel device drivers ... fast forward, last I heard of him, he was
doing VLSI chip design.

When you recurse lower into the stack, it can be hard to get back again.
Nothing wrong with that if doing something that has caught your interest
and imagination...  unless there was something higher level you needed
to get done :)

I wonder if the bug he filed ever got fixed.


-- 
Andrew Frederick Cowie

Operational Dynamics is an operations and engineering consultancy
focusing on IT strategy, organizational architecture, systems
review, and effective procedures for change management. We actively
carry out research and development in these areas on behalf of our
clients, and enable successful use of open source in their mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London