Albrecht Schlosser schrieb: >> I know this working (using another approach, see my template example) >> and it's fine - when there is a high resolution monitor, you just need >> to resize the window, save size and the whole software is adjusted to >> the current resolution. > > Probably only if all widgets are (and should be) resized in the same > way.
Do we use the same terms? I want to make some definitions: "zoom" - resizing of a window, when all content of the window follows the resizing. Similar to looking through a magnifying lens or changing the resolution of the whole monitor, but higher resolution is kept for e.g. for graphics. "scaling" - changing the size of all fonts, not necessarily as a result of resizing, but for better match of font type and font size (I used this term in another way). Maybe "scaling" can be used also for changing the font type? This also might cause user to change ratio of window. > What I wanted to say is that you can have some widgets that do > resize, and others that don't. The former would auto-resize their > fonts, the latter wouldn't. So, in the example where you want to > /zoom/, you'd have some widgets that still have smaller fonts. Yes, this is the point, where my "assigning a format" started. It is not always wanted, that the whole window zooms e.g. a list should keep a smaller font. To manage this, it must be possible to assign a format definition to the list. I see your point, but it's a general problem of resizing and depends on the specific application. So you are right - there are cases, such a feature doesn't work without adjustment to current application, but I don't see the problem, because all must be optional. >> Anyway, I hope now it is plain to see, where the problems are, how to >> solve them and what it would achieve - rescaling of fonts on the fly, >> changing fontsize on the fly. > > But only in a "relative" way, as widgets resize... No, by setting h0 different to real starting height, you can scale the fonts without resizing anything. >>> (2) The "pointer version" looks like the "Style" approach we had in >>> FLTK 2 and that *is* already in FLTK 3 [1], so this would be the way to >>> go anyway. Probably. >> >> I think none of them is ready for productive use? Regarding to FLTK 3 I wasn't sure - I also used FLTK 1.3 before it was released. > This question is rhetorical, isn't it? The real problem is, that I neither know FLTK 2, nor FLTK 3. Is there a brief overview about "Style" approach possible, or should I look to the code? Are textsize and textfont members of style right now? > However, since the next step forward should be to FLTK 3, we should > probably not add new API's (methods) to FLTK 1.3 that become obsolete > if (when) we use the "Style" approach in the next version. It realises scaling and zoom? What does "next" mean in real time? > but I wanted to point out the problems that need to be solved I think, I know them and my FLTK patch was not meant as *solution*, but as proof of concept and check for general problems - I needed it to enlighten the way. > I also believe that such auto-resizing of fonts could be > added to FLTK - the question is, however, which way? Will there be > FLTK 1.4, or will we move to FLTK 3 with styles and such soon??? What does "soon" mean in real time? Is FLTK 3 the reason, why I'm missing Matthias? ...very nice, just met your developer warning, when downloading FLTK 3! :o) It works, but it doesn't zoom. Are there serious problems? Looks good! Do you want to tell me to use FLTK 3 for detailed proof of concept? > [1] http://www.fltk.org/cmp.php Oh yes, very interesting! > Since FLTK is targeted at platforms which often lack complete ISO C++ > support or have limited memory, all C++ code in FLTK must use a > subset of ISO C++. What's about today, are these restrictions state of the art? Exceptions Namespaces Standard C++ headers and library Templates static_cast, dynamic_cast, const_cast I'm in doubt of Exceptions, but I love using STL and I don't like char*. To me it's not C++ without STL, at the very most a C+. > We'd need one or the other to add ABI-breaking changes FLTK_3.unrestricted.playground? I really don't like char*. ;o) _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
