AltME groups: search
Help · search scripts · search articles · search mailing listresults summary
world | hits |
r4wp | 235 |
r3wp | 2632 |
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 / 2867 | 1 | 2 | 3 | 4 | 5 | ... | 12 | 13 | [14] | 15 | 16 | ... | 25 | 26 | 27 | 28 | 29 |