gmane.comp.gnome.desktop

Introducing Calendar

Erick Pérez Castellanos — 2012-05-24T18:26:47

Hi:

Some time ago I started coding Calendar application for Gnome as
sketched here[1]

Currently the application does some pretty simple stuff,  like showing
the events of calendars suscribed in Evolution for the actual month.
The rests of the views has to be added/coded yet, but I think the
architecture design is almost completed.

The code is hosted for now at Github[2] cause doesn't have a release yet
as stated here[3], anyway I'll talk with the admins of git.gnome.org

Now, the call for help is for someone on the Design Team to step
forwward to take care of the design parts of the development since I
must confess I'm pretty bad at that, and I have some concerns with the
mockups posted on the wiki.

So, I'll keep up updated.


[1]: https://live.gnome.org/Design/Apps/Calendar
[2]: https://github.com/erick2red/gnome-calendar
[3]: https://live.gnome.org/ProjectPrerequisites

Introducing libzapojit

Debarshi Ray — 2012-05-23T15:51:45

Hello everybody,

I have been working on a GLib/GObject wrapper for the Skydrive and Hotmail
APIs: https://www.gitorious.org/libzapojit

At the moment its dependencies include json-glib-1.0, rest-0.7, libsoup-2.4
and goa-1.0. If required, goa-1.0 can be made optional.

I would like to move it to GNOME infrastructure and make a release in time for
3.5.2. I intend to use it to support Skydrive in gnome-documents:
https://bugzilla.gnome.org/666535

Happy hacking,
Debarshi

First release of Evolution-ActiveSync (v0.92) for Evolution 3.4

David Woodhouse — 2012-05-22T14:06:52

It's syncing to download.gnome.org slowly, but for now is available at
ftp://ftp.infradead.org/pub/activesyncd/evolution-activesync-0.92.tar.xz
ftp://ftp.infradead.org/pub/activesyncd/evolution-activesync-0.92.tar.xz.asc

This is now updated to work with Evolution 3.4. As before, this package
contains the core dæmon for communication with the ActiveSync server, as
well as a Camel back end and Evolution EPlugin for configuring it.

SyncEvolution modules for calendar and addressbook synchronisation are
part of the SyncEvolution repository. We don't have 'direct' Evolution
calendar and addressbook back ends yet, although that would be nice.

Redesign Gnote as Notes?

Aurimas Černius — 2012-05-20T16:44:26

Hi all,

I like the idea of Notes in general:
https://live.gnome.org/Design/Apps/Notes

I think we could transform Gnote into Notes. I made some initial
proof-of-concept, you can see results here:
http://aurisc4.blogspot.com/2012/05/notes-demo.html

This is of course only an initial work, but I'm willing to continue it.
Any comments/ideas?

live image

Ray Strode — 2012-05-17T20:55:51

Hey,

I put together a live image with a jhbuild built in it here:

http://ftp.acc.umu.se/pub/gnome/misc/testing/GNOME-3.5.1-LiveUSB.iso

You can write the image to a usb stick with this command:

sudo dd if=GNOME-3.5.1-LiveUSB.iso of=/dev/DRIVE bs=8M conv=fsync

(where DRIVE is a usb stick, probably /dev/sdb, but could be something
different, so be careful!)

It's a little hacked together, at the moment.  I'd like to get the
process I used more refined and potentially automated so we can do
testing more easily and regularly through the development cycle.

One thing, that makes this image less than useful in virtual machines
is a bug in software rendering.  Adam Jackson,
has a cogl workaround here:

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

But that patch isn't applied, so this image doesn't work great in
virtual machines.  Hopefully that will be resolved soon.

--Ray

Tomboy Replacement???

Adam Lechowicz — 2012-05-15T20:43:53

Hello GNOME Developers,

I would like to ask you if you are in need of a Tomboy Notes
replacement. As you may know, many large distros have stopped using
Tomboy Notes because of the large amount of dependencies needed to run
it. To be exact, here is a terminal output from Debian's "apt-get"

Reading package lists... Done
Building dependency tree      
Reading state information... Done
The following extra packages will be installed:
  binfmt-support cli-common libappindicator0.1-cil libdbus-glib1.0-cil
  libdbus1.0-cil libgconf2.0-cil libgdiplus libglib2.0-cil libgmime2.6-cil
  libgtk2.0-cil liblaunchpad-integration1.0-cil libmono-addins-gui0.2-cil
  libmono-addins0.2-cil libmono-cairo4.0-cil libmono-corlib4.0-cil
  libmono-i18n-west4.0-cil libmono-i18n4.0-cil libmono-posix4.0-cil
  libmono-security4.0-cil libmono-sharpzip4.84-cil
  libmono-system-configuration4.0-cil libmono-system-core4.0-cil
  libmono-system-drawing4.0-cil libmono-system-security4.0-cil
  libmono-system-xml4.0-cil libmono-system4.0-cil mono-4.0-gac mono-gac
  mono-runtime
Suggested packages:
  monodoc-gtk2.0-manual libmono-i18n4.0-all libgamin0 evolution tasque
The following NEW packages will be installed:
  binfmt-support cli-common libappindicator0.1-cil libdbus-glib1.0-cil
  libdbus1.0-cil libgconf2.0-cil libgdiplus libglib2.0-cil libgmime2.6-cil
  libgtk2.0-cil liblaunchpad-integration1.0-cil libmono-addins-gui0.2-cil
  libmono-addins0.2-cil libmono-cairo4.0-cil libmono-corlib4.0-cil
  libmono-i18n-west4.0-cil libmono-i18n4.0-cil libmono-posix4.0-cil
  libmono-security4.0-cil libmono-sharpzip4.84-cil
  libmono-system-configuration4.0-cil libmono-system-core4.0-cil
  libmono-system-drawing4.0-cil libmono-system-security4.0-cil
  libmono-system-xml4.0-cil libmono-system4.0-cil mono-4.0-gac mono-gac
  mono-runtime tomboy

As you can see, Tomboy needs an obscene amount of packages simply to
run. 28 packages to be exact, most of them mono libraries. I have a
solution. My application, Notey, only needs GTK 3 and
python-quickly.widgets to run without a problem on most systems. Notey
is fast, simple, and cutting edge. It uses PyGTK as a backend, and has
been submitted to the Ubuntu Software Center as a free app. Notey is
currently in beta, however the app is completely stable, free of bugs
(As far as I know) and only includes a few menu items that don't work.
You can check it out at:

http://nextgennotetaking.webs.com/

                                                                        
                ~Adam Lechowicz,
                                                                       
                        Developer, Notey
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list< at >gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

application menu design - contributing to the wiki on live.gnome.org

Pigeon Lips — 2012-05-09T04:00:53

Hi All,  a very friendly person on the gnome IRC put me on this mailing
list.

Long story short i wanted to add an article to your design wiki
https://live.gnome.org/Design/Playground but thought it best to run it by
someone first.

after reading this https://live.gnome.org/Design/Whiteboards/Menus i was
inspired by the mega menu. I would like to try a mock up of extending this
concept further and wanted a place to post my thoughts, mock ups and
suggestions on how a nice mega menu could be extended via search and
context driven actions.

Is this an ok thing to do, or do i need to flesh out the idea here first ?

thanks.
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list< at >gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

For newcomers / IBus/IM users: RULES FOR THIS LIST

Olav Vitters — 2012-05-15T17:13:06

Just as a short introduction:

You can discuss pretty much anything on this list as long as it follows
a few rules (from https://live.gnome.org/CodeOfConduct):
* be constructive
  Weird comparisons and so on are not constructive (KDE, GNOME 2,
  dictators, etc).
  Stating that something is bad *not* constructive (explain *why* it is
  bad).
* be polite
* assume people mean well
  nobody is out to make your life difficult. Explain what you need out
  of an IM, what it should do. That'll result in developers making a
  better decision.
* be respectful and considerate
  Even if the other person is not. Contact me if you dislike a certain
  message. I have the abilities to act.
* try to be concise
  sending loads of emails or very long ones (needlessly so) will just
  result in people ignoring or missing what you mean
* be patient and generous


I'm the person who can administrate the list. I highly enjoy
discussions. People can disagree all they want. Always interesting to
learn more.

However, if above rules aren't followed I *will* step in. Again, this
won't be related to your opinion.

another 3.6 feature: harfbuzz

Matthias Clasen — 2012-05-15T12:06:22

After talking to Behdad last weekend, I've filed another 3.6 feature
page for the long-awaited move to harfbuzz 1.0.
It took a long time, but it is finally going to happen this cycle.

For more details, see https://live.gnome.org/ThreePointFive/Features/Harfbuzz

gnome goals for 3.6

Matthias Clasen — 2012-05-15T04:31:31

At the release team meeting last weekend, we've discussed that we want
to revitalize the Gnome Goals [1] effort by adopting a few goals for
this cycle. We've chosen the following goals:

GSettingsMigration
XDGConfigFolders
PortToGtkApplication
PortToGMenu
RemoveMarkupInMessages

The first two are actively being worked on currently, and we should
just get them done instead of dragging this out further.
The next two will make our applications appear more consistent and GNOME 3 like.
The last one was included because we want to include our translators,
and make their life easier by improving the quality of our strings.

The challenge is to complete these goals for the GNOME 3.6 release.

This is a great way to get involved if you are new with GNOME development.
There are several ways in which you can help us to reach that goal:

- determine that a module is not affected by the goal and mark it as
'not needed'
- determine if a module has already been fixed, aand mark it as 'done'
- write a patch for an affected module, link to the bug and mark the
module as 'patch available'
- if you are a module maintainer, review and commit patches for these goals

Lets do this !


Matthias

[1] http://live.gnome.org/GnomeGoals

Some points about IM integration

Owen Taylor — 2012-05-14T23:27:55

In general, choice of input method framework is not a goal in itself.
If we choose a single input method framework to integrate with GNOME -
that doesn't make GNOME like proprietary software from Apple and Microsoft,
because GNOME will still be 100% Free Software, and will still be developed
in the open by the GNOME community.

GNOME doesn't want to work well just for tweakers and enthusiasts - it's
very important to the project that GNOME works well for all users without
tweaking. We want to give the choice of using Free Software to
everybody - this is a much more fundamental form of choice than giving a small
group of users the ability to swap out a different input method framework
underneath GNOME.

GNOME isn't just a set of parts that a Linux distributor takes and uses
to create a working system - we also take responsibility for creating
a fully working system. This means deciding how GNOME interacts with
system components like sound and networking and printing and when necessary
enhancing those components to provide the right experience to the user.

So we can't leave it up to one Linux distributor to combine GNOME with
fcitx to make a version of GNOME that works well for zh_CN and another
Linux distributor to combine GNOME with RIME or hime to make a version
of GNOME that works well for zh_TW. We want GNOME to, without customization,
work well for zh_CN, zh_TW, hi_IN, ru_RU, en_US, and so forth.

Of course, it would be a mistake to think that a small group of English
speaking developers could make GNOME work well in all these languages. That
would be impossible! But from experience, we know that simply leaving a
problem like this to external developers and hoping for the best doesn't
work out well. Instead we need to engage users and developers from these
language communities into the GNOME development community.

I don't want to minimize how easy that is - I know there are very significant
barriers of language, timezone, and distance that make this hard. I know
that bugs get ignored and patches sit around unreviewed. But still,
active engagement is the only way forward. I think it's absolutely wonderful
how many people have gotten involved in the current discussion!

We also need to keep in mind that we aren't talking about the choice of input
method, we are talking about input method *frameworks*. The basics of passing
events from application to daemon, loading different input method backends,
handling hotkeys and displaying feedback are going to be very similar for
all East Asian languages.

Things like displaying feedback may be a little different if we move further
afield to Thai or Hindi - but still, there is no fundamental reason that they
need a different *framework*.

Using a single input framework for all GNOME users has many benefits.
GNOME developers can reproduce bugs that users run into. Bugs only have to
be fixed once, not in multiple frameworks. We can actually figure out how
to make input methods work with onscreen keyboards and accessibility. Our
designers can collaborate on making the configuration dialogs conform to
GNOME standards.

Finally, using a single input method framework is pretty much essential to
the goal of allowing users to configure languages at runtime with a nice user
interface. If language A and language B require different input method
*frameworks*, there is no way that the user can switch between them with a
hotkey.

In general, I don't see standardizing D-Bus interfaces so that GNOME can
work with multiple input method frameworks as being a useful activity.
If the D-Bus interfaces are carefully maintained and changed only with
agreement and advanced notice, then they will impede the progress of bug
fixing and making things better. If the interfaces are not carefully
maintained, then they aren't standards at all, and users will constantly
encounter breakage.

And in any case, as described above, there has to be *one* framework that
works as well as we can possibly make it for all users. Multiple partially
working frameworks are not a substitute.

All of the above is an argument only for picking a single input method
framework. It doesn't say anything about what input method framework we
should pick. The fact that the IBus developers have been engaged with
GNOME for quite some time and are willing to work with us to create a user
experience that is simple and consistent with the GNOME principles is
certainly a big plus, but we do need to make sure that the end result
works well as well as looking good.

- Owen

kind note on quoting

Andy Wingo — 2012-05-14T20:03:51

Hi,

There has been a lot of traffic on d-d-l recently.  That's great.  It's
a bit difficult to follow though, at times.  It would be really helpful
to a casual reader if, when replying, people would trim the parts of the
mails that they are quoting.

Cheers,

Andy

TARBALLS DUE: GNOME 3.4.2

Frederic Peters — 2012-05-14T07:06:01

Hello all,

It's time to get off your development branch for a bit, contemplate
the tenacious work of our translators, cheer on our documentation
team, remind yourself of the important fixes you cherry picked, write
a nice entry to your NEWS file, and upload a nice new stable tarball.

Tarballs are due on 2012-05-14 before 23:59 UTC for the GNOME 3.4.2
stable release, which will be delivered on Wednesday. Modules which
were proposed for inclusion should try to follow the unstable schedule
so everyone can test them.  Please make sure that your tarballs will
be uploaded before Monday 23:59 UTC: tarballs uploaded later than that
will probably be too late to get in 3.4.2. If you are not able to make
a tarball before this deadline or if you think you'll be late, please
send a mail to the release team and we'll find someone to roll the
tarball for you!

For more information about 3.5, the full schedule, the official
module lists and the proposed module lists, please see our colorful 3.5
page:
   http://www.gnome.org/start/unstable

For a quick overview of the GNOME schedule, please see:
   http://live.gnome.org/Schedule


Cheers,

        Frederic

Gnome 3.4 / Anjuta / Scintilla Plugin

Lanoxx — 2012-05-12T16:47:45

Hi,

I just updated to gnome 3.4 and then fired up Anjuta to fix all those 
applets in my gnome-panel that have become broken after the update 
(which sadly is most of them). But to my surprise I can not use the 
scrollwheel in to scroll up any more. When I scroll down everything is 
fine, but when I want to scroll backup, then the editor is flickering 
for a short moment but does not scroll up. When I switch to the 
gtksourceview editor then there is no problem?

Is it a known bug? Any work arounds known?

Best
Regards
Lanoxx

Sharing widgets between GNOME 3 applications

Debarshi Ray — 2012-05-07T13:45:08

The newly designed (or redesigned) GNOME 3 applications have some
common UI elements. For example, if you look at the following designs,
you will notice that the main toolbar, "selection" toolbar, main icon
view, etc. are quite similar: +
https://live.gnome.org/Design/Apps/Boxes +
https://live.gnome.org/Design/Apps/Documents +
https://live.gnome.org/Design/Apps/Photos

We may benefit from having a way to share these widgets among the
applications.  Currently, what I have been doing, for gnome-photos, is
to copy-paste the *.c/*.h files from the gnome-documents tree.

One downside of doing this is that the gnome-photos binary has some
dead code which will never be executed. For example the code path that
implements the "list view" for Documents, which is not necessary for
Photos. So all the classes implementing it need to be copied over into
the gnome-photos tree to avoid maintaining a fork of the GdMainView
widget.

Currently it is not so much of a practical problem, but I am curious
to know if people have better ideas about this.

Happy hacking,
Debarshi

Please check your sources for strings not marked for translationbefore release

Kenneth Nielsen — 2012-05-07T11:59:45

Hallo developers.

Since the release of GNOME 3.4 we have received a steady stream of 
emails saying "This is not a string freeze break, we just forgot to mark 
the strings for translation". So much so, that the statistics e.g. for 
my language (which has not been touched since release) now counts 63* 
untranslated or fuzzy strings in a source that was at 0 at release time, 
three weeks ago.

I understand the reason for not counting marking existing strings as a 
string freeze break. But please understand that even though you are in 
your right to fix things like this post release, and even though it off 
course makes sense to do it, it does not mean that it is not annoying 
and a burden for translators.

The reason for this is that we concentrate large amounts of work in the 
period just before release (where string changes are relatively quiet), 
so therefore it is also an advantage for us if we can finish as much of 
it as possible in that period (of course also because a lot of us has an 
extra hat as distribution translators for distributions that follow 
within a month or so of the gnome release). On top of that, small 
updates are uncharacteristically expensive in a work/string-sense 
because they involve the same amount of emails back and forth for 
proofreading and git work.

So please... If you could make a bit more of an effort of checking your 
sources for non-internationalized strings before release that would be 
great. IMHO 63 is just a bit on the high side of where this number should be

Regards Kenneth

* These 63 off course also include genuinely new strings due e.g. to bug 
fixes.

Introducing Photos

Debarshi Ray — 2012-05-04T15:24:38

Hello everybody!

Around 10 days ago I started implementing Photos as laid out in these designs:
https://live.gnome.org/Design/Apps/Photos

The Git tree is at: http://git.gnome.org/browse/gnome-photos

Currently the application does not do much other than showing a blank window,
but most of the underlying plumbing is in place and from here on I expect the
program to start becoming useful.

A guiding principle of mine has been to share as much of the UI code and the
basic structure of the application with Documents. Documents and Photos have
a lot in common, and even though one is not going to be a clone of the other,
it makes sense not to reinvent the wheel.

Why u no like Javascript?!
--------------------------

I toyed with the idea of writing Photos in Javascript. However, after spending
an evening fighting with a Python 3 / gobject-introspection based application
and failing to get anywhere, and the fact that I am not familiar with all the
ins and outs of GJS, I decided to stick with something that I know inside out.

Having said that, the custom widgets written for Documents are written in C,
so we just copy them over into the Photos tree. Also, the relevant widgets
from Eye of GNOME, if required.

This brings us to ...

Eye of GNOME, GThumb or Shotwell
--------------------------------

It is my understanding that Jon had discussions with the developers of these
applications, and for various reasons it was decided that writing something
from scratch is better. For EoG and GThumb the reason given was that their
maintainers did not have time to work on a major redesign, and for Shotwell it
was an architectural issue with the program.

Please feel free to correct me if I am misrepresenting something. :-)

Future plans
------------

At the moment I am not going to push Photos as a widely publicized feature for
GNOME 3.6, but I do expect it to be functional in a "preview release" sort of
way.

Will keep you informed as things unfold.


Happy hacking,
Debarshi

Introducing realmd

Stef Walter — 2012-05-04T12:35:09

Hey guys,

As part of the User Identities work [1] I've made a new DBus system
service called realmd (pronounced realm-DEE) which manages setup of
Active Directory or Kerberos logins on the machine.

I posted more info to the XDG list:

http://lists.freedesktop.org/archives/xdg/2012-May/012385.html

The source code is hanging out here for now:

http://cgit.freedesktop.org/~stefw/realmd/tree/

In the future the plan is for gnome-control-center to use the DBus
interfaces provided by realmd [1].

Cheers,

Stef

[1]
http://cgit.freedesktop.org/~stefw/realmd/tree/dbus/org.freedesktop.realmd.xml

Reviewed-By: and pastebins

Colin Walters — 2012-05-03T16:00:14

Hi,

One of my goals for 2012 is to increase the number of patches I'm
reviewing myself, and more generally, even further increase the
percentage of patches that go into GNOME that have peer review.

git-bz and splinter make this flow fairly good, however for trivial
patches, especially when multiple developers are online at the same
time, it can be highly convenient to use a pastebin, then on IRC
another developer says "ok".

In this scenario, I don't want to lose the critical information that the
patch has been reviewed (and who reviewed it).  So here's the proposal:

When doing the pastebin+IRC approach, the person committing the patch,
if they have given it a non-superficial review, should add the tag:

Reviewed-By: Jane Doe <janedoe< at >example.com>

to the git commit.  This should mean exactly the same as it does
in the Linux kernel's use:

http://kerneltrap.org/mailarchive/linux-kernel/2007/10/8/332384

If patches have gone through bugzilla (as many nontrivial patches
should), then it's not necessary to add the tag in the git commit as
well, as long as the link to bugzilla is maintained, the information
is stored there.

Opinions?

Gnome 3 issues

surma — 2012-04-27T06:40:22

Hello,
On to the point.
Why did you screw up gnome menus?
I've
been using gnome since 2000, and it
has been the best desktop
available until gnome 3
came. I had a terrible car accident 31. Dets
2005,
which caused me to spend 6 months in coma.
That messed up my
hands and I can't use mouse.
That is why I liked gnome 2, everything
could be done
without mouse.
And strange is ... why does
virtualbox have normal
menus, but real PC has this big mouse
controlled
menu??
VBox gnome 3:
http://www.hot.ee/surma/Vbox_gnome3.jpg
But real computers have this
crappy
menu:
http://blog.fpmurphy.com/blog-images/gnome3cust1-40.png
Here's
an idea:
Maake it so, under gonf-editor you can choose the layout of
the menu.
-Surma_______________________________________________
desktop-devel-list mailing list
desktop-devel-list< at >gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Feature Proposal: finding and rediscovering shared links

2012-04-19T14:38:20

Ben, Peter, and Bruce share links to interesting articles and videos and
sometimes they can't check it, like if Bruce is in a meeting or out and
about on his phone, but if his computer also kept track of the link in IM,
then he could look at it then.

So one thing is that Bruce is unavailable to look/read/watch something, so
defering it to later is an option. Another is if Bruce is looking at
something and needs to come back to it. E.g:
Someone sent Bruce a link to bugzilla and Bruce remembers that he wants to
check on it and do stuff w/ the bug, but 2 or 3 days later or the next week
he asks himself where "where was that bug again?".

Seperating those links into links one has NOT been to yet, but are in
messages, are even more interesting.

It would be nice to see a recently encountered link view, where the user
can see can see a list of links shared with the him.

E.g: Sometimes Ben asks Bruce about some link he shared with him. It would
be nice if Ben could just find it based on the content of the link and
links they shared (sometimes he's not sure it's Bruce, but it's most likely
Bruce)
Bruce could use that same tool to look at links he shared with Ben: "What
was that page of that JavaScript library that does the animation thing that
you sent me a few months ago?"

That happens a good bit, not all the time, but often enough, since both
often share things with each other but one or the other of them forgets.
Some of the stuff they share is just for fun other things are useful for
work. And it's all mixed in together. Often, the funny and interesting
things are videos and then the work stuff has various keywords, like css or
javascript or such (and are usually not videos)

So a possible view for this feature can be done in Web: Links received can
then be automatically put in the queue of Web. And once visited can be
taken out of the queue.

Another possible view would be a dialog for sent/received links for the
Contacts application.

To sum it up: it would be appealing to have a readitlater queue without
explicit managing (well allowing that, and having those prioritized) as
well as having links sent through some direct mean (IM, mail) populate it.

One might argue that sharing happens via Social networks but a lot of it
happens via IM and E-mails too. The concept applied for both.

I have 2 mockups for this idea...
The first would blend in nicely with the current designs of "Web"
http://i.minus.com/ibfFpg4wMTscf0.png
The second would require adding a new view but has the advantage of
allowing a more interactive as well as informative (contextual) display of
the links http://i.minus.com/ibq81FRZb2iII4.png

Cheers
Seif
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list< at >gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list