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: 2301 end: 2400]
world-name: r3wp
Group: !REBOL3 Extensions ... REBOL 3 Extensions discussions [web-public] | ||
Pekr: 26-Aug-2009 | What I would like to look into is the possibility of speed-up of GUI refresh. Not 3D based GUI, just a refresh/rendering/blitting - whatever is possible. Cyphre told me, he has general DLL, which allows to accelerate even R2 faces ... | |
Maxim: 26-Aug-2009 | but my OpenGL extension is not to replace view. Its for gaming, and a totally new GUI experience... | |
Geomol: 26-Aug-2009 | I've got impression, that OGL is slowly dying, and feature lacking, in comparison to DirectX? I don't see that. All *NIXs use OpenGL. OS X GUI is based on OpenGL. Playstation 3 use OpenGL (PS1 and PS2 used a proprietary Sony API). From http://www.opengl.org/ The Khronos(TM) Group, today announced OpenGL(R) 3.2, the third major update in twelve months to the most widely adopted 2D and 3D graphics API (application programming interface) for personal computers and workstations. It seems, OpenGL is growing. | |
Maxim: 26-Aug-2009 | in any case, when you build a GUI with OGL, you build in such a way that everything scales, cause its sooo easy to do... its in fact free... like AGG. so the fact that a GUI isn't exactly pixel perfect is secondary... since often you don't even have the same fonts on various OSes ;-) | |
Oldes: 26-Aug-2009 | I prefere GUI to be pixel perfect. | |
Maxim: 17-Sep-2009 | callbacks are also required for any serious windows api programming, so many systems use them. timers, gui, disk, low-level gfx. | |
Maxim: 18-Sep-2009 | yep, programmatically binding the engine is what I plan to do... especially since it will allows us to rebuild the binding at any moment just by flicking a switch and update it without any user-intervention. so far, my options are: -a direct wrapper generator coded in REBOL using C++ sources, with an advanced C++ declaration to R3 Extension converter, -I try out SWIG build an R3 extension output module for it, -I use another language binding as the one to base mine with, and make a specific tool to convert it to an R3 extension. -do a manual (and painfull) convertion, using a few generic scene interaction commands. One thing I'd like, is to add some way for the OGRE extension to be able to call REBOL code directly via callbacks, using their Extensive hooks throughout the api. Although this will be slower than if the callbacks where in C, obviously, some parts of REBOL are swift enough (like series management) that they just might make the cut for REAL time rendering hooks. Well implemented, they would be fast enough for common GUI interaction events for sure. | |
Maxim: 18-Sep-2009 | GLASS is a general purpose GUI using advanced dataflow programming at its core. I've got some prototypes of various pieces of GLASS using R2 and AGG which work really well, but I've been waiting to be able to do HW gfx before Investing time on the real GLASS, which integrates the prototypes and new stuff too. | |
Robert: 29-Nov-2009 | That's bad because it's IMO an enabler and promoter for R3. As long as the GUI is missing, at least R3 can be used on the server with extensions. | |
Pekr: 31-Jan-2010 | Robert - R3 Chat is official SVN for R3 and soon even for R2. I would learn to use the Chat. Hopefully once R3 Veiw is available, GUI client will emerge .. | |
Maxim: 17-Jun-2010 | a little question... how will the gui be able to call rebol functions? | |
AdrianS: 12-Jul-2010 | there's a GUI front end for cmake too, though I guess one could be made for REBOL just as easily - this lets you resolve env var issues and other things | |
Carl: 16-Jul-2010 | Well... I find that most coders don't pay close attention to their garbage side effects, but in a GUI sysetm, it's wise to do so. | |
Maxim: 16-Jul-2010 | liquid uses state to control processing. each node is like a mini kernel only aware of itself. by linking stuff together and with messaging, all the nodes cooperate. right now, liquid is able to completely control a complete GUI forking of only the refresh of data which actually changes. but i cannot implement some liquid's low-level code within extensions because they can't look up the nodes. | |
Maxim: 16-Jul-2010 | there's REBOL3 GUI | |
Graham: 20-Jul-2010 | If I bring up a GUI in Qt or something .. I'll need a way to call rebol from the GUI as otherwise I have no way of communicating except on exiting the GUi | |
Maxim: 21-Jul-2010 | using OS threads is the only way we can use multiple hardware threads in the same application. otherwise, they will be completely different processes, and that makes a BIG difference in memory consumption, especially on GUI Oses which open up a lot of libs on startup. | |
Pavel: 31-Jul-2010 | Pekr I think in port event model the only what is neccessary is open events to OS events (what possibly is already done, but we don't know how to use it), not only GUI events. Than you can use local pipes (managed by OS including event signalling). Question is if multi machines IPC would go this way. Anyway all this is solved in QNX (signalling abstraction local/external). Question if they use sockets for this. | |
Group: !REBOL3 GUI ... [web-public] | ||
GrahamC: 17-Nov-2010 | you're loading the wrong gui | |
GrahamC: 17-Nov-2010 | load-gui references Carl's old GUI but you need to manually load Henrik's Gui | |
jocko: 17-Nov-2010 | Is it the r3-gui file ? Then the gui doc page should be corrected accordingly ... | |
Henrik: 17-Nov-2010 | Now provides a visible frame for keyboard navigation: http://94.145.78.91/files/r3/gui/248.png | |
Claude: 18-Nov-2010 | henrik, could you tell me if your r3-gui.r3 will works on linux ? | |
Claude: 18-Nov-2010 | do you think carl will choose your gui for R3 standart ? | |
Henrik: 18-Nov-2010 | that's not certain yet as he has not made any evaluation yet, but it will be a publicly distributed GUI, so you can at least get to use it. | |
Henrik: 18-Nov-2010 | http://94.145.78.91/files/r3/gui/style-browser.r3 I think that works. | |
ssolie: 18-Nov-2010 | Henrik: I have buttons working on the Amiga now using your r3-gui.r3 script. I'll blog about it soon-ish. | |
Pekr: 18-Nov-2010 | Guys - what is the reason of kind of slow R3 GUI progress? At least from external observer point of view? That is not complaint nor is it any kind of attack. It is just that I thought that you need R3 GUI for a commercial project? And from external pov we could see: - new resizing system - some new higher-level systems (validation, tabbing/focusing) - some news about low level tweaks - Cyphre posting REP about new possible rich-text system - some endless work on styles However - from external point of view, and unless it all plugs together, Carl's original VID felt more concrete, more complete. Is there any estimate when stuff will plug together to form usable system? Simply put - maybe if system would be docced, ppl could start working on additional styles? Or is it still too early, and non-yet-finished subystems could break any such code? | |
Pekr: 18-Nov-2010 | My whole point was, that Carl took some rewrite route back then, and in 2-3 months timeframe produced kind of basic, but working GUI, which could be demoed by 'demo function of R3, while with R3 GUI, we are not there yet. I don't need to be pointed out to such facts, that 2 years old GUI apparently does not work with latest R3 builds :-) Also - "you can wait ... or be active on your own ..." is not an argument for me. Noone apart from maybe 1-2 guys here want to work on yet-another GUI project. The whole thing is about me (and maybe others) not seeing a "big picture" - things plugging-in together into useable form timeframe. I know that giving any terms is very tricky, but my point was not to get exact nor even estimated date - just some rough ideas about what's still left to be done .... | |
Henrik: 18-Nov-2010 | What's left (not necessarily in order): - test framework for GUI - dialogs - form validation, which meshes with dialogs - help system, which meshes with form validation - database record management, which meshes with form validation - actor documentation parsing - better View function that supports initial states for forms and dialogs - some issues with resizing - work on text editor core - general style work - skin comes last Of course over time we get new ideas or stumble into design issues that need to be solved, before we can move on. That's necessary to make sure that some future feature is going to be simple to do. All this is of course separate from hostkit, font rendering, and DRAW enhancements. | |
Henrik: 18-Nov-2010 | Anyway: Just start using the GUI now. The style browser is built, I have a build system test GUI also and both work fine, so what we need is input on things that are silly or missing in the GUI now. | |
Ladislav: 19-Nov-2010 | Pekr, what is the reason you don't help either by: * wring tests for Parse * writing test for Mold * writing tests for CureCode tickets that don't have tests in the core-tests suite yet * writing some GUI styles * responding to user polls, letting us know what your preferences are * reading the documentation and/or new proposals pointing out at the problems you are having with them * doing other useful work to help R3? That is not complaint nor is it any kind of attack. It is just that I thought you needed R3? And, from my point of view there is no obstacle you could not do any of the above? However, you have still a lot of stuff you can pick and help to make R3 better. Do you still not feel like wanting to do something? Simply put, there is enough oportunities for you to pick from, and the quantity is getting bigger over time. Or, is it still too early, and any effort from you can be expected only when none will be needed? | |
Henrik: 19-Nov-2010 | I would probably agree, if I didn't have other experience with the VID Extension Kit. The trick is to make the focusing mechanism flexible enough to handle all situations. We are not building a GUI that handles specialized situations. We are building a GUI for large business applications with dozens of windows, hundreds of widgets and tons of forms. We absolutely do not want to have something like focusing being a special case per style as other than a special option. | |
Oldes: 19-Nov-2010 | I'm far from the GUI project, but I guess that the best would be centralized default focusing with possible per style extensions (using style's own focusing if required). Style should provide some required info of course. | |
Oldes: 19-Nov-2010 | My opinion above is for special focusing-- like using tab to cycle thru gui items (like buttons). | |
ssolie: 19-Nov-2010 | Are there any GUI tests available that will demonstrate all the various GUI features available in R3? I'd like to know how complete my GUI port is for Amiga so I was hoping there was some benchmark to work towards. I imagine all the platforms will need such a test in the future to guarantee a certain level of basic functionality across all platforms. | |
Rebolek: 19-Nov-2010 | There's style browser that's for testing styles, but you probably wait when Henrik builds new version of r3 gui. | |
Henrik: 19-Nov-2010 | http://94.145.78.91/files/r3/gui/style-browser.r3 http://94.145.78.91/files/r3/gui/r3-gui.r3 Both style browser and GUI updated. | |
ssolie: 20-Nov-2010 | Just tried to run the style-browser.r3 on Amiga and hit the following problem >> do %r3-gui.r3 Script: "Untitled" Version: none Date: none >> do %style-browser.r3 Script: "R3 GUI Style Browser" Version: $Id: style-browser.r3 1179 2010-11-19 18:11:46Z Rebolek $ Date: none ** Script error: cannot MAKE/TO image! from: make gob! [offset: 0x0 size: 400x300 alpha: 0 draw: [clip 0x0 400x300 anti-alias false pen false fill-pen 192.192.192 box 1x1 399x299 0 fill-pen false pen 64.64.64 line-cap square line-width 1.0 variable line [0x0.5 399x0.5] line-cap square line-width 1.0 variable line [0.5x0 0.5x299] line-cap square line-width 1.0 variable line [0x299.5 399x299.5] line-cap square line-width 1.0 variable line [399.5x0 399.5x299] clip 6x6 394x294 translate 6x6 line-width 1.0 variable pen 255.255.255 fill-pen false anti-alias true clip 0x0 0x0 pen false line-width 0.0 variable grad-pen linear normal 1x1 0x2... Any ideas? | |
Pekr: 21-Nov-2010 | to the focus discussion. I don't know why, but I agree with Rebolek this time :-) I know that I am fan of concepts, and subsystems. IIRC VID2 used something like abstracted feel storage. Maybe it was initially a good idea, but how often were 'feel objects actually reused? This was imo an example of a concept, which did not live to its expectations. I know that R3 GUI is abstracted in better way. But I also feel, that we more clearly kind of encapsulated styles - they have all those on-* actors, which let the style to react to various events in its own way. So - stating above - are we really sure that: 1) having abstracted all-styles-related visual representation of focusing brings us an advantage? One advantage might be, that if it is not central, lazy style coder might not implement visual focus representation, and then half of styles might miss it, or we might face some weird situations, when the style author implements the visual focus representation a different visual way. 2) are we sure that one central system will work for e.g. for some complex styles, where some special tricks might be needed to display focus visual representation correctly? | |
Henrik: 21-Nov-2010 | Whenever you are creating a concept in a GUI, such as keyboard navigation and focusing, you immediately want to centralize it with the option of per-style overrides. This is the illusion of control in that you want to meddle, when in fact, you are moving toward a lack of control a lack of unification and opening up all sorts of opportunities for bugs. It is *much harder* to develop large applications, when concepts are not centralized, in the same way if you don't have a single mechanism for help bubbles, for determining which button is default, have a single, unified resizing system (hello, RebGUI), have a standard method for exiting windows, have a standard method for creating and displaying any number of dialogs (hello, VID), have a standard method for validating forms, have a standard method for reading and writing face properties (hello again, RebGUI). With all these things properly in place, GUI development is reduced from weeks to hours. Of course the other method of thinking may prevail, if you have never coded a large GUI before, and therefore don't consider the testing process, which can take *weeks* and *costs money*, because you have to test every single implementation (N number of implementations) of the concept that would otherwise be done in a central system (1 implementation). It's really the testing that constantly is underestimated. One can only determine that something cannot be centralized if it will create too much code, compared to a per-style solution, but it will in general always cause the GUI developer to create functioning and *bug free* layouts with much less work. In that same thinking, R2 View centralizes the generation of a face image gradient, background, text display and edge appearance. It's not flexible, but it makes it darned simple to skin and generally does not have bugs. And you FEEL object question: Yes, they are reused a lot, otherwise VID would probably be 100 kb bigger. | |
Pekr: 21-Nov-2010 | what about new gui not working with A107? Is there A110 exe somewhere? I was able to get it built using Carl's git, but I somehow can't sync it now .... | |
Henrik: 21-Nov-2010 | A110: http://94.145.78.91/files/r3/gui/r3.exe http://94.145.78.91/files/r3/gui/r3lib.dll | |
Pekr: 21-Nov-2010 | a small glitch with style browser - I do mouse over of preview tab, it crashes. In console I do unview none, but consecutive start of style browser fails. Ditto when I try to re-do r3-gui.r3 | |
Pekr: 21-Nov-2010 | Also - I noticed that with field button, arrow down-up moves to the first/last position - it does not work like this in Windows. What it does (in opposition to current R3 GUI) is it hilights the whole text ... | |
Kai: 21-Nov-2010 | Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui: | |
Kai: 21-Nov-2010 | Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui: | |
Kai: 21-Nov-2010 | Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui: | |
Kai: 21-Nov-2010 | Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui: | |
Kai: 21-Nov-2010 | Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui: | |
Kai: 21-Nov-2010 | Hmm - just downloaded 2.100.110.3.1 and get this upon load-gui: | |
Kai: 21-Nov-2010 | GUI version 0.2.1 snip ...size-text has no value ... snip | |
Andreas: 21-Nov-2010 | load-gui references Carl's old GUI but you need to manually load Henrik's Gui | |
Andreas: 21-Nov-2010 | download http://94.145.78.91/files/r3/gui/r3-gui.r3 do %r3-gui.r3 | |
Kai: 22-Nov-2010 | >> do %/c/r3/gui/r3-gui.r3 Script: "Untitled" Version: none Date: none ** access error: cannot open: shape reason: "module not found" | |
Andreas: 22-Nov-2010 | You'll need a "/View" build of A110, such as: http://94.145.78.91/files/r3/gui/r3.exe http://94.145.78.91/files/r3/gui/r3lib.dll | |
Henrik: 23-Nov-2010 | ssolie, since it tests styles, the app should be complete, but may occasionally encounter styles that are unfinished. the program should be used, every time r3-gui.r3 is updated. | |
Kaj: 23-Nov-2010 | Isn't R3 GUI in CureCode? | |
Henrik: 23-Nov-2010 | I think it would be too noisy to have curecode bugs for the GUI just yet, but that's up to Carl or Rebolek. | |
Oldes: 23-Nov-2010 | But then the GUI project could be on GIThub as well. | |
Henrik: 26-Nov-2010 | http://94.145.78.91/files/r3/gui/panels.zip All panel tests. | |
Henrik: 26-Nov-2010 | http://94.145.78.91/files/r3/gui/r3-gui.r3 PANEL and GROUP no longer exist. You need to use HPANEL/VPANEL or HGROUP/VGROUP. | |
Henrik: 26-Nov-2010 | http://94.145.78.91/files/r3/gui/style-browser.r3 Style browser is updated as well to reflect this change. | |
Henrik: 29-Nov-2010 | But even under Windows, the different GUI systems may not behave identically. I would try things in Control panel and other Windows standard dialogs. | |
GiuseppeC: 2-Dec-2010 | We have a big project that needs Android TabletPC and Phones to run on. How difficult would it be to have a an R3 GUI for these touch based devices ? | |
BrianH: 2-Dec-2010 | But to break it down, assuming you want R3-only apps, we would need - A native C compiler for the platform - A rewritten host for the Android application model to support native-only GUI apps (are those possible?) - An AGG port to the hardware/os - Some tweaks to the event model to support touch and multi-touch - Some tweaks to the R3 GUI that deal with the new form factor - A new set of styles that are designed for touch | |
BrianH: 2-Dec-2010 | Of course that would depend on what native plugins are allowed to do on Android. I haven't even heard of a fully native GUI app for Android (they might exist but I haven't heard of it), only CLI apps. | |
BrianH: 2-Dec-2010 | They do have a free GUI. It's just that it's written in Java. | |
BrianH: 2-Dec-2010 | Order entry apps seem like the kind of thing that the existing Android GUI would be able to do easily. | |
BrianH: 2-Dec-2010 | The R3 GUI will eventually need multitouch support and support for modern touch-screen devices (meaning: not treating touch like a mouse). That support would be portable to a variety of devices, some of which would be running OSes that the R3 GUI already runs on. | |
BrianH: 2-Dec-2010 | Kaj, if you have any links to fully native GUI applications for Android that don't use any Java or Dalvik at all, please post them. I have been looking for any indications that such things are possible, and haven't found any yet. The SDL seems to be linked as an NDK library, not as something used to make native apps. All of the native apps I've seen are command-line only and not runnable from an icon in the applications list. I'll keep looking. | |
BrianH: 2-Dec-2010 | It looks like you might be able to use a combination of the standard NDK and a third-party cross-compiler to make fully native GUI apps. You would get the libraries from the NDK, including SGL (that's Skia Graphics Library, not SDL, it owns the framebuffer). I haven't seen anyone try to do this yet but since it may be possible then it might have been done already by someone. | |
Sunanda: 8-Dec-2010 | Am I missing something really basic......Here's my first attempt in many months to play with the R3 GUI. New console session, R3-a110.exe: >> load-gui Fetching GUI... GUI Version: 0.2.1 (Developer test GUI theme) ** 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 | |
BrianH: 8-Dec-2010 | You need to get a GUI build and download Henrik's compiled R3 GUI code. Look above here for the links. | |
Rebolek: 8-Dec-2010 | Please, don't expect LOAD-GUI to work. It loads old Car's GUI that's not compatible with A110 anymore. | |
BrianH: 8-Dec-2010 | http://94.145.78.91/files/r3/gui/r3.exe http://94.145.78.91/files/r3/gui/r3lib.dll http://94.145.78.91/files/r3/gui/r3-gui.r3 | |
Sunanda: 8-Dec-2010 | Thanks.....I was trying to follow the step-by-step example: http://www.rebol.com/r3/docs/gui/guide.html#section-3 | |
BrianH: 8-Dec-2010 | The recent R3 builds have focused on core changes. The GUI has been developed separately. | |
Henrik: 8-Dec-2010 | http://94.145.78.91/files/r3/gui/style-browser.r3 is perhaps useful too. | |
Andreas: 8-Dec-2010 | We should probably just get rid of LOAD-GUI, for the time being. | |
Andreas: 8-Dec-2010 | Or adapt it to load r3-gui snapshots from somewhere instead. | |
Oldes: 8-Dec-2010 | The load-gui issue is there too often.. we should remove/replace it ASAP | |
GrahamC: 8-Dec-2010 | load-gui: func [ ][ alert "See faq" ] | |
jocko: 9-Dec-2010 | I also see as a priority to fix the status of gui : - declare publicly if r3-gui is the official gui development or not - then fix the load-gui call function - and finally update the gui official documentation page. It should not be too difficult, and, to my opinion, it it really important and urgent, because it prevents to develop experimental visual applications. Could the gui development team meet Carl in order to convince him to take a decision ? | |
GrahamC: 9-Dec-2010 | the GUI team should be in daily contact with Carl via their scrum system | |
Pekr: 9-Dec-2010 | But I am not sure Carl is involved with the GUI team decisions, to go this or that direction. But as Carl has nothing better, I just hope he will integrate. But as we know Carl, he might want to revise the code first. Let's hope one months black-out period is over soon - Carl is not available on any public channel .... | |
Henrik: 9-Dec-2010 | Carl is currently only observing, but I've not seen any comments from him on GUI development. But at this time, the number of RM Asset programs and tools that requires the R3 GUI is growing, so we are not in a position where we can hand things over to Carl and expect him to evaluate, rewrite and finish it. | |
Henrik: 9-Dec-2010 | As for docs, I'm not sure when they will be done as some GUI concepts are not finished, but perhaps after beginning to write the first apps. | |
Pekr: 9-Dec-2010 | And I agree, it is a one way ticket. Carl was way too long away from the GUI topic. RMA surely is going to use its own gui for its own apps. And the official R3 GUI? Who knows, but I bet ppl will prefer RMA's work, than having nothing in the end .... | |
Pekr: 9-Dec-2010 | ... after all - anyone can have suggestions to R3 GUI, so even general R3 community should get what will mot probably fit us all .... | |
DideC: 9-Dec-2010 | load-gui.r must be update to check the Rebol version and print an error if it is not compatible. | |
Oldes: 9-Dec-2010 | what was the last version compatible with load-gui? | |
Group: !REBOL3 Source Control ... How to manage build process [web-public] | ||
Fork: 29-Oct-2010 | One of the things I like about Git, and am quite proud of, is the data structures are simple and you can reimplement it if you wish. It's a well-defined data model. There are Git-related projects like GUI tools, for example, with the Eclipse IDE. http://www.computerworld.com/s/article/print/9126619/Q_A_Linux_founder_Linus_Torvalds_talks_about_open_source_identity | |
GrahamC: 29-Oct-2010 | Henrik, you could start by putting the R3-GUI into Git! | |
Cyphre: 29-Oct-2010 | I don't know why it was so big..I installed it half year ago, maye they fixed that. I guess your link is just some cli version? I want gui version. | |
Oldes: 29-Oct-2010 | No, it has gui as well. | |
Andreas: 29-Oct-2010 | gitk and git-gui, yes. | |
Andreas: 29-Oct-2010 | (And yes, even plain msysgit comes with minimal, optional explorer integration in the form of "launch a git shell here" and "launch git gui here", if I remember correctly.) | |
Carl: 29-Oct-2010 | Quick notes: I downloaded via the Git link that Oldes posted above. It's ~12MB (reasonable.) Installed fine on XP. Yes, this is a shell version, which is fine with me since I like to use scripts anyway for merges, builds, and releases. I have yet to try git with github. It would be great if someone could post the magic command line to checkout the existing repository (anonymous currently), Regarding GUI version: it would not be difficult for someone to wrap a few REBOL calls it to give you a bit more GUI feel. Not perfect of course, but something clickable. | |
Pekr: 30-Oct-2010 | I use GUI though .... |
2301 / 2867 | 1 | 2 | 3 | 4 | 5 | ... | 22 | 23 | [24] | 25 | 26 | 27 | 28 | 29 |