On Wed, 2008-12-17 at 19:49 -0500, Jacek Furmankiewicz wrote:
> I've subclassed Container
So it's a fairly deliberate design decision that things that are
abstract in the underlying library are abstract in java-gnome (I mean,
duh, right?).
That said, even if they weren't, you'd still be saddled with all the
hassle of setting up the machinery to allocate resources and what not.
So, as it stands right now,
> , but the parent constructor expects a long pointer. How do I generate
> one?
>
You don't.
(Java desperately needs another visibility modifier: "library";
the problem with protected is that while that's fine for our
internal use going from org.freedesktop.bindings to
org.gnome.glib and on to org.gnome.gtk, it's bloody horrible
that a developer can in turn subclass and then see something
that is library internal. I've long toyed with ways to get
around this, but nothing non-absurd and non-creating a
subordinate object has come to mind)
Anyway, the solution (or workaround, depending on your taste) is so
obvious that you'll kick yourself: just subclass Button, or HBox, or
Image or Label, or...
I grant you it's not the "perfect" solution, but in practice anything
I've found myself creating is actually a Button or "a bunch of stuff
laid out horizontally" or an Image or a Label, or ... so that's what
I've subclassed. Works out pretty well.
[An example of where I used HBox is here.
http://research.operationaldynamics.com/projects/objective/files/ForeignAmountEntryBox.png
Just a bunch of Entries that reacts to changes in each other,
recalculating as necessary. Packing all the Entries, Labels and the
Combo (which was itself a custom subclass wired up for the domain
specific purpose) into an HBox made the whole thing quite neat - and the
end result is (still) a Widget that was subsequently instantiated as
needed and added to other Containers doing such foreign currency work]
Very long term, the way to address this is a package visible factory
method somewhere that takes care of the allocation and setup issues
underneath creating such a generic Container parent. But I haven't
needed to do so in something like 50,000 lines of code using java-gnome,
so I respectfully submit that it isn't urgent. That said, if there is
some reason you really really need to do it directly, then I'm sure we
can figure something out. There is indeed an elegance violation in
subclassing HBox instead of Container, but on the other hand, the fact
that GtkTreeView subclasses GtkContainer and then doesn't actually work
as a GtkContainer is a bit rude, and GtkLabel extends GtkMisc, which is
quite possibly the stupidest name for an intermediate class I've ever
seen, especially given GtkMisc's actual role and the container /
non-container split in the GtkWidget hierarchy. Alas.
AfC
Sydney
|
