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: 2701 end: 2800]
world-name: r3wp
Group: !REBOL3 Extensions ... REBOL 3 Extensions discussions [web-public] | ||
Pekr: 26-Jan-2011 | I would like to get back to Oldes' quesiton - is unloading extension/module/gui or other elements technically impossible? | |
Pekr: 26-Jan-2011 | Once the program closes is not usefull at all. Think about R3 as an OS. It somehow should track resources. And/or stuff like GUI etc. should be isoloted in some context which you could easily scrape - unset, free, whatever ... or the memory consumption will rise endlesly? | |
Group: !REBOL3 GUI ... [web-public] | ||
Rebolek: 6-Mar-2011 | You're confusing GUI with graphical subsystem. In R2, face was used in graphical subsystem, R3 uses gob! instead. Face in R3GUI stores all GUI-related informations and cannot be compared with R2 face. | |
Pekr: 6-Mar-2011 | Studying GUI I have following psychological problem - I never know, what possible elements it might contain. The problem is evident, when you create style using stylize. Even Carl was aware of that, and e.g. for actors he created comments, so that user know, what argument it takes. Looking at various styles, I always wonder, if I can make any facet I want, or is there any MEGA FACE object, containing all possible fields? :-) | |
Pekr: 6-Mar-2011 | with prior gui, I could see 'draw-results, or something like that in the structure. Was it removed? What was it good for? :-) | |
Pekr: 7-Mar-2011 | R3 still hard crashes with the GUI :-( unreproducible .... | |
Pekr: 7-Mar-2011 | But generally yes, for forms, I expect easily setting up pairs of right alighned labels, and fields. That has to be ultra easy, along with the ability to set some margin, but that should be workable via the stylize. Henrik - I think that if you add frameless alternatives, then it is not a big deal ... I just have problem with current aproach, where subpanels create too many lines in the GUI :-) | |
Henrik: 8-Mar-2011 | Tagging is neither facets nor options. They are information that usually relates to the GUI system to describe the state and capability of the style. | |
Pekr: 8-Mar-2011 | There are two concepts, which might be helpfull (maybe it is one concept?): 1) having the same style in various sections of your GUI styled differently 2) having the option to style differently the same style in the same level (that can be done by options) | |
Ladislav: 8-Mar-2011 | re "I thought that you might find a way of how to do it in terms of just one panel" - it is possible to do it in "just one group". Do not forget, that R3-GUI H/Vgroups are more similar to R2 layouts than R3-GUI (H/V)panels. | |
Henrik: 8-Mar-2011 | In R3 GUI, style names themselves act as classes, where in HTML you have a fixed set of tags that need to have classes. IDs are set-word!s, so there is no need to add any superfluous layer to identify specific faces. | |
Maxim: 8-Mar-2011 | Henrik, not quite. using CSS you effectively "tag" your gui and then you can apply effects to multiple types of things which match a tag or pattern. | |
Henrik: 8-Mar-2011 | Maxim, this is necessary in HTML, because of the fixed naming of HTML tags. set-words in the R3 GUI do this. | |
Henrik: 8-Mar-2011 | I suggest that classes in the R3 GUI is not useful for the reason that it interferes with the "intelligence" layer, where we already have: 1. tags to identify state and capability of a face, such as finding the default button in the window or whether the button is disabled. 2. name to identify a specific face 3. style name to identify the style and to create a distinct appearance 4. the ability to group faces by panels 5. have information about the ordering of faces stored in the face tree 6. use specific policies on how to act on a particular face with particular tags | |
Pekr: 8-Mar-2011 | Henrik - you see? I just wanted to have a "button" inside of view, and by change of stylize parameter, to change some aspect of the button. But I might be mixing few things together. In your above example, my-button is a class. So your saying that in R3 GUI, classess are not usefull, is an incorrect statement, as we already do have classes? Or what you would call your 'my-button then? | |
Henrik: 8-Mar-2011 | So your saying that in R3 GUI, classess are not usefull, is an incorrect statement, as we already do have classes? Or what you would call your 'my-button then? - A style is not a class in the HTML sense, where you can apply a particular class to any tag. | |
Pekr: 8-Mar-2011 | Cyphre - what will layout be good in next version? To preconstruct GUI, not displaying it? | |
Ladislav: 9-Mar-2011 | Hi, here is an R3-GUI poll once again: For the resizing purposes, all elements have MIN-SIZE and MAX-SIZE specifying the limits of resizing. It is easy to see, that, unless MIN-SIZE <= MAX-SIZE in both coordinates, the requirements are contradictory. (For example, if we set MIN-SIZE: 100x100 and MAX-SIZE: 50x50 for the same object.) Currently, the code does not trigger an error in such case (not having a built-in test for it), giving the priority to the MIN-SIZE. The poll question: What do you prefer to happen in case object MIN-SIZE and MAX-SIZE dimensions are contradictory? Do you think the current behaviour is acceptable, or do you want the code to always trigger an error, if conflicting requirements are given? | |
Maxim: 9-Mar-2011 | it shoudn't be an error. popping errors in gui code is generally pretty evil if it can be prevented... its better for the gui to look weird than the interpreter to jam for an unknown reason. the possible layout screw-up will be incentive enough for the bug to be fixed. a logging system could help us identify where the engine "thinks" there might be problems... a debug switch which compiles warnings like this would be nice. | |
GrahamC: 9-Mar-2011 | I hate gui errors .. I'd rather have a screwed up display | |
GiuseppeC: 11-Mar-2011 | A small note: I have ran the latest RE-GUI and the examples. I have see that when the CHECK is off the "v" is still visible but greyed. In GUI language I have seen the GREYED "v" means BOTH "true" and "false". Example: you want to filter in a database which customers are active, you set it to true, which are inactive, you set it to false (nothing visible). You want both true and false the you have a third state: the grayed V. | |
Pekr: 11-Mar-2011 | I have problem accepting result of examples: 15, 23, 24, 25, 26, and I stop here, probably many others ... The problem I see is,that I don''t want elements to jump during resizing the way it does. Please try form example 15. IMO if we don't support scaling, the text and its spacing should not change at all. I would expect panel being enlarged, but all it does is the panel moves down, and GUI creates space between the header text and the consecutive text. Also - look at example 26 - why the last line of boxes is shifted down the window from all the rest of the boxes? | |
Pekr: 11-Mar-2011 | Panel example #35 - I just wonder, how many ppl will feel lost the same way as I feel. The naming terms in regards to results are difficult for me to resolve. As for alignment, there is several way of how to name things: halign, valing left , right, center (vleft, vright, vcenter, hleft, hright, hcenter) left, right, center, top, middle, bottom (or the corner alignment - top-left, top-right, buttom-left, bottom-right - if those would be used, I would immediatelly understand it) But - let's try to think about it a bit - we have some alignements in various GUI levels. If possible, let's stay consistent (e.g. it is enough that low-level text handling uses MS Word like terms, which don't relate to the rest of the gui) | |
Henrik: 12-Mar-2011 | I think the edge/frame/border usage is a little confusing. EDGE was a standard feature for every face in VID and it was fixed how it worked. In R3, an edge would be implemented on the DRAW level and could basically mean anything, including what it means in relation to the box model. This is why I'm still advocating a special FRAME style, which in *one* place, settles the meaning and the appearance. Furthermore, a FRAME could be required for any type of face, be it a form with many fields, a compound of faces or groups of compounds of faces, which need to be surrounded by a pixel accurate frame, like in the example below, which I had trouble defining properly, when I experimented with skinning: http://94.145.78.91/files/r3/gui/162.png I had problems with it, because it had to be part of COMPOUND, and yet, certain COMPOUNDs would not have a frame and certain other panel types would also require the frame, but not be a compound. It is just much simpler to have it in a separate style. | |
Ladislav: 12-Mar-2011 | #[[GiuseppeC I have ran the latest RE-GUI and the examples. I have see that when the CHECK is off the "v" is still visible but greyed. GiuseppeC]] - you are not the only one who dislikes this. Count me in. | |
Pekr: 12-Mar-2011 | What's the resistance? You just need to understand, that there might be some users, not understanding GUI internals imo. I put above comment on purpose here, explaining WHY exactly it behaves as it does. Just stating the something is correct without further explanation does not help to understand the case .. | |
Pekr: 12-Mar-2011 | What users poll are you talking about? I do remember some, and when I can't take any preference, I don't participate. OTOH I put many comments in here. In fact - R3 situation is so "devastated" from the community point of view, that there is very little ppl participating in actually anything R3 related. Even in time of Carl's GUI, I might be the only public tester, may 1-3 other guys I remember. Where's all 300 ppl registered here with testing and comments? How much of input you get from any other person? | |
Pekr: 12-Mar-2011 | What I can see though, is a kind of syndrome of a developers, who live behind the closed door, and then wonder if another point of view is presented. It very often ends with statements like "you can take Carl's code, and do your own GUI". And I am far from alone receiving such a reply. And THIS is what I call as an insult, to ppl expressing different pov on the direction taken. | |
Pekr: 17-Mar-2011 | Cyphre: box-model: --------------- Few notes. Certain systems use FLAGs, which could be thought about as kind of switches, or representing certains states, etc., used in binary masks for e.g. Then we have TAGs. Even R3 GUI uses tagging - it is used mostly to mark particular face as behaving some way, belonging to some area, etc. And in that regard, I wonder if box-model type could be done just by using TAGs? What I think about TAGs in GUI in general is, that we don't use the concept to the max. I mean - if tags were not be flat block, but block of blocks, it could be used even more, e.g.: tags: [box-model [tag1 tag2 tag3] style [internal] draw-mode [normal] resizing-mode [.....] ....] Of course that might not work for us in all cases, because as you could see in above example, it would be difficult to distinguish, if something should be a facet, or a tag. E.g. if we would move DRAW-MODE into TAGS, then why not moving MATERIAL there too, etc. My question is - is there any rule for me to remember - what should be a facet, and what could be a TAG? (I expect the difference in how you work with them underneath) My general problem is, that FACETS block is becoming long and messy, so what to do about it? There were following suggestions to think about: 1) close particular settings in subobjects/maps (whatever). There are settings belonging to the areas of resizing, colors, box-moderl, others, etc. The question is, if we want to refer to such values by face/color/bg-color for e.g.? 2) the simplest solution is to at least use some source code conventions. E.g. Carl introduced comments to particular ACTORS, desribing what arguments are supported for the function. So my idea is: facets: [ ; colors bg-color: other-color: ;resizing resizes: init-hint: ... ] ALIGNment: ---------------- It is probably not wise to change all subsequent areas to halign, valign. But anyway, we are a bit chaotic here, unless someone tells me, what's the rule here - to stay compatible to html/css, or to be consistent REBOL wise? I mean - if various areas use ALIGN/VALIGN, then my logical question is - why HPANEL/VPANEL, and not PANEL/VPANEL? My comment is just food for thought, not a claim to change anything. | |
Pekr: 17-Mar-2011 | Dunno where to chat about Jocko's demo, but as Henrik suggested to move here: - some parts are sluggish - for Rebolek - you can look at Demo/To-Do section - Jocko outlined some changes he made to some styles. His demo does not work with current RMA release if I am not wrong. - we should generally start to think, about how to "unload" certain GUI parts from memory. By just clicking here or there I got from 11MB to 38MB of memory usage. In some old GUI I used, it kept track of windows, and those were GC'ed when closed. In REBOL, if I am not mistaken, after the layout, faces objects are defined, and there is no automatic way of how to "undefine" them and free the memory. So my question is - will that be addressed, or is user responsible for the resource tracking? And is it even adressable? | |
Pekr: 17-Mar-2011 | No worry - even if you will be coding in RED, it will not have GUI, so :-) | |
Pekr: 17-Mar-2011 | One general question to GUI/gfx gurus. I know it is very preliminary, but - what about scaling? I mean - playing with my phone, I wonder, if it is facility of mobile OS, or particular app is receiving some zooming info, and acts accordingly? Are we ready for something like that? Because just recently, what we do is - resize. But we don't scale (fonts). It is just question of catching particular OS events, and create particular actors? | |
Rebolek: 17-Mar-2011 | Old flyouts changed offset in loop, so if you switch panel's show-mode to 'fixed, you can make this effect very easily. You can also animate resizing this way, but GUI will be blocked because show is handled inside loop and not using timer event. But if you keep the loop short, user won't notice that the GUI is blocked. | |
jocko: 17-Mar-2011 | Hi, guys Once again, congratulations for the excellent work done. As Rebolek suggested in ALTME, I have some modifications to submit (of course, to check from your side) for the next r3-gui release. I must first mention that I just realized this morning that the r3.exe pre-compiled version of march 11th was not working properly, bugging with some very simple text displays (probably an old version). That's the reason why I did not update the demo with the most recent r3-gui file. By the way, the build date displayed by the exe remains the same whatever the real building date. I don't know how we could have an automatic update of the build version. Rebuilding from your sources (march 11th) allowed the demo to work properly apart from some appearence differences (I have even seen some bugs solved compared to my demo version). However, I will wait for your next weekly release ;-) to update my demo. Coming back to the propositions of modifications : It seems that there are definitions problems, or incompatibilities in r3-gui (around line 66) ;-- circle: [pair! | number! | number!] circle: [pair! | pair! |number! | number!] in r3-gui (around line 1729) ;-- scale: [decimal! decimal!] scale: [pair!] also, I overload the drawing style by this code : stylize [ drawing: sensor [ about: "Simple scalar vector draw block. Can be clicked." tags: [input tab] facets: [ init-size: 100x100 ] options: [ drawing: [block!] init-size: [pair!] ] actors: [ on-make: [ ; if block? drw: face/facets/drawing [ ; bind face/gob/draw: copy drw face/facets] ] ;-- JC on-draw: [face/facets/drawing] ] ] ] Concerning the discussion of this morning on groups and panels, I would also prefer to have a default horizontal arrangement, and only precise when vertical: group, panel, vgroup, vpanel. A side effect is that it would remain compatible with Carl's doc. By the way, it seems that tight is vtight. Logically, it should be htight. That's all for the moment. When debugging the last demos, I may find other issues. | |
Henrik: 17-Mar-2011 | From R3 GUI sources: tight: vtight [] ; for compatibility right now, will be removed (in case you don't have access to source comments) | |
Ladislav: 18-Mar-2011 | Everyone else loves it - I expect a little more objective statements than this. In fact, I don't "love" MAX-SIZE at all. I just know (you have proven it), that some relevant frameworks (like the OSX GUI) include it. I am sure that is the reason, why Carl insists on it as well. So, if we want Carl to "throw our changes to the R3-GUI to the basket", we can remove the MAX-SIZE to achieve that goal. | |
Pekr: 19-Mar-2011 | Very short initial report to the new release: - keyboard area text hilight problem still persists (when hiliting from the bottom up, only one line is hilited) - drop-down shold be closeable by - clicking elsewhere in the gui, clicking arrow of drop-down, or hitting ESC | |
PeterWood: 31-Mar-2011 | By the way, I probably should only be given 0.1 of a vote as I have hardly done any GUI programming with REBOL and certainly none with REBOL3. | |
jocko: 1-Apr-2011 | a suggestion for the next release of r3-gui : the doc style (the doc parser) interprets the first line of text as a title, which is not always appropriated. For instance, in a simple alert "this is an alert", the text is displayed as title. I think that this feature should be removed. | |
PeterWood: 3-Apr-2011 | I was going to suggest a couple of alternatives but it is hard to find something that fits in with the VIEW/VID/GUI metaphors. | |
PeterWood: 3-Apr-2011 | I'm not sure if the parent/child metaphor is appropriate in REBOL3 GUI. | |
PeterWood: 3-Apr-2011 | Personally, I think that ANCESTORS, PARENT, CHILDREN and DESCENDANTS are very useful words for precisely defining relative positions in a heirarchy. They do not seem to sit well with the REBOL though as firstly they are comparative long (and many rebollers appear to worry about having to type one or two extra characters) and secondly they don't really fit in with the existing VIEW/VID/REBOL3 GUI metaphors (which are more facial - FACE, GOB etc.) | |
Ladislav: 21-Apr-2011 | Please, check the http://www.rebol.net/wiki/R3_GUI_terminologyarticle. I hope, that is describes some of the terminological issues we are trying to solve. | |
GrahamC: 22-Apr-2011 | if we wish to generalise, then [ panel 0 panel 90 ] so that in future we can go [ panel -45 panel +45 ] Can this GUI do this? | |
onetom: 22-Apr-2011 | 1) no clue. didn't read the gui terminology recently | |
Ladislav: 22-Apr-2011 | The wording of the http://www.rebol.net/wiki/R3_GUI_terminologyarticle corrected and enhanced. | |
Geomol: 22-Apr-2011 | Maybe we're just tired of user polls, or we don't have the time to dig into this. If you don't have a clear view of what a good GUI should be, and therefore need polls, then maybe use some time to get a clear view. Only suggestions. :-) I looked into it quickly, and I would at this point go for just have panel, letting vertical be a layout-mode option. Reason: K.I.S.S. (and vertical is an option anyway). And if you support user-defined styles (I'm not sure, you do, as I'm not very much into R3 GUI), then programmers can just make their own vpanels, if they need it. If I, as new to some GUI, can get it up and running in a very short time, because it's so simple, that's a huge benefit. | |
Ladislav: 22-Apr-2011 | If you don't have a clear view of what a good GUI should be, and therefore need polls, then maybe use some time to get a clear view - interesting point, should make a note | |
Ladislav: 22-Apr-2011 | In the case of the above poll, all alternatives have their advantages, as is already mentioned in the article. That is why a "good GUI" can use any of the alternatives. A "preferable GUI" should use the one the majority prefers. | |
Geomol: 22-Apr-2011 | I guess, it's extremely hard to create a really good and preferable GUI. I'm struggling with Cocoa and Interface Builder on Mac OS X atm., and I haven't seen any glimpse of a 'perfect' GUI in that yet. If I was to design a GUI, I would go for simpleness, and still make sure, advanced users can make the advanced things. | |
Geomol: 22-Apr-2011 | Suggestion: If you have user-defined styles, then why not just go with a very basic set of styles to begin with, like only panel, group, etc. And then you could make an advanced version of the GUI (by including some script with styles), where you give users vpanel, vgroup, etc. | |
Geomol: 22-Apr-2011 | Result will be, new users don't read very much documentation and can start using the GUI very quickly. If you wanna do more advanced things, read the advanced docs, include the extra script and there you go. | |
Geomol: 22-Apr-2011 | A R2 GUI document, I've used a lot over the years, is: http://www.rebol.com/docs/view-guide.html About everything is there in a small space. It's a very good document to get you going, almost perfect. Maybe just a little too long still. | |
Henrik: 22-Apr-2011 | I find that if something should be decided, you should look at how easy it is to change the code based on that decision. The easier the code is to change, the later you can make the decision. This gives people a chance to test the GUI with that particular decision. In this case, we are working purely with style names, as far as I can see, which is possible to change in a few seconds, if we don't like them. | |
Geomol: 22-Apr-2011 | Are there much R3 GUI code, that people actually use? | |
Pekr: 22-Apr-2011 | Ladislav - in your GUI terminology doc, panel/vpanel section, isn't there a typo in the source code? Imo it should be panel [button button], not hpanel [button button] | |
Robert: 8-May-2011 | We are going to re-factor the complete ACTOR & REACTOR stuff in R3-GUI. It will be streamlined, much simpler and more common in that it follows "best practices" from other GUI libs. The side effect is, that this is a bigger re-refactoring step and will take some time. Until done, we are not going to make a new release. | |
Pekr: 9-May-2011 | As status of RMA's GUI is more of a private effort targetting business level apps, I can imagine kind of simplification, which makes it "dumb, incappable and more rigid than possible", because it just fitst your limited business apps needs :-) | |
Henrik: 11-May-2011 | if you can't, then the GUI will be entirely useless. you couldn't even start it. | |
PeterWood: 9-Jun-2011 | One of the attractions of #1 is that it makes it easy to implement "default handlers" at some point higher up the hierarchy. For example based upon an "esc pressed event" (if one were to exist.) and you had designed a panel with four buttons. If you wanted to close the panel when the user pressed esc, you would simply have a single "handler" for the panel which would receive the event. I'm sure that this isn't the best example and apologise in advance for my ignorance of REBOL3-GUI and its common terms. | |
Pekr: 24-Jun-2011 | Any news from RMA guys? Not trying to push for anything, just curious about the progress of the GUI implementation. Acutally I do remember you stating you are taking longer time before there is next relase. So how things go? | |
Robert: 24-Jun-2011 | Quite good. We did some major re-factoring and are currently getting automatic GUI testing done. We need this for several reasons: 1. Automatic style lib testing 2. Applicaiton testing | |
Gerard: 11-Jul-2011 | A post to keep you informed about what the ELICA LOGO can do relative to 3D graphics, animation an GUI (under windows only) - all their libraries are open source and I thought you would like to know about - see the link in the OPEN GL group. Hope it can be useful in some way or another. Regards, Gerard | |
Henrik: 24-Aug-2011 | The current overview of all styles: http://rebol.hmkdesign.dk/files/r3/gui/253.png Some more images here: http://rebol.hmkdesign.dk/files/r3/gui/ A bit of status: - Cyphre has recently fixed a bug in the hostkit with the display of some unicode characters. Will see if there can be a release. - Cyphre has been working on fixing various low level issues in the R3 GUI source - Cyphre is working on testing scheme for GUI and some documentation - Bolek is working on styles and a TODO test application, called "Notation" for Robert - We still need Carl to fix one particular bug, which is prevents creating complex layouts | |
Pekr: 25-Aug-2011 | I am referring to: http://rebol.hmkdesign.dk/files/r3/gui/255.png - hmm, no horizontal scrolling? | |
Henrik: 27-Aug-2011 | Simple demo of automated testing: http://rebol.hmkdesign.dk/files/r3/gui/010.mov | |
Robert: 2-Sep-2011 | We are currently discussion an option how to write GUI dialects. The thing is how to access face stuff. At the moment you write it like this: get-face/field my-table [cell 2x3] Whereas I like path notation more: my-table/cell/2x3 Using path notaion is not possible but we could enhance the dialect in a way that: "get-face my-table/cell/2x3" would be converted internally to: get-face/field my-table [cell 2x3] So, what do you think? I'm not sure if supporting the path notationis worth the effort. | |
Henrik: 17-Sep-2011 | Tag field style: http://rebol.hmkdesign.dk/files/r3/gui/257.png | |
Pekr: 26-Sep-2011 | Taken from RMAsset Twitter: "We plan to release a new R3-GUI version next Friday." Any significant changes about tobe expected, in comparison to latest release? | |
Pekr: 26-Sep-2011 | ok, thanks ... Ithought that R3 GUI is suited for that task, but that would be probably a preliminary assumption :-) | |
Henrik: 26-Sep-2011 | That time is better invested in allowing people to work on specific things, like the automated testing system for the R3 GUI, rather than specialize ourselves into a corner this early. | |
Robert: 2-Oct-2011 | With our R3-GUI test-system available now, we could really need some help in creating test-cases. The more the better. We want to build-up a huge test-suite for GUI tests that we run on "every commit" to keep quality high and identify breaking changes. | |
Robert: 2-Oct-2011 | The more help to build test-cases and submit them to us, the faster we will be in pushing R3-GUI forward. | |
Pekr: 2-Oct-2011 | I can still get hard crasches of R3, in various phases: do %r3-gui.r3 do %examples/run-layouts.r3 Two times I got a crash, when just closing the windows, and when at layout #15, clicking in the form. Once I got it with layout #20, and once at layout #27, clicking the big red button ... | |
Pekr: 3-Oct-2011 | Cyphre - is there any chance Carl is going to be available to do some low-level fixes? It kind of crashes very often, but of course, with one specific use-case, so "normal GUI usage" (whatever that means) could be without any problems ... | |
Claude: 4-Oct-2011 | great release ;-) thank you. perhaps ask carl to do somethink for gui on linux | |
Pekr: 7-Oct-2011 | As for the possible "look & feel" of the GUI, I personally like HTC Sense, and Linux Mint - combination of light greay and green. IIRC Ashley created some more lightweight look for his GUI too later in the process ... http://www.xda-developers.com/wp-content/uploads/2010/04/ScreenShots.png?139d23 http://smartphoneblogging.com/android-picture-galleries/htc-sense-screenshots/ http://www.linuxmint.com/screenshots.php Take it just as a note :-) | |
Robert: 11-Oct-2011 | So, I see no one is really interested in this R3 GUI stuff... I'm wondering a bit but anyway... I think doing public releases might not be worth the effort. | |
Pekr: 11-Oct-2011 | Robert - I think that it is not accurate, that noone is interested in the R3 GUI. IMO we all are, it is just that each of us is busy elsewhere. If you look into the past of this group, or in the old GUI (Carl's one) old days, it was mostly me and 1-2 users to do some comments, studying code, etc. It is about the general lack of man-power. E.g. shadwolf claimed, he can do tree view in few hours, but is refusing to, and you better don't read the long blog chat. It is also about lost confidence of many rebollers into R3 in general. Or just maybe - ppl being in wait mode, untill Carl reappears? | |
Endo: 11-Oct-2011 | Robert: you are wrong. As Pekr said many of us are waiting and busy with something else. I downloaded all the RMA R3 stuff, tested all GUI examples (found some crash problems btw) I really would like to help/write a tree style, but I'm not a good Rebol coder I'm afraid. So please keep up the work. | |
Sunanda: 11-Oct-2011 | Robert -- an R3 GUI just isn't one of my priorities just now. While there is no likely target date for a beta release of R3, all my REBOL development is on R2. I was happy to help debug R3 alphas while that project had some momentum, and I may be again in the future, But right now, I just do not have the time for what I have to consider to be speculative projects. I hope you do get the help and feedback you need. | |
BrianH: 11-Oct-2011 | I will be more actively interested when I start having to write code that requires any GUI at all, but what I'm working on right now doesn't even need a web interface. All batch and server stuff, and almost all the REBOL stuff is R3. This can't last forever, so I will eventually need a GUI. I am working on ODBC though. | |
Pekr: 12-Oct-2011 | Well, that contradicts a bit expectation, that RMA's GUI is RT's officially endorsed GUI to be bundled with R3. OTOH there are no official R3 releases anyway, so .... | |
Pekr: 12-Oct-2011 | I understand that you are focusing resources as much as possible, otoh it is a bit dangerous aproach - R3 GUI saw rather intense concept changes during last year. Anyone eventually willing to give it a try once time permits will think twice, as recent public release could be pretty much outdated in few weeks, API wise, etc. There should imo be a way, that upon some request or bunch of requests, public release is done e.g once in few months? | |
Ladislav: 12-Oct-2011 | That are not the same excuses. For core, the excuses are, that Carl is not developing. For R3 GUI, the excuses are that we *are* developing. | |
Pekr: 12-Oct-2011 | hmm, that makes R3 GUI a private, mostly a closed effort. The only question which remains now is - once R3 development is re-established, is R3 GUI becoming part of official distribution, or not? What's Carl's take on that? :-) | |
Henrik: 12-Oct-2011 | That would depend if Carl approves it, and AFAIK he has not looked at any of the changes yet. However, it won't affect the development of the R3 GUI, whether he approves it or not. It will still be made. | |
Pekr: 12-Oct-2011 | ah, so it might be just a separate package,like RebGUI is to VID ... yes, that's possible too ... we just did not want to have many GUIs available. But R3 GUI is in limbo anyway, so .... | |
Pekr: 12-Oct-2011 | So the GUI we can see in screenshots is modified RebGUI? Looks decent enough. Similar skin would be nice tohave for R3 too .... | |
Ladislav: 12-Oct-2011 | So the GUI we can see in screenshots is modified RebGUI? - yes | |
Robert: 17-Dec-2011 | jsut a short update: We build our first real-life R3-GUI based tool. It's a little thing but needed in a lot of companies. It's a tool you can interactively create things like heat-maps with. Heat-maps for how your IT system landscape looks like, organizational things etc. It's a nested layout created with color-mapping for visualization. | |
Pekr: 17-Dec-2011 | Screenshot of the UI? Your last Twitter message towards the gui was related to creating new skin? I expect it was not high priority on your list though? | |
Group: !REBOL3 Host Kit ... [web-public] | ||
Kaj: 12-Dec-2010 | I'll get to that when I start porting View to the Syllable GUI, but that project is still a bit in the future | |
Oldes: 2-Jan-2011 | If RM want more people to join the GUI development, they should sync the host-kit with Carl. | |
Robert: 2-Jan-2011 | advanced WRT to the graphics & GUI stuff. | |
Cyphre: 4-Jan-2011 | Rebol strings are stored either as ANSI (one byte) or wide char (double byte). Of course the rich-text module is currently doing the conversion for every rendered ANSI string in realtime. Any sophisticated rich-text caching is not yet implemented. (note: this has nothing to do with font glyph cache which works well) But even though the cache of large text block is missing the performance is still very usable for normal GUI cases so the priority to spend time on the line-cache is not too high at the moment. | |
Group: !REBOL3 Proposals ... For discussion of feature proposals [web-public] | ||
PatrickP61: 2-Jan-2011 | The only thing that cannot be intercepted is when the OS itself closes rebol for any reason. An example would be a user clicking on the [X] box to close the window. Although it would be great to have a CLOSE? termination condition, I certainly understand that Rebol would not be able to intercept that. Now that I think about it, the only way that Rebol could intercept a CLOSE? condition is if the window panel itself is under Rebol control through the GUI -- but even then, that may be a difficult proposal to implement. | |
Steeve: 27-Jan-2011 | but not only GLASS, we have the same wory in any GUI engine | |
Steeve: 27-Jan-2011 | several tens of megabytes to just display a simple GUI pisses me off | |
Ashley: 28-Jan-2011 | re DEDUPLICATE ... it's not just GUI code that would benefit, DB code often needs to apply this on the result set. "buffer: unique buffer" is a common idiom, which can be problematic with very large datasets. |
2701 / 2867 | 1 | 2 | 3 | 4 | 5 | ... | 25 | 26 | 27 | [28] | 29 |