Re: A little experiment: GNOME on wayland-only?

[Carlos Garnacho]

Hi!,

On Sun, Nov 24, 2019 at 2:14 PM Javier Jardón  wrote:

> Hi,
>
> This weekend I was curios about how difficult would be to have GNOME
> in a wayland-only system
>
> Thanks to building GNOME in a sandbox (thanks to buildstream and
> bwrap) and also thanks on using freedesktop-sdk as a base we can
> easily control the whole stack, so I started to experiment [1]
>
> Not sure how far we can go, but at least I'm discovering bugs and
> submitting some patches on the way (some of them are already
> accepted!)
>

If you still want to preserve X11 support, these modules do need to keep
linking to X11 components:
- mutter, so it can spawn Xwayland and serve as a X11 WM
- gnome-settings-daemon, as gsd-xsettings implements the Xsettings manager,
still necessary for X11 clients.
- gtk, as the X11 backend is used by both mutter and gsd-xsettings within a
wayland session

And if you look into misc. components:
- IBus, as it has a XIM implementation relevant to X11 clients
- Pulseaudio, to make ssh -X clients' sound work seamlessly

I do know that from the gnome-shell perspective, everything is paved so
that gdm may use --no-x11, but there's other aspects to it (eg. XDMCP) I'm
not sure can be simply thrown away, or integrated with Xwayland-on-demand.

Beyond that, AFAICT if other regular GNOME session services/apps indirectly
rely on X11 at build/runtime, it's an oversight.

There's been some work lately to have those misc components autostarted
transparently in a better manner for X11 clients, see
https://gitlab.gnome.org/GNOME/mutter/merge_requests/945 and the other
related MRs. After that there's IMHO little reason to have
xwayland-on-demand turned off by default :).


> At some point I would like to generate a parallel pipeline in
> gnome-build-meta so at least we do not regress on wayland-only support
> (and ideally we can create a parallel GNOME VM without X at all, who
> knowns!)
>

If you want to go that far, there's no support in g-s-d/mutter to build
without X11, should be reasonably easy for g-s-d, but it's still likely to
cause to some #ifdef proliferation in mutter.

Cheers,
  Carlos


>
> I'm keeping the progress here: [1] if someone wants to keep track
>
> Cheers,
> Javier
>
> [1] https://gitlab.gnome.org/GNOME/gnome-build-meta/issues/226
> ___
> 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: Tracker as a security risks

[Carlos Garnacho]

Hey Philip :),

On Mon, Dec 5, 2016 at 6:28 PM, Philip Withnall <phi...@tecnocode.co.uk> wrote:
> Hey,
>
> On Mon, 2016-12-05 at 16:42 +0100, Carlos Garnacho wrote:
>> On Mon, Dec 5, 2016 at 3:01 PM, Hanno Böck <ha...@hboeck.de> wrote:
>> > On Mon, 5 Dec 2016 13:44:40 +
>> > Sam Thursfield <sss...@gmail.com> wrote:
>> >
>> > > The design of Tracker takes the risks into account. Metadata
>> > > extraction is isolated in its own process (tracker-extract) which
>> > > can
>> > > crash without (theoretically) causing any harm.
>> >
>> > I don't see how that helps against security vulnerabilities.
>> >
>> > Having an isolated process probably helps in a way that a crash
>> > won't
>> > cause the whole tracker service to malfunction. Thus parsing broken
>> > files won't cause a service disruption. But as long as this process
>> > runs with normal user rights this doesn't protect in a security
>> > sense.
>> >
>> > > > I think there needs to be a wider discussion about this and the
>> > > > fundamental design choices done here need to be questioned.
>> > >
>> > > What questions do you have in particular?
>> >
>> > Quite frankly, I don't claim to have all the answers here, that's
>> > why I
>> > formulated it in an open "needs discussion" way.
>> >
>> > I think sandboxing the tracker parser (which you already indicated
>> > in your mail) is probably the most reasonable way to go forward.
>> > This
>> > isn't exactly my area of expertise, so I can't comment on which
>> > technique here is most promising.
>>
>> It indeed sounds possible to lift extraction into a separate process
>> with limited access to the filesystem, we essentially need to pass an
>> fd to mmap() and an output one to receive sparql back. There's just
>> two things to consider:
>>
>> - The extraction process sometimes needs access to misc files (eg.
>> CUE
>> files, XMP sidecar files, ...), those might be passed along too, but
>> then we need detecting those cases beforehand.
>>
>> - Ideally we wouldn't spawn one process per file being extracted,
>> although if we go to defcon 1 level of paranoia, that's probably what
>> should happen.
>
> I would suggest a single sandboxed extraction process, which has read-
> only access to the whole of ~/, and write access to the Tracker
> database. No network access. That means that regardless of whether or

All changes to the database must be managed by a single thread, which
currently resides in tracker-store, update requests are received via
DBus. So we wouldn't need write access to the database, but we'd need
a connection to the tracker-store process, direct or indirect.

> how the extraction process gets compromised, it cannot compromise the
> integrity of any of the files in your home directory (except the
> Tracker database, which I assume people aren’t too precious about), and
> it can’t compromise the confidentiality of any of your data (except by
> leaking it through the Tracker database — can we assume the database
> format is sufficiently prescribed to be able to prevent this?).

Well... it isn't. If you have readonly/readwrite access to
~/.cache/tracker/meta.db, you have such access to all of it, if the
attacker can do sqlite3_open(), it will bypass any artificial security
restriction we may set (eg.
https://www.sqlite.org/capi3ref.html#sqlite3_set_authorizer). Now,
readonly access to the database seems moot if all of ~/ is also
readonly, and with write access all you'd get is to tamper with the
database.

Readonly access to ~/ kind of concerns me, although might not be used
for any ransomware after all if the targeted file can't be encrypted
nor sent over the network, there seems to be little to do with the
knowledge that might be gained if it can't get out of the process
except over the pipe feeding tracker-store.

>
> This should be easily accomplished by using an AppArmor (or
> equivalently, SELinux) profile for tracker-extract. seccomp-bpf could
> also be used to achieve much the same thing, regardless of whether an
> LSM is enabled.
>
> The Apertis project has such an AppArmor file already, and it would be
> great if that were pulled upstream:
>
> https://git.apertis.org/cgit/packaging/tracker.git/tree/debian/apparmor
> .d/usr.lib.tracker
>
> (I am not claiming this profile is perfect, but it’s a start.)

Thanks for the tip :), worth a look indeed, although I'm looking into
using seccomp directly.

>
>> Anyway, this goes IMHO too much on the technical side for this ML, we
>&

Re: Tracker as a security risks

[Carlos Garnacho]

Hi,

On Mon, Dec 5, 2016 at 3:01 PM, Hanno Böck  wrote:
> On Mon, 5 Dec 2016 13:44:40 +
> Sam Thursfield  wrote:
>
>> The design of Tracker takes the risks into account. Metadata
>> extraction is isolated in its own process (tracker-extract) which can
>> crash without (theoretically) causing any harm.
>
> I don't see how that helps against security vulnerabilities.
>
> Having an isolated process probably helps in a way that a crash won't
> cause the whole tracker service to malfunction. Thus parsing broken
> files won't cause a service disruption. But as long as this process
> runs with normal user rights this doesn't protect in a security sense.
>
>> > I think there needs to be a wider discussion about this and the
>> > fundamental design choices done here need to be questioned.
>>
>> What questions do you have in particular?
>
> Quite frankly, I don't claim to have all the answers here, that's why I
> formulated it in an open "needs discussion" way.
>
> I think sandboxing the tracker parser (which you already indicated
> in your mail) is probably the most reasonable way to go forward. This
> isn't exactly my area of expertise, so I can't comment on which
> technique here is most promising.

It indeed sounds possible to lift extraction into a separate process
with limited access to the filesystem, we essentially need to pass an
fd to mmap() and an output one to receive sparql back. There's just
two things to consider:

- The extraction process sometimes needs access to misc files (eg. CUE
files, XMP sidecar files, ...), those might be passed along too, but
then we need detecting those cases beforehand.

- Ideally we wouldn't spawn one process per file being extracted,
although if we go to defcon 1 level of paranoia, that's probably what
should happen.

Anyway, this goes IMHO too much on the technical side for this ML, we
already have https://bugzilla.gnome.org/show_bug.cgi?id=764786 filed
to Tracker, and it's already high in my list for fixing on 1.12, feel
free to join there.

And I should add... Tracker is not alone here, if it's not Tracker
stumbling on infected content, with varying but still rather low
levels of interaction it may be a thumbnailer, a previewer like sushi,
or the web browser itself streaming content which hit this. So there's
more places in need of further isolation when dealing with untrusted
content.

And still, the chain is only as strong as its weakest link, as soon as
there is anything opening that file with wide enough permissions to
cause any harm, you're essentially screwed. This might sound like an
argument to running every app through flatpak, although I think the
long term answer always is "fix the vulnerability!".

>
>
> The other issue I think is that the quality of huge parts of the foss
> ecosystem needs to be improved. The good news here is that we got some
> powerful tools in terms of fuzzing (afl, libfuzzer) and memory safety
> bug detection (asan) in the past years. Ideally all free software devs
> should be aware of those tools and use them in their development
> process. I'm trying to help here where I can, see e.g. also my recent
> post on this list [1]. If our libraries would be better tested we could
> be more comfortable feeding it with untrusted inputs.

I agree some more active prevention would be positive, sounds like
something to tackle in the libraries dealing with file formats though,
Tracker is a strawman here, in the sense that filesystem extraction
it's only exploitable through its tracker-extract's modules, and those
are for the most part implemented using external libraries.

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

Re: Gnome "opt-in" functionality.

[Carlos Garnacho]

Hi,

On Fri, Sep 16, 2016 at 7:19 AM, Tomasz Torcz  wrote:
> On Fri, Sep 16, 2016 at 11:17:13AM +1000, Daniel Kasak wrote:
>> On my system, when I start gnome ( I usually use Enlightenment ), I
>> see both tracker and evolution processes taking about 192MB of memory.
>> I have 16GB of memory, so they're taking about 1.17% of my total (
>> chip ) memory. That's not really of concern to me.
>
>
>   That's good for you, although it's anecdotical evidence. On the other
> hand, on my system tracker exhaust all the memory in few hours:
> https://bugzilla.redhat.com/show_bug.cgi?id=1264131

Tracker-store's purpose is flushing all operations to disk ASAP,
there's just no reason why it should eat that much memory, besides
memory leaks.

>From reading the warnings in comment #1 there, it seems you're
affected by 
https://git.gnome.org/browse/tracker/commit/?id=6e42c641b8ed48a39a4e3dec9b4a138b8173ea94
, if you have tracker >= 1.7.3 you can do:

killall tracker-miner-fs && TRACKER_MINER_FORCE_CHECK_UPDATED=1
/usr/libexec/tracker-miner-fs &

or just:

tracker reset -r
tracker daemon -s

if you don't care much about the previously stored data. Either of
those will get you rid of these warnings.

But that alone doesn't explain the memory usage in tracker-store,
please file a bug to gnome bugzilla if you still get memory issues
after trying this.

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

Re: 3.20 target bugs

[Carlos Garnacho]

Hey,

(CCing the Tracker ML for this one)

On Thu, Feb 18, 2016 at 1:35 PM, Matthias Clasen
 wrote:
> While we are still waiting for 3.19.90 to appear, here is an initial
> review of the bugs that have been marked as "GNOME target: 3.20"
> during this cycle. Since this is the first review, the list is
> somewhat long, and a bit of a mixed bag, I expect us to narrow it down
> for .91. In any case, all these bugs are well worth fixing, and if you
> can get one of the off the list, you will make 3.20 a better release.
>
> Please help out if you can!
>
> Matthias, for the release team
>
>
>
> Fallout from GTK+ changes (CSS and others)
> --
>
> 761765 bijiben Notes have a grey background rather than a custom color
> 762137 nautilus GtkPlacesSidebar: row selection jumps around
> 760525 gtk+ Labels in dialog buttons misaligned
> 760560 gtk+ Icon buttons wider in GTK+ 3.19.6
> 757503 gtk+ Selected text is white on white (invisible) -
> WebKit1 / GTK+ 3.19.7 & Adwaita
> 761686 gtk+ GtkTreeView theming problems
> 758893 gnome-shell Journal spam: Gdk-WARNING **:
> gdk-frame-clock: layout continuously requested, giving up after 4
> tries
>
> Power / Battery life problems
> -
>
> 752070 polari polari uses a lot of cpu
> 762194 tracker Indexes on battery
>
> Deprecation cleanup & build issues
> ---
>
> 760887 NetworkManager Do not depend on deprecated libnm-glib
> or dbus-glib when we only want to build the new libnma library
> 760946 NetworkManager nm-connection-editor still uses dbus-glib
> 757934 gobject-intros g-ir-scanner should not use system-provided 
> CFLAGS
> 751588 evolution Port to WebKit2
> 751185 empathy Use clutter-gst-3.0
> 749001 empathy Port to webkit2
> 728293 bijiben Port to WebKit2 or GtkTextView
> 705069 gnome-music Port from dbus-python to Gio GDBus API
> 686373 general [META] Switch to WebKit2
>
> Accessibility regressions
> 
>
> 762136 nautilus Progress of file and folder operations is no
> longer accessible to screen readers
>
> Wayland issues
> ---
>
> 749913 mutter wayland: Send frame callbacks when native
> hardware cursors get set
> 760745 mutter 100% CPU : Error transferring wayland clipboard to 
> X11
> 762104 mutter handle dnd drops on the root window
> 760567 gtk+ GDK screen size does not count for HiDPI on Wayland
> 756579 gtk+ GTK should let GDK position menus
> 748098 gdm monitors.xml not working in GDM when running
> under Wayland
> 695806 general [TRACKER] Wayland support
>
> Crashes & serious misbehavior
> -
>
> 761613 mutter crash with xwayland glamor
> 761157 libsecret libsecret-0.18.4 seems to crash gnome-shell
> 755721 glib g_inotify_file_monitor_start called with
> nullpointer for dirname causes a segfault
> 761175 librsvg Svg rendering regression from commit 3ae509 onwards
> 750508 gnome-session Logout is broken (a) when session
> inhibitor is active and (b) after logout is canceled once
> 761317 gnome-settings-daemon housekeeping: /tmp/.X11-unix/X0
> socket gets removed during housecleaning

I would like to drop https://bugzilla.gnome.org/show_bug.cgi?id=762226 here.

In short, sqlite has hidden stuff that Tracker needs behind a compile
time option (disabled by default) because of security concerns, and
Tracker only stumbles on this at runtime.

AFAICT the security concerns come from arbitrary execution of SQL
being able to alter later queries by overriding the full-text search
tokenizer, so they don't apply to Tracker (our SQL comes from a
bizarre state machine, but doesn't qualify as "arbitrary"). Most
immediately, I'll add a configure time check for this feature,
although I don't think it's ok to advice distros to enable
fts3_tokenizer system-wide. Solutions I can think of are:

- Including a static copy of sqlite in Tracker, with fts3_tokenizer() enabled
- Updating to the newer but code-wise incompatible fts5 (we use fts4),
which provides other similar hooks we can use. It's probably too
bleeding edge though, it was considered "experimental" not long ago
[1], and I haven't seen a word saying otherwise in later release
notes.

In this situation, the second option is a matter of time, I'd just
wish there were a longer board to walk.

Cheers,
  Carlos

[1] http://sqlite.org/releaselog/3_9_0.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Possible data loss with Tracker 1.3.x

[Carlos Garnacho]

Hey everyone,

On Fri, Mar 6, 2015 at 1:43 PM, Bastien Nocera had...@hadess.net wrote:
 Hey,

 Tracker 1.3.2 and 1.3.3 had a bug that made them fail to start:
 https://bugzilla.gnome.org/show_bug.cgi?id=743727

 However, after 1.3.4 fixed that problem, we caught a bug in the
 database migration code added earlier that didn't get uncovered until
 now.

 Please refrain from using Tracker 1.3 if previous installations had
 Tracker 1.2 or earlier installed, as it will corrupt the database
 beyond repair:
 https://bugzilla.gnome.org/show_bug.cgi?id=745737

I rolled out 1.3.5 fixing this, please skip 1.3.4 entirely, previous
versions did fail/bail out before doing any harm to the database, so
should be safe.

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

Re: touch screen support

[Carlos Garnacho]

Hey Richard,

On vie, 2014-01-17 at 18:07 +, Richard Henwood wrote:
 Hi All,
 
 I have been using gnome 3.10 with a touch screen and gnome 3.8 with a
 stylus+tablet using absolute positioning.
 
 With both interfaces, I have the following pain points:
 
 + I can't access the bar at the bottom of the screen (gnome-shell?)
 that has the eject functionality etc. I typically get this by running
 the mouse off the bottom - which is not possible with a touch screen
 or stylus/tablet with absolute positioning.

That is a known problem... fixable when gnome-shell gets to handle
desktop-level gestures.

 
 + The scroll bars are tricky to use when I have a long list (like my
 email). A single pixel movement on the scroll bar can sometimes mean
 more than one new page of the list is displayed. Button at the top or
 bottom that support small increments do not exist.

Most scrollable contents in GTK+ applications should be touch-friendly,
with the notable exception of WebKitWebView based widgets. You should be
able to scroll by doing 1-finger touch atop the contents, not only
touching on the scrollbar. What hardware is that? Stylus+tablet sounds
Wacom, but that about the touchscreen? What xorg input driver are those
devices using? what email client is that?

 I would appreciate guidance on the first steps I can take to help the
 gnome touch screen support effort.

There's definitely a few rough points, you can check the general state
of things in https://wiki.gnome.org/Design/OS/Touchscreen , issues are
quite scattered as you see so there's a few ML and IRC channels involved
unfortunately, #gnome-hackers should have most of the involved people
around though.

Cheers,
  Carlos


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

Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4

[Carlos Garnacho]

Hey,

In order to provide some background to the ML, scroll events were being
sent to widgets with GDK_BUTTON_PRESS_MASK (no scroll mask required),
but this played odd with smooth scrolling as scrolled windows get scroll
events in 2 ways:

1) bubbled up from the child within
2) received directly via priv-overshoot_window, only if no child
handles scrolling

With the old behavior, 1) would happen on every widget that would handle
button presses, but not necessarily scrolling, so scrolling in a
viewport or textview (handling smooth scroll) with eg. buttons (handling
just button presses) would intermittently coerce smooth and non-smooth
scrolling depending on the widget below the pointer, the weighted
solutions were:

1) Requiring apps to set GDK_SMOOTH_SCROLL_MASK on *every* widget within
a scrolled window if they want smooth scrolling, or face odd behavior
2) Changing GDK so scroll events are only sent if
GDK_[SMOOTH_]SCROLL_MASK is in the evmask.

Both options required changes to applications (different sets though),
and there are likely way more applications with custom UIs within a
viewport than custom scrollable widgets out there, so 2) was chosen

On jue, 2012-03-15 at 12:52 -0400, Colin Walters wrote:
 On Thu, 2012-03-15 at 08:10 -0400, Matthias Clasen wrote:
 
  Thanks for bringing these up. I'm sure there will be some more fallout
  from the xi2 changes. I don't know if we'll be able to have perfectly
  seamless compatibility in the scroll event case, there are some
  complications that make that hard.
 
 But do you have a global sense of whether we should at this point:
 
 0) Patch affected applications

I think that should be done anyway for coherence (if you expect scroll
events, setting the scroll mask shouldn't hurt). I could just count 3
custom scrollable widgets in gnome outside of gtk (webkit, g-t and
gucharmap), so it shouldn't be a big effort either.

 1) Pursue hacks (or non-hacks?) in GTK+ to improve compatibility
 2) Make it opt-in

Hard to come up with a compatible solution, even if smooth scrolling is
optional.

  Carlos

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

Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4

[Carlos Garnacho]

On vie, 2012-03-16 at 12:56 +0100, Bastien Nocera wrote:

 So gtk_widget_add_events (widget, GDK_SCROLL_MASK); for every widget for
 which we want the old behaviour back, correct? Sounds doable by 3.4.

Exactly, it's pretty much that

 
 snip
   0) Patch affected applications
  
  I think that should be done anyway for coherence (if you expect scroll
  events, setting the scroll mask shouldn't hurt). I could just count 3
  custom scrollable widgets in gnome outside of gtk (webkit, g-t and
  gucharmap), so it shouldn't be a big effort either.
 
 There's a gazillion pieces of code that use scroll events and that'll
 need updating. The smaller the quick fix, the better.
 
 Cheers
 


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

Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4

[Carlos Garnacho]

On vie, 2012-03-16 at 13:59 +0100, Sebastien Bacher wrote:
 Le 16/03/2012 13:50, Patryk Zawadzki a écrit :
  Shouldn't that be the case unless you explicitly ask for 
  GDK_SMOOTH_SCROLL_MASK?
 Well then maybe there is a bug in GTK with scale widgets, sliders 
 stopped reacting to up,down scroll events i.e in the control center 
 sound panel...

http://git.gnome.org/browse/gtk+/tree/gtk/gtkrange.c#n2819

maybe dx is mistakenly non-0 in evdev's wheel up/down?

 
 --
 Sebastien Bacher
 ___
 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

Adwaita finished [Was: Re: String and UI Change Announcement Period]

[Carlos Garnacho]

Hi all,

On Thu, 2011-01-13 at 01:22 +0100, Carlos Garnacho wrote:
 Hi!
 
 On Sun, 2011-01-09 at 23:31 +0100, Vincent Untz wrote:
  Hi all,
  
  We'll enter the String and UI Change Announcement Period at the end of
  tomorrow. This means that starting on Tuesday:
  
- all string changes must be announced to both gnome-i18n@ and
  gnome-doc-list@.
  
- all user interface changes must be announced to gnome-doc-list@.
  
  It probably makes sense at least for the shell team and for the people
  working on the default theme to tell gnome-doc-list how much of the UI
  can be expected to still change during that period. It'd be a shame to
  have people starting to take many screenshots if they'll all be outdated
  a few weeks after.
 
 I just got started polishing the gnome3 theme, so I guess it'd be good
 to hold off screenshots for a few days, apologies for the inconvenience.

I consider myself mostly done with making the Adwaita theme look like
the mockups, everything needed is now in gtk+,
gtk-theme-engine-clearlooks (although it could be better moved to a
separate module) and gnome-themes-standard, so it seems like a good
moment to start with the screenshotting.

I'll get to make high/low contrast variants of the theme for a11y, but I
hope these aren't as urgent.

Again, apologies for the inconveniences.

Cheers,
  Carlos


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

Re: Adwaita finished [Was: Re: String and UI Change Announcement Period]

[Carlos Garnacho]

Hey,

On Wed, 2011-01-19 at 13:02 +, Bastien Nocera wrote:
 On Wed, 2011-01-19 at 11:55 +0100, Carlos Garnacho wrote:
 snip
  I consider myself mostly done with making the Adwaita theme look like
  the mockups, everything needed is now in gtk+,
  gtk-theme-engine-clearlooks (although it could be better moved to a
  separate module) and gnome-themes-standard, so it seems like a good
  moment to start with the screenshotting.
 
 Where do we file bugs for Adwaita [1]? I've been asking this question
 for a number of weeks (months?) and never got a straight answer.

For Adwaita issues, product gnome-themes-standard in bugzilla (the
engine will be moved shortly there, so engine and css files will live
together, different components may be added then).

For more rooted styling issues, product gtk+, component GtkStyleContext.

Cheers,
  Carlos


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

Re: String and UI Change Announcement Period

[Carlos Garnacho]

Hi!

On Sun, 2011-01-09 at 23:31 +0100, Vincent Untz wrote:
 Hi all,
 
 We'll enter the String and UI Change Announcement Period at the end of
 tomorrow. This means that starting on Tuesday:
 
   - all string changes must be announced to both gnome-i18n@ and
 gnome-doc-l...@.
 
   - all user interface changes must be announced to gnome-doc-l...@.
 
 It probably makes sense at least for the shell team and for the people
 working on the default theme to tell gnome-doc-list how much of the UI
 can be expected to still change during that period. It'd be a shame to
 have people starting to take many screenshots if they'll all be outdated
 a few weeks after.

I just got started polishing the gnome3 theme, so I guess it'd be good
to hold off screenshots for a few days, apologies for the inconvenience.

Cheers,
  Carlos

 
 Thanks,
 
 Vincent
 
 -- 
 Les gens heureux ne sont pas pressés.


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

Re: GtkNotebook scrolling usability

[Carlos Garnacho]

Hi! :),

On mié, 2010-03-10 at 16:50 -0600, Cody Russell wrote:
 So, right now GtkNotebook allows you to change tabs by using the mouse
 wheel.  Once I noticed this and the more I thought about it, it really
 seems like a terrible feature and one that may be detrimental to
 usability.

I may understand not all notebooks need this feature. Perhaps we could
have a MDI mode in GtkNotebook, so features such as mouse wheel
scrolling and tab switching on alt+number are effective on these? (The
latter isn't done in GTK+ itself yet, but is featured by most
multitabbed apps)

 
 I talked to Matthias briefly on irc, and he seemed to agree.  He
 suggested that maybe there's a use for it in the case that you have a
 ton of notebook tabs open, but I'm not quite convinced.  Just wanted to
 post on the lists and see if people have thoughts on this, otherwise I'm
 probably going to file a patch to either rip the feature out or at the
 very least make it so we can disable it. :)
 
 / Cody
 
 ___
 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

Update external dependency: system-tools-backends

[Carlos Garnacho]

Hi all!,

I've just released system-tools-backends 2.4.0, this release was
intended to be synchronized with the 2.20 schedule, and I'd like it to
be the recommended version, The minimum version can stay as it is, as
they're compatible.

Reasons? Lots of bugfixing, and being able to set WPA in network-admin
relies on it.

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

gnome-system-tools and liboobs branched for 2.20

[Carlos Garnacho]

Hi!,

I've just branched g-s-t and liboobs for 2.20, development for 2.21 will
happen in trunk as usual, future plans include:

- hal integration
- rtnetlink integration (linux only)
- optional PolicyKit use
- all I couldn't do for 2.20

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

g-s-t and liboobs branched for 2.18

[Carlos Garnacho]

Hi all!,

gnome-system-tools and liboobs have been branched for gnome-2-18, most
notable future changes/features are outlined in the roadmap :)

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

Re: problems with system-tools-backends-2.2.0

[Carlos Garnacho]

On Mon, 2007-04-02 at 12:46 -0300, Carlos Eduardo Rodrigues Diógenes
wrote:
 Hi,
 
 I just compile GNOME 2.18.0 and get in troubles with
 system-tools-backends.
 
 After trying to catch the error I realized that the
 SystemToolsBackends.pl script is used by it. When I run this file, like:
 
 perl SystemToolsBackends.pl I get the following:
 
 Can't locate Net/DBus/Test/MockConnection.pm in @INC (@INC
 contains: /opt/gnome2/share/system-tools-backends-2.0/modules/lib/perl 
 /opt/gnome2/share/system-tools-backends-2.0/scripts 
 /usr/lib/perl5/5.8.8/i486-linux /usr/lib/perl5/5.8.8 
 /usr/lib/perl5/site_perl/5.8.8/i486-linux /usr/lib/perl5/site_perl/5.8.8 
 /usr/lib/perl5/site_perl .) at 
 /opt/gnome2/share/system-tools-backends-2.0/modules/lib/perl/Net/DBus.pm line 
 98.
 BEGIN failed--compilation aborted
 at /opt/gnome2/share/system-tools-backends-2.0/modules/lib/perl/Net/DBus.pm 
 line 98.
 Compilation failed in require at SystemToolsBackends.pl line 39.
 BEGIN failed--compilation aborted at SystemToolsBackends.pl line 39.
 
 I commented the line in lib/perl/Net/DBus.pm that import the
 MockConnection.pm file and everything worked fine.

Thanks! turns out it was a problem when using the bundled version of
Net::DBus, it can be workarounded by using your distro Net::DBus. Anyway
I've just released 2.2.1 which fixes this.

 
 I also find strange that in the system-tools-backends download site:
 http://system-tools-backends.freedesktop.org/download.html
 
 It's not available the 2.2.0 version for download.

Doh! Sorry, I added
http://system-tools-backends.freedesktop.org/downloads/2.2/ , but forgot
to update the html page, it's fixed now.


Regards,
   Carlos

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

system-tools-backends 2.2.0 released

[Carlos Garnacho]

Hi!,

As promised, I've recently made a stable release of
system-tools-backends (2.2.0) in time for 2.18, I encourage that GNOME
2.18 recommends this one.

Regards,
   Carlos

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

Re: Update required system-tools-backends to 2.1/2.2

[Carlos Garnacho]

CCing the release team, it would be really nice if it got in 2.17.x
before the freezes. To take advantage of this feature, changes are
required in liboobs and g-s-t...

Regards,

Carlos

On Thu, 2007-01-04 at 20:11 +0100, Carlos Garnacho wrote:
 Hi!,
 
 As seen on http://live.gnome.org/TwoPointSeventeen/ExternalDependencies
 system-tools-backends minimum dependency version is 1.9.7, it would be
 great to upgrade that dependency to 2.1.2, it features the extensible
 list of supported interface configuration methods and wireless key types
 (for example, Feisty has support for local Zeroconf networks, and the
 g-s-t frontends should notice this without affecting other
 distributions)
 
 Another desirable effect is that the 2.1.x versions use a lightweight
 dispatcher, reducing hugely memory consumption during inactivity
 compared to the 1.9/2.0 versions (marvels of interpreted languages...)
 
 Obviously, the plan is to release s-t-b 2.2.0 with/before gnome 2.18.
 Opinions?
 
 Regards,
 
   Carlos
 ___
 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: Update required system-tools-backends to 2.1/2.2

[Carlos Garnacho]

Hi Joseph!,

I'm already aware of the mail you sent me, will look into that
tonight/tomorrow, I'm sure that 2.1.3 will have this fixed.

Regards


On Mon, 2007-01-08 at 11:44 -0500, Joseph E. Sacco, Ph.D. wrote:
 F.Y.I...
 
 At this point in space-time s-t-b-2.1.2 does not run when built
 within GARNOME-2.17.x on a linuxPPC running Fedora FC6.
 
 Hopefully, whatever problems there are can be resolved soon.
 
 
 -Joseph
 
 ==
 On Thu, 2007-01-04 at 20:11 +0100, Carlos Garnacho wrote:
  Hi!,
  
  As seen on http://live.gnome.org/TwoPointSeventeen/ExternalDependencies
  system-tools-backends minimum dependency version is 1.9.7, it would be
  great to upgrade that dependency to 2.1.2, it features the extensible
  list of supported interface configuration methods and wireless key types
  (for example, Feisty has support for local Zeroconf networks, and the
  g-s-t frontends should notice this without affecting other
  distributions)
  
  Another desirable effect is that the 2.1.x versions use a lightweight
  dispatcher, reducing hugely memory consumption during inactivity
  compared to the 1.9/2.0 versions (marvels of interpreted languages...)
  
  Obviously, the plan is to release s-t-b 2.2.0 with/before gnome 2.18.
  Opinions?
  
  Regards,
  
  Carlos
  ___
  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: Update required system-tools-backends to 2.1/2.2

[Carlos Garnacho]

Hi Vincent!

On Mon, 2007-01-08 at 19:21 +0100, Vincent Untz wrote:
 Le jeudi 04 janvier 2007, à 20:11, Carlos Garnacho a écrit :
  Hi!,
  
  As seen on http://live.gnome.org/TwoPointSeventeen/ExternalDependencies
  system-tools-backends minimum dependency version is 1.9.7, it would be
  great to upgrade that dependency to 2.1.2, it features the extensible
  list of supported interface configuration methods and wireless key types
  (for example, Feisty has support for local Zeroconf networks, and the
  g-s-t frontends should notice this without affecting other
  distributions)
  
  Another desirable effect is that the 2.1.x versions use a lightweight
  dispatcher, reducing hugely memory consumption during inactivity
  compared to the 1.9/2.0 versions (marvels of interpreted languages...)
  
  Obviously, the plan is to release s-t-b 2.2.0 with/before gnome 2.18.
  Opinions?
 
 Sorry, should have replied sooner.
 
 Are both versions compatible? Or do you need some feature that's in
 2.1.x?

2.1.x is compatible with 1.9.x/2.0.x, but it adds the feature I
explained in my original mail, which required liboobs and g-s-t code to
take advantage of it.

 
 I guess it's okay to require the newer system-tools-backends, but if the
 minimum required version is still 1.9.7, then we can change only the
 recommended version...

I've just rolled liboobs and g-s-t without the feature before the
freezes are in effect, anyway it could be great to add 2.1.x as the
recommended version, but I guess that by now the features will have to
wait for 2.20...

Regards

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

Re: Update required system-tools-backends to 2.1/2.2

[Carlos Garnacho]

On Mon, 2007-01-08 at 19:49 +0100, Vincent Untz wrote:
 Le lundi 08 janvier 2007, à 19:28, Carlos Garnacho a écrit :
  I've just rolled liboobs and g-s-t without the feature before the
  freezes are in effect, anyway it could be great to add 2.1.x as the
  recommended version, but I guess that by now the features will have to
  wait for 2.20...
 
 Hrm.
 How long would it take to add those features? I guess you already have
 some patches ready...

Effectively, I've got patches around :), I might cook a new release if
there's time enough and I'm allowed to add this change.

 
 I'd hate to see us losing those features because nobody replied to a
 mail in two weeks.

Well, It wasn't two weeks :). However, maybe just sending a mail to
d-d-l  (as said in [1]) isn't motivation enough for people to test, at
least like should be new modules. I don't know what's the best solution
though, maybe a gnome-bleeding-edge.modules in jhbuild where people may
update the external modules they want? that should at least give some
(voluntary) guinea pigs.

Regards,

Carlos


[1] http://live.gnome.org/TwoPointSeventeen/ExternalDependencies

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

Update required system-tools-backends to 2.1/2.2

[Carlos Garnacho]

Hi!,

As seen on http://live.gnome.org/TwoPointSeventeen/ExternalDependencies
system-tools-backends minimum dependency version is 1.9.7, it would be
great to upgrade that dependency to 2.1.2, it features the extensible
list of supported interface configuration methods and wireless key types
(for example, Feisty has support for local Zeroconf networks, and the
g-s-t frontends should notice this without affecting other
distributions)

Another desirable effect is that the 2.1.x versions use a lightweight
dispatcher, reducing hugely memory consumption during inactivity
compared to the 1.9/2.0 versions (marvels of interpreted languages...)

Obviously, the plan is to release s-t-b 2.2.0 with/before gnome 2.18.
Opinions?

Regards,

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

Re: Liboobs versions

[Carlos Garnacho]

Hi!,

On Tue, 2006-12-05 at 03:13 -0300, Mariano Suárez-Alvarez wrote:
 Hi all,
 
 gnome-system-tools now depends on liboobs 2.17.4 while
 http://cvs.gnome.org/viewcvs/*checkout*/jhbuild/modulesets/freedesktop-2.18.modules?rev=1.8,
  which is used by the GNOME 2.18 moduleset, still lists 0.6.0. 

Yes, that dependency was added yesterday to use an API addition.

 
 http://live.gnome.org/TwoPointSeventeen/ExternalDependencies would
 need a bit of liboobs love too.

I just learnt that liboobs is considered an external dependency, I
(naively?) thought that it was a desktop module, given that it contains
90% of the logical weight of g-s-t and based on a brief conversation
with the release team some time ago [1].

Maybe should liboobs be considered a Desktop module?

Regards,
Carlos


[1] http://mail.gnome.org/archives/release-team/2006-June/msg5.html

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

Re: Proposal: NetworkManager for GNOME 2.18.

[Carlos Garnacho]

On Tue, 2006-12-05 at 10:30 +1100, Jeff Waugh wrote:
 quote who=Dan Williams
 
  If it's a priority, it can certainly be done.
 
 I don't think this is wildly important - it'll just increase maintainership
 requirements for you unnecessarily.
 
 What we do need, however, is some kind of co-operation between NM and the
 GNOME System Tools or other network configuration tools. This may involve
 replacing network-admin entirely (and have better fallbacks for non-Linux
 systems or crappy wifi chipsets when using NM).

Separated as they are, there are things to improve in both concepts, and
users would be certainly happy to be able to manage things from both
feature sets, so it makes much sense to integrate.

If the plan were to ditch network-admin, I'd recommend at least using
liboobs as the safe fallback, it already manages static configuration
for ethernet and wireless interfaces for many Unices quite reliably, and
other desirable stuff.

If we don't ditch network-admin, what about a enable roaming mode
checkbox that deconfigures the wifi interface and lets NM do its job?

Regards,
Carlos

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

Re: Important changes to gnome-doc-utils

[Carlos Garnacho]

Hi!,

On Fri, 2006-11-10 at 02:21 +0100, Frederic Peters wrote:
 Luca Ferretti wrote:
 
  I'm rebuilding my jhbuild sandbox, so I'll file a bug every fault.
  
  In the list of bad guys, by now I have gnome-desktop [1] and
  gnome-control-center[2]
 
 There is also at least gnome-applets[1], gnome-netstatus[2],
 gcalctool[3], gnome-system-tools[4] and evince[5].

gnome-system-tools has just been fixed

Regards

 
 I'll get some sleep and I'll file bug reports if things are not fixed by
 then.
 
 
 Frederic
 
 
 [1] http://jhbuild.bxlug.be/builds/2006-11-09-0004/logs/gnome-applets/#build
 [2] http://jhbuild.bxlug.be/builds/2006-11-09-0004/logs/gnome-netstatus/#build
 [3] http://jhbuild.bxlug.be/builds/2006-11-09-0004/logs/gcalctool/#build
 [4] 
 http://jhbuild.bxlug.be/builds/2006-11-09-0004/logs/gnome-system-tools/#build
 [5] http://jhbuild.bxlug.be/builds/2006-11-09-0004/logs/evince/#build
 ___
 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

gnome-system-tools and liboobs branched for gnome 2.16

[Carlos Garnacho]

Hi,

Don't know if it's useful information, but it's worth telling: g-s-t and
liboobs now have the fictional gnome-2-16 branch, although the DBus
changes didn't get into GNOME 2.16, some distro(s?) chose to ship it,
and they're being told to use stuff from this branch.

future plans in HEAD may be PolicyKit usage (depending on the
HAL/PolicyKit releases used in GNOME 2.18)

Regards

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

Re: gnome desktop integration library

[Carlos Garnacho]

On Wed, 2006-09-06 at 22:56 +0200, Chipzz wrote:
 On Tue, 5 Sep 2006, Havoc Pennington wrote:
 
  Why can't gtk depend on dbus? How do those reasons not apply to libgnome?
 
  I don't know, I'm asking. But there's no reason to just make an
  assumption up front that gtk can't depend on dbus, or that gnome should.
 
 Because gtk+ is not just gnome. Gtk+ is also maemo. Gtk+ is also xfce.
 Gtk+ is also a possible choice for embedded apps on phones, pdas, and
 stuff like that. Gtk+ is also a library for very simple apps, where
 very tight desktop integration does not make sense.

Not only that, Gtk+ has been the toolkit of choice for other thousands
of third party developers [1], why? my guess is that many of them
thought Gtk+ was reasonably lightweight and reasonably easy. If we make
Gtk+ depend on a several times bigger set of dependencies, we'll be
scaring away lots of people.

Gtk+ is a toolkit to make graphic applications, it must provide the
necessary reusable elements to make this an easy task, and IMHO it does
it greatly, and project Ridley is making it even better by including
stuff that was wrongly included higher in the stack.

But introducing lots of (somewhat unrelated) stuff in Gtk+ just because
we think who wouldn't need a ...? feels like the wrong approach for
me. Regarding the libgnome-whatever, having a specific library to get
integration for the desktop would be very welcome by many people, of
course the current libgnome has been a mistake, but I'm sure that many
people here has learnt from the past errors to let them happen again :).

Regards


[1] Don't have numbers really, but I bet that the amount of apps in
Debian using Gtk+ is HUGE

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

Re: gnome desktop integration library

[Carlos Garnacho]

On Wed, 2006-09-06 at 15:42 -0400, Havoc Pennington wrote:

snip
 If you look at for example the GdkSession sketch I posted though, people 
 seem to feel that is GNOME specific for some reasons I don't understand 
 at all; the functionality is completely implementable on Windows and KDE 
 I know, and probably other platforms too.

We can't control the situation in all the environments, and a possibly
non-functioning feature (depending on many factors) would be annoying
for app users, misleading for API users and very possibly painful to
maintain. I'd prefer a more modest approach and do this at a more
restricted level.

Regards

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

Re: Winners of today's build breakages

[Carlos Garnacho]

On Thu, 2006-07-27 at 16:36 +0200, Frederic Peters wrote:
 Carlos Garnacho wrote:
 
  This decision saddens me... I should mention that there's an internal
  copy of Net::DBus in CVS since July 7th, it's just that I've lacked both
  time and internet connection to make tarballs, I'll work on it, although
  it seems a bit late...
 
 And it would probably be better for this internal copy not to install
 in Perl global directories; unfortunately I have not enough Perl-fu to
 know about this.

I think the main issue in that case is packagers, and they'll probably
package Net::DBus separatedly and avoid the internal copy, but you're
right, it's fixed in HEAD.

Regards

 
 
 Frederic
 ___
 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: Winners of today's build breakages

[Carlos Garnacho]

On Wed, 2006-07-26 at 08:30 -0600, Elijah Newren wrote: 
 On 7/26/06, Joseph E. Sacco, Ph.D. [EMAIL PROTECTED] wrote:
  (0) currently running 2.15.90
  For what it's worth, I am currently running 2.15.90, built from the
  source in GARNOME CVS-HEAD
 
  (1) dbus API deprecation issues
  There are some other packages provided by GARNOME that still require
  updating to handle dbus API deprecation:
  * avahi
  * dhcdbd
  * hal
  * liboobs
 
 Note that the gnome-system-tools gnome-2-14 branch will be used for
 Gnome 2.16, and thus liboobs isn't relevant until at least Gnome 2.18.
  I complained for months that the perl-net-dbus hard dependency either
 needed to be brought up on d-d-l and a consensus reached that it's
 okay as a dependency, or that the dependency be made optional.
 Neither happened, so the new version of gnome-system-tools will not be
 used.

This decision saddens me... I should mention that there's an internal
copy of Net::DBus in CVS since July 7th, it's just that I've lacked both
time and internet connection to make tarballs, I'll work on it, although
it seems a bit late...

Regards


 
  * NetworkManager
  * rhythmbox
 ___
 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

gnome-system-tools branched for 2.14

[Carlos Garnacho]

Resent, it seems it didn't arrive, apologies for any duplicate...


On Wed, 2006-05-17 at 18:42 +0200, Carlos Garnacho wrote:
 Hello all,
 
 As usual, there's now a gnome-2-14 branch, which will be left in the
 cold, being fed with small maintenance patches until it finally dies.
 
 HEAD will get all the love, the big plan for it is to get rid of the
 cranky XML interface and use liboobs to communicate with
 system-tools-backends HEAD through DBus. PolicyKit will be studied in
 depth to replace the g-s-t handmade auth method.
 
   Regards
 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-system-tools branched

[Carlos Garnacho]

Hi,

gnome-system-tools has been branched, 2.12 stuff will go to the
gnome-2-12 branch.

I initially wanted to dump all the liboobs work to HEAD, but didn't have
enough time during this release cicle, so it will go to liboobs-branch
and HEAD will contain several small UI and strings improvements

Carlos

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

Re: Gtk+ 2.8 for GNOME 2.12

[Carlos Garnacho]

 --- Vincent Untz [EMAIL PROTECTED] escribió:

snip
 
 As for my position on this: I was at first reluctant to the shipping
 with GTK+ 2.8 option, but I really believe we can find the problems
 if it gets tested *now*. So I'm all for GTK+ 2.8 *now*.

Besides a couple of visual glitches in XFree86 (which have been mostly fixed), 
it has always run pretty fine for me, I'd vote yes :)

  Carlos


 
 Vincent
 
 -- 
 Les gens heureux ne sont pas pressés.
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list
 




__ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: proposed modules [was Re: gnome-keyring-manager in 2.12]

[Carlos Garnacho]

 --- Luis Villa [EMAIL PROTECTED] escribió:

 On 7/14/05, Carlos Garnacho [EMAIL PROTECTED] wrote:
  Hey :),
  
   --- Luis Villa [EMAIL PROTECTED] escribió:
  
   I've just updated the wiki:
   http://live.gnome.org/ReleasePlanning_2fTwoPointEleven_2fDesktop
  
   As of this moment, proposed modules are (AFAIK):
  
   * evince: seems to be a strong consensus for this
   * gnome-keyring-manager: I've not heard a strongyay or nay on this, I
   think even from the maintainer.  James? Still alive? :)
   * eggcups/libgnomecups: fairly freshly proposed. I'm a little nervous
   about testability, but it has wide deployment already, so... shrug
  
  * services-admin from g-s-t: given that it wasn't accepted when other
  tools got in.
 
 Put it on the wiki page :)

/me whistles and puts it in disguise

  Thanks :)

 Luis
 






__ 
Renovamos el Correo Yahoo! 
1GB de capacidad, nuevos servicios y más seguridad 
http://correo.yahoo.es
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

RE: proposed modules [was Re: gnome-keyring-manager in 2.12]

[Carlos Garnacho]

Hey :),

 --- Luis Villa [EMAIL PROTECTED] escribió:

 I've just updated the wiki: 
 http://live.gnome.org/ReleasePlanning_2fTwoPointEleven_2fDesktop
 
 As of this moment, proposed modules are (AFAIK):
 
 * evince: seems to be a strong consensus for this
 * gnome-keyring-manager: I've not heard a strongyay or nay on this, I
 think even from the maintainer.  James? Still alive? :)
 * eggcups/libgnomecups: fairly freshly proposed. I'm a little nervous
 about testability, but it has wide deployment already, so... shrug

* services-admin from g-s-t: given that it wasn't accepted when other 
tools got in.

   Regards

 
 I think that this is it ATM. Anyone have anything else to add? Speak
 now or forever hold your peace :)
 
 Luis
 
 
 On 7/14/05, Christian Rose [EMAIL PROTECTED] wrote:
  lör 2005-07-09 klockan 22:54 +0200 skrev Christian Rose:
   fre 2005-06-10 klockan 13:53 -0400 skrev Luis Villa:
Seems to me that gnome-keyring-manager should at a minimum go into
meta-gnome-proposed in jhbuild*, and seems (to me) to fill a fairly
important need for key management, and should probably be in 2.12.
Anyone have any thoughts on this?
   
For reference, it wasn't in 2.8 because of issues addressed here:
http://mail.gnome.org/archives/desktop-devel-list/2004-July/msg00412.html
   
the usability list thread in the 2.9 timeframe did not seem to go very 
far:
http://mail.gnome.org/archives/usability/2004-December/msg4.html
   
but some new UI was committed in January of this year, and having just
used it for the first time, it seemed to suitably hide the keyring
issues I wasn't interested in (which is basically all of them, since
I'm still not completely sure what the hell a keyring is :) So...
anyone? Bueller?
  
   Was gnome-keyring-manager officially proposed? I'm trying to go through
   what's been proposed so far in order to be able to point the translators
   to those modules, but it seems gnome-keyring-manager was never added to
   http://live.gnome.org/ReleasePlanning/TwoPointEleven/Desktop .
  
  Any news on this? Was or wasn't gnome-keyring-manager officially
  proposed? And how about evince? Or did both of these proposals just fall
  inbetween the cracks?
  
  We need some clarification here.
  
  
  Christian
  
 
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list
 






__ 
Renovamos el Correo Yahoo! 
1GB de capacidad, nuevos servicios y más seguridad 
http://correo.yahoo.es
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

switching to g-c-c shell? [Was: Re: Control center and capplet merging]

[Carlos Garnacho]

On Mon, 2005-06-27 at 14:11 -0400, Rodney Dawes wrote:
 Merging items could be useful. However, I don't think just shoving the
 same existing UI into multiple tabs in a single dialog will help really.
 It will just mean less things in the menu, and more confusion to users
 who are looking for things that are no longer there.
 
 See gnome-control-center. This is in gnome upstream now. However, it is
 totally hidden. :-/

Seems a bit annoying for me too, in fact, I've been working during 2.11
to get gnome-control-center in shape, by adding better/faster layout
functions, RTL support and accessibility support (all of this is now in
CVS [1]), now I'd like to propose it as the default way to access
preferences.

Some may think that it could encourage people to add more capplets, but
that's already happening, in the last 2 releases we've added Multimedia
systems selector, Remote desktop and Removable drives and media, so
we should at least find a way for not punishing users because we don't
follow our own rules :) (HIG says that when there are more than 15
elements in a menu, better think in displaying information in other way)

So here's my vote to get rid of that horrid submenu :)

Regards

[1] might look like this:
http://www.gnome.org/~carlosg/stuff/control-center/g-c-c.png


 
 -- dobey
 
 On Mon, 2005-06-27 at 09:14 -0400, Eric Larson wrote:
  On the usability front, I am not sure it is best to merge tools. While
  it does make some sense it could also be more confusing to the user
  because it forces the user to deal with fonts when they only want to
  change the theme. I think the larger issue is not how many system/admin
  tools there are but rather how they are organized. This is a subtle
  difference but I think it makes some sense. BTW, I am using debian
  unstable if anyone would like to know what I am seeing. 
  
  The Desktop menu on the panel has a huge amount of options which are
  organized into one long list. It seems things could be better by having
  an actual control panel that could help to organize different areas
  better. Something in nautilus where the view shows a title and break
  before showing icons specific to that group could be helpful in
  organizing the mass of preferences while keeping each individual
  interface clean and simple. Although, I am a bit bias, Ximian desktop
  does this. It needs work of course because it is pretty out of date, but
  if we consider things like windows users and mac users, a control panel
  type window that shows preferences in an organized fashion may be very
  usable. 
  
  This is Just my two cents of course :) I am not sure of the current
  scope or context of this problme so I apologize in advanced if it is not
  relevant. 
  
  Eric
 
 
 ___
 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

[PROPOSAL] services-admin from g-s-t for 2.12

[Carlos Garnacho]

Hi everybody!,

I haven't seen any proposal in the whole 2.11 period, so here's one to
break the ice: I'm proposing services-admin from gnome-system-tools for
2.12, the last g-s-t version (1.3.0[.x]) compiles it by default,
featuring a dead easy GUI [1] to activate/deactivate services, both in
real time and at computer startup. It's still missing more descriptions
to handle the most used services, but that's an easy task.

Hope you like it

[1] http://www.gnome.org/~carlosg/stuff/gst/new-services-2.png

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

Re: switching to g-c-c shell? [Was: Re: Control center and capplet merging]

[Carlos Garnacho]

 --- Havoc Pennington [EMAIL PROTECTED] escribió:

 On Wed, 2005-07-06 at 19:37 +0200, Carlos Garnacho wrote:
  Some may think that it could encourage people to add more capplets, but
  that's already happening, in the last 2 releases we've added Multimedia
  systems selector, Remote desktop and Removable drives and media, so
  we should at least find a way for not punishing users because we don't
  follow our own rules :) 
 
 Right or we could just fix the problem - wait that would be INSANE ;-)

just feels better quoted in that piece of sarcasm, even if we do an enviable
work and reduce the number of capplets without moving them from the menu, we 
will have still a growing blob of uncategorized settings (at least, I think that
the tendence to grow is quite noticeable, and even more if we mix at some point 
g-c-c and g-s-t)

I really think that, while the PreferencesRevisited page in l.g.o has pretty 
good ideas, we still should try to show a categorized view of all preferences,
instead of letting users try their luck in the menu (what does Session beside 
Sound? Why there's a separate sublevel for accessibility? ... ;)

So, said this, IMHO fixing one problem is not an excuse to leave the other 
unfixed


 
 If we can't get rid of at least Multimedia systems selector we sure do
 suck.

:)

   Regards

 
 Havoc
 
 
 




__ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: [PROPOSAL] 'Change Password GUI'

[Carlos Garnacho]

--- shakti [EMAIL PROTECTED] escribió:
 Diego Gonzalez wrote:
 
  On Tue, 2005-05-17 at 18:10 +0530, shakti wrote:
 
 Hi,
 
 I would like to propose gnome-passwd (a password change GUI) for GNOME 2.12.
 
 GNOME currently doesn't have a GUI to change the user's  password. This 
 GUI can be integrated as part GNOME control-center using which users can 
 change thier password without having to go to command line.
 
 
 
  There is a capplet on the control-center that i wrote it has some 
  support for changing the password of a user,
  it uses the passwd command thorugh a pipe (using code i stole from 
  gnome-system-tools) to change it, the capplet
  mostly works, but there are some things that need to be finished 
  before that capplet can be enable in the
  default build. I you want to improve the code to change the password 
  or finish the loose ends of the capplet go
  ahead, it is called about-me.
 
 I wrote gnome-passwd as a simple and light-weight utility for 2.12 
 timeframe. It is designed to use PAM authentication directly to allow 
 the use of any new features which PAM might provide in future. So, 
 essentially, I do not use the 'passwd' utility.

beware, there are still platforms supported by gnome which don't use PAM 
(last time I looked at slackware it didn't, for example), and I'd be very 
careful in the addition of gratuitous setuid executables, passwd is very
tested and offers a quite similar CLI across all supported platforms

   Regards


 
 I agree about-me handles more user information. However, I need to look 
 into it further.
 
 As we stand today, gnome-passwd is a ready-to-be-integrated tool, which 
 would help users change their password without the root passwd contraint.
 
 Thanks for your review comments.
 
 - Shakti
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list
 



__ 
Renovamos el Correo Yahoo! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: RFC: On-line Content Filtering of directories

[Carlos Garnacho]

--- Scott J. Harmon [EMAIL PROTECTED] wrote:
 I don't want to select, I want to hide everything but the expression.
 (Hmmm, you implying I'm abnormal? ;-) So are you a 'normal user'? Who is
 a 'normal user'?)

IMHO, someone who very probably won't know what a glob pattern is :)

   Regards

 
 Ed Mack wrote:
  On Wed, 2005-04-20 at 09:40 -0500, Scott J. Harmon wrote:
  
 It seems to me it would be intuitive to place filtering in the Location 
 bar for the file browser.  For example, if I wanted all documents in a 
 directory I could put /home/scott/*.sxw and I would only be shown 
 files ending with .sxw. (I actually tried this a few months ago by 
 accident (-:)
  
  
  Normal users may never even touch the location bar, never mind type
  expressions like that. Anyway, there's Select Pattern for that.
  
  Ed Mack
  
 
 ___
 desktop-devel-list mailing list
 desktop-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/desktop-devel-list
 



__ 
Renovamos el Correo Yahoo!: ¡250 MB GRATIS! 
Nuevos servicios, más seguridad 
http://correo.yahoo.es
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list