gmane.comp.desktop.xfce.devel.version4

Re: About Gtk3/Gtk2 in 4.12

Natanael Copa — 2012-05-25T16:22:11

On Fri, 25 May 2012 10:11:50 -0500
Robby Workman <rw< at >rlworkman.net> wrote:


I just discovered udisks2. will give it a shot.

Thanks!

-nc

Re: About Gtk3/Gtk2 in 4.12

Robby Workman — 2012-05-25T15:11:50

On Fri, 25 May 2012 13:32:52 +0200
Natanael Copa <ncopa< at >alpinelinux.org> wrote:



Not quite.  You need gvfs with EITHER gnome-disk-utility <= 3.2.x
(so gvfs builds the gdu volume monitor) OR udisks2 (so gvfs builds
the udisks2 volume monitor).  If you go with udisks2, there is no
need at all for gnome-disk-utility.




Well, what I've got here is a hybrid mix - there are a few things
that you will need gtk+3 if you have a recent version of the thing
(e.g. libnotify).

-RW

Re: About Gtk3/Gtk2 in 4.12

Natanael Copa — 2012-05-25T14:09:09

On Fri, 25 May 2012 13:53:16 +0200
Maximilien Noal <noal.maximilien< at >gmail.com> wrote:


sorry i meant 1GB


gvfs needs to be built with gnome-disk-utility for the USBs show up?
(using lxpolkit works too)

I have been holding the gvfs update due to this for a while now.

Re: About Gtk3/Gtk2 in 4.12

Maximilien Noal — 2012-05-25T11:53:16

2012/5/25 Natanael Copa <ncopa< at >alpinelinux.org>:
I'd say that anything is useless with only 1 MB of RAM since the late
~1980s. ;-)

How is gnome-disk-utility required  for GIO support to work ?

I don't have it in Xubuntu or Archlinux, only gvfs is required (and
gvfs requires policykit-1-gnome / polkit-gnome) and it works fine (USB
disks are auto-mounted, etc.).

thunar-volman is all I need if I want more mount options / automation.

Re: About Gtk3/Gtk2 in 4.12

Natanael Copa — 2012-05-25T11:32:52

On Fri, 25 May 2012 09:36:42 +0200
Nick Schermer <nick< at >xfce.org> wrote:


Are the speed and resource issues reported upstream? (I think your
findings might explain why ubuntu have been close to useless with 1MB
ram latest releases)

Do you have specific testcases?

Did you test different gtk3 versions (i.e is the current 3.4 better
than the first ones? Is there a tendency that those things are getting
better or worse in gtk?


:-(

gnome-disk-utiltity, needed for GIO support in thunar is gtk3 only
nowdays. Maybe someone should write a xfce-disk-utility (gtk2) with the
minimal things needed to mount USB disks in thunar?

Are there many/any of the dependencies that are gtk3 only? Might be
nice to have a list of those some place.


Yes. The "fun" factor should not be underestimated.


I was really hoping for gtk3 and fixing (or helping upstream fix) the
issues in gtk itself.

That said, to my understanding the only "payment" you get for your work
on xfce is the "fun" part so I think you should do whater you pre

About Gtk3/Gtk2 in 4.12

Nick Schermer — 2012-05-25T07:36:42

Folks,

We've ported a couple of parts of Xfce to Gtk3 and IMO it is better to 
stick with Gtk2 for 4.12. Beside that fact that it is an awful amount of 
work, the resulting applications are visibly slower (large treeviews 
mostly), consume more resources and hardly any advantages (api 
technically).
So for me porting the core of Xfce in the state Gtk3 currently is, is 
for me a no-go.

That said we can still prepare for this to make the switch easier in 
the future.

- Depend on Gtk 2.24.
- Use new API (compile with GSEAL) as much as possible and drop 
deprecated API.
- In a number of places we use Gtk widgets instead of our own versions.
- Libraries (libxfce4ui and exo) can provide a gtk2 and gtk3 version of 
the lib.
- Some core modules (xfce4-appfinder for example) can optionally 
compile against gtk3. This allows us to track Gtk3 progress and possibly 
help finding issues.

This will give us more time to port parts to Gtk3, because with the 
complexity it brings, it will consume a lot of time, leaving n

Re: Panel widgets library

Harald Judt — 2012-05-19T09:01:52

Hi,

Am 19.05.2012 06:24, schrieb Andrzej:

After looking and hacking at various plugins, I can only confirm what 
Andrzej says about consistency and duplication. For example, when 
switching to the vertical mode, how should the plugins behave? 
systemload, netload, cpugraph, diskperf,... some of them handle the 
orientation differently than others. In this mode, some look similar to 
how they're expected to look in deskbar mode (I guess because it's new 
and was not available before and the authors decided this way of 
presentation was better), but some rotate their widgets to the right. 
What if the users expect them to be rotated to the left and arranged 
from the bottom to the top instead of from the top to the bottom? It's 
not supported at the moment and certainly a matter of taste and perhaps 
a bit too wide of scope.

I've seen there are some detailed guidelines at 
http://wiki.xfce.org/dev/hig/panel-plugins, that's already a good start. 
I wonder when those have been published... How about propagati

Panel widgets library

Andrzej — 2012-05-19T04:24:36

I've been thinking about what we can do to improve quality and 
portability of panel plugins (which isn't exactly our strongest point).

Here is one idea:

- split libxfce4panel into two libraries:
   1. libxfce4panel, containing only stuff necessary for talking to the 
panel,
   2. libxfce4panel-widgets (pick your name) - containing additional 
panel-related stuff (panel image, hvbox, new widgets[1]) and is portable 
across panel versions.

Reasons:

- Non-core plugins are expected to be portable across Xfce versions. But 
because they depend on libxfce4panel, it is very difficult to add new 
functions this library - any new features have to be used conditionally, 
which requires changing all the plugins.
- libxfce4panel-widgets could evolve independently from the panel and be 
backward compatible with previous panel/Xfce versions.
- (why not simply use libxfce4ui) the new library would depend on 
libxfce4panel.

[1] we could for example provide a basic plugin widget, which could be 
inserted in the plugin

Re: First gtk3 results

Auke Kok — 2012-05-18T04:44:13

yes, but, I'd rather use a half-assed C implementation to do something 
trivial like that in Python ;^)

Auke

Re: First gtk3 results

Nick Schermer — 2012-05-16T15:37:14

Ran awk '/Pss:/{ sum += $2 } END { print sum }' /proc/$(pidof 
thunar)/smaps

for Thunar gtk2 this gives 10908, for gtk3 14524

Nick

Ps, ps_mem also uses the Pss value from smaps.

Re: First gtk3 results

Auke Kok — 2012-05-16T03:40:03

can you post PSS usage?

you can get Pss from /proc/<pid>/smaps. Add all the rows that start with 
Pss: up. There's a tool called 'memuse' around that does it for you.

Auke

Re: First gtk3 results

Nick Schermer — 2012-05-15T20:43:57

Thunar is now also working in gtk3, or at least, parts of it 
(exo-icon-view is not working). Results are more or less equal: a size 
difference of ~2.5 MiB. Independent of the number of files used.

  7.2 MiB +   2.1 MiB =   9.3 MiB thunar (gtk3, 15 files)
  5.2 MiB +   1.5 MiB =   6.7 MiB thunar (gtk2, 15 files)

10.9 MiB +   2.1 MiB =  13.1 MiB thunar (gtk3, 1680 files)
  9.1 MiB +   1.5 MiB =  10.6 MiB thunar (gtk2, 1680 files)

The shared size will also drop a bit more if we port more gtk3 apps 
that use the xfce libraries.

Speed feels more or less the same (hard to measure that on an i7 ;-).

Nick

Getting started with development, helping out the project

Zsolt Peter Basak — 2012-05-14T07:56:31

Dear XFCE4-dev mailing list subscribers!

I have decided to help out the project, as I want to gather more
experience, and want to make XFCE better. First, I'm pretty sure that
one can't just jump into the middle of coding, there is a road to
that. The first thing I've done after checking the website, was
looking through the "Getting Involved" information. Sadly, the
development and bug fixing part is pretty short, not that informative.

So I would like to ask you. How could I start helping out the project?
Like sorting out bugs, reviewing them, mark them for review/close, and
so on.

Thanks in advance.
Best regards,
(john- on IRC)

Typo in docs.xfce.org

Masato Hashimoto — 2012-05-12T03:31:22

Hi,

There is a typo in http://docs.xfce.org/xfce/xfce4-session/advanced.
(due to the docwiki syntax).


'--' is replaced with '–' in '--with-ck-launch'.

Thx

Revive panel plugins HIG

Landry Breuil — 2012-05-08T19:38:26

Hi,

i'd like to revive/finish the discussion about panel plugins HIG that
started here : http://wiki.xfce.org/de/panel-hig (i suppose de was
meant to be 'dev') and seems to have resulted in
https://wiki.xfce.org/dev/hig/panel-plugins, but apparently not all
information was merged here. I've added a section about the new
features/possibilities given by panel 4.10 here :
https://wiki.xfce.org/dev/hig/panel-plugins?&#panel_properties . That
chunk is to be discussed here on the ml, on the wiki or on irc..

Now there are so many configuration possibilities (size * mode *
nrows..), and so many different levels of maintained plugins that it
becomes a real mess to get a consistent look & behaviour between
various plugins. I've started revamping battery & diskperf plugin UI,
but if we manage to settle on something i'll happily modify the
plugins where i have write access so that they comply to some sort of
HIG.

Landry

Ps; this is not a 'please add your feature request here' mail.

xfce4-settings: Circular scrolling.

Peter de Ridder — 2012-05-08T18:11:21

Hi devs,

I created a feature branch for xfce4-settings. "peter/circularscrolling".
This branch includes an addition to the mouse settings to enable
circular scrolling.
Since this would give 4 options for scrolling I also changed the UI
from radio buttons to a combo box.

The technical implementation is a followed:
If circular scrolling is selected and horizontal scrolling isn't. The
synpatics settings "Synaptics Circular Scrolling" is set to 1 and
"Synaptics Circular Scrolling Trigger" is set to 0 (any edge).
If circular scrolling and horizontal scrolling is selected. The
synpatics settings "Synaptics Circular Scrolling" is set to 1,
"Synaptics Circular Scrolling Trigger" is set to 3 (right edge) and
"Synaptics Edge Scrolling" is set to [0 1 0] (Only horizontal
scrolling).

Does anyone have objections if I merge this into trunk?
I'm planning to merge this on Thursday.

Regards,
Peter

[RFC] [PATCH] Option to show blinking buttons from all workspaces inWindow Button

Mathieu Chouquet-Stringer — 2012-05-08T16:28:18

Hello,

[Resending as I used the wrong email for the list)

I think Xfce used to have this feature (a long time ago or maybe I'm just
confused) where you could have blinking buttons for urgent windows which
are not in your current workspace.

Right now, blinking buttons only works if (or'ed):
- the urgent window is in your current workspace
- you have the "Show windows from all workspaces or viewports" enabled

There's even a bug open regarding this issue:
https://bugzilla.xfce.org/show_bug.cgi?id=6150

I also recall the "blinking on all workspaces" code was removed as some
people didn't really appreciate this feature.  Specially given it wasn't
an option: it was the standard behavior, whether you'd like it or not.

I've never hacked Xfce or anything remotely gtk/X related so bear that
in mind when you read the following...

I've cloned xfce4-panel from git and created a patch to fix this.

Right now, it's an optional feature (disabled by default) called "Show
all blinking windows" (for a lack of creativity

Re: cleaning up xfce-dev-tools

Natanael Copa — 2012-05-08T14:25:53

On Tue, 08 May 2012 15:27:16 +0200
Nick Schermer <nick< at >xfce.org> wrote:



Not that I know.

I was more thinking of a cleanup as in remove code that does not really
need to be there.

-nc

Re: cleaning up xfce-dev-tools

Natanael Copa — 2012-05-08T14:13:04

On Tue, 08 May 2012 13:20:33 +0000
Jannis Pohlmann <jannis< at >xfce.org> wrote:
 

1) Because I have wanted to contribute to xfce long time. But every time
i get demotivated but the .in.in. Its just so ugly and does not inspire
to write clean and efficient code. (autotools is ugly enough)

2) Packagers once in a while need to patch things. When patching the
general rules are:
* If upstream has fixed the issue, use that patch rather than reinvent.
* Don't patch generated code. Fix the stuff that generates code.
* Get you patch accepted upstream
  - send them a patch they simply can apply at first sight without any
    rework (otherwise the reported bug tend to remain unresolved for
    much longer time)

None of those are possible when configure.in.in is involved.

3) I like clean and efficient code.


Ok. That makes it easy.

Please at least ship the .in.in files with the tarballs.

-nc

Re: cleaning up xfce-dev-tools

Nick Schermer — 2012-05-08T13:27:16

Is there a case where the released packages are broken?

Nick

Re: cleaning up xfce-dev-tools

Jannis Pohlmann — 2012-05-08T13:20:33

On Tue, 8 May 2012 15:02:09 +0200, Natanael Copa <ncopa< at >alpinelinux.org>
wrote:

First and foremost I'd like to hear *why* you feel an "urgent need"
to do this and what is bothering you about the .ac.in, .in.in files.

With no good reasons provided I think your "how do you want it
to work?" question is easily answered with: exactly the way it works
at the moment. ;)

  - Jannis