Hi All,
I would go for option 3, a default project that is already pre-configured
and can't be deleted (from inside the gui). I do not like obscure folders
in my home folder so I would store the information next to the ./config.
What we all agree on is that the UI around the projects might need to be
changed a bit. I do not like the pop-ups when creating a new project, a
wizard with a couple of "next next next" steps with some more information
and links to the documentation might be a better way to create a project.
I do agree with Sergio that the ability to open/remove projects from the
list and menu items to do this are in place. On the other hand I do not
agree with the need of creating a default environment. The environments are
great but only serve a purpose in multi-environment or bigger projects. We
have documentation about our layered parameter/environments set-up but
these are unfortunately already outdated.
To counter Sergio on one another point, you can edit the environment
variables via the UI the only thing you can't and might be an extra nice
feature is to create a new empty environment configuration file. you have
to create an empty json file containing {} to allow the edit button to work
we still hold true to our "everything should be possible via the GUI" way
of working.
Cheers,
Hans
On Thu, Jan 21, 2021 at 8:00 PM Bart Maertens <[email protected]> wrote:
> 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]
> .invalid>
> 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
> >
>
