foxgui-users

RE: [Foxgui-users]FOX work here?

[Daniel G. <geh...@ep...>]

MJester,

This case is usually handled by using multiple execution threads.

[Threads are little bit like mini-programs within a single process.
 Instead of running one program for the GUI, and another to crunch 
 the numbers, you would use the main thread to display the GUI, 
 and create a "worker" thread for your calculations. Since 
 the threads of a same process share their memory space, communication
 is very easy (global variables, ...).]

FOX, as a GUI library, has no direct threading support. But you can use
it in conjunction with the omniThread library (LGPL license), which 
comes as a separate module with the OmniORB2 library.

      http://www.cam-orl.co.uk/omniORB/index.html

- Daniel

> -----Original Message-----
> From: fox...@li...
> [mailto:fox...@li...]On Behalf Of M Jester
> Sent: Wednesday, May 03, 2000 5:30 AM
> To: fox...@li...
> Subject: [Foxgui-users]FOX work here?
> 
> 
> Have a C program that loops through iterations improving on an objective 
> until ending conditions are met. I hope to develop a GUI so user 
> can adjust 
> parameters and view progress (e.g. graphs that get updated each 
> iteration) 
> on the fly while the program is iterating. For example, during 1 
> iteration 
> the processor may be busy cruching for a minute, then the intermediate 
> solution is updated and the next iteration is begun. This may go on for 
> hours. Currently communicate with program via ASCII text files 
> that get read 
> in each iteration and program takes new parameters/instructions.
> 
> I downloaded FOX and checked out a bunch of the test programs. All looks 
> great. However, I'm having trouble figuring out how an iteration-based 
> program would work in this object oriented c++ world. The program 
> needs to 
> iterate while all the GUI objects are funcioning and 
> communicating with it. 
> I don't have much experience with C++, which may be the main conceptual 
> problem. Is FOX likely to work to build a GUI for this type of problem. 
> References for developing this type of program would be appreciated.
> Thanks, MJester
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
> 
> 
> _______________________________________________
> Foxgui-users mailing list
> Fox...@li...
> http://lists.sourceforge.net/mailman/listinfo/foxgui-users
> 

[Foxgui-users]FOX work here?

[M J. <mje...@ho...>]

Have a C program that loops through iterations improving on an objective 
until ending conditions are met. I hope to develop a GUI so user can adjust 
parameters and view progress (e.g. graphs that get updated each iteration) 
on the fly while the program is iterating. For example, during 1 iteration 
the processor may be busy cruching for a minute, then the intermediate 
solution is updated and the next iteration is begun. This may go on for 
hours. Currently communicate with program via ASCII text files that get read 
in each iteration and program takes new parameters/instructions.

I downloaded FOX and checked out a bunch of the test programs. All looks 
great. However, I'm having trouble figuring out how an iteration-based 
program would work in this object oriented c++ world. The program needs to 
iterate while all the GUI objects are funcioning and communicating with it. 
I don't have much experience with C++, which may be the main conceptual 
problem. Is FOX likely to work to build a GUI for this type of problem. 
References for developing this type of program would be appreciated.
Thanks, MJester
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

[Foxgui-users]Re: FXWindow::setWidth(n);

[Jeroen v. d. Z. <jv...@cf...>]

On Tue, 02 May 2000, you wrote:
> I have a dialogbox with a text window and button.
> When I call this the first time the "setWidth()" call works.
> On subsequent calls, it doesn't.
> Also, FXWindow::hide() doesn't work on a window within a frame after it is exposed.
> I used the 4 calls flush refresh etc. Don't work.
> Thanks, Mike D...

OK, here it is:

setWidth(), setHeight() records the new width/height into the widget, but does not
do anything else.  So at the first opportunity, the widget's parent will set it
right back to what it was.

The current width of a widget is typically negotiated with the widget's parent. This
process is influenced by layout hints, so that e.g. LAYOUT_FIX_WIDTH strongly suggests to
the widget's parent that the width should be left alone.
Note the layout flags are HINTS, and it is not necessarily true that all layout managers
observe these hints [some layout patterns such as FXSwitcher, ignore most of the hints
because og the layout constraints].  Most layout managers however try their best to 
observe as many hints as makes sense!

Calling hide() will hide the window, but the window's parent isn't necessarily aware
of that, unless you call recalc() also.
The reason that hide() does not call recalc() automatically is that some widgets call
hide() and show() in their layout(), and layout should of course not call recalc() or
the process would never stop.

As a convenience, sending an ID_HIDE message DOES call recalc(), by the way.  This is OK
because layout() itself does not work using messages.


Hope this helps,

		Jeroen

-- 
+----------------------------------------------------------------------------+
| E-Mail : jv...@cf...             `:::'                  .......  ......  |
| USMail : 215 Wynn Drive,            :::  *                  `::.    ::'    |
|          Huntsville, AL 35805       ::: .::  .:.::.  .:: .::  `::. :'      |
| Phone  : (256) 726-4820             :::  ::   ::  ::  ::  ::    :::.       |
| Fax    : (256) 726-4806             ::: .::. .::  ::.  `::::. .:'  ::.     |
| WWW    : http://www.cfdrc.com      .:::.....................::'   .::::..  |
+----------------------------------------------------------------------------+
| Check out the FOX GUI toolkit:                                             |
| U.S.A. [Official]:  http://www.cfdrc.com/FOX/fox.html                      |
|                     ftp://ftp.cfdrc.com/pub/FOX                            |
| Europe [Mirrors]:   ftp://SunSITE.Informatik.RWTH-Aachen.DE/pub/Linux/fox/ |
|                     ftp://imssun1.epfl.ch/pub                              |
+----------------------------------------------------------------------------+

[Foxgui-users]subscribe

[Gordon C. <gor...@fr...>]

SUBSCRIBE

[Foxgui-users] Re: [Foxgui-announce] New Drop of FOX [0.99.121]

[Jeroen v. d. Z. <jv...@cf...>]

On Mon, 01 May 2000, you wrote:
> Hi Jeroen,
> 
> I think Fox is great... and look forward to having a good opportunity
> to use it.  (I haven't yet)  I have been following things closely, and
> had all the features working well both under Linux and Windows...
> including
> Mesa and 3D... It is looking beautiful.
> 
> I only have one comment /request
> > 
> >         - FXQuat FXDQuat additions.
> > 
> 
> How about using  Qtrn  to abbreviate Quaternion?

I have historically called the class FXQuat.  Changing the name would
probably break some people's existing programs, and is therefore not likely
to be widely appreciated .

> I am a seasoned C++ programmer... is there anything that I can do
> to help get to version 1.0?  I would be willing to help with
> either programming or documentation...

Well, if you're also a seasoned PostScript programmer, perhaps you can have a
look at the FXDCPrint.  There are still many things to be done in this class.
[Printing is a big mess, mostly thanks to X11 not really providing WYSIWYG
capabilities in its original design].

Other things, which are quite significant development projects in their own right,
and which I would like to see added to FOX one day, are widgets such as a Rich
Text Widget, and an HTML (XML?) Widget.


> I don't think this is on the FAQ:
> 
> Why all the custom container classes?  Wouldn't it be a bit easier
> to use the standard C++ library and Standard Template Library?

I don't really have any custom container classes besides FXObjectList.  And
for that one, the rationale is that it supports FXStream based, type-safe,
platform-interchangable serialization using FXStream.

As for STL, this causes too many portability headaches; if you need code
to work on many different machines, you're better off avoiding those, at least
untill gcc, VC++, BoC++, SGI MIPS C++, and other popular compilers can be used completely
interchangably; we have all of these compilers, and moving between them is sometimes
very painful.....


Regards,


			Jeroen


-- 
+----------------------------------------------------------------------------+
| E-Mail : jv...@cf...             `:::'                  .......  ......  |
| USMail : 215 Wynn Drive,            :::  *                  `::.    ::'    |
|          Huntsville, AL 35805       ::: .::  .:.::.  .:: .::  `::. :'      |
| Phone  : (256) 726-4820             :::  ::   ::  ::  ::  ::    :::.       |
| Fax    : (256) 726-4806             ::: .::. .::  ::.  `::::. .:'  ::.     |
| WWW    : http://www.cfdrc.com      .:::.....................::'   .::::..  |
+----------------------------------------------------------------------------+
| Check out the FOX GUI toolkit:                                             |
| U.S.A. [Official]:  http://www.cfdrc.com/FOX/fox.html                      |
|                     ftp://ftp.cfdrc.com/pub/FOX                            |
| Europe [Mirrors]:   ftp://SunSITE.Informatik.RWTH-Aachen.DE/pub/Linux/fox/ |
|                     ftp://imssun1.epfl.ch/pub                              |
+----------------------------------------------------------------------------+

Re: [Foxgui-users] FXDataTarget questions

[Jeroen v. d. Z. <jv...@cf...>]

On Fri, 28 Apr 2000, you wrote:
> > You should be able to make any number of widgets send their messages to one
> > single data target, but you can connect only one variable for each data target.
> > 
> > This is because of course a data target sometimes operates in reverse [in GUI update
> > mode] and changes the widget from the variable instead of changing the variable from 
> > the widget.
> 
> Hmmm ... I probably wasn't very clear with my question - I'd like to 
> be able to connect to different variables sequentially (without 
> creating new FXDataTargets each time), not concurrently.

You can do that.  Just call connect() with a reference to the variable. 
It doesn't even matter if the newly connected variable is of a different type
than the old one.

> A quick look at the source says that that's not unreasonable, but I 
> wanted to make sure that I'm not setting myself up for any nasty 
> surprises later! 

You're not.  This should work!

> > So, the GUI updates are not instantaneous, but work as a background or idle task,
> > i.e. they fire SEL_UPDATE messages when there is nothing else to do.  This is of
> > course intentional, otherwise they would interfere with the application's responsiveness.
> 
> That's great - the app I'm considering won't have to do much 
> processing beyond monitoring data - and good response time won't hurt 
> at all.

OK.  Note though that a GUI refresh usually happens when the system "knows" that
GUI needs refreshing.  
So if new data is dropped into monitored variables, but nothing else happens GUI-wise,
you might have to call FXApp::refresh() to cause a GUI update (normally, this is done
for you after a message is known to have been handled).


	- Jeroen



-- 
+----------------------------------------------------------------------------+
| E-Mail : jv...@cf...             `:::'                  .......  ......  |
| USMail : 215 Wynn Drive,            :::  *                  `::.    ::'    |
|          Huntsville, AL 35805       ::: .::  .:.::.  .:: .::  `::. :'      |
| Phone  : (256) 726-4820             :::  ::   ::  ::  ::  ::    :::.       |
| Fax    : (256) 726-4806             ::: .::. .::  ::.  `::::. .:'  ::.     |
| WWW    : http://www.cfdrc.com      .:::.....................::'   .::::..  |
+----------------------------------------------------------------------------+
| Check out the FOX GUI toolkit:                                             |
| U.S.A. [Official]:  http://www.cfdrc.com/FOX/fox.html                      |
|                     ftp://ftp.cfdrc.com/pub/FOX                            |
| Europe [Mirrors]:   ftp://SunSITE.Informatik.RWTH-Aachen.DE/pub/Linux/fox/ |
|                     ftp://imssun1.epfl.ch/pub                              |
+----------------------------------------------------------------------------+

Re: [Foxgui-users] FXDataTarget questions

[Len <lk...@dr...>]

> You should be able to make any number of widgets send their messages to one
> single data target, but you can connect only one variable for each data target.
> 
> This is because of course a data target sometimes operates in reverse [in GUI update
> mode] and changes the widget from the variable instead of changing the variable from 
> the widget.

Hmmm ... I probably wasn't very clear with my question - I'd like to 
be able to connect to different variables sequentially (without 
creating new FXDataTargets each time), not concurrently.

A quick look at the source says that that's not unreasonable, but I 
wanted to make sure that I'm not setting myself up for any nasty 
surprises later! 
  
> So, the GUI updates are not instantaneous, but work as a background or idle task,
> i.e. they fire SEL_UPDATE messages when there is nothing else to do.  This is of
> course intentional, otherwise they would interfere with the application's responsiveness.

That's great - the app I'm considering won't have to do much 
processing beyond monitoring data - and good response time won't hurt 
at all.

Thanks!

-Len

Re: [Foxgui-users] FXDataTarget questions

[Jeroen v. d. Z. <jv...@cf...>]

On Fri, 28 Apr 2000, you wrote:
> Two quick questions about FXDataTarget:
> 
> 
> 1) Is there any reason I couldn't (or shouldn't) connect() a given 
> FXDataTarget an "infinite" number of times to different targets? For 
> example, if I were to use Fox as part of a debugger, and wanted to 
> select an object on a list and observe its members in action, I might 
> set up a textfield for each member, and "re-connect" the associated 
> FXDataTarget as I moved thru the list.

You should be able to make any number of widgets send their messages to one
single data target, but you can connect only one variable for each data target.

This is because of course a data target sometimes operates in reverse [in GUI update
mode] and changes the widget from the variable instead of changing the variable from 
the widget.

 
> 2) How often are targets read? The particular objects I'm thinking 
> about monitoring (above) have "dirty bits" that I could work with, 
> but since it's entirely possible that those bits are suspect, I'd 
> prefer not to.

I think you are talking about GUI updates, and when it happens?  GUI updates
should happen just before the program would block for events [as in calling
select to yield the CPU].

So, the GUI updates are not instantaneous, but work as a background or idle task,
i.e. they fire SEL_UPDATE messages when there is nothing else to do.  This is of
course intentional, otherwise they would interfere with the application's responsiveness.


> 
> 
> (has the CFDRC-based listserv been shut down? I received a "user 
> unknown" message from the server when trying to post this)

Yes, CFDRC mailing list has been down all week due to the firewall/gateway upgrade.
I'm hoping they'll get it fixed soon.


Regards,


		- Jeroen


-- 
+----------------------------------------------------------------------------+
| E-Mail : jv...@cf...             `:::'                  .......  ......  |
| USMail : 215 Wynn Drive,            :::  *                  `::.    ::'    |
|          Huntsville, AL 35805       ::: .::  .:.::.  .:: .::  `::. :'      |
| Phone  : (256) 726-4820             :::  ::   ::  ::  ::  ::    :::.       |
| Fax    : (256) 726-4806             ::: .::. .::  ::.  `::::. .:'  ::.     |
| WWW    : http://www.cfdrc.com      .:::.....................::'   .::::..  |
+----------------------------------------------------------------------------+
| Check out the FOX GUI toolkit:                                             |
| U.S.A. [Official]:  http://www.cfdrc.com/FOX/fox.html                      |
|                     ftp://ftp.cfdrc.com/pub/FOX                            |
| Europe [Mirrors]:   ftp://SunSITE.Informatik.RWTH-Aachen.DE/pub/Linux/fox/ |
|                     ftp://imssun1.epfl.ch/pub                              |
+----------------------------------------------------------------------------+

[Foxgui-users] FXDataTarget questions

[Len <lk...@dr...>]

Two quick questions about FXDataTarget:


1) Is there any reason I couldn't (or shouldn't) connect() a given 
FXDataTarget an "infinite" number of times to different targets? For 
example, if I were to use Fox as part of a debugger, and wanted to 
select an object on a list and observe its members in action, I might 
set up a textfield for each member, and "re-connect" the associated 

FXDataTarget as I moved thru the list.


2) How often are targets read? The particular objects I'm thinking 
about monitoring (above) have "dirty bits" that I could work with, 
but since it's entirely possible that those bits are suspect, I'd 
prefer not to.


(has the CFDRC-based listserv been shut down? I received a "user 
unknown" message from the server when trying to post this)


-Len

[Foxgui-users] Test again

[jvz <jv...@cf...>]

Test