Re: [fltk.development] fltk and high res retina display?
On Fri, Apr 5, 2013 at 2:21 AM, Christophe Geuzaine cgeuza...@ulg.ac.be wrote: Adding keyNSHighResolutionCapable/keytrue/ Indeed, that did the trick! Thanks so much! I updated my make_bundle script, presumably fltk could do the same with the official one, provided there are no side-effects on non-retina systems. in the app's Info.plist makes standard FLTK widgets/fonts draw fairly well (there are some small artifacts and off-by-one line drawings here and there, but nothing major). OpenGL windows are still drawn at half-resolution, though... Yeah, I remember the Apple docs said that opengl, being pixel based, isn't quite so simple to convert to retina. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fltk and high res retina display?
I just upgraded to a newer mac laptop, and discovered that fltk apps don't render in the new highres mode. It seems like it shouldn't be too hard for text at least, but I wasn't able to find an enable high res flag after a bit of looking at https://developer.apple.com/library/mac/#documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Introduction/Introduction.html#//apple_ref/doc/uid/TP40012302-CH1-SW1 There is kWindowHighResolutionCapableAttribute but it's for Carbon. The implication seems to be that for Cocoa apps it should just work. Any of the more mac knowledgeable sorts know what's going on here, or should I keep poking through the apple docs? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
Yes, I thought about that at the time, but chose not to do it. The problem is, it is not obvious what the right answer is, for a string that has carriage returns / line feeds in it. I actually needed this feature in my app, which coincidentally, was also rendering musical symbols. I took the brute force approach: I draw each symbol (which is actually multiple glyphs composed together) on a white buffer and then see how many pixels of white border there are. There are a small number of symbols so I can easy cache the sizes. It was a real pain to implement but seems to mostly be working. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl::event_key() inconsistency between X and OS X
On Mon, Jan 28, 2013 at 11:39 PM, Peter Åstrand astr...@cendio.se wrote: Do you see any improvement if you apply the 3 latest patches from http://www.fltk.org/str.php?L2599 ? They don't apply to fltk HEAD, and it doesn't look very easy to apply by hand. Fl_cocoa.mm has seen some major changes lately that probably broke the patches. Can you update them? thanks! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl::event_key() inconsistency between X and OS X
Mac OS gives access to, in Cocoa parlance: - keyCode, the rank of the physical key that was hit; - characters, the text emitted by the key, which is the source of Fl::event_text(); - charactersIgnoringModifier, which gives the text of the key without ctrl, alt or cmd modifiers, but which (unfortunately may be, and contrarily to X11) doesn't ignore the shift modifier; Fl::event_key() could be built from the keyCode data, but then one would loose any non-US keyboard remapping: press A on a French keyboard, and get 'q' in Fl::event_key(). Fl::event_key(), therefore, is built from the charactersIgnoringModifier data, with an additional trick that removes the shift, if there is one, when the key is alphabetic, and puts a digit when a digit key is pressed, even if the unshifted key doesn't return a digit (as occurs with French keyboards). It's not possible to apply this trick to non alphabetic nor numeric keys without having FLTK know all national keyboard mappings, which is not reasonable. My view is that Fl::event_key() is to be used only to detect/process non-textual keyboard events (e.g., function keys, new-line, arrows, backward or forward delete, escape), and if not, to use Fl::event_text() that is very reliable. Yeah, my guess was also that if you have some symbol, there is no general way of knowing if it's shifted or not, and of mapping it back to its unshifted form. Short of having maps for all the keyboards you use. I previously had lots of problems with Fl::event_key(), but they were probably bugs which have since been fixed, since it seems pretty reliable now. But one issue is that it's still inconsistent WRT symbols. For instance, on my keyboard, shift-/ yields shift-?. But shift-cmd-/ yields shift-cmd-/. It's not a disaster, but it means the keyboard mappings are a bit weird (i.e. the user has to know about that quick, lest he try to map cmd-? and wonder why it doesn't work). I agree fltk can't go building in a symbol map for every single keyboard but my app can do so for the small set of keyboards that matter for it. I imagine shift-cmd-/ is just what OS X gives you, so there's not much else fltk can do, but this is the sort of fiddly detail that a cross-platform library should really try to make consistent, or at least document well if that's not possible. Maybe there's an OS API to get physical keyboard layout, since there are other cross platform programs out there that bind commands to keys. I'll dig around a little and see if there's anything obvious. For me, I still think Fl::event_key() is appropriate, because commands are bound to unshifted/shifted pairs, and even if your keyboard puts symbols in different places I'd like the pairs to remain on the same keycap. But if I'm resigned to adding my own symbol - shifted symbol mapping anyway, I can use that with Fl::event_key() to get the X11 behaviour under OS X. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fl::event_key() inconsistency between X and OS X
I recently switched back to using Fl::event_key() instead of Fl::event_text(), it seems to be much more reliable than it was before. However, there's still an inconsistency. A shifted letter yields the lowercase letter plus the shift modifier. A shifted digit also yields the digit plus shift. However, a shifted symbol (like '/') yields the shifted alternate (like '?') plus shift. This is inconsistent with the others, and probably also makes it hard to map keys consistently, since those symbol mappings vary per keyboard. Also, the X version always emits shift + unshifted keycap. So it's presumably just a bug in the OS X version. I know Manolo's been doing a lot of work in the key handling lately, so presumably it's still fresh in his mind :) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFC] a new class to support Internationalization
On Mon, Jan 28, 2013 at 1:52 PM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: I would like to get input from developers about whether a new class to support internationalization of FLTK apps could be useful. I don't have experience with i18n, but isn't gettext the usual solution here? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Testing CJK text input on Mac OS platform
On Wed, Dec 19, 2012 at 4:28 AM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: Many thanks for testing Chinese input. I have (r.9761) changed things a little bit: marked text appears now in white on blue background, so it should be easily visible. Do you agree? It is, this way is much easier to read. I still think the ideal would be an underline, since that's what all the other apps do, but this way works too. With r.9767, marked text appears underlined on Mac OS. Nice, it looks native now. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Testing CJK text input on Mac OS platform
On Mon, Dec 17, 2012 at 9:48 AM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: Many thanks for testing Chinese input. I have (r.9761) changed things a little bit: marked text appears now in white on blue background, so it should be easily visible. Do you agree? It is, this way is much easier to read. I still think the ideal would be an underline, since that's what all the other apps do, but this way works too. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Testing CJK text input on Mac OS platform
I tried it with OS X's built-in pinyin and zhuyin IMEs for Chinese, it seemed to work. My only comment is that the candidate characters show up with a dark blue background, which makes it hard to see the black text. Other OS X programs underline the candidates. And thanks very much for adding this feature, I previously thought you'd have to use the native text entry widget, which seemed like a hassle. Evidently I was wrong! On Sat, Dec 15, 2012 at 7:18 AM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: Could somebody with knowledge of Chinese, Japanese and/or Korean text input on the Mac OS platform, please, test the current svn version of FLTK 1.3 (r.9755)? The editor example program can be used for this test. Using the Mac OS help for CJK text input, I believe several text input functions are now implemented. Testing from experienced users of CJK text input is much needed, though, for I have no knowledge whatsoever of these languages and input systems. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK ANSI C API
On Sat, Oct 27, 2012 at 9:52 AM, Patrick patr...@spellingbeewinnars.org wrote: Hi Everyone I am daydreaming about writing an Ada FLTK binding or more likely part of one. GNAT. bundled with GCC. can interface with both C and C++ but there are apparently some issues with C++ likely due to namespace mangling. Accessing FLTK from vanilla C would make it easy to create bindings for many languages. I created an FLTK binding to haskell using C, but I took a different approach. Since my app has a simple GUI but complicated logic, I did the GUI in C++ and exported a small higher level interface as C. If you want a complicated GUI then this won't be satisfying because you'll wind up doing lots in C++. But if the app is complicated while the GUI is simple, then it's a lot less work to export a specialized C interface than try to bind all of fltk. Even if you still want to bind at the low level, you'll still probably want to start off by binding only the small subset that you need. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] support for scaling text?
fl_draw has some hardcoded support for rotating text, but what about scaling? Well, scaling along one axis, obviously scaling on both axes is wel supported :) I noticed that whether or not it pays attention to the transformation matrix is undefined, and on OS X at least, it doesn't. Does anyone know of the top of their head if there is some way to stretch text vertically or horizontally? A brief look at the Cocoa docs yields this page: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html It implies that the current transformation matrix applies to text too, which implies that if the fltk transformation matrix maps directly to the OS X one then this support should come for free. However, if this can't be supported on other platforms, perhaps the cocoa fl_draw explicitly disables the transformation matrix for the sake of consistency. In that case, it would be nice to have an escape hatch explicitly marked as non-portable, with perhaps a TODO to see if this can't be extended to all platforms. My understanding is that over the years X and Windows get fancier drawing systems that tends to bring them towards the OS X level of fanciness. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] support for scaling text?
However, I suspect you want something more elegant that takes advantages of the anti-aliasing inherent in proper text rendering engines... Yeah, not just anti-aliasing but actually drawing the stretched text from the outline curves. I think I'd rather see about doing this properly, thanks though. I suspect (but am not certain) that it is possible on all platforms (XFT will support a transform matrix, for example, and which I think might also allow scaling per-axis) and ISTR that the WIN32 API can too. So... the kicker may mainly be that no one has done the work? Yeah, this is sort of a cross-platform chicken and egg problem... I'd be willing to look into doing it for OS X (if Manolo doesn't beat me to the punch as usual :), but it might take me quite a while to get around to X, and I don't really have any interest in doing anything with windows. Since the chance of getting someone who simultaneously knows OS X, X, and windows and is willing to simultaneously push a feature to all of them seems rather slim, maybe there should be a system where you can implement for one platform in a way that you get a warning that it's non-portable but are still allowed to do it? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] getting usable space per screen? alsocompilation failure on OS X
Secondly, is there a portable way to find out the usable space on a screen? Fl::screen_xywh() just gives the resolution which isn't enough to create or maximize windows. In FLTK2 it returned two rectangles per screen: the actual screen and the usable space, this may have been called client area. Check the FLTK2 code and reuse it if possible. There's a new Fl::screen_work_area(), so I'm covered, thanks. I do agree that resize should do what you tell it to. I was getting weird window jumping when the window was larger than the screen (i.e. drag the window and it jumps someplace else when you release the mouse button). That's probably just a bug though. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fl_scroll not copying all channels on OS X?
For a long time I've had a bizarre bug where things that scroll slowly
change color, but only on an external monitor. I ignored it because
I'm usually not using an external monitor :P
But recently I upgraded from OS X 10.6 to 10.8 and now it's doing it
on the main monitor (macbook pro) as well, so I investigated further.
It looks like fl_scroll is changing the color as it moves. Here's an
example:
#include FL/FL_Window.H
#include FL/Fl_Box.H
#include FL/Fl.H
#include FL/fl_draw.H
#include stdio.h
class Box : public Fl_Box {
public:
Box(int x, int y, int w, int h) : Fl_Box(x, y, w, h),
scroll(0)
{}
int scroll;
void draw();
};
static void dummy_scroll_draw(void *, int, int, int, int) {}
void
Box::draw()
{
if (scroll) {
fl_scroll(x(), y(), w(), h(), 0, scroll, dummy_scroll_draw, NULL);
scroll = 0;
} else {
fl_rectf(x() + 40, y() + 40, w() - 80, h() - 80,
fl_rgb_color(0xe5, 0xe5, 0xb2));
}
}
static void
timeout(void *vp)
{
static int i;
Box *b = (Box *) vp;
i++;
if (i 30) {
printf(%d\n, i);
b-scroll = 1;
b-redraw();
Fl::repeat_timeout(.1, timeout, vp);
}
}
int
main(int argc, char **argv)
{
static Fl_Window win(0, 0, 200, 200);
static Box b(0, 0, 200, 200);
win.show();
Fl::add_timeout(.1, timeout, (void *) b);
Fl::run();
return 0;
}
On my machine this shows an orange-ish square which gradually changes
to turquoise. It's like the red channel loses a bit on each copy.
Can anyone reproduce?
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] getting usable space per screen? alsocompilation failure on OS X
On Thu, Sep 13, 2012 at 4:57 AM, MacArthur, Ian (SELEX GALILEO, UK) ian.macart...@selexgalileo.com wrote: Thirdly, I wanted to see if the behaviour had been fixed in recent versions so I did an svn update, but it looks like the build is broken, coincidentally also with a bunch of screen-related symbols: You may have a version that includes local changes or that's not up to date. Here, the current FLTK 1.3 from svn compiles without error. I wonder if the Xcode project is borked in some way though? Jenkins didn't like it yesterday when I checked but the Makefile went fine. Sorry about the false alarm, I did another svn update and it pulled in some more patches, build after that worked. So maybe there was a build in there that was broken, or maybe svn was confused or something. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] getting usable space per screen? alsocompilation failure on OS X
On Wed, Sep 12, 2012 at 2:59 PM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: So in OS X one of the screens has a 22 pixel menu bar. But due to reasons I haven't fully figured out, the maximum vertical size you can make a window before it goes off the bottom of the screen is the screen height - 44. I don't have a dock at the bottom, but if I did it would probably subtract some more pixels. This is because the window size is that of the window's usable space which does not count the window title bar that uses another 22 pixels. The Fl_Window::decorated_h() function returns the titlebar-included window height for you to use. ... Secondly, is there a portable way to find out the usable space on a screen? Fl::screen_xywh() just gives the resolution which isn't enough to create or maximize windows. Use Fl::screen_work_area() functions. Thanks, I didn't see those. I guess the fltk.org's doc is pretty out of date by now. I installed doxygen myself and built docs from HEAD, I should have been doing that all along. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] getting usable space per screen? also compilation failure on OS X
So in OS X one of the screens has a 22 pixel menu bar. But due to reasons I haven't fully figured out, the maximum vertical size you can make a window before it goes off the bottom of the screen is the screen height - 44. I don't have a dock at the bottom, but if I did it would probably subtract some more pixels. But anyway, when I create an Fl_Window apparently there's code that figures how much room is available and reduces the height as necessary. But that same code apparently doesn't apply to the resize method, since it will happily resize past the edges of the screen. It seems to make it buggy too, since it can then jump about randomly when I drag it. So firstly, Fl_Window::resize on the mac should probably clip to the screen size as it does on creation, right? Secondly, is there a portable way to find out the usable space on a screen? Fl::screen_xywh() just gives the resolution which isn't enough to create or maximize windows. Thirdly, I wanted to see if the behaviour had been fixed in recent versions so I did an svn update, but it looks like the build is broken, coincidentally also with a bunch of screen-related symbols: Compiling Fl_Native_File_Chooser_MAC.mm... Fl_cocoa.mm: In function ‘void -[FLDelegate windowDidResignKey:](FLDelegate*, objc_selector*, NSNotification*)’: Fl_cocoa.mm:1046: error: ‘class Fl_Window’ has no member named ‘fullscreen_active’ Fl_cocoa.mm: In function ‘void -[FLDelegate windowDidBecomeKey:](FLDelegate*, objc_selector*, NSNotification*)’: Fl_cocoa.mm:1057: error: ‘class Fl_Window’ has no member named ‘fullscreen_active’ Fl_cocoa.mm: At global scope: Fl_cocoa.mm:2039: error: no ‘void Fl_Window::fullscreen_x()’ member function declared in class ‘Fl_Window’ Fl_cocoa.mm: In member function ‘void Fl_Window::fullscreen_x()’: Fl_cocoa.mm:2040: error: ‘_set_fullscreen’ was not declared in this scope Fl_cocoa.mm:2045: error: ‘FL_FULLSCREEN’ was not declared in this scope Fl_cocoa.mm: At global scope: Fl_cocoa.mm:2048: error: no ‘void Fl_Window::fullscreen_off_x(int, int, int, int)’ member function declared in class ‘Fl_Window’ Fl_cocoa.mm: In member function ‘void Fl_Window::fullscreen_off_x(int, int, int, int)’: Fl_cocoa.mm:2049: error: ‘_clear_fullscreen’ was not declared in this scope Fl_cocoa.mm:2053: error: ‘FL_FULLSCREEN’ was not declared in this scope Fl_cocoa.mm: In static member function ‘static void Fl_X::make(Fl_Window*)’: Fl_cocoa.mm:2171: error: ‘class Fl_Window’ has no member named ‘fullscreen_active’ Fl_cocoa.mm: In function ‘NSImage* imageFromText(const char*, int*, int*)’: Fl_cocoa.mm:3228: error: ‘create_offscreen_with_alpha’ is not a member of ‘Fl_Quartz_Graphics_Driver’ Fl_cocoa.mm: In function ‘NSImage* defaultDragImage(int*, int*)’: Fl_cocoa.mm:3257: error: ‘create_offscreen_with_alpha’ is not a member of ‘Fl_Quartz_Graphics_Driver’ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues and general thoughts froma frustrated long time FLTK user.
On Thu, Mar 22, 2012 at 11:11 AM, Evan Laforge qdun...@gmail.com wrote: Are there people who actually really like and care about themes? I'd personally prefer just a single hardcoded one that looks nice. The problem is that 'nice' is extremely subjective. Some people *hate* gradients, others *require them*. Ditto with rounded corners, straight lines, drop shadows, the color blue, stippling and anything else you can imagine. That's why there are so many GTK themes. None of them is wildly The vast majority of people use windows or the mac, and are told like it or lump it. And they do, though it's probably mostly neither like nor lump but just not care. So the hate is a tempest in a teapot and the require is not really requirement. I know there's a cottage industry of people who crank out themes but I think they mostly do it for each other, are a tiny minority, and are probably never going to care about fltk anyway since hardly any apps use fltk. And yeah, I definitely agree nice is subjective, but I'd take that to mean the problem is unsolvable since it's just fashion and will always change. So unless you have the manpower to spend on elaborate customization engines, easiest route is to get up to usable, incorporate some reasonable things that are not about to change, like antialiasing, and call it a day. There are enough things that are not fashion and are really requirements for some people, like non-latin IME, right-to-left, etc. But of course, as an open source project, people are free to spend their time how they like. I'm just saying what I would do were I the only person working on it :) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues and generalthoughtsfroma frustrated long time FLTK user.
The benefit being any lines drawn by FLTK widgets that might use e.g. diagonal lines or draw rounded edges can benefit looks-wise via anti-aliasing. Another nice thing I expect this will allow is alpha for the various drawing primitives that accept colors. For instance, I have an app with a selection box. It has to be on top of some stuff or you wouldn't see it, but it's still important to see the things underneath. So I have a hack where I create a Fl_RGB_Image and fill it in to simulate a fl_rectf with an alpha channel. It works but was annoying to get right and is probably not very fast (and is constantly reallocating memory). ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues and generalthoughtsfroma frustrated long time FLTK user.
However, when I dig into the FLTK code to look for a place to install this permanently, I find a bizarre mess of #if defined(USE_X11) type junk. What I'd just like to mention I've also been discouraged by the ifdef thicket in the OS specific files. But Manolo was always so fast at fixing any problems that came up that I had the luxury of laziness :) I can understand how it arose, that sort of thing happens naturally once it gets started with just a few. But it sure would be nice to clean it all up. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Window::show() on multiple screens
On Tue, Oct 18, 2011 at 4:49 AM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote:
On Mon, Oct 17, 2011 at 4:58 AM, Manolo Gouy wrote:
Could you, please, try to restore a window after having added
this patch but without overriding show() ?
Excellent, seems to work!
Thanks. The new code has been committed in r.9134.
Sorry, but I think there's something wrong with this patch. Given the
following file:
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Box.H
void
make(int x, int y, int w, int h, const char *label)
{
printf(%s: wanted: %d %d\n, label, x, y);
Fl_Window *win = new Fl_Window(x, y, w, h, label);
win-show();
printf(got: %d %d\n, win-x(), win-y());
}
int
main()
{
make(2318, 22, 120, 1092, 1);
make(2920, 22, 86, 310, 2); // 1800, 854
make(2440, 22, 71, 195, 3); // 2440, 854
make(2543, 23, 374, 767, 4);
make(2200, 22, 118, 1006, 5);
Fl::run();
return 0;
}
The windows marked with comments appear at the (x, y) coordinates in
the comment, not the requested ones. This might be tricky to
reproduce because I have a 1680x1050 monitor (macbook built in) with a
1600x1200 to the right such that the tops line up. If you don't have
that setup maybe you can get a repro with different monitors? Or at
least let me know what I should check out.
I've fiddled with it a bit, but it's still a mystery to me. It's
definitely dependent on which windows are displayed, if I omit one of
the correctly placed windows, one of the incorrect ones will show up
in the requested spot. So there's presumably some persistent state
messing things up. Also it depends on the geometry of the monitors,
if I do the same on a vertically rotated external monitor, the
misplaced windows are misplaced in different place (along the X axis
instead of the Y axis, if I remember correctly). And if I go set
position() on those windows they are in the right place.
I've tracked it down to these lines in Fl_cocoa.mm:make():
crect = [[cw contentView] frame];
w-w(int(crect.size.width));
w-h(int(crect.size.height));
crect = [cw frame];
w-x(int(crect.origin.x));
w-y(int(main_screen_height - (crect.origin.y + w-h(;
The thing is, I don't understand what crect is supposed to be so I
don't understand what this is doing. I'll look at the docs for the
'frame' message, but maybe you'd understand this more quickly.
Thanks!
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Window::show() on multiple screens
On Sat, Nov 12, 2011 at 5:40 AM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: I describe here the logic flow of window creation: // this puts in the crect rectangle the desired window position and size NSRect crect; crect.origin.x = w-x(); crect.origin.y = main_screen_height - (w-y() + w-h()); crect.size.width=w-w(); crect.size.height=w-h(); crect (x, y) = (2910, 718) // this creates a window asking for a position/size through crect FLWindow *cw = [[FLWindow alloc] initWithFl_W:w contentRect:crect styleMask:winstyle]; ... // this maps the new window to the screen [cw makeKeyAndOrderFront:nil]; // this gets the actual size of the mapped window crect = [[cw contentView] frame]; // and puts the actual size in w-w() and w-h() w-w(int(crect.size.width)); w-h(int(crect.size.height)); // this gets the actual window position crect = [cw frame]; crect (x, y) = (1800, -114) // and puts the actual position in w-x() and w-y() w-x(int(crect.origin.x)); w-y(int(main_screen_height - (crect.origin.y + w-h(; The last statement above reflects the fact that cocoa uses coordinates that go upward from the main screen bottom whereas FLTK uses coordinates that go downward from the main screen top. Thanks, the comments help a lot. So one thing that strikes me as suspicious is that you are converting coordinates by subtracting main_screen_height. But if the window is on a different screen won't that be incorrect? It seems like any reference in fltk to a main screen is likely to be misguided, since as far as I can tell main screen just determines where the menu bar is, and that's not fltk's responsibility. Did you try and add a poition() call in your make() function after the show() statement ? What happens ? The positions are correct, but only while the other monitor is plugged in. When it's removed, they're all bunched up on the right, whereas if I had listened to the window manager they would still be bunched but at least fully on the screen. If I add back my original workaround at the start of the thread, all the positioning as correct (in the right place with the external monitor, and placed according to the WM when it's not plugged in). ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Window::show() on multiple screens
On Mon, Oct 17, 2011 at 4:58 AM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: Could you, please, try to restore a window after having added this patch but without overriding show() ? Excellent, seems to work! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fl_Window::show() on multiple screens
So I noticed that when I save windows on the non-primary screen, quit
and restore, they wind up on the primary screen. It looks like on OS
X, show() will move the window back on to the primary screen. So I
overrode show:
void
BlockViewWindow::show()
{
IRect requested = rect(this);
Fl_Double_Window::show();
if (rect(this) != requested) {
IRect screen;
Fl::screen_xywh(screen.x, screen.y, screen.w, screen.h,
requested.x, requested.y);
if (screen.contains(IPoint(requested.x, requested.y)))
this-position(requested.x, requested.y);
}
}
The idea is that if the screen the window wants to be on exists, then
move it again where it wanted to go. Otherwise, let it stay where the
OS put it. This works ok but does lead to an annoying flicker since I
have to wait until after show() to move the window.
I poked into Fl_cocoa.mm and the key function seems to be
Fl_X::make(). There's some fiddling with FORCE_POSITION, but I don't
think this is quite what I want. I think it should appear where
requested if that's on a screen that exists, and otherwise pick some
reasonable spot on the main screen.
Does this seem like reasonable behaviour for the default show?
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3.1 release planning
I see that libXrandr depends on libX11, libXext, libXrender, and libc and that libXft depends on all of these and others. Thus, I conclude that using libXrandr does not require additional libraries on the platform besides itself. Is that correct ? I think so - but the key here (as it is for XFT too, of course) is that is it is on your system at build time, the binary will expect to be able to load it (XFT | XRandR) at runtime, and of course this may not be true if you run on a different machine. I think what Matthias was suggesting is that we might be bale to test for XRandR at runtime and load it where it is available, and use it, but if it is not available, then we fall back to the existing behaviour on X11 systems instead. Isn't the usual thing to define HAS_XRANDR or something and #ifdef the the bits that depend on it? Not that I'm a fan of yet more ifdef, but it seems simpler than some dynamic loading malarkey. I like fltk for its bias toward static linking! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3.1 release planning
On Sat, Oct 1, 2011 at 4:02 PM, Evan Laforge qdun...@gmail.com wrote: I see that libXrandr depends on libX11, libXext, libXrender, and libc and that libXft depends on all of these and others. Thus, I conclude that using libXrandr does not require additional libraries on the platform besides itself. Is that correct ? I think so - but the key here (as it is for XFT too, of course) is that is it is on your system at build time, the binary will expect to be able to load it (XFT | XRandR) at runtime, and of course this may not be true if you run on a different machine. I think what Matthias was suggesting is that we might be bale to test for XRandR at runtime and load it where it is available, and use it, but if it is not available, then we fall back to the existing behaviour on X11 systems instead. Isn't the usual thing to define HAS_XRANDR or something and #ifdef the the bits that depend on it? Not that I'm a fan of yet more ifdef, but it seems simpler than some dynamic loading malarkey. I like fltk for its bias toward static linking! Oh sorry, I understand now what you mean. You can disregard the above :) I guess if it means a statically linked xrandr using fltk program would then fail on X11 without xrandr, with no option to compile a version that works on both, then yeah that would be unfortunate. I guess some dynamic testing of X's installed extensions would be in order. But surely that's nothing new for X extensions, right? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK3: Status
Mmm, it probably could by replacing popen() with pipe()'s and fork()/exec(), with select() to watch the stdout/err pipe, and trapping keystrokes yourself and sending them to the stdin pipe. Tricky though. I'd do it myself, but this week is nuts for me schedule wise. Don't you need a pty for that? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Changing the Color to AARRGGBB
Creating its own type for color is ok with a typedef, but changing it from an
underlying uint32 wold be insanely inefficient, considering that a color vaue
is needed in every graphics call.
typedef doesn't actually create a new type. A real type should be
just as efficient as a number, and C++ was specifically designed to
support this:
class Color {
private:
uint32 val;
public:
uint32 argb() const { return val; } // to pass to other libraries, OS, etc.
... // methods that apply to colors, not numbers
}
As far as I can tell, there are no cons, and plenty of pros.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Changing the Color to AARRGGBB
Generally I feel that a typedef is sufficient. It does not prevent misuse, but it makes the function prototypes clear. It also means that the user can type 0xaarrggbb directly into the code and it works. Qt is really annoying that I always have to look up the converter function. I disagree. I use Color, Point, Rect, etc. types extensively and they're so much more pleasant to work with that I convert to and from the low level fltk (x, y, w, h) stuff at the boundaries and use them exclusively in my code. The benefit is even greater with complex types like Rect which have canonical forms, invariants, etc. I wouldn't want to type a hex value directly in the code and have it implicitly converted into a color, I like the clarity of e.g. Color.rgb(uchar, uchar, uchar) and Color.rgb(double, double, double), Color.rgba(...), or even 'c2 = Color.rgb(..); c2 = c1.a(0.5)'. When I print them out for debugging, I would rather see 'Color.rgb(1, 2, 3)' than some giant decimal number, and the benefit is multiplied when printing out complex types with color components. And of course the convenience of c.brightness(1.2) or c.is_opaque() or whatever else. Trading all that and type safety for the ability to use hex literals seems like, well, not a very good trade. And it's not even a trade, you can get the hex literal to color conversion and back by adding a implicit conversion constructors, but there's a reason those are pretty much universally discouraged: they have all the implicit conversion disadvantages of a typedef. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Changing the Color to AARRGGBB
I think g++ can be convinced to make the object 4 bytes in size and
allocated on 4 byte boundaries but I am unsure about others.
In general I agree it would be better to use a structure, so using your
idea is good as long as we have proof that an array of them can be made
equivalent to an ARGB image array.
Ah, I was (optimistically) assuming that 'struct { t v; }' is
guaranteed to have the same runtime representation as 't v'. But if
this is not the case, then I concede that for efficiency's sake an
untyped representation is necessary.
I think if it were my own code I would treat the packed form as its
own type and extract Colors with various methods. Now that I think of
it, there's something to be said for this: on systems that take this
approach with strings, the library is free to experiment with utf8,
utf16, or 32 bit internal representations for efficiency while the
calling code deals only with unicode code points. Users of 'char *',
however, are faced with a lot of bother when changing encodings---as
some people on this list have personal experience with :)
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] multilingual not fully work fltk
Pango's api pretty much takes entire blocks of text and a box to put them into. It would replace a very high level drawing api in fltk. The OS/X and Windows systems should be rewritten to call their api at this same high level. On the subject, I think we eventually need the same thing for input too. IME is complicated and support needs to come from the OS, or specialized libraries. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Changing the Color to AARRGGBB
On Sat, Aug 20, 2011 at 7:41 PM, Bill Spitzak spit...@verizon.net wrote: For 3.0 (and probably 2.0 as well) I think it is very important that the FLTK color unsigned value be changed so that it is 0xAARRGGBB, instead of the 0xRRGGBBAA used in FLTK2.0 (and in 1.3?). It would be nicer if it were a real type instead of a number. Of course it makes sense to store it internally in whatever format other libraries use for efficient conversion, but this should be an internal matter, to enable an efficient 'uint32 to_argb()' method. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk3 build issue
I see Ben's already answered in favour of exceptions, but I have to say that (at least for the core library) I'm not in favour. (Though, like the STL, I have no problem with using it in user-code, of course.) The usual thing for C++ exceptions is that they're only for exceptional circumstances, which generally means your application is crashing. So constructors should throw when they can't make a valid object, asserts should throw when you violated a precondition, etc. It's a coding error, and the exception gives you a nice error message, traceback, and chance to shut down nicely and destructors to be called. So it's not really about trying to clean up mistakes after the fact. There's just not much a library can do if you passed an index out of bounds, but it's nicer to print a trace and quit rather than segfault. But then from that point of view, it's maybe not a big inconvenience to omit exceptions and use a fatal error callback that logs and quits. Most destructors don't need to be called if the program is quitting anyway. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk3 build issue
On Tue, Aug 9, 2011 at 10:50 AM, Michael Sweet m...@easysw.com wrote: On Aug 9, 2011, at 1:26 AM, Evan Laforge wrote: ... So it's not really about trying to clean up mistakes after the fact. There's just not much a library can do if you passed an index out of bounds, but it's nicer to print a trace and quit rather than segfault. This amounts to the same thing - an uncaught exception will cause a crash, in many cases without any visible logging. Again, I'm -1 on using exceptions in FLTK. In my experience what you said isn't true. On my system (g++ and OS X), an uncaught exception means a nice error message and an exit, in all cases. But as I mentioned, I have no problem with not using exceptions since a simple log and exit callback can serve the same purpose almost as well. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] rotated text
FYI, FLTK 1.3 already has the capability of drawing rotated text in fl_draw(int angle, ...) for normal text drawing (w/o transformation matrix). Maybe this can help you too. Does test/rotated_text work on OS X? IMHO it ought to, but I can't test it right now. You're totally right, and I missed that function. The problem is that I got accustomed to using 1.1.9 documentation since doxygen wanted to install a millian dependencies first, and at the time there was no downloadable doc for 1.3. But there is now, so thanks to whoever did that :) I'm happy now that I can rotate text, but it's a nicer api to use the existing transformation framework than rather have ad-hoc parameters to specific drawing functions. But that's a bit of a bigger task probably, though I guess it wouldn't be so bad to support just the rotation part until someone felt a need to implement other things like stretching and shearing. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Announcing 1.3 ?
On Fri, Jun 17, 2011 at 5:29 AM, Matthias Melcher m...@matthiasm.com wrote: I remember that we used to announce new versions in several places. I just don't remember which ones. Ha, it's clearly been too long since a release :) But that said, congratulations are in order. As a user, I'm glad you guys have been pushing out the fixes and improvements, especially Manolo with all the OS X work. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2662: Docs for Drawing ThingsInFLTK should cover coordinate space of widgets vs. windows
On Tue, Jun 14, 2011 at 11:34 PM, Bill Spitzak spit...@verizon.net wrote: A lot of it was due to Forms compatibility, as it did it this way. There was an attempt to fix this in fltk2. Fix it, as in use global coordinates? Though I've been bitten by this local coordinates thing, Greg's explanation made some sense to me. It would be a hassle to update every widget whenever the window was dragged. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2662: Docs for Drawing Things In FLTK should cover coordinate space of widgets vs. windows
..we probably need to go into some details in the Drawing Things in FLTK section about how the coordinate space works for widgets vs. windows. Speaking of which, why is it that way in the first place? It's a source of bugs, and then special casing to fix the bugs, for me. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fl::event_text() omitted for keyups?
Some keys recently stopped working in my app and I tracked it down to
what I believe is a new bug. This is OS X with the latest svn fltk
1.3.
When a modifier is down, Fl::event_text() no longer emits anything.
In fact it appears key ups no longer put anything in event_text() at
all. The following program should reproduce it. I believe that
previously keyup the letter (capital if shift is held), but now it
doesn't.
#include FL/FL_Window.H
#include FL/Fl_Box.H
#include FL/Fl.H
class Box : public Fl_Box {
public:
Box(int x, int y, int w, int h) : Fl_Box(x, y, w, h) {}
int handle(int evt) {
if (evt == FL_KEYDOWN) {
printf(keydown, text: %s, key: %c\n, Fl::event_text(),
Fl::event_key());
} else if (evt == FL_KEYUP) {
printf(keyup, text: %s, key: %c\n, Fl::event_text(),
Fl::event_key());
}
}
};
int
main(int argc, char **argv)
{
Fl_Window win(0, 0, 200, 200);
Box b(0, 0, 200, 200);
win.show();
Fl::run();
return 0;
}
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl::event_text() omitted for keyups?
On Fri, Jun 3, 2011 at 2:14 AM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: Some keys recently stopped working in my app and I tracked it down to what I believe is a new bug. This is OS X with the latest svn fltk 1.3. When a modifier is down, Fl::event_text() no longer emits anything. In fact it appears key ups no longer put anything in event_text() at all. The following program should reproduce it. I believe that previously keyup the letter (capital if shift is held), but now it doesn't. Should be fixed with r.8773. Can you confirm, please? Looks good to me. Thanks! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Aaaaaarrrarrrr. Was: 1.3.0RC6 coming on Tuesday
But I already *know* that no matter how long I wait until the RC, I will not get a bug report. As soon as the RC is out, within a day, the patches will start flying in. So I wonder: either this is just bad luck and the bread always falls on the side with the jam on it, or you guy were called in by my worst enemy to drive me insane ;-). But what shall we do? Change the release policy? Make RC6 final and push 1.3.1 out a few weeks form now? Make an RC7? Now? In two weeks? I really don't know. Please suggest... . It's just a fact of life that most people will wait until a release to do their testing, and that's when the bugs will start coming in. In fact, isn't that the point of an RC? It's enough a release to get people to think a release is imminent and they should really test their stuff, but not such a release that their are announcements and major version bumps and ABI freezes and all the other stuff that gets awkward when bugs suddenly show up. So I say it's just the RCs doing their job, and go ahead and put out RC7 (either now or in a week), until the bug reports settle. Then 1.3 comes out and you can bet a bunch of new bug reports will suddenly come in then. So I think this is pretty normal, maintain your sanity and keep up the good work :) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Binding and operator precedence
I wouldn't put parens on a * b + c because I have that bit of
precedence memorized. I guess I have the comparison operators
memorized in the same way because mixing them doesn't bother me. At
some point we have to expect people have the rules internalized, yes?
It's a little beside the point, but often checking so many variables
at once is sometimes a sign that the design could be improved. For
instance, for 'x a a = y' type stuff I usually use a Range
object (and I can be sure I'm consistently half-open). In the
num_screens case, it's changed now, but there was some weird stuff
where if screen==0 the dimensions are from Fl::x() etc. and if it's 0
then it's from the screens array.
So I'd say, don't worry about the parens, but fix the underlying
problem f you can :)
On Fri, May 27, 2011 at 3:55 AM, Albrecht Schlosser
ajs856s...@go4more.de wrote:
On 27.05.2011 10:43, MacArthur, Ian (SELEX GALILEO, UK) wrote:
As I was reviewing the recent commits, I was looking at this line of
code:
+ if (num_screens 0 n= 0 n num_screens screens) {
[...]
It's not just me - recent versions of gcc whine on about this too!
Really? I can only remember having seen gcc warnings if you combine
'' and '||' (where '' takes precedence over '||' anyway, and
we fixed all *these* warnings already).
Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Binding and operator precedence
I think Ian's remembering this thread: http://www.mail-archive.com/fltk-dev@easysw.com/msg05736.html ..the main issue being a line like this, which the compiler warned us to add parens: char al = (scrollbar.align()FL_ALIGN_LEFT!=0); Yeah, the precedence of the bit operators is a pretty famous C wart, and the compiler is right to warn about it. I think I've even read (K | R) acknowledging it was a mistake and saying it had to do with some legacy BCPL thing or something. Of course c++ had no choice, but even some languages that don't need source compatibility have followed in C's footsteps. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2583: inconsistent alphabehaviour for fl_draw_image()
Wouldn't it just be add transparency to fl_draw_image() on all platforms? I'm not the one who wants to draw transparent images, just rectangles, so I haven't really followed that bug, and I've never used fl_draw_image(). As long as Fl_RGB_Image::draw continues to support alpha then I'm happy, but then again the only reason I'm using that is a hack to get around the lack of transparency for fl_rectf :) I would have thought fl_draw_image was the primitive that Fl_RGB_Image just called, but looking at the source, apparently not so. On the subject of fl_rectf transparency, would it be reasonable to have them pay attention to an alpha byte in Fl_Color? I imagine OS X support would be pretty easy since it supports alpha stuff natively, and I guess modern windowses too. Not sure about X. On Sat, Apr 23, 2011 at 1:42 PM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: Agreed. Could you, please, post this RFE yourself specifying what image format support would be necessary beyond RGBA ? I would then close STR #2583. I think it would be less confusing to close this ticket as bug fixed and create another for the new feature request. But in any case, as long as we're on this topic, I added my own feature request for alpha for the shape functions. [STR New] Link: http://www.fltk.org/str.php?L2583 Version: 1.3-feature Fix Version: 1.3-feature Reclassified as an RFE because the initial Mac OS inconsistency has been fixed, as noted by the OP. The enhancement would be to add transparency support to the fl_draw_image() function on all platforms. Link: http://www.fltk.org/str.php?L2583 Version: 1.3-feature Fix Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] accurately tracking kbd state
Previously my app was keeping track of keys down by simply recording keydowns and keyups. The advantage of this over Fl::event_state() is that I can treat any key as a modifier, map ControlL separately from ControlR, and it's simpler to not have the separate Modifier type (FL_SHIFT, etc.) and treat all keys equally (yes I know kbd drivers tend to not be able to track every key like a modifier, but the OS X kbd at least does pretty well). However, I had a problem with stuck keys, because holding a key and then unfocusing the app (say cmd-tab on OS X) will give a keydown but no keyup. So I decided that separate ControlL and ControlR is not worth that much and checking Fl::event_state() every time would be less error prone. Unfortunately, there's still a bit of a problem: FL_FOCUS on OS X apparently doesn't update Fl::event_state(). So from the focus until the first keydown, event_state() is telling me that the modifier is still held. Another problem is that I used to use keeping track of all keydowns to determine when a keydown is a repeat. I can still do that by continuing to keep a keydown map, and I *think* this is reliable when used only for detecting repeats. But isn't this something fltk could tell more reliably than I could? So I think the failure to update event_state() on FOCUS is probably just a bug and would be easily enough fixed. But the wider question is, is there a way to accurately track kbd state for all keys? Either I would have to have some way of getting a guarantee that every keydown gets a corresponding keyup (but to do this correctly might require the OS to send an event when it's just not designed to do that), or there could be some way of getting a bitmap of the entire kbd state. This would require fltk to do what I can't, namely keep track of kbd state accurately, but maybe it would be in a better position, since it could ask the OS for a refresh on all keys whenever the app got focus. Reliable handling of kbd state seems like a basic feature to me that all apps would want to have, so what's the right way to do it? I think I'm unusual in that I want to handle my own modifiers at a low level where many apps are satisfied with built-in ways to bind certain mod+letter combos, but it's hardly a totally crazy things to want to do. Games, for instance, would want to track multiple key downs accurately. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] bogus FL_NUM_LOCK on OS X
On Fri, Apr 29, 2011 at 2:21 PM, Evan Laforge qdun...@gmail.com wrote: Here's another one I just found: When arrow keys are pressed on my macbook, Fl::event_state() claims numlock is down. This happens with the current HEAD. I think I got this one. Simply delete this line from Fl_cocoa.mm:/mods_to_e_state: if ( mods NSNumericPadKeyMask ) state |= FL_NUM_LOCK; The documentation at http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSEvent_Class/Reference/Reference.html says that NSNumericPadKeyMask indicates that the key is on the numeric keypad, *not* that NumLock is down. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2609: shape functions (fl_rectf etc.) support alpha
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2609 Version: 1.3-feature It would be nice if fl_rectf and friends could accept and RGBA color and draw a transparent shape. I have emulated this by creating an Fl_RGB_Image and setting the alpha on all pixels, but it's ugly and inefficient. This is complementary to STR 2583, which is for image level alpha support. Link: http://www.fltk.org/str.php?L2609 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2583: inconsistent alpha behaviour for fl_draw_image()
I think it would be less confusing to close this ticket as bug fixed and create another for the new feature request. But in any case, as long as we're on this topic, I added my own feature request for alpha for the shape functions. On Sun, Apr 17, 2011 at 3:27 PM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2583 Version: 1.3-feature Fix Version: 1.3-feature Reclassified as an RFE because the initial Mac OS inconsistency has been fixed, as noted by the OP. The enhancement would be to add transparency support to the fl_draw_image() function on all platforms. Link: http://www.fltk.org/str.php?L2583 Version: 1.3-feature Fix Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] recent Fl.cxx change bus errors on OS X
Recently a line was added to Fl::focus(): #ifdef __APPLE__ if (fl_xfocus != win) Fl_X::i(win)-set_key_window(); #endif Unfortunately this bus errors for me since Fl_X::i(win) is NULL. It's all a bunch of single letter undocumented variable names in there, but I gather this gets the system specific window pointer. I can't easily tell who is supposed to set it because it's a single letter variable name, but maybe it has something to do with the window for the widget not being shown yet when I call focus on it? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] spurious FL_FOCUS
Hmm, that's interesting. I saw the same when I added the destructor, and I was really surprised. I checked out another fltk svn working copy to try it with a clean install, but meanwhile I did on the old working copy something like: make distclean rm -rf autom4* ./configure make Yeah, good call, that got it. I had remade my project from scratch but forgot to clean out the fltk directory. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fl_eventnames (was: Re: spurious FL_FOCUS)
BTW: I wonder whether your show_key() function would work for UTF-8
characters?
Well, it wouldn't, but this is 'int Fl::event_key()', which doesn't
return UTF-8 anyway. The doc says it returns a 'keycode', but doesn't
really define what that is. When I type on a zhuyin keymap, I get the
qwerty keys, and when I use the OS X character pallette apparently
event_key() doesn't understand it at all... I get a FL_KEYDOWN and
FL_KEYUP, but the event_key retains the previous value.
I've gotten sort of random stuff out of event_key(), it can give some
confusing results on OS X when the keyboard has been remapped.
Interestingly, when I switch from zhuyin back to latin, I get this msg
from the OS:
2011-03-25 20:57:08.464 flbug[72227:903] Warning - conversion from 64
bit to 32 bit integral value requested within NSPortCoder, but the 64
bit value 9223372036854775807 cannot be represented by a 32 bit value
I modified it to include Fl::event_text(), and utf8 for that part
seems to work fine:
const char *
show_event_info(int ev)
{
static char buf[1024];
switch (ev) {
case FL_PUSH: case FL_DRAG: case FL_RELEASE: case FL_MOVE:
case FL_MOUSEWHEEL:
snprintf(buf, sizeof buf, (%d, %d), Fl::event_x(), Fl::event_y());
break;
case FL_KEYDOWN: case FL_KEYUP:
// Don't bother with Fl::event_length() because 'buf' isn't returned
// with an explicit length.
snprintf(buf, sizeof buf, %s (\%s\),
show_key(Fl::event_key()), Fl::event_text());
break;
default:
return unknown;
break;
}
return buf;
}
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] spurious FL_FOCUS
On Thu, Mar 24, 2011 at 6:28 AM, Manolo Gouy manolo.g...@univ-lyon1.fr wrote: Evan: Please, apply r. 8530 and let me know if the focus of your app now behaves correctly with the Cocoa version. Looks like it does! And I can remove my FL_SHOW - FL_FOCUS hack too. Thanks! However, it looks like Albrecht's change 8529 causse my app to bus error. All it does is add a virtual destructor, but even after a complete make clean and recompile, I get bus error with it, and no bus error without it. In fact, it reliably makes *all* fltk programs linked against it bus error on my machine. Not sure why. The only nonstandard thing I'm doing is compiling with -m32 (64 bit is default on snow leopard). Anyone else see this? I'll do some more poking in the meanwhile. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fl_eventnames (was: Re: spurious FL_FOCUS)
#include FL/names.H
:
class YourWindow : public Fl_Window {
:
int handle(int e) {
fprintf(stderr,WINDOW %s: EVENT=%s\n, label(), fl_eventnames[e]);
return(Fl_Window::handle(e));
}
:
BTW, fl_eventnames appears to be undefined. I see it in commented-out
debug prints, but can't find a definition anywhere.
I actually have a small utility library that has a 'const char
*show_event(int evt);' function that's basically the same, only safer,
since it won't segfault on a bad input. Since it's obviously a useful
function, how about adding it to the Fl namespace or something?
Here's mine:
const char *
show_event(int ev)
{
const char *e = unknown;
switch (ev) {
case FL_NO_EVENT: e = nothing; break;
case FL_PUSH: e = push; break;
case FL_DRAG: e = drag; break;
case FL_RELEASE: e = release; break;
case FL_MOVE: e = move; break;
case FL_MOUSEWHEEL: e = mousewheel; break;
case FL_ENTER: e = enter; break;
case FL_LEAVE: e = leave; break;
case FL_FOCUS: e = focus; break;
case FL_UNFOCUS: e = unfocus; break;
case FL_KEYDOWN: e = keydown; break;
case FL_KEYUP: e = keyup; break;
case FL_SHORTCUT: e = shortcut; break;
case FL_DEACTIVATE: e = deactivate; break;
case FL_ACTIVATE: e = activate; break;
case FL_HIDE: e = hide; break;
case FL_SHOW: e = show; break;
}
return e;
}
In fact, here are some more bonus ones:
const char *
show_key(int key)
{
static char buf[32];
if (isprint(key))
sprintf(buf, '%c', key);
else if (isprint(key FL_KP_Last key - FL_KP))
sprintf(buf, kp-%c, key - FL_KP);
else if (isprint(FL_F = key key FL_F_Last))
sprintf(buf, fn-%d, key - FL_F);
else {
const char *e = unknown;
#define K(KEY, STR) case FL_##KEY: e = #STR; break
switch (key) {
K(Escape, escape);
K(BackSpace, backspace);
K(Tab, tab);
K(Enter, enter);
K(Print, print);
K(Scroll_Lock, scroll_lock);
K(Pause, pause);
K(Insert, insert);
K(Home, home);
K(Page_Up, page_up);
K(Delete, delete);
K(End, end);
K(Page_Down, page_down);
K(Left, left);
K(Right, right);
K(Down, down);
K(Shift_L, shift_l);
K(Shift_R, shift_r);
K(Control_L, control_l);
K(Control_R, control_r);
K(Caps_Lock, caps_lock);
K(Alt_L, alt_l);
K(Alt_R, alt_r);
K(Meta_L, meta_l);
K(Meta_R, meta_r);
K(Menu, menu);
K(Num_Lock, num_lock);
K(KP_Enter, kp_enter);
#undef K
}
return e;
}
return buf;
}
const char *
show_event_info(int ev)
{
static char buf[1024];
switch (ev) {
case FL_PUSH: case FL_DRAG: case FL_RELEASE: case FL_MOVE:
case FL_MOUSEWHEEL:
snprintf(buf, sizeof buf, (%d, %d), Fl::event_x(), Fl::event_y());
break;
case FL_KEYDOWN: case FL_KEYUP:
return show_key(Fl::event_key());
break;
default:
return unknown;
break;
}
return buf;
}
const char *
show_damage(uchar d)
{
static char buf[1024];
memset(buf, '\0', sizeof buf);
if (d FL_DAMAGE_ALL)
strcat(buf, all, );
if (d FL_DAMAGE_CHILD)
strcat(buf, child, );
if (d FL_DAMAGE_EXPOSE)
strcat(buf, expose, );
if (d FL_DAMAGE_SCROLL)
strcat(buf, scroll, );
if (d FL_DAMAGE_OVERLAY)
strcat(buf, overlay, );
if (d FL_DAMAGE_USER1)
strcat(buf, user1, );
if (d FL_DAMAGE_USER2)
strcat(buf, user2, );
sprintf(buf+strlen(buf), (%d), d);
buf[strlen(buf)] = '\0';
return buf;
}
const char *
show_widget(const Fl_Widget *w)
{
static char buf[127];
IRect r = rect(*w);
snprintf(buf, sizeof buf, (%d %d %d %d) %s \%s\ '%s',
r.x, r.y, r.w, r.h,
typeid(*w).name(), w-label(), show_damage(w-damage()));
return buf;
}
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fl_eventnames (was: Re: spurious FL_FOCUS)
On Thu, Mar 24, 2011 at 7:39 PM, Greg Ercolano e...@seriss.com wrote:
Evan Laforge wrote:
#include FL/names.H
BTW, fl_eventnames appears to be undefined. I see it in commented-out
debug prints, but can't find a definition anywhere.
It's in the FL/names.h file. When you include it, that
variable becomes a global.
(in my previous post, the .H should be .h)
Oh, I see it, I missed it because I did grep *.H.
Here's mine:
We should probably add some of those 'bonus' ones you've made.
Go for it. I don't have commit, but I'm happy to declare all the code
under the fltk license. Here's another thing that's been handy:
// RAII style clipping
struct ClipArea {
ClipArea(IRect r) { fl_push_clip(r.x, r.y, r.w, r.h); }
~ClipArea() { fl_pop_clip(); }
};
I use Rect and Point types instead of fltk's separated integers, but
that's irrelevant to the main idea.
The nice thing about putting these in the include file is they
don't affect code size (doesn't bloat the library), and only takes
up space if you include them in your app. (kinda like xpms)
I hadn't thought of that. I'm personally happy to trade a few K for
safety, but I know some people use fltk in low memory situations. If
we stick 'inline' on the functions or put them entirely into the
header, will it have the same effect?
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] spurious FL_FOCUS
On Wed, Mar 23, 2011 at 10:13 AM, Greg Ercolano e...@seriss.com wrote: Greg Ercolano wrote: Evan Laforge wrote: Any other input out there? I wanna see your handle() code. Indeed, the first thing I did was as you suggest, and replace the handle with a printf and return Fl_Window::handle(evt). However, when I try to repro with the simplest possible version, I can see the no initial focus problem, but not the ignores Fl::focus() problem. That makes some sense because the real question about the latter is why Fl::focus() is called with a window, which it's evidently not expecting. So I'll poke around with that some. Actually, looks like there might be something up with OSX + svn current with regards to FL_FOCUS. I suggest keeping an eye on this bug: http://www.fltk.org/str.php?L2594 Indeed. If we can agree that Fl::focus(window) should set focus to the window, then I can attach a simple patch to fix that. I'll find out why it's getting called with the window, but in any case I think it should work when given one. For problem #1, if Manolo says his patch (send FL_FOCUS after FL_SHOW) is fixing it, then I'd like to give his patch a try. Like I said, it didn't work for me but I didn't investigate further so I could have been making a dumb mistake. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] spurious FL_FOCUS
On Wed, Mar 23, 2011 at 12:50 PM, Greg Ercolano e...@seriss.com wrote: Evan Laforge wrote: I suggest keeping an eye on this bug: http://www.fltk.org/str.php?L2594 Indeed. If we can agree that Fl::focus(window) should set focus to the window, then I can attach a simple patch to fix that. I figure you should work with manolo on this one; he's been handling the Cocoa port, so he'll want to weigh in on patches. FL::focus() is in Fl.cxx, so it's shared for all platforms. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] spurious FL_FOCUS
When I create a new window, it gets an FL_SHOW, as expected. When I click in the new window, a mouse down and mouse up are sent to the new window, and then after the mouse up, FL_FOCUS is sent to the *old* window. Every click on the new window yields a focus on the old window (which according to the OS, doesn't have focus at all). If I type a key, the event goes to the new window as expected, and the spurious FL_FOCUS stops happening and clicks are normal. I can reproduce this easily. It might be specific to my app, but at the moment I'm thinking it's not. I'm investigating further, but does this sound familiar to anyone else? OS X 10.6.6, current svn version of fltk. Also, a while back I would get capslock keydowns occasionally when giving focus to the app. I haven't seen those for a while now though, so maybe they were fixed. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] spurious FL_FOCUS
On Tue, Mar 22, 2011 at 6:35 PM, Evan Laforge qdun...@gmail.com wrote: When I create a new window, it gets an FL_SHOW, as expected. When I click in the new window, a mouse down and mouse up are sent to the new window, and then after the mouse up, FL_FOCUS is sent to the *old* window. Every click on the new window yields a focus on the old window (which according to the OS, doesn't have focus at all). If I type a key, the event goes to the new window as expected, and the spurious FL_FOCUS stops happening and clicks are normal. I can reproduce this easily. It might be specific to my app, but at the moment I'm thinking it's not. I'm investigating further, but does this sound familiar to anyone else? OS X 10.6.6, current svn version of fltk. Ok, after poring over the code for a few hours I think I have a better handle on this. First of all, FL_FOCUS is not sent when a new window is created. FL_SHOW is sent, and I had a hack to work around that by registering a focus when it saw a show, because of course the newly created window *is* focused. At least it is in OS X. So problem 1 was that fltk doesn't know a new window has focus even though the OS thinks it does. Problem 2 was that when I click on it, it doesn't receive focus from the click. Then fl_fix_focus comes through, notices that the window in fl_xfocus doesn't seem to contain focus, and sends it a FL_FOCUS... since fl_xfocus is the old unfocused window, it's sending a FL_FOCUS to the unfocused not-clicked-on window. The reason fl_xfocus is wrong is that firstly window creation didn't update it, and then the Fl::focus(new_window) triggered by the click doesn't update it. That's because Fl::focus() does this thing where it walks up to the window of the widget by calling parent() until it returns null, and then sets fl_xfocus to that. But it starts off with a window(), so if the widget is already a window it skips the whole thing. So, I feel like there are two problems here. Firstly, I think Fl_X::make() should probably be giving the newly created window focus, i.e. setting fl_xfocus and maybe focus_ too, since the OS already is. I think it should emit a FL_FOCUS as well. I tried to do this in one go by sticking a handle(FL_FOCUS) after the handle(FL_SHOW) in Fl_cocoa.mm's Fl_X::make(), but it didn't actually set the focus, and I didn't investigate further. Probably something like that is the right thing to do though. Secondly, if I'm reading this correctly, Fl::focus(window) never works because the loop doesn't expect the passed object to already be a toplevel window. I think that's an easy patch, simply fix that bit of logic in there. But this focus stuff is a real rats maze, and I'm not confident I'm seeing everything, or that I'm not missing something about how focus is supposed to work. It's full of these undocumented global variables like focus_ and fl_xfocus. Any other input out there? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3.0 RC 3 released!
I think when the release goes out there should be a warning about Fl_Text_Display slowness. After all, it means that any app that uses it for more than 50 lines or so is effectively no longer portable to OS X (yes, it really is that slow... it wedges for about 5s to sequentially add 50 lines, and scrolling is already too slow to use). Of course, pre-1.3 no fltk app is portable at all to 10.6 so it's a definite improvement as far as 10.6 goes, but a warning might save some hypothetical new users some head scratching when their app beach-balls on OS X. On the other hand, since I'm developing on 10.6 now, my motivation to help out with a fix or workaround is increasing all the time :) I just checked for the STR and can't find it any more. And on further experimentation, the slowness only seems to happen when wrap_mode is turned on. test/editor is fast because it doesn't do that, if you uncomment the line where it turns on wrap_mode, it becomes slow, even using a fixed-width font. Also, the wrapping is still a little wrong, though test/editor doesn't demonstrate this, so it must be related to something else. In addition, when using proportional fonts and dragging a selection, the text to the right of the selection will jump around a few pixels whenever the selection changes. It looks like the letter at the end of the selection is getting chopped off a little. This is also visible in test/editor if you use '//' to turn on the proportional font. I thought I made a STR for these things, but I don't see it anymore. Should I add one? Or one STR for each issue? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3.0 RC 3 released!
On Wed, Jan 19, 2011 at 9:59 AM, Greg Ercolano e...@seriss.com wrote: Evan Laforge wrote: I thought I made a STR for these things, but I don't see it anymore. Should I add one? Or one STR for each issue? Just regarding this: I went to http://fltk.org/str.php and searched for elaforge and found only these items: Hm, maybe I didn't add a STR back then after all. Ok, I'm going to add STRs for slowness, incorrect wrapping, and text wobble, along with an example program that demonstrates it. I'll add them for 1.3, since they are after all serious bugs, but if consensus is push them up to 1.4 so 1.3 has a chance of coming out then that's ok too. PS, I love the doc for Fl_Text_Display::wrapped_column :) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_X not exported on mac in 1.3
I voted for hiding as well, and Manolo did it recently for X11, but now I found out that we *have* some documentation for Fl_X in the chapter Operating System Issues, section Using a Subclass of Fl_Window for Special X Stuff. This is X11 only, and I guess only hardcore X11 developers can understand and use all of it ;-) So, what to do now? Revert? Rewrite/remove this documentation chapter? What about those who used this information in their programs? Document the workaround (define FL_LIBRARY) and note that such code will likely not be portable to future versions of FLTK. As far as I know, this is the way to do OS specific things, like get a handle on the underlying window and call OS functions, right? In that case it should be kept. I'm not sure that we need to put a lot of work into saving people from themselves, I think clear documentation on it saying that its whole point is to be system specific and it may change between fltk versions is good enough. But if people are afraid of accidentally using it (as I did), then this and other system specific things can be hidden by default, unless FLTK_EXPOSE_INTERNALS is defined. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_X not exported on mac in 1.3
I don't see the Fl_X class documented in Doxygen. Am I wrong ?
I think you're right, I don't see it either. I'm not sure where I got
the idea to use it. It seems less likely to make portability if it's
consistently not exported for all OSes, but if it's not documented
then I suppose you can blame only yourself if you use it.
You can write:
int has_windows() { return Fl::first_window() != NULL; }
Ah, this is better, thanks.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fl_X not exported on mac in 1.3
I just updated to the head of 1.3, and my app failed to compile,
complaining that Fl_X was undefined. Looking at FL/mac.H, it looks
like it's intentionally hidden when compiling against an application.
Hiding system specific stuff seems like a good idea, but it looks like
this is inconsistent with X11 and win32. And if Fl_X is meant to be
hidden, documentation should be removed for it, and there should be
some alternate way to write:
int has_windows() { return Fl_X::first != NULL; }
Otherwise, hiding Fl_X for the mac is probably an oversight and should be fixed.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3.x : level of UTF-8 support?
In each case, the environment pops up a little input window for the input to go into, and it then gets passed to the app. This sort of worked OK, though the pop-up is maybe meant to be modal for the window receiving the input and I'm not sure that worked right on my ubuntu trials. Also the pop-up window seemed to have the wrong decorations and I couldn't figure out where it was meant to be placed - it popped up in what seemed to me to be the wrong place. I can confirm this. I remember that I tested the Windows IME support when I fixed a bug (but Windows (XP) only). I remember that the IME popup window appeared at the right place (as I expected) in normal Fl_Input widgets, but not in multiline input widgets (they appeared at the wrong line or character offset). I tested with Japanese characters, and all seemed to work well (as far as someone who can't even read Japanese can tell ;-) ). Interesting! The candidate window must exist at a lower level than the input widget. I can confirm that in OS X the IME does *not* work. BTW, the other motivation for me to want to use the native text widget for OS X is that the fltk 1.3 one is too slow, and wraps incorrectly. There's a STR for this, but no one (including myself) seems eager to get into the text display code, so I figured trying a native widget could kill two birds with one stone. The second one is actually the main showstopper for me so when it's time to start hacking fltk I'll likely start because of that reason, rather than the IME reason. Of course simply fixing the text display to not be slow is also a perfectly reasonable approach, but it wouldn't solve the IME problem. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.3.x : level of UTF-8 support?
What level of character support do you require from FLTK in the future? 1. plain ASCII only, so UTF-8 support needed 2. ASCII plus Western accented characters 3. simple left-to-right character sets (Greek, Cyrillic...) 4. simple right-to-left character sets (Arabic, Hebrew...) 5. complex character sets (Chinese, Japanese, Korean...) I use fltk 1.3 to display Chinese and other unicode symbols, it works just fine. I don't think the issue is display, since once you can display some unicode characters you can display them all. The issue is input. CJK require complicated IMEs that plug in at the OS level (for windows and OS X at least, I'm not sure what X does). I know that for Arabic you have to pick combining form, and for many Indian systems you need to pick combining forms and vowel symbols, so they also require non-trivial IME support. I guess there is also character composition that happens at render time, but since the OS X version of fltk 1.3 just calls the OS renderer, all that stuff is taken care of. So I believe the only plausible way to support input is to hook into the OS level IME. Ideally there would be something as simple as an OS-specific get_glyph function, but of course this is complicated by the fact that the IMEs want to display candidate characters. Also in the Windows and OS X worlds, they expect you to be using the OS default widget library and may not bother to provide lower level hooks. So I believe the most practical solution is likely to be using the native text entry widget in the same way we use the native file chooser. For X, I imagine there are probably a few libraries to choose from, so you just pick the main one and then integrate that. Since this is a complicated and possibly contentious kind of change, and maybe not even required by the active developers quite yet, I suggest to forget about input for 1.3. Make sure all internal functions expect utf8 strings first, as Matthias suggests. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] automated indenting tool
On Mon, Apr 5, 2010 at 7:35 PM, none @easysw.com wrote: Greg Ercolano schrieb: The reason not to redefine tabs are that tabs are 8 in every conceivable context except editors where they are changed. there is no need to redefine tabs as they are not needed to replace spaces! So no other medium will show those files correctly unless their tabstops are all changed too. thats wrong! all files are rendered correct independent from actual tab display width Only with a sufficiently loose definition of correct :) If you wrap to 80 columns with 2 space tabs but I look at the file with 8 space tabs, it won't be 80 columns anymore. This isn't theoretical, it happens all the time and it's annoying. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] automated indenting tool
I don't think rejecting tabs is a good idea, as there should really be no problem if people use spaces or tabs or both as long as they're used 'correctly'. The only time a problem comes up is when editors are set to have tab stops set to odd things. But people do do that, all the time. There are a lot of problems that are theoretically non-problems if everyone would just configure the same, but people don't do that. Since you mentioned python, python standards reject mixed tabs and spaces. There's even a compiler flag to make them into errors. I have ts=8 in vim but get annoyed at them anyway because they make cursor movement unpredictable. When there are no benefits (I can't think of any at least...) to mixing tabs with spaces, and when it's so easy to configure editors to insert spaces, why do it? ___ 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 Mon, Feb 15, 2010 at 5:38 AM, Albrecht Schlosser ajs856s...@go4more.de wrote: Evan Laforge wrote: 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_), Yes, really good point, and Fl_Group::sizes_ is a very good example. This could be a class/struct that contains 2 fix Rect members for the group itself and the resizable, resp., and an array of Rect's for the children. This would probably make the code much easier to read and to understand. BTW.: Fltk 2 uses fltk::Rectangle internally. Interesting, I'll take a look. The first thing I did when starting with fltk was write my own Rect and Point classes (actually templates with typedefs, though I only use the int version of rect and the int and bool versions of Point). I'd be happy to either contribute those or backport the fltk 2 version. Presumably they should be called Fl_Rect etc. since we're not using namespaces. Two big points that I would like to address in the near future: (1) an alternate version of Fl_Scroll that doesn't need the scrollbars in its children() array. This would also make fix_scrollbar_order() obsolete. Ideally this would be API compatible with the old version, so that code that accounts for the 2 more children doesn't break. I'm thinking of an alternate constructor or Fl_Scroll::compatibility(int), or so... Ideas welcome. In the worst(?) case we would use another widget name. Yes, absolutely. I have a SimpleScroll widget that *only* provides scrolling because of just that reason, it provides only 'Point offset()' and 'set_offset(Point)'. I don't think it needs to be compatible with Fl_Scroll though, it's messy to have no-op scrollbar methods on it. SimpleScroll is not yet suitable for contribution because it doesn't actually use fl_scroll (I do most of my scrolling at a different level), but unless someone already has a better candidate, I'd be happy to add that and contribute it. Then presumably Fl_Scroll could inherit from Fl_SimpleScroll and add only the scrollbar stuff. (2) all sorts of Fl_Group's child modification methods (add, remove, insert, clear, etc.) should be virtual... I would document insert and remove as the ones you should override, and implement the others in terms of those primitives. That way those who want an invariant only have to override those two. Though seeing how important clear() performance is to some people, I suppose that would have to be added to the primitives too since repeated remove()s would be too slow. So when is the appropriate time to do these things? 1.3 introduces so much great stuff I feel like we should concentrate on getting it out as quickly as possible. On the other hand, merely adding new classes or adding a 'virtual' keyword won't destabilize existing ones so it seems unlikely to affect release time. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] To FLTK-1.3.0 and beyond
On Mon, Feb 15, 2010 at 11:54 AM, Duncan Gibson duncan.gib...@xs4all.nl wrote: Printing, precisely, is an item of the FLTK 1.3 roadmap! If I understand the dates in the RFE correctly, it's a new item. And that's my point. In the meantime all of the older STRs are just sitting there stopping 1.3.0 from being released, and have been since the initial discussions and push for 1.3.0 back in 2008. By this do you mean everything that turns up on http://fltk.org/str.php?L+P4+S-2+C0+E0+Qversion:1.3 ? I don't see anything about utf8 there. The src has a TODO.utf8, but the referenced google doc is mostly placeholder put stuff here and the ones in the file are different and not very clear, and look rather old. Following some of them manually reveals some are RFEs and some are closed. Maybe everything considered necessary for a 1.3 release could be changed to CRIT so a version:1.3 CRIT search will turn them up? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_cocoa.mm doesn't report modifiers
Evan: I tried your patch. With it the sudoku demo no longer
executes shortcuts of the system menu bar. So I won't commit it.
I retain the idea of removing unused variables. Thanks.
Is the FL_KEYUP event for cmd-keys really important ?
Oh right, yes this would bypass the system menu. I forgot that some
apps actually use it :)
I'll modify the patch to continue to emit key equivalents but also
emit the key ups for command just like the other modifiers.
Yes, keyup is important. I track key state myself because I do key
chording. When keyup is suppressed it looks like that key is down
forever. It's true I don't do chords with command down, but inserting
that as a special case would be uglier than simply making the library
consistent.
Since I assume you already applied removing wRect I omit that part:
Index: Fl_cocoa.mm
===
--- Fl_cocoa.mm (revision 7075)
+++ Fl_cocoa.mm (working copy)
@@ -1391,6 +1391,30 @@
}
@end
+...@interface FLApplication : NSApplication
+{
+}
+- (void)sendEvent:(NSEvent *)theEvent;
+...@end
+
+...@implementation FLApplication
+// The default sendEvent turns key downs into performKeyEquivalent when
+// modifiers are down, but swallows the key up if the modifiers include
+// command. This one makes all modifiers consistent by always sending key ups.
+// FLView treats performKeyEquivalent to keyDown, but performKeyEquivalent is
+// still needed for the system menu.
+- (void)sendEvent:(NSEvent *)theEvent
+{
+ NSEventType type = [theEvent type];
+ NSWindow *key = [self keyWindow];
+ if (key type == NSKeyUp) {
+[key sendEvent:theEvent];
+ } else {
+[super sendEvent:theEvent];
+ }
+}
+...@end
+
static FLDelegate *mydelegate;
void fl_open_display() {
@@ -1398,7 +1422,7 @@
if ( !beenHereDoneThat ) {
beenHereDoneThat = 1;
-[NSApplication sharedApplication];
+[FLApplication sharedApplication];
NSAutoreleasePool *localPool;
localPool = [[NSAutoreleasePool alloc] init];
mydelegate = [[FLDelegate alloc] init];
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] text entry
I removed about 90% of the X11 specific FLTK keyboard handling in Carbon a while ago. Assuming that the Cocoa version builds on it, we should still be letting OS X handle a lot of the keyboard input. I type a lot of German on my US keyboard and getting Umlauts works as it does on all OS X native apps (Alt-u, vowel). It looks like the remaining keyboard code in Fl_cocoa.mm is compose stuff. From what Manolo says, this is because we can't use the native functionality without either adding a lot of hair to Fl_Input or simply swapping it out for a native input widget. So in the short term it looks like fltk gets by with its own implementation, because using the OS one is too much work. Entering Chinese with a character palette is not really practical, it would be much easier to just write in another app and then paste it into the fltk text input. This works but isn't ideal, so in the medium to long term, it would be nice to use the native input widget, which would also provide a usable Fl_Text_Display. Maybe a 1.4 thing. My own app can put off chinese input for a while, perhaps forever, so I won't be motivated to look into it seriously for a while yet. ___ 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] 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?
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
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] Fl_cocoa.mm doesn't report modifiers
On Thu, Jan 21, 2010 at 6:19 PM, Evan Laforge qdun...@gmail.com wrote:
This patch should repair this bug.
Please, let me know if it does/doesn't.
Thanks for helping debug FLTK-1.3-cocoa
Yes, indeed it does. Thanks!
I spoke too soon, command+key doesn't send the keyup. After some
digging around it has to do with some apparently undocumented and
mysterious behaviour wrt NSApplication sending key equivalents. We
don't need any of that since we already have our own mysterious and
hard to disable key equivalent system (don't get me started on that).
Here's a patch against the current version. I cut out a bit of unused
code while I was at it:
Index: Fl_cocoa.mm
===
--- Fl_cocoa.mm (revision 7075)
+++ Fl_cocoa.mm (working copy)
@@ -1391,6 +1391,31 @@
}
@end
+...@interface FLApplication : NSApplication
+{
+}
+- (void)sendEvent:(NSEvent *)theEvent;
+...@end
+
+...@implementation FLApplication
+// The default sendEvent swallows key ups when command is down. This one
+// bypasses all that key equivalent stuff and sends the event directly to the
+// key window.
+//
+// For some reason commancd-esc is still sent as a performKeyEquivalent, so
+// FLView still needs to override performKeyEquivalent to act like keyDown.
+- (void)sendEvent:(NSEvent *)theEvent
+{
+ NSEventType type = [theEvent type];
+ NSWindow *key = [self keyWindow];
+ if (key (type == NSKeyDown || type == NSKeyUp || type ==
NSFlagsChanged)) {
+[key sendEvent: theEvent];
+ } else {
+[super sendEvent:theEvent];
+ }
+}
+...@end
+
static FLDelegate *mydelegate;
void fl_open_display() {
@@ -1398,7 +1423,7 @@
if ( !beenHereDoneThat ) {
beenHereDoneThat = 1;
-[NSApplication sharedApplication];
+[FLApplication sharedApplication];
NSAutoreleasePool *localPool;
localPool = [[NSAutoreleasePool alloc] init];
mydelegate = [[FLDelegate alloc] init];
@@ -2012,12 +2037,6 @@
while (w-parent()) w = w-window(); // todo: this code does
not make any sense! (w!=w??)
}
-Rect wRect;
-wRect.top= w-y();
-wRect.left = w-x();
-wRect.bottom = w-y() + w-h(); if (wRect.bottom=wRect.top)
wRect.bottom = wRect.top+1;
-wRect.right = w-x() + w-w(); if (wRect.right=wRect.left)
wRect.right = wRect.left+1;
-
const char *name = w-label();
Fl_X* x = new Fl_X;
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] text entry
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! I haven't looked into exactly what would be involved to do this, but how about tearing out the whole compose key system for non-X (well, OS X at the moment) and replacing it with the system supplied one? Has it been considered and abandoned because of technical difficulties? Simply historical baggage and not tried because of lack of time? Some philosophical or design objections? 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). This may be much trickier to integrate, I don't know yet. An increased use of native widgets is certainly a change of direction for fltk, but as I see it using native widgets when available is fast and light because it completely removes code. It's probably not compatible with all the custom box drawing stuff and themes but that's another thing I personally wouldn't mind completely removing... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_cocoa.mm doesn't report modifiers
On Wed, Feb 10, 2010 at 12:40 AM, MacArthur, Ian (SELEX GALILEO, UK) ian.macart...@selexgalileo.com wrote: Unfortunately, I still can't switch to 1.3 entirely because of the Fl_Text_Display problems (text misplaced and too slow). That one has hard to fix written all over it. Ideas welcome... I imagine there must be a native OS X text widget that does line wrapping and text styles. One of these weeks I'll take look into what would be necessary to use that. Unfortunately Fl_Text_Display and Fl_Text_Buffer seem like rather large APIs to try to reproduce in entirety, so this may just be a solution for my specific needs and not a general one. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [SUMMARY] Re: RFC: FLTK 1.3 Fl_Widget::is_group() and Fl_Widget::is_window()
One more short request: could you put in comments explaining why these particular bits of dynamic type info are needed? E.g. group because xyz important function needs to do generic traversal of Fl_Widgets, and window because xyz important function needs to treat windows specially. RTTI is out because overhead / embedded platform compilers don't support it / whatever. That way future readers won't wonder why these particular two types and not my favorite type? And subclassers can know when it's appropriate to override. I remember wondering that about the type() magic. Thanks! On Wed, Feb 10, 2010 at 8:25 AM, Albrecht Schlosser ajs856s...@go4more.de wrote: Albrecht Schlosser wrote: 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() ... and the winner is: virtual Fl_Group *Fl_Widget::as_group() const; virtual Fl_Window *Fl_Widget::as_window() const; The majority voted for the pointer return value and the renamed versions with as_ instead of is_. If nobody objects within the next one or two days I'll commit this into svn probably on Friday (after the snapshot) or the coming weekend. Thanks to all for opinions and comments! Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_cocoa.mm doesn't report modifiers
Is this a Fl_Text_Display problem when displaying plain ascii, or is it related to using UTF-8, as in http://www.fltk.org/str.php?L2158 ? Yes - I think that STR is part of it (and I think, but am not certain) that the proposed fix is correct. However, Evan's other problem is that the OSX text rendering is slow now under 1.3 because of other changes to implement UTF8. This is all plain ascii, but I'm sure the utf8 changes are the root cause. Spacing is also messed up on color changes, which maybe has to do with the changed kerning rules or something. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_cocoa.mm doesn't report modifiers
Sorry about the delay! Evan: the patches for the two cocoa-FLTK-1.3 bugs you reported (missing FL_KEYBOARD event when hitting a modifier key, incorrect 1-pixel width clipping) are now in the svn. Could you, please, see if your app(s) is (are) now correctly and fully supported by cocoa-FLTK-1.3 ? I finally compiled against the latest 1.3 from svn and every seems to be working well. In addition, the window movement problem I reported seems to be fixed as well. It actually emits resizes at regular intervals and on mouse up, not on every pixel as my 1.1 patch did. I actually prefer your way because it puts less spam in the logs and I don't need to track the window as its moving, I just want the final position, but if this behaviour is intentional you should probably mention it in the docs. Unfortunately, I still can't switch to 1.3 entirely because of the Fl_Text_Display problems (text misplaced and too slow). It's a separate app though so I can probably just keep linking that one against 1.1, but they link to some of the same object files so it's not totally trivial. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] window positions (was: Fl_cocoa.mm doesn't report modifiers)
On Tue, Feb 9, 2010 at 4:13 PM, Evan Laforge qdun...@gmail.com wrote:
seems to be fixed as well. It actually emits resizes at regular
intervals and on mouse up, not on every pixel as my 1.1 patch did. I
actually prefer your way because it puts less spam in the logs and I
don't need to track the window as its moving, I just want the final
position, but if this behaviour is intentional you should probably
mention it in the docs.
Actually, I spoke too soon, window position is still not quite right.
Apparently when the window manager modifies the position I requested,
Fl_Window::x() still reports the x I requested, not the real one.
event_x_root() - event_x() is just totally wrong (it reports 0, and
then in resize lags behind the real position):
#include stdio.h
#include FL/Fl.H
#include FL/Fl_Double_Window.H
class Win : public Fl_Double_Window {
public:
Win(int x, int y, int w, int h) : Fl_Double_Window(x, y, w, h) {
printf(init %d %d\n, x, y);
printf(init by root: %d %d\n,
Fl::event_x_root() - Fl::event_x(),
Fl::event_y_root() - Fl::event_y());
printf(x y %d %d\n, this-x(), this-y());
}
void resize(int x, int y, int w, int h) {
Fl_Double_Window::resize(x, y, w, h);
printf(resize %d %d\n, x, y);
printf(by root %d %d\n,
Fl::event_x_root() - Fl::event_x(),
Fl::event_y_root() - Fl::event_y());
printf(x y %d %d\n, this-x(), this-y());
}
};
int
main(int argc, char **argv)
{
Win win(0, 0, 200, 200);
win.show(argc, argv);
Fl::run();
return 0;
}
OS X doesn't like 0, 0, it adjusts x to 4 for I don't know why, and
adjusts y to 44 to avoid the menu bar. Based on my understanding, the
sets of numbers should be the same.
As an aside, does anyone else think event_x_root() - event_x() is a
particularly non-intuitive way to get a window's position? It took me
a while to find it, and then when I found it, took me a while to
believe it, and now whenever I see it I think wait, what does the
window's position have to do with the current event? *which* window is
this the position of?
In fact, Fl_Window::x() seems to work fine and I'm not sure why I used
event_x_root(), perhaps it was the documentation which says: To find
the absolute position of an Fl_Window on the screen, use the
difference between event_x_root(),event_y_root() and
event_x(),event_y().
So I guess it's two bug reports:
- bad advice in Fl::event_x_root() doc
- Fl_Window::x() incorrect when the system modifies the passed sizes
OS X 10.5.8, fltk 1.3, as usual.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: FLTK 1.3 Fl_Widget::is_group() and Fl_Widget::is_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 proposals, votes please ... 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 ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: FLTK 1.3 Fl_Widget::is_group() and Fl_Widget::is_window()
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 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 missing; where do
we need to cast?
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. So currently it's:
if (w.type() == xyz) { g = (Fl_Group) w ...
If I understand the proposal, that would make
if (w.is_group()) { g = (Fl_Group) w ...
So why not put the cast in the method:
if (Fl_Group *g = w.as_group()) { ...
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: FLTK 1.3 Fl_Widget::is_group() andFl_Widget::is_window()
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 that uses the pointer in a boolean context won't notice that it's not an int. And this way there's one less thing to remember and do manually and maybe get wrong (granted it's not hard to remember that is_group means you cast to Fl_Group, but why have it if you can avoid it?). Having both seems redundant. As an aside, is there an official reason to use int instead of bool? I notice fltk prefers int. is_ in the function name is clear enough, but bool is still better documentation. Oh, also why I suggested as_group is because there's a common convention that is_ is for a predicate, but that's not universal. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk 1.3: Fl_Text_Display text misaligned, word wrapping slow - Transient Font Matching?
WRT transient font matching: whatever CoreText does, it gets the same effect, I think. All I know is that when I have an English font selected and switch to a Chinese IME and it picks a Chinese font for me, and there's somehow an association an italic looking English font will pick an italic looking Chinese font. I've actually been a little curious about how that happens. OS X widgets know that their version of fl_width is slow and optimize for that by caching and minimizing re-rendering. Fl_Text_Editor simply re-renders the whole text... . Ah, this explanation makes sense to me. So it seems like there are a couple options. One is to do the caching, add a memoizing wrapper around fl_width so the app can control the cache (and put a note on fl_width saying it may be slow), then modify the various text displays to use it. Maybe Fl_Text_Display is the only one that renders enough text to need it. Another is try to replace Fl_Text_Display on OS X with a native widget. Presumably there is an OS provided styled text entry that already does all this stuff. I guess it depends on how convenient it is to integrate with fltk idea of a style map or fltk event handling. But provided it gives a pretty low level way to integrate then this would be the best option. Otherwise if it's going to be a nightmare of hackery and inconsistency then it would be better to stick to pure fltk. Also, caching in fltk may make sense if windows and linux are expected to follow suit and get fancier with their text rendering. Certainly that seems more likely than them getting simpler and faster. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_cocoa.mm doesn't report modifiers
Fl_cocoa.mm is presently a single file just as Fl_mac.cxx, and they have comparable sizes. Yes, they're both huge. Maybe it's just me, but that size is larger than comfortable for navigation and makes even static scope very wide. In any case, it sounds like the mac files are undergoing a lot of active work at the moment. I'll wait until things have settled down and bring up reorganization at that point. I think it's probably pretty safe to make 1.3 OS X only. Do you mean cocoa only ? FLTK is already OS X only (as opposed to OS 9). Ah, in that case once the cocoa stuff is settled down and gone through a version, Fl_mac.cxx can simply be removed. Of course a version for fltk means 5 to 10 years... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fl_push_clip buggy under cocoa?
Wow, that was fast. Or your working time is opposite to mine :) Yes, it seems this fixes the problem, thanks! The mixed tabs and spaces and various trailing spaces throughout these files make it easy for patches to fail. I see the patch mostly replaces the -1 with -0.9 (in 6 separate places... wow). Did you figure out what is going on with clipping on OS X or is this from experimentation? Are the other hunks e.g. in MACbitmapFromRectOfWindow related? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_cocoa.mm doesn't report modifiers
This patch should repair this bug. Please, let me know if it does/doesn't. Thanks for helping debug FLTK-1.3-cocoa Yes, indeed it does. Thanks! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fl_push_clip buggy under cocoa?
I've just been upgrading my app to fltk 1.3 with cocoa... great work, and thanks for doing this! That said, I was getting messed up drawing, and I traced it to the following code: DEBUG(BEFORE draw_area); fl_push_clip(draw_area.x, draw_area.y, draw_area.w, draw_area.h); fl_clip_box(0, 0, , , draw_area.x, draw_area.y, draw_area.w, draw_area.h); DEBUG(AFTER draw_area); The result is that the width and height come out one pixel less than they went in. I also had a problem where draw_area.h == 0 wasn't clipping at all. So I checked out Fl_cocoa.mm:MacRectRegionIntersect and it looks like CGRectIntersection is indeed chopping off the width and height. I'm suspicious that fltk's idea of a rectangle is inclusive of the right and bottom edge, while OS X's idea is exclusive. The OS X doc I could find didn't say one way or the other. Also, the next line: if (!CGRectIsEmpty(test)) outr-rects[j++] = test; Why ignore an empty rect? If I want to push a disjoint or zero sized clip, I would expect everything to be clipped out. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fl_push_clip buggy under cocoa?
Could you, please, post a simple code example that displays
the problem ? This would be very helpful.
Also, specify whether you are on snow leopard or not, because
there are small peculiarities of snow leopard on this topic.
Sure, code is at the bottom. This is all on 10.5.8.
Now, when compiled on 1.1.9, this shows a rect with a one pixel red
line, a rect with a two pixel red line, and the third rect is not
drawn at all. It prints:
clip rect: 10 10 x 1 20
clip rect: 10 50 x 2 20
So that all makes sense. When compiled on fltk-1.3.x-r7008, the first
rect has no red line (so a clip of width 1 is mistaken as a complete
clip), the second has two pixels (so that's correct), and the third
rect isn't clipped, and shows up (so a clip of width 0 does nothing).
And it prints:
clip rect: 0 0 x 0 0
clip rect: 10 50 x 1 19
So it looks like for some reason OS X clip functions are clipping one
pixel *wider* than the given rect, so fltk subtracts 1 to compensate.
Except OS X doesn't add 1 to 0, so when you pass 1, fltk makes it zero
and OS X goes ahead and clips it all... even though CGRectIsEmpty is
false for this zero width rect. Then if you pass 0, it becomes -1,
which is finally considered empty, and so MacRectRegionIntersect
ignores it entirely.
And... fltk doesn't add 1 back on when it returns it from fl_clip_box,
so using this to add a new clip successively shaves off pixels.
As far as the solution, I haven't looked into that much yet, I don't
really know anything about OS X graphics programming. Obviously the
best thing would be to figure out what's up with this +1 behaviour and
turn it off. The docs for CGContextClipToRects [1] says only that
The locations and dimensions of the rectangles are specified in the
user space coordinate system. I don't know what user space
coordinate systems are on OS X, but maybe there's something wrong
there. Otherwise, we can add specific hacks for ==0, ==1, and 1, but
I wouldn't have a lot of trust that it will continue to work without
understanding the underlying cause.
BTW, fl_rect.cxx:fl_push_clip is a real mess of #ifdefs. In fact the
whole file is like that. Isn't the idea to separate platform specific
files? If I made a patch that separated it out, at the cost of some
code duplication, would it be accepted? And this stuff about
__APPLE_QUARTZ__ and __APPLE_COCOA__ overlapping is confusing,
shouldn't they be exclusive?
Also, on a similar subject, wouldn't it be better to conditionally
compile Fl_cocoa.mm and fl_color_mac.cxx etc. from the build system
rather than using #include? It's confusing.
Also also while I'm in a cleanup mood... how about someday removing
reference output params like fl_clip_box? Ref args should be const,
output args should be pointers. Adding a new function and deprecating
the old one is ok too, as long as we eventually get rid of deprecated
stuff (fl_clip() is still around...).
[1]
http://developer.apple.com/mac/library/DOCUMENTATION/GraphicsImaging/Reference/CGContext/Reference/reference.html#//apple_ref/c/func/CGContextClipToRects
#include stdio.h
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Box.H
#include FL/fl_draw.H
struct Rect {
Rect(int x, int y, int w, int h) : x(x), y(y), w(w), h(h) {}
int x, y, w, h;
};
static void
print_clip()
{
Rect r(0, 0, 0, 0);
fl_clip_box(0, 0, , , r.x, r.y, r.w, r.h);
printf(clip rect: %d %d x %d %d\n, r.x, r.y, r.w, r.h);
}
class Box : public Fl_Box {
public:
Box(int x, int y, int w, int h) : Fl_Box(x, y, w, h) {
box(FL_THIN_DOWN_BOX);
color(FL_WHITE);
}
void draw() {
Fl_Box::draw();
fl_push_clip(0, 0, w(), h());
fl_color(FL_BLACK);
fl_rectf(10, 10, 50, 20);
fl_push_clip(10, 10, 1, 20);
print_clip();
fl_color(FL_RED);
fl_rectf(0, 0, 30, 100);
fl_pop_clip();
fl_color(FL_BLACK);
fl_rectf(10, 50, 50, 20);
fl_push_clip(10, 50, 2, 20);
print_clip();
fl_color(FL_RED);
fl_rectf(0, 50, 30, 100);
fl_pop_clip();
fl_push_clip(10, 100, 0, 20);
fl_rectf(10, 100, 50, 20);
fl_pop_clip();
fl_pop_clip();
}
};
int
main(int argc, char **argv)
{
Fl_Double_Window win(100, 100, 200, 200);
Box box(0, 0, 200, 200);
win.show(argc, argv);
Fl::run();
return 0;
}
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fl_push_clip buggy under cocoa?
there. Otherwise, we can add specific hacks for ==0, ==1, and 1, but
I wouldn't have a lot of trust that it will continue to work without
understanding the underlying cause.
Oh, and except the fact that there is then no way to clip to a single pixel.
Also, looks like the failure to clip to 0 is due to fl_push_clip:
...
} else { // make empty clip region:
...
#ifdef __APPLE_COCOA__
r = NULL;
#else
...
Replacing NULL with XRectangleRegion(0, 0, 0, 0) seems to do better.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] ARE THERE STILL ACTIVE FLTK 2 DEVELOPERS AROUND?
And the more we use C++, the less convinced I become about the way namespaces are used in C++ : There seems to be a widespread habit of just sticking a using namespace xyz at the head of every file and thereby negating almost all the value that namespaces are supposed to bring. So what's the point? Well, don't do that then :) I don't. Theoretically all the random namespacing mechanisms at work (FL_, fl_, Fl_, Fl::, ... any more?) could all be unified. That said, though I find it ugly, remembering which flavor of prefix to apply has never been a big problem for me. And my impression is that the fltk user community is just not large enough to support a big source incompatible change. Doing the big incompatible change that fixes everything is risky even with major projects even if everyone can agree on the fixes. I'm in favor of cannibalising and phasing out the morbid branches. I'd be happy to continue living with the current naming scheme though in favor of gradual changes and cleanups. Things like more virtual methods, renaming things that clash, using larger types internally, and maybe using concrete classes like Point or Rect instead of bunches of ints. There's a lot of hackery like the wacky sizes_ layout and hacks to keep e.g. scrollbars at a certain position in children_ that could be made more regular at a very minor cost to performance (if any). Some stuff like support for the 8 bit colormap could probably be dropped. And UTF8 of course. Lots of things to do without worrying about names! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] OSX 10.6 Snow Leopard
Ok, that's a good start. Since I don't know much about mac stuff I'll see if I can't find documentation for quickdraw to better figure out the appropriate modern functions. And first get my terminology straight... quickdraw is ancient and gone, cocoa is current but obj c, and carbon is the C interface and is current and not deprecated, right? Or is it? I can't imagine the *C interface* being deprecated... And then wrt development... I know there is some documentation but I couldn't find any on either the documentation or faqs pages. Faqs is all cluttered up with announcements, maybe it's buried in there somewhere. Anyway, what's the current version for development? 1.3 nightly? Is there a repo to check out, or do I just download the nightly snapshot and manually send patches of that? I see from http://fltk.org/cmp.php that Source files shall be placed under the control of the Subversion (SVN) software. But I don't see any URLs to point SVN at. Other projects have these in prominent locations linked from the main page, usually from a development link. I had to click bugs and features - roadmap - configuration management plan to find the development info I did find. So that leads me to ask... where's the svn repo for the website itself? ;) On Wed, Sep 2, 2009 at 2:17 AM, Albrecht Schlosserajs856s...@go4more.de wrote: Greg Ercolano wrote: OK, hope you all are ready for this.. This is a fresh checkout of 1.3.x and default FLTK build on stock Snow Leopard 10.6 + stock Xcode tools running on an intel mac mini: FWIW: These are the names only, sort(ed) -u (72 in total): AppendResMenu BringToFront ClearMenuBar CollapseWindow ConvertEventRefToEventRecord CountDragItems CreateNewWindow DiffRgn DisposeRgn DisposeWindow DrawMenuBar FSpMakeFSRef FindWindow GetAvailableWindowAttributes GetAvailableWindowPositioningBounds GetDeviceList GetDragItemReferenceNumber GetDragMouse GetFlavorData GetFlavorDataSize GetFlavorFlags GetMainDevice GetMenuHandle GetMenuItemRefCon GetMouse GetNextDevice GetPort GetPortBounds GetQDGlobalsArrow GetQDGlobalsScreenBits GetWindowBounds GetWindowClass GetWindowEventTarget GetWindowPort GlobalToLocal HideWindow HiliteMenu InstallReceiveHandler InstallTrackingHandler InvalWindowRect InvalWindowRgn IsWindowActive IsWindowCollapsed KLGetCurrentKeyboardLayout KLGetKeyboardLayoutProperty KeyTranslate LocalToGlobal MacFindWindow MenuSelect MoreMasters MoveWindow NewRgn QDBeginCGContext QDEndCGContext RepositionWindow SelectWindow SetEventMask SetItemMark SetOrigin SetPort SetPortClipRegion SetRectRgn SetWindowActivationScope SetWindowBounds SetWindowClass SetWindowResizeLimits SetWindowTitleWithCFString ShowWindow UnionRgn kEventWindowDrawContent typeFSS typeLongInteger Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] OSX 10.6 Snow Leopard
Not quite. Carbon is the old transitional C interface they used to move over from OS9 to OSX (actually, Carbon may even predate that, I can't remember that far back...) and is now deprecated. We need to move to Quartz, I think. Gotcha, I remember seeing the quartz select stuff in the configure help. Don't know what fltk-2 does. Suspect it is still QD actually... Can't remember when it forked off the 1.x line. It may have some relevant fixes though... Don't know. Hopefully the changes can be ported to fltk2 without too much effort. My main interest is fltk1 though. Best just use the svn repo: see the bottom of page http://www.fltk.org/software.php Oops, failure to scroll on my part. How embarrassing. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] OSX 10.6 Snow Leopard
And first get my terminology straight... quickdraw is ancient and gone, cocoa is current but obj c, and carbon is the C interface and is current and not deprecated, right? Or is it? I can't imagine the *C interface* being deprecated... Not quite. Carbon is the old transitional C interface they used to move over from OS9 to OSX (actually, Carbon may even predate that, I can't remember that far back...) and is now deprecated. We need to move to Quartz, I think. Actually, it looks like we need to move to cocoa, or at least away from carbon. Functions in the missing list like like CreateNewWindow are carbon, not quartz. So at a first glance, it seems like all non objective C development on OS X is doomed: http://en.wikipedia.org/wiki/Carbon_%28API%29 The transition to 64-bit Macintosh applications beginning with Mac OS X v10.5 has brought the first major limitations to Carbon. Apple does not provide compatibility between the Macintosh graphical user interface and the C programming language in the 64-bit environment, instead requiring the use of the Objective-C dialect with the Cocoa API. I think there must be ways to call obj c from c++, and there's an obj-c++ thing that lets you mix them, so it seems it might be possible to write Fl_mac in obj c with an API that can be called from c++. I'd have to research the details here a little, since I don't know much about obj c. So the job is bigger than we thought. Getting rid of the old quickdraw stuff is still a good idea of course, it just doesn't solve the whole problem. The carbon quartz bindings to obj c quartz bindings are probably a much more straightforward port than quickdraw to quartz. Of course, as long as you don't need 64bit then carbon lives on. Most applications probably don't, so the main thing to wonder about is will the next major version drop 32 bit support entirely? 64bit is not exactly a clear win for apps that don't need it, so it seems reasonable to keep the both around forever but maybe 16bit seemed that way once upon a time too. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
