Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[native-UI] What's native?

 [1/29] from: greggirwin:mindspring at: 21-Jun-2004 18:28


Hi Carl, CR> One of the complaints I receive about REBOL is it doesn't adopt CR> the look-and-feel of the OS it's running on, though if it did, my CR> complaint would be the program I'm using isn't consistant across CR> platforms. So, I've come to believe the user should be given a CR> choice in the matter, and ideally for each program they run. I don't know if emulating other GUI systems is worth the effort (which will be nothing short of enormous). Offering a native look isn't so hard, but getting the native feel right will always be tough, and a moving target at that. One of the big benefits to a non-native GUI--which I never seem to see mentioned--is what it's like to support apps that look and behave differently on each OS they run on (discounting glitches). If I have an interface that looks and behaves identically across platforms, I don't have to be running the OS my customer is to tell them what they're seeing on the screen, or what remember what special keys an OS uses. As an end user--one who spends most of his time on one platform--if I can take my app with me, it helps to have it exactly like I'm used to it on *my* native OS. Joel cites this as the single most important feature his editor should have, and why he uses the one he does--it's the same everywhere. I know the Mac community is notorious for refusing to use apps that don't adhere to UI standards, so that's obviously a tough call if you want to sell a commercial app into that sector. Just my 2 cents. It's a good topic. -- Gregg

 [2/29] from: carl:cybercraft at: 22-Jun-2004 17:17


>Hi Carl, >CR> One of the complaints I receive about REBOL is it doesn't adopt
<<quoted lines omitted: 6>>
>hard, but getting the native feel right will always be tough, and a >moving target at that.
All agreed. I never said it'd be easy. ;-)
>One of the big benefits to a non-native GUI--which I never seem to see >mentioned--is what it's like to support apps that look and behave
<<quoted lines omitted: 3>>
>they're seeing on the screen, or what remember what special keys an OS >uses.
True, and the docs can be identical as well. These are mainly the developers' problem, not the users', and I'm thinking of things from the users' POV.
>As an end user--one who spends most of his time on one platform--if I >can take my app with me, it helps to have it exactly like I'm used to >it on *my* native OS. Joel cites this as the single most important >feature his editor should have, and why he uses the one he does--it's >the same everywhere.
But, at least for now, most people are not switching between platforms on a regular basis, and those people expect an app to behave the way they're used to at the widget level.
>I know the Mac community is notorious for refusing to use apps that >don't adhere to UI standards, so that's obviously a tough call if you >want to sell a commercial app into that sector.
Still, if developers are moving to the browser as the interface of choice, the platform you're running on might begin not to matter too much. -- Carl

 [3/29] from: g:santilli:tiscalinet:it at: 22-Jun-2004 13:01


Hi Carl, On Tuesday, June 22, 2004, 7:17:35 AM, you wrote: CR> But, at least for now, most people are not switching CR> between platforms on a regular basis, and those people expect CR> an app to behave the way they're used to at the widget level. Well, Mac users maybe. Amiga users, only in part (you had MUI, ClassAction, and so on). Windows, well each app seems to do whatever it likes to. Widely used apps such as video or audio players have their own GUI, and so on. Linux, well if you think about UI consistency then you have never used Linux. :P Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [4/29] from: greggirwin:mindspring at: 22-Jun-2004 9:10


Hi Carl, CR> But, at least for now, most people are not switching between CR> platforms on a regular basis, and those people expect an app to CR> behave the way they're used to at the widget level. .... CR> Still, if developers are moving to the browser as the interface of CR> choice, the platform you're running on might begin not to matter CR> too much. I'm glad you said "at least for now", because I'm not really worried about "now"; I'm thinking about the future. Compare today's browsers and HTML with where they were when they started. Browsers definitely changed what people considered acceptable app design. In the early 90's, the UI gurus said 80% of people were happy with an app's performance if the next screen was displayed (completely) in 2 seconds or less, and these were rich UIs; after 2 sec's, performance acceptance dropped off pretty fast -- 4-6 second delays are death for desktop apps. Ed said: "Besides the look & feel issue, many /View widgets are not as rich nor as easy to program as those of HTML." And many HTML widgets are not as rich or easy to program as native widgets. :) For me, REBOL isn't about going head-to-head against other apps in the UI feature set, it's about creating better UIs that are compelling and that will be accessible to people who take their stuff with them, running it on whatever machine happens to be available. We may also want to consider what happens in scenarios of server rendered application bits. Let's learn from the morass of browser in compatibility issues that led to so much logic checking which browser you're running in, so you know what to do. -- Gregg

 [5/29] from: krobillard:san:rr at: 22-Jun-2004 10:41


On Tuesday 22 June 2004 08:10, Gregg Irwin wrote:
> Ed said: "Besides the look & feel issue, many /View widgets are not as > rich nor as easy to program as those of HTML." > > And many HTML widgets are not as rich or easy to program as native > widgets. :)
At least HTML widgets act like native widgets. There are some major 'feel' issues with REBOL widgets. The worst is the fact that popup menus are drawn in the view window and are not separate. I have had to increase the size of my main window because the popup menu for my application was being cut off at the window edge and menu items were unreachable! Another is lack of X11 clipboard support for text widgets. Usability issues, not look, is what keeps me from using REBOL/View for anything but the most basic GUIs. -Karl

 [6/29] from: ml:addept:ws at: 22-Jun-2004 13:43


There are a number of ways that you can avoid the pop-up inside window issue. Take for example the dropdown.r that I put up on REBOL.org It took me about an hour's time to put that together and I can add the same popup ability to any face inside of about 15 minutes now. It may be worth a look... Another thing you can look at is checking the location that the popup will appear and adjusting its offset and size to fit... HTH! ~~Ammon :~>

 [7/29] from: greggirwin:mindspring at: 22-Jun-2004 14:52


Hi Karl, KR> At least HTML widgets act like native widgets. There are some major 'feel' KR> issues with REBOL widgets. The worst is the fact that popup menus are drawn KR> in the view window and are not separate. I have had to increase the size of KR> my main window because the popup menu for my application was being cut off at KR> the window edge and menu items were unreachable! Another is lack of X11 KR> clipboard support for text widgets. Usability issues, not look, is what KR> keeps me from using REBOL/View for anything but the most basic GUIs. Clipboard support is, indeed, very important IMO. OTOH, the biggest problem I see is not what widgets don't do today, but the lack of low-level VID/View docs that will make it easier for all of us to write better ones when we need to. It's possible to do, as evidenced by Cyphre, Romano, Gabriele, Etienne, and others, but it's not easy enough for the rest of us. I think most, if not all, the pieces we need to do that are in our hands, so we're to blame as much as RT IMO. Another thing to consider. If you use native widgets in your UI, you're probably going to lose use of things like the EFFECT block. In most cases that's not an issue, but for skinned UIs it will be important. -- Gregg

 [8/29] from: rotenca:telvia:it at: 23-Jun-2004 1:29


Hi, Karl
> At least HTML widgets act like native widgets. There are some major 'feel' > issues with REBOL widgets. The worst is the fact that popup menus are drawn > in the view window and are not separate. I have had to increase the size
of
> my main window because the popup menu for my application was being cut off
at
> the window edge and menu items were unreachable!
This is not a Rebol limit. This is only a limit of the actual implementation of the mezzanine choose func. From my pov, Rebol has not great limits in Gui, but the actual Vid styles are very basic (to keep View Rebol size low) and if you want advanced styles, you must write them by yourself. The point is that it CAN be done almost always. The only limits i see are: 1) drag and drop cannot happen between not rebol and rebol windows 2) systray in windows is not supported in plain View version 3) clipboard support is basic
> Usability issues, not look, is what > keeps me from using REBOL/View for anything but the most basic GUIs.
I agree on the fact that the most important side Rebol gui is usability; look is never the problem in professional projects. The reason is simple: i did not remember in my experience a professional project without at least a graphic people (often many more). --- Ciao Romano

 [9/29] from: carl:cybercraft at: 23-Jun-2004 20:07


>Hi Karl, >KR> At least HTML widgets act like native widgets. There are some major
<<quoted lines omitted: 12>>
>low-level VID/View docs that will make it easier for all of us to >write better ones when we need to.
Indeed. A lack of decent View docs is a huge time-waster. For instance, I stumbled on CHOOSE recently, which solves Karl's complaint above about popup menus being stuck within windows. Example... view layout [ text "Menu" [ choose/offset ["a" "b" "c" "d"] func [face][print face/text] 50x50 ] ] Available in View 1.2.1 and probably earlier. Documented anywhere? Not that I've noticed. Sigh... -- Carl Read

 [10/29] from: rotenca:telvia:it at: 23-Jun-2004 12:49


> view layout [ > text "Menu" [ > choose/offset ["a" "b" "c" "d"] func [face][print face/text] 50x50 > ] > ] > > Available in View 1.2.1 and probably earlier. Documented anywhere? Not
that I've noticed. Sigh... http://www.rebol.com/docs/words/wchoose.html --- Ciao Romano

 [11/29] from: rotenca:telvia:it at: 23-Jun-2004 12:51


Hi,
> This is not a Rebol limit. This is only a limit of the actual implementation > of the mezzanine choose func.
I wanted to say: it is only a limit of the actual use of choose (like happens in the choice style) where the /window refinement of choose is used. --- Ciao Romano

 [12/29] from: carl:cybercraft at: 24-Jun-2004 0:28


>> view layout [ >> text "Menu" [
<<quoted lines omitted: 5>>
>that I've noticed. Sigh... >http://www.rebol.com/docs/words/wchoose.html
Ah - I stand corrected. Though you won't find that page by looking in their View docs as far as I can tell - you have to get to it via the Core docs. Still, it looks like I need to explore their site a bit more... -- Carl

 [13/29] from: rotenca:telvia:it at: 23-Jun-2004 16:49


Hi, Carl
>Still, it looks like I need to explore their site a bit more...
I think that the words section of the Rebol site (http://www.rebol.com/docs/dictionary.html) is the more up to date of the whole rebol site. But i agree, rebol docs are not great at all. I should say: Rebol documentation hides the power and the deep of the language. And it hides well :-( --- Ciao Romano

 [14/29] from: greggirwin:mindspring at: 23-Jun-2004 10:26


Carl et al, CR> Still, it looks like I need to explore their site a bit more... You could also use view-ref (which needs to be updated), or http://www.rebol.com/docs/dictionary.html to poke around, or maybe someone could spruce up this idea that would show you info for a random word. REBOL [title: "word-a-day"] random/seed now/precise words: remove-each w first system/words [not value? to lit-word! w] word: first random words print [uppercase form word newline] do reduce ['help to word! word] halt -- Gregg

 [15/29] from: g:santilli:tiscalinet:it at: 23-Jun-2004 19:31


Hi Gregg, On Wednesday, June 23, 2004, 6:26:20 PM, you wrote: GI> word: first random words or word: random/only words Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amiga Group Italia sez. L'Aquila --- SOON: http://www.rebol.it/

 [16/29] from: krobillard:san:rr at: 23-Jun-2004 11:14


I didn't know about choose/offset but this really isn't an improvement. The popup window has a title bar and border like a main window and if you move the window containing the choose widget, the popup window doesn't open over the widget anymore! That's how it works on the Linux version at any rate. This is not consistent with any other popup menu I've used on any OS. And why do I have a choice of a separate window or not? What happened to simple thing being simple? It's good to see that view functions are now in the function dictionary. -Karl On Wednesday 23 June 2004 03:49, Romano Paolo Tenca wrote:

 [17/29] from: greggirwin:mindspring at: 23-Jun-2004 13:22


Hi Gabriele, GI>> word: first random words GS> or GS> word: random/only words Thanks! I'm always forgetting to look for help on things I *think* I know about. :) -- Gregg

 [18/29] from: greggirwin:mindspring at: 23-Jun-2004 14:23


Hi Karl, KR> What happened to simple thing being simple?
>> fn: func [face] [print face/text] >> chooser: does [choose/offset ['A 'B 'C 'D 'E] :fn wnd/offset] >> view wnd: layout [button [chooser]]
This works for me under Windows. Maybe send them a feedback about Linux's behavior. -- Gregg

 [19/29] from: rotenca:telvia:it at: 23-Jun-2004 23:28


Hi Karl,
> I didn't know about choose/offset but this really isn't an improvement. The > popup window has a title bar and border like a main window and if you move
I do not see it here on XP.
> the window containing the choose widget, the popup window doesn't open over > the widget anymore!
view layout [text "Menu" [choose/offset ["a" "b" "c"] func [face][print face/text] screen-offset? face]]
> This is not consistent with any other popup menu I've used on any OS. And > why do I have a choice of a separate window or not? What happened to simple > thing being simple?
It does not seem to me too complex changing "50x50" with 2 words (screen-offset? face). The problem is lack of documentation. I'ld be happy if solutions in C would be of the same complexity. A better choose function should permit to set the offset automagically. the point is that it can be done: only 2 or 3 lines of code to add to the choose function. --- Ciao Romano

 [20/29] from: krobillard:san:rr at: 23-Jun-2004 22:19


On Wednesday 23 June 2004 14:28, Romano Paolo Tenca wrote:
> I do not see it here on XP. > It does not seem to me too complex changing "50x50" with 2 words
<<quoted lines omitted: 4>>
> point is that it can be done: only 2 or 3 lines of code to add to the > choose function.
Well thanks for yet another attempt at a solution. Yet the fact remains that this popup menu acts in highly non-standard ways. On X11 the title bar *is* present. When you click somewhere off the popup it does *not* dissapear as it should. And when the window is near the screen border the popup will appear at a random location (sometimes on the opposite side of the screen). It is simply not something I'd use in a professional application. The same widget coded in C++/Qt only takes about twice the amount of code as REBOL. The neat thing is, it actually works properly (and on all platforms). -Karl

 [21/29] from: carl:cybercraft at: 24-Jun-2004 21:33


>On Wednesday 23 June 2004 14:28, Romano Paolo Tenca wrote: >> I do not see it here on XP.
<<quoted lines omitted: 15>>
>The same widget coded in C++/Qt only takes about twice the amount of code as >REBOL. The neat thing is, it actually works properly (and on all platforms).
Hi Karl, Yes - all true, or at least about the title bar. I've just checked it in Linux. The problem appears to be that they're using a window for CHOOSE and on some platforms a window's border can't be got rid off. The following in Windows gives you a borderless layout... view/options layout [button "Close" [unview]] [no-border no-title] but not in Linux. What's more, on Amiga the NO-TITLE isn't needed to get rid of the border, but it is in Windows. (Though Amiga's depricated with regards to Amiga, at least at the moment, so...:) So windows' borders are a real problem for cross-platform apps in REBOL, never mind attempting to create popups. The real question I guess is what platforms RT plans to support with regards to View in the long-term. Will they go back to supporting all the platforms they started out supporting if resources ever permit them to again, or just stick with four or so of the main ones? As a limited number would perhaps allow them to do more as well as reaching a higher level of cross-platform compatibility. In the meantime though, it looks like we'd be best to stick to menus within a window... ): All that said, I'm still very impressed at the level of cross-platform compatibility View does achieve. -- Carl Read

 [22/29] from: sags:apollo:lv at: 24-Jun-2004 16:41


What about direct access/comments of documentation like it is in php.net for example? Janeks On 23 Jun 2004 at 16:49, Romano Paolo Tenca wrote:

 [23/29] from: mmastroianni:fluentenergy at: 24-Jun-2004 10:09


Hi all - (occasionally I feel the need to abandon my daily lurking here and say something -- the interplay here is fascinating to me...)
> The problem is lack of documentation. I'ld be happy if > solutions in C would be
<<quoted lines omitted: 3>>
> Ciao > Romano
I just want to say this: I yearn for the day that there is that milestone kind of tutorial/text/manual documentation that leads the potential future REBOL user/developer from very simple REBOL concepts to very complex ones, peeling away the confusion that I and others encounter attempting to secure the benefits of REBOL with limited time available to get it . I have used REBOL successfully to do useful things, but without the benefit of appreciating its elegance (so often described here passionately). This makes it difficult to be an effective advocate; it is becoming ever easier to consider a language like Python as a reasonable best candidate for a scripting tool, given the documentation support and community resources. I have even purchased the time of a very competent REBOL programmer and travelled w/ an IT associate for a one afternoon tutoring session. It was very useful, but scratched the surface (by definition). My point: if excellent (i.e., clear, illustrative, progressive) tutorial/reference materials and information are compiled and made available (perhaps even an occasional training seminar), if REBOL is as capable and worthy of our interest as I believe it to be, people will adopt it in much greater numbers; and companies like mine will risk depending on it. (That felt good - thanks for suffering my brief soapbox digression...) Regards, Mike Michael Mastroianni President, Fluent Energy [mmastroianni--fluentenergy--com]

 [24/29] from: nitsch-lists:netcologne at: 24-Jun-2004 19:19


On Mittwoch, 23. Juni 2004 20:14, Karl Robillard wrote:
> I didn't know about choose/offset but this really isn't an improvement. > The popup window has a title bar and border like a main window and if you > move the window containing the choose widget, the popup window doesn't open > over the widget anymore! That's how it works on the Linux version at any > rate.
Thats linux. It even differs between window-managers AFAIK. Lack of ressources..
> This is not consistent with any other popup menu I've used on any OS. > And why do I have a choice of a separate window or not? What happened to > simple thing being simple?
Maybe to avoid this window-manager-problems? Also the code is very similar. And, does it make your code bigger? BTW, i like that view/linux can't do this titlebar-hiding. Else, show image of screenshot, let user enter password..

 [25/29] from: nitsch-lists:netcologne at: 24-Jun-2004 19:26


On Dienstag, 22. Juni 2004 19:41, Karl Robillard wrote:
> On Tuesday 22 June 2004 08:10, Gregg Irwin wrote: > > Ed said: "Besides the look & feel issue, many /View widgets are not as
<<quoted lines omitted: 7>>
> size of my main window because the popup menu for my application was being > cut off at the window edge and menu items were unreachable!
Sounds like a very small app-window?
> Another is > lack of X11 clipboard support for text widgets. Usability issues, not > look, is what keeps me from using REBOL/View for anything but the most > basic GUIs.
Have you tried betas? for me it was utterly broken first, then it worked with xterm, not kde, then it worked with both on suse 8.0, currently KDE is a bit broken on knoppix 3.4 again. Since KDE-clipboard was broken anyway, i guess thats KDe's fault. With emacs and /view i copypaste all the time with betas.
> > -Karl
-Volker

 [26/29] from: antonr:lexicon at: 25-Jun-2004 16:08


All I can say is: set [a b]["write some" "code"] print [a b a b a a a b] :) Anton.

 [27/29] from: antonr:lexicon at: 25-Jun-2004 17:04


> > This is not consistent with any other popup menu I've used on any OS. > > And why do I have a choice of a separate window or not? What
<<quoted lines omitted: 3>>
> very similar. > And, does it make your code bigger?
But, lack of pop-menu is a deficiency of View on linux which will need to be fixed. I think every user interface has its own way of doing pop-menus. Windows just happens to allow rebol to do it with a window. (I don't know if native pop-menus are based on a window or not.) This means rebol's implementation is currently simple, but therefore not cross-platform. So some work will need to be done to see how best to implement pop-menus on unix. It would be good to see a local-choose or local-pop-menu similar to local-request-file, as we have now.
> BTW, i like that view/linux can't do this titlebar-hiding. Else, > show image of > screenshot, let user enter password..
Hmm makes me wonder if taking screen shots ought not to require higher privilege, since the user might have private information on screen. Anton.

 [28/29] from: greggirwin:mindspring at: 25-Jun-2004 11:13


Hi Anton, AR> It would be good to see a local-choose or local-pop-menu similar AR> to local-request-file, as we have now. On Windows, once the system port works with View Windows, we should be able to use the menu APIs directly. We could now, but only for console windows. :\ -- Gregg

 [29/29] from: didec:tiscali at: 29-Jun-2004 21:04


> There are a number of ways that you can avoid the pop-up inside window > issue. [...]
The easier is to use the 'confine func :
>> help confine
USAGE: CONFINE offset size origin margin DESCRIPTION: Return the correct offset to keep rectangular area in-bounds. CONFINE is a function value. ARGUMENTS: offset -- Initial offset (Type: pair) size -- Size of area (Type: pair) origin -- Lower bound (upper left) (Type: pair) margin -- Upper bound (lower right) (Type: pair)
> HTH! > ~~Ammon :~>
DideC

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted