AltME groups: search

Hey, I found a really neat GUI interface in the Picasa photo organizer 
program from Google. (http://www.google.com/downloads/) If you download 
it or already have it, just click the "Timeline" button near the 
top of the screen. I think it would be really neat if someone could 
make a REBOL clone of that screen.

I like the admin-gui but on my developer machine I always use apache.

There's a Free clone of Delphi out there called Free Pascal with 
a GUI-alike called Lazarus, but I doubt its COM support is that good, 
and they can't do the GUI as well because the best features of Delphi's 
GUI are patented by Borland. I think Microsoft licenses those patents 
for Visual Studio.

Had to search my hd a bit, long not used. found it in a few places, 
uploaded one here: http://polly.rebol.it/test/test/museum/diff/gui/

it's the same difference as having view or using whatever the os 
provides for the gui

I am not sure - even with rebol (core), if you want gui, you have 
to download View :-) I am not against kind of standardising upon 
good modules, but not sure if I want one big exe with everythign 
inside. :-)

Would you really want a non-native GUI, with every call to / from 
it going via slow [in relative terms] routine! APIs?


I agree that having one *huge* exe that does 100% of what *everyone* 
wants but only has 20% of it's functionality used by the average 
coder is a bad thing. The problem is defining what constitutes huge 
and what functionality is needed by most coders. Here are some typical 
components:

	Graphics
	Sound
	Networking
	Maths
	Encryption
	Data storage
	Installer
	Registry access
	Library access


Which should be built-in? Which should be loadable modules? Is your 
preference going to be the same as mine? These are not easy design 
questions.

Every OS is done in modular way for a reason - give a break please 
- one of the best OS designs I looked into a bit imo is QNX - even 
something like event system for gui is external to kernel - in fact, 
the kernel is really small and nearly everything is module. Aren't 
we talking real-time OS here?

I say this to myself occasionally. It means "build more GUI, then 
things will be easier".

Qtask with a rebol front-end requires a fairly advanced rebol GUI.

denismx: the password is saved when it is asked via the gui. so it's 
not asking you because you have set it already :)

The bandwidth is fine - it's an architectural bug. AltME shouldn't 
block on retrieval at all. Any blocking should happen after the message 
has been retrieved, just long enough to post the message to the GUI, 
no more than a millisecond.

ICarii will take this information so he can build a better GUI :)

I got it to work on a different port.

On windows you do not seem to need to declare the port like on linux.
Windows opens multiple worlds from the gui

the post dropping is the # 1 bug in Atlme.  lets just prevent it 
from flushing the text area before it receives the post, and at least 
we won't be frustrated.


the clearing of the view when a connection is dropped is also EXTREMELY 
annoying... you have to click back on the group, and it clears te 
"unread" bg color and resets the scrollbar.   these can be changed 
without any real coding change required... its just preventing a 
few things in the gui/network event handling.  maybe we could just 
the bg of the Network status to RED, that accomplishes the same goal, 
but doesn't turn us into enraged altme users.

Will be done in R3. R3 Chat system is said to use similarities to 
AltME system, just more robust. It just needs GUI client ...

there is one issue which is SO ANNOYING, I sometimes close altme 
before throwing out my computer by the window.

 when the display becomes a blue screen if the client loses its connection 
 with the server...


this is both useless and highly irritating, cause when the world 
re-connects (99% of the time on its own) you have to re-click on 
the group, which looses the "unread msg" beige highlight.  it also 
forces you to have to re-click on the text entry with the mouse.


when your internet connection is buggy or a server has troubles... 
disconnection may happen repetitively every few seconds.  the blue 
just makes altme unusable in a situation where it should just stall, 
until a new message is sent.


when a world disconnects, it should just change the color of something 
or put a label somewhere obvious in red color... but don't touch 
the GUI's functionality.... please

As Graham says, the REBOL.org archive does cover the network shemes 
group:
  http://www.rebol.org/aga-display-posts.r?post=r3wp763x1814

But not the REBOL3 GUI group -- Brian did not set that to [web-public] 
-- if he his happy for it to be [web-public] we can easily add it 
to the archive.
Please report rebol.net problems via RAMBO for best results.

(The script I was working on which led to this bug was this one:

do read http://anton.wildit.net.au/rebol/gui/demo-future-progress.r

i had such a problem with massive gui and async. Workarounded the 
following way: recycle is off permanently. there is a thread (do-every 
or such) which checks how much memory was allocated and when it is 
to much it recycled. crashing stopped.

First run View 2.7.5.3.1 and do this:


 site: select load-thru http://www.rebol.net/reb/index.r[folder "Anton"]
	clear find site %index.r
	load-thru/update site/patch/caret-to-offset-patch.r

Do the main demo, showing patched AREA:

	do-thru site/patch/demo-caret-to-offset-patch.r

Three patched styles; AREA, FIELD, INFO:
	
	do-thru site/gui/demo-area.r
	do-thru site/gui/demo-field.r
	do-thru site/gui/demo-info.r

The initial experimental testing script:

	do-thru site/patch/test-caret-to-offset-patch.r

as cmd is a non gui product

they have a website and there are some binaries. on linux i found 
a few in my distor, the second worked nearly automatic, after editing 
something. for windows i guess there is something more comfortable. 
binaries makes sense because they are in my login-script :) I guess 
windows could pop up browser too, as gui is closer coupled to scripting?

that is my primary need or want to use rebol for, is to manipulate 
text. I like perl, but  love rebol's small footprint, if it can give 
me the same power of perl in a much smaller package, with a gui, 
that is all the better. I could potentially replace access and a 
lot of proprietary tools with a small rebol view application.

the BCC header field is a field used by mail clients to let users 
type addresses that will *not* be included in the header. it is, 
basically, a user interface. back at the time mail clients did not 
have a gui, and just processed mail from a file or by letting you 
type them on the terminal

graham: that's a good idea and the desktop already has something 
like that, a gui that lets you type to subject and message. we could 
just add bcc and cc

http://www.rebol.cz/~cyphre/trans-gui.r
http://www.rebol.cz/~cyphre/trans-win.r

I have a proble to submit to VID GURUS... My problem is the following 
I writing a click and scroll algorithm. (ike In MDP-GUI you have 
the floating toc window panel when you click on on of the title shows 
in the floating toc window the visualisation scroll to the related 
title. But this show the title on the middle of the screen and no 
on the top of the visualisation pane. The forumal I apply is sld/data: 
related-offet/y  / sub-pane-visualisation/size/y  and then I apply 
the scroll function. What must be the for mula to have always the 
related title in the visualisation pane on the top part of the screen

When I was working on MDP-GUI some month ago basing me on the very 
first intent of ashley we were using a layout compositor (and a layout 
call) to renderize the docuement view than Ashley comes with a design 
based on pre contructed minimal enherited face system and using only 
show the gain inthe do view area rendendering process was about 300 
%:)

and easier if you "only" need a tradition GUI ?

pekr make the try take a very frirst version of MDP-GUI and take 
the lastest  You will be suprise ;)

I was happy to see "request-dir" as I was updating a 6-year old tool 
that I use off and on. I was wondering if, for sake of continuity, 
there is a "windows" gui for this?

it's not that VID is not good, it's that its purpose was not to be 
the ultimate gui framework, but more of an example of what you can 
do; indeed, now we have RebGUI too. but, the problem with that way 
of thinking, is that in practice developers need a solid base to 
start. so it's much better for everyone to provide it.

.

vid2: Has somebody ever tried oberon/blackbox-builder? Thats the 
kind of layouting i like. They use text with "active-x-controls" 
inside (only better and simpler ;) . blackbox can do really windows-style 
guis that way. then while developing you can mark part of that gui 
and just copypaste it somewhere else. gives a lot easier control 
than typical gui-builders IMHO.

do http://www.lexicon.net/antonr/rebol/gui/demo-rotate-knob.r

Check out this old script. It's a bit messy, but the example works.
http://www.lexicon.net/antonr/rebol/gui/transparent-events.r

site: select load-thru http://www.reboltech.com/index.r[folder "Anton"]
clear find site %index.r
load-thru/update site/gui/rotate-knob.r
load-thru/update site/gui/demo-rotate-knob.r
do-thru site/gui/demo-rotate-knob.r

IIm not often complaining but Im getting a bit disapointed about 
this.....Well anyway.. Im killing GUI time here with some alternatives...Hope 
RT do  thier best..

do http://www.lexicon.net/antonr/rebol/gui/iterated/list-of-checks.r

do http://www.lexicon.net/antonr/rebol/gui/iterated/list-of-toggles.r

Does anyone have a good performance with Rebol/view and i.e. Hummingbird 
Remote Desktop?  Seems Rebol is quiet slow here where GTK GUI is 
flashing over my screen my Rebol gui's do need far more time..
Any hint of tip is welcome..

These changes to PARSE are another example of changes to the R3 core 
happening as a side effect of the new GUI work :)

I am the editor of the PARSE proposals.


It was decided that I perform this role because Carl is focused on 
the GUI work right now and someone qualified had to do it. With Carl 
busy and Ladislav not here, I am the one left who has the most background 
in parsing and the most understanding of what can be done efficiently 
and what can't. When the PARSE REPs of old were discussed, I was 
right there in the conversation and the originator of about half 
of them, mostly based on my experience with other parsers and parser 
generators. Because of this I am well aware of the original motivation 
behind them, and have had many years to think them through. It's 
just head start, really.


I am also the author of the current implementation of COLLECT and 
KEEP, based on Gabriele's original idea, which was a really great 
idea. It is also really limited. Collecting information and building 
data structures out of it is the basic function that programming 
languages do, and something that REBOL is really good at. I am not 
in any way denigrating the importance of building data structures. 
I certainly did not mean to imply that your appreciation of that 
important task was in any way less important.


The role of an editor is not just to collect proposals, but to make 
sure they fit with the overall goal of the project. This sometimes 
means rejecting proposals, or reshaping them. This is not a role 
that I am sorry about - someone has to do it to make our tool better. 
We are not Perl, this is not anything goes, we actually try to make 
the best decisions here. I hate to seem the bad guy sometimes, but 
someone has to do it :(


PARSE is a portion of REBOL that is dedicated to a particular role. 
It recognizes patterns in data, extracts some of the data, and then 
calls out to the DO dialect to do something with the data. It doesn't 
really do anything to the data itself - everything happens in the 
DO dialect code in the parens. It is fairly simple really, and from 
carefully designed simplicity it gets a heck of a lot of power and 
speed. That is its strength.


The thing that a lot of people don't remember when making improvements 
to a dialect like PARSE is that PARSE is only one part of REBOL. 
If something doesn't go into PARSE, it can go into another part of 
REBOL. We have to consider the language as a whole when we are doing 
things like this.

Here is the overall rationale for the PARSE dialect proposals:

- All new features need to be simple to explain and use, and fast 
at runtime.
- A good feature would be one of these:

  - An extremely powerful enhancement of PARSE's language recognition.

  - A fix to a design flaw in an existing feature, or a compatibility 
  fix.

  - A serious improvement to a sufficiently common use case, or common 
  error.


The reason I didn't want to put COLLECT and KEEP into PARSE is because 
it is a small part of a much bigger problem that really needs a lot 
of flexibility. Different structure collection and building situations 
require different behavior. It just so happens that the DO dialect 
is much better suited to solving this particular problem than the 
PARSE dialect is. Remember, PARSE is a native dialect, and as such 
is rather fixed.


There are some PARSE proposals that make parse actually do something 
with the data itself: CHANGE, INSERT and REMOVE. We were very careful 
when we designed those proposals. In particular, we wanted to provide 
the bare minimum that would be necessary to handle some very common 
idioms that are usually done wrong, even by the best PARSE programmers. 
Sometimes we add stuff into REBOL that is just there to solve a commonly 
messed up problem, so that a well debugged solution would be there 
for people to choose instead of trying to solve it again themselves, 
badly. (This is why the MOVE function got added to R3 and 2.7.6, 
btw.) Even with that justification those features might not make 
it into PARSE because they change the role of PARSE from recognition 
to modification. I have high hopes, though.


Another proposal that might not make it into PARSE is RETURN. RETURN 
is another ease-of-use addition. In particular, the thing it makes 
easy is stopping the parse in the middle to return some recognized 
information. However, it changes the return characteristics of PARSE 
in ways that may have unpredictable results, and may not have enough 
benefit. The proposal that has a better chance of making it is BREAK/return, 
though I'd like to see both (we can hope, right?).


Most of the REPs from Gabriele's doc have been covered. Most of them 
have been changed because we have had time in the last several years 
to give them some thought; the only unchanged ones are NOT and FAIL, 
so far. Some have been rejected because they just weren't going to 
work at all (8 and 12). THROW and DO are still under discussion - 
the proposals won't work as is, but the ideas behind them have merit. 
The rest have been debated and changed into good proposals. Note 
that the DO proposal would be rejected outright for R2, but R3's 
changes to word binding make it possible to make it safe (as figured 
out during a conversation with Anton this evening).


There are other features that are not really changes to the PARSE 
dialect, and so are out of scope for these proposals. That doesn't 
mean that they won't be implemented, just that they are a separate 
subject. That includes delimiter parsing (sorry, Petr), tracing (sorry, 
Henrik), REBOL language syntax (sorry, Graham), and port parsing 
(sorry, Steeve, Anton, Doc, Tomc, et al). If it makes you feel better, 
while discussing the subject with Anton here I figured out a way 
to do port parsing with the R3 port model (it wouldn't work with 
the R2 port model). I will bring these all up with Carl when it comes 
to that.


I hope that this makes the situation and my position on the subject 
clearer. I'm sorry for any misunderstandings that arose during this 
process.

Right now the driving force is building better dialects - Carl needs 
it for the new GUI dialects. The data parsing improvements have just 
accumulated over the years and now seems like as good a time as any, 
especially because of the R3 compatibility break.

Carl is focussed on the GUI stuff right now, and his feedback is 
needed since he will be using the feature for that.

Cyphre is a member of the development world for the new GUI.

Server currently doesn't have the Syllable GUI yet, but it will come

When is the GUI due ?

I'd consider using it as a virtualisation platform, but I guess I'd 
wait till a GUI was wrapped around at least the installation

I mean, on the server I just need a text interface and no GUI frills. 
Just lean and mean machine.

to make sure the mouse, and clock work and the video too I think 
.. though that's not so necessary in a non-gui environment

so, no gui then?

Syllable GUI on Desktop, maybe a remote REBOL GUI on Server

A rebol gui thru ssh to the server?

For example, the first goal for a graphical server was to port the 
Syllable Desktop GUI to Server, but that project is stalled for the 
moment being because the developer is gone

I've installed Syllable Desktop 0.6.6. Didn't run my nvidia card 
so I switched to vesa mode. I didn't find my PS/2 Defender mouse, 
and navigation over GUI elements is degraded when only keyboard is 
used (underimplemented)? I can provide any details about my hardware. 
The primary problem at question is a mouse.

Kaj: BTW Congratulations on achieving a fast GUI at the OS! Even 
Oberon/A2 GUI is slower---though A2 uses bigger screen resolution.

I'm sure it is, but that defeats the purpose of rebgui which is to 
build a complete gui toolkit without having to know the internals.

CTX-REBGUI/COLORS is an object of value:
	window          tuple!    236.233.216
	widget          tuple!    244.243.238
	edge            tuple!    127.157.185
	edit            tuple!    255.255.255
	over            tuple!    255.205.40
	menu            tuple!    49.106.197
	btn-up          tuple!    200.214.251
	btn-down        tuple!    216.232.255
	btn-text        tuple!    77.97.133

CTX-REBGUI/EDIT is an object of value:
	...
	tabbed          block!    length: 5
	hilight-on-focus block!   length: 2
	caret-on-focus  block!    length: 4
	action-on-enter block!    length: 3
	...

ctx-rebgui/widgets/set-sizes unit-size font-size


Plus many widgets have various option flags to control some aspect 
of their behavior.


Probably not skinning in the true sense but enough to change basic 
scale, colors and behaviors to cover the major use cases as they 
have been presented to me thus far. Skinning that lets you change 
"look & feel" to the extent that the GUI can mimic native Windows, 
OSX, C64, etc could be done but at what price in complexity and delivery 
time? And what percentage of folks would just stick with the default 
look & feel anyway. Another way of saying this is to ask whether 
it is a good idea to put 80% of your effort into satisfying the needs 
of 5% of your user-base?

Right at the beginning of RebGUI I asked if anyone had good pointers 
to a consistent graphical style that we could follow (other than 
WindowsXP, Mac OSX, KDE, etc) ... in the ensuing silence I chose 
to go what I'm familiar with, XP. I'm still keen to have a modern 
looking REBOL style that doesn't look too out of place on Windows, 
Mac or Linux; but I'm not a gfx guy. Jaime's BEER interface (the 
GUI config front-end) is about the best I've seen far.

I've had good feedback on the GUI for my RebGUI application.

Overlooked that gui-interface for beer. Where is it?

Making the GUI look right and not just a copy of something else is 
tricky. I often think about it. I also had to deside with Canvas, 
both for the tool panel and the requesters. I went with a very basic, 
clean style for the requesters, maybe even a bit boring.

I see two needs. One is for 'normal' application like business application, 
where the GUI shouldn't for any sake come in the way. A basic, clean 
look is needed for that. The other is 'special' application, that 
would benefit from something more eye-candy like. Examples are a 
visual remote control, or a music player.

I'm wondering, if users on the different platforms, that REBOL runs 
on, would find it very strange to use an application, that doesn't 
use the normal GUI look for that platform. I remember some guy (a 
developer, I think) many years ago, that would trash an application 
immediately, if it didn't use the OS own GUI.

With REBOL, we have options. We can make our GUI look exactly like 
the host OS (maybe even read the system files to see, what theme 
is selected), or we can build our own, maybe better GUI.

The fundamental thing which makes one GUI better than others is consistency. 
 period.   design is all about making the looks and feel work for 
target a target audience, but if its inconsistent accross the experience, 
then its instantly unusable for anyone. 
.

I am inclined to agree that consistency is important in GUI design 
(imo. down to the last detail, it reflects competency), but *the* 
most important thing is that form meets function, and a part of this 
is selecting the best possible visual metaphor for the task at hand. 
 While widgets are a means to this end, it's all too easy to overuse 
them.

I've thought much lately about the difficulty in introducing a third-party 
style into any given OS environment (which we as cross-platform developers 
must consider short of using native libraries) and it is difficult. 
 The subtleties of eg. OS X and WinXP are far different, so is there 
a happy medium?  I'd like to think so, but having tried /View on 
OS X, I'm not so sure that my previous attempts at platform-neutral 
GUI style are as successful as they could have been (though anti-aliased 
fonts may be a key missing feature).

Look & Feel: Getting close to OS look but still let it look different 
is a good idea. Users won't expect exact behaviour. The GUI must 
be simple to use. That's it. Tooltips are IMO a very good quick-and-dirty 
help-feature.

About gui-look: How about mimicing amiga?

How about using the new Canvas GUI images ?

As for the GUI issues, I am confident that Ashley and contributors 
will fix those issues and so I have released it as is.  I don't resize 
anyway.

VID editing system is all not not natural ... the caret system is 
the most awfull thing i saw this far on rebol and that 's a pitty 
because it limitate so mutch inventivity (well in fact ... yes and 
not ...  i played a lot with caret sytem when i as working on MDP-GUI 
Some  hard things are relatively easy to make like flags insertion 
to born a sleected piece of text and some easy things are hard to 
do like keeping the selection on the selected text and not on the 
begin inserted flag ...)

Gabriele, are you planning to follow up on the design document you 
posted when we talked R3 GUI design?

I'm sure I don't want VID improvements before of rebcode.... I want 
CORE with rebcode first... And I really hope that some release  will 
not be postponed just because there is no  new tree-list GUI or something 
else

but that is not the point. I just first could not follow, how they 
work with widgets, and then I found out - they have separated code 
and widget definitions. At first it looks strange .... it is like 
having 'feel(s) , event maintanance, app logic, without seeing what 
actually you are working with. But I do understand, why they keep 
widget defs outside in external file, which is kind of simple (as 
VID is), with static positioning - it is very easy to import to visual 
GUI builder ....

widgets and their functionality are defined in .nib files for a cocoa 
program. this is because much of the binding between the widgets 
and the code is created during runtime. this is also why Interface 
Builder is able to create much of the initial functionality for a 
Cocoa GUI, just by defining attributes to widgets and let you test 
the interface to a fairly high level without compiling any code.

it would also help if the community could do a little bit. GUI Design 
for example didn't have to stop, just because Carl goes to France.

Geomol, I built a printer abstraction system called system-print 
for my apps. It's not finished, but for what it does it works sort 
of OK. You can choose printing method via a GUI and it auto-detects 
Ghostscript and uses it if necessary.

I'm still working on my VID->Postscript thing. I will need it for 
work on a paper layout GUI later this month, so there will be some 
progress there.

A bit OT but Lad and I started a test-dialect for RebGUI. You could 
send CLICK to GUI objects etc. and compare results and state, make 
screenshots of something was wrong etc.

Robert what you describe even if for GUI app sounds somewhat similar 
too.. I also take screenshots for example , and I also need some 
methods to chech and compare the state of app , that is still totally 
missing (and many other things)

you reference the CONTEXT the test should be executed in. Then you 
can use all GUI word. Using set-word! sets the GUI widget to the 
value, state etc. (the dialect makes the most useful setting). You 
can press widgets, check values in widgets (fields, tables, check, 
...) You can even use different paths depending on results.

for my part, when R3 goes open, I'll be integrating liquid-paint 
with OpenGL asap... which will completely alleviate my need for /view. 
 we will have a 3D native GUI  :-)

BrianH: I think that what Doc means by Windows console is R2 kind 
of console, not that ugly black monster Windows offers you by default 
:-) There was lots of talk about the console topic and we imo need 
both - system default one, for admins, and GUI based one, for normal 
users. But GUI console could be created using View, as Cyphre showed, 
even in R2 it was nicely usable ...

Yeah, the intention is that a GUI console will be written in REBOL, 
part of the community-created, open-source portion. Then you can 
use or adapt the console for your own apps as well if you like. How 
about having RConsole being implemented with that? :)


Right now the GUI doesn't have good-enough Unicode support to make 
the console yet, so the GUI console will have to wait for the release 
of the host code (the current priority), and the subsequent resumption 
of the GUI work.

cheyenne-admin also has a *VERY* nice GUI, using GLayout.

Note this is a linux server-side only tool (currently).
currently:
	-remote browing of files in a gui.
	-uploading/downloading any files to/from the webserver
	-running command-lines remotely
soon: 
	-chmoding remote files
	-handling webserver start/stop/restart  remotely.
	-more as time goes by.

I hate Apache config file. Because I hate having to read tons of 
docs to just "switch on" some app. Cheyenne's config file has never 
been designed to copy the Apache way, nor to be used by average end 
user. It's just a placeholder waiting to be replaced by a builtin 
web GUI allowing a simple, fast and straightforward way to manage 
the server. That has been the plan since the beginning and one of 
the main motivation for building Cheyenne. Unfortunately, I never 
had the required time to complete that goal yet, so I'm stuck with 
that, and that's also why Cheyenne is still at 0.9.x.

Documentation can be replaced by a well designed GUI.

The config GUI is supposed to be remotely accessible (using authentication).

if the config GUI is web based... then it relies on the server actually 
working...  but I'm not trying to argue with you, just pointing out 
the fact that server configuration is usually much better handled 
in text and I think many admins prefer it.  the fact that everything 
in windows is GUI based is the most annoying aspect about it.

Well, I always thought that GUI was an improvement other text files. 
Cheyenne is suppose to work out of the box with a default config 
file. The admin web UI would be reacheable with http://server-ip/admin/
(just an example).

I have a generic configuration managing library... the documentation 
is directly embeded in the configuration engine... if you save out 
the config or print it on screen, you have all the docs right there 
with it.  if you build a gui which uses the configuration data, you 
can also pull out the text from it. 


maybe that is what should be done.... allow string types within the 
config dialect (and store it appropriately).  then you/we could easily 
build tools using that info directly.

Embedding docs that can be extracted for a GUI is a good idea.

this being said, I understand the appeal for GUI-based configs, but 
most power users are much more effective with raw data than having 
to fiddle with a screen hiding the data.

screen hiding the data

 you're already supposing that the admin GUI will be badly designed...I'm 
 not talking about doing a Webmin clone (this is the typical example 
 of *bad* UI design, IMHO).

as long as the config GUI is only a tool over the files, and it doesn't 
overwrite the files automatically, I won't complain  :-)

as a point of fact, it is very possible that some modules (like remark) 
will require stuff to be setup which is hard to simulate through 
a gui.  managing a system of nested parameters and list is very complex 
to handle programatically.

I'm adding words which are commands within remarks' module using 
the do variant of config definition...  this allows me to grow a 
config by calling the same command multiple times.... this would 
be very unweildy to implement any other way (but not impossible)...


maybe a function-based api could allow us to "hook" into the GUI 
but its pretty hard to cover all possibilities in any case... anhow... 
back to modulating remark.