AltME groups: search

nothing new, this is based on the old examples of systray usage. 
we use the systray in the detective too.

it can be done, but not with all features I wanted - ability to change 
icon state in regards to what is happening in the app (coloring, 
blinking), ability to slide mini window, when you mouse over it, 
reaction to left/right mouse click. If all that can be done, then 
ok, but it is acording to Cyphre. I don't mind if rebol systray support 
already supports that :-)

improved systray support .. viz. support mouse overs. and different 
icons

Cyphre systray: great news!

James...yes.  Working on that tech, talked about it with Carl just 
the other day.  We are attempting to make a SysTray app right now.

Ingo: on the 'system port, no official doc. Some info:
rebolist thread (rebol.org) :

    http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlMYFJ
'signal demo script :

    http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlNFFJ
drag-and-drop demo script: 

    http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=sys-port-drag-accept.r
systray demo script:

    http://compkarori.com/vanilla/display/System+Tray+Functionality

It's different for each OS. For MS-WIn, there is:
    get-modes system/ports/system 'system-modes
    ;== [window winmsg tray endian]
where:
    'window : REBOL console window handle,
    'winmsg : OS message block,
    'tray : systray definition block
    'endian : CPU byte order ('big or 'little)

For Linux:
    get-modes system/ports/system 'system-modes
    ;== [signal read-fd write-fd except-fd signal-names endian]

Cyphre's systray code could come in useful into making this a systray 
application

systray.. ;-) putting rebol in the systray...

Where to find some documentation about systray in Rebol?

http://www.rebol.org/cgi-bin/cgiwrap/rebol/search.r?find=systray&form=yes

Cyphre is working on systray enhancements .. stay tuned

there is one bug found with systray :-( you get events only if console 
window is visible ....

This bug is not related to systray directly (ie the current Systray 
support works fine) but it is related to system port.

Regarding bug:

Script of Gabriele works fine for me even no console window is visible. 

Then the question is - does it (systray opeartions) affects other 
event waiting on ports (f.ex. interface events, loading file from 
internet)

Josh - Cyphre was supposed to release systray support last week. 
Hopefully it is soon. Dunno about features though ... (it will be 
.dll based)

I mean you start the systray with do-events, but then you can't start 
your forever [ process ]

Just wondering how's it's done with just the systray icon and no 
GUI

graham, maybe look at my clips.r script, it is systray only.

I've abstracted the systray/forever loop out here 
http://rebol.wik.is/Code_Samples/Systray.r

is there a definite documentation on the systray support in windows? 
 I have some working code (from Izkata) but I am wondering if there 
is more to the interface than what I am using.

an exhaustive code example could also suffice

I don't even think I used systray in REBOL since going to Vista. 
 So dunno if it works on Vista.

Max, I found some old systray experimental code. No guarantees.

Systray? Systray was done by Cyphre for me on contract, and released 
for free. IIRC Cheyenne used it at some point ...

If there wouldn't be a systray I probably wouldn't switch my bigger 
project to rebol and consequently started with all projects in rebol.. 
cheyenne was the most cruicial reason, if there wouldn't be cheyenne 
I would never switch -- but systray was the final nail in the coffin 
of the previous languge for that particular project. So, thanks  
Pekr and Cyphre!

the event handling dispatches code related to the event that triggered 
it.  there is no way for that code to interrupt the even handler, 
especially when the event handler isn't programmed by yourself.


when you add wait []  in a function, there are many reasons why to 
want that wait to return.  in this case, modal operation of some 
code.


wait is a nested system where a second call to wait doesn't break 
the first call to wait.  


To allow this I had to patch view's wake-event directly, but it works 
now.. 


 there is no way for a normal action to interrupt event handling a 
 part from closing all windows, which made this modal operation of 
 my code especially complex to build without an interruption mechanism.


I've had other situations like having a systray and view not collaborating, 
where closing a window ends the app even when the systray is running, 
or where the window wait keeps running even if all windows are closed 
and the systray was then hidden as well.   a timer event would have 
easily solved that issue by interrupting appropriate event handlers 
when it detects some situations.

Very good!   Also, if Cyphre can work with us on R2 update, we can 
add those systray features native.

(To prevent requirement of DLLfor systray  if possible.)

A little bit surprised, that I was asked, if systray support done 
by Cyphre for my purposes, could be used by others, as I stated it 
obviously here on altme. To put the confusion aside, Cyphre managed 
to release it publicly - license - BSD:

http://www.rebol.org/view-script.r?script=tray.r

Ashley, I am using build 210 (I'll update shortly), but wow, I love 
this little library. No compromises, fault intolerant, and best of 
all, ZERO learning curve.


Would it be an idea to add some systray functions to RebGUI for Windows?

Gabriele has written some systray stuff ...

Seems something here, http://rebol.wik.is/Code_Samples/Systray.r

I would suggest, to not overcomplicate things from the very beginning, 
to simply stick to what we have - cross platform UI behavior. I know 
there are OS specific things - installers, control panel icon, systray 
icon, OS-X (Amiga) system menu, etc., those should be possible as 
an option ... (e.g. view/new/os could use OS dialog box ... or view/specs 
layout [layout here] [spec-block configuring how the same layout 
should map to OS features ... .e.g. already mentioned menu)])

The question is whether we want to integrate into the OS or not? 
Almost each OS does menus, systray notifications and window handling 
differently.

and VID should be able to use all common interface like systray or 
always on top

what do win32 features for REBOL 3.0 mean? Anything specific? Rebol 
is meant being cross-platform, although many would like to see things 
like better systray, com interface etc. :-)

Doc - do you want cool Systray support? Works excellently.  Dony 
by Cyphre for me, BSD ....

If you close Cheyenne by using the [x] console gadget, a ghost image 
remains in the systray (disappears if you pass you mouse over), f 
you stop your Cheyenne session by using the systray menu, it will 
clean it properly.

Cheyenne release v0.9.15 beta. Download at http://softinnov.org/tmp/cheyenne-r0915.zip

Changelog :

v0.9.15 - 20/06/2007


 o RConsole was not started by default in the previous release. Fixed
	

 o RSP: 'include function protection from infinite cycles changed. 
 It's

   now based on a counter (5 maximum recursive includes). It's a little 
   less

   cleaner than stack-based tracking but much more reliable (avoids 
   matching
	  paths and targets).
	  

 o HTML.r library rewritten from scratch. Now, faster and more conforming 
 to 

   standards (Full range of Latin1 entities supported). Fixes URL-encode 
   bugs.

	o BugFix for command line parsing in encapped Cheyenne on Linux.
	

 o Fixed an issue with 'decode-multipart in RSP.r. File upload should 
 work ok 
	  again.
	  

 o Added a new global function : 'rsp-log value. Outputs values in 
 console for 
	  debugging RSP scripts. Works as 'probe.
	  

 o Reloading config file now supported. Running sessions and client 
 connections

   survive to the reloading process (needs some additional testing). 
   Activating
	  config file reload is done using:
	  
	  		- (Windows) "Reload Config" menu option in systray icon.
	  		- (UNIX)     kill -s HUP pid
	  		

 o UNIX signals SIGINT,SIGQUIT,SIGTERM now catched to allow cleaner 
 exit and last

   minute actions. Triggers the new 'on-quit event for HTTPd modules.
	

 o HTTPd internal events (not phases) refactored to be cleaner. New 
 module's
	  events added:
	
			- 'on-started:	when Cheyenne starts.
			- 'on-reload:   before a config file reload happens.
			- 'on-reloaded: after a config file reload happens.
			- 'on-quit:     when Cheyenne is about to stop and quit.
			

 o RSP sessions can now be made persistent (can survive to a server 
 complete restart).

   This option is controlled by a new config keyword: 'persist. Usage 
   is :
	  	
	        persist [sessions]    ; other flags can be added at will
	        

 o BugFix in session cookie handling for web-apps using 'auth mode. 
 Now the cookie

   is sent on the 302 redirection to the login page avoiding the creation 
   of a 
	  "shadow session" that will never be used. 
	  

 o FastCGI is under heavy work so mod-fastcgi is commented in config 
 file to avoid

   fastcgi startup. If you want to play with PHP, just uncomment the 
   line.

Binary Cheyenne doesn't display taskbar, only the systray icon.

The yellow tooltip message when mouse is over the systray icon could 
be a good place. Instead of "Cheyenne is running" could be "Cheyenne 
is listening on port(s) ...". I'll think about it.

I've also patched the systray code to include the port number(s) 
in the yellow help message.

Here's the current changelog since 0.9.19 :

v0.9.20 - ??/??/2009


 o RSP: databases definition can now be declared at webapp level allowing 

   multiple instances of a webapp to use the same virtual database name 
   but,
	  pointing to different real databases.
	  

 o Config keyword 'databases now allowed in webapp sections. If defined 
 there,
	  it takes precedence over the global section definition.
	  

 o Systray help message now includes HTTPd port number used by the 
 running
	  instance.
	  

 o RSP: session security improved by binding client's IP address to 
 the session.
	
	o Fixed issue with loading %libc.so for Linux 64bits versions.
	

 o HTTPd: fix a long standing issue with IE5/6/7 extra CRLF sent randomly
	  after POST data.

if you're accepting ideas for cheyenne... it would be cool for the 
conf dialog to allow us to add items in the systray, which fork to 
a system event within the mod.  many uses for this come to my mind 
 :-)

What is Cheyenne using DLL interface for?
 

- UNIX: CGI support, running as user instead of root, management 
of external servers (like PHP)

- Windows: CGI support, external servers (PHP), Desktop detection 
(for hiding working files), NT Services support, mutiple instances 
support, systray menu

DLLs are generally not cross platform too, no?

DLL are not, but the mappings to the DLL can be written easily in 
REBOL code, no need to go down to C. I see that as a big advantage 
in simplicity and maintainability.

/shell is available, just less powerfull.
Cheyenne requires /info, /output, /input and /error.


/output is not there, but in such a case /wait is sufficient - you 
can redirect to file, and read it after the return from the call/wait

If you want to have the slowest CGI support in the world, that's 
a good way for sure!