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: 1201 end: 1300]
world-name: r3wp
Group: !REBOL3-OLD1 ... [web-public] | ||
Pekr: 29-Jan-2009 | eh? you launch demo, go few items down in text-list, select text-view, and it crashes to console with: Cannot parse the GUI dialect at: 'set ts read-string %main.r | |
Henrik: 29-Jan-2009 | the demos will of course have to be made correctly. gui-demo.r is only a launcher. | |
Sunanda: 29-Jan-2009 | you need to load-gui first. Then, don't use layout, that' sso R2. Just: view [button "press" do [print "pressed"]] | |
kcollins: 31-Jan-2009 | Graham, I think you can get a list from within the R3 alpha as discussed here: http://www.rebol.net/wiki/GUI_Example_-_View_all_styles | |
Pekr: 2-Feb-2009 | r3-alpha as well as r3-gui AltMe worlds are completly dead ... | |
Pekr: 2-Feb-2009 | .... hopefully it is an interim state, a preparation for GUI client. New chat system starts to turn being interesting - threaded discussions, user ranking, tagging, searches, secure, movement of msgs/headings (reorganisation), recently files sharing is being worked on. The long term plan is to replace Altme ... with better Altme :-) | |
Pekr: 2-Feb-2009 | yes, but with MS console crap, it is really a pain to use the chat, as you can't increase number of columns. I hope some primitive GUI comes soon ... | |
kib2: 2-Feb-2009 | As far as I've seen, there's currently no way to run a GUI script with R3 alpha. Am I wrong ? | |
Henrik: 2-Feb-2009 | kib2: that fooled me first, but type "load-gui" and you have the GUI system available to you. | |
Henrik: 2-Feb-2009 | kib2: about the GUI system, it is very far from done, so don't be too disappointed. Also we have a private bug list for the GUI alone. | |
Pekr: 2-Feb-2009 | Henrik - hopefully we are close to being back to GUI soon ... | |
Henrik: 2-Feb-2009 | Primary issues with the GUI: - Layout resizing can result in too much horizontal stretching and too little vertical stretching. - Style list is very incomplete. - Keyboard navigation is very sparse. - No rich text editing. - Skin will become more esthetically pleasing later. - Some nasty bugs in the low level graphics engine, not yet solved. What is not likely to change: - The design of the system feels very solid. Every time a change or addition is made, it's 5-10 lines of code. - Style creation process, so feel free to make your own styles. What is likely to change: - The layout engine gets new features now and then to simplify the dialect. - Popups, dialogs. | |
[unknown: 5]: 2-Feb-2009 | The GUI demo needs to be made smaller (vertical space) | |
BrianH: 2-Feb-2009 | Paul, that is the plan. The old monolithic REBOL will go away once the module system is up and running. There are already functions flagged for moving into non-default modules - especially ones that have limited use or too much overhead. But remember that we add these mezzanines so that we can use them, and many are just cleaned-up versions of code that is used in the GUI, the other mezzanines, the intrinsics, etc. We are trying to keep things as efficient as possible so that the code that is loaded by default is minimal. Still, you will have to realize that REBOL is partly written in REBOL so you can't get rid of everything. | |
BrianH: 2-Feb-2009 | The advantage to the current chat is the messages in it, not the UI. Those messages are still going to be there when the GUI client is in use, and we needed something in place to get the information out there and managed (AltMe wasn't good enough at management). However, you have once again figred ot the plan: Carl intends to run, not walk, away from using console for chat. | |
BrianH: 2-Feb-2009 | You need to ignore the UI of chat for now, because the important problem being worked on now is getting the source file database integrated so developers can see that source you were requesting. Then we will have more developers (in theory) and we can get the GUI working well enough to write the GUI chat client you also requested. Which shouldn't be that hard - all of the tough stuff is either handled by the chat infrastructure (which is mostly there now) or the GUI infrastructure. | |
BrianH: 2-Feb-2009 | If you want to help now I can get you an account on the current DevBase - be warned that the GUI is not great yet (because it's R2). | |
Janko: 2-Feb-2009 | just want to express my oppinion that I am happy of the core things beeing in focus (language, runtime, core libs (tcp...)...) not the "addons" like gui | |
BrianH: 2-Feb-2009 | I sort of agree, but most of the core bugs were discovered and fixed during the course of writing the "addons" like the GUI or non-core mezzanine functions. Most of the core language enhancements came from the GUI work too. I expect the work on higher-level port schemes will help debug the low-level port code. You need to write the high-level stuff to help refine the low-level stuff. | |
Janko: 2-Feb-2009 | most of the core bugs were discovered and fixed during the course of writing the addons" like the GUI or non-core mezzanine functions" yes, I fully agree with this and understand that higher level code tests and helps design (reiterate) the low level that it's build upon... | |
Janko: 2-Feb-2009 | but I still take decision to make chat in CLI first and not focus on GUI etc too quickly very highly. Because having a good core on which gui (or many gui-s) and all things are built seems 100x more important than having *something to show* .. a nice gui on a patched core... I appreciate the priorities and focus, and this tells me that I can rely on R3 being good. | |
Henrik: 3-Feb-2009 | Graham, an issue with 100% CPU usage every time a GUI was invoked. | |
GiuseppeC: 3-Feb-2009 | Switching from AltME to RebDev chat has been very hard for me and since I am not a core developer I will be in read only mode until the GUI version will be released. | |
GiuseppeC: 3-Feb-2009 | However I am not negative about how things are going. We finally have a pubblic alpha. an upgrade mechanism, an internal chat system. GUI is going to be developed and also documentation reviewed. | |
[unknown: 5]: 3-Feb-2009 | We already have GUI in R3 but you gotta load it first via load-gui. I know it is still in development though. | |
GiuseppeC: 3-Feb-2009 | It will be the foundation for the RebDev GUI side. Everyone seems now in the same cavern where Carl retired himself. | |
[unknown: 5]: 3-Feb-2009 | I'm not a fan of rebdev either but I view it as the catalyst for the GUI side of it. | |
GiuseppeC: 3-Feb-2009 | However we are in the middle of a big change. Once the new messaging system and the GUI will be complete the whole speed of REBOL3 will shift up again. | |
Pekr: 4-Feb-2009 | Chat system feels good. But if we do add concepts like reply to particular message, and system is no more flat, we are not able to easily handle it without GUI anymore. Some commands are changed in quick pace, some changes don't make sense to me. | |
Janko: 4-Feb-2009 | ( + if I will need gui for desktop server, rebol has lighweight software rendered gui, factor also has a gui but on windows it's opengl based which is not really practical for a gui.. even casual games on windows try to use DX7 renderer for maximum compatibitily and avoid opengl beacause of driver issues) | |
BrianH: 6-Feb-2009 | You're right, it's gone. The new GUI uses Draw for its elements, so the loss might not have been noticed. I'll check. | |
Graham: 12-Feb-2009 | Hope we get a GUI for R3 chat soon ... I find it just too hard to read it in a console. | |
[unknown: 5]: 12-Feb-2009 | I thought Henrik's R3 GUI skills would have manufactured a GUI for RebDev by now. | |
BrianH: 12-Feb-2009 | R3's GUI is missing some necessary styles for a RebDev client, notably grids. Filling in the blanks needs more programmers, so we are focussing on getting the file management portions of DevBase integrated first so we can get other people involved in the process. Priorities :( | |
Pekr: 13-Feb-2009 | ... untill there is GUI to DevBase, many ppl will prefer Altme channel for quite some time ... | |
Graham: 15-Feb-2009 | so the layout parser sets the action properties of each gui element | |
Graham: 15-Feb-2009 | the big question ... will this make making gui's harder or not? | |
Graham: 15-Feb-2009 | I still like the cleaner separation of gui from function | |
Pekr: 15-Feb-2009 | There is not just general 'do, like in R2, there is now many reactors. In order to better understand new architecture, here's some docs - http://www.rebol.net/wiki/R3_GUI... | |
BrianH: 15-Feb-2009 | Unobtrusive Javascript is based on the principle that the behaviors attached to the structure need to be optional, because Javascript might not work or be turned off. This will *never* be the case for R3 GUI behaviors, so the principle doesn't apply here. | |
Graham: 15-Feb-2009 | BrianH, how does R3 styles work? I didn't notice it on the R3_Gui page | |
BrianH: 15-Feb-2009 | (sorry, I was busy). Imagine if you took the structure/appearance separation of HTML/CSS to the extreme, and had *no* appearance code in your layouts, just behavior and structure. Put all appearance code in the styles. That's the R3 GUI. Oh, and the styles will be themable too. | |
BrianH: 15-Feb-2009 | You style styles (what other GUI systems call controls). | |
Henrik: 15-Feb-2009 | You can define the button actions as you please. If you look at this shot: http://rebol.hmkdesign.dk/files/r3/gui/180.png The 5 colored buttons are separate styles, based on BUTTON. | |
BrianH: 15-Feb-2009 | No decision yet. I call it R3 GUI. | |
Graham: 15-Feb-2009 | Anyway I hope R3G has robust keyboard handling .. for speed a mouse driven gui sucks | |
Graham: 15-Feb-2009 | The JS GUI is pretty much the de-facto standard GUI | |
Graham: 15-Feb-2009 | to give smooth GUI changes | |
Pekr: 15-Feb-2009 | Graham - what JS gui? Is there actually any JS GUI? Or are you talking about web gui in general, hence HTML, CSS, JS? | |
Pekr: 15-Feb-2009 | Graham - I think noone criticised you. But honestly - you started your description like if R3 GUI plan would need any inspiration in JS. There were many many discussions about it, and also from some docs it starts to be apparent, how R3 GUI is flexible ... | |
Pekr: 15-Feb-2009 | ... besides that, there also were some talks of R3 GUI generating some output to web .... we will see, where all this leads ... | |
Pekr: 15-Feb-2009 | No need to reopen the discussion, but the thing you wanted was to separate gui description (elements and its placing, look) from the action code? | |
Graham: 15-Feb-2009 | So, one person could design the gui, and another could design the functionality | |
Pekr: 15-Feb-2009 | There is surely still time to talk about those things for R3 gui. | |
Pekr: 15-Feb-2009 | While basic concepts are in place, there still might be room to allow many things. R3 gui is really very flexible ... | |
Pekr: 15-Feb-2009 | You will be able to post some notes via chat system. Dunno when we will be back to GUI though. RebDev aka DevBase is still not finished ... | |
BrianH: 15-Feb-2009 | The R3 GUI does the separation of form and function better than Delphi (or even HTML/CSS/Javascript). | |
BrianH: 15-Feb-2009 | Yup. The equivalent in the R3 GUI is to change the implementation of the actions. | |
Pekr: 15-Feb-2009 | E.g. JAVA GWT does that - you can have JAVA native GUI, as well as very good browser based one - http://www.gwt-ext.com/demo/ | |
PeterWood: 15-Feb-2009 | Pekr: Delphi (and Lazarus) most definititely separate the description of the GUI and the code. They are described in different, though simiiar langauges and saved in separate files; .dfm for the GUI description, .dpr (or .pas) for the code. | |
Mchean: 17-Feb-2009 | I have a question about the Gui_Basics example in the R3 docs. The ex. under Adding styles won't work for me. title "Opinion Survey" comes back with title having no value - this after load-gui | |
kib2: 23-Feb-2009 | In fact, it's not the demo. Doing a "load-gui" from the console crashes all. | |
Ammon: 24-Feb-2009 | I'm running r3-a35 and load-gui is working for me. | |
Henrik: 24-Feb-2009 | looks like changes in the GUI dialect | |
Henrik: 25-Feb-2009 | That is 2 bugs rolled into one: 1. The script used to be called main.r, which is what it is called there. 2. The R3 GUI indicates an error in the dialect, when actually the file can't be read. | |
Pekr: 26-Feb-2009 | I just read about 'gather function and would like to ask about its area of usage? In the past, in FoxPro DB days, there was common method to get all for related data, via function called gather, and the reverse was to set a form from an array, via scatter fucntion. I think that if gather takes just one field from objects, we might use good name for some limited functionality, whereas it could be good name for GUI forms (panels) and gathering of info from all objects in one run? | |
Henrik: 26-Feb-2009 | We don't really need scatter/gather for the R3 GUI, as it already works with SET-FACE and GET-FACE using panels. | |
BrianH: 26-Feb-2009 | GATHER was your request, Henrik, specificly for use in the R3 GUI. Are you withdrawing the request? I need to know soon. | |
kib2: 26-Feb-2009 | There are some things I can't understand in the demo : when you click on source, you don't get the full source but just a part of it. Also, I've tried launching this script (from Dragger demo) : REBOL [ ] load-gui view [ doc { ^-^-^-===Drag the boxes ^-^-^-Blue boxes are unbounded. ^-^-^-Red boxes are parent panel bounded. ^-^-} d1: free-drag d4: lock-drag red panel 0 80.200.80.80 [ d2: free-drag d3: lock-drag red ] ] ...and got a parse error : why ? | |
Henrik: 26-Feb-2009 | have you studied how the R3 GUI works? | |
Anton: 27-Feb-2009 | The error that has occurred above is that the "demo-let" that kib2 looked at is not properly documented. Its script header should declare what its dependencies are and in what environment it should be run. This is a constant source of time-wasting for everyone, as an undocumented script apparently advertises that it has no dependencies and can run on its own. So all new-comers to the script will try it in the console themselves and see it doesn't work. Now the wondering begins: "is it supposed to be working or is it still in development?" etc. It's not kib2's fault for not having studied how the R3 GUI works. | |
Henrik: 27-Feb-2009 | http://www.rebol.net/wiki/R3_GUI | |
[unknown: 5]: 27-Feb-2009 | I don't know much about the progress of R3 GUI yet. | |
Henrik: 27-Feb-2009 | The latest shots of the UI can be seen at http://rebol.hmkdesign.dk/files/r3/gui/ but it is still changing and far from done. | |
[unknown: 5]: 1-Mar-2009 | I noticed the GUI demo in R3 is very buggy. Sometimes it just eats CPU and does nothing. | |
AdrianS: 6-Mar-2009 | well, if you can believe it, I've been "following" REBOL since it's beginnings, but never really pursued a deeper understanding of it due to various reasons (lack of adoption, closed nature of the language, lack of time on my part, etc). I have always, though, felt a very strong attraction to it because of all the possibilities hinted at - the lightweight nature, the clarity of expression, the built-in GUI, dialecting, and so on. | |
Pekr: 10-Mar-2009 | I just visited AGG newsgroup after one year, and some interesting projects do emerge. Community agreed that any open work will be done to BSD version (2.4), which is a good sign (although RT has probably no problem obtaining special license). Dunno why, but there are (apart from Cyphre) another few Czecho-Slovak guys, and one of them is doing rather interesting project. AsmJIT and BlitJIT libraries, with MIT licence. Author says about it: Antigrain is great piece of software with great licence, but without better acceleration it's quite slow. So blitjit can increase speed of your applications in way you can't imagine. For example is there complete MMX/SSE2 extension for antigrain ? No, but don't panic, other libraries also have problems with cpu specific features. The reason why it might be interesting is, that generally there is no good 2D HW acceleration out there, and here is what author of LibNUI answered to Cyphre: I'm the author or nui (http://libnui.net) which is a GUI toolkit based on OpenGL (and now OpenGL ES / Direct3D). This project was started some 8 or 9 years ago and I've been working on it and with it amlist daily for that time. My experience is that it's some orders of magnitude harder to have HW support for those features that to add a JIT to your engine in order to optimize your bottlenecks (I've done some of that for pro audio dsp code). The reason is that no two chips work exactly the same and behaviour even tend to change over driver releases. To diferent cards, even sometimes from diferent vendors, will not give you the exact same scan convertion or rasterizing, and I'm not even touching shaders diferences... It seems to be x86 only so far, but maybe guys like Cyphre or BrianH or Anton or anyone skilled in those areas should keep an eye on those guys :-) Here's a link: http://code.google.com/p/blitjit/ ... as for those another AGG based Czech and Slovak projects: http://www.rw-designer.com/ http://www.crossgl.com/ Shouldn't we get those guys hooked to REBOL? :-) | |
Pekr: 10-Mar-2009 | Henrik - as there is not much comfort in RebDev chat - not using other gob types contradics their purpose, no? I do understand, why keeping GUI desing simpler might have advantages, but stating that effects are not needed so far, because Draw dialect can serve us well for GUI purposes, might also mean, that we could discard effect pipeline? :-) | |
Henrik: 10-Mar-2009 | No, it just means that I have not needed effects yet. I think they should definitely be possible, but we have to be careful not overexposing it. MAKE-GOB could introduce a level of control that we don't want in a style, making a single style a big mess with hundreds of lines of code, because you have to reference GOBs. So far GOB management happens in 20-30 lines of code in one specific place in the R3 GUI design. It's very tight and controlled and by adding an effects GOB there, would make sense in the R3 GUI design. | |
Henrik: 11-Mar-2009 | Somewhere in rebdev. We have a high level GUI thread there. Might as well create a low-level one too. | |
Pekr: 11-Mar-2009 | Ah, damn, another big restructure of DocBase? :-) While Docs become more readable and graphically nicer, the person doing restructuring does not even distinguish Gabriele's GUI to Carl's one, so it really becomes an organisational mess and he ruined Carl's initial Docs for GUI ... | |
Henrik: 13-Mar-2009 | http://rebol.hmkdesign.dk/files/r3/gui/093.png Some shapes in this image was done that way. | |
Pekr: 19-Mar-2009 | Those wanting to influence VID resizing model - http://www.rebol.net/wiki/GUI_Face_Sizing | |
Henrik: 19-Mar-2009 | http://rebol.net/wiki/GUI_howto_debug | |
Henrik: 19-Mar-2009 | http://rebol.hmkdesign.dk/files/r3/gui/061.png | |
Pekr: 19-Mar-2009 | http://rebol.net/wiki/GUI_howto_debug#Runtime_Debug | |
Ammon: 19-Mar-2009 | I want to get to 't because I'm trying to hack together a GUI for DevBase because the console client is painful to use and I thought this might be a good way to introduce myself to some of the internal workings of the new GUI. I want to redefine "say" in the chat.r to update ''t with the text it would normally print. To have changed what VIEW returns such that I can't actually get to the face produced is unbelievably confusing. There must be a good reason for it though, what is it? You do realize that if I have no way creating a pointer to a face then I can't use get-face, set-face, etc. on it don't you??? | |
Ammon: 19-Mar-2009 | I need a solution to a problem and that solution very well may be a paradigm shift on my side. I just need to know how to interact with the GUI from outside the GUI code OR I need an explanation of why the ability to do has been removed in the latest release of R3's GUI. | |
Ammon: 19-Mar-2009 | Something I did in my code all the time with VID 2 is window: layout [ ... ] then go ahead and connect/modify/abuse the window in any number of ways and then show it later. I'd often set up panels this way so that I can have the faces built ready to switch out at the click of a button and this would allow me to easily keep different areas of the GUI in sync easily but now that Layout is gone I can't do it this way. The real question here is why is view returning the gob instead of the face? Seems on how I actually have the GUI source code sitting on my machine, I can hack this to give me what I want the problem is, it would be a hack which means that I can't hack it to give me what I want because what I want is not a hack. Get it? ;-) | |
Ammon: 20-Mar-2009 | I'm actually not seeing anything in the new GUI that allows you to find a given face's parent. It's really very frustrating me... | |
Pekr: 20-Mar-2009 | I posted my reaction to rebdev chat too. I am missing some aproach to easily traverse gui: - there is bog/pane, but not face/pane. There is face/faces e.g. for panel style. If it is the same concept, why name it differently? - there is no face/parent-face to traverse backwards - face/gob contains just one gob. It also seems to me, that it is not even a pointer to the gob, but not sure. Not sure if it would be usefull, but currently face can't be built from multiple unrelated gobs. You have to have one gob, and other ones in gob/pane | |
Henrik: 20-Mar-2009 | Maarten, a few thousand? Not likely to happen right now and as Carl said, he would add features as needed, and there's no need to support a few thousand users right now. Right now the next step is a proper GUI. | |
Henrik: 20-Mar-2009 | Ammon, it sounds simply to me that some features for setting window titles, etc. are either missing or undocumented. I'm pretty sure you're not meant to use obscure paths to access features, but to use SET-FACE, GET-FACE, SET-FACET and GET-FACET. These features are much more powerful in the R3 GUI than the ones in VID. And if they're missing, it doesn't take long to add them, so instead of "getting annoyed as hell", ask nicely on rebdev and Carl will probably find some time to add them. :-) | |
Pekr: 20-Mar-2009 | ... and - it was declared from the very beginning, that GUI is much needed here, and it will be surely done ... | |
Pekr: 20-Mar-2009 | I was against new system, but I am satisfied with Carl's explanation of his POV. He needed streamlined channels for chat, bugs, CVS, filesharing. New system, in comparison to AltME, gives us: - threaded discussions - ranking - tagging - threaded discussions - message/topic moving - versioning system - document management. Docs posted anywhere to any message. - console version So far, the big minus is - no GUI client. But - that might be over in few months ... So - if we think of RebDev as nothing more than RT's supporting infrastructure, I am OK with it. It is just that for fast dev related chat, e.g. nowadays GUI related, it can't reach Altme comfort and speed in not more than 20%. Threading is very confusing now ... | |
Ammon: 20-Mar-2009 | I'm updating DocBase GUI docs. 1. Changing the links at the bottom of each of the pages to point to a single template so that they are automically updated across all pages by changing one document. 2. Adding [[Category:GUI]] to each of them. 3. If I have time I'll start working on a VID2 to 3 document that describes what changed. Things like face/parent-face is now parent-face? face. | |
[unknown: 5]: 21-Mar-2009 | I just wanted to mention that when I run the gui demo and click the "text view" test it causes an error on my vista machine. | |
Henrik: 24-Mar-2009 | right now, I'm rebuilding the MAKE-TICKS function for the R3 GUI as I need more flexibility, and it would be greatly simplified and easier to understand with something like this. | |
Henrik: 24-Mar-2009 | http://rebol.hmkdesign.dk/files/r3/gui/106.png Make-ticks was used in the 5 sliders at the top. | |
ICarii: 27-Mar-2009 | view is currently swiss cheese and the underlying Core has some large gaps that really need addressing before GUI sees the light of day.. IMHO.. |
1201 / 2867 | 1 | 2 | 3 | 4 | 5 | ... | 11 | 12 | [13] | 14 | 15 | ... | 25 | 26 | 27 | 28 | 29 |