[GRASS-dev] GRASS in OSGeo4W and upcoming releases
Dear all, In the light of upcoming releases (7.8.6 rather soon, 8.0 not too far either) I have been wondering about the (future) availability of GRASS versions on MS Windows. The Next Generation of OSGeo4W seems to be here, as the download-link on trac.osgeo4w.org already points to it. That is great as it allowed to have an ever growing amount of packages (let alone the large proj-data package) in a comprehensive installer. Going forward I have ported our github actions on Windows to OSGeo4W-NG (V2) (some cleanup and review remains), so we can test PRs against this new environment. But my questions are now: on the website we have for three versions advertised for download on Linux (https://grass.osgeo.org/download/linux/): a current, a legacy and a preview version. Personally, I think we should offer the same on MS Windows, where 7.8 would become the legacy version, 8 the stable version and 8.x the preview once 8.0 is released. For 7.8 and 8.0 we will have release candidates I guess, where we need to decide how we want those in OSGeo4W (should e.g. 8.0.1RC be a new version in grass-stable). The preview version would probably be something like a weekly or nightly build? Or is there some naming policy in OSGeo4W we should follow, Jürgen? I would be willing to contribute to packaging additional versions for OSGeo4w by adjusting the current packaging recipe to other version, oriented on e.g. the different QGIS packages. Would that be helpful, Jürgen, or would you prefer other ways to help getting this stuff into OSGeo4W-NG? BTW, on what system do you run the code here: https://github.com/jef-n/OSGeo4W (Cygwin? MSYS2?) would be useful to know for testing locally... Once we have those new versions in OSGeo4W, we should probably also have a look at the addon-builds for Windows. If they run on top of the available GRASS verions in OSGeo4W, we could make sure that addons for the respective versions are available. Builds could be automated in GitHub actions, I guess... I can contribute there as well, but we need an agreed-upon plan first, no? Any thoughts? Cheers Stefan ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Renaming master branch to main branch
Dear all, The master branch was renamed to main. Please update your local repositories and workflows accordingly. ## 1. Local repo update and branch rename If you are contributing code or compiling source code from Git, you need to modify your local repository as well. Go to your fork's website on GitHub. It will warn you about the rename in the OSGeo repo. Go to settings and to the rename. Go to the main page of your fork again. Now it will warn you about the rename in your repo (your fork). It will give you instructions on renaming the local branch and making it point to the renamed branch. (The assumption is that your fork repo is the remote named origin.) Additionally, there still will be upstream/master and you can remove it using (assuming upstream remote is the OSGeo repo. You can remove upstream/master and update info about the default branch using: git fetch upstream --prune git remote set-head upstream -a Alternatively, if you are not keeping your fork's master/main branch up to date, you can follow instructions from my initial email which allow you to skip the fork part resulting in a slightly different local setup. ## 2. Updating your contributing steps To update your local main branch (base branch) and to rebase or merge with the latest source code, use upstream/main instead of upstream/master. ## 3. Updating workflows using source code from Git If you have a workflow which is using the source code obtained from Git , you will need to update it if you explicitly specify the branch name. If you do --branch, checkout, or switch, and at the same time using the master branch, you will need to change "master" to "main". If you use only a simple `git clone`, no changes are needed because `git clone` takes the default branch which will continue to work. ## 4. Other issues The base branch for PRs was changed automatically. The PRs updating most of the source code for core and addons were merged. Some CI-related changes will still be needed for core. Additionally, I assume the workflows outside of the source code will be updated as part of the updates to addons repo structure and changes for the release branch for 8.0. Help in this area is welcome. https://github.com/OSGeo/grass/pull/1806 https://github.com/OSGeo/grass-addons/pull/598 Let me know if you face any questions. Best, Vaclav On Wed, Aug 18, 2021 at 10:41 PM Vaclav Petras wrote: > Dear all, > > I will rename our default branch currently called master to main in the > following days. We already discussed it here and there, but the rename > should be relatively smooth. Much simpler than the addons repo > reorganization. Users not compiling code themselves should not be affected. > Contributors will be, but GitHub warns you about the rename when you come > to the repo web page. Those compiling from source may need to make changes. > > The update of a local clone can be done with instructions similar to the > following (I will post them again once I confirm it is the best fit): > > git branch -m master main > git fetch upstream > git branch -u upstream/main main > git remote set-head upstream -a > > Additionally, to get rid of upstream/master, do: > > git fetch --prune > > You don't need to update your fork unless you want to. > > The changes needed in the repo are already in a PR (feel free to review): > > https://github.com/OSGeo/grass/pull/1806 > > Those compiling from source code obtained from Git will need to make > changes when they explicitly specify the branch. A simple `git clone` takes > the default branch which will continue to work. However, if you do > --branch, checkout, or switch, and at the same time using the master > branch, you will need to change "master" to "main". > > Let me know if you have any questions or concerns. > > Best, > Vaclav > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GSoC 2021: Final report: First steps towards a new GRASS GIS Single-Window GUI
Hello everyone, I am sending my Final GSoC report. The more detailed version with permanent links on GitHub PRs and with several screenshots can be found at the project wiki: https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout# FinalReport (https://trac.osgeo.org/grass/wiki/GSoC/2021/SingleWindowLayout#FinalReport) . Abstract: The project was focused mainly on the extensive Graphical User Interface refactoring necessary to prepare GRASS for Single-Window GUI. In addition to a good programming base, the simple working Single-Window GUI prototype was built in a parallel environment. This Single-Window frame largely copies the design (mockup) which the author had proposed for the GSoC application (see (https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/SingleWindow)[1]). All main functionality will be put into operation after the successful merge of PR [2] and PR [3]. (https://github.com/OSGeo/grass/pull/1789)However, to completely replace the current Multi-Window GUI solution, many other improvements are still expected. The state of the art BEFORE the start of GSoC: Although the GRASS GUI has been enriched with many new features since last year, the basic Multi-Window GUI concept used in all historical GRASS versions has been preserved. As the name suggests Multi-Window GUI consists of several windows (frames) - the control window and additional separate map display windows. The control window includes a notebook containing 5 tabs in a standard 2D map view - Data, Display, Modules, Console, and Python. The state of the art AFTER GSoC: A large part of the project was focused on GUI refactoring. The core work had to be done all at once in the PR (https://github.com/OSGeo/grass/pull/1675)[2] and since it overturns the core logic of map display widgets, it was decided to merge it after GSoC when the GRASS 8 will be released. To sum it up, we are probably not entirely done with the refactoring, but the main part was managed. In addition, a Single-Window GUI prototype has been coded in a parallel environment. I with help of my mentors handled to get to the stage where most of the functions are working. There is just missing completion of PR [3] and possible check/fix of workspaces functioning. It is important to emphasize here that I'm talking about basic functionality. To provide a really user-friendly environment, many other things will have to be changed or reprogrammed. All those steps are summed up in the "Next steps" paragraph. Conclusion: To follow the project idea I wrote for the GSoC application, I succeeded (with help of my mentors) to provide the first steps for a new era of Single -Window GUI. Those steps have a form of refactoring as well as a new parallel simple Single-Window GUI prototype. I believe it's one big step forward and I am looking forward to further development of which I would like to be a part. Next Steps: All these following points assume that the main functionality is working. In other words, we must have a merged main refactoring PR [2] and a merged PR [3](https://github.com/OSGeo/grass/pull/1789) aiming at the implementation of the AuiNotebook closing event. Then several improvements are possible (and probably necessary): * Enable undocking the Map Display notebook tab to a separate window. It will allow each user to use the Single-Window GUI as the Multi-Window GUI. * Fix switching to the Console pane in an automatic notebook if any information is written there. * Check/test if workspaces are functioning properly. * Focus on a newly added Map Display tab in the Display pane (now it may not be clear at first glance that it has been added). * Modify the appearance for the dark mode. Some parts are ugly and illegible (names of AuiNotebook tabs, names of panes, ugly gradients etc.). * Add the option for starting GRASS as the Single-Window GUI => we want GRASS geeks to try it out. :-) Other improvements mainly concern the organization of widgets and possible ideas for the future: * It is necessary to change the rendering of the 3D View panel. Now the 3 D View pane is added as another panel under the Display tab - very problematic in terms of space. * A part of the Console pane in the startup Single-Window layout is not visible. We should completely reorganize the Console tab, such as the Output window and Command prompt data outputs go into two separate tabs. * If both Map Display tabs are displayed side by side, the status bar cannot fit in the space. The solution is to create a separate dialog, which will contain a check box and other settings for the Map Display notebook tab. * Each user should be able to choose a convenient layout of widgets and save this setting for future sessions. It should be possible via perspectives. * Creating, saving, and selecting perspectives along with switching to dark mode could be part of a new tab menu
