AltME groups: search

>> exists? to-file "c:\rebol\rebgui\enfacecmd.exe"
== false
>> exists? to-rebol-file "c:\rebol\rebgui\enfacecmd.exe"
== true

in rebgui at least

Sounds like RebGUI needs grid formatting.

e.g. for me, RebGUI is a dead end. I talked to Bobik, and he is back 
to VID for simple stuff. There were many changes lately, and some 
things got broken, and it does not seem to be supported anymore. 
As for GUI, I believe that in 2-3 months, you will be able to talk 
otherwise, as Robert wants to move his tools to R3 definitely ...

ok, should work for rebgui too then

Odd, the directory has 755 so should be readable ... anyway the files 
can be accessed directly:

	http://www.dobeash.com/RebGUI/dictionary/American.zip

and:

	British.zip
	Czech.zip
	Dansk.zip
	Deutsch.zip
	Espanol.zip
	Francais.zip
	Italian.zip

Maxim - I might not care. This is just one measure, what client want. 
I provided clients with many solutions, from DOS apps via Windows 
native apps, some web apps, and VID/RebGUI small apps. They don't 
care.

Thanks Graham - what should I do with the first run of Tortoise? 
I suppose I better don't do Check-out? Should I create a "working 
copy"? I don't remember how I did it for Rebgui, as I am long time 
issuing Update item from the context menu. I need to do first sync 
of Cheyenne now, and would not like to screw something on the server 
side :-)

never noticed a date issue .. but then I use rebgui's date requester.

The point would be, were tables done correctly in RebGUI, that the 
pretty print formatting would come at cell rendering time rather 
than as input to the table. In the work I've been doing, Cyphre changed 
table for me so that it would allow sorting on strings that contain 
numbers.

I'm talking about RebGUI, not VID.

Henrik .. you surprise me .. you've always said you don't use rebgui 
!

The app I'm building now requires RebGUI and so I get to know it 
a little bit.

Let it be known:


As my role as Secretary of user.r, the International REBOL User Association, 
it with great honour that I hereby announce that

Ashley G Trüter is named the 2008 user.r   rebol Of The Year.


Congratulations Ashley for the well deserved honour and the members 
of user.r would like to take this opportunity to thank you for your 
contributions, both personal and professional, to the world of REBOL 
development.


For those that may not know, Ashley is the author of many great software 
frameworks including RebGUI, RebDB and a SQLite driver.  He consistently 
displays a level of kind professionalism that makes him more than 
worthy to receive the first ever rebol of the year award.

Cheers mate.

Brian Tiffin
user.r Secretary

Ah, Ashley and RebGUI 3.0 :-)

I've spent a bit of time going over R3/View and believe it now has 
all the "building blocks" required to build a modern/fast gob! based 
GUI. The amazing thing is that these building blocks are the 10 natives 
that View adds [to Core]. They are:

	gob!
	caret-to-offset
	cursor
	draw
	effect
	map-event
	map-gob-offset
	offset-to-caret
	show
	size-text


With these 10 natives (gob! is actually a type!) we should be able 
to construct simple but powerfull gob!-based GUIs with a smaller 
mezz footprint than R2. My preliminary conversion of RebGUI to R3 
seems to take about 50% the code to do the same thing [compared to 
R2] ... very promising at first glance.


To get a feeling for how tight the code can be the next post is the 
entire [skeleton] source of a working gob!-based GUI.

hehe, so we might get RebGUI 3 sooner, than VID3 :-)

Yes and no. Yes it's going to be as minimalistic and bloat free as 
before ... no as I'm aiming for something that allows seperation 
of form and function. RebGUI has a number of limitations that under 
R2 were problematic to resolve but under R3 are doable.

Nice Ashley. Waiting to see RebGUI in R3. Your project could be a 
big step forward for REBOL

Ashley - maybe you can "just" write a low level layer of RebGUI3 
in such a way, that upper layers (widgets) code will require no change 
to its code? Having RebGUI available for R3 could boost R3 usage 
...

No, not wrong attitude. Styles are built by experts, i.e. people 
separated from those that build layouts. In VID, you don't have this 
distinction as you can manipulate styles directly in the layout, 
but you do, somewhat, in RebGUI.

Carl seems to have some specific stuff in mind for vid direction 
but he is just not going to get to it anytime soon...I do not see 
a prob with you guys coming up with an alternate vid (rebgui for 
r3) in the mean time...each gui may be addressing different needs 
anyway. Carl's VID, when ready, can become the defacto and distributed 
with R3 but in the mean time we can use the alternate to push R use 
forward.

Even if an official GUI is released tomorrow it will not be all things 
to all people and some will develop other gui's (rebgui, maxim's 
glass etc) why not start now as opposed to later. It need not be 
considered a folk of the offical vid...just an alternative choice. 
the official when released will be adopted if it works well enough 
so you won't be stepping on carl's toes.

ah, fine. Hope that he will use some of mine outlined Rebgui grid 
- virtual rows/columns, so that you can use raw data block directly 
from SQL query, no need to rebuild it into special block. Very usefull 
...

i liked pretty much the idea of an advanced high end side widget 
library like REBGUI . It evolved so much faster than View in  last 
years. and the result is nothing to deal with the rough aspect of 
the basic VID

maybe  this set of "advanced widgets" can be updated automatically 
through internet like rebgui was. IT depends in fact on how often 
do we plan to update the widget library  if its once or twice a year 
then it can be done through regular R3 release if it's more ofthen 
then we need a way to update the advanced library more often

rebgui ;-)

btw - is grid system done by Cyphre? He did his own grid, as well 
as RebGUI grid. Hope the design has virtual columns/rows, to stop 
the need to reshape original data source ;-)

I prefer the rounded edge tabs used in Rebgui ... but I see windows 
uses squared off tabs

hmm, it seems like Carl is finally cooperating even in the GUI area? 
:-) So, is he liking new RebGUI like resizing model, or not? :-) 
I remember even some discussions in the past, and Carl had his own 
opinion on that. I hope that max-size need is eliminated ... or still 
it is not? :-)

From my perpsective it is easy - we need resizing system, which just 
works. With RebGUI, I still had some issues even with simple GUIs 
....

resizing: no, Carl does not like RebGUI resizing model, nor some 
look-alikes. Neither do I. That is why Cyphre and I had to try two 
distinct prototypes not being fully content with any of them (the 
second one being able to deliver some nice pictures already). Tomorrow, 
it is time to try yet another resizing model, this time adhering 
to Carl's original idea more, than his own implementation, so the 
system is going to be quite advanced (it took a lot of time to fine-tune 
some algorithm details, we almost gave up).

Cool, because I did not like RebGUI resizing either, dunno why. Maybe 
because I was not getting what I exptected ...

216 is a more special layout in respect to resizing. It is defined 
so, that it can be resized only horizontally, and only the first 
and the last element are allowed to change their sizes when being 
resized. (that is something you cannot define in RebGUI as far as 
I know, neither it was possible in Carl's resizing algorithm, afaik)

In RebGUI, there were some keywords available, so that you could 
influence things. The same I remember for Romano's sizing model I 
personally tested for him ...

it uses rebgui

I guess it was started with RebGUI .. and you just carried on using 
it.  Could you have written it in the vid-ext-kit?

and yes it was started with RebGUI, mainly because that was the standard 
GUI system to use at the time.

yeah, it looked a lot like rebgui to me; but who knows, maybe you 
just imitated that style :) thanks for clearing that up!

Dunno if it's just me .. but often I will get RebGui crashes because 
part of the gui being referenced has not yet appeared.

All I can say then is that I do see a lot of rebgui errors if I use 
the gui too quickly

Our primary concern is that RM Asset needs to use R3 very soon for 
a production app for a customer, so the focus is to make all things 
that are normally handcranked in VID and RebGUI, such as form validation, 
handling of database records and a complete UI test framework fully 
automatic. If it takes 2 days instead of 7 to build and test a GUI, 
Robert saves money and can ship earlier.


Over the past year, with the rather big RebGUI app, NLPP, that RM 
Asset has built, we've learned exactly where we need to make things 
better and what works OK and certain delays, because of GUI architecture 
limitations have cost money. It's no longer for convenience or for 
advertizing the GUI as easy, but hard money savings are involved.

R3GUI is surely not a final name, althought not that bad. It reads 
as REGUI, which is close to RebGUI :-) It will not work, once R4 
is introduced (in 2020 or so :-)

It's also a lot wider than that of RebGUI's

I would regard such design being - fundamental. I like that RebGUI 
because of that - one widget, one file, easy as that. There is too 
much fuss about inheritance, having some base, upon which other styles 
are based - that is an utopia, and I don't know, while we still keep 
to that. That does not save any signicant memory, and I doubt that 
by changing one parameter to some base style, you want to have all 
childs influenced. That is nice example of inheritance, but completly 
misses practical usability imo :-)

OK, whatever ... if it would work like in RebGUI, showing some automated 
help/parameters, or old R2 Word browser, it would be nice ...

That's also how rebgui does it ...   across is default so vpanel 
2 [ .. ] is two coumns

Aha, did not know, that RebGUI did it that way

Regarding Graham's note about RebGUI - Cyphre checked it, and there 
we can use just a PANEL (which corresponds to the above proposed 
HPANEL, as it looks), and an AFTER X value, which corresponds to 
HPANEL X specifying the number of columns, not the number of rows, 
as Gregg/Izkata seem to propose for HPANEL

When Cyphre did the grid for RebGUI for me, that is what I suggested 
to him - to enclose column VID description into block, so that you 
can reorganise it easily .... so I am OK with that ...

could you give me an url to try all your style ? like tour.r on rebgui 
 ?

Whenever you are creating a concept in a GUI, such as keyboard navigation 
and focusing, you immediately want to centralize it with the option 
of per-style overrides. This is the illusion of control in that you 
want to meddle, when in fact, you are moving toward a lack of control 
a lack of unification and opening up all sorts of opportunities for 
bugs.


It is *much harder* to develop large applications, when concepts 
are not centralized, in the same way if you don't have a single mechanism 
for help bubbles, for determining which button is default, have a 
single, unified resizing system (hello, RebGUI), have a standard 
method for exiting windows, have a standard method for creating and 
displaying any number of dialogs (hello, VID), have a standard method 
for validating forms, have a standard method for reading and writing 
face properties (hello again, RebGUI).


With all these things properly in place, GUI development is reduced 
from weeks to hours.


Of course the other method of thinking may prevail, if you have never 
coded a large GUI before, and therefore don't consider the testing 
process, which can take *weeks* and *costs money*, because you have 
to test every single implementation (N number of implementations) 
of the concept that would otherwise be done in a central system (1 
implementation). It's really the testing that constantly is underestimated.


One can only determine that something cannot be centralized if it 
will create too much code, compared to a per-style solution, but 
it will in general always cause the GUI developer to create functioning 
and *bug free* layouts with much less work.


In that same thinking, R2 View centralizes the generation of a face 
image gradient, background, text display and edge appearance. It's 
not flexible, but it makes it darned simple to skin and generally 
does not have bugs.


And you FEEL object question: Yes, they are reused a lot, otherwise 
VID would probably be 100 kb bigger.

I don't agree, and I've also built large apps, both with the VID 
Extension Kit, which supports the philosophy of restrained access 
to faces and RebGUI, where face hacking is necessary. The former 
is significantly easier to work with, than the latter due to not 
needing to be explicit on every single twist and turn. The lack of 
proper uniformity does not leave room for an intelligence beyond 
the style level, and you will not unveil the potential for reducing 
code size, testing times and greater overall consistency and stability.

My opinion is, that noone will be ever able to work with materials 
in any gfx tool. So for me the central material storage is a wrong 
decision. The same as it was with Gab's GUI to have central storage 
of skin and look. At some point, it makes sense, yes. But otoh, I 
prefer the source readability, and I think RebGUI was better, keeping 
stuff related to one style together.


What is more - we keep style draw "frames" at the style level too. 
I would like materials to move in the style too. I don't expect having 
tonnes of material skins, to switch between.

Following few things:


- why is "custom" include needed? We should either user R3 native 
facilities, or include an include as a standard into R3 :-) (this 
is no real question, just a remark that if we find it usefull, then 
why notto make it part of R3?)

- RMA does not work with CureCode tickets. It would be good to either 
dismiss/close or resolve them? E.g. I find renaming of do-style and 
do-face to do-action, do-reaction a good tip to implement


- we should resolve the size of buttons vs scroller vs tabs. In Carl's 
GUI, button is 28 pixels tall, and it feels OK. Our's here is 22, 
I have no preference here, but could be those 28 pixels. Scroller 
is only 16pix - not acceptable imo. It should be of the size of the 
progress. Tabs are proportionally too tall.

- tabs should have line removed for actual tab. I suspect it might 
be more difficult to draw the container then.

- there seems to be someone at RMA liking Old aqua interface of MacOS. 
Tabs, buttons and scrollers are a good example ... of how to not 
do visuals anymore :-)

- area - enter few lines, go to bottom, and try to hilite the text 
by keyboard (shift plus arrow-up). It always hilites only actual 
line

- info areas, labes, etc., should prohibit display of caret, maybe 
allow hilighting, but allowing to have caret in "disabled" area is 
not looking nice

- text-table buttons are Excel filter inspired, but looking strange 
- some more thoughts needed
- select-an-option does not allow keyboard navigation

- text-list does not scroll, when navigated by keyboard, ditto text-table

- tabbing feels strange for text table. I alway said, that we need 
nested tabbing. I can imagine tab stopping on table, but next tab 
moving away, not actually going into tabbing in terms of the hilited 
widget. Enter should enter the more complex style, escape move away. 
That is not typical also at OS level, but then - everybody has it 
wrong :-)

- between the text-list and text-table, I have to press tab three 
times -visually I am not sure, "where" hilite disappears

- is text-table a compound style? What sense does it have to have 
buttons hilighted, not being able to enter the action? Why are not 
arrows tabbable? Table headers cells should be one style, not two.

- text-table is the weakest "grid" we ever had. Comparing to Cyphre's 
style pack, and rebgui grid. This is like 5% of functionality, not 
thought out style, useless for any serious data. I want to see the 
display of infiinte amount of data, proper caching.

- tab should be tabbable, ctrl-tab allowed to switch between the 
tabs  


I find the styles/gui inconsistent. There should be someone defining 
the styles, their behaviour to keyboard navigation, tabbing, etc. 
So far it seems like style being put together with no deeper thought 
about the end result of the whole GUI.

Rebolek - easy to describe. Cyphre is the guru of grids. I remember 
his Cyphre styles grid, and I also do remember grid my company paid 
for, for RebGUI. And I really don't understand, why witch each new 
GUI, we have to start from scratch, and introduce something which 
is clear departure from what was achieved before? Here's few features, 
which were supported:

- cell can be ANY style (VID dialect)

- virtual columns/rows. Simply put - no need to reformat data obtained 
from some data source. Easy to switch/hide columns/row. Only pointers 
to data moved, no need to reformat data, easy to submit back to db 
backends, without the need to reformat the data again

- hilighting - row or cell or cell + row, full keyboard navigation
- horizontal scrolling
- ultra fast, unlimited amount of records


In the past (1998) we bought a product called GridPlus for our CA 
Visual objects. It was few thousands of lines of code, but it just 
smashed any other grids from Delphi, etc. Ditto for DOS era - EzBrowse 
- it even allowed to freeze columns, save set-up of grid plus filters 
for particular windows etc. I have very good idea what kind of functionality 
should grid allow.

R2/View starts at 7.4MB here. And running RebGUI Tour.r (containing 
all styles), goes to 16MB. R3 starts at 2.4MB, running all-styles.r3 
goes to 11.8 MB

NLPP 2.0 is R2 and RebGUI based.

The timing is bad, as NLPP 2.0 has already been in development since 
early 2011 and it's almost leaving alpha development. Furthermore, 
there is a lot of development time invested in some special RebGUI 
widgets for NLPP and converting this work to R3 would take a significant 
amount of time.

Are the RebGUI widgets being released?

ah, so it might be just a separate package,like RebGUI is to VID 
... yes, that's possible too ... we just did not want to have many 
GUIs available. But R3 GUI is in limbo anyway, so ....

I have a RebGUI application of some hundreds of screens and sadly 
it is not very brisk these days presumably due to GC occurring at 
inconvenient times, or just using too much ram.  Any stress testing 
down with R3GUI with hundreds to screens?

no, the app we build has about 12-15 windows, and we are using a 
different branch of RebGUI with our own fixes.

maybe i wasn't clear. Sorry i readed my post and some things appears 
not to be clear anough... 


1) Rebol runtime environement already exists that's the VM you install 
on your computer when you want to run scripts 

But a) it's not called a runtime environement  b) it's need disappears 
when you use REBO/SDK to "hide" your industrial secrets or when you 
don't want on purpose the client to install or know that  it's rebol 
behind.


2) by speudo compiling (byte code compilation) you allow people that 
need it to be a step closer to the hardware but keeping the portability 
effect so a rebol VM in my opinion should be able to  run both  a 
speudo binary file or a text script rebol file. Of course  like in 
java people would feel the need to share their software with embeded 
 Rebol Runtime Environement.


3) Having a runtime environement is the best modular way ...  core 
will be the base then you have View and lot of othe modules that 
wil clip to rebol. for example if i  put  import  "oracle" at the 
begining of my script then rebol runtime environement knows that 
he need the oracle package and goes to rebol.com to retrieve it and 
install it to the proper rebol runtime place in order for the vm 
to find it. Something close to what apt-get is to debian. REbol Environement 
doesn't comes with the whole thing but if the script tells it he 
can expend it selves in the fastest way. Well this runtime organisaton 
in  fact already exists but it's not pushed to it's extend, you know 
the point where the good idea become the best idea. the rebol/view 
2 implies a /desktop which implies a local scrit library (like a 
cache) to store the rebol script see the idea is there but once again 
it's not pushed to it's limits. Only rebgui used this system to store 
an extension to rebol.


4) by being closer to what people extend as an output you make them 
interessted in your input . To be more explicite by giving to peope 
what they are used to get in the end of their creation process then 
you allow them to be confident in your solution and to be more interressted 
on the way you propose to build your software.


5) i took java and .net as main example but if you look closely this 
is an expending tendency. For example Adobe Flash do that.


6) the other interrest in the compiled way is to merge the source 
code and the related resourcies at the same place (1.exe  file for 
example) and then forbiding the people to change their contents ... 
and this leaded then to the skining my application modo. Wich is 
just the we don't merge in the resulting binary the resourcies . 
In rebol we can already easyly build a script merger with data to 
output a .r file containing both but then people can still extract 
the ressourcies and change them etc...

(i have rebgui, cheyenne, vid-ext, rebdb, host-kit, musiclessonz, 
power-mezz, glass, r3 gui in this folder. ~500 files)

do we have to buy rebol source code from carl like it was done from 
neogeo by blender ? if that the case I'm ready to give to taht purpose 
one moth of salary in full this is how commited I am to rebol cause 

I like rebol I always liked it and will always like it ... I'm just 
extermely sad that we can't organise a proper stuff to make rebol 
the gran scripting language it deserves to be 

We lack comitement we lack seriousnes and sorry to tell you this 
but rebol shouldn't be our hobby it should be our reason to very 
live 

You guys should be ashamed to see so much people leaving this community 
and instead of smugging them and ignoring them YOU (yeah you !  don't 
force me to call you by your name !) should be an offering  force 
to create main project AND WORK WITH THE OTHERS to make rebol something 
noticeable not just something to fill your spare time !

you shoudl be ashamed of this ... common are you so blind that you 
see rebol being abandonned and deserted more and more  RMA is faaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaar 
zillion light years of being as community moving as RebGUI and the 
main reason is that by abandoning REbGUI you slaped us in our faces 
and know what we don't like that we don't like the gurus selected 
fews we don't like RMA we don't like what rebol has become and the 
one more hating is is carl sassenrath  himself  we forced his hand 
to give us more  freedom and more action on rebol and WE WASTED IT 
purely and simply 


Then all we ever standed for is futile and void ... and what I see 
here is stupid comments about a dead product that it's main own and 
only author abandoned .

Instead of giving bucktracks that will never been read or take in 
considaration please the remaining of you the rebol community TAKE 
ACTION !!!

If you hate me if you dispise me then this is your chance to prouve 
me wrong and make miserable ! cause hey the mniserable ones til now 
are you the stupid tens thousand bugs founders that will never find 
a solution cause the main guy to  implement those fixe is gone since 
november 2010

focus on one and single project do what RMA wasn't able to do ... 
and if to acheive that you have to make cyphre Robert and the other 
RMA members myserable just do it ! do a freaking r3gui that can hold 
a candle to was rebGUI was and is ! so far you are just fucking sploiled 
child and I hate you  sooooooooooo much .  you were given everything 
I never had, the fame the confidence the spot light  the ears of 
each and everyone and what you do out of that  ????!!!  nothing ! 
 you let carl to totally toy you !

Regarding the translation functions: yes, the directives do not suffice 
to supply all the necessary functionality. Other code is needed to 
handle the run-time translation of "marked" strings. That code was 
written by Cyphre and is influencing the behaviour of RebGUI widgets 
to show the currently required language version of the text.

btw - can Tortoise SVN be used as a GIT client, or is that something 
different? I like how I upgraded RebGUI - what was the system RebGUI 
used based upon?

I just wonder - if SVN worked for RebGUI, would not it be sufficient 
for R3 too?

It didn't really work for rebgui ...