On 01.03.2010, at 16:22, Domingo Alvarez Duarte wrote: > MacArthur, Ian (SELEX GALILEO, UK) wrote: >> >>> It's a question to behave consistently if we scale/zooned the widgets >>> size/position we should as well do the same with it's font size. >> >> Why? >> The behaviour you describe is consistent, and is pretty much what every >> toolkit does. Indeed, I can't, off-hand, think of any that scale label >> font sizes as their containing widgets change size, though I guess a few >> do allow that as a (non-default) optional behaviour?
> Probably you didn't understand what my concern and probably didn't you > have tried what I proposed. > > Try this: > > Open test/input.cxx and add this line to it: > > window->resizable(window); > window->show(argc,argv); ///// this is a new line to be added > return Fl::run(); > > Compile and run it type something on all input fields, resize to full > screen and after that resize it to 1/3 of the original one. OK, I understand. However to me, that is a totally different functionality. The first use is a layout manager. There is a good reason why the "input" test is not resizable: it makes no sense. Check out the (carefully crafted ;-) resize behavior of the Fluid Widget editor. Text field will stretch in length, or, wherever it makes sense, allow more lines to be input. The second use, scaling the entire UI, is a great thing to have, but it can't be the job of the layout manager. Instead, the whole application should scale. It makes little sense to scale the widget editor in Fluid, but not the main view and all the other dialog boxes, right? I wouldn't mind at all to have a global scale functionality. I have actually put quite some thought into this (and so has Apple: they have been "announcing" a freely scalable desktop for a while now, but obviously still enough issues to not release it). To sum it up: - all FLTK applications should have a certain base scale for all widgets: normal, small, large, etc. - scaling an application must apply to all possible dialogs and windows in that application - an application must remember if it was scaled - scaling must be transparent for the application developer, no additional thing to worry about - all graphics coordinates (text positions and size, etc.) must be of type "double" to avoid aliasing effects - lines become fuzzy when scaled in an anti-aliasing environment, and the start to double up in an integer base environment; this can only be avoided if we know just /what/ is drawn. A scaled button must still look like a button, not some fuzzy ugly something; this *does* work correctly when using the layout manager, but it doesn't work for application based drawing but here is the big deal breaker: all raster graphics must be scaled, too! You approach can not do that. And we all know how ugly pixel graphics become when scaled up or down (and it is time consuming, too!). There is hope though: the Fl_Driver approach which is part of the new printing API could provide just what you need: a scaling screen driver. Actually, output to a printer is pretty much the same thing. To wrap this up: the feature is great, but please don't use the layout manager for that. - Matthias PS: on OS X, you can hold down Ctrl and roll the mouse wheel to scale the entire screen. This is awesome for pixel-correct alignment, but also very ugly and straining to the eye. Some GForce driver allow this on MSWindows. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
