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: 101 end: 200]
world-name: r4wp
Group: #Red ... Red language group [web-public] | ||
DocKimbel: 30-Nov-2012 | I want ALSO View/VID, which is being kind of dismissed here both by Doc and Kaj :-) Absolutly not, I'm just saying that I will build a native GUI solution first, a View-like solution is not my priority but it is welcome. If nobody makes a View-like engine, nor wraps R3/GUI engine, I will consider making one myself when I will have more time. | |
Pekr: 30-Nov-2012 | Doc - I know - what I want is - free form GUI, not necessarily a native GUI, which is mostly good for forms like apps imo. Or just please show me particles.r 1.6KB demo rewritten to GTK :-) | |
Gregg: 30-Nov-2012 | I created a folder and blank file for you Petr: %Red/GUI/Petr's Wishlist.txt | |
Arnold: 1-Dec-2012 | As far as the wish for a View/VID native solution goes, I wish that as well. Maybe it will be possible when the JIT compiler becomes reality to easily adapt Rebol's VID. It does not have to be complete like VID, a basic set of widgets will get you a long way. Other solutions are a really good thing too, but looking at GTK and myself I find it hard to find out how to get GTK on my mac. It is not a standard dmg file I can download and install and it works. Other GUI solutions require integration of their package or having the end user of your programs to find out how to get it running on their machine. That kind of thing can be a real showstopper to global acceptance. I know Doc is working hard and has already stated he intends to come up with a VID like native solution. So we can let him focus and be silent ,or we can comment and discuss letting him know we do care. | |
Pekr: 2-Dec-2012 | His point is, that with PC world converging towards touch, tooltips are a dead concept - there is no hover with touch devices. I also myself don't like pop-up menus, etc. - it was always a hell, and requires special treatment in GUI subsystems .... | |
BrianH: 26-Dec-2012 | We were more focused on lower-level things. The console wasn't much of a priority, especially since we were intending to implement it in the R3-GUI, and that wasn't there yet. | |
Pekr: 26-Dec-2012 | Actually, I am trying to send 50 on a month basis. Now r3 gui project is temting too, but i would have to see the project outline, eg seeing, that cyphre will be paid to update the engine to use hw acceleration, etc. I would love View engine to be useable with Red too. I ca feel some excitement last few weeks, fort both r3 and red projects :-) | |
DocKimbel: 6-Jan-2013 | Red/System is in beta stage. Whether or not it is a good choice for a GUI app is matter of personal taste. I personally gave up building GUI apps in a C-level language a long time ago. However, if you want to give it a try, I recommend you Kaj's GTK+ binding, which now works fine on Linux ARM, as shown here: http://static.red-lang.org/rpi-gtk-widgets.png You can see the source code for this GTK+ demo here: http://red.esperconsultancy.nl/Red-GTK/artifact/3453dd410a1c64ca8f842f75c7431b6f7fc3c4b3 As you can see, Red/System has some limited dialecting capabilities that Kaj leveraged to build a very nice GUI dialect (which is quite an achievement for a low-level language). | |
Gerard: 6-Jan-2013 | Thanks Doc for sharing this information and Kaj for doing this GUI binding, paving the way for newcomers and sharing the source for deep study. When I will be going back to my former status (more free time) I plan to deeply study Red/System in parallel with the C language just to be able to write some small doc (or book) to help newcomers to start with Red/System after coming from the C environment. In fact it's a long time I planned to do it for myself first but never found the time to do so when I worked as a teacher in the past. Now I hope I will better drive my diary to cope with this new planniing !!! | |
Pekr: 17-Jan-2013 | Just donated 50 EUR so that Red project does not feel bad by my move to donate also to R3/Android/GUI :-) | |
Kaj: 1-Feb-2013 | Here's the code for the Red GUI IDE: | |
Kaj: 1-Feb-2013 | It requires a completely extra set of bindings, including to the Java VM and the GUI. We're thinking about it | |
NickA: 15-Feb-2013 | No one will be impressed with normal GUI, email, database capabilities, even if it's 10x more productive, but anything multimedia, video, 3D, etc. which demonstrates "modern" capabilities, and beats other solutions, works on mobile, etc., then they're much more likely to go "hmmm". | |
Kaj: 5-Mar-2013 | It's best to use the MSDOS folder. The Windows folder is less complete and compiled as GUI apps, so no command line output | |
NickA: 7-Mar-2013 | I just never got very far with Boron. I donated to it when I thought it could be a viable open source alternative to R2, but it's feature set never evolved enough to be useful for work, like R2. That's been the problem with ALL REBOL related language tools for the past 6 years or so. That's what made/makes R2 attractive. A full stack of usable tools for creating applications. If the Saphirion guys and Doc build usable tool sets with mature GUI, sound, database, 3D, etc. APIs, then people will begin to use those languages. Boron never had any of those features implemented in a user friendly way. | |
NickA: 7-Mar-2013 | I still think as a full package, REBOL is better, but R2 is getting old an losing support for new, cool features and platforms. If Cyphre is succesful porting R3 GUI to Android, it's got a chance. If Doc gets Red evolved enough to support basic features, it's got a helluva chance. | |
Kaj: 18-Mar-2013 | I hardly ever email, but if he has no plans, it would be a nice second backend that I could make for my GUI dialect | |
Bo: 3-Apr-2013 | Yes, I had a copy of your newer C library binding. I compared the relevant sections and added in the appropriate parts. Now I have a different problem, possibly due to me not running a gui on my Raspberry Pi. Don't know yet if OpenCV requires a GUI to operate or not. | |
Kaj: 7-Apr-2013 | I think OS X GUI apps are fundamentally dual-threaded, with one thread for the GUI, so in the best case, it uses two cores more or less | |
DocKimbel: 29-Apr-2013 | Red executables (like R3 ones or any other language compiled to native code) are not supported directly by mobile OSes. So, it needs to be loaded and called from Java or obj-c, hence the need for shared library support. The experiments with Red/System on Android was limited because using such approach, you can't have access to the higher level API, can't access GUI and need an hack to get it loaded. My goal was just to check that Red/System toolchain was able to produce code that runs on Android. | |
Group: Announce ... Announcements only - use Ann-reply to chat [web-public] | ||
Robert: 1-Jan-2013 | Please note: Scroll through the pages since we sometimes combine several MDP files into one page. Not the nicest way at the moment, but works best to avoid so many pages. The start is for MDP itself and R3-GUI / Actors. | |
Robert: 1-Jan-2013 | Massive R3-GUI documentation brought online. ATT: The docs still referr to the old GUI model. We are going to clean everything up in the next weeks. | |
Maxim: 4-Jan-2013 | does it currently have GUI support? | |
Kaj: 20-Jan-2013 | I moved the GTK+ and GLib bindings for Red/System into CONTEXTs. If you have written code on top of it, you need to adapt the interface. The GUI dialect is now basically independent from GTK; that is, it could be implemented unchanged for other GUI toolkits. | |
Kaj: 30-Jan-2013 | I wrote a simple text editor in the Red GUI dialect: http://red.esperconsultancy.nl/Red-GTK/dir?ci=tip&name=examples | |
Kaj: 1-Feb-2013 | With Doc's latest Red fixes, I was able to write a very simple IDE in the GUI dialect: http://red.esperconsultancy.nl/Red-GTK/dir?ci=tip&name=examples You can write either regular Red code or GUI dialect code, and execute it with respectively the Do or View button. Do executes the code in the interpreter, so no compilation is needed, but the current limitations of the interpreter apply. The code is only 25 lines, but at Brian's request, I'll post that in the #Red channel. | |
Robert: 23-Feb-2013 | New Android release: URL : http://development.saphirion.com/experimental/ Direct URL : http://development.saphirion.com/experimental/r3-droid.apk Changes: -fixed console output crashes -implemented CLIPBOARD:// device -implemented BROWSE -added circular buffer to console -release has now correct platform, version, product and build information -fixed console input hang-on-destroy bug Please give it a try and have fun. This release is a milestone since now Rebol CORE is fully done for Android. We will now start to get the VIEW (graphics) to Android. As soon as we have this, R3-GUI should almost work on Android too. | |
Kaj: 9-Mar-2013 | Then again, maybe not with the MSDOS version, that is compiled to not be a GUI program | |
Robert: 5-May-2013 | Cross-Post from Android group: New release of Rebol3 with graphics on Android: http://development.saphirion.com/experimental/r3-droid.apk Changes: -enable CTO and OTC functions -fix window offset -fix image! / loaders pixelformat color order -fixed close button action (RL_Init failed?) -improved WAIT -added clipping(slow atm but works) -added RESIZE/ROTATE events -improved JNI calls synchronization -added native keyboard input -updated built-in R3-GUI version Note this release is very early alpha so expect unstable situations or even crashes. Feel free to report bugs or any other feedback. This gets us again one step closer to be able to create Android apps with Rebol. Simple, small, fast. :-) | |
Robert: 31-May-2013 | I'm happy to announce that we reached a major milestone and can release a bunch of new things. All the different versions have been merged into one code base which makes things easier for us. This was possible because the new 'retargetable' graphics subsystem was finished. This allows us to port R3 to other platforms much easier. Next target Linux. The release in detail: R3-GUI: Quite a lot of fixes and enhancements. Thanks for all the feedback. The main milestone we achieved was to switch to a resolution independent sizing system. This will scale your app widgets to look the same on different display densities. It's a must have for mobile apps. Next for R3-GUI is to create a simple mobile style set. Fruther, we are going to push the source code to GitHub. We need to setup a bridge to our internal SVN repository, so expect some back and forth on Github before we are stable. Anway feel free to help making R3-GUI better and better. Android: This release is now mostly the same as the windows release. So, yes, it's now possible to do R3-GUI apps on Android. I'm going to try to run Treemapper on it. Type DEMO to see the new R3-GUI version and widget scaling feature. Post as much screenshots / pictures of your phone as you can :-) R3/Saphir: New version for windows with bug-fixes are released as well. Please see the change-log on our web-site for details. Thanks to all the team for the great work! I really think we are close to have a very good and stable base with R3 and R3-GUI. Looking forward to see more and more people joining and becoming part of it. Links: http://development.saphirion.com (Change Logs, Downloads, etc.) http://development.saphirion.com/experimental (Android) https://github.com/organizations/saphirion (Documentations) | |
Andreas: 18-Jun-2013 | I wrote a quick & minimal example illustrating how to use R3-GUI together with R3's async HTTP: https://gist.github.com/earl/447e4e9510a68c308f6b | |
Kaj: 20-Jun-2013 | For relevant platforms, I added extra versions of my Red interpreter console distributions to my downloads: http://red.esperconsultancy.nl/Red-test/dir?ci=tip They provide versions that include my 0MQ binding for messaging. Previous interpreter distributions didn't include it, because on most platforms, you have to install the 0MQ library as an extra. Further, people may need 0MQ with the GTK+ GUI binding, or without it on servers and embedded systems. So there are two new distributions in each platform folder: */Red/red-core-message */Red/red-message red-core-message is meant for servers and includes bindings for the C library, cURL, SQLite and 0MQ. In addition, red-message also includes the GTK binding and is meant for GUI programs. For Windows, most of these interpreters are in the MSDOS/Red/ folder, but I also added a version that is meant to start scripts for GUI programs, so it doesn't open an extra console window: Windows/Red/red-message.exe | |
Kaj: 20-Jun-2013 | As an example, the interpreter to run messaging scripts on a Raspberry Pi without GUI is here: Linux-ARM/Red/red-core-message The interpreter to develop GUI scripts on x86 Linux to communicate with a Raspberry Pi is here: Linux/Red/red-message A similar interpreter to develop GUI scripts on Windows to communicate with a Raspberry Pi is here: MSDOS/Red/red-message.exe As always, for Windows you also have to download the libraries that are included in the repository, according to the instructions here: http://web.syllable.org/news/2012-11-18-20-47-Red-high-level-programming-language-first-alpha.html | |
Robert: 14-Jul-2013 | In conjunction we did a new R3-GUI release as well. added DETAB flag support fixed TEXT-AREA issues fixed TEXT init-size handling fixed SIZE-TXT bug built new R3GUI release (version 4897) delete "experimental" layout-sizing-independent.r3 improve rouding move docs/r3-gui/ to documentation/r3/r3-gui/ remove documentation/r3/r3-gui/license/ directory containing obsolete license Copyright notice update license update typo fixed Rounding correction improved rotate event handling improved drag handling code (removed duplicate gui-events/drag reference) improved android text input handling fixed progress resizing improved text-able cell font handling fonts are antialiased by default on android now http://development.saphirion.com/resources/r3-gui.r | |
Luis: 15-Jul-2013 | Robert, Cyphre Congratulations !! Correct link for r3-gui is: http://development.saphirion.com/resources/r3-gui.r3 (no .r) | |
Robert: 19-Jul-2013 | We have pushed our R3-GUI sources to Github. The project was cleaned up, old stuff removed etc. So it should be in pretty good shape. We keep the GibHub repository in sync with our internal SVN repository. We will further take a look at pull requests and take your feedback into our main line. You can find the repository here: https://github.com/saphirion/r3-gui | |
Group: Rebol School ... REBOL School [web-public] | ||
afsanehsamim: 23-Nov-2012 | in GUI result should not be like blobks, correct? | |
afsanehsamim: 23-Nov-2012 | you mean i should put my gui sfter print | |
Ladislav: 23-Nov-2012 | ALERT is not meant for CGI, it is a GUI function. | |
Ladislav: 22-Mar-2013 | ...but the GUI example should be in the repertoire of beginners, don't you think? (and it even "caught" Cyphre, so he asked me how to do it properly using function, so I had to tell him: "don't") | |
Gregg: 22-Mar-2013 | On the GUI, yes, perhaps. | |
Gregg: 23-Apr-2013 | REBOL, under Windows, uses its own GUI "console" window, so you have to trick it. Running it in CGI mode should work for you. | |
GrahamC: 7-May-2013 | have you done 'load-gui before you run the script? | |
Group: #Red Docs ... How should Red be documented [web-public] | ||
Oldes: 3-Dec-2012 | Here is script which I used to cerate it... note that there are not existing links in Carl's reference (in the GUI section). Hope Red will have documentation without such a silly errors. https://github.com/Oldes/rs/commit/cb6cf1a8d2e3cb2bface3f3c13c3e071ff5e0aa1 | |
james_nak: 3-Dec-2012 | I think I should chime in here because I am one of those people who are not naturally inclined toward the programming arts. I see that many of you realize that the docs have to reach a vast audience from novice to expert. That will involve using different methods of presentaton and detail. How would you envision the database to look like. If we could create something pretty complete then I think all the desired above could be accomplished. For what it's worth I use the following: The rebol dictionary - to look up words and usage I can't remember, try to decipher some functionality I need, hopefully find examples. The View docs - to find out how things works and to remember how certain words work Everything I can find on Parse - This is one subject that is all over the place. Nick's tutorial and Reboltutorial - To learn about topical items that one can do in rebol such as sound and animation. Altme - Asking all of you, especially Henrik, if I can do something and how or when something doesn't work. Rebol.org - To find scripts that do things I need to do Google - OK, this is generic and possibly obvious but when I am trying to figure something out, it's "Rebol ..." The above items are my most used resources and not exclusive. Note, for me the R3 docs were harder to navigate, especially a few years ago when I was looking at the GUI stuff. To me at least they seemed all over the place. So, if one were to analyze that usage, it may help to develop something that can accomplish those different needs. | |
Henrik: 3-Dec-2012 | About wikis, I would probably prefer that the document structure is fixed, and then each page can be a wiki. We had problems early on with the R3 GUI documentation that someone changed it. | |
Gregg: 3-Dec-2012 | Someone also wrote a makedoc GUI, didn't they? Are there tools like that for managing a doc base? I also agree with some earlier comments about some commercial sites having very good docs. How do they do it? | |
Henrik: 3-Dec-2012 | Gabriele wrote a MakeDoc GUI a long time ago. | |
Group: !REBOL3 ... General discussion about REBOL 3 [web-public] | ||
Robert: 16-Dec-2012 | Saphirion is building up a repository with a nightly-build infrastructure. We are currently working on these things: - Win32 builds, mostly done - automatic check of other repositories for changes and pulling changes for test-builds - merging our host-kit to get View and R3-GUI - cross-compiling for Win, OSX & Linux | |
Robert: 16-Dec-2012 | Than we will extend R3-GUI and the automatic test-framework. The latter is used to regression test all R3 builds over and over again. We currently have about 50 cases that crash R3. These need to get fixed. | |
Scot: 17-Dec-2012 | Essentially we need a consistent GUI SDK that will create apps for both platforms.. | |
Kaj: 17-Dec-2012 | Porting the GUI to a new platform is a lot of work | |
Kaj: 17-Dec-2012 | You could write the GUI in the native technology, and do the core app in an embedded R3 library | |
Scot: 17-Dec-2012 | Useless to us. We'll stick with Javascript/HTML/CSS/Java/JSON if we can't use a REBOL dialect for GUI's. | |
Scot: 17-Dec-2012 | What is the state of the GUI on R3? | |
Andreas: 17-Dec-2012 | Win32 only. Draw in the /View builds. R3-GUI from Saphirion on top of that. | |
Andreas: 17-Dec-2012 | Afaik R3 GUI is workably stable. Saphirion has a non-trivial app running with it. | |
Kaj: 17-Dec-2012 | Than we will extend R3-GUI and the automatic test-framework. The latter is used to regression test all R3 builds over and over again. We currently have about 50 cases that crash R3. These need to get fixed. | |
AdrianS: 17-Dec-2012 | Would it make sense to for a start, have a non-native GUI running on top of OpenGL? This is what you see from a bunch of different groups out there - e.g. using Lua (Corona, Gideros, Muai), Python (Kivy), Haxe, etc. This could maybe be done more quickly since I think there's already been some experimenting with OpenGL by Maxim, and others (Cyphre?). I guess taking this route would depend on how much work it would be to make Draw run over OpenGL, but it would open the door to a certain class of apps (games, graphics).. | |
Pekr: 18-Dec-2012 | Yes, imo the first thing, whichou would REALLY help R3 GUI, would be to create a new skin - boxy, simplified, modern. No capsules and old OS9 Apple design hybrids ... | |
Cyphre: 18-Dec-2012 | Henrik, Pekr, yes R3GUI needs to get some nicer skin but otherwise in terms of functionality it's a proof the current R3 can be used for GUI apps even now. | |
AdrianS: 21-Dec-2012 | Is the r3-gui available on the Saphirion site download section the most recent version? It's from March this year, and I seem to remember some activity on it after that point. | |
Robert: 21-Dec-2012 | r3-gui is available. It's not the latest release but works. We are going to update it. I need to fix the web-site project as it's currently broken. | |
GiuseppeC: 22-Dec-2012 | Robert, is it possible to show JPEG images using your R3 GUI ? | |
BrianH: 26-Dec-2012 | Pekr, R2's console was GUI on Windows, not a real console app. Carl had wanted to make an R3 console like R2's but better, in the R3 GUI. We just never got around to it. | |
BrianH: 26-Dec-2012 | Carl's blog was about the inline text-mode problem, trying to solve the open-a-window bug. That wasn't about the planned GUI, it was about fixing the existing console. | |
BrianH: 26-Dec-2012 | If you are talking about the existing R3 console, the problem was that he couldn't make a real console-mode R3 program without losing functionality that he only knew how to support in GUI-mode programs, and he couldn't make a GUI-mode app use the Windows console without allocating its own console window, which lost all of the advantages. It's not to say that this can't be done, just that noone who had the interest and ability to do this had made the effort, because it was low-priority for the contributors at the time. With more contributors now, perhaps this will get fixed. | |
BrianH: 26-Dec-2012 | Also, is it possible to just compile it that way in the first place? And is it possible for such an app to bring up a GUI, say so that it can run console scripts and GUI scripts? | |
Andreas: 26-Dec-2012 | Such an app can bring up a GUI, yes. However, it will always pop up a console window (which can be closed immediately, but this will result in the "console flashing" effect some dislike). | |
Andreas: 26-Dec-2012 | Yes, we should built it that way in the first place. We only recently added building in GUI mode, to avoid a crash with console mode binaries when launched from shells other than cmd.exe. (Another bug that needs fixing). | |
Andreas: 26-Dec-2012 | But note that most (all?) official RT R3 alpha builds have been GUI mode binaries. | |
Kaj: 26-Dec-2012 | Brian, I build the Red examples in both modes, so you can try out the effect if you want. MSDOS/console programs can open a window, but Windows/GUI apps don't seem to be capable of using stdout, at least not to a console they're started from | |
Henrik: 12-Jan-2013 | Is this the best way to perform this check in http://www.rebol.com/r3/demo.r: errout case [ not value? 'size-text ["This R3 release does not provide a graphics system."] ; this one load-gui <> 0.2.1 ["Wrong GUI version for this test script."] true [none] ] | |
Pekr: 13-Jan-2013 | ah, those services. I wrote some doc about what do I don't like about them (naming conventions, other design issues (from my pov)), and Carl told me, that he is going to completly overhaul them once GUI is finished. That never happened though .... | |
Endo: 14-Jan-2013 | I didn't use R/S except for testing/playing but I like to see it working. But I think we have other priorities like GUI, Android etc., R3 itself.. | |
GrahamC: 24-Jan-2013 | Has anyone had any contact with Steven Solie about the Amiga R3 build? I see from his site http://solie.ca/that in 2010/11/23 he had R3-GUI up and running. | |
BrianH: 28-Feb-2013 | It's actually pretty easy to see how they managed it. It was: - A multi-language IDE (not a programming language, people already get those for free) - With a GUI with an emphasis on modern graphic design (pretty!) - With a fancy demo (more pretty!) - With an initial focus on programming languages and development platforms that are already popular (built-in customer base) Powerful IDEs are some of the only development tools that people are still willing to pay money for (i.e. Visual Studio). Most people can't choose what language they write in, but they more often can choose their IDE. And for crappy-but-IDE-friendly languages, an IDE can make all the difference in your productivity. They're not as helpful for really powerful extensible languages like Rebol or Perl, unless the language is so bad that just about anything would help (Perl). Plus, since an IDE is an end-user app you can afford to GPL it, since the only stuff built on it are add-ons - that doesn't work for programming languages unless they have a clear distinction between user code and built-in code that is distinct enough to not violate the GPL distinctions, because most of the competition is permissive - and without the GPL restrictions there is nothing to sell, so there is no business model to get a return on investment. It's nice to point to other open source projects and say "See! We could have done that!" but unless those are comparable projects their success isn't comparable either. | |
BrianH: 28-Feb-2013 | OK, so it's a single-language IDE aimed primarily at the education market, still with a nice-looking GUI if not as modern, with an appeal based on Apple-fan nostalgia for HyperCard. That's a tougher sell, but since it's education market you can get away with GPL/commercial, and since it's Apple-nostalgia you can raise that much money from merely thousands of investors instead of the millions that you'd need if you were going for a less-well-off target market. Makes sense, but it's still nice to see. | |
BrianH: 7-Mar-2013 | And a better console, built on R3-GUI. And better text-mode console support for systems where you can't use a GUI. | |
Pekr: 7-Mar-2013 | BrianH: well, I was long time a proponent of R3. What attracted me most were devices, even more modularity, etc. But - let's not be deluded. If you are careful enough, you could see, that ppl mention some things here or in regards to Red, eg. asking - is View going to be available? Let's not ingore, that many ppl started to use REBOL, because it was kind of complete package - console, call, dbases, networking, gui ... | |
BrianH: 7-Mar-2013 | Still, all of that can be added on or retrofitted, that's the whole point of being modular. Having them implemented and available before 3.0 would be a good idea for marketing reasons (don't knock those, they're important), but not having them done before 3.0 won't break user code the way not doing core semantic changes before 3.0 would. People will be working on these before 3.0 comes out because they need them, and the ones that we as a community consider to be the most important to include in 3.0 will likely be worked on the most. But the great part about that stuff is that it doesn't have to be developed as part of R3 itself, just like the GUI is being developed separately. | |
Robert: 8-Apr-2013 | The generic problem to solve is this: You somehow have to specify what should happen for different actions. Let's start with the "somehow have to specify what should happen". For this you have some options: 1. Write the application logic code in the GUI spec block. For sort stuff OK, for long not. 2. Just call a function from the GUI spec block and write the rest somewhere elese. That's IMO the best way. I used FSM and just send "application logic events". The next part is the "for different actions". Same here: 1. Name them explicitly on-* and specify the code with one of the options above.BTW: IIRC R3-GUI has click and right-click blocks for convinience. 2. Define an implicit mappging from block order to event type. 1st block = click, 2nd = right click, 3rd = double left, 4th double right, etc. IMO that's not a good style. Overall what I never liked about VID was that is was not explicit enough. For big projects that's a must. For small you might skip this but if those projects get bigger, you are hit again. | |
NickA: 8-Apr-2013 | We can always build a "shortcut" dialect like VID on top of R3-GUI, for common simple patterns, once R3-GUI is complete. | |
Pekr: 9-Apr-2013 | The problem is, that while the R3-GUI is now more flexible by removing reactors, it is also more difficult to understand. I remember trying to understand the 'on-action issue in the past, now I briefly re-read the doc, and I still can't understand the design. I need following things to be cleared up for me, so that I can both use it, and possibly explain it to others: 1) If you look into Actors docs - http://development.saphirion.com/rebol/r3gui/actors/index.shtml# , there is no mention of 'on-action actors. There are many actors listed, but not the 'on action one 2) The 'on-action actor is mentioned in the attached doc at the same URL, describing, why reactors were removed. So here is the definition of 'on-action: a) "The ON-ACTION actor is useful if the style needs to call some default action from multiple places (actors) in the style definition." - understand the purpose, but why and when I would like to do such thing? Any example easy to understand? Just one sentence maybe? b) "For example, the BUTTON style needs to call the default style action from the ON-KEY actor and also from the ON-CLICK actor, so it is better to call the ON-ACTION actor from the both code points to avoid the necessity to override multiple style actors." - looking at button or even clicker style definition, I can see no such stuff, as 'on-key or 'on-click calling anything named 'on-action. That is the part that is most confusing for me, and which did not help to understand the 'on-action a little bit. Are we talking about the 'do-face here? There is also a question, if better name could be found for 'on-action. Unless I can fully understand, what happens here, difficult to suggest. Now to make it clear - I am not judging architecture, just trying to get my head around the docs and button/style examples. And being average reboller - if I have difficulcy to understand it, the chances are, there is more ppl, which will strugle in that area? | |
Pekr: 9-Apr-2013 | I think ppl in kind of an wait mode. Some interested in Android in general, some interested in Red progress, som interested in Ren, most of us busy other way. Max in fact is doing a good job - he tries to use the system in a practical way. My questions are just theoretical, just by reading docs and looking into the code. I know I will be back to GUI at some point, just dunno when ... | |
Pekr: 9-Apr-2013 | About excuses - there are imo no excuses. As I said - we are just few, and ppl are busy with other things too. As for those really needing GUI right now (it's not me for e.g.), I think, that some ppl prefer what they know R2 VID, RebGUI, just because of typical entry barrier. There is nothing wrong with R3-GUI imo, and from what I studied in the past, it is much better system than R2. Sometimes, it is difficult to find out real reasons, why ppl react this way, or that way, I just dunno ... | |
Pekr: 9-Apr-2013 | I think that there is no way to take it as offense. Noone said a bad word against R3-GUI today imo ... | |
MaxV: 9-Apr-2013 | To all people who want to dare in Documentation R3 GUI labirinth , you may use http://rebol.informe.com/wiki/view/Main_Pageto help community. | |
Group: !R3 Building and Porting ... [web-public] | ||
NickA: 18-Dec-2012 | Android and iOS. How much of a bounty do I need to offer for R3 with GUI on Android? | |
Oldes: 19-Dec-2012 | Btw.. with High Resolution Displays coming these days, the HW powered GUI is a must. The CPU rendering will be just for making high quality assets for GPU. http://www.tomshardware.com/news/Intel-Higher-Resolution-Displays-Coming,15329.html | |
Bo: 21-Dec-2012 | Actually, Oldes, that's a great idea! R3's new GUI could be built to utilize OpenGL by default. That way, the GPU would handle all the graphics calls, and R3 would have 3D capabilities built-in as a bonus! This would probably even make porting to Android and other platforms a lot easier. In fact, doesn't IOS (iPhone) use OpenGL? | |
Oldes: 21-Dec-2012 | It is. OpenGL ES2.0. As well as Android. Actually I don't think there is a chance to do GUI on these platforms without OpenGL. | |
Cyphre: 21-Dec-2012 | Bo, I think if we don't make drastic changes to the GOB mechanism we should be safe when building anything on top of the GOB datatype. The gob! is in fact abstraction layer between the "VIew engine" and any "GUI framework" written in REBOL. So as take this example: We have now R3GUI framework which runs quite well on the current View engine (although this engine was build in 2 weeks during the very early R3 alpha work so it's kind of Q&D prototype ;)) (BTW should I mention the R3GUI is much better than R2 VID?) Anyway, the R3GUI works on current View engine. When I tried to change the engine so it uses OpenGL accelerated AGG the R3GUI still worked without any problem (except visual bugs caused by incomplete OpenGL code implementation of the new prototype). SO from that example you can see the "View engine" and "GUI framework" are two independent things and can be developed or even exchanged separately. | |
Cyphre: 21-Dec-2012 | From the "design architecture" POV we should focus on stabilizing the GOB abstraction mechanism and DRAW/TEXT/EFFECT dialects syntaxes. If these layers are fine-tuned you have great base that allows us make experiments at the low-level graphics and also as well at the high-level GUI abstraction layer. | |
Cyphre: 21-Dec-2012 | So to sum up my thoughts: -anyone can even now start working on it's own great GUI dialect for R3, or contribute and enhance to already existing R3GUI (latest version will be published soon) -anyone can create own great low-level graphic engine for XY platform or just one native binding for specific os -work of these people won't be useless if they stuck to the current gob! datatype Ofcourse we can do slight changes to the gob!s or draw dialect as well but these should be always easy to incorporate in already existing code that relies on them | |
Robert: 22-Dec-2012 | The R3 I mentioned is R3-View. I'm going to publish it with the latest R3-GUI. Announcement will follow. | |
Group: Community ... discussion about Rebol/Rebol-related communities [web-public] | ||
AdrianS: 31-Dec-2012 | This is a periodic posting of community links along with activity levels for discussion dedicated to Rebol and Rebol-like languages. The intent is to bring a dispersed community together by providing the current list of places where the community gathers along with reasonably accurate activity indicators for each place. This list will be posted in each location weekly or bi-weekly so that anyone dropping by will not have to look far in order to learn where else things are happening. Currently the activity stats are gathered manually and postings are also not automated. This will hopefully change as the requisite scripts to scrape and post automatically are developed. This updated list will eventually be available at http://rebol.comas the site is cleaned up post Rebol open sourcing. # Chats ## R3 Chat This is the primary forum for Rebol 3.0. It runs from any Rebol console in a text mode, but a GUI version is planned. - Run R3, type chat and follow the instructions (all platforms.) - Type "help" for more information or visit R3 DevBase Chat Forum (http://www.rebol.com/r3/devbase/index.html). - To view public messages from any web browser go to RebDev mobile/phone interface (http://www.rebol.net/cgi-bin/rebdev-web.r). - Problems? Please contact Rebol Technologies at (http://www.rebol.com/cgi-bin/feedback/post2.r). Activity: 4 messages this month ## Rebol chat on Stack Overflow (http://chat.stackoverflow.com/rooms/291/rebol) - Note that you will need a reputation of 20 in order to be able to post in the chat. - You can gain this minimal reputation (essentially a spam filter) by participating in the Stack Overflow group of sites. Activity: 380 messages this week ## AltME Worlds A private instant messaging system where rebolers hang out 24/7. The current world dedicated to Rebol and Rebol-like language discussion is called REBOL4 - Get client at http://www.altme.com/download.html - connect to the 'rebol-gate' world with user/pass, guest/guest - request account on REBOL4 world in the REBOL4 request group Web archives of public groups, first to last in the most active world, REBOL4, as well as the dormant world, REBOL3: REBOL4 (http://www.rebol.org/aga-groups-index.r?world=r4wp) Activity: 286 posts last 6 days REBOL3 (http://www.rebol.org/aga-groups-index.r?world=r3wp) # Forums ## Rebol Facebook group (http://www.facebook.com/groups/rebol) A new special interest group for Facebook users. Activity: 26 messages this month ## Rebol Google+ community (https://plus.google.com/communities/100845931109002755204) Activity: 4 messages this month ## Rebol Google Group (https://groups.google.com/forum/?fromgroups#!forum/rebol) Activity: 43 messages this month ## Synapse EHR Rebol Forum (http://synapse-ehr.com/community/forums/rebol.5) A web-based forum for R2 and R3, provided by Synapse EHR Activity: 13 messages this month ## RebelBB France (http://www.digicamsoft.com/cgi-bin/rebelBB.cgi) A simple forum, written in Rebol, for French speakers. Activity: 140 messages this month ## Nick's Rebol Forum (http://rebolforum.com/index.cgi) A micro-forum (just a few lines of Rebol) hosted by Nick Antonaccio. (Note: the captcha question is first.) Activity: 79 messages this month # Q&A (Question & Answer) ## Stack Overflow questions on Rebol http://stackoverflow.com/questions/tagged/rebol Activity: 219 questions tagged http://stackoverflow.com/questions/tagged/rebol3 Activity: 2 questions tagged | |
GrahamC: 30-May-2013 | You can use GUI tools ... such as Git GUI | |
Maarten: 31-May-2013 | I'm just wondering (really, just that): is dev capacity (i.e. Cyphre GUI. other's on OSX, 64 bit) the limiting factor to accelerate in the short term? Or money? | |
Maarten: 31-May-2013 | I would want R3 on Android with GUI, GPS, Camera support. And R3 64 bit Linux server side ("Core"). |
101 / 2867 | 1 | [2] | 3 | 4 | 5 | ... | 25 | 26 | 27 | 28 | 29 |