Gtk: shape started and fixes on offset, timer, dragging....

[rcqls]

A lot of red scripts run on Linux with this PR. The most well-known is tiger.red ....

[qtxie]

This is PR contains many commits which already in the GTK branch. Would you please remove it?

[dockimbel]

@rcqls You need to git rebase or git merge from red/GTK to your local branch before making a PR, otherwise, it's impossible to review as too many unrelated commits are included in your PR...

If we need to refresh the red/GTK branch with latest red/red commits, let me know.

[rcqls]

@dockimbel Oups, I thought this PR was closed by me. Currently there is a lot of changes in my repo rcqls/GTK-dev. My plan is to simply fetch red/GTK to rcqls/GTK and simply copy and paste all my new files from rcqls/GTK-dev to rcqls/GTK. Of course I will loose the git history but it would be still in rcqls/GTK-dev and it does not really matter. Is it ok? I think I already said that to @qtxie but I am unsure.
It could be a good idea too to refresh the red/GTK branch before.

[greggirwin]

@rcqls do you have all your work safely somewhere else, and this PR can be closed?

[rcqls]

@greggirwin Yes you can safely close this PR. All the GTK stuff is in rcqls/red:GTK-dev branch. I am waiting for the 0.7.0 release a GTK branch to update everything and include in the red/red:GTK branch.

[dumblob]

@rcqls sorry to comment here, but Issues is closed in your own repo with GTK branch. I have quite an important question - namely why are you, and I quote "waiting for the 0.7.0 release" of Red?

I'm unfortunately one of those who would like to use your work (i.e. Red GUI on Linux) as soon as possible, but I have to admit, that gathering sources from different places is kind of difficult. Maybe just having a GTK3 pull request open while requesting pull into red:master (not just red:GTK) and regularly rebasing it while waiting for acceptance (might be many months - depending on the Red development schedule) would ease the transparency and possibilities for those trying to run full fledged Red on non-Windows, non-MacOS, and non-Android platforms.

It would also encourage reviews of more devs, so the chance of merging shall significantly increase (Red repo has almost whopping 4k stars).

@ all Red devs: Generally last few years statistics from Stackoverflow show, that great majority of developers use Unix-based systems (and only a smaller part of them uses MacOS), so allowing them to develop (i.e. use all Red features) on their favorite platform shall be the very second priority immediately after a good paying customer.

[9214]

@dumblob we have a dedicated chat room for discussions related to GTK branch, and I strongly suggest to move all your questions there.

[rcqls]

@dumblob As @9214 suggests we can chat in the red/GTK room. As a quick answer, I can just tell you that I open issues in my repo. The fact that I, for a temporary period, develop everything in my repo is only because I never see any person willing to contribute in the red/GTK branch for longtime. Like you I hope this will change when my first proposal would be consequent enough. From now it is easier for me to develop in my branch even though it is a bit messy. Since the next version of red (0.7.0) is coming soon, I decided it could be a good idea to make the red/GTK on par with the master branch for this next version.

[dumblob]

@9214 thanks for the pointer to the chat.

@rcqls thank you for the explanation and for opening the issue tracker - your repo serves as kind of "staging" then 😉.

One more thing regarding using "chat". I'm quite a busy person (and I dare to say many (most?) other open source community members also are), so no time to chat. Chat or alike feels like an information black hole (it's difficult to follow all the chat as it's by definition "chatty" and it's difficult to reference any information from a chat to anyone in public and even more difficult to search for such information). Chat is also usually "not persistent enough" (e.g. the history remains only for a certain period). People will be asking over and over the same thing as having answers in some of the many communication channels while explicitly having no such answers in the main communication channel (i.e. GitHub issues of the Red repo) is more than often like not having them at all.

That's why I prefer asking questions directly in a tracker and just e.g. labeling them with question to distinguish them and make them easily filterable and searchable. Last but not least the advantage of having to search just once and not in each communication channel separately is enormously helpful - otherwise performing all search steps (including refining, searching for different similar words, etc.) must be performed N-times - for each communication channel - leading to high complexity, then fighting different searching mechanisms and engines, having a different audience on each communication channel whereas the "right people" are by Murphys laws always "on other channels", etc.

Pardon the lengthy post but as I'm already at it, I'll repeat the old truth. Technical centralization is really bad as it implies single point of failure/..., but user interface centralization is the goal number one in accessibility, manageability, and whole general success (and in case of non-critical data it's even more important than avoiding technical centralization - in case of GitHub one can even export regularly all the data and store it somewhere else so one doesn't have actually any risk in using "solely GitHub for everything").

Sorry for this rant - I just had the urge to openly communicate my thoughts as I really like the year-long persistence with which you're developing Red and wishing Red will become way more widespread and you to earn some nice (material/monetary/...) benefits for all the hard work.