Thread: [Java-gnome-developer] (no subject)
Brought to you by:
afcowie
Menu
▾
▴
java-gnome-developer
|
From: <dg...@we...> - 2001-08-06 23:31:46
|
Hello, Just to let you know www.webcamgo.com is open Now ! Make around Trip Live Around the World with all the Webcams. It's fun ! http://www.webcamgo.com Thanks and have a nice visite on www.webcamgo.com we apologize for any email you may have inadvertently received. Please send back this email. |
|
From: Tiago C. <cog...@li...> - 2003-07-30 21:50:15
|
Hi,
First of all congrats for your great job on bringing the java community a way to
integrate gnome in theyre apps, i really appreciated, i've been following this
project but was waiting for the gnome 2 port.
Noq for the not unfortunate part, I've downloaded 0.8 version and tried to run
the "First" in your tutorial and it doens't work, it shows this error message:
java.lang.UnsatisfiedLinkError: /home/tiago/usr/lib/libGNOMEJava.so:
libGTKJava.so: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1473)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1397)
at java.lang.Runtime.loadLibrary0(Runtime.java:788)
at java.lang.System.loadLibrary(System.java:832)
at org.gnu.gnome.Program.<clinit>(Program.java:100)
.....
This is very strange, because i ran java -Djava.library.path=/my/path
SomeProgram
my/path contains the following files:
libGNOMEJava.so.0.8.0 libGladeJava.so.0.8.0
libGTKJava.so libGTKJava.so.0.8.0
libGNOMEJava.so libGladeJava.so
I am devoloping a project which contains JNI bindings so i've already ran
programs which include binding libraries (infact the program which is calling
the "First" example uses a jni library and it loads correctly), i tried puting
the libGTKJava.so in my home, in /usr/lib but no results until now. i find it
very strange.
I tried to run this line only:
Gtk.main();
The program loaded successfully so I thought that gnome was not working and GTK
might have a chance so i tried running a GTK only example. I created the
following code:
Window win = new Window(WindowType.TOPLEVEL);
win.show();
Gtk.main();
The program segfaulted and crashed the JVM with the following message (only
showing part but can send you the real log):
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x4CA2D984
Function=gtk_window_new+0x2C
Library=/usr/lib/libgtk-x11-2.0.so.0
Current Java thread:
at org.gnu.gtk.Window.gtk_window_new(Native Method)
at org.gnu.gtk.Window.<init>(Window.java:44)
When i ran the example above and before crashing it showed this error output:
(process:16576): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:16576): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:16576): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:16576): GLib-GObject-CRITICAL **: file gtype.c: line 1937
(g_type_add_interface_static): assertion `G_TYPE_IS_INSTANTIATABLE
(instance_type)' failed
(process:16576): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:16576): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:16576): GLib-GObject-CRITICAL **: gtype.c:1871: initialization
assertion failed, use g_type_init() prior to this function
(process:16576): GLib-GObject-CRITICAL **: file gobject.c: line 615
(g_object_new): assertion `G_TYPE_IS_OBJECT (object_type)' failed
I tried switch Window for a Dialog but unfornatly the same error persisted.
After this i downloaded the current (30.07.2003) cvs version but no changes
whatsoever.
I really need to port my application to java-gnome because i want to put my
project on savannah and they are really strict about java software (which can't
use swing code).
I am using J2SDK 1.4.2 from sun (i've also tested it with J2SDK 1.4.1 from
blackdown) and the same problem happened.
Thank you for your time,
Tiago Cogumbreiro
|
|
From: Mark H. <mh...@ti...> - 2003-07-31 06:37:09
|
On Wed, 2003-07-30 at 22:58, Tiago Cogumbreiro wrote:: > java.lang.UnsatisfiedLinkError: /home/tiago/usr/lib/libGNOMEJava.so: > libGTKJava.so: cannot open shared object file: No such file or directory libGNOMEJava cannot find libGTKJava - this is being done natively, so the options passed to Java are not involved. Instead, you need to set the environment variable LD_LIBRARY_PATH to point to your local java-gnome lib dir e.g. export LD_LIBRARY_PATH=/home/tiago/usr/lib/:$LD_LIBRARY_PATH -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Tiago C. <cog...@li...> - 2003-08-01 02:13:07
|
Quoting Mark Howard <mh...@ti...>: > On Wed, 2003-07-30 at 22:58, Tiago Cogumbreiro wrote:: > > java.lang.UnsatisfiedLinkError: /home/tiago/usr/lib/libGNOMEJava.so: > > libGTKJava.so: cannot open shared object file: No such file or > directory > > libGNOMEJava cannot find libGTKJava - this is being done natively, so > the options passed to Java are not involved. Instead, you need to set > the environment variable LD_LIBRARY_PATH to point to your local > java-gnome lib dir > e.g. export LD_LIBRARY_PATH=/home/tiago/usr/lib/:$LD_LIBRARY_PATH > -- > .''`. Mark Howard > : :' : > `. `' http://www.tildemh.com > `- mh...@de... | mh...@ti... | mh...@ca... > That was it, it's all working now :) Thank you very much Mark. By the way, i was browsing the sourcode of java-gnome and came accross to a tool that has something with generating jni bindings, do you have any documentation about this tool available? It might become _very_ handy when i develop my jni apps. Thank you for your time, Tiago Cogumbreiro |
|
From: Mark H. <mh...@ca...> - 2003-12-10 13:41:48
|
Hello, Sorry for such a long email -- it is important for the java-gnome project, however, so I think it's worth it. Please send any comments or questions you have. For those of you who don't know yet, some of the gtkmm developers have proposed and in fact created and 'official' set of gnome bindings. This means that the bindings are listed on the gnome bindings web pages as official bindings [1]. Developers (and distributors and end users) will therefore be far more interested in these bindings than bindings listed in a contrib page. Being in the gnome bindings release set will show quality and commitment. It may also lead the way for applications developed with gnome bindings (as opposed to the standard c gnome) to be included in the official gnome desktop release. [1] http://www.gnome.org/start/2.5/bindings/ Java-Gnome developers have agreed in private that we should definitely do all we can to join this group. Of course, there are quite a few changes and guarantees we need to make -- we need to follow the rules [2]. [2] http://developer.gnome.org/dotplan/bindings/rules.html Summary of rules ---------------- (my proposals are in the section after this) API support NB: this is my interpretation of what we should be doing - there doesn't seem to be any official version - If we say we support a gtk/gnome module, we should support all of the latest version of it (e.g. for gtk+ we cannot leave out treeview widgets). However, small variations are acceptable, especially for cases which are exceedingly difficult to support in java, such as not including the entire drag and drop functionality - *we* choose which modules we support. We announce these in the modules list [3]. - If we want to develop bindings for a new module, we can do this without following the schedule - making our own releases when we like, but they will not be listed in the modules list [3]. [3] http://www.gnome.org/start/2.5/bindings/modules.html Release schedule We must strictly follow the release schedule [4]. Note that this includes first tarballs by 22 December, further tarballs roughly at 2 week intervals, API freeze and beta1 tarballs by Feb. 16th, and the final release by Mar. 22nd. [4] http://www.gnome.org/start/2.5/bindings/ Multiple tarballs (many developers from many projects disagree about this). We should have separate tarballs for each module we support. This is a good idea - we can assign modules to developers and more easily ensure that each module has an active developer. This will be of even more importance as the project grows to support more of gnome. Also, it is required by the bindings release set rules and will look good from that perspective. We will still create a large tarball containing everything, which is what most people will actually use. Version Numbers major.minor.sub minor = odd -- development version minor = even -- stable release There has not been a recommendation to follow upstream version numbers at this stage. Changes to be made to Java-Gnome -------------------------------- Now for the important part. This is what I think we need to be doing now: API support ----------- We should (initially) publicly announce support for glib, gtk, gnome, libglade. We then need to urgently see how much of the upstream api we actually support. The current sources are based on 2.0 releases -- there are probably many changes which are required. *please* can ppl volunteer to take a module each and go through this -- either file bug reports for any API sections which we don't support, or produce a document listing them all (if there are many). We need to produce a schedule for this and make sure it is all done properly, ideally within the next 2 weeks. This task is probably vital to our joining the gnome bindings release. CVS Hacking ----------- If there are no objections, I will do this over the next few days. Reorganise cvs: java-gnome/web - website java-gnome/java-gnome - main code tree. Includes makefiles which will build everything. { java-gnome/java-gnome/gtk java-gnome/java-gnome/pango java-gnome/java-gnome/atk java-gnome/java-gnome/glib java-gnome/java-gnome/glade java-gnome/java-gnome/gnome java-gnome/java-gnome/gtkhtml java-gnome/java-gnome/vte java-gnome/java-gnome/gconf } - These are the main source code areas. Each will contain separate Makefile.in's (the makefiles will be generated using data from jg/jg/build/), /src/java/org/gnu/... and /src/jni/ trees. These will all generate separate jar files and shared libraries { java-gnome/java-gnome/doc-core java-gnome/java-gnome/doc-glade java-gnome/java-gnome/doc-gnome } - packages containing documentation and example applications. java-gnome/java-gnome/build - scripts to automate creation of makefiles, tarballs, etc. Applications currently in cvs should be moved to separate projects -- they are too large to be classed as example applications. Having them in separate projects would also be of great benefit to them. Could somebody please volunteer to be the maintainer for each of these and create a new sourceforge project? In order to make these changes, I will download the cvs repo source and hack that manually. This will leave a few days where no commits can be mode and then everybody will have to check everything out again. It's a nuisance - but sadly necessary. I will start as soon as other j-g developers send an email saying they agree - please do this soon. Released Tarballs ----------------- (note - these will all be created by a single script, so it won't be a difficult as it sounds) tarball_name (cvs modules included) libglib-java (glib) libgtk-java (gtk, pango, atk) libgnome-java (gnome) libglade-java (glade) [ libgtkhtml-java (gtkhtml) ] [ libgconf-java (gconf) ] [ libvte-java (vte) ] [ libgnomepanel-java (gnomepanel) ] Items in brackets will be created and put on the website, but will not go in our gnome bindings module list until we are sure we can support them. They are in development. [ java-gnome (all) ] - this is as a convenience. It will probably be used by everyone, especially developers and distributors (who will then create multiple binary packages). Releases will be made: a) (for each module) When we want to. e.g. I would release a libglib module now, including changes to CustomEvents which I made recently. b) (for all public modules) When we need to create tarballs to send to the gnome bindings release group. Focus Shift ----------- At present, the focus of java-gnome has been on improving api and adding support for more gnome libraries. This has to change. We will have to work in three modes: * upgrades - upgrading existing bindings to the latest upstream API. Note that this only includes released stable modules * maintenance - fixing bugs in released modules (e.g. gnome 2.6 release series when we are busy working on 2.7). This will produce tarballs to go into gnome 2.6.x releases. Will mostly be done in parallel with upgrade work (This is not an issue at the moment since we don't have any stable releases - it will be in the future though) * development - Developing bindings for new modules (gconf, gtkhtml, panel-applet, gnome-vfs...). This will be done separately. Releases will be made, but will not be sent to gnome and will not follow the bindings release schedule (until they are complete and we put them forward for inclusion in our stable modules list) The important factor about this is priorities - maintenance then upgrades, then development - we must do things in this order. CVS Branches ------------ In order to implement this, we will have to be more clever with cvs. HEAD branch - development. This is where we will be most of the time gnome2.6 branch - created once 2.6 is nearly ready for release. j-g0.8 branch - created immediately after the cvs hacking and cleaning up from that. This will be for bug fix releases made between now and 2.6 release. (versions may change - see below) NB: having the separate modules in cvs for each upstream module will make this far easier - we will be able to branch modules at different times depending on their development. Release Schedule ---------------- We will release when gnome release schedule asks us to and also when we feel like it. IMHO, releases have been far too infrequent so far for java-gnome. The build scripts for building tarballs should make this easier. Separate modules can be released separately. We will differentiate stable and developmental releases. API changes in stable releases will only happen when they do in gnome -- every 6 months. Parallel install ---------------- We need to make sure that this is all done correctly. The java sources need modifying to load libraries including the major.minor version numbers; the shared libs need to be created with these numbers. People will want to have multiple versions of java-gnome installed - stable for their existing installed apps and developmental for their bug fixing/development/etc.. Version Numbers --------------- java-gnome 0.9.0 should be the next set of tarballs (Dec. 22nd, for gnome 2.5.1). These are our development releases. java-gnome 1.0.0 will be released alongside gnome2.6 I don't think we should follow gnome version numbers - I'm not saying why - this email is far too long already. Move away from sourceforge? --------------------------- CVS is unreliable. File releases are a lot of work - uploading tarballs to an ftp server is much easier Bug tracking is very limited I would like to apply for accounts on gnome.org for java-gnome project. In addition to solving the above problems, it would be yet another sign that java-gnome is a part of the gnome community and ppl should be using it for their applications Upstream contacts ----------------- We need to stay in touch with upstream developments more closely than we are doing at present. If any java-gnome developer is not already subscribed to lan...@li..., please do so now. Also, please keep a check on the gnome bindings release pages and more generally gnome pages. We need help! ------------- I know that many people read java-gnome developer without taking part in java-gnome development. If you can spare any time at all it would be much appreciated. I will try to help out as much as I can with new developers, I'm sure other developers will do too. The main priority at the moment is checking how much of the gnome api we implement - somebody will send another email in a few days with links to the upstream API reference, changes between 2.0 and 2.5 and our own api reference - please volunteer to look through a small section of this. Actions Summary --------------- (I'm really sorry this email got so long...) api - somebody needs to send links to all upstream apis and changes between them (any volunteers?). We all then need to check how much we currently support. We need to keep a record of what checks we have done. cvs hacking - Let me know if it's ok & I'll get to it. tarballs - we'll release more of these after the cvs hackery focus - work more on existing bindings while there are pending bug reports, then look to new libraries release schedule 22 December - tarballs. Make or break time for our inclusion in the official bindings list. 16 Feb - API Freeze 22 March - bindings for 2.6 released parallel install - need minor code modifications version numbering - let me know if you disagree my proposal above sourceforge - anyone second my proposal upstream - join the ml, look at webpages. Find out about development. Find out what API has changed from 2.0 to 2.5 Please send comments, questions and suggestions ASAP -- to be included in the gnome release set we need to move very quickly. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Jeffrey M. <ku...@zo...> - 2003-12-11 14:18:53
|
On Wed, 2003-12-10 at 08:41, Mark Howard wrote:
> API support
> -----------
> We should (initially) publicly announce support for glib, gtk, gnome,
gnome should be stated as libgnome, libgnomeui, and libgnomecanvas
since they are all contained in our org.gnu.gnome package.
> libglade. We then need to urgently see how much of the upstream api we
> actually support. The current sources are based on 2.0 releases --
> there are probably many changes which are required.
> *please* can ppl volunteer to take a module each and go through this --
> either file bug reports for any API sections which we don't support, or
> produce a document listing them all (if there are many).
> We need to produce a schedule for this and make sure it is all done
> properly, ideally within the next 2 weeks. This task is probably vital
> to our joining the gnome bindings release.
>
> CVS Hacking
> -----------
> If there are no objections, I will do this over the next few days.
Are you sure this can be completed and tested in order to allow us
time to make the necessary changes prior to the 22nd?
> Reorganise cvs:
> java-gnome/web
> - website
> java-gnome/java-gnome
> - main code tree. Includes makefiles which will build everything.
> { java-gnome/java-gnome/gtk
> java-gnome/java-gnome/pango
> java-gnome/java-gnome/atk
> java-gnome/java-gnome/glib
> java-gnome/java-gnome/glade
> java-gnome/java-gnome/gnome
> java-gnome/java-gnome/gtkhtml
> java-gnome/java-gnome/vte
> java-gnome/java-gnome/gconf
> } - These are the main source code areas. Each will contain separate
> Makefile.in's (the makefiles will be generated using data from
> jg/jg/build/), /src/java/org/gnu/... and /src/jni/ trees. These will all
> generate separate jar files and shared libraries
>
> { java-gnome/java-gnome/doc-core
> java-gnome/java-gnome/doc-glade
> java-gnome/java-gnome/doc-gnome
> } - packages containing documentation and example applications.
>
> java-gnome/java-gnome/build
> - scripts to automate creation of makefiles, tarballs, etc.
>
> Applications currently in cvs should be moved to separate projects --
> they are too large to be classed as example applications. Having them in
> separate projects would also be of great benefit to them. Could
> somebody please volunteer to be the maintainer for each of these and
> create a new sourceforge project?
>
> In order to make these changes, I will download the cvs repo source and
> hack that manually. This will leave a few days where no commits can be
> mode and then everybody will have to check everything out again. It's a
> nuisance - but sadly necessary. I will start as soon as other j-g
> developers send an email saying they agree - please do this soon.
I am in favor of this move but am concerned that we might not be
able to get everything completed prior to the 22nd. If we do intend
to shoot for this date we should announce our intention on the bindings
list.
>
> Released Tarballs
> -----------------
> (note - these will all be created by a single script, so it won't be a
> difficult as it sounds)
> tarball_name (cvs modules included)
> libglib-java (glib)
> libgtk-java (gtk, pango, atk)
> libgnome-java (gnome)
libgnome, libgnomeui, libgnomecanvas
> libglade-java (glade)
> [ libgtkhtml-java (gtkhtml) ]
> [ libgconf-java (gconf) ]
> [ libvte-java (vte) ]
> [ libgnomepanel-java (gnomepanel) ]
> Items in brackets will be created and put on the website, but will not
> go in our gnome bindings module list until we are sure we can support
> them. They are in development.
> [ java-gnome (all) ] - this is as a convenience. It will probably be
> used by everyone, especially developers and distributors (who will then
> create multiple binary packages).
>
> Actions Summary
> ---------------
> (I'm really sorry this email got so long...)
>
> api - somebody needs to send links to all upstream apis and changes
> between them (any volunteers?). We all then need to check how much we
> currently support. We need to keep a record of what checks we have
> done.
> cvs hacking - Let me know if it's ok & I'll get to it
I would say start now. I just checked in some code so make sure
you get the latest.
> tarballs - we'll release more of these after the cvs hackery
> focus - work more on existing bindings while there are pending bug
> reports, then look to new libraries
> release schedule
> 22 December - tarballs. Make or break time for our inclusion in the
> official bindings list.
> 16 Feb - API Freeze
> 22 March - bindings for 2.6 released
> parallel install - need minor code modifications
Yes. We will have more shared objects to load and finding the entry
point for some of the libs might not be easy.
> version numbering - let me know if you disagree my proposal above
> sourceforge - anyone second my proposal
yes
> upstream - join the ml, look at webpages. Find out about development.
> Find out what API has changed from 2.0 to 2.5
>
> Please send comments, questions and suggestions ASAP -- to be included
> in the gnome release set we need to move very quickly.
|
|
From: Mark H. <mh...@ca...> - 2003-12-11 14:48:32
|
On Thu, Dec 11, 2003 at 09:13:51AM -0500, Jeffrey Morgan wrote: > gnome should be stated as libgnome, libgnomeui, and libgnomecanvas > since they are all contained in our org.gnu.gnome package. we're not going to be able to support libgnomecanvas are we? > > CVS Hacking > > ----------- > Are you sure this can be completed and tested in order to allow us > time to make the necessary changes prior to the 22nd? I've just downloaded the nightly cvs tarball and will start hacking right away. The problem is that I don't have access to the cvs repository directly - I will have to upload the new tarball and request sourceforge admins to install it (this is what it says to do in their docs). If sourceforge is not ready in time, I can create the tarballs myself easily enough for December 22nd. In fact, I would like to have a release before that time - 0.9.0, to test the new build scripts, multiple tarballs and such. Then we can release 0.9.1 to send to gnome. > I am in favor of this move but am concerned that we might not be > able to get everything completed prior to the 22nd. If we do intend > to shoot for this date we should announce our intention on the bindings > list. Done. > > Released Tarballs This is what we should send to the gnome bindings team then, to go on the modules list -- is it ok? http://www.gnome.org/start/2.5/bindings/modules.html > > tarball_name (cvs modules included) > > libglib-java (glib) > > libgtk-java (gtk+, pango, atk) > > libgnome-java (libgnome, libgnomeui, libgnomecanvas) ^^^^^^^^^^^^^^ I don't think we can realistically include this. > > libglade-java (libglade) Other bindings also available (soon) > > [ libgtkhtml-java (gtkhtml) ] > > [ libgconf-java (gconf) ] > > [ libvte-java (vte) ] > > [ libgnomepanel-java (gnomepanel) ] > > cvs hacking - Let me know if it's ok & I'll get to it > I would say start now. I just checked in some code so make sure > you get the latest. I've downloaded a nightly tarball, so will have to manually check all changes from the last few days. I'm starting.. > Yes. We will have more shared objects to load and finding the entry > point for some of the libs might not be easy. Good point. We also need to load e.g. libgnome-java-1.0 directly to avoid problems -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- mh...@de... | mh...@ti... | mh...@ca... |
|
From: Jeffrey M. <ku...@zo...> - 2003-12-11 14:57:36
|
On Thu, 2003-12-11 at 09:47, Mark Howard wrote: > On Thu, Dec 11, 2003 at 09:13:51AM -0500, Jeffrey Morgan wrote: > > gnome should be stated as libgnome, libgnomeui, and libgnomecanvas > > since they are all contained in our org.gnu.gnome package. > we're not going to be able to support libgnomecanvas are we? libgnomecanvas support has been included for some time but I am not sure how complete it is. We can determine if it should be included once we perform our review of the gnome packages. |
|
From: Luca De R. <pie...@li...> - 2003-12-13 19:06:23
|
Hi all, I' m sorry I haven't partecipated these days: unfortunately I have no more access to a decent pc, I'm stuck with a P 200Mhz :(( I could use my girlfriend's one, but not everytime I'll need it. This is bad cause it takes me a life to compile, so I think I couldn't try the new build before Monday. Also I'm on exam (guess what? uml & java, quite hard stuff for me). Il mer, 2003-12-10 alle 14:41, Mark Howard ha scritto: > cvs hacking - Let me know if it's ok & I'll get to it. Ok. Modularity is good. > tarballs - we'll release more of these after the cvs hackery Ok: I think that an all-in-one tarball is vital: modularity is fine, however the whole gnome is experiencing the difficulty to build gnome itself, so garnome, etc... rised up. I've read in the past (on a gnome-developer list) that they thought gnome was falling behind kde also because building gnome is hard (at least it's impractical), and because the haven't a way to distribute it quickly, like an all-in-one tarball :) > focus - work more on existing bindings while there are pending bug > reports, then look to new libraries Agreed. > version numbering - let me know if you disagree my proposal above Ok. Have separate stable/unstable branches it's a benefit for users and above all for us :) > sourceforge - anyone second my proposal Gnome.org + they have bugzilla. + we hope they update things faster (sf web interface is never updated). + it feels like it's a better place for java-gnome.(more official) - I don't know how the do cvs acces and stuff like this and if they have docs. But I think this isn't a problem at all. Sf.net + Very popular repo. + They have a lot of services( compile farm etc..) - There services aren't always reliable. I think we should move to benefit from the use of e.g bugzilla, but leave a sf project entry and maybe upload the tarballs there too. -- Luca De Rugeriis <pie...@li...> |
|
From: Benjamin J. <bp...@gm...> - 2004-11-06 19:38:28
|
--- OOPS! Accidentaly forgot to send this mail to the list
--- Sent useless stuff that contained only Jerry's quoted mail
--- Sorry... :-)
> Yes. Java web start is awesome. Making a similar thing possible with
> Gnome/GTK would be awesome. However, I have gone down this path before.
>
> GTK/Gnome are native libs. This means, for the JWS program to run, it
> cannot do so in a sandbox. The user gets an ugly message telling them
> not to do it.
Right!
This might be the biggest problem when trying to deploy java-gnome
applications using some kind of web start system. The 'standard' user will
just click away the warning message ("Uh... what's that s'posed 'ter be??!
") and that's it. With full access to the system I can't imagine what an
application considered to do harmful things might do... :-(
Anyway... such things can be thought trough. When deploying a standard
Java/Swing application same things can happen: the application wants to have
full access to network, harddisk and refrigiator, the user simply clicks
'OK' and is bored by the missing/bad certificate -- and that's it.
Besides,... it might be wrong to try to immitate Java Web Start 100%, but it
might be a good start to show off some of java-gnome's features. It would be
awesome if other deployment methods beside JNLP could be 'plugged in' to
extend the whole thing...
> GTK/Gnome do not use Java class loader to load their resouses: such as
> icons, themes, .gtkrc files, and the like. There isn't a good way to do
> this with JWS. Gtk/Gnome would have to be able to load their resources
> out of a Classloader. Perhaps adding a callback to GTK's file operations
> that lets you plug in arbitrary ways to retrieve a byte[] or something.
But you CAN use the java class loader to load resources for use with
java-gnome... I used the following code in my 1st java-gnome app:
new LibGlade(
getClass().getResource("somefile.glade").getFile(),
this
);
packed it all nicely together in a JAR file and launched the app using
SableVM. Works! Didn't try that with icons, sounds, etc though...
... you're right. I nearly don't know anything about GTK/GNOME. GNOME is my
desktop of choice and now that I've found out that there is a java-gnome
project I might be going slightly too fast. I'll try to do more RTFMs... :-)
>
> Both of the above cases could more properly be solved in the same way
> Swing/AWTs are. When a Swing program is downloaded from JWS, it does not
> download the entirety of the Swing and AWT libraries: they are located
> on the local machine. AWT uses JNI (or something) to interface with the
> native machine to do it's graphic rendering... and JWS doesn't give you
> a warning about this (just like an applet). Basically somebody has
> configured a security manager of some sort to trust Swing/AWT. So,
> Java-Gnome is installed locally and given permission to do what it
> needs. Obviously this makes one click deployment not quite work...
> except that your Linux distribution SHOULD distribute Java-Gnome by
> default!!!
Yes. That should definately be the goal. Java-Gnome must be installed to use
GNOME Web Start!!!
If there is another net launching protocol similar to JNLP which might be
suited better to deploy java-gnome applications, let me know. See.... I just
had an idea, I'm not quite sure if it might work out.... but I like the idea
itself. Maybe nobody is interrested in my Java-Gnome deployment system.
That's what I wanted to find out first. Is there a need for GNOME Web Start?
Have fun...
Benjamin
(this time from a different e-mail address)
--
NEU +++ DSL Komplett von GMX +++ http://www.gmx.net/de/go/dsl
GMX DSL-Netzanschluss + Tarif zum supergünstigen Komplett-Preis!
|
|
From: Ralph H. <ra...@gm...> - 2007-02-02 08:48:58
|
-- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer |
|
From: Brandon T. <csu...@at...> - 2010-12-20 04:13:50
|
So I have an image from a Pixbuf in a fixed container and I was wondering if there was any type of online resources or anyone could provide some insight on how I might be able to allow the user to drag the image to another location within the fixed area. The fixed area is set in a scrollable viewport. Thanks, bt |
|
From: Andrew C. <an...@op...> - 2010-12-21 16:43:32
|
On Sun, 2010-12-19 at 23:13 -0500, Brandon Thomas wrote: > So I have an image from a Pixbuf in a fixed container Hm. Fixed. Maybe you could describe what you're working on or what you're trying to achieve? In general, to do the sort of manipulations you're hinting at you need a canvas (ie, GooCanvas, which we haven't got a binding for as yet). But for certain simplifications you can get away with some creative Cairo work yourself. In the end there's not much you can't do on a DrawingArea. AfC Sydney |
|
From: iamamoocow d. <lis...@ya...> - 2013-04-15 16:58:02
|
http://www.orthoreliefhospital.com/vvbry/madfsc/1f619/bw297dqn/opy |
|
From: iamamoocow d. <lis...@ya...> - 2013-04-16 15:36:16
|
http://www.peche-stergoz.com/pulqjtrc/5se/zev987pk |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X