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

RE: [java-gnome-hackers] gtk Widgets

[Jeffrey M. <Jeffrey.Morgan@BristolWest.com>]

> I would like to start looking at the tree and list widgets.
> IMHO, this would be best done by having the main classes implement the
> widgets similar to how is done in Gtk, including most of the 
> complexity;
> then work on simplifying the classes in derived classes (e.g. having a
> class for a simple list widget (single column, no editable cells, no
> DnD) with methods such as add(int index, String item) )

This sounds like a good approach.  It's all yours.

-Jeff

[java-gnome-hackers] gtk Widgets

[Mark H. <mh...@ti...>]

hi,
I've mostly done the widgets I said earlier and also looked at a few
example apps. These seem to work quite well.

AFAIK, the following gtk widgets are the main ones which require work:
Dialog,=20
WindowGroup,
AccelLabel,=20
Image
MultiLine Text editor widgets
Tree and List Widgets
Menus & ToolBars
Selection Dialogs

I would like to start looking at the tree and list widgets.
IMHO, this would be best done by having the main classes implement the
widgets similar to how is done in Gtk, including most of the complexity;
then work on simplifying the classes in derived classes (e.g. having a
class for a simple list widget (single column, no editable cells, no
DnD) with methods such as add(int index, String item) )
--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

Re: [java-gnome-hackers] Internationalization code in gnome jni code

[Philip A. C. <pc...@td...>]

I'm having to work late tonight.  (I'm emailing from work now)=20
Unfortunately, I will not be able to work on it tonight.  However, when
I do, I will be sure to regen the .c files.

Thanks,

On Tue, 2002-08-20 at 14:36, Jeffrey Morgan wrote:
> When you begin again tonight please get the latest JNIProps.txt
> from cvs and rerun the generator.  I made a slight change that
> will keep certain c compilers from producing errors.  I have
> already made the appropriate changes to the jni code you checked
> in last night.
>=20
> -Jeff
>=20
> On Tue, 2002-08-20 at 05:25, Jeffrey Morgan wrote:
> > Great! Let me know if you need help.
> >=20
> > -Jeff
> >=20
> > On Mon, 2002-08-19 at 23:05, Philip A. Chapman wrote:
> > > Everyone,
> > >=20
> > > I've added the code changes for org_gnu_gnome.App.c through
> > > org_gnu_gnome_ColorPicker.c.  I've still to complete changes on the
> > > remainder of the gnome jni code files.  Also, during the last compile=
, I
> > > noted that there are quite a few warnings being emitted for
> > > org_gnu_gnome_Color_Picker.c.  I intend to tackle each of these issue=
s
> > > in the coming days.
> > > --=20
> > > Philip A. Chapman
> >=20
> >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
> > _______________________________________________
> > java-gnome-hackers mailing list
> > jav...@li...
> > https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> >=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs3390
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
--=20
Philip A. Chapman

Re: [java-gnome-hackers] Internationalization code in gnome jni code

[Jeffrey M. <ku...@zo...>]

When you begin again tonight please get the latest JNIProps.txt
from cvs and rerun the generator.  I made a slight change that
will keep certain c compilers from producing errors.  I have
already made the appropriate changes to the jni code you checked
in last night.

-Jeff

On Tue, 2002-08-20 at 05:25, Jeffrey Morgan wrote:
> Great! Let me know if you need help.
> 
> -Jeff
> 
> On Mon, 2002-08-19 at 23:05, Philip A. Chapman wrote:
> > Everyone,
> > 
> > I've added the code changes for org_gnu_gnome.App.c through
> > org_gnu_gnome_ColorPicker.c.  I've still to complete changes on the
> > remainder of the gnome jni code files.  Also, during the last compile, I
> > noted that there are quite a few warnings being emitted for
> > org_gnu_gnome_Color_Picker.c.  I intend to tackle each of these issues
> > in the coming days.
> > -- 
> > Philip A. Chapman
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> java-gnome-hackers mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-hackers
> 

Re: [java-gnome-hackers] Internationalization code in gnome jni code

[Jeffrey M. <ku...@zo...>]

Great! Let me know if you need help.

-Jeff

On Mon, 2002-08-19 at 23:05, Philip A. Chapman wrote:
> Everyone,
> 
> I've added the code changes for org_gnu_gnome.App.c through
> org_gnu_gnome_ColorPicker.c.  I've still to complete changes on the
> remainder of the gnome jni code files.  Also, during the last compile, I
> noted that there are quite a few warnings being emitted for
> org_gnu_gnome_Color_Picker.c.  I intend to tackle each of these issues
> in the coming days.
> -- 
> Philip A. Chapman

[java-gnome-hackers] Internationalization code in gnome jni code

[Philip A. C. <pc...@td...>]

Everyone,

I've added the code changes for org_gnu_gnome.App.c through
org_gnu_gnome_ColorPicker.c.  I've still to complete changes on the
remainder of the gnome jni code files.  Also, during the last compile, I
noted that there are quite a few warnings being emitted for
org_gnu_gnome_Color_Picker.c.  I intend to tackle each of these issues
in the coming days.
--=20
Philip A. Chapman

RE: [java-gnome-hackers] update

[Jeffrey M. <Jeffrey.Morgan@BristolWest.com>]

> I've been working on setting up event handlers for the classes I've
> worked on so far. 
> I have not done this for the statusbar:
> The signals are text-popped and text-pushed; the only way to 
> emit these
> signals is by making calls to the pop and push methods, so I don't see
> any reason for adding event handlers.
> 
> I have not done Label either, as I'm unsure what the signals do:
> copy-clipboard 	- I guess this means "selected text block"
> move-cursor 	- Labels don't have cursors
> populate-popup	- No idea what this is (specific to the 
> label widget)

It is not necessary to provide all available events.  Just
use your past experience to determine if this is an event
that you would use.  It is easy to go back and add them
later if a user requests it but bloat tends to stay around
a long time 8-)

> I have also worked on ProgressBar. All methods of Progress (and so
> ProgressBarStyle enum) are deprecated in the gtk docs. Should I remove
> these and make ProgressBar extend Widget rather than Progress?

I think we should keep Progress for the time being.  There are
fields that can only be accessed via Progress.  Hopefully the
GTK developers will move these to ProgressBar in the future.
 
> I think I'll take a look at the following gtk classes unless 
> anyone has
> any objections:
> H V Separator
> Entry,
> SpinButton
> Range,
> H V Scale,
> Adjustment,
> H V ScrollBar

Their all yours!

RE: [java-gnome-hackers] String encoding | showAll() | ButtonBox example

[Jeffrey M. <Jeffrey.Morgan@BristolWest.com>]

> I have not modified any of the jni code for the gnome classes beyond
> what is created by the generator.  I don't think the merge will be too
> bad.  I will try to get gnome's jni code updated this evening.

All other packages have been updated.  I do believe I went
through the gnome jni code and cleaned up several compiler
warnings.  You might want to check this prior to just
replacing the code.

-Jeff

[java-gnome-hackers] update

[Mark H. <mh...@ti...>]

hi,
I've been working on setting up event handlers for the classes I've
worked on so far.=20
I have not done this for the statusbar:
The signals are text-popped and text-pushed; the only way to emit these
signals is by making calls to the pop and push methods, so I don't see
any reason for adding event handlers.

I have not done Label either, as I'm unsure what the signals do:
copy-clipboard 	- I guess this means "selected text block"
move-cursor 	- Labels don't have cursors
populate-popup	- No idea what this is (specific to the label widget)

I have also worked on ProgressBar. All methods of Progress (and so
ProgressBarStyle enum) are deprecated in the gtk docs. Should I remove
these and make ProgressBar extend Widget rather than Progress?

I think I'll take a look at the following gtk classes unless anyone has
any objections:
H V Separator
Entry,
SpinButton
Range,
H V Scale,
Adjustment,
H V ScrollBar
--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

RE: [java-gnome-hackers] String encoding | showAll() | ButtonBox example

[Philip A. C. <pc...@td...>]

I have not modified any of the jni code for the gnome classes beyond
what is created by the generator.  I don't think the merge will be too
bad.  I will try to get gnome's jni code updated this evening.

On Mon, 2002-08-19 at 06:30, Jeffrey Morgan wrote:
> >   I've been working on an example app for the ButtonBoxes:
> > /src/examples/gtk/buttonbox/ButtonBoxes.java
> > (I have implemented gtk Frame btw)
> > 
> > The main problem seems to be with string encodings. 
> > The button box example gives the warnings:
> > ** (java-gnome:14365): WARNING **: Invalid UTF8 string passed to
> > pango_layout_set_text()
> > 
> > In my code, I have been using String.getBytes() with no encoding
> > argument. I guess this is wrong. I have tried a few examples and read
> > through the gtk docs, but have been unable to determine what should be
> > passed to the getBytes method. 
> > 
> > This seems to affect all classes which pass Strings to native methods.
> 
> If you get the latest from cvs and run the generator it will
> produce C code that will fix this problem.  We now have the task
> of merging this C code with the code in the src/jni directory.
> I will do this for all of the glib, atk, pango, and gtk classes
> today.  The Java will not change; you still need to pass in an
> array of bytes.
> 
> -Jeff
-- 
Philip A. Chapman
Product Development Manager

ACO Information Services
866-897-STAR (7827)
-- 
Philip A. Chapman

RE: [java-gnome-hackers] String encoding | showAll() | ButtonBox example

[Philip A. C. <pch...@ac...>]

I have not modified any of the jni code for the gnome classes beyond
what is created by the generator.  I don't think the merge will be too
bad.  I will try to get gnome's jni code updated this evening.

On Mon, 2002-08-19 at 06:30, Jeffrey Morgan wrote:
> >   I've been working on an example app for the ButtonBoxes:
> > /src/examples/gtk/buttonbox/ButtonBoxes.java
> > (I have implemented gtk Frame btw)
> >=20
> > The main problem seems to be with string encodings.=20
> > The button box example gives the warnings:
> > ** (java-gnome:14365): WARNING **: Invalid UTF8 string passed to
> > pango_layout_set_text()
> >=20
> > In my code, I have been using String.getBytes() with no encoding
> > argument. I guess this is wrong. I have tried a few examples and read
> > through the gtk docs, but have been unable to determine what should be
> > passed to the getBytes method.=20
> >=20
> > This seems to affect all classes which pass Strings to native methods.
>=20
> If you get the latest from cvs and run the generator it will
> produce C code that will fix this problem.  We now have the task
> of merging this C code with the code in the src/jni directory.
> I will do this for all of the glib, atk, pango, and gtk classes
> today.  The Java will not change; you still need to pass in an
> array of bytes.
>=20
> -Jeff
--=20
Philip A. Chapman
Product Development Manager

ACO Information Services
866-897-STAR (7827)

RE: [java-gnome-hackers] String encoding | showAll() | ButtonBox example

[Jeffrey M. <Jeffrey.Morgan@BristolWest.com>]

>   I've been working on an example app for the ButtonBoxes:
> /src/examples/gtk/buttonbox/ButtonBoxes.java
> (I have implemented gtk Frame btw)
> 
> The main problem seems to be with string encodings. 
> The button box example gives the warnings:
> ** (java-gnome:14365): WARNING **: Invalid UTF8 string passed to
> pango_layout_set_text()
> 
> In my code, I have been using String.getBytes() with no encoding
> argument. I guess this is wrong. I have tried a few examples and read
> through the gtk docs, but have been unable to determine what should be
> passed to the getBytes method. 
> 
> This seems to affect all classes which pass Strings to native methods.

If you get the latest from cvs and run the generator it will
produce C code that will fix this problem.  We now have the task
of merging this C code with the code in the src/jni directory.
I will do this for all of the glib, atk, pango, and gtk classes
today.  The Java will not change; you still need to pass in an
array of bytes.

-Jeff

[java-gnome-hackers] Work so far

[Philip A. C. <pc...@td...>]

Everyone,

I've gotten a lot done with TestGNOME, though it's still not ready to
run yet.  I've implemented a lot of of org.gnu.gnome.App.  It's not
complete yet, but a large portion is done.  I've finished
org.gnu.gnome.ColorPicker, org.gnu.gnome.DateEdit,
org.gnu.gnome.FontPicker, and org.gnu.gnome.HRef.  I hope to be finished
with TestGNOME soon and start testing all this new code.  Until then, it
does compile! ;-)
--=20
Philip A. Chapman

Re: [java-gnome-hackers] Object rename request

[Philip A. C. <pc...@td...>]

Somehow, clipboard doesn't seem as though it needs to be changed.=20
"clipboard" is a compound word taken from the English language, and so
Clipboard seems fine to me.  Outside of GUI widgets and the world of
programming, however, there is no such thing as a toolbar (At least, not
according to the dictionary at http://www.m-w.com).  It all seems rather
arbitrary and based on what "feels" right. ;-)

Anyway, thanks for acting on my suggestion.

On Sun, 2002-08-18 at 10:35, Mark Howard wrote:
> I have not renamed:
> Clipboard
> (should it also be renamed?)
--=20
Philip A. Chapman

Re: [java-gnome-hackers] Object rename request

[Mark H. <mh...@ti...>]

On Sun, 2002-08-18 at 14:07, Philip A. Chapman wrote:
> Mark,
>=20
> As you have time, could you rename Toolbar to ToolBar.  I believe the
> name change is desirable as the rename from Statusbar to StatusBar.=20
> Ignore this if you do not agree.

I've renamed:
Toolbar=20
ToolbarChildType
ToolbarSpaceStyle
ToolbarStyle
Tooltips
TooltipsData
Scrollbar
HScrollbar
VScrollbar

I have not renamed:
Clipboard
(should it also be renamed?)

I will now work on:
- Adding support for multiple listeners on each button (I was thinking
this was unnecessary when implementing it, but can now think of a few
cases where it could be useful)
- Write Event handling for the other widgets I've been working on
- Adding calls to initializeEventHandlers in all the constructors I've
written.

--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

[java-gnome-hackers] Object rename request

[Philip A. C. <pc...@td...>]

Mark,

As you have time, could you rename Toolbar to ToolBar.  I believe the
name change is desirable as the rename from Statusbar to StatusBar.=20
Ignore this if you do not agree.

Thanks,
--=20
Philip A. Chapman

Re: [java-gnome-hackers] Button Event Listeners

[Jeffrey M. <ku...@zo...>]

The code you added only allows there to be one listener.
You should change this to allow multiple listeners.  Other
than that it looks good.

-Jeff

On Sat, 2002-08-17 at 11:42, Mark Howard wrote:
> hi,
>   I've implemented event listeners for the gtk Button widget. Please
> take a look to make sure everything is how you would like it.
> 
> There's a very basic example in examples/gtk/buttons/ButtonEvents.java
> 
> The changes involved:
> - Creating gtk/events/ButtonEvent.java and
> gtk/events/ButtonListener.java (mostly copied from the mouse listener)
> - Writing SetListener (stored internally as a weak reference) and event
> handing methods in Button.java
> - Adding initializeEventHandler method to Button.java
> - Adding calls to initializeEventHandler in button constructors
> 
> -- 
> 
> +----------------------------------------------+
> | Mark Howard               cam.ac.uk   mh344@ |
> | http://www.tildemh.com    tildemh.com    mh@ |
> +----------------------------------------------+

Re: [java-gnome-hackers] String encoding | showAll() | ButtonBox example

[Jeffrey M. <ku...@zo...>]

On Sat, 2002-08-17 at 05:37, Mark Howard wrote:
> hi,
>   I've been working on an example app for the ButtonBoxes:
> /src/examples/gtk/buttonbox/ButtonBoxes.java
> (I have implemented gtk Frame btw)
> 
> The main problem seems to be with string encodings. 
> The button box example gives the warnings:
> ** (java-gnome:14365): WARNING **: Invalid UTF8 string passed to
> pango_layout_set_text()

I'll take a look at it this evening and see if I can uncover
the root of the problem. 

> All widgets seem to require either implicit show() calls or calls to
> showAll() of their direct parent. This seems strange, IMHO.

This is strange but not something we can get around.  It is a
requirement of the GTK libs.

-Jeff

[java-gnome-hackers] Button Event Listeners

[Mark H. <mh...@ti...>]

hi,
  I've implemented event listeners for the gtk Button widget. Please
take a look to make sure everything is how you would like it.

There's a very basic example in examples/gtk/buttons/ButtonEvents.java

The changes involved:
- Creating gtk/events/ButtonEvent.java and
gtk/events/ButtonListener.java (mostly copied from the mouse listener)
- Writing SetListener (stored internally as a weak reference) and event
handing methods in Button.java
- Adding initializeEventHandler method to Button.java
- Adding calls to initializeEventHandler in button constructors

--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

[java-gnome-hackers] add prefix to Window

[Mark H. <mh...@ti...>]

hi,
  After reading previous emails, I agree that it is a bad idea to have
the prefixes on the class names. The previous example of colour wouldn't
be that important as the user is unlikely to import both awt and j-g
packages.

However, we do have a serious name space conflict with gtk and gdk
Window. I have been working on example apps and it is not ideal to have
to write the package name in full (this will affect *all* non-gnome
apps)
org.gno.gtk.Window window =3D new
org.gnu.gtk.Window(GtkWindowType.TOPLEVEL);
I think it might be a good idea to add a prefix to these particular
classes.=20

As far as I can see, no other classes are conflicting.=20
--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

[java-gnome-hackers] String encoding | showAll() | ButtonBox example

[Mark H. <mh...@ti...>]

hi,
  I've been working on an example app for the ButtonBoxes:
/src/examples/gtk/buttonbox/ButtonBoxes.java
(I have implemented gtk Frame btw)

The main problem seems to be with string encodings.=20
The button box example gives the warnings:
** (java-gnome:14365): WARNING **: Invalid UTF8 string passed to
pango_layout_set_text()

In my code, I have been using String.getBytes() with no encoding
argument. I guess this is wrong. I have tried a few examples and read
through the gtk docs, but have been unable to determine what should be
passed to the getBytes method.=20

This seems to affect all classes which pass Strings to native methods.

++

All widgets seem to require either implicit show() calls or calls to
showAll() of their direct parent. This seems strange, IMHO.

--=20

+----------------------------------------------+
| Mark Howard               cam.ac.uk   mh344@ |
| http://www.tildemh.com    tildemh.com    mh@ |
+----------------------------------------------+

RE: [java-gnome-hackers] name conflict

[Philip A. C. <pc...@td...>]

I think the names should stand as they are.  This is the reason packes
were created to start with.  Personally, if there is a chance that there
may be a name confusion when reading my code, I usually use the full
name of the Class.

On Fri, 2002-08-16 at 14:36, Jeffrey Morgan wrote:
> > Which class will the newbie should use?, java.awt.Color or
> > org.gnu.gdk.Color? see what I mean?
> >=20
> > I think that the class names without the Gdk,... prefix can make the
> > code a bit complex.
> >=20
> > I want to hear you opinions.
>=20
> I understand your point.  The reason I removed the prefix was
> because I thought it was redundant due to the package names.  Also,
> I thought somebody that is new to java-gnome, and new to GTK/GNOME
> for that matter, shouldn't be concerned with which library a
> widget was wrapping.  Finally, I envision creating higher abstractions
> than what is provided in the native libraries (a true framework) and
> it would not be clear which prefix to use in those circumstances.
> I am open to your suggestions.
>=20
> -Jeff
>=20
> BTW: I think you English is fine!!
>=20
--=20
Philip A. Chapman

RE: [java-gnome-hackers] name conflict

[Rubio Jr. <ser...@hi...>]

Umm, better now :). I like the idea.



I appreciate to hear that my english is not so bad.

Thks.


On Fri, 2002-08-16 at 21:36, Jeffrey Morgan wrote:
> > Which class will the newbie should use?, java.awt.Color or
> > org.gnu.gdk.Color? see what I mean?
> > 
> > I think that the class names without the Gdk,... prefix can make the
> > code a bit complex.
> > 
> > I want to hear you opinions.
> 
> I understand your point.  The reason I removed the prefix was
> because I thought it was redundant due to the package names.  Also,
> I thought somebody that is new to java-gnome, and new to GTK/GNOME
> for that matter, shouldn't be concerned with which library a
> widget was wrapping.  Finally, I envision creating higher abstractions
> than what is provided in the native libraries (a true framework) and
> it would not be clear which prefix to use in those circumstances.
> I am open to your suggestions.
> 
> -Jeff
> 
> BTW: I think you English is fine!!
> 

RE: [java-gnome-hackers] name conflict

[Jeffrey M. <Jeffrey.Morgan@BristolWest.com>]

> Which class will the newbie should use?, java.awt.Color or
> org.gnu.gdk.Color? see what I mean?
> 
> I think that the class names without the Gdk,... prefix can make the
> code a bit complex.
> 
> I want to hear you opinions.

I understand your point.  The reason I removed the prefix was
because I thought it was redundant due to the package names.  Also,
I thought somebody that is new to java-gnome, and new to GTK/GNOME
for that matter, shouldn't be concerned with which library a
widget was wrapping.  Finally, I envision creating higher abstractions
than what is provided in the native libraries (a true framework) and
it would not be clear which prefix to use in those circumstances.
I am open to your suggestions.

-Jeff

BTW: I think you English is fine!!

RE: [java-gnome-hackers] My work so far

[Jeffrey M. <Jeffrey.Morgan@BristolWest.com>]

> Would it be possible to rename the Statusbar Widget to StatusBar? This
> will probably require an exception to be added to the code which
> generates the java file. 

I think it is a good idea to rename the Statusbar class.  I don't
believe we will need to make a change to the code generator since
it is no more than a developers tool at this time.  Any code that
is created by the generator should be merged with the existing
code in the src/java and src/jni directory.  There shouldn't
be too many changes going forward.

Please make sure you also change the naming of the methods in
the C code.  JNI requires a specific naming convention in order
to work.

-Jeff