RE: [fltk.general] Preferred methods of implementing screen labels and decorations [General Use]

[MacArthur, Ian (Leonardo, UK)]

> As mentioned in earlier posts, I'm using FLTK to create a "PC
> Oscilloscope" and so need a Front Panel. I've used box frames to draw
> borders around control groups, and labelled boxes for control labels.
> Some of these provoke "unused variable" warnings from the compiler - not
> a problem - but as a novice GUI designer it makes me wonder whether I've
> adopted an optimum solution. A screenshot can be found here (please
> excuse the prototype "clunky" appearance):

> http://52midnight.com/tmp/SNPS.gif

Looks fine for a first pass.

(Also, note that it's usually OK to post (not too large!) images in line here, to save people having to fetch 'em from elsewhere to view...)


> I'm aware that other methods exist, e.g. using background pixmaps over
> which the FLTK widgets are drawn, but would much appreciate the advice
> of those more experienced.

> What is the preferred - or least CPU intensive - method of implementing
> such things?

There's no "right" way, since it will depend on what all is happening.
Note that fltk widgets are pretty cheap to maintain - they only really cost you CPU when they are being redrawn, and they need a bit of RAM to "exist in", but often times less than an analogous pixmap would take.

For my part, I usually use "real" widgets, with a few pixmaps to help our at times.

Greg has a nice example here:

http://www.seriss.com/people/erco/fltk/#Altimeter

That uses a mixture of fltk widgets and pixmaps to produce quite a nice looking result.

If you've not seen it before, Greg's examples page is a handy crib sheet for useful ideas to build on.



Leonardo MW Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

[52mid...@gmail.com]

> Note that fltk widgets are pretty cheap to maintain

Ah, that's what I was wanting. I'm now having to learn a heap of stuff I'd only guessed at before. I assume that if I use the mouse to drag a window across the screen, the Window Manager treats it just as an anonymous block of pixels rather than asking it to redraw itself, and simply "block moves" it, back-filling the area left behind.

> but often times less than an analogous pixmap would take.

Right, about what I'd figured.

> Greg has a nice example here:

Thanks for that page - gives me a much better idea of what can be achieved with some more effort.

[Ian MacArthur]

> On 12 Jan 2017, at 17:15, 52midnight wrote:
>

> I assume that if I use the mouse to drag a window across the screen, the Window Manager treats it just as an anonymous block of pixels rather than asking it to redraw itself, and simply "block moves" it, back-filling the area left behind.
>

That depends...

Different window managers do different things with that, so it isn’t easy to give a simple answer.

Many simply show an overlay rectangle that you can drag, resize, etc. and do not trigger repositioning and redrawing of the window until you release the drag.

But others show the window content whilst dragging, and of these some will just grab a snapshot of the window and drag that, others will actively refresh the window *whilst it is being dragged or resized* so there are many different cases you might encounter.

Also note that, on Windows platforms, an application's event loop is essentially paused whilst the Window is being dragged, so no GUI events can be processed during a drag. Other WM systems tend *not* to do that, in general (although some do.)

On Windows, if you absolutely *must* keep servicing background activities during a drag, there are things you can do (e.g. with threads and such) but generally it is easier just to freeze and then pick up the pieces once the app resumes.

What platform are you on?

[52mid...@gmail.com]

> What platform are you on?

I'm a FOSS-only fella since the turn of the century. Debian 8.2 after moving through various distros, including several years with Gentoo until they discarded init in favour of systemd (sign of the cross).

My professional career was hardware design, so I spent most of it resenting operating systems as impediments to hardware access. Have learned to compromise somewhat, but only with Linux. Could never be bothered with the bug-ridden and patent-plagued world of M$.

[Ian MacArthur]

> On 13 Jan 2017, at 01:22, 52midnight wrote:
>
> > What platform are you on?
>
> I'm a FOSS-only fella since the turn of the century. Debian 8.2 after moving through various distros, including several years with Gentoo until they discarded init in favour of systemd (sign of the cross).

I thought debian was looking to systemd too now?

I’ve given up resisting it, though I’m not keen. Here’s one basket, lets put all our eggs into it...
Plus, the personalities implementing it don’t inspire confidence.
I’m pretty sure we are only one bug away from a serious exploit with systemd....

[Greg Ercolano]

See also:
http://www.seriss.com/people/erco/fltk/ntsc-waveform-sim/ntsc-waveform-sim.html

..you'll need flash to see the video, source code link included.

I found that normal fl_line() drawing is pretty amazingly fast.
I made a vector paint program (still working on it) that handles
drawing thousands of line segments in realtime. Depends on the platform,
but I was pretty amazed how fast fl_line() drawing is.