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: 2001 end: 2100]
world-name: r3wp
Group: !REBOL3 GUI ... [web-public] | ||
BrianH: 13-May-2010 | Persistent GUI state will allow an application to save its state, be suspended or shut down, and be restored later, all automatically in response to system events. Windows 7, Androis and iPhone OS 4.0 all have facilities for triggering this kind of event in applications in response to power management or (for Windows 7) reboots. This will make it possible for us to write REBOL apps that will resume after an intentional shutdown by the system. | |
BrianH: 13-May-2010 | But I'm not assuming that the R3 GUI will do that immediately, just that it will be possible. | |
Robert: 13-May-2010 | Brian, yep, exactly. And it's not only about suspension. Think about logging of at one system and again on at an other while taking over your app session and GUI state on this system to continue your work. | |
shadwolf: 13-May-2010 | rebol GUI is light weight gob are enought well done to be considered as a stand alone entity... So why not trying to get the best of rebol doing things like that... | |
Gregg: 3-Jun-2010 | Screenshots are here: http://rebol.hmkdesign.dk/files/r3/gui/ Thanks for doing that Henrik. | |
james_nak: 5-Jun-2010 | Get getting around to checking r3 gui. Does anyone else get the char-size needs a value error upon load-gui? | |
Henrik: 5-Jun-2010 | james, it may be that you are running a98 or a99. the GUI will currently only run on a97 and below. | |
Henrik: 5-Jun-2010 | Yes, well, currently I need to finish another project, so GUI development could be faster, but Cyphre and Rebolek are working on it. At least it's moving. Proper resizing is the topic now. | |
Pekr: 7-Jun-2010 | Well, AGG is good enough imo. Our problems imo lay elsewhere - GUI incompletness, GUI look (skin). | |
Pekr: 7-Jun-2010 | ... and even more deeply ... the world goes HTML5, what do we do about it? :-) (I know there is still place where R3/GUI will be usefull) | |
BrianH: 7-Jun-2010 | Hosting Webkit wouldn't help here: The whole point to HTML5 etc. acceptance is that people don't have to install another program - they can just use their existing web browser. Hosting Webkit would only help us if we want to display existing web browser code; it wouldn't be necessary for generating code to run in Webkit, because the copy of Webkit that people would be displaying your GUI in would usually be a separate program, often on a separate computer. And HTML/JS/CSS is just text - we can generate text already. | |
AdrianS: 7-Jun-2010 | Brian, my point with the embedded WebKit would be to have an alternative gui framework that has the capabilities people are used to from a browser. With a non-hosted WebKit (or any old browser), you couldn't have very close integration with the REBOL runtime. | |
BrianH: 7-Jun-2010 | Embedding REBOL *in* Webkit would work well. The other way around wouldn't help as much, because we'd be stuck with the browser GUI model when we don't have to be. People don't use the HTML/CSS/JS model because it's good (it's not), they use it because it's there already. | |
BrianH: 7-Jun-2010 | Maxim, I don't doubt that it using Webkit in R3 would be useful. But it would be useful for other reasons than providing a GUI for R3 (the topic of this group) - more for displaying the GUIs of other code within R3, other code (un?)fortunate enough to have been written in HTML/CSS/JS. | |
Henrik: 15-Jun-2010 | http://rebol.hmkdesign.dk/files/r3/gui/210.png Demo of pixel accurate resizing. http://rebol.hmkdesign.dk/files/r3/gui/211.png Same as 210, except border sizes for each individual GOB is randomized. | |
Pekr: 22-Jun-2010 | Henrik - any new screenshots to R3 GUI in the pipeline? :-) | |
Pekr: 22-Jun-2010 | Also - with the change to the "box model" and introduction of "material" system, will it be any easier to adapt the overall GUI look? | |
Pekr: 22-Jun-2010 | hmm, it seems like Carl is finally cooperating even in the GUI area? :-) So, is he liking new RebGUI like resizing model, or not? :-) I remember even some discussions in the past, and Carl had his own opinion on that. I hope that max-size need is eliminated ... or still it is not? :-) | |
Henrik: 24-Jun-2010 | if you can reference strings from outside the GUI, that shouldn't be a problem to do on your own. I don't find it generally to be a good idea to provide language support inside a GUI engine. | |
BrianH: 24-Jun-2010 | Good, because I've been waiting for the R3 GUI resizing model to be finalized before I retrofit the R2 VID resizing patch with its algorithm. | |
Claude: 24-Jun-2010 | carl say => With the above renewed effort on the GUI, the priority of moving the graphics library to the Host-Kit has jumped up a few notches. This is a non-trivial project; however, the next sprint is expected to arrive in two weeks | |
Henrik: 24-Jun-2010 | Posted 5 shots: http://rebol.hmkdesign.dk/files/r3/gui/212.png from 212 to 216. I think they need some explanation from either Ladislav or Cyphre. | |
Ladislav: 24-Jun-2010 | http://rebol.hmkdesign.dk/files/r3/gui/212.png- this is a layout using a PANEL style, elements are layed vertically, (in columns), center-aligned, having different (randomly adjusted) sizes | |
Pekr: 24-Jun-2010 | what I don't understand for the gui is, what panel and group are layered in different directions - vertical vs horizontal :-) (unrelated to resizing) | |
Rebolek: 24-Jun-2010 | I don't like max-size, but the way it's done now, I think, that it can be omited from style-writing and R3/GUI can take care of it. But that's just a guess right now. There's now code to support my guess. | |
Graham: 24-Jun-2010 | Anyone know if one can update the GUI from a network event? | |
Pekr: 25-Jun-2010 | Henrik - so what happens next? Resizing model is incorporated into GUI, and then we can see some beta? Or is it still too early? | |
Cyphre: 25-Jun-2010 | Pekr: the new resizing model is not yet integrated to R3 GUI. We are finalizing the prototype so it is fine-tuned. The integration to R3GUI part will start from the next week. | |
Pekr: 25-Jun-2010 | as for why min-max size totally sucks. Who tries to predict, what is the correct max-size? I linked my notebook to my LCD TV, and instantly the gui looked totally wrong, as the resolution went up to 1920x1080 (FullHD), but field was set to max 900. Carl told me, that fields should not be so long. But - I don't want to discuss it with the style author. In such a case, I had to adapt the style to "fix" the case ... | |
AdrianS: 25-Jun-2010 | Cyphre, is the layout framework pluggable in any way? Could it be replaced with a different model? I'm just thinking how layouts are done in Java where there are quite a few different layout managers available and one size doesn't have to fit all. Here are some options: http://leepoint.net/notes-java/GUI/layouts/90independent-managers.html | |
AdrianS: 25-Jun-2010 | well, this is what I was asking about - should the GUI elements be tied that closely to how they're laid out? | |
Pekr: 25-Jun-2010 | I am not sure I understand what you mean :-) GUI elements in our case are not something which is easily encapsulated in its source code and hence can be used with different engine, at least I think. But maybe I just don't sufficiently undersand, what "layout manager" means, so I will let the question to be answered by others ... | |
AdrianS: 25-Jun-2010 | Does the declaration of REBOL GUI elements need to be so different from how other toolkits handle them? It just seems that needing to have only one way (one layout engine) of laying things out is a lot to ask of both the layout framework designers and the users of that layout engine. | |
Pekr: 25-Jun-2010 | The only thing I can do right now is to point you to new GUI docs, maybe by reading the docs you will understand, how things are layered .... http://www.rebol.com/r3/docs/gui/gui.html | |
AdrianS: 25-Jun-2010 | It seems from reading: http://www.rebol.com/r3/docs/gui/faces.html that you might be able to define a new "layout" function implementing a different layout description dialect to achieve a new layout. Am I understanding it correctly? Is this layout description dialect specifically what the gang is working on? | |
Pekr: 25-Jun-2010 | Apart from the fact that I can't properly answer your question, my understanding is, that the team is working on all aspects of GUI, in following areas: - low-level (in C) - new GUI is based mostly on AGG, some fixes and enhancements are going to be done. Carl, and Cyphre probably too, is also working on HostKit GUI isolation, so that the GUI can be fully open-sourced, becomes part of Host environment, and can be eventually replaced - various GUI subsystems are being worked on - layout, resizing, keyboard navigation/tabbing/accelerator keys, skinning/themes/materials, GUI transition effects, etc. - GUI styles - new VID is supposed to be released with some advanced styles, as e.g. tabs, grid, hopefully tree too, maybe a menu (dunno about that one) - some other things come to my mind - browser plugins, video codecs etc. - good times ahead once we are there, but first things first :-) | |
AdrianS: 25-Jun-2010 | Ok, but does this mean that a new "layout specification dialect" would not be able to redefine sizing? It seems that it should be able to do so as the sizing of GUI elements is intimately part of laying things out. | |
AdrianS: 25-Jun-2010 | I would think that a GUI element's size is relative to the layout model defined by a particular layout implementation - that is, GUI elements that are being managed by a grid/table-like layout manager would resize differently than those being laid out by a layout implementation that "flows" it's managed elements or fixes their positions to absolute coordinates. | |
AdrianS: 25-Jun-2010 | Yes, the layout implementation is the code that is behind the function "layout" in a face, for example. See: http://www.rebol.com/r3/docs/gui/faces.html The dialect parsed by this code is specifically called "layout description dialect" in the docs. This is different, as I understand, than VID, is it not? | |
AdrianS: 25-Jun-2010 | The way I understand it, VID is a superset of the layout description dialect. So, to reiterate, if there is such a thing as a "layut description dialect" and there could be more than one defined, how come you are saying that resizing of GUI elements managed by any number of layout implementations is independent of these implementations when, as I tried to describe above, the resizing that you should get for a GUI element should take into account the "bounds" set by a particular layout implementation. | |
AdrianS: 25-Jun-2010 | Hmm, well words in VID that declare the GUI elements, button, text, for example, are not layout specific. If I were to change the layout dialect, would these not stay the same? Doesn't this mean that the VID is a superset of any layout dialect in that it includes words for defining layout and words for declaring GUI elements? | |
Ladislav: 25-Jun-2010 | Hmm, well words in VID that declare the GUI elements, button, text, for example, are not layout specific. If I were to change the layout dialect, would these not stay the same? Doesn't this mean that the VID is a superset of any layout dialect in that it includes words for defining layout and words for declaring GUI elements? - no, this is REBOL, and you can define a totally different dialect than VID, and such a dialect surely does not have to be a subset of VID in any sense of the word | |
BrianH: 25-Jun-2010 | AdrianS, I've worked with Swing and know what you are talking about. The equivalent to a Java swappable layout model in the R3 GUI (when last I worked on it) is a group style. The "group" and "panel" styles are two such grouping styles. More group styles and other composite styles can be added. What you request is built into the model already. | |
AdrianS: 25-Jun-2010 | Brian, what you're saying though is that a containing GUI element is responsible for the layout of it's children as opposed to delegating that functionality to a layout manager. In Java, each GUI component that can be a parent can have a different layout manager added to it,but it doesn't manage the layout itself. | |
AdrianS: 28-Jun-2010 | I suppose I just had the expectation that REBOL styles would only concern themselves with look and behaviour (group acting as a tab group, for example) and that layout would be handled by other types of constructs in the dialect, the way I'm used to. As for needing hierarchies in Java, these are there in the GUI component declaration to match the visual hierarchical arrangement and to make control of child visibility, event passing and layout match what you would expect to see coming from such a visual arrangement. If similar control can be achieved by REBOL in a different way, so be it. | |
Henrik: 5-Jul-2010 | http://rebol.hmkdesign.dk/files/r3/gui/219.gif Carl's drawing of the R3 GUI/graphics pipeline (posted with his permission). | |
shadwolf: 6-Jul-2010 | see you and i will keep watching the gui part | |
Henrik: 6-Jul-2010 | http://rebol.hmkdesign.dk/files/r3/gui/220.png 220 to 225 shows the resize engine in use with globally set borders with quite good pixel accuracy. the border style should be possible to set globally according to cyphre in a similar way as in VID, of course without the artistic limitations of VID. | |
Gregg: 6-Jul-2010 | base-url: http://rebol.hmkdesign.dk/files/r3/gui/ img-url: func [id] [rejoin [base-url id %.png]] ids: [%220 %221 %222 %223 %224 %225] imgs: copy [] foreach id ids [repend imgs [id load read/binary img-url id]] cur-id: first ids show-next-image: does [ cur-id: select join ids first ids cur-id set-face f-img imgs/:cur-id ] view layout [ f-img: image (imgs/:cur-id) btn "Next" [show-next-image] ] | |
Henrik: 9-Jul-2010 | http://rebol.hmkdesign.dk/files/r3/gui/225.png http://rebol.hmkdesign.dk/files/r3/gui/226.png First integration test of the new resizing scheme. It looks much more solid and accurate, but there are still a few bugs (the partially blanked button in 226). | |
shadwolf: 10-Jul-2010 | WAHOUUUU !!!!!!! REBOL GUI START LOOKING LIKE SOMETHING A PRO COULD SELL !!! | |
Graham: 11-Jul-2010 | the gui and parser .... | |
Pekr: 12-Jul-2010 | any news on R3 GUI front? :-) | |
Henrik: 14-Jul-2010 | transition shouldn't affect GUI development. it's not like all copies of A97 stopped working. :-) | |
shadwolf: 15-Jul-2010 | the thing is draw and so agg can be used on any widget componing VID and that's a hugde constraint what really sux with opengl are those half assed IHM interface i know glut, x and w32 extension that allows the opengl rendering engine to recive user events and then display on screen in the particular area set for it. Those interfaces are not 1% as fun as VID... Vid is total flexibility. we never did that in vid be you can imagine heavy animation using draw dialect on any kind of preset styled face. I think carl tryed to show that with the animated sliding widget when you open a window in his R3 GUI demo. | |
Graham: 15-Jul-2010 | So, one could use AGG for somethings like a GUI and then use Cairo for display postscript | |
Henrik: 15-Jul-2010 | http://rebol.hmkdesign.dk/files/r3/gui/228.png This odd looking dialog marks a few milestones from two days of work: - Successfully create and open an email dialog created from a single style, which represents the content area. - Successfully validate the content area from the validation information stored in the style. - Successfully display validation result in the content area (the letters to the right of the fields show INVALID) - Successfully block closing it, when it's not correctly filled, when clicking "Send" using a new DISMISS reactor. - Successfully store the content in a way so that it can be returned in an object, when the dialog is finished or store a NONE/FALSE when cancelled. The dialog is called by: REQUEST-EMAIL. It doesn't send any email, that comes later. The reason it looks odd is because the new resizing scheme requires some changes in how sizes are handled in styles and I haven't quite figured out how to change them yet. We'll probably need some more prototypes, but all in all, this is a fairly good method of creating complete-featured dialogs quickly. | |
Graham: 21-Jul-2010 | Is this page deprecated? http://www.rebol.com/r3/docs/gui/reactors.html My older r3 builds don't recognize 'make-reactor | |
Graham: 21-Jul-2010 | >> load-gui Fetching GUI... GUI Version: 0.2.1 (Developer test GUI theme) == 0.2.1 >> make-reactor ** Script error: make-reactor has no value | |
Henrik: 21-Jul-2010 | besides, there will be a rather large extension to the GUI soon. it's not a good idea to work on docs now. | |
Carl: 21-Jul-2010 | The lower-level graphics changes from host-kit and pair decimals will disrupt only the compositing layer of the GUI. The rest is as Henrik noted, unchanged. | |
Andreas: 21-Jul-2010 | Just a quick question to further my understanding: is the Saphirion NLPP/Cost Analysis stuff already R3-based, or what GUI framwork is used for the Saphirion apps? (Henrik? Robert?) | |
Henrik: 22-Jul-2010 | and yes it was started with RebGUI, mainly because that was the standard GUI system to use at the time. | |
Graham: 22-Jul-2010 | Dunno if it's just me .. but often I will get RebGui crashes because part of the gui being referenced has not yet appeared. | |
Graham: 23-Jul-2010 | All I can say then is that I do see a lot of rebgui errors if I use the gui too quickly | |
Graham: 23-Jul-2010 | If I use the GUI in a sedate mode .. then no errors | |
Anton: 25-Jul-2010 | Henrik, I haven't looked at it, but if I guess right, you mean you're considering adding a callback ability to the window close function. Surely it would be a gui programmer who would be able to use this callback, right? You haven't programmed the close button to pop open a dialog for the end-user asking for arbitrary rebol code to execute with security off, have you? ;-) | |
Anton: 25-Jul-2010 | Hmm yes. If ever a dialog's close button does not simply close the dialog, I'm probably going to wish that the designer had found a better way to program the gui. | |
Pekr: 26-Jul-2010 | Any news how implementing command wrappers for AGG goes? Or on GUI status in gerenal? :-) | |
Henrik: 26-Jul-2010 | If it's not clear, the GROUP style produces this flow: http://rebol.hmkdesign.dk/files/r3/gui/225.png If you turn that 90 degrees, you'll see that it's like how newspapers arrange columns, so I would want to find a familiar DTP term for it. | |
Ladislav: 26-Jul-2010 | So, both http://rebol.hmkdesign.dk/files/r3/gui/214.pngand http://rebol.hmkdesign.dk/files/r3/gui/225.png are examples of the Group style now. | |
Ladislav: 26-Jul-2010 | The http://rebol.hmkdesign.dk/files/r3/gui/214.pnghas LAYOUT-MODE set to columns, while the http://rebol.hmkdesign.dk/files/r3/gui/225.png has LAYOUT-MODE set to rows. | |
Ladislav: 26-Jul-2010 | They are both groups, in the http://rebol.hmkdesign.dk/files/r3/gui/214.png you can see the columns, in http://rebol.hmkdesign.dk/files/r3/gui/225.png you can see rows, can't you? | |
Pekr: 26-Jul-2010 | Henrik - by "lines" you mean probably rows, right? OK - what happens, if one GUI element in particular row is wider? The whole row becomes that wide, or it shrinks? | |
Ladislav: 26-Jul-2010 | http://rebol.hmkdesign.dk/files/r3/gui/213.png | |
BrianH: 26-Jul-2010 | Panel is a good name. All of these are pretty arbitrary when applied to a GUI system. Pick something traditional like Group and Panel, that sounds nice. | |
Anton: 26-Jul-2010 | HTML refers to this as "inline" (and the line may wrap). I used grid-face/LAYOUT-DIRECTION: 1x1 and grid-face/MOVE-FIRST: 'horizontal in my old GRID style. do http://anton.wildit.net.au/rebol/gui/demo-grid.r But the parameters needs to be clarified some more. Academic papers published as PDFs often have two columns of text. That means a single line of text wraps horizontally, vertically, and horizontally again. Eg. The line of text first wraps (horizontal) when the right hand edge of the first column is reached, then, after many rows are similarly wrapped, when the bottom of the first column is reached (vertical wrap). All of that occurs again for the second column (and perhaps more columns) until there is no more room on the page, so the final level of wrapping is horizontal. So I would have face/WRAP: [horiz vert horiz] which specifies three levels of wrapping, horizontal for chars, vertical for lines of text, horizontal again for columns (so that the next page is underneath the first one). To put pages horizontally, you would just have face/WRAP: [horiz vert vert] Or you could specify an extra level of wrapping, eg. so that you could have groups of two pages shown horizontally face/WRAP: [horiz vert vert horiz] The direction for each level of layout should be specified to correspond, eg. face/LAYOUT-DIRECTION: [1 1 1 1] which would give left-to-right and top-to-bottom. (Use -1 for right-to-left and bottom-to-top directions.) | |
BrianH: 26-Jul-2010 | If we see styles like 'red-button, we've failed in our design of the R3 GUI system. | |
Henrik: 26-Jul-2010 | Anton, you are free to do that, but it will break the philosophy of how styles work together. I think this point is not properly understood, but it will move the GUI to the next level, where you spend zero time thinking about colors or theme, can properly divide UI design between a graphical designer and one producing programs. | |
Pekr: 26-Jul-2010 | simply put - it is not that it would not be technically possible to pass any such argument to the style during the construction. It is about - we don't want to do that for some attributes, color being one of them, because it could ruin overall look of the GUI ... | |
Henrik: 26-Jul-2010 | it's not just looks. deep semantics that are used to make the GUI function properly relies on functional styles rather than appearance of styles. if you have a red button, the GUI won't know of its importance. but if you have an OK-BUTTON, you can tell how important it is, when it should be focused and what you are allowed to do with it. automating this can cut off hundreds of hours of development and testing time, because you don't have to pay attention to those details. the UI system does that for you. | |
Henrik: 26-Jul-2010 | proper usage of styles in the R3 GUI works exactly the same as in documents that are properly styled. there is no difference. | |
Henrik: 5-Aug-2010 | the R3 GUI does something like that already with a RELAY option, but it's cumbersome to use and less flexible. | |
Pekr: 5-Aug-2010 | for cross-linking GUI elements, it might be sufficient, but for overall app logic? There would have to be list of possible update actions for each element possible change. The system I used in DOS ere had it exactly like that. And it worked even with grid for e.g. You deleted an item, and the update action was able to update your stock DB item related amount. The mechanism would have to be universal enough, because if it will not cover enough cases, it will not be used by developers, and will bloat the GUI code, as everybody will replace it with own version .. | |
Maxim: 5-Aug-2010 | Although I've implement 5 complete GUI frameworks, so far I've stayed relatively silent on the R3 GUI front cause I'm building my own framework and I don't want to interfere with the R3 system. but I will pitch in here and say that what Henrik proposes is a good idea (I use the same name for a relatively similar feature), though it needs one thing if it is to be usable by newbies. a way for do-face NOT to call attach. the reason is that if you want several cooperating controls, they must not create feedback. | |
Pekr: 5-Aug-2010 | Henrik - one field change might cause change in multiple other places, not necessarily GUI related. | |
Maxim: 5-Aug-2010 | my old VALVE liquid system was similar to this and I could easily have 30 interconnected controls in realtime, all refreshing, some even generating data which where used in other parts of the gui (like backgrounds). so you'd have a control control and the whole "stylesheet" would updated interactively. | |
Robert: 5-Aug-2010 | Petr, the app logic shoudl just get a trigger from the GUI (subscriber pattern) and than do what ever makes sense. | |
Robert: 5-Aug-2010 | State machine: Not to be meant to be part of the GUI. The reactor code would just trigger the state machine than. | |
Henrik: 6-Aug-2010 | Regarding ATTACH, perhaps it's best for now to leave it working as it is, as I'd like to keep it. One big advantage of reactors is that you can write your own very quickly and not affect the GUI system. | |
shadwolf: 7-Aug-2010 | is it possible to know who work on what in the GUI topic and have a slight idea of the steps done and the steps to be done .... | |
Henrik: 9-Aug-2010 | http://rebol.hmkdesign.dk/files/r3/gui/229.png Text now works in hostkit. | |
Henrik: 11-Aug-2010 | Finally got some usable fields again: http://rebol.hmkdesign.dk/files/r3/gui/230.png Now for some deeper testing of the resizing system. | |
Henrik: 11-Aug-2010 | http://rebol.hmkdesign.dk/files/r3/gui/231.png :-) | |
Graham: 12-Aug-2010 | did you ever figure out how to create GUI event from inside a network protocol? | |
Cyphre: 12-Aug-2010 | Graham: regarding the 'updating GUI from network protocol' question I have found some older scripts I did and quickly added the progressbar to it so you should see how it works. You can download it from here: http://www.rebol.cz/cyphre/scripts/r3/net/client.r3 and http://www.rebol.cz/cyphre/scripts/r3/net/server.r3 just run server and client on localhost and press enter in the client console to see how the server shows the progress of upload. | |
Graham: 12-Aug-2010 | Imagine a GUI based on polar coodinates | |
BrianH: 12-Aug-2010 | Complexity is the enemy for the R3 GUI. | |
Maxim: 12-Aug-2010 | R3 GUI would be top-down by default for everything. | |
Maxim: 12-Aug-2010 | conceptually is solves a problem in just about GUI engines out there. and its dead simple to use and understand. |
2001 / 2867 | 1 | 2 | 3 | 4 | 5 | ... | 19 | 20 | [21] | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 |