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: 1 end: 100]
world-name: r4wp
Group: #Red ... Red language group [web-public] | ||
GrahamC: 27-Feb-2012 | GUI next? | |
Pekr: 5-Mar-2012 | how big is actually enlightenment (the parts you need to use, to get a GUI and app done using it)? | |
MagnussonC: 11-Apr-2012 | Is there going to be a built in graphic GUI like in Rebol/View or will Red always depend on external graphical libraries for GUI's? | |
TomBon: 11-Apr-2012 | GUI, nice would be a clean cross plattform ANSI C lib, handling the basic window & eventmanagement and providing access via a simplified meta-api (VID-DSL). this way nearly all script languages could use this lib as a native GUI generator. | |
DocKimbel: 6-Jun-2012 | @Graham and others: I should have wrote you earlier about what I am currently doing instead of leaving you with no info, sorry for that, I was very busy these last weeks, with both real life events (good ones ;-)) and a new customer from which I accepted a short-term job to help pay the bills. The contributions I've received so far *are* helpful and I can't thank enough all the people that made donations! But their are not enough to cover all my expenses here, if I could get 3-4 times more from donations, that would be perfect, but as long as the userbase won't be larger I think that it won't be possible. So I've accepted a short contract (til end of june) to build a trading bot generator with a visual editor (GUI in View) that emits MQ4 language source code for feeding the Metatrader4 application. Of course, I'm building it in REBOL (Red not ready yet for that). The plan was to work part-time on it and part-time on Red, but these last two weeks I had to work almost only on that project. I still have a few days of intensive work on it, then I'll switch to part-time. I have quite a lot of code to commit (the Red compiler), but I'll wait to finish first the internal modifications in Red/System (to ease the integration with Red) before publishing it. | |
DocKimbel: 15-Jun-2012 | Hehe :-) For the core language, from user perspective, it will be very similar. For the external libs (GUI mainly), Red will provide different options. For more detail, you can re-read all the slides from the two presentations I've made for Red. | |
Pekr: 24-Jul-2012 | e.g. that native RED GUI would be handy, one day :-) | |
DocKimbel: 24-Jul-2012 | Certainly! But I must admit that I have hesitated in the beginning between HTML5 and VID for the GUI. | |
Janko: 24-Jul-2012 | wow, looks really nice. I was never good with R gui's so I have no idea how you made those custom components | |
Janko: 24-Jul-2012 | I don't know. Please don't be bogged down by things like gui in Red too fast! You first have to make a langauge / a platform that others (we) can use and build upon and add libs when we need them. And for all the love to VID and like, my oppinion is still that usability matters the most and it's hard to beat usability (all the little conventions) with non-native GUI-s. Or big delevoloped libraries that emaulate them well enough (Qt, GTK, ...) | |
Pekr: 25-Jul-2012 | As for Janko's message - I am not suggesting changing priorirites too. GUI can wait imo, we need Red first :-) | |
Kaj: 11-Aug-2012 | In Syllable, I repackage Red and Cheyenne in a package with a Unix-like structure, such as a separate subdirectory for the executable, but it gets cluttered because they find all their other files related to that executable. Actually, that's the way we want it to work for Syllable Desktop GUI applications, but for a console program that needs to be in the system path, you need the Unix structure with separate search paths for separate subdirectories | |
BrianH: 11-Aug-2012 | IN block word is used in the R3 GUI. It does the same context walk that Doc says WITH does, but only to retrieve a word. | |
AdrianS: 24-Aug-2012 | Petr - for a git GUI you might want to try SmartGit - free for non commercial use and, IMO, the best GUI. Also, it's available for all platforms. I use this, tortoise and the command-line, depending on the context | |
MagnussonC: 27-Aug-2012 | Is Rebols GUI code (view etc) going to be usable in Red? Or is it going to something completely different? A while back I think there was talk of an dedicated Red editor (Reditor?). Is this still included in the roadmap? | |
Pekr: 27-Aug-2012 | I think that guys had some kind of GUI in mind, or maybe more specifically - some GUI targets, as e.g. html5, etc., being native on target devices. Myself, I would support and sponsor bit a View plus VID3 transition towards the Red, but not sure if someone would pick up. So - in the end, some "GUI" might appear .... | |
Pekr: 27-Aug-2012 | ... but GUI is not a priority right now I think .... | |
Kaj: 27-Aug-2012 | I'm not sure it's useful to repeat this, because people seem to wipe their memory and start over the discussion, but: - Red's roadmap includes binding to native GUIs. That means there's supposed to appear a binding for every platform Red is ported to. The intent is to try to create one dialect that would be able to drive all these native bindings. This would be a common denominator dialect. - Some of those GUIs are actually cross-platform, such as GTK and Enlightenment. so those can figure as a cross-platform GUI. They could offer more functionality than the common denominator dialect but still be cross-platform. | |
Robert: 27-Aug-2012 | I'm not convinced with the native GUI bindings. A lot of framework have tried it too and it's a lot of work to bridget the gaps. Or if the least common denominator is becoming to small the native look & feel won't help since the app feels crippeled anyway: Why don't they use widget ABC here? | |
Robert: 27-Aug-2012 | Porting / binding R3 GUI to Red shouldn't be hard to do. It's a lot of work but we would get a simple and fast to use GUI. One of the major USPs of Rebol. I don't know any other simple to use interpreter that gives you a GUI out of the box. And, in these app days, it's no longer so critical to support native look & feel in all aspects. | |
Pekr: 27-Aug-2012 | Robert - it is just that talking to Cyphre, he was eventually interested in a "port", which would be more of a new implementation, supporting more advanced stuff in the backend (as switching targets, hw acceleration, etc.), and doing it in his free time the initial guess was 12 months. Such product would be surely cool, but it seems to me, that it could be just the second stage. In first stage, I would prefer having windowing/events plus AGG ported (still fast enough for many things, I don't understand the obsession about the speec, well, apart from devices lacking float support, here, AGG would be really slow). Such step could be done in 2-3 months of work? Then ppl could start port R3 GUI to it .... | |
Kaj: 27-Aug-2012 | That's fine; it would be one of the supported cross-platform GUIs, next to Enlightenment and GTK. Of course, you'll have to make sure you have the rights to use the R3 GUI | |
DocKimbel: 27-Aug-2012 | We don't have to be limited in GUI backend options, as long as we can use the same dialect (or subset of it) to program them. | |
DocKimbel: 27-Aug-2012 | About the native GUI option (using only what the OS provides), I'm pretty confident that the minimum common should be enough to cover most needs for business apps, I will do a prototype for the Red IDE. Having a free drawing x-platform canvas, for games and non-native GUI would also be needed, SDL seems to be the best backend for that AFAIK (that gives us also OpenGL for free). | |
MagnussonC: 27-Aug-2012 | I guess then that some code from R2/R3 applications will be reusable in Red (as Red uses Rebol syntax), but not the GUI code. | |
DocKimbel: 27-Aug-2012 | R2/R3: probable, for the GUI code, it depends how close our VID version will be (R3 VID seems to be a good model that we could push further). | |
DocKimbel: 19-Sep-2012 | The overhead of the current implementation is about 5-6 times the program execution time, so it's very usable. I will publish it today, and I hope someone will pick it up to improve it and add features (like a GUI front-end for the reports, with sortable columns). | |
DocKimbel: 19-Sep-2012 | REBOL code profiler released: https://github.com/dockimbel/Red/blob/v0.3.0/red-system/utils/profiler.r Should work with any REBOL app. Documentation, comments and example included in file header. Hope someone will pick it up and improve it (like adding functions sub-tree stats and a GUI). This is github, so feel free to fork then fix/improve. | |
Pekr: 23-Sep-2012 | As for end user visibility, I can imagine one common place to have it - Menu/About dialog, credits section. But, what about apps without the GUI, right? | |
DocKimbel: 15-Oct-2012 | So, we can now say that Red/System is more advanced than R3, as it can make sophisticated GUI apps on ARM devices. ;-P | |
DocKimbel: 28-Oct-2012 | Yes, MSDOS uses the 'console sub-system, while Windows target uses the 'GUI sub-system. | |
DocKimbel: 28-Oct-2012 | The difference lies in the PE header, the sub-system required to run the app needs to be set to either 'console or 'GUI. | |
DocKimbel: 28-Oct-2012 | But Windows seems to be quite permissive in recent versions, so a GUI app can also be started from DOS console. | |
DocKimbel: 28-Oct-2012 | Yes, it would be cleaner for the day when we will have real GUI apps in Red, in addition to console-only ones. | |
Kaj: 28-Oct-2012 | I suppose GTK and SDL officially need GUI | |
DocKimbel: 28-Oct-2012 | Brian: as I've explained to Kaj earlier, Windows does make a difference between apps built with GUI or built for console- only. If it wasn't the case, we would only have the "Windows" target. | |
Pekr: 1-Nov-2012 | So, what is the strategy? I can see various dirs, one named MSDOS, but can't see Windows? So what are the targets to distinguish, when we build the Windows apps for GUI, or the console? | |
Jerry: 10-Nov-2012 | Doc, I will. The metrics will be numbers of 1. Datatypes 2. Actions 3. Ops 4. Natives 5. Functions 6. Objects 7. Schemes 8. GUI-Components | |
BrianH: 20-Nov-2012 | Kaj, rebcode! isn't really in R2 anymore either. But the mechanism that was used to make rebcode fast in R2 has been implemented in R3, and it used by the R3-GUI dialect. Anyone could implement their own rebcode if they like, even with improvements. That mechanism would be worth supporting in Red. | |
kensingleton: 21-Nov-2012 | No gob! Does this mean no GUI or just gui done in different way? | |
DocKimbel: 21-Nov-2012 | Does this mean no GUI or just gui done in different way? See all the presentation slides for Red, a native GUI system will be provided. Also a web server with a new web framework will be part of Red stack, so modern style web apps will be supported. The GUI will probably be done in different way than R3 underneath, maybe a gob!-like datatype will be a good match, but such implementation detail is not known until implementation starts. Also, it is possible to extract R3 GUI code, wrap it in a shared library and plug it in Red (but I won't be the one doing that and maintaining such wrapper). | |
Pekr: 22-Nov-2012 | In the end I think, that having easy to maintain GUI is not necessarily related to the backend itself, and that keeps me attracted to Red, as I know, that Doc will not tolerate any unnecessary bloated solution :-) | |
DocKimbel: 22-Nov-2012 | Pekr: you have a wrong view on what the Red ecosystem is and will be. It is probably caused by 15 years of limited options from RT and closed-source nature of REBOL products. In Red ecosystem, like in any most other languages ecosystems, you'll be able to choose GUI between different options. Don't give a wrong picture of Red by assuming that you will be limited to only one choice. | |
NickA: 30-Nov-2012 | Doc, what are your current expectations about timing for a Red GUI? Do you want to make it VID-like? (my vote is for yes). GUI was the "hook" for R2, and I think a GUI as simple to use as VID, even if not encompassing as many features, would increase RED's appeal dramatically. | |
DocKimbel: 30-Nov-2012 | VID-like: definitely. Not only because it is a simple and efficient way to build GUI, but also because it nicely shows the power of dialecting, applied rightly, so it "validates" the whole concept behind REBOL and Red. I was planning two approaches: - prototype a VID dialect for cross-platforma native GUI once we have the right interfaces between Red and Red/System. (That part will include also mobile platforms, if possible, else, they will have rely on a mobile-oriented GUI dialect). I will probably start to play with it around Christmas, and try to reach an alpha/beta in Q2 2013. - prototype a VID dialect for HTML frontend, having GUI frameworks as backend targets (Sensha, jqueryUI,...). The hard part here is abstracting the client-side coding, Topaz would be great for that, if Gabriele can find time to continue working on it. Else, I will need to work on my own Red to JS compilateur. It would be also nice to have a wrapper over R3/View or a Red/System port of it, but it would need contributors to take it in charge. There are also more possible GUI options. | |
Pekr: 30-Nov-2012 | The cool stuff to show-off would be - bring your Red on your SD card/USB stick, plug-it-in, go to its dir = show "no-instal" option, show some GUI dialect, press a button, generate android app, and with one command or a dialect, push it to Google play. Then I can send you my friends short/long description, how long it took him to get his app there, downloading and installing all the JAVA crap and all dependencies ... | |
DocKimbel: 30-Nov-2012 | :-) File and network I/O: should be done for Christmas (maybe alpha state for networking). I will provide then HTTP client/server support shortly after. Expect more network protocols to come in Q1/Q2 2013. 2D/sound will be part of the work on GUI, so will happen later in 2013. Mysql support through networking: I will very much like to have that, as Postgresql support too. Expect them before summer 2013 (or maybe before for MySQL, if I need it for a killer Red demo). ;-) | |
Henrik: 30-Nov-2012 | Now after observing development of several GUI systems, there are always some particular things I find wrong with them: They were designed with small details in mind rather than the big picture. This means that when a developer uses a GUI system, he'll find that some things are easy, while others are very hard. For example, none of our GUI systems are particularly designer friendly, meaning that building a skin requires a programmer with artistic skills. There are not many of those around and that's a real problem. Saphirion's R3 GUI was derived from Carl's work in a way, where several parts were rewritten, because they didn't scale enough for real-world GUIs. The rest of the work has been about beefing up the R3 GUI to handle what is needed. Development often seems to go in isolated sections: Building styles, building a layout engine, event handling, skin system, animation or whatever, without a properly coherent view on the whole thing. We talk about how we have a really nice feature, but that feature may not mean much, if it's not functioning in a coherent way with the rest. If I were to restart VID Ext Kit as a new GUI system, I would rewrite it top down: Start with an application with the simplest, purest GUI description and write the GUI system down from there. I would recommend that a GUI system for Red needs to be written like that, starting as early as possible and let it grow downwards instead of upwards with a real application in mind rather than some neat demos. | |
Henrik: 30-Nov-2012 | In short: Write apps and pretend we have a complete, perfect and luxurious GUI system with no work-arounds. Then write that GUI system. | |
AdrianS: 30-Nov-2012 | It would be great if the GUI system used a combination of vector and bitmap rendering for widgets. Vector drawing could be used for initial drawing or when a GUI was re-sized. Thereafter, the widgets could cache their bitmap (if so configured). Maybe I'm stating the obvious and this is already how things are planned to work. | |
DocKimbel: 30-Nov-2012 | Henrik:I agree with your way of thinking, that is the kind of pragmatic approach I take often too when designing any dialects or even APIs. For the Red native GUI system, I will prototype it with the first big Red app I plan to write: the Red IDE. | |
Gregg: 30-Nov-2012 | I agree with Henrik 90%. The hard part is picking the target app and important elements. A game, or modern app with animation elements is a very different target than an "efficiency above all" business app. One of my failed attempts with REBOL was to get Carl, for just this reason, to identify a target audience. It guides your design. In the case of a Red/REBOL GUI, maybe there is no single design or dialect. Making small apps simple is hard to match to the needs of complex apps. If you're writing database/CRUD apps, wouldn't it be great to have a toolset designed just for that? That same toolset won't work well for games though. I think using an IDE as the first target app is a *fantastic* idea. It covers a lot of areas, including the possibility of building on an extensible app framework (something lighter than Eclipse :-), files, documents, workflow, tool integration, customization, and many UI elements. And *we*, developers, are the target audience. | |
Pekr: 30-Nov-2012 | Well, as for me, it is easy as that - f*ck off native controls :-) What does that really mean today? I have really no intention seeing GTK or other crap. Either use your own GUI, or HTML, that's almost the only standard, which will prevail anyway. We should ask ourselves - how relevant is e.g. the Gnome GUI guide? And who cares in the big picture? So - for easy embedded stuff, just give me a small GUI system, for bigger picture, give me a HTML5. I e.g. don't understand, why Kaj tries to port something like Enlightenment. I really miss the big picture. Who and why should ever use it? For personal purposes, or some specific stuff - why not, but that's not imo a strategic direction ... | |
Pekr: 30-Nov-2012 | And I even don't agree with Henrik. I really can't see, how your top-down aproach might work. You need a solig gfx engine (View), general enough, to build up. Carl's GUI was OK. And imo Saphirion did a bad mistake - we heard, for so long time, that the look is the final step. All those years, and the look is really a crap. Much worse, than what Carl brought up, even if I can see many improvements in engine itself. Look sells, take it, or leave it, and then - please don't even try to do your own GUI. No matter how good it is, if it looks like 80'ties Solaris, it will never get accepted ... | |
Pekr: 30-Nov-2012 | I would never want my app to look like GTK, easy as that. Maybe because I have zero intention to do Linux native GUI app. Linux, in a big picture (desktop), is irrelevant. Alway was. Who claims otherwise, lives in separate reality :-) Mobile will prevail classical PC sales very soon (if not already). Own GUI, for small niche, might be good. But - it has to have attractive design. The situation with Saphirion was, that the substantially rewritten Carl's engine. Nice enhancements, resizing and other stuff. But I NEVER understood, why the look was so totally unattractive. You see, Henrik once again claiming the old stuff, which was the basic reason of a failure. Design is a separate animal, which was supposed to come later, which could be done by anyone, which "just" needs material system which never appeared, etc. And result for me (as a sigle person)? Carl's GUI desing attracts me by some 60% more, just because of look. Once again - look sells ... | |
Pekr: 30-Nov-2012 | In fact, what I think is, that Saphirion was really close to the GUI engine, which adressed most of what we wanted to solve by VID2 to VID3 transition. It was just not polished. And because of that, ppl did not find it attractive enough to play with. And that's a real pity. Anyone doing native platform GUI will make me to close that demo at first sight, easy as that. Doc is in kind of difficult situation - as we can see, many former/recent rebollers are still interested in View like engine. The same reason why Doc dismissed LLVM in Carl's blog post, the same reason many will dismiss attempts to link to GTK, Enlightenment, etc - I don't want to use 5+MB crap ... | |
Gregg: 30-Nov-2012 | ...for easy embedded stuff, just give me a small GUI system, for bigger picture, give me a HTML5 So what do you propose for the GUI, that will allow it to look good? i.e., what is your constructive suggestion, rather than criticizing all the wrongs of the past. | |
Gregg: 30-Nov-2012 | My suggestion, then, is to make a list of target OSs, prioritize the value of a GUI on them, and propose the best GUI solution for each. | |
Kaj: 30-Nov-2012 | GTK is the native GUI for Ubuntu. I've told you many times | |
DocKimbel: 30-Nov-2012 | How many of us would ever need to do a real native Linux app? We are talking about a cross-platform GUI framework, that means: write once, run everywhere. Using native widgets from the OS is an option, using custom ones (with non-standard look'n feel like /View) is another option. So, you write a Red GUI app on whatever system you like and your Linux users will be able to run it. | |
Kaj: 30-Nov-2012 | Feel free to write a custom GUI in Red | |
NickA: 30-Nov-2012 | It's hard to imagine that the native UI interface would meet with criticism from any main stream developers - by definition, it's the _native UI. Doing things that way just takes longer to port. I honestly don't care which way it goes, as long as there's a usable GUI system with a _productive syntax_. | |
Gregg: 30-Nov-2012 | That is, if Doc creates your dream GUI system, what is it? | |
NickA: 30-Nov-2012 | I should have asked the GUI question in private ;) | |
DocKimbel: 30-Nov-2012 | My understanding is that most people stick to one desktop OS, they are not switching OSes whole day (that is just a very small minority of computer users). Having close integration with OS can bring many advantages over a custom GUI like hardware acceleration or close integration with OS/desktop services. There are still cases where a custom cross-platform GUI could be good enough, so a View-like engine for Red is welcome. I just think that the default GUI option should be to provide an OS-integrated user experience. | |
Group: Announce ... Announcements only - use Ann-reply to chat [web-public] | ||
Robert: 24-Mar-2012 | Saphirion's Host-kit has been updated: -added PNG encoder -added Core extension module for generic additional commands -reworked compile/build process -fixed security flaw in Encap -fixed bug caused non-functional networking -improved console output handling logic -patched ENCODE to not crash on png -updated LOAD-GUI with currentspahirion link -recompiled r3.exe, r3core.exe, r3encap.exe and r3ogl.exe Update on the web-page will be available on the weekend. | |
MaxV: 28-Nov-2012 | made good progress over the holiday, powered by turkey sandwiches from France. Prep of C source nearly done. See, not just a dump and run. Sure, a few problems came up, but I'm not going to hold up the release for them. You can decide. Grabbed latest git source and built it for this dev box (which did not support 1.8 version as bin.) Once released, I've got a number of notes to write up. Like how to quickly port R3. Takes about 5 mins if you know what you're doing. Got it up on ARM & MIPS Linux. Also, I have some goals in mind. Android and iphone, that kind of thing. Getting graphics and sound back up. GUI and tinyGUI. A micro-R3 for smallish embedded systems. There's a lot you can help with. Delegation, right? | |
Robert: 21-Dec-2012 | Made it to restore the web-project for http://development.saphirion.com That's where we are going to publish our R3 stuff. Still some work to do, but you will find our R3 version there, R3-GUI etc. | |
Robert: 22-Dec-2012 | http://development.saphirion.com I have reworked the whole site. You can download the latest R3 releases with graphics engine for windows for now. Further our latest R3-GUI release is available too. The site contains a bounty shop as well, if you want to support / donate to some of our efforts. All things we will work on are listed. Stay tuned, more to come over the next weeks. | |
Robert: 22-Dec-2012 | Updated our R3 version. Changes: - no longer links libstdc++ dynamically but statically. You get an error that libstdc++-6.dll is missing from your computer. - changed startup procedure to support correct stdio redirection in console mode (used if you start R3 with a command line argument, else GUI mode) | |
Robert: 30-Dec-2012 | Updated: http://development.saphirion.com/downloads/to contain the complete R3-GUI ZIP with additional docs, examples etc. | |
Group: Ann-Reply ... Reply to Announce group [web-public] | ||
GrahamC: 10-Mar-2012 | GUI looks good ... not sure what to do with it though! | |
Cyphre: 15-Mar-2012 | I downloaded fromthis link: http://www.saphirion.com/development/downloads-2/files/heat-map-gui-demo.exe.zip and the models/ contains some test data | |
Kaj: 7-May-2012 | You need to update your repository from your local command line or Git GUI | |
Endo: 8-Nov-2012 | Well, GUI is also important for my work. Is there an encapper for R3 anyway? Or you mean put script & r3.exe in a package and write a batch? | |
Robert: 22-Dec-2012 | where is it? On our R3-GUI doc pages? | |
Maxim: 4-Jan-2013 | Robert, does the android port currently have GUI support? | |
Robert: 5-Jan-2013 | As said, files and GUI will be next. | |
GrahamC: 14-Jan-2013 | Sore the core builds are on rebolsource.net and the gui builds are on development.saphiron .... | |
Pekr: 13-Feb-2013 | why don't we just follow Saphirion guys? They concentrate very fine rebollers, it is just that as a business entity, they implement, what they need most. But - everybody can influence it via donations imo, so I did, sent few dollars to R3 droid port, and R3 GUI on droid. | |
Pekr: 13-Feb-2013 | in fact, it is even worse - GUI is done for quite some time, yet no new styles/skins appear, so nothing to complain here about - anyone of us can contribute. I just somehow don't believe, that yet-another-fork will make situation any better .... | |
Pekr: 13-Feb-2013 | In regards to above remark, I e.g. don't understand e.g. Nick requesting R2 being released, as R3 GUI is superior to R2, we just somehow magically don't start using it, dunno why. | |
james_nak: 28-Feb-2013 | Is it a not a gui-based tool? | |
Pekr: 8-Mar-2013 | Hopefully it would be adaptable to Red later, although Red has a bit different GUI priorities. | |
BrianH: 8-Mar-2013 | Pekr, unless this is a huge rehash that you don't want to repeat, could you let me know which View engine proposal you're talking about? I don't do GUI stuff so it's been a while since I caught up with current events. In the !R3-GUI group if that's appropriate. | |
Group: Rebol School ... REBOL School [web-public] | ||
GrahamC: 10-Mar-2012 | If this is a Gui app, wny can't you just wait ? | |
Marco: 10-Mar-2012 | @grahamC: It is a gui app that sends output to seral port, so I don't want to block user input while waiting the job to be done. | |
GiuseppeC: 9-May-2012 | Next level ! Any suggestion about creating a dynamic built GUI ? I whish to create a GUI from a Block of data, each data is a button and each button has an action attached to it. Could you please point me to some code to analize? Thanks in advance | |
james_nak: 9-May-2012 | Giuseppe, you can experiment by creating your gui code as a block and then "do" it. Then view it. a: [layout [button "hi" [print "hello"]]] b: do a view b | |
GrahamC: 20-May-2012 | odbc drivers for windows can only be used with the rebol/view, the gui build, unless you paid for a rebol/command sdk | |
Pekr: 21-Jun-2012 | Recently I switched to R3, as I don't need the gui, just a script to do some webpage source code post-processing .... | |
Maxim: 4-Jul-2012 | here is a simple way to get the code for a face within the layout function ( I found it the easiest to remember): view layout [ across text "1" my-radio: radio on do [probe my-radio] text "2" radio ] the advantage of this system is that you get the actual face with any facets setup as they really are in your gui. this is often the easiest way to identify just where and how a specific facet affects a face... probe it without your change, and then run it again, with your change... comparing both probes in a diff or merge tool. | |
Group: !Syllable ... Syllable free operating system family [web-public] | ||
Kaj: 25-Jun-2012 | I'm starting to get the GUI build to work, and it takes a few hours here, but Syllable Desktop can't use the second core on this machine, and compiling is roughly half the speed as on Linux, anyway, so that's roughly consistent with your timing | |
Kaj: 27-Jun-2012 | No, we never wanted to depend on Qt. And I have it all built now, but the GUI doesn't work yet | |
Kaj: 27-Jun-2012 | I have all of Enlightenment working except the widget set. I have DirectFB working and am currently building GTK and Qt on top of that. I have all of Qt built but nothing GUI works. I have all of GTK working except GTK itself, so no GUI there, either, but I'm still working on that | |
Pekr: 27-Jun-2012 | I know. But I also expect RED being kind of compatible to RED, syntax wise. And I think Robert would not mind, if someone tried to port R3 GUI to RED. As you can read on various places, ppl still want View, small toolkit, and some are even reluctant to join RED, if the clarification of GUI availability is not made ... | |
Kaj: 27-Jun-2012 | I have already provided a GUI for Red. It's fine if R3/View is rewritten for it, but I'm not going to do it | |
Pekr: 27-Jun-2012 | What's your GUI for RED? GTK? How big is that? No under 1MB exe, no sugar :-) | |
Group: Web ... Anything related to the WWW [web-public] | ||
Gerard: 18-Aug-2012 | Nice, do you use some GUI for the output, kind of VId I suppose ? | |
Kaj: 18-Aug-2012 | REBOL 2 is no use to me because it would never run on Syllable, and REBOL 3 still only has a GUI for Windows and Amiga, so it hasn't been useful for me to make a VID frontend |
1 / 2867 | [1] | 2 | 3 | 4 | 5 | ... | 25 | 26 | 27 | 28 | 29 |