World: r3wp
[!REBOL3]
older newer | first last |
Graham 12-Aug-2010 [4446] | Market leader is RIM, followed by Android and then IOS |
NickA 12-Aug-2010 [4447x2] | I still have that phone, but I just carry a Windows 7 netbook everywhere I go, and a tiny clamshell phone - that setup is much more powerful and practical. |
For my current needs. | |
Graham 12-Aug-2010 [4449] | However, it makes more sense to target the OS most used by developers |
BrianH 12-Aug-2010 [4450] | I know, Nick. I was the one who asked for that build in the first place. Unfortunately, that is why it doesn't support onscreen keyboards well: The original build was for a netbook. |
NickA 12-Aug-2010 [4451] | My biggest hope is still to see more developers attracted to REBOL, and mobile platforms are fresh meat. |
Graham 12-Aug-2010 [4452x2] | I would love to be able to render postscript in a view face/gob |
Give us the power and the developers will flock | |
Pekr 13-Aug-2010 [4454] | Do we have any technical possibility to ever run even on Android? Does it allow native code? How do we link to their API, which is JAVA based? |
Andreas 13-Aug-2010 [4455] | Pekr: technical possibility? yes. native code? yes. use android api? see the link I posted above; SL4A could be a start. |
Pekr 13-Aug-2010 [4456] | thanks, missed those ones ... |
Robert 13-Aug-2010 [4457] | Rebol on mobiles makes sense to provide mobile clients to some commercial enterprise apps. Management loves to see the latest real-time sales numbers. |
Pekr 13-Aug-2010 [4458x2] | yes, I know - but so far, it seems to me, that most platforms are going towards more prohibitive way of accessing their APIs, and overall running other environments on them. For corporate sphere, Android, Win7 and BB are important, not so much iPhone imo, but if you introduce that as part of your app solution, some might accept it. |
the thing is, how we can get REBOL on such platforms. Compile REBOL app into something else or having REBOL in JAVA e.g., sucks imo - lot's of work. I can see the only way to be a native port, but then - connecting to APIs might be technically difficult. | |
Robert 13-Aug-2010 [4460] | If the platforms are closed... well, than we leave it behind and use the once that are open. And if people use closed platforms, well than they have to do without cool solutions. |
BrianH 13-Aug-2010 [4461] | The only platform that I know of that would prohibit native REBOL is Win7 (don't know about BB). However, some platforms (especially iPhone) won't allow the full REBOL experience including the GUI. Most GUI layouts would need rethinking for the small screen anyways, and using native tookkits matters much more on phones (memory, consistency), so that's not as big a deal. It does mean that we need to pay more attention to embedded profiles of the host kit. |
Pekr 13-Aug-2010 [4462x2] | but GUI (VID) is exactly our advantage imo, to show the world, how easy is it to do basic form apps. There is not much to adhere toGUI wise imo. Each app can look totally different, like in old Amiga days, no? |
BrianH: interesting note about Win7 .... I did not expect it. The licence is more prohibitive than that of an iOS? | |
BrianH 13-Aug-2010 [4464x2] | Native code is not allowed on WP7 - you must write for Silverlight or XBL (both .NET). This isn't a license restriction though, it's technological. .NET code becomes native before it is executed though, and GNU has a C compiler for .NET, so it's not so bad. WP7 has an app store but they have seen the fallout from Apple's restrictions so their store is much less restrictive. |
The pricniple behind VID - simple dialected GUI layouts - is REBOL's strength. The actual implementation would not be as much of a strength on a memory-constrained system with a native GUI toolkit and strict UI design rules. However, you can make a simple cross-platform layout dialect for phone UIs that tells the native toolkit what to do, and then make platform-specific implementations for the various native toolkits. Dialecting is REBOL's greatest strength. | |
Maxim 13-Aug-2010 [4466] | a lot of VID's dialect can be used to describe the layout even on native GUI toolkits. |
BrianH 13-Aug-2010 [4467] | Exactly! You would need to redo your layout anyways for the small screen (unless the layout dialect is *really* properly strict about not allowing sizes, offsets and real colors in its layouts, the way the R3 GUI is supposed to be), but the layout dialect itself could be very compatible and you could reuse a lot of code. |
Robert 16-Aug-2010 [4468x2] | WRT to all the discussions in ~Vent / Rebol3 GUI etc. I want to make some points clear. And, don't interpret things that are not written as these will be false. |
1. host-kit release: It's still Carl's job and responsebility to release official host-kits. We (RM-Asset team) won't do this. 2. host-kit support: Yes, we spend time to work on the host-kit source-code. And yes, we concentrate on these things we need for our upcoming projects. All this will flow into the host-kit and be available to you. And, I'm sponsoring this effort. Our goal is to help to get the host-kit to a stable state ASAP. | |
Pekr 16-Aug-2010 [4470] | and it should be also noted, than many here appreciate the effort very much, so thanks Robert. |
Robert 16-Aug-2010 [4471x9] | 3. rebol3 gui: We are working on getting VID to a state that it can be used for app development. For this we did a complete new resizing system, changed the styles etc. This is not yet ready for release because to much flux in the design and code. We will release it either in form of the official VID via Carl or as our own VID fork, if Carl decides that the official VID should look differently. No decision taken yet and I hope that we don't need to fork VID. |
4. styles: We need a bunch of styles for our apps. We will create them all if necessary because we need a stable style set that is enterprise & bullet proof. Most likely I can't make use of hobby-styles in commercial apps. There is a bunch of other requirements to full-fill. And yes, we will release these too. But, we set the priorities, we fix the bugs we think are critical, we work on the features we need. I listen to you, we think about it, but decisions are made on a pure: Urgent & necessary for business context. | |
5. Extensions: We will create a bunch of R3 extensions we need. Some will be quite special, some more generic. For these we use a mix from open-source libs, commercial frameworks etc. Which bings up the nice licensing issue stuff if things should be released. As I hate licensing issues at all, and it's a big time killer, my rule is quite simple: RM Asset will have all necessary licenses we need, if I can release stuff we think about it. If not, than not. Sorry. I don't have time to get all this sorted out to provide a perfect-R3-framework to everyone. | |
6. collaboration: We are absolutly open to it. We support the community with everything that's possible. But, our main focus will not be to become the community runners. We have our own priorities and we stick to them. Next, we focus on getting things done. If the community talks about a specific topic, no problem, if people code something, no problem. If we need something different, we will do it with or without the community. | |
7. financing / sponsoring: To be able to do it, one needs to have something to spend. And yes, making money form projects is the goal for us. This gives the freedom to spend money on non-project relasted R3 stuff we do. This is the sponsoring and investment we do into R3. As long as I can finance the sponsoring parts I will do it. Again, I follow the golen rule: The one owning the gold makes the rules. Meaning, I set the priorities to the things we need or which complete some aspects etc. But it won't be a community driven process. | |
All this won't stopp anyone to bite the bullet and do something on their own. If you want to avoid double work, cross-check with us. We will tell everyone what we are working on. I will tell everyone what our plans are. etc. As transparent as possible. | |
Again, we will move forward. You can "follow" us and use what we have done. You can "accompany" us to help driving things forward faster. At the end of the day it's your decision (of course). | |
But I won't enter any Kindergarten discussions that are not moving us forward or where some go nuts because we have clear red thread we follow and don't care to much what they think. | |
That's it. Overall, IMO we have moved R3 forward much faster and with greater progress than before. And it's not only because we are now coding everything etc. By far not. But at least we have helped to get more momentum to R3. | |
shadwolf 16-Aug-2010 [4480x3] | android is linux based ... i have one on my acer laptop that's a short linux ... |
on acer the android don't have access to android market ... | |
instead of having an android phone maybe the devtools include an emulator no ? | |
Gregg 16-Aug-2010 [4483] | Thanks Robert. I like the fact that a goal is the use of R3 to build commercial apps. That means things like accelerator keys and other features have a better chance of being seen as important. |
Carl 17-Aug-2010 [4484] | http://www.rebol.net/r3blogs/0329.html- about callbacks |
Oldes 17-Aug-2010 [4485] | cool... will be there any examples as well? |
Robert 17-Aug-2010 [4486x2] | (OT: Our world is back online) |
Carl, great news! I'm ready :-) | |
Robert 18-Aug-2010 [4488] | I have a XML file and want to handle it by tags like a nested block. Are there are any tricks? Or do I need to use PARSE / FIND etc. |
Gregg 18-Aug-2010 [4489x2] | So, you want to use path notation on the parse XML? |
parsed XML | |
Robert 18-Aug-2010 [4491x2] | I would like to extract a set of elements like: Everything between <TAG> ... </TAG> |
TAG should be specified. | |
Gregg 18-Aug-2010 [4493x2] | What I mean is, do you want to convert the XML to a block and then access it like this? data/tag |
Or do you just want to parse the raw data out of the XML between those two <tags>? | |
Robert 18-Aug-2010 [4495] | No, not necessary. |
older newer | first last |