• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

AltME groups: search

Help · search scripts · search articles · search mailing list

results summary

worldhits
r4wp235
r3wp2632
total:2867

results window for this page: [start: 1301 end: 1400]

world-name: r3wp

Group: !RebGUI ... A lightweight alternative to VID [web-public]
Graham:
25-Feb-2007
Yes, I know that might defeat your design objectives for the gui 
:(
Henrik:
2-Mar-2007
not being able to use exactly the color you want, could cause problems 
if you are trying to match a specific color in the background of 
your GUI.
btiffin:
3-Mar-2007
I haven't delved to deep.  The last cut of RebGUI I pulled out of 
svn causes a segmentation fault on my Debian Etch RC1 system.

>> do %tour.r
Script: "RebGUI widget tour" (16-Feb-2007)
Script: "RebGUI system" (18-Feb-2007)
>> q
Segmentation fault
[blue-:-dev]:~/gui/rebgui$

Note I did nothing other than start tour, and close it

REBOL/View 1.3.2.4.2 16-Mar-2006 Core 2.6.3

[blue-:-dev]:~$ uname -a

Linux dev 2.6.18-4-686 #1 SMP Wed Feb 21 16:06:54 UTC 2007 i686 GNU/Linux

Just so ya know.
Robert:
10-Mar-2007
I have never been asked about non-OS like GUI (I think that's what 
you mean). They like the app and it's simple design.
Graham:
3-Apr-2007
Now I have hundreds of these requesters coming up 


The file framework/libraries/gui.r was modified locally and a new 
version from the server is available. Do you want to create a backup-copy 
of the local file?
Robert:
6-Apr-2007
actions: We have added a RESET-ACTION. With this I can call something 
like my-form-gui/reset and it will reset all contained widgets to 
some default values. IMO a must have and keeps default values etc. 
near the widget, the source of information.
Graham:
14-Apr-2007
I basically wrapped a gui around other peoples' code :)
Ashley:
16-Apr-2007
I've wrapped both in a gui-error/continue test which will write out 
diagnostic information to %error.txt but ignore the error.
Graham:
21-Apr-2007
it violates gui principles if you claim the ability to insert at 
the caret, but it inserts elsewhere
Graham:
21-Apr-2007
I'm putting a  gui-error/continue around the caret handling in area
Robert:
13-May-2007
I18N: We have written an own I18N system, that can handle all UI 
aspects dynamically. Table columns, drop-list data etc. Works very 
well. And it can be used not only inside GUI stuff but through the 
whole code.
Terry:
22-May-2007
After looking at all of the various UI for Rebol that's currently 
available, and although they are all great in their own right, I 
can't help but think there's something missing.  I've found the rebol 
mashups I've done using Javascript, HTML, CSS and Flash.. to be so 
much more flexible, and of a higher quality... perhaps not in things 
like speed etc., but when it comes to eye-candy, View, and all of 
it's GUI libs come in third at best.


If you're running windows.. take a look at RASH.. a simple blue button 
that floats on top of all your other windows.. click it, and a panel 
pops up.. 

It uses Flash as the UI.. and it's really quite easy to tie Rebol 
into Flash..  and you can do it with core. Why there isn't more Flash 
/ Rebol mashups is weird
Ashley:
22-May-2007
when it comes to eye-candy, View, and all of it's GUI libs come in 
third at best

 ... I'd exclude View from that statement. With AGG support built-in 
 it enables you to be as creative as you want; the fact that no-one 
 has built a nice Konfabulator-like dialect that uses View to its 
 full potential is another issue.
Maxim:
23-May-2007
 the fact that Konfabulator-like dialect that uses View to its full 
 potential is another issue.


did you look at (short on time, cause everyone else was late ;-) 
 elixir devcon session ?


that just what it is...  100% AGG gui engine... with full AGG element 
based interaction and per stroke feel.
Graham:
1-Jun-2007
This is more of a general question on gui design... but should one 
keep all buttons on screen, or, provide buttons as required?
Louis:
22-Oct-2007
In the following script I would like to be able to click on a row 
of the table to populate the data entry fields, so that I can edit 
the data for the record displayed in that row. How do I do that? 
 

rebol []
do %sqlite.r
do %rebgui.r
unless value? 'ctx-rebgui [

    either exists? %rebgui-ctx.r [do %rebgui-ctx.r] [do %rebgui.r]
]
set-colors
tab-size: 120x55

fonts: reduce [font-sans-serif font-fixed font-serif "Courier New"]
if not exists? %id.txt [write %id.txt 1]
either not exists? %indodex.db [
    CONNECT/create %indodex.db

    SQL "create table base (ID, Title, Nama, Alamat, Kota, Propinsi, 
    Telefon, Handfon, Fax, Email, URL, Tgl_Nikah, Nota)"

    SQL "create table birthdays (ID, Nama, Jenis, Hubungan, Tgl_Lahir, 
    Agama, Nota)"
][
    CONNECT/flat %indodex.db
]

do show-cc: make function! [] [
set-colors
(i: to-integer read %id.txt)
label-width: 19
f-width: 59
display "IndoDex Ver. 1.0.1" compose/only [
            button-size 16x8
            margin 1x1
            space 1x1
            ;image %roladex.jpg 
            ;return
            label 7 "ID:" id: text (to-string i) 7
            pad 17
            ;label 13 "Nama:" 

            title: drop-list 30 #W "Pak" data ["Pak" "Ibu" "Sdr." "Sdri." "Drs." 
            "Dr." "Tuan" "Nyonya" "Nona" "Pdt."] 17x5
            nama: field f-width
            label label-width "Telefon:" 
            telefon: field f-width
            label label-width "Handfon:" 
            handfon: field f-width
            return
            pad 31
            label label-width "Fax:" 
            fax: fax: field f-width
            label label-width "E-Mail:" 
            email: field f-width
            label label-width "URL:" 
            url: field f-width
            return
            pad 31
            label label-width "Alamat:" 
            alamat: field f-width
            label label-width "Kota:"
            kota: field f-width
            label label-width "Propinsi:"
            propinsi: field f-width
            return
            pad 31
            label label-width "TglNikah:" 
            tgl_nikah: field f-width
            label label-width "Nota:" 
            nota: field 139
            return
            return

            t: table options ["ID" left .03 "Title" left .04 "Nama" left .2 "Telefon" 
            left .16 "Handfon" left .14 "Fax" left .14 "E-mail" left .15 "URL" 
            left .15] data (sql "select id, title, nama, telefon, handfon, fax, 
            email, url from base") 270x150 
            return
            button "Add" [
                either all [nama/text <> "" nama/text <> none][

                    SQL reduce ["insert into base values (?, ?, ?, ?, ?, ?, ?, ?, ?, 
                    ?, ?, ?, ?)" id/text title/text nama/text alamat/text kota/text propinsi/text 
                    telefon/text handfon/text fax/text email/text URL/text tgl_nikah/text 
                    nota/text]

                    insert t/data SQL "select id title nama alamat kota propinsi telefon 
                    handfon fax email URL tgl_nikah nota from base"

                    ;a: sql/flat "select id/text title/text nama/text alamat/text kota/text 
                    propinsi/text telefon/text handfon/text fax/text email/text URL/text 
                    tgl_nikah/text nota/text from base"
                    ;sql reduce [insert table/data a]
                    id/text: form i: i + 1
                    save %id.txt i
                    clear-text nama
                    clear-text alamat
                    clear-text kota
                    clear-text propinsi
                    clear-text telefon
                    clear-text handfon
                    clear-text fax
                    clear-text email
                    clear-text url
                    clear-text tgl_nikah
                    clear-text nota
                    ;show id
                    t/redraw
                    return
                ][
                    alert {Cannot save if "Nama" field is empty.}
                ]
            ]
            button "Update" []
            button "GUI Info" [

                print [id/text " " title/text " " nama/text " " alamat/text newline]
            ]
            button "DB Info" [
                print [TABLES newline]
                SQLite/col-info?: true
                newline
                print [SQL "select * from base" newline]
                print [SQLite/columns newline]
                print [ROWS "base" newline]
            ]
            button "Halt" [
                halt
            ]
            button "Quit" [
                quit
            ]
]
]
do-events
DanielSz:
13-Nov-2007
My rebgui UI gets unresponsive while some code is running. Since 
rebol doesn't have threads, I wonder what solution you'd recommend. 
Does the trick of assigning a rate of 0 to a GUI element work in 
RebGUI? Or would you perhaps separate the offending code and use 
"launch" to run a separate rebol process? Or maybe you know some 
other magic that I don't?
DanielSz:
18-Nov-2007
Ashley, this is to express my thanks for rebgui. It is wonderful, 
and a *huge* relief from VID. I spent the week developing a GUI for 
a pet project of mine. Great documentation. Great demo. Great syntax. 
Pure enjoyment!!!
Luis:
19-Nov-2007
I want write a chat system. 

 RebGui provide me the client gui. Somebody knows a chat server with 
 history?
(synapse-chat server source code is not available)
GiuseppeC:
13-Dec-2007
I have taken a deep look at the GUI System available for Rebol I 
and my choice has gone to RebGUI. I have taken a look to to list 
VIEW project too and I have a request/proposal: why don't you merge 
the list view into RebGUI. It is really very powerful, much more 
the standrd lists available in RebolGUI. It woul be an huge improvement 
and we will have a GUI system on steroids for DB projects.
Robert:
24-Dec-2007
I see your point and I totally agree. On the other hand doing a real-life 
full-fledged application requires most of the time more than just 
a basic widget.


What I found out is, that most simple widgets are ok from a GUI POV 
but not in these areas:
- storing / saving widget state and user-data

- be programmatically controlable (like setting a tree to a specific 
state, hiding stuff, setting sort-oder etc.)

- implement always returning usage patterns in a more programmer 
convinient way

- using a common approach for specification (nested blocks, key/value 
pairs etc.)
Robert:
24-Dec-2007
And those things make widgets quite big. I would bet that for complex 
widgets 75% of the code is not GUI related.
Pekr:
24-Dec-2007
Ashley - by your aproach though, RebGUI will be first class REBOL 
gui toolkit for some time, but always second league to any normal 
toolkit. I can't agree to ANY kind of simplification, it is just 
does not deliver what normal OS user is used to. It is surely fine 
to keep simplicity and maintainability in mind, but we should be 
real - who cares if widget has 1 or 100KB? I don't, and what end 
users will judge is only comfort of usage.
BrianH:
24-Dec-2007
This is a GUI framework, not an app. You have to add code to a framework 
to make an app anyways - it's not any different to add other GUI 
controls. I realize that intregration is a process in itself, but 
it can be done, and sometimes it is simpler than rewriting the code 
yourself.
Reichart:
25-Dec-2007
Yeah, I was thinking about adding or not adding that (X-Internet), 
but it really is nice to tie them together, since otherwise (in an 
era of Web 2.0) it is not clear what this GUI is actually used for. 
 We suffer this a lot in the Rebol community, assuming people know 
what the hell is going on, and what something "is"

What you are describing is…er, well, Quilt.

Again, this is why we have to slowly move towards each other.
Ashley:
31-Dec-2007
Providing keyboard support for inherently graphical controls (e.g. 
radio-group, spinner, etc) is IMHO a waste of time. All the main 
input widgets (field, edit-list, area, sheet, etc) should and do 
have proper keyboard support. If you're designing an application 
for fast data entry then you should confine your widgets to those 
that accept keyboard input (i.e. data entry forms). If you want a 
rich GUI with a full set of graphical widgets then I don't think 
it's too much to ask that users have a pointing device. I mean, you 
don't expect users to use Windows without a mouse? Or Office type 
applications?


But, list away as I'm currently doing major code fixes (better scroll-wheel 
support for one) anyway; if it's relatively straight-forward to do 
I'll do it.
Graham:
31-Dec-2007
what do other gui's do?
Graham:
18-Jan-2008
If a gui pops up, perhaps a key combination could be used to make 
a selection
JohanAR:
6-Mar-2008
I'm having some trouble that I was hoping you could help me with.. 
again :)


I want to have a tab in a tab-panel that contains some kind of group 
block and a button. Every time the button is pressed the group block's 
contents should change to a new, dynamically generated, GUI block.


It works up to the part where the button is pressed, but the group 
block is never changed.
JohanAR:
6-Mar-2008
I can add that the dynamically generated GUI consists of a mixture 
of texts, fields and another button. When that button is pressed 
all fields are evaluated and possibly modified.
Henrik:
15-Jun-2008
probably a little bit, since you can select what to include. I suppose 
VID can be removed if RebGUI is going to be the GUI for the application.
BrianH:
23-Jun-2008
I'm not aware of any R2 GUI framework that is not a memory hog, but 
my standards are probably off.
btiffin:
5-Sep-2008
Kinda ... maybe ... it might be a start; check out http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=rebdbgui.r


It's a sample I wrote for someone a long time ago.  It links the 
GUI fields to a RebDB database.  One way of doing it anyway.
Louis:
8-Sep-2008
What I want to do is populate the gui table with all the data in 
the SQLite projects table.
Graham:
22-Dec-2008
I've got three vertically left aligned group-box's and I'm sizing 
them the same by using absolute sizes to also right align them.  
But this means I can't use different gui sizes because then the contents 
of the boxes can exceed the group-box.  But if I use automatic sizing 
using -1x-1, then I can't get both left and right sides of the group-boxes 
to align ... or can I??
Pekr:
23-Jan-2009
it is imo not question of particular GUI system, but the question 
of widgets available. That is why I also wanted split-screen, resizable. 
But - those issues are not RebGUI related, so we are most probably 
chatting in wrong group ...
GiuseppeC:
6-Apr-2009
Ashley, one question. As you have created the best GUI solution for 
REBOL2 I ask to myself why your still not involved in REBOL3 GUI. 
Are you waiting the final VID version to port your great experience 
in this area ?
Ashley:
13-Apr-2009
Hi Giuseppe, I'll respond in full to your questions here as I've 
had quite a few emails recently asking similar questions about the 
future of R3 and RebGUI.

As you have created the best GUI solution for REBOL2

 ... Thanks, remember that "best" is in the eye of the beholder though 
 ;) ... RebGUI was created only because VID wasn't up to the task.

I ask to myself why your still not involved in REBOL3 GUI.

 ... Apart from the fact that I cannot give the project the time it 
 requires, the R3 GUI is in far more capable hands than mine. I'm 
 looking forward to it making RebGUI obsolete! ;)


Are you waiting the final VID version to port your great experience 
in this area ?

 ... When the R3 GUI is stable I'll look at how best to port apps 
 from RebGUI to it. I'm thinking either a compatibility layer or an 
 outright script conversion utility. But while we wait for that glorious 
 future (stable R3/GUI SDKs on Windows, Mac and Linux) RebGUI is still 
 the only R2/GUI game in town (IMHO).
Graham:
14-Apr-2009
This isn't strictly a Rebgui question ... but here goes.  I want 
to double click on a word and perform an action.  That action involves 
interacting with some gui elements on the current screen.  Now, there 
is a function 'hilight-text inside the rebgui 'edit object which 
is inside the rebgui-ctx context.  So, I can hook in there with my 
dbl-click function.  But how to make it call my function which is 
defined for each window?
Graham:
20-Apr-2009
Actually I was just thinking of allowing users to use a gui to enter 
numbers into fields ...but why not use a calculator requester for 
that?
Pekr:
10-May-2009
I do understand your point of view, which is - you try to keep Rebgui 
to its original idea. But - VID styleset is not real alternative 
to R2 GUI navadays, so refusing more complex widgets, especially 
in the case where noone really pushes anyone to use them, is escaping 
my understanding.
Louis:
30-May-2009
The problem I have with GUI programming is that I don't know how 
to find bugs.  How do you guys do it?
Ashley:
31-Jul-2009
changed from single color web like look to some W9x look, was there 
any reason?
 ... commercial reality ;)
where would I have changed the font?
 ... ctx-rebgui/effects/font
request-char somehow misbehaves here
 ... bug, noted
fonts must be handled differently in w7s

 ... I don't have access to W7 at home, but will check this Monday 
 at work
where do I set my UI options?

 Design time with ctx-rebgui/effects, /colors /behaviors and /sizes

 Adding request-ui back so you can alter these values from a GUI is 
 trivial ... what I've removed is the rebind logic that enabled you 
 to dynamically change values (i.e. you would have to re-do %rebgui.r 
 to see any UI changes take effect ... not very practical for an SDK 
 app)
they look like W9x

 ... the color scheme (with the colors/page change noted above) is 
 taken straight from W7
don't like gradiented buttons/tab
 ... based on W7 and Mac
I thought Ashley wanted to go more web way, not desktop app way

 ... I've actually gone for something halfway (simpler than OS, more 
 complex than Web)
is it using a smaller font?

 ... 12pt by default as always (maybe W7 renders it differently than 
 XP?)
everything seems much smaller
 ... bigger screen? ;)
I would welcome tour.r would fit 1280x800 notebook

 ... RC1 is about getting the basic functionality right, %tour.r and 
 %RebDOC.r will both be made to run 1024x768
used to fit
 ... they havn't been reworked yet
Windows XP with 1366 x 768 ...
 ... will be fixed with above
Ashley:
9-Aug-2009
Build 207
- Fixed slider bug (zero divide error when ratio = 1)
- Added find-key-face to needed funcs when not using view.r
- Added undisplay (does what unview/only does, but better)
- request-error now accepts string
- Removed gui-error (obsoleted by request-error)
- Removed find-face func
- Cosmetic changes to:
	- led
	- led-group
	- radio-group
	- chat
- Removed tip & over? attributes
- Made init, options & old-color attributes optional
- Made action & feel objects optional

- Replaced rebface, subface, gradface & btnface with baseface & gradface
- Added over? function
- icon changed to accept file name directly

- Added action/on-time event (used in conjunction with rate - see 
anim)
- Added table & text-list alternate row coloring
btiffin:
25-Aug-2009
re append-widget; close to ditto Graham, but I now use append-widget 
when I need to link RebGUI fields to persistent RebDB store.  Well 
it's a general purpose data-field widget that can stash code in the 
data (RebGUI keyword) attribute of the gui widget.   See http://www.rebol.org/view-script.r?script=rebdbgui.r
for a (very ineffficient) sample I posted way back when when someone 
asked for a way of getting persistent RebGUI fields.   Used to be 
the same for an overlay panel, but Ashley put in the 'no-tabs option 
for tab-panel and my copy was sent to a shallow grave as the hack 
it was deserved.
Pekr:
11-Sep-2009
Why RebGUI uses request-file non-native requestor? For more GUI consistency?
Ashley:
15-Sep-2009
Why RebGUI uses request-file non-native requestor?
	- GUI consistency
	- speed
	- functionality
	- native requestor is broken on OS X

Can editor's position/size be set?

 - I can make the default smaller, what's your notebook screen res?

 - I'll probably add a /size refinement as well (I can see how you 
 might need a small or large editor in certain situations)
Pekr:
28-Sep-2009
Apart from that, let's hope that in few months, we are back to R3 
GUI, and that is where the most of interest of outer community is 
going to be ;-)
Carl:
28-Sep-2009
Yes, R3 GUI is very important to me as well.  The question is...
Ashley:
30-Sep-2009
re: dobeash.com
	- transfer of domain OK
	- ftp of backup content to domain OK
	- http access ... not working ... will investigate

R3 GUI is very important to me as wel
 ... ditto!!!


All these changes appear to have degraded the usability of rebgui 
somewhat

 ... remember that these are development builds, only accessable via 
 SVN. I was hoping to stabalize and "release" by end of this month 
 (September), but the domain issues I've been having have probably 
 pushed that back a month.
Ashley:
22-Oct-2009
re: RebGUI and R3/VID. I'll probably put something up on my website 
on this topic as I get asked this quite a lot. Basic thinking at 
this stage is:

	I need to create SDK GUI apps for Windows and OSX
	R2/RebGUI is the only practical alternative at present for *me*
	I'd love to use R3/VID to create SDK GUI apps today
	This probably won't be possible for quite some time

 If and when this *is* possible I'll port all my apps over to R3/VID

 To do this I'll either create a compatibility layer that lets RebGUI 
 apps run on R3/VID, or

 Write a conversion script that tries to convert (if possible) RebGUI 
 scripts to R3/VID

 I'd hope R3/VID is complete enough that it doesn't require any of 
 RebGUI's basic widgets!
jack-ort:
24-Feb-2010
Hi!  maybe I should ask this in the "I'm New" group.  Wanted to try 
out RebGUI for my 2nd REBOL project.  I'm stuck early on trying to 
refresh a table based on a SQL query in a parent window when closing 
a child window that would have added a record to table.  I've gotten 
the examples on click and away events to work, but do not understand 
how to use focus events apparently.  Can someone point me to some 
sample code that would help w/ moving focus from window to window 
and refreshing tables?  With that, I think most of my GUI problems 
would be solved. 

TIA!  -Jack
jack-ort:
25-Feb-2010
Ashley - that got me started, but where I get stuck is on the syntax 
to refer to a widget *in another window*.  In the sample below, I 
want my "Save" button to not only write a new record to my SQLite 
db, but also to refresh the query that loads the table in the parent 
window (OR, can I refresh the parent window table after the child 
window closes and the focus returns to the parent?  I cannot seem 
to trigger any focus events.).  I was trying to wrap my windows in 
objects, which are new to me also, so I'm sure that is part of my 
problem.  Obviously my attempt to refer to my table by this path 
(adddelusers/gui/tbl/data) is incorrect, since I get this error:

** Script Error: Invalid path value: tbl
** Where: on-click

** Near: insert adddelusers/gui/tbl/data (sql/flat "select * from 
users order by userid") adddelusers/gui/tbl/redraw

adddelusers: context [
			title: {Add/Remove Users}

   tbldata: copy esql/rtn [sql/flat "select * from users order by userid"][]
			gui: [

    tbl: table 125x50 options ["UserID" left 0.2 "Password" left 0.8] 
				return
				button "Add User" 30 on [
										click [display/parent adduser/title adduser/gui ]
									]
				button "Remove User" 30 [alert "need to add code here..."]
						]	
]

adduser: context [
		title: {Add User}
		gui: [	
				user:	field text "username" return
				pwd:	field text "password" return

    button "Save" [sql compose ["insert or replace into users values 
    (?,?)" (to-word user/text) (to-binary checksum/secure pwd/text)]

         insert adddelusers/gui/tbl/data (sql/flat "select * from users order 
         by userid") adddelusers/gui/tbl/redraw
								unview adduser/gui ]
				button "Cancel" [unview adduser/gui]
		]
	]
jack-ort:
25-Feb-2010
Ashley - that got me started, but where I get stuck is on the syntax 
to refer to a widget *in another window*.  In the sample below, I 
want my "Save" button to not only write a new record to my SQLite 
db, but also to refresh the query that loads the table in the parent 
window (OR, can I refresh the parent window table after the child 
window closes and the focus returns to the parent?  I cannot seem 
to trigger any focus events.).  I was trying to wrap my windows in 
objects, which are new to me also, so I'm sure that is part of my 
problem.  Obviously my attempt to refer to my table by this path 
(adddelusers/gui/tbl/data) is incorrect, since I get this error:

** Script Error: Invalid path value: tbl
** Where: on-click

** Near: insert adddelusers/gui/tbl/data (sql/flat "select * from 
users order by userid") adddelusers/gui/tbl/redraw

adddelusers: context [
			title: {Add/Remove Users}

   tbldata: copy esql/rtn [sql/flat "select * from users order by userid"][]
			gui: [

    tbl: table 125x50 options ["UserID" left 0.2 "Password" left 0.8] 
				return
				button "Add User" 30 on [
										click [display/parent adduser/title adduser/gui ]
									]
				button "Remove User" 30 [alert "need to add code here..."]
						]	
]

adduser: context [
		title: {Add User}
		gui: [	
				user:	field text "username" return
				pwd:	field text "password" return

    button "Save" [sql compose ["insert or replace into users values 
    (?,?)" (to-word user/text) (to-binary checksum/secure pwd/text)]

         insert adddelusers/gui/tbl/data (sql/flat "select * from users order 
         by userid") adddelusers/gui/tbl/redraw
								unview adduser/gui ]
				button "Cancel" [unview adduser/gui]
		]
	]
Graham:
25-Feb-2010
If you're going to try and encapsulate inside a context, why not 
provide the method to update the gui inside the context?
Ashley:
23-May-2010
what is your status re RebGUI and its future?

 ... RebGUI does most of what *I* need it to do at present, but I'd 
 really prefer to be using R3 + SDK + Cool looking R3 GUI. I'm experimenting 
 with a minimalist GOB-based R3 GUI, but it's more an intellectual 
 pursuit to see how minamalist (and functional) I can get it ... so 
 don't hold your breath.
Gregg:
21-Aug-2010
VID is the native REBOL GUI dialect. If you're just getting started, 
and doing basic UIs, it's worth a look.
Awi:
15-Jan-2011
Sorry for reporting only bugs, I like the 2.x series so much, it's 
much faster, no slow scrolling, I do really hope this version gets 
stable and usable. Currently it's the only usable GUI for me with 
nice graphic.
Awi:
17-Jan-2011
I also assumed that since like 2008 :-) Some things like this project 
cannot wait, and RebGUI and Rebol2 are more than good enough for 
almost every case in my project. And I think if Rebol3 and r3-gui 
are out someday, I'll just rewrite my apps.
Endo:
1-Nov-2011
This shows the problem more clear:

gui-table/add-row ["a" "b" "c"]
gui-table/redraw ;works ok

b: copy gui-table/data

clear gui-table/data
gui-table/redraw ;clears the table

gui-table/data: copy b
gui-table/redraw ;shows nothing


There is something related directly to the DATA block inside TABLE 
functions I think.
Group: !REBOL3-OLD1 ... [web-public]
Pekr:
27-Mar-2009
Hmm, isn't jus alpha transparency enough? Why to do any shape detection? 
We just need the ability to define level, which will let events to 
go to underlying faces, just like Amiga DE did it. And if you look 
at Cyphre's irregular window shape, you will see, that it simply 
is not rectangular, or is it?

do http://www.rebol.cz/~cyphre/trans-gui.r
Claude:
2-Apr-2009
what about the gui upgrade & performance  with table ?
Henrik:
2-Apr-2009
you can still follow my screenshots at http://rebol.hmkdesign.dk/files/r3/gui/
BrianH:
2-Apr-2009
The R3 GUI is class-based with dynamic inheritance (and switchable 
classes), so you can be sure that we will make that fast.
Maxim:
2-Apr-2009
btw, I'm really sorry if I'm not participating in the R3 GUI effort... 
I'm just elsewhere in the GUI world... what you guys are doing, I've 
done so many times, on too many platforms, for it to be still *fun*.


a lot of people don't get that I use (and occasionally abuse) rebol 
for my own long-term goals.  its just the fastest prototyper out 
there.  Now that GLASS has officially started, the (eventual) end 
goals for it are sort of beyond current desktop/window/button/menu 
 concepts of GUI, even if that is what I am starting with, cause 
I need the bricks before building the wall.
BrianH:
2-Apr-2009
Keep in mind that I am not really participating in the R3 GUI effort 
right now either - I've been working at a lower level. I write LOAD 
:)
Pekr:
2-Apr-2009
Maxim - you have strange aproach. On one hand, you claim you did 
GUI and object stuff so many times it is no more fun for you, but 
on the other hand you complain, that R3 does not allow OOP functionality 
x or y?
Maxim:
2-Apr-2009
I didn't say I did object stuff many times, only the gui part of 
things.  I've been implementing gui apis for like 15 years, at various 
levels... all with the end goal of getting to GLASS.
Pekr:
2-Apr-2009
... there is very few ppl contributing. Most of guys from here being 
invited to R3-gui showed no real input to Carl.
ICarii:
2-Apr-2009
re contributing to 3.4 GUI - in the beginning I did testing and some 
creating but it became frustrating creating controls/widgets by always 
working around the various gotchya's that I decided to test only 
and wait for beta until trying to create complex widgets.  In the 
meantime i'm toying with my old onyx system and converting it to 
use geomal's GLServer.  I program for fun these days and if im not 
having 'fun' i move on to something that interests me more.
BrianH:
3-Apr-2009
I've been the main writer of the non-GUI mezzanine changes for thhe 
last year. My code tends to be more strict than Carl's :)
Pekr:
8-Apr-2009
Geomol - I have to object. Before complaining about the way the projects 
is run, please check the following:


 - do you really understand, how the project is being run at all? 
 Because quite frankly, you are not using fair arguments here imo. 
 I can agree, but only to some extent, that things are being done 
 in a chaotic way. But - being close to Carl and trying to listen 
 to him and COMMUNICATE with him, I can understand the aproach he 
 takes. 


- one of your false arguments is, that putting things into CureCode 
is not helpful - CureCode was chosen by Carl and the community as 
a streamlined channel for bug reporting. Now please don't tell me, 
that even some low level bugs are not reported? There is a changelog 
which simply proves you being wrong.


- Before some releases Carl asks BrianH to change CureCode items 
rating to fix most important stuff - so how comes that our aproach 
does not work? Please post bug reports, talk to Carl or BrianH to 
raise the importance - doesn't following section show we finally 
got our requested - release early, release often?
http://www.rebol.net/wiki/R3_Releases


- and to be honest - you are one of persons being added to the r3-gui 
world. Some time back Carl had to add even lamer like me to the list 
:-) - and you know why? Because he was not getting much of response. 
He nominated top community gurus to help with the GUI. Actually, 
the same happened during the Gab's VID3 project - only me, Henrik, 
and BrianH commented. It seems to me that some ppl prefer to chat 
about science and belief systems instead of helping to develop R3 
;-) (I am not dismissing anyone's right to come here to chat about 
anything - this place is really a rebol pub where we meet, but the 
other worlds were specialised, yet lacked the input from community, 
even if asked for help)


- in order to get more ppl involved in R3 development at native level, 
it is clear where do we need to get - we've got R3 chat to be base 
of new Altme, new BBS, new DevBase. In March plan Carl clearly outlined, 
that in order to get sources out, we need rebin, plugins. They are 
now postponed due to modules, security, but still a high priority. 
How do I know? Because I was not lazy and asked Carl the specific 
question.


- we also get improvements on other fronts - we have got new streamlined 
Docs. I suggested Carl to add community section, then also new R3 
section to rebol.com page and to produce detailed changelogs. These 
all are small steps, but steps which make a difference.


Now please tell me - how complaining here can make situation any 
better? How many bugs have you posted, how many rebdev messages you 
have asked to Carl? Why don't you talk about your concerns with Carl? 
He will respond to you, like to me or anyone else - either via chat, 
or via a Blog article.


As for me, I am quite fine with how R3 is progressing last few months. 
Yes, we are slow on the whole project, but we are still doing a good 
progress imo.
Geomol:
8-Apr-2009
Responding to Pekr's comments:


- I've communicated with Carl privately before. Starting on the OS 
X port more than a year ago is one example. Lack of info back to 
me made me stop. It's in a group in r3-alpha, you don't have access 
to.


- About CureCode, I didn't argue, it's not helpful. I don't care, 
what bug report system is used, as long as it works. Curecode is 
one of the best such systems, I've seen. Yes, low level bugs are 
reported. That's not the problem. It doesn't make much sense to me 
to work on a building (in lack of better metaphor) at the 123 level, 
when the basement isn't stable. Question is, how long this situation 
will last, before I see a stable version across platforms. My guess 
is years, therefore my concerns.


- r3-gui. Again it doesn't make much sense to me to work on GUI, 
if the core has many bugs.


- You list many topics in monthly plan. Development is going on at 
all levels of the building. I would start by making a solid basement, 
then make my way up. Making any level finished, before going to the 
next. It's just another way of doing things. I have good experience 
doing it the way, I try to describe.


- About docs. It's about time, something is done with the docs. I 
had huge problems figuring out, even how to test R3 back in the r3-alpha 
days. Docs were confusing, lack info, etc. Some months ago I tried 
to figure out, if I could port Canvas RPaint to R3. I stopped quickly, 
when I couldn't find the docs to do even simple things.


Well, you ask, why I complain. Initially I just said, how I felt. 
Loosing faith in the project. I really hope, it'll happen one day. 
But as I see it, it'll take years. I feel like sharing this view 
with others. Then you can use it as you wish. I need to figure out, 
what I'll do with my own development.
Pekr:
8-Apr-2009
I have access to all worlds I know development went in - r3-alpha, 
r3-gui, and I of course remember your effort. It is not the time 
(yet) to do solid porting to another systems by ourselves. So far 
only Carl does some ports, bu those should be regarded being experiments.
Pekr:
8-Apr-2009
I do remember myself panicking xy times in the past. Other panicked 
too - we all arged Carl to get back to finishing Core first, then 
move forward. But Carl thinked otherwise - that R3 is good enough 
to attract new users via GUI. You all surely know, how difficult 
it is to change Carl's mind. But OTOH Carl listens to what we say.
Henrik:
8-Apr-2009
Geomol, I'm not sure why it surprises you that R3 takes a long time 
to build. It's always been difficult to determine exactly when R3 
would be considered stable. Building the GUI was a very quick way 
to expose multiple bugs of which some are solved (including some 
nasty memory related crashes).
Pekr:
8-Apr-2009
Where do I find those #60, #115 and #250 tickets? I can't see a bug-base 
in r3-alpha, just in terms of r3-gui, and those tickets don't match 
... are they in CureCode?
Henrik:
8-Apr-2009
pekr, the R3 bug database was moved to Curecode back in January. 
The R3 GUI bug database is not published, because the GUI is considered 
too alpha to keep a bug database for.
BrianH:
8-Apr-2009
Yes, chat is complex to use, though I find it more useful than AltME 
overall, even in text mode. When we get the GUI it won't even be 
harder to use. That's why we need modules - the code needs reorganization.
Pekr:
8-Apr-2009
I will go so far, that I even think that some part of the community 
became so ignorant, that making R3 fully open sourced would not change 
a bit of this situation. Some real work is needed, and ppl here complain 
that they don't have time to even scan sources of available info. 
Now tell me, how the same ppl are supposed to do any quality code 
for R3, even if it would be open-sourced? Once again - GUI is open-sourced, 
protocols are open-sourced, yet ppl don't even care to test or give 
a feedback.
PeterWood:
9-Apr-2009
PeterWood:R3/GUI/General>> more 3365

 ** Script error: submit-of? does not allow none! for its fid argument

 ** Where: case all submit-of? case what-file? more-file parse try 
 either either forever command-loop make context do catch applier 
 do try chat
** Near: case [

    is-submit? msg [msg]

    is-name? msg [submit-of?..
.

--- Note: unexpected error logged to error-log.txt
Graham:
9-Apr-2009
Maybe once we have a usuable GUI wrapped around dev chat it might 
be easier to follow what is going on ... but it's a bit of a black 
box to me now.
BrianH:
10-Apr-2009
The map! type is used extensively in the GUI, and some mezzanines. 
The MAP function's name wasn't my idea - some Haskell fan thought 
we needed a map function (true) and that it should be called the 
same thing (not REBOL-like). This came before the name of the map! 
type was chosen, and prevents us from making a proper functional 
map function of that name. At least we already had a fold-like function 
with a REBOL name: REMOVE-EACH.
Oldes:
11-Apr-2009
When you say DevBase, do you mean the R2 based with gui or the file 
sharing in R3 chat?
james_nak:
17-Apr-2009
Thanks. I was happy to see the demo gui run.
Henrik:
17-Apr-2009
Demo GUI is still the first prototype.
Pekr:
21-Apr-2009
New short doc to comment on: http://rebol.com/r3/docs/concepts/gui-layout.html
Henrik:
22-Apr-2009
On the new R3 GUI document: I think the new guides and layers concept 
will work much better, but of course it depends on the implementation. 
I've asked a range of questions in Chat to get some more information.
BrianH:
26-Apr-2009
Steeve, I can guarantee that if bugs are not reported they won't 
be fixed at all. It is completely inappropriate to compare the R2 
project to the R3 project. Bugs weren't getting fixed in the proprietary, 
release-rarely R2, but they *are* getting fixed quite regularly in 
the semi-community, release-often R3 project.


We are in alpha, and still in the design phase with much of the core 
of R3. We only have so many people actively contributing to R3, only 
so much capacity. And you might recall how much we have been insisting 
that people not use R3 in production yet, that it is not ready. This 
means that the main product that is setting the priorities of what 
gets fixed or implemented is R3 itself. And that product is still 
being built.

No regression allowed

 - are you kidding? Large quantities of R3 are brand new code. It 
 isn't regressing, it just hasn't caught up yet.


And don't assume that the code will work the same in R3 as in R2 
- we aren't even trying to be compatible with R2 except where appropriate. 
We're fixing design shortcomings in R2, not just bugs, and that means 
incompatibilities sometimes. Compatibility with R2 is considered 
a nice thing to do, but not as high a priority as doing things right, 
adapting REBOL to handle the needs of today and tomorrow.


And speaking of priorities, they are not absolute. We set priorities 
relative to what we are working on now and what we will need next. 
Once those things are done, we bump the priorities of the next things 
on the list.


We recognize that vectors are important, but they are not as important 
as security and modularity *right now*. We needed modules settled 
now because the plugin model depends on them, because it would help 
us design the security model, and because the GUI and mezzanine code 
needs organization to be further developed.


We need the plugin model because it affects the host interface design, 
and the host interface needs a redesign before we can release the 
host code. We need to release the host code so that more people can 
fix bugs like that OS X bug PeterWood mentioned.


Things are going to get fixed, but most fixes require other things 
to get done first. We are focusing now on the bottlenecks, the bugs 
or waiting improvements that are blocking the most. Right now the 
highest priorities are those that are blocking people from contributing 
to R3, because the resource we have the least of is people that are 
willing to help.
BrianH:
26-Apr-2009
The two biggest things blocking contributions:

1. We need to release the host code so people can fix platform-specific 
bugs.

2. The GUI infrastructure is just not in good enough shape to handle 
contributions, at least from a code organization standpoint.


There are people who won't participate at all because there is no 
GUI client for R3 chat (which sounds completely ridiculous to me), 
and in some cases we really need those people's help (ironically 
enough, not always for GUI work). For that and many other reasons, 
the GUI is a huge priority in the short term.


And we *really* need to release the host code, or platform-specific 
bug-fixes and enhancements won't happen.
Graham:
26-Apr-2009
There are people who won't participate at all because there is no 
GUI client for R3 chat (which sounds completely ridiculous to me), 
  

I'm suprised that so many people are happy to work with a non-gui 
client.  If one asks for volunteers to spend their time, and create 
a retro environment for them to work ... you're not going to get 
the optimal result.
BrianH:
26-Apr-2009
Don't take it personally if something sounds ridiculous to me - I 
don't consider my opinion to be common.


We needed the infrastructure in place for collaborative development. 
What we were using before (AltMe, DevBase 2, traditional revision 
control systems) had failed us - we couldn't scale past about 5 developers 
before the process fell apart. That's why the R3-GUI AltMe world 
was created.


Even in text mode, R3 chat and DevBase 3 have been a huge success, 
as the many releases of R3 in the last few months have shown. We 
needed contributions to get R3 to the point where it is now.
BrianH:
27-Apr-2009
I just see little point in submitting bugs.


If you are talking about bugs in stuff that is mostly designed but 
not fully implemented (like money!, or maybe vector!) then they are 
worth reporting if they haven't been reported already - just don't 
expect an immediate fix, since we may not be working on those yet.


If you are talking about bugs in stuff that is still being designed 
(like the GUI) then reporting problems in R3 chat is better. 


If you are talking about bugs in stuff that hasn't been designed 
yet but may have a placeholder (like task! or utype!) then don't 
bother.
Vladimir:
28-Apr-2009
Just downloaded R3-a49 release and Gui Demo is working ( text view 
isn't ) but I can't get simple window to show :(

Examples from http://www.rebol.net/wiki/GUI_Examplesare not working.... 
:(
I get missing this missing that... :(


I just want to show simple text in a window, or a button... am I 
asking to much ? :)
Henrik:
28-Apr-2009
Also the GUI is only working under Windows at this time.
ICarii:
28-Apr-2009
vlad: remember to add load-gui to your scripts
Vladimir:
28-Apr-2009
Well I downloaded r3-a49 and started it. Typed Demo, and only when 
I press View-text error happens... other parts are working fine...
Could be that missing load-gui is a problem :) oopss
Pekr:
28-Apr-2009
view-text is broken quite some time. But when you try to use your 
own gui, you really have to use load-gui first ..
Vladimir:
28-Apr-2009
Error: "cannot parse the Gui dialect at: 'ts read-string main.r button 
Huge"

And thanks, load-gui did the job :)
Steeve:
28-Apr-2009
Actualy, load-gui is not requested if you manage yourself gobs and 
events.
You just have to open the event port and add your handler into.
1301 / 286712345...1213[14] 1516...2526272829