Hi Matt, Hop, Option 3 seems to be the most transparent and intuitive approach if people choose not to configure projects.
I guess one of the main reasons why new users wouldn't want to work in projects is because they fear the unknown, projects have a sense of complexity or they feel out of their comfort zone one way or another. I guess the need for a project structure will automatically come when a user gets more comfortable in Hop Gui, begins to do more complex work, starts to work on different (real life) projects etc. One approach to keep projects close by in the user interface could be to show the project toolbar as disabled or greyed out, so it's right there to enable. We already have ctrl-click to enable/disable hops, we could consider making ctrl-click a default combination to enable disable functionality. That functionality would be the project toolbar in this case, but could also work for metadata objects that are not required in a given project etc. Regards, Bart On Thu, Jan 21, 2021 at 4:18 PM Matt Casters <[email protected]> wrote: > Dear Hoppers, > > In a lot of other IDE like tools you find a project-centric approach to > developing something. > Using a project is mostly enforced by the way that software works, for > example Eclipse or Idea. > > In Hop we implemented projects as part of a plugin because sometimes you > just want to trim things down to the bare essentials. So essentially what > this comes down to is that you can use projects and put all your work under > a certain folder as per usual OR you can do your own thing and configure > Hop just the way you like. > > Right now though it's not possible to not use a project once you've used > one in the GUI. > > Brandon raised this issue in a JIRA case and on the chat and perhaps it was > a misunderstanding but in any case we are faced with some options to reduce > confusion: > > 1. Force the use of a project on a user. Don't even allow new files or > metadata to be created without a project to work in. This is how most > tools work but the downside is that we'd have to nag the user for the > creation of a new project before anything can be done. > 2. Keep things as the way they are but allow the user to disconnect from a > project. Carify where metadata is stored in this scenario. We could simply > add a new button in the toolbar to "disconnect" from a project which would > simply clear the project combo box. > 3. Option 1. but with automatic creation of a "Default" project. We can > store that project somewhere in a standard location (configurable) like > Eclipse does in ~/workspace/ or simply in the config folder next to the > metadata (./config/projects/default) > > I honestly have no opinion on it so I thought I'd ask. It's not urgent but > it warrants clarification since this confusion will continue to bubble up I > think. Maybe you have another idea? Let us know. I'd be happy to make > the changes to the codebase, those are likely quite limited. > > I also think this issue can be tied together with the shipment of standard > samples packages with the Hop distribution. Perhaps if we have a Default > project we could also have a "Samples" project. > > Cheers, > Matt >
