[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] Fl_Window::show() on multiple screens
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! ___ 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 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
#include
#include
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 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
> Please, try r.9176 that should fix all problems. Looks like my test program above is positioning properly now. Thanks! ___ 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] Doublebuffering issues and general thoughtsfrom a frustrated long time FLTK user.
On Mon, Mar 19, 2012 at 6:41 PM, james wrote: >> By the way, I just have to say, if you guys haven't started using git >> yet, you really don't know what you're missing. There's a reason >> nobody uses SVN anymore. > I strongly recommend git too, I was converted from SVN land, and git is > particularly good for open source projects. (SVN may have some merits in > closed sources) The advantage of git is to allow people to contribute patches easily. So you need to first start with some people who actually want to contribute patches but don't already have svn. Otherwise we need to protect the valuable contributors we already have and if they're already comfortable with svn I'd say don't rock their boats :) git + github is definitely pretty nice though. ___ 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.
> I was relieved to see you mentioned shared library support for themes. > This is also where I got in a big argument with the other FLTK > developers. It is ugly but work should be done on loading GTK themes and > calling the Windows "Appearance Manager", not on writing parsers for > some fltk-specific format that no other programs use and can only set a > bunch of colors. I know it is not fun but it HAS to be done this way, > and it has to be done NOW, rather than pretending that after ignoring it > FLTK will magically have the right underlying scheme to allow these to run. Are there people who actually really like and care about themes? I'd personally prefer just a single hardcoded one that looks nice. ___ 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 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
[fltk.development] fltk 1.3 linux bug in Fl::event_text()
Here's a small program that demonstrates Fl::event_text() vs. Fl::event_key():
#include
#include
#include
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, %x, key: %c\n",
Fl::event_text(), Fl::event_text()[0], Fl::event_key());
} else if (evt == FL_KEYUP) {
printf("keyup, text: %s, %x, key: %c\n", Fl::event_text(),
Fl::event_text()[0], 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;
}
On my system, if I chord 'a' and 'o' (that is, press 'a', press 'o',
release 'a', then release 'o', the 'a' release returns 'o' in its
event_text():
% ./handle
keydown, text: a, 61, key: a
keydown, text: o, 6f, key: o
keyup, text: o, 6f, key: a
keyup, text: o, 6f, key: o
Can anyone on linux reproduce? If so, I'll file a STR and maybe look
into fixing it. I have an easy workaround (just use event_key(),
which I avoided on OS X due to a different bug), but it's clearly a
bug. I think my app is unusual in caring a lot about keyups :)
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk 1.3 linux bug in Fl::event_text()
On Sat, Mar 24, 2012 at 11:29 PM, Evan Laforge wrote: ... > Can anyone on linux reproduce? If so, I'll file a STR and maybe look > into fixing it. I have an easy workaround (just use event_key(), > which I avoided on OS X due to a different bug), but it's clearly a > bug. I think my app is unusual in caring a lot about keyups :) Wait, not such an easy workaround after all. event_key() doesn't take shift into account, and you can't tell what shift does to symbols. I guess I need a fix after all. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk 1.3 linux bug in Fl::event_text()
On Sat, Mar 24, 2012 at 11:29 PM, Evan Laforge wrote: > Can anyone on linux reproduce? If so, I'll file a STR and maybe look > into fixing it. I have an easy workaround (just use event_key(), > which I avoided on OS X due to a different bug), but it's clearly a > bug. I think my app is unusual in caring a lot about keyups :) Waaaiiit... I just dug up an old message from me reporting the exact same thing. And on further thought, Bill was right, that you can't use event_text for keyups. Sorry about the noise! Since I need to know what letter went up, now I keep a keys_down map from event_key to event_text, so I can figure out what the "down" text was for a given key when it goes back up. I need the map anyway to suppress spurious keyups, e.g. if a keydown shifts focus from a different app (e.g. command-tab), then the focused app gets a keyup it didn't see a keydown for. I need the keyup text because it's easier to bind keys to '~' rather than '`' + SHIFT, and maybe not even accurate since different key layouts might have different mappings for shifted symbols. I'm suspicious of the "keep a key table" approach because those things get out of sync so easily, but I don't see another way around. If fltk doesn't want to keep a table internally so it can have an accurate event_text(), maybe we could clear it out on keyups to at least prevent people from accidentally relying on something that *usually* works? ___ 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] getting usable space per screen? alsocompilation failure on OS X
On Thu, Sep 13, 2012 at 4:57 AM, MacArthur, Ian (SELEX GALILEO, UK) 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 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] 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
#include
#include
#include
#include
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] fl_scroll not copying all channels on OS X?
On Mon, Sep 17, 2012 at 9:05 AM, Manolo Gouy wrote: >> 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. > > Could you, please, report whether r.9680 fixes the bug. > It expect it does. Indeed it does. Thanks! Though I did have this problem with external monitors even on OS X 10.6, so it's not just a 10.8 thing. Though now that I'm all upgraded I'm not super motivated to care :) ___ 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] 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] FLTK ANSI C API
On Sat, Oct 27, 2012 at 9:52 AM, Patrick 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
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 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] Testing CJK text input on Mac OS platform
On Mon, Dec 17, 2012 at 9:48 AM, Manolo Gouy 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
On Wed, Dec 19, 2012 at 4:28 AM, Manolo Gouy 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
[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 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] Fl::event_key() inconsistency between X and OS X
On Mon, Jan 28, 2013 at 11:39 PM, Peter Åstrand 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
Re: [fltk.development] Fl::event_key() inconsistency between X and OS X
> We recently updated the patches for 1.3.2. Sorry to hear that they no longer > apply to HEAD. > > Would it be possible for you to test with 1.3.2 and see if our patches does > what you want? I haven't read through all the details, but you might want to > set the SIMPLE_KEYBOARD flag to get the desired behaviour. I applied to 1.3.2, and called set_simple_keyboard() in the widget that is receiving KEYDOWNs, but the result is the same: shift-/ gives '?'. So unless I'm doing it wrong, it doesn't look like it helps. On a different subject, I'm not so sure about the design. It seems confusing for each widget to have a different invisible state that determines what kind of KEYDOWNs it sees. A Fl::event_raw_key()? An optional Widget::handle_raw() method? Anyway, I don't fully understand what the patch is doing, so ignore if this idea doesn't really apply. ___ 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
[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] fltk and high res retina display?
On Fri, Apr 5, 2013 at 2:21 AM, Christophe Geuzaine wrote: > Adding > > NSHighResolutionCapable 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] [RFE] STR #1983: clarify event delivery documentation
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1983 Version: 1.3-feature The documentation in events.html#events claims this: FLTK follows very simple and unchangeable rules for sending events. However, the rules for sending events are actually quite complicated, and not exactly unchangeable. While they are presumably documented somewhere in the docs, they aren't documented right there in the event delivery system. Here is matthiasm's description: """ Nope, the widget that has the focus gets the keyboard event first, then all its parents. If that didn't work, the keystroke is sent again as a SHORTCUT, but this time to the widget under the mouse pointer, then all its parents, then all shortcut handlers. """ In addition to that, there is the handler list which handles the event last. Also, when sending the SHORTCUT, I believe there is some hackery which tries to find the *closest* widget to the mouseover widget, in an undocumented way. The documentation should mention the complete event deliver scheme. ... and it would make me happy if it would remove the "very simple" part :) Link: http://www.fltk.org/str.php?L1983 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #1984: provide a hook to override default event delivery
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1984 Version: 1.3-feature Fltk's event delivery scheme is hardcoded in Fl::handle and can't be changed. For example, events delivered directly to focused leaf widgets cannot be intercepted at all. It would be nice to be able to replace that with my own function so I could customize event delivery, perhaps as simple as logging all events, or as complicated as implementing a completely different event delivery scheme. This would be easy enough to implement by adding a function to set a handler which is called instead of Fl::handle. Link: http://www.fltk.org/str.php?L1984 Version: 1.3-feature ___ 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 Schlosser 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
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
[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
#include
#include
#include
#include
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
[fltk.development] Fl_cocoa.mm doesn't report modifiers
Like the subject says, I know longer get FL_KEYDOWN and FL_KEYUP for modifiers. Looking around in the file, it looks like it's just not implemented, mods_to_e_keysym is never called. Unless there's some patch already being prepared for it, I'd like to take a shot at implementing it myself. Also, and this is mostly to Manolo since I guess he's the de-factor owner at this point, the file is kind of big at 3300 lines and a bit messy. Would you mind if I sent some clean up patches? I'm thinking of normalizing formatting to fltk standards, and then splitting it out into e.g. Fl_cocoa_keyboard.mm, Fl_cocoa_mouse.mm, etc. Some things like the fd select stuff can probably go in generic Fl_mac.cxx, unless the plan is to remove that entirely. I think it's probably pretty safe to make 1.3 OS X only. ___ 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
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
[fltk.development] fltk 1.3: Fl_Text_Display text misaligned, word wrapping slow
Hi, here are some regressions with fltk 1.3. I reduced the file demonstrating the problem as much as possible, it's still 150 lines but should be clear. I haven't dug into the fltk side yet to see where the problem lies, but I won't have time for the next few days so I thought I'd throw this out first. Problem 1 is misaligned text. It looks like spaces are kerned widely, until the text changes color, at which point it thinks you were using a narrower kerning. The result is that text in a different color is further to the left than it should be. Problem 2 is slowness. It should be obvious when you run the program, both inserting lines (it seems to get linearly slower on each insert) and when resizing the window. Problem 3 is with word wrapping, if you look carefully when resizing the window you'll notice that a word is cut off about %50 before it gets wrapped to the next line. Compiling with 1.1.9 the colored text is properly aligned and insertion and wrapping happens instantly, although I just noticed that the wrapping is different after insertion and after the first resize. Interesting, maybe there's a bug in 1.1.9 too? I initially thought this was a cocoa thing, but it's the same when I turn of __APPLE_COCOA__, so I'm guessing it has something to do with the new UTF8 support. As before, this is on OS X 10.5.8. test_logview.cc Description: Binary data ___ 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] 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 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] 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 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
#include
#include
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] Fl_cocoa.mm doesn't report modifiers
On Wed, Feb 10, 2010 at 12:40 AM, MacArthur, Ian (SELEX GALILEO, UK) 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 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] window positions (was: Fl_cocoa.mm doesn't report modifiers)
> 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 Never mind about the second, I realized that if you ask for the dimensions before show() then of course they may not be the final values. I now emit them on FL_SHOW, which works. I still don't understand what's going on with event_x_root(), but I stopped using it so I suppose I don't need to... ___ 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 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] 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 budui 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] Will FLTK use more C++ features?
On Mon, Feb 15, 2010 at 5:38 AM, Albrecht Schlosser 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 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
> IMHO you're missing an important point here: FLTK's cross platform > compatibility. If we would use native Fl_ widgets on one > platform, you couldn't derive your own widgets in a cross platform > way. My own application, for instance, derives own widgets from > Fl_Input and uses handle() to filter keypresses and does some more > things. What, if the Mac version would use a native widget "under > the hood" of Fl_Input? Yes, well ideally the system part would be able to coexist with that. In the same way that fltk's compose feature is transparent to people extending Fl_Input, the IME should also be transparent. I would certainly expect a native text widget to be driven by the fltk event system, so you should still be able to override handle(). > Not to speak about identical behavior of the same app. on different > platforms, but that's a question that can't be answered generally. > Dependent on the user base, someone who has more experience on a > Mac would more like the Mac way, but someone who knows an app. on > Windows (or works with the same app. on different platforms) would > probably want it to behave identically on all platforms. I know that > there are reasons to add platform specific stuff (like system > menus, native file chooser, etc.), but probably better not in such > essential widgets like Fl_Input (and Fl_Text_Display/Fl_Text_Editor). Well, wrt to IME, I don't think anyone expects it to be identical on all platforms. An IME is a lot of work by a whole team of people, so I wouldn't expect fltk to ever have its own. So it's either use the system one or not be able to enter text at all in that language, so not so much a question of "different behaviour" but "exists or not". If it turns out to be not so hard to integrate the IME protocol with a non-native widget, then that's a good way to go. Otherwise I think the native version should be customizable enough to respond to the same configuration as the fltk one. But I'm not sure without looking more closely. Fl_Text_Display is in a similar position, since it's too slow to be usable. The combination of Fl_Text_Display and Fl_Text_Buffer presents a rather fat interface but hopefully it would be possible to tear out the complicated insides and replace all the "insert x text" methods with dispatches to the underlying system buffer. Again I don't know for sure without looking into it in detail, but unless there are intractable impedence mismatch issues then this would be a nicer approach to trying to maintain your own independent text rendering system. It may turn out to be more expedient to simply tweak the fltk version to make fewer expensive calls, but I feel this may merely delay the inevitable. As the "basics" get more complicated over time, they are taken over by the OS because it's too hard for each app or library to maintain its own implementation. This means libraries must move to a higher level, which has been a long term trend. The tricky part about a cross platform library is that different platforms move at different rates. But I think it can be done all the same. Maybe over-optimistic? ___ 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] 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
> Yup. > > Don't you just love it when the young guys (re)discover the wheel and > think it's cool. The particular young guys involved are Rob Pike and Ken Thompson. > Time was when we always ran lint or cb... I myself am a young guy so I don't know about 'cb', but lint didn't handle formatting, did it? Anyway, I like the gofmt approach, just please don't mix tabs and spaces. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Warning messages
> was intended to mean: > > a = ( b & m ) != 0 ; > > but was with precedence rules: > > a = b & ( m != 0) ; > > which is IMHO really surprising for a reader/programmer... > > But it is as it is, and the compiler does what you tell it, and > not what you *intended* it to do ;-) This precedence oddity is a well-known C flaw, I believe even K&R have acknowledged it (something like "what would you change about C if you could?" "not much, besides some operator precedence issues"). When I pass -Wparentheses to gcc, I get: t.c: In function ‘main’: t.c:6: warning: suggest parentheses around comparison in operand of & So there's special warning code to help you with this problem. The fact that some other languages have imitated this flaw is usually about "better standard than better", which is usually the reason to pick a C-like syntax in the first place :) ___ 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] 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?
> I imagine that Fl_Native_Text_[widget] would only expose the minimum > lowest-common-denominator API, not the full API we currently expose for > the nedit widget. > > Anybody who needed fancy control of the widget would acquire some > suitable "handle" to the widget and them use platform specific coding > using the native API. > > Something like that? Indeed, that was basically my idea too. I haven't really looked enough at the OS X libraries to know if it's practical but the idea is appealing in theory. I thought only OS X had the wrapping problem but if X has it too then yeah, that makes the case stronger for fixing the nedit code. Since it's all volunteer basis anyway, no reason to not do both, eventually :) I'll have to check out the latest build to see how the IME stuff works. Many thanks (once again) to Manolo! Another nice thing about a native input widget is that it's somehow more jarring when input widgets don't conform to platform standards than other ui elements. Even once I get used to the fact that the app doesn't do the native style menus or whatever, I still expect command-a to select all and get surprised when it doesn't. > Volunteers to implement this welcome! Eventually I will need a better solution for my app, so I'll come back to the UI side of things, but it'll probably be a little while. > (Now I Have to go meet the builders again - work is "ongoing" at the > house, but we are having issues. Very old buildings can be tricky!) make clean && make... if only it were so easy :) ___ 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] 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
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] 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 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
[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 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] spurious FL_FOCUS
On Wed, Mar 23, 2011 at 10:13 AM, Greg Ercolano 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 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
Re: [fltk.development] spurious FL_FOCUS
On Thu, Mar 24, 2011 at 6:28 AM, Manolo Gouy 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
> :
> 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 wrote:
> Evan Laforge wrote:
>>> #include
>>
>> 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
> 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
[fltk.development] [RFE] STR #2600: Fl::screen_count() and friends are only initialized once
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2600 Version: 1.3-feature If I attach or detach a screen, fltk won't realize that until I restart. In src/screen_xywh.cxx, the info is fetched with screen_init(), which is protected by a global and thus only ever called once. Attaching and detaching screens is very common with laptops, so this should be fixed. In addition, it would be nice to be able to register a callback when a screen is added or removed, to avoid having to constantly poll for changes. Link: http://www.fltk.org/str.php?L2600 Version: 1.3-feature ___ 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
[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 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
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 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
Re: [fltk.development] recent Fl.cxx change bus errors on OS X
> This should be fixed in r. 8577. Indeed it is, thanks! 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. ___ 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 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
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
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
