Linux redraw problem
Status: Beta
Brought to you by:
maynardd
Menu
▾
▴
#32 Linux redraw problem
This bug originally mentioned by tswoam at:
http://sourceforge.net/forum/forum.php?
thread_id=145653&forum_id=45896.
I have had just one problem, not sure whether this is
a Unix specific thing or if it happens when running on
windows too.
Basically, if the <windowBottom> and <windowRight>
elements in the OPML's header are too big, presumably
too big for the windows size its currently running at,
then some strange things happen.
The outline loads in backwards (top line becomes
bottom, etc). The very first line, which would be
displayed at the very bottom (because its all
reversed) doesn't get displayed at all. And, the whole
outline is uneditable, that is, you can modify text of
existing nodes, but you can't add new ones, and you
can't move the old ones around as you normally can.
Logged In: YES
user_id=102030
Thanks for the bug report. I'm going to look at adding some
code to limit size and position. I believe I've already got
some in there but it is likely not robust enough. Hopefully
I can reproduce this on windows so it's not a platform
specific thing.
Haven't been able to get any weird behavior under win2k
with all kinds of garbage values for the
top/left/bottom/right values in an OPML. This may indeed be
linux specific. However, I did add location restrictions
for the enclosing Outliner Window so that it can't be
placed offscreen by messing with the config.txt file
manually.
>Basically, if the <windowBottom> and
><windowRight> elements in the OPML's header are
>too big, presumably too big for the windows size
>its currently running at, then some strange
>things happen.
In theory this shouldn't be a problem, since all the
outline JInternalFrames sit within a JDesktopPane which
dynamically resizes itself to accomodate any open windows.
This leads me to believe this might be a Swing problem with
JDesktopPanes under *nix. I'll check Sun's bug parade and
see if anything is mentioned.
Logged In: YES
user_id=102030
Hi Simon
So far as I know, you're the first person to
run JOE on Linux. Very cool.
A few questions:
[0] I assume you compiled and built JOE from its
sources. Is that right ??
[1] If so, can you provide some details of your development
environment ??
[2] If so, did you have to tweek any of the sources to get
JOE to build ??
[3] What version of Linux are you using ??
And thanks for the bug report.
Stan
Logged In: YES
user_id=102030
ummm, as far as I know I didn't do any building. :) I
downloaded the outline-1.8.5.tar.gz, unpacked it, converted
the run.bat to a run.sh for the Bash shell, and ran. =:)
I had to mess with pretty much nothing, except the bash
script.
I'm using Slackware 8.0, Java version:
java version "1.3.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build
1.3.1_01)
Java HotSpot(TM) Client VM (build 1.3.1_01, mixed mode)
Under some Linux's (Slackware being one) Java actually
crashes unless due to the initial thread becoming to big,
so the shell script had to set a limit on this too, but
thats a general Java problem.
Other than that though, it was pretty easy to get working.
I guessed the window bug thing was Linux specific
mainly 'cos I guessed it would've been figured out already
if it wasn't.
I've actually written this thing to convert a load of
different outline formats in to each other, and back, etc,
I used it for importing outlines from the GNOME
program "Think" in to OPML, and then in to JOE.
So as a quick hack I setup this program to also
automatically set all the <window*> elements to blank
values, which gets round the problem easily enough.
The only other thing I can think off that doesn't work is
that you can't access the help files directly, because it
uses windows filenames, "\" not "/", etc, but thats far
from serious because you can just load them manually.
Simon
--
simon@kittle.co.uk
http://simon.kittle.info
Logged In: YES
user_id=102030
From what you've observed would it make sense to create an
exception for Linux that constrains the
top/left/bottom/right valus of an OPML to the current size
of the JDesktop? Do you think that might eliminate the
problem?
Also, it would help to get the os.name string from the java
environment so I can write the exception. To get this,
start Outliner, go to "Application Preferences" -> Misc,
then check the "Print Environemnt on Startup" checkbox.
Then close Outliner and then relaunch. At the end of the
spew that goes to the console the environment will be
printed out. One of these lines will start with "os.name".
Thanks for the help.
When I get a chance, I'll transfer the info from this
thread to a new bug.
Logged In: YES
user_id=102030
ok,
os.name just equals "Linux". This is using Sun's JDK.
os.version is the kernel version number. probably not a lot
of use.
As for the size thing, it may help. It seems to be that the
error occours if you resize the window. i.e, if you leave
an outline still, and don't resize it, or move it around
with in the app after you've done a "New" outline, it
usually laods up again OK.
If you try and resize it, make it nice and big for editing,
then problems arise when reloading.
But the actual values are within the window bounds, I just
checked an outline, the <window*> values are like, 2, 4,
460, 650.
The main JOE window is about 800x560, so it should fit
easily.
Logged In: YES
user_id=102030
>If you try and resize it, make it nice and big for
>editing, then problems arise when reloading.
Hmm, this makes me think this might actually be related to
the Phantom Scrolling Bug I introduced in the last build.
That bug was causing a bunch of extra redraws to occur on
resize and window selection events.
I'm going to attach my latest unreleased jar that has a fix
for that bug and let me know if it fixes the problem.
Logged In: YES
user_id=102030
Doh! I always forget there's an attachment size limit. I'll
scp it up to the webserver. The jar is at:
http://outliner.sourceforge.net/outliner.jar