On Sat, Feb 06, 2010 at 06:30:08AM -0800, Andreas Ekstrand wrote:
Hi,
We use an Fl_Scroll with a large number of buttons to accomplish a fancy
tree-view in our application. After an update to the latest FLTK 1.3, we
discovered a major fall in performance when clearing the scroll in order
imacarthur wrote:
About 20-plus years ago, I wrote a PS to CGM interpreter for a
display unit we had.
Yikes -- sounds like a big project to parse postscript
and convert..!
Not so bad as it sounds... The device who's output we were processing
only used a subset of all that PS
I reverted the change in svn for now and I will perhaps not be able
to work on this in the next few days. It's a pity that it didn't
work, but I knew that there was an inconsistent state during the
delete loop. I didn't expect this fix_focus/send_event problem
though, but this is definitely
Currently not working in my test: Transparency (real alpha or
transparent
pixels like in Fl_Pixmap). I didn't test real alpha channel images yet.
Is there a chance that transparency can work with printing devices?
I'll post my demo program that shows the effect with a pixmap.
Albrecht: I
manolo gouy wrote:
Currently not working in my test: Transparency (real alpha or
transparent
pixels like in Fl_Pixmap). I didn't test real alpha channel images yet.
Is there a chance that transparency can work with printing devices?
I'll post my demo program that shows the effect with a
Hm, that's why I also posted the .pdf file ;-)
Sorry, my mistake.
I have just now run the test on MSWin, and see the point.
In fact, a bigger problem occurs on Mac: the pixmap disappears
altogether whenever scaling is applied (although it's perfectly
reproduced at 1:1 scale, as said
Hi Kurt,
I was thinking about sub-classing Fl_Group or Fl_Scroll and implement a clear
method of my own, but variables being private and Albrecht strongly suggesting
NOT to do this make me reluctant to do it. Also, I would probably just
reintroduce the bugs present in the previous FLTK
That would be great, I hope someone (Albrecht?) knows the answer to this. I
also hope there won't be other problems instead...
/Andreas
I reverted the change in svn for now and I will perhaps not be able
to work on this in the next few days. It's a pity that it didn't
work, but I knew
MacArthur, Ian (SELEX GALILEO, UK) wrote:
Is there some way we could set a magic flag during the clear operation
that would be used to prevent the fix_focus stuff from being propagated,
thus ducking the problem?
I don't think so - at least it wouldn't be easy to do. Probably
too many places to
I had to change print_widget again because it failed under Windows
on sub-sub-windows, and believe the problem you handle here is now
correctly handled. I'll put that in the new branch after checking it.
Yes, I knew that. I wanted to post it later, but now you beat me to
it. I wouldn't
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1964
Version: 2.0-feature
This patch is AMAZING!!1! My touchpad/scroll buttons no longer feel
handicapped. Please add.
Link: http://www.fltk.org/str.php?L1964
Version:
manolo gouy wrote:
In our case (printing), aren't we interested only in shown()
windows?
I wouldn't say so. At least this is an unecessary restriction.
You can have all sorts of windows just created in memory, e.g.
tool windows etc., and maybe you want to print them for some
reason. OTOH,
Hi, developers,
I propose to add these two virtual methods to Fl_Widget:
[1] virtual int Fl_Widget::is_group()
[2] virtual int Fl_Widget::is_window()
Rationale: I'd like to eventually get rid of the pseudo RTTI
usage of Fl_Widget::type(), as in:
[3] if (widget-type() = FL_WINDOW) ...
Thus, I propose to add these two virtual methods and use them
where appropriate. They would also be useful for user code
and the new (work in progress) Fl_Printer support.
Fl_Widget::is_group() would be useful for traversing a widget
tree (to avoid dynamic_cast).
Opinions, better
Hello!
What shall I know in order to be able to help to the FLTK development?
As far I know basic assembly, C and C++. C and C++ - would be beginner too, I
guess!
___
fltk-dev mailing list
fltk-dev@easysw.com
Hello!
What shall I know in order to be able to help to the FLTK development?
As far I know basic assembly, C and C++. C and C++ - would be beginner too, I
guess!
Thank you!
___
fltk-dev mailing list
fltk-dev@easysw.com
On 8 Feb 2010, at 18:36, Albrecht Schlosser wrote:
However, since type() [3] is a fast inline method and the new
proposed methods are virtual, there might be a small performance
penalty if we would replace this all over in the FLTK core.
Yup - it's been a long time since I measured it, and
On 8 Feb 2010, at 19:09, Evan Laforge wrote:
But you'd still have to cast, right? To avoid casting (in the client
code at least) wouldn't you need:
virtual Fl_Group *Fl_Widget::as_group() const
Evan,
I'm not sure I understand... Fl_Group derives from Fl_Widget, so they
are the same as
On Mon, Feb 8, 2010 at 12:49 PM, imacarthur imacart...@gmail.com wrote:
On 8 Feb 2010, at 19:09, Evan Laforge wrote:
But you'd still have to cast, right? To avoid casting (in the client
code at least) wouldn't you need:
virtual Fl_Group *Fl_Widget::as_group() const
Evan,
I'm not sure I
On 8 Feb 2010, at 21:39, Evan Laforge wrote:
I'm not sure I understand... Fl_Group derives from Fl_Widget, so they
are the same as far as this is concerned... The method itself
returns int (in Albrecht's implementation) but that's in effect a
boolean... There must be something here that I am
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2310
Version: 1.3-feature
Albrecht: I have the scaling of pixmap images now working
under Mac OS X for the Fl_Printer class.
Link: http://www.fltk.org/str.php?L2310
Evan Laforge wrote:
Well, unless I'm misunderstanding, this whole thing is about evil
upcasts, right? You have a widget and you want to cast it to a group
and do group things to it.
You're absolutely right.
So currently it's:
if (w.type() == xyz) { g = (Fl_Group) w ...
If I
But I'm open for both, and if there wasn't FLTK 2 I would also
have proposed the pointer return value. Maybe we should do
what is best for the code (i.e. return the pointer) and don't
look at FLTK 2 at all. Or we could also do both...
I vote for doing the cast in the method. FLTK 2 type code
23 matches
Mail list logo
