Re: [fltk.development] [RFE] STR #2310: OS-independent API toprinting operations for MSWindows and Mac OS X
manolo gouy wrote: Albrecht: I have here a little lift to give to your morale :=) Thanks, but my morale is okay. ;-) The print demo no longer loose widgets, because I removed a clip to window that works well (and is useful) under Mac but made all these widgets disappear in the print demo page under MSWin. This is in uploaded FLTK.pdf (Make sure to update your files relatively to the changes I brought this morning to the svn). I had seen the clipping problems _after_ your removal of the window clipping from the Windows code. However, the print demo works now, and maybe there was an old file involved (the dependencies are not up-to-date, as we know). I'll update the makedepend files later today when I have more time. In fact I didn't see much difference with or w/o the Windows window clipping call. My experience was that it worked more or less, depending on if the print dialog occluded the main window or not. Thus, I thought that it had to do with some basic window clipping that came from the visibility of the main window (system clipping area ?). But I couldn't get a clue what was really happening... One more observation, though. Maybe you can compare with the Mac version: When I tried the unittests demo, I could see some red lines at the right side and the bottom in the viewport test. This looked as if the window clipping width and height were off by one pixel. I changed it to be w-1 and h-1, and the red lines disappeared. Of course, this was before you removed the clipping from the Windows code. Currently the red lines are visible at all four corners. I'm not sure if this is: (a) Windows specific (b) Fl_Printer specific (c) a general clipping question. So we definitely have a clip problem under MSWindows. I am also certain of that after having deactivated all clip statements (add x=y=-1000; w=h=4000; at the top of fl_push_clip() function) and having seen that the missing widgets of the scroll demo reappeared together, though, with many others that needed be clipped away. Yep, tried it - confirmed. I'll look in detail into this problem. Thanks very much! Many thanks for having added as_group() and as_window(). The corresponding code is so elegant in its simplicity! Yes, indeed. :-) I'll change Fl_Printer::print_widget() using these new functions. Okay, that would be fine. Could you consider adding as_gl_window() as well? This could be useful for our print objective. An Fl_Gl_Window could be detected and processed adequately, that is, with function glReadPixels that reads the screen pixels of a GL window. I considered it, and I'm hesitating. I can see that we need a way to find out what kind of window we have, but I didn't want to add one function for each kind of window: maybe we would also need as_cairo_window(), overlay, glut, ... . And I certainly wouldn't want to add one function for each _widget_ type. But that's only my current opinion, or better: /feeling/. The main point I wanted to solve was to be able to distinguish widgets, groups, and windows. These are essential points in the widget hierarchy. There are also some flags() used for window types: menu_window and tooltip_window, and there is a proposal for xclass (or something similar) to use to distinguish window types. Maybe we can find a better way to get all this together, and [ thinking ... ] perhaps the best way would be to add a [virtual?] window_type() method to Fl_Window with another byte or int internal bit field. Maybe - I don't know. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Will FLTK use more C++ features?
Hello everyone ! I have a very simple question. Do you plan to use more C++ features in the future for FLTK? Like std::string, functors, STL, etc... If you use many of C++ strengths, I am sure that the library will still be very light, and even more pleasant to use. Thanks ! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2310: OS-independent API to printing operations for MSWindows and Mac OS X
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 I believe to have sorted out the clipping problem under MSWindows. Update file src/fl_rect.cxx from the last svn for that. I tried these demos under MSWin that print well: tree, table, symbols, editor, clock, image, scroll, mandelbrot, tiled_image. Link: http://www.fltk.org/str.php?L2310 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
On 14 Feb 2010, at 11:04, Dufour wrote: I have a very simple question. Do you plan to use more C++ features in the future for FLTK? Like std::string, functors, STL, etc... This question, or some similar variant of it, comes up every now and then - so far the answer has always been; well, probably not. Historically, the issue has always been one of ensuring portability and reliability - note that many of the C++ features people ask for - e.g. std::string, STL, etc... - are not part of the language definition per se, they are part of the surrounding infrastructure around the language core, and historically they have not been as widely or consistently available cross-platform. Things get better, but are still some way short of the cross-platform consistency achieved by the C standard libraries, for example. Of course, you can use any or all of these extensions with fltk in your own code; indeed I often use STL containers for managing lists of items and widgets these days myself, though I have had issues with the differences in STL implementations between linux and win32, for example. If you use many of C++ strengths, I am sure that the library will still be very light, and even more pleasant to use. As I say, you can readily use these features yourself in your own code. When it comes down to it - where do you see them being used in fltk itself? How do you envisage those additions / changes being made without breaking the API and or ABI compatibility that we strive so hard to maintain? And lastly - FL == Fast Light. Make a little statically lined code with inline methods; make some functionally equivalent code with templates. Check the relative sizes and execution speeds... templates work, but in the majority of cases (i.e. any case where the mapping is so trivial you probably didn't need it in the first place!) they require a lot more indirection, some of which is resolved at execution time, making the code bigger and slower. A perfectly valid choice, but not what we want for FL... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] text entry
On 14 Feb 2010, at 1:18, Evan Laforge wrote: So from looking around in Fl_cocoa.mm I couldn't help but notice fltk has this whole complicated system for handling non-ascii text input that seems to be incompatible with the system provided one. That probably made sense for X which has (or had, I don't know about now) no system of its own, but it seems counter productive on OS X and windows. The result is that I know how to type in chinese on every app on my system except my own... the fltk one! Is it not the case that the whole compose key is largely independent of the proper input of non-LGC languages, though? Hmm, that question seems opaque now I read it back; I'll try and ask it again but making more sense this time... Using fltk-1.3, on linux and win32 systems, when I want to input Japanese or Chinese text, for example, I invoke the host system's IME and enter text in that. The IME then sends the composed UTF8 sequences to the foreground (fltk) window and all seems to be well. Fltk's own, historical, compose key mechanism does not seem to me to be involved (indeed I suspect that mainly handles the typing of LGC glyphs that don't appear on a your keyboard, e.g. me typing ß on a UK keyboard that has no key for it...) I am not familiar with the Apple IME, so don't know if that works - I assume that it does, though? Or are you saying that it does not? In fact, it might be nice to completely replace the text input widgets and get standard editing commands in the bargain (I'm always surprised when command-a doesn't select all). Hmm, CMD-A seems to work for me on this Mac (just tried a few simple widgets though.) Where is it failing for you? -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2310: OS-independent API to printing operations for MSWindows and Mac OS X
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 Rewrote Fl_Printer::print_widget() so it uses as_group() and as_window() to traverse the widget tree looking for subwindows. Link: http://www.fltk.org/str.php?L2310 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
[..] - note that many of the C++ features people ask for - e.g. std::string, STL, etc... - are not part of the language definition per se, they are part of the surrounding infrastructure around the language core Ian, I don't want to be adversarial, nor do I want to engage in a debate about whether or not fltk should use these features. Still, just for a little truth in advertising, please note that the above has not been true for at least 7 years. The first C++ standard, published in 1998, included just about everything people ask for (certainly strings and stl); the 2003 revision added, IIRC, namespaces and a few odds and ends. Use it or don't, but thinking that std::string isn't part of the C++ language is akin to thinking that strcmp() isn't part of the C language. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] text entry
Using fltk-1.3, on linux and win32 systems, when I want to input Japanese or Chinese text, for example, I invoke the host system's IME and enter text in that. The IME then sends the composed UTF8 sequences to the foreground (fltk) window and all seems to be well. Fltk's own, historical, compose key mechanism does not seem to me to be involved (indeed I suspect that mainly handles the typing of LGC glyphs that don't appear on a your keyboard, e.g. me typing ß on a UK keyboard that has no key for it...) Hmm, well if that's true, isn't it all redundant and can be removed right now? Even if it does provide some feature beyond the system's like the ability to type some glyphs without switching IME, no one is going to know how to use it because no other app on the system does that. I am not familiar with the Apple IME, so don't know if that works - I assume that it does, though? Or are you saying that it does not? It doesn't for me... In fact, it might be nice to completely replace the text input widgets and get standard editing commands in the bargain (I'm always surprised when command-a doesn't select all). Hmm, CMD-A seems to work for me on this Mac (just tried a few simple widgets though.) Where is it failing for you? The part where everything gets selected :) I'm on OS X 10.5.8 and I just tried with test/input on the latest 1.3. Cmd-a does nothing. Perhaps the issue with selection is the edit menu, normally cmd-a invokes a command on the edit menu, but fltk apps don't have Edit by default. I guess that's logical enough. Since mac apps all have a standardized edit menu, maybe there could be a statically defined edit menu that you could put in Fl_Sys_Menu_Bar? Zhuyin input enters the zhuyin characters but they never build into proper characters. Normally when you hit a tone mark, a choice window pops up, and after picking the right character it replaces the zhuyin cluster. Similarly, pinyin writes latin characters until you hit space, at which point you get the character choice menu. The windows IMEs are basically the same but I haven't tested them on fltk. However, on fltk the character build window never comes up, once again using test/input. You can test yourself easily enough, just go to prefs - international - input menu and enable Traditional Chinese and pinyin + zhuyin (for some reason it insists at least two be enabled), select pinyin from the input menu and then type buduispace in any app and see what happens. I tried with arabic and it seems to work normally (though I don't know the language so I'm not sure :), even the right to left part. Japanese input has the same problem as Chinese. So it looks like the input methods that do character replacement don't work. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
Of course, you can use any or all of these extensions with fltk in your own code; indeed I often use STL containers for managing lists of items and widgets these days myself, though I have had issues with the differences in STL implementations between linux and win32, for example. [...] As I say, you can readily use these features yourself in your own code. ÂCan you show me some of your work, using FLTK with some modern C++? Just so as I know how to do that. When it comes down to it - where do you see them being used in fltk itself? How do you envisage those additions / changes being made without breaking the API and or ABI compatibility that we strive so hard to maintain? I was expecting this kind of questions, and I don't really know how to answer them. However, add some things that are part of the C++ infrastructure, which should not be too hard for developpers such as you. In any case, it won't make your library Slow and Heavy ! Thanks for the answer ! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
On 14 Feb 2010, at 16:07, s...@sjssoftware.com wrote: Ian, I don't want to be adversarial, It's OK - I respect your input; I've seen plenty of stuff from you to know that you know your stuff, and value your opinions: Tell me I'm wrong and I'll believe you! Use it or don't, but thinking that std::string isn't part of the C++ language is akin to thinking that strcmp() isn't part of the C language. OK - but just for the record, I don't think that strcmp() is part of the C language. I think of it is as part of the supporting libraries. I do most of my coding in embedded environments, generally on custom hardware (though it has been a *very* long time since we created our own CPU...) and in many of those the standard libraries are not available, unless you write your own implementations of them, or port newlib or etc... Experience using C++ in those environments? Let's just say that the C libraries are simpler to port/emulate... Things are better now, but for a very long time, the actual behaviour of C++ code and the STL could be very variable depending on which target we ran it on, and that's not a good thing for portability. Doesn't inspire confidence, shall we say... Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2310: OS-independent API to printing operations for MSWindows and Mac OS X
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 I have (correctly this time I believe) changed the MSWindows version of Fl_Printer so the default origin of graphics coordinates is at top left of the printable page area, as with the Mac OS X version. Thus, Fl_printer::printable_rect(int x, int y, int w, int h) does not make much sense because it always sets x and y to 0, so I changed it to Fl_printer::printable_rect(int w, int h). This will cause you, Albrecht, some compilation errors in your test programs, but I think preferable to change the API now for the better. I have also added Fl_Printer::margins(int left, int top, int right, int bottom) that computes the margin sizes around the printable page area. Link: http://www.fltk.org/str.php?L2310 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] text entry
On 14 Feb 2010, at 18:02, Evan Laforge wrote: Fltk's own, historical, compose key mechanism does not seem to me to be involved (indeed I suspect that mainly handles the typing of LGC glyphs that don't appear on a your keyboard, e.g. me typing ß on a UK keyboard that has no key for it...) Hmm, well if that's true, isn't it all redundant and can be removed right now? I don't know. Possibly it can be, or can be made X11 specific - if we believe the OSX and win32 implementations cover what's needed. I'm thinking of the case where I might be typing something in a European language (and don't have any IME running) but need to type some glyph that's not on my keyboard, then the fltk compose stuff might come into play. But both OSX and win32 provide native compose mechanisms - e.g. on this Mac the native thing I type for ß is alt+s (and indeed that works in fltk and non-fltk apps so far as I know.) The fltk sequence would be composess, but so far as I know, that *does not* work in fltk widgets on OSX. Maybe it does? I am not familiar with the Apple IME, so don't know if that works - I assume that it does, though? Or are you saying that it does not? It doesn't for me... Hmm, OK. I think it is meant to. How do you invoke it? Maybe I'll get a chance to look. Does Manolo know how the IME hooks into the cocoa stuff, BTW? Hmm, CMD-A seems to work for me on this Mac (just tried a few simple widgets though.) Where is it failing for you? The part where everything gets selected :) I'm on OS X 10.5.8 and I just tried with test/input on the latest 1.3. Cmd-a does nothing. Oh yes - works in my test harness, but now I try the fltk test/input demo, I see it does nothing. Did this used to work? I thought it used to work... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
ÂCan you show me some of your work, using FLTK with some modern C++? Just
so as I know how to do that.
The templates belong to the modern C++, aren't ? ;-)
For example, I use them to create highlighted buttons:
templateclass T class Fl_Simple_Highlight : public T
{
public:
Fl_Simple_Highlight(int x, int y, int w, int h, const char* l=0)
:T(x,y,w,h,l)
,hover_(false)
,keep_color_(FL_WHITE)
{ }
virtual void draw() {
if (hover_ active_r())
predraw();
T::draw();
if (hover_ active_r())
postdraw();
}
virtual int handle(int event) {
switch (event) {
case FL_ENTER:
hover_ = true;
redraw();
break;
case FL_LEAVE:
hover_ = false;
redraw();
break;
}
return T::handle(event);
}
protected:
bool hover_;
Fl_Color keep_color_;
virtual void predraw() {
keep_color_ = color();
color(fl_lighter(keep_color_));
}
virtual void postdraw() {
color(keep_color_);
}
};
Fl_Simple_HighlightFl_Button *button1;
Fl_Simple_HighlightFl_Return_Button *button2;
and so on...
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] text entry
Hmm, well if that's true, isn't it all redundant and can be removed right now? I don't know. Possibly it can be, or can be made X11 specific - if we believe the OSX and win32 implementations cover what's needed. Even if by some chance the fltk input has some great feature that was awkward in the native input method... no one knows its there. But I'd be real surprised if the native input methods don't cover everything needed. I'm thinking of the case where I might be typing something in a European language (and don't have any IME running) but need to type some glyph that's not on my keyboard, then the fltk compose stuff might come into play. Well, you'd do whatever it is you do for every other app on the system. Both the mac and windows have key shortcuts that switch between input methods, and anyone who switches between input methods frequently, like myself, will have those shortcuts well memorized. If you only need the occasional European glyph, well that's why even the English IME already has dead-key and compose support. AFAIK, this stuff makes sense under X where there is no system IME and every app rolls its own. Actually, I wouldn't be surprised if there weren't some kind of system level IME thing on X too nowadays, but I don't use X enough lately to know... it's probably part of one of those desktop thingies, and fltk certainly can't be fast and light if it starts off saying first start up GNOME I am not familiar with the Apple IME, so don't know if that works - I assume that it does, though? Or are you saying that it does not? It doesn't for me... Hmm, OK. I think it is meant to. How do you invoke it? Maybe I'll get a chance to look. Does Manolo You can try the steps I outlined previously, prefs - international - etc. Hmm, CMD-A seems to work for me on this Mac (just tried a few simple widgets though.) Where is it failing for you? The part where everything gets selected :) I'm on OS X 10.5.8 and I just tried with test/input on the latest 1.3. Cmd-a does nothing. Oh yes - works in my test harness, but now I try the fltk test/input demo, I see it does nothing. Did this used to work? I thought it used to work... It doesn't work on fltk 1.1.9 either. I think we need an edit menu. Maybe you already manually added an edit menu to your app so it works for you? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
ÂCan you show me some of your work, using FLTK with some modern C++?
Just so as I know how to do that.
The templates belong to the modern C++, aren't ? ;-)
For example, I use them to create highlighted buttons:
templateclass T class Fl_Simple_Highlight : public T
{
public:
Fl_Simple_Highlight(int x, int y, int w, int h, const char* l=0)
:T(x,y,w,h,l)
,hover_(false)
,keep_color_(FL_WHITE)
{ }
virtual void draw() {
if (hover_ active_r())
predraw();
T::draw();
if (hover_ active_r())
postdraw();
}
virtual int handle(int event) {
switch (event) {
case FL_ENTER:
hover_ = true;
redraw();
break;
case FL_LEAVE:
hover_ = false;
redraw();
break;
}
return T::handle(event);
}
protected:
bool hover_;
Fl_Color keep_color_;
virtual void predraw() {
keep_color_ = color();
color(fl_lighter(keep_color_));
}
virtual void postdraw() {
color(keep_color_);
}
};
Fl_Simple_HighlightFl_Button *button1;
Fl_Simple_HighlightFl_Return_Button *button2;
and so on...
Very smart ! Thanks !
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
Dufour wrote: Hello everyone ! I have a very simple question. Do you plan to use more C++ features in the future for FLTK? Like std::string, functors, STL, etc... If you use many of C++ strengths, I am sure that the library will still be very light, and even more pleasant to use. Although I hesitate to reply on these cause it can spark long vi/emacs threads, it's always therapeutic. ;) There's been hesitance for FLTK to adopt the std library to ensure FLTK will compile on minimum platforms (embedded hardware, cell phones, etc) which often only support subsets of the advanced C++ template features. And this would prevent FLTK from building on those platforms. That's the main reason its been passed over by FLTK. That info is somewhat dated though.. it's possible many embedded platforms support std by now, but I'm not sure. I think there were more recent votes on this, I don't recall the outcome. It might be time to re-evaluate this, but IMHO nothing stops FLTK app programmers from using std libs, it's just FLTK itself internally prefers not to use it for portability. So it shouldn't really affect someone writing apps. I personally have a distaste for std, even though I use it. So everyone don't be offended if you disagree; I know I'm probably in some minority on this. My main distaste for std its unintuitive, alien syntax, and how complex its internals are, esp. since these get exposed to the app programmer through compiler errors and during debugging, due to how it's implemented mostly in #include files. For instance, while developing an application, I received the following insane error message from the compiler about a small mistake in a line that removes elements from a vector: test.cxx: In function 'int main()': test.cxx:24: error: no matching function for call to 'std::vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar ::erase(__gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char_traitschar, std::allocatorchar *, std:: vectorstd::basic_stringchar, std::char_traitschar, std::allocatorchar , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, __gnu_cxx::__normal_iteratorstd::basic_stringchar, std::char _traitschar, std::allocatorchar *, std::vectorstd::basic_stringchar, std::char_traitschar, std::allocator char , std::allocatorstd::basic_stringchar, std::char_traitschar, std::allocatorchar, std::string)' This is the longest single line error message I think I've ever scene from a C++ compiler. The only useful information in there was the problem occurred on Line 24. When I see that, I think 'this has not been gracefully integrated into the compiler', and whether its part of the language or not seems academic. I'm also not a fan of the std syntax which I find overly engineered and alien in the context of C/C++. Doing simple things is often very hard, and the syntax completely unintuitive. I don't know much about how std was developed, but it seems like too many smart people were involved, and not enough input from dumb practical people. Anything that makes me feel dumb I don't like. ;) Regardless, std is something I use in projects unrelated to FLTK, and it's hard to avoid when you need a strong string library or dynamic arrays, hashes, etc. as its ubiquitous. I've used it in FLTK apps before; you just have to use c_str() when passing in strings, or write wrapper methods to convert FLTK 'arrays of pointers' to std vectors, arrays, hashes, etc. depending on what you need. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2310: OS-independent API to printing operations for MSWindows and Mac OS X
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 Clipping: works much better now, thanks for finding this annoying bug. :-) :-) :-) test/unittests - viewport test, however, shows the off-by-one effect mentioned elsewhere (red line in the right and bottom corners). But that's perhaps a more general problem with clipping ? Margin changes: okay, no problem for me. I didn't use my own test programs for a while, and rewriting them if needed is okay. There's enough stuff with the normal FLTK demos. print_widget, using as_group() etc.: I don't think that this would work with sub-sub-windows, and it doesn't work with subwindows included in another widget (group). I didn't even know that there are subwindows in test/tabs.cxx, but printing them does funny things. They are hidden in tab #5 in both Fl_Tabs and Fl_Wizzard (left and right side) [hint: three colored rectangles]. They appear at wrong places, and they are printed even if the corresponding group is hidden (at least after it has been shown once). I don't know if this can discovered reliably, maybe with visible_r(), but then you wouldn't be able to print hidden (not show()n) windows. There are different effects, though, with svn -r 7076 and 7078, respectively. Note: if subwindows are printed, they must be handled in the same way as normal widgets, i.e. their x/y-coordinates must be taken into account. The fact that it works with the subwindows demo is a nice side effect, IMHO. And one more: unittests - rendering text looks crazy ;-P when printed. The green frames are at strange places. P.S. all tests done with r 7078 (or 7076 where noted). Link: http://www.fltk.org/str.php?L2310 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
I modern c++ features in my programs which use fltk, but I don't think fltk is actually hurt that much by not using them itself. Yes, Fl_Group could use std::vector, but that code is there and debugged and it's not too complicated to deal with the children array on your own. It could use std::string internally, but really std::string mostly saves you from malloc/free headaches but once you give them to fltk it takes ownership anyway. I think fltk internals *could* benefit from plain old non-controversial c++ features like classes and virtual methods, e.g. use Rect and Point types instead of passing masses of ints in an ad-hoc way and mysterious arrays (I'm thinking of Fl_Group::sizes_), and virtual Fl_Group::add so you can enforce invariants on children (e.g. Fl_Scroll has its own clear() but it's not virtual so it's just asking to be sliced off, and has fix_scrollbar_order sprinkled everywhere to make up for not being able to override insert(), etc. etc. And then lots of other things which are just plain engineering standards but may be more controversial, like ref params are always const. And Greg, if that's the longest error msg you've seen out of gcc then you obviously haven't been using templates much. Pull out boost, make a mistake and stand back in awe :P ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] pcnetsecur...@gmail.com Assist ência Técnica manutenção de computadores i nformatica Vitória-es 09017
Contato: pcnetsecur...@gmail.com Contato: pcnetsecurity @ gmail.com Planos a partir de R$ 250,00 . Assistência Técnica Prestamos assistência técnica nos computadores de sua empresa ou residência, e também possuímos uma equipe qualificada para fazer a manutenção no próprio local. - Contratos de Suporte e Manutenção Reduza os custos de sua empresa com solicitações de visitas técnicas para seus computadores, elaboramos um contrato de manutenção integrado para sua empresa onde disponibilizamos: técnicos, equipamentos de suporte e substituição, e atendimento no horário comercial ou plantão sob análise. - Redes Corporativas (Projetos e Instalações de Cabeamento Estruturado ou Wireless e parte Lógica em Geral) Projetamos e instalamos desde uma simples rede ponto a ponto, até uma rede de dados mais complexa e segura com compartilhamento de arquivos local e/ou remotamente, impressoras e Internet com Servidores 2003 ou 2008 Server. Disponibilizamos: TS (Terminal Server), VPN (Virtual Private Network) e FTP (File Tranfer Protocol), além de diversos serviços afins, como Backups automatizados entre outros. - Consultoria técnica em Hardware e Software Prestamos consultoria para melhorar os processos de sua empresa através da informática, otimizando assim o seu atendimento e o desenvolvimento da empresa. - Segurança. Protegemos sua empresa de vírus e invasões, o acesso aos dados dos usuários é feito de forma seletiva, ou seja, somente aqueles que tiverem permissões especiais terão essa possibilidade. Fazemos também um backup completo de todo o seu HD. Contato: pcnetsecur...@gmail.com Contato: pcnetsecurity @ gmail.com ornx*el*ilfyW?cD_$^zezkRM ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] window positions (was: Fl_cocoa.mm doesn'treport modifiers)
I'll see whether there is some missing update of the event_x_root() value in the present code. Thank for fixing this! About the doc: may be its intent is to provide a procedure that works on subwindows as well as on windows. I agree it's more intuitive to just do window-x() to get window's screen position, but this fails if window is a subwindow. Ah I see, subwindows are relative to their parent window. Well then that's easy. How about we deprecate event_x_root and implement Fl_Window::absolute_x() and absolute_y() as for (Fl_Window *w = this; w; w = w-window()) x += w-x()? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2310: OS-independent API to printing operations for MSWindows and Mac OS X
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 I added compatibility functions for Linux/X11 so that it compiles, but doesn't do anything useful (except a warning message), updated the dependencies and did some code cleanup (header files, typos). Sorry if this breaks something on Mac OS, but I am confident that it's okay. Link: http://www.fltk.org/str.php?L2310 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
