r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

World: r3wp

[Windows/COM Support]

Yes, with the DLL interface you can theoretically create native-like 
GUI system according to your needs if you have enough time/motivation 
While maintaining the flexibility of VID/rebGuI ?
If you write VID/RebGUI like dialect with binding to Windows native 
GUI why not? :)
hmm, not sure Cyphre, but you are the guru. Does windows has anything 
like face? If you would use only its windowing system, it is just 
what win32API allows you - dialogs, etc. - so no such flexibility, 
unless you would code View like compositing yourself
Cool :)
Pekr: You can create and control any windows dialog if you have the 
API available. (and this can be applied to any other OS feature). 
So it is possible to create native GUI controlable at the higher 
level of some dialect(simmilar to VID/Rebgui). People who are making 
common apps don't need to access it at face level but ofcourse such 
system would be based on face-like objects with methods related to 
Windows GUI elements etc.
the same could probably be done for OSX/Cocoa... it would solve many 
issues with GUI nativity in OSX.
If you really need noative GUI then this can be the way but remember 
this is also *lot* of work multiplied by each operating system ;)
which is why it's probably not worth doing for anything other than 
Windows and OSX. For linux, it would be ... wow... how many different 
GUI systems do we have there? :-)
(But for example Java has already such toolkit and IIRC it is huge 
opensource  Eclipse tool platform supported by IBM)
Using native windows will go to greatly improving the success of 
View based programs in the commercial sector.
because they don't have to ask "why does the program look so weird?"
Using native Windows will certainly kill View completly
We use top systems - SAP - they have own look, completly, even behavior 
to some elements - noone complains ..... we have Lotus Notes - very 
different look to most of apps, different navigation to app ....
for me, RebGUI, look-wise, is very Windows like .... yet some of 
us, including you, Graham, complained that it looks dull, and if 
it could be prettified .... :-)
pekr, I don't believe so. View is essential for those 5 minute apps 
that you need to do for a friend.
of course, maybe it just depends, how professional you intend to 
be, but as I showed you, completly OS compatible look is not so important. 
What is imo more important is the feel. If we can't get visual representation 
of accelerator keys, ctrl tab, rich text, key precise behavior for 
ui elements, that is what I see as a problem ....
... that can be fixed imo, if View gets fixed in those respective 
areas ....
Just look for e.g. ad Ad-aware vs. Spy and Destroy. Spy & Destroy 
was chosen by many as better, yet I can see ppl chosing Ad-aware, 
because of different look actually ...
the question is, with Google and others pushing the envelope, how 
long OS itself will be driving factor of IT evoluion, or it will 
become a commodity :-)
Yes, in specific commercial sector people expect the 'conservative' 
look&feel. But  this feature should be provided as an external solution 
mainy due the increase of binary size of Rebol in that case. I think 
sch module would be for about 2MB in size.
I think time of "amiga" (in the sense of non traditional look to 
apps), is coming back in Internet age ...
ok, then, I can accept your pov. But - wouldn't fixing View plus 
providing certain skin be enough?
I agree that native GUI/feel should not be a main part of Rebol, 
but it should not be a luxury item either that you have to pay for
From my POV  View is still very ligthweight and powerful system for 
OS independent solutions.
I think that what Henrik feels as a problem is not actually "look" 
at all, but it is the "feel", which is the culprit. I expect UI elements 
as drop-down, etc., react to keyboard, mouse, just the same as if 
it would be OS app, or it is denerving, stopping my productivity, 
which is based upon certain customs ....
the problem, for me, for Bobik, and maybe for others, could also 
be, that VID simply has problems, and is not features/styles complete.
But we were promissed VID plus will fix that, no?
If I would consider different UI toolkit, maybe I would look to create 
some GTK or Qt bindings, as other scripting languages try to do ... 
those are existing, and even cross-platform, no?
...it should not be a luxury item either that you have to pay for

 Well, this all depends on the conditions.  You can expect this as 
 free stuff in Java world with much bigger developer base. But I don't 
 believe anyone here in our small comunity have enough time/resources 
 to spent hunderds hours on such project just to make some people 
 from the comunity happy and provide solution for their commercial 
 app for free ;)
Another possibility is that you find some company who is interested 
and pay the developement and make the source open for the comunity.
(or at least provide the framework in library form with documentation 
so people can use it)
cyphre, hopefully it wouldn't have to be the end of it. it should 
be the final product that users should pay for and native support 
for GUIs is not the goal but the means. I think it would be a bit 
sad if Rebol had yet another essential component as payware. you 
can do most of this stuff for free on other languages, which would 
cause even smaller motivation for using Rebol as a development platform.

this is why I release my components (LIST-VIEW, Tester, Tab-view, 
TOOLBAR) as BSD licensed freeware. If I didn't, I would have zero 
the money has to come from somewhere yes, but use the tools we create, 
to create more leverage in making money on end-user products.
Cyphre - I also agree with your another pov, which you had in the 
past. It all seems simple at the beginning, but once you delve more 
deeply into it, things start to complicate. Bringing native OS binding 
for Rebol imo would cost many resources. And I believe first version 
would be just ugly wrapper, containing more or less stright conversion, 
using Win32 logic. Isn't there a fact, that others do use other, 
mainly cross-platform bindings? We have View, but wouldn't native 
toolkit project be just reinventing the wheel? Others use tk, gtk, 
qt, wxwidgets, etc.
this also means it would be problematic if one developer were to 
only create developer products, so we shouldn't do that. balance 
between end user and developer products :-)
I wonder how much money Carl gets from Pro Rebol tools versus end 
user products like IOS. I think there should be more products like 
IOS for Rebol Tech to sell, in order to get income from there instead 
of from developers. You can get really far on other solutions without 
paying a dime.
nice :-) http://wxwidgets.org/about/screensh.htm(I got to it trying 
PythonCard for Python, which uses wxPython, which is just wrapper 
to wxWidgets)
Things like Webobjects for MacOSX cost a lot of money back in the 
NextSTEP days. Today they are free.
Henrik: agree...you are surely payed by someone for your cool widgets 
and it is great you can share it with us. So the same can be with 
other dev products. This all depends on the 'sponsor'. People usually 
provide something to comunity in case they really need/use it for 
their own work and IMO in our case that is the only way we can get 
more complex solutions 'for free'.
I also agree DLL support should be free in Rebol.
I am very tempted to know, what is licensing model and extensibility 
model for R3. Really not much was said in that regard yet ...
It's not so much the look I necessarily want but the support for 
native functionality.
is there any way to reuse some of the eclipse work?
Speech recognition command & control does not work with Rebol apps 
as long as that is the case and I need that...

 Terry claims speech recognition worls pretty well with his products.
Eclipse - erm, use java?
Anyone built a file transfer using FEC ?  http://research.microsoft.com/barc/mbone/fcast.aspx
Ms provide the Active X controls for this unsupported research prototype