java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 29)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

On Sat, 2007-12-08 at 16:29 +0530, Manu Mahajan wrote:
> This is a patch to run the configure script on open suse.
>=20
> Please review and advise.

Merged to 'mainline'.

AfC
Bangalore

--- Mark Howard <mh...@ti...> escreveu:

> Why not just change them all to present tense and
> have a consistent
> javadoc style to say that this will fire a signal
> which can optionally
> be intercepted by xyz listener.
> 
> button.click()
> treeview.activateRow()
> 
> onClick()
> onRowActivation()

I like clicked() and activateRow() instead of
doClicked(), but I prefer the current onClicked() or
onRowActivated() for callbacks.

Cheers,
Vreixo

> 
> Mark
> 
>
-------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux
> Business White Paper
> from Novell.  From the desktop to the data center,
> Linux is going
> mainstream.  Let it simplify your IT future.
>
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
>
https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/

Why not just change them all to present tense and have a consistent
javadoc style to say that this will fire a signal which can optionally
be intercepted by xyz listener.

button.click()
treeview.activateRow()

onClick()
onRowActivation()

Mark

On 27/11/2007, Andrew Cowie <an...@op...> wrote:
> ... I am tempted to present all such methods with their own prefix to
> make their relationship to the signal clear.
>
> Inspired by the "on" Owen Taylor suggested that led to the onClicked()
> in design of the Button.CLICKED interface for 'clicked' signals, I'm
> thinking:
>
>         doClicked()
>         doRowActivated()
>
> etc across the board for all signals that can be publicly fired by the
> programmer on a given class (which is to say, most of them).

If you're going to change the names away from the Gtk conventions I
personally would like to see the new names follow Java norms.  In Java
libraries, the "fire" prefix is usually used to send event callbacks
to listeners.  E.g. "fireClicked()" and "fireRowActivated()" would
send "clicked()" and "rowActivated()" callbacks respectively.

However, "fire" methods are usually protected, to ensure that events
are not announced except when the object actually makes the state
change that is being announced.  Public methods that result in events
being fired are conventionally in the imperative mood but relate to
the object's responsibilities, not to its event-firing mechanism.

E.g. A button would have a "click()" method would result in the button
calling its protected "fireClicked()" method which would send out the
"clicked()" callback, and "activateRow(n)" would call the protected
"fireRowActivated()" method which would send out the "rowActivated()"
callbacks.

Would something like that be possible?

--Nat

There are, of course, lots of methods across GTK that cause a signal to
be emitted. Examples are gtk_button_clicked() and
gtk_tree_view_row_activated()

Translated to Java, these are clicked() and rowActivated()

The thing that bothers me is that it's not terribly obvious what such
methods are for. In English, those words are not present tense verbs, so
the fact that they cause that signal to be fired doesn't make a whole
lot of sense. I mean, hey: "rowActivated()"? That sounds like a
question.

So I am tempted to present all such methods with their own prefix to
make their relationship to the signal clear.

Inspired by the "on" Owen Taylor suggested that led to the onClicked()
in design of the Button.CLICKED interface for 'clicked' signals, I'm
thinking:

        doClicked()
        doRowActivated()

etc across the board for all signals that can be publicly fired by the
programmer on a given class (which is to say, most of them).

Comments?

AfC
Sydney

On Tue, 2007-11-27 at 17:31 +0100, Timm Preetz wrote:
> this time with the patch attached...

Merged to 'website' branch, and published to sourceforge.

I trust you'll update this in the future as the package's status in Arch
changes.

AfC
Sydney

this time with the patch attached...

On Tue, 2007-11-27 at 12:25 +1100, Andrew Cowie wrote:

> So what would be really ideal is if you would fix up
> http://java-gnome.sourceforge.net/4.0/get/arch.php
> it's in the sources at web/public/4.0/get/arch.php. See the Gentoo page
> for an example of what I did for developer on that distro:
> http://java-gnome.sourceforge.net/4.0/get/gentoo.php

As there are no binary packages in the official Arch Linux repositories
yet, the installation procedure is a little bit more than just one
command, but doable for all Arch user I think.

> > I have just one question left: How can I build the docs?
> 
> $ make doc
> 
> > I would be glad to hear from you so that I could build a java-gnome-docs
> > package for use in Devhelp.
> 
> That's something I'd like to see as well. I've got a bad feeling it's
> going to involve writing a custom JavaDoc doclet to output the index
> data.

So true. Docs building and "working" fine, but all the frame stuff that
is needed to make up for not having chapters in Devhelp for these docs
isn't really useful.

As I couldn't find anything on the web it's probably a DIY task to get
the table of contents created so that one could at least switch to ne
'no frames'-layout.

Regards,
Timm

On Mon, 2007-11-26 at 16:41 +0100, Timm Preetz wrote:

> first, congratulations for the new java-gnome release :)

Thanks for contributing to it.

> It's already packed for Arch Linux ;)

So what would be really ideal is if you would fix up
http://java-gnome.sourceforge.net/4.0/get/arch.php
it's in the sources at web/public/4.0/get/arch.php. See the Gentoo page
for an example of what I did for developer on that distro:
http://java-gnome.sourceforge.net/4.0/get/gentoo.php

> I have just one question left: How can I build the docs?

$ make doc

> I would be glad to hear from you so that I could build a java-gnome-docs
> package for use in Devhelp.

That's something I'd like to see as well. I've got a bad feeling it's
going to involve writing a custom JavaDoc doclet to output the index
data.

I must admit I'm sorta half tempted to write a custom JavaDoc doclet for
the HTML documentation too - admittedly people are used to the default
look and feel, but it's a wee bit cumbersome (compared to, say, pygtk's
docs).

Srichand, rather wisely, pointed out to me that I had better things to
be doing with my time :)

AfC
Sydney

On Fri, 2007-11-23 at 16:34 +0100, Timm Preetz wrote:
> here is the bundle :)

Merged.

> Today it was much easier than yesterday and everything works fine now!

Glad to hear that.

> Looking forward to some Java-GNOME hacking,

Yeay

AfC
Sydney

On Tue, 2007-11-20 at 05:31 -0300, Vreixo Formoso Lopes wrote:
> The patch we we're talking about last weekend.

Merged.

AfC
Sydney

On Wed, 2007-11-21 at 17:30 +0100, Timm Preetz wrote:
> today I created a 'java-gnome' package[1] for Arch Linux[2].

Awesome.

> Therefore I had to make some changes to the configure script which I now
> want to share with you.

Awesome!

Please grab a branch of the sources from Bazaar as described in the
HACKING document, commit your changes adding Arch Linux as a supported
distro, and then run the bundle command to=20

That way someone wishing to hack on java-gnome itself can get it to
build themselves with minimal effort.

> I hope the changes are ok, and easy to understand.

I read diffs...

> There is just one thing I couldn't solve. The last part of my changes,
> where it wants to find the jdk. How could I default that for arch
> to /opt/java?

Good question. Ping me on IRC or give me a call, and we'll talk about
it.

AfC
Sydney

--=20
Andrew Frederick Cowie
Managing Director
Operational Dynamics Consulting, Pty Ltd

Sydney    +61 2 9977 6866
New York  +1 646 472 5054
Toronto   +1 647 477 5603
London    +44 207 1019201

We are an operations engineering consultancy focusing on strategy,
organizational architecture, systems review, and change management
procedures: enabling successful use of open source in mission
critical enterprises, worldwide.

http://www.operationaldynamics.com/

Hello,

today I created a 'java-gnome' package[1] for Arch Linux[2].

Therefore I had to make some changes to the configure script which I now
want to share with you.

I hope the changes are ok, and easy to understand.

Mostly I just copied (from debian) and made minor changes for arch.

There is just one thing I couldn't solve. The last part of my changes,
where it wants to find the jdk. How could I default that for arch
to /opt/java?

That would save the output I added afterwards for Arch Users to use the
'jdk=/opt/java' option.

Regards,
Timm

[1] http://aur.archlinux.org/packages.php?do_Details=1&ID=13896
[2] http://www.archlinux.org/

Hey,

Sorry to all those lurkers that there hasn't been much traffic on list;
most of the activity has been on IRC or one-to-one on the phone. A quick
update relative to
http://java-gnome.sourceforge.net/4.0/NEWS.html#treeview=20

The 'treeview' branch is merged to 'mainline', at last. From the commit
logs:
 =20
  Add coverage of the TreeView API to java-gnome
 =20
  Merge major development branch 'treeview' to 'mainline'. This is the
  culmination of three months of work, primarily by Andrew Cowie with
  significant contribution from Srichand Pendyala.
 =20
  Major coverage additions are the model side (TreeModel, ListStore,
  DataColumn*) and to the view side (TreeView, TreeViewColumn,
  CellRenderer*) along with associated glue code (TreeIter, TreePath,
  TreeSelection). Code validation provided through vairous unit tests
  and a new example in doc/examples/treeivew/.
 =20
  Implementation unfortunately required a fairly significant amount of
  manual C code, but we are pleased with the usability of the overall
  result and feel it was worth the effort.
 =20
  Thanks to Peter Miller, Hanna Wallach and Srichand Pendyala for having
  reviewed the TreeModel design, and to Bryan Clark and Owen Taylor for
  having considered the inversion in the TreeViewColumn - CellRenderer
  relationship.

The bulk of the implementation on the 'treeview' branch was completed in
October, thanks in no small part to the GNOME Foundation having
sponsored a hackfest in Boston. There was a lot of new coverage, however
and it took a while to finish bringing its documentation up to standard.

Also in are the 'delete' branch, which was a bugfix for a problem raised
by Vreixo,

  Fix memory management of Window instances
 =20
  There is a peculiar corner case, identified by Vreixo Formoso, where
  if a Window instance is deleted its contents are released but it is
  not, since we still can hold a Java reference to it; this in turn
  prevents the Window from ever being finalized.
 =20
  Fix by using an obscure feature of GtkWindow, telling GTK that we (the
  language binding) control the Ref count that GTK holds to the Window
  when it is displayed on the screen, and then managing that Ref by
  manipulating the 'delete-event', 'hide' and 'show' signals. Thanks to
  Owen Taylor for having evaluated the problem and for describing the
  GtkWindow has_user_ref_count field.

and the 'screenshots' one,

  Automatically generate screenshots for documentation
 =20
  Merge 'screenshot' branch. This code introduces the ability to take a
  screenshot of the presented window, thereby allowing us to create a
  program to automatically make the images we need to fill in the
  illustrations in our API documentation. This uses GPL code from
  gnome-utils's gnome-screenshot program.
 =20
  Fill out some of the capabilities on Pixbuf, notably adding save().
 =20
  Also introduce a number of "Snapshots", the term we will use for
  programlets which draw a Window to be captured as a screenshot. The
  API here isn't ideal, but it's a start. Program Harness uses these
  classes to render, capture, and save the snapshots.

which is a bit of fun I had last week when I realized a) we needed
screenshots of Windows and things for our API documentation, and b)
taking them manually was a pain in the ass.

++

With this all in hand, we can start polishing things up for a release of
4.0.5, hopefully within the next week or so.

There a number of build annoyances that came up when Carl was building
last week; I'd like to address things like that before we do the
release. We also have to tweak the equivalence script to ensure GTK 2.12
is installed on the building machine. Other than that, we're almost at
release quality now, and there's always 4.0.6 for the stuff that doesn't
get addressed before the end of the week :)

AfC
Sydney

P.S. The `bzr viz` that comes from the bzr-gtk 0.92.1 plugin that works
with Bazaar 0.92 is _really_ awesome. You should have a look if you
haven't already.

Il giorno sab, 10/11/2007 alle 19.12 +1100, Andrew Cowie ha scritto:

> Mario and I chatted this morning before he went to bed. These methods
> actually gave me cause to do some tests (we were both curious about
> something) and I was able to update the class documentation quite a bit
> as a result. Yeay, removing TODOs.

Great! I'll also do my homework today, hacking is always fun :)

> merged.
>=20
> Thanks Mario. Welcome aboard.

Thank you!!

Mario
--=20
Lima Software - http://www.limasoftware.net/
GNU Classpath Developer - http://www.classpath.org/
Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre
Jabber: ne...@ja...
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/

On Fri, 2007-11-09 at 21:12 +0100, Mario Torre wrote:
> This is my first attempt to contribute to java-gnome, so I expect to do
> some more work on this patch.

Nope. It was fine.

> I wanted to discuss this with Andrew

Mario and I chatted this morning before he went to bed. These methods
actually gave me cause to do some tests (we were both curious about
something) and I was able to update the class documentation quite a bit
as a result. Yeay, removing TODOs.

> I've tested it with an application, still no idea how to automate (I'll
> look into the test directory for examples).

I added a tiny test to ValidateProperties.

> A final note, the @since tag is 4.0.5, I'm not sure if that's correct.

Yes, that's correct. Assuming it gets merged, it'll go out in the
forthcoming release, and 4.0.5 will be next. If it doesn't make it to
'mainline' in time, well, {shrug} we bump it to 4.0.6 later.

and...

merged.

Thanks Mario. Welcome aboard.

++

Did you know it takes, on average, 1 hour per method [pair] to evaluate
patches, study references, run tests, update documentation with
resultant experiences, and then merge to 'mainline' & publish?

And that's when it's _good_ code.

AfC
Sydney

Hello!

This is my first attempt to contribute to java-gnome, so I expect to do
some more work on this patch.

I wanted to discuss this with Andrew before submitting to the list, but
I was not lucky today.

Anyway, here it is, most of the code was already there, I guess it was
just waiting for someone to write the javadocs and the public API.

I've tested it with an application, still no idea how to automate (I'll
look into the test directory for examples).

A final note, the @since tag is 4.0.5, I'm not sure if that's correct.

I'm waiting for comments!

Thanks
Mario

Changelog:

2007-11-09  Mario Torre  <ne...@li...>

	* src/bindings/org/gnome/gtk/Button.java:
	(getImage): new method.
	(setImage): likewise.

-- 
Lima Software - http://www.limasoftware.net/
GNU Classpath Developer - http://www.classpath.org/
Fedora Ambassador - http://fedoraproject.org/wiki/MarioTorre
Jabber: ne...@ja...
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Please, support open standards:
http://opendocumentfellowship.org/petition/
http://www.nosoftwarepatents.com/

Hi all,

Andrew Cowie schrieb:
> That's not valid scheme syntax, is it? I don't believe so. If we
> accepted this patch it would mean that the other language bindings
> wouldn't be able to use the .defs data anymore.
>
>   
Oops,
I didn't know that all language bindings uses the same .defs files.
Sorry about that.
> You can do this kind of validation in the bindings layer. That's what
> it's there for. See Alignment.check() which is a private static method
> (therefore callable during construction) which has the logic to validate
> the input.
>
>   
Ok, I will use a check method.

Regards,
Thomas.

On Mon, 2007-10-29 at 08:15 -0300, Vreixo Formoso Lopes wrote:
> send you the patch with current state of my Dialog
> branch, this one with FileChooserDialog
> implementation.

This is terrific work from Vreixo and Thomas. I have one or two minor
quibbles I'll write about later, and will have to do the editing pass
over the JavaDoc before I merge to 'mainline', but I will be accepting
it this patch.

AfC
Sydney

On 11/1/07, Andrew Cowie <an...@op...> wrote:
>
> Hey Thomas. Thanks for your contribution.
>
>
> > Enclosed is a patch for the GtkTable.defs that you can see
> > that the generator works.
>
> Actually, for such a radical change it would also be appropriate to add
> test case(s) to validate the correct parsing behaviour.

For radical changes, I'd love to see _lots_ of Javadoc explaining any
deviation from default behavior with an example too.

AfC
> Canberra
>

Srichand
Minneapolis

-- 
Srichand Pendyala
http://srichand.net.in/

Hey Thomas. Thanks for your contribution.

On Wed, 2007-10-31 at 16:25 +0100, Thomas Schmitz wrote:=20
> I wanted to implement the Table class as I saw that there is no way to
> handle that the constructor of the Table allows only restricted values
> as rows and columns. Means the value of 'rows' is restricted to be
> greater then 0 and smaller then 65536. So I have implemented the
> possibility to add a parameter in the .defs files. This parameter looks
> like '( > 0 & < 65536)'.

Eeek.

That's not valid scheme syntax, is it? I don't believe so. If we
accepted this patch it would mean that the other language bindings
wouldn't be able to use the .defs data anymore.

> But this is only an example for the
> GtkTable.defs, of course.

You can do this kind of validation in the bindings layer. That's what
it's there for. See Alignment.check() which is a private static method
(therefore callable during construction) which has the logic to validate
the input.

This shows up in quite a number of other places too, especially on the
'treeview' branch.

> Enclosed is a patch for the GtkTable.defs that you can see
> that the generator works.

Actually, for such a radical change it would also be appropriate to add
test case(s) to validate the correct parsing behaviour.

AfC
Canberra

---------- Forwarded message ----------
From: Marcus Dapp Survey-Admin (sg) <swp...@ge...>
Date: Oct 27, 2007 5:20 AM
Subject: Software patents and the java-gnome project - A scientific survey =
(sg)
To: ku...@us...

Dear kuzman,

There is considerable debating in the Free/Libre/Open Source Software
communities about software patents; but what do we really know? What
are your own experiences with software patents in the java-gnome
project? We are cordially inviting you to participate in our global
scientific survey on software patents and FLOSS projects.

This is a joint research project of the Center for Comparative and
International Studies (CIS), the Chair for Strategic Management and
Innovation (SMI), and the Chair for Law&Economics; all at the Federal
Institute of Technology (ETH) in Zurich, Switzerland:
http://www.ethz.ch.

Participation is by invitation only. We are inviting only a random
sample of project leaders/key developers of active SF projects (August
2006). So, your participation does matter and will improve the overall
data quality.

As an additional benefit, we include everybody in a lottery who
completes the questionnaire. The prizes are nice, we think:

1st -- A green 'XO' (OLPC) laptop, sponsored by Google's Open Source
Program Office[1]
2nd -- A free 'Neo1973' mobile phone, sponsored by OpenMoko/FIC[2]
3rd -- Be surprised. We aim for similar 'coolness' as the other prizes ;-)

Your privacy is protected. Results will be aggregated and anonymous.
Identifying information (login/projectname/email address) are only
used for this email conversation. More on privacy is on the first
survey page.

=3D> http://www.swpat-floss.ethz.ch/lv/index.php?sid=3D6&token=3D1363570848

Thanks for helping us by submitting your response within the next
days. There are only multiple choice questions, so answering will be
straightforward. If you face technical problems, please email Marcus
at swp...@ge... with the subject line: 'bug-report-sg'.

We hope you find coming up with answers as exciting as we found coming
up with questions. Thank you very much for your interest and time!

Professor Thomas Bernauer, http://www.cis.ethz.ch
Professor Georg von Krogh, http://www.smi.ethz.ch
Professor G=E9rard Hertig, http://www.hertig.ethz.ch
Marcus M. Dapp, PhD candidate

Marcus M. Dapp | WEC C 19 | ETH-Zentrum | CH-8092 Zurich | Switzerland

[1] http://www.laptop.org
[2] http://www.openmoko.org

(sg)

On Tue, 2007-10-23 at 11:11 +0200, Thomas Schmitz wrote:
> I didn't really think much about the activate method...

We have been trying pretty hard to be careful about what we expose and
how. This is mostly a filter on things that are pure C (only) APIs, and
a quick sanity check as to whether the behaviour or signature needs to
be adjusted to be suitable in the context of the rest of java-gnome.

Mostly, though, if you need something because you've used it in the past
- or better yet are using it presently - and can comment on what you use
something for and how it is best employed, then we're all set.

> I'm not as far as that I want to (can) decide such things.

That's ok. Your contribution is much appreciated.

Merged.

AfC
Sydney

=20

Hi!

Send you a patch with the implementation of the
alternative to destroy Windows that I have told you
yesterday.

I've tried to do most of the implementation on java
side, and that bring some collateral effects (such as
the presence of protected methods that must be
completelly hidden to developers) that must be fixed
in a future. Please think of this patch as a revision
for testing and validating the idea, not for merging
into mainline.

The patch includes a little test app, if you play a
bit with it you will see the idea seems to work very
well. Of course, the testing app is really simple, and
we will need to test harder situations.

In any case, I've presented a solution that works.
Even needing much more testing, now it is time that
people that didn't like my idea try to implement a
situation that make it break.

Cheers,
Vreixo

      Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento!
http://br.mail.yahoo.com/
On Tue, 2007-10-23 at 04:23 -0300, Vreixo Formoso Lopes wrote:
> The idea is:
>=20
> the Window to be hidden, but not destroyed on 'delete-event'

So I basically told Vreixo on IRC that I thought this was a non-starter.
We are not about to redefine the meaning of the 'delete-event' signal.=20

He does have a legit memory management concern relating to reference
counts for Windows that aren't hooked up to quit the main loop. We're
looking into that further.

AfC
Sydney

2002	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (102)	Sep (43)	Oct (32)	Nov (43)	Dec (51)
2003	Jan (6)	Feb (19)	Mar (39)	Apr (22)	May	Jun (11)	Jul (2)	Aug (4)	Sep	Oct (3)	Nov (9)	Dec (73)
2004	Jan (88)	Feb (141)	Mar (116)	Apr (69)	May (199)	Jun (53)	Jul (90)	Aug (23)	Sep (11)	Oct (212)	Nov (57)	Dec (61)
2005	Jan (88)	Feb (17)	Mar (21)	Apr (50)	May (44)	Jun (33)	Jul (21)	Aug (37)	Sep (39)	Oct (43)	Nov (40)	Dec (15)
2006	Jan (21)	Feb (69)	Mar (23)	Apr (6)	May (29)	Jun (19)	Jul (17)	Aug (15)	Sep (13)	Oct (16)	Nov (9)	Dec (7)
2007	Jan (30)	Feb (39)	Mar (1)	Apr (12)	May (53)	Jun (30)	Jul (39)	Aug (75)	Sep (16)	Oct (13)	Nov (20)	Dec (5)
2008	Jan (8)	Feb (14)	Mar (33)	Apr (7)	May (22)	Jun (23)	Jul (17)	Aug (9)	Sep (9)	Oct (25)	Nov (9)	Dec (1)
2009	Jan (20)	Feb (38)	Mar (9)	Apr (15)	May (30)	Jun (35)	Jul (22)	Aug (10)	Sep (7)	Oct (23)	Nov (6)	Dec (8)
2010	Jan (5)	Feb (10)	Mar (17)	Apr (10)	May (16)	Jun (8)	Jul (3)	Aug (15)	Sep (14)	Oct (26)	Nov (11)	Dec (14)
2011	Jan (10)	Feb (8)	Mar (6)	Apr (7)	May (18)	Jun (17)	Jul (6)	Aug (1)	Sep (2)	Oct (6)	Nov (2)	Dec (10)
2012	Jan (6)	Feb (9)	Mar	Apr (3)	May (1)	Jun	Jul (5)	Aug (14)	Sep	Oct (1)	Nov	Dec
2013	Jan	Feb (8)	Mar (6)	Apr	May (1)	Jun	Jul	Aug (2)	Sep	Oct	Nov	Dec (2)
2014	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2017	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

java-gnome-hackers Mailing List for The java-gnome language bindings project (Page 29)

java-gnome-hackers — Hacking on the bindings themselves: design issues and co-ordination