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: 1601 end: 1700]
world-name: r3wp
Group: !CureCode ... web-based bugtracking tool [web-public] | ||
Graham: 5-Feb-2010 | Would be better to create a R3 GUI project now ... or filter them off and import them later on? | |
Henrik: 24-Nov-2010 | Doc, you can create an R3 GUI project in Curecode, if you like (or can). This way, we don't pollute the REBOL 3 project with GUI bugs. | |
Henrik: 6-Dec-2010 | Any news on having an R3 GUI project under Curecode? | |
BrianH: 6-Dec-2010 | The problem with making a separate project is that it is difficult to move tickets from one project to another when they are misfiled. The other problem is that some tickets apply to both the core and the GUI. I would be OK with creating a separate project if we had a way to move tickets. But I would be even more happy with being able to filter by category in the detail view, which would allow us to effectively do the same thing with a single project. | |
BrianH: 6-Dec-2010 | There are tickets in the REBOL 3 project already that apply to the GUI, and others that apply to CureCode. Both would be nice to move. | |
Dockimbel: 6-Dec-2010 | So, I'll add a R3 GUI project as soon as the "move ticket" feature will be put online. | |
Henrik: 26-Jan-2011 | any update on adding the R3 GUI as a project to curecode? | |
Dockimbel: 27-Jan-2011 | R3 GUI project added to CureCode, ticket http://issue.cc/r3/1837 moved to R3 GUI. I've added alpha 110 & 111 to versions list, let me know if you need categories too (I would need an ordered list of items for that). | |
Group: !REBOL3 ... [web-public] | ||
Graham: 19-Jan-2010 | We should start creating subgroups ... .. as we have for R3 GUI and R3 Schemes | |
Claude: 27-Jan-2010 | but we need first a good R3 GUI | |
Gregg: 2-Feb-2010 | With the progress Graham, Andreas, and Steeve (and maybe others I've missed) have made on schemes, I would like to see their momentum and work leveraged. The host kit is probably also very important, so others can pursue that. Redirection, for writing pipe and filter apps. If the GUI console for Windows isn't too hard, that would be great IMO. | |
Graham: 3-Feb-2010 | A GUI table would be nice ... | |
Graham: 4-Feb-2010 | I was going to have a look at the R3 gui sources but they're all flattened.. Is there a pretty print for r3? | |
Henrik: 10-Feb-2010 | there are many subtle changes, so I wouldn't expect too many scripts run out of the box. GUI scripts won't work at all. | |
Robert: 14-Feb-2010 | As object! is being used more and more now in R3 and (within the GUI) a lot of words in objects will only be present if there is a value available, we have to cross-check a lot more if specific words are present. And this can pollute the code. | |
Pekr: 23-Feb-2010 | Jerry ... we all wish for things to proceed faster. However, we have to wait a bit. Hopefully Carl is doing wildly in the HostKit/Extension area, so that guys can proceed with other areas, as GUI for example ... | |
Graham: 24-Feb-2010 | Still tracing ... seems to be doing a lot with nothing happening. I would have thought the whole GUI would be in a wait | |
Graham: 26-Feb-2010 | Carl is still tidying up the GUi documents ... taking much longer than was expected | |
Graham: 28-Feb-2010 | I use 'use a lot attached usually to GUI buttons. Wonder if it's worthwhile to have a version like funct that automatically makes all set words local so that we don't have to declare them | |
Pekr: 6-Mar-2010 | any comment towards !REBOL3 GUI wait & CPU sleep times topic? :-) | |
Henrik: 19-Mar-2010 | The most "action" seems to be in R3 GUI documentation here: http://www.rebol.com/r3/docs/gui/gui.html | |
BrianH: 25-Mar-2010 | No impact for end programmers because there isn't much written in R3 yet outside of the mezzanines. But it would impact the GUI code as well, so we should get this done before too much of that is written. And people are working on that now (mostly Henrik, but still). This is a really time-critical change: Whatever we choose, it should go into one of the next two R3 releases. | |
btiffin: 14-Apr-2010 | I could google and poke around, but I'd rather Ask a Friendly Human. Where are we at with GUI and GNU/Linux? I get a crash; ** Script error: size-text has no value ** Where: font-char-size? make make-text-style parse fontize do do either load-gui ** Near: font-char-size? self Is if worth digging in for? Fonts? etc. Or, is it a don't bother yet? | |
btiffin: 14-Apr-2010 | from >> load-gui that is | |
Pekr: 14-Apr-2010 | we are not far ... yet ... R3 GUI should be pushed forward by Robert's team, but guys are mostly waiting for Carl to turn View into regular Extension, and releasing its sources, so that low-level View enhancements can be done. As for VID itself, we are still in kind of wait mode imo ... | |
Pekr: 21-Apr-2010 | Is there any resolution to this topic? (Console) ... when playing with R3, I can't stand that ugly Windows "console" more and more :-) We can't even have multiline cut & paste :-( http://www.rebol.net/r3blogs/0282.html I don't remember the outcome - will we put R2 console back to Windows distro? Or wait for our own GUI based one? | |
BrianH: 4-May-2010 | For that matter, accessors can be written in functional or procedural style, often more efficiently too, as they are in R3's GUI. | |
BrianH: 4-May-2010 | So the main thing that the property feature does (from my extensive experience using that feature in other languages) is to hide complexity. Which is great, until you actually need to know what the heck is going on - something that happens almost immediately. At that point, hiding the complexity means destroying your ability to understand your own code by looking at it, even a simple assignment statement, and forcing you into a particular model of operation that may or may not be appropriate. So it's great for Delphi, which comes with a built-in GUI framework and is supposed to be easy for VB-level programmers to use; it's not so good for REBOL, where the GUI is swappable and our users are in some cases some of the smartest people I've ever met. | |
Steeve: 4-May-2010 | I used that technic in an GUI trial for R3, the syntax was pretty light. | |
Maxim: 4-May-2010 | and glass even uses the liquid (trans)mutation feature where you swap classes on the fly based on oranisation of GUI | |
BrianH: 4-May-2010 | (Sorry, phone calls) Processed fields are great, and accessors are a great, but there are at least 3 different ways of doing accessors (method, procedural, functional) and syntax support would only support the method-style accessors. And because of REBOL's object model, method-style accessors have a lot of memory overhead, whether they are supported by syntax or not. This is why R3's GUI uses procedural/functional accessors. | |
Steeve: 5-May-2010 | but there is a memory overhead, so take it with care... (actually it's not suited for intensive computings inside a GUI,, just my opinion) >> same? d/pane d/pane == false | |
Maxim: 5-May-2010 | the hostkit extraction is a pretty huge endeavour, because he has to change the core model and open it up much more. the GUI pokes at just about every level into the core things like actions (callbacks into the core), devices, object access, these can't be side-stepped IMHO. yes the A98 (or whichever release fully extracts view from the core as an extension), will be the mother of all releases. The only REBOL release I have been waiting for... for over a decade. | |
BrianH: 5-May-2010 | For one thing, gobs can't copy their data references even if you use COPY/deep, because gobs don't understand what is in those references, and because in almost all cases there are reference cycles in the GUI between the gob and the object referred to by the data. I can't imagine it ever being safe to copy gobs in a real GUI. | |
BrianH: 5-May-2010 | In R3, the GUI objects have a reference to their gobs, for high level code, and the same gobs have a reference to their higher-level objects in their data field, for low-level code. Both of these references are necessary. So im most cases there is a reference cycle in real-world code. | |
Pekr: 6-May-2010 | hmm, 395 KB, so GUI-less release. Preparation for View externalisation :-) | |
GiuseppeC: 7-May-2010 | It seems that the migration of GUI to the external host is more difficult that expected. | |
shadwolf: 13-May-2010 | i was reading doc about moblin now meegoo os and i was stunned to learn all their gui where based uppon QT &and ... | |
shadwolf: 13-May-2010 | why not rebol ,,, serriously if you have to fall that low as using javascipt + QT for you gui only to say we do quick qt developpements why not using rebol? | |
Maxim: 13-May-2010 | Gab, yes I actually have some secret little links into the batcave ;-) but I don't have specific details beyond the fact that he is commited to the view extraction and that its not a piece of cake. the rest of my comments really are just by obvious architectural analysis and having tried to plug into the core myself and realizing how much is still missing to provide an integrated GUI which cooperates with the core. even the event/device/messaging system isn't totally usable externally right now. the command! concept is being rewritten from the ground up so it supports some kind of contextualized operation (could this be the basis for callbacks into the core? :-) and when I mean design changes, Its realy things like: before we could call an action directly within a face... there is no callback procedure in R3 hostkit beyond running a string in the global context. there is no object/function support in the extensions, cause that opens up a big can of worms (and some secrets into the interpreter's operation?). the current R3 relies on the protection it has living within core, now, Carl will have to open up the core a lot so that he can plug back into it, and yes, since Carl is a perfectionist, he won't allow that openess to be a security risk or half-assed solution. | |
BrianH: 14-May-2010 | Not systematically yet, but yes on an ad-hoc basis for a few years now. Even during the GUI design phase before the first 2.100 public alpha. | |
Henrik: 24-May-2010 | I don't think you should do that yet. Wait 6-12 months and see what tools are around. What RM Asset is developing is mostly backend/tools stuff, to make sure that developing boring business apps becomes a smooth and quick process and some of these things wouldn't work well in R2 or would be hampered by various already known showstoppers. We have to think forward and build this stuff under R3 now, otherwise we will have two things: A fast and poorly supported platform to build apps on (R3) and a slow and limited platform to build apps on (R2), and we don't want that, do we? Besides, RM Asset already has some target apps in mind for R3. Also given how R3 uses a hostkit, gives everyone much more control over how they want certain things done or add special extensions to, say, graphics or database capability without having to ask Carl to add it. I think you will appreciate that this stuff is done first, so you can build a good app in a few days, rather than spending 2 months doing it. It'll save you a good bit of money too. This involves GUI test tools, customer feedback mechanisms built into the GUI, quickly integrating a GUI with a database, completing the GUI generally, various extensions, such as the high speed networking extensions needed for xpeers-II. | |
Pekr: 24-May-2010 | Customer feedback into the GUI? I am really interested to know, what is VID turning into :-) Or is functionality as "customer feedback mechanism" an addon? Maybe it would be helpful to have some high-level diagram, about GUI components ... | |
Maxim: 26-May-2010 | with view extraction from the coe, he has NO CHOICE in giving us a means to execute loaded, bound, code, since all a GUI really does is trigger code. code which is managed by the core. I also know that vector and image datatypes will definitely be part of next extension, its really important. I am in the process of requesting that the argument frame be increased to 15 arguments by default... 7 is ridiculously low, especially if you want to use refinements. | |
Pekr: 2-Jun-2010 | ... well, that was for a host kit and maybe a GUI ... as for RIF and R3/Services - wait 5 years ... | |
Robert: 1-Jul-2010 | IMO it's more critical to use to get a good GUI up & running with a broad set of styles. | |
Robert: 1-Jul-2010 | My goal is to get R3 out of alpha, beta to release. To get the GUI to a state that you can create apps with it. | |
Graham: 1-Jul-2010 | Well, a GUI a nice, but the working out network details seems a little more basic :) | |
Pekr: 1-Jul-2010 | as for apps - GUI, networking, DB drivers .... | |
Henrik: 2-Jul-2010 | Graphics extension loads: http://rebol.hmkdesign.dk/files/r3/gui/217.png List of graphics functions: http://rebol.hmkdesign.dk/files/r3/gui/218.png There was a small demo to display a random collection of gobs, but a bug in the host kit prevents me from taking a screenshot. | |
Gregg: 2-Jul-2010 | IMO it's more critical to use to get a good GUI up & running with a broad set of styles. I agree Robert. Even if the set of styles is not broad, if we have a few good examples of how to write styles (and maybe some docs, which I am willing to help with), we can turn the community loose. | |
Gregg: 2-Jul-2010 | We should also have a list of styles, and if a core GUI team member sketched out rough designs or inheritance/composition thoughts and prototypes, we stand a better chance of our work being used. | |
Graham: 2-Jul-2010 | you have to be part of the gui developement team ... | |
BrianH: 17-Jul-2010 | We have the !REBOL3 GUI and !REBOL3 Extensions groups to handle that request. It's a work in process. What else? | |
Graham: 21-Jul-2010 | Interesting .. so I can start my gui that way as a task | |
BrianH: 22-Jul-2010 | With Silverlight/Moonlight, you don't need a side interface, it has a GUI. That GUI will be accellerated by OpenGL or whatever is available. With Mono, you can integrate anything. | |
BrianH: 22-Jul-2010 | Oh, then this conversation is more off-topic in this group than I thought. Well, here's what you missed: - The R3 GUI is being actively developed by commercial developers, and it is much faster than the approach you just mentioned. - We have had a couple releases in the last week, with more to come. In other words, we're not stuck. - The GUI code has been moved to the host, and is thus open source. - Everyone involved is hard at work, communicating, and busy. This includes Carl. - All of your criticisms of the project are outdated. | |
Pekr: 31-Jul-2010 | GUI, console (not willing to experiment that much with the Windows default one), call, protocols (ftp, email, easy-cgi), DB (mysql, sqlite) | |
Graham: 31-Jul-2010 | Well, of those, I think I only see 'call and 'gui as blocking ... as the others are either usable in some sort of fashion | |
Robert: 1-Aug-2010 | GUI: This will result in a bunch of styles we need. | |
TomBon: 1-Aug-2010 | robert, great to hear about the gui. what kind of styles you are planning? some advanced ones like treeview etc.? | |
Oldes: 1-Aug-2010 | Do you know when is planed the unicode support in gui's textfields? | |
BrianH: 2-Aug-2010 | Having trouble finding it. The function is more than 2 years old, and first came about during the first closed GUI development project. | |
Graham: 12-Aug-2010 | he doesn't say what fails though ... whether it was the core or the gui | |
BrianH: 12-Aug-2010 | Here's an interesting subject: What value does R3 have as a library in another app with its own GUI and networking? | |
BrianH: 13-Aug-2010 | The only platform that I know of that would prohibit native REBOL is Win7 (don't know about BB). However, some platforms (especially iPhone) won't allow the full REBOL experience including the GUI. Most GUI layouts would need rethinking for the small screen anyways, and using native tookkits matters much more on phones (memory, consistency), so that's not as big a deal. It does mean that we need to pay more attention to embedded profiles of the host kit. | |
Pekr: 13-Aug-2010 | but GUI (VID) is exactly our advantage imo, to show the world, how easy is it to do basic form apps. There is not much to adhere toGUI wise imo. Each app can look totally different, like in old Amiga days, no? | |
BrianH: 13-Aug-2010 | The pricniple behind VID - simple dialected GUI layouts - is REBOL's strength. The actual implementation would not be as much of a strength on a memory-constrained system with a native GUI toolkit and strict UI design rules. However, you can make a simple cross-platform layout dialect for phone UIs that tells the native toolkit what to do, and then make platform-specific implementations for the various native toolkits. Dialecting is REBOL's greatest strength. | |
Maxim: 13-Aug-2010 | a lot of VID's dialect can be used to describe the layout even on native GUI toolkits. | |
BrianH: 13-Aug-2010 | Exactly! You would need to redo your layout anyways for the small screen (unless the layout dialect is *really* properly strict about not allowing sizes, offsets and real colors in its layouts, the way the R3 GUI is supposed to be), but the layout dialect itself could be very compatible and you could reuse a lot of code. | |
Robert: 16-Aug-2010 | WRT to all the discussions in ~Vent / Rebol3 GUI etc. I want to make some points clear. And, don't interpret things that are not written as these will be false. | |
Robert: 16-Aug-2010 | 3. rebol3 gui: We are working on getting VID to a state that it can be used for app development. For this we did a complete new resizing system, changed the styles etc. This is not yet ready for release because to much flux in the design and code. We will release it either in form of the official VID via Carl or as our own VID fork, if Carl decides that the official VID should look differently. No decision taken yet and I hope that we don't need to fork VID. | |
Henrik: 22-Aug-2010 | android: should be possible, as it allows native C libraries, but not sure about GUI stuff. | |
Robert: 23-Aug-2010 | Answering to Petr's R3-GUI question, here, as it's not GUI related. | |
Pekr: 23-Aug-2010 | I posted in R3-GUI as I consider it being "your group" :-) Well, 1-2 month bug-fixing could be usefull, but I know ppl - noone will consider R3 ready, unless the basic infrastructure is in-place. And not having tasking/IPC is one big handicap - e.g. Doc will surely not start the Cheyenne transition (if he will port it at all) ..... that's how I feel about it. 'Call needs to be implemented too, or R3 stays in isolation for system related scripting. Your aproach limits R3 to only GUI realated usage ... if we are rushing to have R3 1.0 stamp on it, then priorities, or simply target feature-set should be discussed, and set .... | |
Pekr: 23-Aug-2010 | ... but - then we are getting into Max's territory of GUI aproach ... so Max - better release your stuff, before Carl does so :-) | |
Maxim: 24-Aug-2010 | yes... most applications now are multi-threaded if only to make them smoother... the GUI in one thread, heavy lifting in another, for example. async, doesn't allow you to scale, only to time slice. you can still only compute on a single request at a time. if the request needs time to finish (rendering, for example), it effectively blocks all async and I/O handling. | |
Steeve: 28-Aug-2010 | but maybe it will be a real GUI | |
AdrianS: 10-Sep-2010 | Henrik put up a link to his newest build in REBOL3 GUI: http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3 | |
Ashley: 10-Sep-2010 | show and size-text are natives not mezz. Without them you can't build a GUI. | |
AdrianS: 10-Sep-2010 | Should I expect something different?: >> do %r3-gui.r3 Script: "Untitled" Version: none Date: none >> source show show: make command! [[ {Display or update a graphical object or block of them.} gob [gob! none!] ]] >> source size-text size-text: make command! [[ {Returns the size of text rendered by a graphics object.} gob [gob!] ]] >> | |
AdrianS: 10-Sep-2010 | I was trying to make a build with r3-gui.r included, but when running the generation step of the build make-host-init.r outputs the error "Invalid tuple -- 2.147484e9x2.147484e9" when processing this file. Is there something wrong with this tuple? | |
AdrianS: 10-Sep-2010 | the offending line in r3-gui is: max-size: 2.147484e9x2.147484e9 | |
Henrik: 10-Sep-2010 | skimming... r3-gui.r3 requires A105. anything below will give a size-text error. | |
Claude: 10-Sep-2010 | >> demo Fetching demo... Script: "R3 GUI - Development Test Script" Version: 0.1.2 Date: none This R3 release does not provide a graphics system. The demo cannot be shown. >> do http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3 Script: "Untitled" Version: none Date: none ** access error: cannot open: %shape.r reason: none >> system/version == 2.100.107.4.2 | |
AdrianS: 10-Sep-2010 | I believe that the build that was posted didn't have the draw stuff in - on my own build, I get this error when I try the demo after loading your r3-gui script: >> do %r3-gui.r3 Script: "Untitled" Version: none Date: none >> >> demo Fetching demo... Script: "R3 GUI - Development Test Script" Version: 0.1.2 Date: none Fetching GUI... GUI Version: 0.2.1 (Developer test GUI theme) ** Script error: expected command! not font ** Where: size-text font-char-size? make make-text-style parse fontize do do either load-gui case catch either either applier do try demo ** Near: size-text gob | |
BrianH: 30-Sep-2010 | No, it wouldn't, because there are still a few opt-in modules that are included but not imported by default. For instance, modules that implement conflicting functionality, such as CGI vs. GUI. | |
Andreas: 19-Oct-2010 | (Besides, I got the impression from the R3 GUI team that they have A108 pre-releases with graphics enabled. Might have read a bit too much between the lines, though.) | |
BrianH: 19-Oct-2010 | Except the history of the R3 releases since RMA took over the R3-GUI project. | |
Pekr: 20-Oct-2010 | Well, it will be possible, once R3 is not going to be a GUI app. | |
Pekr: 20-Oct-2010 | Andreas - power console can't work. I tried Console2. The outcome is, you can't have both the true console mode and the GUI app. Look at the above link. Or simply Carl was not able to achieve that. Some ppl said, that is the reason why Python has two executables - one for plain console mode, and the other for GUI mode. But I might not interpret it correctly ... | |
Andreas: 20-Oct-2010 | RT binaries are built as GUI apps, the above is built as Console app. | |
Pekr: 21-Oct-2010 | launch from cmd.exe is fixed. Although I would like to see R3 to reuse cmd console, if it does not include GUI ... | |
ChristianE: 21-Oct-2010 | Cyphre, Andreas, that's what I was seeing, too. Build as console app --> no unicode chars displayed, build as gui app --> unicode chars are fine, but you can't run in a console window. I don't know what other languages are doing or if there is a way to fix this at all. From the information I gathered back then, I'd say, probably there isn't. | |
Cyphre: 21-Oct-2010 | ok, that is in the 'console app' mode....sorry I meant that there might be a way how to check if the 'GUI app' is run standalone or from console and then decide what approach to use. But I haven't tried to play with it yet. | |
Andreas: 21-Oct-2010 | unfortunately there seems to be no way for a GUI app to keep an association to the console it was launched from. | |
Andreas: 26-Oct-2010 | (Ah yes, console not GUI build, so that last part is for free :) | |
Pekr: 26-Oct-2010 | ok, what about having console (not GUI) build of R3, and loading View extension? Could it work? | |
Pekr: 26-Oct-2010 | yes ... that is why I am confused, because there was a saying, that under Windows, you can't have both worlds - console, and GUI app in one, and that e.g. even python uses two separate executables ... | |
Group: DevCon2010 ... this years devcon [web-public] | ||
Pekr: 2-Feb-2010 | One day, once we rebollers become rich, we buy some nice piece of land ourselves. It will be renamed to Reui ... and new GUI system will be called the same name :-) |
1601 / 2867 | 1 | 2 | 3 | 4 | 5 | ... | 15 | 16 | [17] | 18 | 19 | ... | 25 | 26 | 27 | 28 | 29 |