>
> > microwindows-0.91, and nxlib 0.45. I'm not sure if that=20
> > answers your "Graphics layer? Window manager...?" question. =20
> > My background is embedded systems, not graphics, so the=20
> > terminology is new for me.
>
> Microwindows and nxlib were pretty much the answer. What target
> hardware, BTW?
Cirrus 9307.
>
> NOTE: At this point I usually go off on a rant about the troubles I had
> (years ago now) getting microwindows and nxlib to work right, and I
> usually suggest folk just try running XF86 or Xorg on their embedded
> target (I did, years ago), since most targets are perfectly capable of
> running a "full" X-server these days, and all sorts of weird
> compatibility issues just magically disappear... But if it is working
> for you, that's fine.
>
Its "mostly" working. I'll keep your suggestion in mind.
>
> > First, I had to rebuild fltk with the appropriate=20
> > enable-threads switch to get Fl:lock/unlock to show up in my=20
> > library. I'm surprised it worked as well as it did, without=20
> > being thread-aware library.
>
> Yup, threading is like that - it appears to be working fine for years,
> then chaos...
> As we roll out more multi-processor platforms, that's going to get a lot
> worse. Are we all looking forward to the fun?
>
> > I'm now in the process of adding=20
> > the lock/unlock pairs everywhere. So far, its not breaking=20
> > anything. :)
>
> It might even be fixing things!
>
I'm convinced we were doing it wrong before (no locks) but the locks/unlocks
certainly haven't solved my problems -- I still have the same lack-of-redraw
issues, same seg faults in malloc.
I'm currently working on getting everything into calls from the main thread,
using the awake/thread_message mechanism.
>
> > 1. You referred me to the 1.1.8 docs. I read chapter 10 but=20
> > not the whole thing. How much different is that threading=20
> > behavior from 1.1.7 which I am running? Should I upgrade? =20
> > Are there any compatibility issues I should be aware of?
>
> The threading behaviour is not significantly different. Matthias added
> some extensions to the ::awake mechanism, and some other tweaks, but the
> functionality is equivalent and the API is pretty much the same.
> But I don't think Chapter 10 was added until after the 1.1.7 docs were
> released, so you can't read that chapter in the 1.1.7 docs...
> I'd advocate updating, but not for threading support per se, just to get
> all the bug-fixed 1.1.8 goodness. Most of the time, you shouldn't see
> any difference at all, I hope!
>
> > 2. From the 1.1.8 doc:
> >=20
> > > Don't call Fl::wait(), Fl::flush() or any related methods that will
> > > handle system messages
> >=20
> > Can you give me an idea what the "any related methods" are?
>
> Hmm, tricky. I'm not entirely sure... Anybody?
> Certainly I'd avoid Fl::check(), or any of the ::add_timeout,
> ::add:idle, ::repeat_timeout, ::add_fd functions...
>
>
> > 3. Before I started all this editing, I had a main that=20
> > called Fl::run()
> > and then another thread that called Fl:wait(1.0); in a loop=20
> > (with other stuff). After reading your docs I changed main thread to:
> >=20
> > Fl:lock();
> > while (true) // Its embedded so there's no exit
> > {
> > Fl:wait();
> > }
>
> Well, I always call Fl::lock before I even create my widgets (although I
> think that's just superstition) and I always call Fl::run() in the main
> thread.
>
> > and I got rid of the Fl:wait call in the other thread.
>
> Yup. Can't call Fl::wait in a worker thread. Well, not safely, anyway.
>
> > But then I wasn't getting the screen to change the first time=20
> > I expected it to. So as an experiment I changed main to
> >=20
> > Fl:lock();
> > while (true) // Its embedded so there's no exit
> > {
> > Fl:wait(1.0);
> > Fl:flush();
> > }
> >=20
> > and it did the trick. Do you have any comments about that?
>
> Use Fl::run()?
As far as I can tell, using the awake/thread_message mechanism requires me to
use Fl::wait() instead of Fl::run() that you are steering me towards :)
>
> > So far I'm still planning on keeping the show(), hide(),=20
> > image() and label() calls in the other threads, protected by=20
> > the locks. But if necessary, I can do the=20
> > awake/message/callback thing so that it is all from main.
>
> I think, as long as the widgets are instantiated in the main thread,
> showing/hiding them from a helper thread, suitably protected by locks,
> is safe.
> Let us know how you get on, of course...
One last question: should I be worried about STR675? I don't think I'm
directly calling anything in fl_ask.H, but that doesn't mean something internal
isn't.
Thanks again.
>
> Cheers,
> --=20
> Ian
>
>
>
>
>
> SELEX Sensors and Airborne Systems Limited
> 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.
> ********************************************************************
>
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
