Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 12:49
    zwortex commented #4549
  • 12:48
    zwortex commented #4549
  • Jan 14 22:30
    hiiamboris commented #4788
  • Jan 14 22:14
    dockimbel commented #4788
  • Jan 14 21:53
    dockimbel edited #4788
  • Jan 14 21:52
    dockimbel commented #4788
  • Jan 14 21:46
    dockimbel assigned #4788
  • Jan 14 21:44
    greggirwin commented #4793
  • Jan 14 20:06
    hiiamboris commented #4793
  • Jan 14 20:05
    hiiamboris commented #4793
  • Jan 14 19:27
    hiiamboris closed #4768
  • Jan 14 19:27
    hiiamboris commented #4768
  • Jan 14 19:18
    hiiamboris reopened #4768
  • Jan 14 19:18
    hiiamboris commented #4768
  • Jan 14 18:52
    zwortex opened #4799
  • Jan 14 17:53
    hiiamboris commented #4793
  • Jan 14 17:50
    hiiamboris commented #4798
  • Jan 14 17:50
    hiiamboris commented #4798
  • Jan 14 17:47
    hiiamboris commented #4798
  • Jan 14 17:25
    greggirwin closed #4798
Muhammad N ElNokrashy
@narfanar
@geekyi Compilation Error: unknown directive macro
Henrik Mikael Kristensen
@henrikmk
Well, guys, I'm terrible at catching up, but, I'd just like to say that being able to download an executable and start building a GUI with it is exactly what I hoped for! I hope this keeps going. It's starting to feel like a true successor to R2. :-)
Gregg Irwin
@greggirwin
There is a lot to catch up on Henrik.
Holler for what examples will help you most.
Henrik Mikael Kristensen
@henrikmk
@greggirwin I guess I'm really just getting the feel for what's working or not at the moment. Some things don't work quite as expected.
Boleslav Březovský
@rebolek
@henrikmk Hi Henrik! Just post what you think does not work.
Henrik Mikael Kristensen
@henrikmk
@rebolek ok, I tried the TEXT-LIST widget under macOS, but FACE/SELECTED seems to be one step behind in what it returns
Boleslav Březovský
@rebolek
@henrikmk I am not on macOS now, so can't confirm it, but you should add things like this to issue tracker at Github: https://github.com/red/red/issues
Henrik Mikael Kristensen
@henrikmk
thanks
Gregg Irwin
@greggirwin
@henrikmk https://doc.red-lang.org/en/view.html#_text_list notes the behavior clearly.
That tripped me up at first too.
Henrik Mikael Kristensen
@henrikmk
is that borrowed from JS or something? because that doesn't make sense to me, not even that you would need to use two different events to get the old and new selection.
Gregg Irwin
@greggirwin
I can't answer that design question. It may be due to native constraints.
Henrik Mikael Kristensen
@henrikmk
there's no way to pass both the old and new selections to a sub-function.
Gregg Irwin
@greggirwin
If you only get one event, though, how would you support the feature of accessing the prior selection?
Henrik Mikael Kristensen
@henrikmk
simply store OLD-SELECTION as well
Gregg Irwin
@greggirwin
Which is what you would do here, correct? Store old sel on select.
Henrik Mikael Kristensen
@henrikmk
I should not need to do that manually.
Gregg Irwin
@greggirwin
Pose it, and offer a suggested improvement in https://gitter.im/red/red/gui-branch.
PeterWAWood
@PeterWAWood
@Enamex Macros in Red/System are like C macros, they are not executed by the compiler but simply "in-line" the code.
geekyi
@geekyi
@PeterWAWood Are Macros supposed to execute in Red/System? Any special commandline arguments?
geekyi
@geekyi
So the #macro directive is only supported in the Red preprocessor, not in the Red/System preprocessor, both of which happens at compile time (but in the Red case, is also there in the interpreter for compatibility?)
PeterWAWood
@PeterWAWood
The Red/System compiler uses #define for macros. Here is an example:
#define I64-copy(a b) [
    b/least-sig: a/least-sig
    b/most-sig: a/most-sig
]
PeterWAWood
@PeterWAWood
Nenad Rakocevic
@dockimbel

@henrikmk

there's no way to pass both the old and new selections to a sub-function.

In select event:

  • Old: face/selected
  • New: event/picked
event/picked is described in event! section. Though, in a User Manual, we should put all those information together for easier reading.
Gregg Irwin
@greggirwin
In my rush earlier, I forgot it was in event. Tried face/picked. Sorry Henrik!
Henrik Mikael Kristensen
@henrikmk

@dockimbel That still doesn't provide the necessary information where it's needed, in the ON-CHANGE actor. So either ON-CHANGE is worthless or it can only be used in specific circumstances, which the application author must be aware of.

If I were you, I'd get rid of the ON-CHANGE actor, because it doesn't easily describe what change has happened to the widget and who did it. Go with ON-SELECT which is specific enough, along with providing OLD-SELECTION and SELECTION words for the application author to work with.

The GUI needs to be luxurious about what it provides to application authors, because this is where the nitty gritty of debugging happens, and it might as well be provided and debugged by the GUI once, so each application author doesn't have to write and debug their own code for it.

Petr Krenzelok
@pekr
@henrikmk as for the eventual set-faceand get-face- did they allow (in R3-GUI) both setting/getting the default facet, and also the refinement, where you could select the parameter you want to set/get?
Nenad Rakocevic
@dockimbel
@henrikmk select event happens just before a change is applied to the list, change event happens just after. Both are desirable.
Henrik Mikael Kristensen
@henrikmk
@dockimbel but it requires the user to write more code for the same event which is selection. I think you're calling it desirable, because it comes from somewhere else. :-) It's not good code.
Nenad Rakocevic
@dockimbel

@henrikmk

Go with ON-SELECT which is specific enough, along with providing OLD-SELECTION and SELECTION words for the application author to work with.

I don't see the point, we already expose those information to the user.

Henrik Mikael Kristensen
@henrikmk

@dockimbel the information is not exposed where it's needed, in ON-CHANGE. besides, it's not intuitive to expose such related information in such two different ways as FACE/SELECTION and EVENT/PICKED.

If I want to send that information to a function called in the actor, I have to provide more arguments, than just sending FACE.

Nenad Rakocevic
@dockimbel
@henrikmk Yes, you need to pass face and event in such case (or just event/picked). I still fail to see why that would be a problem.
Henrik Mikael Kristensen
@henrikmk
I need to write more code. That's the problem.
Nenad Rakocevic
@dockimbel
Passing two arguments instead of one is a problem for you?
Henrik Mikael Kristensen
@henrikmk
and I need to keep in mind that these differences exist, because in RebGUI, PICKED and SELECTION are very different things.
Nenad Rakocevic
@dockimbel
Ok, so your real issue is that you want Red/View to be exactly like RebGUI?
Henrik Mikael Kristensen
@henrikmk
not at all
uralbash
@uralbash
Does red depend on rebol? (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=red#n11) or it's just for test?
Henrik Mikael Kristensen
@henrikmk

@dockimbel Please have a more macroscopic view of it. It's not a matter of 1-2 lines of extra code for that one widget, but a program with maybe 500 widgets, which I work with on a daily basis. That leads to a substantial amount of extra code to debug, and it gets really tiresome, when you've done it 200 times.

It gets a lot worse, when your widget is more complex. What is the content in EVENT/PICKED for a multi-select table or a field or a drop-list? Does EVENT/PICKED even work in all those cases? Would it then not make sense to map it to something more meaningful in all cases, so the application author doesn't have to remember this?

This is why I say: Really accommodate the application author and provide all the necessaries in easy to remember facets. Having the same information in two places is less important than trying to be sparse, and I think this is a lesson that REBOL GUI systems haven't learned.

Oldes Huhuman
@Oldes
@uralbash current Red compiler is written in Rebol... Red or Red/System compiled scripts doesn't depend on it.
The plan is to write Red compiler in Red in a future.
Hi @henrikmk ! Maybe you should propose a solution which you would found more friendly than current state.
uralbash
@uralbash
@Oldes thanks
Nenad Rakocevic
@dockimbel
@henrikmk You seems to have a very specific model in the back of your head, with which you compare Red/View and rant on the differences. I cannot make sense of your questions about event/picked, nor why you have troubles with information provided by event values. Getting back to more objective points would be helpful, otherwise I don't see this discussion going anywhere.
Henrik Mikael Kristensen
@henrikmk

@dockimbel Yes I have a very specific model in my head and it has developed over about 15 years of working with REBOL GUIs.

The model picked, requires the application author to have intimate knowledge of individual widgets to know how to use them, and this will get worse, the more widgets are written for the UI.

You need to consider scale. Large programs with many widgets. Writing many different throw-away programs. Reducing the need for debugging and the need to write support code to make the UI system work correctly.

This requires that widgets at least have a sensible set of facets that are straightforward and uniform to work with. What these facets are, is something you find out over time, as you write applications with the widgets. Common facets can be selection, old selection, highlighting, face state, preferably stored in an object inside the face.

Later on, build accessor functions for providing a uniform interface for obtaining a selection from tables, fields, etc. This is also useful for traversing forms of very different faces with very simple loops.

Sure, internally, use EVENT/PICKED as you like, but provide the nicely formatted information, so the application author isn't burdened with it.

Henrik Mikael Kristensen
@henrikmk
@pekr I think @rebolek may know the answer to your set-face/get-face question.
François Vanzeveren
@fvanzeveren
Hi all, for those using EditPadPro, I have uploaded a syntax coloring file definition for Red, including VID dialect here: https://www.editpadpro.com/cgi-bin/cscslist4.pl?focus=282 . I invite you to discover this extremely powerfilprogramming text editor. Regards
typo: powerful programming editor