Did some more testing with r7194, to verify that it operates correctly
with my Cairo hooks.
Seems to be OK.
On the Mac, I also tried printing the front window that has my Cairo
rendered context in it (as a widget subclassed from Fl_Box) and was
surprised to discover that the window contents were
Am 03.03.2010 09:49, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Did some more testing with r7194, to verify that it operates correctly
with my Cairo hooks.
Seems to be OK.
Fine.
On the Mac, I also tried printing the front window that has my Cairo
rendered context in it (as a widget
On 2 Mar 2010, at 10:24, Albrecht Schlosser wrote:
Hmm, we fixed some already, but this is important. Can you tell us
which Fl_xyz this was about?
Testing with r7194, Manolo has now fixed those warnings...
All I got this time (warning wise) is:
Compiling fl_font.cxx...
All,
Some notes on testing r7187 of the printing patch on a few random
targets last night.
OSX PPC 10.4.11:
Build and runs OK. Not obviously slower than stock (though this
particular machine is slow by modern standards anyway...)
My offscreen tests worked OK, and printed OK.
Other tests seem to
On 01.03.2010 at 18:51, Matthias Melcher wrote:
On 01.03.2010, at 18:07, Albrecht Schlosser wrote:
The consequence would be to have better planning, a roadmap for ABI
changes, shorter release cycles (with changing minor version numbers
like 1.x) and (as before) the possibility to break the
There is a place to upload a binary so I can upload the compiled code I
have here to be tested on other machines for the zombie proccess ?
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
On 02.03.2010 at 10:08, MacArthur, Ian (SELEX GALILEO, UK) wrote:
All,
Some notes on testing r7187 of the printing patch on a few random
targets last night.
OSX PPC 10.4.11:
Build and runs OK. Not obviously slower than stock (though this
particular machine is slow by modern standards
Well on other news sites they generally have a channel only for binaries
to don't polute the messages, I looked at the news channels availlable
here and decided to post device.exe to test channel if someone want's to
test it.
compiled with mingw 4.4.1 stripped.
Domingo Alvarez Duarte wrote:
Well on other news sites they generally have a channel only for binaries
to don't polute the messages, I looked at the news channels availlable
here and decided to post device.exe to test channel if someone want's to
test it.
compiled with mingw 4.4.1 stripped.
On 02.03.2010, at 11:48, Domingo Alvarez Duarte wrote:
By the way how hard will be to have zoom at design time on fluid, because
it's hard to align things precisely without zoom, as well to allow scrollbox
when designing, for example I have a netbook and some windows that can be
designed
IMHO 1.2 and 2.x died because nothing was ever officially
released. I'd prefer to get the ABI good enough and release
1.3.0. When applied to the many apps out there, we will get
plenty of feedback for fixing... .
Yep, agreed.
1.3 is already such a huge improvement over 1.1. We
There is a place to upload a binary so I can upload the
compiled code I
have here to be tested on other machines for the zombie proccess ?
Not as such - most folk just post them on their own website, if they
need to.
That said, a lot of people (i.e. me, for example) will not download
A lot of build-time warnings about class FL_xyz has
virtual functions
with non-virtual destructor type stuff.
Hmm, we fixed some already, but this is important. Can you tell us
which Fl_xyz this was about?
Don't have that machine here - will post later.
I *think* it was from every
MacArthur, Ian (SELEX GALILEO, UK) wrote:
I reworked a bit the example proposed yesterday, and I'm resending it
here, by the way how hard will be to have zoom at design time
on fluid,
I'm not a big fan of supporting zoom within the toolkit.
Though if others want it, and are able to
On 02.03.2010, at 12:05, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Yes, again, but I hope that we can also include the
Fl_Printer/Fl_Device upgrade.
Well, based on the (frankly still very limited!) testing I've done so
far, I'm veering towards pushing for the Fl_Device patch being
MacArthur, Ian (SELEX GALILEO, UK) wrote:
I reworked a bit the example proposed yesterday, and I'm resending it
here, by the way how hard will be to have zoom at design time
on fluid,
I'm not a big fan of supporting zoom within the toolkit.
Though if others want it, and are able to
Some notes on testing r7187 of the printing patch on a few random
targets last night.
OSX PPC 10.4.11:
Build and runs OK. Not obviously slower than stock (though this
particular machine is slow by modern standards anyway...)
My offscreen tests worked OK, and printed OK.
Other tests seem
On 2 Mar 2010, at 10:24, Albrecht Schlosser wrote:
Hmm, we fixed some already, but this is important. Can you tell us
which Fl_xyz this was about?
Testing with r7194, Manolo has now fixed those warnings...
All I got this time (warning wise) is:
Compiling fl_font.cxx...
fl_font_mac.cxx:38:
On 26.02.2010 17:33, Albrecht Schlosser wrote:
On 26.02.2010 16:58, Matthias Melcher wrote:
do you have an approximate time when you will merge the printing API
into the 1.3 branch? I would like to start fixing the remaining UTF8
issues, but that will change a little bit of the drawing API
To Matthias: It would be really good if you would not do much
structural changes for UTF-8 now, since this might indeed complicate
the merge. Currently I succeeded in merging the main branch changes
into the printing branch, so that we would be able to do the merge-
back easily.
I don't
I ask all developers (and other willing testers) to check out the
printing development branch [1], test it and give feedback. Thanks.
Just tried this on winXP / mingw and it appears to be working OK.
Built fine, and stuff does come out the printer.
I am not seeing the zombie process left
Am 01.03.2010 11:10, MacArthur, Ian (SELEX GALILEO, UK) wrote:
I ask all developers (and other willing testers) to check out the
printing development branch [1], test it and give feedback. Thanks.
Just tried this on winXP / mingw and it appears to be working OK.
Built fine, and stuff does
But, I should probably have been more explicit: what we really need to
test (also) is the normal FLTK behavior on all platforms.
Ah. OK - that'll take a bit longer... Maybe a lot longer!
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A
On 01.03.2010, at 10:45, MacArthur, Ian (SELEX GALILEO, UK) wrote:
To Matthias: It would be really good if you would not do much
structural changes for UTF-8 now, since this might indeed complicate
the merge. Currently I succeeded in merging the main branch changes
into the printing
manolo gouy wrote:
On 26.02.2010 17:33, Albrecht Schlosser wrote:
I've been confident that the existing code two days ago was in a good
shape to merge back, but now I'm not as sure anymore. See below.
Albrecht: I don't understand your concern here.
Could you explain it please?
Okay,
On 01.03.2010, at 14:17, manolo gouy wrote:
This doc hides what is not of end users' concern, namely platform-
specific classes (e.g., Fl_Quartz_Printer) and classes (e.g.,
Fl_Virtual_Printer) that exist only because there are differences
between platforms. Is that a good idea ?
Yes,
MacArthur, Ian (SELEX GALILEO, UK) wrote:
We developers all don't want to have another dead project like
FLTK 1.2 and now obviously also FLTK 2, so that we should be
absolutely sure that
(a) the code is okay and works as expected
(b) it is the right way to go
(c) it is possible to
Do we want to do it for 1.3 though? I can not say.
Yes, that's the main question. We have some kind of catch-22
situation:
We can't get full (PS) printing support w/o device abstraction, but we
must be sure that we want it (now). Last Friday we didn't have it at
all, but Manolo's
Matthias Melcher wrote:
On 01.03.2010, at 10:45, MacArthur, Ian (SELEX GALILEO, UK) wrote:
To Matthias: It would be really good if you would not do much
structural changes for UTF-8 now, since this might indeed complicate
the merge. Currently I succeeded in merging the main branch changes
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Do we want to do it for 1.3 though? I can not say.
Yes, that's the main question. We have some kind of catch-22
situation:
We can't get full (PS) printing support w/o device abstraction, but we
must be sure that we want it (now). Last Friday we
On 01.03.2010, at 18:07, Albrecht Schlosser wrote:
The consequence would be to have better planning, a roadmap for ABI
changes, shorter release cycles (with changing minor version numbers
like 1.x) and (as before) the possibility to break the ABI with each
minor version number change.
manolo gouy wrote:
So developers clearly grasp what changes are involved in the core
of FLTK-1.3, I present them here conceptually but accurately:
I definitely appreciate this description..!
Cery useful for us all to know how the new device abstraction
is implemented
Matthias Melcher wrote:
I'd prefer to get the ABI good enough and release 1.3.0.
Release early, release often is a good tenet used by linux and other
successful open source projects.. I aspire to that myself with my
open source projects.
PS: I still believe that an
Hi guys,
do you have an approximate time when you will merge the printing API into the
1.3 branch? I would like to start fixing the remaining UTF8 issues, but that
will change a little bit of the drawing API which would then make a merge
harder for you.
Thanks for the great work,
Matthias
On 26.02.2010 16:58, Matthias Melcher wrote:
Hi guys,
do you have an approximate time when you will merge the printing API into the
1.3 branch? I would like to start fixing the remaining UTF8 issues, but that
will change a little bit of the drawing API which would then make a merge
On 26.02.2010, at 17:33, Albrecht Schlosser wrote:
On 26.02.2010 16:58, Matthias Melcher wrote:
Hi guys,
do you have an approximate time when you will merge the printing API into
the 1.3 branch? I would like to start fixing the remaining UTF8 issues, but
that will change a little bit
36 matches
Mail list logo
