java-gnome-developer — For people using the bindings to write their own applications

Re: [Java-gnome-developer] Running File I/O Thread Crashes Java-Gnome

[Jester <jsn...@gm...>]

> I don't know if this is really relevant or useful, but if you attach
> jvisualvm to his application and force a GC the window goes blank.
> 
> (Or for that matter if you simply leave it profiling the memory for a
> few seconds it will go blank too)
> 

Yes, that's definitely relevant - thanks for taking the time!

The problem seems to affect windows containing a DrawingArea. There seem to be
multiple ways to trigger this as Kenneth points out. 

My thought is that there's a thread/sync issue in the graphics library.

Re: [Java-gnome-developer] Running File I/O Thread Crashes Java-Gnome

[Kenneth P. <ken...@gm...>]

On Sat, 05 Jun 2010 15:47:12 +1000
Andrew Cowie <an...@op...> wrote:
> 
> I was about to blame this as a GC issue, but it doesn't happen if you
> don't start the thread. At least, I've not seen it (perhaps the thread
> is causing GC pressure. I doubt it, though).

I don't know if this is really relevant or useful, but if you attach
jvisualvm to his application and force a GC the window goes blank.

(Or for that matter if you simply leave it profiling the memory for a
few seconds it will go blank too)

Re: [Java-gnome-developer] Running File I/O Thread Crashes Java-Gnome

[Jester <jsn...@gm...>]

Hi Andrew,

I really appreciate that you took a look at this. I've found a workaround by
running the data retrieving part in a separate process (not just a separate
thread). It's a pain in the 'a' but it works.

Your suggestion about sleeping the thread is good and I've tried this. My sleep
time was 100ms per cycle which still causes the crash. Longer sleep cycles would
not be acceptable for my type of application.

The real data mining thread is very different from my sample code. While
reducing the issues to a small example I learned that just about any type of
file i/o or even data retrieval over http can cause the problems I pointed out.
This makes java-gnome unfit for many real-world application. I have great
interest in finding a solution and will not give up, especially since I now have
a workaround that allows me to build software on java-gnome.

Thanks again!

Re: [Java-gnome-developer] Running File I/O Thread Crashes Java-Gnome

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

On Fri, 2010-06-04 at 20:15 +0000, Jester wrote:
> 3. You will notice that DrawingWin goes blank (the drawing disappears)

That is almost certainly a sign you are blocking the main loop with a
call somewhere in your Thread.

But that doesn't really seem to be the case. Weird.

At first DrawingArea's Widget.ExposeEvent gets called fine, even after
you start the thread. It's only after a while that suddenly it goes
blank. That's very strange.

I was about to blame this as a GC issue, but it doesn't happen if you
don't start the thread. At least, I've not seen it (perhaps the thread
is causing GC pressure. I doubt it, though).

++

The diagnostics I've tried so far are going to extra effort to make sure
the Windows stay in scope, and slowing down your thread to sleep(1000).

Anyway, at first glance you're not misusing GTK. The app's UI isn't
freezing.

AfC
Sydney

[Java-gnome-developer] Running File I/O Thread Crashes Java-Gnome

[Jester <jsn...@gm...>]

I've posted this on the hackers mailing list, but since they're hackers and
don't really use these bindings I will try my luck here :)

Here's the code that will reproduce the crash (2 classes):

--- DrawingWin (main class)
import org.freedesktop.cairo.Pattern;
import org.gnome.gdk.Event;
import org.gnome.gdk.EventExpose;
import org.gnome.gdk.Rectangle;
import org.gnome.gtk.DrawingArea;
import org.gnome.gtk.Gtk;
import org.gnome.gtk.VBox;
import org.gnome.gtk.Widget;
import org.gnome.gtk.Window;
import org.gnome.gtk.WindowPosition;
import org.freedesktop.cairo.Context;
import org.freedesktop.cairo.Format;
import org.freedesktop.cairo.ImageSurface;
import org.gnome.gtk.PolicyType;
import org.gnome.gtk.ScrolledWindow;

public class DrawingWin extends Window {

    private ImageSurface surface;

    DrawingWin() {
        hide();

        setTitle("DrawingWin");

        VBox vbox = new VBox(false, 3);

        final DrawingArea d;

        d = new DrawingArea();
        d.setSizeRequest(800, 800 + 400);

        ScrolledWindow scroll = new ScrolledWindow();
        scroll.setPolicy(PolicyType.AUTOMATIC, PolicyType.AUTOMATIC);
        scroll.addWithViewport(d);

        vbox.add(scroll);

        add(vbox);

        setPosition(WindowPosition.CENTER);

        setSizeRequest(600, 400);

        connect(new Window.DeleteEvent() {

            public boolean onDeleteEvent(Widget source, Event event) {
                Gtk.mainQuit();
                return false;
            }
        });

        showAll();

        surface = new ImageSurface(Format.ARGB32, 800, 1200);
        Context im = new Context(surface);
        //im.setAntialias(Antialias.DEFAULT);
        im.setLineWidth(1.0);

        im.setSource(0.8, 0.8, 0.8);
        im.rectangle(0, 0, 800, 1200);
        im.fill();

        im.setSource(0.0, 0.0, 0.0);
        im.rectangle(10, 10, 600, 400);
        im.stroke();

        im.setSource(1.0, 1.0, 1.0);
        im.rectangle(10, 10, 600, 400);
        im.fill();

        im.setSource(0.0, 0.0, 1.0);
        im.moveTo(25.0, 25.0);
        im.lineTo(50.0, 100.0);
        im.stroke();

        d.connect(new Widget.ExposeEvent() {

            public boolean onExposeEvent(Widget source, EventExpose event) {
                System.out.println("expose action");

                final Context cr;
                final Rectangle rect;
                final Pattern linear, radial;

                rect = event.getArea();

                int canvasWidth = 800; 
                int canvasHeight = 1400; 

                System.out.println(rect);

                cr = new Context(source.getWindow());

                cr.setSource(0.0, 0.8, 0.95);
                cr.rectangle(0, 0, canvasWidth, canvasHeight);
                cr.fill();

                cr.setSource(surface, 0, 0);

                cr.paint();

                System.out.println("paint");

                return true;
            }
        });
    }

    public static void main(String[] args) {
        Gtk.init(args);

        new DrawingWin();
        new ThreadWin();

        Gtk.main();
    }
}

--- ThreadsWin

import java.io.BufferedReader;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.gnome.gdk.Event;
import org.gnome.gtk.Button;
import org.gnome.gtk.VBox;
import org.gnome.gtk.Widget;
import org.gnome.gtk.Window;
import org.gnome.gtk.WindowPosition;

public class ThreadWin extends Window {
    DownloadTask t;

    ThreadWin() {
        hide();

        setTitle("ThreadWin");

        VBox vbox = new VBox(false, 3);

        Button start = new Button("Start");

        start.connect(new Button.Clicked() {

            @Override
            public void onClicked(Button source) {
                t = new DownloadTask();
                t.start();
            }
        });

        vbox.add(start);

        add(vbox);

        setPosition(WindowPosition.CENTER);

        setSizeRequest(140, 40);

        connect(new Window.DeleteEvent() {

            public boolean onDeleteEvent(Widget source, Event event) {
                t.cancelTask();
                return false;
            }
        });

        showAll();
    }

    private class DownloadTask extends Thread implements Runnable {
        boolean canceled = false;

        @Override
        public void run() {
            int idx = 0;

            while (!canceled) {
                System.out.println(idx);
                //loadDataFromFile("PWAV.q");

                File f = new File(System.getProperty("user.home"));

                File[] files = f.listFiles();

                for (int i = 0; i < files.length; i++) {
                    f = files[i];

                    if (f.isFile()) {
                        readFile(f);
                    }
                }

                synchronized (this) {
                    try {
                        wait(10);
                    } catch (InterruptedException ex) {

Logger.getLogger(DrawingWin.class.getName()).log(Level.SEVERE, null, ex);
                    }
                }

                idx++;

            }
        }

        void cancelTask() {
            canceled = true;
        }
    }

    void readFile(File f) {
        try {
            FileInputStream fin = new FileInputStream(f);

            BufferedReader in = new BufferedReader(new InputStreamReader(fin));

            // do nothing here...
            in.close();
        } catch (FileNotFoundException ex) {
            System.out.println(ex);
        } catch (IOException ex) {
            System.err.println(ex);
        }
    }
}
---

Instructions:
1. Run DrawingWin which will open two windows, DrawingWin and ThreadsWin
2. Press start which launches a thread
3. You will notice that DrawingWin goes blank (the drawing disappears)
4. Close ThreadWin by pressing the close button on the window bar
5. Close DrawingWin
6. You will see the following crash log:

Exception in thread "main" org.gnome.glib.FatalError: Gdk-CRITICAL
gdk_window_get_position: assertion `GDK_IS_WINDOW (window)' failed
        at org.gnome.gtk.GtkMain.gtk_main(Native Method)
        at org.gnome.gtk.GtkMain.main(GtkMain.java:82)
        at org.gnome.gtk.Gtk.main(Gtk.java:119)
        at DrawingWin.main(DrawingWin.java:119)

My apologies for the slightly complicated example, but it requires two windows
to trigger the assertion problem from above.

Jester

[Java-gnome-developer] Bundle

[Douglaz <do...@gm...>]

Hello everyone!

   I'm attaching on this mail a bundle, with a couple function I wrote, so
you could check them.
   I'm short, I did add on GtkEditable and wrote the code on GtkEditable the
following:
      getPosition()
      getSelectionBoundsStart()
      getSelectionBoundsEnd()


Best regards,
Douglas

Re: [Java-gnome-developer] GtkEditable function request

[Guillaume M. <res...@gm...>]

> Hello everyone!
Hi,

> and to request a couple function I found need to use.
>     Both function from the GtkEditable:
> 
>     gtk_editable_get_position()
>     gtk_editable_get_selection_bounds()
> 
> Nothing urgent or anything, but if you find some free time to get them
> to java-gnome, I would be very happy :)
Both functions are not really difficult to cover. That's why maybe you
can do it by your own. Take a look to the HACKING file. But if you
really can't do it, someone would probably do.

But again, try doing it. You would learn a lot of things about
java-gnome like "it's not hard to help us improve it".

> Best regards,
Regards,

-- 
Guillaume Mazoyer - http://www.respawner.fr/

[Java-gnome-developer] GtkEditable function request

[Douglaz <do...@gm...>]

Hello everyone!

    I writing this mail to congratulate you guys on the great job on the
4.0.15 release, and to request a couple function I found need to use.
    Both function from the GtkEditable:

    gtk_editable_get_position()
    gtk_editable_get_selection_bounds()

    Nothing urgent or anything, but if you find some free time to get them
to java-gnome, I would be very happy :)

Best regards,
Douglas

Re: [Java-gnome-developer] Unable to Activate an hidden Window from a third party library callback method

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

On Mon, 2010-04-12 at 23:44 +0000, F.L. wrote:

> A) I need to popup a list view on a key, list items can be filtered 
> by typing wildcards in a textview.  

Easy.

Do you know about TreeModelFilter?
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/TreeModelFilter.html

You add an Entry where user types.

You write an Entry.Changed handler; there you call TreeModelFilter's
refilter(), then in the TreeModelFilter.Visible you check against the
current text of the Entry.


> B) use arrow key (prefered) or mouse to select history entry, 

Yup. You'll want TreeSelection's setMode() to SelectionMode.SINGLE
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/TreeSelection.html#setMode(org.gnome.gtk.SelectionMode)

> put it in the clipboard, 

Easy, Clipboard's setText(), presumably
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/Clipboard.html

[there's a fair bit more complexity available in GtkClipboard we could
expose, but no one has needed it yet]
http://library.gnome.org/devel/gtk/stable/gtk-Clipboards.html
http://www.freedesktop.org/wiki/Specifications/clipboards-spec


> hide the window containing the listview

That's your business, but Widget's hide().
 
> C) and try to paste it back in the former active window.

huh? Yikes. You're telling another application to do something? That's
not going to be easy.

> XSendKey ? 

That'd just be a simulated keystroke one key at a time. That's probably
not a good idea.

I can see the effect you're going for; within your own application
that'd be do-able.

But one app telling another app what to do (outside of, say, libnotify
or DBus or...) is really sketchy. Heck, only the window manager can
really tell other apps what to do, and even then it's only size and
visibility.

But in any case, the task right now is to keep a journal of clipboard
changes and to be able to replay the selected clipboard item back into
the clipboard on request. Even if you can't force paste elsewhere,
getting the item onto the clipboard will get you most of the way to what
you want.

AfC
Sydney

Re: [Java-gnome-developer] Unable to Activate an hidden Window from a third party library callback method

[F.L. <lab...@gm...>]

Andrew Cowie <andrew@...> writes:

Thank you for your quick reply.

> So the question seems to be how to properly implement a desktop wide
> hotkey. That's interesting.

I had a look at Parcellite (Clipboard manager written in C) to implement 
that
feature quickly and found JXGrabkey implementing it similary;

Parcelite application don't have the described problem as its history gui 
is a popup menu linked to a status icon and clipboard entries are listed as menu
items. 

What I try to do :
A) I need to popup a list view on a key, list items can be filtered 
by typing wildcards in a textview.  
B) use arrow key (prefered) or mouse to select history entry, 
put it in the clipboard, hide the window containing the listview
 
C) and try to paste it back in the former active window. XSendKey ? 

C) due to B) out of scope for the moment.

> 
> The window manager gets away with this, obviously, but the question is
> how other apps can register such a thing. I've noticed a few
> applications that seem to do so. Hamster Applet's preference dialog has
> a "global hotkey" Entry which contains (on my system anyway)
> "<Super>+H", for example.
> 
> Maybe we could have a look at their code (which is Python, I'm afraid)
> to see what they're doing.

OK I'll have a look. 


> Did you try Window's present()?
Yes I did, no result.

. 
> But the fact you're having to go straight to X (instead of letting GDK
> do it for you) is a very bad sign; that usually causes problems.

:)( I'am currently doing some painful experimentations X11/C. 
I was naively
hoping to stay in the good old safe Java world :)


F.L.

Re: [Java-gnome-developer] Unable to Activate an hidden Window from a third party library callback method

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

On Mon, 2010-04-12 at 23:38 +0200, Frédéric LABBE wrote:
> 
> I'm working on a project which deals with building a Clipboard History
> tool.

Hey, cool. Neat.

> I use JXGrabkey to register a global/system wide X11 hotkey in order
> to hide/to put to front the application main window.

So the question seems to be how to properly implement a desktop wide
hotkey. That's interesting.

The window manager gets away with this, obviously, but the question is
how other apps can register such a thing. I've noticed a few
applications that seem to do so. Hamster Applet's preference dialog has
a "global hotkey" Entry which contains (on my system anyway)
"<Super>+H", for example.

Maybe we could have a look at their code (which is Python, I'm afraid)
to see what they're doing.

>     void toggleMainWindow () {

I have something similar in Slashtime. Keeping the state variables about
whether you are minimized or not is trickier than it should be; I think
the compositors of the last few years have messed with (ie) the
VisibilityEvents.

> This call back is not executed in the main Thread but in a Thread
> initiated by JXGrabKey.  
> It works fine as the window is successfully hidden or shown 

Oh, it works, ok :)


> When the window is show (hidden state to visible), the window stays
> unselected and the keypress are still
> sent to whatever window I was using prior using the hotkey.

Yeah, Widget's grabFocus() is about focus within the application. It's a
lot harder to force the window manager to do something if you're not the
currently active application.

Did you try Window's present()?
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/Window.html#present()

> Did I miss a point ? Am I doing something the wrong way ? 

I don't think so, but you're outside the boundaries of a single
application, so we need to work cooperatively with the window manager.

There's only so much we can do there; getting focus behaviour right
between applications (ie, preventing focus stealing) has taken the
window-manager people years to get right.

> Are my troubles due to the TreadAwareness design of Java-gnome ?

No, I don't think so (ie, it's working, not crashing or blocking, so
you're probably ok).
But the fact you're having to go straight to X (instead of letting GDK
do it for you) is a very bad sign; that usually causes problems.
> 
> Any ideas to implement the described behavior with a different code
> design ?

Not off hand, but then I've never tried to come up with a global hot
key. If I had to guess, the right question to ask is "what's the GNOME
way to take a keypress globally", perhaps
http://live.gnome.org/ControlCenter/ApplicationDefinedKeybindings

Once we know what we're doing, then we can figure out what to add to
java-gnome if we need to.

AfC
Sydney

-- 
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: enabling
successful deployment of mission critical information technology in
enterprises, worldwide.

http://www.operationaldynamics.com/

Sydney   New York   Toronto   London

[Java-gnome-developer] Unable to Activate an hidden Window from a third party library callback method

[Frédéric L. <lab...@gm...>]

Hi !

I'm working on a project which deals with building a Clipboard History tool.

I've built the tool out of the following components:

    + a java-gnome GTK app (developed by myself). (widget tree detailed at
the end of this post)
    + JXGrabkey (native shared library+ JNI Java bindings)
    + a custom native shared library used to monitor clipboard content (no
implications with this post)

I use JXGrabkey to register a global/system wide X11 hotkey in order to
hide/to put to front the application main window.

When the defined hotkey is pressed then released the JXGrabkey java binding
is called and calls a supplied java callback
which I implemented as follow

         public static void hotkeyCallBack() {
            clippo.toggleMainWindow();
         }

 where clippo is an instance of my app Class with the toggleMainWindow
implemented as follow :
    void toggleMainWindow () {

        if (isMainWindowVisible || isMainWindowMinimized) {
            mainWindow.hide();
        } else {
            isMainWindowVisible=true;
                isMainWindowMinimized=false;
                mainWindow.grabFocus();
                //clipItemListView.grabFocus();

        }
    }


This call back is not executed in the main Thread but in a Thread initiated
by JXGrabKey.
It works fine as the window is successfully hidden or shown but I experience
the following behavior :

When the window is show (hidden state to visible), the window stays
unselected and the keypress are still
sent to whatever window I was using prior using the hotkey.

For example while a Firefox window is opened, active and has focus (I can
scroll page using keyboard arrows),
I press the proper hotkey and my main Window is shown. This window has its
top level set to
true and it is centered with a WindowPosition.MOUSE so the Window is on top
of the display.

I tried using the grabFocus on my Window instance,the tree view instance or
the textinput instance,
aleas! the window keeps staying unselected/unactive (its title bar colour
indicates me it is unselected).
I move arrows the current window is still the browser one. If I click my
window comes active. (I want the user to
be able to do everything without mouse interactions).

Am I doing something the Wrong way. I've been browsing API javadocs without
finding Window.setActive
or obvious workaround.

Did I miss a point ? Am I doing something the wrong way ?
Are my troubles due to the TreadAwareness design of Java-gnome ?

Any ideas to implement the described behavior with a different code design ?

Fred L.

Widget Tree :
    Window (mainWindow)
        VBox
            Treeview
            Trextview

Re: [Java-gnome-developer] New application using Java-Gnome

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

On Thu, 2010-03-25 at 21:43 +0200, Serkan Kaba wrote:
> It has finally reached a maturity for an 
> initial 0.1 release along with the jni libraries supporting it.

That's great news Serkan, congratulations.

AfC
Melbourne

[Java-gnome-developer] New application using Java-Gnome

[Serkan K. <se...@ge...>]

As some of you (at least Andrew) know I started developing an 
application (actually it's a rewrite of an old one) to query inklevels 
of various printers supported by libinklevel 
(http://libinklevel.sf.net). It has finally reached a maturity for an 
initial 0.1 release along with the jni libraries supporting it. The 
project page is @ Googlecode (http://mso.googlecode.com) while source 
code and issue tracker is at Launchpad.

I'll try to add some screenshots, documentation , a Gentoo ebuild etc. 
in the weekend.

I'll be glad to hear feedback from anybody reading this post and willing 
to test it.
-- 
Sincerely,
Serkan KABA

Re: [Java-gnome-developer] java-gnome 4.0.15 released

[Serkan K. <se...@ge...>]

Added to portage including the post release javadoc fixes.

-- 
Sincerely,
Serkan KABA
Gentoo Developer

[Java-gnome-developer] java-gnome 4.0.15 released

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

Happy 15th of March to all of you living in the past. Here in the future
in Australia where it's the 16th of March we've just made another
release of java-gnome!

:)

Release notes
http://java-gnome.sourceforge.net/4.0/NEWS.html#4.0.15

Tarball
http://ftp.gnome.org/pub/gnome/sources/java-gnome/4.0/java-gnome-4.0.15.tar.bz2

Anyone using java-gnome to develop lovely applications is, as ever,
invited to come hang out with us in #java-gnome on irc.gimp.net and chat
with us about what you're up to. We'd love to see you.

Cheers!

AfC
Sydney

-- 
Andrew Frederick Cowie
Consulting Engineer
Operational Dynamics

IT strategy, organizational architecture, systems review, and effective
procedures for change management: enabling successful deployment of
mission critical information technology in enterprises small and large.

http://www.operationaldynamics.com/

Re: [Java-gnome-developer] glib fatal error using a FileChooserButton

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

On Fri, 2010-03-05 at 15:06 +0100, Guillaume Mazoyer wrote:
> ~$ rm .recently-used.xbel

Ok, so, that's weird.

Before we go any further, why would that file ever be empty? Isn't is
part of a default [ie new user has logged in for the first time] GNOME
install?

AfC
Sydney

Re: [Java-gnome-developer] glib fatal error using a FileChooserButton

[Guillaume M. <res...@gm...>]

Hello,

I found why that crash occurred. And it is pretty easy to reproduce.
Go in your home folder and then:

~$ rm .recently-used.xbel
~$ touch .recently-used.xbel

or even (but it is stupid)

~$ mkdir .recently-used.xbel

Start your program with a file chooser widget and then it will crash. I
tested with a program written in C and it does not crash but it warns
you about that ".recently-used.xbel" file.

I don't know if we should really consider this as a bug because if the
user uses his/her desktop right it should not happened... But if we can
do something to prevent the program from crashing it could be nice.


-- 
Guillaume Mazoyer - http://www.respawner.fr/

Re: [Java-gnome-developer] Transparent Window

[Rafael A. <fae...@gm...>]

Ok. Thanks

Try to find a solution by the gnome, I thought transset, maybe I get some
success.

Thanks again.

2010/2/18 Andrew Cowie <an...@op...>

> On Thu, 2010-02-18 at 19:33 -0300, Rafael Arcanjo wrote:
>
> >
> > Well I used the command AWTUtilities.setWindowOpacity (this, 0.5) and
> > gave as incompatible types.
>
>
> You can't mix toolkits.
>
> Two different libraries both trying to drive GTK will confuse the X
> server and crash your Java VM.
>
> If you're using java-gnome (and of course we hope you do!) to build the
> user interface layer for your application, then its native coverage of
> the GTK toolkit is all you need to use.
>
> > is there any way to get the transparent window?
>
> Yes...
>
> Transparency is a somewhat advanced topic; we don't tend to need it much
> in GNOME (and people are discouraged from trying to make fancy shaped
> windows that ignore the window manager).
>
> Coverage in java-gnome has been prototyped but is still experimental and
> not yet accepted for merging to 'mainline'.
>
> If you want to try it you'll need to learn how to build java-gnome from
> Bazaar. If the branch works for you, then perhaps you will consider
> helping us improve it to the point where it can be accepted into the
> next release.
>
>
> There are two parts:
>
>
> 1. Set backing pixmap to transparent:
>
>        screen = w.getScreen();
>        colormap = screen.getColormapRGBA();
>        w.setColormap(colormap);
>
>        w.realize();
>        underlying = w.getWindow();
>        underlying.setBackingPixmap(null, false);
>
> 2. Clear to background in Widget.ExposeEvent:
>
>        cr.setSource(1.0, 1.0, 1.0, 1.0);
>        cr.setOperator(Operator.CLEAR);
>        cr.paint();
>
>
> but as I said, it's still experimental and that API is not in a released
> version of the library, nor in 'mainline'.
>
> If you want to work on it, my branch is at
> 'hackers/andrew/cairo-transparency'. Come and chat with us in
> #java-gnome on irc.gimp.net and we can explore it further.
>
> Otherwise, at the moment,
>
> > is there any way to get the transparent window?
> >
> No, sorry.
>
> AfC
> Sydney
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
>
>

Re: [Java-gnome-developer] Transparent Window

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

On Thu, 2010-02-18 at 19:33 -0300, Rafael Arcanjo wrote:

> 
> Well I used the command AWTUtilities.setWindowOpacity (this, 0.5) and
> gave as incompatible types.


You can't mix toolkits.

Two different libraries both trying to drive GTK will confuse the X
server and crash your Java VM.

If you're using java-gnome (and of course we hope you do!) to build the
user interface layer for your application, then its native coverage of
the GTK toolkit is all you need to use.

> is there any way to get the transparent window?

Yes...

Transparency is a somewhat advanced topic; we don't tend to need it much
in GNOME (and people are discouraged from trying to make fancy shaped
windows that ignore the window manager).

Coverage in java-gnome has been prototyped but is still experimental and
not yet accepted for merging to 'mainline'.

If you want to try it you'll need to learn how to build java-gnome from
Bazaar. If the branch works for you, then perhaps you will consider
helping us improve it to the point where it can be accepted into the
next release.


There are two parts:


1. Set backing pixmap to transparent:

        screen = w.getScreen();
        colormap = screen.getColormapRGBA();
        w.setColormap(colormap);
        
        w.realize();
        underlying = w.getWindow();
        underlying.setBackingPixmap(null, false);
        
2. Clear to background in Widget.ExposeEvent:

        cr.setSource(1.0, 1.0, 1.0, 1.0);
        cr.setOperator(Operator.CLEAR);
        cr.paint();


but as I said, it's still experimental and that API is not in a released
version of the library, nor in 'mainline'.

If you want to work on it, my branch is at
'hackers/andrew/cairo-transparency'. Come and chat with us in
#java-gnome on irc.gimp.net and we can explore it further.

Otherwise, at the moment,

> is there any way to get the transparent window?
> 
No, sorry.

AfC
Sydney

[Java-gnome-developer] Transparent Window

[Rafael A. <fae...@gm...>]

Taking advantage of the topic, is there any way to get the transparent
window?

Well I used the command AWTUtilities.setWindowOpacity (this, 0.5) and gave
as incompatible types.

Thanks again.

Re: [Java-gnome-developer] Bar Gnome

[Rafael A. <fae...@gm...>]

Ok

I will test and return immediately.

Thank you very much.


Taking advantage of the topic, is there any way to get the transparent
window?

Well I used the command AWTUtilities.setWindowOpacity (this, 0.5) and gave
as incompatible types.

Thanks again.

Re: [Java-gnome-developer] Bar Gnome

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

On Thu, 2010-02-18 at 09:50 -0300, Rafael Arcanjo wrote:
> Bar Gnome

I think you mean the `gnome-panel` and specifically the "Window List"
applet?

If so,
> 
> Is there a way to develop an application using the java-gnome it does
> not appear in the bar

Yes.

See Window's setSkipTaskbarHint(), and while you're at it
setSkipPagerHint() too:
http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/Window.html#setSkipPagerHint(boolean)\

See if that does what you're looking for! Good luck,

AfC
Sydney

-- 
Andrew Frederick Cowie
Consulting Engineer
Operational Dynamics
http://www.operationaldynamics.com/

Re: [Java-gnome-developer] Bar Gnome

[Waldemar B. <wb...@gm...>]

Call setSkipTaskbarHint(true) on your Window object.

Am 18.02.2010 13:50, schrieb Rafael Arcanjo:
> Bar Gnome
>
> Is there a way to develop an application using the java-gnome it does 
> not appear in the bar of gnome? Because he had developed an 
> application with the JDialog, but she appeared at the bar of gnome.
>
> In short, I want my application does not appear in the gnome bar, it 
> is possible?
>
> Grateful
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
>
> _______________________________________________
> java-gnome-developer mailing list
> jav...@li...
> https://lists.sourceforge.net/lists/listinfo/java-gnome-developer
>    


-- 
Waldemar Biller<wb...@gm...>
Kleebreite 22, 34246 Vellmar
Germany
Phone: +49 561 8200905
Mobile: +49 170 7701869

[Java-gnome-developer] Bar Gnome

[Rafael A. <fae...@gm...>]

Bar Gnome

Is there a way to develop an application using the java-gnome it does not
appear in the bar of gnome? Because he had developed an application with the
JDialog, but she appeared at the bar of gnome.

In short, I want my application does not appear in the gnome bar, it is
possible?

Grateful