Changed Open/Import Project Page

Aleix Pol aleixpol at kde.org
Tue Aug 3 01:03:19 UTC 2010


On Mon, Aug 2, 2010 at 11:06 PM, Andreas Pakulat <apaku at gmx.de> wrote:

> On 02.08.10 21:23:45, Aleix Pol wrote:
> > On Wed, Jul 14, 2010 at 3:56 PM, Aleix Pol <aleixpol at kde.org> wrote:
> > > Yes, that's what I meant by finding a better solution
> >
> > So we don't like the first step I added and I was considering solutions.
> > Since I have like a mental mess I'll put here the solutions I've thought
> of
> > so that we can discuss.
> >
> > - Separe the wizard into two menu entries open and import project for
> > example. It's easy and straightforward, no code duplication but clutters
> a
> > little the menu. I like it, but I fear the name might not be verbose
> enough.
>
> This is bad, there's a reason that its open/import project now. That
> reason is that in kdev3 times users where always confused which one to
> use when. IIRC the 'import' part is only kept there to cater for kdev3
> users which are used to look for an import entry to get their project
> into kdevelop (when it has no .kdev4 file).
>
> > - Put a Import project button in the same page as the KFileDialog that
> shows
> > the dialog. That would make the UI a little uglier but wouldn't influence
> > the rest that much. Also it would make the new feature very hard to see
> and
> > since it's very oriented to newcomers I don't really like it.
>
> I don't like that either, for the reasons you've already given.
>
> > - Have two KFileDialogs, one for the local case (with the select source
> > widget in the same view) and another one on the next page in case it's a
> > project that's just been checked out. I think this one might make the UI
> a
> > little complicated and probably duplicate some code but it would be the
> best
> > for current users.
>
> I guess you mean having the first page with the combobox and in case
> 'local' is selected (don't have the exact string here right now) get the
> file-selector below the combobox. On the other hand when selecting
> git/svn/... one would get whats there right now, i.e. a separate page
> with the actual file...
>
Yes.


>
> > What do you think? I think the best is to have the two menu entries but
> I'd
> > also like to know what do you think of my concerns on the other ones.
>
> I'd like to propose two more options:
>
> - have two menu entries, one for open/import project from disk, one for
>  open/import project from remote source (need to find better texts)
>  with separate dialog flows
>
What's the difference with my first option?
Yes, we have to be very careful with the naming.


> - Separate the "fetch" step from the "open/import" step, again by having
>  a separate menu entry, but automatically opening the open/import
>  dialog once the fetch is done. This would also make it easier to do
>  the whole thing asynchronously and showing progress of the
>  fetch-stuff. So there's a Project->Fetch Remote Project option which
>  has the first page of the import-wizard only, eventually a second one
>  if necessary. And then once the job doing the fetch (could be a
>  kio-copy, svn checkout, git clone, whatever) is finished it could
>  invoke the import wizard automatically.
>

I don't really see the advantage of having 2 wizards, it's not like we would
work while the project is being loaded. Also, we can make the dialog not
modal. Also, I think a new dialog popping up automatically would feel weird.


>
>
> Andreas
>
> --
> Your aim is high and to the right.
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100803/14156941/attachment.html>


More information about the KDevelop-devel mailing list