Git UI Idea

[James Liggett]

Hey Everybody,
If you've been following recent git plugin developments, you might have
noticed that some of my fellow devs are unhappy with the menu overhaul I
did list month. This would now have been at least the third time this
subject has come up since April, and I don't see it going away anytime
soon. Over the next cycle, I anticipate adding more features; thus the
situation will only get worse.

A great number of different ideas have been proposed by my fellow
developers and I. But I honestly don't like what we have so far. Usually
it comes down something to the effect of: We should have [features I use
here] put in the top-level menu, and put everything else in submenus.
But, there's one *big* problem with that: There is no one way to
accomplish a great deal of things in git, so features that might be used
frequently by one person might not be used at all by somebody else. The
bottom line is that any one proposal would make the git plugin easier
for the person proposing any one solution to use, and harder for some
others. If we are to attract as many users as possible to our project,
we cannot accept such a situation.

As we discussed various ideas on this list, Johannes suggested that we
consider maybe even doing away with most of the menu, and replace it
with some kind of visual system. Specifics weren't discussed in that
thread, but as I evaluate different ideas, I become more intrigued by
such a unique and radical possibility.

I have had such ideas myself in the past, but didn't really investigate
too much because I never really had anything concrete. So I had a
thought a few days ago. What if we replaced the git menu, and the log
viewer, with a GNOME Shell-like overlay?

Now, I'm sure there's a few people here that will probably say something
like: "There's no way in hell we should do that. GNOME Shell sucks!!" ;)
So let me start by describing what this idea is NOT:

It is not excuse to add eye-candy to Anjuta where it doesn't belong. It
doesn't have to look *exactly* like Shell does; with the newest GTK, we
can make it look very much like it does now.

So, what exactly IS this idea then? Basically, I think that if we had
the whole Anjuta window (or even the whole screen) at our disposal, we
could put a lot more things at the user's fingertips. We could show the
log of changes in the middle, and maybe even branches, and have the
commands off to the left like Shell has. I imagine that the list of
commands would change depending on what you have selected in the middle
(a branch or revision). You could have things that have to do with that
selection, like reverting a revision, or rebasing a branch, and so on.

And, placement of the commands in the list, which would be categorized
by type, would change based on context. If you're in the middle of a
rebase, the rebase commands would be up front. If you're bisecting, the
bisect commands would be up front, and so on. We might even be able to
have a "most used" section where the user's most used commands are
always within reach, not unlike what Shell does with app lauchers.

A method like the one I've described can also help cut down on clutter
in the UI and maybe make things easier to use. For example, you might
notice that we waste a lot of space in the log viewer on the message
pane. We could reimplement that as some kind of floating overlay. We
could do the same for things like bisect and diff, i.e. we could have
the users drag revisions to diff them or select good or bad revisions in
a bisect.

Like with GNOME Shell, this overlay would be implemented with Clutter,
but with C instead of JavaScript. :) Using Clutter opens up a wide range
of different possibilities WRT how we construct our UI here. Having each
element of the interface as an actor on a Clutter stage in 3D space
could allow us to more easily allow change the UI based on context. As
an example, I found this video that shows GTK widgets working as actors
on a Clutter stage: http://www.vimeo.com/5126552 The client-side-window
branch of GTK that this functionality needs was merged to GTK master
some time ago, so it should be in the next stable GTK release.

 Alex (the author of the video) is right when he says that the sky is
the limit. Before I saw this I always thought Clutter and GNOME Shell
were nothing more than useless eye candy, but after having seen this I
think similar ideas might just work for us.

So, do you think this is a good idea? Is it worth exploring further?
Please, everybody, developers and average users alike, feel free to
comment.

Thanks,
James Liggett


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Hi!


> So, do you think this is a good idea? Is it worth exploring further?
> Please, everybody, developers and average users alike, feel free to
> comment.

I like the idea and I am looking forward to seeing some prototype. I am
not entirely sure if the use of clutter is necessary (and it means that
we depend on having OpenGL enabled for the user) but let's see.

Regards,
Johannes



------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi James,

James Liggett a écrit :
> But I honestly don't like what we have so far. Usually
> it comes down something to the effect of: We should have [features I use
> here] put in the top-level menu, and put everything else in submenus.
> But, there's one *big* problem with that: There is no one way to
> accomplish a great deal of things in git, so features that might be used
> frequently by one person might not be used at all by somebody else.

Well, I think we can find something better than we have now (as
everything is in submenus currently :)).


> So, do you think this is a good idea? Is it worth exploring further?
> Please, everybody, developers and average users alike, feel free to
> comment.

I see this as lots of work.

I'm a bit afraid to have an interfaces with buttons everywhere and menu
changing for unexpected reason. By example, I really don't like the
Windows menus where less used items disappear. It is difficult to know
what are all your possibilities and you cannot click on the menu item
without reading the text and checking it's the expected one. It doesn't
means that you need to limit to very simple things but if you have more
possibilities, it's probably more difficult to use them right.

Then, using more recent technology, normally means more computing power
and more recent libraries which limits the user base too. So, I don't
know if it's a good idea to use Clutter here.


Anyway, I think it's always useful to explore new things. We will see
how it looks like.

Regards,

Sébastien

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[James Liggett]

On Mon, 2009-09-21 at 09:47 +0200, Johannes Schmid wrote:
> I like the idea and I am looking forward to seeing some prototype. I am
> not entirely sure if the use of clutter is necessary (and it means that
> we depend on having OpenGL enabled for the user) but let's see.
Is there anything other than Clutter that would meet our needs? It seems
like that's the way things are going as far as GNOME UI's go...I don't
care for the idea of requiring OGL acceleration in Anjuta either, but
the little research I've done on Clutter makes me think it's the best
option we've got AFAIK. But I'm not exactly an expert at this stuff
either, so please don't be afraid to chime with alternatives if you know
of any.

James


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[James Liggett]

On Mon, 2009-09-21 at 19:59 +0200, Sébastien Granjoux wrote:
> I see this as lots of work.
You are most certainly correct Seb--Assuredly, I have no illusions about
what I'm getting into here. It will be lots of work, no question. ;)
>
> I'm a bit afraid to have an interfaces with buttons everywhere and menu
> changing for unexpected reason. By example, I really don't like the
> Windows menus where less used items disappear. It is difficult to know
> what are all your possibilities and you cannot click on the menu item
> without reading the text and checking it's the expected one. It doesn't
> means that you need to limit to very simple things but if you have more
> possibilities, it's probably more difficult to use them right.
To be clear, I'm not intending to hide anything. Every command would be
visible to the user in some way--It's just that the most used ones would
be the first ones you'd see; but if you look further down you should see
everything. I've yet to hash out the exact details though. I'm sure a
bit of trial and error will be necessary here; we'll just have to see
how it goes.
>
> Then, using more recent technology, normally means more computing power
> and more recent libraries which limits the user base too. So, I don't
> know if it's a good idea to use Clutter here.
I won't insist on using Clutter. If we can accomplish the goals I've set
forth without it, that would be great. But as of yet, it seems like
Clutter might be the easiest to work with. Like the rest of the idea,
this isn't set in stone.

And, remember that I'm just exploring the idea--The final product, if
there even is one at all, could be quite a bit different from what I've
initially laid out.

Thanks Johannes and Seb for your feddback. :)

James


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[James Liggett]

On Mon, 2009-09-21 at 18:04 -0700, James Liggett wrote:
> On Mon, 2009-09-21 at 09:47 +0200, Johannes Schmid wrote:
> > I like the idea and I am looking forward to seeing some prototype. I am
> > not entirely sure if the use of clutter is necessary (and it means that
> > we depend on having OpenGL enabled for the user) but let's see.
> Is there anything other than Clutter that would meet our needs? It seems
> like that's the way things are going as far as GNOME UI's go...I don't
Just for the record, I did run across GooCanvas while I was doing some
follow-up research for this idea. Does anybody have any experience with
that? Could it work better for us?

Thanks,
James


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Hi James!

Am Montag, den 21.09.2009, 20:40 -0700 schrieb James Liggett:

> On Mon, 2009-09-21 at 18:04 -0700, James Liggett wrote:
> > On Mon, 2009-09-21 at 09:47 +0200, Johannes Schmid wrote:
> > > I like the idea and I am looking forward to seeing some prototype. I am
> > > not entirely sure if the use of clutter is necessary (and it means that
> > > we depend on having OpenGL enabled for the user) but let's see.
> > Is there anything other than Clutter that would meet our needs? It seems
> > like that's the way things are going as far as GNOME UI's go...I don't
> Just for the record, I did run across GooCanvas while I was doing some
> follow-up research for this idea. Does anybody have any experience with
> that? Could it work better for us?

I am not entirely sure why you need something else than Gtk+ widgets for
it. You can also use gdl to bring the correct windows in front or play
with always-on-the front gtk+ windows. Only use Clutter if you really
need. GooCanvas is a canvas widget and it's not in the official GNOME
stack. I would be difficult to use it here.

Regards,
Johannes


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Massimo Cora']

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Sébastien Granjoux wrote:

>
> I'm a bit afraid to have an interfaces with buttons everywhere and menu
> changing for unexpected reason. By example, I really don't like the
> Windows menus where less used items disappear. It is difficult to know
> what are all your possibilities and you cannot click on the menu item
> without reading the text and checking it's the expected one. It doesn't
> means that you need to limit to very simple things but if you have more
> possibilities, it's probably more difficult to use them right.
>
> Then, using more recent technology, normally means more computing power
> and more recent libraries which limits the user base too. So, I don't
> know if it's a good idea to use Clutter here.
>

I agree with you here. While on a side I'd like to see some new cool
interfaces implemented in gnome programs, on the other one I fear that
they won't be as stable/maintained as we hope. It could be tricky to get
the right Clutter UI for every Anjuta's user. I'd probably prefer to see
how the Clutter (or Clutter like) thing is accepted/adopted inside gnome
before trying a new road.

I've another suggestion: why not try to come up with something like a
git-menu-editor so that every user can lay the menus how he feels better?
There'll be a default layout installed in system, but that can be
overridden by user prefs. I don't know if it's possible to change it on
the fly once plugin is loaded, but the menu is just an xml so it
shouldn't be that difficult.
If the menu editor is too much work we can ship defaults layouts
choosable by the user. I don't think there'll be N possibilities, but
2-3 could be enough. Think for instance to ident settings: there are few
major ones that are always used. Usually an user is too lazy to study a
new ident system to match his feelings and so he just relies on defaults.



regards,
Massimo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkq6eY8ACgkQcfVTgMRILk2GrQCeKcV83AV/7RvrA1Mu2dCFH+1X
/rQAnAkgCBWr+CGDG9xQ0/IEBxs8r/zL
=57yZ
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[James Liggett]

On Tue, 2009-09-22 at 09:43 +0200, Johannes Schmid wrote:
> > Just for the record, I did run across GooCanvas while I was doing some
> > follow-up research for this idea. Does anybody have any experience with
> > that? Could it work better for us?
>
> I am not entirely sure why you need something else than Gtk+ widgets for
> it. You can also use gdl to bring the correct windows in front or play
> with always-on-the front gtk+ windows. Only use Clutter if you really
> need. GooCanvas is a canvas widget and it's not in the official GNOME
> stack. I would be difficult to use it here.
On further thought, I think direct use of GDL might get me where I want
to go. I just have a few questions though: is it possible to do things
like allow the user to close panels, but not iconify them? Also, is it
possible to put docking tab buttons on the top instead of the bottom?

Thanks,
James



------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[James Liggett]

On Wed, 2009-09-23 at 21:40 +0200, Massimo Cora' wrote:

> > Then, using more recent technology, normally means more computing power
> > and more recent libraries which limits the user base too. So, I don't
> > know if it's a good idea to use Clutter here.
> >
>
> I agree with you here. While on a side I'd like to see some new cool
> interfaces implemented in gnome programs, on the other one I fear that
> they won't be as stable/maintained as we hope. It could be tricky to get
> the right Clutter UI for every Anjuta's user. I'd probably prefer to see
> how the Clutter (or Clutter like) thing is accepted/adopted inside gnome
> before trying a new road.

In light of these, and some other issues, I've decided to dump Clutter
altogether. I'm looking into something like GDL now (not the docks that
Anjuta already uses, but my own set.)

>
> I've another suggestion: why not try to come up with something like a
> git-menu-editor so that every user can lay the menus how he feels better?
> There'll be a default layout installed in system, but that can be
> overridden by user prefs. I don't know if it's possible to change it on
> the fly once plugin is loaded, but the menu is just an xml so it
> shouldn't be that difficult.
> If the menu editor is too much work we can ship defaults layouts
> choosable by the user. I don't think there'll be N possibilities, but
> 2-3 could be enough. Think for instance to ident settings: there are few
> major ones that are always used. Usually an user is too lazy to study a
> new ident system to match his feelings and so he just relies on defaults.

There's a few problems with that approach. Firstly, I proposed a similar
idea in another thread a few days ago. Reception to it seemed mixed at
best. And even if I tried to use some predefined layouts, it's possible
that we might still encounter the same problems we do now. Except that
it'll be people complaining about how the available presets don't quite
fit their needs. And then theres the issue of having to customize the
menu. Many users would probably see that as a lot of extra work that
they don't want to do.

So relax, any hard dependency on 3D acceleration is off the table. Give
me a bit of time and I'm sure you'll like what you see... :)

Thanks,
James


------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Massimo Cora']

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

>
> So relax, any hard dependency on 3D acceleration is off the table. Give
> me a bit of time and I'm sure you'll like what you see... :)
>


yeah I'm sure I will ;)

regards,
Massimo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkq89MkACgkQcfVTgMRILk0HywCfenciXGao+HysDoFS2lg+KNYl
3vQAn3AIyNNlJQfTQmbk87DWCrYypHVQ
=d2Vg
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel