t quite shortly to propose an OpenJDK project that will
>> consider the goals of
>> - a short to medium term solution for JDK running on Wayland in X11
>> compatibility mode
>> - a medium to long term solution for JDK running as a native Wayland client.
>>
>> The
On Fri, Jul 9, 2021 at 12:17 PM Alexey Ushakov
wrote:
>
>
>
> On 8 Jul 2021, at 19:11, Mario Torre wrote:
>
> [resending with hopefully the correct email address as I have
> completely lost which mailing list I'm subscribed to with which
> email!!!]
>
> I te
e with
> > various parties that have expressed
> > interest in helping towards the outcome of supporting Wayland
> >
> > Consequently we expect quite shortly to propose an OpenJDK project
> > that will consider the goals of
> > - a short to medium term solution for JDK running on
#x27;s get this pushed ASAP.
Hi Phil,
I pushed to the client repository, please let me know if there is anything else
I need to do, and sorry again for the hassle
Cheers,
Mario
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
ic for the isWheel.
Here is the patch to fix this, I'm still running the whole series of
tests but I'm confident this time:
http://cr.openjdk.java.net/~neugens/8234107/webrev.00/
I apologise again for this, it shouldn't happen.
Cheers,
Mario
On Wed, Nov 13, 2019 at 8:39 PM Mario Torr
will need to file a new
> bug
> to track the re-fix.
>
> -phil.
>
>
>
> On 11/13/19 11:23 AM, Mario Torre wrote:
> > Ok, I can reproduce the error now.
> >
> > The test uses the VK_TAB to traverse the buttons, I admit this code is
> > quite... interest
ers,
Mario
On Wed, Nov 13, 2019 at 7:28 PM Mario Torre
wrote:
>
> Hi Phil,
>
> This is strange, as I've run the full jtreg tests in addition to the
> mouse event ones and didn't get any failure. Nonetheless, thanks for
> spotting and apologise for breaking the build, I
gt;
> When I backout your change, the tests all pass again.
> Prasanta also reported that backing out this change fixed them.
>
> These tests aren't what I'd call 100% stable but there is definitely a
> new problem here.
> Can you check what you see on your end and we'
On Mon, 2019-11-11 at 11:45 +, Dmitry Markov wrote:
> Hi Mario,
>
> The fix looks good to me.
Thanks, I pushed it.
Cheers,
Mario
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
On Thu, 2019-10-31 at 12:00 +0100, Mario Torre wrote:
> On Wed, 2019-10-30 at 15:45 -0700, Sergey Bylokhov wrote:
> > Looks fine.
>
> Thanks!
>
> I believe I still need a second reviewer's approval? (or, is this
> rule still in place?)
>
Ping?
Cheers,
Mario
-
On Wed, 2019-10-30 at 15:45 -0700, Sergey Bylokhov wrote:
> Looks fine.
Thanks!
I believe I still need a second reviewer's approval? (or, is this rule still in
place?)
Cheers,
Mario
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
cus event.
Cheers,
Mario
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
On Tue, 2019-10-08 at 11:42 +0200, Mario Torre wrote:
Ping?
Cheers,
Mario
> Hi all,
>
> I filed a bug related to how mouse wheel interact with focus events:
>
> https://bugs.openjdk.java.net/browse/JDK-8231991
>
> The issue seems to be that we still consider mouse butto
- if approved - all the way down to 8,
I'm not sure if the addition of those two constants is accepted
however in the backports, perhaps I should just hard code the values
for these instead?
Thanks in advance for the feedback.
Cheers,
Mario
--
Mario Torre
Associate Manager, Software Engine
time
> on debugging, fixing & testing, please give us your understanding, Sergey.
>
> Finally I am in favor of Martin's patch 2 sent by Oct 16th:
> http://cr.openjdk.java.net/~mbalao/webrevs/8204142/8204142.webrev.02
>
> Cheers,
> Laurent
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
d this in the 9 patch as it is indeed more logical. Thanks for
spotting this as I completely missed it (good that we have reviews for
backports too!).
It's fixed in this new webrev:
http://cr.openjdk.java.net/~neugens/8150954/webrev-jdk8u.01/jdk.patch
Cheers,
Mario
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30 9205 5D7E 4952 3F65 7898
On Mon, Jul 11, 2016 at 7:10 PM, Alexandr Scherbatiy
wrote:
> The fix looks good to me.
Great, I just updated my local repository, I'll push as soon as it's
done compiling.
Thanks!
Cheers,
Mario
On Fri, Jul 8, 2016 at 10:05 AM, Alexandr Scherbatiy
wrote:
> On 7/4/2016 3:14 PM, Mario Torre wrote:
>>
>> On Wed, Jun 29, 2016 at 12:40 PM, Mario Torre wrote:
>>>
>>> Ping?
>>
>> Ping Ping?
>
>
> Just a question. The isGtkSupported is mo
On Mon, Jul 4, 2016 at 4:07 PM, Semyon Sadetsky
wrote:
> Hello Mario,
>
> I will arrange a new JPRT run this week.
Thanks!
Cheers,
Mario
On Wed, Jun 29, 2016 at 12:40 PM, Mario Torre wrote:
> Ping?
Ping Ping?
> Cheers,
> Mario
>
> On Thu, Jun 16, 2016 at 6:47 PM, Mario Torre wrote:
>> On Wed, Jun 1, 2016 at 1:52 PM, Semyon Sadetsky
>> wrote:
>>>
>>>
>>> On 6/1/2016 2:39 PM,
Ping?
Cheers,
Mario
On Thu, Jun 16, 2016 at 6:47 PM, Mario Torre wrote:
> On Wed, Jun 1, 2016 at 1:52 PM, Semyon Sadetsky
> wrote:
>>
>>
>> On 6/1/2016 2:39 PM, Mario Torre wrote:
>>>
>>> On Wed, Jun 1, 2016 at 1:23 PM, Semyon Sadetsky
>>> w
On Wed, Jun 1, 2016 at 1:52 PM, Semyon Sadetsky
wrote:
>
>
> On 6/1/2016 2:39 PM, Mario Torre wrote:
>>
>> On Wed, Jun 1, 2016 at 1:23 PM, Semyon Sadetsky
>> wrote:
>>>
>>> I ran JPRT build. It seems that the build server does not have the
>>
On Wed, Jun 1, 2016 at 1:23 PM, Semyon Sadetsky
wrote:
> I ran JPRT build. It seems that the build server does not have the requested
> header:
>
> /opt/jprt/T/P1/102200.ssadetsk/s/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:40:39:
> fatal error: X11/extensions/Xcomposite.h: No su
2016-05-30 17:53 GMT+02:00 Semyon Sadetsky :
> The rest is OK to me.
Great, thanks!
This is the final webrev:
http://cr.openjdk.java.net/~neugens/8150954/webrev.04/
Assuming it's still OK for you, I believe I need another reviewer's OK to push?
Cheers,
Mario
--
pgp key: http://subkeys.pgp.ne
2016-04-06 14:02 GMT+02:00 Semyon Sadetsky :
>
>
> On 4/6/2016 2:19 PM, Mario Torre wrote:
>>
>> On Wed, Apr 6, 2016 at 12:50 PM, Semyon Sadetsky
>> wrote:
>>>
>>> Hello Mario,
>>>
>>> Seems X11 call would be the best solution for AW
On Tue, May 24, 2016 at 12:42 PM, Muneer Kolarkunnu
wrote:
> Hi Prasanta,
>
>
>
> I raised ccc and it got approved: http://ccc.us.oracle.com/8153184
This link doesn't seem to be accessible from outside, is there a public link?
Cheers,
Mario
It's very difficult to understand your issue, beside, it seems that you are
manually copying around libraries and it's clear that this only has the
effect of destabilizing the platform.
I suggest to start with a clear description of what the problem is, what is
the expected behavior, what is the e
2016-04-20 20:32 GMT+02:00 Sergey Bylokhov :
> Hi, Mario.
>>
>> BTW, Toolkit.createCustomCursor doesn't say to throw anything upon
>> failure, I would expect user code to check getBestCursorSize before
>> calling createCustomCursor, but this seems to never be done in the
>> internal code, and I do
Hi all,
I happens that I stumbled upon an interesting issue with
XToolkit.createCustomCursor().
On a very specific combination of hardware and X11 driver we get an
exception propagating from XToolkit.createCustomCursor(), the
exception is:
java.awt.AWTException: Exception: class
java.lang.Illega
On Wed, Apr 6, 2016 at 2:02 PM, Semyon Sadetsky
wrote:
> Not compile time switch but run-time. I would introduce a new system
> property, for example "-Dawt.robot.gtk=true". Just in case if your solution
> will stop to work on some platforms or WMs. GTK may be the working
> alternative there.
Al
On Wed, Apr 6, 2016 at 12:50 PM, Semyon Sadetsky
wrote:
> Hello Mario,
>
> Seems X11 call would be the best solution for AWT Robot screenshots under
> Linux. I'm ready to approve it as a default solution.
> But it seems to me better to preserve the current GTK dependent code as a
> kind of alterna
On Tue, Mar 8, 2016 at 1:21 PM, Mario Torre wrote:
> Hi Sergey,
>
> Here is a proposed fix for JDK9, it removes the dependencies on GTK
> and use only X11 calls:
>
> http://cr.openjdk.java.net/~neugens/8150954/webrev.02/
>
> I only tried this on a RHEL 7.2 so far but
Hi all,
I'm interested in backporting this change to 8u:
https://bugs.openjdk.java.net/browse/JDK-8137571
Before I go on and rework/test the patch on 8 I would like to know if
this is desired (or if you are already planning to do that!).
Cheers,
Mario
ot totally convinced we should use X11 directly, instead we
should probably move to using GTK always[1], but I realise this is the
longest path[2].
Cheers,
Mario
[1] GTK3 possibly.
[2] And of course, I'm totally willing to help here.
On Wed, Mar 2, 2016 at 5:45 PM, Mario Torre wrote:
> On
On Wed, Mar 2, 2016 at 5:24 PM, Sergey Bylokhov
wrote:
> Hi, Mario.
> I assume that it works exactly the same as gtk version? if yes then it will
> be good to change the code in jdk9 as well and remove this dependency?
You mean to remove the dependency on GTK and use the X11 code?
It would make
Hi all,
I have a fix for the issue detailed in the following bug report:
https://bugs.openjdk.java.net/browse/JDK-8150954
The issue is does not affect JDK9 so I guess my primary target for the
bug is jdk8u-dev and the backports will go into 7 and 6 as needed.
The fix basically checks the _NET_W
I couldn't find a LinearRGBConverter in OpenJDK but indeed that name
was somewhat familiar...
I believe you want to contact the GNU Classpath project, this isn't an
OpenJDK issue.
Cheers,
Mario
2016-01-18 13:01 GMT+01:00 Andrey Kuzmenko :
> Hi guys, I think there is a bug in LinearRGBConverter c
On Thu, 2015-02-19 at 17:30 +0100, Roman Kennke wrote:
> Am Dienstag, den 17.02.2015 um 13:55 -0800 schrieb Phil Race:
> > As I understand it, none of these can be exported from the java.desktop
> > module.
> > Only standard Java SE APIs can be exported.
> >
> > Which means that even if you made
On Wed, 2015-02-18 at 16:06 -0800, Phil Race wrote:
> There have been brief internal exchanges every now and again for some
> substantial period
> of time (18 months at least) as to whether we should consolidate the
> various JDK client groups
> in openjdk. The client groups are considered to be
2015-02-16 23:57 GMT+01:00 Roman Kennke :
> So, in order to make Cacio stuff work with JDK 9, it needs to be part of the
> desktop module, in other words, OpenJDK code base. Sounds like it's time for
> a Cacio JEP :-)
Ok, let's do that then.
Cheers,
Mario
--
pgp key: http://subkeys.pgp.net/
On Mon, 2015-02-16 at 18:54 +0100, Roman Kennke wrote:
> Am Montag, den 16.02.2015 um 09:05 +0100 schrieb Mario Torre:
> > Hi Phil,
> >
> > While I welcome this, it also means it will make impossible to create
> > custom ports of the AWT ports for *JDK9+. For one, it
Hi Phil,
While I welcome this, it also means it will make impossible to create
custom ports of the AWT ports for *JDK9+. For one, it will break
Caciocavallo for example.
Do you have any suggestion how we can deal with this?
For Cacio, we can try to merge the code in the JDK proper (long
overdue
On Fri, 2014-10-31 at 14:54 +0100, Jiri Vanek wrote:
> On 06/19/2014 04:46 PM, Petr Pchelko wrote:
> > Hello, Jiri.
> >
> > Sorry for the delayed answer.
> > From the code point of view you current change looks OK to me. It's an
> > internal package and we can change the access modifier easily.
>
On Thu, 2014-06-19 at 17:26 +0200, Jiri Vanek wrote:
> For now, I'm going to derive the API from original plugin-applet-hole
> patch little bit reduced by
> experience from [3]
I don't have myself a lot of experience with the Plugin API (from an
implementation POV), but I would guess that the re
Vote: yes
Cheers,
Mario
Il 19/mag/2014 21:53 "Anthony Petrov" ha
scritto:
> I hereby nominate David DeHaven (OpenJDK user name: ddehaven) for jdk9
> Committer
>
> David has contributed a number of patches to JDK 7u, 8, 8u, and 9. Also,
> he has reviewed many fixes that went into those releases.
Il giorno lun, 17/12/2012 alle 17.23 +0400, Artem Ananiev ha scritto:
> On 12/14/2012 5:30 PM, Mario Torre wrote:
> > Il giorno ven, 14/12/2012 alle 16.35 +0400, Artem Ananiev ha scritto:
> >> On 12/14/2012 4:10 PM, Roman Kennke wrote:
> >>> Am Freitag, den 14.12.2
Il giorno ven, 14/12/2012 alle 16.35 +0400, Artem Ananiev ha scritto:
> On 12/14/2012 4:10 PM, Roman Kennke wrote:
> > Am Freitag, den 14.12.2012, 15:35 +0400 schrieb Artem Ananiev:
> >> On 12/10/2012 11:57 PM, Mario Torre wrote:
> >>> Hello Anthony,
> >>>
Il giorno gio, 13/12/2012 alle 17.17 +0400, Anthony Petrov ha scritto:
> Hi Mario,
>
> XConstants.java:
> > 133 public static final int MAX_BUTTON_MASK = 5;
>
> This is obviously not a mask, but an index. Please rename this constant
> to just MAX_BUTTONS, or MAX_BUTTON_INDEX, or MAX_BUTTONS
Hello Anthony,
Sorry for the delay, but I've been pretty busy lately.
Here is the new webrev with the corrections you requested:
http://cr.openjdk.java.net/~neugens/853079/webrev.02/
Is it OK now for pushing to jdk8 awt-gate?
I need a bug ID too.
Cheers,
Mario
2012/11/14 Mario Torre :
Il giorno mer, 14/11/2012 alle 21.35 +0400, Anthony Petrov ha scritto:
> Roman, Mario,
>
> I agree with your reasoning regarding "prefer to
> not leave bugs intact". :) I appreciate that you've tested with a
> multi-button mouse, this confirms that the fix is safe. I believe that
> we don't have
Il giorno lun, 12/11/2012 alle 15.44 +0100, Roman Kennke ha scritto:
> Am Montag, den 12.11.2012, 18:29 +0400 schrieb Anthony Petrov:
> > Hi Mario, Roman,
> >
> > Thanks for additional details. I'm not really an expert in the mouse
> > events handling area, but the fix looks scary. I recall we pu
Hi all!
I would like to propose a fix for this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=853079
The root cause of the bug is an event being generated that sets the
grabWindowRef on the window confusing the internal events state.
Usually, when a mouse press is detected the grabWindowRef i
Il giorno mar, 07/08/2012 alle 17.18 +0400, Anthony Petrov ha scritto:
> I agree with Artem that pre-loading the jawt library unconditionally is
> a bad thing to do, because even tiny milliseconds matter. Besides, a
> fair amount of Java GUI applications simply don't require jawt, so this
> pre
2012/7/30 Artem Ananiev :
> What is "binary compatibility"? It's impossible to make any change in JDK
> and don't break someone's code, that relies on unspecified behavior. My
> personal attitude to "binary compatibility" is the same as to "bug to bug
> compatibility", which was never supported by
are/vm/memory/binaryTreeDictionary.cpp:173:7:
> >>>>
> >>>> error: ‘link_tail’ was not declared in this scope, and no declarations
> >>>> were found by argument-dependent lookup at the point of instantiation
> >>>> [-fpermissive]
> >&
e don't observe the
> problem.
>
> --
> best regards,
> Anthony
>
>
> On 6/13/2012 2:19 PM, Mario Torre wrote:
>>
>> Hi all!
>>
>> I'm trying to compile the latest http://hg.openjdk.java.net/jdk8/awt
>> but I got this error:
>>
&g
Hi all!
I'm trying to compile the latest http://hg.openjdk.java.net/jdk8/awt
but I got this error:
ompiling
/home/neugens/work_space/jdk/jdk8-awt/hotspot/src/share/vm/memory/blockOffsetTable.cpp
/home/neugens/work_space/jdk/jdk8-awt/hotspot/src/share/vm/memory/binaryTreeDictionary.cpp:
In instan
Hi all,
I also agree with Omair.
To be honest, I'm not that happy with the fix, but not because of
Omair's patch, which is very fine given the current state of things,
but because we keep adding this to each and every new WM we find,
although fixing AWT in this regard will be probably more work t
Il giorno 13/gen/2012, alle ore 17:42, Richard Bair ha scritto:
>
> On Jan 5, 2012, at 12:20 PM, Roman Kennke wrote:
>
>> Hi all,
>>
>> Thanks Mario for bringing this up.
>>
>> First of all let me explain what is Cacio and why we think it's useful.
>> In essence, it is an (somewhat) abstract i
Hello all,
I would like to ask a question about the future directions for Caciocavallo,
and CacioWeb.
As you may already know, Cacio is a project we started for the OpenJDK
Innovators Challenge and was aimed at refactoring the graphics code in OpenJDK
to allow custom peers (and hence easy the
t; On 10/15/2011 12:30 AM, Mario Torre wrote:
>> While working a bit on cacio, we just found some new nice addition to the
>> Toolkit code, like this one:
>>
>> public boolean areExtraMouseButtonsEnabled() throws HeadlessException {
>> GraphicsEnvironme
While working a bit on cacio, we just found some new nice addition to the
Toolkit code, like this one:
public boolean areExtraMouseButtonsEnabled() throws HeadlessException {
GraphicsEnvironment.checkHeadless();
return Toolkit.getDefaultToolkit().areExtraMouseButtonsEnabled()
the whole intent of the behaviour is to discourage external
> code
> from accessing sun.* classes etc, this isn't something that's prominently
> documented.
>
> -phil.
>
>
> On 9/28/2011 2:30 PM, Mario Torre wrote:
>> Hi Phil,
>>
>> Thanks for th
Hi Phil,
Thanks for the explanation. Since we compile cacio against the rt.jar that
would make sense...
On the other end, this is a problem, since building cacio will require a source
distribution now... Is there any way to force javac to tolerate "friendly" code?
Cheers,
Mario
---
pgp key: ht
2011/8/18 Clemens Eisserer :
> Sorry the first patch was broken, as the static block executed before the
> static initializer.
> I've uploaded a corrected version to:
> http://cr.openjdk.java.net/~ceisserer/7080700/webrev.01/
>
> Is it ok to initialize to 1 directly in line 199?
>
> Thanks Clemens
2011/8/18 :
> Changeset: 34fdcdb70d20
> Author: rupashka
> Date: 2011-07-28 18:13 +0400
> URL: http://hg.openjdk.java.net/jdk8/2d/jdk/rev/34fdcdb70d20
>
> 6995769: occasion NPE thrown from SwingUtilities.computeIntersection()
> Reviewed-by: alexp
>
> ! src/share/classes/javax/swing/R
2011/7/28 Roman Kennke :
> Hi Artem,
>
>> On 7/28/2011 10:34 PM, Roman Kennke wrote:
> I will tell this (artificial problem) to my team! They are running into
> this every couple of weeks with a real world application in a critical
> application. Yes, it's application's fault. But doing this bette
2011/7/28 Roman Kennke :
> Find attached a testcase. Upon running, this will bring up a small frame
> and a JOptionPane. None of them renders for me, but after some blind
> clicking in the option pane it throws exactly this NPE.
>
> Regards, Roman
>
Yes! :)
Mario
--
pgp key: http://subkeys.pgp.n
2011/7/28 Artem Ananiev :
>
> +1
Yeah, I agree with Roman, IllegalStateException sounds like the
perfect option to me.
Cheers,
Mario
--
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
IcedRobot: www.icedrobot.org
Proud GNU Cl
2011/7/28 :
> Changeset: 34fdcdb70d20
> Author: rupashka
> Date: 2011-07-28 18:13 +0400
> URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/34fdcdb70d20
>
> 6995769: occasion NPE thrown from SwingUtilities.computeIntersection()
> Reviewed-by: alexp
>
> ! src/share/classes/javax/swing/
, you remember it?
Roman, maybe we should introduce some big macro instead ;)
In any case, I agree this is my problem, there is nothing wrong in the
JDK code, I just think it would be more portable with this refactored a bit.
Cheers,
Mario
--
Mario Torre, Software Developer, http://www.jrolle
, I'm only interested in 7 so far
(speaking for my company, now).
Cheers,
Mario
--
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +4
plus some other little places.
I need to prepare a patch for that, but before I would like to have some
suggestion or if you are not interested at all, I'll just fix the
specific code that we use and not care about all the references.
Cheers,
Mario
--
Mario Torre, Software Devel
s,
> Andrei
If you really did this, you will be my personal hero for a long long
time!
Cheers,
Mario
--
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.ai
point, I expect this to be better and better as the time
pass.
Cheers,
Mario
--
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +49-721-663 96
ve!
Cheers,
Mario
--
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +49-721-663 968-53
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Andrei
How many buttons and scroll wheels do yo have on your mouse??? :)
Cheers,
Mario
--
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Te
to build up the community!
Let's defeat the remaining sceptical!! :)
Cheers,
Mario
--
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas
hat this time we have the review to
happen in public?
Cheers,
Mario
--
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +49-721
't see much alternatives.
This code is X11 specific anyway.
All this Font code is really sensible to this kind of infinite loops...
Cheers,
Mario
--
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18
Il giorno sab, 06/09/2008 alle 11.01 +0200, Roman Kennke ha scritto:
Hi all!
> I see this is a problem, but nothing that can't be solved with some
> hacking :-)
SMOP :)
> > Because if you want to
> > incorporate this toolkit to
> > JDK you must have compatible behavior, LaF, and pass JCK.
>
Il giorno mar, 05/08/2008 alle 12.25 -0700, Dmitri Trembovetski ha
scritto:
>Yeah, I knew you'll like Phil's changes to that code =)
eh...
I'll try to sync asap. I think we should define a better interface for
the Font code, what we did was just a "wild" refactor, while it would be
nice to h
t would make sense to have it? In this case I
would put little more of myself into this.
Ciao!
Mario
--
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.c
his (he's on vacation
>until Aug 26 though).
So it's a good time for doing the changes!!! haha
Seriously, I hope we can work out something!
Cheers!
Mario
P.S. I'm sorry if anyone gets the mail 6 times, it seems that I have few
problems with the correct addres
published
under the SCA of Roman Kennke, Mario Torre and aicas GmbH. This
includes the code published under these repositories:
http://hg.openjdk.java.net/caciocavallo/caciocavallo/
http://kennke.org/~hg/hgwebdir.cgi/caciocavallo/
http://kennke.org/~hg/hgwebdir.cgi/caciocavallo-ng/
The latter two
published
under the SCA of Roman Kennke, Mario Torre and aicas GmbH. This
includes the code published under these repositories:
http://hg.openjdk.java.net/caciocavallo/caciocavallo/
http://kennke.org/~hg/hgwebdir.cgi/caciocavallo/
http://kennke.org/~hg/hgwebdir.cgi/caciocavallo-ng/
The latter two
published
under the SCA of Roman Kennke, Mario Torre and aicas GmbH. This
includes the code published under these repositories:
http://hg.openjdk.java.net/caciocavallo/caciocavallo/
http://kennke.org/~hg/hgwebdir.cgi/caciocavallo/
http://kennke.org/~hg/hgwebdir.cgi/caciocavallo-ng/
The latter two
87 matches
Mail list logo
