Re: Icon theme changes

[John Stowers]

>
>
>
> The reason for this change is to make things more simple and reliable.
> With our current use, symbolic icons are simply not an optional add-on
> anymore, but an integral part of the user experience. By making it
> part of the single icon theme, we avoid a whole class of 'broken UX'
> cases that happen when somebody forgets to install or removes the
> symbolic icons.
>

Hey,

Some people (like myself...) were not happy with the deprecation of stock
icons last year. At that time it was stated that one can at least depend on
certain common icon(names) 'gtk-XXX' to be present and useful. Does this
merger imply a similar position with respect to the -symbolic versions?

If I am distributing a gtk application (for use not just withing GNOME)
which icons can I assume present?

John



>
> Matthias
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Python Docs (was Re: Coordination for developer documentations)

[John Stowers]

Simon and others,

With respect to PyGObject docs, I hope you are all aware of
http://lazka.github.io/pgi-docs/ and http://learngtk.org/

The first link is especially fantastic.

FWIW I also purchased www.pygobject.org a while ago and am wondering what
to do with it. My current plan is to consolidate all PyGObject / GI docs
there (maybe in a month or two when I am less busy).

John


On Sat, Mar 8, 2014 at 4:04 AM, Simon Feltman  wrote:

> On Fri, Mar 7, 2014 at 3:22 AM, Christoph Reiter
>  wrote:
> > On Thu, Mar 6, 2014 at 11:37 AM, Ekaterina Gerasimova
> >  wrote:
> >> On 6 March 2014 10:07, Christoph Reiter 
> wrote:
> >>> Since it wasn't mentioned so far; outside of gnome.org, on the Python
> >>> side of things, there exists the GTK+ 3 tutorial [0] maintained by
> >>> Sebastian Pölsterl (accepts pull requests, but isn't actively working
> >>> on it [1]) and the gi api reference [2], which I actively maintain.
> >>
> >> I have been using these recently and am very keen to see them on
> >> developer.gnome.org. There is a developer experience hackfest[3]
> >> coming up at the end of April which would be a perfect time to make
> >> that happen, is there any chance that you could make it?
> >
> > Sorry, can't make it, but I'm willing to help in that regard. I can
> > write up a project status/roadmap if that helps.
>
> That would be helpful. I think it would be nice to integrate your work
> (or abstracted parts of it) with pygobject itself.
>
> An idea that has been cooking in the back of my mind (and to a very
> small degree has been realized with pygobject's function signature
> docs) is to have pygobject handle documentation by filling out Python
> doc strings lazily when accessed. This would of course require
> developers to have either gir files installed or preferably devhelp
> could ship sgml (or mallard?) files which are accessible to tools
> outside of devhelp (or devhelp provides some sort of API if it doesn't
> already).
>
> I think the benefits to an approach like this could be fairly significant:
>
> * GI function argument interpretation for Python docs would be as
> close as possible to pygobject by having the argument translation code
> living in pygobject itself. Preferably we could expose pygobjects
> internal argument caches which already have all the translation logic
> applied and re-use this for the docstrings. This has the benefit of
> lowering maintenance cost by ensuring the documentation for function
> arguments is in lockstep with how pygobject actually works.
>
> * Overrides and Python specific API extensions would automatically be
> included in the docs.
>
> * Better developer workflow. By using Python doc strings, we
> automatically integrate with all of the awesome Python developer tools
> and things like doc tips in IDE's should just work.
>
> * Tools like Sphinx [1] could be used to generate html docs by
> pointing it at the "gi" Python package. In a similar vein, I realize
> Christoph's pgidocgen uses gir files translated to reStructuredText
> which is then run through Sphinx (please correct me if I'm wrong
> here).
>
> * By using Sphinx, we also get direct references back to the Python
> docs [2] for native Python constructs (as is realized with Christoph's
> docs, although I'm not sure if it is Sphinx or pgidocgen doing that).
>
> * We could integrate Sebastian's Python GTK+ tutorials which are
> written in reST by moving them into pygobject. Since GNOME projects
> are mirrored on github, I think they could still be pushed to
> readthedocs if we want that.
>
> * Testing of example code. Another possibility is to have Python
> specific versions of the developer doc examples living under a
> sub-folder of pygobject (preferably in Python's "doctest" format
> [3]). These could be pulled into the docs given the examples have some
> type of unique tag in the xml source. They could then be run as part
> of the pygobject test suite to ensure they are working Python.
>
> * Sphinx also seems to supports devhelp output (among other formats)
> which is interesting in that we might be able to achieve a similar
> look and feel with the rest of the GNOME developer docs.
>
> -Simon
>
> [1] http://sphinx-doc.org/man/sphinx-apidoc.html
> [2] http://docs.python.org/
> [3] http://docs.python.org/3/library/doctest.html
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Potential GNOME IDE

[John Stowers]

>
> It would be nice to have some GObject features, like completion of
> properties and signals names, with calltips to show details about a
> property or signal, and a button to add the callback function with the
> correct parameters.
>
> Also for handling the GObject boilerplate, like renaming a class and
> keeping a correct indentation with the GNOME conventions (also for
> lining up the function paramaters).
>

I know Christian Hergert has done a work on both those topics, I suggest he
be contacted to collaborate with sooner rather than later. I am sure he
will be grateful for the help.

John
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Fallback mode is going away - what now ?

[John Stowers]

On Fri, Nov 23, 2012 at 7:27 PM, Allan Day  wrote:
> Florian Müllner  wrote:
> ...
 The Tweak Tool shouldn't have anything to do with extensions. They are
 something that you install and run as a part of the system, not
 something to be "tweaked" via settings.
>>
>> While I agree with you that gnome-tweak-tool (and package managers
>> (*)) are not the right place for extension management, I don't think
>> this is much of a concern with the matter at hand - as I understand
>> it, extensions are merely an implementation detail here and not
>> exposed to the user (except that they should also appear separately on
>> extensions.gnome.org, so users don't have to switch their system over
>> entirely if they only care about one or two "tweaks"). As mentioned
>> briefly above, I'd still assume an implementation based on extensions
>> even if we are going for a separate session.
> ...
>> (*) not to mention an extension management extension - I wish I was kidding
>
> Yeah, we sorely need a way to locally enable/disable and uninstall
> extensions. This should be built into the core, somehow.

Really?

Because I have all that code written and sitting there in tweak-tool
and have held off enabling/presenting it for fear of stepping on the
toes of e.g.o and confusing everyone.

If you want me to put that into tweak-tool just ask.

BTW; this gets a bit messier if now we ship classic mode as a
collection of system-wide (i.e. package manager installed) extensions
instead of the user-only extensions aka e.g.o.

John


>
> Allan
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dropping fallback mode in 3.8

[John Stowers]

> advanced setting app is SLOW to react to clicks in the categories list (about 
> 2 to 3 seconds)
>

Meh, that is just my rubbish code*, not a statement by the GNOME that
you must buy a new computer.

Some combinations of bugs from you list might make things slower on
your hardware. Anecdotes here suggest they  don't do that for
everyone. Software is made of bugs, it will continue to be made of
bugs, and patches are always appreciated. It's a rude thing to say but
it is the world we choose to live in.

John

* http://git.gnome.org/browse/gnome-tweak-tool/tree/gtweak/tweakview.py#n90
(showing and hiding lots of widgets is probably not the nicest thing
to do here...)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Fallback mode is going away - what now ?

[John Stowers]

On Wed, 2012-11-21 at 09:56 -0500, Matthias Clasen wrote:
> 
> I don't think a separate session will work very well for this - for
> one thing, setting this up will require a number of settings to be
> tweaked (e.g. the one for the minimize button), and alternative
> sessions don't have the right infrastructure for that. The session
> chooser on the login screen is not the best designed part of the login
> experience either. And finally, if Ubuntu calls their pristine GNOME3
> session 'GNOME Classic', what would we call this one, "GNOME Classic
> Plus" ?! 

I'm open to including the enabling and configuration of this "GNOME
Classic" mode in tweak tool. Just provide me with some UI mockups etc.

related aside: can we please put include the user-theme extension in
this list, or possibly fold its functionality into gnome-shell proper.
It would be easier in tweak-tool if I could always assume it was there.

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME goal for 3.8: Python 3 -- impact for pygobject itself

[John Stowers]

On Mon, 2012-11-05 at 10:28 +0100, Martin Pitt wrote:
> Hello all,
> 
> Olav Vitters [2012-11-05 10:05 +0100]:
> > In the last release team meeting we've accepted the Python 3 porting
> > goal for GNOME 3.8.
> > https://live.gnome.org/GnomeGoals/Python3Porting
> > 
> > Meaning: During development phase of GNOME 3.8 (3.7.x) we will depend on
> > Python 3.
> 
> *applauds*

Can we also require that we continue to work with python 2.7 (at least
g-i and pygobject)?

Scientific computing users will be on python2.7 for at least a few more
years.

John

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.8 "feature": Drop or Fix Fallback Mode

[John Stowers]

>
> It'd be useful to know to what extent people would be affected if we
> stop supporting the fallback mode. For instance, last June, Antoine
> mentioned that llvmpipe support is not there yet on OpenBSD...

If fallback mode goes away I would like blocker importance placed on bugs like

https://bugzilla.gnome.org/show_bug.cgi?id=648156

(GNOME 3 refusing to start on a system with multiple X11 screens - now
thankfully fixed).

Maybe we need to clarify policy on regressions offered without replacement.

John
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Mirroring GNOME on github

[John Stowers]

>
> One of the modules that I develop (gnome-shell) has very strict code
> review policies. If we want a paper trail of reviews, the typical
> thing to do is to link to a Bugzilla bug in the commit message, which
> has patch review comments.
>
> How does that fit into our GitHub flow? Do I review a pull request,
> and link to it in the commit message? Again, that means that our
> workflow now depends on GitHub.

Maintainers are free to reject contributions if they are improperly
made for the project. Having a github mirror does not take away their
ability to do that (c.f. the Kernel model and forks on github).
Similarly, not all projects have the code review policies of
gnome-shell; I fear by thinking this is the case was we will cut of
our nose to spite our face, as they say.

Github is already a wild west of GNOME technology forks, and I believe
having an official presence there would allow us to take advantage of
those forks and to reduce fragmentation.

Beyond making things less messy than they are now, Github has its own
advantages too, as I mentioned (code search across all projects, etc).

Anyway, I think that is my case made now.

John
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Mirroring GNOME on github

[John Stowers]

>
> I'm just saying that we need maintainers to manually look at GitHub
> every once in a while for pull requests, and file a bug upstream or
> merge into the repo or something. Maintainers are already overworked,
> so I doubt they're going to do that.

See at end.

> The other alternative is telling everyone that files a pull request
> "this is not the appropriate mechanism for contributing back
> upstream",

This is Linus's position. I don't see it as a problem (although I
would replace 'appropriate' with 'preferred').

> even politely, is a turn-off. Are they going to make the
> effort to register at Bugzilla and learn how to use git-bz? I don't
> think so.

Probably not - that is my premise; they are using github because they
don't like/know the bz+git-bz workflow.

Would such a hypothetical contributor have bothered giving me the
laborious opportunity to reject his contribution if I had asked him to
go through bz first anyway?

If a contributor already has a github account, and a local git branch,
I can't honestly say that the most efficient way for him to contact me
is to install git-bz, magic it, set up a bz account, and magic the
diff into bugzilla. The magic is technically cool, I love git-bz, but
we are too inside the bubble to see that this is fcrazy for a moderate
newcomer (hello GSOC/GWOP)!

>
> But will the contributors forks and patches be respected? If we don't
> make an effort to upstream contributions from GitHub (which is manual
> effort), their time is wasted, and all we've done is put up a trap for
> potential contributors to fall into, where what they should have done
> was to file a bug and patch upstream.

I guess I replied above to this.

> It also means that we're maintaining two separate infrastructures --
> one on git.gnome.org, and one on GitHub. Fragmentation is never good.

Well Alberto can chime in here, but this should be automatic. We have
the metadata to route the branch/pull request mails to maintainers via
the doap files anyway.

We already have fragmentation on github, but because we are not a
canonical upstream there we cannot see the fragmentation via the
github network view.

John
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Mirroring GNOME on github

[John Stowers]

>>
>> Disadvantages
>> * Maintainers might see this is mandating them change their workflow.
>> I emphasize that github should be only a mirror, interaction and
>> merging should occur first on git.gnome.org
>
> This is a killer. There would just be forks of random GitHub
> repositories with patches, and people submitting pull requests, that
> are as effective as /dev/null. Slashdot writes that we're mirroring on
> GNOME, and the designers are the cabal again.
>
> if we want to mirror on GitHub, we need to have an active presence
> there. I don't know what that would mean.

I don't see how your second paragraph follows from your first (and the
cabal bit is just confusing).

I believe that the most important consideration is whether github will
attract more contributors to the project, and if so, whether the
benefit of such will be worth working with a non-free UI.

Would it be fair to say you acknowledge that it will attract more
contributors ("random[1] forks and patches") but on balance think it
will not be worth the non-free UI?

I'd quite like to have pull requests that I can ignore (or format into
a patch to merge)...

John

[1] s/random/GNOME/ (that is the point remember. we currently have
random forks there)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Mirroring GNOME on github

[John Stowers]

Hi,

I spoke about this with a few people at GUADEC, but I would like to
continue the discussion here.

Can we please mirror the GNOME repositories on github.org
(https://github.com/GNOME)?

Advantages
* Many many people already have forks of GNOME components there, if
GNOME was the parent of these clones then we could easily the
differences
* Github has a working code search
* Nice web UI including visual image diffs, branch diff browser,
commit browser, etc
* Allows maintainers see who is working on their project via
notification of forks and watchers
* Code search is approximately ∞ than google code search (RIP)
* In my experience cloning from github is faster than cloning from gnome.org
* Improved visibility, perception of openness, other marketing intangibles.

Disadvantages
* Maintainers might see this is mandating them change their workflow.
I emphasize that github should be only a mirror, interaction and
merging should occur first on git.gnome.org
* Github UI is not FOSS
* Work required to keep mirror up to date

Regarding the last point, Alberto Ruiz already has some scripts that
are manually run to update the mirror. A simple approach would be to
put these on the gnome servers and run them in the post commit hook.
However, Github already maintains mirrors for others
(https://github.com/mirrors). I would not be surprised if they could
do a similar thing for us if we ask.

Regards,

John
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Be respectful and considerate. A complaint.

[John Stowers]

>
> And here is the same feature, but at the window manager level (and for all
> the other apps too):
> http://andreasn.myownb3.com/temp/nau-side-by-side.png
>
> Same thing, just on a different level and now desktop-wide.

Not quite.

With split planes

select complex combination of files with ctrl -> right click -> move
to other pane. Unless this feature appears nautilus wide (right click
-> move to ) this represents a
usability loss for me.

John
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: taking features away (compact view removed from Nautilus)

[John Stowers]

On Sat, Jun 30, 2012 at 6:32 PM, Jasper St. Pierre
 wrote:
> It seems like the broken "labels beside icons" behavior should be
> treated as a bug in GtkIconView that should just be fixed.

Don't worry about it, the text beside icons bug was fixed by removing
the offending feature too.

http://git.gnome.org/browse/nautilus/commit/?id=6aac88928b1935c8e4f5c54a61935f05c57d740e

John
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing Photos

[John Stowers]

>
> The point is that we already use Tracker in GNOME (Documents and Boxes
> depend on it) and I don't see any reason for existing apps to stop
> using it and while we could compromise on some code-duplication, its
> certainly a big issue if there is two entities harvesting metadata
> from tons of photos on every GNOME installation.



Correct me if I am wrong, but I thought GNOME only depended on
tracker-store and not the indexer?

If GNOME now depends on the indexer, that is incredibly good news.
Perhaps this cycle we might get useful search in GNOME; in nautilus
and the shell at least

I have been using tracker happily for years to manage large
collections of papers and documents and could not live without it.

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Design in the open

[John Stowers]

> 
> So there are lots of ways that we can do design better as a community,
> and contributors on this list can all play a part in helping to make
> us to be even more successful in this regard. It will take actions as
> well as words to move forward, of course - if you want to help, or
> have your own ideas, just get in touch.

Many of your suggestions seem designed to address or avoid conflict, or
to convey design team decisions in a better manner. This is not the
source of my confusion nor my uncertainty in how to interact with the
design team.

In order to piece together the rationale or even the process for design
team decisions I currently browse commit logs on the gnome-design github
repo, and look at comments made when changing live.gnome.org pages. Some
of you tweet stuff, others scatter it on google+. You suggest even using
$some_new_webapp to better collaborate on designs.

While I cannot see the discussion and the evolution of design team
thought (even if I have the time to piece together all these sources of
information) all I see is a decision by decree when a live.gnome.org
page is created which describes the final design.

My suggestion is thus the same as it was the last time this thread was
raised - if the design team does not want to archive discussions on a
mailing list, may they please allow IRC logging on the gnome-design
channel. You can even be proactive and send email updates to ddl or
something.

Of course if the canonical way to interact with the design is to show up
on IRC at a specific hour then, IMO, you will lose contributors. I can
hack any time of night when I have the motivation and the free time. But
if I want to understand why the design team did something I have to...
trust them?

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Anyone interested in keeping pessulus alive?

[John Stowers]

>
> There was nothing really tricky in pessulus itself, except knowing which
> keys exist and finding how to present them (and even for that, I don't
> think we were doing such a great job :/).

There is plenty of code in gnome-tweak-tool for almost-autogenerating
a UI on top of gsettings keys.

If you wish to go down this route you are welcome to take the code from g-t-t*

John

* and share the wrath of many - 'auto generated UIs are evil!'
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v6)

[John Stowers]

> 
> Phoronix and any linux news orientated site would be _perfect_ for a
> Gnome survey! If gnome thinks otherwise then keep on living in that
> little perfect utopia world of gnome. Reality is way different. Gnome
> really seems to be living in some ideal small "everyone loves gnome"
> world where they can tap in sites with millions of unbiased users that
> all give unbiased objective feedback.. Wake up gnome, not gonna
> happen!

Read this: http://www.phoronix.com/scan.php?page=news_item&px=MTAwMjY
and ask that question again.

I think it confirms the worst suspicions of those questioning the
usefulness of this survey.

What actionable items or lessons do you see in those 'early results'.
There is no useful feedback there, all I see is fail and a black mark on
the reputation of phoronix.

Olav, I suggest you continue to moderate this thread. I predict nothing
good will come of it.

John




___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Confused about the release

[John Stowers]

On Wed, 2011-08-31 at 16:26 -0500, Federico Mena Quintero wrote:
> On Tue, 2011-08-30 at 15:24 -0400, Shaun McCance wrote:
> 
> > I noticed that we have Contacts, Documents, and Sushi in the
> > apps moduleset.
> 
> gnome-documents worries me because of its dependency on Tracker.
> 
> As far as I can tell, g-d is linked from
> https://live.gnome.org/ThreePointOne/Features/FindingAndReminding - to
> https://live.gnome.org/Design/Apps/Documents - which are just factual or
> planning pages, not discussion pages.  (FindingAndReminding is even
> marked "obsolete"! - what about the sublinks to Document-Centric Gnome?)

Personally I am overjoyed to see tracker finally get some use inside the
GNOME platform. I have been using it locally for years (and the stable
0.10.x series is great BTW) to manage large collections of papers and
documents. I was becoming rather disappointed with a sentiment that I
saw emerging in GNOME - "local documents are obsolete, its not worth
doing unless it is cloud cloud online cloud tweet".

I was worried we were neglecting a perfectly good solution (tracker)
while waiting for a perfect one (cloud cloud online cloud?).

IMO the tracker miner architecture looks to be able to accommodate
off-site content quite well (flickr, gdocs, etc miners). It looks like
Cosimo concluded the same thing.

I'm happy to see that the async search provider stuff got merged into
shell, so now we can have tracker and ZG extensions for search.

I agree it is sad that ZG has not been picked up here, and documents
seems to have silently replaced a lot of the document centric planning
and your work, but I will take this progress over no progress.

I hope this doesn't turn into another tracker/ZG thread of doom.

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: SweetTooth and Live Extension Enabling/Disabling

[John Stowers]

On Wed, 2011-08-24 at 14:00 -0400, Jasper St. Pierre wrote:
> Hey guys, it's Jasper.
> 
> Again, the last time I talked about SweetTooth, it was a month ago.
> I'm here to say that enabling/disabling of extensions has landed!

Congratulations!

I will get this into tweak-tool ASAP.

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: new jhbuild features: jhbuild sysdeps and partial_build = True

[John Stowers]

> In the latest jhbuild, when the "partial_build" key is set (the
> default) we explicitly look at what's installed on the system, and if
> they're new enough, omit them from the build list (unless you have
> built them before).

This doesn't currently work on non-packagekit system, such as Ubuntu. I created

https://bugzilla.gnome.org/show_bug.cgi?id=655546

Which allows jhbuild sysdeps to work-ish. I suspect a more complete
implementation using apt might be needed if one wants to install
system dependencies instead of just skipping them.

John
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On the Interaction with the design team

[John Stowers]

> As a foundation member and supporter of GNOME I don't even know myself 
> how to give a feedback that matters and join the hundreds unhappy 
> contributors with this decision (users spend hours looking at how they 
> can power off their machine, talk about good UX...), nor can I point 
> anyone to a method to give feedback that matters that would help to get 
> our voice heard.

Yip, this is exactly my position and I face the same dilemma.

I decided to just minimize [1] all my public open-source contribution
[2]. I don't know how to make things better in this new design-driven
world, so I will just settle for not making things worse.

I guess this is progress; GNOME3 is, on balance, certainly very good.

This email is not intended to be rude, nor taken badly. It is a
reflection of private correspondence I have had with other hackers who
might abstain from these contentious discussion on d-d-l for the reasons
cited above.

John

[1] gnome-tweak-tool, user-theme not withstanding. Those were my bridge
building exercises between the hypothetical 'power user' and the
hypothetical 'GNOME3 architects'.
[2] I just put stuff on github and never mention it...


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On the Interaction with the design team

[John Stowers]

On Mon, 2011-06-06 at 13:42 +0100, Allan Day wrote:
> Dave Neary wrote:
> > Hi,
> > 
> > 
> > So, in short, I would like the design team to act like the gnome-utils team.
> 
> GNOME design has all the equivalent facilities [1, 2, 3] excluding the
> mailing list.
> 
> Again, I agree (and have never disagreed) that we need to do better. The
> only question has been around the appropriateness of a mailing list.

Does this mean an IRC log/bot is back off the table?

I would be happy to read such logs not for accountability but because
it allows one to learn how the design process operates (like how reading
code can be useful as a programmer). It can also be more convenient for
people in stupid timezones (me).

John

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: systemd as external dependency

[John Stowers]

> Hey,
> 
> Could you give some details on what is the issue with running Ubuntu and
> contributing to GNOME? Several active GNOME contributors are running
> Ubuntu, do you means they are not welcome to contribute to GNOME because
> of the distribution they decided to use?

I'm not wading into this fight too deeply, nor am trying to take this
thread OT.

I am currently running the GNOME3 PPA on Ubuntu 10.04 and contributing
to GNOME [1]. It seems to work OK [2] now (but I am still wary of
upgrades). The main differences (excluding bugs) from upstream seem to
be
* No gnome-panel 3.0 (blocking on new e-d-s AIUI)
* Old Rhythmbox version that misses plugins
* Old evolution (as per e-d-s)

John

[1] Porting gnome-games/soduku + goocanvas to pygobject, maintaining
gnome-tweak-tool
[2] There was a few incidents where crashy g-s-d got through and would
only show me the fail whale and prevent login. There is also a g-s-d
race condition (that bites occasionally) in g-d-m where several g-s-d
instances are started and eat 100% of my CPU. I have lost the bug # for
this.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: "Open containing folder" for all apps

[John Stowers]

On Fri, 2011-05-13 at 10:05 +0100, Calum Benson wrote:
> On 11 May 2011, at 17:52, Federico Mena Quintero wrote:
> 
> > One detail of "Open if file manager" is that it is trivial to make apps
> > call "nautilus --blahblah", but ideally this should be cross-desktop
> > (and I imagine that Firefox and LibreOffice won't like to have
> > Gnome-specific stuff like that).  Maybe we need to add an option to
> > xdg-open(1)?

A few other thoughts on this, as I have noticed myself using the
following methods to map open files to the filesystem over the last
days. Some of these problems might be obsoleted by a more proper fix,
but nevertheless;

* I like not only being able to find the file in nautilus, but to copy
its path to the clipboard (for later pasting into a terminal)
* Many applications (nautilus, rhythmbox, evince, etc) have a
File->Properties type window that shows a location label/entry with the
full file path. Some standard widget for this case that has 'Copy path
to Clipboard' and/or 'Reveal in File Manager' may be useful.

John

p.s. IIRC nautilus now has a DBus interface that you can use to select
files, if the command line approach is not chosen.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: 3.2: gjs/seed

[John Stowers]

> String handling and containers are sort of limited lowlevel things
> though. I don't think anyone has a problem with using the language
> native versions of these. Especially since the gnome platform story on
> these are quite weak.
> 
> However, a platform like pyton is much richer. It contains many things
> that directly conflicts with our platform. Config APIs (gsettings), http
> support (soup), file handling and streams (gio), ssl support
> (glib-networking), etc. Isn't there even talk about a native python
> widget toolkit?

I don't think that is fair. I'm happy that I was able to do all these
things using the python standard library while waiting for the GNOME
libraries to catch up. Now that we have gio,gsettings,soup,json etc (and
g-i support) I will use them instead.

Almost every language lets you shoot yourself in the foot in a myriad of
ways but if the argument is that pythons failing - 'you might mistakenly
choose to use non/incompatible GNOME libraries' is bad, then I think
that is a weak argument.

Regards,

John



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Musings on the contacts user experience

[John Stowers]

On Thu, 2011-04-28 at 16:20 -0400, Matthias Clasen wrote:
> 
> I'm not sure we really want a separate people tab in the overview. I
> know it is tempting, now that we have these 'tabs', to just keep
> adding on there: places, documents, contacts, what have you... but I
> think it will lead to a clunky experience if we add a separate tab for
> each class of objects that we want to treat as important. Showing
> contacts (and documents, etc) in the search results on the other hand,
> seems like a very natural idea and makes a ton of sense. 

I'm already concerned with the performance of searching and display of
many items in the overview, so I hope this is implemented smartly.

I'm not sure if the delay is in rendering the icons, or in
walking/filtering the long list of candidate matches in JavaScript,
but I have many more contacts than I do applications.

Regards,

John

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New master.gnome.org

[John Stowers]

> I can describe what the script does somewhere. Only 'install' is
> interesting for maintainers. The rest is release-team stuff and more
> sysadmin related (ftpadmin validate-tarballs will validate all tarballs
> within a module.. going to rename that to validate-module).

[ can't find the mail describing the new features. Replying
  here instead. Sorry ]

>- Announcement mails are a bit nicer
>If you have a  in your DOAP, it is used. Falls back to
>shortdesc. It'll also use the name (so in the mail it'll use 'GNOME
>Shell instead of 'gnome-shell')

Does this mean we should no longer send announcement mails to the
announce list, that they will be done automatically?

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: empathy integration with the desktop

[John Stowers]

> 
> As a new user of gnome-shell when I installed the Fedora 15 Alpha, my
> first thought was that "Available" and "Busy" referred to my IM
> status, and there was nothing that indicated to me that they had
> anything to do with the notification system. I only made that
> connection from a stray reference on either this list or the
> gnome-shell mailing list. My guess is that a lot of users will make
> the same connection and be confused when those settings don't seem to
> do anything to their IM status (even assuming they knew that they had
> to start empathy to begin with).

Wow, totally agree. 

I have been testing the shell for months now and, embarrassingly, your
email is the first time I have heard that those items in the user menu
had any affect on notifications.

As an ex-ubuntu user I assumed they were similar to the me-menu and
adjusted IM presence only.

Without wishing to cast myself as representative, I think this needs to
be much clearer, not just for new users, but existing users who might be
used to Ubuntu / Unity.

> 
> >
> > Basically, mapping desktop status with IM status can be tricky. IIRC
> > Ubuntu used to automatically connect accounts when changing the presence
> > using their presence indicator and stopped doing so because loads of
> > users were wondering why their IM accounts were suddenly online.
> 
> I think a bigger issue with the ubuntu Me Menu is that in the initial
> state after login, the IM status menu items are desensitized, and
> empathy (just as unintuitively as in Alexander's use case) needs to be
> started from the messaging menu, which is two items away on the
> notification menu bar. In both cases, the proper behavior should not
> necessarily address the IM status at login, but actually making the
> menu items useful in adjusting that status. Even though I hardly ever
> use IM, I do try to remember to have it on when I am working from
> home, and I occasionally (maybe 3-4 times a month) chat with my wife
> when I am at the office and she's on the computer at home. That said,
> the task of muting and unmuting notifications seems to be a rather
> lower priority than setting online status, and I don't think that the
> current menu items communicate their purpose particularly well.

Agree. I too use IM infrequently and even in the Ubuntu case every time
I click on items in the me-menu I am unsure if it will sign me in, make
me online, take me out of invisible, or start empathy for me to do any
of those options.

The shell needs to communicate more clearly why clicking on these items
will do wrt. IM. Perhaps every click on these items could be via
starting/showing the empathy main window, if for no other reason to
introduce people to its existence.

John

> 
> Michael Knepher
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.2 ideas and plans

[John Stowers]

On Tue, 2011-03-22 at 10:02 -0400, Matthias Clasen wrote:
> With GNOME 3.0 going into code freeze any day now, it is high time
> that we start looking beyond 3.0 and start collecting ideas and making
> plans for what comes next. To that end, I have collected a list of
> things that have fallen off the 3.0 train at one point or another, as
> well as some other things that might be nice to put on the roadmap.
> Some of these have designs and/or working implementations, others or
> just ideas.
> 
> I'd like to encourage everybody to chime in with their own ideas and
> plans for GNOME 3.2.

How about a GtkMenuButton - so people can pack menus into a button if
they don't want a menubar in their application.

We are starting to see this trend a bit now, current examples are
Chrome/ium and Firefox (kinda), but it appears in the GNOME3 EOG mockups
too.

GtkMenuToolButton is close but AFAIK can't take sub-menus.

John

[1]
http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/eye%
20of%20gnome/menu.png


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no way to change theme or fonts in System Settings?

[John Stowers]

> Let me know when you have a bugzilla component. There's a number of
> control-center bugs that should be coming your way.

Done.

https://bugzilla.gnome.org/browse.cgi?product=gnome-tweak-tool

John (nervously awaiting bug onslaught...)

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no way to change theme or fonts in System Settings?

[John Stowers]

> 
> There'll be a tool for that, although that is an add-on tool (ie, not
> part of the control center). Since I've been lagging on this, John
> Stowers stepped up and moved much faster than I did (he also chose
> python while I was playing with js ;-)):
>  https://github.com/nzjrs/gnome-tweak-tool
> 
> (kudos to John!)
> 
> This needs some love, and we'll import that in git.gnome.org, I assume.
> But yeah, that's how we will deal with this :-)

I wanted to finish of a few more things, but this has been imported onto
the GNOME git now, and lives here;

http://git.gnome.org/browse/gnome-tweak-tool/
http://imgur.com/a/NmL44#By22E (screenshots)

It supports most of the contentious issues I saw people talking about,
and some extra niceties like gtk theme switching (only shows themes that
have gtk+-2 and gtk+-3 support), and shell theme switching +
installation (needs the usertheme extension from [1])

Adding 'tweaks' for new things is pretty easy, see tweaks/tweak_*.py for
examples.

Feedback appreciated.

Oh, and the new pygobject (+ gobject-introspection) is seven types of
awesome.

John

[1] http://git.gnome.org/browse/gnome-shell-extensions


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Jump Lists / Quick Lists / Dash Embellishments in GNOME 3

[John Stowers]

> Having jumplists in the shell overlay was desired by pretty much
> everybody, though it was not specified whether they would be
> implemented as right-click menus on application icons, or something
> else.
> 
> My takeaway from the session was that we would use a combination of
> static verbs (specified in .desktop) and dynamic actions (specified
> using GApplication actions) to build the "action list" in an
> application's jumplist *and* in the application menu in the top panel
> of the shell.  But after talking to Ryan Lortie later, it seemed that
> he and Owen preferred using GApplication actions only for the
> application menu, and that all actions in the jumplist would be
> specified using the .desktop file.

For my future reference, and for the Google, here is an example of doing
this dynamic GAction + GtkApplication business.

https://bugzilla.gnome.org/show_bug.cgi?id=637334#c12

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Jump Lists / Quick Lists / Dash Embellishments in GNOME 3

[John Stowers]

> My takeaway from the session was that we would use a combination of
> static verbs (specified in .desktop) and dynamic actions (specified
> using GApplication actions) to build the "action list" in an
> application's jumplist *and* in the application menu in the top panel
> of the shell.  But after talking to Ryan Lortie later, it seemed that
> he and Owen preferred using GApplication actions only for the
> application menu, and that all actions in the jumplist would be
> specified using the .desktop file.

As a follow up, I just noticed that this is the approach taken [1][2] by
Ubuntu.

John

[1] https://wiki.ubuntu.com/Unity/LauncherAPI
[2] https://bugzilla.gnome.org/show_bug.cgi?id=642567


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Jump Lists / Quick Lists / Dash Embellishments in GNOME 3

[John Stowers]

Hi All,

I see that Ubuntu has merged [1] their implementation of 'quick lists'
[2], and also offer ways to embellish their application launcher icons
with numbers and progress bars.

Is there a plan describing how these things might fit with gnome-shell
(or not)? [5] leaves this part unspecified.

As I understood it, quick lists were meant to be supported upstream via
exported GApplication actions [4], gtk offers GtkNumerableIcon [5] (but
nothing in the dash), and there is no progress bar equivalent. Is this a
correct summary, and is there a recommendation to application authors
how similar things might be done in GNOME3?

Regards,

John


[1] https://wiki.ubuntu.com/Unity/LauncherAPI
[2] AKA Windows 7 jump lists
[3] http://live.gnome.org/ThreePointZero/AppIntegration
[4] http://library.gnome.org/devel//gio/2.27/GApplication.html
[5] http://library.gnome.org/devel/gtk3/unstable/GtkNumerableIcon.html


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 in March 2011

[John Stowers]

On Sat, 2010-08-07 at 13:24 +0200, Tomeu Vizoso wrote:
> On Sat, Aug 7, 2010 at 12:20, John Stowers  
> wrote:
> > On Sat, 2010-08-07 at 11:12 +0200, Tomeu Vizoso wrote:
> >>
> >> Alternatively, if distros were able to support the combination
> >> Python2+Gtk2+PyGObjectWithIntrospection
> >
> > Just to be clear, do you mean that distributions will likely ship
> >
> > Python2+PyGtk2+(Gtk2-.gir)+(PyGobjectWithIntrospection+(Gtk3+.gir))
> >
> > next cycle? I.e. GObject introspection support should be disabled for
> > Gtk2 builds?
> 
> This is getting confusing ;)

Agree.

> 
> My understanding is that both Fedora 14 and Ubuntu Maverick will ship with:
> 
> - gobject-introspection
> - pygobject with introspection support

Good, but,

> - typelibs for gtk2
> - python 2.x
> 
> This means that authors of pygtk-based applications will be able to
> port their apps to introspection in those distros without having to
> build additional software.

I think this combination is not very useful. We are telling python
developers to port a pygtk app (that already works) to the new pygobject
gobject-introspection api, and all they will get is a slightly different
way of accessing the same gtk-2.X API, but likely also a new set of bugs
to deal with. That is not to say that pygobject+gobject introspection is
buggy, but surely it won't be perfect to start with.

I think a better story is to tell people that they should port their
pygtk apps to pygobject+gobject-introspection and then they get gtk-3
new features, new API, and ponies for free. 

This means I suggest typelibs for gtk-2 should not be built, they should
only be built for gtk-3. Distros will need to ship both gtk versions,
but I expect they will do that anyway (or gtk-2.90 snapshots at least).

> 
> If we told them to port their apps to Gtk3 and Python 3 ASAP, they
> would need to build stuff, so probably lots of people would wait 6
> months more to start porting. So most ported apps would start
> appearing in distros in +12 months.

I am not sure what implications the Python3 stuff would have.

John

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 in March 2011

[John Stowers]

On Sat, 2010-08-07 at 11:12 +0200, Tomeu Vizoso wrote:
> 
> Alternatively, if distros were able to support the combination
> Python2+Gtk2+PyGObjectWithIntrospection 

Just to be clear, do you mean that distributions will likely ship

Python2+PyGtk2+(Gtk2-.gir)+(PyGobjectWithIntrospection+(Gtk3+.gir))

next cycle? I.e. GObject introspection support should be disabled for
Gtk2 builds? 

John

> in the next release, most
> people could start porting to introspection during the next cycle,
> then porting to Python 3+Gtk 3 in the next one. 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 in March 2011

[John Stowers]

On Fri, 2010-07-30 at 01:00 +0200, Steve Frécinaux wrote:
> On 07/30/2010 12:39 AM, John Stowers wrote:
> > On Fri, 2010-07-30 at 00:32 +0200, Steve Frécinaux wrote:
> >> On 07/30/2010 12:28 AM, John Stowers wrote:
> >>> On Fri, 2010-07-30 at 00:23 +0200, Steve Frécinaux wrote:
> >>>> It's not as simple: you can't use pygtk and pygi at the same time in the
> >>>> same program.
> >>>
> >>> Is that still true if PyGtk+friends is built against Gtk-3.0 etc? That
> >>> is not my understanding.
> >>
> >> This has nothing to do with the Gtk version. It's merely that you can't
> >> have several C wrappers for the same gtype, so the first imported one
> >> wins. And they don't have exactly the same API. So if you use gtk.Window
> >> and Gtk.Frame, both will use the same GtkWidget wrapper, and it could be
> >> Gtk.Widget or gtk.Widget...
> >
> > I'm not suggesting mixing the bindings. No way.
> >
> > If a Python plugin only does "import pygtk,gedit (which pulls in the old
> > defs generated bindings [1])" then how does it clash with the gtypes
> > registered from gi (as AFAIK those are connected dynamically in the
> > 'from gi.repository import' hook)?
> 
> It's simple: plugins are in-process, and the limitation stands at the 
> interpretor level, so basically it's that a single process has to choose 
> between both wrappers.
> 
> If you do "import gtk" from plugin 1, the wrappers will be registered 
> and used when plugin 2 is loaded...

Ahh right, I forgot the per-process part. You are correct.

Can someone from Release Team or someone else suitable please write a
public service announcement to planet gnome, or gnome news or something
to explain this?

Something like "If you wrote a python plugin for GEdit/Rhythmbox/Totem
then you need to rewrite/fix it to use pygobject gobject-introspection
if you want it to work on GNOME 2.32 and GNOME 3.0"?

I would post something myself on pgo but I fear it would be interpreted
as a passive-agressive whine (because I don't maintain any of the
modules in question). Nevertheless I think it is something that needs to
be said publicly and loudly. Managing expectations is important if we
don't want a backlash against GNOME 3.0.

Furthermore, does the RT have a policy on API (and ABI where applicable)
guarantees for bindings/plugin APIs? I suspect with javascript seeing
more use in GNOME we might hit this sort of issue again (Seed vs. GJS
for example).

Regards,

John

p.s. How does this story work for nautilus (which will be built against
Gtk-3.0 I presume, but still only has defs generated bindings for
python. In that case they will need a pygtk built against 3.0, correct?)

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 in March 2011

[John Stowers]

On Fri, 2010-07-30 at 10:39 +1200, John Stowers wrote:
> On Fri, 2010-07-30 at 00:32 +0200, Steve Frécinaux wrote:
> > On 07/30/2010 12:28 AM, John Stowers wrote:
> > > On Fri, 2010-07-30 at 00:23 +0200, Steve Frécinaux wrote:
> > >> It's not as simple: you can't use pygtk and pygi at the same time in the
> > >> same program.
> > >
> > > Is that still true if PyGtk+friends is built against Gtk-3.0 etc? That
> > > is not my understanding.
> > 
> > This has nothing to do with the Gtk version. It's merely that you can't 
> > have several C wrappers for the same gtype, so the first imported one 
> > wins. And they don't have exactly the same API. So if you use gtk.Window 
> > and Gtk.Frame, both will use the same GtkWidget wrapper, and it could be 
> > Gtk.Widget or gtk.Widget...
> 
> I'm not suggesting mixing the bindings. No way.
> 
> If a Python plugin only does "import pygtk,gedit 
Bah, this should have read "import gedit,gtk" ^^^

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 in March 2011

[John Stowers]

On Fri, 2010-07-30 at 00:32 +0200, Steve Frécinaux wrote:
> On 07/30/2010 12:28 AM, John Stowers wrote:
> > On Fri, 2010-07-30 at 00:23 +0200, Steve Frécinaux wrote:
> >> It's not as simple: you can't use pygtk and pygi at the same time in the
> >> same program.
> >
> > Is that still true if PyGtk+friends is built against Gtk-3.0 etc? That
> > is not my understanding.
> 
> This has nothing to do with the Gtk version. It's merely that you can't 
> have several C wrappers for the same gtype, so the first imported one 
> wins. And they don't have exactly the same API. So if you use gtk.Window 
> and Gtk.Frame, both will use the same GtkWidget wrapper, and it could be 
> Gtk.Widget or gtk.Widget...

I'm not suggesting mixing the bindings. No way.

If a Python plugin only does "import pygtk,gedit (which pulls in the old
defs generated bindings [1])" then how does it clash with the gtypes
registered from gi (as AFAIK those are connected dynamically in the
'from gi.repository import' hook)?

> 
> >> Actually, I don't want to *write* those, and especially the required
> >> overrides.
> >
> > But the defs and the overrides, had already been written (for<  2.32?).
> > I am not suggesting adding defs and overrides of new API.
> 
> Not for libpeas. There has never been such def files.

[1] I was talking about, for example, the gedit and rhythmbox defs files
that lived in those modules.

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 in March 2011

[John Stowers]

On Fri, 2010-07-30 at 00:23 +0200, Steve Frécinaux wrote:
> On 07/30/2010 12:13 AM, John Stowers wrote:
> > I have no objection to that. My problem is that in the space of one
> > minor release, *every* python plugin for a gtk application (e.g [1]) has
> > skipped this 'dying' phase and move straight to 'dead'. That is not a
> > nice backwards compatibility story for python developers.
> >
> > I offer a third option. Plugins add 'pygtk.require(3.0)' [3] to their
> > code and libpeas support loading legacy plugins.
> 
> It's not as simple: you can't use pygtk and pygi at the same time in the 
> same program. 

Is that still true if PyGtk+friends is built against Gtk-3.0 etc? That
is not my understanding.

> So you would have to choose between running pygi-based 
> plugins or legacy pygtk ones. And those legacy plugins would require 
> some changes anyway: Gedit.WindowActivatable is not the same as 
> gedit.Plugin...
> 
> The only fix would be to allow running both at the same time, for 
> instance by reimplementing pygtk as a compatibility layer over pygi, but 
> then there would be no need for libpeas to support pygtk explicitely.
> 
> > You suggest that you do not want to maintain def files any more. Fair
> > enough, but I suspect that the C-api between the minor releases of these
> > apps would be retained (as is expected of C-apis). If the C-api has been
> > retained then what is the maintenance burden of keeping the defs file
> > around which describe this API?
> 
> Actually, I don't want to *write* those, and especially the required 
> overrides.

But the defs and the overrides, had already been written (for < 2.32?).
I am not suggesting adding defs and overrides of new API.

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 in March 2011

[John Stowers]

> >
> > Would you consider supporting non pygobject-g-i (i.e. traditional)
> > python plugins in libpeas if I finish the pygtk-3.0 stuff [1]?
> 
> The thing is, I don't really want to write pygtk-based bindings. The 
> goal is to allow application writers to *not* write bindings, and those 
> who use libpeas already use pygi anyway so how useful would it be?
> 
> Also, pygtk is supposed to be dying...

I have no objection to that. My problem is that in the space of one
minor release, *every* python plugin for a gtk application (e.g [1]) has
skipped this 'dying' phase and move straight to 'dead'. That is not a
nice backwards compatibility story for python developers.

I am not just concern trolling here, I regularly help people on the
pygtk list and I would estimate that very few people actually know what
is going on. Hell, take an example I just saw in google reader this
morning [2], that developer is going to wake up the morning after their
distro release and see his plugin fail to work - the most I expect he
will see is a note in the release notes that says "Rhythmbox now uses
libpeas for plugins". We need to think of a better backwards
compatibility story, or add a big heading to the top of [1] that says
"If you wrote a python plugin for GEdit/totem/Rhythmbox, it will not
work in GNOME 3.0 (and GNOME 2.32)"

I offer a third option. Plugins add 'pygtk.require(3.0)' [3] to their
code and libpeas support loading legacy plugins.

You suggest that you do not want to maintain def files any more. Fair
enough, but I suspect that the C-api between the minor releases of these
apps would be retained (as is expected of C-apis). If the C-api has been
retained then what is the maintenance burden of keeping the defs file
around which describe this API?

Regards,

John

[1] http://live.gnome.org/Gedit/Plugins#third_party
[2]
http://www.omgubuntu.co.uk/2010/07/fullscreen-rhythmbox-plug-in-your.html
[3] actually if pygtk.available(3.0): pygtk.require(3.0). I will
probably make it print a big "YOU SHOULD BE USING PYGOBJECT GI" to
stdout/stderr.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 in March 2011

[John Stowers]

On Thu, 2010-07-29 at 13:50 +0200, Steve Frécinaux wrote:
> On 07/29/2010 01:06 PM, Xavier Claessens wrote:
> >> Speaking about my modules, I will not accept any changes to make them
> >> work with GTK+ 2.x again, nor would I want people to waste their times
> >> doing that.
> >
> > Why? As I understand, GTK3's only advantage is to have GtkApplication,
> > which is being backported to 2.22, right? So I don't see why you can't
> > make a --enable-gtk3 switch in your modules. Empathy is doing that from
> > the beginning, and it works fine.
> 
> This is not so easy for some modules. Especially, those who rely on 
> bindings and have been working toward gobject-introspection support (as 
> gedit, totem and vinagre did, by supporting libpeas) must deal with the 
> fact that those new bindings (or at least, pygobject's g-i support, 
> which was the concern in gedit's case) won't see a 2.32 release.

Would you consider supporting non pygobject-g-i (i.e. traditional)
python plugins in libpeas if I finish the pygtk-3.0 stuff [1]?

John

[1]
http://mail.gnome.org/archives/gtk-devel-list/2010-July/msg00031.html

> 
> >> The 2.32 story is inexistent: "Hey, you have a couple of weeks to
> >> release something that you didn't plan for, and that didn't exist".
> >
> > If I understood, the story for 2.32 is the same than what we planned to
> > be 3.0 so far. Except:
> > 1) modules should release with the version '2.32' instead of '3.0'.
> > 2) gnome-shell won't be part of that release
> > 3) modules must build with GTK 2.22, with extra bonus if they also build
> > with 3.0.
> > 4) did I forgot something else?
> 
> - pygobject with g-i support won't be part of that release
> - dconf won't be part of that release
> => people won't spend time to strip those out of the modules that spent 
> consequent resources on embracing them.
> 
> I think the release-team goal here is not to force those into stripping 
> those 3.0-only bits, hence the agreement on the gedit plan to make just 
> another 2.30 release with some more fixes.
> 
> Regards,
> Steve Frécinaux
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90

[John Stowers]

>
> A separate but related issue is that unless somebody plans to update
> gtk-sharp, Tomboy may not be GTK3 compatible this cycle (I don't know
> off-hand what parts of gtk-sharp may be incompatible with GTK3).  Do
> other non-C apps have similar issues, or is this just a problem with
> the Mono bindings?

AFAIK (and please correct me if I am wrong), but the story is the same
for PyGtk; it builds against Gtk-2.0 and not 3.0.

 * What does this mean for Python apps and GNOME 3.0 / 2.31

There is also the case of apps like Rhythmbox, Totem, Gedit, that
support PyGtk plugins

 * Will these apps lose plugin support this cycle?

John
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Platform for Developer Documentation

[John Stowers]

> 
> I'm growing a bit sick of GNOME having to be in this "limbo" situation
> where it can't stick to any technology because downstream
> distributions choose not to ship some components by default.
> 
> PackageKit and PulseAudio are two projects that are pretty well
> aligned with the GNOME platform in terms of API technology and goals,
> they solve hard problems to solve, they don't have any real contenders
> (yes they have problems, but if we wait until they are perfect, we
> will never have a platform).

Forgive me if I misrepresent Lennart here, but I thought the PulseAudio
policy [1] was "use GStreamer, libcanberra or ALSA (if you know what you
are doing)", and then PulseAudio will keep out of your way. 

Therefore, for the purposes of this list, having GStreamer and Canberra
present is sufficient.

John

[1] http://0pointer.de/blog/projects/guide-to-sound-apis.html


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3 cleanup status update

[John Stowers]

> 
> Manpower issues aside, PyGObject should be the only Python Bindings
> package in GNOME 3.  I think everyone agrees with this (right?).  We
> are discussing real-life practical issues, but we shouldn't lose sight
> of the ultimate goal.

Can anyone estimate how API compatible pygi+gtk will be with pygtk?

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: tracker

[John Stowers]

On Wed, 2009-10-28 at 20:04 -0700, Sriram Ramkrishna wrote:
> I think I'm with Zeeshan here.  It looks like you should have some
> time to get some real world testing before putting it into the
> release.  Do you guys have objection to that?

Correct me if I am wrong, but isn't tracker 0.7 being shipped in maemo
5? That seems like a pretty significant real world test case.

John



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

ChangeLog generation and git

[John Stowers]

Hi All,

I am converting my projects to auto-generate ChangeLog at dist time.
Looking at various GNOME modules, I cannot see a consensus on the
correct way to do this. Some projects simply do 

$git log > ChangeLog

while other use custom scripts [1]. Is there recommended way to do this?
Could some module maintainers please point me at the method they are
most proud of?

I will collect my findings and post on live.gnome.org when done.

Regards

John

[1]
http://github.com/cryos/avogadro/blob/master/scripts/gitlog2changelog.py

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GlobalMenu Application for inclusion as a GNOME module

[John Stowers]

On Thu, 2009-09-03 at 00:40 +0200, Pierre Slamich wrote:
> Dear GNOME maintainers,
> 
> This is a proposal on behalf of the GlobalMenu developers for its
> inclusion either in gnome-applets or as a dependency of GNOME.

+1 from me, I use this daily, and it works wonderfully.

While some might argue that the GTK_MODULES implementation is hacky it
works well in practice.

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: libdmapsharing

[John Stowers]

On Sat, 2009-06-27 at 00:27 +0200, Andre Klapper wrote:
> Hi Mike,
> 
> thanks for your interest in making libdmapsharing an official part of
> GNOME (though the proposal deadline for 2.28 has already passed).
> 
> Am Freitag, den 26.06.2009, 16:08 -0400 schrieb W. Michael Petullo:
> > Purpose:
> > libdmapsharing is a library to access and share DMAP (DAAP & DPAP)
> > content. This library is written in C using GObject and libsoup. The DMAP
> > family of protocols are used by products such as iTunes, iPhoto and the
> > Roku SoundBridge family to share content such as music and photos.
> 
> I wonder if this may interfere with other existing projects, e.g.
> Conduit? (Though Conduit has not seen a release since 21-Oct-2008 so I
> wonder how active the development currently is.)

No conflict with Conduit here.

Development is still active, unfortunately I have been slack at
releases. Having a Ubuntu PPA has made me lazy.

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposing libgdata as a new desktop module

[John Stowers]

> 
> * if it isn't going to spread beyond google (or we have no reason to
> believe so, at any rate) is there a reason to think that google is
> special/important enough that we should compromise our values here? Is
> there a good tactical reason for it? (I'd say that this, roughly, is
> our relationship to SMB.) (There may be; I'm open to that possibility
> but don't see it argued for yet.)
> 
> * alternately, are there ways to make this more general and support
> alternatives? In other words, should this be a general purpose
> web-data library (perhaps an atompub library?) in which gdata is but
> one mode? Should it be integrated with some other, pre-existing
> network connection or data protocol library?

This is one of the main goals of Conduit, and was the central theme of 
my talk at Guadec.

We sit between $APP and many services and present a consistent get/put
API for storing and retrieving data from them. Sync is only one consumer
of this get/put API. Photo upload to n services from within EOG is
another user of this

Of course, we then have the lowest common denominator problem, but we
live in an imperfect world.

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposing libchamplain as an external dependancy for GNOME 2.28

[John Stowers]

On Thu, May 7, 2009 at 12:01 PM, Christian Persch  wrote:

> Hi;
>
> John Stowers wrote:
> > Unfortunately, the original TangoGPS author, [...], ignores any
> > emails from me, other osm-gps-map developers, or users, that request
> > permission to change the license of osm-gps-map to LGPL.
> >
> > I guess the lesson here is to never create a library, derived from a
> > GPL project, unless you are sure that the original copy write holders
> > are open to re-licensing those parts of the code to LGPL, aka mature
> > and reasonable people.
>
> There are good reasons to choose GPL even for a library[1]. The
> code's author not agreeing to relicense his GPL'd code under LGPL does
> not give you permission to insult him as ›unreasonable‹ or ›immature‹
> like you did above.
>
> I think just ignoring such relicencing requests is perfectly
> fine behaviour, esp. if, as you seem to imply above, multiple
> persons have pestered the author about it.


About 6-10 emails over 12 months is not really pestering either. I can
assure you that I was polite in all my emails, and also had contact with the
author early in the project, keeping him in the loop with some design
decions, asking for his opinion, etc. It was only when the issue of license
arose that the ignoring started. I did not just turn up and say "hey I
forked your project, you should relicense it".

I do not believe that ignoring a polite request for considering a licensing
change is a mature response.

Anyway, this thread is OT now.

John



>
>
>
>Christian
>
> [1] http://www.gnu.org/licenses/why-not-lgpl.html
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposing libchamplain as an external dependancy for GNOME 2.28

[John Stowers]

> > 
> > * It is good to see you have added support for specifying map uri's. I
> > would also like to see you support quadtree encoding, and
> > randomization of hosts. See osm-gps-map for what I mean...
> 
> I will have a look, but little code can be shared as osm-gps-map is
> GPL :) but if the method is generic enough method I'll see how to
> reproduce it.

Tell me about it. 

osm-gps-map was originally created out of TangoGPS [1]. I forked the
code, made it into a library, and have been improving it ever since.

Unfortunately, the original TangoGPS author, Marcus Bauer, ignores any
emails from me, other osm-gps-map developers, or users, that request
permission to change the license of osm-gps-map to LGPL.

I guess the lesson here is to never create a library, derived from a GPL
project, unless you are sure that the original copy write holders are
open to re-licensing those parts of the code to LGPL, aka mature and
reasonable people.

So good luck with libchamplain, and I am genuinely sorry that I cannot
contribute any code from osm-gps-map to it.

Regards

John

[1] http://www.tangogps.org

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposing libchamplain as an external dependancy for GNOME 2.28

[John Stowers]

On Mon, 2009-05-04 at 22:37 -0400, Pierre-Luc Beaudoin wrote:
> Hi,
> 
> I would like to propose libchamplain as an external dependency to GNOME
> 2.28.  If you never heard about this project, it is a Clutter based map
> widget for your application.  It currently uses downloaded image tiles
> as map data but there is a Google Summer of Code project to render the
> tiles locally.  More information available at: 
> http://projects.gnome.org/libchamplain

Hi

As the maintainer of osm-gps-map [1], a non-clutter mapping library with
comparable features, I support libchamplain's proposal.

I do not intend to add clutter support to osm-gps-map, it will remain a
Gdk/Cairo only library as its intended, and my current, use of it is on
embedded devices with no OpenGl support. Clutter is the new cool, so I
support all ways to get this into the platform.

However, looking over the libchamplain API (quickly, sorry if I
mis-characterize something) I have a few comments

* It is good to see you have added support for specifying map uri's. I
would also like to see you support quadtree encoding, and randomization
of hosts. See osm-gps-map for what I mean...
* Where is the simple API? It seems like quite a few lines of code are
required to get something to show. In osm-gps-map one can write

map = osm_gps_map_new() 

or

map = g_object_new (OSM_TYPE_GPS_MAP,
   "repo-uri","http://www.bla.com,
   "tile-cache",cachedir,
   "tile-cache-is-full-path",TRUE,
   "proxy-uri",g_getenv("http_proxy"),
   NULL);

and they are done. If this sort of scheme is not possible because
libchamplain returns a Clutter actor, what about adding a call

map = libchamplain_new_gtk_widget(xxx)

Which at least returns the widget wrapped already setup in a Gtk+
widget. Is this possible or does that add some dependecy to clutter-gtk?

* What is the sqlite dependecy for? Cache? Did you feel that using a
database for cache was a performance benefit? In osm-gps-map we use an
in memory cache of the last N tiles + a border around what is already
showing, and just load the rest of the tiles from disk. Performance of
that approach is more than sufficient (on any of the embedded targets I
have tried, for example)

Regards

John

[1] http://nzjrs.github.com/osm-gps-map/


> 
> Libchamplain 0.3 (a development release) has just been released.  A 0.4
> stable release will be made before or in sync with GNOME 2.28.
> libchamplain follows Clutter numbering and API/ABI stability plan.
> Since it is a young project, errors in the API are corrected in the next
> even release until maturity is achieved and 1.0 is released.
> 
> Libchamplain would not introduce any new dependencies.  It currently
> depends on Clutter 0.8 but will be ported to Clutter 1.0 as soon as it
> is announced. Or depandancies include: libsoup(-gnome), cairo, sqlite
> and Gtk+.  It doesn't depend on deprecated libraries for Gnome 3.0.
> 
> libchamplain already use a lot of the GNOME infrastructure: bugzilla,
> mailing list, wiki and web hosting.  Migrating the git repository from
> gitorious to git.gnome.org is planned. Releases are stored on
> libchamplain.pierlux.com for now but it is also planned to move to
> GNOME.
> 
> libchamplain is already used by an EOG-plugin to display where an image
> has been taken.  There are pending branches for Empathy (being reviewed,
> to be optionally available for 2.28) to display a map of where your
> contacts are.  There is also an embryonic plug-in for F-Spot.  Other
> non-GNOME applications are using it too but none have made releases
> using it so far.
> 
> libchamplain has bindings for Perl, Python, C# and C++.  You can find
> packages (or work has started) on Debian, Ubuntu, Gentoo, ArchLinux,
> RedHat and OpenSuse. There is a port to FreeBSD.
> 
> While libchamplain isn't integrated with any of the GNOME sub-projects,
> it shouldn't feel alien to them either.  There is little i18n to be
> done, no user documentation needed and I bugtriage myself.  There has
> been some talk about A11y, but these plans will have to wait until the
> SoC is over. Developer documentation is very important and that's why a
> full API reference is available:
> http://libchamplain.pierlux.com/doc/unstable/
> 
> libchamplain would contribute to improve the User Experience desired in
> GNOME 3.0 by bringing blingy map information to the desktop.  Teamed
> with GeoClue you get a geolocation framework to build tomorrow's
> location aware applications.  7 SoC projects were submitted in regard to
> geolocation in GNOME this year only (2 were accepted, 5 were releated
> directly to libchamplain).
> 
> libchamplain is available under LGPL 2.1.
> 
> The project started in August 2008 and has enjoyed a nice growth since.
> There is a good community starting to build on the IRC channel and we
> can count 16 different contributors to the code. See
> https://www.ohloh.net/p/

Re: On autogenerated ChangeLog

[John Stowers]

On Sat, 2009-04-18 at 22:23 -0400, Tristan Van Berkom wrote:
> On Sat, Apr 18, 2009 at 9:54 PM, Behdad Esfahbod  wrote:
> > Hey,
> >
> > I first wrote Makefile.am magic for Pango to generate ChangeLog from git on
> > demand.  Those macros have been modified and gathered in
> > http://live.gnome.org/Git/ChangeLog to only generate ChangeLog for "make
> > dist".  I wonder what people actually want to have, so I can work on
> > canonical macros to copy across projects (and eventually find a better way
> > to distribute).  Pros and cons:
> >
> 
> Personally, I prefer maintaining an actual revisioned ChangeLog file, simply
> because I like having the ChangeLog as a part of the project data, revisioning
> tools come and go, projects get exported and imported, but the ChangeLog
> always remains in the repository or published tarball.

I recall someone once mentioning (excuse my butchering the correct 
terms) a git merge strategy that makes it easier to
maintain a ChangeLog and not have to fight with it when merging 
branches.

Who was that person, and can they please attach the information
to http://live.gnome.org/Git/ChangeLog

Thanks

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Metacity, Mutter, GNOME Shell, GNOME-2.28

[John Stowers]

On Mon, 2009-03-23 at 17:11 -0400, Owen Taylor wrote:
> On Mon, 2009-03-23 at 17:02 -0400, Colin Walters wrote:
> > On Mon, Mar 23, 2009 at 4:41 PM, Owen Taylor  wrote:
> > >
> > > 2) Mutter could be renamed as a project to mutter (binary, GConf schemas,
> > > etc. Presumably, the internals would stay Meta*) and imported into GNOME
> > > version control independently of metacity. The uncomposited and RENDER
> > > code paths would gradually be removed leaving just a Clutter based WM/CM.
> > > The main disadvantage of this approach is that any ongoing maintenance
> > > of Metacity would not feed from or to this project automatically.
> > 
> > I'd like to toss in here:
> > 
> > 4)
> >  o Import "mutter" as a "branch" of metacity
> >  o When built, it installs its binary by default by default as
> > "metacity-compositor"
> >  o We share a common GConf schema subset (even if e.g. compositor has
> > a few more keys)
> >  o We share the bugzilla name "metacity"
> >  o Replay some of the non-compositing changes like GObject-ification
> > and introspection support on to mainline to reduce the divergence
> > 
> > There are some tradeoffs here, but I'd like to avoid creating a
> > distinct mutter "brand" and forking the GConf keys, even if the
> > display technology is changing a lot.
> 
> A branch in the (future) Metacity git repository is an interesting idea,
> in that it allows changes to be moved somewhat more conveniently between
> the trees.
> 
> But it could also be confusing, and unless you are going to keep on
> merging Metacity wholesale into mutter, there's not a big advantage in
> having them in the same repository. 'git cherry-pick' has no special
> intelligence over just applying a patch.

I am sure there will be users that do not like the change in mental
model gnome-shell will bring. It would be a shame if those users missed
out on the improvements to Metacity (aka mutter).

I think whatever development model allows Metacity to ship with a
clutter based compositing backend, or an alternative metacity-clutter
binary would be best.

John

> How would you see packaging and installation working with your scheme?
> I don't see how different programs (metacity and metacity-clutter) could
> share the same GConf schema keys.
> 
> - Owen
> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: SoC 2009 Ideas List Officially Triaged (New Untriaged Ideas still accepted until Monday)

[John Stowers]

On Sat, 2009-03-21 at 08:49 -0700, Sandy Armstrong wrote:
> Hi all,
> 
> I just wanted to briefly mention that the triage committee has finished 
> sorting community-proposed SoC ideas into categories on:
> 
> http://live.gnome.org/SummerOfCode2009/Ideas
> 
> The student proposal period begins Monday, so if you have a new idea to 
> add between now and then, please add it to the "New Untriaged Ideas" 
> section, and the committee will decide how to categorize it.  We are 

Hi,

What is the reason for the Conduit idea that I was prepared to mentor
being removed from the list?

Can I add it back into the "New Untriaged Ideas" section?

John

> mostly interested in ideas with a mentor already attached. :-)
> 
> Students: keep in mind that you may propose any idea you like, even if 
> it is not on the list.  With the proper attention to detail, even an 
> "Underground" idea can lead to a "Rockstar" proposal.
> 
> Enjoy your weekend,
> Sandy
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gobject-introspection, gir-repository and gjs moved to git

[John Stowers]

On Wed, 2009-02-11 at 17:25 -0200, Johan Dahlin wrote:
> gobject-introspection, gir-repository and gjs were today moved over to git.
> The old svn repositories will still work, but only in read-only mode.

Does this mean the GNOME move to git is complete and the git
repositories are now writeable and persistent?

I have been following the gnome-infrastructure mailing list, but there
has been no status update regarding the migration for a few weeks.

John

> 
> You can now check them out by doing:
> 
>   git clone ssh://@git.gnome.org/git/
> 
> or, if you don't have an account on gnome.org:
> 
>   git clone git://git.gnome.org/
> 
> Thanks to Owen Taylor and Kristian Høgsberg for helping us converting
> the repositories.
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Following GNOME Development

[John Stowers]

Hey,

Some of you might be interested in a little distraction I hacked on over the
last few weekends. It is basically a small PyGtk GUI to track GNOME
development, kind of like GNOME commit digest [1], but generated on demand.
The tool also includes some other useful information such as the changes to
a project NEWS or ChangeLog files, and bugzilla patches over the last N
days. You can find more information at

http://github.com/nzjrs/gnome-svn-commits-monitor/tree/master

John

[1] http://blogs.gnome.org/commitdigest/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Main Menu mockup

[John Stowers]

On Wed, Nov 5, 2008 at 11:57 AM, Matthew McGowan <
[EMAIL PROTECTED]> wrote:

> Hello gnome desktop developers,
>
> Apologies if this is the wrong forum for such an email.
>
> I have seen a fair bit of discussion about usability ideas for Gnome 3.
>  Going by a post on planet.gnome.org, the current thinking as far as
> desktop interaction[1] seems to involve some kind of multi-functional
> left-sided panel.
> Inspired by recent discussions and a few other applications such as Opera
> and Adobe Acrobat 8, i decided to have a go at developing some of my own
> ideas and add them to the mix.  I used Clutter and python to do so as these
> tools offer a relatively easy way of layering images and cairo textures
> whilst at the same time Clutter allowed me to provide some degree of
> interactivity (which further demonstrates ideas).
>
> You can get my main menu mockup/prototype from here:
> http://dl.getdropbox.com/u/123544/main-menu-mockup.tar.gz
>
> To run my mockup you need clutter 0.8 and pyclutter installed.
>
> My main menu mockup, i believe, offers more functionality than existing
> main menus... though i guess it is similar to the Novells Slab menu and
> Vista's Start menu(?).  It would provide a single location for browsing
> applications, friends/contacts, places, deskbar-like search, document
> history, logout options and system preferences & administration.
>
> I believe many users would be somewhat familiar with the paradigm i offer
> as there are precedents in the software world, Adobe Acrobat 8, Opera, Slab,
> and Vista start menu and the likes of web browsers and Banshee which
> implement similar UI ideas (with regard to panel-type interfaces which
> expose application functionality).
>
> I am no coder and i don't really know how buggy/attractive the code is, it
> runs fine on my Ubuntu 8.10 system... the main threat is missing icons, but
> i think it should handle the absence of icons gracefully...


Hmm, not so much for me (debian unstable)...

Traceback (most recent call last):
  File "mocker.py", line 986, in 
mocker.build_mockup( Stage )
  File "mocker.py", line 57, in build_mockup
content=ExitContent()
  File "mocker.py", line 404, in __init__
padding=10
  File "mocker.py", line 819, in __init__
Widget.__init__(self, w, h, Style.button)
TypeError: __init__() takes exactly 7 arguments (4 given)

John


>
> Hopefully some of you will look at my mockup and provide some feedback or
> maybe develop some of the ideas.
>
>
> Regards,
> Matthew McGowan
>
> _
> [1] http://live.gnome.org/Boston2008/GUIHackfest/WindowManagementAndMore
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Prototyping the next generation panel?

[John Stowers]

2008/10/28 Johannes Schmid <[EMAIL PROTECTED]>

> Hi!
>
> So after I finally got to read
> http://live.gnome.org/Boston2008/GUIHackfest/WindowManagementAndMore and
> vuntz blogpost I was wondering if there is already a place where the
> prototyping of the new panel is happening. I guess quite some people
> would be interested. (And I would also love if we would use some faster
> prototyping language then C and if we intend to use clutter or
> whatever...)


Have a talk with Neil Patel about avant window navigator.

I understand that he is currently working on refactoring AWN such that it
becomes more like a panel, less like a dock, but I am sure that he can
explain that a lot better than I.

Personally I would not be sad if AWN were to replace gnome-panel all
together (in the default install), but thats a story for another day.

John


>
> Thanks and regards,
> Johannes
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GSD should not housekeep the thumbnails

[John Stowers]

On Tue, 2008-09-23 at 13:31 -0700, Bastien Nocera wrote:
> On Tue, 2008-09-23 at 21:04 +0200, John Stowers wrote:
> 
> > There is also epeg, from Enlightenment, and I quote them, an
> "IMMENSELY
> > FAST JPEG thumbnailer library API."
> 
> Which seems to be very deprecated:
> http://trac.enlightenment.org/e/changeset/35550

Or incorporated into EVAS because it was good...

> And used libjpeg anyway:
> http://trac.enlightenment.org/e/browser/trunk/OLD/epeg/configure.in#L35

Well according to the docs it actually only used libjpeg for extraction
of the DCT coeffs, and not for decoding of the jpeg wholesale

John

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GSD should not housekeep the thumbnails

[John Stowers]

On Mon, 2008-09-22 at 22:41 -0400, Matthias Clasen wrote:
> 2008/9/22 Ted Gould <[EMAIL PROTECTED]>:
> > On Mon, 2008-09-22 at 18:19 -0500, Federico Mena Quintero wrote:
> >> JPEG loading with libjpeg is currently really slow (the benchmark being
> >> Photoshop, which is really goddamn fast for JPEGs).
> >>
> >> We could totally use some liboil/profiling ninjas to work on libjpeg to
> >> make it faster.  Then, maybe thumbnailing on-the-fly wouldn't be
> >> painful.
> >
> > That sounds like a GREAT SoC/Senior Project/etc. assignment.
> > Verifiable, measurable, contained and useful!
> 
> IIRC, David Schleef has some fast jpeg decoding routines lying around
> somewhere...

There is also epeg, from Enlightenment, and I quote them, an "IMMENSELY
FAST JPEG thumbnailer library API."

Docs:
http://docs.enlightenment.org/api/epeg/

Example:
http://systhread.net/texts/200507epeg1.php

> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

On Thu, 2008-07-31 at 14:36 +0200, Patryk Zawadzki wrote:
> On Thu, Jul 31, 2008 at 2:01 PM, John Stowers
> <[EMAIL PROTECTED]> wrote:
> > I don't know If I agree with the icon being in system/preferences
> > however, for two reasons.
> >
> > * If/when a future, improved UI appears, it will probably live in
> > accessories, so why confuse existing conduit users with two moves, once
> > -> system, and once back to accessories.
> > * The system/prefs menus are already very cluttered, often with items
> > that are neither system related, nor preferences, and often its not
> > clear which menu they should belong in.
> 
> Uhm, if apps are supposed to manage their synchronization via API
> callouts then doesn't the UI really belong to the preferences? Like
> System → Preferences → Synchronization or something. I can't see how
> it's different from libgda's DB access properties or from PolicyKit's
> authorization editor.

I would say the UI is a necessary evil, during the transition, until
more applications utilize the Conduit DBus interface. Justification;

There are many synchronization options Conduit provides, that while
can/should be managed over DBus, are currently not. For example;
 * Anything to do with Tomboy (direct network sync, to usb key/folder
type locations, to ipod notes, etc)
 * Anything to do with evolution and PIM. Although we are working on
other UI concepts for the evolution/PIM case
 * etc

There are also many sync options, that I believe, do not make sense when
managed from another application. From what application, or in what way,
could you manage;
 * RSS/Podcast type sync, photostream to iPod, Youtube to iPod, etc
 * Our network sync functionality, where anything can be synced to
another PC on the local network
 * Folder/Folder sync, USB key insertion, and backup type scenarios (UI
hooks in Nautilus are very limited)
 * Desktop prefs sync

I dont wish to keep repeating this finer point, but there is quite a
distance between what I believe apps should be doing (via DBus), and
what it is currently done. That divide is filled by the Conduit UI, and
we have many users who utilise the UI to do this, both for the scenarios
I outlined above, and countless others. Removing the UI would remove
this functionality from these users.

Team Conduit has worked very hard to integrate with applications where
it makes sense, by writing plugins for EOG, Totem and Nautilus, as well
as expanding the DBus interfaces of many GNOME desktop applications. It
is impractical to require we patch every application we wish to sync
with before we can be admitted to GNOME.

In summary, the current UI is improving, we are working very hard at it,
so removing it all together seems a bit like tossing the baby out with
the bathwater.

Regards,

John

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

On Thu, 2008-07-31 at 13:03 +0200, Patryk Zawadzki wrote:
> 2008/7/31 Mathias Hasselmann <[EMAIL PROTECTED]>:
> > Am Donnerstag, den 31.07.2008, 12:39 +0200 schrieb Dave Neary:
> >> Hi,
> >>
> >> Vincent Untz wrote:
> >> > Short description:
> >> > ==
> >> > Conduit is a synchronization architecture for the GNOME desktop. It
> >> > provides an intuitive GUI for synchronizing things and a DBus interface
> >> > for external applications to do the same.
> >>
> >> Stepping back for a second (obnoxiously creating a whole new
> >> sub-thread), I'd like to say it's a pity that "conduit as architecture"
> >> has become conflated with "conduit as GUI application". It's kind of
> >> like talking about gconfeditor's GUI when considering gconf for
> >> inclusion in the platform.
> >
> > Well, just adding "conduit as architecture", and deferring inclusion of
> > its UI until 2.26 sounds compelling. That way applications can start
> > using it.
> 
> See my earlier proposition - just move the menu icon to
> system/preferences and hide the status icon.

I'm not completely opposed to this idea. I support removing the status
icon, and disabling the start at login behaviour (autostart via DBus
will be sufficient) [1].

I don't know If I agree with the icon being in system/preferences
however, for two reasons.

* If/when a future, improved UI appears, it will probably live in
accessories, so why confuse existing conduit users with two moves, once
-> system, and once back to accessories.
* The system/prefs menus are already very cluttered, often with items
that are neither system related, nor preferences, and often its not
clear which menu they should belong in.

John

[1] Dear lazyweb. Is there a 'right way' to programatically manage this
'should I start at login?' behaviour - from inside the app. It seems
that installing two .desktop files, and then managing the starting
behaviour from the sessions capplet is a bit convoluted. Cant I just
rewrite the .desktop file from within conduit to include/exclude some
sort of magic autostart key?. Please reply off list.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

> 
> * Also it would help if some artist would take care about the canvas and
> apply sane padding and line widths. It'd also help to apply theme colors
> instead of randomly chosen colors. My desktop theme uses decent
> gradients for UI elements. There are no gradients at all in the Conduit
> canvas.

This has now been fixed [1] in my devel branch [2], and should find its
way to trunk soon. Conduit now respects your theme (and theme changes),
and uses subtle themed gradients in the major UI elements. 

A lot of plumbing has been completed that makes it easier to apply these
themed attributes to the GUI, and I encourage those who are interested
in making it look prettier to check out the get_style_properties [3]
function in the appropriate widgets.

John

[1]
http://www.johnstowers.co.nz/blog/index.php/2008/07/31/conduit-ui-experiments/
[2] http://bzr-playground.gnome.org/~jstowers/conduit/devel/
[3] see conduit/gtkui/Canvas.py (I would link to it but loggerhead on
bzr seems broken)


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed external dependency: WebKit/GTK+

[John Stowers]

On Mon, 2008-07-28 at 00:33 +0200, Vincent Untz wrote:
> Homepage: http://webkit.org/ http://live.gnome.org/WebKitGtk
> Proposal on d-d-l: 
> http://mail.gnome.org/archives/desktop-devel-list/2008-April/msg00134.html
> License: LGPLv2 or later (I believe)
> 
> Short description:
> ==
> WebKit/GTK+ is the new GTK+ port of the WebKit, an open-source web
> content engine that powers numerous applications such as web browsers,
> email clients, feed readers, web and text editors, and a whole lot
> more.
> 
> Summary so far:
> ===
>  + many +1
>  + should be API/ABI stable and follow the GNOME release cycle
>  + integration with various other libraries of the GNOME stack
>  + patches (and plans) exist for various GNOME applications to make them
>use WebKit

Is anyone aware if the pywebkitgtk [1] folks also plan to make a stable
release for GNOME 2.24?

John

[1] http://code.google.com/p/pywebkitgtk/

>  + the 2.24 branch of epiphany has been created from the 2.22 one, so
>will likely still use Gecko
>  + main concern is about the accessibility support. The accessibility
>team is waiting for an update from the WebKit/GTK+ team.
> 
> Vincent
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: project hamster

[John Stowers]

On Wed, 2008-07-30 at 21:13 -0500, Diego Escalante Urrelo wrote:
> On 7/30/08, John Stowers <[EMAIL PROTECTED]> wrote:
> >
> >  But when I tried hamster applet, there was no such information to be
> >  seen. I would have expected to see incomplete tasks as possible
> >  activities.
> >
> 
> Works here with 2.23.4 in Intrepid, I have no evo python...

Hmm, Its probably a messed up development environment on my PC then.
Evolution python is part of gnome-python-desktop since 2.22 IIRC.

Thanks,

John

> 
> greetings.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: project hamster

[John Stowers]

On Wed, 2008-07-30 at 17:34 -0700, Sandy Armstrong wrote:
> Vincent Untz wrote:
> > Homepage: http://projecthamster.wordpress.com/
> > svn/git/bzr/...: http://code.google.com/p/projecthamster/source/checkout
> > Proposal on d-d-l: 
> > http://mail.gnome.org/archives/desktop-devel-list/2008-April/msg00138.html
> > License: GPLv3 (or is it GPLv3 or later?)
> >
> > Short description:
> > ==
> > Project Hamster is a nifty time tracking applet for the Gnome desktop.
> > It helps to keep track on how much time has been spent during the day on
> > set up activities.
> >
> > Requires new external dependencies:
> > ===
> > python-pysqlite2 [although we can just say it's python]
> >
> > Summary so far:
> > ===
> >  + not hosted in the GNOME infrastructure, but willing to migrate
> >  + many releases since the proposal
> >  + some discussion about using e-d-s instead of sqlite. It seems
> >the maintainers prefer to stay with sqlite
> >  + some people like it
> 
> I finally decided to try this out and I'm really digging it.  I'm an 
> easily-distracted person and Hamster is helping me to track where my 
> time is going.  Sure, it's probably most useful to people who do actual 
> work from their GNOME desktop...but is that much different than Evolution?
> 
> I think there is a lot of potential to integrate Hamster further into 
> GNOME, perhaps by tracking your usage of certain applications, or by 
> integrating into the clock applet or e-d-s as has been suggested.  Being 
> part of GNOME gives it the opportunity to do this integration in a 
> well-supported manner.

Hmmm, I browsed the hamster applet source code, and they appear to try
to use the evolution-python bindings to pre-populate the list of tasks
from the evolution TODO list.

But when I tried hamster applet, there was no such information to be
seen. I would have expected to see incomplete tasks as possible
activities.

Did I miss something?

John

> 
> Ultimately, it's for the distros (and users) to decide what ends up on a 
> desktop.  I think GNOME and Project Hamster have a lot to gain by 
> joining forces at a project level, though.
> 
> Cheers,
> Sandy
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

On Wed, 2008-07-30 at 07:37 -0400, Willie Walker wrote:
> From Li Yuan regarding a11y:
> 
> "Accessibility is a problem for conduit. The GUI is simple, but the 
> left tree view doesn't support keyboard navigation well. Also one has 
> to drag some items to the right "sync area", there is no way to do this 
> by keyboard. And the "sync area" is not accessible. I suspect 
> accessibility work is need by goocanvas.

Yeah, I saw those bugs today. Thanks a lot. I had a few discussions at
GUADEC on how to actually implement the appropriate atk interfaces, for
the canvas items, using python directly. It seems documentation on how
to do this is a bit thin, at least in comparison with the rest of the
accessibility+gtk docs, where one can set properties on the widgets
directly.

Does anyone have any idea on how to go about doing this?

John

> 
> See: http://bugzilla.gnome.org/show_bug.cgi?id=545429
> http://bugzilla.gnome.org/show_bug.cgi?id=545430
> http://bugzilla.gnome.org/show_bug.cgi?id=545431
> 
> Li"
> 
> On Jul 30, 2008, at 6:44 AM, Murray Cumming wrote:
> 
> > On Tue, 2008-07-29 at 23:49 +1200, John Stowers wrote:
> >>> So with what sites can I easily sync my data (from what desktop
> >>> applications)?
> >>
> >> The following is a partial list of non-pim sync functionality
> >
> > I just tried Conduit (version 0.3.6 in Ubuntu Hardy) and I don't think
> > it's at all easy. I failed to figure out how to upload (or sync) photos
> > from a local folder to flickr. I did manage to drag rectangles for
> > flickr and a folder to the canvas.
> >
> > It seems roughly comparable to using the gstreamer pipeline editor
> > instead of using Totem. We can't possibly present this as an 
> > application
> > for users. Major -1 from me.
> >
> >
> > I don't like assistants (wizards) but I guess that this would be better
> > with an additional assistant, guiding people through the choices
> > somehow. For instance:
> >
> > Page 1:
> > Synchronize to web or to device:
> >
> > [] Website
> > [] Palm Pilot
> > [] Windows CE Device
> > [] Nokia Internet Tablet
> > [] Mobile Phone
> >
> > Page 2 (Website):
> >
> > Choose Folder.
> >
> > Synchronize this folder to:
> >
> > Photos:
> > [] Flickr
> > [] Picasa
> > etc
> >
> > Videos:
> > [] YouTube
> > [] Google Video
> > etc
> >
> > General Files:
> > [] Box.net
> >
> >
> >
> >> == Photos ==
> >> FSpot/eye of gnome/nautilus/folder <-->
> >>  * Flickr
> >>  * Picasa
> >>  * SmugMug
> >>  * ShutterFly
> >>  * Facebook
> >>  * iPod Phots
> >>
> >> == Videos ==
> >> totem/nautilus/folder -->
> >>  * Youtube
> >>  * iPod Video
> >>  * nxxx
> >>
> >> == Files ==
> >> * file/folder <--> file/folder
> >> * Box.net
> >> * S3 support (eta: 1 week)
> >> * Google Documents
> >>
> >> == Notes ==
> >> Tomboy Notes <-->
> >> * Backpack Notes
> >> * File/Folder
> >>
> >> == Misc ==
> >> * RSS feed enclosures
> >> * Desktop settings (GConf)
> >>
> >> There is also network sync functionality that allows two PCs to sync
> >> peer to peer any of the above listed data.
> >>
> >> I have not gone into the other sync permutations possible, and I am
> >> certain I have left some items out.
> >
> > -- 
> > [EMAIL PROTECTED]
> > www.murrayc.com
> > www.openismus.com
> >
> > ___
> > desktop-devel-list mailing list
> > desktop-devel-list@gnome.org
> > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

On Wed, 2008-07-30 at 13:24 +0200, Mathias Hasselmann wrote:
> Am Mittwoch, den 30.07.2008, 22:56 +1200 schrieb John Stowers:
> > On Wed, 2008-07-30 at 12:44 +0200, Murray Cumming wrote:
> > > I failed to figure out how to upload (or sync) photos
> > > from a local folder to flickr. I did manage to drag rectangles for
> > > flickr and a folder to the canvas.
> > 
> > Did you read the help documentation?
> 
> With that question you described best, why Conduit is not ready for
> GNOME inclusion yet: No GNOME application, really no single one should
> require studying a manual for doing absolutely basic operations.

Well I think *study* is excessive, but I acknowledge your point. Lets
compare conduit with a word processor/presentation app/music player/note
taker. If you install a new flavour of one of those applications, even
if you have not used it before, its pretty clear what to do. Usability
in that case is equivalent to familiarity. You have already learnt how
to interact with applications of that family before, its familiar enough
to dive right in.

What is the similar family of apps to conduit. What are people
expecting? Given a new type of tool, with which they are unfamiliar, is
it not OK to ask that the user spend a few minutes learning about it?

I dont ask the user read the whole documentation. The section entitled
"Understanding the Conduit Interface" is quite brief, and explains the
whole link-stuff-together idea.

> 
> 
> Despite that Conduit looks really promising, but it still needs a lot of
> UI love, and UI love is a quite central topic in GNOME - IMHO.
> 
> * For me it was hard to figure out, that some of the icons in the left
> can act as synchronization source __and__ as sink.
> * I only figured out by accident, that I can drop targets in the box
> drawn by some synchronization source.

Good point. Perhaps we should have a temporary indicator shown while
hovering a drag and drop

> * I've dropped some "Network" sink and it is connected to the source by
> some red line. What does this color mean? I cannot figure out how to
> configure or even just remove that seemingly useless sink.

Context menus do everythin on the canvas. There is no configuration for
network, which is why the config option will be grey in the context
menu.

Yes the red line is confusing, thats actually a bug

> * Guess I'd already help if the Conduit canvas would follow established
> practice and provide graphical hints when some place within the canvas
> would accept dropping of something. For instance you could place a
> translucent but linked version of the dragged item within source boxes
> which can accept the item:
> 
> +-+
> |  ++  +---+  |
> |  | Home   |--| Backup Folder |  |
> |  | Ready  |   :  | Ready |  |
> |  ++   :  +---+  |
> |   :     |
> |   :  . - - - - - - - .  |
> |   '- - - - - - - : Something New :  |
> |  : Preview   :  |
> |  ' - - - - - - - '  |
> +-+
> +-+
> |  ++ '
> |  | Photos '
> 

Good idea. I think I will implement this.

> * Also it would help if some artist would take care about the canvas and
> apply sane padding and line widths. It'd also help to apply theme colors
> instead of randomly chosen colors. My desktop theme uses decent
> gradients for UI elements. There are no gradients at all in the Conduit
> canvas.

Any volunteers? My art skills are limited.

Thanks for your reply Mathias, these are the kind of responses that I
intended, and wanted, the module discussion to bring out, these kinds of
actually can make a big difference*

John

* Aside: I think the module discussions should be *much* earlier. To
actually give application authors time to address concerns raised.


> 
> 
> Ciao
> Mathias

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

On Wed, 2008-07-30 at 12:44 +0200, Murray Cumming wrote:
> On Tue, 2008-07-29 at 23:49 +1200, John Stowers wrote:
> > > So with what sites can I easily sync my data (from what desktop
> > > applications)?
> > 
> > The following is a partial list of non-pim sync functionality
> 
> I just tried Conduit (version 0.3.6 in Ubuntu Hardy) and I don't think
> it's at all easy. 

0.3.6 is about 7 months old, its nearly impossible to get updates into
Ubuntu. Updated versions are available in our PPA

https://launchpad.net/~conduit/+archive

> I failed to figure out how to upload (or sync) photos
> from a local folder to flickr. I did manage to drag rectangles for
> flickr and a folder to the canvas.

Did you read the help documentation?

> It seems roughly comparable to using the gstreamer pipeline editor
> instead of using Totem. We can't possibly present this as an application
> for users. Major -1 from me.
> 
> 
> I don't like assistants (wizards) but I guess that this would be better
> with an additional assistant, guiding people through the choices
> somehow. For instance:
> 
> Page 1:
> Synchronize to web or to device:
> 
> [] Website
> [] Palm Pilot
> [] Windows CE Device
> [] Nokia Internet Tablet
> [] Mobile Phone
> 
> Page 2 (Website):
> 
> Choose Folder.
> 
> Synchronize this folder to:
> 
> Photos:
> [] Flickr
> [] Picasa
> etc
> 
> Videos:
> [] YouTube
> [] Google Video
> etc
> 
> General Files:
> [] Box.net
> 
> 
> 
> > == Photos ==
> > FSpot/eye of gnome/nautilus/folder <-->
> >  * Flickr
> >  * Picasa
> >  * SmugMug
> >  * ShutterFly
> >  * Facebook
> >  * iPod Phots
> > 
> > == Videos ==
> > totem/nautilus/folder -->
> >  * Youtube 
> >  * iPod Video
> >  * nxxx
> > 
> > == Files ==
> > * file/folder <--> file/folder
> > * Box.net
> > * S3 support (eta: 1 week)
> > * Google Documents
> > 
> > == Notes ==
> > Tomboy Notes <-->
> > * Backpack Notes
> > * File/Folder
> > 
> > == Misc ==
> > * RSS feed enclosures
> > * Desktop settings (GConf)
> > 
> > There is also network sync functionality that allows two PCs to sync
> > peer to peer any of the above listed data.
> > 
> > I have not gone into the other sync permutations possible, and I am
> > certain I have left some items out.
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

> 
> I guess at the end of the day I'm not sure if/why conduit is replacing
> gnome-pilot.

Conduit has not been proposed to replace gnome-pilot. Eventually we will
support palm sync, and we can discuss the future of gnome-pilot at that
time.

I believe Conduit provides sufficient benefits now to warrant inclusion,
irrespective of palm support.

John

> 
> Cheers,
> Dave.
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

> > 
> > I appreciate the difficulty of doing all this, and I like that it's
> > being done properly via a proper framework, but it doesn't seem like it
> > has enough device support to be genuinely useful to many people yet.
> 
> I know everyone likes to think of themselves as a representative user,
> and by no means am I dismissing the importance of mobile device sync,
> but I personally use online services more these days. The level of
> mobile device sync we support well (nxxx and WM5 and iPod) correspond to
> the devices I own. GPM integration will likely/hopefully be done this
> cycle.

hmmm, this paragraph was not meant to sound as condescending as it came
out. 

Apologies!

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

On Tue, 2008-07-29 at 13:21 +0200, Murray Cumming wrote:
> On Tue, 2008-07-29 at 22:21 +1200, John Stowers wrote:
> > On Tue, 2008-07-29 at 11:24 +0200, Murray Cumming wrote:
> > > How easy is it to do this for any particular specific cases, such as
> > > syncing a Palm with a desktop PC (With Evolution, hopefully), or syncing
> > > the contacts on my mobile phone, or with my N810?
> > 
> > Palm isnt supported.
> > Windows mobile 5/6 support is OK, and getting better.
> > Nokia phone support (via gnome-phone-manager is being worked on ATM)
> > Nokia nxxx support is pretty good.
> [snip]
> 
> I appreciate the difficulty of doing all this, and I like that it's
> being done properly via a proper framework, but it doesn't seem like it
> has enough device support to be genuinely useful to many people yet.

I know everyone likes to think of themselves as a representative user,
and by no means am I dismissing the importance of mobile device sync,
but I personally use online services more these days. The level of
mobile device sync we support well (nxxx and WM5 and iPod) correspond to
the devices I own. GPM integration will likely/hopefully be done this
cycle.

I don't want GNOME to wait forever (again..) for the perfect sync
solution, because in my experience perfect is equivalent to supporting
>= some arbitrary moving threshold combination of devices and
webservices.

The diverse and useful range of things Conduit supports has grown to
support over the last few years have seemed to validate our
architectural choices. This means than any future additions to Conduit,
in terms of devices we support, or bugs we fix, will propogate through
the whole desktop, with no additional work on the part of application
authors.

> 
> > Our strength and historical focus has been sync to online services from
> > GNOME apps. Our current focus is on mobile devices.
> 
> So with what sites can I easily sync my data (from what desktop
> applications)?

The following is a partial list of non-pim sync functionality

== Photos ==
FSpot/eye of gnome/nautilus/folder <-->
 * Flickr
 * Picasa
 * SmugMug
 * ShutterFly
 * Facebook
 * iPod Phots

== Videos ==
totem/nautilus/folder -->
 * Youtube 
 * iPod Video
 * nxxx

== Files ==
* file/folder <--> file/folder
* Box.net
* S3 support (eta: 1 week)
* Google Documents

== Notes ==
Tomboy Notes <-->
* Backpack Notes
* File/Folder

== Misc ==
* RSS feed enclosures
* Desktop settings (GConf)

There is also network sync functionality that allows two PCs to sync
peer to peer any of the above listed data.

I have not gone into the other sync permutations possible, and I am
certain I have left some items out.


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

On Tue, 2008-07-29 at 11:24 +0200, Murray Cumming wrote:
> On Mon, 2008-07-28 at 00:32 +0200, Vincent Untz wrote:
> > Homepage: http://www.conduit-project.org
> > svn/git/bzr/...: http://svn.gnome.org/viewvc/conduit/
> > Proposal on d-d-l: 
> > http://mail.gnome.org/archives/desktop-devel-list/2008-March/msg00320.html
> > License: ??? (GPLv2 or later?)
> > 
> > Short description:
> > ==
> > Conduit is a synchronization architecture for the GNOME desktop. It
> > provides an intuitive GUI for synchronizing things and a DBus interface
> > for external applications to do the same.
> 
> Surely any proposed application should be much clearer about what it
> will allow users to do.
> 
> What can I realistically expect to sync with what? Are we talking about
> syncing multiple desktops, or syncing information between the desktop
> and phones/PDAs.

For a good overview, written better than I could, please check out the
lifehacker article
http://lifehacker.com/398775/sync-and-back-up-your-data-with-conduit-for-linux
And also, the presentation I gave at GUADEC is pretty informative
http://files.conduit-project.org/Conduit%20-%20GUADEC%202008.pdf

> 
> How easy is it to do this for any particular specific cases, such as
> syncing a Palm with a desktop PC (With Evolution, hopefully), or syncing
> the contacts on my mobile phone, or with my N810?

Palm isnt supported.
Windows mobile 5/6 support is OK, and getting better.
Nokia phone support (via gnome-phone-manager is being worked on ATM)
Nokia nxxx support is pretty good.

Our strength and historical focus has been sync to online services from
GNOME apps. Our current focus is on mobile devices. 

We have two SOC projects, SyncML support, and iPod support.

> 
> Also, shouldn't this be integrated into particular applications?
> Shouldn't Evolution have a sync menu item, replacing it's current awful
> gnome-pilot synchronization feature.

Our future plans involve integrating into other applications when it
makes sense. Doing so at this point may be putting the cart before the
horse, for technical reasons outlined in the presentation above.

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

On Mon, 2008-07-28 at 17:47 -0400, Colin Walters wrote:
> On Tue, 2008-07-29 at 09:33 +1200, John Stowers wrote:
> 
> > If another app calls into conduit using dbus, it will automatically
> > start, without the gui. If the user then starts Conduit from the
> > accessories menu, the Gui will be launched atop the already running
> > service.
> 
> Ok; can you summarize the status on that?  Which apps are using it now?
> Which plan to?  Particularly with respect to apps in 2.24?

With regard to planned apps,

* Tomboy has expressed interest, but has not wanted to depend on Conduit
while it is not a part of GNOME
* Cheese has also shown interest for photo/video upload

We of course have plans to integrate with other applications, but its a
balancing act between adding features/fixing bugs in Conduit core to
make it work, and spending time on integrating it with other apps. The
relative motivation for which of these tasks to work on depends on
Conduits presence/importance in GNOME.

John

> 
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

On Mon, 2008-07-28 at 17:47 -0400, Colin Walters wrote:
> On Tue, 2008-07-29 at 09:33 +1200, John Stowers wrote:
> 
> > If another app calls into conduit using dbus, it will automatically
> > start, without the gui. If the user then starts Conduit from the
> > accessories menu, the Gui will be launched atop the already running
> > service.
> 
> Ok; can you summarize the status on that?  Which apps are using it now?
> Which plan to?  Particularly with respect to apps in 2.24?

We have the eye-of-gnome plugin for multiple site photo upload, and a
totem plugin for video upload. There is a nautilus extension for folder
sync to/from online services, and we are also working on a smaller
applet/tray icon for mobile device sync only (i.e. detects your phone
when connected, pre-configures sync with evolution, and  just does it.
In case of error it then launches the main GUI)

We will probably blog about the latter very soon. 

John

> 
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

On Mon, 2008-07-28 at 11:16 -0400, Colin Walters wrote:
> On Mon, 2008-07-28 at 00:32 +0200, Vincent Untz wrote:
> > Homepage: http://www.conduit-project.org
> > svn/git/bzr/...: http://svn.gnome.org/viewvc/conduit/
> > Proposal on d-d-l: 
> > http://mail.gnome.org/archives/desktop-devel-list/2008-March/msg00320.html
> > License: ??? (GPLv2 or later?)
> > 
> > Short description:
> > ==
> > Conduit is a synchronization architecture for the GNOME desktop. It
> > provides an intuitive GUI for synchronizing things and a DBus interface
> > for external applications to do the same.
> 
> I've briefly looked at conduit-0.3.11.1-1.fc9.noarch; one thing I'm
> wondering is that are we thinking of running it by default?  Concretely
> what is a new user's interface to this system?  Just a new entry in the
> Accessories menu?  

If another app calls into conduit using dbus, it will automatically
start, without the gui. If the user then starts Conduit from the
accessories menu, the Gui will be launched atop the already running
service.

Basically I would prefer Conduit did not automatically start with the
session as it increases login time.

There was originally a technical justification for having Conduit
running all the time, but since then we have got better about scanning
for appropriate connected hardware, instead of relying on Conduit
running all the time to notice when it gets plugged in.

In future there may be additional reasons to have conduit running all
the time, such as 'always up to date' sync (only our gconf sync uses
this ATM, IIRC).

In summary however, If I was a distributor, I would not autostart
conduit at login (yet).

John

> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: conduit

[John Stowers]

On Mon, 2008-07-28 at 01:05 +0200, Vincent Untz wrote:
> Le lundi 28 juillet 2008, à 00:32 +0200, Vincent Untz a écrit :
> > Homepage: http://www.conduit-project.org
> > svn/git/bzr/...: http://svn.gnome.org/viewvc/conduit/
> > Proposal on d-d-l: 
> > http://mail.gnome.org/archives/desktop-devel-list/2008-March/msg00320.html
> > License: ??? (GPLv2 or later?)
> > 
> > Short description:
> > ==
> > Conduit is a synchronization architecture for the GNOME desktop. It
> > provides an intuitive GUI for synchronizing things and a DBus interface
> > for external applications to do the same.
> 
> I think there's a C library to make it easy to use conduit from C apps.
> What's its state?

It lives inside conduit svn. Its a basic oo wrapper around our DBus API.
Seems to work OK AFAICT, but so far has not seen any users.

John

> 
> Vincent
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: maintainer scripts

[John Stowers]

On Sun, 2008-07-27 at 01:50 +0200, daniel g. siegel wrote:
> On So, 2008-07-27 at 11:46 +1200, John Stowers wrote:
> > On Sun, 2008-07-27 at 01:08 +0200, daniel g. siegel wrote:
> > > another quick question: maintainer.py seems to pick up all bug fixes,
> > > but what about features, or other enhancements, which are no bugs? how
> > > do i get those into the NEWS file?
> > 
> > Check out 
> > http://svn.gnome.org/viewvc/conduit/trunk/NEWS?view=markup 
> > and
> > http://www.conduit-project.org/wiki/MakingARelease
> > 
> > If I make a commit, that adds a feature, not related to a bug # I add it
> > to NEWS directly. When maintainer.py makes the NEWS file any things I
> > had added to the current version section of the file get prepended to
> > the top of NEWS.new
> 
> i see. but wouldnt it be better then, to analyze the svn log until the
> last release?

Maybe, but I don't think so.

How would one determine which commits add features - perhaps a special
stanza in the message, e.g. #feature. What about new features that span
multiple commits, or if you forget to mention the new feature in the
commit message. 

I tend to make commit messages developer focused, i.e. "add foo_bar
function", not user focused.

John

> 
> daniel
> 
> > 
> > John
> > 
> > > 
> > > daniel
> > > 
> > > On Mi, 2008-07-23 at 18:17 -0400, Claudio Saavedra wrote:
> > > > El mié, 23-07-2008 a las 23:35 +0200, daniel g. siegel escribió:
> > > > > i just found some scripts like maintainer.py, list-translator.sh and
> > > > > so
> > > > > on.. does anybody use them for rolling your own tarballs? 
> > > > 
> > > > We use maintainer.py to prepare most of the stuff that should go into
> > > > NEWS before rolling tarballs. It makes it way easier!
> > > > 
> > > > Claudio
> > > > 
> > > ___
> > > desktop-devel-list mailing list
> > > desktop-devel-list@gnome.org
> > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> > 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: maintainer scripts

[John Stowers]

On Sun, 2008-07-27 at 01:08 +0200, daniel g. siegel wrote:
> another quick question: maintainer.py seems to pick up all bug fixes,
> but what about features, or other enhancements, which are no bugs? how
> do i get those into the NEWS file?

Check out 
http://svn.gnome.org/viewvc/conduit/trunk/NEWS?view=markup 
and
http://www.conduit-project.org/wiki/MakingARelease

If I make a commit, that adds a feature, not related to a bug # I add it
to NEWS directly. When maintainer.py makes the NEWS file any things I
had added to the current version section of the file get prepended to
the top of NEWS.new

John

> 
> daniel
> 
> On Mi, 2008-07-23 at 18:17 -0400, Claudio Saavedra wrote:
> > El mié, 23-07-2008 a las 23:35 +0200, daniel g. siegel escribió:
> > > i just found some scripts like maintainer.py, list-translator.sh and
> > > so
> > > on.. does anybody use them for rolling your own tarballs? 
> > 
> > We use maintainer.py to prepare most of the stuff that should go into
> > NEWS before rolling tarballs. It makes it way easier!
> > 
> > Claudio
> > 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: maintainer scripts

[John Stowers]

On Sat, 2008-07-26 at 14:11 -0400, Thomas Thurman wrote:
> Ysgrifennodd daniel g. siegel:
> > thanks! it was exactly that what i needed. i modified it a bit, mostly
> > to have the changelog and news style of older release notes of cheese.
> 
> Metacity also has a release script, which I'd also like to merge:
> 
> http://svn.gnome.org/viewvc/metacity/trunk/tools/release-wrangler.py?revision=3625&view=markup
> 
> Brad Fitzpatrick produced a grand unified release script called ShipIt 
> once; I took a look at merging it with that.  It's written in Perl, 
> which is a shame because most GNOME scripts are written in Python or 
> shellscript.  However, it did have one really important and useful 
> feature, which was that any project could contain a file which overrode 
> one or more steps of the standard procedure.  That way, you didn't have 
> to write a new release script every time, or fork a standard one, but 
> you could modify it in just the way you needed.
> 
> I didn't end up using ShipIt in the end, because there were some 
> finer-grained modifications needed than it seemed worth making and 
> keeping the same system.  The design is rather lovely, though, and I 
> believe it would be worthwhile to adopt in any generalised maintainer 
> script.
> 
> > btw: we have another cool script, which basically is a wrapper around
> > svn commit, which updates the ChangeLog file with the commit message
> > before actually commiting.
> > 
> > you can find it here: http://home.cs.tum.edu/~siegel/files/cicl
> 
> Funnily enough, Metacity also has such a script :)

I have transitioned to maintaining Conduit completely out of
bzr-playground.gnome.org. 

In this workflow I use MOAP. Amongst other things, It prepares changelog
entries, and makes commits. I used to use prepare-Changelog.pl and cicl,
but it didnt support bzr, etc. I find MOAP much better.

Workflow:

make changes
moap cl prep #makes changelog entry
moap cl ci   #commits with commit message = changelog entry
bzr push svn+http

John
 
> 
> http://svn.gnome.org/viewvc/metacity/trunk/tools/commit-wrangler.py?view=markup
> 
> Maybe we should all be pooling effort.
> 
> peace
> 
> T
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: maintainer scripts

[John Stowers]

On Wed, 2008-07-23 at 23:35 +0200, daniel g. siegel wrote:
> hello!
> 
> i just found some scripts like maintainer.py, list-translator.sh and so
> on.. does anybody use them for rolling your own tarballs? 

I use a slightly modified version of maintainer.py to do NEWS updates,
release notes prep, etc.

The workflow I use when making a release is
http://www.conduit-project.org/wiki/MakingARelease

John

> 
> im just too lazy to prepare the NEWS file by hand every time and then
> write that announce mail...
> 
> daniel
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: evolution-data-server now depends on sqlite 3.5

[John Stowers]

On Thu, 2008-07-17 at 13:30 +0200, =?ISO-8859-1?Q?Sebastian_P=F6lsterl_
wrote:
> Am Donnerstag, den 17.07.2008, 13:27 +0200 schrieb Patryk Zawadzki:
> > 2008/7/17 Sebastian Pölsterl <[EMAIL PROTECTED]>:
> > > Am Mittwoch, den 16.07.2008, 18:41 +0200 schrieb Luca Ferretti:
> > >> According to this[1] commit, evolution-data-server now depends on
> > >> sqlite.
> > >>
> > >> Due to the increasing[2] number of project that require this library,
> > >> could we consider to officially add sqlite to external deps?
> > > I'm all for it. That way I can use sqlite to store Deskbar-Applet's
> > > history.
> > 
> > Isn't deskbar (at least in part) a python app? Doesn't stock python
> > ship with sqlite3 bindings?
> > 
> Only Python 2.5 does, but only Python 2.4 is a blessed external
> dependency. Increasing the minimum version to 2.5 would make more sense
> in this case.

I'm a fan of increasing the Python version to 2.5 as I depend on a
number of 2.5 only features in Conduit. I guess bumping the python
external dep version is fodder for another discussion however.

John

> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module proposal: Conduit for GNOME 2.24

[John Stowers]

On Mon, 2008-03-31 at 15:16 -0400, Adam Schreiber wrote:
> I rather like the idea of conduit.  I just set up some google calendar
> <-> evolution calendar syncs and it worked great.
> 
> Since it's taking passwords and storing them, is it using a secure
> method like gnome-keyring? 

It was, but I had to take it out due to a crasher in the python gnomevfs
bindings. That has now been fixed, so I will be able to add this back in
this cycle.


>  Also, to sync a second calendar on the
> same account it required me to add the authentication information
> again.  The concept of persistent accounts probably needs to be
> introduced at some point to allow saying sync these 5 google calendars
> from the same acount with these matching evo ones without 5 separate
> conduit groups.
> 
> Note: There's a proposed SoC project that wants to create persistent
> accounts in the About Me capplet.

This was discussed briefly with the mugshot folks. The concept of a
centralised 'this is my account details on these services' type thing.
No resolution was ever really reached, so I would be happy if the SOC
project (for example) came and solved these problems for me!

John


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module proposal: Conduit for GNOME 2.24

[John Stowers]

On Mon, 2008-03-31 at 12:03 -0700, Eitan Isaacson wrote:
> Hi.
> 
> Conduit in it's current state is not accessible. Is there a way to
> create and modify groups and items without using the mouse? This of
> course is a very basic access issue.
> 
> Not less important, the canvas in which all the groups and items are
> reviewed and edited is inaccessible to assistive technologies. For this
> to be accessible, there needs to be keyboard navigation, and proper ATK
> interfaces implemented. I am not sure how possible this is to do
> directly in python[1].
> 
> I would give this a +1 if the devs think they could make Conduit
> accessible by 2.24.

I will have to look into (py)goocanvas to see how/if it supports ATK,
and what I will need to do to hook into this. Does anyone have some
experience with this sort of thing?

In an ideal world, I expected the Gtk+ team to have decided on a new
Canvas by now, so I could switch to using that.

John


> 
> Cheers,
>   Eitan.
> 
> 
> On Mon, 2008-03-31 at 23:35 +1300, John Stowers wrote:
> > Hey Guys,
> > 
> > On behalf of the Conduit [1] development team, I would like to propose
> > Conduit for inclusion in GNOME 2.24 desktop suite.
> > 
> > * Purpose: Conduit is a synchronization architecture for the GNOME
> > desktop. It provides an intuitive GUI for synchronizing things and a
> > DBus interface for external applications to do the same.
> > 
> > * Justification:
> > Our immediate benefits to the GNOME desktop are very well supported
> > multi-site photo/upload and sync (from Fspot, eog and folder), tomboy
> > synchronization to a number of places, file/folder sync (including
> > intuitive removable volume support, and the ability to do all these
> > things peer to peer. We also support many more than these listed,
> > however at the cost of additional dependencies. See below for
> > clarification.
> > 
> > In implementing these diverse backends, I am confident our abstractions
> > are sound, and we will be able to grow with the GNOME desktop and
> > support synchronization with any device you can imagine. Applications
> > using our DBus interface will get these benefits at no extra cost.
> > 
> > * Dependencies:
> >   pygtk,
> >   gnomevfs,
> >   gnome-python-desktop > 2.22,
> >   python-gtkmozembed,
> >   [NEW] pygoocanvas > 0.9.0,
> >   [NEW] goocanvas > 0.9.0,
> >   [NEW] Python 2.5 (for network sync support)
> > 
> > * Resource usage:
> >   GNOME FTP, GNOME SVN, GNOME bugzilla, translations
> > 
> > * Adoption:
> >   Packaged for all major distros, expressions of interest for more
> > extensive use by Ubuntu [2], Mandriva [3] and Suse [4]
> > 
> > * Gnome-ness:
> >   * We support Tomboy note sync and Fspot photo sync. In both cases we
> > were instrumental in the development of DBus interfaces in the
> > respective applications
> >   * We support evolution-data-server through the new python evolution
> > bindings we contributed to GNOME last cycle.
> >   * Our file/folder sync uses gnomevfs
> >   * [WIP] We have developed an eog plugin for photo upload to a number
> > of sites, directly from within the application
> >   * [WIP] We have developed a nautilus plugin to enable easy
> > file/folder sync
> > 
> > * Additional Information:
> > Our focus for this cycle is the support of mobile devices through both
> > libsyncml [5] and (python)gammu [6]. This will obviously introduce
> > additional dependencies on these libraries.
> >   
> > We are looking forward to, and will be adding support for GIO/GVFS as
> > soon as it is available to be used from Python.
> >   
> > We also support the following services although support for them comes
> > at the cost of additional dependencies
> >   * Google contacts, [WIP] calendar, [WIP] documents (requires
> > python-gdata [7]) 
> >   * Backpackit.com (require python backpack [8])
> >   * Facebook photos (requires pyfacebook [9])
> >   * iPod photos (requires libgpod [10])
> > 
> > Conduit is translated into a number of languages, and features user help
> > documentation. However both of these are WIP.
> > 
> > We have had firm expressions of interest from Tomboy and Cheese about
> > using conduit for Sync and Export respectively. Conduits presence in the
> > desktop set would make their dependency on us for this functionality
> > more palatable.
> > 
> > Looking forward to hearing your thoughts
> > 
> > John Stowers
> > 
> > [1] http://www.conduit-project.org

Re: Module proposal: Conduit for GNOME 2.24

[John Stowers]

On Mon, 2008-03-31 at 13:31 +0200, Matteo Settenvini wrote:
> These are wonderful news! I'd like to thank you for Conduit, I use it
> often and it's really useful.
> 
> The only thing I miss is PocketPC integration (which unfortunately I've
> to use for work) with SyncCE.

I agree.

There are python bindings available for SyncCE, but I dont have a device
to play with. 

Unfortunately the contributor who initially did some experiments on
SyncCE in Conduit did not have time to complete the work.

I will ping him for this cycle!

John

> 
> Thanks for your wonderful job! I'd like to have Conduit in GNOME.
> 
> Matteo
> 
> 
> Il giorno lun, 31/03/2008 alle 23.35 +1300, John Stowers ha scritto:
> > Hey Guys,
> > 
> > On behalf of the Conduit [1] development team, I would like to propose
> > Conduit for inclusion in GNOME 2.24 desktop suite.
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module proposal: Conduit for GNOME 2.24

[John Stowers]

> 
> ACK.
> 
> Maybe the UI would be more easy to understand if the tree view in the
> main window would be replaced by some Glade/GIMP like tool palette.
> I am developing a generic tool palette widget for usage
> in Glom (and hopefully many other programs) in libegg/toolpalette right
> now. [1][2]

hehe, yeah I stumbled across this a few weeks ago. I will keep an eye on
your progress.

> 
> Also the preferences dialog could use quite some UI love.

Its no excuse really, but there are a few things in there (like the
MappingDB tab) that are only visible in development releases.

> 
> But I agree that some application like Conduit would greatly benefit
> GNOME.
> 
> Ciao,
> Mathias
> 
> [1] http://svn.gnome.org/viewvc/libegg/trunk/libegg/toolpalette/
> [2]
> http://taschenorakel.de/pictures/screenshots/2008/03/31/testtoolpalette.png
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module proposal: Conduit for GNOME 2.24

[John Stowers]

> 
> >   * [WIP] We have developed an eog plugin for photo upload to a number
> > of sites, directly from within the application
> 
> Any chance of working on something similar for Totem and Cheese?
> http://bugzilla.gnome.org/show_bug.cgi?id=459505
> http://bugzilla.gnome.org/show_bug.cgi?id=522210

I am confident that video upload to Youtube and Vimeo will be added this
cycle as both services have nice APIs (and bindings).

http://bugzilla.gnome.org/show_bug.cgi?id=522120
http://bugzilla.gnome.org/show_bug.cgi?id=524777 

> 
> > * Additional Information:
> > Our focus for this cycle is the support of mobile devices through both
> > libsyncml [5] and (python)gammu [6]. This will obviously introduce
> > additional dependencies on these libraries.
> 
> And gnome-phone-manager, if I get off my butt.

Good to hear!

I'd like to see the UI reviewed before giving it a +1, as I've had very
> hard times understanding how to actually make it work. Something a bit
> more like iSync (at least for the "core" PIM data) would be nice.

I agree. Such an interface could be easily implemented atop the Conduit
DBus interface but I would prefer the consensus of what constitutes
'core' sync come in part from the GNOME community. 

For example one consequence of getting into GNOME would be that the
means for managing Tomboy sync would move from the Conduit GUI into
Tomboy [1].

John

[1] Well that's what I would like. I hope the Tomboy devs agree!

> 
> Cheers
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Module proposal: Conduit for GNOME 2.24

[John Stowers]

Hey Guys,

On behalf of the Conduit [1] development team, I would like to propose
Conduit for inclusion in GNOME 2.24 desktop suite.

* Purpose: Conduit is a synchronization architecture for the GNOME
desktop. It provides an intuitive GUI for synchronizing things and a
DBus interface for external applications to do the same.

* Justification:
Our immediate benefits to the GNOME desktop are very well supported
multi-site photo/upload and sync (from Fspot, eog and folder), tomboy
synchronization to a number of places, file/folder sync (including
intuitive removable volume support, and the ability to do all these
things peer to peer. We also support many more than these listed,
however at the cost of additional dependencies. See below for
clarification.

In implementing these diverse backends, I am confident our abstractions
are sound, and we will be able to grow with the GNOME desktop and
support synchronization with any device you can imagine. Applications
using our DBus interface will get these benefits at no extra cost.

* Dependencies:
  pygtk,
  gnomevfs,
  gnome-python-desktop > 2.22,
  python-gtkmozembed,
  [NEW] pygoocanvas > 0.9.0,
  [NEW] goocanvas > 0.9.0,
  [NEW] Python 2.5 (for network sync support)

* Resource usage:
  GNOME FTP, GNOME SVN, GNOME bugzilla, translations

* Adoption:
  Packaged for all major distros, expressions of interest for more
extensive use by Ubuntu [2], Mandriva [3] and Suse [4]

* Gnome-ness:
  * We support Tomboy note sync and Fspot photo sync. In both cases we
were instrumental in the development of DBus interfaces in the
respective applications
  * We support evolution-data-server through the new python evolution
bindings we contributed to GNOME last cycle.
  * Our file/folder sync uses gnomevfs
  * [WIP] We have developed an eog plugin for photo upload to a number
of sites, directly from within the application
  * [WIP] We have developed a nautilus plugin to enable easy
file/folder sync

* Additional Information:
Our focus for this cycle is the support of mobile devices through both
libsyncml [5] and (python)gammu [6]. This will obviously introduce
additional dependencies on these libraries.
  
We are looking forward to, and will be adding support for GIO/GVFS as
soon as it is available to be used from Python.
  
We also support the following services although support for them comes
at the cost of additional dependencies
  * Google contacts, [WIP] calendar, [WIP] documents (requires
python-gdata [7]) 
  * Backpackit.com (require python backpack [8])
  * Facebook photos (requires pyfacebook [9])
  * iPod photos (requires libgpod [10])

Conduit is translated into a number of languages, and features user help
documentation. However both of these are WIP.

We have had firm expressions of interest from Tomboy and Cheese about
using conduit for Sync and Export respectively. Conduits presence in the
desktop set would make their dependency on us for this functionality
more palatable.

Looking forward to hearing your thoughts

John Stowers

[1] http://www.conduit-project.org
[2] https://wiki.ubuntu.com/SyncIntegration
[3] http://wiki.mandriva.com/en/2008.1_What%27s_New
[4] http://www.novell.com/brainshare/general-sessions-2008.html
[5] http://libsyncml.opensync.org/
[6] http://cihar.com/gammu/python/
[7] http://code.google.com/p/gdata-python-client/
[8] http://bleu.west.spy.net/~dustin/projects/backpack/
[9] http://code.google.com/p/pyfacebook/
[10] http://www.gtkpod.org/libgpod.html




___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GSOC 2008 advice

[John Stowers]

On Tue, 2008-02-26 at 12:10 -0600, Benjamin Gramlich wrote:
> Greetings all,
> 
> I am interested in applying to work on a project for Gnome during the
> summer of code 2008, and I have a few ideas. 
> 
> Idea #1) Re-implement the panel-applet library/interface to depend on
> DBUS.

I guess you are familiar with the hacking that desrt did on the panel
last year [1][2]. AIUI one consequence of this was a shift to DBus. It
would be cool if someone was to pick this up and run with it.

Here are some of my random notes about what a shiny new panel would look
like
* Some way to mix in and out of process applets, a C API that would
support this, might be a sensible for the default set of applets, saving
memory and startup time.
* See what can be taken/adapted from AWN[3]/Cairo-dock[4]. Should there
be another basic panel primitive that is more like a dock? Is there a
need for the two to be separated, or is AWN just what the panel would
look like if it was implemented again today, using current technologies?
* Pick a widget technology. Something that would allow people to write
widgets with less hacking mojo. We have seen other people facilitate
this by making widgets closer to the web. Jackfield[5] development seems
to have stopped, but webkit is the rage these days, and looking at , it
seems capable of making all our dreams come true[6].
* Also check out the amazing bling in aastro-desktop[7], using Clutter
and JSON.
* Is the management of desktop widgets by the panel a good idea? Should
the panel be like the vista sidebar, applets can be in it, or hovering
on the desktop.

Regards

John

[1] http://git.desrt.ca/gitweb/?p=panel;a=summary
[2] http://blogs.gnome.org/desrt/2007/02/18/panel-composite-bin/
[3] http://awn-project.org/
[4]
http://thedailyubuntu.blogspot.com/2008/02/cairo-dock-animated-launch-bar-for_03.html

[5] http://www.kryogenix.org/code/jackfield/
[6]
http://www.atoker.com/blog/2008/02/26/developing-hybrid-web-gtk-applications/
[7] http://svn.o-hand.com/view/clutter/trunk/toys/astro-desktop/

> 
> Idea #2) Migrate the panel to GIO/GVFS and DBUS.
> 
> Idea #3) Develop a tutorial for GIO/GVFS.
> 
> Idea #4) Create more compositing effects for metacity and develop a gui
> configuration tool for the effects.
> 
> Are these ideas any good? Are they in line with what Gnome needs at the
> moment? Would they duplicate the work of a Gnome developer? Lastly, (and
> probably most importantly) would there be a mentor available to help
> with any of these projects?
> 
> I'm really excited about the possibility of doing SOC this year, and I
> would like to get studying and learning as soon as possible. Any
> feedback or advice is most appreciated.
> 
> Thank you,
> 
> Benjamin
> 
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME's testing strategy for GUIs

[John Stowers]

On Thu, 2008-02-14 at 13:26 -0800, Brad Taylor wrote:
> Hey,
> 
> > Personally I would like to use one of these frameworks to automatically
> > take screenshots of Conduit releases, but so far I'm stuck. I don't have
> > enough time to compare all the available options, and don't want to
> > waste time picking one that doesn't get anointed at a later date.
> 
> FYI -- Strongwind, by default, takes a screenshot after every
> action/expected result pair, so it could be used as an automated
> documentation tool.

Looking through the code I noticed that utils.takeScreenshot() took a
shot of the root window, not of a specific window, which is what I would
need (as conduit has ~1 config dialog per data provider).

Then there is other stuff like making this all work automatically and
easily in xvfb so that I do not get dialogs popping up all over the
show. Does strongwind do this? (actually never mind, I dont want to take
this off topic)

Regards,

John

> 
> Best,
> 
> -Brad
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME's testing strategy for GUIs

[John Stowers]

> 
> 
> * Many tools are available for automated testing, and GNOME needs to
>   annoint one with holy gnome pee so that it will become an acceptable
>   dependency for development.  Whether this is LDTP, Dogtail, Strongwind,
>   or others, a clear decision needs to be made so that people can go
>   forth with creating tests.

Not that anointing something as holy pee always works (remember Tracker
v Beagle), but I think in this case it is worth it.

Personally I would like to use one of these frameworks to automatically
take screenshots of Conduit releases, but so far I'm stuck. I don't have
enough time to compare all the available options, and don't want to
waste time picking one that doesn't get anointed at a later date.

Perhaps this same rationale is the reason [1] that we don't have
 * Some sort of desktop wide automated system for keeping screenshots up
to date in documentation (and taking them in all supported languages)
 * Heaps of GUI regression tests in JHBuild

John

[1] The other reason, of course, is that people don't have infinite free
time to hack on these things

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Online Desktop and GNOME 2.22

[John Stowers]

>
>
>
>  - it seems inevitable that both gnome-http-lib and Firefox would need
>to rely on some type of common "repository" of cookies, etc. and that
>this repo would be managed by some type of daemon that handled
>locking and change-notification; said daemon would need to be able
>to run sans Firefox, and would need to handle changes to the repo,
>not be read-only.


Isnt there some work been done on using gnome-keyring to store
authentication information for firefox? (sorry I cant remember the link to
the patch in FF bugzilla). Wouldnt it be a natural extension to this to use
either use this, or upcoming GSettings (gnome-y) or dconf (more cross
desktoppy) for the cookie store. Both of these implementations already deal
with locking and change notification, so why do we need a new daemon?
(especialy if dconf AIUI is daemonless)

- though it never pays to block on a committee, I would say key
>people to get "sign off" from (or at least keep informed) would
>be Alex so we know the solution works for gvfs, and the Mozilla
>team, so we know they will take the patches to Firefox and
>be OK with the way it's done


Yeah, and lets not forget webkit also. I think this is where something like
dconf, which sounds a bit less GNOME-y has a greater chance of being signed
off by on multiple projects with stakeholders outside GNOME.

I guess it would then be a natural extension to make libsoup / gvfs et. al
depend on dconf for authentication info and cookies.

But does this then fall down or come back the the same debate about hard and
soft deps and where (how low) something in the stack like dconf,
gnome-keyring and gvfs (authentication) lies.

John


>
>  - the Mozilla team might be interested in this problem on Windows
>also, since right now using the Windows HTTP stuff shares state
>with IE, but I'm guessing apps that rely on this get hosed when
>people use Firefox. So maybe Mozilla would like to provide an
>HTTP lib on Windows that shares state with Firefox, or something.
>No idea though.
>
> Havoc
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Online Desktop and GNOME 2.22

[John Stowers]

On Nov 22, 2007 6:40 AM, Alp Toker <[EMAIL PROTECTED]> wrote:

> Colin Walters wrote:
> > On Tue, 2007-11-20 at 15:23 -0200, Pedro de Medeiros wrote:
> >
> >> That's all very interesting, but what about a better integration
> >> of on-line applications in the desktop environment like regular
> >> applications? Have you seen, for instance, prism?
> >>
> >> http://labs.mozilla.com/2007/10/prism/
> >>
> >> I think this is a very simple idea, and also a good match for a
> >> on-line desktop project.
> >
> > I agree, and blogged about this last month:
> >
> > http://cgwalters.livejournal.com/9706.html
> >
>
> There's no need to look far and wide for this kind of functionality.
>
> We've already got a sleek and powerful browser component built around
> GLib and GTK+ whose sole purpose is integration with the desktop:
>
>   http://live.gnome.org/WebKitGtk


Just to broaden this discussion a little

I recently tried Pagico [1] (which is a cross platform personal organiser).
AFAICT (its closed source) Their approach to cross platform development
seemed to involve writing the application in PHP and then starting apache to
serve it. The app is then a thin-ish wrapper around firefox/gtkmozembed
widget that connected to http://localhost:port

My question is, do we want to encourage this sort of development in GNOME,
and if so, how?.

For example, the new shiny HTML5 client db stuff in webkit [2] will go some
way to allowing desktop apps to be written in HTML/JS and then run inside a
light webkit shell, but can we do better. What about
* A simple way to start a webkit browser widget associated with a private,
standalone httpserver? - might be necessary if someone wants to write apps
in PHP/some other server side language
* Some way to communicate gtk-isms/function calls from the html/js app to
the desktop. For example, I have previoulsy acomplished this (in
pygtkmozembed) by
1) encoding  gtk function calls as javascript status messages
2) catching on_status_changed and then reecreating the call
Can webkit facilitate some sort of Gtk/GNOME javascript binding?

Anyway, somthing else to think about

John

[1] http://www.pagico.com/
[2]
http://webkit.org/blog/126/webkit-does-html5-client-side-database-storage/

> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Online Desktop and GNOME 2.22

[John Stowers]

On 11/2/07, Colin Walters <[EMAIL PROTECTED]> wrote:
> John Stowers wrote:
> > But at the moment this particular 'PDA' requires a different way for
> > it to be connected. As I explained earlier, the other 'PDA's we
> > support are either connected(), disconnected(), or we ask for the user
> > to connect them (log in) while we wait. I am interested in providing a
> > consistant way for users to connect their 'PDA's (log in) and I do
> > this by either using programmatic login (gdata for example), or asking
> > them to log in using our simple browser login. online.gnome.org doesnt
> > seem to support either of these scenarios, requiring  a different
> > connection procedure to everyone else.
> >
> > I am really interested in thinking about how to integrate sync into
> > the desktop.
> >
> So I'm planning to spend some time next week taking a look at how we can
> clean up some of the web service authentication in the desktop.  Here's
> a wiki page with some initial thoughts:
> http://live.gnome.org/OnlineDesktop/WebAccountSystem

Cool, sounds good. As I said, the site-specific-browser thing works
quite well. For WebAccountSystem, when the user logs into something,
you might want to consider doing that login with a small ssb - I find
doing so differentiates the process and makes it more obvious to the
user that their action results in a ssb being shown. Launching the
system web browser to log in may result in 1) a new firefox tab 2) new
firefox window 3) new/restore firefox session.

The ssb thing seems more deterministic. You could make the ssb clearly
"Gnome Online Desktop Login" branded. Once all the other things you
mention are sorted out then you should have no problem propagating the
login info from the ssb out to the system browser and the desktop.

[snip]

>
> As Owen said, basically the way we'd thought login to online.gnome.org
> would work is that some part of your desktop (say the personalized
> application launcher) tells you you need to log in, and you click there
> to do so.
> I'm not sure at the moment what conduit would be syncing to/from
> online.gnome.org.

Pretty much anything we currently sync through an intermediary and
that is not a big binary file;
 * Application prefs (we have had our own settings/gconf sync for a while)
 * Tomboy notes
 * Contacts
 * Calendar info
 * Small files (/me ducks)

John

>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Online Desktop and GNOME 2.22

[John Stowers]

>
> [ excellent detailed description omitted ]
>
> What if you don't think of online.gnome.org as a web service; what if
> you think of it like a PDA someone plugged into their USB port?

Excellent!

Apologies if I mis/over-interpret your analogy but this is EXCATLY how
I think about online.gnome.org

Let me explain, because I think we have both build sufficiently large
hammers so now everything looks like a nail. Here goes my nail
story...

Conduit already supports synchronization of many types of data (files,
photos, contacts, calender, settings, notes, text) to many different
kinds of 'PDAs'/$WEBAPPS. In this way I think of online.gnome.org as
JUST ANOTHER 'PDA'[1]  (dataprovider) that we want to support and we
want to support it well.

But at the moment this particular 'PDA' requires a different way for
it to be connected. As I explained earlier, the other 'PDA's we
support are either connected(), disconnected(), or we ask for the user
to connect them (log in) while we wait. I am interested in providing a
consistant way for users to connect their 'PDA's (log in) and I do
this by either using programmatic login (gdata for example), or asking
them to log in using our simple browser login. online.gnome.org doesnt
seem to support either of these scenarios, requiring  a different
connection procedure to everyone else.

I am really interested in thinking about how to integrate sync into
the desktop.

So now its your turn, what if you dont think of conduit as 'just
another sync app' and start to think of it as 'the correct way to sync
things to not just online.gnome.org but to other PDAs'.

Regards

John

[1] If online.gnome.org gets wider acceptance then it might make sense
for it to be the default 'PDA' for certain types of data, but thats a
discussion for another day.

>
> - Owen
>
>
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Online Desktop and GNOME 2.22

[John Stowers]

Hiya,

> > b)
> > There is no way to login to programatically to online desktop using
> > either the dbus api or another manner. This is different to many many
> > other web apis and makes it difficult to reliably use the api from
> > outside mugshot.
>
> I don't quite understand this point. The general idea is that the user
> *is* logged on, and we barely even support logging out ;-) The general
> expectation would be that not being logged in is pretty much the
> same as being not connected to the internet.
>
> But assuming that we fix the lack of a working log out UI, I could
> see the need for a D-BUS API to backend a dialog:
>
>  "Conduit needs you to be logged in to online.gnome.org to
>   perform this operation. Log in now?"
>
> [ Cancel]  [ Login ]
>
> Where Login would prompt you for authentication. Is this the kind of
> thing you are looking for?
>

OK. Let me explain what we have in conduit. We support lots of
webservices in conduit, which means we have login code and experience
for each one. As it turns out, most web login systems fall into two
categories and require very little login logic. The two types of
logins are;

a) The ability to log in programatically. Call methodFoo(secretKey) on
the server and get back a authentication frob to use in all subsequent
calls
b) Two step login. e.g. call methodLogin(user) on the server, which
brings up a web browser, you log in then you call
methodGetFrob(username) and you get your magic frob. Frob does not
always equal a cookie IIRC.

a) doesnt involve web-login-driver and/or ddm at all. Its not needed
(beyond the 'what is my username on this service' type config we
already discussed)

My problem with the current implementation is that is doesnt reliably
solve B in all cases. For example - we are concerned with the
initial[1] login experience in conduit. Lets say you want to upload
some photos to $WEBAPP from eye of gnome (i.e. you may treat Conduit
as  a DBus service - dont even start its gui). The first time the user
ever does this they need to login to said $WEBAPP using a browser. If
that is the case, it allows us a much cleaner [2] experiece if Conduit
pops up a small site-specific-browser to allow the user to log in,
rather than starting firefox which has its own problems, its hugeness,
it not reliably getting the users attention, 26 other open tabs,
session saver extension/restore previously crashed session,  etc [3]).

[1] The 'initial' experience actually happens quite a lot for some
webservices - for example box.net logins only stay valid for a few
hours. This means that you must re-login to the webservice almost
every day. If this is the case it seems convoluted to go with the
mugshot approach - switch to a browser, login, wait for it to pick up
the cookie, get the cookie from mugshot, turn the cookie into a from
that the box.net api needs (is this even possible in the general
case?)

[2] Their are some other hairy things here like there is no way to
reliably start a new browsing session that blocks the caller (which is
needed because many webservices invalidate the login if you call
getFrob() before the user has logged in).

So to come back to your question - I dont really want a seperate login
dialog for online desktop (at least not as the final solution), I just
would like online desktop to offer a login process that is more
similar to all other $WEBAPPS and that allows a consistant login
experience when authenticating, whether for the 0th, 1st, or nth time.
And if we do have to authenticate then at least give us the option of
not starting the whole system browser to do a simple 2 second login.

Until something like a or b is possible Its a bit hard to make
conduits round peg fit into online desktop square hole - especially
when all other webservice login methods have roundish holes or holes
of an oval nature.

I know you think of online deskop as different, a always logged in
type scenario, but that doesnt fit my use-case for it, and becomes
even hairier when I cant get it to consistantly log in.

I would really appreciate if you could check conduit out from SVN and
play with how it logs into things using its built in web browser for
and idea of what I mean [3].

[3] caveat: as I mentioned in my blog post, SVN head is a bit rocky atm.

> > c)
> > Continuing on from the above point, the current method of monitoring
> > and parsing the cookie file to log in, while cute, is not something I
> > totally grok. While I see the point of it all (login once, and then
> > access the services from any app) It never gets close to solving the
> > real problem, sharing authenticating information from the browser with
> > the rest of the system. web-login-driver is neither here nor there as
> > a solution, it adds another running daemon for very little benefit, as
> > the final step in the process (rewriting the cookie file so the
> > browser can pickup external logins) is not implemented.
>
> I think you are mixing togethe

Re: Online Desktop and GNOME 2.22

[John Stowers]

Hiya

After spending some time trying to integrate Conduit with
online-desktop lately, I thought I should share my thoughts.

a)
The build provess for hippo
(http://svn.mugshot.org/dumbhippo/trunk/client) is overly complex on
account of things for windows and osx in there. This includes a
dependency on firefox and a huge bunch of statically built libraries.
This seems a bit excessive.

b)
There is no way to login to programatically to online desktop using
either the dbus api or another manner. This is different to many many
other web apis and makes it difficult to reliably use the api from
outside mugshot.

c)
Continuing on from the above point, the current method of monitoring
and parsing the cookie file to log in, while cute, is not something I
totally grok. While I see the point of it all (login once, and then
access the services from any app) It never gets close to solving the
real problem, sharing authenticating information from the browser with
the rest of the system. web-login-driver is neither here nor there as
a solution, it adds another running daemon for very little benefit, as
the final step in the process (rewriting the cookie file so the
browser can pickup external logins) is not implemented.

The whole thing seems to depend on firefox/gecko quite heavily. How
does this fit in with gtk/webkit?

In conduit I use a simple site-specific-browser based on gtkmozembed
to log people into web services. mugshot can never see this login
because 1) I cant tell it about the embedded browsers cookie file
and/or 2) the above problems about not properly sharing logins between
all browsers means once I log into a site using the ssb, mugshot does
not propogate this login info to other browsers (for the reasons
mentioned in c) and being unable to rewrite browsers cookie files
underneath them and have them pick it up

d)
The mugshot GUI runs in the same process as data-model-engine. I
realise you are working to remedy this. It would be good if apps that
might be interested in the info on the gnome servers (gimmie and
conduit for example) didnt need to have mugshot gui running.

e)
Can you explain the relevance of pyddm if one can communicate with
data-model-engine over DBus to acomplish the same functionality?

f)
Work is ongoing in Conduit to make it play nicely with OD. We should
have some things to show soon (minus gross login hack due to b+c. Lets
talk about standard places in online desktop where we can store
peoples login names to different sites (i.e what is my flickr
username). This is probbably a documentation issue where object paths
and such just need to be spec'd out somewhere.

g)
Lets get some thoughts from the security folks on if it makes sense to
(for example) store private information on online.gnome.org using
http/https authentication

h)
Another canvas library (yes Its staticly built, and yes I am also
guilty of using another canvas lib - goocanvas) but how is the gtk
canvas unification/blessing process going?. As an aside I guess this
becomes a non-issue if d is solved

Anyway, apologies if any of these points appear negative. I totally
agree with the ideas of online desktop, I just disagree with some
points of its implementation

John Stowers (conduit developer)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list